Software Technology for “Hardware blockchain acceleration

Blockchain Fintech – John VELISSARIOS, Callum Stuart Hyland, Laurence Richard Freeman, Piergiorgio Rettaroli, Ennio Acernese, Pasquale Di Tucci, Salvatore Gifuni, Accenture Global Solutions Ltd

Abstract for “Hardware blockchain acceleration

Hardware acceleration is a tool that supports complex software processes. A hardware security module, in particular, provides transaction chain encryption support. The security module circuitry offers high-speed security features as well as acceleration of the security features necessary for the processing of blockchain transactions in one implementation.

Background for “Hardware blockchain acceleration

Rapid advances in electronics technology and communication technology, driven by enormous customer demand, have led to new complex network transaction chains. The security, features and speed of implementations will be improved by improvements in hardware and software.

“FIG. “FIG. 100), which allows for secure and efficient execution of complex transactions between entities. There are many possible entities. These could include individuals, hardware systems, software, or software processes. FIG. FIG. 1. The smartphones 102 and104 are shown as examples of hardware platforms that allow entities to conduct transactions with the architecture 100. In this example Entity A is associated to the smartphone 102, and Entity B with the smartphone 1004. FIG. Entity A and Entity B will engage in digital exchange. Digital exchange could be, for example, a transfer value between accounts at different financial institutions. FIG. FIG.

FIG. 1. A smartphone application 106 accepts transaction inputs from Entity A. This transaction input specifies a transaction amount, and a recipient: Entity in this example. Smartphones 102 and104 have an enrollment certificate 110 which the smartphone app 106 passes to an authentication system 112, e.g. in a transaction request 110. One example is that the authentication system 112 can implement a hyperledger client (HFC), 113 in dedicated hardware, or in a virtual container or docker container for virtual machines. An authentication interface (114) includes an exposed authentication programming interface (API), which receives transaction request 110. The authentication system 112 can provide additional layers of security by requiring that the transaction request 110 travel over hypertext protocol secure sockets, (HTTPS), which is protected by transport layer security. FIG. 1.)”

“The enrolment cert verifies authentication by encrypting payloads from smartphones 102 using a public key associated to the enrolment certificates. The HFC certificate authority (CA 116) holds the counterpart private key. The authentication system 112 can verify the request using the private key. FIG. 1.)”

“A membership service that runs at a system Node, e.g. the system node 128, may verify Entity A’s account as specified in the transaction request 110. A transaction CA also generates a unique transaction token. Each transaction is identified uniquely by the transaction token and used to sign it. The certificate allows the request for Entity 132 to be sent to the validating peer node (e.g., an online server that supports operations for Entity 132), and it is then received at security controller circuitry number 134. Security controller circuitry 134 responds to the processing chaincodes. Chaincodes are programmatic logic that is used to support the implementation of the data storage layer. The chaincode is used to update the balances in two accounts within the shared global ledger. To ensure separation of concerns between the systems, these accounts are stored in an encrypted serialized format. This means that all accounts sent to the sender are encrypted using the sender’s peer network (e.g. bank A) keys and can’t be decrypted if the receiver has the same peer network (e.g. bank B) keys and vice versa. The relevant system hardware security module, HSM (e.g. the HSM 128 that supports Entity A 132), is notified to request encryption or decryption. FIG. 1.) Examples of HSMs are the nShield Solo, nShield Edge, and nShieldConnect? Thales e-Security offers a variety of devices.

“In one implementation, the serialized encrypted format is a JavaScript object notation file (JSON), but other representations of the format are also acceptable. This format contains account data (e.g. sender, recipient and quantity as well as other data) and a “cipher?” field. After encryption, account data is encrypted in the peer network HSM. The output is then placed in the?cipher?? field. field. The peer node resets certain fields in the account data. For example, it may set pre-determined sensitive fields to zero. Security controller circuitry 134 can use symmetric cryptography with all keys securely stored in the HSMs. Each account has a URL field which specifies the URL of the security manager it was onboarded. Accordingly, any peer node may view the account and locate the API (via the URL field) to request encryption/decryption of an account.”

“The chaincode sends a network demand 122 to security controller interface 124, which (preferably) has a hardware support connector 126 to HSM 128. Interfaces 124 and126 can have hardwired or wireless connections, over proprietary or nonproprietary bus or communication networks. Network request 122 requests the HSM 128 decrypt an account to allow the chaincode to alter the account balance. To decrypt the account, the authentication system 112 extracts the global state stored in blockchain using two exposed functions: putState ( ) and getState ( ). The peer nodes also have a key/value storage. This key/value stores contains a list of encrypted serialized format account objects linked to their unique identifiers.

“The cryptographic functions can be executed by a high-security hardware device, such as the HSM 128, but they are not limited to software implementation. The HSM 128, which is a data storage layer, allows for the execution of encryption and decryption without the need to be performed directly. FIG. The implementation shown in FIG. The security controller circuitry (134) that controls the HSM 128 in secure environments is housed physically with the HSM 128, such as in an enterprise secure center. FIG. 1.)”

“Once Entity A and Entity B have been decrypted, and after the balance updates in each account, the updated accounts are reencrypted and saved in the serialized encrypted data format (e.g. the JSON file). The chaincode then sends the encryption request 130 to Entity A and Entity B to security manager interface 124. This passes it on to the HSM 128 to enable encryption. The chaincode receives the encryption results and creates a new transaction within the bank’s node. This transaction will be submitted/requested to be included in a new block on the blockchain. FIG. 1.)”

“Note: In this example implementation, both Entity A and Entity B accounts are modified by actions taken in response to the transaction request received by the peer node. Let’s say that Bank A receives an request from Entity A asking to transfer value to Entity B associated to Bank B. The Bank A peer node will then request authentication system 112 in order to update and identify the accounts. The authentication system 112 will then call the security manager API via the URL fields above to request encryption for both accounts. The chaincode modifies both accounts’ balances and uses the exact API previously used to request encryption from the identical HSMs. After encryption and modification, the chaincode asks for submission of updated accounts to the Blockchain. Consensus is then run to ensure that all nodes have the same account status. Final, all nodes are allowed to mirror update accounts.

“Every node in the system must verify that the version of the world state it is using to add the new block to the blockchain contains the updated accounts. This ensures that there are no compromised or missing nodes. Once consensus has been reached (e.g. all nodes have the exact same copy of data structure), the transaction is officially injected into the Blockchain. To increase speed and scalability in reaching consensus in a private permission blockchain system, the authentication system 112 might implement, for example, the Practical Byzantine Fault Tolerance algorithm (PBFT). FIG. 1.)”

