DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application is being examined under the pre-AIA first to invent provisions.
Response to Amendment
Applicant’s “Appeal Brief” filed on 05/26/2026 has been considered.
The office action filed on 10/23/2025 is withdrawn.
Claims 1-13 and 21-33 remain pending in this application and an action on the merits follow.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 04/13/2026 and 04/20/2026 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
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 pre-AIA 35 U.S.C. 103(a) which forms the basis for all obviousness rejections set forth in this Office action:
(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 102, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-13 and 21-33 rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over U.S. Patent Application Publication No. 2003/0145205 to Sarcanin, in view of International Patent Application Publication No. 2006/0110947 to Barsukov.
With regard to claims 1, 12, and 21, Sarcanin discloses a system comprising:
one or more servers configured to: perform an automated handshake for an authorization to perform one or more secure electronic mobile commerce transactions, the at least one server designated to perform the one or more secure electronic mobile commerce transactions after the authorization (paragraphs 426-440 and 462-463, SSL Certificate Handshake Attempted. The first authentication takes place as soon as the user has been accepted as a Registered User Site by use of the Secure Sockets Layer (SSL). Is the user an existing VirtualSAFE client or is this the first time they are trying to sign-up and process a payment? YES. Step 6--Active X/Java Applet/Application sends dedicated public WEB server key to client);
exchanging security keys to provide additional security for a first electronic mobile commerce transaction of the one or more secure electronic mobile commerce transactions via the secure connection with the wireless mobile-end user device (paragraph 119, the CEV 109 stores secret keys and encryption algorithms, performs cryptographic functions on secret data and generates digital signatures.);
transmit, via the secure connection with the wireless mobile end-user device, a purchase confirmation request for a first electronic mobile commerce transaction of the one or more electronic mobile commerce transactions with the at least one server confirmed to have the compatible and approved server status (paragraphs 21 and 103-104, the client terminal communicates with the payment server by first forwarding the draw request to the payment server. The payment server verifies the transaction to determine if it is a valid transaction from a known merchant. ), wherein the purchase confirmation request provides information relating to the first electronic mobile commerce transaction, the information including an amount of the first electronic mobile commerce transaction (paragraphs 369-370, The draw request message may include a variety of data including a draw request token, state information, the merchant identifier, the transaction identifier, security information, a wallet provider identifier, and an intersector electronic wallet ("IE-W") identifier. Also the message may include an algorithm used by the card, an expiry date, the balance of the card, a currency code, a currency exponent, the authentication mode of the IE-W, the transaction number of the IE-W, a key version, and the purchase amount. In one embodiment, the draw request message is built by packaging the virtual card's response to the "Reset" and "Initiate IE-W for Purchase" commands, any public key certificates, the total cost, and the currency of the transaction received from the HTML page.), and wherein the purchase confirmation request triggers a request for an approval by a device user of the first electronic mobile commerce transaction to be conducted through a central billing process, wherein the approval requires a biometric authentication of the device user locally on the wireless mobile end-user device (paragraphs 22 and 94, receiving a user identifier and a PIN from the user at the client terminal for authorizing the transaction. The smart card may include an encryption module in order to provide a variety of security features. For example, security features may include simple PIN numbers, biometrics, simple algorithms, or sophisticated algorithms such as the Data Encryption Standard (DES) or Rivest Shamir Adelman (RSA) encryption. A smart card may include any number of keys which are known to the card issuer and that are used during the course of a payment or load transaction to generate digital signatures for validation of the stored-value card, security card or module, or the system itself.); and
receive, by the at least one server in response to the purchase confirmation request, a purchase confirmation for the first electronic mobile commerce transaction (paragraph 40, sending a purchase receipt message from the merchant server to the client terminal, the purchase receipt message indicating that the product has been released to the user, thereby completing the secure electronic commerce transaction.).
However, Sarcanin does not disclose wherein the automated handshake includes: transmitting, via a secure connection with a wireless mobile end-user device, a first signed message to the wireless mobile-end user device to confirm a compatible and approved server status of at least one server of the one or more servers, receiving, via the secure connection with the wireless mobile end-user device, a second signed message from the wireless mobile-end user device to confirm a compatible and approved device status of the wireless mobile end-user device desiring to perform the one or more secure electronic mobile commerce transactions, after the authorization, with the at least one server confirmed to have the compatible and approved server.
However, Barsukov teaches the automated handshake includes: transmitting, via a secure connection with a wireless mobile end-user device, a first signed message to the wireless mobile-end user device to confirm a compatible and approved server status of at least one server of the one or more servers (The terminal 10 then opens an SSL session with the target gateway host 19 specified in the terminal configuration and sends the ITID. During the SSL handshake, the terminal 10 does not validate the gateway host's 19 certificate. The gateway host 19 receives the data, extracts the ITID and then searches the terminal information database (particularly in the uninitialised terminals table) for the copy of the terminal initialisation key. The ITID is used to perform the search. If no matching terminal record is found, the gateway host 19 closes the connection. Otherwise, the gateway host issues a random unique password for the requesting terminal. Examiner notes that the gateway host issues a random unique password to the terminal to confirm the terminal is in a compatible/approved (i.e., the ITID is stored in the terminal information database) list of the gateway host, which is considered as “transmitting, via a secure connection with a wireless mobile end-user device, a first signed message to the wireless mobile-end user device to confirm a compatible and approved server status of at least one server of the one or more servers”., page 49, lines 4-20), receiving, via the secure connection with the wireless mobile end-user device, a second signed message from the wireless mobile-end user device to confirm a compatible and approved device status of the wireless mobile end-user device desiring to perform the one or more secure electronic mobile commerce transactions, after the authorization, with the at least one server confirmed to have the compatible and approved server (The unique password and root certificate are then sent to the terminal 10. The terminal 10 stores the received credentials to the terminal memory for future use. When the gateway host 19 receives a confirmation from the terminal 10, it also deletes the outdated terminal record from the terminal information database. A new record includes the ITID, an .sup.Λin-service' flag to indicate that the terminal is active, and a unique terminal password. Examiner notes that the gateway hose receives a confirmation message from the terminal to confirm an activated status of the terminal which is ready to perform electronic payment, which is considered as “receiving, via the secure connection with the wireless mobile end-user device, a second signed message from the wireless mobile-end user device to confirm a compatible and approved device status of the wireless mobile end-user device desiring to perform the one or more secure electronic mobile commerce transactions, after the authorization, with the at least one server confirmed to have the compatible and approved server”., page 49,lines 4-page 50, lines 4 and page 50, lines 28-page 51, line 4).
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention was made to modify a mobile transaction system of Sarcanin to include, the automated handshake includes: transmitting, via a secure connection with a wireless mobile end-user device, a first signed message to the wireless mobile-end user device to confirm a compatible and approved server status of at least one server of the one or more servers, receiving, via the secure connection with the wireless mobile end-user device, a second signed message from the wireless mobile-end user device to confirm a compatible and approved device status of the wireless mobile end-user device desiring to perform the one or more secure electronic mobile commerce transactions, after the authorization, with the at least one server confirmed to have the compatible and approved server, as taught in Barsukov, in order to prevent the use of a fake terminal or fake acquirer host, or to prevent physical tampering with the terminal (Barsukov, page 3, line 32-page 4, line 2).
With regard to claims 2 and 22, Sarcanin discloses the one or more servers are further configured to: create a token corresponding to the first electronic mobile commerce transaction (paragraph 378, . Next, the payment server packages the result message including the transaction identifiers and sends this message to the VirtualSAFE server 108 in encrypted form.).
With regard to claims 3 and 23, Sarcanin discloses the token corresponding to the first electronic mobile commerce transaction is specific to the secure connection between the wireless mobile end-user device and the one or more servers (paragraph 378, the payment server packages the result message including the transaction identifiers and sends this message to the VirtualSAFE server 108 in encrypted form. The server then passes the result to the emulator for appropriate database updates such as balance and ID. .).
With regard to claims 4 and 24, the combination of references discloses wherein header information included in the second signed message from the wireless mobile end-user device conforms to one or more predetermined specifications (Barsukov, page 45, lines 10-13, The terminal HTTP client replies to the GET request with the corresponding ETag (i.e identifier of cacheable content) HTTP header generated by the gateway host's HTTP proxy.), wherein the one or more servers are further configured to: transmit the purchase confirmation request to a mobile payment agent in the wireless mobile end-user device (Sarcanin, paragraphs 21, sending transaction information from the merchant server to the client terminal in response to the transaction request message).
With regard to claims 5 and 25, Sarcanin discloses the one or more servers are further configured to: request, via the mobile payment agent, the approval of the device user for the electronic mobile commerce transaction to be conducted through the central billing process (paragraph 22, receiving a user identifier and a PIN from the user at the client terminal for authorizing the transaction).
With regard to claims 6 and 26, Sarcanin discloses the one or more servers are further configured to: confirm that a user account has a sufficient credit limit to be billed for the first electronic mobile commerce transaction (paragraph 24, comparing the price of the product to the account balance for the smart card at the authentication server to determine if the transaction can proceed).
With regard to claims 7 and 27, Sarcanin discloses the one or more servers are further configured to: receive the purchase confirmation request via the secure connection between the wireless mobile end-user device and the one or more servers (paragraph 21, sending transaction information from the merchant server to the client terminal in response to the transaction request message, the transaction information being contained in a second web page generated by the merchant server and displayable to the user through the browser, the transaction information including a price for the product, an IP address of the payment server, a transaction identifier, and a merchant identifier).
With regard to claims 8 and 28, Sarcanin discloses the one or more servers are further configured to: receive the purchase confirmation request for the first electronic mobile commerce transaction using a web browser application (paragraph 21, the transaction information being contained in a second web page generated by the merchant server and displayable to the user through the browser).
With regard to claims 9 and 29, the combination of references discloses after performing the automated handshake, exchange security keys to provide additional security for the first electronic mobile commerce transaction via the secure connection with the wireless mobile-end user device (Sarcanin, paragraph 119, Barsukov, page 51, line 1-5, After the handshake, the terminal and the gateway host 19 are connected over a secure channel and any request from the terminal is assumed to be safe. But to prevent terminal 10 forgery, the STP protocol provides an additional terminal authentication check.).
With regard to claim 10, Sarcanin discloses the one or more servers are further configured to: send a confirmation of a purchase bill to a billing server for a triangle confirmation of the first electronic mobile commerce transaction (paragraphs 25 and 27, sending a draw request message from the authentication server to the payment server using the IP address of the payment server, the draw request message containing the transaction information. sending a debit request message from the client terminal to the payment server.).
With regard to claims 11 and 30, Sarcanin discloses the one or more servers are further configured to: bill for the first electronic mobile commerce transaction through the central billing process (paragraphs 117-118, the secure transaction repository 114 includes a purchase table (i.e. log full of transactions and timestamps) and an initiation table (i.e. log full of transactions, funding request/response, and timestamps)).
With regard to claim 13, the combination of references discloses header information included in the second signed message from the wireless mobile end-user device conforms to one or more predetermined specifications (Barsukov, page 45, lines 10-13), the method further comprising: billing for the first electronic mobile commerce transaction through the central billing process (Sarcanin, paragraphs 117-118).
With regard to claims 31-33, the combination of references discloses and teaches transmitting the first signed message to the wireless mobile-end user device occurs after receiving the second signed message from the wireless mobile-end user device (Barsukov, page 49,lines 4-page 50, lines 4 and page 50, lines 28-page 51, line 4, Examiner notes that authentication is performed during the handshake by exchanging digital certificates. The sequence of messages between the client side and the server side is interchangeable.).
Response to Arguments
Applicants' Appeal Brief filed on 05/26/2026 have been fully considered but they are not fully persuasive especially in light of the new prior art applied in the rejections.
Applicants remark that “the combination of references does not disclose the automated handshake includes: transmitting, via a secure connection with a wireless mobile end-user device, a first signed message to the wireless mobile-end user device to confirm a compatible and approved server status of at least one server of the one or more servers, the at least one server designated to perform the one or more secure electronic mobile commerce transactions after the authorization; and receiving, via the secure connection with the wireless mobile end-user device, a second signed message from the wireless mobile-end user device to confirm a compatible and approved device status of the wireless mobile end-user device desiring to perform the one or more secure electronic mobile commerce transactions, after the authorization, with the at least one server confirmed to have the compatible and approved server”.
Examiner directs Applicants' attention to the office action above.
Conclusion
Please refer to form 892 for cited references.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ARIEL J YU whose telephone number is (571)270-3312. The examiner can normally be reached 11AM - 7PM (M-F).
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, Obeid Fahd A can be reached on 571-270-3324. 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.
/ARIEL J YU/Primary Examiner, Art Unit 3627 /FAHD A OBEID/Supervisory Patent Examiner, Art Unit 3627
Prosecution Insights