Detailed Action
Claims 1-7 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-2, 4-5, and 7 are currently amended.
Response to Remarks
Claim Objections
Applicant’s objections to the claims have overcome the previous rejections. Accordingly, the previous objections are withdrawn.
35 U.S.C. § 112
Applicant’s amendments to the claims have overcome the previous rejections. Accordingly, the previous rejections are withdrawn.
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. § 103
Remark 1: Applicant argues “Sharma and Sadayoshi, alone or in combination, fail to disclose at least "off-chain multi-factor authentication for services on a blockchain," with the method using "a push-mode multi-factor authentication server," to obtain "an account of an end-user, the account being identifiable via an accountID, the push-mode multi-factor authentication server being an off-chain server that is not a part of the blockchain on which the services are being authenticated; in response to determining that an operation associated with a customer smart contract is to be executed on the blockchain, the customer smart contract determining an off-chain multi-factor approval status of the end-user with the push-mode multi-factor authentication server, the determining comprising: ... calling a function in an SDK and performing an in-chain call to a function OracleRequest in an oracle operator smart contract, the function OracleRequest including: the accountID, a callback smart contract address, a callback smart contract function Id, an oracle token address, and the integer; performing, by the oracle operator smart contract, a gas payment, and emitting an event with the accountID and the integer as parameter; based on the emitting of the event, the oracle server executing the task identified by the integer, the task performing an API call to an oracle interaction backend that further calls a checkStatus API; in response to execution of one or more functions of the checkStatus API, the push-mode multi-factor authentication server confirming the off-chain multi-factor approval status to the oracle server via the oracle interaction backend; and based on the off-chain multi-factor approval status, performing, by the oracle server, a call to a function fullfillOracleRequest2 of the oracle operator smart contract, the call to the function fullfillOracleRequest2 propagating the off-chain multi-factor approval status to the customer smart contract," as recited in claim 1.” (Applicant Arguments, 2025-09-03). The applicant contends “Sharma merely discloses using a sidechain, i.e., another blockchain, for authentication. At no point does Sharma disclose using an off-chain server, e.g., part of an Oracle network, to perform two-factor authentication. That is, at no point does Sharma disclose a hybrid architecture that incorporates the robust security of Web2 into the Web3 environment. Further, to the extent Sadayoshi discloses two-factor authentication, Sadayoshi merely discloses using a blockchain as the second factor, i.e., using a public ledger to derive the second factor in the two-factor authentication. That is, Sadayoshi does not disclose providing two-factor authentication for a blockchain, i.e., Web3 application, using a Web2 application.” (id.).
Response to Remark 1: Examiner respectfully disagrees, as the cited references (e.g. Sharma and Sadayoshi) still teach the limitations of the currently amended independent claims, as shown at least in paragraphs 6, 16, 18-19, and 26 of Sharma, and as further outlined in paragraph 11 of this action. Indeed, Sharma discloses a hybrid two-factor flow in which a separate system (e.g. a sidechain network and its associated components) supplies the second factor that gates execution on the primary chain. Further, Sadayoshi does teach a hybrid authentication system that is communicatively coupled to a web application server (e.g. Web2) and to the public ledger (e.g. Web3). The hybrid system calls a smart contract, the ledger validates with a public key, and the result is returned to/consumed by the off-chain web system to permit access or proceed. 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.
Claims 1-7 are rejected under 35 U.S.C. 103 as being unpatentable over Sharma et al. (US20200213128A1) (hereinafter “Sharma”) in view of Sadayoshi et al. (US20210084024A1) (hereinafter “Sadayoshi”).
As per Claim 1, Sharma teaches:
A method for off-chain multi-factor authentication for services on the blockchain, the method comprising: obtaining, by a push-mode multi-factor authentication server, an account of an end-user, the account being identifiable via an accountID; (“The blockchain nodes 108 may store a data pair associating the sidechain wallet information with the blockchain wallet, for use in identifying sidechain data values and performing the second factor authentication.” (Para. 0027); “In step 402, a data pair may be stored in a memory (e.g., the memory 226) of a blockchain node (e.g., the blockchain node 108) that includes at least a public key of a first cryptographic key pair and an expected data value. In step 404, a transaction request may be received by a receiver (e.g., the receiving device 202) of the blockchain node, wherein the transaction request includes at least a first digital signature, one or more input addresses, one or more output addresses, and at least one transaction amount. In step 406, a processed transaction may be identified by a processing device (e.g., the querying module 218) of the blockchain node in a sidechain that includes at least a destination address and a transaction data value, wherein the destination address is generated using the public key of the first cryptographic key pair.” (Para. 0046)
the push-mode multi-factor authentication server being an off-chain server that is not a part of the blockchain on which the services are being authenticated; (“For the second authentication factor, the blockchain node 108 may examine the sidechain to identify the most recent sidechain data value that includes a destination address generated using the user's blockchain wallet. In some embodiments, the user 102 may receive a sidechain transaction identifier from the sidechain node 114 when the sidechain data value is posted, which may be provided to the blockchain node 108 to expedite the identification process. Once the sidechain data value is identified, the blockchain node 108 may identify the expected data value included therein. The blockchain node 108 may then check the expected data value found in the sidechain data value against the expected data value received from the user 102 (e.g., or provided thereto by the blockchain node 108, as applicable). This check of the expected data value may be the second authentication factor, where, if the expected data values do not match, the blockchain transaction may not be processed. If the expected data values do match, and the first authentication factor is successful, then the blockchain transaction may be processed using standard methods and systems. The user 102 may thus successfully transaction on the blockchain using two factor authentication, where the second factor relies on the use of a sidechain without compromising the user's anonymity or the decentralized nature of the blockchain.” (Para. 0026)
performing, . . ., a gas payment, and emitting an event . . .; (“For instance, a blockchain transaction may be posted (e.g., with a zero or trivial currency amount) to the blockchain that uses the sidechain wallet information as the output address or otherwise includes the sidechain wallet information in the blockchain transaction data, such as in a smart contract.” (Para. 0027); “In some cases, sidechain nodes 114 may actively push updated sidechain blocks to the blockchain node 108. In other cases, the blockchain node 108 may monitor the sidechain for updates and pull new blocks once they are added. The querying module 218 of the blockchain node 108 may execute a query on the memory 226 of the blockchain node 108 for storage of the sidechain data therein.” (Para. 0042); “In step 324, if both authentications are successful, the blockchain transaction may be processed and added to the blockchain, such as by generating a new blockchain data value to include the blockchain transaction data, generating a new block that includes the blockchain data value, and distributing the new block to other blockchain nodes 108 for verification and inclusion in the blockchain.” (Para. 0044)
based on the emitting of the event, . . . executing the task identified by the integer, the task performing an API call to . . . that further calls a checkStatus API; (“Processing of the sidechain transaction may include verification of the first digital signature using a public key of the user's sidechain wallet, the generation of a new sidechain data value that includes the transaction data, and the inclusion of the new sidechain data value in a newly generated block that is verified and added to the sidechain.” (Para. 0042); “In some cases, sidechain nodes 114 may actively push updated sidechain blocks to the blockchain node 108. In other cases, the blockchain node 108 may monitor the sidechain for updates and pull new blocks once they are added. The querying module 218 of the blockchain node 108 may execute a query on the memory 226 of the blockchain node 108 for storage of the sidechain data therein.” (Para. 0042); “In step 318, the querying module 218 of the blockchain node 108 may execute a query on the memory 226 of the blockchain node 108 to identify the sidechain data value that was added to the sidechain in step 308, using the sidechain transaction identifier, if available, or through the destination address included in the sidechain data value generated using the public key of the blockchain wallet involved in the blockchain transaction. In step 320, a first authentication may be performed by the validation module 222 of the blockchain node 108, which may include validating the second digital signature using the blockchain wallet's public key (e.g., included in the transaction data or previously provided to the blockchain node 108) and the signature generation algorithm.” (Para. 0044)
in response to execution of one or more function of the checkStatus API, the push-mode multi-factor authentication server confirming the off-chain multi-factor approval status . . .; and (“The blockchain node 108 may then check the expected data value found in the sidechain data value against the expected data value received from the user 102 (e.g., or provided thereto by the blockchain node 108, as applicable). This check of the expected data value may be the second authentication factor, where, if the expected data values do not match, the blockchain transaction may not be processed. If the expected data values do match, and the first authentication factor is successful, then the blockchain transaction may be processed using standard methods and systems. The user 102 may thus successfully transaction on the blockchain using two factor authentication, where the second factor relies on the use of a sidechain without compromising the user's anonymity or the decentralized nature of the blockchain.” (Para. 0026); “In step 410, a second authentication may be performed by the processing device (e.g., the validation module 222) of the blockchain node, wherein the second authentication includes at least validating the transaction data value using the expected data value. In step 412, the received transaction request may be transmitted, by a transmitter (e.g., the transmitting device 224) of the blockchain node to a plurality of other nodes in a blockchain network (e.g., the blockchain network 106) that includes the blockchain node.” (Para. 0047)
based on the off-chain multi-factor approval status, . . ., propagating the off-chain multi-factor approval status to the customer smart contract; (“If the expected data values do match, and the first authentication factor is successful, then the blockchain transaction may be processed using standard methods and systems. The user 102 may thus successfully transaction on the blockchain using two factor authentication, where the second factor relies on the use of a sidechain without compromising the user's anonymity or the decentralized nature of the blockchain.” (Para. 0026); “In step 324, if both authentications are successful, the blockchain transaction may be processed and added to the blockchain, such as by generating a new blockchain data value to include the blockchain transaction data, generating a new block that includes the blockchain data value, and distributing the new block to other blockchain nodes 108 for verification and inclusion in the blockchain.” (Para. 0044); “In step 412, the received transaction request may be transmitted, by a transmitter (e.g., the transmitting device 224) of the blockchain node to a plurality of other nodes in a blockchain network (e.g., the blockchain network 106) that includes the blockchain node.” (Para. 0047).
based on receiving the propagated off-chain multi-factor approval status by the customer smart contract, authenticating the end-user to perform the operation on the at least one blockchain, and (“A blockchain wallet may include a private key of a cryptographic key pair that is used to generate digital signatures that serve as authorization by the user 102 for a blockchain transaction, where the digital signature can be verified by the blockchain network 106 using the public key of the cryptographic key pair. Verification of the digital signature may serve as the first authentication factor in the methods discussed herein. In some cases, the term “blockchain wallet” may refer specifically to the private key. In some embodiments, a third party entity, such as a key repository, may store the consumer's private key. In other embodiments, the private key may be stored on the computing device 104.” (Para. 0018); “To implement a second factor of authentication, a sidechain is used. A secondary blockchain wallet that uses the sidechain is registered by the user with the primary blockchain. Before a new blockchain transaction takes place, the user must perform an action on the sidechain using the secondary blockchain wallet, such as by posting a digital token, unique value, or an address of the primary blockchain wallet. This expected data value is also available to the nodes in the primary blockchain, either provided by the user before a transaction or generated by the nodes themselves.” (Para. 0006); “When the primary blockchain transaction is submitted to the blockchain, the nodes authenticate it as normal (e.g., using the digital signature), but also check the sidechain for posting of the expected data value to the secondary blockchain wallet that is paired with the primary blockchain wallet as the second factor. A transaction cannot be successfully confirmed, and thereby processed, without this second factor.” (Para. 0006)).
based on the end-user being authenticated and based on the end-user performing the operation on the at least one blockchain, generating a block associated with the operation and adding the block to the at least one blockchain based on a consensus among the nodes in the at least one blockchain to add the block.
(“One or more computing devices may comprise a blockchain network, which may be configured to process and record transactions as part of a block in the blockchain. Once a block is completed, the block is added to the blockchain and the transaction record thereby updated.” (Para. 0016); “maintains a continuously growing list of data records hardened against tampering and revision, even by its operators, and may be confirmed and validated by the blockchain network through proof of work and/or any other suitable verification techniques associated therewith.” (Para. 0016); “The blockchain network 106 may be comprised of a plurality of blockchain nodes 108. Each blockchain node 108 may be a computing system that is configured to perform functions related to the processing and management of the blockchain, including the generation of blockchain data values, verification of proposed blockchain transactions, verification of digital signatures, generation of new blocks, validation of new blocks, and maintenance of a copy of the blockchain.” (Para. 0019)).
Sharma does not disclose:
• “a call to a function fullfillOracleRequest2 of the oracle operator smart contract, the call to the function fullfillOracleRequest2” (claim 1).
However, as per Claim 1, Sadayoshi in the analogous art of multi-factor authentication, teaches: “a call to a function fullfillOracleRequest2 of the oracle operator smart contract”. (See “Based on the authentication of the received request, the public ledger 112 may return the hybrid ID to the hybrid authentication system 102.” (para. 0038); “At 422, the public ledger 112 may return the hybrid ID (e.g., the hybrid ID created at 312 of FIG. 3B) linked with the public key to the hybrid authentication system 102 based on the authentication of the received request.” (para. 0073); “At 424, the hybrid authentication system 102 may issue the access token [based on the returned hybrid ID] (received at 306 of FIGS. 3A and 3B) to the web application server 104” (para. 0074).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Sharma with the technique of Sadayoshi to include on-chain smart contract module returning the approval or ‘hybrid ID’ to an off-chain component, which then propagates the approval downstream. Therefore, the incentives of providing increased data availability for the user provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
Sharma does not disclose:
• “in response to determining that an operation associated with a customer smart contract, is to be executed on the blockchain, the customer smart contract determining on off-chain multi-factor approval status of the end-user with the push-mode multi-factor authentication server, the determining comprising: based on determining that a mapping between a public key and the accountID exists, returning the account ID, an address of an oracle server, and an integer that identifies a task in the oracle server using a multi-factor authentication provider smart contract, that is deployed on that blockchain” (claim 1).
However, as per Claim 1, Sadayoshi in the analogous art of multi-factor authentication, teaches: “in response to determining that an operation associated with a customer smart contract, is to be executed on the blockchain, the customer smart contract determining on off-chain multi-factor approval status of the end-user with the push-mode multi-factor authentication server, the determining comprising: based on determining that a mapping between a public key and the accountID exists, returning the account ID, an address of an oracle server, and an integer that identifies a task in the oracle server using a multi-factor authentication provider smart contract, that is deployed on that blockchain”. (See “In order to link the web ID with the wallet account, a smart contract will be written and made accessible by the Hybrid authentication system 102. At the time of wallet linking with web-ID, the hybrid authentication system 102 may also initiate a transaction via the smart contract to update the public ledger 112 with linking information for the wallet account and the web ID. This linking information may be related to the wallet account and the web account of the user 118 and may include, for example, a hybrid ID for the user 118, the public key for the wallet account (e.g., Ethereum Wallet Account), the web ID for the web account (e.g., a Social Media Account), and a user identifier. In certain instances, the user 118 may be provided with options to link multiple web accounts (or multiple web-IDs) to the same wallet account so as to allow the user 118 to select any suitable web-ID for SSO access to the web application 106. The linking of the wallet account with the web-ID(s) is described in detail, for example, in FIG. 3A and FIG. 3B.” (para. 0037); “At 422, the public ledger 112 may return the hybrid ID (e.g., the hybrid ID created at 312 of FIG. 3B) linked with the public key to the hybrid authentication system 102 based on the authentication of the received request. The returned hybrid ID may be linked with the public key and stored on the public ledger 112. Additionally, the returned hybrid ID may include identifiers which indicate that the web ID for the web account of the user 118 is linked to the wallet account.” (para. 0073).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Sharma with the technique of Sadayoshi to include smart contract interaction and key-to-ID mapping within a transaction authorization process, such that ‘hybrid ID’ is understood as the account ID and the smart contract call returns the mapping, or confirmation of the absence of mapping. Therefore, the incentives of providing increased data security for the user provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
Sharma does not disclose:
• “to the oracle server via the oracle interaction backend” (claim 1)
However, as per Claim 1, Sadayoshi in the analogous art of multi-factor authentication, teaches: “to the oracle server via the oracle interaction backend”. (See “At 420, the public ledger 112 may use the smart contract to validate the signature with the public key of the wallet account.” (para. 0072); “At 422, the public ledger 112 may return the hybrid ID (e.g., the hybrid ID created at 312 of FIG. 3B) linked with the public key to the hybrid authentication system 102 based on the authentication of the received request.” (para. 0073); “The returned hybrid ID may be linked with the public key. . . At 424, the hybrid authentication system 102 may issue the access token (received at 306 of FIGS. 3A and 3B) to the web application server 104” (para. 0074).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Sharma with the technique of Sadayoshi to include an MFA approval status check via a server-backend connection, such that the on-chain contract or ‘oracle-operator’ completes its check and prepares a status that can be communicated off-chain. Therefore, the incentives of providing increased data security for the user provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
Sharma does not disclose:
• “calling a function in an SDK and performing an in-chain call to a function OracleRequest in an oracle operator smart contract, the function OracleRequest including: the accountID, a callback smart contract address, a callback smart contract function Id, an oracle token address, and the integer” (claim 1).
However, as per Claim 1, Sadayoshi in the analogous art of multi-factor authentication, teaches: “calling a function in SDK and performing an in-chain call to a function OracleRequest in an oracle operator smart contract, the function Oracle Request including: the accountID, a callback smart contract address; a callback smart contract function Id, an oracle token address, and the integer”. (See “At 418, the hybrid authentication system 102 may receive the signature via the UI form and call the smart contract (i.e. the smart contract called at 314) based on the received signature. Once a call is made to the smart contract, a validation process may be initiated on the public ledger 112 using the smart contract, as described herein.” (para. 0071)
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Sharma with the technique of Sadayoshi to include in-chain calls within a transaction authorization process, such that any on-chain call initiated by the server could correspond to an ‘OracleRequest’ function. Therefore, the incentives of providing increased data security for the user provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
Sharma does not disclose:
• “by the oracle operator smart contract. . . with the accountID and the integer as parameter” (claim 1).
However, as per Claim 1, Sadayoshi in the analogous art of multi-factor authentication, teaches: “by the oracle operator smart contract. . . with the accountID and the integer as parameter”. (See “At 314, the hybrid authentication system 102 may call a smart contract from the public ledger 112 using the signature and the created hybrid ID and may execute a transaction via the smart contract to update the public ledger 112 with linking information for the wallet account and the web ID. By way of example, the transaction may include an operation to retrieve a public key of the wallet account from the signature and another operation to the link the public key of the wallet account with the hybrid ID. The hybrid authentication system 102 may store the hybrid ID, the public key for the wallet account (e.g., Ethereum Wallet Account), the web ID for the web account (e.g., a Social Media Account), and a user identifier as the linking information on the public ledger 112. The smart contract may control access to the linking information on the public ledger 112 for future requests from the hybrid authentication system 102.” (para. 0059); “FIGS. 3A and 3B, collectively, illustrate a sequence diagram for linking web ID(s) with a user's wallet account on a public ledger, in accordance with an embodiment of the disclosure. FIGS. 3A and 3B are explained in conjunction with elements from FIG. 1 and FIG. 2. With reference to FIGS. 3A and 3B, there is shown a sequence diagram 300 that illustrates a method for linking a web-ID of the web account (managed by the identity provider 110) with the wallet account on the public ledger 112. The sequence of operations may be from 302 to 314 which may be executed by various elements of the network environment 100, such as the hybrid authentication system 102, the web application server 104, the identity provider 110, and the public ledger 112.” (para. 0052)
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Sharma with the technique of Sadayoshi to include the recording of on-chain gas payments via oracle operator smart contract within a transaction authorization process. Therefore, the incentives of providing increased data analysis for the user provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
Sharma does not disclose:
• “the oracle server. . .[and] an oracle interaction backend” (claim 1).
However, as per Claim 1, Sadayoshi in the analogous art of multi-factor authentication, teaches: “the oracle server. . .[and] an oracle interaction backend (See “At 420, the public ledger 112 may use the smart contract to validate the signature with the public key of the wallet account. For example, Elliptic Curve Digital Signature Algorithm (ECDSA) produces a signature that includes three parameters, namely, r, s, and v. As the smart contract runs on computational resources of the public ledger 112, the smart contract may call a public method (i.e. a recovery function) to recover an address from these three parameters. In case the recovered address matches with the public key (or a hash of the public key), the smart contract may determine the signature as valid. Thereafter, based on the validation of the received signature, the hybrid authentication system 102 may authenticate the request received from the web application server 104 to access the secure content 108 a on the resource server 108.” (para. 0072)
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Sharma with the technique of Sadayoshi to include a validation routine executed by a specific server and associated backend within a transaction authorization process, such the ledgers validation routine is analogous to the oracle-servers task and its internal checkStatus API. Therefore, the incentives of providing increased data analysis for the user provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
Sharma does not disclose:
• “performing, by the oracle server” (claim 1).
However, as per Claim 1, Sadayoshi in the analogous art of multi-factor authentication, teaches: “performing, by the oracle server”. (See “At 422, the public ledger 112 may return the hybrid ID (e.g., the hybrid ID created at 312 of FIG. 3B) linked with the public key to the hybrid authentication system 102 based on the authentication of the received request. The returned hybrid ID may be linked with the public key and stored on the public ledger 112. Additionally, the returned hybrid ID may include identifiers which indicate that the web ID for the web account of the user 118 is linked to the wallet account.” (para. 0073); “At 314, the hybrid authentication system 102 may call a smart contract from the public ledger 112 using the signature and the created hybrid ID and may execute a transaction via the smart contract to update the public ledger 112 with linking information for the wallet account and the web ID. By way of example, the transaction may include an operation to retrieve a public key of the wallet account from the signature and another operation to the link the public key of the wallet account with the hybrid ID. The hybrid authentication system 102 may store the hybrid ID, the public key for the wallet account (e.g., Ethereum Wallet Account), the web ID for the web account (e.g., a Social Media Account), and a user identifier as the linking information on the public ledger 112. The smart contract may control access to the linking information on the public ledger 112 for future requests from the hybrid authentication system 102.” (para. 0059); “At 430, the hybrid authentication system 102 may receive, from the resource server 108, the validation request for the access token and may validate the access token based on the received validation request. For example, the hybrid authentication system 102 may compare the access token originally issued by the hybrid authentication system 102 with the access token shared by the resource server 108 in the validation request. The hybrid authentication system 102 may inform the resource server 108 about the validity of the access token.” (para. 0077).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Sharma with the technique of Sadayoshi to include a specific server to perform status propagation within a transaction authorization process. Therefore, the incentives of providing increased data analysis for the user provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
As per Claim 2, Sharma teaches:
The method of claim 1, wherein the mapping between the public key and the account ID is based on a pairing process, wherein the pairing process comprises: obtaining a pairingToken; exposing the public key to a decentralized application, DAPP,; . . .. (“The expected data value may be a digital token, password, data file, hash value, or any other value. For instance, in one example the user 102 may provide its own, custom expected data value through the computing device 104. In another example, the computing device 104 may generate a digital token, which may be a random or pseudo-random alphanumeric value. In yet another example, the user 102 may request, through the computing device 104, a digital token from a blockchain node 108 for use. The expected data value may be provided to a sidechain node 114 in the sidechain network 112 along with the destination address and a digital signature generated using the sidechain wallet in the computing device 104. The sidechain node 114 may validate the digital signature using the public key of the sidechain wallet and verify and add the sidechain data value to a new block in the sidechain, using standard methods and systems. The sidechain node 114 may thus include a new sidechain data entry that includes the expected data value and a destination address that is directly tied to the user's blockchain wallet (e.g., being generated by its public key).” (Para. 0024); “processing of the sidechain transaction may include transmitting a sidechain transaction identifier for the sidechain data value back to the computing device 104 using a suitable communication network and method. In step 310, the receiving device 202 of the blockchain node 108 may receive the new sidechain data value as part of the updating of the sidechain. In some cases, sidechain nodes 114 may actively push updated sidechain blocks to the blockchain node 108. In other cases, the blockchain node 108 may monitor the sidechain for updates and pull new blocks once they are added. The querying module 218 of the blockchain node 108 may execute a query on the memory 226 of the blockchain node 108 for storage of the sidechain data therein.” (Para. 0042); “In some embodiments, the user 102 may be required to pre-register their sidechain wallet with the blockchain network 106. In such embodiments, the user 102 may provide information regarding their sidechain wallet, such as a public key thereof, to a blockchain node 108 before initiating any transactions using two factor authentication. The blockchain nodes 108 may store a data pair associating the sidechain wallet information with the blockchain wallet, for use in identifying sidechain data values and performing the second factor authentication. In some embodiments, the expected data value in the sidechain data value may be a digital signature generated using the user's sidechain wallet, where checking of the expected data value may include verifying this digital signature using the user's registered sidechain public key. In some cases, the data pair may be stored in the blockchain itself. For instance, a blockchain transaction may be posted (e.g., with a zero or trivial currency amount) to the blockchain that uses the sidechain wallet information as the output address or otherwise includes the sidechain wallet information in the blockchain transaction data, such as in a smart contract.” (Para. 0027)
Sharma does not disclose:
• “calling a smart contract function pair of the multi-factor authentication provider smart contract; performing the in-chain call to the oracle operator smart contract; performing the gas payment and, emitting an event pair that includes: the public key, the pairingToken, and the integer to execute the pairing; generating, by the oracle server, a unique requestID, the oracle server further running a pairing task by interacting with the oracle interaction backend; verifying, by the oracle interaction backend, that the pairingToken is not expired and that is associated to the end-user by interacting with the push-mode multi-factor authentication server, the latter returning the accountID based on the verifying; performing, by the oracle server, a call to the function fullfillOracleRequest2 of the oracle operator smart contract with accountID as input parameter, the oracle operator smart contract performing a callback to said function towards the multi-factor authentication provider smart contract, such that upon reception of the callback the mapping is created” (claim 2).
However, as per Claim 2, Sadayoshi in the analogous art of multi-factor authentication, teaches: “calls a smart contract function pair (public key, pairingToken) of the multi-factor authentication provider smart contract; performs an in-chain call to the oracle operator smart contract; performs, by the oracle operator smart contract, a gas payment, the oracle operator smart contract further emitting an event pair that includes: the public key, the pairingToken, and the integer to execute the pairing; generates, by the oracle server, a unique requestID, the oracle server further running the pairing task by interacting with the oracle interaction backend; verifies, by the oracle interaction backend, that the pairingToken is not expired and that is associated to the end-user by interacting with the multi-factor authentication server, the latter returning the accountID in case the verification is true; performs, by the oracle server, a call to the function fullfillOracleRequest2 of the oracle operator smart contract with accountID as input parameter, the oracle operator smart contract performing a callback to said function towards the multi-factor authentication provider smart contract, such that upon reception of the callback the mapping is created” (See “At 314, the hybrid authentication system 102 may call a smart contract from the public ledger 112 using the signature and the created hybrid ID and may execute a transaction via the smart contract to update the public ledger 112 with linking information for the wallet account and the web ID.” (para. 0059); “the transaction may include an operation to retrieve a public key of the wallet account from the signature and another operation to the link the public key of the wallet account with the hybrid ID” (para. 0059); “At 422, the public ledger 112 may return the hybrid ID (e.g., the hybrid ID created at 312 of FIG. 3B) linked with the public key to the hybrid authentication system 102 based on the authentication of the received request. The returned hybrid ID may be linked with the public key and stored on the public ledger 112. Additionally, the returned hybrid ID may include identifiers which indicate that the web ID for the web account of the user 118 is linked to the wallet account.” (para. 0073).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Sharma with the technique of Sadayoshi to include permanently linking a public-key wallet to an off-chain MFA account. Therefore, the incentives of providing increased data security, especially in the context of DApps, for the user provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
As per Claim 3, Sharma teaches:
The method of claim 1, wherein the public key is an identifier of a wallet, or WalletID. (“The recipient may generate a blockchain address using its public key (e.g., in the recipient device 110), which may be provided to the computing device 104. In some cases, the recipient may provide (e.g., via the recipient device 110) the computing device 104 with its public key, where the computing device 104 may generate the blockchain address. The computing device 104 may then submit the required information to a blockchain node 108 in the blockchain network 106 for processing. In some instances, the blockchain node 108 may return a blockchain transaction identifier to the computing device 104, which may be a value that is unique to that blockchain transaction for identification thereof. In such traditional transactions, the recipient may be required to generate (e.g., via the recipient device 110) blockchain address or distribute its public key, and, in some cases, may be required to submit the blockchain transaction data directly to blockchain networks 106.” (Para. 0022); “The entry posted to the sidechain, referred to herein as a sidechain data value, may include at least a destination address that is generated using the user's blockchain wallet (e.g., the public key thereof) as well as an expected data value.” (Para. 0024); “A method for two factor authentication for a blockchain transaction includes: storing a data pair including a public key of a first cryptographic key pair and an expected data value” (abstract)
As per Claim 4, Sharma teaches:
The method of claim 1, wherein the services on the blockchain include web3 services. (“In some embodiments, a smart contract may be used by to generate and provide the new expected data value back to the computing device 104 or directly to the sidechain node 114, where the smart contract executes open successful processing of the initial blockchain transaction.” (Para. 0028); “The methods and systems discussed herein culminate in an improved blockchain network 106 where two factor authentication can be successfully used without compromising decentralization or user anonymity via the use of a sidechain. In some cases, interaction with the sidechain and use of expected data values can be managed completely by a blockchain wallet in the user's computing device 104, enabling the second authentication factor to be used without requiring any additional input or actions performed by the user 102. In such cases, the user 102 may be protected against theft of their blockchain wallet's private key by behaving as normal due to the improvements made to the blockchain nodes 108 and user blockchain wallet discussed herein.” (Para. 0029).
As per Claim 5, Sharma teaches:
A system for multi-factor authentication for services on a blockchain, the system comprising: at least one blockchain; a customer smart contract is to be executed on the at least one blockchain; a multi-factor authentication provider smart contract configured to operate in the at least one blockchain; an oracle network comprising an oracle server, an oracle operator smart contract and an oracle interaction backend; a push-mode multi-factor authentication server, configured to hold an account of an end-user, the account being identifiable via an accountID; (“The blockchain nodes 108 may store a data pair associating the sidechain wallet information with the blockchain wallet, for use in identifying sidechain data values and performing the second factor authentication.” (Para. 0027); “In step 402, a data pair may be stored in a memory (e.g., the memory 226) of a blockchain node (e.g., the blockchain node 108) that includes at least a public key of a first cryptographic key pair and an expected data value. In step 404, a transaction request may be received by a receiver (e.g., the receiving device 202) of the blockchain node, wherein the transaction request includes at least a first digital signature, one or more input addresses, one or more output addresses, and at least one transaction amount. In step 406, a processed transaction may be identified by a processing device (e.g., the querying module 218) of the blockchain node in a sidechain that includes at least a destination address and a transaction data value, wherein the destination address is generated using the public key of the first cryptographic key pair.” (Para. 0046)
the push-mode multi-factor authentication server being an off-chain server that is not a part of the blockchain on which the services are being authenticated: (“For the second authentication factor, the blockchain node 108 may examine the sidechain to identify the most recent sidechain data value that includes a destination address generated using the user's blockchain wallet. In some embodiments, the user 102 may receive a sidechain transaction identifier from the sidechain node 114 when the sidechain data value is posted, which may be provided to the blockchain node 108 to expedite the identification process. Once the sidechain data value is identified, the blockchain node 108 may identify the expected data value included therein. The blockchain node 108 may then check the expected data value found in the sidechain data value against the expected data value received from the user 102 (e.g., or provided thereto by the blockchain node 108, as applicable). This check of the expected data value may be the second authentication factor, where, if the expected data values do not match, the blockchain transaction may not be processed. If the expected data values do match, and the first authentication factor is successful, then the blockchain transaction may be processed using standard methods and systems. The user 102 may thus successfully transaction on the blockchain using two factor authentication, where the second factor relies on the use of a sidechain without compromising the user's anonymity or the decentralized nature of the blockchain.” (Para. 0026)
wherein, in response to determining that an operation associated with the customer smart contract is to be executed on the at least one blockchain, the customer smart contract is configured to determine an off-chain multi-factor approval status of the end-user with the push-mode multi-factor authentication server, the determining comprising: (“The entry posted to the sidechain, referred to herein as a sidechain data value, may include at least a destination address that is generated using the user's blockchain wallet (e.g., the public key thereof) as well as an expected data value. The expected data value may be a digital token, password, data file, hash value, or any other value. For instance, in one example the user 102 may provide its own, custom expected data value through the computing device 104. In another example, the computing device 104 may generate a digital token, which may be a random or pseudo-random alphanumeric value. In yet another example, the user 102 may request, through the computing device 104, a digital token from a blockchain node 108 for use. The expected data value may be provided to a sidechain node 114 in the sidechain network 112 along with the destination address and a digital signature generated using the sidechain wallet in the computing device 104..” (Para. 0024); “In step 306, the sidechain node 114 may receive the sidechain transaction data. In step 308, the sidechain transaction may be processed. Processing of the sidechain transaction may include verification of the first digital signature using a public key of the user's sidechain wallet, the generation of a new sidechain data value that includes the transaction data, and the inclusion of the new sidechain data value in a newly generated block that is verified and added to the sidechain. In some embodiments, processing of the sidechain transaction may include transmitting a sidechain transaction identifier for the sidechain data value back to the computing device 104 using a suitable communication network and method. In step 310, the receiving device 202 of the blockchain node 108 may receive the new sidechain data value as part of the updating of the sidechain. In some cases, sidechain nodes 114 may actively push updated sidechain blocks to the blockchain node 108. In other cases, the blockchain node 108 may monitor the sidechain for updates and pull new blocks once they are added. The querying module 218 of the blockchain node 108 may execute a query on the memory 226 of the blockchain node 108 for storage of the sidechain data therein.” (Para. 0042);
based on determining that a mapping between a public key and the accountID exists, returning the accountiD, an address of an oracle server, and an integer that identifies a task in the oracle server using a multifactor authentication provider smart contract that is deployed on the at least one blockchain: (“For the second authentication factor, the blockchain node 108 may examine the sidechain to identify the most recent sidechain data value that includes a destination address generated using the user's blockchain wallet. In some embodiments, the user 102 may receive a sidechain transaction identifier from the sidechain node 114 when the sidechain data value is posted, which may be provided to the blockchain node 108 to expedite the identification process. Once the sidechain data value is identified, the blockchain node 108 may identify the expected data value included therein. The blockchain node 108 may then check the expected data value found in the sidechain data value against the expected data value received from the user 102 (e.g., or provided thereto by the blockchain node 108, as applicable). This check of the expected data value may be the second authentication factor, where, if the expected data values do not match, the blockchain transaction may not be processed. If the expected data values do match, and the first authentication factor is successful, then the blockchain transaction may be processed using standard methods and systems. The user 102 may thus successfully transaction on the blockchain using two factor authentication, where the second factor relies on the use of a sidechain