DETAILED ACTION
Notice of Pre-AIA or AIA Sta
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
This is first office action on the merits in response to the application filed on 03/02/2024.
Claims 1-11 are currently pending and have been examined.
Claim Objections
Claims 1, and 7 are objected to because of the following informalities: In claims 1 and 7, it reads "MPT." The word "MPT" should not be abbreviated without spelling out abbreviation at first occurrence. Appropriate correction is required.
Claim Rejections - 35 USC § 103
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 theprior 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.
5. The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-11 are rejected under 35 U.S.C. 103 as being unpatentable over Nolan et al. (US 20190034936 A1), in view of Dvorak et al. (US 20150324789 A1), and further in view of Chan et al. (US 11301452 B2).
7. Regarding claims 1 and 7, Nolan discloses a method (system for preventing changing and executing of a multi-signature smart wallet until a group key is signed with at least two signatures, comprising: one or more processors; a memory coupled to at least one of the processors; a network interface that connects the local node to one or more remote nodes; and a set of computer program instructions stored in the memory and executed by at least one of the processors in order to perform actions, (Para. 0155-0157)),
initiating a first transaction to register, by the client, the multi-signature smart wallet on a blockchain platform with the k out of n public-private key pairs, (Claim 11. A method for approving transactions for an e-wallet, comprising: combining a transaction with an M of N threshold authorization policy to create an approval request in an originating e-wallet share hosted in a first device; signing the approval request in the originating e-wallet share to create an initial approval request; and providing the initial approval request to an anonymizing router to be transferred to another device hosting another e-wallet share for signing.)
sending, by the client, the n public-private key pairs to n approvers, receiving, a signed approval of the proposal from at least k voters, by the multi-signature smart wallet before allowing funds from the multi-signature smart wallet to be utilized for the proposal, (Para. 0404-0410, Example 69 includes the subject matter of any of examples 64 to 68. In this example, the apparatus includes a secret sharing module configured to generate a shared secret that is transmitted to devices hosting the e-wallet shares. Example 70 includes the subject matter of example 69. In this example, the apparatus includes an escrow creator to create an escrowed key that is transmitted to the devices hosting the e-wallet shares. Example 71 includes the subject matter of either for example 69 or 70. In this example, the apparatus includes a key reconstitution module to reconstitute a key from a shared secret, an escrow, or both. Example 72 includes the subject matter of any of examples 64 to 71. In this example, the apparatus includes a leader elector to choose a master device for completing a transaction. Example 73 includes the subject matter of example 72. In this example, the leader elector is configured to be operated in a protected blockchain. Example 74 includes a method for approving transactions for an e-wallet. The method includes combining a transaction with an M of N threshold authorization policy to create an approval request in an originating e-wallet share hosted in a first device. The approval request is signed in the originating e-wallet share to create an initial approval request. The initial approval request is provided to an anonymizing router to be transferred to another device hosting another e-wallet share for signing. Example 75 includes the subject matter of example 74. In this example, the method includes creating the M of N threshold authorization policy for the e-wallet, creating an authorization signing key pair for each share in the e-wallet, and posting a public key for each share in the e-wallet to a blockchain.)
creating a second transaction to create a proposal that utilizes the multi-signature smart wallet, (Para. 0409, Example 74 includes a method for approving transactions for an e-wallet. The method includes combining a transaction with an M of N threshold authorization policy to create an approval request in an originating e-wallet share hosted in a first device. The approval request is signed in the originating e-wallet share to create an initial approval request. The initial approval request is provided to an anonymizing router to be transferred to another device hosting another e-wallet share for signing.; and Claim 12. The method of claim 11, comprising: signing a received approval request to create a multi-signed approval request; determining that M of N e-wallet shares have signed; and returning the multi-signed approval request to the originating e-wallet share.)
creating a third transaction to vote on the proposal, (Claim 19. receiving votes from devices hosting e-wallet shares to elect a lead device to perform a transaction; and initiating the transaction from the lead device, if M of N devices have selected the lead device.; and Claim 20. receiving votes from devices comprising e-wallet shares to ban a device from participating in transactions; and banning the device, if M of N devices have voted to ban the device.)
Nolan does not explicitly disclose comprising: creating, by a client, k out of n public-private key pairs for a multi-signature smart wallet wherein k is a required threshold number of public-private key pairs to process the multi-signature smart contract and n is the total number of public-private key pairs.
However, Dvorak teaches comprising: creating, by a client, k out of n public-private key pairs for a multi-signature smart wallet wherein k is a required threshold number of public-private key pairs to process the multi-signature smart contract and n is the total number of public-private key pairs, (Para. 0020-0021,One embodiment of the present disclosure includes the creation and use of three different multi-signature private keys in which none of the private keys can be used individually to enact a transaction. In these embodiments, two or more multi-signature private keys may be used to enact a transaction. A first private key, referred herein as the device key, may be stored on the secure device. A second private key, referred herein as a server key, may be stored on a server. In one embodiment, the server key is stored in an encrypted form, decryption thereof requiring the use of an inherence factor such as biometric data that may be provided via the secure device. A third private key, referred herein as a data vault key, may be stored in offline storage. In one embodiment, the data vault key may be secured by a knowledge or inherence factor (PIN, password, biometric data... When you swipe your finger to confirm a transaction, the secure device signs the transaction with its embedded private key and sends the partially signed transaction along with a fingerprint scan to a server. The second private key is stored server-side and if the fingerprint scan is a match, the server countersigns the transaction with the second private key and broadcasts a multi-signed transaction to a cryptocurrency network, such as the Bitcoin network.)
One of ordinary skill in the art would have recognized that applying the known technique of Dvorak to the known invention of Nolan would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate key pairs features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the method to include creating, by a client, k out of n public-private key pairs for a multi-signature smart wallet wherein k is a required threshold number of public-private key pairs to process the multi-signature smart contract and n is the total number of public-private key pairs result in an improved invention because applying said technique will ensures that there must be a keypair to authorize transactions so that one key cannot finalize transactions, thus improving the overall security of the invention.
Nolan as modified does not explicitly disclose registering the multi-signature smart wallet in an MPT to record a state of the multi-sig smart wallet.
However, Chan teaches registering the multi-signature smart wallet in an MPT to record a state of the multi-sig smart wallet, (Column 2/line 43, In some additional examples, storing the original work data in a blockchain involves storing the original work data in a data structure that includes at least one of a Merkle tree, a Patricia trie, or a modified Merkle Patricia trie and storing the data structure in the blockchain.; and Column 3/line 26, FIG. 2C is a data architecture diagram showing still another illustrative example of a derivative work data blockchain where the original work data is stored in a Merkle Patricia trie in the original work data block and each derivative work data block on the blockchain identifies a key to an element of the original work data utilized in a derivative work along with an identifier for a source of the derivative work and an identifier for a source that identified and submitted the derivative work data; and Claim 5. where the step of storing the original work data in a blockchain comprises: storing the original work data in a data structure that includes at least one of a Merkle tree, a Patricia trie, or a modified Merkle Patricia trie; and storing the data structure in the blockchain.)
One of ordinary skill in the art would have recognized that applying the known technique of Chan to the known invention of Nolan as modified would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate mpt features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the method and system to include registering the multi-signature smart wallet in an MPT to record a state of the multi-sig smart wallet result in an improved invention because applying said technique will allow the registering process to be quicker and more efficient with in a mpt to prevent unauthorized users and tampering with user’s wallets, thus improving the overall security of the invention.
8. Regarding claim 2, Nolan discloses further comprising: responsive to validating the shared signature utilizing public keys of the two or more users and the approved proposal id equals the proposal id for the multi-signature smart wallet, adding the shared signature to a reconstructed multi-signature context utilizing a public key of the multi-signature smart wallet, (Para 0411, Example 76 includes the subject matter of either of example 74 or 75. In this example, the method includes signing a received approval request to create a multi-signed approval request, determining that M of N e-wallet shares have signed, and returning the multi-signed approval request to the originating e-wallet share.; and Para. 0429, Example 94 includes a non-transitory, machine readable medium. The non-transitory, machine readable medium includes code that, when executed, directs a processor to circulate a transaction approval request to e-wallet shares for signing, and complete the transaction if M of N e-wallet shares have signed the transaction approval request.; and Para. 0217, FIG. 23 is a process flow diagram of a method 2300 for wallet signing authorization using an M of N policy, in accordance with some examples. The method 2300 begins at block 2302, when a private key (Kw1), for example, an EPID key, for an e-wallet (W1) is created with N e-wallet shares. At block 2304, an M of N threshold authorization policy is created for W1. At block 2306, an authorization signing key pair is generated for each share in W1. Public keys are distributed to all shares. At block 2308, the public key for W1 is disclosed to a blockchain that performs transactions using an e-wallet.; and Para. 0427, Example 92 includes the subject matter of any of examples 74 to 91. In this example, the method includes identifying parameters to allow an escrowed key to be reconstituted if an event occurs, dividing an e-wallet key into e-wallet key shares, and encrypting the e-wallet key shares to each of a plurality of e-wallet shares). Examiner interprets the term smart contract is analogous for the term identifying parameters, threshold authorization policy, and machine readable medium includes code that, when executed, directs a processor to circulate a transaction approval request in the cited prior art.
Nolan does not explicitly disclose validating and finalizing the transaction when the received signatures are at least the threshold number.
However, Dvorak teaches validating and finalizing the transaction when the received signatures are at least the threshold number, (Para. 0013, Each key storage location may be secured using a distinct authentication factor. In one embodiment, the cryptocurrency virtual wallet system and method may require N keys out of M keys for completion of a transaction or action where N<=M. In one embodiment, two out of three keys can be used for completion of a transaction or action. Thus, even if the server is compromised, or the secure device is lost, only one of the three private encryption keys is compromised.; and Para. 0021, A benefit of embodiments of the cryptocurrency virtual wallet system and method includes the embedding of a first private key in the secure device itself without any logic in the secure device to transmit the first private key so that the first private key is protected by the possession factor. Without having possession of the secure device, there is no way for a third party to obtain the first private key. When you swipe your finger to confirm a transaction, the secure device signs the transaction with its embedded private key and sends the partially signed transaction along with a fingerprint scan to a server. The second private key is stored server-side and if the fingerprint scan is a match, the server countersigns the transaction with the second private key and broadcasts a multi-signed transaction to a cryptocurrency network, such as the Bitcoin network.
One of ordinary skill in the art would have recognized that applying the known technique of Dvorak to the known invention of Nolan would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate threshold features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the method to include validating and finalizing the transaction when the received signatures are at least the threshold number result in an improved invention because applying said technique will ensures that transactions are only finalized and validated when enough signatures are obtained, thus improving the overall performance of the invention.
9. Regarding claims 3 and 8, Nolan discloses wherein the smart contract is initialized with a plurality of multi-signature wallet proposals, (Para. 0025-0026, FIG. 22 is a schematic diagram of a wallet signing authorization using an M of N policy, in accordance with some examples. FIG. 23 is a process flow diagram of a method for wallet signing authorization using an M of N policy, in accordance with some examples.; and Para. 0209, FIG. 22 is a schematic diagram of a wallet signing authorization 2200 using an M of N policy, in accordance with some examples. E-wallet share devices may be headed or headless. Headed devices may require additional user logins and approval dialogs, which may further strengthen a determination of a user intent to use the wallet. Headless share devices may participate in the M of N signature scheme so that an attacker will be required to physically compromise additional devices in order to reach the M threshold of approvers.; and Para. 0217, FIG. 23 is a process flow diagram of a method 2300 for wallet signing authorization using an M of N policy, in accordance with some examples. The method 2300 begins at block 2302, when a private key (Kw1), for example, an EPID key, for an e-wallet (W1) is created with N e-wallet shares. At block 2304, an M of N threshold authorization policy is created for W1. At block 2306, an authorization signing key pair is generated for each share in W1. Public keys are distributed to all shares. At block 2308, the public key for W1 is disclosed to a blockchain that performs transactions using an e-wallet.; and Para. 0429, Example 94 includes a non-transitory, machine readable medium. The non-transitory, machine readable medium includes code that, when executed, directs a processor to circulate a transaction approval request to e-wallet shares for signing, and complete the transaction if M of N e-wallet shares have signed the transaction approval request.; and Para. 0427, Example 92 includes the subject matter of any of examples 74 to 91. In this example, the method includes identifying parameters to allow an escrowed key to be reconstituted if an event occurs, dividing an e-wallet key into e-wallet key shares, and encrypting the e-wallet key shares to each of a plurality of e-wallet shares). Examiner interprets the term smart contract is analogous for the term identifying parameters, threshold authorization policy, and machine readable medium includes code that, when executed, directs a processor to circulate a transaction approval request in the cited prior art.
Regarding claims 4 and 9, Nolan discloses wherein the plurality of multi-signature wallet proposals contains a first proposal tailored for a first initiator and a second proposal tailored for a second initiator and the first proposal is different from the second proposal, (Para. 0417-0422, Example 82 includes the subject matter of example 81. In this example, the method includes creating an EPID share key for the e-wallet share. Example 83 includes the subject matter of either of examples 81 or 82. In this example, the method includes generating a symmetric key, producing a shared secret to divide the symmetric key into key shares, distributing a key share to an e-wallet share, and erasing the symmetric key. Example 84 includes the subject matter of example 83. In this example, the method includes encrypting the first key portion using the key share to form an escrow key, and removing an unencrypted first key portion. Example 85 includes the subject matter of example 84. In this example, the method includes receiving the approval request, signing the approval request to form a signed approval request, and replying with the escrow key and the signed approval request. Example 86 includes the subject matter of example 85. In this example, the method includes reconstituting the symmetric key, reconstituting the encrypted first key portion, decrypting the first key portion using the symmetric key, appending the first key portion and the second key portion to reform the EPID private key, and signing the transaction with the EPID private key. Example 87 includes the subject matter of any of examples 74 to 86. In this example, the method includes receiving votes from devices hosting e-wallet shares to elect a lead device to perform a transaction, and initiating the transaction from the lead device, if M of N devices have selected the lead device.; and Para. Para. 0429, Example 94 includes a non-transitory, machine readable medium. The non-transitory, machine readable medium includes code that, when executed, directs a processor to circulate a transaction approval request to e-wallet shares for signing, and complete the transaction if M of N e-wallet shares have signed the transaction approval request).
Regarding claims 5 and 10, Nolan discloses further comprising: preventing initiating a new multi-signature wallet transaction with a new proposal id when the new proposal id was previously created, (Para. 0402-0401, Example 66 includes the subject matter of 65. In this example, the subsequent device comprises a subsequent transaction signer to sign the approval request and determine if the M of N policy has been met, and a subsequent e-wallet app configured to send the approval request to the anonymizing router to be returned to the first device. Example 67 includes the subject matter of either of example 65 or 66. In this example, the apparatus includes a blacklist comprising a signature for a lost or stolen device. The e-wallet app is configured to check the signatures on the approval request against the blacklist. If a signature for a blacklisted device is detected, the e-wallet app is configured to return an unsigned approval request to the anonymizing router.)
12. Regarding claims 6 and 11, Nolan discloses further comprising: preventing execution of an expired proposal, (Para. 0422-0427, Example 87 includes the subject matter of any of examples 74 to 86. In this example, the method includes receiving votes from devices hosting e-wallet shares to elect a lead device to perform a transaction, and initiating the transaction from the lead device, if M of N devices have selected the lead device. Example 88 includes the subject matter of example 87. In this example, the method includes starting a timer after the lead device is elected, and voiding the transaction if the lead device does not complete the transaction before the timer expires. Example 89 includes the subject matter of any of examples 74 to 88. In this example, the method includes receiving votes from devices hosting e-wallet shares to ban a device from participating in transactions, and banning the device, if M of N devices have voted to ban the device. Example 90 includes the subject matter of example 89. In this example, the method includes starting a timer after votes are received to ban the device, and voiding the vote if M of N devices have not responded before the timer expires. Example 91 includes the subject matter of any of examples 74 to 90. In this example, the method includes placing a cap on an amount a device can spend within a set time period. Example 92 includes the subject matter of any of examples 74 to 91. In this example, the method includes identifying parameters to allow an escrowed key to be reconstituted if an event occurs, dividing an e-wallet key into e-wallet key shares, and encrypting the e-wallet key shares to each of a plurality of e-wallet shares.)
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Methods and apparatus for providing attestation of information using a centralized or distributed ledger (US 20170317833 A1) teaches methods and apparatus for providing authentication of information of a user are described. Upon validation of this information, a first hash function is applied to the user's information to create a hash. A public attest key is generated by combining the hash of the user's information with one or more public keys. An attestation address is generated based on the public attest key. A signed transaction which includes the attest key is communicated for storage in a centralized or distributed ledger at the attestation address.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Davida L. King whose telephone number is (571) 272-4724. The examiner can normally be reached M-F 8am-5pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Neha Patel can be reached on (571) 270-1492. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/D.L.K./Examiner, Art Unit 3699
/NEHA PATEL/Supervisory Patent Examiner, Art Unit 3699