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-5, 8-9, 12-19, 22-23, and 26-29 are currently amended.
Claims 6-7, 11, 20-21, and 25 are cancelled.
Claims 30-35 are newly added.
Response to Remarks
35 U.S.C. § 101
Applicant’s amendments to the claims have overcome the previous rejections. Accordingly, the previous rejections are withdrawn.
35 U.S.C. § 102 and 103
Remark 1: Applicant argues “a 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. This is described clearly on the second paragraph of page 3 which is incorporated by reference in Applicant's Specification: "One way to implement a multi-factor authentication wallet is to implement a 'm of n' wallet, but instead of a different individual controlling each of the n keys, a single person controls the different keys, but keeps them on different applications and/or devices to prevent creating a single point of failure." Applicant's Specification then describes the processes of enforcing the 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 being stored on a separate device and/or application," prior to execution of a corresponding single, specific blockchain transaction at, for example, [050]-[056].” (Applicants Response, 2025-07-30). The applicant contends “. . ."[conventional] multi-signature wallets may be built upon" by, for example "to implement a 'm of n' wallet, but instead of a different individual controlling each of the n keys, a single person controls the different keys, but keeps them on different applications and/or devices to prevent creating a single point of failure." In other words, the security gained by requiring separate signatures is preserved, but a non-trivial improvement is created by eliminating the overhead of requiring signatures from separate users/entities, and by enabling an individual to benefit from the added security of multi-signature wallets without having to involve or rely on additional entities/users.” (id.)
Response to Remark 1: Examiner respectfully disagrees, as the currently cited references (e.g. Black and Basu) do teach “the multi-factor authentication (MFA) smart contract wallet includ[ing] an MFA rule requiring "receipt of separate approvals signed by a number m of n 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, wherein m is at least two and n is equal to or greater than two.”, as shown at least in paragraphs 20, 33, 35, 358, and 360-361 of Basu, and as further outlined in paragraphs 12-20 of this action. (id). 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 equal to or greater than two, (“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); “