-DETAILED ACTION
This is an office action on the merits in response to the communication filed on 11/21/2025.
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 .
Claims’ Status
Claims 1-4 are elected. Claims 5-6 are withdrawn. Claims 1-4 are pending and are considered in this office action.
Claim Rejections - 35 USC § 112
Claim 2 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. Claim 2 recites: “associating the unique Apple ID with the merchant's account data within the merchant database maintained by the invention”, however it is not clear how the merchant database maintained by the invention.”
Claim 2 recites the limitation “Enabling the merchant's computing system to utilize the unique Apple ID for accessing the Tap To Pay feature without……”. There is insufficient antecedent basis for “Tap To Pay feature” in the claim.
Claim 3 recites the limitation “Initiating, upon successful detection of visible indications of NFC support, the mobile NFC card application on the smart device of the remote cardholder”; also on “performing the BIN-based detection by applying OCR techniques to the captured card image or video or by manually inputting the BIN number by the merchant.” There are insufficient antecedent basis for “the smart device” and “the BIN-based detection” in the claim.
Claim 4 recites “a. Operating, when utilizing the Tap to Pay functionality on a smart device…; h. Introducing an additional layer of transaction security by altering the encryption key with a key decryptable only by an authorized payment services partner, enhancing the security of the transaction.” There are insufficient antecedent basis for “Tap to Pay functionality” and “encryption key” in the claim.
In addition, claim 3 recites “a. Detecting, by the downloadable application executed on….; b. Initiating, upon successful detection of visible indications of NFC support, the mobile NFC card application on the smart device……”. It is not clear whether “the downloadable application” and “the mobile NFC card application” are the same.
Clarifications are required.
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-4 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
Step 1 (The Statutory Categories): Is the claim to a process, machine, manufacture or composition of matter? MPEP 2106.03
Per Step 1, Claims 1-4 are drawn to a method which is within the four statutory categories (i.e., a process).
Independent claim 1 recites:
a. providing a downloadable application for installation on a mobile device of a cardholder, the downloadable application configured to facilitate payment transactions;
b. Receiving, at a merchant's computing system, a request for payment from a remote cardholder, said request comprising transaction details and identification information associated with the remote cardholder;
c. Transmitting a payment request link to the remote cardholder's mobile device, said payment request link configured to initiate the downloadable application and establish a communication link between the remote cardholder's mobile device and the merchant's computing system;
d. Receiving, at the merchant's computing system, a confirmation code from the remote cardholder via the downloadable application or through manual entry, said confirmation code serving to verify the identity of the remote cardholder;
e. Establishing a secured communication channel between the remote cardholder's mobile device and the merchant's computing system;
f. Transmitting transaction details, including the confirmation code, from the remote cardholder's mobile device to the merchant's computing system through the secured communication channel;
g. Processing the payment transaction at the merchant's computing system using transaction details and confirmation code received from the remote cardholder's mobile device;
h. Transmitting a payment confirmation to the remote cardholder's mobile device through the secured communication channel, confirming the successful completion of the payment transaction; wherein the payment transaction is qualified for "card present" rates due to the verification of the remote cardholder's identity through the confirmation code, thereby reducing transaction costs and risks associated with the payment transaction.
Step 2A Prong 1: Does the claim recite an abstract idea, law of nature, or natural phenomenon MPEP 2106.04.
The limitations, as drafted, constitute a process that, under its broadest reasonable interpretation, covers managing, 1) fundamental economic principles or practices; 2) commercial interaction including agreements in the form of contracts, under the Certain methods of organizing human activity, but for the recitation of generic computer components. The abstract idea, recited above, includes: a. providing a downloadable application for installation on a mobile device of a cardholder, the downloadable application configured to facilitate payment transactions; b. Receiving, at a merchant's computing system, a request for payment from a remote cardholder, said request comprising transaction details and identification information associated with the remote cardholder; f. Transmitting transaction details, including the confirmation code, from the remote cardholder's mobile device to the merchant's computing system through the secured communication channel; g. Processing the payment transaction at the merchant's computing system using transaction details and confirmation code received from the remote cardholder's mobile device. If a claim limitation, under its broadest reasonable interpretation, covers performance of: 1) fundamental economic principles or practices; 2) commercial interaction including agreements in the form of contracts, but for the recitation of generic computer components, it falls within the Certain Methods of Organizing Human Activity grouping of abstract ideas. Accordingly, the claim recites abstract ideas.
Step 2A Prong 2: Does the claim recite additional elements that integrate the judicial exception into a practical application? MPEP 2106.04.
The recited computing elements (mobile device; central server; payment service provider; etc) are recited at a high-level of generality, i.e. as generic computing element performing generic computer functions such that it amounts to no more than mere instructions to apply the exception using generic computer components (see MPEP 2106.05(f)). Simply adding a general purpose computer or computer components after the fact to an abstract idea does not integrate a judicial exception into a practical application or provide significantly more, since it amounts to no more than a recitation of the words "apply it" (or an equivalent) to implement an abstract idea or other exception on a computer, as set forth in MPEP 2106.05(f).
The additional positive elements are: c. Transmitting a payment request link to the remote cardholder's mobile device, said payment request link configured to initiate the downloadable application and establish a communication link between the remote cardholder's mobile device and the merchant's computing system; d. Receiving, at the merchant's computing system, a confirmation code from the remote cardholder via the downloadable application or through manual entry, said confirmation code serving to verify the identity of the remote cardholder; e. Establishing a secured communication channel between the remote cardholder's mobile device and the merchant's computing system; h. Transmitting a payment confirmation to the remote cardholder's mobile device through the secured communication channel, confirming the successful completion of the payment transaction; wherein the payment transaction is qualified for "card present" rates due to the verification of the remote cardholder's identity through the confirmation code, thereby reducing transaction costs and risks associated with the payment transaction” in claim 1; which amounts to linking the use of the judicial exception to a particular technological environment or field of use – see MPEP 2106.05(h).
Accordingly, these additional claim elements, alone and in combination do not integrate the abstract idea into a practical application, because (1) they do not effect improvements to the functioning of a computer, or to any other technology or technical field (see MPEP 2106.05(a)); (2) they do not apply or use the abstract idea to effect a particular treatment or prophylaxis for a disease or a medical condition (see the Vanda memo); (3) they do not apply the abstract idea with, or by use of, a particular machine (see MPEP 2106.05(b)); (4) they do not effect a transformation or reduction of a particular article to a different state or thing (see MPEP 2106.05(c)); (5) they do not apply or use the abstract idea in some other meaningful way beyond generally linking the use of the identified abstract idea to a particular technological environment, such that the claim as a whole is more than a drafting effort designated to monopolize the exception (see MPEP 2106.05(e) and the Vanda memo). Therefore, per Step 2A, Prong Two, the claim is directed to an abstract idea not integrated into a practical application.
Step 2B (The Inventive Concept): Does the claim recite additional elements that amount to significantly more than the judicial exception? MPEP 2106.05.
Step 2B of the eligibility analysis concludes that the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. Examiner carries over the analysis from Step 2A related to the generic computing elements being no more than a recitation of the words "apply it" (or an equivalent) to implement an abstract idea or other exception on a computer (MPEP 2106.05(f)). The additional claim elements that are just “applying it” or “generally linking the use of the judicial exception to a particular technological environment or field of use” are mere instructions to implement an abstract idea on a computer, are carried over for further analysis in Step 2B.
When the independent claims are considered as a whole, as a combination, the claim elements noted above do not amount to any more than they amount to individually. The operations appear to merely apply the abstract concept to a technical environment in a very general sense. The most significant elements of the claims, that is the elements that really outline the inventive elements of the claims, are set forth in the elements identified as an abstract idea. Therefore, it is concluded that the elements of the independent claims are directed to one or more abstract ideas and do not amount to significantly more. (MPEP 2106.05)
Further, Step 2B of the analysis takes into consideration all dependent claims as well, both individually and as a whole, as a combination:
Claims 2-4 are further directed to additional abstract ideas because the steps performed are simply narrowing the scope of the abstract idea of claim 1 since their individual and combined significance is still not significantly more than the abstract concept at the core of the claimed invention. For example, claim 2 narrowing the scope of claim 1 by associating Apple ID with the merchant’s account; claim 3 narrowing the scope of claim 1 by using OCR techanique to NFC-supported credit card; claim 4 narrowing the scope of claim 1 by incorporating Tap-to-Pay feature; etc, which all of the limitation are narrowing the steps performed in claim 1.
Moreover, the claims in the instant application do not constitute significantly more also because the claims or claim elements only serve to implement the abstract idea using computer components to perform computing functions (Enfish, see MPEP 2106.05(a)). Specifically, the computing system encompasses general purpose hardware and software modules.
The most significant elements of the claims, that is the elements that really outline the inventive elements of the claims, are set forth in the elements identified in the independent claims as an abstract idea. The fact that the associated computing devices are facilitating the abstract concept is not enough to confer statutory subject matter eligibility. In sum, the additional elements do not serve to confer subject matter eligibility to the invention since their individual and combined significance is still not heavier than the abstract concepts at the core of the claimed invention. Therefore, it is concluded that the dependent claims of the instant application do not amount to significantly more either. (see MPEP 2106.05)
In sum, claims 1-4 are rejected under 35 USC 101 as being directed to non-statutory subject matter.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim 1 is rejected under 35 U.S.C. 102(a)(2) as being anticipated by van den Berg et al. (US12079794B2; hereinafter: Berg).
With respect to claim 1
Berg teaches the limitation:
a. Providing a downloadable application for installation on a mobile device of a cardholder, the downloadable application configured to facilitate payment transactions ([0156], If the buyer is not a known user, at step 515 a message may be sent to the buyer's mobile device. The message may request that the buyer download a payment applet, POS application, and/or any other application for making a payment; [0136], The buyer mobile device 210, may be a mobile device, such as a phone or a tablet (such as, but without being limitative a Galaxy™ from Samsung Inc., an iPhone™ or an iPad™ from Apple Inc.) which may be configured to operate a transaction mechanism, such as, but without being limitative, a payment applet and/or point of sale (POS) application which allows the buyer mobile device 210 to operate as a payment device (e.g. payment terminal).;
b. Receiving, at a merchant's computing system, a request for payment from a remote cardholder, said request comprising transaction details and identification information associated with the remote cardholder (see at least [0143].);
c. Transmitting a payment request link to the remote cardholder's mobile device, said payment request link configured to initiate the downloadable application and establish a communication link between the remote cardholder's mobile device and the merchant's computing system ([0145], The communication service 208 may transmit a message (e.g., an SMS message, a notification, an email, etc.) to the buyer mobile device 210. The message may be transmitted based on the mobile phone number and/or any other identifier corresponding to the buyer mobile device 210, such as a device ID or application ID. The message may comprise a hyperlink and/or executable content which may be clicked and/or activated by the buyer after being received by the buyer mobile device 210. In some embodiments, selecting the hyperlink included in the message causes the mobile device 210 to send a request to obtain a payment applet, such as from the server 206….. After receiving the request to obtain the payment applet, the server 206 may transmit and/or remotely install and provision the payment applet on the buyer mobile device 210.);
d. Receiving, at the merchant's computing system, a confirmation code from the remote cardholder via the downloadable application or through manual entry, said confirmation code serving to verify the identity of the remote cardholder ([0139], If a mobile wallet is used, the mobile wallet may generate a token after receiving authorization from the buyer, such as after the buyer enters a passcode and/or completes a biometric authentication. The token may then be transmitted to complete the transaction, such as to the server 206);
e. Establishing a secured communication channel between the remote cardholder's mobile device and the merchant's computing system ([0140], FIG. 4 is a diagram of communications flows between several entities for operating a buyer's device as a payment device in accordance with embodiments of the present technology. FIG. 4 illustrates communication flows between several entities for operating a consumer device as a payment device, such as a POS terminal of the seller, thereby allowing completion of a transaction between a buyer and a seller platform.);
f. Transmitting transaction details, including the confirmation code, from the remote cardholder's mobile device to the merchant's computing system through the secured communication channel ([0171-0172], The token may include payment card data, such as an account number, information identifying the buyer, and/or any other data related to the transaction..….At step 740 the token may be transmitted. The token may be transmitted to the issuer and/or any other entity for processing the transaction.);
g. Processing the payment transaction at the merchant's computing system using transaction details and confirmation code received from the remote cardholder's mobile device ([0172], At step 740 the token may be transmitted. The token may be transmitted to the issuer and/or any other entity for processing the transaction. Steps 745 to 760 are similar to steps 545 to 560 and actions performed at steps 745 to 760 may be similar to those performed at steps 545 to 560.);
h. Transmitting a payment confirmation to the remote cardholder's mobile device through the secured communication channel, confirming the successful completion of the payment transaction ([0149], In some embodiments, after completing a transaction, the issuer 216 may transmit a notification indicating a transaction result to the server 206, the seller platform 204, the buyer mobile device 210, the buyer device 202, and/or any other device associated with the transaction that the transaction has been completed.);
wherein the payment transaction is qualified for “card present” rates due to the verification of the remote cardholder's identity through the confirmation code, thereby reducing transaction costs and risks associated with the payment transaction ([0171-0172], At step 735 the mobile wallet may generate a token. The token may be a payment token. The token may indicate that it corresponds to a CP transaction. The token may include payment card data, such as an account number, information identifying the buyer, and/or any other data related to the transaction. At step 740 the token may be transmitted. The token may be transmitted to the issuer and/or any other entity for processing the transaction. Steps 745 to 760 are similar to steps 545 to 560 and actions performed at steps 745 to 760 may be similar to those performed at steps 545 to 560. If the transaction is approved, the transaction performed by the method 700 may be processed as a CP transaction; see also [0005], The buyer's mobile phone may be configured to act as a payment device of the seller, such as a point of sale (POS) device, terminal device, payment terminal of the seller, etc. This may allow an online or remote transaction between a buyer and a seller to be processed as a CP transaction (and not as CnP transaction) thereby reducing risks of fraud and/or associated processing fees.)
Examiner’s Note (Intended Use): The portion of the limitation which recites “thereby reducing transaction costs and risks associated with the payment transaction” is merely a recited intended use of the verification step. This portion is given little to no patentable weight because the limitation, or portion thereof, does not claim the function(s) as being positively recited actions or functions, and/or it does not add any meaning or purpose to the associated manipulative step(s). See MPEP 2103 C and 2111.04. Simply because the limitation recites something as being “for…. [performing a specific functionality]”, etc. does not mean that the functions are required to be performed, or are actually performed.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over Berg et al. (US12079794B2) in view of Bell et al. (US10783508B1) in view of TapPay (TapPay Enables Tap to Pay on iPhone for Merchants to Accept Contactless Payments; April 26, 2023).
With respect to claim 2
Berg teaches the limitation of claim 1. Berg further teaches:
Providing an onboarding interface within the downloadable application, said onboarding interface configured to receive merchant identification information ([0015-0017], In some implementations of the method, causing the second device to request that the buyer present the payment instrument to the second device comprises causing an applet on the second device to activate……the applet is configured to display a merchant name and a transaction amount corresponding to the transaction.);
d. Transferring the unique Apple ID and associated merchant account data to the merchant's computing system through the secured communication channel ([0027], In some implementations of the method, the application corresponding to the seller activates a payment applet configured to acquire the payment instrument data via an NFC interface of the second device.);
Berg doesn’t explicitly disclose, but Bell teaches:
b. Generating, by a processor, a unique Apple ID dedicated to the merchant based on the received merchant identification information (see col.6 ln43-ln50, To accept card-less payment transactions, the merchant typically creates a merchant account with the payment system by providing information describing the merchant including, for example, a merchant name, contact information, e.g., telephone numbers, the merchant's geographic location address, and one or more financial accounts to which funds collected from users will be deposited.);
c. Associating the unique Apple ID with the merchant's account data within the merchant database maintained by the invention (see col.6 ln43-ln52, To accept card-less payment transactions, the merchant typically creates a merchant account with the payment system by providing information describing the merchant including, for example, a merchant name, contact information, e.g., telephone numbers, the merchant's geographic location address, and one or more financial accounts to which funds collected from users will be deposited. This merchant information can be securely stored by the payment system, for example, in a merchant information database.);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Berg with the teaching of Bell as they relate to a system of processing payment transaction. One of ordinary skill in the art before effective filing date of the claimed invention was made would have modified the system of Berg of using consumer device to acting a payment device to include a method of onboarding merchant account on a point-of-sale terminal in Bell for predictable results of improving the payment process between the merchant and the consumer.
Berg in view of Bell don’t explicitly disclose, but TapPay teaches:
e. Enabling the merchant's computing system to utilize the unique Apple ID for accessing the Tap To Pay feature without requiring the sharing of the merchant's personal Apple ID (Using Tap to Pay on iPhone is easy, secure and private. With Tap to Pay on iPhone in the TapPay app, at checkout, merchants will simply prompt the customer to hold their contactless payment near the merchant's iPhone, and the payment will be securely completed using NFC technology. Tap to Pay on iPhone uses the built-in features of iPhone to keep the business' and customers' data private and secure. When a payment is processed, Apple doesn't store card numbers on the device or on Apple servers.);
wherein the unique Apple ID provides secure access to the Tap To Pay feature and ensures a seamless and efficient onboarding process for merchants, enhancing the overall user experience.
The portion of the limitation which recites “wherein the unique Apple ID provides secure access to the Tap To Pay feature and ensures a seamless and efficient onboarding process for merchants, enhancing the overall user experience.” is merely a recited intended use. This portion is given little to no patentable weight because the limitation, or portion thereof, does not claim the function(s) as being positively recited actions or functions, and/or it does not add any meaning or purpose to the associated manipulative step(s). See MPEP 2103 C and 2111.04. Simply because the limitation recites something as being “for … [performing a specific functionality]”, etc. does not mean that the functions are required to be performed, or are actually performed.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Berg/Bell with the teaching of TapPay as they relate to a system of processing payment transaction. One of ordinary skill in the art before effective filing date of the claimed invention was made would have modified the combined systems of Berg/Bell, for example using consumer device acting as a payment device in Berg, to include a system of enabling Tap-to-Pay feature in TapPay for predictable results of improving the payment process between the merchant and the consumer.
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over Berg et al. (US12079794B2) in view of Singal et al. (US20200334429A1), and further in view of Li et al. (US20190392417A1).
With respect to claim 3
Berg teaches the limitation of claim 1. Berg doesn’t explicitly disclose, but Singal teaches:
Detecting, by the downloadable application executed on the remote cardholder's mobile device or the merchant's computing system, visible indications of NFC support on a physical credit card using Optical Character Recognition (OCR) techniques, said visible indications including recognition of the NFC logo or antenna-related elements (see at least [0021-0022, 0036-0037, and 0058]);
Initiating, upon successful detection of visible indications of NFC support, the mobile NFC card application on the smart device of the remote cardholder or the merchant's computing system (see at least [0070-0071].);
Activating the Near Field Communication (NFC) technology on the smart device to establish a communication link with the physical credit card exhibiting visible indications of NFC support ([0054], FIG. 6 illustrates an environment 600 within which the methods, devices, and systems in which alignment of an NFC enabled mobile device and a NFC enabled document for enabling NFC data communications, in accordance to some embodiments….. The mobile device 610 is a user electronic device that includes a NFC antenna 614 NFC and electronics 614A configured with the capability to connect to and read data from a document configured with passive NFC electronics. The mobile device 610 configured with the capability to read from an passive document 620 is referred to as an active device. This is because the device generates an electro-magnetic field that, when close enough, powers passive NFC electronics 625 on the document 620 through electromagnetic induction and thereby enabling the reading of data off the document 620; [0058], Non-limiting examples of NFC passive documents include driver licenses, identity cards, passports, credit cards, and physical documents that have NFC electronics and antennas embedded within them.);
Reading card data through NFC technology to ascertain compatibility and NFC capabilities of the physical credit card ([0029], FIG. 2 shows a detailed block diagram of the system 200 for ID document verification, in accordance with an example embodiment. The system 200 may include a processor 210, an RFID reader 220, and an optional database 230. The processor 210 may be configured to receive an image associated with an ID document. The image may be captured by the camera associated with the client device. The processor 210 may transmit the image to a remote server. The server processes the image using OCR to detect various zones on the image containing data associated with the ID document and a holder of the ID document and extract printed data from the image. The processor 210 may be further configured to receive the extracted printed data from the server. The RFID reader 220 may use the printed data as a key to access the RFID chip of the ID document. In such a way, the RFID reader 220 may retrieve digital data from the RFID chip. The processor 210 may analyze the digital data and match the digital and printed data to check if they are identical);
The portion of the limitation which recites “to ascertain compatibility and NFC capabilities of the physical credit card” is merely a recited intended use. This portion is given little to no patentable weight because the limitation, or portion thereof, does not claim the function(s) as being positively recited actions or functions, and/or it does not add any meaning or purpose to the associated manipulative step(s). See MPEP 2103 C and 2111.04. Simply because the limitation recites something as being “for … [performing a specific functionality]”, etc. does not mean that the functions are required to be performed, or are actually performed.
f. Utilizing OCR techniques within an automated system to determine NFC capabilities by capturing and analyzing card images or videos, thereby facilitating the identification of NFC-compatible cards; or alternatively g. Employing the Bank Identification Number (BIN) present in the initial six digits of the credit card as an alternative method for NFC detection ([0026], To verify the ID document 140, a user can cause the system 200 capture an image 130 of the ID document 140 by using a camera associated with the client device 120 (smart phone, a notebook, a personal computer (PC), a tablet PC, or the like). An image 130 associated with the ID document 140 may be transmitted to the server 150 either via a mobile application, a stand-alone web application, or via a fully integrated service (XML, i-frame). The image 130 may be captured by a camera associated with the client device 120, e.g. a phone camera, a tablet PC camera, and so forth. The server 150 may receive and analyze the image 130 to recognize printed data associated with the ID document 140 (for example, issue date, holder's name, age, gender, holder's fingerprint, and so forth). Printed data can be recognized by optical character recognition (OCR).);
The portion of the limitation which recites “thereby facilitating the identification of NFC-compatible cards” is merely a recited intended use. This portion is given little to no patentable weight because the limitation, or portion thereof, does not claim the function(s) as being positively recited actions or functions, and/or it does not add any meaning or purpose to the associated manipulative step(s). See MPEP 2103 C and 2111.04. Simply because the limitation recites something as being “for … [performing a specific functionality]”, etc. does not mean that the functions are required to be performed, or are actually performed.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Berg with the teaching of Singal as they relate to a system of reading card/document data using NFC related devices. One of ordinary skill in the art before effective filing date of the claimed invention was made would have modified the system of Berg of using consumer device acting as a payment device to include a system of reading card/document data using NFC related devices for predictable results of improving the payment process between the merchant and the consumer.
Berg in view of Singal do not explicitly disclose, but Li teaches:
h. Performing the BIN-based detection by applying OCR techniques to the captured card image or video or by manually inputting the BIN number by the merchant ([0084], The first terminal recognizes, in the TEE of the first terminal, the bank card account information image by using an OCR algorithm, to obtain the bank card account information.);
i. Enabling the utilization of tap-to-pay functionality upon confirmation of NFC capabilities, providing users with optimal payment methods and enhanced transaction experiences ([0003], Payment applications such as Apple Pay (Apple Pay), Samsung Pay (Samsung Pay), Huawei Pay (Huawei Pay), and Mi Pay (Mi Pay) are payment applications that are jointly developed by a terminal manufacturer and an organization such as a card organization or a card issuer and that are based on an embedded secure element (Embedded Secure Element, eSE) and a Near Field Communication (Near Field Communication, NFC) communications interface in a terminal, and allow a user to bind a physical bank card such as a credit card or a debit card of the user to the terminal, to form a virtual bank card ……After the physical bank card is bound to the terminal to form the virtual bank card, the terminal can be used to tap a card reader of an NFC point of sale (Point of Sale, POS) terminal, where this action is also referred to as “tap Tap”, so that payment through card tapping can be made.)
The portion of the limitation which recites “providing users with optimal payment methods and enhanced transaction experiences” is merely a recited intended use. This portion is given little to no patentable weight because the limitation, or portion thereof, does not claim the function(s) as being positively recited actions or functions, and/or it does not add any meaning or purpose to the associated manipulative step(s). See MPEP 2103 C and 2111.04. Simply because the limitation recites something as being “for … [performing a specific functionality]”, etc. does not mean that the functions are required to be performed, or are actually performed.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Berg/Singal with the teaching of Li as they relate to a system of reading card/document data using NFC related devices. One of ordinary skill in the art before effective filing date of the claimed invention was made would have modified the combined systems of Berg/ Singal, for example using consumer device acting as a payment device in Berg, to include a method of detecting BIN using OCR technique in Li for predictable results of improving the payment process between the merchant and the consumer.
Berg further teaches:
e. Verifying, based on the detected NFC capabilities, whether the transaction qualifies for “card present” rates and initiating the payment transaction using the qualified rate (see [0141-0142].)
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Berg et al. (US12079794B2) in view of Pietra et al. (US20250209442A1) in view of Safak (US20190180275).
With respect to claim 4
Berg teaches the limitation of claim 1. Berg doesn’t explicitly disclose, but Pietra teaches:
a. Operating, when utilizing the Tap to Pay functionality on a smart device, as a data processor on behalf of a payment services provider, executing tasks according to instructions provided by said payment services provider; b. Initiating Tap to Pay via the smart device and launching a virtual payment terminal application, wherein the application gathers essential data necessary for establishing a valid session for transaction processing ([0044], At this point the handheld mobile payment device 1104 is presented to the customer so that the customer can present payment either via mobile wallet 1102 (such as Apple Pay or Google Pay) or via a physical credit card at step 510. A credit card reader 1103 connected to the handheld mobile payment device 1104 may receive credit card information via chip/dip payment or via touchless payment at step 511. The credit card information is passed to an application such as the Outpay Venue App running on the handheld mobile payment device 1104, wherein the credit card information is sent securely, at step 512, to the payment processor 1106 such as Stripe via the payment processor's Software Development Kit (SDK).);
i. Collaborating between the Tap to Pay feature on the smart device and the central server to ensure secure, encrypted, and authenticated transactions, preserving the confidentiality of transaction details through encryption mechanisms ([0044-0045], At step 515, Outpay API 1107 or the POS service creates a request to capture payment which is transmitted back to the payment processor. The request for payment capture can be made immediately when receiving the notice of readiness, or can be processed at a later time such as end of day, in case a refund may need to be processed….If the capture request is successful, the payment processor 1106 notifies the Outpay backend, at step 516, which sends payment to a POS server 1108, thereby updating the POS on the transaction.)
The portion of the limitation which recites “to ensure secure, encrypted, and authenticated transactions, preserving the confidentiality of transaction details through encryption mechanisms” is merely a recited intended use. This portion is given little to no patentable weight because the limitation, or portion thereof, does not claim the function(s) as being positively recited actions or functions, and/or it does not add any meaning or purpose to the associated manipulative step(s). See MPEP 2103 C and 2111.04. Simply because the limitation recites something as being “for … [performing a specific functionality]”, etc. does not mean that the functions are required to be performed, or are actually performed.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Berg with the teaching of Pietra as they relate to a system of managing payment transaction using consumer device. One of ordinary skill in the art before effective filing date of the claimed invention was made would have modified the system of using consumer device acting as a payment device in Berg, to include a method of utilizing Tap to Pay feature on a smart device in Pietra for predictable results of improving the payment process between the merchant and the consumer.
Berg in view of Pietra don’t explicitly disclose, but Safak teaches:
c. Retrieving an encrypted token containing identifiers for the payment services provider and the merchant, along with merchant details and unique virtual payment terminal identifiers, said encrypted token enabling secure session establishment ([0031-0032], Following generation and signing of the cryptographic checksum, the computing device 102 may generate a payment token. The payment token may include at least the account token, data identifying the transaction account, and the transaction amount for the payment transaction. In some cases, the payment token may also include information identifying the consumer 104 and/or an indication of the currency used in the payment transaction. In some embodiments, the payment token may also include information identifying the issuing institution 106, such as an issuer identification number, bank identification number, routing number, or other suitable value that may be used by the point of sale device 108 and/or payment network 110 in identifying the issuing institution 106 during processing of the payment transaction... Once the payment token is generated, the computing device 102 may encrypt the payment token using the account private key.)
The portion of the limitation which recites “said encrypted token enabling secure session establishment” is merely a recited intended use. This portion is given little to no patentable weight because the limitation, or portion thereof, does not claim the function(s) as being positively recited actions or functions, and/or it does not add any meaning or purpose to the associated manipulative step(s). See MPEP 2103 C and 2111.04. Simply because the limitation recites something as being “for … [performing a specific functionality]”, etc. does not mean that the functions are required to be performed, or are actually performed.
d. Gathering a secure hardware token from a central server, indicating the secure hardware status of the smart device ([0035], In other instances, the issuing institution 106 may be able to validate the merchant. In an exemplary embodiment, the data may be included in a transaction message that is submitted to the payment network 110 via payment rails associated therewith, where the transaction message may be formatted pursuant to one or more standards governing the exchange of transaction messages as used in traditional payment transactions, such as the International Organization of Standardization's ISO 8583 or ISO 20022 standards. In these embodiments, the transaction message may include a message type indicator indicative of an authorization request, and may include a plurality of data elements, where one data element is configured to store the encrypted payment token and another data element is configured to store the signed cryptographic checksum.);
e. Validating the secure hardware token on the central server, and upon successful validation, dispatching a session token to the smart device for subsequent transaction execution ([0056], The computing device 102 may also include a validation module 218. The validation module 218 may be configured to validate and verify data for use in performing the functions of the computing device 102 as discussed herein. The validation module 218 may receive data to be validated as input, may attempt to validate the data, and may provide results of the attempt to another module or engine of the computing device 102. For example, the validation module 218 may be configured to validate digital signatures generated by point of sale devices 108, validate digital signatures generated by the computing device 102, validate cryptographic checksums based on transaction orders or data associated therewith, etc; see also [0073], In step 424, the issuing institution 106 may electronically transmit a session code to the computing device 102. The session code may be encrypted by the public key or another suitable key or value for which the computing device 102 possess the corresponding data used for decryption.);
f. Encrypting transaction information on the smart device and transmitting it to the central server for processing, wherein the server retains the encrypted state of the transaction information without decryption ([0076], the wallet server 400 may store data associated with the account token (e.g., the identification data, such as a reference number), but may not be utilized for mapping. In such an example, the issuing institution 106 or a separate entity, such as the payment network 110, token service provider, etc., may performing the mapping. In such cases, the wallet server 400 may be used as an intermediary between the issuing institution 106 and the appropriate entity. For instance, the wallet server 400 may receive the account token and any additional data in step 442, but may forward the relevant data to the token service provider for the storage of mapping data; see also [0074], In step 430, the issuing institution 106 may receive the account token request. In step 432, the issuing institution 106 may generate the account token, which may include any payment credentials suitable for use in an electronic payment transaction, such as a transaction account number, expiration date, security code, name, application cryptograms, application transaction counter, etc. In step 434, the issuing institution 106 may electronically transmit the generated account token to the computing device 102. In some embodiments, the account token may be encrypted, such as by using the same public key or encryption key as the session code, or a separate key, which may, in some cases, be based on the session code.);
g. Authenticating the transaction on the server by utilizing pertinent details including the session token, smart device specifics, and merchant information, while leaving the content of the encrypted transaction intact during authentication ([0070], In step 406, the wallet server 400 may electronically transmit the account data (e.g., and authorization data, if applicable) to the issuing institution 106 using a suitable communication method in a request for account details. In step 408, the issuing institution 106 may receive the request. In step 410, the issuing institution 106 may identify the transaction account using the account identifier, and, if applicable, authenticate the consumer 104 using the authentication data, and identify account information associated with the transaction account.);
h. Introducing an additional layer of transaction security by altering the encryption key with a key decryptable only by an authorized payment services partner, enhancing the security of the transaction ([0036], The payment network 110 may receive the transaction message for the electronic payment transaction. The encrypted payment token may be decrypted by the payment network 110, issuing institution 106, or another trusted entity, such as the token service provider. For instance, the system 100 may include a trusted service manager that may be configured to store account public keys for provisioning to point of sale devices 108 and use in decrypting encrypted payment tokens. In such embodiments, the payment network 110 may forward the transaction message to the trusted service manager, which may decrypt the encrypted payment token and then forward the transaction message, with the payment token decrypted, to the issuing institution 106 (e.g., identified via the identification data in the now-decrypted payment token). In other embodiments, the trusted service manager may decrypt the payment token and return the decrypted payment token to the payment network 110, which may then forward the transaction message, with the now-decrypted payment token, to the appropriate issuing institution 106. In some embodiments, the account token included in the decrypted payment token may be mapped to the corresponding transaction account payment credentials by the payment network 110, the trusted service manager, or a third party system configured to perform such functions.);
The portion of the limitation which recites “enhancing the security of the transaction” is merely a recited intended use. This portion is given little to no patentable weight because the limitation, or portion thereof, does not claim the function(s) as being positively recited actions or functions, and/or it does not add any meaning or purpose to the associated manipulative step(s). See MPEP 2103 C and 2111.04. Simply because the limitation recites something as being “for … [performing a specific functionality]”, etc. does not mean that the functions are required to be performed, or are actually performed.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Berg/ Pietra with the teaching of Safak as they relate to a system of managing payment transaction using consumer device. One of ordinary skill in the art before effective filing date of the claimed invention was made would have modified the combined systems of Berg/ Pietra, for example using consumer device acting as a payment device in Berg, to include a method of generating various types of encrypted token for processing transaction as taught in in Safak for predictable results of improving the payment process between the merchant and the consumer.
Conclusion
THIS ACTION IS MADE Non-FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to YIN Y CHOI whose telephone number is (571)272-1094 or yin.choi@uspto.gov. The examiner can normally be reached on M-F 7:30 - 5:30pm EST.
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, Neha Patel can be reached on 571-270-1492. 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.
/YIN Y CHOI/Examiner, Art Unit 3699 3/20/2026
/NEHA PATEL/Supervisory Patent Examiner, Art Unit 3699