DETAILED ACTION
Acknowledgements
This office action is in response to the claims filed 07/06/2026.
Claims 1-21 are cancelled.
Claims 22, 23 and 26 are amended.
Claims 22-34 are pending.
Claims 22-34 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 .
Specification
The disclosure is objected to because of the following informalities: Paragraph 88 recites “FIG. 2 shows illustrative system 200. System 200 shows that password generation app 105 uses authentication token 105 to generate dynamic password 201.” The authentication token has been demarcated as element 103 and it is not element 105. Appropriate correction is required.
Response to Arguments
Applicant's arguments filed 07/06/2026 have been fully considered but they are not persuasive.
101
Due to Applicant’s amendments, prior rejections are withdrawn.
112
There is a lack of clarity and conflation of entities and terms within the claims that create various 112 rejections, a showing of disclosure support paragraphs for the drafted limitations can provide clarity of Applicant’s intention and address the rejections. The dependent claims contain further 112 rejections that continue those in the independent claims.
103
Yau teaches securing access to a password generation application via a frontend lock-box application, wherein the frontend lock-box application stores the authentication token corresponding to the private cryptographic key (¶ 180-188, 215-225, 258, 423-441): storing a public cryptographic key paired to the private cryptographic key via a backend lock-box application that links the first protected cryptocurrency conversion service to the authentication token stored in the frontend lock-box application(¶ 368-372, 387-396).
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 22-34 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claim 22 recites “in response to receiving the request, detecting username input field and password input field on a webpage hosting the first protected cryptocurrency conversion service and triggering activation of a secure application program interface (API) accessible via the webpage…” According to the disclosure(¶ 67, 100, 101), “the method may include accessing a webpage hosting the protected service. The method may include identifying a username input field on the webpage. The method may include identifying a password input field on the webpage. In response to identifying the username and password input fields, the method may include triggering activation of a secure application program interface (“API”). … At step 2, in response to the request for access, webpage 501 is presented. Webpage 501 requires entry of a username and password to access the requested protected services 109…. in response to detecting webpage 501, API 205 uses authentication token 103 to bypass webpage 501 and the conventional requirement to enter a username and password to access the requested protected services 109.” The disclosure provides support for detecting a webpage and identifying the username and password input fields on a webpage. The disclosure does not provide written description support for “in response to receiving the request, detecting username input field and password input field on a webpage hosting the first protected cryptocurrency conversion service.” Dependent claims 23-34 are also rejected.
Claim 22 recites “transmitting, via the secure API, a request to obtain a biometric authentication … receiving the biometric authentication and using the biometric authentication to access an authentication token stored in a digital wallet on a second protected service, wherein the authentication token corresponds to a private cryptographic key” According to the disclosure(¶ 11, 73, 78-80, 85, 94), “The first app may require a biometric authentication before activating the secure API and submitting the authentication token to access the protected service using the target user profile… the API may require biometric authentication before using the username and password associated with the second protected application to access the authentication token…the API may require biometric authentication before using the username and password associated with the second protected application to access the authentication token.” The disclosure provides for the API “requiring” biometric authentication before using a username and password. The disclosure does not provide for transmitting a request, via an API, to obtain biometric authentication. Secondly, ta username and password are what are needed to “access an authentication token stored in a digital wallet on a second protected service” not the receipt of biometric authentication. The disclosure does not provide written description support for “transmitting, via the secure API, a request to obtain a biometric authentication … receiving the biometric authentication and using the biometric authentication to access an authentication token stored in a digital wallet on a second protected service….” Dependent claims 23-34 are also rejected.
Claim 22 recites “receiving the biometric authentication and using the biometric authentication to access an authentication token stored in a digital wallet on a second protected service, wherein the authentication token corresponds to a private cryptographic key…securing access to a password generation application via a frontend lock-box application, wherein the frontend lock-box application stores the authentication token corresponding to the private cryptographic key….” According to the disclosure(¶ 34-39, 51, 52, 92, 93), “The frontend lock-box application may store an authentication token. The frontend lock-box application may be a digital wallet.” The disclosure provides for the front-end lock-box to be a digital wallet. The disclosure does not provide for a separate digital wallet that contains an authentication wallet and a frontend lock-box application that also contains the same authentication token. The disclosure does not provide written description support for “receiving the biometric authentication and using the biometric authentication to access an authentication token stored in a digital wallet on a second protected service, wherein the authentication token corresponds to a private cryptographic key…securing access to a password generation application via a frontend lock-box application, wherein the frontend lock-box application stores the authentication token corresponding to the private cryptographic key.” Dependent claims 23-34 are also rejected.
Claim 22 recites “autogenerating a dynamic password using the authentication token as a seed, wherein the dynamic password comprises a digital signature generated by: inputting a message into a hash function to produce a hash value….” According to the disclosure(Figure 1; ¶ 27, 85-88, 97-99), “System 100 includes mobile device 101. Mobile device 101 may include one or more apps for accessing protected services 109. …System 100 includes password generation application 105. password generation application 105 may autogenerate a dynamic password using authentication token 103.” The disclosure provides a system that includes a mobile device and a password generation application that autogenerates a dynamic password, the disclosure does not describe the password generation application as part of the mobile device nor that the mobile device is capable of autogenerating a dynamic password. The disclosure does not provide support for a mobile device autogenerating a dynamic password using the authentication token as a seed, wherein the dynamic password comprises a digital signature generated by: inputting a message into a hash function to produce a hash value. Dependent claims 23-34 are also rejected.
Claim 22 recites “transmitting credentials comprising the digital signature to a password validation application comprising a first smart contract operating on a distributed ledger….” According to the disclosure(Figure 1; ¶ 89-94),” Dynamic password validation app 107 may use API 205 to interact with protected services 109. API 205 may facilitate access to protected services 109 using validation of dynamic password 201 provided by dynamic password validation app 107. API 205 may interact with smart contracts that control access to protected services 109. In some embodiments, the smart contracts may involve cryptocurrency conversion applications. The smart contracts may be programmed to allow access to protected services 109 when dynamic password 201 is validated by dynamic password validation app 107.….” The disclosure discusses using an API to interact with a smart contract. The disclosure does not provide written description support for the password validation application comprising a first smart contract operating on a distributed ledger. Dependent claims 23-34 are also rejected.
Claim 22 recites “in response to validating the dynamic password, activating the first protected cryptocurrency conversion service based on programming in the second smart contract that grants access to the first protected cryptocurrency conversion service.” According to the disclosure(Figure 1; ¶ 70-73, 81-98), “When dynamic password 201 is successfully validated by password validation app 107, backend lock-box app 303 may activate protected services 109 using user profile 305. In certain embodiments, protected services 109 may include a crypto-currency conversion application… before the API submits credentials to the second protected application, the API may check whether the first protected application has been activated by the second protected application. When the first application has been activated by the second protected application, an entry may be made to a smart contract… The smart contracts may be programmed to allow access to protected services 109 when dynamic password 201 is validated by dynamic password validation app 107.” The disclosure describes when the password is validated, the backend lock-box app may activate protected services using user profile or the smart contract allowing access. The disclosure does not provide written description support for in response to validating the dynamic password, activating the first protected cryptocurrency conversion service based on programming in the second smart contract that grants access to the first protected cryptocurrency conversion service. Dependent claims 23-34 are also rejected.
Claims 23, 26 and 28 recite providing “enhanced security”. According to the disclosure(¶ 8), “It would be further desirable to provide enhanced security systems for protecting cryptocurrency conversion utilities.” This is the only mention of “enhanced security” in the entire disclosure, and the mention pertains to it being a desire, not an achieved result as claimed. The disclosure does not provide support for the limitations in claim 23, “wherein the frontend lock-box application and backend lock-box application operate as part of an authentication sequence by separating token storage from service linking to provide enhanced security for cryptocurrency conversion service access”, claim 26 “wherein the first protected cryptocurrency conversion service comprises a decentralized application operating on a publicly accessible distributed ledger, wherein the decentralized application operating on the publicly accessible distributed ledger provides enhanced security compared to centralized authentication servers” and claim 28, “wherein the first communication channel and the second communication channel using separate private cryptographic keys provide enhanced security as part of an authentication sequence”.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 22-34 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Claim 22 recites “receiving the biometric authentication and using the biometric authentication to access an authentication token stored in a digital wallet on a second protected service, wherein the authentication token corresponds to a private cryptographic key… securing access to a password generation application via a frontend lock-box application… storing a public cryptographic key paired to the private cryptographic key via a backend lock-box application”. The claims are unclear and indefinite. First, the claims are unclear whether the “mobile device” is the single entity enacting the claimed method. It is unclear whether the interface, wallet, protected services and applications are located on the mobile device or are part of remote systems, if remote, the claims are missing essential entities to the claims. The claims are unclear and indefinite.
Claim 22 recites “receiving, at a mobile device, a request for access to the first protected cryptocurrency conversion service… autogenerating a dynamic password using the authentication token as a seed, wherein the dynamic password comprises a digital signature generated by: inputting a message into a hash function to produce a hash value…” The claims are unclear and indefinite. First, the claims are unclear whether the “mobile device” is the single entity enacting the claimed method. The claims are unclear and indefinite. Dependent claims 23-34 are also rejected.
Claim 22 recites “transmitting credentials comprising the digital signature to a password validation application comprising a first smart contract operating on a distributed ledger ….”. The claim is unclear and indefinite. The claim is unclear as to whether the limitation is claiming the password validation app comprises a smart contract that is operating on the distributed ledger. Dependent claims 23-34 are also rejected.
Similarly claim 25, recite “provides secure storage for the authentication token as part of an authentication sequence….” The claims are unclear and indefinite. The limitations already claim that the recited steps perform Applicant’s intended result as part of the claims. The claim is unclear and indefinite in whether the Applicant can claim a proposed conclusion as part of a proposed claim limitation and omitting whatever essential steps that guarantee the recited conclusion can be part of the proposed claims.
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 22-34 are rejected under 35 U.S.C. 103 as being unpatentable over Yau et al. (US 20160261411) (“Yau”), and further in view of Ashbrook et al. (US 20150222957) (Ashbrook).
Regarding claim 22, discloses receiving, at a mobile device, a request for access to the first protected cryptocurrency conversion service; in response to receiving the request, detecting username input field and password input field on a webpage hosting the first protected cryptocurrency conversion service (¶ 42-45, 97-102, 127-133, 265-277, 284-293, 398, 411, 413, 418-421, 458-462, 467);
transmitting, via the secure API, a request to obtain a biometric authentication comprising facial recognition, iris recognition, retina recognition, or fingerprint recognition (¶ 395-400, 447-458);
receiving the biometric authentication and using the biometric authentication to access an authentication token stored in a digital wallet on a second protected service, wherein the authentication token corresponds to a private cryptographic key(¶ 82, 94-102, 180-186, 262-264, 389-403):
Claim Interpretation – Disclosure(¶ 9, 78), “The system contains an authentication token stored on a mobile device within a digital wallet. A second protected application that runs on the mobile device is secured by a username and password… After the API is activated, the API may be programmed to use the username and password associated with the second protected application to access the authentication token stored in the digital wallet. ”
securing access to a password generation application via a frontend lock-box application, wherein the frontend lock-box application stores the authentication token corresponding to the private cryptographic key (¶ 180-188, 215-225, 258, 423-441):
storing a public cryptographic key paired to the private cryptographic key via a backend lock-box application that links the first protected cryptocurrency conversion service to the authentication token stored in the frontend lock-box application(¶ 368-372, 387-396);
autogenerating a dynamic password using the authentication token as a seed, wherein the dynamic password comprises a digital signature generated by(¶ 82, 94-102, 180-186, 262-264, 389-403):
inputting a message into a hash function to produce a hash value; and encrypting the hash value using the private cryptographic key, whereby the digital signature is generated using a mathematical relationship between the private cryptographic key and a paired public cryptographic key that allows the private cryptographic key to generate digital signatures that can be validated using the public cryptographic key without revealing the private cryptographic key (¶ 37-42, 370-376, 393, 394, 418-422, 485);
transmitting credentials comprising the digital signature to a password validation application comprising a first smart contract operating on a distributed ledger; wherein the first smart contract automatically validates the credentials by: using the paired public cryptographic key to decrypt the digital signature to obtain a decrypted hash value; generating a new hash value of the digital signature using the hash function; and comparing the decrypted hash value and the new hash value to determine authenticity(¶ 37-45, 82, 126-133, 180-187, 215-225, 370-376, 393, 394, 418-422, 485);
Claim Interpretation - According to the disclosure(Figure 1; ¶ 53-57),” A digital signature may be generated by inputting a message into a hash function. … The dynamic password may be a one-time password. For example, each time access to a protected service is requested, a random nth number token may be generated the source authentication token. The random nth number token may be the message that is input to the message into the hash function to generate a digital signature….”
bypassing, via the secure API, the username input field and the password input field that secure access to the webpage hosting the first protected cryptocurrency conversion service; interacting, via the secure API, with a second smart contract running on the distributed ledger that controls access to the first protected cryptocurrency conversion service; and in response to validating the dynamic password, activating the first protected cryptocurrency conversion service based on programming in the second smart contract that grants access to the first protected cryptocurrency conversion service (¶ 82, 94-102, 133-139, 467, 476, 477, 482).
Yau does not disclose and triggering activation of a secure application program interface (API) accessible via the webpage. Ashbrook teaches and triggering activation of a secure application program interface (API) accessible via the webpage (Abstract; Figure 3, 4, 5.B; ¶ 21, 30, 37-44). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Yau and Ashbrook in order to provide updated access to third party services (Ashbrook; ¶ 2-7).
Regarding claim 23, Yau discloses wherein the frontend lock-box application and backend lock-box application operate as part of an authentication sequence by separating token storage from service linking to provide enhanced security for cryptocurrency conversion service access (¶ 260-262, 335, 336, 354-358, 387-398, 458-463, 480).
Claim Interpretation – the claim language “provide enhance security” merely recites a result and therefore has no patentable weight ( Minton v. Nat’l Ass’n of Securities Dealers, Inc., 336 F.3d 1373, 1381, 67 USPQ2d 1614, 1620 (Fed. Cir. 2003)) MPEP 2111.04 and 2173.05.
Regarding claim 24, Yau discloses wherein the backend lock-box application receives the dynamic password from the frontend lock-box application and uses the public cryptographic key paired to the private cryptographic key corresponding to the authentication token to validate the dynamic password (¶ 37-45, 82, 126-133, 180-187, 215-225, 370-376, 393, 394, 418-422, 485).
Regarding claim 25, Yau discloses wherein the digital wallet links the authentication token to the first protected cryptocurrency conversion service and provides secure storage for the authentication token as part of an authentication sequence (¶ 398, 411, 413, 418-21, 458-462).
Claim Interpretation – the claim language “provides secure storage” merely recites a result and therefore has no patentable weight ( Minton v. Nat’l Ass’n of Securities Dealers, Inc., 336 F.3d 1373, 1381, 67 USPQ2d 1614, 1620 (Fed. Cir. 2003)) MPEP 2111.04 and 2173.05
Regarding claim 26, Yau discloses wherein the first protected cryptocurrency conversion service comprises a decentralized application operating on a publicly accessible distributed ledger, wherein the decentralized application operating on the publicly accessible distributed ledger provides enhanced security compared to centralized authentication servers (¶ 82, 94-102, 180-186, 262-264, 389-403).
Claim Interpretation – the claim language “provide enhance security” merely recites a result and therefore has no patentable weight ( Minton v. Nat’l Ass’n of Securities Dealers, Inc., 336 F.3d 1373, 1381, 67 USPQ2d 1614, 1620 (Fed. Cir. 2003)) MPEP 2111.04 and 2173.05.
Regarding claim 27, Yau discloses transmitting communications between a frontend lock-box application and a backend lock-box application; via a first communication channel comprising an encrypted data transmission path; and transmitting communications between the backend lock-box application and the first protected cryptocurrency conversion service via a second communication channel comprising an encrypted data transmission path; wherein the first communication channel transmits communications between the frontend lock-box application and the backend lock-box application as part of an authentication sequence, and the second communication channel transmits communications between the backend lock-box application and the first protected cryptocurrency conversion service to establish secure access (¶ 82, 94-102, 133-139, 467, 476, 477, 482).
Regarding claim 28, Yau discloses wherein: the first communication channel encrypts transmitted data using a first private cryptographic key controlled by the frontend lock-box application; and a second communication channel encrypts transmitted data using a second private cryptographic key controlled by the backend lock-box application; wherein the first communication channel and the second communication channel using separate private cryptographic keys provide enhanced security as part of an authentication sequence (¶ 37-45, 82, 126-133, 180-187, 215-225, 370-376, 393, 394, 418-422, 485).
Claim Interpretation – the claim language “provide enhance security” merely recites a result and therefore has no patentable weight ( Minton v. Nat’l Ass’n of Securities Dealers, Inc., 336 F.3d 1373, 1381, 67 USPQ2d 1614, 1620 (Fed. Cir. 2003)) MPEP 2111.04 and 2173.05.
Regarding claim 29, Yau discloses further comprising requiring a second- factor authentication that is manually input by a user before autogenerating the dynamic password for the first protected cryptocurrency conversion service, wherein the second- factor authentication comprises a biometric feature or entry of a one-time password provided to the user (¶ 395-400, 447-458).
Regarding claim 30, Yau discloses wherein the first protected cryptocurrency conversion service is further configured to_ determine an amount associated with an electronic communication request to transact in cryptocurrency; convert an amount of cryptocurrency sufficient to satisfy the amount into an amount of a second currency; and execute the request to transact in the second currency using the amount of the second currency (¶ 398-412, 458-462; claim 1).
Regarding claim 31, Yau discloses wherein the biometric authentication comprises facial recognition, iris recognition, retina recognition, fingerprint recognition, or a combination thereof (¶ 395-400, 447-458).
Regarding claim 32, Yau discloses wherein: the password validation application validates the dynamic password; a backend lock-box application activates the first protected cryptocurrency conversion service when the dynamic password is successfully validated; the password validation application transmits signals to establish an electronic communication executable connection between the first protected cryptocurrency conversion service and a cryptocurrency conversion exchange; and wherein the backend lock-box application activation and cryptocurrency conversion exchange connection establishment occur as part of an authentication sequence after successful validation (¶ 42-45, 97-102, 127-133, 265-277, 284-293, 398, 411, 413, 418-421, 458-462, 467).
Regarding claim 33, Yau discloses wherein the first smart contract comprises the second smart contract (¶ 479-486).
Regarding claim 34, Yau discloses wherein the first smart contract and the second smart contract are separate smart contracts running on the distributed ledger, wherein the first smart contract performs credential validation, and the second smart contract performs service access control (¶ 479-486).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Goroff et al., (US 20190325408) teaches passwords, biometric authentication and cryptocurrency assets.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ILSE I IMMANUEL whose telephone number is (469)295-9094. The examiner can normally be reached Monday-Friday 9:00 am to 5:00pm.
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 H PATEL can be reached on (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.
/ILSE I IMMANUEL/Primary Examiner, Art Unit 3699
Prosecution Insights