After consensus has been reached, the transaction is added to the blockchain. A polling mechanism continuously checks for new blocks. A message is sent to each party informing them about any new transactions that have been added to the ledger. Google Cloud Messaging (GCM), in one implementation, sends notifications to smartphones 102 and104. (Logic Point 7 of FIG. 1.)”

“FIG. 2 shows an expanded view 200 showing the hardware accelerated transactions architecture. FIG. FIG. 2. The security controller circuitry of 134 is included in the Entity A peer network 132. Security controller circuitry (134) defines an HSM interface 250. It includes an API-toAPI mapping 206 and a security manager API. Security manager API 202 exposes a number of security manager functions. For example, security manager function 204 is used to request that peer nodes 132 execute certain security functions (e.g. encrypt and decrypt data). The API-toAPI mapping206 implements an explicit or implicit security manager API to HSM API?toAPI mapping that is tailored to the HSM being used, as further described below.

“FIG. 2. Also, it shows an example architecture 200 that illustrates how the HSM 128 creates a secure execution environment. The dedicated hardware security circuitry (208) performs encryption, decryption and key generation. Key storage, key management, key management, as well as other security functions. HSM 128 defines an HSM API 210 which exposes a number of security functions. HSM security functions run on native HSM hardware and perform the requested security functions (e.g. decrypt data) and return security answers (e.g. decrypted data)

“The API to-API mapping206 converts security requests received at peer node 132 into an HSM-specific function. HSM specific functions are transmitted to the HSM 128 by the security controller circuitry (134) in the form requested security functions (214). The security controller circuitry of 134 also receives security responses 216 from HSM 128 once the HSM 128 has executed the requested security function.

The HSM interface 250 is a flexible and reconfigurable technical solution for connecting a peer node with a variety of HSMs. The peer node 132 can be easily modified to work with many security hardware by reconfiguring the API to-API mapping206 to point at specific functions in an HSM. Multiple instances of HSM interface 250 may be installed in any peer node. Each instance can have different API-toAPI mappings for different HSMs. This allows for multiple HSMs to be supported simultaneously, such as redundant operation or fault tolerance.

“FIG. “FIG. The table below describes the security manager functions. It also indicates where mappings can be provided to specific HSMs and software. The security manager API 302 and the API-toAPI mapping 304 allow for communication between multiple HSMs. The API-to-API map 304 can redirect not only HSM functions but also software implemented security functions. This is especially true in cases where the peer node does not communicate with the HSM.

“TABLE 1\nAPI Security Manager\nFunction Description HSM Connection\nsymmetricEncrypt Encrypt data with a symmetric key Mapping to HSM 1\nMapping to HSM 2\nMapping to Software\nsymmetricDecrypt Decrypt data with a symmetric key Mapping to HSM 1\nMapping to HSM 2\nMapping to Software\napplyDigitalSignature Apply a Digital Signature to a message Mapping to HSM 1\nverifyDigitalSignature Verify the Digital Signature of a Mapping to HSM 1\nmessage\ngenerateECKeyPair Generate a key pair using the Mapping to HSM 1\nElliptic Curve algorithm”

“Tables 2-5 provide a concrete example of the security management function symmetricEncrypt. Tables 6-9 give a specific implementation of the security manger function symmetricDecrypt.

“symmetricEncrypt”

“This function encrypts data using a symmetric key.”

“TABLE 2\nsymmetricEncrypt Input:\nHeader/\nMandatory/ Url/\nParameter Description Optional Body Type\ncallerIdentifier Identifier of the caller O B String\nsystem\nhsmKeyAlias Alias of the key to use O B String\n(if not provided a\ndefault one will be\nused)\ndataToEncrypt Data to encrypt M B String\n(hex encoded)”

“TABLE 3\nsymmetricEncrypt Output:\nMandatory/\nParameter Description Optional Type\nresultCode The Result code of the task M String\nerrorManagement Object identifying the error O* Object\nerrorCode Code that identifies error M String\noccurred\nerrorDescription Error description M String\nencryptedData The encrypted data M String\n*included if resultCode is FAILED”

“TABLE 4\nsymmetricEncrypt Results\nResult Code Result Description\nSUCCESS Service executed successfully\nFAILED Service execution failed”

“TABLE 5\nsymmetricEncrypt Example\nProtocol REST\nPath [IP:PORT]/cxf/securityManager/symmetricEncrypt\nMethod POST\nContent application/json\ntype\nExample JSON request:\n{\n?callerIdentifier? : ?bankA?,\n?hsmKeyAlias?:?aeskey?,\n?dataToEncrypt? : ?33363231?\n}\nExample JSON response:\n{\n?baseResponse? : {\n?result? : ?SUCCESS?\n},\n?encryptedData? :\n?C8BF4E043AFA5595D21F56E16DD15571?\n}”

“symmetricDecrypt”

“This function decrypts data using a symmetric key.”

“TABLE 6\nsymmetricDecrypt Input:\nMandatory/ Header/\nParameter Description Optional Url/Body Type\ncallerIdentifier Identifier of the O B String\ncaller system\nhsmKeyAlias Alias of the O B String\nsymmetric key to\nuse (if not\nprovided a default\none will be used)\ndataToDecrypt Data to decrypt M B String\n(hex encoded)”

“TABLE 7\nsymmetricDecrypt Output:\nMandatory/\nParameter Description Optional Type\nresultCode The Result code of the task M String\nerrorManagement Object identifying the error O* Object\nerrorCode Code that identifies error M String\noccurred\nerrorDescription Error description M String\ndecryptedData The decrypted data M String\n*included if resultCode is FAILED”

“TABLE 8\nsymmetricDecrypt Results\nResult Code Result Description\nSUCCESS Service executed successfully\nFAILED Service execution failed”

“TABLE 9\nsymmetricDecrypt Example\nProtocol REST\nPath [IP:PORT]/cxf/securityManager/symmetricDecrypt\nMethod POST\nContent application/json\ntype\nExample JSON request:\n{\n?callerIdentifier? : ?bankA?,\n?hsmKeyAlias?:?aeskey?,\n?dataToDecrypt? :\n?C8BF4E043AFA5595D21F56E16DD15571?\n}\nExample JSON response:\n{\n?baseResponse? : {\n?result? : ?SUCCESS?\n},\n?decryptedData? : 33363231\n}”

“The function transforms 306 map security manager functions and corresponding objects back to HSM specific requested safety functions 308 that are defined in the HSM configured or chosen to perform the security manger function in question.”

