Detailed Description
For the purpose of making the objects, technical solutions and advantages of the embodiments of the present application more apparent, the technical solutions of the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application, and it is apparent that the described embodiments are some embodiments of the present application, but not all embodiments of the present application. All other embodiments, which can be made by those skilled in the art based on the embodiments of the application without making any inventive effort, are intended to be within the scope of the application.
In one exemplary configuration of the application, the terminal, the devices of the services network each include one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
The memory may include volatile memory in a computer-readable medium, random Access Memory (RAM) and/or nonvolatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.
Computer-readable media include both permanent and non-permanent, removable and non-removable media, and information storage may be implemented by any method or technology. The information may be computer program instructions, data structures, modules of the program, or other data. Examples of storage media for a computer include, but are not limited to, phase change memory (PRAM), static Random Access Memory (SRAM), dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), read Only Memory (ROM), electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape storage or other magnetic storage devices, or any other non-transmission medium which can be used to store information that can be accessed by a computing device.
The following description will be made of terms related to embodiments of the present application.
Merck tree: the most common bottom storage structure of the blockchain can ensure that the whole tree data cannot be tampered through the root Hash.
Intelligent contract: protocols or contracts in blockchain systems that can be automatically executed allow trusted transactions to be conducted without third parties, which transactions are traceable and irreversible.
Transaction: transaction in broad terms refers broadly to all in-chain activities including transfer/contract invocation/proposal voting, etc.
Account model: an abstraction in a blockchain network is used to represent and manage user assets, identifications, and interactions. This model describes the structure, attributes, and behavior of accounts in the blockchain.
Zero-knowledge proof (ZKP): refers to the ability of a prover to trust that a certain assertion is correct without providing any useful information to the verifier.
ZkSNARK: the full scale zero-knowledge Succinct Non-INTERACTIVE ARGUMENTS OF KNOWLEDGE is a non-interactive succinct zero knowledge proof and is the most classical encryption algorithm system in the zero knowledge proof.
Zero knowledge proof circuit: the zero knowledge proof algorithm generation and verification logic defined by the developer comprises privacy parameters and public parameters, the correctness of the circuit can be demonstrated to a third party under the condition that the privacy parameters are not disclosed, a proving person generates ZKP proof by using all the parameters, and the proving person verifies the validity of the proof by using the ZKP proof and the public parameters.
The actual application scene of the method of the embodiment of the application can be as follows: assume that the user has two accounts, an X account and a Y account. The user uses the X account as a social account daily, and other social accounts of the user, such as a video website account, a Twitter account, and the like, are bound, i.e., based on the X account, the video website account, the Twitter account, and the like bound with the X account can be found. All operations and assets under the X account are visible to all due to the openness of the blockchain. Other people can check all transactions under the X account and the assets held under the X account through means such as a blockchain browser.
Assuming that a user wants to purchase a collection of assets, he wants to prove that he does own the collection of assets, but does not want to disclose when, through what channels, from where, at what prices the collection of assets was purchased. Thus, the user enables another Y account on the chain that is completely unrelated to the X account, purchasing the batch of assets. Since the Y account is completely independent of the X account in the chain, the X account and the video website account, twitter account, of the user bound to the X account cannot be deduced from the Y account. While others can find it through a blockchain browser or the like, the Y account has acquired a batch of assets, it is not known in the real world, and specifically who acquired the batch of assets.
This can be accomplished by the method of the present embodiment in order to prove possession of the purchased asset without exposing the user's Y account. The method comprises two processes of generating asset privacy certification and asset privacy verification.
In the process of generating privacy asset certification, the user uses the interaction between the Y account and the central mechanism to request to generate certification data of the on-chain address of the Y account held by the user, and generates ZKP certification data based on the ZKP mode, wherein the ZKP certification data can certify that the user is positioned on the current merck tree to a third party without exposing the user address and the merck certification path, namely, the user holds a specific number of assets.
In the asset privacy verification stage, the user verifies by submitting generated ZKP certification data and the user's social account (e.g., the user's commonly used video website account) to the blockchain public chain to certify that the specific person to whom the submitted social account corresponds owns the corresponding asset without exposing that the user purchased the asset using the Y account.
Fig. 1 is a flow chart of a method for performing asset privacy certification according to an embodiment of the present application. The method comprises at least step S101, step S102 and step S103 performed by the client device, and step S201 and step S202 performed by the central office device.
The method according to an embodiment of the present application employs a merck (Merkle) tree as the underlying data storage structure.
The target user according to the embodiment of the application carries out transaction through the first account to obtain the target asset. Wherein the target user is a user who wishes to verify possession of the target asset by way of zero knowledge proof.
Wherein the assets in the target asset refer to assets in a broad sense, including homogeneous tokens, non-homogeneous tokens, semi-homogeneous tokens, and the like. Such as points on a chain held by the user, digital collections on a chain held, etc.
Prior to the steps shown in fig. 1, the method further comprises steps S203 to S205 performed by the central authority device.
In step S203, the central office apparatus constructs a merck tree corresponding to the target smart contract, and inserts all addresses on the chain of the target smart contract on the merck tree.
Optionally, the central agency device screens the on-chain address of the user which corresponds to the target intelligent contract and meets the condition according to the data disclosed on the chain. The filtered addresses on the chains are then ordered according to a specific rule and inserted once into the merck tree according to the determined ordering.
In step S204, the central office apparatus generates a random number, inserts the random number into the built merck tree, and obtains a hash value of the root of the merck tree.
In step S205, the central office apparatus generates a zero knowledge proof verification contract based on the merck tree, and issues a hash value of the root of the merck tree in the verification contract.
As will be described below with reference to fig. 1, in step S101, the client device sends, to the central office device, a presence verification request using the address on the first chain, the presence verification request being used to request the central office device to generate and return presence verification data of the address on the first chain that exists in the built merck tree for the user corresponding to the client device.
In step S201, in response to receiving a request from a client device, the central authority device verifies whether the address on the first chain is present in the constructed merck tree by interacting with the client device.
Specifically, the central agency device generates a random character string and transmits the generated character string to the client device; then, the central agency equipment receives signature information sent by the client equipment, wherein the signature information is obtained by signing the random character string by using an account private key on a chain; then, analyzing the received signature result to verify the validity of the signature, and obtaining the address on the chain corresponding to the signature account; the central authority device then verifies whether the on-chain address of the signature account is in the built merck tree.
In step S202, if the verification passes, the center authority device transmits corresponding presence certification data to the client device.
In step S102, the client device receives presence certification data returned by the center authority device.
In step S103, the client device generates, by the zero knowledge proof circuit, target proof data including data for proving that a user corresponding to the client device holds a predetermined number of target assets, based on the presence proof data and the hash value of the merck tree root that has been constructed in the center mechanism device.
According to the method of embodiments of the present application, a zero-knowledge proof is constructed by a trusted central authority, and a user uses an on-chain address to obtain a proof based on the zero-knowledge proof by interacting with the central authority, which proof can prove to a third party that it is useful for a certain number of assets without exposing the on-chain address.
Fig. 2 is a flow chart of a method for performing asset privacy certification according to an embodiment of the present application. The method includes at least S104 performed by a client device, and steps S301, S302, and S303 performed by a target node device of a blockchain system.
In a practical scenario, the execution subject of the method is a client device and a target node device in a blockchain system. The target node device comprises a zero-knowledgeproof (ZKP) circuit, the zero-knowledgeproof circuit is a developer-defined zero-knowledge proof algorithm generation and verification logic, the zero-knowledge proof circuit comprises privacy parameters and public parameters, the correctness of the circuit can be verified to a third party under the condition that the privacy parameters are not disclosed, a proving person can generate the ZKP proof by using all the parameters, and a proving person can verify the validity of the proof by using the ZKP proof and the public parameters.
The target node device may be a user device, or a device formed by integrating the user device and a network device through a network, or may also be an application running on the device, where the user device includes, but is not limited to, various terminal devices such as a computer, a mobile phone, a tablet computer, a smart watch, a bracelet, and the network device includes, but is not limited to, a network host, a single network server, a plurality of network server sets, or a computer set based on cloud computing, and the network device may be implemented, for example, to implement a part of processing functions when setting an alarm clock. Here, the Cloud is composed of a large number of hosts or web servers based on Cloud Computing (Cloud Computing), which is a kind of distributed Computing, one virtual computer composed of a group of loosely coupled computer sets.
In step S104, the client device sends an asset attestation request to the target node device using the second in-chain address, the attestation request including target attestation data and social account information.
The asset proving request is used for requesting to prove that a user corresponding to the social account holds a preset number of target assets.
Wherein the second on-chain address and the first on-chain address are both on-chain addresses owned by the target user, and the second on-chain address is independent of the first on-chain address. For example, the second on-chain address may correspond to an on-chain address of a blockchain account commonly used by the user, and the first on-chain address may be an on-chain address of an account used to anonymously purchase the asset.
In step S301, a target node device receives an asset attestation request from a client device, the asset attestation request including target attestation data and social account information.
In step S302, the target node device verifies the target verification data through a zero knowledge proof circuit algorithm, and a corresponding verification result is obtained.
In step S303, if the verification is successful, the target node device writes the social account information into a verification contract, so as to prove that the user corresponding to the social account information holds a predetermined number of target assets.
If the verification fails, the target node equipment returns the result information of the verification failure to the corresponding client equipment.
According to one embodiment, the method further comprises a step S304 performed by the target node device, said step S302 comprising a step S3021 and a step S3022.
In step S304, after the verification is successful and the social account information is written into a certification contract, the target node device marks the target certification data as used within the certification contract.
In step S3021, when verifying the target certification data by a zero knowledge proof circuit, verifying whether the target certification data is marked as used;
in step S3022, if the target certification data is valid and the target certification data is not marked as used, the verification result is verification success, otherwise, verification failure.
According to one embodiment, after verification is completed, the central authority publishes the random number mixed in when building the merck tree, and a third party can build the merck tree according to the address information on the chain disclosed on the chain and the random number to verify whether the central authority is disliked.
According to the method of embodiments of the present application, a zero-knowledge proof is constructed by a trusted central authority, and a user uses an on-chain address to obtain a proof based on the zero-knowledge proof by interacting with the central authority, which proof can prove to a third party that it is useful for a certain number of assets without exposing the on-chain address. The user uses another irrelevant account to submit the obtained evidence and the social account information of the user to the blockchain system for verification, and if the verification is successful, the specific person corresponding to the submitted social account can be proved to have the preset number of assets, and the account used by the user for purchasing the assets can not be exposed, so that the aim of asset privacy evidence is achieved.
The method of the application embodiment is described below in connection with an example.
FIG. 3 illustrates a flow diagram of an exemplary privacy asset attestation scenario, according to an embodiment of the present application.
The blockchain system of this example uses Merkle trees as the underlying data structure to store account information in the blockchain system. The application scenario of this example is described as follows: a user holds a digital asset through the smart contract_a using an on-chain address addrA, referred to as a large household address, and holds the digital asset a number greater than N. The user wishes to prove that he holds more than N number of the digital assets, but does not want to expose his in-chain address addrA, to prevent others from querying the user for details of the channel, time, and price to purchase the batch of digital assets based on addrA. To achieve this, the method of the present example includes two processes, an asset privacy attestation and an asset privacy verification.
Referring to fig. 2, the generating private asset attestation process of the present example includes an interaction between a client device where an attestation person is located and a trusted central authority by which the attestation person requests from the trusted central authority to generate attestation data that holds an address addrA on its own chain (merkle proof).
The data obfuscation process according to the present example includes the following steps P1 to P6:
P1: the trusted center mechanism inserts all obtained large household addresses into the Merkle tree by scanning all large household addresses in the intelligent contract_A; all the large household addresses are publicly visible on the chain, and the trusted center mechanism can sequentially insert the large household addresses into the Merkle tree after the large household addresses are ordered according to the capital letters;
P2: the trusted center mechanism generates a random number randomNum, and inserts the random number into the Merkle tree to obtain a hash value (root hash) of a final Merkle tree root (MerkleRoot); the step aims at preventing a third party from constructing a Merkle tree of a large household address to randomly generate a certificate before the certificate;
P3: the trusted center mechanism deploys zero knowledge proof verification contract_B to the chain according to the constructed Merkle tree;
p4: the client device where the prover is located sends a request to the trusted central authority to generate proof data holding the address addrA on the chain itself (merkle proof);
P5: in response to receiving a request from a client device, the trusted authority verifies whether the transaction address is a large user address by interacting with the client device and sends corresponding attestation data (merkle proof) to the client device when the verification passes.
Specifically, the trusted central authority generates a random string randomStr; the client device where the user is located signs randomStr by using the account addrA private key on the chain, and sends a corresponding signature result to the trusted center mechanism; the trusted center mechanism analyzes the received signature result, verifies the validity of the signature and obtains the addrA address of the signature account; the trusted authority detects whether the address of the signature account addrA is in the merkle tree constructed, if the verification passes, merkle proof is generated for the addrA, and the address is sent to the client device where the requesting user is located.
P6: generating a zero knowledge proof ZKP proof by using a zkSNARK algorithm based on merkle proof obtained in the asset privacy proof process and root hash published in P2 by a trusted central authority, wherein ZKP proof= zkSNARK (MerkleRoot, merkleProof); the ZKP may prove to a third party that the user address addrA is located on the currently constructed Merkle tree without exposing the user address addrA and Merkle proof.
With continued reference to fig. 2, the asset privacy verification process of the present example includes interactions between a client device where a prover is located and a node device corresponding to a blockchain public chain.
The asset privacy verification process according to the present example includes the following steps Q1 to Q4:
Q1: the client device sends a transaction to the on-chain verification contract_B by using a new on-chain account addrB to request asset verification, wherein the sent transaction parameters are ZKP proof and social account ID;
Q2: the node equipment corresponding to the public chain verifies the received ZKP proof through a zero knowledge proof circuit;
Q3: if the verification is passed, writing (insert) a social account ID submitted by the client device into a contract, and marking the ZKP proof as used in the contract to prevent subsequent secondary use by others;
Q4: after verification is completed, the trusted central authority publishes the random number randomNum mixed in the step P2, and a third party can build merkle tree according to the address information of the large household published on the chain and the random number to verify whether the central authority is disliked or not.
Up to this point, through the above-described flow of the present example, user a proves that the number of digital assets of the intelligent contract_a that a specific person corresponding to the social account ID does hold is greater than N without exposing the large user address (in-chain address addA).
In addition, the embodiment of the application also provides a first device for performing asset privacy certification in the client equipment and a second device for performing asset privacy certification in the central agency equipment, wherein the structures of the first device and the second device are shown in fig. 4.
Wherein the first device comprises: means for transmitting a presence document request to the center facility using the first on-chain address (hereinafter referred to as "first request transmitting means 101"), means for receiving presence document data returned from the center facility (hereinafter referred to as "presence document receiving means 102"), and means for generating target document data by a zero-knowledge proof circuit based on the presence document data and a hash value of the merck tree root already constructed in the center facility (hereinafter referred to as "document data generating means 103").
The second device includes: means for checking that an address on the first chain exists in the constructed merck tree (hereinafter referred to as "address existence check means 201") by interacting with the client device in response to receiving a request from the client device, and means for transmitting corresponding existence check data to the client device (hereinafter referred to as "existence check transmitting means 202") if the check passes.
Prior to operation of the apparatus shown in fig. 4, a target user according to an embodiment of the present application transacts through a first account to obtain a target asset. Wherein the target user is a user who wishes to verify possession of the target asset by way of zero knowledge proof.
Wherein the assets in the target asset refer to assets in a broad sense, including homogeneous tokens, non-homogeneous tokens, semi-homogeneous tokens, and the like. Such as points on a chain held by the user, digital collections on a chain held, etc.
The second device further comprises a merck tree construction device, a hash value acquisition device and a verification contract generation device.
The merck tree construction device constructs an merck tree corresponding to the target intelligent contract, and inserts all addresses on chains of the target intelligent contract into the merck tree.
Optionally, the central agency device screens the on-chain address of the user which corresponds to the target intelligent contract and meets the condition according to the data disclosed on the chain. The filtered addresses on the chains are then ordered according to a specific rule and inserted once into the merck tree according to the determined ordering.
The hash value acquisition device generates a random number, inserts the random number into the constructed merck tree, and obtains the hash value of the tree root of the merck tree.
The verification contract generating means generates a zero knowledge proof verification contract based on the merck tree, and issues a hash value of a root of the merck tree in the verification contract.
The following description will refer to fig. 4, where the first request sending means 101 in the client device sends, to the central office device, a presence prove request using the address on the first chain, where the presence prove request is used to request the central office device to generate and return presence prove data, which is stored in the merck tree and is constructed, of the address on the first chain, where the user corresponding to the client device holds the presence prove data.
In response to receiving a request from a client device, the address presence checking means 201 in the central authority device checks whether the address on the first chain is present in the built merck tree by interacting with the client device.
Specifically, the central agency device generates a random character string and transmits the generated character string to the client device; then, the central agency equipment receives signature information sent by the client equipment, wherein the signature information is obtained by signing the random character string by using an account private key on a chain; then, analyzing the received signature result to verify the validity of the signature, and obtaining the address on the chain corresponding to the signature account; the central authority device then verifies whether the on-chain address of the signature account is in the built merck tree.
If the verification is passed, the presence certificate transmitting means 202 transmits corresponding presence certificate data to the client device.
The presence document receiving means 102 receives presence document data returned from the center facility.
The certification data generating device 103 generates target certification data including data for certifying that a user corresponding to the client device holds a predetermined number of target assets by the zero knowledge certification circuit based on the presence certification data and the hash value of the merck tree root constructed in the center office equipment.
According to an apparatus of an embodiment of the present application, a zero-knowledge proof is constructed by a trusted central authority, and a user uses an on-chain address to obtain a proof based on the zero-knowledge proof by interacting with the central authority, which proof can prove to a third party that it is useful for a certain number of assets without exposing the on-chain address.
Referring to fig. 5, fig. 5 is a schematic structural diagram of a first apparatus for performing asset privacy certification in a client device and a third apparatus for performing asset privacy certification in a target node device of a blockchain system according to an embodiment of the present application.
Wherein the first device comprises: an asset attestation request is sent to the target node device using the second on-chain address, the attestation request including target attestation data and social account information (hereinafter referred to as "second request sending means 104").
The third device includes: means for receiving an asset certification request from a client device (hereinafter referred to as "second request receiving means 301"), means for verifying the target certification data by a zero-knowledge certification circuit algorithm to obtain a corresponding verification result (hereinafter referred to as "zero-knowledge verification means 302"), and means for writing the social account information into a verification contract to certify that a user corresponding to the social account holds a predetermined number of target assets (hereinafter referred to as "information certification means 303") if the verification is successful.
Referring to fig. 5, in step S104, the second request transmitting means 104 in the client device transmits an asset attestation request to the target node device using the second on-link address, the attestation request including the target attestation data and the social account information.
The asset proving request is used for requesting to prove that a user corresponding to the social account holds a preset number of target assets.
Wherein the second on-chain address and the first on-chain address are both on-chain addresses owned by the target user, and the second on-chain address is independent of the first on-chain address. For example, the second on-chain address may correspond to an on-chain address of a blockchain account commonly used by the user, and the first on-chain address may be an on-chain address of an account used to anonymously purchase the asset.
The second request receiving means 301 in the target node device receives an asset attestation request from the client device, the asset attestation request comprising target attestation data and social account information.
The zero knowledge verification device 302 verifies the target verification data through a zero knowledge proof circuit algorithm to obtain a corresponding verification result.
If the verification is successful, the information proving device 303 writes the social account information into a verification contract to prove that the user corresponding to the social account information holds a predetermined number of target assets.
If the verification fails, the target node equipment returns the result information of the verification failure to the corresponding client equipment.
According to one embodiment, the third means further comprises certification data marking means.
After successful verification and writing of the social account information into a attestation contract, attestation data tagging means tags the target attestation data as used within the attestation contract.
The information proving device 303 verifies whether the target certification data is marked as used or not when verifying the target certification data by a zero knowledge proving circuit; if the target certification data is valid and the target certification data is not marked as used, the verification result is verification success, otherwise, the verification failure is verification failure.
According to one embodiment, after verification is completed, the central authority publishes the random number mixed in when building the merck tree, and a third party can build the merck tree according to the address information on the chain disclosed on the chain and the random number to verify whether the central authority is disliked.
According to an apparatus of an embodiment of the present application, a zero-knowledge proof is constructed by a trusted central authority, and a user uses an on-chain address to obtain a proof based on the zero-knowledge proof by interacting with the central authority, which proof can prove to a third party that it is useful for a certain number of assets without exposing the on-chain address. The user uses another irrelevant account to submit the obtained evidence and the social account information of the user to the blockchain system for verification, and if the verification is successful, the specific person corresponding to the submitted social account can be proved to have the preset number of assets, and the account used by the user for purchasing the assets can not be exposed, so that the aim of asset privacy evidence is achieved.
Based on the same inventive concept, the embodiment of the present application further provides an electronic device, where the corresponding method of the electronic device may be the method for performing asset privacy certification in the foregoing embodiment, and the principle of solving the problem is similar to that of the method. The electronic equipment provided by the embodiment of the application comprises: at least one processor; and a memory communicatively coupled to the at least one processor; wherein the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the methods and/or aspects of the various embodiments of the application described above.
The electronic device may be a user device, or a device formed by integrating the user device and a network device through a network, or may also be an application running on the device, where the user device includes, but is not limited to, a computer, a mobile phone, a tablet computer, a smart watch, a bracelet, and other various terminal devices, and the network device includes, but is not limited to, a network host, a single network server, a plurality of network server sets, or a computer set based on cloud computing, where the network device is implemented, and may be used to implement a part of processing functions when setting an alarm clock. Here, the Cloud is composed of a large number of hosts or web servers based on Cloud Computing (Cloud Computing), which is a kind of distributed Computing, one virtual computer composed of a group of loosely coupled computer sets.
Fig. 6 shows a structure of a device suitable for implementing the method and/or technical solution in an embodiment of the present application, the device 1200 includes a central processing unit (CPU, central Processing Unit) 1201, which may perform various appropriate actions and processes according to a program stored in a Read Only Memory (ROM) 1202 or a program loaded from a storage portion 1208 into a random access Memory (RAM, random Access Memory) 1203. In the RAM 1203, various programs and data required for the system operation are also stored. The CPU 1201, ROM 1202, and RAM 1203 are connected to each other through a bus 1204. An Input/Output (I/O) interface 1205 is also connected to the bus 1204.
The following components are connected to the I/O interface 1205: an input section 1206 including a keyboard, mouse, touch screen, microphone, infrared sensor, etc.; an output portion 1207 including a display such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), an LED display, an OLED display, or the like, and a speaker; a storage portion 1208 comprising one or more computer-readable media of hard disk, optical disk, magnetic disk, semiconductor memory, etc.; and a communication section 1209 including a network interface card such as a LAN (local area network ) card, a modem, or the like. The communication section 1209 performs communication processing via a network such as the internet.
In particular, the methods and/or embodiments of the present application may be implemented as computer software programs. For example, embodiments of the present disclosure include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method shown in the flow chart. The above-described functions defined in the method of the present application are performed when the computer program is executed by a Central Processing Unit (CPU) 1201.
Another embodiment of the present application also provides a computer readable storage medium having stored thereon computer program instructions executable by a processor to implement the method and/or the technical solution of any one or more of the embodiments of the present application described above.
In particular, the present embodiments may employ any combination of one or more computer-readable media. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. The computer readable storage medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any of the foregoing. More specific examples (a non-exhaustive list) of the computer-readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.
The computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, either in baseband or as part of a carrier wave. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination of the foregoing. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.
Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.
Computer program code for carrying out operations of the present application may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, smalltalk, C ++ and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any kind of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or may be connected to an external computer (for example, through the Internet using an Internet service provider).
The flowchart or block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of devices, methods and computer program products according to various embodiments of the present application. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
It will be clear to those skilled in the art that, for convenience and brevity of description, specific working procedures of the above-described systems, apparatuses and units may refer to corresponding procedures in the foregoing method embodiments, which are not repeated herein.
In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices, and methods may be implemented in other manners. For example, the apparatus embodiments described above are merely illustrative, e.g., the division of the elements is merely a logical function division, and there may be additional divisions in actual implementation, e.g., multiple elements or page components may be combined or integrated into another system, or some features may be omitted, or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.
The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.
In addition, each functional unit in the embodiments of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit. The integrated units may be implemented in hardware or in hardware plus software functional units.
The integrated units implemented in the form of software functional units described above may be stored in a computer readable storage medium. The software functional unit is stored in a storage medium, and includes several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) or a processor (processor) to perform part of the steps of the methods described in the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a random access Memory (Random Access Memory, RAM), a magnetic disk, or an optical disk, or other various media capable of storing program codes.
Finally, it should be noted that: the above embodiments are only for illustrating the technical solution of the present application, and are not limiting; although the application has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit and scope of the technical solutions of the embodiments of the present application.
Furthermore, it is evident that the word "comprising" does not exclude other elements or steps, and that the singular does not exclude a plurality. A plurality of units or means recited in the apparatus claims can also be implemented by means of one unit or means in software or hardware. The terms first, second, etc. are used to denote a name, but not any particular order.