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 .
Information Disclosure Statement
The information disclosure statement(s) (IDS) submitted on 5/21/2026 is(are) in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
While 37 CFR 1.97 and 1.98 do not require that the information be material, rather they allow for submission of information regardless of its pertinence to the claimed invention and there is no requirement to explain the materiality of submitted references, the cloaking of a clearly relevant reference by inclusion in a long list of citations may not comply with Applicant's duty of disclosure, see Penn Yan Boats, Inc. V. Sea Lark Boats Inc., 359 F. Supp. 948, aff'd 479 F. 2d. 1338.
Response to Amendment
The amendment filed August 10, 2026 has been entered. Claims 1-20 remain pending in the application. Applicant' s amendments to the Claims have overcome each and every 101 rejections previously set forth in the Non-Final Office Action mailed April 9, 2026.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
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 nonobviousness.
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) 1-2, 4-6, 9-12, 14-16, and 19-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Fuentes (US 20120030047 A1; already of record in IDS) in view of Shankar (US 20200012798 A1).
Regarding Claims 1 and 11, Fuentes teaches A computer-implemented method, comprising (Fuentes: Abstract): A computing apparatus comprising: a processor; and a memory storing instructions that, when executed by the processor, cause the processor to (Fuentes: Abstract; Paragraph(s) 0064):
receiving, by a node in a switchboard system, the switchboard system configured to route data for a plurality of issuer systems, a request to establish a session to perform a tap-to function from a client device, wherein the function is at least partially performed utilizing a contactless card (Fuentes: Abstract; Paragraph(s) 0032, 0017-0018, 0026, 0036, 0015-0016, 0102 teach(es) the client may generate a purchase order message, and provide the generated purchase order message to the merchant server. The merchant server may obtain the purchase order message from the client, and may parse the purchase order message to extract details of the purchase order from the user; the authentication chip may be configured to recognize the user's payment token physical card when the card is in the vicinity of the authentication chip. For example, the authentication chip and the card may communicate signals via Bluetooth™, Wi-Fi™, RFID tags, cellular connectivity (e.g., 3G, 4G), and/or the like; the user input may include, but not be limited to: keyboard entry, card swipe, activating a RFID/NFC enabled hardware device (e.g., electronic card having multiple accounts, smartphone, tablet, etc.), mouse clicks, depressing buttons on a joystick/game console, voice commands, single/multi-touch gestures on a touch-sensitive interface, touching user interface elements on a touch-sensitive display, and/or the like; transform payment token-based purchase orders, via PT components, into multi-issuer purchase payment funds transfers; the PT component takes inputs (e.g., purchase input, token arbitrator address, token creation input, purchase input, token arbitrator address, issuer data response, payment option input, issuer server data, user data, batch data, issuer server data, and/or the like) etc., and transforms the inputs via various components (e.g., TPE, tPTE, and/or the like), into outputs (e.g., tokenization invitation, token data, token authentication confirmation a, issuer data update, “authorization in progress” message, token data, authorization fail message, transaction data, authorization response, authorization success message, batch append data, purchase receipt, transaction data, funds transfer message, and/or the like)); generating, by the node, session information corresponding to the session to perform the function based on the request to establish the session, wherein the session information comprises a … and a … session token for tracking communication associated with the session within the switchboard system that routes data for the plurality of issuer systems (Fuentes: Paragraph(s) 0032, 0034, 0041-0043 teach(es) The merchant server may obtain the purchase order message from the client, and may parse the purchase order message to extract details of the purchase order from the user; If the merchant server determines that the purchase order message is tokenization, the merchant server may invoke a procedure (i.e., session) to process the transaction; The token server may initiate a user verification session; the token server may determine the issuers to contact for payment processing using the pre-defined issuer settings and/or the payment options input provided by the user); sending, by the node, the session information to the client device, wherein the client device sends at least a portion of the session information to the contactless card including the … (Fuentes: Paragraph(s) 0034-0036, 0026 teach(es) the token server may generate a unique and resolvable token identifier irrespective of the token requesting channel (e.g., merchant, issuer, acquirer, payment network, user, etc.); The token server may also provide a token identifier to the client. The client may store the token identifier and/or display the token identifier for the user; the user may provide user input, e.g., purchase input, into the client indicating the user's desire to purchase the product. In various implementations, the user input may include, but not be limited to: keyboard entry, card swipe, activating a RFID/NFC enabled hardware device (e.g., electronic card having multiple accounts, smartphone, tablet, etc.), mouse clicks, depressing buttons on a joystick/game console, voice commands, single/multi-touch gestures on a touch-sensitive interface, touching user interface elements on a touch-sensitive display, and/or the like); receiving, by the node, authenticating information from the contactless card via the client device, the authenticating information including an issuer identifier associated with the issuer of the contactless card and at least a portion of the session information sent to the contactless card (Fuentes: Paragraph(s) 0032, 0043, 0034, 0045, 0026, 0036 teach(es) the client may generate a purchase order message, and provide the generated purchase order message to the merchant server. The merchant server may obtain the purchase order message from the client, and may parse the purchase order message to extract details of the purchase order from the user; the token server may generate a unique and resolvable token identifier irrespective of the token requesting channel (e.g., merchant, issuer, acquirer, payment network, user, etc.); the user's payment token may be linked to one or more issuer financial institutions (“issuers”), such as banking institutions, which issued the account(s) for the user linked to the payment token. For example, such accounts may include, but not be limited to: credit card, debit card, prepaid card, checking, savings, money market, certificates of deposit, stored (cash) value accounts and/or the like; the user may provide user input, e.g., purchase input, into the client indicating the user's desire to purchase the product. In various implementations, the user input may include, but not be limited to: keyboard entry, card swipe, activating a RFID/NFC enabled hardware device (e.g., electronic card having multiple accounts, smartphone, tablet, etc.), mouse clicks, depressing buttons on a joystick/game console, voice commands, single/multi-touch gestures on a touch-sensitive interface, touching user interface elements on a touch-sensitive display, and/or the like); …; extracting, by the node, the issuer identifier from the authenticating information (Fuentes: Paragraph(s) 0034, 0040 teach(es) The token server may obtain the form, and parse the form to extract data fields and values from the form to generate a token data record. For example, the token server may generate a unique and resolvable token identifier irrespective of the token requesting channel (e.g., merchant, issuer, acquirer, payment network, user, etc.); , the token server may parse the token arbitration request message, and extract the payment token from the message); identifying, by the node, a server associated with the issuer identifier; and communicating, by the node, with the server to securely perform the function, … (Fuentes: Abstract; Paragraph(s) 0043, 0045, 0016 teach(es) the token server may determine the issuers to contact for payment processing using the pre-defined issuer settings and/or the payment options input provided by the user).
However, Fuentes does not explicitly teach a nonce unique to the session and a signed session token, determining, by the node, that the authenticating information is associated with the session based on the received nonce, and wherein communicating includes sending the nonce to the server.
Shankar from same or similar field of endeavor teaches wherein the session information comprises a nonce unique to the session and a signed session token (Shankar: Paragraph(s) 0136-0138 teach(es) the verification may be performed by the service provider computer by using a public key associated with the private key that signed the event or device specific data. For example, in some embodiments, the event specific data may be a nonce, and the nonce may be signed by a private key residing in a secure element on the communication device; The application token may have been cryptographically signed by the token service computer which issued the application token), determining, by the node, that the authenticating information is associated with the session based on the received nonce (Shankar: Paragraph(s) 0136, 0141 teach(es) the event specific data may be a nonce, and the nonce may be signed by a private key residing in a secure element on the communication device; the device and/or event specific data may be signed by an encryption key in a secure element in the communication device. The resulting digital signature may be verified by the service provider computer using a corresponding encryption key (e.g., a public key) to ensure that the correct communication device is requesting the redemption of the application token), and wherein communicating includes sending the nonce to the server (Shankar: Paragraph(s) 0136 teach(es) The signed nonce may then be provided to the service provider computer alone or with the nonce).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teachings of Fuentes to incorporate the teachings of Shankar for a nonce unique to the session and a signed session token, determining, by the node, that the authenticating information is associated with the session based on the received nonce, and wherein communicating includes sending the nonce to the server.
There is motivation to combine Shankar into Fuentes because Shankar’s teachings of nonce and signed token would facilitate the security of the system (Shankar: Paragraph(s) 0136-0138).
Regarding Claims 2 and 12, the combination of Fuentes and Shankar teaches all the limitations of claims 1 and 11 above; and Fuentes further teaches comprising verifying the signed session token prior to extracting the issuer identifier from the authenticating information (Fuentes: Paragraph(s) 0056, 0041 teach(es) the token database may provide an issuer data response, including data on issuers to contact for payment. In some implementations, the token server may determine whether the user token is authenticated).
Regarding Claims 4 and 14, the combination of Fuentes and Shankar teaches all the limitations of claims 1 and 11 above; however the combination does not explicitly teach wherein the signed session token comprises the nonce, client session information, and a function request with a private key of the node.
Shankar further teaches wherein the signed session token comprises the nonce, client session information, and a function request with a private key of the node (Shankar: Paragraph(s) 0136-0138 teach(es) the verification may be performed by the service provider computer by using a public key associated with the private key that signed the event or device specific data. For example, in some embodiments, the event specific data may be a nonce, and the nonce may be signed by a private key residing in a secure element on the communication device; The application token may have been cryptographically signed by the token service computer which issued the application token)
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teachings of the combination of Fuentes and Shankar to incorporate the teachings of Shankar for wherein the signed session token comprises the nonce, client session information, and a function request with a private key of the node.
There is motivation to combine Shankar into the combination of Fuentes and Shankar because Shankar’s teachings of nonce and signed token would facilitate the security of the system (Shankar: Paragraph(s) 0136-0138).
Regarding Claims 5 and 15, the combination of Fuentes and Shankar teaches all the limitations of claims 4 and 14 above; and Fuentes further teaches wherein the client session information comprises session identification information to identify the session (Fuentes: Paragraph(s) 0040-0041, as stated above with respect to claims 1 and 11).
Regarding Claims 6 and 16, the combination of Fuentes and Shankar teaches all the limitations of claims 1 and 11 above; and Fuentes further teaches wherein the session information further comprises a function terms of service, and a terms of service version (Fuentes: Paragraph(s) 0017 teach(es) a user may be required to provide a digital certificate to verify the user's identity prior to utilization of a payment token for a purchase transaction).
Regarding Claims 9 and 19, the combination of Fuentes and Shankar teaches all the limitations of claims 1 and 11 above; and Fuentes further teaches wherein the authenticating information comprises an issuer key identifier (pKey ID), a card unique identifier (pUID), and a cryptogram (Fuentes: Paragraph(s) 0040, 0094).
Regarding Claims 10 and 20, the combination of Fuentes and Shankar teaches all the limitations of claims 1 and 11 above; and Fuentes further teaches wherein the issuer identifier is in plaintext and identifies the issuer of the contactless card, the server associated with the issuer of the contactless card, or both (Fuentes: Paragraph(s) 0040, as stated above with respect to claims 1 and 11).
Claim(s) 3, 8, 10, and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Fuentes in view of Shankar, as applied to claims 1 and 8 above, and in further view of Natarajan (WO 2023022719 A1).
Regarding Claims 3 and 13, the combination of Fuentes and Shankar teaches all the limitations of claims 1 and 11 above; however the combination does not explicitly teach wherein the signed session token is a JavaScript Object Notation (JSON) Web Token (JWT).
Natarajan from same or similar field of endeavor teaches wherein the signed session token is a JavaScript Object Notation (JSON) Web Token (JWT) (Natarajan: Paragraph(s) 0081, 0083-0084 teach(es) Token-based authentication often uses the JavaScript Object Notation (JSON) Web Token (JWT) because the JWT is widely used in all industries and is a de-facto standard for authentication. JWT is an open standard that defines a compact, secure, and self-contained mechanism to transmit data between parties in JSON. JWT is a stateless type of authentication, which means that the server does not store any session information in the database of the server, and the server does not need to keep a record of which user has logged in or which token is issued for which user).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teachings of the combination of Fuentes and Shankar to incorporate the teachings of Natarajan for wherein the signed session is a JavaScript Object Notation (JSON) Web Token (JWT).
There is motivation to combine Natarajan into the combination of Fuentes and Shankar because Natarajan’s teachings of JavaScript Object Notation (JSON) Web Token (JWT) would facilitate the security of the system (Natarajan: Paragraph(s) 0081, 0083-0084).
Regarding Claims 8 and 18, the combination of Fuentes and Shankar teaches all the limitations of claims 1 and 11 above; however the combination does not explicitly teach wherein the node is located in a region mapped to a time zone of the client device.
Natarajan further teaches wherein the node is located in a region mapped to a time zone of the client device (Natarajan: Paragraph(s) 0010 teach(es) The Consumer Sentinel Network, maintained by the Federal Trade Commission (FTC), tracks consumer fraud and identity theft complaints that have been filed with federal, state and local law enforcement agencies and private organizations).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teachings of the combination of Fuentes and Shankar to incorporate the teachings of Natarajan for wherein the node is located in a region mapped to a time zone of the client device.
There is motivation to combine Natarajan into the combination of Fuentes and Shankar because Natarajan’s teachings of tracking consumer fraud and identity theft complaints that have been filed with federal, state and local law enforcement agencies and private organizations would facilitate the reduction of identity theft (Natarajan: Paragraph(s) 0010).
Claim(s) 7 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Fuentes in view of Shankar, as applied to claims 1 and 8 above, and in further view of Violleau (WO 2016024876 A1).
Regarding Claims 7 and 17, the combination of Fuentes and Shankar teaches all the limitations of claims 6 and 16 above; however the combination does not explicitly teach comprising receiving a consent date to the function terms of service and the terms of service version from the client device.
Violleau from same or similar field of endeavor teaches comprising receiving a consent date to the function terms of service and the terms of service version from the client device (Violleau: Abstract; Paragraph(s) 0034, 0022 teach(es) pre-approved operations may include, for example, deploying application(s) on the client in the context of a license that has already been approved by the user. More specifically, if a user has already accepted particular terms of agreement or a license agreement previously, this information is stored in the client-application mapping on the server).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teachings of the combination of Fuentes and Shankar to incorporate the teachings of Violleau for comprising receiving a consent date to the function terms of service and the terms of service version from the client device.
There is motivation to combine Violleau into the combination of Fuentes and Shankar because Violleau’s teachings of particular terms of agreement or a license agreement would facilitate processing of pre-approved operations (Violleau: Paragraph(s) 0034).
Response to Arguments
Applicant's arguments filed August 10, 2026 have been fully considered but they are not persuasive.
Regarding applicant’s argument under Claim Rejections - 35 USC § 103 that “the cited references fail to disclose "a node in a switchboard system, the switchboard system configured to route data for a plurality of issuer systems",” examiner respectfully argues that the claim language does not recite anything of definition or technical details of the switchboard system and the node. It is unclear how the situation or technical problem to solve are defined or recited, and how the issuers are switched, in the claims. As stated in the previous action, it is recommended for the applicant to amend the claims further with more technical details and contexts of multi-issuer environment, switchboard system, session, interactions among node, client device, contactless card, issuer systems, and servers for the issuers, as disclosed in the Original Specification (See Paragraph(s) [0028]-[0029]).
Regarding applicant’s argument under Claim Rejections - 35 USC § 103 that “Fuentes's payment token is not comparable to the claimed session information, which includes a session token and a session identifier,” examiner respectfully argues that the claim language does not recite the session token (and the session) with technical details and contexts enough to differentiate the invention from the cited references.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CLAY LEE whose telephone number is (571)272-3309. The examiner can normally be reached Monday-Friday 8-5pm EST.
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, Neha Patel can be reached on (571)270-1492. 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.
/CLAY C LEE/Primary Examiner, Art Unit 3699