“FIG. “FIG. HSM interface 402 also includes API-to-API mapping 413. In this particular example, the API-to-API mapping 406 has implemented the symmetricDecrypt function transformation 408, the symmetricEncrypt function transformation 410, the applyDigitalSignature function transformation 412, the generateECKeyPair function transformation 414, and the verifyDigitalSignature function transformation 416. Function transformations 408-416 map each function available from security circuitry API 404, the symmetricEncrypt function transformation 410, the applyDigitalSignature function transformation 412 and the generateECKeyPair function transform 414 to the HSM specific functions 418 that are relevant for the HSM being used in this example. The API for HSM 420 implements functions called ‘aesEncryption’. (used for both encryption and decryption), ?applyDigitalSignature?, ?verifyDigitalSignature?, and ?generateEllipitcCurveKeyPair?. An API call to the HSM API function symmetricDecrypt maps to one example: The mapping of the security circuitry API 404 and the HSM 420 is shown in Table 10.

“TABLE 10\nMapping for HSM 420\nsymmetricEncrypt\nHSM Package: com.comp.cpaas.dcpp.hsm.integration.nshield\nspecific Object: NShieldInterface\nfunction Method: aesEncryption\nsymmetricDecrypt\nHSM Package: com. comp.cpaas.dcpp.hsm.integration.nshield\nspecific Object: NShieldInterface\nfunction Method: aesEncryption\napplyDigitalSignature\nHSM Package: com. comp.cpaas.dcpp.hsm.integration.nshield\nspecific Object: NShieldInterface\nfunction Method: applyDigitalSignature\nverifyDigitalSignature\nHSM Package: com. comp.cpaas.dcpp.hsm.integration.nshield\nspecific Object: NShieldInterface\nfunction Method: verifyDigitalSignature\ngenerateECKeyPair\nHSM Package: com. comp.cpaas.dcpp.hsm.integration.nshield\nspecific Object: NShieldInterface\nfunction Method: generateEllipticCurveKeyPair”

“FIG. “FIG. API-to-API mapping 506 is included in the HSM interface 502. The API-to-API map 506 implemented the symmetricDecrypt transformation 508 as well as the symmetricDecrypt transformation 510 in this example. Note that the API-to-API mapping 506 need not provide a mapping for every function, and in this case no mapping is defined for the applyDigitialSignature function, the generateECKeyPair function, or the verifyDigitalSignature function. These functions can be called unsupported and may return an error code. They may also be passed on to other systems or handled in another way.

“The function transformations 508 & 510 map two functions from security circuitry API 504. to HSM specific functions 518, as defined in the HSM in use. In this case, it is the HSM 520. The API for HSM 520 implements functions known as?encrypt? For symmetric encryption and decryption For symmetric encryption. An API call to the function symmetricEncrypt maps to the?encrypt function. HSM API function. The mapping of the security circuitry API 504 and the HSM 520 is shown in Table 11.

“TABLE 11\nMapping for HSM 520\nsymmetricEncrypt\nHSM Package:\nspecific com.comp.cpaas.dcpp.enabler.securitymanager.manager.util\nfunction Object: KeyManager\nMethod: encrypt\nsymmetricDecrypt\nHSM Package:\nspecific com.comp.cpaas.dcpp.enabler.securitymanager.manager.util\nfunction Object: KeyManager\nMethod: decrypt\napplyDigitalSignature\nHSM None\nspecific\nfunction\nverifyDigitalSignature\nHSM None\nspecific\nfunction\ngenerateECKeyPair\nHSM None\nspecific\nfunction”

“FIG. “FIG.6 shows a third example 600, in which HSM interface 602 defines security circuitry API 604. The security circuitry API 604 also includes the five functions mentioned above. HSM interface 602 also includes API-to-API mapping 606. The API-toAPI mapping 606 implemented the symmetricDecrypt transformation 608 as well as the symmetricDecrypt transformation 610 in this example.

“The function transformations 608 & 610 map two functions from security circuitry API 604 into software. In this case, the peer node will only rely on software-implemented security functions. An HSM is not required to execute the security functions. Function transformations 608 & 610 define a software function that will execute in response API calls to symmetricDecrypt function. This is the?decryptSw function. Function transformations 608 and 610 specify a software function that will execute in response API calls to thesymmetricDecrypt function: The?decryptSw? function. function.”

“Table 12 summarizes this example’s mapping from security circuitry API 604 through the HSM 620.”

“TABLE 12\nMapping for HSM 620\nsymmetricEncrypt\nHSM Package:\nspecific com.accenture.cpaas.dcpp.enabler.securitymanager.manager.util\nfunction Object: SecurityManager\nMethod: encryptSw\nsymmetricDecrypt\nHSM Package:\nspecific com.accenture.cpaas.dcpp.enabler.securitymanager.manager.util\nfunction Object: SecurityManager\nMethod: decryptSw\napplyDigitalSignature\nHSM None\nspecific\nfunction\nverifyDigitalSignature\nHSM None\nspecific\nfunction\ngenerateECKeyPair\nHSM None\nspecific\nfunction”

“FIG. “FIG.7 shows a hybrid implementation 700 of the HSM interface 702 that implements a security circuitry API 704. In this particular example, the API-to-API mapping 706 has implemented the symmetricDecrypt function transformation 708, the symmetricDecrypt function transformation 710, the applyDigitialSignature function transformation 712, the generateECKeyPair function transformation 714, and the verifyDigitalSignature function transformation 716. The API-to-API map 706 in this example uses a mixture of HSM functions and software functions to make the calls to security circuitry API 704.

“The function transformations 708, 710 and 714 map three functions from security circuitry API 704 into HSM specific functions 718 on the HSM 720. The HSM 720 maps the functions symmetricDecrypt and symmetricEncrypt to the calls to generateECKeyPair, symmetricDecrypt, and symmetricEncrypt. On the other hand, the function transformations 712 and 716 handle calls to apply or verify a digital signature by mapping the calls to software functions: sWapplyDigitalSignature and sWverifyDigitalSignature, respectively. The mapping of the security circuitry API 704 and the HSM 720 is shown in Table 13.

“TABLE 13\nMapping for HSM 720\nsymmetricEncrypt\nHSM Package: com.comp.cpaas.dcpp.hsm.integration.nshield\nspecific Object: NShieldInterface\nfunction Method: aesEncryption\nsymmetricDecrypt\nHSM Package: com. comp.cpaas.dcpp.hsm.integration.nshield\nspecific Object: NShieldInterface\nfunction Method: aesEncryption\napplyDigitalSignature\nHSM Package:\nspecific com.accenture.cpaas.dcpp.enabler.securitymanager.manager.util\nfunction Object: SecurityManager\nMethod: sWapplyDigitalSignature\nverifyDigitalSignature\nHSM Package:\nspecific com.accenture.cpaas.dcpp.enabler.securitymanager.manager.util\nfunction Object: SecurityManager\nMethod: sWverifyDigitalSignature\ngenerateECKeyPair\nHSM Package: com. comp.cpaas.dcpp.hsm.integration.nshield\nspecific Object: NShieldInterface\nfunction Method: generateEllipticCurveKeyPair”

