DETAILED ACTION
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 .
Priority
Applicant’s claim for the benefit of a prior-filed application under 35 U.S.C. 119(e) or under 35 U.S.C. 120, 121, 365(c), or 386(c) is acknowledged.
Information Disclosure Statement
The information disclosure statement(s) (IDS) submitted on February 18, 2026, and May 26, 2026, is/are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement(s) has/have been considered by the examiner.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 2-8, 10-17, and 19-21 rejected under 35 U.S.C. 101 because the claimed invention is directed to abstract ideas without significantly more. There are two criteria for subject matter eligibility. The first is that the claimed invention must be to one of the four statutory categories, i.e., a process, machine, manufacture, or composition of matter. See MPEP 2106(I). Second, the claimed invention also must qualify as patent-eligible subject matter, i.e., the claim must not be directed to a judicial exception unless the claim as a whole includes additional limitations amounting to significantly more than the exception. See MPEP 2106(I). Here, claims 2-13 are directed towards a process and claims 14-21 are directed towards a machine. Therefore, the analysis proceeds to determine whether the claims recite abstract ideas.
Per Claim 2: Claim 2, as a whole, is directed towards the abstract idea of providing a new authentication key and authorizing a transaction to transfer funds from a first account to a second account. In particular, the claim recites receiving a request for an authentication key and verifying the request. The method then initiates a key rotation countdown and, after the countdown, sending a message based on contact information. The claim then authorizes a transaction to transfer funds from a first account to a second account. In other words, the claim recites both Mental Processes, such as verifying the key rotation request and initiating a countdown, as well as Certain Methods of Organizing Human Activities, such as authorizing a transaction to transfer funds, recognized as reciting abstract ideas. More specifically, the following underlined claim elements recite abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a).
receiving, at a cryptocurrency management server (CMS), a cryptocurrency management device (CMD) key rotation request for a two-factor authentication key of a cryptocurrency management system, wherein the cryptocurrency management system includes at least the CMS, a first CMD, and a mobile communication device (MCD) configured to manage cryptocurrency funds associated with a user account;
verifying the CMD key rotation request;
initiating a key rotation countdown, wherein the key rotation countdown is associated with a duration of time that is based on a security policy of the user account and the key rotation countdown is associated with the first CMD;
transmitting, after the duration of time of the key rotation countdown, one or more messages based on contact information associated with the user account; and
authorizing, based on the one or more messages, a transaction to transfer funds from a first cryptocurrency address associated with the first CMD to a second cryptocurrency address associated with a second CMD to restore the two-factor authentication key, wherein the second cryptocurrency address is associated with one or more private keys from the second CMD, the CMS, and the MCD.
Because the claim recites abstract ideas, the analysis proceeds to determine whether the claim recites additional elements that recite a practical application of the abstract ideas. According to MPEP 2106.04(d), additional elements that recite an instruction to apply the abstract ideas using a computer, that recite insignificant extra-solution activities, or that generally link the use of the abstract ideas to a particular technological environment or field of use are not indicative of a practical application. Here, the claim recites the additional elements of receiving a key rotation request for a two-factor authentication key, transmitting a message based on contact information associated with the user account, CMD, CMS, and MCD. Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., a fundamental economic practice or mathematical equation) does not integrate a judicial exception into a practical application or provide significantly more. See MPEP 2106.05(f). Here, the receiving and transmitting data amount to an instruction to apply the abstract idea. Further, the CMD, CMS, and MCD are computers that are being used to implement the abstract ideas; therefore, they also amount to an instruction to apply the abstract ideas. Therefore, the claim as a whole fails to recite a practical application of the abstract ideas.
The analysis then proceeds to determine whether the additional elements, when considered individually and in combination, recite significantly more than the abstract ideas. According to MPEP 2106.05, additional elements that recite an instruction to apply the abstract ideas using a computer, that recite insignificant extra-solution activities, that generally link the use of the abstract ideas to a particular technological environment or field of use, or that recite well-understood, routine, and conventional activities are not indicative of reciting significantly more than the abstract ideas. Claim elements previously considered to recite insignificant extra-solution activities are reevaluated at this step to determine whether they recite well-understood, routine, and conventional activities. Such findings must be supported by the evidentiary requirements set forth in the Berkheimer Memo. Here, the claim recites the additional elements of receiving a key rotation request for a two-factor authentication key, transmitting a message based on contact information associated with the user account, CMD, CMS, and MCD. As noted above, these are instructions to apply the abstract ideas. Therefore, the additional claim elements, when considered individually and in combination, fail to recite significantly more than the abstract ideas.
Accordingly, claim 2 is rejected as being directed towards patent ineligible subject matter.
Per Claim 5: Claim 5 recites abstract subject matter similar to that discussed above in connection with independent claim 2. However, claim 5 fails to recite any additional elements not already discussed above. Therefore, claim 5 also fails to recite a practical application of the abstract ideas or significantly more than the abstract ideas.
Accordingly, claim 5 is rejected as being directed towards patent ineligible subject matter.
Per Claim 14: Claim 14 recites abstract subject matter similar to that discussed above in connection with independent claim 2 and does so in the context of a system. Claim 14 recites the following additional elements not recited in independent claim 2:
one or more processors; a cryptocurrency management server (CMS); a first cryptocurrency management device (CMD); a second CMD; a mobile communication device (MCD); and a memory storing instructions which, when executed by the one or more processors, cause the system to:
However, these additional elements fail to recite a practical application of the abstract ideas or significantly more than the abstract ideas as they are computers, i.e., tools, that are used to implement the abstract ideas.
Accordingly, claim 14 is rejected as being directed towards patent ineligible subject matter.
Per Claims 3-4, 6-8, 10-13, 15-17, and 19-21: Claims 3-4, 6-8, 10-13, 15-17, and 19-21 have also been analyzed for subject matter eligibility. However, these claims also fail to recite patent eligible subject matter for the following reasons:
Claims 3, 6, and 15 recite the additional element that the key rotation request is initiated via a mobile application installed on the MCD. However, this fails to recite a practical application of the abstract ideas or significantly more than the abstract ideas as it amounts to an instruction to apply the abstract ideas using computers.
Claims 4, 7, and 16 recite the abstract idea of receiving authentication information and verifying the authentication information, which is a Certain Method of Organizing Human Activities.
Claims 8 and 17 recite the abstract idea of generating a key pair and signing a transaction, which is a Certain Method of Organizing Human Activities. The additional element of transmitting the new key pair fails to recite a practical application of the abstract ideas or significantly more than the abstract ideas as it recites an instruction to apply the abstract ideas. See MPEP 2106.05(f).
Claims 10 and 19 recite the abstract idea of verifying an authorization token is signed and if so, beginning the countdown, which is a Mental Process.
Claims 11 and 20 recite the abstract idea of verifying the authorization token is signed and if it is not, initiate additional verification procedures, which is a Certain Method of Organizing Human Activities.
Claims 12 and 21 recite receiving a cancellation notification and terminating the key rotation request, which is a Certain Method of Organizing Human Activities.
Claim 13 recites the abstract idea of receiving a second key rotation request and based on the second request and the cancellation, initiate additional verification procedures, which is a Certain Method of Organizing Human Activities.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 2-7, 12, 14-16, and 21 is/are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Pub. No. 2019/0220859 to Weight et al. in view of U.S. Patent Pub. No. 2020/0005282 to Kim.
Per Claim 2: Weight discloses:
A computer-implemented method for recovering a lost private key in a cryptocurrency management system, comprising: (see Weight at ¶ 24: FIG. 9A is a flow diagram illustrating an example method for restoring a customer wallet following the loss of the customer's private key using multi-sig)
receiving, at a cryptocurrency management server (CMS), a cryptocurrency management device (CMD) key rotation request for a two-factor authentication key of a cryptocurrency management system, wherein the cryptocurrency management system includes at least the CMS, a first CMD, and a mobile communication device (MCD) configured to manage cryptocurrency funds associated with a user account; (see Weight at ¶ 162: The currency conversion system 104 may receive 901, from a customer device 102, identity data for a customer and a request to restore a customer wallet. In examples, the identity data may include a customer's name, date of birth, driver's license number and expiration date, address, phone number(s), email address(es), social security number, image of customer's government issued photo identification, photo of the customer holding the government issued photo identification, employment information, and/or income. The identity data may also include biometric data, such as fingerprint data (e.g., scan(s) of the customer's fingerprint(s)), retinal scan data (e.g., image(s) of the customer's retina), facial recognition data (e.g., image(s) of the customer's face), and/or voice data (e.g., recording(s) of the customer's voice). Instead of raw biometric data (e.g., images and/or recordings), the identity data may include processed data derived from the raw biometric data, e.g., image features, voice features, etc.)
verifying the CMD key rotation request; (see Weight at ¶ 163: The currency conversion system 104 may verify 903 the identity data for the customer received from the customer device 102. In examples, verifying may include comparing received biometric data with previously stored biometric data, e.g., biometric data that was stored when the customer initially created their account with the currency conversion system 104.)
authorizing, based on the one or more messages, a transaction to transfer funds from a first cryptocurrency address associated with the first CMD to a second cryptocurrency address associated with a second CMD to restore the two-factor authentication key, wherein the second cryptocurrency address is associated with one or more private keys from the second CMD, the CMS, and the MCD. (see Weight at ¶ 186: Digital assets may also be transferred 1005 from the old (lost) customer wallet to the new transaction address, e.g., signing the transaction using a first key (from the trusted third party 106) and a second key (from the currency conversion system 104). This may include the customer device 102, currency conversion system 104, and/or the trusted third party 106 transmitting a request to the asset exchange 108 (or other nodes with access to the distributed ledger 118) to record a change of ownership from the old customer wallet to the new transaction address. The request to record a change of ownership may require signatures using M/N (e.g., 2/3) of the new private keys or M/N (e.g., 2/3) of the old private keys. Therefore, the device generating/sending the request may be required to verify that it already possesses one or more old private keys and/or has received one or more old private keys from other device(s) before it signs the request, i.e., the generating/sending device may be required to verify that it possesses M/N (e.g., 2/3) of the old private keys before it signs the request.)
However, Weight fails to disclose but Kim, an analogous art of cryptocurrency wallet recovery, discloses:
initiating a key rotation countdown, wherein the key rotation countdown is associated with a duration of time that is based on a security policy of the user account and the key rotation countdown is associated with the first CMD; (see Kim at ¶ 86: Notifying an owner of the wallet S500 functions to notify a wallet owner that wallet access (or ownership) has been challenged. S500 preferably includes transmitting a notification to a notification endpoint using a notification method. In some variations, S500 includes transmitting a notification at least one owner device (e.g., 231) associated with the wallet, or user device associated with the user account, during the challenge period (waiting period). The notification can include: a challenge initiation notification, a wallet identifier, an abort option (e.g., an abort icon, a set of challenge abort instructions, etc.), an accept option, or any other suitable information. The notification endpoint preferably includes one or more devices (e.g., 231) (e.g., multiple devices) associated with the owner(s) of the wallets, but can additionally or alternatively include: user accounts (e.g., on the third party platform, on secondary platforms, etc.), smart contracts (e.g., on the blockchain system), or any other suitable endpoint. Examples of notification endpoints include: mobile device clients, browser clients, phones, smartwatches, or any suitable endpoint. The notification method can include: email, SMS, push notifications, audiovisual notifications, phone calls, or any other suitable notification method. See also ¶ 53: The challenge period can be specified at wallet setup, specified with a request signed by the owner keys, specified with a request signed by the recovery key(s), be a predetermined duration (e.g., no challenge period, 30 minutes, 60 minutes, 30 days, 60 days, etc.), or be any other suitable period.)
transmitting, after the duration of time of the key rotation countdown, one or more messages based on contact information associated with the user account; and (see Kim at ¶ 88: S500 is preferably performed in response to S200, but can alternatively be performed before, after, in response to, or contemporaneously with S100, S300, or S400, or at any suitable time. The notification is preferably transmitted during the challenge period or until a challenge termination condition is met, wherein owner notifications cease upon challenge period termination. However, the notification can be transmitted after the challenge period, or for any suitable period of time.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Weight so that a waiting/challenge period is required before transferring cryptocurrency to another address/wallet using the techniques disclosed in Kim. One of ordinary skill in the art would have been motivated to do so enable owners time to abort the recovery process if an attacker manages to initiate the recovery process (see Kim at ¶ 25).
Per Claim 5: Weight discloses:
A computer-implemented method, comprising: (see Weight at ¶ 24: FIG. 9A is a flow diagram illustrating an example method for restoring a customer wallet following the loss of the customer's private key using multi-sig)
receiving, at a cryptocurrency management server (CMS), a key rotation request; (see Weight at ¶ 162: The currency conversion system 104 may receive 901, from a customer device 102, identity data for a customer and a request to restore a customer wallet. In examples, the identity data may include a customer's name, date of birth, driver's license number and expiration date, address, phone number(s), email address(es), social security number, image of customer's government issued photo identification, photo of the customer holding the government issued photo identification, employment information, and/or income. The identity data may also include biometric data, such as fingerprint data (e.g., scan(s) of the customer's fingerprint(s)), retinal scan data (e.g., image(s) of the customer's retina), facial recognition data (e.g., image(s) of the customer's face), and/or voice data (e.g., recording(s) of the customer's voice). Instead of raw biometric data (e.g., images and/or recordings), the identity data may include processed data derived from the raw biometric data, e.g., image features, voice features, etc.)
verifying the key rotation request; (see Weight at ¶ 163: The currency conversion system 104 may verify 903 the identity data for the customer received from the customer device 102. In examples, verifying may include comparing received biometric data with previously stored biometric data, e.g., biometric data that was stored when the customer initially created their account with the currency conversion system 104.)
authorizing, based on the one or more messages, a transaction to transfer funds from a first cryptocurrency address associated with the first CMD to a second cryptocurrency address associated with a second CMD, wherein the second cryptocurrency address is associated with one or more private keys from the second CMD, the CMS, and a mobile communication device (MCD). (see Weight at ¶ 186: Digital assets may also be transferred 1005 from the old (lost) customer wallet to the new transaction address, e.g., signing the transaction using a first key (from the trusted third party 106) and a second key (from the currency conversion system 104). This may include the customer device 102, currency conversion system 104, and/or the trusted third party 106 transmitting a request to the asset exchange 108 (or other nodes with access to the distributed ledger 118) to record a change of ownership from the old customer wallet to the new transaction address. The request to record a change of ownership may require signatures using M/N (e.g., 2/3) of the new private keys or M/N (e.g., 2/3) of the old private keys. Therefore, the device generating/sending the request may be required to verify that it already possesses one or more old private keys and/or has received one or more old private keys from other device(s) before it signs the request, i.e., the generating/sending device may be required to verify that it possesses M/N (e.g., 2/3) of the old private keys before it signs the request.)
However, Weight fails to disclose but Kim discloses:
initiating a key rotation countdown, wherein the key rotation countdown is associated with a duration of time that is based on a security policy of a user account and the key rotation countdown is associated with a first cryptocurrency management device (CMD); (see Kim at ¶ 86: Notifying an owner of the wallet S500 functions to notify a wallet owner that wallet access (or ownership) has been challenged. S500 preferably includes transmitting a notification to a notification endpoint using a notification method. In some variations, S500 includes transmitting a notification at least one owner device (e.g., 231) associated with the wallet, or user device associated with the user account, during the challenge period (waiting period). The notification can include: a challenge initiation notification, a wallet identifier, an abort option (e.g., an abort icon, a set of challenge abort instructions, etc.), an accept option, or any other suitable information. The notification endpoint preferably includes one or more devices (e.g., 231) (e.g., multiple devices) associated with the owner(s) of the wallets, but can additionally or alternatively include: user accounts (e.g., on the third party platform, on secondary platforms, etc.), smart contracts (e.g., on the blockchain system), or any other suitable endpoint. Examples of notification endpoints include: mobile device clients, browser clients, phones, smartwatches, or any suitable endpoint. The notification method can include: email, SMS, push notifications, audiovisual notifications, phone calls, or any other suitable notification method. See also ¶ 53: The challenge period can be specified at wallet setup, specified with a request signed by the owner keys, specified with a request signed by the recovery key(s), be a predetermined duration (e.g., no challenge period, 30 minutes, 60 minutes, 30 days, 60 days, etc.), or be any other suitable period.)
transmitting, after the duration of time of the key rotation countdown, one or more messages based on contact information associated with the user account; and (see Kim at ¶ 88: S500 is preferably performed in response to S200, but can alternatively be performed before, after, in response to, or contemporaneously with S100, S300, or S400, or at any suitable time. The notification is preferably transmitted during the challenge period or until a challenge termination condition is met, wherein owner notifications cease upon challenge period termination. However, the notification can be transmitted after the challenge period, or for any suitable period of time.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Weight so that a waiting/challenge period is required before transferring cryptocurrency to another address/wallet using the techniques disclosed in Kim. One of ordinary skill in the art would have been motivated to do so enable owners time to abort the recovery process if an attacker manages to initiate the recovery process (see Kim at ¶ 25).
Per Claim 14: Weight discloses:
A system for recovering a lost private key, comprising: (see Weight at Abstract: A computing system that includes at least one processor and at least one memory communicatively coupled to the at least one processor is disclosed.)
one or more processors; (see Weight at Abstract: A computing system that includes at least one processor and at least one memory communicatively coupled to the at least one processor is disclosed.)
a cryptocurrency management server (CMS); (see Weight at ¶ 59: The currency conversion system 104 may be a bank or non-bank financial institution that converts currency into other forms of currency, e.g., a money services business (MSB).)
a first cryptocurrency management device (CMD); (see Weight at ¶ 62: The trusted third party 106 may be a financial institution. In examples, the trusted third party 106 may be implemented using one or more computing devices that are trusted that are trusted to verify transactions between two parties.)
a second CMD; (see Weight at ¶ 62: The trusted third party 106 may be a financial institution. In examples, the trusted third party 106 may be implemented using one or more computing devices that are trusted that are trusted to verify transactions between two parties.)
a mobile communication device (MCD); and (see Weight at ¶ 58: In examples, the customer device 102 may be a mobile device, e.g., using the Android® or iOS® operating systems.)
a memory storing instructions which, when executed by the one or more processors, cause the system to: (see Weight at Abstract: A computing system that includes at least one processor and at least one memory communicatively coupled to the at least one processor is disclosed.)
receive, at the CMS, a key rotation request; (see Weight at ¶ 162: The currency conversion system 104 may receive 901, from a customer device 102, identity data for a customer and a request to restore a customer wallet. In examples, the identity data may include a customer's name, date of birth, driver's license number and expiration date, address, phone number(s), email address(es), social security number, image of customer's government issued photo identification, photo of the customer holding the government issued photo identification, employment information, and/or income. The identity data may also include biometric data, such as fingerprint data (e.g., scan(s) of the customer's fingerprint(s)), retinal scan data (e.g., image(s) of the customer's retina), facial recognition data (e.g., image(s) of the customer's face), and/or voice data (e.g., recording(s) of the customer's voice). Instead of raw biometric data (e.g., images and/or recordings), the identity data may include processed data derived from the raw biometric data, e.g., image features, voice features, etc.)
verify the key rotation request; (see Weight at ¶ 163: The currency conversion system 104 may verify 903 the identity data for the customer received from the customer device 102. In examples, verifying may include comparing received biometric data with previously stored biometric data, e.g., biometric data that was stored when the customer initially created their account with the currency conversion system 104.)
authorize, based on the one or more messages, a transaction to transfer funds from a first cryptocurrency address associated with the first CMD to a second cryptocurrency address associated with the second CMD, wherein the second cryptocurrency address is associated with one or more private keys from the second CMD, the CMS, and the MCD. (see Weight at ¶ 186: Digital assets may also be transferred 1005 from the old (lost) customer wallet to the new transaction address, e.g., signing the transaction using a first key (from the trusted third party 106) and a second key (from the currency conversion system 104). This may include the customer device 102, currency conversion system 104, and/or the trusted third party 106 transmitting a request to the asset exchange 108 (or other nodes with access to the distributed ledger 118) to record a change of ownership from the old customer wallet to the new transaction address. The request to record a change of ownership may require signatures using M/N (e.g., 2/3) of the new private keys or M/N (e.g., 2/3) of the old private keys. Therefore, the device generating/sending the request may be required to verify that it already possesses one or more old private keys and/or has received one or more old private keys from other device(s) before it signs the request, i.e., the generating/sending device may be required to verify that it possesses M/N (e.g., 2/3) of the old private keys before it signs the request.)
However, Weight fails to disclose but Kim discloses:
initiate a key rotation countdown, wherein the key rotation countdown is associated with a duration of time that is based on a security policy of a user account and the key rotation countdown is associated with the first CMD; (see Kim at ¶ 86: Notifying an owner of the wallet S500 functions to notify a wallet owner that wallet access (or ownership) has been challenged. S500 preferably includes transmitting a notification to a notification endpoint using a notification method. In some variations, S500 includes transmitting a notification at least one owner device (e.g., 231) associated with the wallet, or user device associated with the user account, during the challenge period (waiting period). The notification can include: a challenge initiation notification, a wallet identifier, an abort option (e.g., an abort icon, a set of challenge abort instructions, etc.), an accept option, or any other suitable information. The notification endpoint preferably includes one or more devices (e.g., 231) (e.g., multiple devices) associated with the owner(s) of the wallets, but can additionally or alternatively include: user accounts (e.g., on the third party platform, on secondary platforms, etc.), smart contracts (e.g., on the blockchain system), or any other suitable endpoint. Examples of notification endpoints include: mobile device clients, browser clients, phones, smartwatches, or any suitable endpoint. The notification method can include: email, SMS, push notifications, audiovisual notifications, phone calls, or any other suitable notification method. See also ¶ 53: The challenge period can be specified at wallet setup, specified with a request signed by the owner keys, specified with a request signed by the recovery key(s), be a predetermined duration (e.g., no challenge period, 30 minutes, 60 minutes, 30 days, 60 days, etc.), or be any other suitable period.)
transmit, after the duration of time of the key rotation countdown, one or more messages based on contact information associated with the user account; and (see Kim at ¶ 88: S500 is preferably performed in response to S200, but can alternatively be performed before, after, in response to, or contemporaneously with S100, S300, or S400, or at any suitable time. The notification is preferably transmitted during the challenge period or until a challenge termination condition is met, wherein owner notifications cease upon challenge period termination. However, the notification can be transmitted after the challenge period, or for any suitable period of time.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Weight so that a waiting/challenge period is required before transferring cryptocurrency to another address/wallet using the techniques disclosed in Kim. One of ordinary skill in the art would have been motivated to do so enable owners time to abort the recovery process if an attacker manages to initiate the recovery process (see Kim at ¶ 25).
Per Claims 3, 6, and 15: The combination of Weight and Kim discloses the subject matter of claims 2, 5, and 14, from which claims 3, 6, and 15 depend, respectively. Weight further discloses:
wherein the CMD key rotation request is initiated by the MCD via a mobile application installed locally on the MCD. (see Weight at ¶ 58: A customer may download, to the customer device 102, an application corresponding to the currency conversion system 104. The application may present a user interface on the customer device 102, and the customer may provide input using the user interface. Based at least in part on the user input, the application on the customer device 102 may send and receive instructions and/or other data to the currency conversion system 104. In examples, the application on the customer device 102 may only communicate directly with the currency conversion system 104, which communicates with other devices in the system 100, i.e., the currency conversion system 104 may be a gateway to other devices in the system 100. Alternatively, the application on the customer device 102 may communicate directly with the trusted third party 106, the currency conversion system 104, and/or other devices in the system 100.)
Per Claims 4, 7, and 16: The combination of Weight and Kim discloses the subject matter of claims 2, 5, and 14, from which claims 4, 7, and 16 depend, respectively. Weight further discloses:
receiving, at the CMS, authenticating information associated with a user of the user account associated with the first CMD; and (see Weight at ¶ 162: The currency conversion system 104 may receive 901, from a customer device 102, identity data for a customer and a request to restore a customer wallet. In examples, the identity data may include a customer's name, date of birth, driver's license number and expiration date, address, phone number(s), email address(es), social security number, image of customer's government issued photo identification, photo of the customer holding the government issued photo identification, employment information, and/or income. The identity data may also include biometric data, such as fingerprint data (e.g., scan(s) of the customer's fingerprint(s)), retinal scan data (e.g., image(s) of the customer's retina), facial recognition data (e.g., image(s) of the customer's face), and/or voice data (e.g., recording(s) of the customer's voice). Instead of raw biometric data (e.g., images and/or recordings), the identity data may include processed data derived from the raw biometric data, e.g., image features, voice features, etc.)
verifying an authenticity of the authenticating information. (see Weight at ¶ 163: The currency conversion system 104 may verify 903 the identity data for the customer received from the customer device 102. In examples, verifying may include comparing received biometric data with previously stored biometric data, e.g., biometric data that was stored when the customer initially created their account with the currency conversion system 104.)
Per Claims 12 and 21: The combination of Weight and Kim discloses the subject matter of claims 5 and 14, from which claims 12 and 21 depend, respectively. However, Weight fails to disclose but Kim discloses:
receiving, at the CMS, a cancellation notification prior to an end of the duration of time; and (see Kim at ¶ 58: The abort condition functions to prematurely terminate the challenge period (waiting period), and can function to halt owner account replacement or addition to the wallet. Examples of an abort condition can include: receiving an abort message signed by the recovery address (e.g., recovery key) or one or more owner accounts (e.g., old owner accounts; old owner keys), receiving a transaction signed by a predetermined number of the owner accounts (e.g., old owner accounts, old owner keys), or any suitable abort condition. The abort conditions can be specified by the owner accounts (e.g., received in a message signed by a threshold number of owner accounts), specified by a user account (e.g., wherein the wallet receives the abort conditions in a message from the user account that is signed by the recovery account), specified by default, or otherwise determined.)
terminating the key rotation request in response to receipt of the cancellation notification. (see Kim at ¶ 58: The abort condition functions to prematurely terminate the challenge period (waiting period), and can function to halt owner account replacement or addition to the wallet. Examples of an abort condition can include: receiving an abort message signed by the recovery address (e.g., recovery key) or one or more owner accounts (e.g., old owner accounts; old owner keys), receiving a transaction signed by a predetermined number of the owner accounts (e.g., old owner accounts, old owner keys), or any suitable abort condition. The abort conditions can be specified by the owner accounts (e.g., received in a message signed by a threshold number of owner accounts), specified by a user account (e.g., wherein the wallet receives the abort conditions in a message from the user account that is signed by the recovery account), specified by default, or otherwise determined.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Weight so that a wallet recovery process may be aborted using the techniques disclosed in Kim. One of ordinary skill in the art would have been motivated to do so to enable a user to cancel an erroneous recovery process.
Claim(s) 8 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Weight and Kim as applied to claims 2 and 5 above, and further in view of U.S. Patent Pub. No. 2015/0324789 to Dvorak.
Per Claims 8 and 17: The combination of Weight and Kim discloses the subject matter of claims 5 and 14, from which claims 8 and 17 depend, respectively. However, the combination of Weight and Kim fails to disclose but Dvorak, an analogous art of cryptocurrency wallets, discloses:
generating, at the CMS, a new key pair; (see Dvorak at ¶ 59: Since bitcoin transactions are publicly visible on the block chain ledger, many users generate a new private encryption key, and therefore a new public bitcoin address, for each transaction so that the full balance of their bitcoin wallet isn't known to those they transact with. These encryption keys may be generated randomly or they may be derived from a master key.)
transmitting the new key pair to the MCD, wherein the MCD, in response to receipt of the new key pair and receipt of a new public key associated with the second CMD, generates the transaction; and (see Dvorak at ¶ 112: User account server 52 stores an RSA public key in the device database 54 and sends an encrypted RSA private key to the user with an authorization code via the web server 56. See also ¶ 122: Continuing the process, user account server 52 may send public key 1, public key 2 and public key 3 as well as a device ID to wallet server 46.)
signing the transaction with a private key of the new key pair, wherein the MCD and the second CMD also sign the transaction with corresponding private keys. (see Dvorak at ¶ 21: When you swipe your finger to confirm a transaction, the secure device signs the transaction with its embedded private key and sends the partially signed transaction along with a fingerprint scan to a server. The second private key is stored server-side and if the fingerprint scan is a match, the server countersigns the transaction with the second private key and broadcasts a multi-signed transaction to a cryptocurrency network, such as the Bitcoin network.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Weight so that multiple devices are required to sign a transaction using the techniques disclosed in Dvorak. One of ordinary skill in the art would have been motivated to do so to increase the security of the transaction.
Allowable Subject Matter
Claims 9 and 18 objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
The following is a statement of reasons for the indication of allowable subject matter: the subject matter of dependent claims 9 and 18, in combination with the claim limitations recited in the respective independent claims was not found in a single reference or reasonable combination of references in the prior art.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
U.S. Patent Pub. No. 2019/0236594 discloses a system and method for bootstrapping a cryptographic ledger based on stake in a fiat currency. Stake can be verified using proof of cash systems involving anti-spoofing, anti-counterfeiting, and remote verification and transaction functionality. Stake can further or otherwise be verified using proof of balance systems involving verification of one or more balances using a service of a financial institution or data provider. These systems, together or separately, can be utilized to implement a cryptographic currency and application platform enabling financial transaction and general computing capabilities, in accordance with various embodiments of the invention.
U.S. Patent Pub. No. 2005/0123142 discloses a method, and a corresponding apparatus, provide for remote, secure replacement of private keys in a private key infrastructure. The method is implemented as a secure key replacement protocol (SKRP), which includes the steps of receiving a rekey request, where the rekey request identifies a private key for replacement, authenticating the rekey request, replacing the identified private key with a SKRP key, signing the challenge with the SKRP key, and returning the signed challenge. The rekey request includes the SKRP key and the challenge.
U.S. Patent Pub. No. 2022/0224530 discloses a system for restoring a lost private key. More specifically, in the system, an extra private key is split into a plurality of parts, the parts are double-encrypted and stored in external servers, and when a key used has been lost, the pieces of the private key are downloaded from the respective servers through authentication and decrypted for use. The system includes at least: a terminal that generates a reference key when a driving signal is input, converts the reference key to an encryption key, splits the encryption key into a plurality of parts to generate a plurality of the partial encryption keys, performs secondary encryption on one of the partial encryption keys with a preset authentication code, and receives and decrypts the partial encryption keys stored in the server unit when a loss signal is input from outside.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NILESH B KHATRI whose telephone number is (571)270-7083. The examiner can normally be reached 8:30 AM - 5:30 PM Monday-Friday, alternating Fridays off.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Neha Patel can be reached at (571) 270-1492. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/NILESH B KHATRI/Primary Examiner, Art Unit 3699
Prosecution Insights