DETAILED ACTION
Status of Claims
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This action is in reply to the amendment filed on 02/19/2026.
Claims 1, 11, and 19 have been amended.
Claims 1-20 are currently pending and have been examined.
Response to Arguments
Applicant's arguments filed 02/19/2026 with respect to the 101 and 103 rejections have been fully considered but they are not persuasive. With respect to 103, applicant argues that none of the references of record disclose "converting, by the indicia-based payment server, information associated with the transaction into a concealment token; [and] transmitting, by the indicia-based payment server, the concealment token to the merchant device, wherein the concealment token conceals a payment source associated with the transaction from the merchant device,", the Examiner respectfully disagrees. Chitalia discloses these features in at least [0030], [0034-0035], [0048], [0078], [0086] (with support in [0005], [0028-0030], and [0040] of the provisional), where Chitalia disclose generating a payment token, which conceals the account data, and sending token to the resource device (i.e. merchant) for use in completing the transaction.
With respect to 101 Applicant argues #1:
Under the two-step framework set forth in Alice Corp. v. CLS Bank International, 573 U.S. 208 (2014), a claim is first analyzed to determine whether it is directed to a judicial exception such as an abstract idea (Step 2A), and if so, whether the claim recites additional elements that amount to significantly more than the judicial exception (Step 2B). Under the USPTO's 2019 Revised Patent Subject Matter Eligibility Guidance, Step 2A is divided into two prongs: Prong One asks whether the claim recites a judicial exception, and Prong Two asks whether any judicial exception is integrated into a practical application. As noted in the USPTO's "Reminders on evaluating subject matter eligibility of claims under 35 U.S.C. 101 (August 4, 2025)," claims must be evaluated under the Alice/Mayo framework with careful attention to the specific claim limitations and their technical character. Additionally, consistent with the "Advance notice of change to the MPEP in light of Ex Parte Desjardins (December 5, 2025)," the analysis should consider whether the claimed invention provides a technical solution to a technical problem.
Applicant submits that the claims, as amended, are not directed to an abstract idea and, even if they were, the claims integrate any alleged abstract idea into a practical application and recite significantly more than the alleged abstract idea.
The Office Action has alleged that the claims are directed to commercial or legal interactions for processing a transaction. Independent claims 1, 11, and 19 now recite "converting, by the indicia-based payment server, information associated with the transaction into a concealment token; [and] transmitting, by the indicia-based payment server, the concealment token to the merchant device, wherein the concealment token conceals a payment source associated with the transaction from the merchant device." These limitations are not abstract concepts, but rather specific technical operations performed by the indicia-based payment server to achieve a concrete technical result.
The amendments explicitly claim the conversion of account information into a concealment token and the transmission of that token to conceal sensitive payment details from the merchant device. This is not merely claiming the idea of a solution but rather reciting a specific technical implementation that achieves the disclosed improvement.
Under Step 2A, Prong Two, a claim that integrates a judicial exception into a practical application will apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception. The 2019 Guidance identifies several considerations indicative of integration into a practical application, including whether an additional element reflects an improvement in the functioning of a computer or an improvement to other technology or technical field.
Applicant submits that the claims as amended reflect an improvement to the technical field of payment processing. The specification explains that conventional payment systems require merchants to receive and handle sensitive user account information, creating security vulnerabilities and requiring merchants to update their backend systems to handle such information securely. As described in paragraph [0045] of the as-filed specification, the claimed system addresses these technical problems by converting information into concealment tokens that conceal the underlying payment source from the merchant. This technical solution allows merchants to process transactions without ever receiving sensitive user information, thereby improving the security of the payment processing system and eliminating the need for merchants to update their backend systems to handle sensitive data.
The claims do not merely recite the abstract idea of processing a transaction, but instead recite a specific technical architecture in which an indicia-based payment server generates indicia for display at a merchant device, receives authorization after the indicia is scanned and the transaction is authorized by the user, converts account information into a concealment token, and transmits that token to the merchant device to conceal sensitive information. This ordered combination of technical steps achieves a specific technical improvement that is rooted in computer technology. This ordered combination of technical steps achieves a specific technical improvement that is rooted in computer technology.
Examiners response:
The Examiner respectfully disagrees, converting information into concealment tokens and sending the merchant the concealment token to use in a transaction, alone and in combination with the argued steps is not a technical improvement, rather part of the abstract idea, with the idea being limited to the computer environment. Additionally, the prior art shows tokenization of payment cards is common practice with the known benefit of protecting real payment card data by not allowing it to be exposed to the merchants, as evident by NPL Upbin, Tokenization And The Collapse Of The Credit Card Payment Model, which states:
In the real world, the concept of a token generally refers to the act of substituting something simple and convenient for something more cumbersome or complicated. Think of the utility of a subway token in preference to cash, or (as in Monopoly), how much easier it is to move a game piece around a board than your physical self. In the payments world, tokens have traditionally been used to enhance information security. Tokenization* is a system where you substitute a proxy set of identifying information for the real payment card data, so that merchants don’t have to handle this sensitive and regulated data and it isn’t exposed more than necessary.
For this reason, the Examiner is not persuaded and the claims are not indicative of an improvement to technology.
With respect to 101 Applicant argues #2:
The present claims may be analogous to Examples 40 and 41 from the USPTO's Subject Matter Eligibility Examples. Example 40 (Adaptive Monitoring of Network Traffic Data) was found patent eligible because the claims recited a specific technical solution to a technical problem in network monitoring, where the claimed method improved the functioning of the computer system by adapting monitoring based on collected data. Similarly, Example 41 (Cryptographic Communications) was found patent eligible because the claims recited specific technical steps for establishing a secure communication channel that addressed technical problems in data security. Like Examples 40 and 41, the present claims recite a specific technical solution (i.e., the conversion of account information into a concealment token and transmission to the merchant device) that addresses a technical problem in payment processing systems, namely the security vulnerabilities associated with merchants handling sensitive payment information. The claimed tokenization and transmission operations provide a technical improvement to the security of payment processing systems in a manner comparable to the cryptographic techniques found eligible in Example 41.
In Digitech Image Technologies, the claims were directed to organizing information into a new form without any particular application of that information. Here, the claims recite specific technical operations including the conversion of account information into a concealment token and the transmission of that token to a merchant device to conceal payment details. These are not mere data manipulation steps but rather security-enhancing technical operations that produce a tangible technical benefit in the payment processing system.
Even assuming arguendo that the claims recite an abstract idea, the claims satisfy Step 2B because they recite significantly more than any alleged abstract idea. The specific combination of generating indicia configured to prevent sharing of payment source or account details with the merchant, converting account information into a concealment token, and transmitting that token to the merchant device to conceal sensitive information represents a specific technical implementation that is not well- understood, routine, or conventional in the field.
Examiners response:
Examiner respectfully disagrees, in Example 40 of the PEG, the invention varied the amount of network traffic based on monitored events in the network by only collecting data when an abnormal condition was detected, specifically, the method limits collection of additional Netflow protocol data to when the initially collected data reflects an abnormal condition, which avoids excess traffic volume on the network and hindrance of network performance, providing a specific improvement over prior systems, resulting in improved network monitoring. The Applicant's invention does not monitor network traffic or limit data collecting based upon an abnormality or result in an improvement to the network itself, rather the system is directed towards commercial or legal interactions for completing a transaction using a scannable indicia and concealment token being limited to the computer environment.
With respect to Example 41, the claims were found eligible because the combination of additional elements use of the mathematical formulas and calculations in a specific manner sufficiently limits the use of the mathematical concepts to the practical application of transmitting the ciphertext word signal to a computer terminal over a communication channel creating a process that secures private network communications, so that a ciphertext word signal can be transmitted between computers of people who do not know each other or who have not shared a private key between them in advance of the message being transmitted, where the security of the cipher relies on the difficulty of factoring large integers by computers. Here the claims do not integrate the concepts into a practical application, as with respect to the use of a concealment token, this is WURC as evident and shown above the NPL to Upbin. For the same reasons as discussed above, the claims fail to amount to significantly more under Step 2B, additionally, further MPEP 2106.05(d)(ii) provides that receiving and transmitting data over a network (see buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network), and Electronic recordkeeping, Alice Corp. Pty. Ltd. v. CLS Bank Int'l, 573 U.S. 208, 225, 110 USPQ2d 1984 (2014) (creating and maintaining "shadow accounts"); Ultramercial, 772 F.3d at 716, 112 USPQ2d at 1755 (updating an activity log); are well-understood routine and conventional, similar to the instant application claims which recites and sending and receiving data over network, for processing a transaction using an indicia and a concealment token.
For the reasons above, applicant’s arguments are not persuasive.
Claim Interpretation
In the independent claims, the clause “configured for display at a merchant device of a merchant” and “transmitting… the indicia to be displayed” is interpreted as an intended use/field of use of the indicia, as the displaying of the indicia is not positively recited. The intended use language in the claim merely states the result of the limitation in the claim and adds nothing to the patentability or substance of the claim. See Texas Instruments Inc. v. International Trade Commission, 26 USPQ2d 1010 (Fed. Cir 1993); Griffin v. Bertina, 62 USPQ2d 1431 (Fed. Cir. 22); Amazon.com Inc. v. Bamesandnoble.com Inc., 57 USPQ2d 1747 (Fed. Cir. 21). Hence the intended use limitations are not given patentable weight.
Claims 2, 13, and 20 recite “enabling the scanning…” and “enabling opening…”. With respect to the “enabling” language in the claims, the Merriam-Webster dictionary defines enable as:
a: to provide with the means or opportunity
training that enables people to earn a living
b: to make possible, practical, or easy
a deal that would enable passage of a new law
c: to cause to operate
software that enables the keyboard
The Examiner will interpret enabling similar to definitions as discussed above, as providing a means/opportunity/make possible and not give weight to the scanning or opening steps in the claims 2, 13, and 20 as the scanning and opening are not positively recited, rather the system merely is enabled in that this step could occur, but is not necessarily performed.
In general, the grammar and intended meaning of terms used in a claim will dictate whether the language limits the claim scope. Language that suggests or makes optional but does not require steps to be performed or does not limit a claim to a particular structure does not limit the scope of a claim or claim limitation. The following are examples of language that may raise a question as to the limiting effect of the language in a claim:
statements of intended use or field of use,
"adapted to" or "adapted for" clauses,
"wherein" clauses, or
"whereby" clauses.
This list of examples is not intended to be exhaustive. See also MPEP § 2111.04.
The rejections given below are interpreted in light of 35 U.S.C. § 112, rejections and the claim interpretation discussed above.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more, and fails step 2 of the analysis because the focus of the claims is not on the devices themselves or a practical application but rather directed towards an abstract idea, the analysis is provided below.
Step 1 (Statutory Categories) - The claims pass step 1 of the subject matter eligibility test (see MPEP 2106(III)) as the claims are directed towards a system, method and non-transitory machine-readable medium.
Step 2A – Prong One (Do the claims recite an abstract idea?) - The idea is recited in the claims, in part, by:
generating indicia configured for display at a merchant;
transmitting the indicia to be displayed;
receiving, subsequent to (i) the indicia being scanned by the first user, and (ii) the transaction being authorized by the first user, an authorization from the merchant to process the transaction;
converting information associated with the transaction into a concealment token;
transmitting the concealment token to the merchant, wherein the concealment token conceals a payment source associated with the transaction from the merchant; and
processing the transaction.
The steps recited above under Step 2A Prong One of the analysis under the broadest reasonable interpretation covers commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations) but for the recitation of generic computer components. That is other than reciting an indicia-based payment server, a merchant device, first user device, an application, an application programming interface, one or more data storage devices, and one or more processors, nothing in the claim elements are directed towards anything other than commercial or legal interactions for completing a transaction using a scannable indicia and concealment token. If a claim limitation, under its broadest reasonable interpretation, covers commercial or legal interactions, then it falls within the “Certain Methods of Organizing Human Activities” groupings of abstract ideas. Accordingly, the claims recite an abstract idea.
Step 2A – Prong Two (Does the claim recite additional elements that integrate the judicial exception into a practical application?) - This judicial exception is not integrated into a practical application. In particular, the claims only recite the additional elements of an indicia-based payment server, a merchant device, first user device, an application, an application programming interface, one or more data storage devices, and one or more processors. The indicia-based payment server, merchant device, first user device, application, application programming interface, one or more data storage devices, and one or more processors are recited at a high level of generality such that it amounts to no more than mere instructions to apply the exception using generic computer components and limits the judicial exception to the particular environment of mobile computers. The indicia is described in [0057] as “The indicia may be one or more of a one-dimensional bar code, a two-dimensional bar code (e.g., a QR code), or any machine readable design that may facilitate the relaying of transaction information to a mobile device using a scanner of the user mobile device.”, the generating of the indicia is akin to organizing information and manipulating information through mathematical correlations, Digitech Image Techs., LLC v. Electronics for Imaging, Inc., 758 F.3d 1344, 1350, 111 USPQ2d 1717, 1721 (Fed. Cir. 2014) where the patentee in Digitech claimed methods of generating first and second data by taking existing information, manipulating the data using mathematical functions, and organizing this information into a new form, as is here with the new form being an indicia which is used by the user to extract information (see also An application program interface for extracting and processing information from a diversity of types of hard copy documents – Content Extraction, 776 F.3d at 1345, 113 USPQ2d at 1356, which is found to be ineligible). Mere instructions to apply the judicial exception using generic computer components and limiting the judicial exception to a particular environment are not indicative of a practical application (see MPEP 20106.05(f) and MPEP 20106.05(h)). With respect to “configured for display at a merchant device of a merchant”, and “transmitting… the indicia to be displayed” this is directed towards the intended use of the indicia and attempting to claim the idea of the solution, and as per MPEP 2106.05(a) “An important consideration in determining whether a claim improves technology is the extent to which the claim covers a particular solution to a problem or a particular way to achieve a desired outcome, as opposed to merely claiming the idea of a solution or outcome. McRO, 837 F.3d at 1314-15, 120 USPQ2d at 1102-03; DDR Holdings, 773 F.3d at 1259, 113 USPQ2d at 1107.,” see also Internet Patents Corporation v. Active Network, Inc., 790 F.3d 1343, 1348, 115 USPQ2d 1414, 1418 (Fed. Cir. 2015) (The recitation of maintaining the state of data in an online form without restriction on how the state is maintained and with no description of the mechanism for maintaining the state describes "the effect or result dissociated from any method by which maintaining the state is accomplished" and does not provide a meaningful limitation because it merely states that the abstract idea should be applied to achieve a desired result. Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claims are directed towards an abstract idea.
Step 2B (Does the claim recite additional elements that amount to significantly more than the judicial exception?) - The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, as discussed above, with respect to integration of the abstract idea into a practical application, using the additional elements of the indicia-based payment server, merchant device, first user device, application, application programming interface, one or more data storage devices, and one or more processors to perform the steps recited in Step 2A Prong One of the analysis amounts to no more than mere instructions to apply the exception using generic computer components and limits the judicial exception to the particular environment. Mere instructions to apply an exception using generic computer components and limiting the judicial exception to a particular environment does not provide an inventive concept. The additional elements have been considered separately, and as an ordered combination, and do not add significantly more (also known as an “inventive concept”) to the judicial exception. Further, MPEP 2106.05(d)(ii) provides that receiving and transmitting data over a network (see buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network), and Electronic recordkeeping, Alice Corp. Pty. Ltd. v. CLS Bank Int'l, 573 U.S. 208, 225, 110 USPQ2d 1984 (2014) (creating and maintaining "shadow accounts"); Ultramercial, 772 F.3d at 716, 112 USPQ2d at 1755 (updating an activity log); are well-understood routine and conventional, similar to the instant application claims which recites and sending and receiving data over network, for processing a transaction using an indicia and a concealment token. Further, the displaying step falls to transform the claims into patent eligible material, as this is part of the field of use and technical environment in which the abstract idea is being implement and does not result in an improvement to additional elements (see MPEP 2106.05(h) Electric Power Group court decision). The claims are not patent eligible.
The dependent claims have been given the full analysis including analyzing the additional limitations both individually and in combination as a whole. For instance, claims 2 is worded in such a way the claims are reciting the desired outcomes (see MPEP 2106.05(f)), as claim 2 recites “enabling” the scanning and opening of the indicia and a mobile app, which is also part of the technical environment. Claim 3 further describe the abstract idea and environment in which the idea is being limited to, falling within the “Certain Methods of Organizing Human Activities” groupings of abstract ideas. Claims 4-10, and 12 further describe abstract steps being limited the particular environment. The Dependent claims when analyzed both individually and in combination are also held to be patent ineligible under 35 U.S.C. 101 for the same reasoning as above and the additional recited limitations fail to establish that the claims are not directed to an abstract idea. The additional limitations of the dependent claims when considered individually and as an ordered combination do not amount to significantly more than the abstract idea.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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 1-8, 10-16, and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Laracey (US Patent Application Publication 20130238455), “Laracey” in view of Phillips, et al. (US Patent Application Publication 20160155112), “Phillips” in view of Lyons, et al. (US Patent Application Publication 20120130889), “Lyons” in view of Chitalia, et al. (US Patent Application Publication 20170236113), “Chitalia”.
As per claim 1, 11, and 19, Laracey discloses:
A computer- implemented method comprising: [0021]
generating, by an indicia-based payment server, indicia configured for display at a merchant device of a merchant; [0041-0044], [0055], [0092] For example, the checkout token may be looked up from a table associating a merchant ID (received at 408) with a static checkout token. In some embodiments, the checkout token could be generated by the transaction management system 230 when it receives the merchant payment authorization request at 408, and then the checkout token would be passed back to the merchant system 209 as part of the acknowledgement of the merchant payment authorization request... For example, a customer may operate mobile device 202 to take a digital picture or capture the image of a checkout token 210 displayed on or at a merchant point of sale device to initiate a payment transaction using the present invention. The captured image is shown as item 237 on the display screen 236. As will be described further below, the checkout token 210 may be used to initiate and conduct transactions with a merchant… For example, in some embodiments, some or all of the transaction details may be encoded in a dynamic checkout token which, when captured and processed by the mobile device 102, provides the transaction details to the mobile device 102
transmitting, by the indicia-based payment server, the indicia to be displayed; [0041-0044], [0055], [0092] For example, the checkout token may be looked up from a table associating a merchant ID (received at 408) with a static checkout token. In some embodiments, the checkout token could be generated by the transaction management system 230 when it receives the merchant payment authorization request at 408, and then the checkout token would be passed back to the merchant system 209 as part of the acknowledgement of the merchant payment authorization request...
processing, by the indicia-based payment server, the transaction. [0067] Once the final confirmation to proceed with the payment has been received from the customer's mobile device 202, the transaction management system 230 creates an authorization approval request message for transmission through one or more payment processing network(s) 232 to cause the authorization, clearing and settlement of funds for the transaction.
While Laracey, discloses the user opening the app, and then scanning the QR code to extract the information, and further discloses receiving an authorization request from the merchant ([0095-0097], [0106], [0117-0119]), Laracey however does not expressly disclose that that the app was opened in response to the indicia being scanned by the first user device, Phillips, however does disclose this feature as shown in fig. 1, [0035-0037], [0105] The QR code contains information that supports a payment transaction via the cardholder's mobile device. The cardholder uses the camera of the mobile device to scan the QR code on the bill. The scanning of the QR code launches a mobile payment application on the mobile device. The cardholder swipes his/her thumb on the mobile device to verify himself/herself and to confirm that the bill payment transaction is to proceed. A process like that shown in FIG. 1 ensues, leading to a payment via a payment system to the entity that tendered the bill to the cardholder… In some embodiments, the payment gateway 210 is identified to the mobile device 202 during communication between the mobile device 202 and the merchant 206 (e.g., the merchant 206 may provide information identifying a specific gateway to be used for the transaction during interaction “1”)… A third interaction (labeled as item “3”) occurs between the payment gateway 210 and the merchant 206 in which the gateway 210 uses the merchant identifier (obtained from the transaction payload data) to determine which merchant the transaction originated from. The payment gateway 210 then connects to the appropriate merchant 206 and provides a “Basket ID” for the transaction (where the Basket ID is obtained from the transaction payload created in interaction “1”)… A fourth interaction (labeled as item “4”) occurs between the merchant 206 and the payment gateway 210, where the merchant 206 validates the basket ID received in message or interaction “3”, and uses the basket ID to lookup details of the transaction. The transaction details are then returned to the payment gateway 210 and may include, for example, the basket ID, a transaction amount, the relevant currency, etc. At this point in the transaction flow, the payment gateway 210 has information associated with the pending transaction, including the basket ID, the transaction details (including, for example, the transaction amount) and the transaction payload.
It would have been obvious to one having ordinary skill in the art at the time the invention was filed to modify Laracey with the ability to have the scanning of the QR launch the mobile payment as taught by Phillips, doing so allows the app to be launched when the QR code is scanned, as opposed to having to open the app first [0105].
While Laracey discloses the user scanning and authorizing transaction and the merchant being able to send an update authorization request message after the checkout code is scanned (see [0038, 55, 61-66, 78-79, 100-103]), under a narrow interpretation it could be argued Laracey does not expressly the following, Lyons, however discloses:
receiving, by the indicia-based payment server, subsequent to (i) the indicia being scanned by the first user device, and (ii) the transaction being authorized, from the first user device to the indicia-based payment server, on an application, of the first user device, an authorization from the merchant device of the merchant to process the transaction; and see figs 6A and 6B, [0091-0092], [0127] where the Examiner interprets the user choosing a funding source at step 618, after scanning the QR code in step 624 to read on authorizing from the user the transaction, and subsequently the merchant can send a request to close a tab, akin to authorization to process the transaction at step 648 At block 614, the patron 10 of the establishment (e.g., bar) may use the payer device 10A to scan the pay code printed on the open receipt to extract the pay code data. At block 616, the pay code data may be stored on the payer device 10A… At block 618, the patron 10 of the establishment may select a funding source using the payer device 10A. At block 632, the pay code server 50 may receive the funding details and, at block 644, the pay code server may approve (e.g., pre-approve) the electronic transaction and may notify the patron 10, the merchant 40, and/or the POS 40A… At block 648, the POS 40A can send a request to close a tab, and send the updated details to the pay code server 50. At block 650, the transaction details may be updated in the pay code server 50 and may, based on a request from the payer device 10A, send the updated transaction details to the payer device 10A… the user can scan a pay code on the poster using the payment application on their mobile device without network connectivity.
It would have been obvious to one having ordinary skill in the art at the time the invention was filed to modify Laracey with the ability to track a bill and allow a merchant to update the transaction total after the user has scanned QR code for the transaction and chosen a funding account as taught by Lyons, doing so further allows the transaction details to be updated prior to completing the order [0091-0093].
Additionally, Laracey does not expressly disclose the following, Chitalia, however discloses:
converting, by the indicia-based payment server, information associated with the transaction into a concealment token; [0030], [0034-0035], [0048], [0078], [0086] (with support in [0005], [0028-0030], and [0040] of the provisional) In some embodiments, the token may be generated on the fly using API calls. For example, when a request is received to tokenize an account identifier or other sensitive information, token generation module 512 may determine a token range to assign the token… The code may be, for example, a QR code …In some embodiments, a token may be used in place of a PAN to initiate, authorize, settle or resolve a payment transaction.
transmitting, by the indicia-based payment server, the concealment token to the merchant device, wherein the concealment token conceals a payment source associated with the transaction from the merchant device; and [0030], [0034-0035], [0048], [0078], [0086] (with support in [0005], [0028-0030], and [0040] of the provisional) In some embodiments, token exchange can be achieved via a transactional message, such as an ISO message, an application programming interface (API), or another type of web interface (e.g., web request)… A “resource provider” may be an entity that can provide a resource such as goods, services, information, and/or access. Examples of a resource provider include merchants, access devices, secure data access points, etc… At step S152, the resource provider computer 25 may send a request for the token for the transaction to token server 30. The request may include identifying transaction data, such as the transaction identifier previously provided to the token server 30 by the application provider computer 40. At step S154, the token server 30 may retrieve the token associated with the identifying transaction data, and provide it to the resource provider computer 25… In some embodiments, the token may be generated on the fly using API calls. For example, when a request is received to tokenize an account identifier or other sensitive information, token generation module 512 may determine a token range to assign the token… The code may be, for example, a QR code. The consumer may scan the code with his or her communication device using a camera or other visual sensor associated with the communication device. The code may be interpreted by an application on the communication device and the transaction data may be displayed to the consumer in one embodiment. The consumer may request a token at the communication device that corresponds to a payment device selected to perform the payment transaction. The token, the transaction data, and the consumer's location may be provided to an application provider computer. The application provider computer may facilitate completion of the transaction between the consumer and the merchant using the transaction data and the token, if the consumer's location is within a predetermined threshold distance of the merchant's location, as described further herein…In some embodiments, a token may be used in place of a PAN to initiate, authorize, settle or resolve a payment transaction.
It would have been obvious to one having ordinary skill in the art at the time the invention was filed to modify Laracey with the ability to generate a token concealing private payment information for completing the transaction as taught by Chitalia, doing so further protects the payment information by tokenization the information [0034-0035].
As per claim 2, 13, and 20, Laracey discloses:
subsequent to transmitting the indicia to be displayed: enabling the scanning of the display of the indicia, by the first user device, to extract information related to payment preferences of a user; and [0041-0043], [0126],[0176-0177] For example, in some embodiments, some or all of the transaction details may be encoded in a dynamic checkout token which, when captured and processed by the mobile device 102, provides the transaction details to the mobile device 102... The system uses the token to match Jane's request with information sent from Starbucks about the transaction, and also uses it to retrieve a subset of Jane's available payment accounts that are appropriate for use in making this particular purchase. The list of available payment accounts may be retrieved by the payment application on Jane's mobile device communicating with the remote transaction management system (e.g., by causing the transaction management system to look up the list of payment accounts Jane has registered, and to look up and apply any relevant rules or preferences). In this case, Jane has indicated a preference that her Starbucks gift card be used whenever possible… Referring now to FIG. 8B, a further user interface is shown, again on a display device 836 of a mobile device 802. In the user interface of FIG. 8B, the user has captured the checkout token or QR code (e.g., using the screen of FIG. 8A), and has received a response message from a transaction management system (such as the system 230 of FIG. 2) with details of the payment transaction that the customer is about to complete. In particular, the transaction management system has returned detailed transaction information about the purchase transaction, including merchant information and the purchase amount (shown as item 842). The user interface also shows the customer a number of available payment options 844a-n. The available payment options 844a-n may be shown in the order of preference or desirability based on, for example, customer preferences or rules established by the customer (e.g., pursuant to the process described above in conjunction with FIG. 3 or the like), by the merchant, or by the payment system operator. For example, as shown, a private label credit card is displayed as the first (or top-most) payment account 844a. Information about each of the payment accounts 844 may be displayed, including the current available balance as well as any reward, loyalty or other benefits associated with using that particular payment account in the current transaction.
enabling opening, by the first user device, of the application with the information related to the payment preferences of the user. [0176-0177] The display of the mobile device 802 also includes a number of buttons or icons 840, 842 which allow the customer to perform functions associated with the payment system of the present invention. For example, as depicted, the customer may choose to reset 840 the capturing of the checkout code (e.g., in the event that the code was not properly captured or read) or the customer may select among other choices 842 including to clip or view special offers associated with the merchant location where the customer is currently shopping, view different payment accounts and related information, pay (which is shown as the currently selected option) or view more options.
As per claim 3, and 14, Laracey discloses:
wherein the indicia is displayed on a user interface of the merchant device that is different from the first user device, and wherein the display of the indicia is scanned by the first user device. [0040], [0096] After a successful authentication process, the customer is prompted to scan, capture (or otherwise enter) a checkout token from a device associated with the merchant 108 (shown as interaction 112 between the mobile device 102 and the merchant 108)… In either embodiment, the checkout token 210 is displayed for scanning, capture or other entry by a customer using their mobile device 202
As per claim 4, and 15, Laracey discloses:
receiving a desired payment source to be used for the transaction. [0103] After the merchant calculates the transaction total, the merchant transmits the total in an updated merchant payment authorization request message to the transaction management system 230. The system 230 uses this information to update the pending transaction record and then causes a message to be transmitted to the mobile device 202 to update the mobile device 202 with the total amount due (and may also include information about a list of available payment accounts that may be used in the transaction). The mobile device 202 may be updated to display the total as well as any loyalty savings (if any were earned in the transaction) as well as the list of available payment accounts. The customer then selects her desired payment account(s) to complete the transaction as normal. Those skilled in the art will appreciate that other modifications may be made to some or all of the processes shown herein to achieve different transaction flows.
As per claim 5, and 16, Laracey discloses:
subsequent to the indicia being scanned by the first user device: displaying, on a user interface of the first user device, information related to the desired payment source. [0102-0103] The transaction management system 230 creates a pending transaction record and transmits a checkout token to the merchant. The merchant then causes the checkout token to be displayed or presented to the customer. For example, it may be displayed to the customer on a display screen of a point of sale terminal while she is waiting for the transaction to be totaled. The customer then captures the checkout token using her mobile device 202…After the merchant calculates the transaction total, the merchant transmits the total in an updated merchant payment authorization request message to the transaction management system 230. The system 230 uses this information to update the pending transaction record and then causes a message to be transmitted to the mobile device 202 to update the mobile device 202 with the total amount due (and may also include information about a list of available payment accounts that may be used in the transaction). The mobile device 202 may be updated to display the total as well as any loyalty savings (if any were earned in the transaction) as well as the list of available payment accounts. The customer then selects her desired payment account(s) to complete the transaction as normal. Those skilled in the art will appreciate that other modifications may be made to some or all of the processes shown herein to achieve different transaction flows.
As per claim 6, Laracey does not expressly the following, Phillips, however discloses:
prior to receiving the authorization to process the transaction: authenticating the transaction using biometric data. [0103-0105] In this use-case, a cardholder has received a paper invoice, such as a utility bill. A QR code is included in the printed material on the bill. The QR code contains information that supports a payment transaction via the cardholder's mobile device. The cardholder uses the camera of the mobile device to scan the QR code on the bill. The scanning of the QR code launches a mobile payment application on the mobile device. The cardholder swipes his/her thumb on the mobile device to verify himself/herself and to confirm that the bill payment transaction is to proceed
It would have been obvious to one having ordinary skill in the art at the time the invention was filed to modify Laracey with the ability to have the ability to require the user to swipe their thumb to verify themselves and confirm the transaction to process as taught by Phillips, doing so allows for biometric-based cardholder verification to be used [0103-0105].
As per claim 7, Laracey discloses:
wherein the indicia further encodes transaction information including one or more of: an identification of a merchant or merchant group; an identification of a good or service; a quantity of each good or service; a type or category that a good or service belongs to; a method of delivery for a good; a date and time of arrival or shipment for a good or service; or a date and/or time of a purchase. [0041-0043] For example, in some embodiments, some or all of the transaction details may be encoded in a dynamic checkout token which, when captured and processed by the mobile device 102, provides the transaction details to the mobile device 102… The information from the transaction detail message provides the customer with details about the transaction, including but not limited to the amount due, the name and location of the merchant (information contained in or derived from the merchant payment authorization request), and possibly one or more marketing messages.
As per claim 8, Laracey discloses:
wherein the indicia further encodes transaction information including one or more of: a cost of a good and/or service; a cumulative cost of goods and/or services; any one or more of service fees, gratuity fees, taxes, or conversion fees, a total cost reflecting the addition of any one or more of service fees, gratuity fees, taxes, conversion fees, or shipping related fees; or a selection of a currency and/or mode of payment to be used for the transaction. [0041-0043] For example, in some embodiments, some or all of the transaction details may be encoded in a dynamic checkout token which, when captured and processed by the mobile device 102, provides the transaction details to the mobile device 102… The information from the transaction detail message provides the customer with details about the transaction, including but not limited to the amount due, the name and location of the merchant (information contained in or derived from the merchant payment authorization request), and possibly one or more marketing messages.
As per claim 9, and 17, Laracey does not expressly disclose the following, Chitalia, however discloses:
generating and transmitting a token indicating the authorization of the transaction using an application programming interface. [0030], [0034-0035], [0048], [0078], [0086] (with support in [0005], [0028-0030], and [0040] of the provisional) In some embodiments, token exchange can be achieved via a transactional message, such as an ISO message, an application programming interface (API), or another type of web interface (e.g., web request)… A “resource provider” may be an entity that can provide a resource such as goods, services, information, and/or access. Examples of a resource provider include merchants, access devices, secure data access points, etc… At step S152, the resource provider computer 25 may send a request for the token for the transaction to token server 30. The request may include identifying transaction data, such as the transaction identifier previously provided to the token server 30 by the application provider computer 40. At step S154, the token server 30 may retrieve the token associated with the identifying transaction data, and provide it to the resource provider computer 25… In some embodiments, the token may be generated on the fly using API calls. For example, when a request is received to tokenize an account identifier or other sensitive information, token generation module 512 may determine a token range to assign the token… The code may be, for example, a QR code. The consumer may scan the code with his or her communication device using a camera or other visual sensor associated with the communication device. The code may be interpreted by an application on the communication device and the transaction data may be displayed to the consumer in one embodiment. The consumer may request a token at the communication device that corresponds to a payment device selected to perform the payment transaction. The token, the transaction data, and the consumer's location may be provided to an application provider computer. The application provider computer may facilitate completion of the transaction between the consumer and the merchant using the transaction data and the token, if the consumer's location is within a predetermined threshold distance of the merchant's location, as described further herein…In some embodiments, a token may be used in place of a PAN to initiate, authorize, settle or resolve a payment transaction.
It would have been obvious to one having ordinary skill in the art at the time the invention was filed to modify Laracey with the ability to generate a token concealing private payment information for completing the transaction as taught by Chitalia, doing so further protects the payment information by tokenization the information [0034-0035].
As per claim 10, and 18, Laracey discloses:
transmitting a signal that indicates that the transaction cannot be processed; and [0044] In some embodiments, the transaction management system 130 transmits a payment authorization request message to the customer's mobile device, enabling the customer to have a final opportunity to confirm or cancel the payment transaction, although this step is optional. The customer's confirmation or cancellation is transmitted from the mobile device 102 as a customer payment authorization message to the transaction management system 130 via path 114.
denying further processing of the transaction. [0044] In some embodiments, the transaction management system 130 transmits a payment authorization request message to the customer's mobile device, enabling the customer to have a final opportunity to confirm or cancel the payment transaction, although this step is optional. The customer's confirmation or cancellation is transmitted from the mobile device 102 as a customer payment authorization message to the transaction management system 130 via path 114.
As per claim 12, Laracey discloses:
receiving the indicia that encodes the information related to the transaction; and [0092] In some embodiments, as discussed above, the checkout token is not sent from the merchant system 209. Instead, the checkout token may be retrieved, generated or "looked up" by the transaction management system 230 in response to a message received at 408 from merchant system 209. For example, the checkout token may be looked up from a table associating a merchant ID (received at 408) with a static checkout token. In some embodiments, the checkout token could be generated by the transaction management system 230 when it receives the merchant payment authorization request at 408, and then the checkout token would be passed back to the merchant system 209 as part of the acknowledgement of the merchant payment authorization request.
displaying the indicia. [0093] Processing continues at 410 where a checkout token is displayed or otherwise provided to the customer. Processing at 410 may be performed in a number of different ways, depending, in some embodiments, on whether a static checkout token or a dynamic checkout token is used. In situations where static checkout tokens are used, the display of the checkout token may be performed prior to the transaction by placing or otherwise displaying a static checkout token in an area associated with the point of sale device 212.
As per claims 11, 13-17, and 18, claims 11, 13-16, and 18 recite substantially similar limitations to those found in claims 1-5, 9, and 10, respectively. Therefor claims 11, 13-17, and 18 are rejected under the same art and rationale as claims 1-5, 9, and 10, respectively. Furthermore, Laracey discloses a data storage device to perform the instructions [0021], [0171], and a processor [0047], [0172].
As per claim 20, claim 20 recite substantially similar limitations to those found in claim 2. Therefor claim 20 is rejected under the same art and rationale as claim 2. Furthermore, Laracey discloses a non-transitory machine readable medium [0021], [0171].
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 nonprovisional extension fee (37 CFR 1.17(a)) 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 GREGORY S CUNNINGHAM II whose telephone number is (313)446-6564. The examiner can normally be reached Mon-Fri 8:30am-4pm.
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, Bennett Sigmond can be reached at 303-297-4411. 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.
GREGORY S. CUNNINGHAM II
Primary Examiner
Art Unit 3694
/GREGORY S CUNNINGHAM II/Primary Examiner, Art Unit 3694
Prosecution Insights