“FIG. 8 shows an alternative implementation example 800 for the HSM interface 802 with the security circuitry API 804. This example shows that the HSM interface 802 supports multiple HSMs 802 for a single peer, e.g. the HSMs 1 through HSM?n?. HSMs can be different HSMs and provided for redundancy or load balancing, fault tolerance or other reasons. The HSM interface 802 provides support for multiple HSMs 820 by defining multiple API-toAPI mappings 806, one per unique HSM. HSM interface 802 then switches between HSMs. The HSM interface 802 performs mappings based on the HSM currently in use. Configuration files 850 may be used to specify API-to-API mappings of pre-determined HSMs in some implementations. To quickly and efficiently establish mappings to HSMs, the security controller circuitry can load one or more configuration files.

“FIG. “FIG. 9 illustrates logic 900 that may be implemented by a hardware-accelerated transaction processing system. An authentication interface is used to receive a transaction request (902) and an enrollment certificate (902. The system may verify the sender account associated with the transaction request (904) or return a verification error message (906).

“The system sends a decryption request for the hardware security module to decrypt the sender account (908). Security manager circuitry might receive a function call for decryption (910) and map it to the HSM API (912). Then, transmit the HSM-specific function call to HSM (914). Security manager circuitry may receive decrypted data from the hardware security module (916), e.g. as a return value of the HSM specific function call.

“The security manager circuitry might then perform a data upgrade on the decrypted information. The security manager circuitry might generate updated account data in response to a transaction request (918). The system sends an encryption request to the hardware security unit for hardware encryption of the new sender account data after it has been updated (920). For example, the encryption request can be sent to HSM via an API function call. The API may, as with encryption, implement a predetermined mapping to an algorithm used by one or more HSMs to decrypt. This means that the security manager circuitry receives an encrypted request function call (922), interprets it to the HSM API (924) and then transmits the HSM-specific function call to HSM (926).

“The system adds the updated account information to a serialized encrypted transactions chain data structure. The system might request the inclusion of encrypted updated account data (928) that reflects the transaction request within a block in the serialized encryption transaction chain data structure. After consensus has been reached (e.g. all nodes have the exact same copy of data structure), the new transaction can be handed to all bank nodes and officially injected into the Blockchain. To increase speed and scalability in a private permission blockchain system, the system might use, for example, the Practical Byzantine Fault Tolerance algorithm. Once consensus has been reached, the transaction is added to the blockchain. A polling mechanism in the system and similar systems continuously checks for new blocks (930).

The methods, devices and architectures described above can be implemented in many ways using a variety of hardware and software. Circuitry may include an instruction processor such as a Central Processing Unit, microcontroller or microprocessor. It can also be implemented as an Application Specific Integrated Circuit, Programmable Logic Device, Field Programmable Gate Array, or an Application Specific Integrated Circuit. Or as circuitry that contains discrete logic, other circuit components, analog circuit components or both. Circuitry can include discrete interconnected hardware parts or be combined on one integrated circuit device, distributed among multiple integrated system dies or implemented in an Multiple Chip Module (MCM), which consists of multiple integrated circuit devices in a common package.

Circuitry can store instructions or access them for execution or implement their functionality in hardware. Instructions may be stored on tangible storage media other than a transitory signals, such as flash memory, Random Access Memory, RAM, a Read Only Memory, ROM, or an Erasable Programmable Read Only Memory, EPROM; or on magnetic or optical discs, such as a Compact Disk Read Only Memory, Hard Disk Drive, HDD, or any other magnetic or optical disk; and/or on another machine-readable medium. A product such as a computer program product may contain a storage medium and instructions. The instructions, when executed by circuitry in the device, can cause it to implement any of these processing procedures described above.

“The implementations can be distributed. Circuitry can include many distinct components such as processors and memory, and may be distributed across multiple processing systems. Although parameters, databases and other data structures can be stored and managed separately, they may all be combined into one memory or database. They may also be logically and physically organized differently and implemented in many ways. Examples of implementations include program variables, hash table, program variables and arrays. Instructions can be broken down into parts (e.g. subroutines and other code sections) or may be part of multiple programs. They may also be distributed across multiple processors and memories, and can be implemented in many ways. Examples of implementations include standalone programs and as part a library such as a Dynamic Link library (DLL). A library may include shared data, one or more shared programs, and instructions that execute any of the processing shown in the drawings. [52] There are many implementations that have been described. There are many other possible implementations. Virtual machines managed by cloud service providers may host any component or functionality of the architecture. This means that while some implementations can be fully localized within an enterprise, others may be fully migrated to the cloud or hybrid implementations with both local and cloud implementations. Concerning querying devices: The smartphones applications and desktop computer mentioned above are only a few examples. Other querying devices can be used as well, such as hands-free systems inside vehicles, digital personal assistants on smartphones or desktop computers, hands-free control systems at home and many other types.

Summary for “Hardware blockchain acceleration

Rapid advances in electronics technology and communication technology, driven by enormous customer demand, have led to new complex network transaction chains. The security, features and speed of implementations will be improved by improvements in hardware and software.

“FIG. “FIG. 100), which allows for secure and efficient execution of complex transactions between entities. There are many possible entities. These could include individuals, hardware systems, software, or software processes. FIG. FIG. 1. The smartphones 102 and104 are shown as examples of hardware platforms that allow entities to conduct transactions with the architecture 100. In this example Entity A is associated to the smartphone 102, and Entity B with the smartphone 1004. FIG. Entity A and Entity B will engage in digital exchange. Digital exchange could be, for example, a transfer value between accounts at different financial institutions. FIG. FIG.

FIG. 1. A smartphone application 106 accepts transaction inputs from Entity A. This transaction input specifies a transaction amount, and a recipient: Entity in this example. Smartphones 102 and104 have an enrollment certificate 110 which the smartphone app 106 passes to an authentication system 112, e.g. in a transaction request 110. One example is that the authentication system 112 can implement a hyperledger client (HFC), 113 in dedicated hardware, or in a virtual container or docker container for virtual machines. An authentication interface (114) includes an exposed authentication programming interface (API), which receives transaction request 110. The authentication system 112 can provide additional layers of security by requiring that the transaction request 110 travel over hypertext protocol secure sockets, (HTTPS), which is protected by transport layer security. FIG. 1.)”

“The enrolment cert verifies authentication by encrypting payloads from smartphones 102 using a public key associated to the enrolment certificates. The HFC certificate authority (CA 116) holds the counterpart private key. The authentication system 112 can verify the request using the private key. FIG. 1.)”

