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 .
DETAILED ACTION
This Office Action is in response to an AMENDMENT entered March 30, 2026 for the patent application 18/774,669.
Status of Claims
Claims 1 - 20 are pending in the application.
Claims 1 – 8 and 17 - 20 (non-elected claims) are withdrawn from consideration.
Claims 9 – 16 are examined below.
Response to Arguments
Examiner would like to point out that the Supreme Court in KSR International Co. v. Teleflex Inc. described seven rationales to support rejections under 35 U.S.C. 103:
Combining prior art elements according to known methods to yield predictable results;
Simple substitution of one known element for another to obtain predictable results;
Use of known technique to improve similar devices (methods, or products) in the same way;
Applying a known technique to a known device (method, or product) ready for improvement to yield predictable results;
“Obvious to try” –choosing from a finite number of identified, predictable solutions, with a reasonable expectation of success;
Known work in one field of endeavor may prompt variations of it for use in either the same field or a different one based on design incentives or other market forces if the variations would have been predictable to one of ordinary skill in the art; and
Some teaching, suggestion, or motivation in the prior art that would have led one of ordinary skill to modify the prior art reference or to combine prior art reference teachings to arrive at the claimed invention.
Prior art is not limited just to the references being applied, but includes the understanding of one of ordinary skill in the art. The prior art reference (or references when combined) need not teach or suggest all the claim limitations; however, Office personnel must explain why the difference(s) between the prior art and the claimed invention would have been obvious to one of ordinary skill in the art. The “mere existence of differences between the prior art and an invention does not establish the invention’s nonobviousness.” see Dann v. Johnson, 425 U.S. 219, 230 (1976).
Applicant's arguments filed with an Amendment on March 30, 2026 have been fully considered but they are not persuasive.
Re: Claim 9, the applicant asserts that cited prior art do not teach – “prompting, by a merchant point-of-sale device, a customer for payment for a transaction.“, (see page 9 of the Remarks).
The Examiner respectfully disagrees, Asefi does discloses “prompting, by a merchant point-of-sale device, a customer for payment for a transaction.“ at (Asefi, [0042] - The merchant computing device 140 may be used at a point of sale location to conduct transactions with the account holder. For example, the merchant computing device 140 may include a POS computer system such as a cash register system connected to a central server system operated by the merchant. As another example, the merchant computing device 140 may include a mobile computing device (e.g., smart phone, tablet PC, etc.) operated by a store clerk as the clerk moves throughout the store. Again, the mobile computing device in such an embodiment may connect to a central server system operated by the merchant.), with further emphasis at (Asefi, [0011], - Referring generally to the figures, systems and methods for facilitating a financial transaction are described. More particularly, the present disclosure relates to improved systems and methods for processing payments that allow the payments to be completed without the use of a traditional transaction network. Many financial transactions are completed electronically. For example, credit cards, debit cards, stored value cards, and other devices allow a user to complete electronic payments. A user maintains financial accounts at one or more financial institutions, and each account is linked to one of the various types of cards or other devices referred to above. To complete payment to a merchant, the user provides the card associated with the account to be used for payment. The card is scanned via a point-of-sale (POS) computing device by the merchant such that the POS device can obtain information (e.g., an account number, an identity of the user, etc.) from the card. The information obtained from the card is transmitted to the issuing financial institution from the POS device via a proprietary transaction network.).
Re: Claim 9, the applicant asserts that cited prior art do not teach – “reading, by the merchant point-of-sale device and using a camera, an optical code that identifies a payment card and comprises an indicator for payment network-less transactions.“, (see page 10 of the Remarks).
The Examiner respectfully disagrees, Asefi does discloses “reading, by the merchant point-of-sale device and using a camera, an optical code that identifies a payment card and comprises an indicator for payment network-less transactions.“ at (Asefi, [0050] - In some arrangements, the mobile device 110 can receive the payment request via NFC, Bluetooth, or Wi-Fi. For example, the network interface circuit 342 of the merchant computing device 140 can be configured to transmit the payment request to the mobile device via a predetermined communication protocol, and the network interface circuit 312 of the mobile device 110 can be configured to receive the payment request according to the predetermined communication protocol. In some other arrangements, the mobile device 110 can be configured to receive the payment request in the form of an optically scanned code, such as a QR code. For example, the payment requesting circuit 348 of the merchant computing device 140 can be configured to generate the payment request in the form of an optical code, and the input device 315 of the mobile device 110, which may include optical equipment such as a camera, scans the optical code. In some arrangements, the mobile wallet client application can be configured to extract the payment request information from the scanned optical code.), with further emphasis at (Asefi, [0055], - At 425, the mobile device 110 transmits the authorization message to the merchant computing device 140. In some arrangements, the mobile device 110 can be configured to transmit the authorization using the same communication protocol or optical code that by which the mobile device received the payment request at 405. If the authorization message indicates that the payment request was approved, then the merchant can remit the goods to the user, credit a merchant account associated with the user, or take any other appropriate action. If the authorization message indicates that the payment request was denied, then the merchant can instead seek to obtain payment by a different method. For example, the merchant may ask the user to pay with cash, or with a different financial account.).
Re: Claim 9, the applicant asserts that cited prior art do not teach – “identifying, by the merchant point-of-sale device, the transaction as a payment network-less transaction based on the optical code.“, (see page 11 of the Remarks).
The Examiner respectfully disagrees, Asefi does discloses “identifying, by the merchant point-of-sale device, the transaction as a payment network-less transaction based on the optical code.“ at (Asefi, [0051] - The mobile device generates authentication information at 410. In some arrangements, the authentication information includes biometric data from the user of the mobile device 110. The biometric data can include information corresponding to the user's voice, the user's fingerprint, the user's iris, or any other type of biometric data. The input device 315 of the mobile device 110 can be configured to allow the user to provide the biometric data. For example, the input device 315 can be a microphone configured to capture audio corresponding to the user's voice. In some other arrangements, the input device 315 can be a camera configured to capture an image corresponding to the user's iris or a fingerprint sensor configured to scan the user's fingerprint. Other forms of authentication information also can be used. For example, the mobile device 110 can store a device token uniquely identifying the mobile device 110 from among other mobile devices. In some implementations, the mobile device 110 can compare its location to a location of the merchant computing device 140 to ensure that the mobile device 110 is physically located near the merchant computing device 140 as an additional form of authentication information.), with further emphasis at (Asefi, [0044], - The code scanner 344 may be configured to scan
codes, such as but not limited to, optically scanned or non-optically scanned codes. In the embodiment of the present disclosure, the code scanner 344 scans one or more types of codes. After receiving the code, the scanner 344 determines the information that was incorporated into the code by the mobile device 110 or the mobile wallet bank computer system 320 that generated the code,).
Re: Claim 9, the applicant asserts that cited prior art do not teach – “communicating, by the merchant point-of-sale device and without using a payment network, transaction details for the transaction, information from the optical code, and a merchant identifier to an issuer backend for an issuer of the payment card.“, (see page 12 of the Remarks).
The Examiner respectfully disagrees, Leyva does discloses “communicating, by the merchant point-of-sale device and without using a payment network, transaction details for the transaction, information from the optical code, and a merchant identifier to an issuer backend for an issuer of the payment card.“ at (Leyva, [0078] - Phrases similar to a "payment processor" may include a company (e.g., a third party) appointed (e.g., by a merchant) to handle transactions. A payment processor may include an issuer, acquirer, authorizer and/or any other system or entity involved in the transaction process. Payment processors may be broken down into two types: front-end and back-end. Front-end payment processors have connections to various transaction accounts and supply authorization and settlement services to the merchant banks' merchants. Back-end payment processors accept settlements from front-end payment processors and, via The Federal Reserve Bank, move money from an issuing bank to the merchant bank. In an operation that will usually take a few seconds, the payment processor will both check the details received by forwarding the details to the respective account's issuing bank or card association for verification, and may carry out a series of anti-fraud measures against the transaction. Additional parameters, including the account's country of issue and its previous payment history, may be used to gauge the probability of the transaction being approved. In response to the payment processor receiving confirmation that the transaction account details have been verified, the information may be relayed back to the merchant, who will then complete the payment transaction. In response to the verification being denied, the payment processor relays the information to the merchant, who may then decline the transaction.), with further emphasis at (Leyva, [0049], - Referring to FIG. 8, in various embodiments, a payment code 810 may be printed on a transaction instrument 820. In various embodiments, the payment code 810 may only contain information which is otherwise visible on the transaction instrument 820. For example, the payment code 810 may comprise a transaction account number or an alias, expiration date, consumer name, and a card identification number ("CID"). In various embodiments, the payment code 810 may comprise additional information such as an alias, a static security code, a billing address, or any other information. In various embodiments, transaction instrument 820 may comprise a first payment code on a first side of the transaction instrument, and a second payment code on a second side of the transaction instrument. PCD 130 may scan payment code 810 from transaction instrument 820 using camera 830. PCD 130 may prompt the owner of transaction instrument 820 to enter additional transaction information on PCD 130. The additional transaction information may comprise a signature, billing zip code, personal identification number, or any other verification information. PCD 130 may also prompt the consumer or the transaction instrument owner to enter a transaction amount. PCD 130 may transmit the transaction information to CAS 110.).
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 of this title, 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 9 – 16 are rejected under 35 U.S.C. 103 as being obvious over Azita Asefi et al. (Pub. # US 2023/0106418 A1 – herein referred to as Asefi) in view of Marcel Leyva et al. (Pub. # US 2018/0315045 A1 – herein referred to as Leyva).
Re: Claim 9, Asefi discloses a method, comprising:
prompting, by a merchant point-of-sale device, a customer for payment for a transaction (Asefi, [0042] - The merchant computing device 140 may be used at a point of sale location to conduct transactions with the account holder. For example, the merchant computing device 140 may include a POS computer system such as a cash register system connected to a central server system operated by the merchant. As another example, the merchant computing device 140 may include a mobile computing device (e.g., smart phone, tablet PC, etc.) operated by a store clerk as the clerk moves throughout the store. Again, the mobile computing device in such an embodiment may connect to a central server system operated by the merchant.);
reading, by the merchant point-of-sale device and using a camera, an optical code that identifies a payment card and comprises an indicator for payment network-less transactions (Asefi, [0050] - In some arrangements, the mobile device 110 can receive the payment request via NFC, Bluetooth, or Wi-Fi. For example, the network interface circuit 342 of the merchant computing device 140 can be configured to transmit the payment request to the mobile device via a predetermined communication protocol, and the network interface circuit 312 of the mobile device 110 can be configured to receive the payment request according to the predetermined communication protocol. In some other arrangements, the mobile device 110 can be configured to receive the payment request in the form of an optically scanned code, such as a QR code. For example, the payment requesting circuit 348 of the merchant computing device 140 can be configured to generate the payment request in the form of an optical code, and the input device 315 of the mobile device 110, which may include optical equipment such as a camera, scans the optical code. In some arrangements, the mobile wallet client application can be configured to extract the payment request information from the scanned optical code.);
identifying, by the merchant point-of-sale device, the transaction as a payment network-less transaction based on the optical code (Asefi, [0051] - The mobile device generates authentication information at 410. In some arrangements, the authentication information includes biometric data from the user of the mobile device 110. The biometric data can include information corresponding to the user's voice, the user's fingerprint, the user's iris, or any other type of biometric data. The input device 315 of the mobile device 110 can be configured to allow the user to provide the biometric data. For example, the input device 315 can be a microphone configured to capture audio corresponding to the user's voice. In some other arrangements, the input device 315 can be a camera configured to capture an image corresponding to the user's iris or a fingerprint sensor configured to scan the user's fingerprint. Other forms of authentication information also can be used. For example, the mobile device 110 can store a device token uniquely identifying the mobile device 110 from among other mobile devices. In some implementations, the mobile device 110 can compare its location to a location of the merchant computing device 140 to ensure that the mobile device 110 is physically located near the merchant computing device 140 as an additional form of authentication information.).
However, Asefi does not expressly disclose:
communicating, by the merchant point-of-sale device and without using a payment network, transaction details for the transaction, information from the optical code, and a merchant identifier to an issuer backend for an issuer of the payment card; and
receiving, by the merchant point-of-sale device and from the issuer backend, a decision on the transaction.
In a similar field of endeavor, Leyva discloses:
communicating, by the merchant point-of-sale device and without using a payment network, transaction details for the transaction, information from the optical code, and a merchant identifier to an issuer backend for an issuer of the payment card (Leyva, [0078] - Phrases similar to a "payment processor" may include a company (e.g., a third party) appointed (e.g., by a merchant) to handle transactions. A payment processor may include an issuer, acquirer, authorizer and/or any other system or entity involved in the transaction process. Payment processors may be broken down into two types: front-end and back-end. Front-end payment processors have connections to various transaction accounts and supply authorization and settlement services to the merchant banks' merchants. Back-end payment processors accept settlements from front-end payment processors and, via The Federal Reserve Bank, move money from an issuing bank to the merchant bank. In an operation that will usually take a few seconds, the payment processor will both check the details received by forwarding the details to the respective account's issuing bank or card association for verification, and may carry out a series of anti-fraud measures against the transaction. Additional parameters, including the account's country of issue and its previous payment history, may be used to gauge the probability of the transaction being approved. In response to the payment processor receiving confirmation that the transaction account details have been verified, the information may be relayed back to the merchant, who will then complete the payment transaction. In response to the verification being denied, the payment processor relays the information to the merchant, who may then decline the transaction.); and
receiving, by the merchant point-of-sale device and from the issuer backend, a decision on the transaction (Leyva, [0052] - Referring to FIG. 10, a flowchart is illustrated according to various embodiments. In step 1010, PCD 130 may scan a payment code located at a merchant POS. For example, a gas pump or a cash register at a merchant store may comprise a payment code which is viewable by a consumer. The payment code may be digitally produced on a screen or may be in a physical embodiment such as a sticker affixed to a gas pump. The payment code may comprise information such as a merchant account, a merchant location, a merchant service establishment number, a merchant tax identification number, or other information identifying the merchant or the specific POS. In various embodiments, the payment code may comprise dynamic information such as the date or time of day, or a transaction identifier which changes after each transaction conducted at the POS.).
Therefore, in light of the teachings of Leyva, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify the method of Asefi, motivation according to one KSR Exemplary Rationale where a known technique is used to improve similar methods and systems in the same way by providing an account authorization system may transmit the dynamic security codes to a portable consumer device. At the time of transmitting, the dynamic security code may not be associated with a transaction. The account authorization system may receive a transaction request from a merchant or from the portable consumer device. The transaction request may comprise the transaction account number and the dynamic security code. The account authorization system may detect a dynamic security code in the transaction request and determine that the transaction account number and the dynamic security code match a transaction account number and dynamic security code stored on a database. The account authorization system may transmit an authorization message to the merchant. (Leyva, [0007]).
Re: Claim 10, Asefi discloses the method of claim 9,
wherein the optical code is read from a payment card or from a customer electronic device (Asefi, [0046] - The payment requesting circuit 348 communicates a payment request via the network interface circuit 342 to the mobile device 110. The payment receiving circuit 349 determines when payment has been received by the merchant computing device 140 and allocates the payment accordingly. The merchant computing device 140 may further connect to or integrate with other hardware. For example, in one embodiment, the merchant computing device 140 may connect to a card reader for reading credit cards, debit cards, stored value cards, and so on. As another example, the merchant computing device 140 may be con-figured to prompt the user to provide a random security code. The random security code may be generated by the mobile device 110, by a separate security device, or in another manner. The security code may be provided to the merchant computing device 140 directly by the mobile device 110, may be keyed into the merchant computing device 140 (e.g., by a store clerk), or may be received in another manner.).
Re: Claim 11, Asefi discloses the method of claim 9,
wherein the optical code comprises a Quick Response (QR) code or a bar code (Asefi, [0050] - In some arrangements, the mobile device 110 can receive the payment request via NFC, Bluetooth, or Wi-Fi. For example, the network interface circuit 342 of the merchant computing device 140 can be configured to transmit the payment request to the mobile device via a predetermined communication protocol, and the network interface circuit 312 of the mobile device 110 can be configured to receive the payment request according to the predetermined communication protocol. In some other arrangements, the mobile device 110 can be configured to receive the payment request in the form of an optically scanned code, such as a QR code. For example, the payment requesting circuit 348 of the merchant computing device 140 can be configured to generate the payment request in the form of an optical code, and the input device 315 of the mobile device 110, which may include optical equipment such as a camera, scans the optical code. In some arrangements, the mobile wallet client application can be configured to extract the payment request information from the scanned optical code.).
Re: Claim 12, Asefi discloses the method of claim 9, further comprising:
receiving, by the merchant point-of-sale device, a personal identification number (PIN) (Asefi, [0016] - Payment information may include private or otherwise sensitive information about the user, such as an account number for a financial account held by the user or personal information about the user's identity. Providing this information to the merchant can potentially expose the user to risk of data theft, for example, if the merchant's computing systems are compromised by a fraudster or other malicious third party in the future. In some arrangements, certain user information, such as an account number, may be "tokenized" or otherwise abstracted prior to being transferred to the merchant. However, the information provided to the merchant still typically includes personal identifying information of the user, which may put the user at risk if the information is stolen. Bypassing the proprietary transaction network and allowing the user to send the information directly to the financial institution, as described in this disclosure, reduces this risk.);
wherein the merchant point-of-sale device communicates the PIN with the information from the optical code (Asefi, [0017] - In addition, because user communicates directly with the financial institution via the user computing device, the financial institution may be able to infer a portion of the payment information without ever receiving it from the user. For example, the financial institution may infer an account number based on an identity of the user (or the user's computing device). The user computing device may send user identity information or a unique device number associated with the user computing device to the financial institution. The financial institution can maintain records indicating the account numbers associated with its customers. Thus, by comparing the information received from the user computing device to its stored records, the financial institution can determine an account number to be used for the payment. As a result, the account number does not have to be transmitted to the financial institution, thereby reducing the risk that the account number could be intercepted in transit to the financial institution.).
Re: Claim 13, Asefi discloses the method of claim 9, wherein the decision comprises a rejection of the transaction, and further comprising:
executing, by the merchant point-of-sale device, the transaction using a payment network (Asefi, [0016] - The arrangement described above also achieves the technical effect of reducing unauthorized access to a user's payment information. For example, the traditional payment systems described above generally require the user to provide payment information to the merchant, who then transmits the payment information to a financial institution via the proprietary payment network. In some arrangements, the merchant also may save some or all of the user's payment information. Payment information may include private or otherwise sensitive information about the user, such as an account number for a financial account held by the user or personal information about the user's identity. Providing this information to the merchant can potentially expose the user to risk of data theft, for example, if the merchant's computing systems are compromised by a fraudster or other malicious third party in the future.).
Re: Claim 14, Asefi in view of Leyva discloses the method of claim 10,
wherein the issuer backend is configured to push a notification to the customer electronic device and to receive confirmation for the transaction from a computer application associated with the issuer backend (Leyva, [0044] - In various embodiments, the authorization system may transmit a transaction notification to PCD 130. The transaction notification may be sent within the transaction application. In various embodiments the transaction notification may be sent via a SMS, text, e-mail, or other method of communication. The transaction notification may require that the consumer confirm the transaction by clicking on a confirm button or by indicating their confirmation in any other manner. The transaction notification may require the consumer to enter a password or other verification information, in various embodiments, the CAS 110 may determine that the transaction was fraudulent based on the response from PCD 130.). The rationale for support of motivation, obviousness and reason to combine see claim 9 above.
Re: Claim 15, Asefi in view of Leyva discloses the method of claim 14,
wherein the customer electronic device is configured to suppress the notification from other computer applications on the customer electronic device (Leyva, [0044] - In various embodiments, the authorization system may transmit a transaction notification to PCD 130. The transaction notification may be sent within the transaction application. In various embodiments the transaction notification may be sent via a SMS, text, e-mail, or other method of communication. The transaction notification may require that the consumer confirm the transaction by clicking on a confirm button or by indicating their confirmation in any other manner. The transaction notification may require the consumer to enter a password or other verification information, in various embodiments, the CAS 110 may determine that the transaction was fraudulent based on the response from PCD 130.). The rationale for support of motivation, obviousness and reason to combine see claim 9 above.
Re: Claim 16, Asefi in view of Leyva discloses the method of claim 9, further comprising:
approving, by an issues application executed by a customer electronic device, the transaction in response to the issuer backend being unavailable (Leyva, [0078] - Phrases similar to a "payment processor" may include a company (e.g., a third party) appointed (e.g., by a merchant) to handle transactions. A payment processor may include an issuer, acquirer, authorizer and/or any other system or entity involved in the transaction process. Payment processors may be broken down into two types: front-end and back-end. Front-end payment processors have connections to various transaction accounts and supply authorization and settlement services to the merchant banks' merchants. Back-end payment processors accept settlements from front-end payment processors and, via The Federal Reserve Bank, move money from an issuing bank to the merchant bank. In an operation that will usually take a few seconds, the payment processor will both check the details received by forwarding the details to the respective account's issuing bank or card association for verification, and may carry out a series of anti-fraud measures against the transaction. Additional parameters, including the account's country of issue and its previous payment history, may be used to gauge the probability of the transaction being approved. In response to the payment processor receiving confirmation that the transaction account details have been verified, the information may be relayed back to the merchant, who will then complete the payment transaction. In response to the verification being denied, the payment processor relays the information to the merchant, who may then decline the transaction.). The rationale for support of motivation, obviousness and reason to combine see claim 9 above.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOHN H. HOLLY whose telephone number is (571)270-3461. The examiner can normally be reached on MON. - FRI 10 AM - 8 PM.
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 S. GART can be reached on 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 an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/John H. Holly/Primary Examiner, Art Unit 3696
Prosecution Insights