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–21 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., an abstract idea) without reciting significantly more than the judicial exception.
Under the 35 U.S.C. §101 subject matter eligibility two-part analysis, Step 1 addresses whether the claim is directed to one of the four statutory categories of invention, i.e., process, machine, manufacture, or composition of matter. See MPEP §2106.03. If the claim does fall within one of the statutory categories, it must then be determined in Step 2A [prong 1] whether the claim is directed to a judicial exception (i.e., law of nature, natural phenomenon, and abstract idea). See MPEP §2106.04. If the claim is directed toward a judicial exception, it must then be determined in Step 2A [prong 2] whether the judicial exception is integrated into a practical application. See MPEP §2106.04(d). Finally, if the judicial exception is not integrated into a practical application, it must additionally be determined in Step 2B whether the claim recites "significantly more" than the abstract idea. See MPEP §2106.05.
Examiner note: The Office's 2019 Revised Patent Subject Matter Eligibility Guidance (2019 PEG) is currently found in the Ninth Edition, Revision 10.2019 (revised June 2020) of the Manual of Patent Examination Procedure (MPEP), specifically incorporated in MPEP §2106.03 through MPEP §2106.07(c).
Step 1: Claims 1–10 are directed to a process, claims 11–20 are directed to a machine/system, and claim 21 is directed to a computer program product (manufacture).
Therefore, these claims fall within a statutory category of invention.
However, these claims must still satisfy the judicial exception analysis under Step 2A and Step 2B.
Step 2A – Prong One; These claims recite creating invoices, transmitting invoices to consumers, processing payments, verifying transactions with financial institutions, and updating merchant payment records.
These limitations collectively describe managing payment transactions between a merchant, consumer, and payment processor. Such activities fall within the category of certain methods of organizing human activity, specifically: commercial interactions, financial transactions, billing and payment settlement. These are fundamental economic practices.
Courts have repeatedly held such activities to be abstract ideas. See, for example, Alice Corp. v. CLS Bank International (financial settlement abstract idea), buySAFE Inc. v. Google Inc. (transaction guarantees abstract idea), Ultramercial Inc. v. Hulu LLC (commercial transaction management abstract idea)
Step 2A – Prong Two; These claims further recite additional elements including: merchant device, consumer communication device, payment processor server, QR code generation module, QR code scanning module, NFC communication module, digital wallet module, payment processing module, fraud prevention module, settlement module.
However, these elements merely represent generic computer components used to implement the abstract idea.
These claims do not: improve computer functionality, improve network technology, provide a new data structure, or solve a technological problem. Instead, the computer components simply automate conventional financial transaction activities.
For example: generating and scanning QR codes, transmitting data via NFC, executing payment applications, updating transaction records. These are routine computer functions.
Thus, these claims do not integrate the abstract idea into a practical application.
Step 2B – Inventive Concept
These claims must next be evaluated to determine whether they include additional elements that amount to significantly more than the abstract idea.
The additional elements represent well-understood, routine, and conventional activities previously known in the payment processing field.
Examples include: QR code generation and scanning for payments, NFC payment transmission, digital wallet payment processing, communication with financial institutions for authorization, updating transaction records.
Such activities are widely used in modern payment systems.
Courts have held that implementing financial transactions using generic computer technology does not provide an inventive concept. See: Alice Corp. v. CLS Bank International, Intellectual Ventures I LLC v. Capital One Bank.
Accordingly, these claims do not include an inventive concept sufficient to transform the abstract idea into patent-eligible subject matter.
Berkheimer Evidence (WURC)
The specification describes the computing components at a high level of generality, indicating that the elements are conventional. For example, the specification describes: generic mobile devices, conventional payment processing systems, standard communication technologies such as QR codes and NFC. Such descriptions support a finding that the claimed components are well-understood, routine, and conventional.
Thus, claims 1–21 are directed to an abstract idea of managing payment transactions, which falls within the category of certain methods of organizing human activity. These claims do not integrate the abstract idea into a practical application and do not include additional elements amounting to significantly more than the abstract idea. Accordingly, claims 1–21 are rejected under 35 U.S.C. 101.
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-10 and 21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Moshal (US2014/0289107), in view of Xie et al. (US 2015/0278800, hereinafter Xie) and further in view of Orlinsky Scott (WO 2022216724A1, hereinafter Orlinksy).
With respect to claim 1, Moshal discloses the feature of a method for conducting a payment transaction at a merchant site in which a merchant generates invoice information associated with a transaction (see for example abstract, paragraphs [0020], [0027] and Fig. 2);
creating a payment invoice by a merchant using a payment facilitating application or system associated with a payment service provider (see for example paragraphs [0027] and [0031] and Fig. 3);
sending the payment invoice to a consumer in real-time by scanning a payment invoice code using a consumer communication device (see for example paragraphs [0033], [0035] and Fig. 4);
processing a payment by the consumer using a mobile device payment application (see for example paragraphs [0036] and [0038]).
Moshal does not explicitly disclose the feature of processing a payment on a consumer communication device in which sensitive card details are maintained secure and undisclosed to the merchant by using a payment provider server or payment application, and automatically updating a merchant payment invoice or transaction record upon completion of a payment transaction following payment authorization.
However, Xie teaches the feature of processing a payment on a consumer communication device in which sensitive card details are maintained secure and undisclosed to the merchant by using a payment provider server or payment application (see for example paragraphs [0045], [0051] and Fig. 5), and
Kim teaches the feature of automatically updating a merchant payment invoice or transaction record upon completion of a payment transaction following payment authorization (see for example paragraphs [0041], [0044] and Fig. 6).
Therefore, It would have been obvious to one of ordinary skill in the art to combine the teachings of Moshal , Suresh, and Kim. Moshal teaches a QR-based invoice payment workflow in which a consumer scans an invoice code to initiate payment using a mobile device. Xie teaches secure mobile payment applications that protect sensitive card information and support NFC communication and digital wallet functionality. Orlinsky teaches payment provider servers verifying transactions with financial institutions and updating merchant systems upon payment completion. One of ordinary skill in the art would have been motivated to combine these teachings in order to enhance the security and functionality of QR-based payment invoice systems by incorporating secure mobile wallet payment processing and payment provider verification with financial institutions. The combination merely involves using known mobile payment security mechanisms and payment network verification techniques with a known QR-based invoice payment architecture, which would have resulted in predictable improvements in payment security, reliability, and merchant transaction management.
With respect to claim 2, Moshal further discloses the feature of sending the payment invoice via a QR code that can be scanned using the consumer’s communication device (see for example paragraphs [0033], [0034] and Fig. 4).
With respect to claim 3, Xie further teaches the feature of transmitting transaction or payment data between a merchant device and a consumer communication device using near field communication (NFC) (see for example paragraphs [0039] and [0043] and Fig. 2).
It would have been obvious to utilize NFC communication for transmitting invoice data instead of or in addition to QR scanning, as both techniques were known contactless communication mechanisms for mobile payments.
With respect to claim 4, Xie further teaches the feature of a consumer using a digital wallet application on a mobile device to process a payment transaction (see for example paragraphs [0045] and [0050]).
With respect to claim 5, Xie further teaches the feature of manually entering card information into a mobile payment application to complete a payment transaction (see for example paragraphs [0053] and [0055]).
With respect to claim 6, Orlinsky further teaches the feature of automatically updating the merchant payment status upon receipt of payment confirmation from a payment processor (see for example paragraphs [0041], [0043] and Fig. 6).
With respect to claim 7, Moshal further discloses the feature of providing confirmation of payment to the consumer device after completion of the payment transaction (see for example paragraphs [0039] and [0041]). Such confirmation inherently includes a digital receipt or transaction confirmation message.
With respect to claim 8, Xie further teaches the feature of storing transaction data and receipts within a consumer payment or financial management application (see for example paragraphs [0057] and [0060]).
With respect to claim 9, Orlinsky further teaches the feature of verifying the payment transaction with a financial institution during payment processing (see for example paragraphs [0035], [0038] and Fig. 4).
With respect to claim 10, Orlinsky discloses the feature of verification initiated directly by a payment provider communicating with a financial institution without merchant involvement (see for example paragraphs [0037] and [0040]).
With respect to claim 21, Moshal discloses the feature of a set of instructions executable by a merchant device to generate a payment invoice based on transaction details (see for example paragraphs [0027] and [0031] and Fig. 3).
transmitting the payment invoice to a consumer communication device via a secure communication protocol in which the invoice data is encoded into a scannable payment code (see for example paragraphs [0031], [0033] and Fig. 4);
a consumer communication device receiving the payment invoice by scanning the payment code and decoding invoice data for payment processing (see for example paragraphs [0033], [0035] and Fig. 4).
Moshal does not explicitly disclose the feature of a payment application on a consumer device configured to process a payment transaction using stored payment credentials, processing the payment transaction in a manner that prevents sensitive card details from being transmitted to the merchant, such that payment credentials are handled by a payment provider system, a payment provider server configured to receive and verify a payment transaction by communicating with a financial institution, performing authentication and validation of the payment transaction including multi-factor authentication procedures prior to authorizing the transaction, a transaction update module configured to receive confirmation of payment completion from the payment provider and automatically update the payment status within the merchant system.
However, Xie teaches the feature of;
a payment application on a consumer device configured to process a payment transaction using stored payment credentials (see for example paragraphs [0045] and [0050] and Fig. 5).
processing the payment transaction in a manner that prevents sensitive card details from being transmitted to the merchant, such that payment credentials are handled by a payment provider system (see for example paragraphs [0048], [0051] and [0054]), and
Kim teaches the feature of a payment provider server configured to receive and verify a payment transaction by communicating with a financial institution (see for example paragraphs [0035], [0038] and Fig. 4); and
performing authentication and validation of the payment transaction including multi-factor authentication procedures prior to authorizing the transaction (see for example paragraphs [0039] and [0041]); and
a transaction update module configured to receive confirmation of payment completion from the payment provider and automatically update the payment status within the merchant system (see for example paragraphs [0041], [0043] and Fig. 6).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the invention to combine the teachings of Moshal , Suresh, and Kim. Moshal teaches a QR-based payment invoice architecture in which a merchant generates invoice data and a consumer scans the invoice code using a mobile device to initiate payment. Xie teaches secure mobile payment applications that protect sensitive payment credentials and prevent transmission of card details to merchants, thereby improving transaction security in mobile payment environments. Orlinsky teaches payment provider servers verifying payment transactions with financial institutions and automatically updating merchant transaction records following successful authorization.
One of ordinary skill in the art would have been motivated to combine these teachings in order to enhance the QR-based invoice payment system of Moshal with the secure credential handling and digital wallet payment processing of Xie and the payment network verification and merchant update functionality of Kim, thereby providing improved payment security, reliable authorization with financial institutions, and automatic transaction status synchronization between payment providers and merchant systems. Such a combination represents the predictable use of known payment processing components performing their established functions.
Claim(s) 11, 12, 14 and 18-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Moshal, in view of Orlinsky.
With respect to claim 11, Moshal discloses the feature of a system including a merchant device configured to generate invoice information and transmit that invoice to a consumer device (see for example paragraphs [0027], [0031] and Fig. 3).
a consumer device configured to receive the invoice and initiate payment processing (see for example paragraphs [0033] and [0036]).
Moshal does not disclose the feature of a payment processor configured to verify the transaction with a financial institution; a module that updates the merchant system upon completion of the transaction.
However, Orlinsky teaches the feature of a payment processor configured to verify the transaction with a financial institution (see for example paragraphs [0035] and [0038]);
a module that updates the merchant system upon completion of the transaction (see for example paragraphs [0041] and Fig. 6).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the invention to combine the teachings of Moshal. Moshal teaches a QR-based payment invoice architecture in which a merchant generates invoice data and a consumer scans the invoice code using a mobile device to initiate payment. Orlinsky teaches payment provider servers verifying payment transactions with financial institutions and automatically updating merchant transaction records following successful authorization. One of ordinary skill in the art would have been motivated to combine these teachings in order to enhance the QR-based invoice payment system of Moshal with the payment network verification and merchant update functionality of Orlinsky, thereby providing improved payment security, reliable authorization with financial institutions, and automatic transaction status synchronization between payment providers and merchant systems. Such a combination represents the predictable use of known payment processing components performing their established functions.
With respect to claim 12, Moshal further discloses a QR code generation module representing payment invoice data (see for example paragraphs [0031] and [0033]).
With respect to claim 14, Moshal discloses a QR code scanning module on a consumer device retrieving invoice data by scanning (see for example paragraphs [0033] and Fig. 4).
With respect to claim 18, Orlinsky discloses a payment processing module handling payment transactions (see for example paragraphs [0034] and [0036]).
With respect to claim 19, Orlinsky discloses a payment settlement process ensuring funds transfer from consumer to merchant (see for example paragraphs [0043] and [0045]).
With respect to claim 20, Moshal discloses generating and transmitting transaction confirmation information to a consumer device after payment completion (see for example paragraphs [0039] and [0041]).
Claim(s) 13, 15-17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Moshal (US2014/0289107), in view of Xie.
With respect to claim 13, Xie further teaches the feature of an NFC payment transfer module transmitting transaction data via NFC (see for example paragraphs [0039] and [0043]).
With respect to claim 15, Xie further teaches the feature of an NFC module on a consumer device receiving transaction data via NFC communication (see for example paragraphs [0039] and [0043]).
With respect to claim 16, Xie further teaches the feature of a digital wallet module storing payment credentials for mobile payments (see for example paragraphs [0045] and [0050]).
With respect to claim 17, Xie further teaches the feature of fraud monitoring modules associated with payment processing servers (see for example paragraphs [0062] and [0065]).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the invention to combine the teachings of Moshal. Moshal teaches a QR-based payment invoice architecture in which a merchant generates invoice data and a consumer scans the invoice code using a mobile device to initiate payment. Xie teaches secure mobile payment applications that protect sensitive payment credentials and prevent transmission of card details to merchants, thereby improving transaction security in mobile payment environments.
One of ordinary skill in the art would have been motivated to combine these teachings in order to enhance the QR-based invoice payment system of Moshal with the secure credential handling and digital wallet payment processing of Xie, thereby providing improved payment security, reliable authorization with financial institutions, and automatic transaction status synchronization between payment providers and merchant systems. Such a combination represents the predictable use of known payment processing components performing their established functions.
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