“A membership service that runs at a system Node, e.g. the system node 128, may verify Entity A’s account as specified in the transaction request 110. A transaction CA also generates a unique transaction token. Each transaction is identified uniquely by the transaction token and used to sign it. The certificate allows the request for Entity 132 to be sent to the validating peer node (e.g., an online server that supports operations for Entity 132), and it is then received at security controller circuitry number 134. Security controller circuitry 134 responds to the processing chaincodes. Chaincodes are programmatic logic that is used to support the implementation of the data storage layer. The chaincode is used to update the balances in two accounts within the shared global ledger. To ensure separation of concerns between the systems, these accounts are stored in an encrypted serialized format. This means that all accounts sent to the sender are encrypted using the sender’s peer network (e.g. bank A) keys and can’t be decrypted if the receiver has the same peer network (e.g. bank B) keys and vice versa. The relevant system hardware security module, HSM (e.g. the HSM 128 that supports Entity A 132), is notified to request encryption or decryption. FIG. 1.) Examples of HSMs are the nShield Solo, nShield Edge, and nShieldConnect? Thales e-Security offers a variety of devices.

“In one implementation, the serialized encrypted format is a JavaScript object notation file (JSON), but other representations of the format are also acceptable. This format contains account data (e.g. sender, recipient and quantity as well as other data) and a “cipher?” field. After encryption, account data is encrypted in the peer network HSM. The output is then placed in the?cipher?? field. field. The peer node resets certain fields in the account data. For example, it may set pre-determined sensitive fields to zero. Security controller circuitry 134 can use symmetric cryptography with all keys securely stored in the HSMs. Each account has a URL field which specifies the URL of the security manager it was onboarded. Accordingly, any peer node may view the account and locate the API (via the URL field) to request encryption/decryption of an account.”

“The chaincode sends a network demand 122 to security controller interface 124, which (preferably) has a hardware support connector 126 to HSM 128. Interfaces 124 and126 can have hardwired or wireless connections, over proprietary or nonproprietary bus or communication networks. Network request 122 requests the HSM 128 decrypt an account to allow the chaincode to alter the account balance. To decrypt the account, the authentication system 112 extracts the global state stored in blockchain using two exposed functions: putState ( ) and getState ( ). The peer nodes also have a key/value storage. This key/value stores contains a list of encrypted serialized format account objects linked to their unique identifiers.

“The cryptographic functions can be executed by a high-security hardware device, such as the HSM 128, but they are not limited to software implementation. The HSM 128, which is a data storage layer, allows for the execution of encryption and decryption without the need to be performed directly. FIG. The implementation shown in FIG. The security controller circuitry (134) that controls the HSM 128 in secure environments is housed physically with the HSM 128, such as in an enterprise secure center. FIG. 1.)”

“Once Entity A and Entity B have been decrypted, and after the balance updates in each account, the updated accounts are reencrypted and saved in the serialized encrypted data format (e.g. the JSON file). The chaincode then sends the encryption request 130 to Entity A and Entity B to security manager interface 124. This passes it on to the HSM 128 to enable encryption. The chaincode receives the encryption results and creates a new transaction within the bank’s node. This transaction will be submitted/requested to be included in a new block on the blockchain. FIG. 1.)”

“Note: In this example implementation, both Entity A and Entity B accounts are modified by actions taken in response to the transaction request received by the peer node. Let’s say that Bank A receives an request from Entity A asking to transfer value to Entity B associated to Bank B. The Bank A peer node will then request authentication system 112 in order to update and identify the accounts. The authentication system 112 will then call the security manager API via the URL fields above to request encryption for both accounts. The chaincode modifies both accounts’ balances and uses the exact API previously used to request encryption from the identical HSMs. After encryption and modification, the chaincode asks for submission of updated accounts to the Blockchain. Consensus is then run to ensure that all nodes have the same account status. Final, all nodes are allowed to mirror update accounts.

“Every node in the system must verify that the version of the world state it is using to add the new block to the blockchain contains the updated accounts. This ensures that there are no compromised or missing nodes. Once consensus has been reached (e.g. all nodes have the exact same copy of data structure), the transaction is officially injected into the Blockchain. To increase speed and scalability in reaching consensus in a private permission blockchain system, the authentication system 112 might implement, for example, the Practical Byzantine Fault Tolerance algorithm (PBFT). FIG. 1.)”

After consensus has been reached, the transaction is added to the blockchain. A polling mechanism continuously checks for new blocks. A message is sent to each party informing them about any new transactions that have been added to the ledger. Google Cloud Messaging (GCM), in one implementation, sends notifications to smartphones 102 and104. (Logic Point 7 of FIG. 1.)”

“FIG. 2 shows an expanded view 200 showing the hardware accelerated transactions architecture. FIG. FIG. 2. The security controller circuitry of 134 is included in the Entity A peer network 132. Security controller circuitry (134) defines an HSM interface 250. It includes an API-toAPI mapping 206 and a security manager API. Security manager API 202 exposes a number of security manager functions. For example, security manager function 204 is used to request that peer nodes 132 execute certain security functions (e.g. encrypt and decrypt data). The API-toAPI mapping206 implements an explicit or implicit security manager API to HSM API?toAPI mapping that is tailored to the HSM being used, as further described below.

“FIG. 2. Also, it shows an example architecture 200 that illustrates how the HSM 128 creates a secure execution environment. The dedicated hardware security circuitry (208) performs encryption, decryption and key generation. Key storage, key management, key management, as well as other security functions. HSM 128 defines an HSM API 210 which exposes a number of security functions. HSM security functions run on native HSM hardware and perform the requested security functions (e.g. decrypt data) and return security answers (e.g. decrypted data)

“The API to-API mapping206 converts security requests received at peer node 132 into an HSM-specific function. HSM specific functions are transmitted to the HSM 128 by the security controller circuitry (134) in the form requested security functions (214). The security controller circuitry of 134 also receives security responses 216 from HSM 128 once the HSM 128 has executed the requested security function.

The HSM interface 250 is a flexible and reconfigurable technical solution for connecting a peer node with a variety of HSMs. The peer node 132 can be easily modified to work with many security hardware by reconfiguring the API to-API mapping206 to point at specific functions in an HSM. Multiple instances of HSM interface 250 may be installed in any peer node. Each instance can have different API-toAPI mappings for different HSMs. This allows for multiple HSMs to be supported simultaneously, such as redundant operation or fault tolerance.

“FIG. “FIG. The table below describes the security manager functions. It also indicates where mappings can be provided to specific HSMs and software. The security manager API 302 and the API-toAPI mapping 304 allow for communication between multiple HSMs. The API-to-API map 304 can redirect not only HSM functions but also software implemented security functions. This is especially true in cases where the peer node does not communicate with the HSM.

