Detailed Action
Claims 1-5, 8-10, 12-19, 22-24 and 26-35 are pending and are examined.
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 .
Status of Claims
Claims 1, 15, 29, and 34 are currently amended.
Response to Remarks
35 U.S.C. § 103
Remark 1: Applicant argues “ Claim 1 is amended to recite that "m is at least two and n is greater than m (emphasis added). There is support of this amendment in the specification as filed, for example at [007] and [041]. Prior to the amendment, claim 1 already recited that "the n private keys are each created and owned by a single user, each private key being associated with a unique address, being stored on a separate device and/or application, and being associated with the MFA smart contract wallet." Claim 1 also already recited the multi-factor authentication (MFA) smart contract wallet includes an MFA rule requiring "receipt of separate approvals signed by a number m of the plurality of n private keys created and owned by a single user, each private key being associated with a unique address, being stored on a separate device and/or application, and being associated with the MFA smart contract wallet, prior to execution of a corresponding single, specific blockchain transaction. As amended, in claim 1 n (the total number of private keys) is greater than m (the number of signed requests received). In other words, the multi-factor authentication (MFA) smart contract wallet includes an MFA rule that specifies that that signed requests from a subset (m) of the total number (n) private keys is utilized to trigger required to approve and trigger execution of a corresponding single, specific blockchain transaction. Thus, the multi-factor authentication wallet is implemented as an "m of n" wallet, but instead of a different individual user controlling each of the n keys, a single person controls the different keys which are stored on different devices and/or applications, and the total number of private keys is greater then the number of signatures required to execute a blockchain transaction. As discussed in the last response, Black generally describes verifying customer data
received from a customer device to restore a customer wallet. When the customer is verified, a request for a key associated with the wallet is made to a key repository of a trusted third party. The customer wallet can be restored using a first and second key associated with the customer wallet [Abstract, [0007]. Black does describe requiring M of N keys to use the wallet, in which multiple private keys are distributed between multiple separate entities, such as "three private keys may be generated and distributed among various devices within a multi-sig system: (1) a first key held by a customer (end user); (2) a second key held by a currency conversion system (e.g., a money services business (MSB)) or exchange; and (3) a third key held by a trusted third party (such as a credit union or bank)." [0043]. Nothing in Black discloses or suggests that N is greater than M. The Office admits that Black does not disclose that the multiple private keys are not "created and owned by a single user" as claim 1 recites. The Office also admits that Black does not disclose that "wherein the MFA smart contract wallet includes an MFA rule requiring receipt of separate approvals signed by a number m of the plurality of n private keys created and owned by a single user, each private key being associated with a unique address, being stored on a separate device and/or application, and being associated with the MFA smart contract wallet, prior to execution of a corresponding single, specific blockchain transaction" as claim 1 recites.
Instead, the Office states that Basu teaches these pre-amendment limitations. Basu Describes Split Key Authentication and Password-Less Logon to SSO. Basu describes two separate functionalities. One functionality is a split key authentication and password-less logon to SSO (single-sign on) servers. Basu describes this functionality in detail from [0370] to [0380], and illustrates it in Figures 10 and 11. In this functionality, the single private key of a given user is split into two partial private keys. Actual login to the SSO server requires a signature based on the full private key, but this is created using two partial signatures, on made by each partial key. One partial key is stored on the user's computer, and the other on the user's mobile device. This is for added security, so that if one device becomes compromised, the full key is still not compromised. As Basu describes this procedure: [a] split key based signature scheme is used that requires two separate signatures from two split keys (of the primary key) to create the combined signature. These partial signatures are constructed on two separate devices to enhance the security. Compromise of one key doesn't result in the compromise of the primary key ([0374]). In order to log on to an SSO server in Basu, a challenge is used when the user tries to login, which can be met by supplying a single signature made up of two partial key signatures, one partial key stored on the user's desktop and the other stored on the user's mobile device. Although the distribution of the single key into multiple partial keys across multiple devices provides a degree of security in case one device is compromised, ultimately the partial signatures need to be combined to create a full signature based on the whole key, which must match the single public key for the challenge to be met and the operation to be approved. As Basu puts it: The desktop will sign the challenge partial key and send the signature to the mobile....The mobile will sign the challenge with its own partial key, combine the signatures and respond back to the blockchain IDP server along with the primary public key...The blockchain IDP server confirms that the signature is valid with respect to the public key ([0375]); See also Figure 10 (illustrating combining two partial signatures into one full signature and using that to complete the password- less logon). In other words, a single signature by a primary (whole) private key is created by combining the two partial keys, to allow a user to more securely login to an SSO server without supplying a password. This technique requires that both of the key segments be used to create the whole key, which is then used to sign the login request. Basu does discuss the possibility of dividing the whole key into more than two segments and distributing the multiple segments to more than two separate devices: "split the private key of the client into two or more parts...assign the split private key part to two or more client devices...signing to authenticate a challenge using a partial key part at one of the client devices...send the challenge to the remaining client devices who sequentially sign" ([0380]; Figure 11). But no matter how many segments the private key is split into, all of them need to be used to engage in the transaction. If the private key is divided into two partial keys, two partial signatures that are combined into a single full signature are necessary to verify the user. If the private key is divided into ten segments, all ten partial signatures must be combined to create the same full signature. The other, separate functionality described by Basu is a conventional multi-signature wallet, which requires a given number of votes from different users before executing a blockchain transaction.. Each vote is associated with its own signature. Basu describes this functionality in detail from [0357] to [0369], and illustrates it in Figures 8 and 9. This is conventional m of n authentication (Basu calls it "t of n"). Nothing in Basu suggests that the multiple voters are the same user, or that each separate voter's signature is created by a single user. Instead, the multi-signature wallet described in Basu is a conventional m of n wallet that is like the one in Black, in which the n private keys are generated by and managed by separate users/entities. Note that the split signature password-less login and the multiple signature wallet are separate features of Basu. Nothing in Basu suggests combining them. The split signature password-less login is used to login to SSO servers ([0370]- [0380]; Figures 10 and 11), whereas the multi-signature wallet is used to implement multi-user voting to approve blockchain transaction ([0357]-[0369]; Figures 8 and 9). As described in detail below in the section on the hypothetical combination of the references, these two features are not interchangeable or usefully combinable. Basu does not teach that the "the plurality of n private keys associated with the MFA smart contract wallet are created and owned by a single user" as claim 1 recites The Office states that Basu teaches this limitation, based on Basu's discussion of the splitting of a single private key into two partial keys and storing them on separate client devices as part of the split key password-less login functionality described above. However, even
assuming for the sake of discussion that each fragment of the split private key is itself a separate private key (which it is not), Basu would still be silent on the plurality of n keys associated with the smart contract wallet being created and owned by a single user. Bau's split keys are not associated with the smart contract wallet, but are instead used for password fee login to an SSO server. The multi-user smart contract wallet in Basu uses multiple keys owned and maintained by separate voting users, as described above. Basu does not teach that "the MFA smart contract wallet includes an MFA rule requiring receipt of separate approvals signed by a number m of the plurality of n private keys created and owned by a single user, each private kev being associated with a unique address, being stored on a separate device and/or application, and being associated with the MFA smart contract wallet, prior to execution of a corresponding single, specific blockchain transaction" as claim 1 recites. The Office states that Basu teaches this limitation, based on Basu's conventional m of n wallet functionality. By contrast, as explained above, the multi-user smart contract wallet in Basu uses multiple keys owned and maintained by separate voting users. In fact, Basu in its entirely is silent on multi-factor authentication (MFA) rules, much less a an MFA rule requiring receipt of separate approvals signed by a number m of the plurality of n private keys created and owned by a single user, each private kev being associated with a unique address, being stored on a separate device and/or application, and being associated with the MFA smart contract wallet, prior to execution of a corresponding single, specific blockchain transaction." As explained above, the separate split key fragments in Basu are not associated with the smart contract wallet or used for multiple factor authentication for blockchain transactions, but are instead used for password fee login to an SSO server. Basu does not teach that the number of private keys is greater than the number of signatures. As explained above, in the split key password-less sign on of Basu, every private key segment must be used. No matter how many segments the private key is split into, all of them need to be used to engage in the transaction. If the private key is divided into two partial keys, two partial signatures that are combined into a single full signature are necessary to verify the user. If the private key is divided into ten segments, all ten partial signatures must be combined to create the same full signature. Thus, assuming for the sake of discussion only that the separate key segments are each private keys (which they are not), the number of private keys need to execute a transaction (m) would still have to be exactly equal to the total number of private keys in existence (n). Thus, Basu does not teach "where n is greater than m" as amended claim 1 recites. Black is also silent on this limitation. The Hypothetical Combination of Black with Basu would still fail to teach or suggest the limitations at issue. Black describes a conventional m of n wallet in which the multiple private keys used to approve a blockchain transaction are owned and maintained by separate users. Basu describes also describes a conventional m of n system in which the multiple private keys used to approve a blockchain transaction. These multiple private keys are owned and maintained by separate users (called voters in Basu) in the manner of Black. Basu also describes splitting a single key owned by one user in two, and storing the two key fragments on the user's computer and mobile device. When logging onto an SSO server, rather than requiring a password, the two key fragments are automatically retrieved, combined, and used to log the user on to the server. Combining the split key password-free login of Basu with the conventional m of n wallets in Black and Basu would, at best, result only in a system that combines split-key password free logon to an SSO server with conventional m of n wallet functionality, in which n separate users maintain n separate private keys, and m of them have to approve a block chain transaction using their separate key before the blockchain transaction executes. Note that the split key functionality used in Basu to automatically logon to an SSO server would not work to approve a multi-signature wallet blockchain transaction. The split key functionality of Basu does not require separate signatures each separately approved by the key owner, but instead automates the process of logging in to an SSO server by automatically using two separate key fragments to produce one full signature. If a multi-signature wallet that required separate signatures from m of n key holders utilized the split key functionality of Basu, the resulting system would have a number of serious deficiencies (to the extent that it would work at all), and would still not provide or suggest the functionality of Applicant's claims. First, the signature owner or owners would not be able to approve or reject the proposed transaction, as the split-key process is automatic and transparent to the user (the browser automatically executes a partial sign and sends the challenge to the mobile device which then automatically executes a partial sign and combines the two partial signatures (see, e.g., Figure 10). The whole point of the password free login is to automate the single sign on process for the user to avoid the burden of having to maintain and enter a password, while still preserving some security: the value proposition for this approach is a higher security and an easier password-less login flow...Enterprises already use SSO to make it easy for their employees to login to their various internal application that each require login. Existing solutions rely on password based authentication. And some require changing the password every few weeks or months. Some even prevent reusing the previous 10 passwords, making it extremely painful to employees. While this improves the security, it imposes unnecessary burden on the employees (Basu [0371]-[0372]). By contrast, automatically signing and sending multiple requests to execute a multi authentication factor blockchain transaction transparently to the user(s) would defeat the whole security proposition of requiring separate signed requests to execute the transaction. Although the split key functionality works to save the user the bother of having to login to a server, it would not work in the context of MFA wallets/blockchain transactions which are based on actively signing each request to execute the blockchain transaction for security. Secondly, all of the signature fragments from the split key functionality would still need to be utilized to create a single full signature. Thus, the multi-signature wallet would not be a multi-signature wallet at all, but instead a single signature wallet in which the single signature is created from all of the partial signatures. Once again, this defeats a key advantage of MFA wallets/blockchain transactions. Finally, because all of the partial signatures are required to create the single full signature and authorize an action (e.g., signing into the SSO server), it would not be possible for m to be less than n, as claimed. Instead, m must be equal to n. Thus, the hypothetical combination would still fail to teach at least the limitations that the Office admits are not disclosed by Black, and would further fail to teach or suggest "m is at least two and n is greater than m," as amended claim 1 now recites. The Office gives two motivations to combine Black with Basu. First, the Office cites "the incentives of reducing third-party custody risk while retaining multi-approval security provided a reason to make the adaptation" (FOA, p. 9). Secondly, the Offices cites "the incentives of device separation, two-factor/multi-factor usability, and predicable address-key mapping via distinct public keys provided a reason to make a adaptation" (p. 10). Thus, the first given motivation to combine Black with Basu is that the results would reduce "third party risk while retaining multi-approval security," and that the combination would thus be useful. Although Basu describes that the split-key password-less login functionality reduces the risk that a third party could comprise the whole key because it is split into multiple pieces, nothing in either reference suggests that this functionality could be combined with Black to "retain multi-approval security" at the level of multi-factor wallet authentication. Instead, as explained above, combining the split key password-free login of Basu with the conventional m of n wallet in Black would only result in a system that combines split-key password free logon to an SSO server with conventional m of n wallet functionality, in which n separate users maintain n separate private keys, and m of them have to approve a block chain transaction using their separate key before the blockchain transaction executes. For the reasons explained above, the split key functionality used in Basu to automatically logon to an SSO server would not work to securely approve a multi-signature wallet blockchain transaction, and thus there is no incentive to combine the references to "retain multi-approval security with split-keys." The other given motivation to combine Black with Basu is that the results would be maintain "device separation, two-factor/multi-factor usability, and predicable address-key mapping via distinct public keys," and thus the combination would be useful. Once again, Basu does describe that the split-key password-less login functionality creates device separation. In addition, the conventional m of n multi-user authentication of Black uses multiple devices. Since both references use separate devices, device separation cannot be a motivation to combine them. As for "two-factor/multi-factor usability," the split key functionality in Basu provides combining two fragments of a key to login to a server without using a password. That could be described as a type of "two-factor/multi-factor usability." The conventional MFA wallet of Black requires multiple signatures to execute a blockchain transaction. This could also be described as a different type of "two-factor/multi-factor usability." There is no motivation to combine these different types of "two-factor/multi-factor usability," and as explained above, the m of n type wallet and authentication used in Black is not compatible with the split key functionality used in Basu, nor would the hypothetical result be useful. Finally, the Office cites "predicable address- key mapping via distinct public keys." Only the m of n functionality of Black uses distinct public keys. The split key functionality of Basu uses a single public key that matches the whole private key created by combining the private key fragments. As for predictable address key mapping, in both references each key is mapped to an address, and nothing in the hypothetical combination would create any advantage over the separate references in the mapping of keys to addresses, nor does the Office explain how this would be an incentive for combination.” (id.)
Response to Remark 1: Examiner respectfully disagrees, as the currently cited references (e.g. Black and Basu) do teach the amended independent claims as shown at least in paragraphs 124 and 216 of Black, paragraphs 358, 361, and 364 of Basu, and as further outlined in paragraphs 11-20 of this action. (id). Indeed, applicants arguments are not persuasive, as Black teaches the amended m-of-n relationship because the multi-approval condition may require two private keys associated with three public transaction keys to transact from the multi-approval transaction address. Although Black’s preferred embodiment may distribute keys among different entities, Basu teaches the missing single-user/multi-device aspect by disclosing a client/end-user with two or more computing devices and split-key authentication material assigned across those devices. Applicant’s attempt to treat Basu’s split-key authentication and Basu’s smart-wallet multi-signature disclosure as non-combinable is unpersuasive because the rejection relies on Basu for its broader teachings of user-controlled multi-device cryptographic authentication and smart-wallet disclosure teaches T-of-N multi-signature approval, voter public keys, a minimum number of votes, and execution only after the required number of votes is collected. It would have been obvious to modify Black’s m-of-n wallet with Basu’s single-user, multi-device cryptographic authentication teachings to reduce third-party custody risk while retaining threshold transaction security. Accordingly, this contention is unpersuasive.
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 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.
Claim(s) 1-5, 8-10, 12-19, 22-24 and 26-35 are rejected under 35 U.S.C. 103 being unpatentable over Black et al. (US20190220852A1) (hereinafter “Black”) in view of Basu et al. (US20220173917A1) (hereinafter “Basu”)
As per Claim 1, 15, and 29, Black teaches:
A computer-implemented method executed by a multi-factor authentication (MFA) smart contract wallet for securing blockchain transactions, by enforcing MFA rules requiring a number m of separate blockchain transaction requests signed with separate ones of a plurality consisting of a number n total commonly owned private keys associated with the MFA smart contract wallet to authorize a corresponding single, specific blockchain transaction, the method comprising: receiving, by the MFA smart contract wallet, a proposed specific blockchain transaction request having a transaction value, call data and a recipient address, and being signed by a specific one of the plurality of n private keys associated with the MFA smart contract wallet (“The transaction request may indicate a type and quantity of cryptocurrency to be transferred, e.g., 0.15 Bitcoins. The transaction request may also indicate optional attributes, such as conditional triggering requirements, duration of the transaction request, etc. The transaction request may also include a transaction address for a destination wallet.” (Para. 0137); “The transaction request may be signed 708 based on the first private transaction key(s) 206 and the second private transaction key(s) 216. Specifically, the application on the customer device 102 may identify a multi-approval transaction addresses 530 with enough cryptocurrency to fill the transaction request.” (Para. 0138); “the customer device 102 may sign 812 the transaction request using the first private transaction key 206A stored at the customer device 102.” (Para. 0157)
wherein the n private keys are each . . .; (“A multi-party multi-signature (multi-sig) methodology may distribute a different private key (e.g., a unique string of numbers, letters, and/or other characters) to each of the customer device 102, the currency conversion system 104, and the trusted third party 106. Using multi-sig, any requested cryptocurrency purchase or transaction from the customer must be signed using M/N (e.g., two of three) private keys, e.g., signed by the customer device 102 and the currency conversion system 104.” (Para. 0050); “In examples, the private transaction key 206A stored at the customer device 102 and the private transaction key 216A stored at the currency conversion system 104 (and transferred to the customer device 102) may preferably be used to transact from the multi-approval transaction address 530.” (Para. 0125); “The public transaction key 207A may be used to derive a transaction addresses, monitor transactions for a transaction address, and/or view account balances (e.g., on a blockchain).” (Para. 0120)
wherein m is at least two and n is greater than two, (“the resulting multi-approval transaction address 530 is different than a typical transaction address because it requires M private keys (as specified by the multi-approval condition 529) associated with the N input public keys to transact from the multi-approval transaction address 530. In examples, the multi-approval condition 529 specifies that two private keys (e.g., two of the private transaction keys 206A, 216A, 226A) associated with the three public transaction keys 207A, 217A, 227A are required in order to transact from the multi-approval transaction address 530.” (Para. 0124); “a customer may require 2 out of 5 private keys (or key components) to perform an action in the personal account (e.g., (M=2)<(N=5)).” (Para. 0216); “M/N (e.g., two of three) private keys.” (Para. 0050); “that two private keys (e.g., two of the private transaction keys 206A, 216A, 226A) associated with the three public transaction keys 207A, 217A, 227A are required in order to transact from the multi-approval transaction address 530.” (Para. 0124); “The multi-approval transaction address 530 may require private keys, associated with the at least M (e.g., two) of first public key, the second public key, and the third public key, to transact from the multi-approval transaction address 530.” (Para. 0134)
receiving, by the MFA smart contract wallet, separate approvals of the proposed blockchain transaction signed by at least m minus one of the n private keys each being . . ., each private key being associated with a unique address, being stored on a separate device and/or application, and being associated with the MFA smart contract wallet; and (“In the method 800C, the customer device 102 may sign 812 the transaction request using the first private transaction key 206A stored at the customer device 102. The customer device 102 may send 814 the partially signed transaction request to the currency conversion system 104. The currency conversion system 104 may sign 816 the transaction request using the second private transaction key 216A stored at the currency conversion system 104. The currency conversion system 104 may transmit 818 the fully signed transaction request to the customer device 102.” (Para. 0157); “the currency conversion system 104 may send 826 the partially signed transaction request back to the customer device 102. The customer device 102 may sign 828 the transaction request using the first private transaction key 206A stored at the customer device 102.” (Para. 0158); “the application may then input a first private transaction key 206 and a second private transaction key 216 for each identified multi-approval transaction address 530 into a redeem script (e.g., redeemScript according to BIP16) in order to transact from the respective multi-approval transaction address 530.” (Para. 0138)
executing, responsive to satisfaction of the MFA rule, a multi-factor authenticated blockchain transaction request signed by a unique private key of the MFA smart contract wallet, the multi-factor authenticated blockchain transaction request corresponding to the proposed specific blockchain transaction request. (“To initiate a cryptocurrency transaction, the customer may open 714 an application on the customer device 102 using authentication data. In examples, the authentication data may include biometric data, e.g., the customer placing a finger on a fingerprint reader, pointing a camera at their face, pointing a camera at their eye, or speaking into a microphone. In examples, the application may open only if the biometric data matches the biometric data uploaded during onboarding. Alternatively, the authentication data may be a password, or a combination of biometric data and a password. Once the user has gained access to the application, the customer may create 716 a transaction request in the application.” (Para. 0142); “In examples, a first private account key 214A and a first public account key 215A may be maintained for a first customer, while a second private account key 214B and a second public account key 215B may be maintained for a second customer. Alternatively, the first private account key 214A and the first public account key 215A may be maintained for a first type of cryptocurrency held in a customer wallet, while the second private account key 214B and the second public account key 215B may be maintained for a second type of cryptocurrency held in the same customer wallet. The first type and the second type may be selected from among Bitcoin, Ethereum, Litecoin, etc.” (Para. 0081); “FIG. 2C is a block diagram illustrating another example node tree 200C on the trusted third party 106 for implementing a customer wallet. In examples, the node tree 200C may implement one or more HD wallet(s) for one or more customers according to portions of BIP32 and/or portions of BIP44.” (Para. 0091).
Black does not disclose:
• “created and owned by a single user” (claim 1).
However, as per Claim 1, Basu the analogous art of tokenized transactions, teaches: “created and owned by a single user”. (See “A client is an end-user with two or more computing devices who initiates the requests and wants to commit transactions on the blockchain platform.” (Para. 0033); “In the example of FIG. 1, the environment includes a first consumer or client system 110-1 through an nth client system 110-n wherein each client owns two or more devices 1, 2, 3, . . . n,.” (Para. 0035); “A system and method of blockchain platform for authenticating clients, comprising of: creating a public and private key at a client device; splitting the private key into two or more parts; assigning the split private key part to two or more client devices.” (Para. 0020))
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Black, teaching multi-approver wallet security and explaining that limiting access to a single entity is undesirable, with the technique of Basu, teaching a client/end-user controls two or more devices and authenticates using split keys, to include a wallet in which the plurality of keys are created and owned by single user across that users multiple devices. Therefore, the incentives of reducing third-party custody risk while retaining multi-approval security provided a reason to make the adaptation, and the invention resulted from application of prior knowledge in a predictable manner.
Black does not disclose:
• “each private key being associated with a unique address, being stored on a separate device and/or application, and being associated with the MFA smart contract wallet” (claim 1).
However, as per Claim 1, Basu the analogous art of tokenized transactions, teaches: “each private key being associated with a unique address, being stored on a separate device and/or application, and being associated with the MFA smart contract wallet”. (See “Allow creation of a multiple signature wallet context for a wallet. The transaction containing this request must be send from the target wallet's client. It must include a list of voter public keys and the minimum number of votes that must be collected before funds may be sent from the wallet.” – each public key providing a unique on-chain address (Para. 0361); “The client may use a multiple signatures or group-based smart-contract or smart-wallet on the blockchain platform. The client may use passwordless authentication using split keys that are associated with two or more client devices.” (Para. 0035); “assigning the split private key part to two or more client devices; signing to authenticate a challenge using a partial key part at one of the client devices; sending the challenge to the remaining client devices.” (Para. 0020))
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Black with Basu’s technique of splitting/assigning keys to two or more client devices of the same user, and configuring a multi-signature smart wallet that identifies signers by their public keys and enforces a minimum number of votes, thereby yielding n user-owned keys on separate devices/apps, each identified by a distinct public key, all associated with the user’s smart contract wallet. Therefore, the incentives of device separation, two-factor/multi-factor usability, and predicable address-key mapping via distinct public keys provided a reason to make a adaptation, and the invention resulted from application of prior knowledge in a predictable manner.
Black does not disclose:
• “wherein the MFA smart contract wallet includes an MFA rule requiring receipt of separate approvals signed by a number m of the plurality of n private keys . . ., each private key being associated with a unique address, being stored on a separate device and/or application, and being associated with the MFA smart contract wallet prior to execution of a corresponding single, specific blockchain transaction” (claim 1).
However, as per Claim 1, Basu the analogous art of tokenized transactions, teaches: “wherein the MFA smart contract wallet includes an MFA rule requiring receipt of separate approvals signed by a number m of the plurality of n private keys . . ., each private key being associated with a unique address, being stored on a separate device and/or application, and being associated with the MFA smart contract wallet prior to execution of a corresponding single, specific blockchain transaction”. (See “Users can add T-of-N multi-sig capabilities to standard MPT wallets. Votes to send tokens must arrive one-per-transaction and are stored in public blockchain state.” – m-of-n threshold with per-transaction approvals (Para. 0358); “It must include a list of voter public keys and the minimum number of votes that must be collected before funds may be sent from the wallet.” – pre-execution threshold (Para. 0361); “Any implementation has to consider the following before finalizing transactions on the smart wallet: querying whether multi-signature capabilities already exist; updating the list of signers and/or required number of votes.” (Para. 0360))
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Black with Basu’s technique that adds T-of-N multi-sig to a smart wallet and executes a transfer only after the required number of votes is collected, thereby encoding an MFA rule that gates execution of a specific blockchain transaction of m-of-n approvals from the users multiple keys. Therefore, the incentives of improving transaction integrity through threshold approval and aligning wallet behavior with well-understood multi-sig semantics provided a reason to make the adaptation, and the invention resulted from application of prior knowledge in a predictable manner.
As per Claim 2, 16, and 30, Black teaches:
The method of claim 1, wherein the transaction value, the call data and the recipient address are received at a separate device and/or an application corresponding to each one the one of the n commonly owned private keys associated with the MFA smart contract wallet, prior to submitting the responsive blockchain transaction requests from the m approving ones of the externally owned accounts. (“the customer may create 706 a transaction request in the application.” (Para. 0136); “The transaction request may indicate a type and quantity of cryptocurrency to be transferred, e.g., 0.15 Bitcoins. The transaction request may also indicate optional attributes, such as conditional triggering requirements, duration of the transaction request, etc. The transaction request may also include a transaction address for a destination wallet where the cryptocurrency is to be transferred.” (Para. 0137); “The customer device 102 may send 814 the partially signed transaction request to the currency conversion system 104. The currency conversion system 104 may sign 816 the transaction request using the second private transaction key 216A stored at the currency conversion system 104.” (Para. 0157); (“To initiate a cryptocurrency transaction, the customer may open 704 an application on the customer device 102 using authentication data. In examples, the authentication data may include biometric data, e.g., the customer placing a finger on a fingerprint reader, pointing a camera at their face, pointing a camera at their eye, or speaking into a microphone. In examples, the application may open (or allow particular access) only if the biometric data matches the biometric data uploaded during onboarding. Alternatively, the authentication data may be a password, or a combination of biometric data and a password. Once the user has gained access to the application, the customer may create 706 a transaction request in the application.” (Para. 0136); “The system 100 may use a multi-approval methodology, e.g., multi-party multi-signature (multi-sig) methodology, a multi-party key splitting methodology, or a combination of the two. A multi-party multi-signature (multi-sig) methodology may distribute a different private key (e.g., a unique string of numbers, letters, and/or other characters) to each of the customer device 102, the currency conversion system 104, and the trusted third party 106. Using multi-sig, any requested cryptocurrency purchase or transaction from the customer must be signed using M/N (e.g., two of three) private keys, e.g., signed by the customer device 102 and the currency conversion system 104. The private keys may be generated at the customer device 102, the currency conversion system 104, the trusted third party 106, or some combination. Multi-sig methodology does not require private keys to be split.” (Para. 0050); “FIG. 1 is a block diagram illustrating an example system 100 for multi-approval cryptocurrency accounts and transactions. The system 100 may include a customer device 102, a currency conversion system 104, a trusted third party 106, an optional asset exchange 108, an optional identify services provider 110, and a distributed ledger 118. Additionally, the system 100 may include more than one of each device.” (Para. 0047)
As per Claim 3 and 31, Black teaches:
The method of claim 1, further comprising in response to receipt by the MFA smart contract wallet of the proposed specific blockchain transaction request signed by the specific one of the plurality of n private keys associated with a unique address, sending a notification, by the MFA smart contract wallet, to others of the unique addresses associated with others of the n private keys, the notification indicating that the specific blockchain transaction request having the transaction value, the call data and the recipient address has been proposed, and requesting an approval or rejection of the proposed blockchain transaction. (“The trusted third party 106 may receive information from the currency conversion system 104 about transactions requested by the customer device 102. Alternatively, the trusted third party 106 may receive information relating to requested transactions directly from the customer device 102. In either case, the information received at the trusted third party 106 may indicate that a pending transaction needs to be signed (e.g., authenticated) using a private key stored at the trusted third party 106.” (Para. 0062); “the currency conversion system 104 may also notify 412 the trusted third party 106 about the cryptocurrency purchase order, the custodial order, and/or a new transaction address in the customer wallet.” (Para. 0116); “the currency conversion system 104 may also record 1012 the transfer on a distributed ledger and notify the customer device 102 when the transfer has been successfully recorded.” (Para. 0194))
As per Claim 4 and 32, Black teaches:
The method of claim 1, using a notification service to push notifications to each one of the n separate devices and/or applications corresponding to commonly owned private keys, the pushed notifications concerning MFA smart contract wallet events, the events including proposed blockchain transaction requests received by the MFA smart contract wallet. (“keys and/or key components can be electronically distributed to the devices using at least one of email, Short Message Service (SMS), Multimedia Messaging Service (MMS), instant messaging, push notification (such as a push verify notification), by polling (or pulling) a notification.” (Para. 0045); “the currency conversion system 104 may also record 1012 the transfer on a distributed ledger and notify the customer device 102 when the transfer has been successfully recorded.” (Para. 0194); “the information received at the trusted third party 106 may indicate that a pending transaction needs to be signed (e.g., authenticated) using a private key stored at the trusted third party 106.” (Para. 0062))
As per Claim 5 and 33, Black teaches:
The method of claim 1, wherein there is a fixed period of time for receipt of separate approvals of the proposed blockchain transaction signed by the m minus one of the n private keys each being . . ., each private key being associated with a unique address, being stored on a separate device and/or application, and being associated with the MFA smart contract wallet to submit the responsive blockchain transaction requests. (“The transaction request may also indicate optional attributes, such as conditional triggering requirements, duration of the transaction request, etc.” (Para. 0143); “The cryptocurrency purchase order may also indicate optional attributes, such as a limit price, stop price, conditional triggering requirements, duration of the order, whether the order may be partially filled, etc.” (Para. 0112).
As per Claim 8 and 34, Black teaches:
The method of claim 1, wherein the n total number of unique private keys are associated with different computing devices. (“The private account key 204 may further be specific to a type of cryptocurrency, e.g., the customer device 102 may include a different private account key 204 for each type of cryptocurrency stored in a customer wallet. . . A customer wallet may be defined by the private account key 204 and/or other private account key(s)” (Para. 0068); “FIG. 2A is a block diagram illustrating an example node tree 200A on the customer device 102 for implementing a customer wallet.” (Para. 0067))
As per Claim 9 and 35, Black teaches:
The method of claim 1, wherein the n total number of unique private keys are associated with n different applications on one or more computing devices. (“Each of the customer device 102, the currency conversion system 104, the trusted third party 106, the asset exchange 108 and the identity services provider 110 may be implemented as any of a mobile computing device, such as a mobile phone, tablet computer, mobile media device, mobile gaming device, laptop computer, or vehicle-based computer, etc.; or a non-mobile computing device such as a dedicated terminal, a public terminal, a kiosk, a server, a cloud server, or a desktop computer.” (Para. 0048); “In examples, each of the customer device 102, the currency conversion system 104, and the trusted third party 106 may include at least one memory, at least one processor, at least one optional network interface, at least one optional display device, at least one optional input device, and at least one optional power source. Additionally, each of the customer device 102, the currency conversion system 104 and/or the trusted third party 106 may be implemented using multiple physical devices.” (Para. 0049); “The system 100 may use a multi-approval methodology, e.g., multi-party multi-signature (multi-sig) methodology, a multi-party key splitting methodology, or a combination of the two. A multi-party multi-signature (multi-sig) methodology may distribute a different private key (e.g., a unique string of numbers, letters, and/or other characters) to each of the customer device 102, the currency conversion system 104, and the trusted third party 106. Using multi-sig, any requested cryptocurrency purchase or transaction from the customer must be signed using M/N (e.g., two of three) private keys, e.g., signed by the customer device 102 and the currency conversion system 104. The private keys may be generated at the customer device 102, the currency conversion system 104, the trusted third party 106, or some combination. Multi-sig methodology does not require private keys to be split.” (Para. 0050)
As per Claim 10 and 24, Black teaches:
The method of claim 1, wherein the proposed blockchain transaction comprises sending cryptocurrency from the MFA smart contract wallet to a receiving wallet. (“The system 100 may use a multi-approval methodology, e.g., multi-party multi-signature (multi-sig) methodology, a multi-party key splitting methodology, or a combination of the two. A multi-party multi-signature (multi-sig) methodology may distribute a different private key (e.g., a unique string of numbers, letters, and/or other characters) to each of the customer device 102, the currency conversion system 104, and the trusted third party 106. Using multi-sig, any requested cryptocurrency purchase or transaction from the customer must be signed using M/N (e.g., two of three) private keys, e.g., signed by the customer device 102 and the currency conversion system 104. The private keys may be generated at the customer device 102, the currency conversion system 104, the trusted third party 106, or some combination. Multi-sig methodology does not require private keys to be split.” (Para. 0050); “To initiate a cryptocurrency transaction, the customer may open 704 an application on the customer device 102 using authentication data. In examples, the authentication data may include biometric data, e.g., the customer placing a finger on a fingerprint reader, pointing a camera at their face, pointing a camera at their eye, or speaking into a microphone. In examples, the application may open (or allow particular access) only if the biometric data matches the biometric data uploaded during onboarding. Alternatively, the authentication data may be a password, or a combination of biometric data and a password. Once the user has gained access to the application, the customer may create 706 a transaction request in the application” (Para. 0136); “During routine operation, private keys from both the customer (end user) and currency conversion system/exchange may be required to transact from a customer wallet, e.g., to transfer cryptocurrency from a transaction address. If the user were to lose their private key (such as by losing, breaking, or upgrading their device that contained the private key), private keys of the currency conversion system/exchange and the trusted third party (such as the credit union or bank) may be used to recover the wallet. When a wallet is recovered, new private keys (or private key components) may be generated for (1) the customer (end user); (2) the currency conversion system/exchange; and (3) the trusted third party (such as a credit union or bank).” (Para. 0046)
As per Claim 12, Black teaches:
The method of claim 1, wherein at least one of the private keys being created and owned by the single user is stored in a wallet of the single user. (“The node tree 200A may reside on the customer device 102 and may include a hierarchy of levels. Specifically, the node tree 200A may include a private account key 204 and a public account key 205 in the first level (L1). The private account key 204 may be a unique string of numbers, letters, and/or other characters that is specific to a customer. The private account key 204 may further be specific to a type of cryptocurrency, e.g., the customer device 102 may include a different private account key 204 for each type of cryptocurrency stored in a customer wallet.” (Para. 0068); “the customer device 102 may store a separate private account key 204 for each of Bitcoin, Ethereum, Litecoin, etc. A customer wallet may be defined by the private account key 204 and/or other private account key(s)” (Para. 0068); “FIG. 2A is a block diagram illustrating an example node tree 200A on the customer device 102 for implementing a customer wallet.” (Para. 0067)
As per Claim 13 and 27, Black teaches:
The method of claim 1, wherein the blockchain server is located remotely from separate devices and/or applications on which the private keys are stored (“The node tree 200A may reside on the customer device 102 and may include a hierarchy of levels. Specifically, the node tree 200A may include a private account key 204 and a public account key 205 in the first level (L1).” (Para. 0068); “Each of the devices in the system 100 may be communicatively coupled to one or more other devices using at least one network 112 (such as networks 112A-B). In examples, the at least one network 112 includes at least one wired network and/or at least one wireless network. In examples, any combination of wired and wireless networks may be used to couple the customer device 102, the currency conversion system 104, and the trusted third party 106 to each other.” (Para. 0064); “the customer device 102 may transmit 1628 the sweeping transaction to an optional distributed ledger 118 (e.g., to a node implementing an optional distributed ledger 118) for recording on the optional distributed ledger 118.” (Para. 0274))
As per Claim 14, Black teaches:
The method of claim 1, wherein each private key is hosted by a unique computing device. (“Each of the customer device 102, the currency conversion system 104, the trusted third party 106, the asset exchange 108 and the identity services provider 110 may be implemented as any of a mobile computing device, such as a mobile phone, tablet computer, mobile media device, mobile gaming device, laptop computer, or vehicle-based computer, etc.; or a non-mobile computing device such as a dedicated terminal, a public terminal, a kiosk, a server, a cloud server, or a desktop computer.” (Para. 0048); “FIG. 1 is a block diagram illustrating an example system 100 for multi-approval cryptocurrency accounts and transactions. The system 100 may include a customer device 102, a currency conversion system 104, a trusted third party 106, an optional asset exchange 108, an optional identify services provider 110, and a distributed ledger 118. Additionally, the system 100 may include more than one of each device.” (Para. 0047); “In examples, each of the customer device 102, the currency conversion system 104, and the trusted third party 106 may include at least one memory, at least one processor, at least one optional network interface, at least one optional display device, at least one optional input device, and at least one optional power source. Additionally, each of the customer device 102, the currency conversion system 104 and/or the trusted third party 106 may be implemented using multiple physical devices.” (Para. 0049).
As per Claim 17, Black teaches:
The at least one non-transitory computer-readable storage medium of claim 15, further comprising notifying other of the n externally owned accounts of the proposed blockchain transaction request received by the MFA smart contract wallet. (“In examples, keys and/or key components can be electronically distributed to the devices using at least one of email, Short Message Service (SMS), Multimedia Messaging Service (MMS), instant messaging, push notification (such as a push verify notification), by polling (or pulling) a notification, or by Bluetooth, Wi-Fi, or near field communication (NFC) transmission. In examples, the keys and/or key components can be displayed on a screen and written down or otherwise physically distributed through printing (such as into a Quick Response (QR) code, barcode, etc.) or stored on USB keys/memory sticks (or other solid state drives), or optical or magnetic disks. Additionally, an index of a key or a key component within a node tree may be communicated from a first device to a second device, which can derive the key or key component from a different key already stored at the second device.” (Para. 0045); “The system 100 may use a multi-approval methodology, e.g., multi-party multi-signature (multi-sig) methodology, a multi-party key splitting methodology, or a combination of the two. A multi-party multi-signature (multi-sig) methodology may distribute a different private key (e.g., a unique string of numbers, letters, and/or other characters) to each of the customer device 102, the currency conversion system 104, and the trusted third party 106. Using multi-sig, any requested cryptocurrency purchase or transaction from the customer must be signed using M/N (e.g., two of three) private keys, e.g., signed by the customer device 102 and the currency conversion system 104. The private keys may be generated at the customer device 102, the currency conversion system 104, the trusted third party 106, or some combination. Multi-sig methodology does not require private keys to be split.” (Para. 0050); “During routine operation, private keys from both the customer (end user) and currency conversion system/exchange may be required to transact from a customer wallet, e.g., to transfer cryptocurrency from a transaction address. If the user were to lose their private key (such as by losing, breaking, or upgrading their device that contained the private key), private keys of the currency conversion system/exchange and the trusted third party (such as the credit union or bank) may be used to recover the wallet. When a wallet is recovered, new private keys (or private key components) may be generated for (1) the customer (end user); (2) the currency conversion system/exchange; and (3) the trusted third party (such as a credit union or bank).” (Para. 0046)
As per Claim 18, Black teaches:
The at least one non-transitory computer-readable storage medium of claim 15, using a notification service to push notifications to each one of the n externally owned accounts, the pushed notifications concerning MFA smart contract wallet events, the events including proposed blockchain transaction requests received by the MFA smart contract wallet. (“In examples, keys and/or key components can be electronically distributed to the devices using at least one of email, Short Message Service (SMS), Multimedia Messaging Service (MMS), instant messaging, push notification (such as a push verify notification), by polling (or pulling) a notification, or by Bluetooth, Wi-Fi, or near field communication (NFC) transmission. In examples, the keys and/or key components can be displayed on a screen and written down or otherwise physically distributed through printing (such as into a Quick Response (QR) code, barcode, etc.) or stored on USB keys/memory sticks (or other solid state drives), or optical or magnetic disks. Additionally, an index of a key or a key component within a node tree may be communicated from a first device to a second device, which can derive the key or key component from a different key already stored at the second device.” (Para. 0045); “The system 100 may use a multi-approval methodology, e.g., multi-party multi-signature (multi-sig) methodology, a multi-party key splitting methodology, or a combination of the two. A multi-party multi-signature (multi-sig) methodology may distribute a different private key (e.g., a unique string of numbers, letters, and/or other characters) to each of the customer device 102, the currency conversion system 104, and the trusted third party 106. Using multi-sig, any requested cryptocurrency purchase or transaction from the customer must be signed using M/N (e.g., two of three) private keys, e.g., signed by the customer device 102 and the currency conversion system 104. The private keys may be generated at the customer device 102, the currency conversion system 104, the trusted third party 106, or some combination. Multi-sig methodology does not require private keys to be split.” (Para. 0050); “During routine operation, private keys from both the customer (end user) and currency conversion system/exchange may be required to transact from a customer wallet, e.g., to transfer cryptocurrency from a transaction address. If the user were to lose their private key (such as by losing, breaking, or upgrading their device that contained the private key), private keys of the currency conversion system/exchange and the trusted third party (such as the credit union or bank) may be used to recover the wallet. When a wallet is recovered, new private keys (or private key components) may be generated for (1) the customer (end user); (2) the currency conversion system/exchange; and (3) the trusted third party (such as a credit union or bank).” (Para. 0046)
As per Claim 19, Black teaches:
The at least one non-transitory computer-readable storage medium of claim 15, wherein there is a fixed period of time for the m approving ones of the externally owned accounts to submit the responsive blockchain transaction requests. (“During routine operation, private keys from both the customer (end user) and currency conversion system/exchange may be required to transact from a customer wallet, e.g., to transfer cryptocurrency from a transaction address. If the user were to lose their private key (such as by losing, breaking, or upgrading their device that contained the private key), private keys of the currency conversion system/exchange and the trusted third party (such as the credit union or bank) may be used to recover the wallet. When a wallet is recovered, new private keys (or private key components) may be generated for (1) the customer (end user); (2) the currency conversion system/exchange; and (3) the trusted third party (such as a credit union or bank).” (Para. 0046); “FIG. 7A is a flow diagram illustrating an example method 700A for cryptocurrency transactions in a multi-approval system, e.g., spending cryptocurrency for goods or services. The method 700A may be performed by the customer device 102, the currency conversion system 104, and optionally, the trusted third party 106 in the system 100 illustrated in FIG. 1.” (Para. 0134); “To initiate a cryptocurrency transaction, the customer may open 704 an application on the customer device 102 using authentication data. In examples, the authentication data may include biometric data, e.g., the customer placing a finger on a fingerprint reader, pointing a camera at their face, pointing a camera at their eye, or speaking into a microphone. In examples, the application may open (or allow particular access) only if the biometric data matches the biometric data uploaded during onboarding. Alternatively, the authentication data may be a password, or a combination of biometric data and a password. Once the user has gained access to the application, the customer may create 706 a transaction request in the application.” (Para. 0136)
As per Claim 22, Black teaches:
The at least one non-transitory computer-readable storage medium of claim 15, wherein the n total number of unique private keys are associated with externally owned accounts on different computing devices. (“Each of the customer device 102, the currency conversion system 104, the trusted third party 106, the asset exchange 108 and the identity services provider 110 may be implemented as any of a mobile computing device, such as a mobile phone, tablet computer, mobile media device, mobile gaming device, laptop computer, or vehicle-based computer, etc.; or a non-mobile computing device such as a dedicated terminal, a public terminal, a kiosk, a server, a cloud server, or a desktop computer.” (Para. 0048); “In examples, each of the customer device 102, the currency conversion system 104, and the trusted third party 106 may include at least one memory, at least one processor, at least one optional network interface, at least one optional display device, at least one optional input device, and at least one optional power source. Additionally, each of the customer device 102, the currency conversion system 104 and/or the trusted third party 106 may be implemented using multiple physical devices.” (Para. 0049); “The system 100 may use a multi-approval methodology, e.g., multi-party multi-signature (multi-sig) methodology, a multi-party key splitting methodology, or a combination of the two. A multi-party multi-signature (multi-sig) methodology may distribute a different private key (e.g., a unique string of numbers, letters, and/or other characters) to each of the customer device 102, the currency conversion system 104, and the trusted third party 106. Using multi-sig, any requested cryptocurrency purchase or transaction from the customer must be signed using M/N (e.g., two of three) private keys, e.g., signed by the customer device 102 and the currency conversion system 104. The private keys may be generated at the customer device 102, the currency conversion system 104, the trusted third party 106, or some combination. Multi-sig methodology does not require private keys to be split.” (Para. 0050)
As per Claim 23, Black teaches:
The at least one non-transitory computer-readable storage medium of claim 15, wherein the n total number of unique private keys are associated with different applications on one or more computing devices. (“Each of the customer device 102, the currency conversion system 104, the trusted third party 106, the asset exchange 108 and the identity services provider 110 may be implemented as any of a mobile computing device, such as a mobile phone, tablet computer, mobile media device, mobile gaming device, laptop computer, or vehicle-based computer, etc.; or a non-mobile computing device such as a dedicated terminal, a public terminal, a kiosk, a server, a cloud server, or a desktop computer.” (Para. 0048); “In examples, each of the customer device 102, the currency conversion system 104, and the trusted third party 106 may include at least one memory, at least one processor, at least one optional network interface, at least one optional display device, at least one optional input device, and at least one optional power source. Additionally, each of the customer device 102, the currency conversion system 104 and/or the trusted third party 106 may be implemented using multiple physical devices.” (Para. 0049); “The system 100 may use a multi-approval methodology, e.g., multi-party multi-signature (multi-sig) methodology, a multi-party key splitting methodology, or a combination of the two. A multi-party multi-signature (multi-sig) methodology may distribute a different private key (e.g., a unique string of numbers, letters, and/or other characters) to each of the customer device 102, the currency conversion system 104, and the trusted third party 106. Using multi-sig, any requested cryptocurrency purchase or transaction from the customer must be signed using M/N (e.g., two of three) private keys, e.g., signed by the customer device 102 and the currency conversion system 104. The private keys may be generated at the customer device 102, the currency conversion system 104, the trusted third party 106, or some combination. Multi-sig methodology does not require private keys to be split.” (Para. 0050)
As per Claim 25, Black teaches:
The at least one non-transitory computer-readable storage medium of claim 15, wherein at least one externally owned account comprises an application associated with at least a private key. (“To initiate a cryptocurrency transaction, the customer may open 704 an application on the customer device 102 using authentication data. In examples, the authentication data may include biometric data, e.g., the customer placing a finger on a fingerprint reader, pointing a camera at their face, pointing a camera at their eye, or speaking into a microphone. In examples, the application may open (or allow particular access) only if the biometric data matches the biometric data uploaded during onboarding. Alternatively, the authentication data may be a password, or a combination of biometric data and a password. Once the user has gained access to the application, the customer may create 706 a transaction request in the application.” (Para. 0136); “The system 100 may use a multi-approval methodology, e.g., multi-party multi-signature (multi-sig) methodology, a multi-party key splitting methodology, or a combination of the two. A multi-party multi-signature (multi-sig) methodology may distribute a different private key (e.g., a unique string of numbers, letters, and/or other characters) to each of the customer device 102, the currency conversion system 104, and the trusted third party 106. Using multi-sig, any requested cryptocurrency purchase or transaction from the customer must be signed using M/N (e.g., two of three) private keys, e.g., signed by the customer device 102 and the currency conversion system 104. The private keys may be generated at the customer device 102, the currency conversion system 104, the trusted third party 106, or some combination. Multi-sig methodology does not require private keys to be split.” (Para. 0050); “During routine operation, private keys from both the customer (end user) and currency conversion system/exchange may be required to transact from a customer wallet, e.g., to transfer cryptocurrency from a transaction address. If the user were to lose their private key (such as by losing, breaking, or upgrading their device that contained the private key), private keys of the currency conversion system/exchange and the trusted third party (such as the credit union or bank) may be used to recover the wallet. When a wallet is recovered, new private keys (or private key components) may be generated for (1) the customer (end user); (2) the currency conversion system/exchange; and (3) the trusted third party (such as a credit union or bank).” (Para. 0046)
As per Claim 26, Black teaches:
The at least one non-transitory computer-readable storage medium of claim 15, wherein at least one externally owned account comprises a wallet comprising at least a private key. (“To initiate a cryptocurrency transaction, the customer may open 704 an application on the customer device 102 using authentication data. In examples, the authentication data may include biometric data, e.g., the customer placing a finger on a fingerprint reader, pointing a camera at their face, pointing a camera at their eye, or speaking into a microphone. In examples, the application may open (or allow particular access) only if the biometric data matches the biometric data uploaded during onboarding. Alternatively, the authentication data may be a password, or a combination of biometric data and a password. Once the user has gained access to the application, the customer may create 706 a transaction request in the application.” (Para. 0136); “The system 100 may use a multi-approval methodology, e.g., multi-party multi-signature (multi-sig) methodology, a multi-party key splitting methodology, or a combination of the two. A multi-party multi-signature (multi-sig) methodology may distribute a different private key (e.g., a unique string of numbers, letters, and/or other characters) to each of the customer device 102, the currency conversion system 104, and the trusted third party 106. Using multi-sig, any requested cryptocurrency purchase or transaction from the customer must be signed using M/N (e.g., two of three) private keys, e.g., signed by the customer device 102 and the currency conversion system 104. The private keys may be generated at the customer device 102, the currency conversion system 104, the trusted third party 106, or some combination. Multi-sig methodology does not require private keys to be split.” (Para. 0050); “During routine operation, private keys from both the customer (end user) and currency conversion system/exchange may be required to transact from a customer wallet, e.g., to transfer cryptocurrency from a transaction address. If the user were to lose their private key (such as by losing, breaking, or upgrading their device that contained the private key), private keys of the currency conversion system/exchange and the trusted third party (such as the credit union or bank) may be used to recover the wallet. When a wallet is recovered, new private keys (or private key components) may be generated for (1) the customer (end user); (2) the currency conversion system/exchange; and (3) the trusted third party (such as a credit union or bank).” (Para. 0046)
As per Claim 28, Black teaches:
The at least one non-transitory computer-readable storage medium of claim 15, wherein each externally owned account is hosted by a unique computing device. (“Each of the customer device 102, the currency conversion system 104, the trusted third party 106, the asset exchange 108 and the identity services provider 110 may be implemented as any of a mobile computing device, such as a mobile phone, tablet computer, mobile media device, mobile gaming device, laptop computer, or vehicle-based computer, etc.; or a non-mobile computing device such as a dedicated terminal, a public terminal, a kiosk, a server, a cloud server, or a desktop computer.” (Para. 0048); “FIG. 1 is a block diagram illustrating an example system 100 for multi-approval cryptocurrency accounts and transactions. The system 100 may include a customer device 102, a currency conversion system 104, a trusted third party 106, an optional asset exchange 108, an optional identify services provider 110, and a distributed ledger 118. Additionally, the system 100 may include more than one of each device.” (Para. 0047); “In examples, each of the customer device 102, the currency conversion system 104, and the trusted third party 106 may include at least one memory, at least one processor, at least one optional network interface, at least one optional display device, at least one optional input device, and at least one optional power source. Additionally, each of the customer device 102, the currency conversion system 104 and/or the trusted third party 106 may be implemented using multiple physical devices.” (Para. 0049).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Justin A. Jimenez whose telephone number is (571) 270-3080. The examiner can normally be reached on 8:30 AM - 5:00 PM.
The following prior art made of record and not relied upon is considered pertinent to applicant's disclosure: US20210272120 (Murdoch), discussing “. . . a computing system of a subject entity is configured to generate one or more claims, each of which includes at least information related to (1) a DID, (2) a property of a subject entity that is an owner of the DID, and (3) a value corresponding to the property. The claim is then signed with a private key associated with the corresponding DID to generate a cryptographic signature. The cryptographic signature proves that the claim is issued by the owner of the corresponding DID. Since the claim is issued by the subject entity and is about the subject entity, the claim is called a self-issued claim. A portion of data related to the self-issued claim is then propagated onto a distributed ledger.” (Para. 0008)
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, John W. Hayes can be reached on 571-272-6708. 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.
/Justin Jimenez/
Patent Examiner, Art Unit 3697
/ARI SHAHABI/Primary Examiner, Art Unit 3697
Prosecution Insights