DETAILED ACTION
The present application, filed on 8/31/2023 is being examined under the AIA first inventor to file provisions.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 12/12/2025 has been entered.
The following is a non-final Office Action on the Merits in response to Applicant’s submission.
a. Claims 1-3, 6-11, 13, 15, 19 are amended
Overall, Claims 1-19 are pending and have been considered below.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112 (f). is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f):
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112 (f). The presumption that the claim limitation is interpreted under 35 U.S.C. 112 (f). is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112 (f). The presumption that the claim limitation is not interpreted under 35 U.S.C. 112 (f). is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112 (f). except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112 (f). except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112 (f). because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “configured to manage an application”, “computing module configured to manage a database”, “computing module configured to manage an API” in claim 13.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112 (f). it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112 (f). applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112 (f).
The element “a simplified human-device element” has not been defined by the specification, the drawings or by the initial set of claims. For examination purpose, Examiner interprets “a simplified human-device element” as any display of a mobile digital device.
Claim Rejections - 35 USC § 112(a)
The following is a quotation of 35 U.S.C. 112(a):
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 13-19 are rejected under 35 U.S.C. 112(a) as failing to comply with the written description requirement. The claims contain 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 pre-AIA the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claims 13 are rejected for reciting the elements: “configured to manage an application”, “computing module configured to manage a database”, “computing module configured to manage an API” in claim 13. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. For these elements, there are no sufficient algorithms in the specification or drawings.
The remainder of the claims are rejected by virtue of dependency.
Claim Rejections - 35 USC § 112(b)
The following is a quotation of 35 U.S.C. 112(b):
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 13-19 are rejected under 35 U.S.C. 112(b), as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or the applicant regards as the invention. Such a claim is not sufficiently precise to provide competitors with an accurate determination of the 'metes and bounds' of the protection involved (IPXL Holdings LLC v. Amazon.com Inc., 77 USPQ2d 1140 (CA FCs 2005); Ex parte Lyell, 17 USPQ2d 1548).
Claims 13 are rejected under 35 U.S.C. 112(b), as being indefinite for failing to particularly point out and distinctly claim the subject matter which applicant regards as the invention.
The claim limitations in claim13; “configured to manage an application”, “computing module configured to manage a database”, “computing module configured to manage an API” in claim 13 invoke 35 U.S.C. 112 (f). However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f);
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
The remainder of the claims are rejected by virtue of dependency.
Claim Rejections - 35 USC § 112(a)
Written Description (Possession)
The following is a quotation of 35 U.S.C. 112(a):
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 8-19 are rejected under 35 USC 112(a) as failing to comply with the written description requirement. The claim 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(s), at the time the application was filed, had possession of the claimed invention.
Claims 8 is rejected for reciting the subject matter “modifying the balance of the second electronic storage application by incorporating the balance data” which is not adequately described in the specification, in the drawings or in the original set of claims to satisfy the requirements as described in MPEP 2163.05 V: “While there is a presumption that an adequate written description of the claimed invention is present in the specification as filed, In re Wertheim, 541 F.2d 257, 262, 191 USPQ 90, 96 (CCPA 1976), a question as to whether a specification provides an adequate written description may arise in the context of an original claim. An original claim may lack written description support when (1) the claim defines the invention in functional language specifying a desired result but the disclosure fails to sufficiently identify how the function is performed or the result is achieved …” Further "Even if a claim is supported by the specification, the language of the specification, to the extent possible, must describe the claimed invention so that one skilled in the art can recognize what is claimed. The appearance of mere indistinct words in a specification or a claim, even an original claim, does not necessarily satisfy that requirement. "Enzo Biochem, Inc. v. Gen-Probe, Inc., 323 F.3d 956, 968, 63 USPQ2d 1609, 1616 (Fed. Cir. 2002) (holding that generic claim language appearing in ipsis verbis in the original specification did not satisfy the written description requirement).”
In the instant situation, the application specification attempts to describe the term, however, no further information, like calculation method or algorithm is provided; i.e. HOW the function is performed. In addition, the specification verbally recites (ipsis verbis) the language of the claim. While the specification discloses the function, it discloses neither the necessary structure, nor the necessary algorithm to perform the function, i.e. HOW the calculation is performed.
The question is, given the disclosure, would a POSITA conclude that the inventor was in possession of the term “modifying the balance of the second electronic storage application by incorporating the balance data” in order to cause a system to perform the functions? The answer is clearly “no.” It looks as if the invention recites terms that have neither structure nor algorithm.
Therefore, the subject matter was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor(s), at the time the application was filed, had possession of the claimed invention.
For examination purpose, Examiner will interpret “modifying the balance of the second electronic storage application by incorporating the balance data” as any type of calculation, which is what the prior art of record discloses. The reference is provided for compact prosecution purpose.
Claims 12 is rejected for reciting the subject matter “modifying in the target electronic storage application a balance data” which is not adequately described in the specification, in the drawings or in the original set of claims to satisfy the requirements as described in MPEP 2163.05 V: “While there is a presumption that an adequate written description of the claimed invention is present in the specification as filed, In re Wertheim, 541 F.2d 257, 262, 191 USPQ 90, 96 (CCPA 1976), a question as to whether a specification provides an adequate written description may arise in the context of an original claim. An original claim may lack written description support when (1) the claim defines the invention in functional language specifying a desired result but the disclosure fails to sufficiently identify how the function is performed or the result is achieved …” Further "Even if a claim is supported by the specification, the language of the specification, to the extent possible, must describe the claimed invention so that one skilled in the art can recognize what is claimed. The appearance of mere indistinct words in a specification or a claim, even an original claim, does not necessarily satisfy that requirement. "Enzo Biochem, Inc. v. Gen-Probe, Inc., 323 F.3d 956, 968, 63 USPQ2d 1609, 1616 (Fed. Cir. 2002) (holding that generic claim language appearing in ipsis verbis in the original specification did not satisfy the written description requirement).”
In the instant situation, the application specification attempts to describe the term, however, no further information, like calculation method or algorithm is provided; i.e. HOW the function is performed. In addition, the specification verbally recites (ipsis verbis) the language of the claim. While the specification discloses the function, it discloses neither the necessary structure, nor the necessary algorithm to perform the function, i.e. HOW the calculation is performed.
The question is, given the disclosure, would a POSITA conclude that the inventor was in possession of the term “modifying in the target electronic storage application a balance data” in order to cause a system to perform the functions? The answer is clearly “no.” It looks as if the invention recites terms that have neither structure nor algorithm.
Therefore, the subject matter was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor(s), at the time the application was filed, had possession of the claimed invention.
For examination purpose, Examiner will interpret “modifying in the target electronic storage application a balance data” as any type of calculation, which is what the prior art of record discloses. The reference is provided for compact prosecution purpose.
Claims 13 is rejected for reciting the subject matter “manage a database configured to store a second encrypted seed, wherein the second computing module is connected to the communications network” and “manage the API” which is not adequately described in the specification, in the drawings or in the original set of claims to satisfy the requirements as described in MPEP 2163.05 V: “While there is a presumption that an adequate written description of the claimed invention is present in the specification as filed, In re Wertheim, 541 F.2d 257, 262, 191 USPQ 90, 96 (CCPA 1976), a question as to whether a specification provides an adequate written description may arise in the context of an original claim. An original claim may lack written description support when (1) the claim defines the invention in functional language specifying a desired result but the disclosure fails to sufficiently identify how the function is performed or the result is achieved …” Further "Even if a claim is supported by the specification, the language of the specification, to the extent possible, must describe the claimed invention so that one skilled in the art can recognize what is claimed. The appearance of mere indistinct words in a specification or a claim, even an original claim, does not necessarily satisfy that requirement. "Enzo Biochem, Inc. v. Gen-Probe, Inc., 323 F.3d 956, 968, 63 USPQ2d 1609, 1616 (Fed. Cir. 2002) (holding that generic claim language appearing in ipsis verbis in the original specification did not satisfy the written description requirement).”
In the instant situation, the application specification attempts to describe the term, however, no further information, like calculation method or algorithm is provided; i.e. HOW the function is performed. In addition, the specification verbally recites (ipsis verbis) the language of the claim. While the specification discloses the function, it discloses neither the necessary structure, nor the necessary algorithm to perform the function, i.e. HOW the calculation is performed.
The question is, given the disclosure, would a POSITA conclude that the inventor was in possession of the term “manage a database configured to store a second encrypted seed, wherein the second computing module is connected to the communications network” and “manage the API” in order to cause a system to perform the functions? The answer is clearly “no.” It looks as if the invention recites terms that have neither structure nor algorithm.
Therefore, the subject matter was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor(s), at the time the application was filed, had possession of the claimed invention.
For examination purpose, Examiner will interpret “manage a database configured to store a second encrypted seed, wherein the second computing module is connected to the communications network” and “manage the API” as any type of calculation, which is what the prior art of record discloses. The reference is provided for compact prosecution purpose.
The reference is provided for the purpose of compact prosecution. The remainder of the claims are rejected by virtue of dependency.
Claim Rejections - 35 USC § 112(b)
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.
Claims 8-12 are rejected under 35 U.S.C. 112(b), 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.
Regarding Claims 8, 18-19 – The claims are rejected for using acronyms, without spelling out their meaning. An essential purpose of patent examination is to fashion claims that are precise, clear, correct, and unambiguous. Only in this way can uncertainties of claim scope be removed (In re Zletz, 13 USPQ2d 1320 (Fed. Cir. 1989)). Examiner objects to using proper nouns, acronyms, abbreviations and trademarks in the claims. Although the meaning of these terms is currently known, that meaning can change over time, rendering the claims indefinite.
Regarding Claim 8 – The claim recites “configured to carry out some operational processes ...” The claim is indefinite because it is not clear which operational processes have to be caried out.
Regarding Claim 18 – The claim recites “configured to carry out a plurality of operational processes ...” The claim is indefinite because it is not clear which operational processes have to be caried out.
Regarding Claims 9, 18 – The claims has been amended to recite: “… configured to carry out some operational processes of a smart contract of the blockchain network such as recording and verifying …” The claims are indefinite, because an example of a term does not constitute a "clear definition" beyond the scope of the example (see MPEP 2106.11.C; MPEP 2111.01)
The reference is provided for the purpose of compact prosecution. The remainder of the claims are rejected by virtue of dependency.
Claim Rejections - 35 USC § 103
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
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 difference 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 the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103(a) are summarized as follows:
i. Determining the scope and contents of the prior art.
ii. Ascertaining the differences between the prior art and the claims at issue.
iii. Resolving the level of ordinary skill in the pertinent art.
iv. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 4-14, 16-19 are rejected under 35 U.S.C. 103 as being unpatentable over Richardson et al (US 2024/0089249), in view of Langenschaedel et al (US 2015/0262176), in further view of Martel et all (US 10,872,152).
Regarding Claim 1: Richardson discloses:
C) obtaining, by means of a computing device, a first encrypted seed through a first encryption process carried out by the computing device taking as input the private password data, the public password data, the storage application identification data, the first character string and a first random salt; {see at least [0068] seeds in encrypted form (reads on first encrypted seed) with character string}
D) sending by means of the computing device the first encrypted seed from the application to an Application Programming Interface (API), wherein the API is managed by a third computing module connected to the first computing module and the computing device via the communications network; {see at least [0233], [0267]-[0270] encrypted password to API server}
F) storing
G) obtaining the encrypted private password by carrying out a third encryption process performed by the computing device taking as input the user password and the private password data; and {see at least [0266]-[0267] encrypted password}
H) storing the encrypted private password in a memory module of the computing device, wherein the computing device, comprising a processor and memory modules, is configured to decrypt the encrypted the private password when a user enters into the application the user password, wherein upon decryption of the encrypted private password the computing device stores in a volatile memory module the private password data. {see at least [0267] encrypted password stored in password manager; [0096] decrypted seeds. The claim element “to decrypt the encrypted private password when a user enters into the application the user password” consists entirely of language disclosing at most a reason to have performed earlier method steps (intended use or field of use), but does not affect the functions in a manipulative sense (see MPEP 2103 I C) and imparts neither structure nor functionality to the claimed method (see MPEP 2111.05, MPEP 2114 and authorities cited therein), so it is considered but given no patentable weight. The reference is provided for the purpose of compact prosecution.}
Richardson does not disclose, however, Langenschaedel discloses:
A method for obtaining an encrypted private password, comprising: {see at least [0209] ledger (reads on blockchain) with storage application}
A) obtaining by means of a computing device a first application configured to store an access data set from a user; wherein the first storage application is obtained through a process under Bitcoin Improvement Proposal (BIP) standard carried out by the computing device, and wherein the first storage application has a private password data, a public password data, and a storage application identification data; {see at least fig71, rc544, [0200] third party storage application on a blockchain}
B) receiving in an application accessed by the computing device a first string of characters and a user password which are entered by the user into the computing device; wherein the application is managed by a first computing module that establishes connection with the computing device through a communications network; {see at least [0013] user name and password (reads on string of characters and password)}
It would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Richardson to include the elements of Langenschaedel. One would have been motivated to do so, in order to create and operate an encrypted storage application on a blockchain. In the instant case, Richardson evidently discloses encrypting an account. Langenschaedel is merely relied upon to illustrate the functionality of an electronic storage application in the same or similar context. Since both encrypting an account, as well as electronic storage application are implemented through well-known computer technologies in the same or similar context, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Richardson, as well as Langenschaedel would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Richardson / Langenschaedel.
Richardson, Langenschaedel does not disclose however, Martel discloses:
E) obtaining by means of the API a second encrypted seed by carrying out a second encryption process taking as input the first encrypted seed and a second random salt; {see at least (2)/[1:28-36] multi-layer encryption; fig9C, rc914, (91)-(92)/[20/19-59] cryptographic seed or salt (reads on second encrypted seed and salt); … can be used as seed}
… the second encrypted seed … {see at least (2)/[1:28-36] multi-layer encryption; fig9C, rc914, (91)-(92)/[20/19-59] cryptographic seed or salt (reads on second encrypted seed and salt); … can be used as seed}
It would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Richardson, Langenschaedel to include the elements of Martel. One would have been motivated to do so, in order to improve system security. In the instant case, Richardson, Langenschaedel evidently discloses creating and operating an encrypted storage application on a blockchain. Martel is merely relied upon to illustrate the functionality of a multi-layer encryption system in the same or similar context. Since both creating and operating an encrypted storage application on a blockchain, as well as a multi-layer encryption system are implemented through well-known computer technologies in the same or similar context, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Richardson, Langenschaedel, as well as Martel would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Richardson, Langenschaedel / Martel.
Regarding Claim 4: Richardson, Langenschaedel, Martel discloses the limitations of Claim 1. Richardson further discloses:
wherein the first character string is a secret word. {see at least [0042] using the secret (reads on secret word)}
Regarding Claim 5: Richardson, Langenschaedel, Martel discloses the limitations of Claim 1. Richardson further discloses:
wherein the user password is a number. {see at least [0410]; [0438] password is a number (CVV number)}
Regarding Claim 6: Richardson, Langenschaedel, Martel discloses the limitations of Claim 1. Richardson further discloses: further comprising a storage application recovery process comprising the steps:
iv) obtaining the first encrypted seed in the API by decrypting the second encrypted seed; {see at least [0068] seeds in encrypted form (reads on first encrypted seed)}
v) receiving in the application the first encrypted seed from the API; {see at least [0068] seeds in encrypted form (reads on first encrypted seed)}
vi) displaying a character string input message in the application; {see at least [0068] seeds in encrypted form (reads on first encrypted seed) with character string}
vii) receiving in the application the first character string) when the user enters said first character string into the computing device; {see at least [0068] seeds in encrypted form (reads on first encrypted seed) with character string}
viii) decrypting in the computing device the first encrypted seed to obtain the private password data; {see at least [0096] decrypted seeds. The claim element “to obtain the private password data” consists entirely of language disclosing at most a reason to have performed earlier method steps (intended use or field of use), but does not affect the functions in a manipulative sense (see MPEP 2103 I C) and imparts neither structure nor functionality to the claimed method (see MPEP 2111.05, MPEP 2114 and authorities cited therein), so it is considered but given no patentable weight. The reference is provided for the purpose of compact prosecution.}
ix) receiving in the computing device a user password entered by the user, and {see at least [0267] encrypted password stored in password manager}
x) carrying out steps G) to H). {see at least [0266]-[0267] encrypted password; encrypted password stored in password manager; [0096] decrypted seeds}
Langschaedel further discloses:
i) receiving in the application a storage application recovery command entered by the user through the computing device; {see at least fig6, [0090] current balance (based on the broadest reasonable interpretation (MPEP 2111), reads on recovery command)}
ii) sending from the application to the API a storage application recovery request, wherein the storage application recovery request includes a user identification data; {see at least [0016]-[0018] identifying by address}
It would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Richardson, Langenschaedel to include additional elements of Langenschaedel. One would have been motivated to do so, in order to initiate a recovery request. In the instant case, Richardson, Langenschaedel evidently discloses creating and operating an encrypted storage application on a blockchain. Langenschaedel is merely relied upon to illustrate the additional functionality of a recovery request in the same or similar context. Since the subject matter is merely a combination of old elements, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Martel further disclose:
iii) extracting the second encrypted seed from the database through the API, wherein the API queries the database taking as input the user identification data; {see at least (2)/[1:28-36] multi-layer encryption; fig9C, rc914, (91)-(92)/[20/19-59] cryptographic seed or salt (reads on second encrypted seed and salt); … can be used as seed}
It would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Richardson, Langenschaedel, Martel to include additional elements of Martel. One would have been motivated to do so, in order to improve system security. In the instant case, Richardson, Langenschaedel, Martel evidently discloses creating and operating an encrypted storage application on a blockchain. Martel is merely relied upon to illustrate the functionality of a multi-layer encryption system in the same or similar context. Since the subject matter is merely a combination of old elements, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Regarding Claim 7: Richardson, Langenschaedel, Martel discloses the limitations of Claim 1. Richardson further discloses: further comprising a storage application transaction access process, comprising:
I) receiving in the application the user password entered by the user into the computing device; {see at least [0073] receiving inputs … password}
II) decrypting with the computing device the encrypted private password, wherein the computing device stores the private password data in a volatile memory module, and {see at least [0096] decrypting seeds}
Langschaedel further discloses:
III) establishing communication between the application and a blockchain transaction module of the API; where at the end of step III) the electronic storage application is enabled to make transactions in the blockchain network through the interaction of the user with the application by means of the computing device. {see at least [0028] request for payment (reads on transfer request). The claim element “to make transactions in the blockchain network through the interaction of the user with the application by means of the computing device” consists entirely of language disclosing at most a reason to have performed earlier method steps (intended use or field of use), but does not affect the functions in a manipulative sense (see MPEP 2103 I C) and imparts neither structure nor functionality to the claimed method (see MPEP 2111.05, MPEP 2114 and authorities cited therein), so it is considered but given no patentable weight. The reference is provided for the purpose of compact prosecution.}
It would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Richardson, Langenschaedel, Martel to include additional elements of Langenschaedel. One would have been motivated to do so, in order to perform necessary transactions. In the instant case, Richardson, Langenschaedel, Martel evidently discloses creating and operating an encrypted storage application on a blockchain. Langenschaedel is merely relied upon to illustrate the functionality of enabling transactions in the same or similar context. Since the subject matter is merely a combination of old elements, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Regarding Claim 8: Richardson, Langenschaedel, Martel discloses the limitations of Claim 1. Richardson further discloses: further comprising a token recovery method comprising:
M) establishing connection between the API and the blockchain network through a communications protocol that allows connecting to a subnetwork comprising a plurality of interconnected nodes, wherein each node is a computing device comprising a processor and memory configured to carry out at least one smart contract of the blockchain network; {see at least [0096] toke transfer request (reads on establishing connection. The claim element “to carry out some operational processes of the smart contract of the blockchain network” consists entirely of language disclosing at most a reason to have performed earlier method steps (intended use or field of use), but does not affect the functions in a manipulative sense (see MPEP 2103 I C) and imparts neither structure nor functionality to the claimed method (see MPEP 2111.05, MPEP 2114 and authorities cited therein), so it is considered but given no patentable weight. The reference is provided for the purpose of compact prosecution.}
Langschaedel further discloses:
J) receiving in the application an account recovery command entered by the user into the computing device; {see at least fig6, [0090] current balance (based on the broadest reasonable interpretation (MPEP 2111), reads on recovery command)}
K) sending an account recovery request from the application to the API; wherein the account recovery request includes a user identification data of the user; {see at least [0016]-[0018] identifying by address}
L) repeating steps A) to H) to obtain a second electronic storage application; {Langenschaedel discloses the claimed invention except for repeating steps. It would have been obvious to one having ordinary skill in the art at the time of filing to repeat steps A) to H), since it has been held that mere duplication of the essential steps of a process involves only routine skill in the art. St. Regis Paper Co. v Bemis Co., 193 USPQ 8; In re Harza, 274 F.2d 669, 124 USPQ 378 (CCPA 1960)}
N) obtaining with the subnetwork a balance data of the electronic storage application by means of a query process taking as input the user identification data; wherein the query process is one of the operating processes; {see at least [0090] current balance (reads on modifying balance}
O) incorporating the balance data into a second storage application, wherein the subnetwork incorporates said balance of the second electronic storage application using the at least one contract function; and {see at least [0090] current balance (reads on modifying balance}
P) unlinking with the subnetwork the user identification data of the electronic storage application by means of the at least one contract function. {Langenschaedel fails to explicitly disclose the conditional claim limitation; however, it is reasonable to assume that one of ordinary skills in the art will realize that at a certain moment the electronic storage application data has to be unlinked form the subnetwork – see MPEP 2123 and MPEP 2144.01}
It would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Richardson, Langenschaedel, Martel to include additional elements of Langenschaedel. One would have been motivated to do so, in order to update an account on an as-needed basis. In the instant case, Richardson, Langenschaedel, Martel evidently discloses creating and operating an encrypted storage application on a blockchain. Langenschaedel is merely relied upon to illustrate the functionality of balancing out an account. Since the subject matter is merely a combination of old elements, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Regarding Claim 9: Richardson, Langenschaedel, Martel discloses the limitations of Claim 1. Richardson further discloses: further comprising a token transfer process comprising:
R) displaying in the application a user password entry message; {see at least [0076] entry of a user}
S) receiving on the computing device the user password; {see at least [0076] entry of a user (implicitly reads on receiving)}
T) obtaining the private password data by decrypting the encrypted private password by means of the computing device; {see at least [0157] using the decrypting key of the password}
U) storing in the volatile memory module the private password data; {see at least [0267] encrypted password stored in password manager}
V) obtaining a token transfer request in the application via the computing device when the user enters a token transfer command in said computing device, wherein the token transfer request includes at least one storage application identification data of the first storage application of the user, a target storage application identification data of a target electronic storage application, and a token quantity data; {see at least [0145]-[0146] token transfer request}
W) receiving the token transfer request in the API; {see at least [0145]-[0146] token transfer request}
X) sending from the API the token transfer request towards a subnetwork comprising a plurality of interconnected nodes, wherein each node is a computing device comprising a processor and memory configured to carry out some operational processes of a smart contract of the blockchain network such as recording and verifying data transactions and generating a distributed transaction ledger; {see at least [0096] token transfer request. The claim element “to carry out some operational processes of the smart contract of the blockchain network” consists entirely of language disclosing at most a reason to have performed earlier method steps (intended use or field of use), but does not affect the functions in a manipulative sense (see MPEP 2103 I C) and imparts neither structure nor functionality to the claimed method (see MPEP 2111.05, MPEP 2114 and authorities cited therein), so it is considered but given no patentable weight. The reference is provided for the purpose of compact prosecution.}
Y) carrying out the token transfer between the electronic storage application and the target storage application in the blockchain network by carrying out at least one smart contract function. {see at least [0096] token transfer request}
Regarding Claim 10: Richardson, Langenschaedel, Martel discloses the limitations of Claim 9. Richardson further discloses:
Y1) obtaining through the subnetwork a transfer register data at the end of step Y), wherein the transfer record data includes the storage application identification data of the electronic storage application of the user, the destination storage application identification data of the destination electronic storage application and a number of tokens data transferred, and where the transfer registration data is registered in the electronic storage application and in the destination electronic storage application. {see at least [0538] recording data (based on the broadest reasonable interpretation (MPEP 2111), reads on transfer records}
Regarding Claim 11: Richardson, Langenschaedel, Martel discloses the limitations of Claim 10. Langenschaedel further discloses: further comprising a token conversion process comprising:
Z1) receiving in the application a cash-closing command entered by the user into the computing device; Z2) proceeding to step {see at least [0028] request for payment (based on the broadest reasonable interpretation (MPEP 2111), reads on cash-closing command}
Z3) if the private password data is stored in the volatile memory module, otherwise, repeating steps R) to U) to store in the volatile memory module the private password data; Z3) sending a cash-closing request from the application to the API; {see at least [0028] request for payment (based on the broadest reasonable interpretation (MPEP 2111), reads on cash-closing command}
Z4) querying the transfer record data of step Y1) in subnetwork via API; {see at least fig2, [0084] transfer records}
Z5) sending a transfer request to a fourth computing module having at least one transactional module and connecting to the API, and {see at least [0028] request for payment (reads on transfer request)}
Z6) obtaining a transfer verification data when transferring data of value between a first account and a second account accessed by the transactional module. {see at least [0034] transfer verification}
It would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Richardson, Langenschaedel, Martel to include additional elements of Langenschaedel. One would have been motivated to do so, in order to execute a cash-closing command. In the instant case, Richardson, Langenschaedel, Martel evidently discloses creating and operating an encrypted storage application on a blockchain. Langenschaedel is merely relied upon to illustrate the functionality of querying transfers and executing a cash closing command. Since the subject matter is merely a combination of old elements, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Regarding Claim 12: Richardson, Langenschaedel, Martel discloses the limitations of Claim 11. Langenschaedel further discloses:
Z7) receiving in the API the transfer verification data; {see at least [0034] transfer verification}
Z8) sending from the API to the subnetwork the transfer verification data; and {see at least [0034] transfer verification}
Z9) incorporating balance data into the target storage application. {see at least [0090] current balance (reads on modifying balance}
It would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Richardson, Langenschaedel, Martel to include additional elements of Langenschaedel. One would have been motivated to do so, in order to keep the account up to date. In the instant case, Richardson, Langenschaedel, Martel evidently discloses creating and operating an encrypted storage application on a blockchain. Langenschaedel is merely relied upon to illustrate the functionality of balancing an account. Since the subject matter is merely a combination of old elements, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Regarding Claim 13: Richardson discloses:
a first computing module, selected from a virtual machine, a server, a computer, or a server farm, and comprising a processor and memory, configured to manage an application, wherein the application is configured to:
establish a connection to a user computing device through receiving from the computing device a first string of characters and a user password that are entered by the user; and {see at least [0068] seeds in encrypted form (reads on first encrypted seed) with character string}
sending a first encrypted seed from the application to an application programming interface API; {see at least [0233], [0267]-[0270] encrypted password to API server}
a second computing module, comprising a processor and memory, configured to manage a database configured to store a second encrypted seed, wherein the second computing module is connected to the communications network; {see at least fig2, rc30. The claim element “to store a second encrypted seed, wherein the second computing module is connected to the communications network” consists entirely of language disclosing at most a reason to have performed earlier method steps (intended use or field of use), but does not affect the functions in a manipulative sense (see MPEP 2103 I C) and imparts neither structure nor functionality to the claimed method (see MPEP 2111.05, MPEP 2114 and authorities cited therein), so it is considered but given no patentable weight. The reference is provided for the purpose of compact prosecution.}
a third computing module, comprising a processor and memory, connected to the first computing module, the second computing module, and the computing device via the communications network, and configured to manage the API, wherein the API is configured to: {see at least fig2, rc40, API server. The claim element “to manage the API” consists entirely of language disclosing at most a reason to have performed earlier method steps (intended use or field of use), but does not affect the functions in a manipulative sense (see MPEP 2103 I C) and imparts neither structure nor functionality to the claimed method (see MPEP 2111.05, MPEP 2114 and authorities cited therein), so it is considered but given no patentable weight. The reference is provided for the purpose of compact prosecution.}
wherein the computing device is configured to:
obtaining the first encrypted seed through a first encryption process taking as input the private password data, the public password data, the storage application identification data, the first character string, and a first random salt; {see at least [0068] seeds in encrypted form (reads on first encrypted seed) with character string}
obtaining the encrypted private password by carrying out a third encryption process taking as input the user password and the private password data; {see at least [0266]-[0267] encrypted password}
storing the encrypted private password in a memory module; and {see at least [0266] storing the encrypted password}
decrypting the encrypted private password when a user enters into the application the user password, wherein upon decryption of the encrypted private password the computing device stores in a volatile memory module the private password data. {see at least [0270] decrypting an encrypted password}
Richardson does not disclose, however, Langenschaedel discloses:
A system for obtaining an encrypted private password, comprising: {see at least [0209] ledger (reads on blockchain) with storage application}
establishing connection with the database through a communication network, and {see at least [0013] user name and password (reads on establishing connection))
obtaining a first storage application through a process under Bitcoin Improvement Proposal (BIP) standard, wherein the electronic storage application has a private password data, a public password data, and a storage application identification data; {see at least fig71, rc544, [0200] third party storage application on a blockchain}
It would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Richardson to include the elements of Langenschaedel. One would have been motivated to do so, in order to create and operate an encrypted storage application on a blockchain. In the instant case, Richardson evidently discloses encrypting an account. Langenschaedel is merely relied upon to illustrate the functionality of an electronic storage application in the same or similar context. Since both encrypting an account, as well as electronic storage application are implemented through well-known computer technologies in the same or similar context, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Richardson, as well as Langenschaedel would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Richardson / Langenschaedel.
Richardson, Langenschaedel does not disclose, however, Martel discloses:
obtaining the second encrypted seed by carrying out a second encryption process taking as input the first encrypted seed and a second random salt; and {see at least (2)/[1:28-36] multi-layer encryption; fig9C, rc914, (91)-(92)/[20/19-59] cryptographic seed or salt (reads on second encrypted seed and salt); … can be used as seed}
It would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Richardson, Langenschaedel to include the elements of Martel. One would have been motivated to do so, in order to improve system security. In the instant case, Richardson, Langenschaedel evidently discloses creating and operating an encrypted storage application on a blockchain. Martel is merely relied upon to illustrate the functionality of a multi-layer encryption system in the same or similar context. Since both creating and operating an encrypted storage application on a blockchain, as well as a multi-layer encryption system are implemented through well-known computer technologies in the same or similar context, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Richardson, Langenschaedel, as well as Martel would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Richardson, Langenschaedel / Martel.
Regarding Claim 14: Richardson, Langenschaedel, Martel discloses the limitations of Claim 13. Richardson further discloses:
wherein the first computing module is connected to the third computing module via a communications protocol selected from Hypertext Transfer Protocol Secure (HTTPS), Hypertext Transfer Protocol (HTTP), Transmission Control Protocol/Internet Protocol (TCP/IP), Secure Shell (SSH), Representational State Transfer (REST), Simple Object Access Protocol (SOAP), and combinations thereof. {see at least [0570] HTTP error}
Regarding Claim 16: Richardson, Langenschaedel, Martel discloses the limitations of Claim 13. Richardson further discloses:
wherein the first computing module is selected from a virtual machine, a server, a computer, a server farm, and combinations thereof. {see at least [0042], [0044] server}
Regarding Claim 17: Richardson, Langenschaedel, Martel discloses the limitations of Claim 13. Langenschaedel further discloses:
wherein the database is a non-relational database. {see at least [0007] public database (reads on non-relational database)}
It would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Richardson, Langenschaedel, Martel to include additional elements of Langenschaedel. One would have been motivated to do so, in order to use a simple structure to perform the operation. In the instant case, Richardson, Langenschaedel, Martel evidently discloses creating and operating an encrypted storage application on a blockchain. Langenschaedel is merely relied upon to illustrate the functionality of a non-relational database. Since the subject matter is merely a combination of old elements, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Regarding Claim 18: Richardson, Langenschaedel, Martel discloses the limitations of Claim 13. Langenschaedel further discloses: further comprising a subnetwork establishing communication with the API,
wherein the subnetwork includes a plurality of nodes interconnected via a communications protocol selected from Transmission Control Protocol (TCP) and User Datagram Protocol (UDP), where each node is a computing device comprising a processor and memory, and wherein the nodes are configured to carry out at least one smart contract function of the blockchain network such as recording and verifying data transactions, generating a distributed transaction ledger, and facilitating communication with external computing devices.. {see at least fig73a, rc2a, [0211] sending a cross-check request (based on the broadest reasonable interpretation requirement (MPEP 2111), reads on operations of a smart contract)}
It would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Richardson, Langenschaedel, Martel to include additional elements of Langenschaedel. One would have been motivated to do so, in order to utilize an established communication protocol. In the instant case, Richardson, Langenschaedel, Martel evidently discloses creating and operating an encrypted storage application on a blockchain. Langenschaedel is merely relied upon to illustrate the functionality of a TCP communication protocol. Since the subject matter is merely a combination of old elements, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Regarding Claim 19: Richardson, Langenschaedel, Martel discloses the limitations of Claim 18. Ricahrdson further discloses:
wherein each node establishes communication with a blockchain transaction module of the API via a communications protocol selected from TCP, SSH, TCP/IP, HTTPS, and combinations thereof. {see at least [0504] TCP/IP protocol}
Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over Richardson et al (US 2024/0089249), in view of Langenschaedel et al (US 2015/0262176), in further view of Martel et all (US 10,872,152), in further view of Kurasaki et al (US 2008/0016004).
Regarding Claim 2: Richardson, Langenschaedel, Martel discloses the limitations of Claim 1. Richardson, Langenschaedel, Martel does not disclose, however, Kurasaki discloses:
wherein the first encryption process, the second encryption process, and the third encryption process are selected from Advanced Encryption Standard (AES), AES 256, AES 132, Blowfish, Data Encryption Standard (DES), Serpent, Two fish processes, and combinations thereof. {see at least [0093] DES, AES}
It would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Richardson, Langenschaedel, Martel to include the elements of Kurasaki. One would have been motivated to do so, in order to utilize established technologies. In the instant case, Richardson, Langenschaedel, Martel evidently discloses creating and operating an encrypted storage application on a blockchain. Kurasaki is merely relied upon to illustrate the functionality of encryption method in the same or similar context. Since both creating and operating an encrypted storage application on a blockchain, as well as encryption method are implemented through well-known computer technologies in the same or similar context, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Richardson, Langenschaedel, Martel, as well as Marien would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Richardson, Langenschaedel, Martel / Marien.
Claims 3, 15 are rejected under 35 U.S.C. 103 as being unpatentable over Richardson et al (US 2024/0089249), in view of Langenschaedel et al (US 2015/0262176), in further view of Martel et all (US 10,872,152), in further view of Marien et al (US 2014/0189359).
Regarding Claim 3: Richardson, Langenschaedel, Martel discloses the limitations of Claim 1. Richardson, Langenschaedel, Martel does not disclose, however, Marien discloses: further comprising a step AA) preceding the step A) of carrying out a user identity verification process comprising the substeps:
AA1) receiving in the application a user identification data entered by the user into the computing device; {see at least [0159] user identification data}
AA2) sending from the application an One-Time Password (OTP) request to the API, wherein the OTP request includes the user identification data; {see at least [0022] token transforms the cryptogram into OTP}
AA3) obtaining via an identification server an identification data including an OTP key data after the API receives the OTP request; {see at least fig24, rc2415, [0450] using the OTP key. Marien fails to explicitly disclose the conditional claim limitation; however, it is reasonable to assume that one of ordinary skills in the art will realize that the data can be received only after a request has been placed – see MPEP 2123 and MPEP 2144.01}
AA4) sending via the identification server the identification data to a user address selected from a telephone number, email address, social network profile address, and combinations thereof, {see at least [0150], [0159] receiving (which implicitly reads on sending) user ID; [0474] user’s email address}
AA5) obtaining in the application an OTP input data entered by the user via the computing device after receiving the identification data; {see at least fig24, rc2415, [0450] OTP associated with particular user. Marien fails to explicitly disclose the conditional claim limitation; however, it is reasonable to assume that one of ordinary skills in the art will realize that the data can be obtain only after receiving the identification data – see MPEP 2123 and MPEP 2144.01}
AA6) sending from the application to the API the OTP input data; and {see at least fig24, rc2415, [0450] OTP associated with particular user.}
AA7) obtaining via API an OTP validation data when the OTP input data matches the OTP key data and proceed to step A), otherwise repeat substep AA1). {see at least fig24, rc2460, [0450] OTP is verified}
It would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Richardson, Langenschaedel, Martel to include the elements of Marien. One would have been motivated to do so, in order to utilize established technologies. In the instant case, Richardson, Langenschaedel, Martel evidently discloses creating and operating an encrypted storage application on a blockchain. Marien is merely relied upon to illustrate the functionality of encryption method in the same or similar context. Since both creating and operating an encrypted storage application on a blockchain, as well as encryption method are implemented through well-known computer technologies in the same or similar context, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Richardson, Langenschaedel, Martel, as well as Marien would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Richardson, Langenschaedel, Martel / Marien.
Regarding Claim 15: Richardson, Langenschaedel, Martel discloses the limitations of Claim 1. Richardson, Langenschaedel, Martel does not disclose, however, Marien discloses: further comprising an identification server connected to the third computing module and the first computing module via the communications network,
where the application is also configured for:
receiving a user identification data entered by the user into the computing device; {see at least [0159] user identification data}
sending a request to the API; {see at least [0022] token transforms the cryptogram into OTP}
obtaining an OTP input data entered by the user via the computing device after receiving an identification data; {see at least fig24, rc2415, [0450] using the OTP key. Marien fails to explicitly disclose the conditional claim limitation; however, it is reasonable to assume that one of ordinary skills in the art will realize that the data can be received only after a request has been placed – see MPEP 2123 and MPEP 2144.01}
sending to the API the OTP input data; {see at least [0150], [0159] receiving (which implicitly reads on sending) user ID; [0474] user’s email address}
where the identification server is configured for:
getting the identification data that includes an OTP key data after the API receives the request; and see at least fig24, rc2415, [0450] using the OTP key. Marien fails to explicitly disclose the conditional claim limitation; however, it is reasonable to assume that one of ordinary skills in the art will realize that the data can be received only after a request has been placed – see MPEP 2123 and MPEP 2144.01}
sending the identification data to a user address selected from a telephone number, e-mail address, social network profile address, and combinations thereof; and {see at least [0150], [0159] receiving (which implicitly reads on sending) user ID; [0474] user’s email address}
where API is also configured for:
establishing connection between the identification server and the application; and {see at least [0150], [0159] receiving (which implicitly reads on sending) user ID; [0474] user’s email address}
obtaining an OTP validation data when OTP input data entered by the user matches the OTP key data of the identification data. {see at least fig24, rc2415, [0450] OTP associated with particular user.}
It would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Richardson, Langenschaedel, Martel to include the elements of Marien. One would have been motivated to do so, in order to utilize established technologies. In the instant case, Richardson, Langenschaedel, Martel evidently discloses creating and operating an encrypted storage application on a blockchain. Marien is merely relied upon to illustrate the functionality of encryption method in the same or similar context. Since both creating and operating an encrypted storage application on a blockchain, as well as encryption method are implemented through well-known computer technologies in the same or similar context, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Richardson, Langenschaedel, Martel, as well as Marien would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Richardson, Langenschaedel, Martel / Marien.
The prior art made of record and not relied upon which, however, is considered pertinent to applicant's disclosure:
US 20200344055 A1 Topps; Ryan Joseph DECENTRALIZED AND/OR HYBRID DECENTRALIZED SECURE CRYPTOGRAPHIC KEY STORAGE METHOD - A decentralized and/or hybrid decentralized method for secure cryptography key storage referred to as Mutual Dependency Architecture (MDA) includes the steps of encrypting the cryptographic key using an unlock key; encrypting the unlock key using an encryption tool to create an encrypted seed; and storing the encrypted seed; wherein a user must have access to a first storage area in the device and to a second storage area external to the device in order to access the cryptographic key. In one embodiment, the encryption tool is a store key that is stored in unencrypted form in the first storage area, while the encrypted seed is stored in the second storage area. In another embodiment, the encryption tool is a Hardware Security Module (HSM) having an authentication key that is encrypted using a store key and stored in the second storage area, while the encrypted seed and the store key are stored in unencrypted form in the first storage area. The method can be used to build a fully encrypted and permanently secure network and/or internet of devices and/or things, and to exchange messages between devices on the network.
US 20200193420 A1 Vogel; Henry Michael et al. DATA MANAGEMENT SYSTEMS AND METHODS - Example data management systems and methods are described. In one implementation, a data management system includes a carbon key configured to store at least one authentication factor associated with a user. The system also includes a hardware storage application configured to communicate with the carbon key. The hardware storage application includes a fingerprint sensor configured to scan a fingerprint of the user, a display configured to receive a personal identification number (PIN) from the user; and a system on chip (SOC) configured to authenticate the carbon key, the fingerprint, and the PIN. Additionally, the SOC can sign a transaction based on authentication of at least two of the carbon key, the fingerprint, and the PIN.
US 20040184064 A1 TaKeda, Kenichi et al. Printer driver program and printer - In a printer driver that transmits a print data to a printer connected via a network to make a print request, a document password processing unit prompts a user to input a document password for decrypting a PDF document data encrypted by a predetermined application. A print data creating unit creates a print data including the PDF document data encrypted and the document password. The created print data is transmitted to the printer via the network by a host I/F controller and a host I/F. -
US 20020073046 A1 David, Sancho Enrique System and method for secure network purchasing - A system for permitting a secure electronic transaction on a network is disclosed. The network has a user device having a fingerprint, a provider's server and a means for providing verification of user's identity. In response to a request by the provider's server the means for providing verification positively identifies the fingerprint of the user device. It thereupon requests a confirmation from the user device of the transaction and upon receiving the confirmation completes the transaction.
US 20070074027 A1 Tung; Tien-Chun Methods of verifying, signing, encrypting, and decrypting data and file - Methods of verifying, signing, encrypting and decrypting data and files contained a mobile telecommunication device having public keys (authentication) and private keys (digital identification) installed inside the device, and an electronic device handling requests to the mobile telecommunication device. When the files are signed, verified, encrypted or decrypted, the electronic device is input (or automatically connected) with an identification code and then requests are sent for verification, signing, encryption and decryption together with certain optional necessary data to the mobile telecommunication device. According to various requests, the mobile telecommunication device releases the installed public keys or obtains private keys by inputting pre-set protective access codes to sign, verify, encrypt, or decrypt to the necessary data and then re-transmit the signed, verified, encrypted or decrypted necessary data to the electronic device to complete the methods. By using the mobile telecommunication to sign, verify, encrypt and decrypt the data and files, methods of identification are cost saving and conveniently to be used.
US 6182220 B1 Chen; Qilun et al. System and method for building and exchanging encrypted passwords between a client and server - A method and system is provided for communicating encrypted user passwords from a client to a server. During new environment negotiations, the server communicates to the client a server random seed value. The client then generates a client random seed value and, using the client random seed value, the server random seed value, and the user variable name, an encrypted user password. The client then communicates to the server the client random seed, the user variable name and the encrypted user password. Then the server validates the encrypted user password using the server random seed, the client random seed and the user’s variable name.
Response to Amendments/Arguments
Applicant’s submitted remarks and arguments have been fully considered.
Applicant disagrees with the Office Action conclusions and asserts that the presented claims fully comply with the requirements of 35 U.S.C. § 101 regrading judicial exceptions. Further, Applicant is of the opinion that the prior art fails to teach Applicant’s invention.
Examiner respectfully disagrees with the latter remark.
With respect to Applicant’s Remarks as to the claims being rejected under 35 USC § 101.
Applicant’s arguments are persuasive. As a result of the amendments and in light of Applicant’s arguments, the rejection is withdrawn.
With respect to Applicant’s Remarks as to the claims being rejected under 35 USC § 112(a) and 35 USC § 112(b), as a result of interpreting claims under 35 USC § 112(f).
Applicant submits that the claim limitations “configured to manage an application”, “computing module configured to manage a database”, “computing module configured to manage an API” in claim 13”, should not be interpreted under 35 USC § 112(f)
Examiner has carefully considered, but doesn’t find Applicant’s arguments persuasive.
Applicant’s arguments are persuasive. After further consideration, the rejection is withdrawn. The rejections are withdrawn, as a result of the amendments and Applicant’s arguments.
Thus, the rejection is proper and has been maintained.
Applicant submits “… concerning the indefiniteness objection against the use of technical acronyms and abbreviations (e.g., API, BIP standard, blockchain, smart contract), the Applicant maintains that these terms are standard, well-established technical terminology in the fields of distributed ledger technology and cryptography and a PHOSIT A is fully familiar with their meaning and function. Furthermore, the Specification provides sufficient contextual definition for each term; for example, the BIP standard is defined by its role in obtaining the first storage application (e.g. an electronic wallet). The use of accepted industry terminology in its intended technical context establishes that the claims distinctly point out the subject matter as required by 35 U.S.C. § 112(b).”
Examiner has carefully considered, but doesn’t find Applicant’s arguments persuasive.
Applicant’s arguments are persuasive. After further consideration, the rejection is withdrawn. The rejections are withdrawn, as a result of the amendments and Applicant’s arguments.
Thus, the rejection is proper and has been maintained.
With respect to Applicant’s Remarks as to the claims being rejected under 35 USC § 103.
Applicant submits that the prior art of record does not disclose: “obtaining a second encrypted seed by carrying out a second encryption process taking as input the first encrypted seed and a second random salt nor storing the second encrypted seed in a database. … does not provide support for the storage of a uniquely derived multi-layered encrypted seed.”
Examiner has carefully considered, but doesn’t find Applicant’s arguments persuasive.
Richardson discloses:
F) storing
Martel discloses:
E) obtaining by means of the API a second encrypted seed by carrying out a second encryption process taking as input the first encrypted seed and a second random salt; {see at least (2)/[1:28-36] multi-layer encryption; fig9C, rc914, (91)-(92)/[20/19-59] cryptographic seed or salt (reads on second encrypted seed and salt); … can be used as seed}
F) … the second encrypted seed … {see at least (2)/[1:28-36] multi-layer encryption; fig9C, rc914, (91)-(92)/[20/19-59] cryptographic seed or salt (reads on second encrypted seed and salt); … can be used as seed}
Richardson, Martel discloses the claim limitations. Therefore, the rejection is proper and has been maintained.
The other arguments presented by Applicant continually point back to the above arguments as being the basis for the arguments against the other 103 rejections, as the other arguments are presented only because those claims depend from the independent claims, and the main argument above is presented against the independent claims. Therefore, it is believed that all arguments put forth have been addressed by the points above.
Examiner has reviewed and considered all of Applicant’s remarks. The changes of the grounds for rejection, if any, have been necessitated by Applicant’s extensive amendments to the claims. Therefore, the rejection is maintained, necessitated by the extensive amendments and by the fact that the rejection of the claims under 35 USC § 101 has not been overcome.
Inquiries
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Radu Andrei whose telephone number is 313.446.4948. The examiner can normally be reached on Monday – Friday 8:30am – 5pm EST. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Patrick McAtee can be reached at 571.272.7575. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
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.
As disclosed in MPEP 502.03, communications via Internet e-mail are at the discretion of the applicant. Without a written authorization by applicant in place, the USPTO will not respond via Internet e-mail to any Internet correspondence which contains information subject to the confidentiality requirement as set forth in 35 U.S.C. 122. A paper copy of such correspondence will be placed in the appropriate patent application. The following is a sample authorization form which may be used by applicant:
“Recognizing that Internet communications are not secure, I hereby authorize the USPTO to communicate with me concerning any subject matter of this application by electronic mail. I understand that a copy of these communications will be made of record in the application file.”
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center information webpage. Status information for unpublished applications is available to registered users through Patent Center information webpage only.
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.
Any response to this action should be mailed to:
Commissioner of Patents and Trademarks
P.O. Box 1450
Alexandria, VA 22313-1450
or faxed to 571-273-8300
/Radu Andrei/
Primary Examiner, AU 3698