“TABLE 1\nAPI Security Manager\nFunction Description HSM Connection\nsymmetricEncrypt Encrypt data with a symmetric key Mapping to HSM 1\nMapping to HSM 2\nMapping to Software\nsymmetricDecrypt Decrypt data with a symmetric key Mapping to HSM 1\nMapping to HSM 2\nMapping to Software\napplyDigitalSignature Apply a Digital Signature to a message Mapping to HSM 1\nverifyDigitalSignature Verify the Digital Signature of a Mapping to HSM 1\nmessage\ngenerateECKeyPair Generate a key pair using the Mapping to HSM 1\nElliptic Curve algorithm”

“Tables 2-5 provide a concrete example of the security management function symmetricEncrypt. Tables 6-9 give a specific implementation of the security manger function symmetricDecrypt.

“symmetricEncrypt”

“This function encrypts data using a symmetric key.”

“TABLE 2\nsymmetricEncrypt Input:\nHeader/\nMandatory/ Url/\nParameter Description Optional Body Type\ncallerIdentifier Identifier of the caller O B String\nsystem\nhsmKeyAlias Alias of the key to use O B String\n(if not provided a\ndefault one will be\nused)\ndataToEncrypt Data to encrypt M B String\n(hex encoded)”

“TABLE 3\nsymmetricEncrypt Output:\nMandatory/\nParameter Description Optional Type\nresultCode The Result code of the task M String\nerrorManagement Object identifying the error O* Object\nerrorCode Code that identifies error M String\noccurred\nerrorDescription Error description M String\nencryptedData The encrypted data M String\n*included if resultCode is FAILED”

“TABLE 4\nsymmetricEncrypt Results\nResult Code Result Description\nSUCCESS Service executed successfully\nFAILED Service execution failed”

“TABLE 5\nsymmetricEncrypt Example\nProtocol REST\nPath [IP:PORT]/cxf/securityManager/symmetricEncrypt\nMethod POST\nContent application/json\ntype\nExample JSON request:\n{\n?callerIdentifier? : ?bankA?,\n?hsmKeyAlias?:?aeskey?,\n?dataToEncrypt? : ?33363231?\n}\nExample JSON response:\n{\n?baseResponse? : {\n?result? : ?SUCCESS?\n},\n?encryptedData? :\n?C8BF4E043AFA5595D21F56E16DD15571?\n}”

“symmetricDecrypt”

“This function decrypts data using a symmetric key.”

“TABLE 6\nsymmetricDecrypt Input:\nMandatory/ Header/\nParameter Description Optional Url/Body Type\ncallerIdentifier Identifier of the O B String\ncaller system\nhsmKeyAlias Alias of the O B String\nsymmetric key to\nuse (if not\nprovided a default\none will be used)\ndataToDecrypt Data to decrypt M B String\n(hex encoded)”

“TABLE 7\nsymmetricDecrypt Output:\nMandatory/\nParameter Description Optional Type\nresultCode The Result code of the task M String\nerrorManagement Object identifying the error O* Object\nerrorCode Code that identifies error M String\noccurred\nerrorDescription Error description M String\ndecryptedData The decrypted data M String\n*included if resultCode is FAILED”

“TABLE 8\nsymmetricDecrypt Results\nResult Code Result Description\nSUCCESS Service executed successfully\nFAILED Service execution failed”

“TABLE 9\nsymmetricDecrypt Example\nProtocol REST\nPath [IP:PORT]/cxf/securityManager/symmetricDecrypt\nMethod POST\nContent application/json\ntype\nExample JSON request:\n{\n?callerIdentifier? : ?bankA?,\n?hsmKeyAlias?:?aeskey?,\n?dataToDecrypt? :\n?C8BF4E043AFA5595D21F56E16DD15571?\n}\nExample JSON response:\n{\n?baseResponse? : {\n?result? : ?SUCCESS?\n},\n?decryptedData? : 33363231\n}”

“The function transforms 306 map security manager functions and corresponding objects back to HSM specific requested safety functions 308 that are defined in the HSM configured or chosen to perform the security manger function in question.”

“FIG. “FIG. HSM interface 402 also includes API-to-API mapping 413. In this particular example, the API-to-API mapping 406 has implemented the symmetricDecrypt function transformation 408, the symmetricEncrypt function transformation 410, the applyDigitalSignature function transformation 412, the generateECKeyPair function transformation 414, and the verifyDigitalSignature function transformation 416. Function transformations 408-416 map each function available from security circuitry API 404, the symmetricEncrypt function transformation 410, the applyDigitalSignature function transformation 412 and the generateECKeyPair function transform 414 to the HSM specific functions 418 that are relevant for the HSM being used in this example. The API for HSM 420 implements functions called ‘aesEncryption’. (used for both encryption and decryption), ?applyDigitalSignature?, ?verifyDigitalSignature?, and ?generateEllipitcCurveKeyPair?. An API call to the HSM API function symmetricDecrypt maps to one example: The mapping of the security circuitry API 404 and the HSM 420 is shown in Table 10.

“TABLE 10\nMapping for HSM 420\nsymmetricEncrypt\nHSM Package: com.comp.cpaas.dcpp.hsm.integration.nshield\nspecific Object: NShieldInterface\nfunction Method: aesEncryption\nsymmetricDecrypt\nHSM Package: com. comp.cpaas.dcpp.hsm.integration.nshield\nspecific Object: NShieldInterface\nfunction Method: aesEncryption\napplyDigitalSignature\nHSM Package: com. comp.cpaas.dcpp.hsm.integration.nshield\nspecific Object: NShieldInterface\nfunction Method: applyDigitalSignature\nverifyDigitalSignature\nHSM Package: com. comp.cpaas.dcpp.hsm.integration.nshield\nspecific Object: NShieldInterface\nfunction Method: verifyDigitalSignature\ngenerateECKeyPair\nHSM Package: com. comp.cpaas.dcpp.hsm.integration.nshield\nspecific Object: NShieldInterface\nfunction Method: generateEllipticCurveKeyPair”

“FIG. “FIG. API-to-API mapping 506 is included in the HSM interface 502. The API-to-API map 506 implemented the symmetricDecrypt transformation 508 as well as the symmetricDecrypt transformation 510 in this example. Note that the API-to-API mapping 506 need not provide a mapping for every function, and in this case no mapping is defined for the applyDigitialSignature function, the generateECKeyPair function, or the verifyDigitalSignature function. These functions can be called unsupported and may return an error code. They may also be passed on to other systems or handled in another way.

“The function transformations 508 & 510 map two functions from security circuitry API 504. to HSM specific functions 518, as defined in the HSM in use. In this case, it is the HSM 520. The API for HSM 520 implements functions known as?encrypt? For symmetric encryption and decryption For symmetric encryption. An API call to the function symmetricEncrypt maps to the?encrypt function. HSM API function. The mapping of the security circuitry API 504 and the HSM 520 is shown in Table 11.

