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 January 22, 2026 has been entered.
Response to Amendment
The amendment filed January 22, 2026 has been entered. Claims 1-20 remain pending in the application.
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.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Under the Step 1 of the Section 101 analysis, Claims 1-10 are drawn to a method which is within the four statutory categories (i.e., a process), and Claims 11-20 are drawn to a system which is within the four statutory categories (i.e. a machine.
Since the claims are directed toward statutory categories, it must be determined if the claims are directed towards a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea). Based on consideration of all of the relevant factors with respect to the claim as a whole, claims 1-20 are determined to be directed to an abstract idea. The rationale for this determination is explained below:
Regarding Claims 1 and 11:
Claims 1 and 11 are drawn to an abstract idea without significantly more. The claims recite “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; 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 nonce and a signed session token; 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; receiving, by the node, a message from the contactless card via the client device, the message 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; extracting, by the node, the issuer identifier 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.”
Under the Step 2A Prong One, the limitations, as underlined above, are processes that, under its broadest reasonable interpretation, cover Certain Methods Of Organizing Human Activity such as commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations). For example, but for the “node”, “switchboard system”, “tap-to function”, “client device”, “contactless card”, and “server” language, the underlined limitations in the context of this claim encompass the human activity. The series of steps belong to a typical sales activities or behaviors, because entities such as node, client, and issuer interact with one another and process data and information including request, message, identifiers, etc. for performing sessions.
Under the Step 2A Prong Two, this judicial exception is not integrated into a practical application. In particular, the claim only recites additional elements – “A computer-implemented method, comprising:”, “A computing apparatus comprising: a processor; and a memory storing instructions that, when executed by the processor, cause the processor to:”, and “node”, “switchboard system”, “tap-to function”, “client device”, “contactless card”, and “server”. The additional elements are recited at a high-level of generality (i.e., performing generic functions of an interaction) such that it amounts no more than mere instructions to apply the exception using a generic computer component, merely implementing an abstract idea on a computer, or merely using a computer as a tool to perform an abstract idea. Additionally, regarding the specification and claims, there is no improvement in the functioning of a computer or an improvement to other technology or technical field present, there is no applying or using the judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition present, there is no implementing the judicial exception with or using the judicial exception in conjunction with a particular machine or manufacture that is integral to the claim present, there is no effecting a transformation or reduction of a particular article to a different state or thing present, and there is no applying or using the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment present such that the claim as a whole is more than a drafting effort designed to monopolize the exception. Accordingly, these additional elements, individually or in combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claims are directed to an abstract idea.
Under the Step 2B, 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 integration of the abstract idea into a practical application, the additional elements in the process amounts to no more than mere instructions to apply the exception using generic computer components. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. The claims are not patent eligible.
Regarding Claims 2-10 and 12-20:
Dependent claims 2, 5-6, 12, and 15-16 only further elaborate the abstract idea and do not recite additional elements.
Dependent claims 3-4, 7-10, 13-14, and 17-20 include additional limitations, for example, “JavaScript Object Notation (JSON) Web Token (JWT)” (Claims 3 and 13); “private key” and “node” (Claims 4 and 14); “client device” (Claims 7 and 17); “node” and “client device” (Claims 8 and 18); “key” and “cryptogram” (Claims 9 and 19); and “contactless card” and “server” (Claims 10 and 20), but none of these limitations are deemed significantly more than the abstract idea because, as stated above, they require no more than generic computer structures or signals to be executed, and do not recite any Improvements to the functioning of a computer, or Improvements to any other technology or technical field.
Thus, taken alone, the additional elements do not amount to significantly more than the above-identified judicial exception (the abstract idea). Furthermore, looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology, and their collective functions merely provide conventional computer implementation or implementing the judicial exception on a generic computer.
Therefore, whether taken individually or as an ordered combination, claims 2-10 and 12-20 are nonetheless rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
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 (Fuentes: Paragraph(s) 0032, 0034, 0041 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); 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 (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, a message from the contactless card via the client device, the message 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 message (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 and a signed session token.
Shankar from same or similar field of endeavor teaches wherein the session information comprises a nonce 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)
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 and a signed session token.
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 message (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 message comprises the issuer identifier, an issuer key identifier (pKey ID), a card unique identifier (pUID), …, and a cryptogram (Fuentes: Paragraph(s) 0040, 0094).
However, the combination of Fuentes and Shankar does not explicitly teach the nonce.
Shankar further teaches the nonce (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)
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 a nonce.
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 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 January 22, 2026 have been fully considered but they are not persuasive.
Regarding applicant’s argument under Claim Rejections - 35 USC § 101 that “The claims are directed to a node in a switchboard system establishing a session with a client device and a server associated with an issuer identifier for performing a function for the client device. This is not a method of organizing human activity per the definitions,” examiner respectfully argues that the claims recite processing of a single session, thus not providing any technical details and contexts of handing a plurality of sessions for switching them or any improvements related to such switching among different sessions. It is recommended for the applicant to amend the claims further with more technical details and contexts of multi-issuer environment, switchboard system, sessions, interactions among nodes, client device, contactless card, and servers for the issuers, as disclosed in the Original Specification (See Paragraph(s) [0028]-[0029]). The technical features (details and contexts) in those paragraphs are not recited in the claims. It is also noted that the nonce and the signed session token have never been used.
Regarding applicant’s argument under Claim Rejections - 35 USC § 103 that “Fuentes does not disclose "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" and "receiving, by the node, a message from the contactless card via the client device, the message including an issuer identifier associated with the issuer of the contactless card and the at least a portion of the session information sent to the contactless card",” examiner respectfully argues that Fuentes teaches that the user’s client device interacting with a RFID/NFC enabled hardware device such electronic card (Fuentes: Paragraph(s) 0034-0036, 0026, 0032, 0043, 0034, 0045). In addition, the claims do not explicitly recite relationship among the devices such as node, client device, servers, issuer systems, and how a session is defined technically in any technical context, for example. As stated above, 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]).
Conclusion
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