DETAILED ACTION
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 .
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 07/24/2026 has been entered.
Acknowledgements
This Office Action is in response to the RCE filed on 07/24/2026.
Claim 17 was newly introduced.
Claim 1 was amended.
Claims 4 and 13-15 were canceled.
Claim 17 was newly introduced.
Claim Rejections - 35 USC § 101
35 U.S.C. 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.
Claim 17 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
According to MPEP 2106 II, It is essential that the broadest reasonable interpretation (BRI) of the claim be established prior to examining a claim for eligibility. Further, MPEP 2103 I C establishes that the subject matter of a properly construed claim is defined by the terms that limit the scope of the claim when given their broadest reasonable interpretation. It is this subject matter that must be examined. Regarding the independent claims, claim 17 recites “associating,… in a data structure, the unique identifier of the identified first party, an account number for the account of the user, and the second electronic token”, language directed to non-functional descriptive material. See MPEP 2111.05. In addition, claim 17 recites “generating… token to include a cryptographic hash of the unique identifier” , a statement of intended use or field use. See MPEP 2114 II.
With respect to the Eligibility Step 1 of the Alice/Mayo two-part test of the subject matter eligibility analysis (see MPEP 2106), in the instant case, claim 17 are directed to a method. Therefore, these claims fall within the four statutory categories of invention.
Following step 2A, prong one of the analysis, the language of the independent claims reciting an abstract idea are marked in bold below:
receiving, from a first party, a first electronic message requesting to link an account of a user, the first electronic message including a unique identifier of the first party;b. generating, by a computer device, a first electronic token to include a cryptographic hash of the unique identifier, wherein the first token does not include identifying information for the first party;c. receiving, by the computer device, one or more second electronic messages from a second party, the one or more second electronic messages including the first electronic token and information indicative of the account of the user;d. verifying, by the computer device, the first electronic token received from the second party matches the first electronic token generated by the computer device;e. generating, by the computer device, a second electronic token in response to the verification, wherein the second electronic token does not include identifying data for the user or the first party;f. identifying the first party based on the first electric token; andg. associating, by the computer device, in a data structure, the unique identifier of the identified first party, an account number for the account of the user, and the second electronic token.
Therefore, the portions highlighted in bold above recite electronic recordkeeping and credential issuance, which is an abstract idea grouped within the certain methods of organizing human activity grouping of abstract ideas in prong one of step 2A. The claims are grouped within certain methods of organizing human activity because the steps recited describe the commercial or legal interaction of processing information through a clearing-house for managing membership maintenance and transfer. Accordingly, the claims recite an abstract idea.
With respect to step 2A, prong two of the analysis, this judicial exception is not integrated into a practical application. Specifically, with respect to using a computer device to perform the recited steps/functions, this additional element perform the steps or functions such as: “receiving,… message…”, “generating… token…”, “receiving… message…”, “verifying… token…”, “generating… token…”, “identifying… party…”, “associating… [data]…”. This additional element is recited at a high-level of generality such that it represents no more than mere instructions to apply the exception using a generic computer component, which only serves to use a computer as a tool to perform the abstract idea. Therefore, this element does not integrate the abstract idea into a practical application because it requires no more than a computer performing functions that correspond to acts required to carry out the abstract idea. Accordingly, these additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Therefore, following the analysis of step 2A, prong two, the claims are still directed to an abstract idea.
With respect to step 2B of the analysis, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to the integration of the abstract idea into a practical application, the additional computer element, such as a computer device, performs the steps/functions of “receiving,… message…”, “generating… token…”, “receiving… message…”, “verifying… token…”, “generating… token…”, “identifying… party…”, “associating… [data]…”, and amount to no more than mere instructions to apply the exception using generic computer components. Mere instructions to apply an exception using generic computer components cannot provide an inventive concept beyond the abstract idea of electronic recordkeeping and credential issuance. As discussed above, taking the claim elements separately, these additional elements perform the steps or functions that correspond to the actions required to perform the abstract idea. Viewed as a whole, the combination of elements recited in the claims merely recite the concept of electronic recordkeeping and credential issuance. Therefore, independent claim 17 is not eligible.
Claim Rejections - 35 USC § 103
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claim 17 is rejected under AIA 35 U.S.C. 103 as being unpatentable over Redberg et al. (US 2019/0200218 A1), hereinafter Redberg'218, in view of Redberg et al. (US 2014/0281506 A1), hereinafter Redberg'506.
With respect to claim 17, Redberg'218 teaches a method of associating a first party and a second party (Transferring soft tokens from one mobile device to another) comprising:
receiving, from a first party, a first electronic message requesting to link an account of a user, the first electronic message including a unique identifier of the first party; (see token transfer request, device ID/Fingerprint paragraph [0044]: “...when user 102 wants to transfer one or more tokens installed on first device 104 to second device 110, user 102 can start mobile application 106 installed on first device 104, and using mobile application 106, can generate a Token Transfer Request (TTR). System 108 can associate the TTR with data regarding various tokens stored on first device 104, and can enable first device 104 to send the TTR and appropriate token data to system 108 as shown, wherein system 108 can transfer the TTR and the associated token data to TPS 112.”; Examiner notes the "first party" is the first device 104 and the second party is the second device 110 in Fig 2A. Fig. 2A, paragraph [0053]: “Module 202 is configured to receive, from a transferring device (e.g., first device 104), a token transfer request (TTR), requesting the transfer of one or more soft tokens (e.g., those issued by an authentication server associated with mobile app 106 running on first device 104) installed on first device 104. The TTR may also include data associated with the token(s) to be transferred (“token data”), wherein the token data may include any or a combination of an encrypted token seed, a token serial number, a token type, a One-Time Password (OTP) display length, a counter value, a device fingerprint of first device 104, a flag indicative of whether a personal identification number (PIN) is required, a PIN length, one or more PIN policy attributes, counters for HOTP event-based tokens, and an issuer field to identify the issuing party (and therefore the appropriate authentication server). In one embodiment, one or more portions of the token data, e.g., the token serial numbers, the token seeds and the device fingerprint, may be transferred in encrypted format.”; Fig. 2B, paragraph [0063]: “In this manner, token provisioning server 112 can receive, from first device 104, the token transfer request (TTR) as well as token data pertaining to one or more tokens on first device 104.”; Fig. 3, paragraph [0074]: “Upon receipt of such an instruction from user 102, first device 104 can generate a token transfer request (TTR) with token data that can be sent to token provisioning server 112, as illustrated at step 2. The token data can pertain to tokens installed on device 104.”);
generating, by a computer device, a first electronic token to include a cryptographic hash of the unique identifier, wherein the first token does not include identifying information for the first party; (see paragraph [0045]: “Upon receipt of the TTR and associated token data, system 108 can generate/create a transfer activation code (TAC), that is stored by token provisioning server 112 and associated with the token data.”; Fig. 2A, paragraph [0054]: “Module 204 is configured generate or caused to be generated by a token provisioning server, for example, a transfer activation code (TAC) responsive to receipt of the token data from the transferring device (e.g., first device 104). In one embodiment, module 204 receives the token data from module 202 along with the corresponding TTR. Upon receipt of the token data, module 204 stores the token data and generates or causes to be generated the TAC..." Fig. 2B, paragraph [0066]: “In an exemplary embodiment, a unique TAC can be generated by TPS 112 for each token installed on device 104. In another exemplary embodiment, only one unique TAC can be generated for all the tokens installed on device 104. As can be readily understood, in the latter case, user 102 need not provide multiple TACs (one for each token) for transfer of tokens to second device 110.”; Fig. 3, paragraph [0075]: “Upon receipt of the TTR with token data, system 108 can enable storage of the token data at TPS 112, and creation of a transfer activation code (TAC), as shown at step 3. In one embodiment, the TAC can be transferred from TPS 112 to authentication server 114 to allow the TAC to be delivered to user 102 via appropriate means (e.g., SMS, email or a phone call). Further, user 102 can be informed via first device 104 that ‘transfer initialization is complete’ as shown at step 4.”; Examiner notes the language "generating... to include..." is directed to intended use.);
receiving, by the computer device, one or more second electronic messages from a second party, the one or more second electronic messages including the first electronic token and information indicative of the account of the user; (see Fig. 2B, step 3, paragraph [0069]: “In an exemplary embodiment, as illustrated at FIG. 2B, step 3,... Upon receipt of the TAC, using module 256, second device 110 can provide the TAC automatically to TPS 112 and thereafter TPS 112 can automatically provide various token data such as token_1 data as illustrated to second device 110.”; Fig. 3, step 12, paragraph [0079]: “Thereafter, second device 110 can send the TAC to TPS 112, as illustrated at step 12...");
verifying, by the computer device, the first electronic token received from the second party matches the first electronic token generated by the computer device; (see paragraph [0049]: “After the TAC has been input to mobile app 106 running on second device 110, mobile app 106 may deliver the TAC to system 108. Thereafter, system 108 can send the TAC to TPS 112 and when the TAC provided by second device 110 matches the TAC issued to first device 104 TPS 112 can send the token data to second device 110 directly or indirectly via system 108, based on which the token data can be installed on second device 110.”);
generating, by the computer device, a second electronic token in response to the verification, wherein the second electronic token does not include identifying data for the user or the first party; (see Fig. 3, biding token to second device, paragraph [0079]: “Thereafter, second device 110 can send the TAC to TPS 112, as illustrated at step 12. Upon receipt of the TAC, TPS 112 can send the token data to second device 110 as illustrated at step 13 and thereafter second device 110 can install the tokens, as illustrated at step 14. In an embodiment in which the token seeds have been bound to the device on which they were previously installed by encrypting them with a finger print of the device (e.g., a unique device ID) and a hardcoded key provided by a provisioning server (e.g., TPS 112) as described in U.S. Pat. No. 9,143,492 (which has previously been incorporated herein by reference), before transferring the token data to second device 110, TPS 112 unbinds the token seeds from first device 104 by decrypting the token seeds with the fingerprint of first device 104 and the hardcoded pre-shared key (shared by the first device and TPS 112)...");
identifying the first party based on the first electric token; and (see Fig. 3, token decryption using finger print of first device, paragraph [0079]: “Thereafter, second device 110 can send the TAC to TPS 112, as illustrated at step 12. Upon receipt of the TAC, TPS 112 can send the token data to second device 110 as illustrated at step 13 and thereafter second device 110 can install the tokens, as illustrated at step 14. In an embodiment in which the token seeds have been bound to the device on which they were previously installed by encrypting them with a finger print of the device (e.g., a unique device ID) and a hardcoded key provided by a provisioning server (e.g., TPS 112) as described in U.S. Pat. No. 9,143,492 (which has previously been incorporated herein by reference), before transferring the token data to second device 110, TPS 112 unbinds the token seeds from first device 104 by decrypting the token seeds with the fingerprint of first device 104 and the hardcoded pre-shared key (shared by the first device and TPS 112)...").
Redberg'218 does not explicitly disclose a method comprising: associating, by the computer device, in a data structure, the unique identifier of the identified first party, an account number for the account of the user, and the second electronic token.
However, Redberg'506 discloses a method (Soft token system) comprising: associating, by the computer device, in a data structure, the unique identifier of the identified first party, an account number for the account of the user, and the second electronic token (see paragraph [0096]: “In accordance with an embodiment of the present invention, authentication server 208 stores user related information such as user names, corresponding passwords, profile information, preferences, and so forth. In accordance with another embodiment of the present invention, authentication server 208 stores a copy of soft token application 203. In accordance with further embodiments of the present invention, authentication server 208 stores token serial numbers, secret keys, Personal Identification Numbers (PINs), unique device IDs, OTP values, seeds and activation codes.”).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate the database maintenance as disclosed by Redberg'506 in the method of Redberg'218, the motivation being to perform authentication checks to ascertain whether the details input by the user are correct (see Redberg'506, paragraph [0094]).
With respect to the BRI of the claim, Examiner notes that claim 17 recites “associating,… in a data structure, the unique identifier of the identified first party, an account number for the account of the user, and the second electronic token”, language directed to non-functional descriptive material. See MPEP 2111.05. In addition, claim 17 recites “generating… token to include a cryptographic hash of the unique identifier” , a statement of intended use or field use. See MPEP 2114 II.
Prior Art Analysis
Claims 1-3, 5-12 and 16 are allowed, as indicated in the Notice of Allowance dated 04/28/2026, since the amendment of claim 1 does not significantly alter the scope of the previously examined claims.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to EDUARDO D CASTILHO whose telephone number is (571)270-1592. The examiner can normally be reached Mon-Fri 8-5.
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.
/EDUARDO CASTILHO/Primary Examiner, Art Unit 3698
