Detailed Description
In order to make the technical solutions in the present specification better understood by those skilled in the art, the technical solutions in the embodiments of the present specification will be clearly and completely described below with reference to the drawings in the embodiments of the present specification, and it is obvious that the described embodiments are only some embodiments of the present specification, not all embodiments. All other embodiments, which can be made by one of ordinary skill in the art without undue burden from the present disclosure, are intended to be within the scope of the present disclosure.
An electronic signature is data contained in electronic form in a data file that is attached to identify the signer and indicate that the signer approves the content therein. In colloquial terms, an electronic signature is a signature of an electronic form of an electronic document by cryptographic techniques. Common forms of electronic signatures are: digitized images of handwritten signatures or seals, digital signatures using biometric data (iris, fingerprint, etc.) or based on cryptographic techniques, etc. The "reliable electronic signature" requirement in the "electronic signature law" issued by the national institutes of cryptography. Specifically, the "reliable electronic signature" should satisfy the following four conditions: (1) the exclusive property and the uniqueness of the electronic signature making data; (2) confidentiality of electronic signature production data; (3) Tamper-resistance of electronic signatures and (4) tamper-resistance of data messages.
The signer identity is a core element of the electronic signature and mainly comprises an identity ID and a key corresponding to the identity ID. The uniqueness of the identity ID and the security of the key are the basis for ensuring the reliability of the electronic signature. However, current electronic signature is usually implemented based on a centralized electronic signature service, and the signature making process is actually completed by a centralized server, so that a data text to be signed needs to be sent to the centralized server during signature, and therefore, it is difficult to meet the related requirements of reliability. To solve the above-mentioned problems, one or more embodiments of the present disclosure propose an electronic signature method, which implements a reliable distributed electronic signature based on a combination of a distributed Digital Identity (DID) on a blockchain and a trusted execution environment in a client (or a mobile terminal), so as to technically satisfy four basic requirements of "reliable electronic signature" in "electronic signature law".
Distributed digital identity utilizes distributed technology to enable digital identity to be truly owned and governed by a user without requiring any intermediary to contact, own and control the user's identity and data. The distributed digital identity may be an identifier consisting of a string of characters, representing a distributed digital identity. The distributed digital identity can be a decentralised verifiable identifier, and a user can independently finish operations such as registration, analysis, update and the like of the distributed digital identity, so that the unique identity can be realized without a decentralised endorsed registration mechanism. The block chain system is used as a main stream infrastructure of the current distributed digital identity, and the characteristics of the block chain such as decentralization, tamper resistance, traceability and the like enable the establishment of an identity system with unique identification, high reliability, tamper resistance and decentralization to be realized.
Blockchains are a reliable distributed storage system that uses a decentralized, untrusted way to maintain a reliable ledger with multiple nodes in aggregate. In a blockchain system, different participants can build a distributed blockchain network through deployed nodes (nodes). The decentralized (or multicentric) distributed ledger constructed using the chain block structure is stored on each node (or on a large number of nodes, such as consensus nodes) in the distributed blockchain network. The tampering difficulty of the account book is improved through the block chain type mechanism account book structure and a multi-node account book storage mechanism, so that the block chain has the characteristics of tamper resistance, traceability and the like.
The Trusted Execution Environment (TEE) refers to a secure trusted area in a cloud server or a client (including mobile terminals such as smart phones, tablet computers, smart televisions, and the like of users) to ensure the security, confidentiality and integrity of codes and data placed therein. The trusted execution environment provides an isolated execution environment in which code and data can run and in which the code and data can be guaranteed not to be interfered by a conventional operating system during the running process, thereby guaranteeing confidentiality and integrity of the code and data. Before the client leaves the factory, an Original Equipment Manufacturer (OEM) may pre-install a trusted application (Trust Application, TA) in the trusted execution environment of the client to perform the corresponding operations. In one or more embodiments of the present description, a client may be based on an android system, an IOS system, or other operating systems, without limitation.
One or more embodiments of the present disclosure provide an electronic signature method, where in order to implement the distributed electronic signature method, a distributed digital identity corresponding to a signer and a first public key and a first private key of the signer associated with the distributed digital identity are established, where the distributed digital identity and the first public key may be stored on a blockchain, and the first private key may be stored in a trusted execution environment of a first client corresponding to the signer to ensure security of the first private key. The signer may initiate the signature through a scenario application installed in the first client, where the scenario application refers to application software installed in the client that is capable of implementing a specific service. When the context application determines that there is already a distributed digital identity corresponding to the signer, the relevant steps of the electronic signature may be continued directly. If the scenario application program determines that the distributed digital identity corresponding to the signer has not been established at present, the corresponding distributed digital identity is first registered on the blockchain for the signer, and an associated first public key and first private key are generated in a trusted execution environment of the first client.
Specifically, as shown in fig. 1, before the first client acquires the data to be signed by the signer, the electronic signature method may include:
in step S110, the first client obtains identity verification information corresponding to the signing party.
Wherein the identity verification information may be used to verify the identity of the signer. In some embodiments, the identity verification information may include two-element information (identification card number and name). Alternatively, the identity verification information may include information such as other certificate numbers and names that can uniquely indicate the signer. The identity verification information may include biometric information of the signer, for example, at least one of biometric features capable of identity recognition such as face information, fingerprint information, voice information, and iris information of the signer. By comparing the identity verification information (for example, comparing whether or not the two-element information and the face information of the signer agree) in the subsequent step, the identity of the signer can be confirmed.
In some embodiments, the scenario application may include a user profile tool that may provide on-client profile authentication capabilities, and identity verification information corresponding to the signer may be obtained by the user profile tool in the scenario application.
As shown in fig. 1, the electronic signature method may further include:
step S130, when the identity verification information is verified, the distributed digital identity corresponding to the signature party is registered in the blockchain.
The identity verification platform can verify the identity verification information, the first client side sends the obtained identity verification information corresponding to the signature party to the identity verification platform for verification, and the identity verification platform registers the distributed digital identity for the user to the blockchain after verification is passed. It can be seen that the identity verification platform includes a first functional module for performing identity verification and a second functional module for registering a distributed digital identity for a user with the blockchain, and in some embodiments the two functional modules may be independently two different service platforms and communicatively coupled to each other.
Identity verification can be understood as performing KYC authentication on a user, the identity verification platform can be completely finished locally or can be in butt joint with a third party with identity verification capability, identity verification information acquired from a first client side is sent to the third party with identity verification capability, the third party finishes verification, and a verification result returned by the third party is received. The third party with identity verification capability may be a centralized service or a distributed service.
In some embodiments, the third party with identity verification capability may be a centralized service platform, for example, the third party may be a centralized identity verification platform of a public security authority. In this way, the user verification tool can send the identity verification information to the third party for verification via the identity verification platform, and the identity verification platform performs the next action according to the verification result returned by the third party, for example, when the verification result passes, the distributed digital identity is registered for the user with the blockchain.
In other embodiments, the third party with identity verification capability may be a distributed service platform, such as a distributed service platform implemented based on blockchain. At this time, the third party may be an intelligent contract deployed on the blockchain for performing identity verification based on the identity verification information of the user, so that the user verification tool may send the identity verification information to the third party via the identity verification platform to perform verification, where the identity verification platform initiates an intelligent contract for performing identity verification by using the user to the first blockchain, and obtains a verification result from the first blockchain through the predictor. Similarly, when the verification result passes, the identity verification platform registers the distributed digital identity for the user with the blockchain.
It should be noted that, the blockchain deployed with the intelligent contract for identity verification and the blockchain for registering the distributed digital identity may be the same blockchain or different blockchains. The identity verification platform requires the ability to interface with different blockchains when it is different blockchains, e.g., the identity verification platform needs to register blockchain accounts on the two different blockchains separately.
In addition, when the identity verification information is verified, a distributed digital identity corresponding to the signer may be registered in the blockchain, which may uniquely indicate the corresponding signer.
As shown in fig. 1, the electronic signature method may further include:
in step S150, the first client generates a first public key and a first private key associated with the distributed digital identity in a trusted execution environment.
By generating the first public key and the first private key in the trusted execution environment of the first client, the security of the key can be well ensured. It will be appreciated that the first public key and the first private key herein are matched to each other, that is, the first public key may be used to decrypt data encrypted via the first private key. Further, in some embodiments, the first public key and the first private key may be based on an RSA cryptosystem, wherein content encrypted by the first public key may be and can only be decrypted by the first private key, and content signed by the first private key may be and can only be signed by the first public key. In a specific example, the first public key and the first private key may be generated based on an elliptic curve signature algorithm, e.g., using an R1 curve. However, it will be appreciated that other digital signature algorithms may be employed to generate the first public key and the first private key, without limitation.
In some embodiments, to secure the trusted execution environment in the first client, direct information interaction with the trusted execution environment via an authentication tool in the client is typically only allowed based on the trusted authentication service. The identity authentication tool in the scene application program can solve the interaction problem with the trusted execution environment. When the client leaves the factory, the root certificate of the corresponding identity authentication service is stored in the trusted execution environment, so that the TEE can trust the identity authentication service. And when the client leaves the factory, a third private key and a corresponding third public key are also preset in the trusted execution environment, the third public key is sent to the identity authentication service, and in order to ensure the security of the third public key, a transmission channel capable of ensuring the security of the public key is adopted to transmit the public key to the identity authentication service. In one implementation, the third private key may be a trusted root key of the trusted execution environment.
Accordingly, as shown in fig. 2, the first client generating the first public key and the first private key associated with the distributed digital identity in the trusted execution environment may include:
step S151, an identity authentication tool included in a scene application program installed in a first client acquires a distributed digital identity from a blockchain, which is signed and transmitted by an identity authentication service by using a second private key;
Step S153, the identity authentication tool transmits the distributed digital identity signed by the second private key to the trusted execution environment;
step S155, the trusted application in the trusted execution environment performs signature verification on the obtained distributed digital identity by using a second public key matched with a second private key of the identity authentication service; and
in step S157, the trusted application generates a first public key and a first private key associated with the distributed digital identity when the verification passes.
That is, in the first client, reliable information interaction with the trusted execution environment is achieved through an identity authentication tool in the context application. However, it will be appreciated that if reliable communication with the trusted execution environment can be achieved in other ways, the transfer of data to and reading of data from the trusted execution environment may also be achieved without the authentication service and corresponding authentication tool described above, without limitation.
In addition, in the process of transmitting the distributed digital identity, the distributed digital identity can be signed by using the second private key, and the signature verification is performed by using the second public key in a trusted execution environment, so that the obtained distributed digital identity is ensured to be reliable in source and not tampered. Wherein the second public key may be contained in a trusted root certificate of an authentication service pre-configured in a trusted execution environment. Also, the first public key and the first private key of the signer are generated in a trusted execution environment of the first client corresponding to the signer, not in other environments (e.g., a centralized platform) which cannot be controlled by the signer, thereby effectively guaranteeing the security of the keys.
Returning to fig. 1, the electronic signature method may further include:
in step S170, the first client transmits and stores the distributed digital identity and the first public key into the blockchain, and stores the first private key in the trusted execution environment.
Specifically, in the case of directly communicating with the trusted execution environment through an authentication tool in the context application based on the authentication service, as shown in fig. 3, the first client transmitting and storing the distributed digital identity and the first public key into the blockchain may include:
step S171, the trusted application in the trusted execution environment signs the generated first public key by using the third private key and transmits the first public key to an identity authentication tool included in the scene application installed in the first client; and
in step S173, the authentication tool transmits the distributed digital identity and the first public key to the blockchain via the authentication service for the blockchain to store the distributed digital identity and the first public key in association.
The third private key corresponding to the trusted execution environment is used for signing the first public key to be transmitted, so that the security of the transmission process can be ensured. In addition, when the authentication service or the block link receives the signed first public key, the third public key matched with the third private key can be used for checking the signature, so that the obtained first public key is ensured to be reliable in source and not tampered. In some embodiments, the third private key may also be the same as the second public key, and a trusted application in the trusted execution environment may sign encrypt the first public key to be transmitted with the second public key of the authentication service, and accordingly, the third public key may be the same as the second private key, i.e., the authentication service may decrypt the encrypted first public key with its second private key. It will be appreciated that in other embodiments, the distributed digital identity may be signed and checked simultaneously.
Further, it will be appreciated that the transmission of the distributed digital identity and associated first public key may also be accomplished without the authentication service and corresponding authentication tool described above, without limitation, if reliable communication with a trusted execution environment can be accomplished in other ways.
The distributed digital identity and associated first public key may be stored on the blockchain to obtain the first public key from the blockchain if desired.
In addition, the first private key generated in the trusted execution environment of the first client is bound with the corresponding distributed digital identity and stored in the trusted execution environment, so that the first private key associated with the specific distributed digital identity is used for realizing the electronic signature. In general, in any case, the first private key cannot be transmitted outside the trusted execution environment, so as to ensure that the signer controls the first private key thereof, and further ensure the reliability of the electronic signature.
Thus far, the distributed digital identity of the signer and the corresponding first public and first private keys associated with the scenario application have been established, and the distributed digital identity and first public keys may be returned to the distributed digital identity service on the blockchain. It will be appreciated that where there are multiple scenario applications corresponding to different specific application scenarios, a distributed digital identity associated with the same signer and corresponding first public and first private keys may be established for each scenario application. In other words, the same signer may have multiple sets of distributed digital identities and corresponding first public keys and first private keys, which are used for electronic signature in different scenario applications.
The distributed digital identity and the corresponding first public key and first private key form the distributed digital identity of the signer, and the distributed data identity (comprising DID and corresponding public and private key pairs) can be used as a unified distributed digital identity for a plurality of different scene applications. As an implementation manner, if the signer has registered the uniform identity DID, then when registering other scene Applications (APP), the signer may first go to the blockchain to perform a query after face brushing, and if the existing distributed digital identity on the blockchain is queried, the signer may directly use the blockchain or authorize the distributed digital identity to a new scene application for use.
It should be noted that, the distributed digital identity of the present application may be created before registering the scene application program, and at this time, may be initiated by the user (including the signer) at the identity verification platform; the above-mentioned identity may also be initiated by the whole component of the scene application program including the tool module related to the distributed identity creation (such as the identity authentication tool and the user kernel tool in the present application), may be initiated when the scene application program is registered, or may be initiated when a specific node is first performed in the process of the scene application program service, for example, when the signing party signs.
On the premise that the distributed digital identity corresponding to the signing party is established, the electronic signature of the digital file can be realized. As shown in fig. 4, the electronic signature method in one or more embodiments of the present specification may include:
in step S310, the first client obtains data to be signed by the signer.
The data to be signed can be a digitized file of an agreement, a contract, a certificate and the like which exist in the form of an electronic document. In some embodiments, the acquired data to be signed may be transmitted to the trusted execution environment by an authentication tool included by a scenario application installed in the first client. However, it will be appreciated that other means of communicating with the trusted execution environment may be employed to transfer the data to be signed to the trusted execution environment, without limitation.
As shown in fig. 4, the electronic signature method may further include:
in step S330, the first client obtains the signature verification information from the signing party and verifies the signature verification information.
The willingness to sign of the signer may be further determined based on the signature verification information from the signer. If the signature confirmation information is not acquired or the signature confirmation information is not verified, the signature party is not signed willingly or the source of the signature willingness is unreliable, and then the electronic signature is not continued.
In some embodiments, as shown in fig. 5, the first client obtaining the signature verification information from the signer and verifying the signature verification information may include:
step S331, a trusted application in a trusted execution environment sends a signature confirmation request to an identity authentication tool included in a scene application installed in a first client;
step S333, the identity authentication tool acquires signature confirmation information from a signature party and verifies the signature confirmation information; and
in step S335, the authentication tool transmits the verification result of the signature verification information to the trusted application.
The signature verification information may include at least one of biometric information of the signing party, such as fingerprint information, face information, and voice information, and other biometric information that can be used for user identification. When the signer is willing to sign, fingerprint verification, face brushing, voiceprint verification, etc. can be performed, for example. It will be appreciated that other means than an authentication tool may be employed to communicate with the trusted execution environment to effect signature verification. The manner in which the signature information is verified may be confirmed by the trusted application upon verification of the key generated in the trusted execution environment.
In some embodiments of the present invention, during the verification process, the identity authentication tool performs the collected signature verification information in the trusted execution environment with the user biometric information pre-stored in the trusted execution environment of the first client, and outputs a verification result according to the comparison result. The user biometric information pre-stored in the trusted execution environment of the first client may be set by the user when initializing the first client.
Returning to fig. 4, the electronic signature method may further include:
in step S350, when the first client determines that the signature verification information is verified, the signature data is generated according to the data to be signed by using the first private key in the trusted execution environment.
Wherein the signing process takes place in a trusted execution environment of the first client corresponding to the signing party, thus being able to fulfil the requirement of "reliable electronic signature" as described above.
In some embodiments, when a trusted application in the trusted execution environment determines that the signature verification information is verified, the trusted application may calculate a hash value of the data to be signed based on a preset hash algorithm and encrypt the hash value with a first private key to generate the signed data.
In other embodiments, when a trusted application in a trusted execution environment determines that the signature verification information is verified, at least a portion of the data to be signed may also be encrypted with the first private key to produce signed data.
It will be appreciated that the trusted application may also use other means to generate signature data from the data to be signed using the first private key, without limitation.
Further, in the case of directly communicating with the trusted execution environment based on the authentication service, when the first client determines that the signature verification information is verified, generating signature data from the data to be signed using the first private key in the trusted execution environment may further include: the trusted application in the trusted execution environment transmits the generated signature data to an authentication tool included in the scenario application installed in the first client, so that the generated signature data can be read out of the trusted execution environment through the authentication tool for verification and other operations.
As shown in fig. 6, after generating signature data from data to be signed using the first private key in the trusted execution environment, the electronic signature method may further include:
Step S510, signature verification is performed on the signature data.
In particular, the context application on the first client or a second client different from the first client may sign the signature data. Specifically, a first public key associated with the distributed digital identity corresponding to the signer can be searched on the blockchain, the signature data is decrypted by using the searched first public key, and the signature data is checked according to the decryption result. When the content related to the data to be signed obtained after decryption by using the first public key accords with the original data to be signed, the verification signature can be considered to pass; and if the first public key cannot decrypt the signature data or the decrypted data does not accord with the data to be signed, the verification signature is considered to not pass. Signature verification is carried out on the signature data through the scene application program so as to meet the signature verification link in the service and verify the authenticity of the contract signature.
In the electronic signature method of one or more embodiments of the present disclosure, reliable distributed electronic signature is realized based on distributed digital identities on a blockchain and trusted execution environment technology in a client, in the process of generating and transmitting signature data, a third party platform is not involved in signing, and the signing process and data transmission are performed by a signer in person and meet the requirements of encryption and reliable transmission, so that the electronic signature method meets the requirement of "four-property" of "reliable electronic signature" in the electronic signature method, and thus user privacy and security of related data are protected.
One or more embodiments of the present specification also provide an electronic signature device, wherein the distributed digital identity corresponding to the signer and the first public key associated with the distributed digital identity are stored on the blockchain, and the first private key associated with the distributed digital identity and matching the first public key is stored in a trusted execution environment of the electronic signature device corresponding to the signer. As shown in fig. 7, the electronic signature device may include an identity module 710 and a signature module 730. The identity module 710 may be configured to obtain data to be signed by a signer and obtain signature verification information from the signer and verify the signature verification information, among other things. Identity module 710 may include user authentication tool 713 and user authentication tool 711 as described above to obtain relevant information and perform corresponding verification. Further, the signature module 730 disposed in the trusted execution environment may be configured to generate signature data from the data to be signed using the first private key in the trusted execution environment when it is determined that the signature verification information is verified.
Specifically, in some embodiments, the signature module 730 may be configured to calculate a hash value of the data to be signed based on a preset hash algorithm when it is determined that the signature verification information is verified; and encrypting the hash value with the first private key to produce signature data.
In other embodiments, the signature module 730 may be configured to encrypt at least a portion of the data to be signed with the first private key to generate the signed data when it is determined that the signature verification information is verified.
As shown in fig. 7, in one or more embodiments of the present description, the electronic signature device may further include a key module 750 disposed in the trusted execution environment, the key module 750 may be configured to generate a first public key and a first private key associated with the distributed digital identity, and the first public key and the first private key match each other.
In particular, in some embodiments, key module 750 may be configured to obtain a distributed digital identity from a blockchain signed and transmitted by an authentication service with a second private key, to verify the obtained distributed digital identity with a second public key of the authentication service that matches the second private key, and to generate a first public key and a first private key associated with the distributed digital identity when the verification passes.
As shown in fig. 7, in some embodiments, the electronic signature device may further include a signature verification module 770, which signature verification module 770 may be configured to verify signature data.
In particular, the signature verification module 770 may be configured to find a first public key associated with a distributed digital identity corresponding to the signer on the blockchain; and decrypting the signature data by using the searched first public key, and checking the signature data according to the decryption result.
One or more embodiments of the present specification also provide an electronic signature system, as shown in fig. 8, which may include one or more electronic signature devices 700 and blockchain 800 as described above. Blockchain 800 may provide distributed digital identity services to implement distributed electronic signatures.
Furthermore, in some embodiments, the electronic signature system may also include an identity verification platform. The electronic signature device 700 sends the acquired identity verification information corresponding to the signing party to the identity verification platform for verification, and the identity verification platform registers the distributed digital identity for the user with the blockchain 800 after verification is passed. The identity verification platform may include a first functional module for performing identity verification and a second functional module for registering a distributed digital identity for a user with the blockchain, which may be separate two different service platforms and communicatively coupled to each other in some embodiments.
Identity verification can be understood as performing KYC authentication on a user, and the identity verification platform can be completely finished locally or can be in butt joint with a third party with identity verification capability, sends identity verification information acquired from the electronic signature device 700 to the third party with identity verification capability, and receives a verification result returned by the third party. The third party with identity verification capability may be a centralized service or a distributed service.
In some embodiments, the third party with identity verification capability may be a centralized service platform, for example, the third party may be a centralized identity verification platform of a public security authority. In this way, the user verification tool can send the identity verification information to the third party for verification via the identity verification platform, and the identity verification platform performs the next action according to the verification result returned by the third party, for example, when the verification result passes, the distributed digital identity is registered for the user with the blockchain.
In other embodiments, the third party with identity verification capability may be a distributed service platform, such as a distributed service platform implemented based on blockchain. At this time, the third party may be an intelligent contract deployed on the blockchain for performing identity verification based on the identity verification information of the user, so that the user verification tool may send the identity verification information to the third party via the identity verification platform to perform verification, where the identity verification platform initiates an intelligent contract for performing identity verification by using the user to the first blockchain, and obtains a verification result from the first blockchain through the predictor. Similarly, when the verification result passes, the identity verification platform registers the distributed digital identity for the user with the blockchain.
It should be noted that, the blockchain deployed with the intelligent contract for identity verification and the blockchain for registering the distributed digital identity may be the same blockchain or different blockchains. The identity verification platform requires the ability to interface with different blockchains when it is different blockchains, e.g., the identity verification platform needs to register blockchain accounts on the two different blockchains separately.
Further, in some embodiments, the problem of interaction with a trusted execution environment may be solved with an authentication tool in a scenario application of the electronic signature device 700. When the electronic signature device 700 leaves the factory, the root certificate of the corresponding identity authentication service is stored in the trusted execution environment, so that the trust of the TEE on the identity authentication service is realized. And when the electronic signature device 700 leaves the factory, a third private key and a corresponding third public key are preset in the trusted execution environment, the third public key is sent to the identity authentication service, and in order to ensure the security of the third public key, a transmission channel capable of ensuring the security of the public key is adopted to transmit the public key to the identity authentication service. In one implementation, the third private key may be a trusted root key of the trusted execution environment.
In the 90 s of the 20 th century, improvements to one technology could clearly be distinguished as improvements in hardware (e.g., improvements to circuit structures such as diodes, transistors, switches, etc.) or software (improvements to the process flow). However, with the development of technology, many improvements of the current method flows can be regarded as direct improvements of hardware circuit structures. Designers almost always obtain corresponding hardware circuit structures by programming improved method flows into hardware circuits. Therefore, an improvement of a method flow cannot be said to be realized by a hardware entity module. For example, a programmable logic device (Programmable Logic Device, PLD) (e.g., field programmable gate array (Field Programmable Gate Array, FPGA)) is an integrated circuit whose logic function is determined by the user programming the device. A designer programs to "integrate" a digital system onto a PLD without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Moreover, nowadays, instead of manually manufacturing integrated circuit chips, such programming is mostly implemented by using "logic compiler" software, which is similar to the software compiler used in program development and writing, and the original code before the compiling is also written in a specific programming language, which is called hardware description language (Hardware Description Language, HDL), but not just one of the hdds, but a plurality of kinds, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), lava, lola, myHDL, PALASM, RHDL (Ruby Hardware Description Language), etc., VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog are currently most commonly used. It will also be apparent to those skilled in the art that a hardware circuit implementing the logic method flow can be readily obtained by merely slightly programming the method flow into an integrated circuit using several of the hardware description languages described above.
The controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, a microprocessor or processor and a computer readable medium storing computer readable program code (e.g., software or firmware) executable by the (micro) processor, logic gates, switches, application specific integrated circuits (Application Specific Integrated Circuit, ASIC), programmable logic controllers, and embedded microcontrollers, examples of which include, but are not limited to, the following microcontrollers: ARC 625D, atmel AT91SAM, microchip PIC18F26K20, and Silicone Labs C8051F320, the memory controller may also be implemented as part of the control logic of the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller in a pure computer readable program code, it is well possible to implement the same functionality by logically programming the method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers, etc. Such a controller may thus be regarded as a kind of hardware component, and means for performing various functions included therein may also be regarded as structures within the hardware component. Or even means for achieving the various functions may be regarded as either software modules implementing the methods or structures within hardware components.
The system, apparatus, module or unit set forth in the above embodiments may be implemented in particular by a computer chip or entity, or by a product having a certain function. One typical implementation device is a server system. Of course, the application does not exclude that as future computer technology advances, the computer implementing the functions of the above-described embodiments may be, for example, a personal computer, a laptop computer, a car-mounted human-computer interaction device, a cellular telephone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.
Although one or more embodiments of the present description provide method operational steps as described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive means. The order of steps recited in the embodiments is merely one way of performing the order of steps and does not represent a unique order of execution. When implemented in an actual device or end product, the instructions may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even in a distributed data processing environment) as illustrated by the embodiments or by the figures. The terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, it is not excluded that additional identical or equivalent elements may be present in a process, method, article, or apparatus that comprises a described element. For example, if first, second, etc. words are used to indicate a name, but not any particular order.
For convenience of description, the above devices are described as being functionally divided into various modules, respectively. Of course, when one or more of the present description is implemented, the functions of each module may be implemented in the same piece or pieces of software and/or hardware, or a module that implements the same function may be implemented by a plurality of sub-modules or a combination of sub-units, or the like. The above-described apparatus embodiments are merely illustrative, for example, the division of the units is merely a logical function division, and there may be additional divisions when actually implemented, for example, multiple units or 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 forms.
The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
In one typical configuration, a computing device includes 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, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a 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, read only compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage, graphene 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. Computer-readable media, as defined herein, does not include transitory computer-readable media (transmission media), such as modulated data signals and carrier waves.
One skilled in the relevant art will recognize that one or more embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, one or more embodiments of the present description may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Moreover, one or more embodiments of the present description can take the form of a computer program product on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.
One or more embodiments of the present specification may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. One or more embodiments of the present specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
In this specification, each embodiment is described in a progressive manner, and identical and similar parts of each embodiment are all referred to each other, and each embodiment mainly describes differences from other embodiments. In particular, for system embodiments, since they are substantially similar to method embodiments, the description is relatively simple, as relevant to see a section of the description of method embodiments. In the description of the present specification, a description referring to terms "one embodiment," "some embodiments," "examples," "specific examples," or "some examples," etc., means that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the present specification. In this specification, schematic representations of the above terms are not necessarily directed to the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, the different embodiments or examples described in this specification and the features of the different embodiments or examples may be combined and combined by those skilled in the art without contradiction.
The foregoing is merely an example of one or more embodiments of the present specification and is not intended to limit the one or more embodiments of the present specification. Various modifications and alterations to one or more embodiments of this description will be apparent to those skilled in the art. Any modification, equivalent replacement, improvement, or the like, which is within the spirit and principles of the present specification, should be included in the scope of the claims.