Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
This Office Action is in response to Applicant’s communication filed on October 23, 2024 for the patent application 18/924,452. Claims 1 – 20 are pending in the application.
Information Disclosure Statement
The Information Disclosure Statement (IDS) submitted on October 23 2024 was filed in compliance with the provisions of 37 CFR 1.97. Accordingly, this Information Disclosure Statement is being considered by the Examiner.
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.
Claim(s) 1 – 20 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to an abstract idea without significantly more.
Claims 1 - 20 are either directed to a method or system or computer readable medium, which are statutory categories of invention. (Step 1: YES).
The Examiner has identified method claim 1 as the claim that represents the claimed invention for analysis and is similar to system claim 8 and computer readable claim 15. Claim 1 recites the limitations of:
( A ) initiating, at a point-of-sale (POS) terminal, a transaction using a payment vehicle comprising data included in an embedded microchip;
( B ) transmitting, from the POS terminal, a payment transaction request to the payment processing system, the payment transaction comprising the data;
( C ) authenticating, by the payment processing system, the payment transaction request;
( D ) in response to the authenticating, determining, by the payment processing system, that the payment vehicle is a parallel payment vehicle;
( E ) determining, by the payment processing system, that the parallel payment vehicle is compatible with a merchant system associated with the POS terminal;
( F ) determining, by the payment processing system, a plurality of merchant program options associated with the merchant system, a plurality of user payment preferences, and an available balance of the parallel payment vehicle;
( G ) determining, by the payment processing system, that the user payment preferences include automatic redemption associated with the parallel payment vehicle;
( H ) determining, by the payment processing system, that the available balance of the parallel payment vehicle is greater than or equal to an amount associated with the transaction; and
( I ) reducing, by the payment processing system, the available balance of the parallel payment vehicle by the amount associated with the transaction.
These limitations without the bolded limitations above, cover performance of the limitations as certain methods of organizing human activity under their broadest reasonable interpretation.
More specifically, these limitations cover performance of the limitations as a fundamental economic practice.
In summary, if claim 1 limitations, under its broadest reasonable interpretation, covers performance of the limitation as a fundamental economic practice, then it falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. Accordingly, the claim recites an abstract idea. Claims 8 and 15 are also abstract for similar reasons. (Step 2A-Prong 1: YES. The claims are abstract).
The use of the payment processing system or any of the bolded limitations in claim 1 are just applying generic computer components to the recited abstract limitations. Similar arguments apply to claims 8 and 15.
Therefore, the above mentioned judicial exception is not integrated into a practical application by merely applying generic computer components (bolded elements).
Furthermore, the “initiating” and “reducing” steps are recited at a high level of generality and amounts to mere data gathering/transmitting, which are forms of insignificant extra-solution activity (See MPEP 2106.05(g): CyberSource v. Retail Decisions, Inc., 654 F.3d 1366, 1375 (Fed. Cir. 2011); and OIP Techs., Inc. v. Amazon.com, Inc., 788 F.3d 1359, 1363 (Fed. Cir. 2015)).
In addition, supported by specification, the computer hardware 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 component., see MPEP 2106.05(f), where applying a computer or using a computer is not indicative of a practical application).
Claim 1, limitation ( A ), ( B ) and ( E ) above in Applicant’s specification para [0019], which discloses “To address the above-noted problems, the present disclosure describes systems and methods that execute payment transactions of a parallel payment vehicle that may include the functionality and aspects of both open-loop and closed-loop payment vehicles. For example, a processing system including a parallel payment system, a transaction system, and a tokenization system of the present disclosure may execute payment transactions of a parallel payment vehicle. The parallel payment system may determine whether a payment vehicle of a customer received at a merchant's point of sales (POS) terminal or a merchant's e-commerce website on a browser is a parallel payment vehicle. In one embodiment, the merchant's POS terminal may also be configured to determine whether the payment vehicle received is a parallel payment vehicle. Upon deter-mining the payment vehicle is a parallel payment vehicle, the processing system may execute the payment transaction associated with the parallel payment vehicle based on an open-loop or a closed-loop payment transaction process. The payment transaction may be executed by the processing system based on the customer's preferences for utilizing an open-loop payment account or a closed-loop payment account associated with the parallel payment vehicle.“.
Also, claim 1, limitation ( A ), ( D ), ( E ), ( F ), ( H ) and ( I ) above in Applicant’s specification para [0024], which discloses “Referring now to the appended drawings, FIG. 1 depicts an exemplary system 100 including a point of service (POS) terminal 110, a browser 115, a merchant system(s) 120, and a processing system 130, which is in communication with a transaction network(s) 160. The POS terminal 110 may collect data of a payment vehicle 106 (e.g., credit card, debit card, gift card, loyalty card, bonus points card, digital payment device, digital wallet, etc.) from a user 105 and transfer the data of the payment vehicle 106 securely to the processing system 130. The payment vehicle 106 (e.g., credit card, debit card, contactless payment device, digital payment device, digital wallet, etc.) may be an open-loop payment vehicle, a closed-loop payment vehicle, or a parallel payment vehicle (e.g., a payment vehicle including both functionality and aspects of an open-loop payment vehicle and a closed-loop payment vehicle).“. Similar arguments apply to claims 8 and 15.
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.
Therefore, claims 1, 8 and 15 are 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).
The claims 1 , 8 and 15 do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when considered separately and as an ordered combination, they do not add significantly more (also known as an “inventive concept”) to the exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements (bolded elements above) amount to no more than mere instructions to apply the abstract idea using generic computer components. In conclusion, merely "applying" the exception using generic computer components cannot provide an inventive concept. Therefore, the claims 1, 8, and 15 are not patent eligible under 35 USC 101. (Step 2B: NO. The claims do not provide significantly more).
Dependent Claims
Dependent claims 2 – 7, 9 - 14 and 16 - 20 are also rejected under 35 U.S.C. 101. Dependent claims 2 – 7, 9 - 14 and 16 - 20 are further define the abstract idea or further define the extra-solution activities that are present in independent claim 1 thus abstract idea correspond to certain methods of organizing human activity as presented above. Claims 2 – 7, 9 - 14 and 16 - 20 clearly further define the abstract idea as stated above and further define extra-solution activities such as presenting data and transmitting/receiving data.
Furthermore, dependent claims 2 – 7, 9 - 14 and 16 - 20 do 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.
Regarding claims 2 and 9, these claims merely recite additional steps that amount to no more than insignificant extra-solution activity. Specifically, claim 2 states “encrypting the data into a token using a tokenization system associated with the payment processing system.”. These steps amount to no more than mere data gathering/analysis, which is a form of insignificant extra- solution activity (See M PEP 2016.05(g): CyberSource v. Retail Decisions, Inc., 654 F.3d 1366, 1375 (Fed. Cir. 2011); and GIP Techs., Inc. v. Amazon.com, Inc., 788 F.3d 1359, 1363 (Fed. Cir. 2015)). Such limitations do not integrate the abstract idea into a practical application, or amount to significantly than the abstract idea, because the courts have found the concept of data gathering to be well-understood, routine, and conventional activity (See MPEP 2106.05(d): GIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363 (Fed. Cir. 2015); and buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, (Fed. Cir. 2014)). Similar arguments can be made for claim 9.
Regarding claims 3, 10 and 17, these claims merely recite, "determining, upon analysis of the token by the payment processing system, a type of the payment vehicle, the type of the payment vehicle being at least one of: a first type, a second type, or a combination type, wherein the combination type leverages first type data objects and second type data objects.“. These limitation merely recites storing data in a server which amounts to no more than gathering/storing data which is a form of insignificant extra-solution activity (See MPEP 2106.0S(g)(3)(iii): GIP Technologies, 788 F.3d at 1363). This does not integrate the abstract idea into a practical application because it has been determined, by the courts, that the concept of storing data is well-understood, routine, and conventional activity (See MPEP 2106.0S(d)(II): Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334 (Fed. Cir. 2015)). Similar arguments can be made for claims 10 and 17.
Regarding claims 4, 11 and 18, these claims merely recite, "displaying, on a display screen of the POS terminal, a graphical user interface presenting the plurality of merchant program options including: A) one or more first type options and one or more second type options and B) one or more priority options that define a payment processing priority order for the one or more first type options and/or the one or more second type options during a processing of the transaction.“. These limitation merely recites storing data in a server which amounts to no more than gathering/storing data which is a form of insignificant extra-solution activity (See MPEP 2106.0S(g)(3)(iii): GIP Technologies, 788 F.3d at 1363). This does not integrate the abstract idea into a practical application because it has been determined, by the courts, that the concept of storing data is well-understood, routine, and conventional activity (See MPEP 2106.0S(d)(II): Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334 (Fed. Cir. 2015)). Similar arguments can be made for claim 11 and 18.
Regarding claims 5 and 19, these claims merely provide further detail regarding selection preferences, recited in claims 1 and 15. Merely stating “receiving, at a graphical user interface of the POS terminal, the plurality of user payment preferences via selections from a user at the graphical user interface, the plurality of user payment preferences identifying a predetermined order of use of one or more types of the payment vehicle.". This does not integrate the abstract idea into a practical application because it does not impose any meaningful limitation on practicing the abstract idea. Similar arguments can be made for claim 19.
Regarding claims 6, 13 and 20, These claims merely add further description to the process of “determining, by the payment processing system, that the user payment preferences does not include automatic redemption associated with the parallel payment vehicle; and processing, by the payment processing system, the transaction according to an open-loop payment process.”. This amount to no more than mere data gathering/outputting as described in reference to claims 1, 8 and 15 (see analysis above). Merely describing the comparing the new claim information does not integrate the abstract idea into a practical application, or amount to significantly more than the judicial exception, because it does not impose any meaningful limitations on practicing the abstract idea. Similar arguments can be made for claims 13 and 20.
Regarding claims 7 and 14, these claims merely recite, "determining, by the payment processing system, that the available balance of the parallel payment vehicle is less than or equal to an amount associated with the transaction; and reducing, by the payment processing system, the available balance of the parallel payment vehicle to a value of zero.“. These limitation merely recites storing data in a server which amounts to no more than gathering/storing data which is a form of insignificant extra-solution activity (See MPEP 2106.0S(g)(3)(iii): GIP Technologies, 788 F.3d at 1363). This does not integrate the abstract idea into a practical application because it has been determined, by the courts, that the concept of storing data is well-understood, routine, and conventional activity (See MPEP 2106.0S(d)(II): Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334 (Fed. Cir. 2015)). Similar arguments can be made for claim 14.
As a result, such limitations do not overcome the requirements as described above. Therefore, claims 2 – 7, 9 - 14 and 16 - 20 are directed to an abstract idea. Thus, claims 1 - 20 are not patent eligible.
Claim Rejections – 35 USC §103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1 – 20 are rejected under 35 U.S.C. 103 as being obvious over Louis J. Krouse et al. (Pat. # US 6,097,834 – herein referred to as Krouse) in view of Edison U. Ortiz et al. (Pub. # US 2018/0253727 A1 – herein referred to as Ortiz) and further in view of Meredith Altenhofen et al. (Pub. # US 2018/0322489 A1 – herein referred to as Altenhofen).
Re: Claim 1, Krouse discloses a computer-implemented method for executing a parallel payment vehicle transaction by a payment processing system, the method comprising:
initiating, at a point-of-sale (POS) terminal, a transaction using a payment vehicle comprising data included in an embedded microchip (Krouse, col. 1, lines 29 – 46 – Many systems and methods exist in the prior art for electronically processing and/or executing financial transactions. For example, debit card systems exist wherein EFT and/or ACH transactions may be authorized to pay for goods or services at the point of sale (e.g., at the merchant or retailers place of business, and/or at the location of third party transaction agent for the merchant or retailer). Such systems typically include a mechanism for reading customer bank account information encoded on a magnetic strip on the customer's debit card, which information is then utilized by the system to generate an EFT or ACH request from the customer bank account to the payee's bank account (e.g., the retailer's or merchant's bank account). Typically, prior to executing the EFT or ACH request, the system requires the customer to input a pre-selected Personal Identification Number (PIN) or other type of authorization information associated with the debit card being used in the transaction, and unless the pre-selected PIN or authorization information is input correctly, the system will not execute the request.);
transmitting, from the POS terminal, a payment transaction request to the payment processing system, the payment transaction comprising the data (Krouse, col. 8, lines 1 – 12 – A copy of the numeric data is also transmitted from the processor 40 to the authorization record generator 38, which also retrieves from the storage system 42 the payee and payment amount data associated with this trans5 action and transmits same to the generator 38. Processor 40 also supplies to the generator 38 from the storage system 42 data indicative of the initiation of the current transaction. Preferably, each of the terminals 18, 20, 22 of the system 10 is associated with a unique station/terminal identification code or number which is stored in the terminal's respective storage system 42. This terminal identification number is also supplied to the generator 38 from the system 42.);
determining, by the payment processing system, that the parallel payment vehicle is compatible with a merchant system associated with the POS terminal (Krouse, col. 18, lines 47 – ? – Also, although various of the functional components of the systems of the first and second aspects of the present invention (e.g., recognizer 32, processor 40, record generator 38, interfaces 44, 48, 56, 58, 60, transaction generator 52, and controller of system 10; image characterization generator 204, comparator 220, location generator 218, image processor 216, request generator 224, and interfaces 226, 230) preferably are embodied in whole or in part as one or more distributed computer program processes running on one or more conventional general purpose computers (e.g., IBM-compatible 80X86 based, Apple MacIntosh, and/or RISC microprocessor based computers), conventional telecommunicat10ns devices (e.g.: TCP/IP, and/or ISDN means) networked together by conventional hardware and software, other types of computers, telecommunications, and network devices may be used without departing from the present invention.);
determining, by the payment processing system, a plurality of merchant program options associated with the merchant system, a plurality of user payment preferences, and an available balance of the parallel payment vehicle (Krouse, col. 2, lines 11 – 24 – Furthermore, under present banking regulations, although there is no limit to the number of times EFT or ACH transactions refused due to insufficient funds can be resub-mitted for payment, a check returned to the merchant for insufficient funds can only be once re-submitted to the banking system for payment. This means that once a check has twice been returned to a merchant for insufficient funds, the merchant must seek to obtain payment for the goods and/or services provided in exchange for the check via means outside the banking system (e.g., by contacting the customer or payor of the check, turning the check over to a collection agency, and/or turning to litigation). Each of these options involves expenditures of time, money, and other resources by the merchant.);
determining, by the payment processing system, that the user payment preferences include automatic redemption associated with the parallel payment vehicle (Krouse, col. 6, lines 34 – 54 – Preferably, if the point of sale 12 is the premises of a third party payment agent for the merchant or retailer that is actually providing the goods or services for which payment is being effected by tender of the negotiable instrument 110, prior to placing the document 110 in the scanner 34, the human operator of the payment terminal 18 inputs (e.g., as a result of or after tallying the purchases being paid for by the check 110) to the processor 40 via the device 30 data indicative of both the amount of the payment and the payee to which the payment is being made (i.e., the payment amount indicated on the negotiable instrument being tendered in payment). Preferably, there is permitted to be only one payee per transaction. Alternatively, if the point of sale is the merchant's or retailer's premises, negotiable instruments processed via the terminal at that point of sale will presumably only be made out to a single payee (i.e., the merchant or retailer at the point of sale); in such instances, the human operator may simply input data indicative of the amount of the payment being made, and the processor 40 may be adapted to automatically associate appropriate payee identification data with the inputted payment amount data.);
determining, by the payment processing system, that the available balance of the parallel payment vehicle is greater than or equal to an amount associated with the transaction (Krouse, col. 17, lines 18 – 46 – user/customer to accomplish this. The information obtained from reading the customer's debit card and provision of the customer's PIN via the interface 206 may then be utilized by the generator 224, together with the aforesaid billing information, to generate an ACH EFT request to transfer funds from the customer's bank account (indicated via the debit card information) to the bill payee's bank account, to pay the customer's bill as indicated on the billing document 400. This request is transmitted from the generator 224 to the ACH/EFT system via the interface 226, and a copy of said request is stored in the archive 228 in association with the other billing information and scanned image obtained from the document 400 by the system 200. Once the ACH system notifies the generator 224 that the request has been executed, the generator 224 provides to the payee system 232 via the interface 230 a copy of the notice, the submitted ACH/EFT request, and a statement of the customer's billing account number in order to permit the payee 232 to update its records to reflect the customer's payment to reduce the outstanding balance of the customer's billing account. Alternatively, the ACHIEFT request may be forwarded by the generator 224 to the payee 232 via the interface 230 for submission by the payee 232 directly to the ACH/EFT system. The archive 228 may also be adapted to permit the payee 232 to access the other information associated with the payee (e.g., the particular EFT requests generated for effectuating payment of bills generated by that payee and scanned images of such bills) stored in the archive 228.); and
reducing, by the payment processing system, the available balance of the parallel payment vehicle by the amount associated with the transaction (Krouse, col. 17 lines 30 – 46 – Once the ACH system notifies the generator 224 that the request has been executed, the generator 224 provides to the payee system 232 via the interface 230 a copy of the notice, the submitted ACH/EFT request, and a statement of the customer's billing account number in order to permit the payee 232 to update its records to reflect the customer's payment to reduce the outstanding balance of the customer's billing account. Alternatively, the ACHIEFT request may be forwarded by the generator 224 to the payee 232 via the interface 230 for submission by the payee 232 directly to the ACH/EFT system. The archive 228 may also be adapted to permit the payee 232 to access the other information associated with the payee (e.g., the par- EFT requests generated for effectuating payment of bills generated by that payee and scanned images of such bills) stored in the archive 228.).
However, Krouse does not expressly disclose:
authenticating, by the payment processing system, the payment transaction request;
in response to the authenticating, determining, by the payment processing system, that the payment vehicle is a parallel payment vehicle.
In a similar field of endeavor, Ortiz discloses:
authenticating, by the payment processing system, the payment transaction request (Ortiz, [0041] – In further embodiments, trusted platform(s) in accordance with the invention may be used to authenticate and/or otherwise complete transactions based on identity, such that for example users may in effect be enabled to pay for, or otherwise control the processing of, transactions based on their personal identities, or information uniquely association with their identities. In such transactions signal data associated with such a user's identity can be received and registered, or otherwise validated and verified, through a strict onboarding process and maintained at a server in the trusted platform, and thereafter relied upon as pre-authorized for purposes of adjudicating transactions. Each individual purchaser or other transaction initiator (human or juristic) may have or be associated with multiple identities, for example in different jurisdictions or in different trans-actional contexts, for different social media platforms, for particular online services (iTunes), etc.);
in response to the authenticating, determining, by the payment processing system, that the payment vehicle is a parallel payment vehicle (Ortiz, [0142] – To initiate a transaction, a user may execute a merchant application 114, 630 on a device 110, 600 and select an item (good or service) to be purchased. For example, upon accessing a merchant application 114, 630, the user can use any suitably-configured keyboards, key-pads, pointers, touch screen devices, and/or other input/ output device(s) 610 in conjunction with suitably-configured user interface display screens to designate such goods or services. As part of a checkout sequence, merchant application 114, 630 may then transmit (directly of via any other suitable components, such as mPOS or POS device(s) 132, 134) a request to merchant backend 136, 910 for provision of the certificate issued to the merchant by certification authority 120, 905. After the request has been fulfilled, merchant application 114, 630 may then use the received merchant's certificate to query wallet application 114, 630 for permission to access payment credentials, such as HCE tokens. In some cases, merchant application 114, 630 may query wallet application 112, 622 automatically following receipt of the merchant's certificate from merchant backend 136, 910. Alternatively, merchant application 114, 630 may display a prompt to the user asking for express authorization to query wallet application 112, 622.).
Therefore, in light of the teachings of Ortiz, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify the method of Krouse, motivation according to one KSR Exemplary Rationale where a known technique is used to improve similar methods and systems in the same way by provide an improved systems, methods, and programming structures for the secure negotiation, authorization, execution, and confirmation of multi-party and multi-device data processes, including particularly transactions involving
multiple potential payment or funding sources.
Re: Claim 2, Krouse in view of Ortiz discloses the computer-implemented method of claim 1, further comprising:
encrypting the data into a token using a tokenization system associated with the payment processing system (Ortiz, [0051] – Following selection by the user of the requesting device, or by the virtual wallet, of one or more payment options, the virtual wallet may respond to the merchant application, via communications subsystems of the requesting device, with a token or credential representing the selected method(s) or source(s) of payment of the user. The merchant application may then transmit the received token or credential to the merchant server along with other information needed to complete the transaction. Payment information sent to the merchant server may be encrypted so that the merchant may not be able to view or otherwise access any of the user's sensitive information. Encryption of the payment information may be performed by the virtual wallet prior to transmission to the merchant application, by the merchant application, or by some other application or pro-gram on the requesting communication device. To complete transactions and process the selected payment, the merchant server may forward the token or payment credential received from the virtual device and other required transaction information to a payment gateway or other transaction processor.). The rationale for support of motivation, obviousness and reason to combine see claim 1 above.
Re: Claim 3, Krouse discloses the computer-implemented method of claim 2, further comprising:
determining, upon analysis of the token by the payment processing system, a type of the payment vehicle, the type of the payment vehicle being at least one of:
a first type, a second type, or a combination type, wherein the combination type leverages first type data objects and second type data objects (Krouse, col. 2, lines 48 – 62 – Systems and methods also exist in the prior art for effectuating payment of bills or accounts payable via EFT and/or ACH transactions. For example, various commercially available computer software programs exist for electronically paying bills based upon information (e.g., bill payee, amount due, etc.) manually input to the program by a human user, or provided to the program from a previously generated file containing such information. Disadvantageously, such programs require a significant amount of human operator interaction which can slow the process of paying bills using such programs. Further disadvantageously, such programs are subject, to a significant degree, to human operator errors (e.g., input of erroneous payment information), which can result in generation of erroneous electronic bill payments.).
Re: Claim 4, Krouse discloses the computer-implemented method of claim 1, further comprising:
displaying, on a display screen of the POS terminal, a graphical user interface presenting the plurality of merchant program options including:
A) one or more first type options and one or more second type options (Krouse, col. 6, lines 34 – 54 – Preferably, if the point of sale 12 is the premises of a third party payment agent for the merchant or retailer that is actually providing the goods or services for which payment is being effected by tender of the negotiable instrument 110, prior to placing the document 110 in the scanner 34, the human operator of the payment terminal 18 inputs (e.g., as a result of or after tallying the purchases being paid for by the check 110) to the processor 40 via the device 30 data indicative of both the amount of the payment and the payee to which the payment is being made (i.e., the payment amount indicated on the negotiable instrument being tendered in payment). Preferably, there is permitted to be only one payee per transaction. Alternatively, if the point of sale is the merchant's or retailer's premises, negotiable instruments processed via the terminal at that point of sale will presumably only be made out to a single payee (i.e., the merchant or retailer at the point of sale); in such instances, the human operator may simply input data indicative of the amount of the payment being made, and the processor 40 may be adapted to automatically associate appropriate payee identification data with the inputted payment amount data.) and
B) one or more priority options that define a payment processing priority order for the one or more first type options and/or the one or more second type options during a processing of the transaction (Krouse, col. 8, lines 12 – 24 – Generator 38 utilizes the numeric transaction data, payee and payment amount data, transaction date and time data, and terminal identification number to generate, for each point of sale financial transaction processed by the terminal, a unique respective record of the transaction for being assented to by the party tendering the negotiable instrument document being processed by the terminal. For each such transaction, the generator 38 causes the unique respective record generated by the generator 38 to be printed out by printer 36 (which comprises, e.g., a conventional laser printer) as a respective hard copy transaction record. An example of one such hard copy transaction record 70 is shown in FIG. 4.).
Re: Claim 5, Krouse discloses the computer-implemented method of claim 1, further comprising:
receiving, at a graphical user interface of the POS terminal, the plurality of user payment preferences via selections from a user at the graphical user interface, the plurality of user payment preferences identifying a predetermined order of use of one or more types of the payment vehicle (Krouse, col. 12, lines 20 – 36 – Turning now to FIG. 7, a preferred embodiment 200 of a system according to the second aspect of the present invention will be described. System 200 comprises at least one bill payment terminal 202. It should be understood that although only one such bill payment terminal 202 is shown in FIG. 7, system 200 may comprise a plurality of such terminals without departing from this aspect of the present invention. Terminal 202 comprises a user interface/display device 206 and an optical scanner 208. Device 206 preferably comprises a conventional graphical user interface and system control means or other type of human input/output, control and display means for permitting a human operator (not shown) to monitor and control operation of various of the functional components of the system 200 in the manner described more fully below. Scanner 208 preferably comprises a conventional scanner device that is substantially identical to scanner 34 of system 10.).
Re: Claim 6, Krouse in view of Ortiz discloses the computer-implemented method of claim 1, further comprising:
determining, by the payment processing system, that the user payment preferences does not include automatic redemption associated with the parallel payment vehicle (Ortiz, [0185] – POS transactions can also be improved through application of payment processes enabled by the invention, including those which enable drawing on multiple user accounts, particularly when whole or partial payment using loyalty or rewards points is desired. A user 190 of a device 110, 110' wishing to pay in such fashion can load a wallet application associated with an FI/FSP 120, 160 associated with both a funds account and a loyalty or rewards account, select an BCE-compliant funds account to be used for payment, and a points slider 1422 or similar device be displayed automatically, if points are available and eligible for redemption in the transaction. Using the device 1420 the user 190 can select how many points to redeem, and/or which portion of the payment is to be satisfied through points redemption; and when the user taps the device on a POS terminal to pay or otherwise authorizes completion of the transaction, the wallet 112 can route to the merchant system 136, 136' a transaction payment data set comprising a "hidden" data item representing the number of points to be revealed, in such fashion that the merchant system is neither informed of nor burdened with the fact that points are being used to pay some or all of the transaction price, and optionally to provide access to additional information in a data field presented only to the user 190 regarding how many points to redeem.); and
processing, by the payment processing system, the transaction according to an open-loop payment process (Ortiz, [0053] – In addition to different types of payment, tokens stored in or otherwise accessible to or controlled by, virtual wallet applications in accordance with various aspects and embodiments of the invention can include multiple tokens useful for completing payments of the same type (e.g., credit, debit, pre-paid, rewards, or loyalty), but drawn or otherwise provided from accounts held, controlled, or otherwise administered by independent FIS or FSPs, i.e., by FlS or FSPs subject to independent legal rights and obligations, and/or independent owners or administrators. Such independent FlS or FSPs can impose many different distinct requirements, including successful submission of unique security codes and/or compliance with other secure features procedures, which are all accounted for by various aspects and embodiments of the invention.). The rationale for support of motivation, obviousness and reason to combine see claim 1 above.
Re: Claim 7, Krouse discloses the computer-implemented method of claim 1, further comprising:
determining, by the payment processing system, that the available balance of the parallel payment vehicle is less than or equal to an amount associated with the transaction (Krouse, col. 17, lines 18 – 46 – user/customer to accomplish this. The information obtained from reading the customer's debit card and provision of the customer's PIN via the interface 206 may then be utilized by the generator 224, together with the aforesaid billing information, to generate an ACH EFT request to transfer funds from the customer's bank account (indicated via the debit card information) to the bill payee's bank account, to pay the customer's bill as indicated on the billing document 400. This request is transmitted from the generator 224 to the ACH/EFT system via the interface 226, and a copy of said request is stored in the archive 228 in association with the other billing information and scanned image obtained from the document 400 by the system 200. Once the ACH system notifies the generator 224 that the request has been executed, the generator 224 provides to the payee system 232 via the interface 230 a copy of the notice, the submitted ACH/EFT request, and a statement of the customer's billing account number in order to permit the payee 232 to update its records to reflect the customer's payment to reduce the outstanding balance of the customer's billing account. Alternatively, the ACHIEFT request may be forwarded by the generator 224 to the payee 232 via the interface 230 for submission by the payee 232 directly to the ACH/EFT system. The archive 228 may also be adapted to permit the payee 232 to access the other information associated with the payee (e.g., the particular EFT requests generated for effectuating payment of bills generated by that payee and scanned images of such bills) stored in the archive 228.); and
reducing, by the payment processing system, the available balance of the parallel payment vehicle to a value of zero (Krouse, col. 17, lines 26 – 46 – This request is transmitted from the generator 224 to the ACH/EFT system via the interface 226, and a copy of said request is stored in the archive 228 in association with the other billing information and scanned image obtained from the document 400 by the system 200. Once the ACH system notifies the generator 224 that the request has been executed, the generator 224 provides to the payee system 232 via the interface 230 a copy of the notice, the submitted ACH/EFT request, and a statement of the customer's billing account number in order to permit the payee 232 to update its records to reflect the customer's payment to reduce the outstanding balance of the customer's billing account. Alternatively, the ACHIEFT request may be forwarded by the generator 224 to the payee 232 via the interface 230 for submission by the payee 232 directly to the ACH/EFT system. The archive 228 may also be adapted to permit the payee 232 to access the other information associated with the payee (e.g., the particular EFT requests generated for effectuating payment of bills generated by that payee and scanned images of such bills) stored in the archive 228.).
Re: Claim 8, Claim 8 is a system claim corresponding to method claim 1. Therefore, claim 8 is analyzed and rejected as previously discussed with respect to claim 1.
Re: Claim 9, Claim 9 is a system claim corresponding to method claim 2. Therefore, claim 9 is analyzed and rejected as previously discussed with respect to claim 2.
Re: Claim10, Claim 10 is a system claim corresponding to method claim 3. Therefore, claim 10 is analyzed and rejected as previously discussed with respect to claim 3.
Re: Claim 11, Claim 11 is a system claim corresponding to method claim 4 Therefore, claim 11 is analyzed and rejected as previously discussed with respect to claim 4.
Re: Claim 12, Claim 12 is a system claim corresponding to method claim 5. Therefore, claim 12 is analyzed and rejected as previously discussed with respect to claim 5.
Re: Claim 13, Claim 13 is a system claim corresponding to method claim 6. Therefore, claim 13 is analyzed and rejected as previously discussed with respect to claim 6.
Re: Claim 14, Claim 14 is a system claim corresponding to method claim 7. Therefore, claim 14 is analyzed and rejected as previously discussed with respect to claim 7.
Re: Claim 15, Claim 15 is an apparatus claim corresponding to method claim 1 and system claim 8. Therefore, claim 15 is analyzed and rejected as previously discussed with respect to claims 1 and 8.
Re: Claim 16, Claim 16 is an apparatus claim corresponding to method claim 2 and system claim 9. Therefore, claim 16 is analyzed and rejected as previously discussed with respect to claims 2 and 9.
Re: Claim 17, Claim 17 is an apparatus claim corresponding to method claim 3 and system claim 10. Therefore, claim 17 is analyzed and rejected as previously discussed with respect to claims 3 and 10.
Re: Claim 18, Claim 18 is an apparatus claim corresponding to method claim 4 and system claim 11. Therefore, claim 18 is analyzed and rejected as previously discussed with respect to claims 1 and 11.
Re: Claim 19, Claim 19 is an apparatus claim corresponding to method claim 5 and system claim 12. Therefore, claim 19 is analyzed and rejected as previously discussed with respect to claims 5 and 12.
Re: Claim 20, Claim 20 is an apparatus claim corresponding to method claim 6 and system claim 13. Therefore, claim 20 is analyzed and rejected as previously discussed with respect to claims 6 and 13.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOHN H. HOLLY whose telephone number is (571)270-3461. The examiner can normally be reached on MON. - FRI 10 AM - 8 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, MATTHEW S. GART can be reached on 571-272-3955. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/John H. Holly/Primary Examiner, Art Unit 3696