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 3/2/2026 has been entered.
Response to Amendment / Arguments
Regarding claims rejected under 35 USC 103:
Applicant’s arguments, in view of the amended claim language, have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Wang (WO 2019/147251 A1).
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 21, 26-28, 33-35, and 39-40 are rejected on the ground of nonstatutory double patenting as being unpatentable over at least claims 1-2 and 5-6 of U.S. Patent No. 11,652,813 B2. Although the claims at issue are not identical, they are not patentably distinct from each other because the patent claims are considered to anticipate the instant claims as per the table below. Instant claims 28, 33-35, and 39-40 are substantially similar to claims 21 and 26-27, and are therefore likewise rejected in view of respective patent claims.
Instant Application
US 11,652,813 B2
21. An identity authority computing device comprising a processor configured to:
communicate with a public network and a secure data processing domain, and prevent access from the public network to confidential user data stored in the secure data processing domain;
activate a token on a registered user computing device associated with a user, the activated token assigned to the user and causing the registered user computing device to generate one or more token values;
transmit, through the secure data processing domain, an encrypted service request to a service provider computing device, the encrypted service request including at least one persistent user identifier, the encrypted service request transmitted in response to a service request (i) including a token value of the one or more token values and (ii) received over the public network from an interface domain associated with an interface computing device different from the service provider computing device, wherein the interface computing device generates one or more application views enabling retrieval of the token value from the registered user computing device;
receive a service response from the service provider computing device, the service response including response data and the at least one persistent user identifier;
filter the service response by removing the at least one persistent user identifier from the service response; and
transmit the filtered service response and the token value to the interface computing device without providing access to the confidential user data associated with the user and stored in the secure data processing domain including the at least one persistent user identifier.
1. An identity authority computing device comprising a processor programmed to:
communicate with a public network and with a secure data processing domain, and prevent access from the public network to confidential user data stored in the secure data processing domain;
6. The identity authority computing device of claim 1, wherein the token value is a one-time password generated by a user computing device based on a token secret generated by the identity authority computing device.
receive a service request over the public network from an interface domain that includes an interface computing device in communication with a user computing device … generate an updated service request including the at least one persistent user identifier;generate an encrypted service request by using a public encryption key associated with the service provider identifier to encrypt the updated service request; and
transmit, within the secure data processing domain, the encrypted service request to a service provider computing device associated with the service provider identifier… receive a service request over the public network from an interface domain that includes an interface computing device in communication with a user computing device, the service request including a service provider identifier and a single-use token value associated with a user…
…wherein the interface domain is prevented from accessing confidential user data associated with the user including the persistent user identifier of the user…
2. The identity authority computing device of claim 1, wherein the processor is further programmed to:
receive a service response from the service provider computing device, the service response including response data and the at least one persistent user identifier;
filter the at least one persistent user identifier from the service response; and
transmit the filtered service response and the token value to the interface computing device.
5. The identity authority computing device of claim 1, wherein the service request is received from the interface computing device in response to receipt by the interface computing device of the token value from a user computing device
26. The identity authority computing device of claim 21, wherein the interface computing device is in communication with a plurality of user computing devices, and wherein the service request further includes a service provider identifier associated with the service provider computing device.
1. …receive a service request over the public network from an interface domain that includes an interface computing device in communication with a user computing device, the service request including a service provider identifier and a single-use token value associated with a user…
27. The identity authority computing device of claim 21, wherein the processor is further configured to, in response to the service request, access an identity database within the secure data processing domain, and wherein the identity database stores and indexes confidential information for a plurality users including a plurality of persistent user identifiers.
1. … in response to the service request, access an identity database within the secure data processing domain, wherein the identity database stores and indexes confidential information for a plurality of users including a plurality of persistent user identifiers…
Claims 22-25, 29-32, and 36-38 are rejected on the ground of nonstatutory double patenting as being unpatentable over U.S. Patent No. 11,652,813 B2 as applied to claims 21, 26-28, 33-35, and 39-40 above, and further in view of Keresman (US 2019/0172061 A1).
Regarding claim 22, the patent claims do not specify: wherein the processor is further configured to filter the at least one persistent user identifier from the service response by replacing the at least one persistent user identifier with the token value. However, the patent claims in view of at least [0050] of Keresman concerning replacing a user credential with a tokenized version are considered to disclose this limitation. Therefore it would have been obvious to one of ordinary skill in the art to modify the patent claims to include replacement with a tokenized value for at least the reasons specified in [0003] of Keresman concerning the advantages of tokenization (i.e., preventing entities from understanding private user data).
Regarding claim 23, it is rejected for substantially the same reasons as claim 22 above (e.g., the citations and obviousness rationale; also see [0032] of Keresman)
Regarding claim 24, the patent claims do not specify: wherein transmitting the filtered service response to the interface computing device causes the interface computing device to generate an application view based on the service response, and transmit the application view to the registered user computing device. However, the patent claims in view of at least [0052] and [0034] of Keresman concerning a merchant website, interactions with a checkout page, and subsequent response messages are considered to disclose this limitation. Therefore it would have been obvious to one of ordinary skill in the art to modify the patent claims to include support for a checkout page and subsequent response because the particular known technique was recognized as part of the ordinary capabilities of one skilled in the art.
Regarding claim 25, the patent claims in view of Keresman disclose: wherein the application view includes at least one of credit history data, personal background data, and vehicle insurance data (refer to at least patent claim 3 reciting “wherein the service response includes at least one of credit history data, personal background data, and vehicle insurance data”). Therefore it would have been obvious to one of ordinary skill in the art to modify the patent claims to implement the checkout page and response of Keresman as part of the service response for substantially the same reasons as claim 24 above.
Regarding claims 29-32 and 36-38, they are substantially similar to claims 22-25 above, and are therefore likewise rejected.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 21-40 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Independent claim 21 is drawn to the apparatus of “an identity authority computing device.” Independent claim 21 further recites “causing the registered user computing device to generate one or more token values” and “wherein the interface computing device generates one or more application views enabling retrieval of the token value from the registered user computing device,” which render it indefinite because the registered user computing device and the interface computing device are outside of the scope of the “identity authority computing device” to which the claim is drawn. The limitations drawn to the registered user computing device and the interface computing device do not modify the structure of the identity authority computing device, and it is not clear how one of ordinary skill in the art should interpret the metes and bounds of the claims so as to understand how to avoid infringement concerning these limitations beyond the scope of the identity authority computing device.
Independent claim 35 is substantially similar in its language, but drawn to a computer readable medium rather than the identity authority computing device. As such, it is rejected under the same analysis (the limitations to the registered computing device and the interface computing device being outside of the scope of the CRM).
Independent claim 28 is a method claim, but it is drawn to “the method implemented using an identity authority computing device.” As such, it is likewise rejected under the same analysis as claims 21 and 35 above where it recites “causing the registered user computing device to generate one or more token values” and “wherein the interface computing device generates one or more application views enabling retrieval of the token value from the registered user computing device.” These limitations concern steps taken by devices other than the identity authority computing device using which the method is implemented.
With specific regard to the “activating a token” step that includes the embedded “causing…” limitation, it is noted that this is non-technical jargon and that applicant has sufficient technical disclosure in their specification to recite in its stead. Specifically, par 0075 states “Identity authority computing device 140 generates a token secret or one or more token values 206, associates the token secret or the one or more token values 206 with the user profile 604 (e.g., with any number of persistent user identifiers), and transmits the token secret or the one or more token values 206 to user computing device 114 as token activation 606.”. Assuming applicant’s amendment is an intent to remove the option of the Identity Authority Computing Device generating the token values itself (by reciting “causing the registered user computing device to generate one or more token values”), then it’s unclear why applicant does not claim the definite and technically complete concept of the Identity Authority Computing Device generating a token secret, associating the generated token secret with a user profile, and transmitting the token secret to the user computing device. This would overcome all 112 issues related to the “causing…” limitation.
The dependent claims do not rectify this issue and are therefore likewise rejected.
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.
Claim(s) 21-24, 26-31, and 33-40 is/are rejected under 35 U.S.C. 103 as being unpatentable over Keresman (US 2019/0172061 A1) in view of Wang (WO 2019/147251 A1).
Regarding claim 21, Keresman discloses: An identity authority computing device (Trusted Token Service Provider TTSP 140 in FIG. 9 of Keresman) comprising a processor configured to:
communicate with a public network (internet 110 in FIG. 9 of Keresman) and a secure data processing domain (payment network 160 in FIG. 9 of Keresman), and prevent access from the public network to confidential user data (e.g., [0031] of Keresman concerning sensitive user data, including a credential such as a PAN) stored in the secure data processing domain (e.g., [0037] of Keresman concerning a token vault; the payment network likewise needs to know user identifying credentials such as a PAN to actually proceed with payment);
Refer to at least [0032] of Kerseman with respect to, e.g., a merchant server being unable to access the user data.
generate one or more token values;
Refer to at least [0037] of Keresman with respect to token generation.
transmit, through the secure data processing domain, an service request to a service provider computing device, the service request including at least one persistent user identifier,
Refer to at least [0048] of Keresman with respect to the TTSP sending a message with a corresponding PAN to the payment network.
the service request transmitted in response to a service request (i) including a token value of the one or more token values and (ii) received over the public network from an interface domain associated with an interface computing device different from the service provider computing device, wherein the interface computing device generates one or more application views (e.g., 130 and 132 in FIG. 9, as well as [0033]-[0035] of Keresman concerning a merchant its merchant website; the merchant is different from the payment network 160 as per FIG. 9; “application views” interpreted as web pages in view of [0043] of the instant specification);
Refer to at least [0041]-[0046] of Keresman with respect to the TTSP being sent a payment request message from the merchant, where the payment request message contains a tokenized version of a user’s PAN.
receive a service response from the service provider computing device, the service response including response data and the at least one persistent user identifier;
Refer to at least [0049] of Keresman with respect to the payment network sending a response with an included PAN.
filter the service response by removing the at least one persistent user identifier from the service response; and
Refer to at least [0050] of Keresman with respect to the TTSP replacing the PAN with the tokenized version of the PAN.
transmit the filtered service response and the token value to the interface computing device.
Refer to at least [0051]-[0052] of Keresman with respect to the TTSP forwarding the replaced-PAN message to the merchant.
without providing access to the confidential user data associated with the user and stored in the secure data processing domain including the at least one persistent user identifier.
Refer to at least [0032], [0035], and [0051] of Keresman with respect to the merchant having no access to the PAN as known to the payment network.
Keresman does not specify: activate a token on a registered user computing device associated with a user, the activated token assigned to the user and causing the registered user computing device to generate the one or more token values; the service request to the service provider computer further comprising an encrypted service request; the generated interface views enabling retrieval of the token value from the registered user computing device. However, Keresman in view of Wang discloses: activate a token on a registered user computing device associated with a user, the activated token assigned (e.g., [0016] of Wang) to the user and causing the registered user computing device to generate the one or more token values;
Refer to at least the abstract, FIG. 1, [0067], and [0102] of Wang with respect to a first user device accessing an access device and being provided with an access token generated at a second user device.
the service request to the service provider computer further comprising an encrypted service request;
Refer to at least [0042]-[0043] of Wang with respect to a form of the claimed service request. Further refer to at least [0064] of Wang with respect to securing messages between entities using secure communications protocols (e.g., SSL, HTTPS).
the generated interface views enabling retrieval of the token value from the registered user computing device.
Refer to at least [0014] and [0131]-[0136] of Wang with respect to the first user device and its respective interface and applications for interacting with the access device (e.g., for a purchase transaction) and obtaining the access token from the second user device.
The teachings of Keresman and Wang both concern generating tokens to secure privacy for sensitive credential information (e.g., [0002] and [0042]-[0043] of Wang), and are considered to be within the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Keresman to further implement a second user device for token generation for at least the reasons discussed in [0007]-[0009] and [0013]-[0016] of Wang (i.e., improved interoperability, offline token generation functionality, reduced storage requirements at the remote server). It further would have been obvious to implement secure communications protocols for at least the purpose of improving security (e.g., preventing eavesdropping of sensitive plaintext data).
Regarding claim 22, it is rejected for substantially the same reasons as claim 21 above (i.e., the citations concerning replacing the PAN with the tokenized PAN).
Regarding claim 23, it is rejected for substantially the same reasons as claim 21 above (i.e., the citations concerning obfuscating the PAN from the merchant while still allowing the transaction).
Regarding claim 24, Keresman-Wang discloses: The identity authority computing device of claim 21, wherein transmitting the filtered service response to the interface computing device causes the interface computing device to generate an application view based on the service response, and transmit the application view to the registered user computing device.
Refer to at least [0052] and [0034] of Keresman with respect to the transaction taking place on a merchant website accessed by a user and respective user device. Once the transaction is complete, the merchant may send an appropriate message indicating success or failure.
Regarding claim 26, Keresman-Wang discloses: The identity authority computing device of claim 21, wherein the interface computing device is in communication with a plurality of registered user computing devices, and wherein the service request further includes a service provider identifier associated with the service provider computing device.
Refer to at least [0034]-[0035] of Keresman with respect to a user and respective user device used to proceed with checkout at the merchant’s website. The check out procedure includes entering payment data such as a PAN and/or other information identifying the payment processor associated with the user’s payment option. A PAN includes an issuer identification number as part of the standard.
Refer to at least FIG. 1 of Wang with respect to second and third user devices in communication with the first user device.
This claim would have been obvious for substantially the same reasons as claim 21 above.
Regarding claim 27, Keresman-Wang discloses: The identity authority computing device of claim 21, wherein the processor is further configured to, in response to the service request, access an identity database within the secure data processing domain, and wherein the identity database stores and indexes confidential information for a plurality users including a plurality of persistent user identifiers.
Refer to at least FIG. 9 and [0037] of Keresman with respect to a token vault storing token-to-credential information.
Regarding independent claim 28, it is substantially similar to independent claim 21 above, and is therefore likewise rejection (i.e., the citations and obviousness rationale).
Regarding claims 29-31 and 33-34, they are substantially similar to claims 22-24 and 26-27 above, and are therefore likewise rejected.
Regarding independent claim 35, it is substantially similar to independent claim 21 above, and is therefore likewise rejection (i.e., the citations and obviousness rationale).
Regarding claims 36-40, they are substantially similar to claims 22-24 and 26-27 above, and are therefore likewise rejected.
Claim(s) 25 and 32 is/are rejected under 35 U.S.C. 103 as being unpatentable over Keresman-Wang as applied to claims 21-24, 26-31, and 33-40 above, and further in view of Official Notice.
Regarding claim 25, Keresman-Wang does not specify: wherein the application view includes at least one of credit history data, personal background data, and vehicle insurance data. However, the examiner hereby takes official notice that that it was well known in the art before the filing date of Applicant’s invention for merchant websites to provide credit history data, personal background data, and/or vehicle insurance data responsive to a purchase. For example, purchasing vehicle insurance from an insurance website would take a user to a coverage page. Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Keresman-Wang to include support for wherein the application view includes at least one of credit history data, personal background data, and vehicle insurance data because design incentives or market forces provided a reason to make an adaptation (i.e., selling credit history, personal background data, and/or vehicle insurance on a website), and the invention resulted from application of the prior knowledge in a predictable manner (the tokenization and substitution in Keresman-Wang is generic to any kind of purchase and merchant website).
Claim 32 is substantially similar to claim 25 above, and is therefore likewise rejected.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VADIM SAVENKOV whose telephone number is (571)270-5751. The examiner can normally be reached 12PM-8PM.
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, Jeffrey L Nickerson can be reached at (469) 295-9235. 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.
/Jeffrey Nickerson/Supervisory Patent Examiner, Art Unit 2432
/V.S/Examiner, Art Unit 2432
Prosecution Insights