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 .
Terminal Disclaimer
Terminal disclaimer has been filed on 10/29/2025. Terminal disclaimer decision has been made on 11/03/2025, and it has been disapproved. Therefore, the original rejection is maintained.
Status of Claims
The following is a Final Office Action on the Merits is in reply to the application filed on 08/01/2024. Claims 1-19 are pending and have been considered below.
Priority
The application claims priority to provisional application 63/517,000, filed on 08/01/2023. The priority is acknowledged.
Claim Rejections - 35 USC § 101
35 USC 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-19 are rejected under 35 USC 101 because the claimed invention is not directed to patent eligible subject matter. The claimed matter is directed to a judicial exception, i.e. an abstract idea, not integrated into a practical application, and without significantly more.
Per Step 1 of the multi-step eligibility analysis, claims 1-8 are directed to a computer implemented method, and claims 10-18 are directed to a system, claim 19 are directed to computer executable instructions stored on a non-transitory storage medium.
Thus, on its face, each independent claim and the associated dependent claims are directed to a statutory category of invention.
Per Step 2A.1. Claim 1, (which is representative of claims 10, 19) is rejected under 35 USC 101 because the claim is directed to an abstract idea, a judicial exception, without reciting additional elements that integrate the judicial exception into a practical application. The limitations of the independent claim 1 recite an abstract idea, shown in bold, while the non-bolded claim elements recite additional element according to MPEP 2106.04(a).
[A] A computer-implemented method, comprising:
[B] receiving a request to access one or more wallets on a blockchain, the request including an authorization code associated with a controlling party associated with the one or more wallets and user credentials associated with the controlling party;
[C] decrypting a first portion of a private key based on the authorization code and a salt associated with the user credentials;
[D] decrypting a second portion of the private key based on credentials associated with an application through which the wallet is accessed; and
[E] granting access to the wallet based on the decrypted first portion and the decrypted second portion of the private key.
Claim 1 (which is representative of claims 10, 19) recites: receiving a request to access wallet ([B]); decrypting portion of the private key ([C]-[D]); and granting access to wallet based on the decryption ([E]), which, based on the claim language and in view of the application disclosure, represents a process aimed at enabling a system for managing credentials.
This is a combination that, under its broadest reasonable interpretation, covers agreements in the form of advertising, marketing, sales activities or behaviors, business relationships (e-commerce), which falls under which falls under Certain Methods of Organizing Human Activity, i.e., Commercial or Legal Interactions grouping of abstract ideas (see MPEP 2106.04(a)(2)).
This overall combination, covers managing and authenticating credentials, including decrypting credential, granting access based on the decryption and such activities can be performed by human using pen and paper. Such limitations expresses observation, evaluation, judgement, which falls under Mental Processes, i.e., Concepts Performed in the Human Mind grouping of abstract ideas (see MPEP 2106.04(a)(2)).
Accordingly, it is reasonable to conclude that claim 1 (which is representative of claims 10, 19) recites an abstract idea that embodies a judicial exception.
Per Step 2A.2. The identified abstract idea is not integrated into a practical application because the additional elements in the independent claims only amount to instructions to apply the judicial exception to a computer, or are a general link to a technological environment (see MPEP 2106.05(f); MPEP 2106.05(h)). For example, the added elements “blockchain,” “user,” “application” computing elements at a high level of generality, which is equivalent to instructions to implement the abstract idea “by a computer” or “on a computer.” The modifiers do not preclude from carrying out the identified abstract idea of enabling means of managing credentials. Therefore, those modifiers do not serve to integrate the identified abstract idea into practical application.
The additional elements in the independent claims, shown not bolded above, recite: blockchain ([B]), user ([C]), application ([D]). When considered individually or as an ordered combination, they amount to nothing more than reception, transmission and/or general computation (i.e., not specific enough computation) of claim elements that serves merely to implement the abstract idea using computing components for performing computer functions (adding the words “apply it” or an equivalent), or merely uses a computer as a tool to perform the identified abstract idea.
Therefore, the additional steps of claim 1 (which is representative of claims 10, 19) do not integrate the identified abstract idea into a practical application and the claims remain a judicial exception.
Per Step 2B. Claim 1 (which is representative of claims 10, 19) does not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when the independent claim is reevaluated as a whole, as an ordered combination under the considerations of Step 2B, the outcome is the same like under Step 2A.2.
Therefore, when considered as a whole and as an ordered combination, the additional elements in the claim amount to instructions to apply the abstract idea on a computer. Moreover, as noted above, there is nothing the computing and additional step (limitations [B]-[C]), that is significant or meaningful to the underlying abstract idea because the identified abstract idea of managing credentials could have been reasonably performed when provided with the relevant data and/or information. Therefore, it is concluded that independent claims 1, 10, 19 are deemed ineligible.
Dependent Claims: Claims 2-9, 11-18 are analyzed for subject matter eligibility. However, these claims fails to recite patent eligible subject matter for following reasons:
Claim 2, which is representative of claim 11 recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recites additional elements according to MPEP 2106.04(a). The claim further recites:
[A] wherein the authorization code associated with the controlling party comprises an alphanumeric string.
The claim further recites the abstract idea of managing credentials. In other words, it recites limitation grouped within the “mental process” grouping of abstract ideas. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP 2106.05(f)).
Claim 3, which is representative of claim 12, recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recites additional elements according to MPEP 2106.04(a). The claim further recites:
[A] wherein the authorization code associated with the controlling party comprises one or more question-answer pairs.
The claim further recites the abstract idea of managing credentials. In other words, it recites limitation grouped within the “mental process” grouping of abstract ideas. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP 2106.05(f)).
Claim 4, which is representative of claims 13, recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recites additional elements according to MPEP 2106.04(a). The claim further recites:
[A] wherein decrypting the second portion of the private key comprises decrypting a first sub-portion of the second portion based a first set of credentials associated with the application and a second sub-portion of the second portion based on a second set of credentials associated with the application.
The claim further recites the abstract idea of decrypting credentials. In other words, it recites limitation grouped within the “mental process” grouping of abstract ideas. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP 2106.05(f)).
Claim 5, which is representative of claim 14, recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recites additional elements according to MPEP 2106.04(a). The claim further recites:
[A] wherein the salt comprises a randomly generated number encrypted using a key associated with the user credentials.
The claim further recites the abstract idea of managing credentials. In other words, it recites limitation grouped within the “mental process” grouping of abstract ideas. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP 2106.05(f)).
Claim 6, which is representative of claims 15, recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recites additional elements according to MPEP 2106.04(a). The claim further recites:
[A] receiving a request to generate the wallet, the request including at least the authorization code associated with the controlling party associated with the wallet;
[B] selecting the private key associated with the wallet from an entropy pool of private keys; and
[C] generating the wallet based on the selected private key.
The claim further recites the abstract idea of managing credentials. In other words, it recites limitation grouped within the “mental process” grouping of abstract ideas. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP 2106.05(f)).
Claim 7, which is representative of claims 16, recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recites additional elements according to MPEP 2106.04(a). The claim further recites:
[A] wherein granting access to the wallet comprises granting access to withdraw items stored in the wallet to an external resource based on signing a transaction using the decrypted first portion and the decrypted second portion of the private key.
The claim further recites the abstract idea of managing credentials. In other words, it recites limitation grouped within the “mental process” grouping of abstract ideas. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP 2106.05(f)).
Claim 8, which is representative of claims 17, recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recites additional elements according to MPEP 2106.04(a). The claim further recites:
[A] generating an intermediate encrypted version of the private key based on the decrypted first portion and the decrypted second portion of the private key; and
[B] decrypting the private key based on the intermediate encrypted version of the private key and a platform-specific decryption key, wherein the decrypted private key grants access to the wallet.
The claim further recites the abstract idea of managing credentials. In other words, it recites limitation grouped within the “mental process” grouping of abstract ideas. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP 2106.05(f)).
Claim 9, which is representative of claims 18, recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recites additional elements according to MPEP 2106.04(a). The claim further recites:
[A] wherein the controlling party associated with the one or more wallets comprises a party associated with a centralized platform through which owners of the one or more wallets perform transactions on the blockchain.
The claim further recites the abstract idea of managing credentials. In other words, it recites limitation grouped within the “mental process” grouping of abstract ideas. The non-bolded additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP 2106.05(f)).
When the dependent claims are considered as a whole, as an ordered combination, the claim elements noted above appear to merely apply the abstract concept to a technical environment in a very general sense, i.e., a computer receives information from another computer, processes that information and then sends a response based on processing results. The most significant elements of the claims, that is the elements that really outline the inventive elements of the claims, are set forth in the elements identified in the independent claims as an abstract idea. The fact that the computing devices are facilitating the abstract concept is not enough to confer subject matter eligibility. Overall, the further elements do not confer subject matter eligibility to the invention since their individual and combined significance are not changing the nature of the abstract concepts at the core of the claimed invention. Therefore, it is concluded that the dependent claims of the instant application do not amount to significantly more. (See MPEP 2106.05).
In sum, Claims 1-24 are rejected under 35 USC 101 as being directed to non-statutory subject matter.
Double Patenting Rejection
The non-statutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper time wise extension of the "right to exclude" granted by a patent and to prevent possible harassment by multiple assignees. A non-statutory obviousness-type double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428,46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046,29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Omum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel/,422 F.2d 438,164 USPQ 619 (CCPA 1970); and, In re Thorington, 418 F.2d 528,163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on non-statutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a non-statutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Effective January 1, 1994, a registered attorney or agent of record may sign a terminal disclaimer. A terminal disclaimer signed by the assignee must fully comply with 37 CFR 3.73(b).
Claims 1, 10, 19 are rejected on the ground of non-statutory obviousness-type double patenting as being unpatentable over claims 1, 9, 17 of patent co-pending application 18792389. Although the conflicting claims are not identical, they are not patentably distinct from each other because the Application’s independent claims 1, 10, 19 are disclosed by the patent co-pending application 18792389's independent claims 1, 9, 17 respectively. The claims are directed respectively to a computer implemented method, to computer executable instructions stored on a non-transitory storage medium and to a system. While the current application discloses “receiving a request to access one or more wallets on a blockchain … decrypting a first portion of a private key … decrypting a second portion of the private key … granting access to the one or more wallets” co-pending application 18792389 discloses “receiving a request to access a wallet on a blockchain … decrypting a first portion of a private key … decrypting a second portion of the private key … granting access to the wallet” as the logic equivalent for “granting wallet access to users’ with proper authorization”. The equivalent pairs recite the same limitations, with the patent co-pending application 18792389 claims reciting few additional limitations. These additional limitations make the claims narrower (species), which reads on broad (genus). See MPEP 2144.08 – In re Jones, 958 F.2d 347, 350, 21 USPQ2d 1941, 1943 (Fed. Cir. 1992) (Federal Circuit has “decline[d] to extract from Merck [& Co. v. Biocraft Laboratories Inc., 874 F.2d 804, 10 USPQ2d 1843 (Fed. Cir. 1989)]. Therefore, the double patenting rejection still is appropriate in this case.
With regards to the dependent claims:
Co-pending application 18792389 claims 2, 10, 18 read on application claims 2, 11.
Co-pending application 18792389 claims 3, 11, 19 read on application claims 3, 12.
Co-pending application 18792389 claims 4, 12, 20 read on application claims 4, 13.
Co-pending application 18792389 claims 5, 13, 21 read on application claims 5, 14.
Co-pending application 18792389 claims 6, 14, 22 read on application claims 6, 15.
Co-pending application 18792389 claims 7, 15, 23 read on application claims 7, 16.
Co-pending application 18792389 claims 8, 16, 24 read on application claims 8, 17.
This is a provisional obviousness-type double patenting rejection because the conflicting claims have been in fact not been patented yet.
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 non-obviousness.
Claims 1-5, 7-14, 16-19 are rejected under 35 U.S.C. 103 as being unpatentable over Jarjoui (US 20220116226 A1) in view of Fletcher (US 2022417025 A1).
Regarding Claims 1, 10, 19. Jarjoui discloses:
receiving a request to access one or more wallets on a blockchain, the request including an authorization code associated with a controlling party associated with the one or more wallets and user credentials associated with the controlling party; [see at least (0084) The client-side application may be used by an N user to authorize a received transaction. The client-side application may be used to decrypt a second layer of encryption of the double encrypted key share. (0085) each of the N users, have in their possession or accessible to them, a double encrypted key share associated with a private key of a wallet or electronic account (i.e., having an inner and outer layer of encryption)]
decrypting a first portion of a private key based on the authorization code and…; [see at least (0085) To decrypt or unlock the outer layer of the double layer of encryption of the key share, the client-side application receives a user's security credentials which exposes the user's private key. The client-side application uses the exposed user private key to decrypt the outer layer of encryption of the double encrypted key share.]
decrypting a second portion of the private key based on credentials associated with an application through which the wallet is accessed; and [see at least Figs. 7, 9, 11, (0065) The system 700 includes a second sub-system 704 which includes a digital signing service 720. (0075) Device 704 in FIG. 7 is represented as device 900 in FIG. 9. Upon receiving a system request, the device 900 generates a wallet private key 902 and public key pair. (0092) For each of the transaction packets that are confirmed to be generated by the respective N users (e.g., via confirmation of their digital signature), then the device 704 proceeds to recreate a wallet private key using the encrypted key shares for each of the confirmed transaction packets. The device 704 decrypts the encrypted key share using the private key 906 of the device 704, 900.]
granting access to the wallet based on the decrypted first portion and the decrypted second portion of the private key. [see at least (0002) The electronic wallet will only release the crytpo currency once the wallet verifies a withdrawal request is digitally signed by the owner of the private key. (0092) The device 704, 900 uses at least a quorum of the decrypted key shares to generate (i.e., recreate) the wallet private key. The device 704, 900 then digitally signs (i.e., authorizes) the digital transaction using the generated wallet private key.]
Jarjoui discloses authenticating credential to grant access to wallet does not disclose, however, Jarjoui does not disclose:
a salt associated with the user credentials;
Nonetheless, Fletcher discloses adding salt to data:
a salt associated with the user credentials; [see at least (0049) Online platforms, such as https://brainwallet.io/, https://paper.dash.org/etc., can easily generate deterministic cryptocurrencies addresses given a password/passphrase and some salt, i.e. random data that is used as an additional input to the hashing one-way function.]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the features of Jarjoui to include the features of Fletcher. A person with the ordinary skill in the art would have been motivated to secure users’ credentials taught by Jarjoui using the salt as taught by Fletcher, in order to salt the users’ credentials. Jarjoui discloses decrypting data. Fletcher teaches adding salt to users’ data. Because both Jarjoui, as well as Fletcher are in the field of managing credentials and references addresses establishing security by adding salt to user data. Moreover, since the elements disclosed by Jarjoui, as well as Fletcher 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 Jarjoui/Fletcher.
Regarding Claims 2, 11. Jarjoui, Fletcher discloses the limitations of Claims 1, 10. Jarjoui further discloses:
wherein the authorization code associated with the controlling party comprises an alphanumeric string. [see at least (0029) Users owning a wallet must separately provide a password and/or pin to access their respective wallets. (0064) At least (x) of the total number (y) users must separately provide a password and/or pin to unlock their private key share 610, 612, 614, 616, 618 and the system 100 provides unlocked private key share 610, 612, 614, 616, 618 to the data storage service 150, 650 … the system 100 may require an additional 2-factor authentication for the users (e.g., by providing an SMS text message with a passcode, or push notification to a device of the user with a passcode) where the user must additionally enter the passcode to unseal the stored encrypted data]
Regarding Claims 3, 12. Jarjoui, Fletcher discloses the limitations of Claims 1, 10. Jarjoui, Fletcher fails to expressly disclose:
wherein the authorization code associated with the wallet comprises one or more question-answer pairs. [see at least (0029) Users owning a wallet must separately provide a password and/or pin to access their respective wallets. (0064) At least (x) of the total number (y) users must separately provide a password and/or pin to unlock their private key share 610, 612, 614, 616, 618 and the system 100 provides unlocked private key share 610, 612, 614, 616, 618 to the data storage service 150, 650 … the system 100 may require an additional 2-factor authentication for the users (e.g., by providing an SMS text message with a passcode, or push notification to a device of the user with a passcode) where the user must additionally enter the passcode to unseal the stored encrypted data]
Note: The above combination of Jarjoui, Fletcher does not expressly disclose wherein the authorization code associated with the wallet comprises one or more question-answer pairs. However this limitation represents non-functional descriptive material and does not affect how the claimed method functions (i.e., the descriptive material does not have any claim function in the claimed method; see MPEP 2106.01). A “wherein” clause does not function to actively limit the claim language. Therefore, the claim element is considered, but given no patentable weight. (MPEP 2111.05). The reference is provided for the purpose of compact prosecution.
Regarding Claims 4, 13. Jarjoui, Fletcher discloses the limitations of Claims 1, 10. Jarjoui further discloses:
wherein decrypting the second portion of the private key comprises decrypting a first sub-portion of the second portion based a first set of credentials associated with the application and a second sub-portion of the second portion based on a second set of credentials associated with the application. [see at least [0102] the systems 100, 700, 900 using Shamir's secret sharing technique, the systems 100, 700, 900 may generate N(M) key shares for a respective N key share.]
Regarding Claims 5, 14. Jarjoui, Fletcher discloses the limitations of Claims 1, 10. Fletcher further discloses:
wherein the salt comprises a randomly generated number encrypted using a key associated with the user credentials. [see at least (0049) Online platforms, such as https://brainwallet.io/, https://paper.dash.org/etc., can easily generate deterministic cryptocurrencies addresses given a password/passphrase and some salt, i.e. random data that is used as an additional input to the hashing one-way function.]
Note: Note: MPEP 2144.01 sets forth that it is proper to take into account not only specific teachings of the reference but also the inferences which one skilled in the art would reasonably be expected to draw therefrom. Here, it is reasonable to infer that salt comprises randomly generated number as a salt is adding unique random string of characters to the data. And, therefore one of skill in the art would have understood the reference to teach the limitation.
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the features of Jarjoui to include the features of Fletcher. A person with the ordinary skill in the art would have been motivated to secure users’ credentials taught by Jarjoui using the salt as taught by Fletcher, in order to salt the users’ credentials. Jarjoui discloses decrypting data. Fletcher teaches adding salt to users’ data. Because both Jarjoui, as well as Fletcher are in the field of managing credentials and references addresses establishing security by adding salt to user data. Moreover, 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 Claims 7, 16. Jarjoui, Fletcher discloses the limitations of Claims 1, 10. Jarjoui further discloses:
wherein granting access to the wallet comprises granting access to withdraw items stored in the wallet to an external resource based on signing a transaction using the decrypted first portion and the decrypted second portion of the private key. [see at least (0002) The electronic wallet will only release the crypto currency once the wallet verifies a withdrawal request is digitally signed by the owner of the private key. (0092) The device 704, 900 uses at least a quorum of the decrypted key shares to generate (i.e., recreate) the wallet private key. The device 704, 900 then digitally signs (i.e., authorizes) the digital transaction using the generated wallet private key.]
Regarding Claims 8, 17. Jarjoui, Fletcher discloses the limitations of Claims 1, 10. Jarjoui further discloses:
wherein granting access to the wallet comprises: generating an intermediate encrypted version of the private key based on the decrypted first portion and the decrypted second portion of the private key; and [see at least (0092) The device 704, 900 uses at least a quorum of the decrypted key shares to generate (i.e., recreate) the wallet private key. The device 704, 900 then digitally signs (i.e., authorizes) the digital transaction using the generated wallet private key.]
decrypting the private key based on the intermediate encrypted version of the private key and a platform-specific decryption key, wherein the decrypted private key grants access to the wallet. [see at least Figs. 7, 9, 11, (0065) The system 700 includes a second sub-system 704 which includes a digital signing service 720. (0075) Device 704 in FIG. 7 is represented as device 900 in FIG. 9. Upon receiving a system request, the device 900 generates a wallet private key 902 and public key pair. (0092) For each of the transaction packets that are confirmed to be generated by the respective N users (e.g., via confirmation of their digital signature), then the device 704 proceeds to recreate a wallet private key using the encrypted key shares for each of the confirmed transaction packets. The device 704 decrypts the encrypted key share using the private key 906 of the device 704, 900.]
Regarding Claims 9, 18. Jarjoui, Fletcher discloses the limitations of Claims 1, 10. Jarjoui further discloses:
wherein the controlling party associated with the one or more wallets comprises a party associated with a centralized platform through which owners of the one or more wallets perform transactions on the blockchain. [see at least Fig.7 (0065) system 700 architecture for processing digital transactions using secured encrypted private keys. The system 700 includes a first sub-system 702 including one or more client devices 710 interconnected via a communications link 735 to an intermediary service 740.]
Claims 6, 15 are rejected under 35 U.S.C. 103 as being unpatentable over Jarjoui in view of Fletcher, as applied to claims [1, 10], in further view of Rocquelay (US 20200351102 A1).
Regarding Claims 6, 14, 22. Jarjoui, Fletcher discloses the limitations of Claims 1, 10. Jarjoui further discloses:
receiving a request to generate the one or more wallets, the request including at least the authorization code associated with the controlling party associated with the wallet; [see at least (0084) The client-side application may be used by an N user to authorize a received transaction. The client-side application may be used to decrypt a second layer of encryption of the double encrypted key share. (0085) each of the N users, have in their possession or accessible to them, a double encrypted key share associated with a private key of a wallet or electronic account (i.e., having an inner and outer layer of encryption)]
selecting the private key associated with the wallet…; and [see at least Fig.8, (0067) The system 700 via device 704 generates a wallet private key and public key pair (block 810). The public key may serve as a wallet or account identifier and/or the device 704 may generate a separate account or wallet identifier and associate the public key to the generated identifier.]
generating the wallet based on the selected private key. [see at least Fig. 8, (0067) The device 704 associates the wallet private key with an electronic wallet and/or other electronic account. The wallet private key is used for accessing and conducting transactions for the associated electronic wallet or account.]
The combination of Jarjoui in view of Fletcher discloses managing data. However, the above combination does not disclose:
… from an entropy pool of private keys
However, Rocquelay discloses:
… from an entropy pool of private keys [see at least (0057) the authentication keys and the symmetrical encryption keys are generated by aggregation of data stored in the entropy pool.]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the features of Jarjoui, Fletcher to include the features of Rocquelay. A person with the ordinary skill in the art would have been motivated to secure users’ credentials taught by Jarjoui, Fletcher using the cryptographic keys as taught by Rocquelay, in order to securely store the cryptographic keys. Jarjoui, Fletcher discloses decrypting data. Rocquelay teaches private key being stored in an entropy pool. Because both Jarjoui, Fletcher as well as Rocquelay are in the field of managing credentials and references addresses establishing security by storing the private key securely. Moreover, since the elements disclosed by Jarjoui, Fletcher as well as Rocquelay 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 Jarjoui, Fletcher/Rocquelay.
Relevant Prior Art Not Relied Upon
The prior art made of record and not relied upon which, however, is considered pertinent to applicant's disclosure:
US 20230252456 A1 Rapowitz; Samuel et al. KNOWLEDGE-BASED AUTHENTICATION FOR ASSET WALLETS - Systems and methods for recovery access to lost blockchain wallet seed phrases are disclosed. The systems and methods can store seed phrases for users for future retrieval. In some examples, a decentralized oracle creates an oracle private key that can be used to authenticate a user who is requesting the seed phrase. In some examples, the oracle creates a private/public key pair that can be used to transmit and store an encrypted version of the seed phrase. The authentication steps described herein also include knowledge-based authentication questions about the wallet, e.g., prior transactions using the wallet, value of the wallet, and the like.
US 20220094537 A1 SHIMADA; Junichi et al. PRIVATE KEY CREATION USING LOCATION DATA - Methods and a system of generating a master seed using location-based data. The system includes a pseudo-random number generator configured to generate a random number and a global positioning system module configured to determine a location of the system. The system also includes an encryption module configured to generate a signing request message. The signing request message includes the random number and the location. The system further includes a communication device configured to transmit the signing request message to a location authority for authorization. The communication device further configured to receive a signature from the location authority upon authorization of the signing request message. The system is further configured to generate a master seed based on the signature.
US 20110022916 A1 Desai; Prasanna et al. METHOD AND SYSTEM FOR SAVING POWER FOR PACKET RE-TRANSMISSION IN AN ENCRYPTED BLUETOOTH LOW POWER LINK LAYER CONNECTION - A Bluetooth low power (BLE) receiver receives a data packet in an encrypted link layer connection from a BLE transmitter. The data packet comprises a transmitted protocol data unit (PDU) and associated cyclic redundancy code (CRC). The PDU comprises a message integrity code (MIC). The BLE receiver determines a connection SNR. In a high connection SNR condition, the BLE receiver determines packet retransmission based on MIC verification without CRC checking. A MIC indication is generated by comparing a local MIC and the MIC in the received data packet. CRC checking is turned on or off for power saving based on the MIC indication and connection SNR. In a high connection SNR, the BLE receiver determines, without CRC checking, to retransmit the received data packet for a MIC failure indication. The local MIC is calculated using a shared secret Encryption Key of 32-bit, 64-bit or 128-bit derived from multiple entropy pools.
US 20240333500 A1 Desmarais; Philippe et al. SYSTEMS, METHODS, AND DEVICES FOR SECURE BLOCKCHAIN TRANSACTION AND SUBNETWORKS - Provided herein is a system, device, method, and subnetwork for performing a secure blockchain transaction of a digital asset. The system includes a terminal for generating the blockchain transaction, the terminal configured to operate in a first mode and a second mode, and a switch connector for preventing the terminal from operating in the first mode and the second mode simultaneously. When the terminal is in the first mode, the terminal is connected via a network to a system provider server, the system provider server in communication with a plurality of blockchain devices. When the terminal is in the second mode, the terminal is in communication with a cold storage device. The cold storage device is configured to store a private key for signing the blockchain transaction. The terminal is configured to sign the blockchain transaction on the cold storage device using the private key.
US 11233658 B2 Jarjoui; Wissam et al. Digital transaction signing for multiple client devices using secured encrypted private keys - Methods, systems, and apparatus, including computer programs encoded on computer storage media, for digital transaction signing for multiple client devices using secured encrypted private keys. The system generates, by a device, a private key and public key pair. The key pair is associated with an electronic account. The device also has an associated private key and public key pair. The device generates multiple key shares of the generated private key associated with the electronic account. The device encrypts each of the multiple key shares with the public key of the device thereby creating multiple first or inner layer of encrypted key shares. The device then encrypts each of the multiple first encrypted key shares each with a separate user public key associated with a user thereby creating multiple second or outer layer of encrypted key shares. The double encrypted key shares are then distributed to the respective users having the user public key.
US 12231561 B2 Valkaitis; Mindaugas Managing access to data - A method including receiving, by a user device, encrypted content and an encrypted assigned private key associated with the encrypted content; decrypting, by the user device, the encrypted assigned private key based at least in part on utilizing a master key to determine a decrypted assigned private key; determining, by the user device, a combination decryption key based at least in part on utilizing the decrypted assigned private key and an access public key associated with the encrypted content; decrypting, by the user device, an encrypted access private key associated with the access public key to determine a decrypted access private key; and decrypting, by the user device, the encrypted content based at least in part on utilizing the decrypted access private key is disclosed. Various other aspects are contemplated.
US 9582671 B2 Ryhorchuk; Kent W. et al. Security and data privacy for lighting sensory networks - In various example embodiments, a system and method are provided for protection customer data collected at sensor nodes within a networked system. A key recovery module determines the encrypted sensor data in a request was encrypted with a certified public key associated with a first customer key-pair. The first customer key-pair represents a recovered private key. The key recovery module determines the private key associated with the first customer key-pair is encrypted with the private key associated with a second customer key-pair. The private key associated with the first customer key-pair is decrypted by using the private key associated with the second customer key-pair. The encrypted sensor data in the request is decrypted using the decrypted private key associated with the first customer key-pair.
Response to Amendments/Arguments
With respect to Applicant’s Remarks as to the claims being rejected under 35 USC § 101.
Applicant submits: “The Problem and the Claimed Solution In the present case, the claims are directed to a technical solution to problems arising in the field of blockchain-based systems, including security concerns involved in accessing wallets on a blockchain network. As the Specification describes: Generally, preventing malicious actions from being taken in respect of a wallet involves maintaining secrecy around the private key. To do so, some applications link a private key to a series of words, or a recovery phrase, that a user can use to recover a private key associated with a wallet. These recovery phrases generally include a significant number of words. Because of the length of these recovery phrases, users often copy these phrases and store the copy of these phrases in insecure locations which can be easily accessed. In turn, because recovery phrases can often be easily accessed, the security of a wallet and the contents therein may be compromised.... Because access to a private key associated with a wallet grants access to the assets contained in a wallet and allows transactions to be performed with respect to the assets in the wallet, the privacy and security of the private key should be maintained. Various techniques are generally used to preserve access to the private key associated with a user's wallet. For example, users may maintain a record of the private key associated with their wallet in a separate (digital or physical) repository. In another example, because private key addresses are generally long alphanumeric strings which are difficult to remember, various key derivation techniques can be used to aid in the retrieval of the private key associated with the wallet. For example, a multi-word passphrase can be generated and used as an input into a key derivation function in order to generate (or retrieve) the private key associated with a wallet. However, while a passphrase may be less complicated to remember than the private key itself, the passphrase generally includes a sufficient number of words such that users store the passphrase in a separate (digital or physical) repository. Thus, users still maintain a record of the private key associated with their wallet in potentially insecure locations, thus exposing the private key of their wallets and potentially allowing malicious actors access to their wallets and the assets contained therein. Maintaining records of private keys associated with a controlling party for multiple accounts may magnify the impact of malicious activity, as a compromise of a private key used by the controlling party to manage multiple accounts may allow a malicious party to exfiltrate assets from many wallets. Specification 11 [0006], [0022] (emphasis added). The claimed methods and systems provide a solution to these problems, namely sharding a private key into multiple portions, each portion independently encrypted. For example, as the Specification provides: Generally, a private key can be sharded, or split, into multiple portions, with some portions being encrypted using credentials associated with the controlling party and other portions being encrypted using credentials associated with an application or platform on which the wallet is hosted. By doing so, multiple user-facing techniques can be exposed to allow a user to decrypt the portions of the private key encrypted using credentials associated with the controlling party, while not exposing techniques by which the private key itself can be directly recovered (e.g., by not exposing a passphrase or other private key recovery mechanism by which the entirety of the private key associated with a wallet can be recovered). By doing so, aspects of the present disclosure may allow users to easily access wallets while maintaining the security of these wallets, as a private key defining a wallet may not be derived directly from data known to a user of the application or platform hosting the wallet.... To protect the private key selected from the key entropy pool 114, wallet generator 112 can split, or shard, the private key into multiple portions (or shards). These portions can be independently encrypted such that a compromise of the keys involved in encrypting one portion of the private key does not expose the entire private key, and thus the wallet associated with the private key, to a malicious party. For example, the private key can be sharded into a first portion and a second portion, with the first portion being encrypted based on the authorization code generated by the controlling party of a centralized platform that is creating a wallet for an ultimate owner of that wallet using the key management system 110 and the second portion being encrypted based on credentials associated with an application through which the wallet is accessed. The first portion of the private key may be referred to herein as the "controlling party portion" of the private key, and the second portion of the private key may be referred to herein as the "platform portion" of the private key. Specification 11 [0023], [0029] (emphasis added). The claims embody the solution described in the Specification, for example, by reciting: (1) "receiving a request to access one or more wallets on a blockchain, the request including an authorization code associated with a controlling party associated with the one or more wallets and user credentials associated with the controlling party"; (2) "decrypting a first portion of a private key based on the authorization code and a salt associated with the user credentials"; (3) "decrypting a second portion of the private key based on credentials associated with an application through which the wallet is accessed"; and (4) "granting access to the one or more wallets based on the decrypted first portion and the decrypted second portion of the private key." Step 2A, Prong 1 - The Claims Are Not Directed to an Abstract Idea Applicant submits that the claims are eligible under the first prong of the Step 2A analysis because the features recited in the claims are not directed to an abstract idea and the Examiner has not established that the features recited in the claims fall within any of the groupings identified in the M.P.E.P. The Federal Circuit has made clear that "[s]oftware can make non-abstract improvements to computer technology just as hardware improvements can." See Enfish, LLC v. Microsoft Corp., 822 F.3d 1327, 1355 (Fed. Cir. 2016). Consistent with this principle, the M.P.E.P. notes in no uncertain terms: "[S]oftware is not automatically an abstract idea." M.P.E.P. § 2106.04(a). Thus, improvements need not be specifically linked to improvements in the computer functionality, but may instead be directed to "other technology."Id. Here, the claimed features are an improvement to computer functionality (e.g., by independently encrypting different shards of a private key), and not merely commercial or legal interactions, contrary to the Examiner's assertion. Office Action, pp. 3-4. The Examiner asserts that certain claim features fall within the grouping of certain methods of organizing human activity (in particular, commercial or legal interactions). Id. Applicant respectively disagrees with this categorization. The grouping of certain methods of organizing human activity includes "fundamental economic principles or practices (including hedging, insurance, mitigating risk); commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations); managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions)." M.P.E.P. § 2106.04. The Office Action asserts that several of the features recited in Applicant's claims "covers agreements in the form of advertising, marketing, sales activities or behaviors, business relationships (e-commerce), which falls under ... Certain Methods of Organizing Human Activity, i.e., Commercial or Legal Interactions." Office Action, pp. 3-4. Notwithstanding the absence of reasoning for why or how the claims recite certain methods of organizing human activity, Applicant submits that the claims do not recite merely "commercial or legal interactions," as asserted by the Examiner, but instead recite specific technical features related to a specific encryption scheme for independently encrypting different shards of a private key, such as "receiving a request to access one or more wallets on a blockchain, the request including an authorization code associated with a controlling party associated with the one or more wallets and user credentials associated with the controlling party"; "decrypting a first portion of a private key based on the authorization code and a salt associated with the user credentials"; "decrypting a second portion of the private key based on credentials associated with an application through which the wallet is accessed"; and "granting access to the one or more wallets based on the decrypted first portion and the decrypted second portion of the private key." Thus, Applicant's claims do not recite features that fall within the grouping of certain methods of organizing human activity. Applicant next directs the Examiner's attention to the Board's decision in Ex parte Raux, in which claims that explicitly recited various computer technology constructs were found patent eligible. Ex parte Raux, Appeal No. 2019-000592 (P.T.A.B. Oct. 29, 2019), at pp. 14-15. In that case, the Board found that the claims at issue were not directed to mathematical concepts, mental processes, or certain methods of organizing human activity, and thus, did not recite an abstract idea, because the recitation of specific computer constructs, such as "object" or "code," constituted a recitation of "technical terms of art in software engineering and computer science."Id. Because the claims recited technical terms of art in software engineering and computer science, the Board found that "[a]rtisans of ordinary skill would have understood the basic focus of claim 1 is the use of software technology implemented on a computer processor" for a specific purpose. Id. (citing MICROSOFT COMPUTER DICTIONARY (5th ed. 2002)). Likewise, Applicant's claims clearly recite terms of art in software engineering and computer science sufficient to show that the basic focus of the claims is the use of software technology, not to certain methods of organizing human activity. For example, Applicant's11 claims recite computer-specific software constructs such as "blockchain," "wallet," and "private key." Therefore, the claims are not directed to commercial or legal interactions, and thus are not directed to an abstract idea. Further, Applicant submits that the claims are not directed to an abstract idea because the claims do not recite a result of a process, but a specific manner by which the process is performed. In SAP America, Inc. v. Investpic, LLC, the Federal Circuit noted that claims in other cases that were previously held to be patent eligible "avoided being 'abstract' in another sense reflected repeatedly in our cases ...: they had the specificity required to transform the claim from one claiming only a result to one claiming a way of achieving it." 890 F.3d 1016, 1021 (Fed. Cir. 2018) (comparing claims held eligible, inter alia, in McRO,Inc. v. BandaiNamco Games America Inc, 837 F.3d 1299 (Fed. Cir. 2016) and Finjan, Inc. v. Blue Coat Sys. Inc., 879 F.3d 1299 (Fed. Cir. 2018) to the claims held ineligible in SAP America). In the present case, the claims recite a specific process for independently encrypting different portions of a private key. This is in contrast to claims found ineligible in Intellectual Ventures I v. Capital One Fin. Corp., where nothing in the claims indicated what steps were performed other than merely collecting, displaying, and manipulating data in an XML document. Intellectual Ventures I, 850 F.3d 1332 (Fed. Cir. 2017). That is, unlike the claims in Intellectual Ventures I, which claimed a result-oriented solution without details of how the result was achieved, the present claims recite specific steps by which a private key may be sharded into different portions that are then independently encrypted to enhance the security of the blockchain system. Thus, Applicant submits that the claims do not recite an abstract idea and are thus eligible under the first prong of the Step 2A inquiry”
Examiner responds: Examiner has fully considered, but doesn’t find Applicant’s argument persuasive. Examiner respectfully disagree with the applicant, the argues the claimed language does not recite an abstract idea and further recites specific specification paragraph. However, for Step 2A prong 1 analysis, the examiner examined the claim languages, and conclude that it does recite an abstract idea. The recited claim language “receiving a request … decrypting a first portion … decrypting a second portion”, however the claim language is not directed to a technological improvement. Furthermore, the applicant argues, Additionally, the applicant argues “claims recite computer-specific software constructs such as "blockchain," "wallet," and "private key."”; the recited language of “blockchain” “wallet,” “private key” are general implementation of blockchain environment. Furthermore, the examiner would like to emphasize these language are used as a tool to perform the abstract idea. See MPEP 2106.04 and the updated rejection above. Thus, the rejection is proper and has been maintained.
Applicant submits: “Step 2A, Prong 2- The Claims Integrate any Alleged Abstract Idea into a Practical Application While Applicant respectfully disagrees that the claims recite the abstract ideas alleged in the Office Action, Office Action, pp. 3-4, Applicant asserts that the alleged abstract ideas are nevertheless integrated into a practical application. Under the second prong of the Step 2A inquiry, "Examiners evaluate integration into a practical application by ...evaluating ...additional elements individually and in combination to determine whether they integrate the exception into a practical application," such as by considering whether an additional element reflects "[a]n improvement in the functioning of a computer, or an improvement to other technology or technical field." M.P.E.P. § 2106.04(d); see also M.P.E.P. § 2106.05 (discussing improvements to computer functionality in the scope of the eligibility analysis). A claim comprising any additional element that integrates the judicial exception into a practical application of that exception is directed to eligible subject matter. Id.; see also Thales Visionix Inc. v. U.S., 850 F.3d 1343, 1347 (Fed. Cir. 2017) (stating that claim elements are considered individually and as a whole so as to "articulate what the claims are directed to with enough specificity to ensure the [Step 2A] inquiry is meaningful."); Ex parte Donovan, Appeal No. 2017-005993 (P.T.A.B. Mar. 5, 2019) at pp. 9-15 (finding claims patent-eligible under Step 2A, Prong 2 of the Alice/Mayo test where the claim as a whole requires specific interoperation of hardware and specially configured computing modules). Applicant submits that at least the following features of the claims integrate any alleged abstract idea into a practical application because they reflect an improvement to other technology or technical field: (1) "receiving a request to access one or more wallets on a blockchain, the request including an authorization code associated with a controlling party associated with the one or more wallets and user credentials associated with the controlling party"; (2) "decrypting a first portion of a private key based on the authorization code and a salt associated with the user credentials"; (3) "decrypting a second portion of the private key based on credentials associated with an application through which the wallet is accessed"; and (4) "granting access to the one or more wallets based on the decrypted first portion and the decrypted second portion of the private key." For example, the claims reflect a technical improvement in the field of blockchain security. Wallets on a blockchain are defined based on a private key and public key. Specification [0004]. Sharing the private keys associated with a wallet may expose the wallet to malicious activity such as, for example, unauthorized transfer of assets in the wallet. Id. [0005]. For centralized platforms, the platform maintains the wallet on behalf of the users of the platform. Id. Conventionally, users on the platform rely on a recovery phrase to recover their private keys. Id. [0006]. However, because of the recovery phrase's length, users often store these phrases in insecure locations which can be easily accessed and therefore compromise the security of the wallet. Id. As a result of this peculiarity, blockchains are susceptible to unique security threats based on unauthorized access to the private key. To counteract these blockchain-based security concerns, the claimed invention includes techniques for independently encrypting different portions of a private key. For example, the Specification describes how a first portion of the private key may be encrypted based on the authorization code generated by the controlling party, and a second portion of the private key may be encrypted based on credentials associated with an application through which the wallet is accessed. Applicant respectfully directs the Examiner's attention to the Board's decision in Ex parteIsrael, in which claims that recited "[a]n entity extraction system for efficient parsing to populate entity properties based on event data" were found to be eligible under Step 2A, Prong 2. Ex parteIsrael, Appeal No. 2022-001271, p. 14 (P.T.A.B. Dec. 1, 2022). In Ex parteIsrael, the Board held that at least the following limitations of claim 1 integrated the recited abstract idea into a practical application: an entity extraction rule recommender which upon execution by the processor examines particular event data from an event data source and produces a recommendation citing at least one entity extraction rule and also targeting at least one entity identifier for use in extracting one or more entity field values from the particular event data and using the one or more extracted entity field values to populate one or more corresponding entity properties; and an entity extraction rules modeler which includes a machine learning classifier that upon execution classifies the entity extraction rule according to its resemblance to one or more other entity extraction rules. Id., p. 14. The Board reasoned that the claim limitations were integrated into a practical application because, as quoted from the applicant's specification, "taking advantage [o]f the teachings herein substantially improves the harvesting and performance of entity extraction rules to support visualizations, analyses, and other event data processing operations."Id., p. 15. Applicant's claims are analogous to those held patentable in Ex parteIsrael. For example, just as the claims of Ex parteIsrael "improve[] the harvesting and performance of entity extraction rules to support visualizations, analyses, and other event data processing operations," id., Applicant's claimed solution improves the function and security of blockchain systems by, for example, independently encrypting different portions of a private key "such that a compromise of the keys involved in encrypting one portion of the private key does not expose the entire private key." Specification [0029]. Thus, just like the claims in Ex parteIsrael, Applicant's claims recite features that integrate any alleged abstract idea into a practical application. Applicant further respectfully directs the Examiner's attention to the Board decision in Ex parte Das, in which claims directed to techniques that improved the efficiency of resource utilization in a computing environment were found eligible under Step 2A, Prong 2 of the Alice/Mayo test because those claims provided an improvement to technology such that computers were not merely used in their ordinary capacity. Ex parte Das, Appeal No. 2020-005686 (P.T.A.B. Mar. 15, 2021), at p. 8 (stating that improvements and functionality tied to a technical construct sufficiently integrate any alleged abstract idea into a practical application). Here, blockchains are a unique type of technical construct generally used in decentralized systems. Specification [0003]. Thus, the present claims15 do not merely use computers in their ordinary capacity, but rather provide an improvement to blockchain systems that integrates the claims into a practical application, as discussed above. Accordingly, Applicant submits that the claims are eligible under Step 2A, Prong 2 of the Alice/Mayo test and respectfully requests withdrawal of this rejection.”
Examiner response: Examiner has fully considered, but doesn’t find Applicant’s argument persuasive. The examiner would like to emphasize that additional element “blockchain” recites high level of generality which is equivalent to instructions to implement the abstract idea. Furthermore, the examiner respectfully disagree with the applicant, the MPEP 2106.04(d) discloses that “an important consideration to evaluate when determining whether the claim as a whole integrates a judicial exception into a practical application is whether the claimed invention improves the functioning of a computer or other technology In short, first the specification should be evaluated to determine if the disclosure provides sufficient details such that one of ordinary skill in the art would recognize the claimed invention as providing an improvement. The specification need not explicitly set forth the improvement, but it must describe the invention such that the improvement would be apparent to one of ordinary skill in the art Second, if the specification sets forth an improvement in technology. the claim must be evaluated to ensure that the claim itself reflects the disclosed improvement.” (Emphasis added) “That is, the claimed invention may integrate the judicial exception into a practical application by demonstrating that it improves the relevant existing technology although it may not be an improvement over well-understood, routine, conventional activity.” (Emphasis added). Thus, the rejection is proper and has been maintained.
Applicant submits: “Step 2B- The Claims Recite an Inventive Concept that Amounts to Significantly More than an Abstract Idea Only if a claim fails both prongs of the revised Step 2A inquiry is Step 2B considered. M.P.E.P. § 2106.04 ("The claim as a whole is directed to a judicial exception (Step 2A: YES) and thus requires further analysis under Step 2B to determine if the claim as a whole amounts to significantly more than the exception itself."). Regarding Step 2B, Section 2106.05(a) notes: "examiners should consider whether the claim 'purport(s) to improve the functioning of the computer itself' or 'any other technology or technical field."'M.P.E.P. § 2106.05(a) (citing Alice Corp. 134 S. Ct. at 2359). "This consideration has also been referred to as the search for a technological solution to a technological problem." Id. To that end, Section 2106.05(a) explains that "[i]f it is asserted that the invention improves upon conventional functioning of a computer, or upon conventional technology or technological processes, a technical explanation as to how to implement the invention should be present in the specification. That is, the disclosure must provide sufficient details such that one of ordinary skill in the art would recognize the claimed invention as providing an improvement." Id. In a Federal Circuit decision, the court held that claims directed to an allegedly abstract idea of "filtering content" were nevertheless eligible under Section 101 because "[t]he inventive concept inquiry requires more than recognizing that each claim element, by itself, was known in the art" and because "an inventive concept can be found in the non-conventional and non-generic arrangement of known, conventional pieces." BASCOM Global Internet v. A T&T Mobility LLC, 827 F.3d 1341, 1350 (Fed. Cir. 2016); see also M.P.E.P. § 2106.05(1). Furthermore, the Federal Circuit held that "[b]y taking a prior art filter solution (one-size-fits-all filter at the ISP server) and making it more dynamic and efficient (providing individualized filtering at the ISP server), the claimed invention represents a 'software-based invention[ ] that improve[s] the performance of the computer system itself."' BASCOM, 827 F.3d at 1351. Similar to BASCOM, the present claims recite non-conventional and non-generic methods and systems, in this case for independently encrypting different portions of a private key, which improve access to blockchain wallets and the technical field of blockchain security. For example, the Specification describes how Applicant's claimed solution improves blockchain security by encrypting a first portion based on the authorization code generated by the controlling party and a second portion based on credentials associated with an application through which the wallet is accessed. Specification [0029]. By independently encrypting the different shards, "a compromise of the keys involved in encrypting one portion of the private key does not expose the entire private key, and thus the wallet associated with the private key, to a malicious party."Id. The improvement is accomplished by particular features in the claims, such as (1) "receiving a request to access one or more wallets on a blockchain, the request including an authorization code associated with a controlling party associated with the one or more wallets and user credentials associated with the controlling party"; (2) "decrypting a first portion of a private key based on the authorization code and a salt associated with the user credentials"; (3) "decrypting a second portion of the private key based on credentials associated with an application through which the wallet is accessed"; and (4) "granting access to the one or more wallets based on the decrypted first portion and the decrypted second portion of the private key." Accordingly, Applicant respectfully submits that the claims are eligible under Step 2B of the Alice/Mayo test and is therefore directed to eligible subject matter under Section 101. Therefore, for at least these additional reasons, Applicant respectfully requests withdrawal of this rejection”
Examiner responds: Examiner has fully considered, but doesn’t find Applicant’s argument persuasive. See updated rejected above and the Step 2B analysis. Thus rejection is proper and has been maintained.
With respect to Applicant’s Remarks as to the Double Patenting.
Applicant submits: “Claims 1, 10, 19 stand rejected on the ground of non-statutory double patenting as being allegedly unpatentable over claims 1, 9, 17 of co-pending US Application No. 18/792,389. While Applicant does not concede validity of the double patenting rejection, Applicant files a terminal disclaimer herewith in the interest of compact prosecution. Accordingly, Applicant respectfully requests that the double patenting rejection be withdrawn
Examiner responds: Examiner has fully considered, but doesn’t find Applicant’s argument persuasive. A terminal disclaimer was filed of by the applicant on 10/29/2025. A decision has been made on 11/03/2025, the terminal disclaimer has been disapproved. The original rejection is maintained. Please see the rejection above.
With respect to Applicant’s Remarks as to the claims being rejected under 35 USC § 103.
Applicant submits: “Claims 1-5, 7-14, and 16-19 stand rejected under 35 USC § 103 as being unpatentable over Jarjoui et al. (US 2022/0116226 A1) in view of Fletcher et al. (US 2022/417025 A1). Applicant respectfully traverses the rejection. Applicant submits that Jarjoui and Fletcher, alone or in combination, do not teach, suggest, or otherwise render obvious "the request including an authorization code associated with a controlling party associated with the one or more wallets and user credentials associated with the controlling party", "decrypting a first portion of a private key based on the authorization code and a salt associated with the user credentials", and "decrypting a second portion of the private key based on credentials associated with an application through which the wallet is accessed" as recited in Claim 1. Claims 10 and 19 recite similar features. In the Office Action, the Examiner relies on Jarjoui for these features except for "a salt". Office Action, p. 13 (citing Jarjoui [0085], [0065], [0075], [0092], Figs. 7, 9, 11). Jarjoui discusses an encryption scheme involving "double encrypted key shares" distributed to different users. Jarjoui, Abstract, [0070]. Jarjoui's double encryption is based on encrypting the key shares first with the public key of the device, and then each with a separate user public key associated with a user. Id., Abstract, [0007], [0085]- [0086]. Conversely, to decrypt the key shares, Jarjoui relies on the user's private key and the device's private key. Id. [0075], [0092]. Once the number of decrypted key shares reaches a threshold ("a quorum"), then the device generates the wallet's private key to sign the transaction. Id. [0092]. In other words, the encryption and decryption in Jarjoui are based on the keys (public and private) of the device and the keys (public and private) of the users. However, Jarjoui's encryption/decryption scheme based on public and private keys does not teach anything about authorization codes or credentials, let alone those of the controlling party and the application as recited in the claims. To the extent Jarjoui mentions credentials, it is in the context of a use's security credentials. Jarjoui [0085]. But the "users" discussed in Jarjoui are the various users of a system where each user has their own wallet and/or electronic account. Id. [0029]-[0030], [0062], [0068]-[0070]. Thus, Jarjoui does not teach anything about the credentials of a controlling party, let alone credentials of an application, and let alone any decryption based on these credentials. Furthermore, Jarjoui is silent as to authorization codes, let alone any decryption based on authorization codes. Therefore, Jarjoui does not teach or suggest "the request including an authorization code associated with a controlling party associated with the one or more wallets and user credentials associated with the controlling party", "decrypting a first portion of a private key based on the authorization code and a salt associated with the user credentials", and "decrypting a second portion of the private key based on credentials associated with an application through which the wallet is accessed" as recited in Claim 1 and similar features recited in Claims 10 and 19. Fletcher fails to remedy the deficiencies of Jarjoui. Fletcher discusses generating and distributing key shares to a "congress" of users on a blockchain. Fletcher, Abstract, [0060]-[0062]. In Fletcher, if a user loses access to their personal private key, the private key shares can be used to generate a valid signature on behalf of the user so long as there are a threshold number of key shares. Id. However, Fletcher is likewise silent as to "authorization code associated with a controlling party", "user credentials associated with the controlling party", and "credentials associated with an application"-let alone any decryption based on these. Therefore, Jarjoui in view of Fletcher fails to teach or suggest "the request including an authorization code associated with a controlling party associated with the one or more wallets and user credentials associated with the controlling party", "decrypting a first portion of a private key based on the authorization code and a salt associated with the user credentials", and "decrypting a second portion of the private key based on credentials associated with an application through which the wallet is accessed" as recited in Claim 1 and similar features recited in Claims 10 and 19. Withdrawal of the rejection is respectfully requested.”
Examiner responds: Examiner has fully considered, but doesn’t find Applicant’s argument persuasive. Examiner respectfully disagree with the applicant, the applicant’s argue each reference individually. The examiner would like to emphasize, the combination of Jarjoui and Fletcher discloses the limitation of claims 1, 10, 19. Furthermore, applicant argues, Jarjoui does not teach authorization code. However the Jarjoui discloses “Users owning a wallet must separately provide a password and/or pin to access their respective wallets.” (see para 0029, Jarjoui). Additionally, the Fletcher reference discloses adding salt to data. Therefore, the combination of Jarjoui, and Fletcher discloses the claim limitation of claims 1, 10, 19. Thus, the rejection is proper, and has been maintained.
Applicant submits: “Claims 6 and 15 stand rejected under 35 USC § 103 as being unpatentable over Jarjoui et al. (US 2022/0116226 A1) in view of Fletcher et al. (US 2022/417025 A1), in further view of Rocquelay et al. (US 2020/0351102 A1). Claims 6 and 15 depend from Claims 1 and 10, respectively, which Applicant submits are allowable over Jarjoui and Fletcher for at least the reasons set forth above. Accordingly, Applicant submits that Claims 6 and 15 are allowable over Jarjoui, Fletcher, and Rocquelay for at least the above reasons and respectfully requests withdrawal of this rejection.”
Examiner responds: Examiner has fully considered, but doesn’t find Applicant’s argument persuasive. Examiner respectfully disagree with the applicant, and would like to emphasize the combination of Jarjoui, Fletcher discloses the claim limitations of claims 1, 10, 19. Thus based on dependency claims 6 and 15 are also rejected. See updated rejection above. Thus, the rejection is proper, and has been maintained.
Conclusion
THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MD S HYDER whose telephone number is (571)270-1820. The examiner can normally be reached Monday - Friday 8:30am - 6: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, 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.
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.
/M.S.H./Examiner, Art Unit 3698 02/09/2026
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698