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 10/30/2025 has been entered.
Response to Amendment
Applicant’s “Amendment” filed on 10/30/2025 has been considered.
Claims 1, 3, 4, 5, 7-11, 13, and 15-20 are amended. Claims 2 and 14 are canceled. Claims 1, 3-13, and 15-20 remain pending in this application and an action on the merits follow.
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 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.
Claims 1, 3-13, and 15-20 are rejected under 35 U.S.C. 103 as being unpatentable over Korean Patent Application Publication No. 2013/0126772 to Kim et al., in view of International Publication No. WO 2012/054786 to Bayer.
With regard to claims 1 and 13, Kim discloses a payment terminal, comprising:
a main processor (page 3, lines 23-24, a main processor); a secure input device (page 3, lines 23-24, an input device); and a secure processor (page 3, lines 23-24, a security processor), wherein the secure processor is configured to:
switch to a secured mode to receive at least one secure user input, wherein, in the secured mode, the secure input device is selectively connected to the secure processor and selectively disconnected from the main processor (page 3, lines 34-page 4, line 12, and page 5, lines 15-18, The input mode may be determined based on the input mode signal from the processor 110. In another embodiment, an application running in the security processor 200 may determine whether data requiring security is input, and may notify the security processor 200 of the start and / or end of the secure input mode. The security processor 200 may receive input data ID from the input device 160 and selectively provide the input data ID to the main processor 110 according to the input mode of the mobile device 100. In addition, in the secure input mode, the secure processor 200 may directly process the input data ID without providing the input data ID to the main processor 110.);
receive the at least one secure user input from the secure input device (page 3, lines 34-page 4, line 12, The security processor 200 may receive input data ID from the input device 160);
generate, based on the at least one secure user input, secured payment information (page 11, lines 9-13, For example, a code (or applet) for receiving a user's Internet banking password, a code (or applet) for making an Internet banking payment, and the like may be executed in the central processing unit 560 of the security processor 500. When the code for receiving the Internet banking application or the Internet banking password of the user is executed, the mobile device 400 may operate in a secure input mode.);
encrypt, in the secured mode, the secured payment information to form encrypted secured payment information (page 11, lines 14-25, The encryption / decryption block 540 can generate a digital signature based on the Internet banking cryptogram extracted by the input processing block 520); and
switch, after verification of the at least one secure user input and notification of an end of the secured mode, to an unsecured mode to receive unsecured information, wherein, in the unsecured mode, the secure input device is selectively connected to the main processor and selectively disconnected from the secure processor (page 3, lines 34-page 4, line 12, and page 5, lines 15-18, The input mode may be determined based on the input mode signal from the processor 110. In another embodiment, an application running in the security processor 200 may determine whether data requiring security is input, and may notify the security processor 200 of the start and / or end of the secure input mode. In the normal input mode, the secure processor 200 may provide input data ID to the main processor 110 so that the main processor 110 processes the input data ID.).
However, Kim does not disclose tag the encrypted secured payment information with the unsecured information to form tagged secured payment information.
However, Bayer teaches tag the encrypted secured payment information with unsecured information, to form tagged secured payment information (paragraphs 42-48 and 109-110, a virtual wallet mobile app, e.g., 311, executing on a device, e.g., 300, of a user may include an app interface providing various features for the user. The app may provide an indication of a pay amount due for the purchase of the product, e.g., 322. In some embodiments, the app may provide various options for the user to pay the amount for purchasing the product(s). the app may provide an option 1 to provide express authorization before initiating the purchase transaction, e.g., 324. An example listing of transaction authorization input 1514 includes timestamp, payment data, and account. Examiner notes that the unsecured information with the security payment code/information are combined to form a transaction authorization input).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the invention was made to modify Kim to include, tag the encrypted secured payment information with unsecured information, to form tagged secured payment information, as taught in Bayer, in order to enhance the consumer shopping experience during purchase transaction authorization, e.g., 203, and/or purchase transaction clearance (Bayer, paragraph 34).
With regard to claims 3 and 15, the combination of references discloses transmitting, by the secure processor, the tagged secured payment information to the main processor (Kim, page 3, lines 23-24, Bayer, paragraphs 86, 107-108, and 110, In some embodiments, upon authenticating the user for access to virtual wallet features, the user wallet device may provide a transaction authorization input, e.g., 1514, to a point-of-sale ("PoS") client, e.g., 1502. Examiner notes that a transaction authorization input is transmitted to the POS client, which is considered as “transmitting, by the secured processor, the tagged secured payment information to the main processor”);
receiving, by the main processor, the tagged secured payment information (Kim, page 3, lines 23-24, Bayer, Fig. 23, paragraphs 86, 107-108, 110, and 157, In some embodiments, upon authenticating the user for access to virtual wallet features, the user wallet device may provide a transaction authorization input, e.g., 1514, to a point-of-sale ("PoS") client, e.g., 1502. Depending on the implementation all of the aforementioned embedded components and microprocessors may be considered the "CPU" and/or "processor" for the FMS. Examiner notes that a POS client/a merchant server with a main processor can be considered as “the main processor”. Examiner notes that receiving a transaction authorization input by a point-of-sale ("PoS") client, can be considered as “receiving, by the main processor, the tagged secured payment information”);
extracting, by the main processor, the unsecured information and the encrypted secured payment information from the tagged secured payment information without decrypting the encrypted secured payment information (Kim, page 3, lines 23-24, Bayer, Fig. 15-16, paragraphs 58, 86 and 196, The FMS may2 include a selection engine that utilizes information gained from a payment gateway to3 get user behavior across different regions, age groups, locale, and applications (ecommerce websites, or sections of a website, or games). the FMS controller may be executing a PHP script implementing a Secure Sockets Layer ("SSL") socket server via the information server, which listens to incoming communications on a server port to which a client may send data, e.g., data encoded in JSON format. Upon identifying an incoming communication, the PHP script may read the incoming message from the client device, parse the received JSON-en coded text data to extract information from the JSON-encoded text data into PHP script variables, and store the data (e.g., client identifying information, etc.) and/or extracted information in a relational database accessible using the Structured Query Language ("SQL"));
instructing, by the main processor, to display the unsecured information (Kim, page 3, lines 23-24, Bayer, paragraph 85, In some embodiments, the merchant server may obtain the checkout request from the client, and extract the checkout detail (e.g., XML data) from the checkout request. Examiner notes that it’s well-known that a POS device can display the checkout detail on a screen for review.);
transmitting, by the main processor, the encrypted secured payment information to a payment gateway (Kim, page 3, lines 23-24, Bayer, paragraph 111, The merchant server may forward the card authorization request to a MaaS server, e.g., 1504a, for routing the card authorization request to the appropriate payment network for payment processing. For example, the MaaS server may be able to select from payment networks, such as Visa, Mastercard, American Express, Paypal, etc., to process various types of transactions including, but not limited to: credit card, debit card, prepaid card, B2B and/or like transactions); and
receiving, by the main processor, a payment response corresponding to the encrypted secured payment information from the payment gateway (Kim, page 3, lines 23-24, Bayer, Fig. 15a-b, paragraph 118, the issuer server(s) may provide a funds authorization response, e.g., 1530, to the pay network server).
With regard to claims 4 and 16, Kim discloses the main processor is further configured to switch the secure processor from the unsecured mode to the secured mode in response to receiving based on reception of a payment request (page 5, lines 12-14 and page 11, lines 9-18, In one embodiment, the main processor 110 may send an input mode signal to the secure processor 200 indicating whether the input mode is the normal input mode or the secure input mode. For example, a code (or applet) for receiving a user's Internet banking password, a code (or applet) for making an Internet banking payment, and the like may be executed in the central processing unit 560 of the security processor 500. The input interface 510 may receive the input data ID from the touch controller 463 and may not provide the input data ID to the main processor 410 in the secure input mode.).
With regard to claims 5 and 17, Kim discloses the secure processor is further configured to receive and forward inputs to the main processor in the unsecured mode (page 3, lines 34-page 4, line 12).
With regard to claim 6, the combination of references discloses the main processor is further configured to download a third party application (Bayer, paragraphs 39-40).
With regard to claims 7 and 18, the combination of references discloses the main processor is further configured to expose the unsecured information by: reception of/receiving a request from a third party application for the unsecured information; verification of/verifying the third party application with a public key certificate stored by the main processor; and based on successful verification of the third party application, providing the unsecured information to the third party application (Bayer, paragraphs 39-41 and 51, the FMS may also allow developers to develop third-party apps that may be provided by the FMS to merchants via an application service store for the merchants. the FMS may facilitate a Developer Console that provides role based permissions to allow users of different levels to access different parts of the platform. One such level may be a customer support representative who can gain access to user transaction data to assist them with any issues, but would not gain access to other information such as revenue reports. In some embodiments, the records may be sent in a Health Insurance2 Portability and Accountability Act (HIPAA)-compliant data format and encrypted, and3 only the recipients who are authorized to view such records may have appropriate4 decryption keys to decrypt and view the private user information. It’s well known that an ownership of an application is a public key certificate, which is an electronic document used to prove the ownership).
With regard to claim 8, the combination of references discloses wherein the main processor is further configured to: update the third party application with an update downloaded to the main processor; based on the update of the third party application, prompt a merchant at the payment terminal to update a permission level for the third party application; receive an updated permission level for the third party application from the merchant; and restrict the unsecured information provided to the third party application based on the updated permission level (Bayer, paragraphs 39-41 and 51).
With regard to claims 9 and 19, the combination of references discloses further comprising exposing by the main processor the unsecured information by: extraction of/extracting a payment status from the payment response; storage of/storing the payment status in association with the unsecured information at a transaction resource; and exposure of/exposing the payment status and the unsecured information stored by the transaction resource to the third party application (Bayer, paragraphs 39-40 and 119).
With regard to claims 10 and 20, the combination of references discloses the unsecured information comprises order information; wherein the main processor is further configured to extract the unsecured information by: determination of/determining a product identifier and an order quantity from the order information, and cache/caching the product identifier and the order quantity; wherein update of/updating the transaction resource comprises, based on the payment status indicating payment information verification, storage of/storing the cached product identifier and the order quantity at the transaction resource; and wherein the exposure of/exposing the unsecured information to the third party application comprises providing the product identifier and the order quantity to the third party application (Bayer, paragraphs 39-40, 85, 119, and 121, the merchant server may extract product data (e.g., product identifiers), as well as available PoS client data, from the checkout request. In some embodiments, using the product data, the merchant server may query, e.g., 914, a merchant/acquirer ("merchant") database, e.g., 903b, to obtain product data, e.g., 915, such as product information, product pricing, sales tax, offers, discounts, rewards, and/or other information to process the purchase transaction and/or provide value- added services for the user. In some embodiments, the server may also generate a purchase receipt, e.g., 1533, and provide the purchase receipt to the client, e.g., 1535).
With regard to claim 11, the combination of references discloses the main processor is further configured to: based on the reception of the payment response update a transaction resource of the main processor with the unsecured information (Bayer, paragraphs 39-40 and 119).
With regard to claim 12, the combination of references discloses the unsecured information comprises unsecured transaction-associated information (Bayer, paragraphs 39-41 and 51).
Response to Arguments
Applicants' arguments filed on 10/30/2025 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 in the secured mode, the secure input device is selectively connected to the secure processor and selectively disconnected from the main processor; receive the at least one secure user input from the secure input device; and in the unsecured mode, the secure input device is selectively connected to the main processor and selectively disconnected from the secure processor”.
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