“TABLE 11\nMapping for HSM 520\nsymmetricEncrypt\nHSM Package:\nspecific com.comp.cpaas.dcpp.enabler.securitymanager.manager.util\nfunction Object: KeyManager\nMethod: encrypt\nsymmetricDecrypt\nHSM Package:\nspecific com.comp.cpaas.dcpp.enabler.securitymanager.manager.util\nfunction Object: KeyManager\nMethod: decrypt\napplyDigitalSignature\nHSM None\nspecific\nfunction\nverifyDigitalSignature\nHSM None\nspecific\nfunction\ngenerateECKeyPair\nHSM None\nspecific\nfunction”

“FIG. “FIG.6 shows a third example 600, in which HSM interface 602 defines security circuitry API 604. The security circuitry API 604 also includes the five functions mentioned above. HSM interface 602 also includes API-to-API mapping 606. The API-toAPI mapping 606 implemented the symmetricDecrypt transformation 608 as well as the symmetricDecrypt transformation 610 in this example.

“The function transformations 608 & 610 map two functions from security circuitry API 604 into software. In this case, the peer node will only rely on software-implemented security functions. An HSM is not required to execute the security functions. Function transformations 608 & 610 define a software function that will execute in response API calls to symmetricDecrypt function. This is the?decryptSw function. Function transformations 608 and 610 specify a software function that will execute in response API calls to thesymmetricDecrypt function: The?decryptSw? function. function.”

“Table 12 summarizes this example’s mapping from security circuitry API 604 through the HSM 620.”

“TABLE 12\nMapping for HSM 620\nsymmetricEncrypt\nHSM Package:\nspecific com.accenture.cpaas.dcpp.enabler.securitymanager.manager.util\nfunction Object: SecurityManager\nMethod: encryptSw\nsymmetricDecrypt\nHSM Package:\nspecific com.accenture.cpaas.dcpp.enabler.securitymanager.manager.util\nfunction Object: SecurityManager\nMethod: decryptSw\napplyDigitalSignature\nHSM None\nspecific\nfunction\nverifyDigitalSignature\nHSM None\nspecific\nfunction\ngenerateECKeyPair\nHSM None\nspecific\nfunction”

“FIG. “FIG.7 shows a hybrid implementation 700 of the HSM interface 702 that implements a security circuitry API 704. In this particular example, the API-to-API mapping 706 has implemented the symmetricDecrypt function transformation 708, the symmetricDecrypt function transformation 710, the applyDigitialSignature function transformation 712, the generateECKeyPair function transformation 714, and the verifyDigitalSignature function transformation 716. The API-to-API map 706 in this example uses a mixture of HSM functions and software functions to make the calls to security circuitry API 704.

“The function transformations 708, 710 and 714 map three functions from security circuitry API 704 into HSM specific functions 718 on the HSM 720. The HSM 720 maps the functions symmetricDecrypt and symmetricEncrypt to the calls to generateECKeyPair, symmetricDecrypt, and symmetricEncrypt. On the other hand, the function transformations 712 and 716 handle calls to apply or verify a digital signature by mapping the calls to software functions: sWapplyDigitalSignature and sWverifyDigitalSignature, respectively. The mapping of the security circuitry API 704 and the HSM 720 is shown in Table 13.

“TABLE 13\nMapping for HSM 720\nsymmetricEncrypt\nHSM Package: com.comp.cpaas.dcpp.hsm.integration.nshield\nspecific Object: NShieldInterface\nfunction Method: aesEncryption\nsymmetricDecrypt\nHSM Package: com. comp.cpaas.dcpp.hsm.integration.nshield\nspecific Object: NShieldInterface\nfunction Method: aesEncryption\napplyDigitalSignature\nHSM Package:\nspecific com.accenture.cpaas.dcpp.enabler.securitymanager.manager.util\nfunction Object: SecurityManager\nMethod: sWapplyDigitalSignature\nverifyDigitalSignature\nHSM Package:\nspecific com.accenture.cpaas.dcpp.enabler.securitymanager.manager.util\nfunction Object: SecurityManager\nMethod: sWverifyDigitalSignature\ngenerateECKeyPair\nHSM Package: com. comp.cpaas.dcpp.hsm.integration.nshield\nspecific Object: NShieldInterface\nfunction Method: generateEllipticCurveKeyPair”

“FIG. 8 shows an alternative implementation example 800 for the HSM interface 802 with the security circuitry API 804. This example shows that the HSM interface 802 supports multiple HSMs 802 for a single peer, e.g. the HSMs 1 through HSM?n?. HSMs can be different HSMs and provided for redundancy or load balancing, fault tolerance or other reasons. The HSM interface 802 provides support for multiple HSMs 820 by defining multiple API-toAPI mappings 806, one per unique HSM. HSM interface 802 then switches between HSMs. The HSM interface 802 performs mappings based on the HSM currently in use. Configuration files 850 may be used to specify API-to-API mappings of pre-determined HSMs in some implementations. To quickly and efficiently establish mappings to HSMs, the security controller circuitry can load one or more configuration files.

