DETAILED ACTION
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 08/24/2026 has been entered.
Status of Claims
The following is a Non-Final Office Action in response to Applicant’s amendments filed on 08/24/2026.
a. Claims 1, 9, 17 are amended
Overall, claims 1-24 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 Objection(s)
Claims 4, 12, 20 objected to because of the following informalities: Claim 4 pg. . Claims 12, 20 recites similar limitations to claim 4. Appropriate correction is required.
Claim Interpretation
Claim 1, on pg. 2 lines 14-17 recites the limitation “granting access to the one or more wallets based on the decrypted first portion and the decrypted second portion of the private key …” The Examiner argues the newly added phrase (“granting access to the wallet … based on concatenating the decrypted first portion and the decrypted second portion into a concatenated key and signing a transaction using the concatenated key.”) renders the former phrase superfluous as the newly added phrase is more specific than and encompasses the former phrase. Claims 9 and 17 recite the same limitation, and the Examiner came to the same conclusion as claim 1.
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 therefore, subject to the conditions and requirements of this title.
Claims 1-24 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, claims 9-16 are directed to a system, and claims 17-24 are directed to a 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. The limitations of independent claim 1 (which is representative of Claims 9, 17) shown in bold recite an abstract idea as explained in MPEP 2106.04(a). The non-bolded language are additional elements addressed further below.
[A] A computer-implemented method, comprising:
[B] receiving a request to access a wallet on a blockchain, the request including an authorization code associated with the wallet and user credentials associated with an owner of the wallet, and wherein the wallet is associated with a previously generated private key sharded into a first portion encrypted based on the authorization code and a salt associated with the user credentials and a second portion encrypted based on credentials associated with an application through which the wallet is accessed;
[C] decrypting the first portion of the private key based on the authorization code and the salt associated with the user credentials;
[D] decrypting the second portion of the private key based on the credentials associated with the 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 based on concatenating the decrypted first portion and the decrypted second portion into a concatenated key and signing a transaction using the concatenated key.
Claim 1 (which is representative of claims 9, 17) 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.
These overall claim elements in combination cover managing and authenticating credentials, including decrypting credentials, granting access based on the decryption and such activities can be performed by human using pen and paper. Such limitations express 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 claim 9, 17) 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 “computer-implemented,” “blockchain,” and “application” recite 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 additional elements do not preclude from carrying out the identified abstract idea of managing credentials. Therefore, those additional elements do not serve to integrate the identified abstract idea into practical application.
The additional elements in the independent claims shown not bolded above, recite: computer-implemented ([A]), blockchain ([B]), and application ([B], [D]). When considered individually, they amount to nothing more than generally linking the use of the judicial exception to particular technological environment or field of use.
Therefore, the additional steps of claim 1 (which is representative of claims 9, 17) 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 9, 17) 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 elements (limitations [A]-[D]), 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, 9, and 17 are deemed ineligible.
Dependent Claims: Claims 2-7, 10-16, 18-24 are analyzed for subject matter eligibility. However, these claims fail to recite patent eligible subject matter for following reasons:
Claim 2 (which is representative of claims 10, 18), recites the following bolded claim elements as abstract idea as explained in MPEP 2106.04(a). The non-bolded language are additional elements addressed further below. The claim further recites:
[A] wherein the authorization code associated with the wallet 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 claims 11, 19), recites the following bolded claim elements as abstract idea as explained in MPEP 2106.04(a). The non-bolded language are additional elements addressed further below. The claim further recites:
[A] wherein the authorization code associated with the wallet 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 12, 20), recites the following bolded claim elements as abstract idea as explained in MPEP 2106.04(a). The non-bolded language are additional elements addressed further below. 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 [on] 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 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 5 (which is representative of claims 13, 21), recites the following bolded claim elements as abstract idea as explained in MPEP 2106.04(a). The non-bolded language are additional elements addressed further below. 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 14, 22), recites the following bolded claim elements as abstract idea as explained in MPEP 2106.04(a). The non-bolded language are additional elements addressed further below. The claim further recites:
[A] receiving a request to generate the wallet, the request including at least the authorization code 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 15, 23), recites the following bolded claim elements as abstract idea as explained in MPEP 2106.04(a). The non-bolded language are additional elements addressed further below. 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 16, 24), recites the following bolded claim elements as abstract idea as explained in MPEP 2106.04(a). The non-bolded language are additional elements addressed further below. 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)).
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
The nonstatutory 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 timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory 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 Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); 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 nonstatutory 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 nonstatutory 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.
Claims 1-24 provisionally rejected on the ground of non-statutory double patenting as being unpatentable over claims 1-8, 10-17, and 19 of co-pending Application No. 18792378 (reference application). Although the claims at issue are not identical, they are not patentably distinct from each other because the claims of the instant application in view of Jarjoui (US 20220116226 A1), would have been obvious to one of skilled in the art over the claims of the reference application.
The table below maps the claims of reference application to the pending claim limitation of the instant application.
Instant Application: 18/792,389
Co-pending Application: 18/792,378 (Reference application)
Claim 1, 9, 17:
[A] A computer-implemented method, comprising:
[B] receiving a request to access a wallet on a blockchain, the request including an authorization code associated with the wallet and user credentials associated with an owner of the wallet, and wherein the wallet is associated with a previously generated private key sharded into a first portion encrypted based on the authorization code and a salt associated with the user credentials and a second portion encrypted based on credentials associated with an application through which the wallet is accessed;
[C] decrypting the first portion of the private key based on the authorization code and the salt associated with the user credentials;
[D] decrypting the second portion of the private key based on the credentials associated with the 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 based on concatenating the decrypted first portion and the decrypted second portion into a concatenated key and signing a transaction using the concatenated key.
Claim 1, 10, 19:
[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, 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, and wherein the one or more wallets are associated with a previously generated private key sharded into a first portion encrypted based on the authorization code and a salt associated with the user credentials and a second portion encrypted based on credentials associated with an application through which the one or more wallets are accessed;
[C] decrypting the first portion of the private key based on the authorization code and the salt associated with the user credentials;
[D] decrypting the second portion of the private key based on the credentials associated with the application through which the one or more wallets are wallet is accessed; and
[E] granting access to the one or more wallets based on the decrypted first portion and the decrypted second portion of the private key based on concatenating the decrypted first portion and the decrypted second portion into a concatenated key and signing a transaction using the concatenated key.
Claims 2, 10, 18:
[A] wherein the authorization code associated with the wallet comprises an alphanumeric string.
Claims 2, 11:
[A] wherein the authorization code associated with the controlling party comprises an alphanumeric string.
Claims 3, 11, 19:
[A] wherein the authorization code associated with the wallet comprises one or more question-answer pairs.
Claims 3, 12:
[A] wherein the authorization code associated with the controlling party comprises one or more question-answer pairs.
Claims 4, 12, 20:
[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.
Claims 4, 13:
[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.
Claims 5, 13, 21:
[A] wherein the salt comprises a randomly generated number encrypted using a key associated with the user credentials.
Claims 5, 14:
[A] wherein the salt comprises a randomly generated number encrypted using a key associated with the user credentials.
Claims 6, 14, 22:
[A] receiving a request to generate the wallet, the request including at least the authorization code 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.
Claims 6, 15:
[A] 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;
[B] selecting the private keys associated with the one or more wallets from an entropy pool of private keys; and
[C] generating the one or more wallets based on the selected private key.
Claims 7, 15, 23:
[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.
Claims 7, 16:
[A] wherein granting access to the one or more wallets comprises granting access to withdraw items stored in the one or more wallets to an external resource based on signing a transaction using the decrypted first portion and the decrypted second portion of the private key.
Claims 8, 16, 24:
[A] 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
[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.
Claims 8, 17:
[A] wherein granting access to the one or more wallets 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
[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 one or more wallets.
Regarding Claims 1, 10, 19, Reference Application discloses the claimed subject matter: […] 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, 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 […]
Regarding Claims 1, 9, 17, Instant Application discloses the claimed subject matter: […] receiving a request to access a wallet on a blockchain, the request including an authorization code associated with the wallet and user credentials associated with an owner of the wallet, […]
Note: The difference between the claims in the instant application is that the instant application 18792389 does not disclose a controlling party, while the reference application 18792378 does. However, it would have been obvious to omit those features.
Regarding Claims 2, 11, Reference Application discloses the claimed subject matter: wherein the authorization code associated with the controlling party comprises an alphanumeric string.
Regarding Claims 2, 10, 18, Instant Application discloses the claimed subject matter: wherein the authorization code associated with the wallet comprises an alphanumeric string.
Note: The difference between the claims in the instant application is that the instant application 18792389 does not disclose a controlling party, while the reference application 18792378 does. However, it would have been obvious to omit those features.
Regarding Claims 3, 12, Reference Application discloses the claimed subject matter: wherein the authorization code associated with the controlling party comprises one or more question-answer pairs.
Regarding Claims 3, 11, 19, Instant Application discloses the claimed subject matter: wherein the authorization code associated with the wallet comprises one or more question-answer pairs.
Note: The difference between the claims in the instant application is that the instant application 18792389 does not disclose a controlling party, while the reference application 18792378 does. However, it would have been obvious to omit those features.
Regarding Claims 6, 15, Reference Application discloses the claimed subject matter: 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;
Regarding Claims 6, 14, 22, Instant Application discloses the claimed subject matter: receiving a request to generate the wallet, the request including at least the authorization code associated with the wallet;
Note: The difference between the claims in the instant application is that the instant application 18792389 does not disclose a controlling party, while the reference application 18792378 does. However, it would have been obvious to omit those features.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or non-obviousness.
Claims 1-5, 7-13, 15-21, 23-24 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, 9, 17. Jarjoui discloses:
(claims 1, 9, 17) receiving a request to access a wallet on a blockchain, the request including an authorization code associated with the wallet and user credentials associated with an owner of the wallet [see at least (0071) A client-side application of a client device 710 then may require that a receiving N user must enter in their respective credentials (e.g., user-id and password, and/or via a two-step authentication process) to receive their particular double encrypted key. Optionally, the N user may use a suitable decryption software or program of choice to decrypt the outer layer of encryption of the double encrypted key shares using the N user's private key of a PGP private/public key pair. (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)]
(claims 1, 9, 17) wherein the one or more wallets are associated with a previously generated private key sharded into a first portion encrypted based on the authorization code … and a second portion encrypted based on credentials associated with an application through which the one or more wallets are accessed; [(0007) the system divides a wallet private key into multiple key shares that are then used to reconstruct the wallet private key. By using key shares to start ensures that no single user or entity has control over an electronic wallet.]
(claims 1, 9, 17) decrypting the first portion of the private key based on the authorization code and … [(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.]
(claims 1, 9, 17) decrypting the second portion of the private key based on the credentials associated with the application through which the one or more wallets are 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.]
(claims 1, 9, 17) 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 cryptocurrency 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.]
(claim 1, 9, 17) based on concatenating the decrypted first portion and the decrypted second portion into a concatenated key and signing a transaction using the concatenated key. [(0098) When the digital signatures of each N user have been validated, and if the device 704, 900 has received the minimum required number of key shares (e.g., a predetermined quorum of key shares), then the device 704, 900 may generate the wallet private key using the key shares according to Shamir's secret sharing technique. The device 704 uses the obtained key shares to recreate the wallet private key. The device 704, 900 then uses the wallet private key to digitally sign the transaction, thereby creating signed valid transaction data.]
Note: Examiner notes the Jarjoui reference does not expressly disclose “concatenated key”. However, the Applicant’s specification on [0062] discloses “the wallet private key may be generated by concatenating the decrypted controlling party private key shard and the decrypted application private key shard into a single key …” One of skilled in the art under broadest reasonable interpretation can conclude a new key is generated by combining the shards of other keys. In addition, the cited portion of the Jarjoui reference discloses using the key shares (i.e., key shards) to generate a private key (i.e., concatenated key), which is used to digitally sign the transaction. Thus, one of skilled in the art can conclude the steps of generating a private key (i.e., concatenated key) is same as both the applicant’s specification and the Jarjoui references because both uses the key shards to generate the new key. Thus, the generated key using the key shares of Jarjoui reads on the concatenated key of the applicant.
Jarjoui discloses authenticating credentials to grant access to wallet does not disclose, however, Jarjoui does not disclose:
… and a salt associated with the user credentials
… a salt associated with the user credentials;
Nonetheless, Fletcher discloses adding salt to data:
… and 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.]
… 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 process of authenticating credentials of Jarjoui to include the generated salt 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, 10, 18. Jarjoui, Fletcher discloses the limitations of Claims 1, 9, 17. Jarjoui further discloses:
wherein the authorization code associated with the wallet 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, 11, 19. Jarjoui, Fletcher discloses the limitations of Claims 1, 9, 17. Jarjoui further discloses
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: Examiner notes the above combination of Jarjoui, Fletcher does not expressly disclose the limitation wherein the authorization code associated with the wallet comprises one or more question-answer pairs. However, the exact data that comprise the authorization code (i.e., pin code, question-answer pair, etc.) is non function descriptive material (see MPEP 2111.05). The data indicating the authorization code does not further limit how the request to access the wallet data (see MPEP 2111.04). Therefore, the type of data in the authorization code cannot be given patentable weight. The reference is provided for the purpose of compact prosecution.
Regarding Claims 4, 12, 20. Jarjoui, Fletcher discloses the limitations of Claims 1, 9, 17. Jarjoui further discloses:
wherein decrypting the second portion of the private key comprises decrypting a first sub-portion of the second portion based [on] 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. [(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, 13, 21. Jarjoui, Fletcher discloses the limitations of Claims 1, 9, 17. Fletcher further discloses:
wherein the salt comprises a randomly generated number encrypted using a key associated with the user credentials. [(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: Here, it is reasonable to infer that salt comprises randomly generated number as a salt is adds unique random string of characters to the data. Therefore, one of skilled 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, 15, 23. Jarjoui, Fletcher discloses the limitations of Claims 1, 9, 17. 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, 16, 24. Jarjoui, Fletcher discloses the limitations of Claims 1, 9, 17. 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.]
Claims 6, 14, 22 are rejected under 35 U.S.C. 103 as being unpatentable over Jarjoui in view of Fletcher, as applied to claims [1, 9, 17] above, in further view of Rocquelay (US 20200351102 A1).
Regarding Claims 6, 14, 22. Jarjoui, Fletcher discloses the limitations of Claims 1, 9, 17. Jarjoui further discloses:
receiving a request to generate the one or more wallets, the request including at least the authorization code 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 keys 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.
Response to Amendments/Arguments
With respect to Applicant’s Remarks as to the claims being rejected under 35 USC § 101.
Applicant submits: “This ordered combination improves blockchain technology by changing how the private key used for blockchain transaction signing is protected, decrypted, recombined, and used. Rather than storing or recovering a complete private key or recovery phrase from a single user-known secret, the claimed process requires a private key that has been sharded into a first portion encrypted based on the authorization code and a salt associated with the user credentials, and a second portion encrypted based on credentials associated with the application through which the wallet is accessed. The claimed process then separately decrypts the first portion based on the authorization code and the salt associated with the user credentials, separately decrypts the second portion based on the credentials associated with the application, concatenates the decrypted first and second portions into a concatenated key, and signs a transaction using the concatenated key. The Specification describes that sharding the private key into independently encrypted portions prevents compromise of the keys involved in encrypting one portion from exposing the entire private key, and thus the wallet associated with the private key, to a malicious party. Id. ,i [0026]. The Specification further explains that the cryptographic salt may be bound to user credentials and protected by cryptographic keys so that malicious parties are unable to recover the cryptographic salt and therefore unable to recover the encryption key used to protect the user portion of the private key. Id. ,i [0028].”
Examiner responds: The Applicant argues the claim recites technological improvement. The Examiner argues, the claims 1, 9, 17 recites, “receiving a request … decrypting a first portion … decrypting a second portion … granting access”. And these limitations as whole environment of use in a blockchain environment. The examiner has considered the remarks but does not find them persuasive. The rejection is maintained.
Applicant submits: “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.")”
Examiner responds: The examiner emphasizes, based on previous analysis of the argument, that claim as a whole or in combination fails both prongs of Step 2A, and requires further analysis under Step 2B. The examiner has considered the remarks and cited cases but does not find them persuasive. The rejection is maintained.
With respect to Applicant’s remarks as to the claims being rejected under 35 USC § 103.
Applicant submits: “the encryption and decryption in Jarjoui are based on the keys of the device and the keys of the users. Jarjoui therefore does not disclose the claimed multidomain private-key architecture in which a previously generated private key is sharded into a first portion encrypted based on an authorization code and a salt associated with user credentials, and a second portion encrypted based on credentials associated with an application through which the wallets are accessed. Nor does Jarjoui disclose decrypting those two differently protected portions using the claimed credential domains, concatenating the decrypted portions into a concatenated key, and signing a transaction using the concatenated key.”
Examiner responds: The Applicant argues the Jarjoui reference does not teach the claim limitation. The Examiner respectfully disagree with the applicant summary of the Jarjoui reference. The Jarjoui reference discloses decrypting data using key shares. Furthermore, the Jarjoui reference discloses generating private key using the key shares and using the generated key to sign transaction (see Jarjoui [0098]). The examiner has considered the remarks but does not find them persuasive. The rejection is maintained.
Applicant submits: “Jarjoui further fails to teach or suggest "decrypting the second portion of the private key based on the credentials associated with the application through which the wallet is accessed." The Office Action cites Jarjoui ,m [0065], [0075], and [0092], and Figs. 7, 9, and 11, but those disclosures concern, at most, the device architecture, generation of a wallet private key and public key pair, and recreation of a wallet private key using encrypted key shares after user transaction packets have been confirmed. Jarjoui ,m [0065], [0075], [0092], Figs. 7, 9, 11. They do not disclose application credentials used to decrypt a second portion of the private key. The digital signatures of users in Jarjoui confirm transaction packets, and the device private key decrypts encrypted key shares. Id. ,i [0092]. Neither is a credential associated with an application through which the wallet is accessed, and neither teaches decrypting a second private-key portion based on such application credentials. Fletcher fails to remedy these deficiencies. The Office Action relies on Fletcher for "a salt associated with the user credentials," citing Fletcher,i [0049]. Final Office Action, pp. 16-17. But Fletcher ,i [0049] discusses brain wallets, in which deterministic cryptocurrency addresses may be generated from a password passphrase and "some salt," where the salt is random data used as an additional input to a hashing one-way function. Fletcher ,i [0049]. That disclosure does not teach decrypting a first portion of a private key based on an authorization code associated with the wallet and a salt associated with user credentials, nor does it teach decrypting a second portion of the private key based on credentials associated with an application. More generally, Fletcher is directed to recovery of cryptographic assets when a user loses a private key using a congress and threshold signature scheme. Id. ,i,i [0016], [0060]. Fletcher therefore does not supply the missing claimed architecture of two separately encrypted private-key portions protected by different credential domains and then concatenated for transaction signing.”
Examiner responds: The Applicant argues the combination of Jarjoui in view of Fletcher does not disclose the claim limitations of claims 1, 9, 17. The Examiner respectfully disagree with the Applicant as the combination of Jarjoui in view of Fletcher does disclose the claim limitations of claims 1, 9, 17. As stated in the updated rejection, the Jarjoui reference discloses decrypting using key shares (i.e., sharded keys), and the Jarjoui reference further discloses generating a private key using the key shares (i.e., concatenating keys) and using the generated key to sign transactions (see Jarjoui [0098]). The rejection has been maintained.
Applicant submits: “Accordingly, Jarjoui in view of Fletcher fails to teach or suggest the above-recited limitations of Claim 1 as amended and similar limitations of Claims 9 and 17 as amended. Claims 2-5, 7-8, 10-13, 15-16, 18-21, and 23-24 depend from the independent claims or otherwise include corresponding limitations and are allowable for at least the same reasons. Withdrawal of this rejection is respectfully requested.”
Examiner responds: The Applicant argues the dependent claims 2-5, 7-8, 10-13, 15-16, 18-21, and 23-24 are allowable as they depend on independent claims 1, 9, 17. The Examiner argues the dependent claims 2-5, 7-8, 10-13, 15-16, 18-21, and 23-24 remain by at least virtue of dependency and art rejection. As established in the previous response to remarks above and the updated 35 USC § 103 rejection above, the combination of Jarjoui in view Fletchers discloses the claim limitations of claims 1, 9, and 17. And the same combination of Jarjoui in view of Fletcher discloses the claim limitation of claims 22-5, 7-8, 10-13, 15-16, 18-21, and 23-24. The rejection has been maintained.
Applicant submits: “Claims 6, 14, and 22 depend from Claims 1, 9, and 17, respectively, which Applicant submits are allowable over Jarjoui and Fletcher for at least the reasons set forth above. Accordingly, Applicant submits that Claims 6, 14, and 22 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 does not find Applicant's argument persuasive. Examiner argues that the combination of Jarjoui, in view of Fletcher discloses the claim limitations of claims 1, 9, 17. Thus based on at least virtue of dependency claims 6 and 14, and 22 are also rejected. See updated rejection above. The rejection has been maintained.
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.
US 20240187258 A1 Heilman; Ethan et al. MULTI-PARTY SPLIT-KEY AUTHENTICATION - [0009] In certain embodiments, a memory device may store instructions that, when executed, cause a processor to perform a method comprising receiving, at a key broker, a request for a root certificate, generating, at the key broker, a secret key based on the request, and generating, at the key broker, the root certificate based on the secret key. The method may further comprise splitting the secret key into a plurality of shards via the key broker, providing a first shard of the plurality of shards from the key broker to an agent, and deleting the first shard at the key broker. The method may further comprise receiving, at the key broker, a partially signed message signed with the first shard, generating, at the key broker, a fully signed message based on the partially signed message and a second shard of the plurality of shards, and issuing the fully signed message.
US 20240187218 A1 Fong; Chee Keat et al. GENERATION OF SIGNING KEYS - [0008] FIG. 6 is an example flowchart schematically illustrating provision of partial signing keys of a coding scheme to remotely authorise management commands.
US 20260094155 A1 Tan; Jurvis Si Jun et al. MULTI-PARTY COMPUTATION FOR SECURE DIGITAL ASSET MANAGEMENT - [0070] Pressing the “Yes” button may cause the mobile device 305 to generate and/or retrieve its own partial signature (e.g., partial signature 205B). Pressing the “Yes” button may cause the server 330 to generate, retrieve, and/or provide its own partial signature (e.g., partial signature 205A). Pressing the “Yes” button may cause the hardware wallet 340 to generate, retrieve, and/or provide its own partial signature (e.g., partial signature 205C). Two or more of these partial signatures may be aggregated and combined to form a signature (e.g., signature 210) that is used to sign the transaction (e.g., the transfer of $500 in Bitcoin between user A and user B).
Conclusion
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
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698
Prosecution Insights