Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Claims 1 – 2, 4, 11, 12, 14 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Smirnov (US Pub. No. 2021/0383363 A1) in view of Gnosis (Gnosis Safe Contracts, 2017).
Per claim 1, Smirnov (US Pub. No. 2021/0383363 A1) is relied upon to teach a computer-implemented system (reads on a hardware and software complex that ensures secure storage of digital currencies/cryptocurrencies and control the entire lifecycle of multiple wallets simultaneously to make transactions in the blockchain network, see Smirnov para 0001 and 0070 – 0072) configured interoperability between (reads on the server receives requests, HSM signs, and results transmit to blockchain – which is interoperability, see Smirnov para 0066 and 0072) a centralized computing system (reads on a centralized control server that processes all incoming requests, see Smirnov para 0003 and 0054) for joint custodial (reads on managing wallets for multiple users/organizations providing custody services, see Smirnov para 0003) secure storage of (reads on HSM providing isolated secure environment, see Smirnov para 0014 and 0069) digital assets (reads on the control server, hardware security module and secure storage of digital currencies centralized and secure lifecycle management of cryptographic keys, see Smirnov para 0001, 0008, 0071 – 0072 and 0089): a computer processor coupled to non-transitory computer memory, the computer processor configured to (see Smirnov para 0104 – 0106): receive a user’s request (reads on a request is received from the user to create a digital wallet, see Smirnov para 0027 and 0082) to create a safe data object (reads on a digital wallet with multisignature security rules, see Smirnov para 0027 and 0082) on the distributed ledger of the decentralized computing system (reads on the blockchain network, see Smirnov para 0066) for storage of (reads on the balances credited to user accounts stored in wallets, see Smirnov para 0059 – 0060) the user’s assets (reads on digital currencies/cryptocurrency balances, see Smirnov para 0008, 0059 – 0060 and 0089); and generate a private key for each owner (reads on a public/private key pair is generated for the new digital wallet belonging to a user, see Smirnov para 0026 – 0029, 0058 and 0086). The prior art of record is silent on explicitly stating an automated smart contract data structure deployed and persisted on a distributed ledger of a decentralized computing system; instantiate the automated smart contract data structure deployed on the distributed ledger for managing digital assets, the automated smart contract data structure comprising a list of pointers referencing a plurality of addresses, a mapping of transactions, a mapping of confirmations, and a user-configured number of required owner signatures for the transactions, wherein each of the addresses corresponds to an owner of a plurality of owners, wherein each of the required owner signatures comprises a digital signature created by the private key corresponding to each of the required owners; store the private key of each owner in a digital asset wallet associated with the owner; configure risk controls in the automated smart contract data structure for the transactions; provide an address of the safe data object to the user for receiving deposits; receive a transfer of a digital asset by the user addressed to the address of the safe data object; receive a request from the user to initiate a transaction of a digital asset from the safe data object to a target recipient at a target address, the transaction being added to the mapping of transactions; prompt each of the required owners to apply a digital signature to the transaction using the private key corresponding to each of the required owners; store a signature collected from each of the required owners in the mapping of confirmations; confirm the mapping of confirmations contains all of the required owner signatures; and upon confirmation of the required owner signatures, transfer the digital asset to the target address.
[0001] The claimed solution relates to a method of making transactions in the blockchain framework using a protected hardware and software complex to ensure secure storage of digital currencies (cryptocurrencies) and control the entire lifecycle of multiple wallets simultaneously to make transactions in the blockchain network.
[0003] An alternative to software wallets are hardware wallets that maintain security of private keys and provide the offline signing of blockchain transactions. However, large investors and organizations providing custody services (banks, funds, etc.), require a brand new approach to storing digital assets, which maintains high security requirements for thousands of blockchain wallets simultaneously. At that, there is a need for centralized and secure lifecycle management of cryptographic keys—their generation, distribution, cold storage and backup. All of these functions must be performed in an isolated environment, protected from any external actions.
[0008] In the preferred embodiment of the invention, a system is proposed for secure storage of digital currencies, as well as for processing and making transactions in at least one blockchain network, that contains at least a control server connected to at least one blockchain network and providing lifecycle management of users' digital wallets, tracking and validation of incoming transactions, generation and primary validation of transactions in blockchain networks, wherein the server contains
[0014] at least one hardware security module (HSM), which is connected to the control server and provides an isolated environment to create and maintain the full life cycle of digital wallets, secure storage of private keys of digital wallets, storage of the authentication data of administrators and users to support the process of sending addresses of digital wallets to the control server, validation of transactions, signing of the confirmed transactions and their transfer to the control server.
[0026] In another preferred embodiment of the presented solution the method is proposed to implement transactions using the digital currencies in the blockchain network, comprising the following steps: [0027] a request is received on the control server to create a digital wallet to make transactions using digital currencies, in which the transaction multisignature rules and rules for confirmation of transactions by users for the created digital wallet are set, and the multisignature rules include at least the data of users assigned to sign the transaction; [0028] the rights and signature of the request for creation of a digital wallet are verified by the authentication data; [0029] the signed request is transferred to the hardware security module (HSM), where the user's digital wallet is created by generating private and public keys; [0030] the private and public keys of the digital wallet and the authentication data of users assigned to confirm transactions on the created digital wallet are saved in the HSM; [0031] the public key of the created digital wallet and the authentication data of users assigned to confirm transactions on the created digital wallet are transmitted and saved to the database of the control server; [0032] a request is received on the control server to execute a transaction by one of the created digital wallets; [0033] primary data of the digital wallet in the blockchain network are collected on the control server; [0034] based on the primary data, a raw transaction is generated and the primary transaction is saved on the control server; [0035] the raw transaction is confirmed by all users using the prescribed transaction multisignature rules and transaction confirmation rules for this digital wallet; [0036] after checking the confirmation of the transaction by the control server, the raw transaction and signatures of the users who confirmed the transaction are transmitted to the HSM; [0037] the rules for transaction confirmation by each signer, the conditions for multisignature of the raw transaction are verified on the HSM by the authentication data; in case of successful verification the raw transaction is signed using the private key of the digital wallet whereby the transaction was initiated; [0038] the signed transaction is transferred to the control server for its further transfer to the blockchain network.
[0054] As shown in FIG. 1, the claimed system (100) comprises a control server (110) that processes all incoming requests from users (10) and administrators (20), a hardware security module (HSM) (120), which is connected to the server and is also connected to one or more redundant HSMs (121)—(123).
[0059] An administrator module (111) may be a separate secure web portal where administrators (20) can observe a list of users (10) and their digital wallets, observe the analytics on digital wallets, including current balances, history of transactions of a user and all requests for input/withdrawal of digital assets.
[0060] Administrators (20) may approve withdrawal requests in those cases when signing by the bank representatives is required. Administrators (20) may also set limits on withdrawal of digital assets for each specific user (10), so that any transaction exceeding this limit will require manual verification and approval from the bank manager. Similarly for deposits, the administrator (20) can manage a trusted list of addresses (white list), deposits from which are automatically credited to the balance of the user (10). If the deposit came from an unknown address, then validation by the manager is required for its crediting. Similarly, administrators (20) can set the limit of allowable deposit so that in the event of receipt of abnormally large deposit to the user's wallet (10), they can request the corresponding proof of source of funds from them before the funds are credited to their account.
[0069] HSM (120) provides an isolated secure environment for generation and storage of digital wallet addresses and private keys, as well as for signing of the approved fund withdrawal transactions. HSM (120) stores the authentication information, including public keys of all users (10). Another feature of HSM (120) is the provision of random generation of private keys with very high entropy.
[0070] The general principle of operation of the claimed system (100) consists in multi-factor confirmation of transactions prior to their transmission to blockchain (150). The server (110) receives and validates user (10) requests to create digital wallets, as well as stores the information about digital wallets of users (10), and when creating digital wallets for each of them the transaction multi-signature rules and the rules for their confirmation by users (10) are specified.
[0071] The control server (110) processes incoming requests for creation of digital wallets by users (10), verifies the signatures of requests by the authentication data of users and generates raw (primary) transactions, which are subsequently transmitted to the HSM (120) for further confirmation.
[0072] HSM (120) performs additional verification of the signatures of all requests for signing the raw transaction with the private key of the corresponding digital wallet and sends the signed transaction to the control server (110) for further transmission to the blockchain network (150). If verification of the transaction confirmation rules and user signatures (319) and verification of multisignature conditions (320) at the HSM (120) is successful, then the HSM (120) performs the procedure of signing the received raw transaction and transmits the signed transaction back to the server (110), which subsequently transfers the signed transaction to the blockchain network (150) for settlement.
[0082] FIG. 2C shows a procedure (230) of creating a digital wallet for performing transactions with digital assets, in particular, with cryptocurrency. At the first stage (231) a request to create a digital wallet is received from user (10). The request (231) includes the type of cryptocurrency, multisignature rules and transaction confirmation rules, and it is generated by means of a user module (112).
[0083] The request (231) to create a digital wallet is signed with the user's private key (232) stored on the user's hardware token. The signed request is sent to the server (110) for further validation (233).
[0084] The validation process (233) consists in processing the authentication data of the user account (220), particularly, verification of signature of the request (231) for compliance with the authentication data, particularly, with the public key stored in the server database (113). Also, in the verification process (233), the rights of the user (10) are checked.
[0085] After successful validation of the request on the control server (110), the user request is transmitted to the HSM (120), where the validation process (234) is also performed, during which the signature of the request (232) is verified for compliance with the public key stored in the HSM (120).
[0086] Based on the results of validation (234) of the request at the HSM a public/private key pair (235) is generated for the new digital wallet. In addition, the parameters for created wallets and transaction multisignature and confirmation rules for these wallets (236) are saved at the HSM (120). After processing the request for creation of digital wallet, the information about successful status of the procedure (230) of creating the digital wallet and its public key are transmitted to the server (237).
[0089] Digital wallet may be used for various types of cryptocurrencies, for example, BTC, BCH, ETH, ETC, ERC20, ERC223, LTC, etc.
PNG
media_image1.png
1021
835
media_image1.png
Greyscale
Gnosis is relied upon to teach an automated smart contract (reads on the GnosisSafe which is a smart contract by explicit declaration and implementation, see Gnosis line 7) data structure (reads on organized data formats such as the exemplary arrays, hash maps and nested maps with defined relationships, operations and invariants, see Gnosis state variables) deployed and (The Examiner construes this to be an obvious if not necessary limitation of the execution/publishing/installation of the Gnosis code because the “pragma solidity 0.4.19” text only exists in contracts intended for deployment and specifies the Solidity compiler version, which compiles the code to EVM bytecode for deployment on a blockchain such as Ethereum, see Gnosis line 1 and constructor + setup pattern) persisted on a distributed ledger (reads on the GnosisSafe contract executes on Ethereum which is explicitly a distributed ledger which is distributed across a plurality of nodes worldwide, see GnosisSafe state variables and contract storage) of a decentralized computing system (reads on a blockchain such as Ethereum and the contract itself which implements decentralized governance (multisig, no admin override) as a result, both the platform and the contract are decentralized, see Gnosis); instantiate (reads on the Gnosis Constructor function which by definition creates a new instance or concrete occurrence of a data structure/GnosisSafe contract from a template/class, see Gnosis “function GnosisSafe..” constructor + setup function which is the instantiation mechanism because calling this creates a new smart contract instance) the automated smart contract (reads on the GnosisSafe which is a smart contract by explicit declaration and implementation, see Gnosis line 7) data structure (reads on organized data formats such as the exemplary arrays, hash maps and nested maps with defined relationships, operations and invariants, see Gnosis state variables) deployed on (The Examiner construes this to be an obvious if not necessary limitation of the execution/publishing/installation of the Gnosis code because the “pragma solidity 0.4.19” text only exists in contracts intended for deployment and specifies the Solidity compiler version, which compiles the code to EVM bytecode for deployment on a blockchain such as Ethereum, see Gnosis line 1 and constructor + setup pattern) the distributed ledger (reads on the GnosisSafe contract executes on Ethereum which is explicitly a distributed ledger which is distributed across a plurality of nodes worldwide, see GnosisSafe state variables and contract storage) for managing digital assets (reads on receiving/storing/transferring ETH via threshold signatures, see Gnosis line 38+), the automated smart contract (reads on the GnosisSafe which is a smart contract by explicit declaration and implementation, see Gnosis line 7) data structure (reads on organized data formats such as the exemplary arrays, hash maps and nested maps with defined relationships, operations and invariants, see Gnosis state variables) comprising a list of pointers referencing a plurality of addresses (The Examiner asserts this is an obvious limitation due to the disclosure of Gnosis because one of ordinary skill in the art would know in Solidity and blockchain contexts, addresses are pointers because they reference accounts on the blockchain where owners can control assets via their private keys and each address in the array points to a specific owner’s account, see Gnosis lines 17 and 341 – 349), a mapping of transactions (reads on the transaction hashes that creates a mapping structure that tracks transactions, see Gnosis lines 24 – 25 and 326 – 339), a mapping of confirmations (reads on tracking whether a transaction was confirmed by an owner where the nested mapping structure allows tracking which specific owners have confirmed which specific transactions, Gnosis lines 24 – 25 and 204 – 220), and a user-configured number of required owner signatures for the transactions (reads on the user configures the threshold variable explicitly representing “number of required confirmations for a safe transaction”. The Examiner asserts required owner signatures and required confirmations to be equivalent because both represent the number of owner approvals needed. In addition, the threshold is user-configured/passed as a parameter, stored in contract state and enforced during execution validation, see Gnosis line 15 and 57 – 81 and 160 – 172), wherein each of the addresses corresponds to an owner of a plurality of owners (The Examiner asserts this is an obvious limitation due to the disclosure of Gnosis because one of ordinary skill in the art would know the isOwner mapping explicitly establishes the correspondence between addresses and owners where each address in the owners array corresponds to an owner, see Gnosis lines 20 – 36 and 72 – 80), wherein each of the required owner signatures comprises a digital signature created by the private key (reads on the combination of the Ethereum cryptographic primitive of ecrecover (line 251) which recovers an address/public key from a digital signature created with the corresponding private key. Line 251 explicitly validates that the signature was created by the private key corresponding to the owner’s address, see Gnosis lines 221 – 255) corresponding to each of the required owners (The Examiner construes this to be an obvious if not necessary limitation of the prior art of record because the addresses derived from public keys that are accepted by Gnosis are conventionally derived from a private key, see Gnosis lines 58 – 80); configure risk controls in the automated smart contract data structure for the transactions (reads on multi-signature requirements which are transaction risk controls and the ability to configure threshold and owner composition provides granular risk management, see Gnosis lines 100 – 137 and 160 – 171); provide an address of the safe data object to the user for receiving deposits (reads on the fallback function which enables the contract to accept Ether transfers sent to the contract address, see Gnosis lines 38 – 44. The Examiner asserts a person of ordinary skill in the art would know every smart contract deployed on Ethereum has a unique address that serves as its identifier and deposit destination and the fallback function marked “payable” explicitly teaches that the contract address can receive deposits. The contract’s deployment and accessibility inherently makes its address available for receiving funds); receive a transfer of a digital asset by the user addressed to the address of the safe data object (reads on the fallback function which enables the contract to accept Ether transactions, which are digital asset transfers, sent to the contract address, see Gnosis lines 38 – 44. The Examiner asserts in Solidity/Ethereum, when a user sends Ether to a contract address, the fallback function is automatically invoked. This is a direct teaching of receiving digital asset transfers addressed to the contract/safe data object); receive a request (reads on implementing the public function invocation, see Gnosis lines 211 – 220) from the user (reads on implementing the caller verification, see Gnosis lines 214 – 215) to initiate a transaction (reads on create transaction hash and store confirmation, see Gnosis line 216) of a digital asset (reads on the Ether amount/value parameter, see Gnosis line 216) from the safe data object (reads on the contract’s own balance, see Gnosis line 289) to a target recipient at a target address (reads on the address to parameter, see Gnosis line 211, 232 and 285); store a signature collected from each of the required owners in the mapping of confirmations (reads on storing confirmation state that exactly threshold number of valid owner confirmations exist before allowing execution, see Gnosis lines 222 – 255); confirm the mapping of confirmations contains all of the required owner signatures; and upon confirmation of the required owner signatures, transfer the digital asset to the target address (reads on after validating the threshold is reached, execute Transaction calls, which has the sequential flow of validate threshold -> execute -> call with value transfer which directly implements the claim language, see Gnosis lines 232 – 306).
Before the effective filing date of the invention it would have been obvious to one of ordinary skill in the art to modify the multisignature transaction validation teachings of the prior art of record by integrating the on-chain smart contract multisignature validation structure with owner array, threshold variable, confirmation mapping and transaction execution logic teachings of Gnosis to realize the instant limitations. One or more of the underpinning rational(s), as discussed in KSR international Co, v, Teleflex inc,s etai,s 550 U,S. 398 (2007) U.S.P.Q.2d 1385, also see MPEP § 2141 {IN), are used to support this conclusion of obviousness. Accordingly, one of ordinary skill in the art would have recognized that applying the known technique of Gnosis would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the immutable blockchain-deployed smart contract validation logic teachings of the prior art of record would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such features into similar systems, resulting in an improved system that achieves the isolated secure environment for rule validation that Smirnov explicitly identifies. The motivation to combine the references is applied to all claims below this heading.
Per claim 2, the prior art of record further suggests wherein the automated smart contract data structure (reads on the GnosisSafe which is a smart contract by explicit declaration and implementation, see Gnosis line 7 and digital wallet of Smirnov para 0057) is coupled to an off-chain database (reads on the database that stores information about digital wallets, see Smirnov para 0057) through one or more pointers referring to configurable off-chain computational addresses (reads on the addresses of digital wallets stored in the database are computational addresses that identify wallets/contracts, see Smirnov para 0057, 0086. In addition, one of ordinary skill in the art would know in Solidity and blockchain contexts, addresses are pointers because they reference accounts on the blockchain where owners can control assets via their private keys and each address in the array points to a specific owner’s account, see Gnosis lines 17 and 341 – 349) of the off-chain database, the off-chain database comprising at least one data record (reads on the database stores information about addresses, transactions, amounts/individual data records for accounts/users, see Smirnov para 0057) having data fields (reads on the separate categories of stored information such as the exemplary addresses, transactions, accounts, rights, see Smirnov para 0057) to store a set of amount thresholds (reads on withdrawal limits for each specific user, see Smirnov para 0057 and 0060), wherein each amount threshold is used to configure (reads on the specific withdrawal limit, see Smirnov para 0060 and 0062) a variable signature requirement for a transaction of an amount higher than the amount threshold (reads on any transaction exceeding the withdrawal limit will require M of N signatures from K groups of users, see Smirnov para 0060 and 0062), wherein the set of amount thresholds can be dynamically modified by the user through the centralized computing system (reads on the obvious if not necessary teaching of the prior art of record in order to set and administrator the limits, see Smirnov para 0057 and 0060 – 0062).
Per claim 4, the prior art of record further suggests generate (reads on a request for approval of the transaction is generated, see Smirnov para 0093), using the centralized computing system (reads on the control server, see Smirnov para 0092), a signed data object token for the user to approve the transaction (reads on the request for approval of the transaction that is signed, see Smirnov para 0092 – 0093), the signed data object token (reads on the request for approval of the transaction that is signed, see Smirnov para 0092 – 0093) residing on one of a server backend of the centralized computing system, the user’s device, or a distributed ledger as a data payload (reads on the signed approval is recorded in the server database, see Smirnov para 0094 – 0095); and incorporate a pointer to (reads on when the server transfers the raw transaction and the signed requests it incorporates references/pointers to these signed objects for processing, see Smirnov para 0057 and 0095) the signed data object token (reads on the request for approval of the transaction that is signed, see Smirnov para 0092 – 0093), wherein the signed data object token is configured for (reads on the request for approval of the transaction that is signed, see Smirnov para 0092 – 0093) verification by an automated approver computing system (reads on the HSM verifies the rules for confirmation of the transaction by each signer and the conditions for multisigning of the received transaction, see Smirnov para 0072 and 0096), wherein the automated approver computing system comprises (reads on the HSM verifies the rules for confirmation of the transaction by each signer and the conditions for multisigning of the received transaction, see Smirnov para 0072 and 0096) automated approval agents that are configured to generate an (reads on the HSM is the automated approver system and it enables/provides the functions of signing of the approved fund withdrawal transactions, see Smirnov para 0067 – 0073) automated signed approval message (reads on the transaction that is signed with the private key, see Smirnov para 0096) based on validation of at least one of the user’s signed data object token (reads on the HSM verifies the rules for confirmation by each signer for the received raw transaction, see Smirnov para 0096) and a target recipient’s signed data object token (see Smirnov para 0058 and 0096).
Claim 11 is analyzed with respect to claim 1.
Claim 12 is analyzed with respect to claim 2.
Claim 14 is analyzed with respect to claim 4.
Claim 20 the non-transitory computer readable medium (see Smirnov para 0105) is analyzed with respect to claim 1.
Claims 3, 6, 9, 10, 13, 16 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Smirnov in view of Gnosis in view of Kim (US Pub. No. 2020/0005282 A1).
Per claim 3, the prior art of record suggests the computer-implemented system of claim 1.
The prior art of record is silent on explicitly stating upon a private key becoming inaccessible, configure, using the centralized computing system, a replacement safe data object for the user; and transfer at least one digital asset stored in the safe data object to the replacement safe data object using at least one transaction, wherein the at least one transaction is signed by the required owners defined for the automated smart contract data structure.
Kim82 (US Pub. No. 2020/0005282 A1) is relied upon to teach upon a private key becoming inaccessible (reads on the private key is lost, see Kim82 para 0003 and 0065 – 0066), configure (reads on the user sets up and activates the wallet configuration including new keys, see Kim82 para 0045 and 0065), using the centralized computing system (reads on using any suitable device such as third party system, see Kim82 para 0045 and 0065), a replacement safe data object for the user (reads on the wallet with new public keys that replaces the old public keys, see Kim82 para 0094 – 0095); and transfer at least one digital asset stored in the safe data object to the replacement safe data object using at least one transaction (reads on transferring the recovery deposit to the new wallet, see Kim82 para 0031, 0108 – 0110), wherein the at least one transaction is signed by the required owners defined for the automated smart contract data structure (reads on a transaction signed with the new private keys associated with one or more blockchain owner accounts, see Kim82 para 0031, 0034, 0041 and 0094).
[0003] Conventionally, if the private key(s) associated with a cryptocurrency wallet are lost, an owner cannot recover access to the wallet and loses the ability to transact from the wallet.
[0031] The cryptocurrency wallet (“wallet”) (e.g., 210) functions to transact cryptocurrency within the distributed ledger system. For example, the wallet can send cryptocurrency from a blockchain address (e.g., user address, wallet address) to a specified endpoint using a transaction (e.g., signed by a private key associated with the address).
[0045] In one variation, the third party system (e.g., 220) creates or manages the wallet (e.g., 210). In this variation, the owners (e.g., owner accounts or owner devices 231, 232 shown in FIG. 2, 331-333 shown in FIG. 3) generate an asymmetric key pair, store the private keys of the asymmetric key pair, and transmit the owner public keys (owner accounts) to the third party system (e.g., 220, 330) (e.g., via the owners' user accounts on the third party system). The third party system determines a recovery account (with a corresponding recovery key) for the wallet, and can create the wallet (e.g., by sending a “create wallet” or “create contract” message, as described herein), assign the owner accounts as the wallet owners, and assign selected recovery account as the wallet recovery account. FIG. 3 shows wallet 310 that includes public keys A, B and C generated by owner devices 331, 332 and 333, respectively. The owner devices 331, 332 and 333 transmit their respective public keys to the third party system 320, which creates the wallet 310 and assigns the owner public keys A, B and C as the owners of the wallet S310. The third party system 320 also determines a recovery key (e.g., 0x777) and assigns the public key corresponding to the determined recovery key as the recovery account for the wallet 310.
[0065] Receiving a wallet recovery request from a user S100 functions to initiate the recovery process. The wallet recovery request is preferably received by the trusted third party (e.g., 220, 320) (e.g., at the third party system), but can be received by an owner, the wallet, or any other suitable entity. The wallet recovery request is preferably received through the third party system (e.g., wherein the user requests the wallet recovery through a logged-in user account associated with the wallet), but can alternatively be dialed in (e.g., wherein the user calls the trusted third party to request the wallet recovery), or otherwise requested. The wallet recovery request is preferably received from a user device (requestor user device) of the user, but can alternatively be received from any other suitable device.
[0066] S100 can be performed when: the wallet owner loses all the private owner keys for the wallet; when the wallet owner loses a subset of the private owner keys for the wallet; when the wallet owner loses control over one or more of the private owner keys for the wallet; or upon occurrence of any other suitable trigger event. The user can be any suitable user, since the user is as yet unverified at S100, but is preferably an owner of the account.
[0094] Providing wallet access to the user Shoo functions to provide wallet access to the requesting user. Shoo preferably includes activating the new public keys or hashes thereof (new owner accounts, new owner addresses) for the wallet, wherein the wallet and/or blockchain system accepts or validates transactions from the wallet that are signed by the new private keys (new private owner keys) paired with the new public keys (new public owner keys).
[0095] Activating the new public keys can include: allowing (e.g., verifying, executing) transactions signed by the new public keys, adding the new public keys to the wallet (e.g., to the set of keys that can sign transactions from the wallet), replacing the old public keys (owner accounts, owner addresses) with the new public keys (example shown in FIG. 4), deleting the old public keys and retaining the new public keys, or otherwise activating the new public keys. The new public keys (or hashes thereof) can be received: as part of the challenge initiation request; as part of a recovery message signed by the recovery account; or otherwise received by the wallet. However, access can be otherwise provided to the requesting user. The new public keys (or hashes thereof) can optionally be stored by the third party system, or not stored by the third party system. The new private keys (e.g., new private owner keys) are preferably stored by the user or owner in a similar manner to old private key storage (e.g., using HSMs, cold storage, user devices, etc.), stored by the third party system, or otherwise stored.
Before the effective filing date of the invention it would have been obvious to one of ordinary skill in the art to modify the smart contract wallet teachings of the prior art of record by integrating the wallet teachings of Kim82 to realize the instant limitation. One or more of the underpinning rational(s), as discussed in KSR international Co, v, Teleflex inc,s etai,s 550 U,S. 398 (2007) U.S.P.Q.2d 1385, also see MPEP § 2141 {IN), are used to support this conclusion of obviousness. Accordingly, one of ordinary skill in the art would have recognized that applying the known technique of Kim82 would have yielded predictable results and resulted in an improved system. It would have been recognized that combining the ability to recover lost keys as taught by Kim82 with the wallet teachings of the prior art of record would have been obvious because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such key recovery features into similar systems, resulting in an improved system that uses all available known in the art techniques to improve administration of blockchain wallets. The motivation to combine the references is applied to all claims below this heading.
Claim 6 is analyzed with respect to claim 3. The prior art of record further suggests seed phrase recovery (reads on wallet recovery when private keys are lost, see Kim82 para 0045 and 0066) to enable the user to access and recover at least one digital asset stored at the safe data object by re-generating a new safe data object having a new public / private key pair (reads on generating a new key pair for the wallet which is analogous to re-generating a new safe data object, see Kim82 para 0045 and 0066 and 0094 – 0096) that is provided to the user upon obtaining signed data object tokens from each of the other required owners (see Kim82 Figures 3 – 5 and associated text).
Per claim 9, the prior art of record further suggests wherein the owners comprise: a user owner corresponding to the requesting user(reads on one or more blockchain owner accounts, see Kim82 para 0041), and one or more provider owners associated with the centralized computing system (reads on a specific one of the set of owner accounts, see Kim82 claim 1).
Per claim 10, the prior art of record further suggests wherein the user is prompted to sign the transaction from the safe data object via the user’s associated digital wallet, wherein the prompting comprises invoking cryptographic wallet software managing the user’s associated digital wallet to obtain a signature using the private key stored in the user’s associated digital wallet (see Kim82 Figure 3 block 310 and Smirnov para 0017, 0019, 0042 and 0083).
Claim 13 is analyzed with respect to claim 3.
Claim 16 is analyzed with respect to claim 6.
Claim 19 is analyzed with respect to claim 9.
Claims 5 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Smirnov in view of Gnosis in view of Dincoglu (US Pub. No. 2025/0014099 A1).
Per claim 5, the prior art of record suggests the computer-implemented system of claim 1. The prior art of record does not explicitly state pay for computation gas costs using the user’s assets stored at the safe data object; and monitor computation gas costs produced by the user’s transactions.
Dincoglu (US Pub. No. 2025/0014099 A1) suggests pay for computation gas costs using the user’s assets stored at the safe data object (reads on the users’ crypto wallet is used to pay gas fees, see Dincoglu para 0027); and monitor computation gas costs produced by the user’s transactions (reads on paying transaction fees using the users’ crypto wallet gas balance, see Dincoglu para 0027, 0029 and 0030).
[0027] Gas abstraction refers to a mechanism that enables users to pay gas fees using multiple currencies or tokens. Users can pay transaction fees using any token supported by the relaying entity rather than being limited to the network's gas token. In some instances, a relaying entity is not used and the users' crypto wallet gas balances in the subnet are constantly monitored and automatically replenished for a seamless experience by the smart contracts. However, if this automatic process is not in place, users must maintain their gas balance another way. For example, users may request for gas tokens from friends/administrators to be manually airdropped to their crypto wallet at the time of the very first deposit as they start with a balance of zero gas tokens. As another example, when the user consumes all the initial gas deposited in their crypto wallet, they can deposit additional gas tokens acquired from trading into their crypto wallet. As another example, if they run out of gas tokens in the subnet contracts, users can manually swap their own tokens for gas tokens. If none of the above options work, users must again ask friends/administrators for a gas token airdrop. These additional steps create unnecessary friction and additional steps for the user.
[0029] According to embodiments, the multi-blockchain trading system enables token deposits, withdrawals, transfers and swapping (trading) of blockchain assets in the multi-chain platform by using smart contracts and one or more third-party bridge applications. Some embodiments include a blockchain (subnet) where token balance management for a given crypto wallet is offloaded to the same smart contracts. In some embodiments, gas token balance management in the crypto wallets is automatically handled in the background by the smart contracts on behalf of the user.
[0030] The disclosed subject technology further provides improvements to the technological field by facilitating an autofill for gas abstraction. Whenever a user interacts with the subnet smart contracts using their crypto wallet (e.g., deposit, send tokens to an address, add an order, cancel an order, etc.), the autofill automatically replenishes the user's gas balances, if necessary, in the background without any user involvement.
Before the effective filing date of the invention it would have been obvious to one of ordinary skill in the art to modify the safe data object teachings of the prior art of record by integrating the gas fees from a user’s wallet to pay for transaction fees teachings of Dincoglu to realize the instant limitation. One or more of the underpinning rational(s), as discussed in KSR international Co, v, Teleflex inc,s etai,s 550 U,S. 398 (2007) U.S.P.Q.2d 1385, also see MPEP § 2141 {IN), are used to support this conclusion of obviousness. Accordingly, one of ordinary skill in the art would have recognized that applying the known technique of Dincoglu would have yielded predictable results and resulted in an improved system. It would have been recognized that combining the payment of gas fees with your crypto wallet balance to the transaction teachings of the prior art of record would have been obvious because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such transaction fee payment features into similar systems, resulting in an improved system that uses all available known in the art techniques to improve the smart contract experience. The motivation to combine the references is applied to all claims below this heading.
Claim 15 is analyzed with respect to claim 5.
Claims 7 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Smirnov in view of Gnosis in view of Kim (US Pub. No. 2021/0374731 A1).
Per claim 7, the prior art of record suggests the system of claim 1. The prior art of record is silent on explicitly stating wherein the risk controls comprise a source address blacklist, the automated smart contract data structure configured to reject a transaction from an address included in the blacklist.
Kim (US Pub. No. 2021/0374731 A1) is relied upon to teach the risk controls comprise a source address blacklist, the automated smart contract data structure configured to reject a transaction from an address included in the blacklist (reads on preventing all smart contract communication to a particular address that is blacklisted, see Kim para 0031, 0035 and 0038).
[0031] In an example, target contract is a token smart contract that has the following roles: master, minter, minter, pauser, blacklister, owner, and administrator. The master minter adds and removes minters and increases their minting allowance. Minters create and destroy tokens. A pauser pauses the contract, which prevents all transfers, minting, and burning. A backlister prevents all transfers to or from a particular address, and prevents that address from minting or burning. An owner can reassign any of the roles except for admin. An admin can upgrade the contract and re-assign itself. In some implementations, the target smart contract implements at least one standard method/function of the ERC-20 interface. Additionally, or alternatively, the target smart contract can implement at least one extended method/function of the ERC-20, interface. In an example, a blacklisted address will be unable to call transfer( ), transferFrom( ), or approve( ), and will be unable to receive tokens; transfer( ), transferFrom( ), and approve( ), will fail if the contract has been paused.
[0035] In variants, a minter mints tokens via the mint function. The minter specifies the amount of tokens to create and a To address which will own the newly created tokens. A minter may only mint an amount less than or equal to its minting allowance. The minting allowance will decrease by the amount of tokens minted; and the balance of the To address and total supply will each increase by amount of tokens minted. In some implementations only a minter may call the minting function. In some implementations, minting fails when the contract is paused. In some implementations, minting fails when the minter or the To address is blacklisted. In some implementations, the minter emits a Mint event and a Transfer event.
[0038] In variants, the token smart contract can blacklist addresses. Blacklisted addresses are unable to transfer tokens, approve tokens, mint tokens, or burn tokens. Addresses can be blacklisted by using the blacklist function of the token smart contract. In variations, only a blacklister role can call the blacklist function.
Before the effective filing date of the invention it would have been obvious to one of ordinary skill in the art to modify the smart contract teachings of the prior art of record by integrating the smart contract rejecting transactions from/to blacklisted addresses of Kim to realize the instant limitation. One or more of the underpinning rational(s), as discussed in KSR international Co, v, Teleflex inc,s etai,s 550 U,S. 398 (2007) U.S.P.Q.2d 1385, also see MPEP § 2141 {IN), are used to support this conclusion of obviousness. Accordingly, one of ordinary skill in the art would have recognized that applying the known technique of Kim would have yielded predictable results and resulted in an improved system. It would have been recognized that combining the ability to restrict specific addresses with the smart contract teachings of the prior art of record would have resulted in predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such security features into similar systems, resulting in an improved system that uses all available known in the art security techniques to improve data security. The motivation to combine the references is applied to all claims below this heading.
Claim 17 is analyzed with respect to claim 7.
Claims 8 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Smirnov in view of Gnosis in view of Madisetti (US Pub. No. 2022/0138735 A1) in view of Jentzsch (US Pub. No. 2022/0116214 A1).
Per claim 8, the prior art of record suggests the system of claim 1, wherein the centralized computing system is configured to provide access to an internet application hosted by the centralized computing system (see Smirnov para 0056 – 0058) for the user to access at least one bank account (The Examiner construes this to be an obvious limitation of the prior art’s API that enables integration with banking systems, see Smirnov para 0007). The prior art of record is silent on explicitly stating a safe data object management interface is integrated into the internet application to allow the user to access the safe data object using application programming interfaces coupling the internet application and the safe data object, the application programming interfaces including programmatic computing calls to a node hosting the distributed ledger of a decentralized computing system, the programmatic computing calls instructing and confirming state change instructions to be transmitted to the distributed ledger of a decentralized computing system corresponding to state changes of the safe data object.
Madisetti (US Pub. No. 2022/0138735 A1) is relied upon to teach for the user to access at least one bank account (reads on sending requests and access bank accounts to exchange currency and transfer value, see Madisetti para 0100 – 0106), the application programming interfaces including programmatic computing calls to a node hosting the distributed ledger of a decentralized computing system (reads on the VTTP server exposes API endpoints and blockchain clients make programmatic calls to blockchain nodes that host distributed ledgers, see Madisetti para 0062 and 0097).
[0062] Referring now to FIG. 3, the components of the Value Token Transfer Protocol (VTTP), are described in more detail. In one embodiment, VTTP works as a request-response protocol based on a client-server architecture, where a VTTP client 200 sends requests to a VTTP Server 212, and the server responds to the requests. The VTTP clients 200 may be available for different platforms and devices such as a desktop client 204, a mobile client 206 or an embedded client 208. Users 202 send VTTP requests to the VTTP server 212 using VTTP clients 200. VTTP requests contain VTTP commands 210 which are processed by the VTTP server 212. A VTTP server 212 may have one or more VTTP Workers 214 to process VTTP requests and execute the VTTP commands 210 sent by VTTP clients 200. VTTP server 212 has blockchain clients 216 for each of the participating blockchain networks 220, 222, 224.
[0097] Referring now to FIG. 15, an exemplary VTTP reference architecture, is described in more detail. Users 800 may use VTTP clients 802, 806 to communicate with VTTP servers 810, 812, 814 through an API gateway 804. The VTTP servers 810, 812, 814 sit under a load balancer 808 and expose a number API endpoints. The API gateway 804 makes these APIs available to the VTTP clients. Each API has an endpoint (for example, vttp://example.com/ethereum) and a set of VTTP methods or commands which are supported for the endpoint (such as GET, SEND, REQUEST, etc.). The API gateway 804 may use an API key to enable authentication for APIs. The API gateway 804 may also perform additional functions such as logging each API request and rate-limiting of requests. A separate relational (SQL) or non-relational (NoSQL) database 816 may be used to store data such as user credentials and application specific data. Each VTTP server is connected to all the participating blockchain networks 818, 820.
[0100] Referring now to FIG. 18, components of the VTTP+ protocol are described in more detail. In the current embodiment, VTTP+ works as a request-response protocol based on a client-server architecture, where a VTTP+ client 1100 sends requests to a VTTP+ Server 1110, and the server 1110 responds to the requests. The VTTP+ clients 1100 may be available for different platforms and devices such as a desktop client 1104, a mobile client 1106 or an embedded client 1108. Users 1102 send VTTP+ requests to the VTTP+ server 1110 using VTTP+ clients 1100. VTTP+ requests contain VTTP+ commands 1124 which are processed by the VTTP+ server 1110. A VTTP+ server 1110 may have one or more VTTP+ Workers 1112 to process VTTP+ requests and execute the VTTP+ commands 1124 sent by VTTP+ clients 1100. The VTTP+ server 1110 may provide a VTTP+ API 1114 that allows the participating blockchain networks 1118, participating fiat banks 1120 and participating fiat wallets 1122 to use VTTP+ protocol for exchange of value 1126, 1128, 1130. The VTTP+ protocol supports the following types of transactions: [0101] VTTP+ supports exchange of fiat currency (in fiat bank accounts and fiat wallet apps) with tokens on blockchain networks; [0102] Fiat value transfer between fiat accounts of participating fiat banks; [0103] Fiat value transfer between wallet accounts of participating fiat wallets; [0104] Fiat value transfer between fiat accounts of participating fiat banks and accounts of participating fiat wallets; [0105] VTTP+ allows retrieving information on accounts, balances, and transactions for all participating fiat bank accounts and fiat wallets; and [0106] VTTP+ allows retrieving information on accounts, balances, contracts, transactions for all participating blockchain networks.
Before the effective filing date of the invention it would have been obvious to one of ordinary skill in the art to modify the centralized control server system that provides access to an internet application for digital wallet management teachings of Smirnov (see para 0007) with the enabling user access to bank accounts through integration with participating banks teachings of Madisetti (see para 0103 – 0106) to realize the instant limitation. One or more of the underpinning rational(s), as discussed in KSR international Co, v, Teleflex inc,s etai,s 550 U,S. 398 (2007) U.S.P.Q.2d 1385, also see MPEP § 2141 {IN), are used to support this conclusion of obviousness. Accordingly, one of ordinary skill in the art would have recognized that applying the known technique of Madisetti to the explicit contemplation of Smirnov to integrate with banking systems would have yielded predictable results and resulted in an improved system. It would have been obvious because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such features into similar systems, resulting in an improved system with complementary components that when combined provides users with a single interface to manage both digital assets and traditional banking. The motivation to combine the references is applied to all claims below this heading.
Jentzsch (US Pub. No. 2022/0116214 A1) is relied upon to teach a safe data object management interface is integrated into the internet application to allow the user to access the safe data object using application programming interfaces coupling the internet application and the safe data object (see Jentzsch para 0023 – 0024), the programmatic computing calls instructing and confirming state change instructions to be transmitted to the distributed ledger of a decentralized computing system corresponding to state changes of the safe data object (see Jentzsch para 0021, 0026 and 0028).
[0021] One embodiment of a disclosed system, method and computer readable storage medium is provided herein for enabling customization of keys by users. A command may be received, by a user interface, to assign a role to a key or keypair (e.g., public and private keys). Responsive to receiving the command, an API operably coupled with the user interface may transmit an update to a smart contract to associate the role with the key (e.g., the public key of a keypair), where the key is associated with a multisignature wallet (e.g., a wallet that maintains the private key of the keypair). The API may receive a request to initiate a transaction, the transaction affected based on whether a key having the assigned role signs the transaction. Responsive to the key having the assigned role signing the transaction, the transaction is affected in a manner. For example, the key may be an approval key that, when signing a transaction initiated by an initiation key, causes the transaction to be executed.
[0023] FIG. 1 illustrates one example configuration of a system environment for customization and remote custody of keys, in an accordance with an embodiment. FIG. 1 depicts environment 100, which includes client device 110, client device 111, network 120, custody provider 130, blockchain 141, multisignature smart contract 140, and privacy service 150. Client device 110 and client device 111 are end-user devices. Client device 110 and client device 111 may be devices of a same user or of different users. Additional client devices may be present in environment 100. A client device may output a user interface for display to a user. The user interface may be operable by the user to cause a key to be generated, to assign a role to a key, and to initiate requests in connection with smart contract 140. The user interface may be generated by an application of a multisignature wallet that has an application programming interface (API) operable to update multisignature smart contract 140. As referred to herein, the terms “multisignature” and “multisig” may be used interchangeably. The application may be installed on a client device, or may be accessed using a browser (e.g., by navigating using the browser to a web page provided by a web server that hosts the user interface). Client devices 110 and 111 store private keys that are generated by those devices.
[0024] The user interface enables a user to assign different roles to keys, thus enabling use of those keys to perform different functions (e.g., in connection with signing a transaction). For example, the user interface may include selectable options that, when selected, cause roles to be assigned to keys associated with a user account. Some exemplary roles include a role of being an “initiation key”, an “approval key”, a “veto key”, and a “recovery key.” The initiation key may perform an initiation function, the approval key may perform an approval function, the veto key may perform a veto function, and a recovery key may perform a recovery function. The user interface enables the user to assign one, or several, roles to a single key with respect to a given transaction. Responsive to receiving an assignment of a role to a key, multisig smart contract 140 is updated to indicate the role of the key with respect to the affected transaction. Alternatively, once a role is assigned, the role may remain in effect until challenged (e.g., the role is effective for multiple transactions until challenged).
[0026] Network 120 provides a communication infrastructure between client device 110, and blockchain 141 (on which multisig smart contract 140 may run, through which multisig smart contract 140 may be communicated with). Network 120 also provides a communication infrastructure between blockchain 141 and custody provider 130. Network 120 is typically the Internet, but may be any one or more networks, including but not limited to a Local Area Network (LAN), a Metropolitan Area Network (MAN), a Wide Area Network (WAN), a mobile wired or wireless network, a private network, or a virtual private network.
[0027] Custody provider 130 generates private keys and stores those keys in a secure way. Custody provider 130 may additionally house and enforce policies associated with keys. Further details of the activity of custody provider 130 are described in further detail below with respect to FIG. 2.
[0028] Multisig smart contract 140 comprises program code for use with an electronic distributed ledger. In one embodiment, the electronic distributed ledger is a blockchain 141. In one embodiment, multisig smart contract 140 includes rules/logic for validating and/or effectuating transactions that are stored in blocks of blockchain 141. For example, a user of a client device, such as client device 110, sends a transaction to blockchain 141 (e.g., signed with needed signatures from private keys held by the user). This may be a simple send transaction (e.g., to move crypto currency), or may be a transaction that triggers a function (e.g., corresponding to a role of a key) in smart contract 140 (which may be, e.g., a multisig smart contract). Smart contract 140 defines rules/logic about how the state of blockchain 141 is changed during a transaction (e.g., storing a value in a state variable).
Before the effective filing date of the invention it would have been obvious to one of ordinary skill in the art to modify the digital wallets and bank account teachings of the prior art of record by integrating the management interface for multisignature wallets/safe data objects that uses APIs to transmit state change instructions to smart contracts and confirm transaction outcomes teachings of Jentzsch to realize the instant limitation. One or more of the underpinning rational(s), as discussed in KSR international Co, v, Teleflex inc,s etai,s 550 U,S. 398 (2007) U.S.P.Q.2d 1385, also see MPEP § 2141 {IN), are used to support this conclusion of obviousness. Accordingly, one of ordinary skill in the art would have recognized that applying the known technique of Jentzsch would have yielded predictable results and resulted in an improved system. It would have been recognized that combining the integrated role-based management interface to the interfaces for managing digital assets stored on blockchain networks teachings of the prior art of record would have been obvious because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such interface features into similar systems, resulting in an improved system that uses all available known in the art techniques to improve the security posture of the system. The motivation to combine the references is applied to all claims below this heading.
Claim 18 is analyzed with respect to claim 8.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Brian Shaw whose telephone number is (571)270-5191. The examiner can normally be reached on Mon-Thurs from 6:00 AM-3:30 PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jeff Nickerson can be reached on (469) 295-9235. The fax phone number for the organization where this application or proceeding is assigned is 703-872-9306.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/BRIAN F SHAW/
Primary Examiner, Art Unit 2432