DETAILED ACTION
Status of the Claims
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . The following is in response to an office action dated March 30, 2026. Claims 1-20 are pending. All pending claims are examined.
Response to Arguments
Art Rejection Analysis
Art Rejection
In light of Applicant’s arguments, the art rejection is withdrawn.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Glynn, USP Pub. No. 20250141687
As to claim 1, Glynn discloses A method comprising:
receiving, at a server, a first request to perform a function, the first request being associated with a user account associated with a contactless card (Glynn, para. 0003 – “…The validity token may be generated upon validating the contactless card using the contactless card identifier, and transmitted to a first computing device communicatively coupled with at least one processor. The method may also include identifying a second computing device in a plurality of second computing devices based on an information request received from the first computing device. The information request may include a first public key associated with the first computing device and the validity token, and may be associated with the contactless card. The method may include sending an encrypted response to the information request and a second public key associated with the identified second computing device to the first computing device.”; see also paras. 0069-0072);
transmitting, by the server to a switchboard node, a validation session request to initiate a validation session for the contactless card (Glynn, paras. 0037-0040. 0042-0043; Figs. 1-2, 5, see also para. 0047- “Validation may include a comparison of information identifying the second computing device stored in one or more fields of the validity token and the second public key. The issuer's second computing device may be validated upon the information identifying the second computing device stored in the field(s) of the validity token matching the second public key. Once confirmation of validity of the issuer's public key is received, the first computing device may be configured to validate the issuer's information (e.g., identifier, name, etc. of the issuer and/or the second computing device). After completing the validations, the first computing device may be configured to generate a shared key using issuer's public key”.);
receiving, at the server, a response, including a nonce, from the switchboard node (Glynn, para. 0011 – “…The operations may include receiving a validity token generated using a contactless card identifier associated with a contactless card, transmitting the validity token to a first computing device, identifying a second computing device in a plurality of second computing devices based on an information request received from the first computing device, the information request including a first public key associated with the first computing device and the validity token, and being associated with the contactless card, the identified second computing device generating an encrypted response to the information request, and causing the first computing device to decrypt the encrypted response to the information request upon generation of a shared key using a second public key associated with the identified second computing device)”;
transmitting, by the server to a user device associated with the user account, the nonce, wherein the user device is to send the nonce to the contactless card during a near field near- field communication (NFC) exchange with the contactless card (Glynn paras. 0013-0016; Fig. 5);
receiving, at the server from the contactless card, via the user device, encrypted data, the encrypted data including the nonce card (Glynn, paras. 0003-0006);
transmitting, by the server to the switchboard node, the encrypted data, including the nonce, wherein the switchboard node is configured to forward the encrypted data to a validation server to validate the encrypted data card (Glynn, paras. 0006-0011; Fig. 5);
receiving, by the server from the validation server, a notification that the encrypted data is validated card (Glynn, paras. 0004-0006; see also paras. 0012-0016); and
performing, by the server, the function as defined in the first request card (Glynn para. 0006 - “…Generation of the encrypted response may include a comparison of information identifying the first computing device stored in at least another field of the validity token and the first public key. The first computing device may be validated upon the information identifying the first computing device stored in at least another field of the validity token matching the first public key. Generation of the encrypted response may also include validation of the first public key associated with the first computing device”.; see also paras. 0037-0040).
As to claim 2, Glynn discloses the method of claim 1, wherein:
the nonce is an identifier that is unique to the validation session and
the nonce differentiates the validation session from other validation sessions granted by the switchboard node (Glynn, paras. 0006-0007).
As to claim 3, Glynn discloses the method of claim 1, wherein the switchboard node is a server operating within a switching network configured to receive at least validation session requests and encrypted data, respond to the validation session requests, and forward the encrypted data to an appropriate validation server configured to validate the encrypted data (Glynn, para. 0071 - Using the routing instructions, the validation engine 102 may forward the information request 122, which may be the same as information request 120 and/or generated based on the information request 120, to the computing device 114. As stated above, in the transaction execution example, the computing device 114 may be server and/or a network of servers that may be associated with the issuer of the contactless card 104. The validation engine 102 may determine the address of one or more of such computing devices 114 and forward the information request 122 to the computing device 114 using the determined address.).
As to claim 4, Glynn discloses the method of claim 1, further comprising:
receiving, at the server from the switchboard node, a request to negotiate with the issuer server to generate a temporary key (Glynn, para. 0079 To transmit the retrieved data to the computing device 112 (either directly or via the validation engine 102), the computing device 114 may be configured to generate a shared key or a shared secret (hereinafter, “shared key”) using a public key associated with the computing device 112 (i.e., the merchant's public key). The shared key may be generated using any known algorithm, such as, for example, an elliptic-curve Diffie-Hellman (ECDH) key agreement protocol. ECDH allows two parties to establish a shared secret over an insecure channel, where each party has an elliptic-curve public-private key pair. The shared secret may be used as a key directly.).
As to claim 5, Glynn discloses the method of claim 4, wherein the confirmation received from the issuer server is encrypted using the ECDH public key by the issuer server (Glynn, para. 0074; see also paras. 0071-0072), and the method further comprises:
decrypting, by the server, the encrypted confirmation using the private key (Glynn, paras. 0074-0078).
As to claim 6, Glynn discloses the method of claim 1, wherein the response from the switchboard node includes terms of service for the function and a terms of service version identifier (Glynn, paras. 0074; see also paras. 0064-0070); and wherein the method further comprises:
sending, by the server, the terms of service to the user device; and receiving, by the server from the user device, a message indicating that the terms of service have been accepted (Glynn, para. 0065 - Receipt of the contactless card identifier from the validation engine 102 may trigger the validity token engine 108 to generate a validity token 118. As can be understood, any way of generating the validity token are possible. The validity token 118 may include a plurality of fields that may be used for storing of information. For example, the validity token engine 108 may package the validity token 118 with the contactless card identifier, the issuer information (e.g., name, identifiers, etc.) determined by the validation engine 102, merchant information, and/or any other information that may be used by various components of the system 100 for identification, verification, authentication, and/or any other functions that may be performed in connection with execution of the transaction. The validity token 118 may, for example, be a JSON web token (JWT) that also be signed and validated using one or more cryptographic signatures.).
As to claim 7, Glynn discloses the method of claim 1, wherein the first request to perform the function includes at least one selected from the group of:
a request to perform an autofill function; a request to execute a transaction;
a request to login in to an account; a request to actuate a controller; and
a request to establish a virtual private network (VPN) (Glynn, paras. 0071-0074; see also para. 0065).
As to claims 8-14 and 15-20 contain limitations similar to claims 1-7 and are rejected in like manner.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHIKA OJIAKU whose telephone number is (571)270-3608. The examiner can normally be reached Monday - Friday: 8.30 AM -5:00 PM 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, Matthew Gart can be reached at 571 272-3955. 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.
/CHIKAODINAKA OJIAKU/
Primary Examiner, Art Unit 3696
Prosecution Insights