DETAILED ACTION
Acknowledgements
The claims filed 10/29/2025 are acknowledged.
Claims 1-5, 7-12, 14-19 and 21 are pending.
Claims 1-5, 7-12, 14-19 and 21 have been 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 .
Response to Amendments/Arguments
Regarding the rejection of the claims under 35 USC 103, applicant states that the prior art does not disclose “transmitting, to the second client application on the second user device, the encrypted payload for decryption by the second client application on the second user device using a second private key associated with the public key associated with the wallet address, wherein the decryption enables the second client application to perform blockchain transactions using the wallet address used by the first client application” because it does not disclose that a second client application is able to perform blockchain transactions using the wallet address used by the first client application.
Examiner notes, however, that Be’ery ‘942 discloses that the encrypted payload is transmitted to a second client application on the second user device for decryption (Be’ery ‘942 ¶¶ 59-60), wherein the decryption enables the second client application to perform transactions using the wallet address used by the first client application (Be’ery ‘942 ¶¶ 8, 54, 59-60, 67-68), because Be’ery ‘942 discloses that a user can recover their account on a new device if they have lost their computing device by decrypting the encrypted key shard (See, e.g., Be’ery ‘942 ¶ 60), and further discloses that the use of the key shards to perform blockchain transactions using a wallet (Be’ery ‘942 ¶¶ 8, 54, 59-60, 67-68). Thus, by recovering a user’s information on a second device when a first device is lost, the second device can perform blockchain transactions using the same wallet address as on the first device.
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.
Claims 1-3, 5, 7-10, 12, 14-17, 19, and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Beery, et al. (US 2022/0045867) (“Beery ‘867”) in view of Be’ery, et al. (US 2023/0299942) (“Be’ery ‘942”) and Aronesty, et al. (US 2021/0144002) (“Aronesty”).
Regarding claims 1, 8, and 15, Beery ‘867 discloses a method for data processing, an apparatus for data processing comprising: a processor; memory coupled with the processor; and instructions stored in the memory and executable by the processor to cause the apparatus to perform the method, and a non-transitory computer-readable medium storing code for data processing, the code comprising instructions executable by a processor to perform the method, the method comprising:
storing, at a custodial token platform, an indication of a second key shard of a first private key, wherein the first private key is divided into the first key shard and second key shard, wherein the custodial token platform is prevented from having access to an entirety of the first private key, and wherein the first private key corresponds to a wallet address used by a first client application for blockchain transactions (Beery ‘867 ¶¶ 8, 34, 38-39, 42, 44, 50, 62, 64);
receiving, at the custodial token platform on the one or more servers and from the first client application on a first user device, a partially signed message that is signed by the first client application using the first key shard stored at the first user device (Beery ‘867 ¶¶ 8, 39, 42-43, 49-50);
signing, at the custodial token platform on the one or more servers, the partially signed message using the second key shard stored at the one or more servers to generate a fully signed message (Beery ‘867 ¶¶ 8, 39, 42, 44, 49-50);
broadcasting, to a blockchain network supported distributed data store and after signing the partially signed message, the fully signed message for inclusion in a blockchain block, and wherein the fully signed message is verifiable by blockchain network nodes using a public key associated with the wallet address used by the first client application (Beery ‘867 ¶¶ 42, 44-45, 49-50, 62, 64);
receiving, at the custodial token platform on the one or more servers and from the first client application on the first user device, an encrypted payload that is encrypted using a public key associated with the client application on the user device, the encrypted payload including the first key shard (Beery ‘867 ¶¶ 65);
transmitting, to the client application on the user device, the encrypted payload for decryption by the client application on the user device using a second private key associated with the public key associated with the wallet address (Beery ‘867 ¶¶ 65-66).
Beery ‘867 does not specifically disclose that the indication of the second key shard is received at the custodial token platform from a first client application on a first user device, wherein the first private key is generated at the first user device. Beery ‘867 also does not specifically disclose that the key the encrypted payload is encrypted with is a public key associated with a second client application on a second user device, or that the encrypted payload is transmitted to a second client application on the second user device for decryption, wherein the decryption enables the second client application to perform transactions using the wallet address used by the first client application.
Be’ery ‘942 discloses that an encrypted payload is encrypted through the use of a public key associated with a second client application on a second user device, and that the encrypted payload is transmitted to a second client application on the second user device for decryption (Be’ery ‘942 ¶¶ 59-60), wherein the decryption enables the second client application to perform transactions using the wallet address used by the first client application (Be’ery ‘942 ¶¶ 8, 54, 59-60, 67-68).
Therefore, it would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify the method of Beery ‘867 to include an encrypted payload that is encrypted through the use of a public key associated with a second client application on a second user device, and transmitting the encrypted payload to a second client application on the second user device for decryption, wherein the decryption enables the second client application to perform transactions using the wallet address used by the first client application as disclosed in Be’ery ‘942, in order to allow a client to recover their account and information on a second device if they lose their first device (Be’ery ‘942 ¶ 60).
Be’ery ‘867 in view of Be’ery ‘942 does not specifically disclose that the indication of the second key shard is received at the custodial token platform from a first client application on a first user device, wherein the first private key is generated at the first user device.
Aronesty discloses receiving an indication of the second key shard at a platform from a first client application on a first user device, wherein the first private key is generated at the first user device (Aronesty ¶¶ 37, 41, 43-44, 53, 59, 63, 114, 125).
Therefore, it would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify the method of Beery ‘867 in view of Be’ery ‘942 to include receiving an indication of the second key shard at a platform from a first client application on a first user device, wherein the first private key is generated at the first user device, as disclosed in Aronesty, in order to allow for an originating device to generate the key shards and securely distribute them to the delegate devices that will use them (Aronesty ¶¶ 43-44, 53, 56, 59, 63).
Additionally, examiner notes that the language “wherein the first private key is generated at the first user device and divided into a first key shard and the second key shard,” “wherein the custodial token platform is prevented from having access to an entirety of the first private key” describes the intended use of the first user device and custodial token platform, but does not require any steps or functions to be performed within the scope of the claim. Further, the language “for inclusion in a blockchain block, and wherein the fully signed message is verifiable by blockchain network nodes using a public key associated with the wallet address used by the first client application” describes the intended use of the blockchain network, but also does not require any steps or functions to be performed within the scope of the claim. Additionally, the language “wherein the decryption enables the second client application to perform blockchain transactions using the wallet address used by the first client application” also only recites the intended use of the second client application, but does not require any steps or functions to be performed within the scope of the claim. Therefore, these limitations do not serve to differentiate the claims from the prior art. The recitation of the intended use of the claimed invention does not serve to differentiate the claim from the prior art. MPEP § 2103 I C states that language that suggests or makes optional but does not require steps to be performed or does not limit a claim to a particular structure does not limit the scope of a claim or claim limitation. An example of such language includes statements of intended use or field of use (MPEP §2103 I C).
Further, the language “wherein the first private key corresponds to a wallet address used by the first client application for blockchain transactions” describes characteristics of the first private key, which is data. However, as these particular characteristics are not processed or executed to carry out any functionality, this limitation recites nonfunctional descriptive material. When descriptive material is not functionally related to the substrate, the descriptive material will not distinguish the invention from prior art in terms of patentability. It has been held that where the printed matter is not functionally related to the substrate, the printed matter will not distinguish the invention from the prior art in terms of patentability …. [T]he critical question is whether there exists any new and unobvious functional relationship between the printed matter and the substrate (In re Ngai 367 F.3d 1336, 1339, 70 USPQ2d 1862 (Fed. Cir. 2004); Ex parte Nehls 88 USPQ2d 1883, 1888-1889 (BPAI 2008); In re Lowry, 32 USPQ2d 1031 (Fed. Cir. 1994); MPEP § 2111.05; Cf. In re Gulack, 703 F.2d 1381, 1385, 217 USPQ 401, 404 (Fed. Cir. 1983)).
Regarding claims 2, 9, and 16, Beery ‘867 discloses:
receiving, at the custodial token platform on the one or more servers and from the client application on the user device, a second partially signed message that is signed by the first key shard stored on the user device (Beery ‘867 ¶¶ 8, 39, 42-43, 49-50);
signing, at the custodial token platform on the one or more servers, the second partially signed message using the second key shard stored at the one or more servers to generate a second fully signed message that is verifiable by the blockchain network nodes (Beery ‘867 ¶¶ 8, 39, 42, 44, 49-50);
broadcasting, to the blockchain network supported distributed data store, the second fully signed message for inclusion in a second blockchain block, (Beery ‘867 ¶¶ 44-45, 49-50).
Beery ‘867 does not specifically disclose that the second partially signed message is received from a second client application on the second user device, and the first key shard is stored on the second user device, wherein the second fully signed message is verifiable by the blockchain network nodes using the public key associated with the wallet address used by the first client application.
Be’ery ‘942 discloses that the second partially signed message is received from a second client application on the second user device, and the first key shard is stored on the second user device (Be’ery ‘942 ¶¶ 59-60), wherein the second fully signed message is verifiable by the blockchain network nodes using the public key associated with the wallet address used by the first client application (Be’ery ‘942 ¶¶ 8, 54, 59-60, 67-68).
Therefore, it would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify the method of Beery ‘867 to include the second partially signed message being received from a second client application on the second user device, and the first key shard being stored on the second user device, wherein the second fully signed message is verifiable by the blockchain network nodes using the public key associated with the wallet address used by the first client application, as disclosed in Be’ery ‘942, in order to allow a client to recover their account and information on a second device if they lose their first device, (Be’ery ‘942 ¶ 60).
Additionally, examiner notes that the language “wherein the second fully signed message is verifiable by the blockchain network nodes using the public key associated with the wallet address used by the first client application,” describes the intended use of the blockchain network, but also does not require any steps or functions to be performed within the scope of the claim. Therefore, this limitations does not serve to differentiate the claims from the prior art. The recitation of the intended use of the claimed invention does not serve to differentiate the claim from the prior art. MPEP § 2103 I C states that language that suggests or makes optional but does not require steps to be performed or does not limit a claim to a particular structure does not limit the scope of a claim or claim limitation. An example of such language includes statements of intended use or field of use (MPEP §2103 I C).
Regarding claims 3, 10, and 17, Beery ‘867 discloses transmitting, with the encrypted payload and to the client application on the user device, the second key shard of the first private key (Beery ‘867 ¶¶ 67).
Beery ‘867 does not specifically disclose that the information is transmitted to a second client application on a second user device.
Be’ery ‘942 discloses that the information is transmitted to a second client application on a second user device (Be’ery ‘942 ¶¶ 59-60).
Therefore, it would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify the method of Beery ‘867 to include the information being transmitted to a second client application on a second user device, as disclosed in Be’ery ‘942, in order to allow a client to recover their account and information on a second device if they lose their first device (Be’ery ‘942 ¶ 60).
Regarding claims 5, 12, and 19, Beery ‘867 discloses that broadcasting the fully signed message comprises: broadcasting the fully signed message that is configured to cause transfer of a crypto token from the wallet address associated with the first client application to another wallet address via the blockchain network supported distributed data store (Beery ‘867 ¶¶ 38, 44-45).
Regarding claims 7 and 14, Beery ‘867 discloses generating, after receiving the encrypted payload, a copy of the second key shard, wherein the copy of the second key shard is used for signing partially signed messages received from the client application (Beery ‘867 ¶¶ 8, 38-39, 43-44, 49-50).
Beery ‘867 does not specifically disclose a second client application.
Be’ery ‘942 discloses a second client application (Be’ery ‘942 ¶¶ 59-60).
Therefore, it would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify the method of Beery ‘867 to include a second client application, as disclosed in Be’ery ‘942, in order to allow a client to recover their account and information on a second device if they lose their first device (Be’ery ‘942 ¶ 60).
Regarding claim 21, Be’ery ‘942 discloses wherein the encrypted payload supports use of the wallet address on the second user device without requiring seed phrase storage or mnemonic recovery (Be’ery ‘942 ¶¶ 8, 54, 59-60, 67-68).
Claims 4, 11 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Beery ‘867 in view of Be’ery ‘942 and Aronesty as applied to claims 1, 8, and 15 above, and further in view of Chen (US 2023/0068597).
Regarding claims 4, 11, and 18, Beery ‘867 in view of Be’ery ‘942 and Aronesty does not specifically disclose deleting, from the custodial token platform, the encrypted payload after transmitting the encrypted payload to the second client application.
Chen discloses deleting, from the custodial token platform, the encrypted payload after transmitting the encrypted payload to the second client application (Chen ¶¶ 43, 48, 66).
Therefore, it would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify the method of Beery ‘867 in view of Be’ery ‘942 and Aronesty to include deleting the encrypted payload after transmitting it to the second client application, as disclosed in Chen, in order to increase the security of the key shards and decrease the likelihood of them being compromised (Chen ¶ 66).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Machani (US 9,673,975) discloses a client obtaining a key share from a server to reconstruct a key (Machani Figure 11; 13:25-14:55).
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Mohammad A. Nilforoush whose telephone number is (571)270-5298. The examiner can normally be reached Monday-Friday 12pm-7pm.
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, John W. Hayes can be reached at 571-272-6708. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Mohammad A. Nilforoush/Primary Examiner, Art Unit 3697