DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This is a Non-Final Office Action in response to amended claims in application 18/625,445 entitled "INFORMATION-SECURITY SYSTEM AND METHOD FOR SECURE TRANSACTION VALIDATION AND AUTHORIZATIONS AT TRANSACTION PROCESSING POINTS" filed on March 11, 2026, with claims 33 and 34 pending.
Status of Claims
Claims 1-32 are cancelled.
Claims 33 and 34 are added and have been examined.
Response to Amendment
The amendment filed March 11, 2026, has been entered. Claims 33 and 34 remain pending in the application. Applicant’s amendments to the Specification, Drawings, and/or Claims have been noted in response to the Final Office Action mailed January 2, 2026.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on April 3, 2024, is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the Examiner.
Examiner’s Note
Intended use language is generally given limited patentable weight. See MPEP 2114(II) ("A claim containing a 'recitation with respect to the manner in which a claimed apparatus is intended to be employed does not differentiate the claimed apparatus from a prior art apparatus’ if the prior art apparatus teaches all the structural limitations of the claim. Ex parte Masham, 2 USPQ2d 1647 (Bd. Pat. App. & Inter. 1987).”); see also MPEP 2103(C). Examples of claim limitations that are often found to precede intended use include “adapted to,” “capable of,” “sufficient to,” “whereby,” “thereby,” and “for.” The following limitations are interpreted as intended use limitations:
The Examiner would like to note that the claims are replete with intended use, however, to provide compact prosecution, the examiner has provided the mapping and rejections:
Claim 33:
“to protect transaction data against interception and unauthorized access;”
“thereby transforming the transaction process into an interactive verification process in which the customer has direct oversight over the accuracy of the transaction”
“thereby enabling the user to modify a total transaction amount before payment authorization;”
“that facilitates efficient and secure data exchange across a distributed transaction processing network to ensure that all parties involved have access to accurate and timely transaction data for a real-time validation process”
“to format the retail transaction data effectively for secure data exchange across distributed systems”
“providing audit trails and transaction verification”
“ensuring compliance with financial transaction standards”
“dynamically adapts to new acquirers to ensure compatibility and security, thereby ensuring the transaction is processed without interruptions”
“to ensure optimal routing of payment requests”
“thereby securing funds for the transaction while allowing for subsequent adjustments prior to final transaction completion and eliminating the possibility of billing errors and unauthorized charges”
“that facilitates seamless communication between various components of the payment process”
“to ensure that transactions are not hindered by technical glitches or compatibility issues with a primary payment acquirer”
“to prevent transaction failures”
“providing a record of the transaction for both parties”
“for returns or disputes”
“to update an inventory system of a merchant accordingly”
Claim 34:
“thereby enabling the user to modify a total transaction amount before payment authorization”
“to protect transaction data against interception and unauthorized access”
“for tracking and management of the transaction through various stages of processing”
“dynamically adapting to new acquirers to ensure compatibility and security”
“thereby securing funds for the transaction while allowing for subsequent adjustments prior to final transaction completion and eliminating the possibility of billing errors and unauthorized charges”
“to perform real-time adjustments to the payment process based on the transaction's specific needs and conditions to ensure optimal routing of payment requests”
“by adjusting the payment reservation accordingly”
“act as a dynamic intermediary that facilitates seamless communication”
“to ensure that transactions are not hindered by technical glitches or compatibility issues”
“to prevent transaction failures”
“accordingly upon modification”
“thereby ensuring that the transaction is accurate and eliminating discrepancies that would otherwise be discovered only upon reviewing a receipt after payment completion”
The Examiner determines the aforementioned intended use statements do not result in any structural nor manipulative difference between the claimed invention and the prior art. Therefore, the intended use statements are afforded limited patentable weight.
Specification Objections
The use of the term New Distribution Capability (NDC) ™, is a trade name or mark used in commerce by the International Air Transport Association (IATA), has been noted in this application. It should be CAPITALIZED wherever they appear and be accompanied by the generic terminology.
Although the use of trade names and marks used in commerce (i.e., trademarks, service marks, certification marks, and collective marks) are permissible in patent applications, the proprietary nature of the marks should be respected and every effort made to prevent their use in any manner which might adversely affect their validity as commercial marks.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 33 and 34 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ).
Claim 33 states:
“repurposing a travel industry-supported … communication enhancement program”
“facilitates efficient and secure data exchange across a distributed transaction processing network”
“accurate and timely transaction data”
“format the … data effectively”
“ensuring compliance”
“dynamically adapts to new acquirers”
“a most efficient transaction processing route”
“for dynamic resource allocation”
“based on the transaction's specific needs and conditions to ensure optimal routing of payment requests”
“eliminating the possibility”
“facilitates seamless communication”
“ensure that transactions are not hindered by technical glitches or compatibility issues”
“if there are any issues”
“determines an optimal payment network”
“adjusts the account of the user accordingly”
Claim 34 states:
“format the retail transaction data effectively”
“ensure compliance with financial transaction standards”
“dynamically adapting to new acquirers”
“select a most efficient transaction processing route”
“eliminating the possibility”
“ensure optimal routing”
“adjusting the payment reservation accordingly”
“act as a dynamic intermediary”
“ensure that transactions are not hindered by technical glitches or compatibility issues”
“if there are any issues”
“determine an optimal payment network”
“adjust the account of the user accordingly”
“update an inventory system of a merchant accordingly”
“ensuring that the transaction is accurate and eliminating discrepancies”
The underlined terms in Claims 33 and 34 lacks boundaries of the protected subject matter and are not clearly delineated. Therefore, the scope is unclear which renders the claims indefinite. The underlined terms are not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention.
Claims 33 and 34 contains the trademark/trade name "new distribution capability packet". Where a trademark or trade name is used in a claim as a limitation to identify or describe a particular material or product, the claim does not comply with the requirements of 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph. See Ex parte Simpson, 218 USPQ 1020 (Bd. App. 1982). The claim scope is uncertain since the trademark or trade name cannot be used properly to identify any particular material or product. A trademark or trade name is used to identify a source of goods, and not the goods themselves. Thus, a trademark or trade name does not identify or describe the goods associated with the trademark or trade name. In the present case, the trademark/trade name is used to identify/describe an XML-based data transmission standard and, accordingly, the identification/description is indefinite.
Therefore, the claims are rejected.
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 33 and 34 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Please see MPEP 2106 for additional information regarding Patent Subject Matter Eligibility Guidance.
Claims 33 and 34 are directed to a method/process, machine/apparatus, (article of) manufacture, or composition of matter, which are/is one of the statutory categories of invention, which are/is one of the statutory categories of invention. (Step 1: YES).
The claimed invention is directed to an abstract idea without significantly more.
Independent Claim 33 recites:
“A ….method for transforming a point-of-sale transaction process to provide real-time customer verification and control over transaction accuracy, the method performed by a transaction processing system comprising a, a …a control object payment processor, a reserved payment driven switch, and a device handler, the method comprising:
initiating, by the ..., a transaction by scanning a merchant point-of-sale identifier displayed on the ..., wherein the scanning triggers the ... to gather the ... information and related telemetry data for secure transaction processing;
establishing, by the ... and the ..., a secure communication link between the ... and the ... through scanning of a …displayed on the ... or through ….wherein the communication link between the ... and the ... is established using a secure wireless protocol selected from a group consisting of…;
…by the transaction processing system, the secure communication link between the ... and the ... using an advanced encryption standard with a key length of at least 256 bits to protect transaction data against interception and unauthorized access;
…by the ..., transaction data from the ... to the ... over the secure communication link, the transaction data including a detailed list of items with respective prices and quantities involved in the transaction;
displaying, by the ..., the transaction data on …in real-time during the checkout process, …presenting an itemized list of purchases with prices and providing interactive controls for the user to approve or dispute each individual item before payment is processed, thereby transforming the transaction process into an
interactive verification process in which the customer has direct oversight over the accuracy of the transaction;
receiving, by the ..., a user selection at the ... through…the user selection including validation or modification of the transaction data, wherein the user selection includes selectively approving or disputing one or more items from the list of items displayed on the ..., thereby enabling the user to modify a total transaction amount before payment authorization;
applying, by the transaction processing system, a user-specific discount or loyalty points to the transaction based on the user-validated transaction data before finalizing the transaction;
verifying, by the ..., user identity through biometric authentication before encoding the transaction data, the biometric authentication …. facial recognition, or voice verification;
…, by the ..., user-validated transaction data from the ... back to the ...;
upon user validation, encoding, by the ..., the user-validated transaction data into a new distribution capability packet by repurposing a travel industry-supported New Distribution Capability communication enhancement program that facilitates efficient and secure data exchange across a distributed transaction processing network to ensure that all parties involved have access to accurate and timely transaction data for a real-time validation process, to format the retail transaction data effectively for secure data exchange across distributed systems;
generating, by the control object payment processor, a unique transaction identifier that is embedded within the new distribution capability packet, wherein the unique transaction identifier is used by the device handler to track and manage the transaction through various stages of processing, providing audit trails and transaction verification;
… by the ..., the new distribution capability packet to the control object payment processor over the distributed transaction processing network, wherein the control object payment processor is configured to interface with both the ... and the ..., facilitating authentication of the transaction data and ensuring compliance with financial transaction standards;
adapting, by the control object payment processor, the transaction data into a compatible mode for a new acquirer if a primary acquirer fails, wherein the control object payment processor establishes a secure and compatible connection between the ... and a customer payment method and dynamically adapts to new acquirers to ensure compatibility and security, thereby ensuring the transaction is processed without interruptions;
selecting, by the transaction processing system, a most efficient transaction processing route based on a transaction type, a transaction amount, and current network conditions using a dynamic routing module within the control object payment processor, utilizing the reserved payment driven switch for dynamic resource allocation to perform real-time adjustments to the payment process based on the transaction's specific needs and conditions to ensure optimal routing of payment requests;
sending, by an issuing bank, a real-time notification to the ... providing an itemized list of the transaction for review by the user via a banking application on the ...;
reserving, by the reserved payment driven switch in conjunction with the control object payment processor, a transaction amount in an account of the user without finalizing the transaction, wherein the reserved payment driven switch holds the payment for items in a reserved state until the user approves the transaction through the ..., thereby securing funds for the transaction while allowing for subsequent adjustments prior to final transaction completion and eliminating the possibility of billing errors and unauthorized charges;
operating, by the device handler, within the transaction processing system to dynamically manage data flow and transaction logic between the ..., the ..., the control object payment processor, and financial institutions, wherein the device handler acts as a dynamic intermediary that facilitates seamless communication between various components of the payment process and manages switching between different payment networks to ensure that transactions are not hindered by technical glitches or compatibility issues with a primary payment acquirer;
switching, by the device handler, to an alternative payment network if there are any issues with a primary payment network, wherein the device handler determines an optimal payment network for the transaction based on real-time conditions to prevent transaction failures;
upon receiving final confirmation from the user via the ..., finalizing, by the control object payment processor, the transaction by sending an instruction to a financial institution to transfer the reserved transaction amount from the account of the user to an account of a merchant;
generating, by the transaction processing system, a secure electronic receipt based on the user-validated transaction data, wherein the secure electronic receipt includes a digital signature of the merchant and a transaction timestamp, and wherein the secure electronic receipt is transmitted to both the ... and the ..., providing a record of the transaction for both parties;
storing, by the ..., the secure electronic receipt in a digital wallet application on the ...;
updating, by the transaction processing system, transaction status on both the ... and the ... in real-time, wherein the transaction status update includes the unique transaction identifier and a summary of the transaction details;
providing, by the ..., an option within the digital wallet application on the ... to modify the transaction post-purchase for returns or disputes, wherein the user can initiate a return process directly from the ... by deselecting returned items on the secure electronic receipt within the digital wallet application, wherein the modification triggers an update to the transaction and adjusts the account of the user accordingly;
notifying, by the ..., the ... of an initiated return process to update an inventory system of a merchant accordingly; and
generating, by the control object payment processor, a new secure electronic receipt reflecting a modified transaction post-return, including an updated total transaction amount and an indication of the returned items,
wherein the ..., the ..., the control object payment processor, the reserved payment driven switch, and the device handler operate in coordination to transform the transaction process into an interactive verification process where the customer can view and approve details of purchases on the ... before payment is finalized.”
These limitations clearly relate to managing transactions/interactions between consumer/buyer, merchant, and/or financial institution. These limitations, under their broadest reasonable interpretation, cover performance of the limitation as certain methods of organizing human activity. Specific instances include instructing for "transforming a point-of-sale transaction process", "presenting an itemized list of purchases", "for the user to approve or dispute each individual item before payment is processed", "applying,...a user-specific discount", "generating...a unique transaction identifier", "providing audit trails and transaction verification", "sending, by an issuing bank, a real-time notification", "reserving, by the reserved payment driven switch in conjunction with the control object payment processor, a transaction amount", "securing funds for the transaction", "switching...to an alternative payment network", and "sending an instruction to a financial institution to transfer the reserved transaction amount" recite a fundamental economic principles or practice and/or commercial or legal interactions. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation as a fundamental economic, commercial, or financial action, principle, or practice then it falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. Accordingly, the claim recites an abstract idea. (Step 2A-Prong 1: YES. The claims recite an abstract idea).
This judicial exception is not integrated into a practical application. In particular, the claims recite the additional elements of:
[computer-implemented] [mobile device][point-of-sale device][a user interface of the mobile device] [the user interface]:
merely applying computer processing, storage, and networking technology as tools to perform an abstract idea
[near field communication][a wireless personal area network, a wireless local area network, and near field communication]: merely applying wireless communication to promote the abstract idea.
[quick response code]: insignificant extra-solution activity to the judicial exception of data gathering and display
[fingerprint scanning]: generally linking to fingerprint security to promote the abstract idea.
[transmitting/transmitted] [encrypting]: insignificant extra-solution activity to the judicial exception of data gathering, display, and encryption
are recited at a high-level of generality (i.e., as a generic processor performing a generic computer function) such that it amounts no more than mere instructions to apply the exception using a generic computer components and/or electronic processes. For example, the Applicant’s Specification reads,
“[0054] Terms like "computers", "machines," and similar phrases are interchangeably used herein, ... refer to devices that can be general-purpose...either virtual or physical... This includes all relevant hardware, software, and components familiar to those with expertise in the area.....like application-specific integrated circuits (ASICs), microprocessors, cores, or other processing units to execute, access, control, or implement various types of software, instructions, data, modules, processes, or routines as mentioned. The usage of these terms in the text is not intended to be limiting or exclusive to any specific kinds of electronic devices or components and should be interpreted in the widest sense by those with relevant expertise. Specific details on computer/software components, machines, etc., are not provided
Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. The additional elements merely add instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea, see MPEP 2106.05(f). Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea and are at a high level of generality. Therefore, Claim 33 is directed to an abstract idea without a practical application. (Step 2A-Prong 2: NO. The additional claimed elements are not integrated into a practical application)
Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. The additional elements merely add instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea, see MPEP 2106.05(f). Accordingly, the additional elements, do not change the outcome of the analysis, when considered separately and as an ordered combination. The claim further defines the abstract idea and hence is abstract for the reasons presented above. The claim does not include any additional elements that integrate the abstract idea into a practical application or are sufficient to amount to significantly more than the judicial exception when considered both individually and as an ordered combination.
For causing the transmitting, MPEP 2106.05(d)(II) indicates that the courts have recognized receiving or transmitting data over a network as well-understood, routine and conventional functions when claimed in a merely generic manner: Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); 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).
Therefore, the claim is directed to an abstract idea. Thus, the claim is not patent eligible. (Step 2B: NO. The claim does not provide significantly more)
Independent Claim 34 recites:
“A transaction processing system for transforming a point-of-sale transaction process to provide real-time customer verification and control over transaction accuracy, the system comprising:
a …the …configured to:
scan a merchant point-of-sale identifier to initiate a transaction,
establish a secure communication link with a …through scanning of …using a secure wireless protocol selected from a group consisting of a…,
receive and display transaction data including a detailed list of items with respective prices and quantities on a user interface in real-time during a checkout process,
present interactive controls on the user interface for a user to approve or dispute each individual item before payment is processed,
receive a user selection including validation or modification of the transaction data through the user interface, wherein the user selection includes selectively approving or disputing one or more items from the list of items displayed on the ..., thereby enabling the user to modify a total transaction amount before payment authorization,
verify user identity through biometric authentication including …facial recognition, or voice verification before encoding the transaction data,
…user-validated transaction data back to the ..., and
encode user-validated transaction data into a new distribution capability packet by repurposing a travel industry-supported New Distribution Capability communication enhancement program that facilitates efficient and secure data exchange across a distributed transaction processing network to format the retail transaction data effectively for secure data exchange across distributed systems;
a ….configured to present …and a wireless communication interface, the ... configured to:
gather ... information and related telemetry data upon scanning of the merchant point-of-sale identifier,
establish the secure communication link with the ...,
… transaction data including the detailed list of items with respective prices and quantities to the ... over the secure communication link, and
receive user-validated transaction data from the ...;
an encryption module configured…the secure communication link between the ... and the ... using an advanced encryption standard with a key length of at least 256 bits to protect transaction data against interception and unauthorized access;
a control object payment processor interfaced with both the ... and the ..., the control object payment processor comprising:
a unique transaction identifier generation module configured to generate a unique transaction identifier that is embedded within the new distribution capability packet for tracking and management of the transaction through various stages of processing, providing audit trails and transaction verification,
a transaction authentication module configured to authenticate the transaction data and ensure compliance with financial transaction standards,
an acquirer adaptation module configured to adapt the transaction data into a compatible mode for a new acquirer if a primary acquirer fails by establishing a secure and compatible connection between the ... and a customer payment method and dynamically adapting to new acquirers to ensure compatibility and security,
a dynamic routing module configured to select a most efficient transaction processing route based on a transaction type, a transaction amount, and current network conditions, and
a transaction completion module configured to send an instruction to a financial institution to transfer a reserved transaction amount from an account of the user to an account of a merchant upon receiving final confirmation from the user via the ...;
a reserved payment driven switch integrated with the control object payment processor, the reserved payment driven switch configured to:
reserve a transaction amount in the account of the user without finalizing the transaction,
hold the payment for items in a reserved state until the user approves the transaction through the ..., thereby securing funds for the transaction while allowing for subsequent adjustments prior to final transaction completion and eliminating the possibility of billing errors and unauthorized charges,
dynamically allocate resources for transaction processing to perform real-time adjustments to the payment process based on the transaction's specific needs and conditions to ensure optimal routing of payment requests, and
facilitate post-transaction adjustments including returns and disputes by adjusting the payment reservation accordingly;
a device handler configured to:
dynamically manage data flow and transaction logic between the ..., the ..., the control object payment processor, and financial institutions,
act as a dynamic intermediary that facilitates seamless communication between various components of a payment process,
manage switching between different payment networks to ensure that transactions are not hindered by technical glitches or compatibility issues with a primary payment acquirer,
switch to an alternative payment network if there are any issues with a primary payment network, and
determine an optimal payment network for the transaction based on real-time conditions to prevent transaction failures;
a secure electronic receipt generator configured to:
generate a secure electronic receipt based on the user-validated transaction data, wherein the secure electronic receipt includes a digital signature of the merchant and a transaction timestamp,
… the secure electronic receipt to both the ... and the ..., providing a record of the transaction for both parties, and
generate a new secure electronic receipt reflecting a modified transaction post-return, including an updated total transaction amount and an indication of returned items; and
a digital wallet application stored on the ..., the digital wallet application configured to:
store the secure electronic receipt,
provide an option to modify the transaction post-purchase for returns or disputes,
enable the user to initiate a return process directly from the ... by deselecting returned items on the secure electronic receipt within the digital wallet application,
trigger an update to the transaction and adjust the account of the user accordingly upon modification, and
notify the ... of an initiated return process to update an inventory system of a merchant accordingly,
wherein the ..., the ..., the control object payment processor, the reserved payment driven switch, and the device handler operate in coordination to transform the transaction process into an interactive verification process where the customer can view and approve details of purchases on the ... before payment is finalized, thereby ensuring that the transaction is accurate and eliminating discrepancies that would otherwise be discovered only upon reviewing a receipt after payment completion.”
These limitations clearly relate to managing transactions/interactions between consumer/buyer, merchant, and/or financial institution. These limitations, under their broadest reasonable interpretation, cover performance of the limitation as certain methods of organizing human activity. Specific instances include instructing for "transforming a point-of-sale transaction process", "receive and display transaction data including a detailed list of items with respective prices and quantities...during a checkout process", "for the user to approve or dispute each individual item before payment is processed", "enabling the user to modify a total transaction amount before payment authorization", "providing audit trails and transaction verification", "ensure compliance with financial transaction standards", "transfer a reserved transaction amount", "hold the payment", "securing funds for the transaction", "ensure optimal routing of payment requests", and "adjusting the payment reservation" recite a fundamental economic principles or practice and/or commercial or legal interactions. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation as a fundamental economic, commercial, or financial action, principle, or practice then it falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. Accordingly, the claim recites an abstract idea. (Step 2A-Prong 1: YES. The claims recite an abstract idea).
This judicial exception is not integrated into a practical application. In particular, the claims recite the additional elements of:
[mobile device comprising a processor, a memory, a display, a camera, a biometric authentication module, and a wireless communication interface], [mobile device] [point-of-sale device] [point-of-sale device comprising a processor, a memory, a display]:
merely applying computer processing, storage, and networking technology as tools to perform an abstract idea
[near field communication] [wireless personal area network, a wireless local area network, and near field communication]: merely applying wireless communication to promote the abstract idea.
[quick response code]: insignificant extra-solution activity to the judicial exception of data gathering and display
[fingerprint scanning]: generally linking to fingerprint security to promote the abstract idea.
[transmitting/transmitted] [to encrypt]: insignificant extra-solution activity to the judicial exception of data gathering, display, and encryption
are recited at a high-level of generality (i.e., as a generic processor performing a generic computer function) such that it amounts no more than mere instructions to apply the exception using a generic computer components and/or electronic processes. For example, the Applicant’s Specification reads,
“[0054] Terms like "computers", "machines," and similar phrases are interchangeably used herein, ... refer to devices that can be general-purpose...either virtual or physical... This includes all relevant hardware, software, and components familiar to those with expertise in the area.....like application-specific integrated circuits (ASICs), microprocessors, cores, or other processing units to execute, access, control, or implement various types of software, instructions, data, modules, processes, or routines as mentioned. The usage of these terms in the text is not intended to be limiting or exclusive to any specific kinds of electronic devices or components and should be interpreted in the widest sense by those with relevant expertise. Specific details on computer/software components, machines, etc., are not provided
Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. The additional elements merely add instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea, see MPEP 2106.05(f). Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea and are at a high level of generality. Therefore, Claim 34 is directed to an abstract idea without a practical application. (Step 2A-Prong 2: NO. The additional claimed elements are not integrated into a practical application)
Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. The additional elements merely add instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea, see MPEP 2106.05(f). Accordingly, the additional elements, do not change the outcome of the analysis, when considered separately and as an ordered combination. The claim further defines the abstract idea and hence is abstract for the reasons presented above. The claim does not include any additional elements that integrate the abstract idea into a practical application or are sufficient to amount to significantly more than the judicial exception when considered both individually and as an ordered combination.
For causing the transmitting, MPEP 2106.05(d)(II) indicates that the courts have recognized receiving or transmitting data over a network as well-understood, routine and conventional functions when claimed in a merely generic manner: Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); 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).
Therefore, the claim is directed to an abstract idea. Thus, the claim is not patent eligible. (Step 2B: NO. The claim does not provide significantly more)
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
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.
Claims 33 and 34 are rejected under 35 U.S.C. 103 as being unpatentable over Vintila (“SYSTEM AND METHOD FOR LOCATION-BASED TOKEN TRANSACTION PROCESSING”, Canadian Publication Number: CA3007992A1), in view of Lin (“PORTABLE POINT OF PURCHASE USER INTERFACES”, U.S. Publication Number: 20100082444 A1),in view of Pitroda (“TRANSACTIONAL SERVICES”, U.S. Publication Number: 20070198432 A1),in view of Ettl (“COMPUTER-IMPLEMENTED TECHNIQUES FOR DETERMINING AND PROVISIONING REAL-TIME INDIVIDUALIZED PRODUCT AND SERVICE OFFERING”, U.S. Publication Number: 20170061463 A1).
Regarding Claim 33,
Vintila teaches,
A computer-implemented method for transforming a point-of-sale transaction process to provide real-time customer verification and control over transaction accuracy, the method performed by a transaction processing system comprising a mobile device, a point-of-sale device,
(Vintila [Claim 9] wherein routing the token via the data communication interface comprises: transmitting the token via a point-of-sale device via a near-field communication
Vintila [0008] To initiate many types of transaction using a virtual wallet, a user can approach a merchant point-of-sale (POS) terminal and present the mobile device for scanning or some other type of data exchange
Vintila [00230] Examples of the use of systems in accordance with the invention to implement both real-time and split-pay processes
Vintila [0006] select which of several payment forms to use in association with a transaction, designate and confirm payment amounts and other transaction details, and otherwise manage or control transactions and accounts to be used in transactions)
a control object payment processor, a reserved payment driven switch, and a device handler,
(Vintila [0064] and other devices such as trusted platforms, payment processors, and/or card or issuer systems...between purchaser devices, merchant devices, and devices controlled by payment processors and other parties.
Vintila [00170] For example, payment gateway 150, 915 may be configured to detect the selected payment method based on the HCE token or payment credential that has been received and then route the transaction accordingly to one or more further downstream entities.)
the method comprising: initiating, by the mobile device, a transaction by scanning a merchant point-of-sale identifier displayed on the point-of-sale device, wherein the scanning triggers the point-of-sale device to gather the mobile device information and related telemetry data for secure transaction processing;
(Vintila [0008] To initiate many types of transaction using a virtual wallet, a user can approach a merchant point-of-sale (POS) terminal and present the mobile device for scanning or some other type of data exchange. For example, in a Near Field Communication (NEC) transaction, an NFC reader will request payment credentials and/or other transaction-specific information from the mobile device when the two are brought into close proximity with one another. Similarly, payment credentials and transaction information can be exchanged between the mobile wallet and merchant POS terminal using visual patterns, such as barcodes and QR codes
Vintila [00227] transaction requests generated by a user device 110' and/or associated with specific transaction requests type(s), based on a variety of criteria, including for example user identity, merchant identity
Vintila [00166] Merchant application 114, 630 may then transmit signals representing the HCE token or other payment credential ... along with other information (date, merchant identification, amount, etc.) needed or otherwise used to complete the transaction
Vintila [00382] that geolocation and payment processes may be utilized together to provide one or more merchant identifiers
Vintila [00440] signals providing information regarding the location of the device represent GPS data or other location data received from a GPS unit on the device, or any other location-based services provided on mobile devices.
Vintila [0006] The use of secure elements, encryption, tokenization, and other techniques can be used to enhance the security)
establishing, by the mobile device and the point-of-sale device, a secure communication link between the mobile device and the point-of-sale device through scanning of a quick response code displayed on the point-of-sale device or through near field communication, wherein the communication link between the mobile device and the point-of-sale device is established using a secure wireless protocol selected from a group consisting of a wireless personal area network, a wireless local area network, and near field communication;
(Vintila [0008] To initiate many types of transaction using a virtual wallet, a user can approach a merchant point-of-sale (POS) terminal and present the mobile device for scanning or some other type of data exchange. For example, in a Near Field Communication (NEC) transaction, an NFC reader will request payment credentials and/or other transaction-specific information from the mobile device when the two are brought into close proximity with one another. Similarly, payment credentials and transaction information can be exchanged between the mobile wallet and merchant POS terminal using visual patterns, such as barcodes and QR codes)
encrypting, by the transaction processing system, the secure communication link between the mobile device and the point-of-sale device using an advanced…to protect transaction data against interception and unauthorized access;
(Vintila [0069] Encryption of the payment information may be performed by the virtual wallet prior to transmission to the merchant application
Vintila [0073] the user's device may cause a payment token, a reference to such a token, and/or other encrypted data stored in a mobile wallet application or elsewhere on the mobile device, or in a secure cloud, to be transmitted to the merchant system)
transmitting, by the point-of-sale device, transaction data from the point-of-sale device to the mobile device over the secure communication link, the transaction data including a detailed list of items with respective prices and quantities involved in the transaction; displaying, by the mobile device, the transaction data on a user interface of the mobile device in real-time during the checkout process, the user interface presenting an itemized list of purchases with prices and providing interactive controls for the user to approve or dispute each individual item before payment is processed, thereby transforming the transaction process into an interactive verification process in which the customer has direct oversight over the accuracy of the transaction;
(Vintila [0008] payment credentials and transaction information can be exchanged between the mobile wallet and merchant POS terminal using visual patterns, such as barcodes and QR codes
Vintila [00219] a user 190 of a mobile or non-mobile request communication device 110, 110',... can shop the merchant website and/or brick and mortar store,...When ready to check out (i.e., complete a transaction), the user 190, ...causing the user to be presented by his/her device 110, 110' with a checkout GUI ...which may for example include all or portions of information represented by the transaction authorization request data set, such as a list of item(s) to be purchased, price, tax, shipping/delivery information, etc., and one or more selectable or otherwise interactive items
Vintila [00196] For example, selection by a user of a device 110' at a POS 132, 134 or within a web browser of a desktop system 110 of an interactive GUI device "check out" or "ready to pay" displayed on a device screen 610 can cause the device 110' to generate and display a GUI comprising items
Vintila [00197] Selection by the user of an interactive GUI "checkout" element 1404 of FIG. 14A can cause the device 110' to initiate a process controlled by the merchant application... enable the user to complete the transaction...approval is required in order for the transaction to be completed, including for example a total purchase amount, identifier(s) associated with account(s) to be used as payment resources, and/or merchant or other accounts designated for receipt of the payment(s), along with any routing, confirmation, and/or security data or devices)
receiving, by the mobile device, a user selection at the mobile device through the user interface, the user selection including validation or modification of the transaction data, wherein the user selection includes selectively approving or disputing one or more items from the list of items displayed on the mobile device,
(Vintila [00219] a user 190 of a mobile or non-mobile request communication device 110, 110',... causing the user to be presented by his/her device 110, 110' with a checkout GUI ...which may for example include all or portions of information represented by the transaction authorization request data set, such as a list of item(s) to be purchased, price, tax, shipping/delivery information, etc., and one or more selectable or otherwise interactive items
Vintila [00196] For example, selection by a user of a device 110' at a POS 132, 134 or within a web browser of a desktop system 110 of an interactive GUI device "check out" or "ready to pay"
Vintila [00197] Selection by the user of an interactive GUI "checkout" element 1404 of FIG. 14A can cause the device 110' to initiate a process controlled by the merchant application 114, 630 to enable the user to complete.... Transaction authorization request data sets generated through the use of such processes can comprise any information required... whose approval is required in order for the transaction to be completed, including for example a total purchase amount
Vintila [00198] Selection by the user of a GUI element 1406 'pay with your bank can cause the device wallet 112, 630 and/or payment options API 116 to continue or initiate a payment process)
thereby enabling the user to modify a total transaction amount before payment authorization; applying, by the transaction processing system, a user-specific discount or loyalty points to the transaction based on the user-validated transaction data before finalizing the transaction;
(Vintila [00105] Real-time offers, including coupon, redemption, discount, credit, and other options may be presented to the user,
Vintila [00202] showing information concerning the amount(s) of cash, rewards, or other values the user may have available for a transaction, for example how many loyalty points the user has available to be applied toward a requested transaction, or how many dollars, pounds, francs, or other types of currency are available to the user for use in the transaction....The user 190 can, for example by using a visual slider 1422 or other interface 1420, designate the number of available points (or different currencies, payment accounts, etc.)] are to be redeemed or otherwise applied toward the proposed transaction.
Vintila [00336] discount applied
Vintila [00320] application of discounts or other offers directed specifically at the user 190 who identified as controlling the transaction session)
verifying, by the mobile device, user identity through biometric authentication before encoding the transaction data, the biometric authentication including fingerprint scanning, facial recognition, or voice verification;
(Vintila [0008] Mobile payment transactions may also require some type of user authentication, such as the inputting of a PIN or identifying biometric, before they will be processed
Vintila [00443] electronic device generates a token....encoding, hashing and/or any other data process for creating a data set suitable for processing at a transaction processing system.
Vintila [0080] A variety of secure authentication methods may be used as described herein, including fingerprint or other biometric verification, including for example voice or facial recognition, login/password, or any other secure verification means supported by particular capabilities of the user's device.)
transmitting, by the mobile device, user-validated transaction data from the mobile device back to the point-of-sale device;
(Vintila [0008] a user can approach a merchant point-of-sale (POS) terminal and present the mobile device for scanning or some other type of data exchange. For example, in a Near Field Communication (NEC) transaction,...payment credentials and transaction information can be exchanged between the mobile wallet and merchant POS terminal...require some type of user authentication, such as the inputting of a PIN or identifying biometric, before they will be processed
Vintila [00197] Selection by the user ... to enable the user to complete the transaction by using payment processes authorized...can comprise any information required or otherwise desired)
generating, by the control object payment processor, a unique transaction identifier that is embedded within the new distribution capability packet, wherein the unique transaction identifier is used by the device handler to track and manage the transaction through various stages of processing, providing audit trails and transaction verification;
(Vintila [Abstract] data structures
Vintila [00305] When, for example, agreement has been reached and the user is ready to complete the transaction, ...generate a transaction request data set comprising a transaction identifier identifying a transaction to be satisfied by payment from one or more payment accounts according to a preference
Vintila [00326] a transaction identifier identifying a transaction to be satisfied by payment
Vintila [00263] an account number may be a single-use...associated with a single transaction. This can, for example, aid in authorizing and tracking transaction, and in subsequent accounting; and provides an additional layer of security
Vintila [00318] the end of day reconciliation of the transaction)
transmitting, by the mobile device, the new distribution capability packet to the control object payment processor over the distributed transaction processing network, wherein the control object payment processor is configured to interface with both the mobile device and the point-of- sale device, facilitating authentication of the transaction data and ensuring compliance with financial transaction standards;
(Vintila [Abstract] data structures
Vintila [0014] a data communication interface... providing via the one or more output devices an output indicating that a dynamically-configured electronic token is in a transaction-ready state...and via the data communication interface, route a token, generated from the token data, for processing at a transaction processing system.
Vintila [0066] To facilitate in-app payments by multiple different users of multiple different merchant applications, an industry-wide standard for the issuance of certificates used to authorize the merchant and/or the merchant application can be agreed upon and implemented.
Vintila [00121] to communicate with a suitable target over cellular or other distributed network
Vintila [00446] methods and systems described herein can involve an interaction between a customer device, merchant device(s), and a server or other device(s) which manage points
Vintila [0066] an industry-wide standard for the issuance of certificates used to authorize the merchant and/or the merchant application can be agreed upon arid implemented)
adapting, by the control object payment processor, the transaction data into a compatible mode for a new acquirer if a primary acquirer fails, wherein the control object payment processor establishes a secure and compatible connection between the point-of-sale device and a customer payment method and dynamically adapts to new acquirers to ensure compatibility and security, thereby ensuring the transaction is processed without interruptions;
(Vintila [00443] electronic device generates a token ...generating the token includes formatting, configuring, populating fields, encoding, hashing and/or any other data process for creating a data set suitable for processing at a transaction processing system. ...the data set must be suitable for being processed by an intermediate system, such as ... an end/acquirer system which can authorize and trigger the appropriate transaction.
Vintila [00445] the token is generated to be in a format compatible for routing over a defined payment processing protocol.
Vintila [00293] if one preferred payment option is unavailable for any reason, an Fl 120, 160 associated with a preference identifier can assess a second preference, or a list or ranked preferences, for availability for satisfying the payment.... may be communicated in or overridden by an identifier provided in a protocol-specified discretionary field, such as am Interac payload (in the case of POS)...From a merchant's perspective, a transaction request data set comprising such a preference identifier can look exactly like any other transaction data set according to the selected protocol, including data corresponding to any payment types or protocols preferred by the merchant.)
selecting, by the transaction processing system, a most efficient transaction processing route based on a transaction type, a transaction amount, and current network conditions using a dynamic routing module within the control object payment processor,
(Vintila [00170] For example, payment gateway 150, 915 may be configured to detect the selected payment method based on the HCE token or payment credential that has been received and then route the transaction accordingly to one or more further downstream entities.
Vintila [00177] When transactions are received from merchant backend 136, 136', 910, payment gateway 150, 915 may determine which TSP 150, 925 issued the received token and then route the transaction accordingly.
Vintila [0053] improved efficiency in the use of communications equipment (e.g., data transmission bandwidth)
Vintila [0010] a certain type of payment
Vintila [0056] such as ¨ in the example of a purchase or other financial transaction - VisaNet
Vintila [00148] identifying a transaction, including ...purchase or other amount(s) associated with the transaction(s).
Vintila [0073] the merchant's certificate status (using data signals recognizable as such by a certification authority or trusted platform))
utilizing the reserved payment driven switch for dynamic resource allocation to perform real-time adjustments to the payment process based on the transaction's specific needs and conditions to ensure optimal routing of payment requests;
(Vintila [0064] and other devices such as trusted platforms, payment processors, and/or card or issuer systems...between purchaser devices, merchant devices, and devices controlled by payment processors and other parties.
Vintila [00170] For example, payment gateway 150, 915 may be configured to detect the selected payment method based on the HCE token or payment credential that has been received and then route the transaction accordingly to one or more further downstream entities.)
sending, by an issuing bank, a real-time notification to the mobile device providing an itemized list of the transaction for review by the user via a banking application on the mobile device;
(Vintila [0092] may then be settled subsequently with an issuer bank
Vintila [00286] suitable notifications and confrmations can be generated
Vintila [00335] enabling real-time interactive communications between users
Vintila [00219] a user 190 of a mobile or non-mobile request communication device ...causing the user to be presented by his/her device 110, 110' with a checkout GUI ...which may for example include all or portions of information represented by the transaction authorization request data set, such as a list of item(s) to be purchased, price, tax, shipping/delivery information, etc., and one or more selectable or otherwise interactive items
Vintila [00196] For example, selection by a user of a device 110' at a POS 132, 134 or within a web browser of a desktop system 110 of an interactive GUI device "check out" or "ready to pay" displayed on a device screen 610 can cause the device 110' to generate and display a GUI comprising items)
reserving, by the reserved payment driven switch in conjunction with the control object payment processor, a transaction amount in an account of the user without finalizing the transaction, wherein the reserved payment driven switch holds the payment for items in a reserved state until the user approves the transaction through the mobile device, thereby securing funds for the transaction while allowing for subsequent adjustments prior to final transaction completion and eliminating the possibility of billing errors and unauthorized charges;
(Vintila [00316] Advantageously, in the event that a user 190 or other purchaser is not satisfied with the manner in which funding for a purchase was allocated with respect to a particular transaction, as a result of automated or semi-automated application of preference criteria as described herein, the user or purchaser can be enabled to review...the funding allocation that resulted from application of the preference criteria...by reviewing a set of completed transactions...and change it. Such changes can be retroactive, or effected prior to closing of a transaction, for example at the end of an accounting period such as a day, week, or month, or within some other window of time)
operating, by the device handler, within the transaction processing system to dynamically manage data flow and transaction logic between the point-of-sale device, the mobile device, the control object payment processor, and financial institutions, wherein the device handler acts as a dynamic intermediary that facilitates seamless communication between various components of the payment process and manages switching between different payment networks to ensure that transactions are not hindered by technical glitches or compatibility issues with a primary payment acquirer;
(Vintila [0023] schematic diagrams representing embodiments of systems and data flows within systems
Vintila [0097] the transaction data flow can be the same, or essentially the same, regardless of the payment protocol selected, in accordance with the preferences of itself or its payment systems service providers.
Vintila [0025] showing representative signal exchanges between components of systems for secure processing of electronic payments
Vintila [0059] Trusted relationships between any or all of request communicaton devices, merchant systems, and Fls and/or other FSPs in accordance with the invention can be implemented through the use of trusted network communication protocols
Vintila [00443] an end/acquirer system which can authorize and trigger the appropriate transaction.)
switching, by the device handler, to an alternative payment network if there are any issues with a primary payment network, wherein the device handler determines an optimal payment network for the transaction based on real-time conditions to prevent transaction failures;
(Vintila [00170] For example, payment gateway 150, 915 may be configured to detect the selected payment method based on the HCE token or payment credential that has been received and then route the transaction accordingly to one or more further downstream entities.
Vintila [00177] When transactions are received from merchant backend 136, 136', 910, payment gateway 150, 915 may determine which TSP 150, 925 issued the received token and then route the transaction accordingly.)
upon receiving final confirmation from the user via the mobile device, finalizing, by the control object payment processor, the transaction by sending an instruction to a financial institution to transfer the reserved transaction amount from the account of the user to an account of a merchant;
(Vintila [00197] Selection by the user of an interactive GUI "checkout" element 1404 of FIG. 14A can cause the device 110' to initiate a process controlled by the merchant application... enable the user to complete the transaction...approval is required in order for the transaction to be completed, including ...confirmation
Vintila [00316] the user or purchaser can be enabled to review...the funding allocation that resulted from application of the preference criteria...by reviewing a set of completed transactions
Vintila [00102] A trusted platform 120 can, for example, be adapted to accept and make payments in accordance with such preferred protocol(s), and to cause payment to be transferred to the merchant in accordance therewith)
generating, by the transaction processing system, a secure electronic receipt based on the user-validated transaction data, wherein the secure electronic receipt includes a digital signature of the merchant and a transaction timestamp, and wherein the secure electronic receipt is transmitted to both the mobile device and the point-of-sale device, providing a record of the transaction for both parties;
(Vintila [0067] in response to receipt of the merchant's certificate or, alternatively, following a manual confirmation prompt presented to the user on the mobile device.
Vintila [00222] intra-FI payment confirmation(s) (for 'on us' transactions), or settlement confirmation as instructions.
Vintila [00278] identifers associated with a merchant transction system 130, payment type information, routing instructions, specific transaction identifier(s), time/date range(s) in which the token is valid, etc.
Vintila [00432] the purchase is complete, and the customer receives a push notification providing details and/or confirmation of the purchase.)
update includes the unique transaction identifier
(Vintila [00326] a transaction identifier identifying a transaction to be satisfied by payment
Vintila [00263] an account number may be a single-use...associated with a single transaction. This can, for example, aid in authorizing and tracking transaction, and in subsequent accounting; and provides an additional layer of security
Vintila [00318] the end of day reconciliation of the transaction)
providing, by the mobile device, an option within the digital wallet application on the mobile device to modify the transaction post-purchase for returns or disputes
(Vintila [00316] Advantageously, in the event that a user 190 or other purchaser is not satisfied with the manner in which funding for a purchase was allocated with respect to a particular transaction,...the user or purchaser can be enabled to review......by reviewing a set of completed transactions in a mobile wallet application..., and change it. Such changes can be retroactive... at the end of an accounting period such as a day, week, or month, or within some other window of time)
wherein the mobile device, the point-of-sale device, the control object payment processor, the reserved payment driven switch, and the device handler operate in coordination to transform the transaction process into an interactive verification process where the customer can view and approve details of purchases on the mobile device before payment is finalized.
(Vintila [0074] Transaction authorization data sets and other payment messages may be configured, by either the mobile device or the merchant, to resemble a payment data set in accordance with a recognized payment protocol
Vintila [0079] with interactive fields adapted to enable the requesting user to log in to the user's authorized bank, credit, loyalty, rewards, and/or other payment account(s).
Vintila [00197] Selection by the user of an interactive GUI "checkout" element ... enable the user to complete the transaction...approval is required in order for the transaction to be completed, including ...confirmation
Vintila [00316] the user or purchaser can be enabled to review)
Vintila does not teach encryption standard with a key length of at least 256 bits; upon user validation, encoding, by the mobile device, the user-validated transaction data into a new distribution capability packet by repurposing a travel industry-supported New Distribution Capability communication enhancement program that facilitates efficient and secure data exchange across a distributed transaction processing network to ensure that all parties involved have access to accurate and timely transaction data for a real-time validation process, to format the retail transaction data effectively for secure data exchange across distributed systems; storing, by the mobile device, the secure electronic receipt in a digital wallet application on the mobile device; updating, by the transaction processing system, transaction status on both the point-of-sale device and the mobile device in real-time, wherein the transaction status… and a summary of the transaction details; the user can initiate a return process directly from the mobile device by deselecting returned items on the secure electronic receipt within the digital wallet application, wherein the modification triggers an update to the transaction and adjusts the account of the user accordingly; notifying, by the mobile device, the point-of-sale device of an initiated return process to update an inventory system of a merchant accordingly; and generating, by the control object payment processor, a new secure electronic receipt reflecting a modified transaction post-return, including an updated total transaction amount and an indication of the returned items,
Lin teaches,
the user can initiate a return process directly from the mobile device by deselecting returned items on the secure electronic receipt within the digital wallet application, wherein the modification triggers an update to the transaction and adjusts the account of the user accordingly;
(Lin [0143] After the receipt has been sent
Lin [0221] The device 10 may then receive receipt information... may transmit (block 624) the receipt to the customer.
Lin [0009] performing returns and exchanges.
Lin [0117] may be selected to process a return, to exchange one article of merchandise for another
Lin [0223] graphical elements 636, 638, and 640 may be selected to perform a price check, a return, and an exchange
Lin [0252] slide bars 792 may be actuated between the yes and no positions using the touch screen to select or deselect each of the options listed.
Lin [0101] the customer's electronic device may include an electronic wallet application
Lin [0237] the customer may receive a cash refund or have one of her accounts...credited with the refund amount.)
notifying, by the mobile device, the point-of-sale device of an initiated return process to update an inventory system of a merchant accordingly; and
(Lin [0008] device may calculate the amount due and may retrieve inventory and price information
Lin [0220] may update an inventory database)
generating, by the control object payment processor, a new secure electronic receipt reflecting a modified transaction post-return, including an updated total transaction amount and an indication of the returned items,
(Lin [0221] device 10 may then receive receipt information......device 10 may transmit (block 624) the receipt to the customer. However, in other embodiments, the device 10 may transmit the receipt information to the server 96 for subsequent transmission to the customer.
Lin [0008] device may calculate the amount due and may retrieve inventory and price information
Lin [0293] device 10 may update the display to show the article within an order summary...may update the total purchase price )
It is prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the dynamic invoice receipt of Vintila to incorporate the returns and exchanges of Lin for “performing returns and exchanges.” (Lin [0009]). The modification would have been obvious, because it is merely applying a known technique (i.e. returns and exchanges) to a known concept (i.e. dynamic invoice receipt) ready for improvement to yield predictable result (i.e. “graphical elements … may be selected to perform a price check, a return, and an exchange” Lin [0223])
Lin does not teach encryption standard with a key length of at least 256 bits; upon user validation, encoding, by the mobile device, the user-validated transaction data into a new distribution capability packet by repurposing a travel industry-supported New Distribution Capability communication enhancement program that facilitates efficient and secure data exchange across a distributed transaction processing network to ensure that all parties involved have access to accurate and timely transaction data for a real-time validation process, to format the retail transaction data effectively for secure data exchange across distributed systems; storing, by the mobile device, the secure electronic receipt in a digital wallet application on the mobile device; updating, by the transaction processing system, transaction status on both the point-of-sale device and the mobile device in real-time, wherein the transaction status… and a summary of the transaction details;
Pitroda teaches,
encryption standard with a key length of at least 256 bits
(Pitroda [0729] The AES cipher supports 128, 192 and 256 bit encryption
Pitroda [0732] fact that the shared secret key is 256 bit strong AES key)
upon user validation, encoding, by the mobile device, the user-validated transaction data into a new distribution capability packet
(Pitroda [0125] personal client device may be selected from the group consisting of a PC, a mobile phone
Pitroda [0099] contingent on a user and request validation.
Pitroda [0306] Web services may be delivered via a distributed infrastructure and/or a secure Web services protocol, such as distributed servers that (1) may be utilizing XML digital signatures and/or XML encryption)
storing, by the mobile device, the secure electronic receipt in a digital wallet application on the mobile device;
(Pitroda [0041] methods and systems may also include the step of storing the transaction receipt in the memory
Pitroda [0044] receipts are stored on the client facility.
Pitroda [0084] may include providing a mobile wallet in association with a universal electronic transaction facility.)
updating, by the transaction processing system, transaction status on both the point-of-sale device and the mobile device in real-time, wherein the transaction status
(Pitroda [0041] methods and systems may also include the step of storing the transaction receipt in the memory
Pitroda [0044] receipts are stored on the client facility.
Pitroda [0084] may include providing a mobile wallet in association with a universal electronic transaction facility.
Pitroda [0684] involving interaction with a merchant....synchronizes a merchant system...the merchant system 170 validates the user using the main services facility 142/transaction platform.
Pitroda [0033] comprises the display of a status associated with a transaction
Pitroda [0021] a merchant facility can include or be hosted by any device with a processor, such as a point of sale terminal, cash register, personal computer, laptop computer, cellular phone, PDA, processor-equipped retail display, kiosk
Pitroda [0351] a local area networking facility supporting wired or wireless network protocols)
and a summary of the transaction details;
(Pitroda [0054] data may be one or more instances of one or more of the following things: a receipt, a statement,... a transaction summary)
It is prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the dynamic invoice receipt of Vintila to incorporate the 256 bit encryption of Lin where “AES cipher supports 128, 192 and 256 bit encryption.” (Pitroda [0729]). The modification would have been obvious, because it is merely applying a known technique (i.e. 256 bit encryption) to a known concept (i.e. dynamic invoice receipt) ready for improvement to yield predictable result (i.e. “implement a very lightweight crypto engine…. with the performance optimised for low-capability clients.” Pitroda [0729])
Pitroda does not teach by repurposing a travel industry-supported New Distribution Capability communication enhancement program that facilitates efficient and secure data exchange across a distributed transaction processing network to ensure that all parties involved have access to accurate and timely transaction data for a real-time validation process, to format the retail transaction data effectively for secure data exchange across distributed systems;
Ettl teaches,
repurposing a travel industry-supported New Distribution Capability communication enhancement program that facilitates efficient and secure data exchange across a distributed transaction processing network to ensure that all parties involved have access to accurate and timely transaction data for a real-time validation process, to format the retail transaction data effectively for secure data exchange across distributed systems;
(Ettl [0029] on a computer or mobile device or the like.
Ettl [0002] New Distribution Capability (NDC) is a travel industry-supported program launched by International Air Transport Association (IATA) for the development and market adoption of a new, extensible markup language (XML)-based data transmission standard. NDC Shopping schemas enable airlines to distribute their full product offers and to merchandize their baggage, seat choices and ancillary services.)
It is prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the dynamic invoice receipt of Vintila to incorporate the XML-based data transmission standard of Ettl where “New Distribution Capability (NDC) … extensible markup language (XML)-based data transmission standard.” (Ettl [0002]). The modification would have been obvious, because it is merely applying a known technique (i.e. XML-based data transmission standard) to a known concept (i.e. dynamic invoice receipt) ready for improvement to yield predictable result (i.e. “NDC Shopping schemas enable airlines to distribute their full product offers and to merchandize their baggage, seat choices and ancillary services.” Ettl [0002])
Claim 34 is rejected on the same basis as Claim 33.
Response to Remarks
Applicant's arguments filed on March 11, 2026, have been fully considered and Examiner’s remarks to Applicant’s amendments follow.
Response Remarks on Claim Rejections - 35 USC § 101
The Applicant states:
“even if the claim were considered to recite elements that could be characterized as managing commercial transactions (a certain method of organizing human activity), the claim as a whole is not directed to an abstract idea. …the claim integrates any purported judicial exception into a practical application …. such as lack of real-time transparency, vulnerability to errors and fraud, inefficient data exchange, and inability to dynamically handle network failures or post-transaction adjustments..."
Examiner responds:
Examiner appreciates that Applicant recognizes the existence of “elements that could be characterized as managing commercial transactions (a certain method of organizing human activity)”. So, the question becomes whether the additional elements integrate the abstract idea into a practical application.
The “lack of real-time transparency, vulnerability to errors and fraud, inefficient data exchange, and ….post-transaction adjustments” all express abstract ideas as well.
The “ability to dynamically handle network failures” may provide groundwork for integration into a practical application should adequate technological features exist.
The Applicant states:
“The integration into a practical application is evident from the specific, ordered combination of steps that enable real-time customer oversight and control, while enhancing security and efficiency."
Examiner responds:
The generic technological components function as designed with no unexpected results.
In the absence of unexpected results, changes or alteration of sequence do not make for a patentable invention, see Ex parte Rubin, 128 USPQ 440 (Bd. App. 1959) ; In re Burhans, 154 F.2d 690, 69 USPQ 330 (CCPA 1946); In re Gibson, 39 F.2d 975, 5 USPQ 230 (CCPA 1930)
The Applicant states:
“Unlike generic transaction processing, these features reflect a particular machine or transformation under MPEP § 2106.05(c)…. as the ordered combination of elements is unconventional and inventive"
Examiner responds:
No specialized device nor particular machine exists. The Applicant’s Specification reads:
“[0054] Terms like "computers", "machines," and similar phrases are interchangeably used herein, ... refer to devices that can be general-purpose...either virtual or physical... This includes all relevant hardware, software, and components familiar to those with expertise in the area.....like application-specific integrated circuits (ASICs), microprocessors, cores, or other processing units to execute, access, control, or implement various types of software, instructions, data, modules, processes, or routines as mentioned. The usage of these terms in the text is not intended to be limiting or exclusive to any specific kinds of electronic devices or components and should be interpreted in the widest sense by those with relevant expertise. Specific details on computer/software components, machines, etc., are not provided
As noted earlier, in the absence of unexpected results, changes or alteration of sequence do not make for a patentable invention, see Ex parte Rubin, 128 USPQ 440 (Bd. App. 1959) ; In re Burhans, 154 F.2d 690, 69 USPQ 330 (CCPA 1946); In re Gibson, 39 F.2d 975, 5 USPQ 230 (CCPA 1930)
Therefore, the rejection under 35 USC § 101 remains.
Response Remarks on Claim Rejections - 35 USC § 103
Applicant's amendments required the application of new/additional prior art.
Applicant’s remarks regarding the rejection made under 35 USC § 103 are rendered moot by the introduction of new prior art.
Therefore, the rejection under 35 USC § 103 remains.
Prior Art Cited But Not Applied
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Hagen (“VERIFICATION OF ITEMS BY AUTOMATED CHECKOUT SYSTEM”, U.S. Publication Number: 20230147176 A1) for verifying items in a retail environment includes a physical shopping cart including a first set of sensors, and an automated checkout station including a second, different set of sensors. The physical shopping cart receives item verification data for verifying an item, detects the item as it enters the physical shopping cart, and performs a primary verification of the item. The automated checkout station obtains a virtual shopping cart that corresponds to the physical shopping cart. The virtual shopping cart includes a list of items that have been placed in the physical shopping cart, and a verification status of each item. The second, different set of sensors generate station sensor data that represents the physical shopping cart and the items in the physical shopping cart. A secondary verification of the physical shopping cart and its contents is performed by the automated checkout station.in view of
Manchireddy (“AUDIBLE AUTHENTICATION”, U.S. Publication Number: 20200168229 A1), A digital assistant device receives a biometric sample from a user and then converts the biometric sample to a biometric template. The digital assistant device can scan for user devices in communication range of the digital assistant device, thereby receiving user device identifiers. The digital assistant device can transmit, to a server computer, an authentication request comprising the biometric template and at least one user device identifier. The digital assistant device can then receive a cryptogram request message comprising the at least one user device identifier, from the server computer. The digital assistant device can transmit, to a user device corresponding to the at least one user device identifier, the cryptogram request message and can then receive a cryptogram. The digital assistant device can then transmit the cryptogram to the server computer. The server computer verifies the cryptogram before further processing of a transaction.
Rellas (“DISTRIBUTION OF PRODUCTS”, U.S. Publication Number: 20140201001 A1) where information is maintained that associates competitors with respective territories for which the competitors have rights that are to be exclusive relative to other competitors for items associated with the territories. A user can enter, through a user interface, an expression of interest that can be associated with one of the territories. In response to the expression of interest, a user is automatically enabled to interact with the competitor that has the exclusive right to the territory, without automatically enabling the user to interact with a competitor that does not have the exclusive right.
Hertel (“SECURED ELECTRONIC TRANSACTION SYSTEM”, U.S. Publication Number: 20090288012 A1) for a unified and integrated configuration that is composed of a payment system, an advertising system, and an identity management system as well as their associated methods such that the unified system has all of the benefits of the individual systems as well as several additional synergistic benefits. Also described are specific configurations (subsystems and/or methods) including the system's access point architecture, a user interface that acts as a visual wallet simulator, a security architecture, coupon handling as well as the system's structure and means for delivering them as targeted advertising, business card handling, membership card handling for the purposes of login management, receipt handling, and the editors and grammars provided for customizing the different types of objects in the system as well as the creation of new custom objects with custom behaviors. The configurations are operable on-line as well as through physical presence transactions, e.g., mobile transaction through a mobile phone or dedicated device at a physical site for a transaction.
Gueroult (“PAYMENT PREPARATION ORCHESTRATION FOR A PAYMENT MANAGEMENT SYSTEM”, U.S. Publication Number: 20240394703 A1) for implementing a payment preparation orchestration process for travel management systems. A payment request including a travel record identification is received at a payment preparation orchestration server via a payment preparation user interface. A payment identification is associated with the travel record identification, and the payment preparation user interface provides access to a plurality of payment processor servers. The payment preparation orchestration server obtains eligible payment processor information associated with the travel record identification from a reservation system. The payment preparation orchestration server accesses a first software development kit (SDK) from a first payment provider and a second SDK from a second payment provider based on the eligible payment processor information. The payment preparation orchestration server then updates the payment preparation user interface with a first interface element associated with the first SDK and a second interface element associated with the second SDK.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHINEDU EKECHUKWU whose telephone number is (571)272-4493. The examiner can normally be reached on Mon-Fri 9 AM ET to 3:30 PM ET.
Examiner interviews are available via telephone 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, Christine Tran, can be reached on (571) 272-8103. 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.
/C.E./Examiner, Art Unit 3695
/CHRISTINE M Tran/ Supervisory Patent Examiner, Art Unit 3695
Prosecution Insights