“FIG. “FIG. 9 illustrates logic 900 that may be implemented by a hardware-accelerated transaction processing system. An authentication interface is used to receive a transaction request (902) and an enrollment certificate (902. The system may verify the sender account associated with the transaction request (904) or return a verification error message (906).

“The system sends a decryption request for the hardware security module to decrypt the sender account (908). Security manager circuitry might receive a function call for decryption (910) and map it to the HSM API (912). Then, transmit the HSM-specific function call to HSM (914). Security manager circuitry may receive decrypted data from the hardware security module (916), e.g. as a return value of the HSM specific function call.

“The security manager circuitry might then perform a data upgrade on the decrypted information. The security manager circuitry might generate updated account data in response to a transaction request (918). The system sends an encryption request to the hardware security unit for hardware encryption of the new sender account data after it has been updated (920). For example, the encryption request can be sent to HSM via an API function call. The API may, as with encryption, implement a predetermined mapping to an algorithm used by one or more HSMs to decrypt. This means that the security manager circuitry receives an encrypted request function call (922), interprets it to the HSM API (924) and then transmits the HSM-specific function call to HSM (926).

“The system adds the updated account information to a serialized encrypted transactions chain data structure. The system might request the inclusion of encrypted updated account data (928) that reflects the transaction request within a block in the serialized encryption transaction chain data structure. After consensus has been reached (e.g. all nodes have the exact same copy of data structure), the new transaction can be handed to all bank nodes and officially injected into the Blockchain. To increase speed and scalability in a private permission blockchain system, the system might use, for example, the Practical Byzantine Fault Tolerance algorithm. Once consensus has been reached, the transaction is added to the blockchain. A polling mechanism in the system and similar systems continuously checks for new blocks (930).

The methods, devices and architectures described above can be implemented in many ways using a variety of hardware and software. Circuitry may include an instruction processor such as a Central Processing Unit, microcontroller or microprocessor. It can also be implemented as an Application Specific Integrated Circuit, Programmable Logic Device, Field Programmable Gate Array, or an Application Specific Integrated Circuit. Or as circuitry that contains discrete logic, other circuit components, analog circuit components or both. Circuitry can include discrete interconnected hardware parts or be combined on one integrated circuit device, distributed among multiple integrated system dies or implemented in an Multiple Chip Module (MCM), which consists of multiple integrated circuit devices in a common package.

Circuitry can store instructions or access them for execution or implement their functionality in hardware. Instructions may be stored on tangible storage media other than a transitory signals, such as flash memory, Random Access Memory, RAM, a Read Only Memory, ROM, or an Erasable Programmable Read Only Memory, EPROM; or on magnetic or optical discs, such as a Compact Disk Read Only Memory, Hard Disk Drive, HDD, or any other magnetic or optical disk; and/or on another machine-readable medium. A product such as a computer program product may contain a storage medium and instructions. The instructions, when executed by circuitry in the device, can cause it to implement any of these processing procedures described above.

“The implementations can be distributed. Circuitry can include many distinct components such as processors and memory, and may be distributed across multiple processing systems. Although parameters, databases and other data structures can be stored and managed separately, they may all be combined into one memory or database. They may also be logically and physically organized differently and implemented in many ways. Examples of implementations include program variables, hash table, program variables and arrays. Instructions can be broken down into parts (e.g. subroutines and other code sections) or may be part of multiple programs. They may also be distributed across multiple processors and memories, and can be implemented in many ways. Examples of implementations include standalone programs and as part a library such as a Dynamic Link library (DLL). A library may include shared data, one or more shared programs, and instructions that execute any of the processing shown in the drawings. [52] There are many implementations that have been described. There are many other possible implementations. Virtual machines managed by cloud service providers may host any component or functionality of the architecture. This means that while some implementations can be fully localized within an enterprise, others may be fully migrated to the cloud or hybrid implementations with both local and cloud implementations. Concerning querying devices: The smartphones applications and desktop computer mentioned above are only a few examples. Other querying devices can be used as well, such as hands-free systems inside vehicles, digital personal assistants on smartphones or desktop computers, hands-free control systems at home and many other types.

Click here to view the patent on Google Patents.

How to Search for Patents

A patent search is the first step to getting your patent. You can do a google patent search or do a USPTO search. Patent-pending is the term for the product that has been covered by the patent application. You can search the public pair to find the patent application. After the patent office approves your application, you will be able to do a patent number look to locate the patent issued. Your product is now patentable. You can also use the USPTO search engine. See below for details. You can get help from a patent lawyer. Patents in the United States are granted by the US trademark and patent office or the United States Patent and Trademark office. This office also reviews trademark applications.

Are you interested in similar patents? These are the steps to follow:

1. Brainstorm terms to describe your invention, based on its purpose, composition, or use.

Write down a brief, but precise description of the invention. Don’t use generic terms such as “device”, “process,” or “system”. Consider synonyms for the terms you chose initially. Next, take note of important technical terms as well as keywords.

Use the questions below to help you identify keywords or concepts.

• What is the purpose of the invention Is it a utilitarian device or an ornamental design?
• Is invention a way to create something or perform a function? Is it a product?
• What is the composition and function of the invention? What is the physical composition of the invention?
• What’s the purpose of the invention
• What are the technical terms and keywords used to describe an invention’s nature? A technical dictionary can help you locate the right terms.

2. These terms will allow you to search for relevant Cooperative Patent Classifications at Classification Search Tool. If you are unable to find the right classification for your invention, scan through the classification’s class Schemas (class schedules) and try again. If you don’t get any results from the Classification Text Search, you might consider substituting your words to describe your invention with synonyms.

3. Check the CPC Classification Definition for confirmation of the CPC classification you found. If the selected classification title has a blue box with a “D” at its left, the hyperlink will take you to a CPC classification description. CPC classification definitions will help you determine the applicable classification’s scope so that you can choose the most relevant. These definitions may also include search tips or other suggestions that could be helpful for further research.

4. The Patents Full-Text Database and the Image Database allow you to retrieve patent documents that include the CPC classification. By focusing on the abstracts and representative drawings, you can narrow down your search for the most relevant patent publications.

5. This selection of patent publications is the best to look at for any similarities to your invention. Pay attention to the claims and specification. Refer to the applicant and patent examiner for additional patents.

6. You can retrieve published patent applications that match the CPC classification you chose in Step 3. You can also use the same search strategy that you used in Step 4 to narrow your search results to only the most relevant patent applications by reviewing the abstracts and representative drawings for each page. Next, examine all published patent applications carefully, paying special attention to the claims, and other drawings.

7. You can search for additional US patent publications by keyword searching in AppFT or PatFT databases, as well as classification searching of patents not from the United States per below. Also, you can use web search engines to search non-patent literature disclosures about inventions. Here are some examples:

• Add keywords to your search. Keyword searches may turn up documents that are not well-categorized or have missed classifications during Step 2. For example, US patent examiners often supplement their classification searches with keyword searches. Think about the use of technical engineering terminology rather than everyday words.
• Search for foreign patents using the CPC classification. Then, re-run the search using international patent office search engines such as Espacenet, the European Patent Office’s worldwide patent publication database of over 130 million patent publications. Other national databases include:
• European Patent Office (EPO) provides esp@cenet to access a network of Europe’s patent databases with access to machine translation of European patents. 
• Japan Patent Office (JPO) – with access to machine translations of Japanese patents.
• World Intellectual Property Organization (WIPO) offers PATENTSCOPE with a full-text search of published international patent applications and machine translations for some documents, as well as a list of international patent databases.
• Korean Intellectual Property Rights Information Service (KIPRIS)
• State Intellectual Property Office (SIPO) with machine translation of Chinese patents.
• Other International Intellectual Property Offices with online patent databases include Australia, Canada, Denmark, Finland, France, Germany, Great Britain, India, Israel, Netherlands, Norway, Sweden, Switzerland, and Taiwan.
• Search non-patent literature. Inventions can be made public in many non-patent publications. It is recommended that you search journals, books, websites, technical catalogs, conference proceedings, and other print and electronic publications.

To review your search, you can hire a registered patent attorney to assist. A preliminary search will help one better prepare to talk about their invention and other related inventions with a professional patent attorney. In addition, the attorney will not spend too much time or money on patenting basics.

Download patent guide file – Click here