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 .
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 as being directed to non-statutory subject matter, without a practical application or significantly more than the abstract idea.
Step 1 – Determine whether the claims are directed to a judicial exception (abstract idea)
Method Claims (1–7)
Claims 1–7 recite a method of processing a point-of-sale (POS) payment, including:
Receiving transaction information at a non-secure processor from a merchant device;
Receiving a message to trigger payment processing (e.g., request for PIN or signature);
Entering a secure touch mode for receiving inputs;
Sending inputs to a secure processor;
Switching from secure touch mode to pass-through mode; and
Sending confirmation to the merchant device.
These steps are directed to the abstract idea of processing a financial transaction, which is a fundamental economic practice and a well-established human activity. The steps recite the concept of collecting payment information, verifying the input, and confirming the transaction — activities routinely performed by merchants and customers long before the advent of computers.
Device Claims (8–14)
Claims 8–14 recite a customer device with secure and non-secure processors configured to perform the steps above. These claims are directed to the same abstract idea of processing payments implemented using generic processors. The claim recitations describe conventional computer components performing routine data handling in the context of a POS transaction.
Media Claims (15–20)
Claims 15–20 recite non-transitory computer-readable media storing instructions for executing the method steps. These claims are directed to the abstract idea of implementing the payment processing method on a generic computing device, which does not transform the underlying abstract idea into patent-eligible subject matter.
Conclusion of Step 1: All claims are directed to the abstract idea of managing and processing a financial transaction, which is a judicial exception under 35 U.S.C. § 101.
Step 2 – Determine whether the claims recite additional elements that amount to an “inventive concept” sufficient to transform the abstract idea into patent-eligible subject matter
Examiner notes:
The claims recite generic computing components such as secure and non-secure processors, memory, and communication with a merchant device. These are routine, conventional hardware components performing conventional functions.
Entering secure touch mode, switching to pass-through mode, and sending confirmations are standard operational modes of a computing device configured to implement financial transactions.
The claims do not provide any technical solution to a problem unique to computers or any improvement to the functioning of the processors themselves. There is no inventive concept beyond the abstract idea of processing a financial transaction using generic hardware.
Conclusion of Step 2: The claimed invention does not recite an inventive concept sufficient to transform the abstract idea into patent-eligible subject matter under Alice/Mayo.
Thus, claims 1–20 are rejected under 35 U.S.C. § 101 because they are:
Directed to the abstract idea of processing a financial transaction (Step 1); and
Recite no additional elements sufficient to transform the abstract idea into patent-eligible subject matter (Step 2).
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 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-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Guise et al. (US 2023/0252441, hereinafter Guise), in view of Guise et al. (US 2021/0326826A/ US11669822B2, hereinafter Guise26).
With respect to claim 1, GUISE teaches receiving information at a non-secure processor from a merchant device during a POS transaction (e.g., a consumer terminal with a main processor displaying screens and receiving transaction context signals) and, when secure data is needed, instructing the non-secure processor to enter a secure touch mode for receiving secure inputs (e.g., PIN input) (see Abstract, Summary, and descriptions of switching between pass through and secure touch modes).
GUISE26 further teaches a point of sale system where a secure processor instructs the main processor to enter a secure touch mode responsive to a request for secure data and exits secure touch mode to pass through mode upon determining the secure data entry is complete (Claim 1 of US11669822B2).
It would have been obvious to one of ordinary skill in the art to combine these teachings to provide a method that receives secure input and, upon confirmation of payment, switches back to pass through mode and sends confirmation to the merchant device.
With respect to claim 2, GUISE26 teaches that the request for secure data can be a request for entry of a personal identification number or other secure input during a POS transaction (see Claim 1 of US11669822B2 regarding requests for secure data). s Thus, triggering the processing of the payment by a PIN or signature request would have been obvious in light of this disclosure.
With respect to claim 3, the initiation of a checkout procedure that triggers the secure data request is inherent in the described POS flow in both references, in which the main processor displays screens during a POS transaction until a request for secure data (e.g., PIN entry) occurs (see GUISE Abstract and Guise 26 Claim 1).
With respect to claim 4, US11669822B2 teaches that, once the secure processor receives a secure data request, it processes the touch input during secure touch mode (claim 1). s It would have been obvious to use the secure processor to process payment information in this manner.
With respect to claim 5, GUISE describes a secure processor that interacts with payment data and a merchant system for secure input and confirmation delivery (see Abstract and related description). s As integrated systems, it would have been routine to configure the secure processor to receive payment information directly and to transmit that information to a payment system.
With respect to claim 6, encrypted communications of secure data between processors and external systems is a conventional feature of secure POS environments; the cited references describe a secure touch mode and secure enclave interaction, which inherently implies secure (e.g., encrypted) data handling.
With respect to claim 7, GUISE teaches information (e.g., merchant transaction data) being input via interfaces of the POS device, which are received by the non-secure/main processor during the POS session.
With respect to claim 8, US11669822B2 teaches a customer device including a main (non secure) processor and a secure processor configured to enter secure touch mode in response to a secure data request and exit secure touch mode upon completion (Claim 1).
With respect to claims 9 and 10, the disclosure of secure data requests (e.g., PIN request) that are triggered at checkout or by an event such as a transaction prompt is inherent in the POS flow of GUISE and GUISE26where screens and requests are displayed until secure touch mode is entered.
With respect to claim 11, US11669822B2 teaches the secure processor processing secure inputs during secure touch mode (see Claim 1). s
With respect to claim 12, direct communication of secure input from the secure processor to merchant/payment systems is a logical implementation of the secure enclave teaching, where the secure processor handles sensitive touch events and the result is fabricated into a merchant’s transaction stream. Such communication is a predictable design choice in the secure POS systems of both references.
With respect to claim 13, encrypted communication by secure processors is a conventional expectation in secure POS systems and would have been obvious to a skilled artisan given the secure touch and enclave environment described in the references.
With respect to claim 14, the merchant interface providing transaction input is taught in GUISE, which describes receiving various consumer/merchant inputs at the touch panel for secure and non-secure processing.
With respect to claim 15, the use of computer readable media to store instructions for performing the method recited in claim 1 is an obvious implementation of the secure/non secure processing steps of GUISE (which inherently relies on software instructions for mode switching and transaction handling).
With respect to claims 16 and 17, these dependent media claims recite features already disclosed as part of the standard POS operation in the references (triggering by PIN or checkout), and storing those behaviors in media instructions is a routine implementation. s+1
With respect to claim 18, execution of instructions to process secure payments is inherently taught by the secure processor logic in GUISE26where secure processor handles touch inputs corresponding to secure data requests.
With respect to claims 19 and 20, executing instructions to cause encrypted direct communication is a predictable and conventional extension of the secure enclave arrangements taught in GUISE, and would have been obvious to one of ordinary skill.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ROKIB MASUD whose telephone number is (571)270-5390. The examiner can normally be reached Mon-Fri 8:00-5:00.
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, Fahd Obeid can be reached at 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.
/ROKIB MASUD/ Primary Examiner, Art Unit 3627