DETAILED ACTION
Response to Amendment
This action is in response to the response to the amendment filed on 12/30/2025. Claims 1-2 have been amended. Claims 1-2 are pending and currently under consideration for patentability.
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 .
Inventorship
This application currently names joint inventors. In considering patentability of the claims under pre-AIA 35 U.S.C. 103(a), the examiner presumes that the subject matter of the various claims was commonly owned at the time any inventions covered therein were made absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and invention dates of each claim that was not commonly owned at the time a later invention was made in order for the examiner to consider the applicability of pre-AIA 35 U.S.C. 103(c) and potential pre-AIA 35 U.S.C. 102(e), (f) or (g) prior art under pre-AIA 35 U.S.C. 103(a).
Information Disclosure Statement
The information disclosure statement(s) (IDS) submitted on 12/18/2025 has been considered by the examiner.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP §§ 706.02(l)(1) - 706.02(l)(3) for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 1-2 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-19 of U.S. Patent No. 12,118,519. Although the claims at issue are not identical, they are not patentably distinct from each other because the claims in U.S. Patent No. 12,118,519 recite the entirety of limitations of claims 1-2 of the instant application. For example, in the instant application independent claims 1-2 are anticipated by claims 1, 9, and 18 of U.S. Patent No. 12,118,519 because claims 1, 9, and 18 of U.S. Patent No. 12,118,519 recite additional features such as “wherein the filter selection maintains an outgoing percentage or currency amount distributed between the multiple payment types within a predetermined period of time, and wherein the filter selection dynamically updates expected fees based on historic fees to predict likely fee amounts for each payment type,” wherein in the instant application claims 1-2 do not recite these features and are essentially broader than claims 1, 9, and 18 of U.S. Patent No. 12,118,519. Therefore claim 1 of U.S. Patent No. 12,118,519 is in essence a “species” of the generic invention of the instant application claim 1. It has been held that a generic invention is “anticipated” by a “species” within the scope of the generic invention. See In re Goodman, 29 USPQ2d 2010 (Fed. Cir. 1993). Appropriate correction is required.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-2 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claims are directed to a judicial exception (i.e., a law of nature, natural phenomenon, or abstract idea) without significantly more.
Step 1: In a test for patent subject matter eligibility, claims 1-2 are found to be in accordance with Step 1 (see 2019 Revised Patent Subject Matter Eligibility), as they are related to a process, machine, manufacture, or composition of matter. Claim 1 recites a system and claim 2 recites a method. When assessed under Step 2A, Prong I, they are found to be directed towards an abstract idea. The rationale for this finding is explained below:
Step 2A, Prong I: Under Step 2A, Prong I, claims 1-2 is directed to an abstract idea without significantly more, as they all recite a judicial exception. Claims 1-2 recite limitations directed to the abstract idea including receiving customer payment details, associated with a first payment type, for payment of an incoming amount; running a fraud check on the customer payment details wherein an error message is sent upon a fraud detection; a transaction router including a payment route optimizer for determining whether to process customer payment details through a supplier pass-through or through a payment gateway; requesting authorization data for payment of the incoming amount, storing a transaction tracking record upon receipt of the authorization data, the transaction tracking record comprising a unique key code and an allocatable amount, the allocatable amount being initialized to a value less than or equal to the incoming amount, and the unique key code being initialized to a cryptographic hash value calculated based on the authorization data and a current date and time; storing a plurality of payment type profiles, each payment type profile associating a payment type with one or more payment attributes; and in response to receiving an outgoing payment request, associated with one or more purchase types, comprising an offered key code and an outgoing amount: and generating outgoing payment details for each purchase type, associated with at least a second payment type, alternative to the first payment type, wherein the second payment type is associated with one of a second brand, organization, or group for purchase of an outgoing first purchase type and a third payment type, wherein the third payment type is associated with one of a third brand, organization, or group alternative to the first and second payment types for outgoing purchase of a second purchase type; and reducing the allocatable amount of the existing transaction record by the outgoing amount, wherein the at least second and third payment types, selected between multiple payment types, is automatically selected by a filter defined by a plurality of transaction preferences comprising one or more optimization goals in compliance with the filter, wherein each outgoing payment request is automatically processed and an outgoing payment generated for each outgoing payment without need for further user intervention. These further limitations are not seen as any more than the judicial exception. Claims 1-2 recite additional limitations including at network-connected interface, from a payment processor, in a data store; and “verifying that the offered key code matches the unique key code of an existing transaction record in the data store and that the outgoing amount is less than or equal to the allocatable amount of the existing transaction record”. A system/method for providing on-demand outgoing payment details is considered to be an abstract idea, specifically, certain methods of organizing human activity; such as commercial interactions, advertising, marketing, and sales because the claims are directed to generating payment details for authorized transactions and running a fraud check on customer payment details. A system/method for providing on-demand outgoing payment details is also considered to be an abstract idea, specifically, Mental Processes such as concepts performed in the human mind (including an observation, evaluation, judgment, opinion) because the claims are directed to receiving, storing, and generating data and the “network-connected computing system” is merely being recited as a tool to perform the abstract idea. Therefore, under Step 2A, Prong I, claims 1-2 are directed towards an abstract idea.
Step 2A, Prong II: Step 2A, Prong II is to determine whether any claim recites any additional element that integrate the judicial exception (abstract idea) into a practical application. Claims 1-2 recite additional limitations including at network-connected interface, from a payment processor, in a data store; and “verifying that the offered key code matches the unique key code of an existing transaction record in the data store and that the outgoing amount is less than or equal to the allocatable amount of the existing transaction record”. The additional limitations reciting - “at network-connected interface, from a payment processor, and in a data store” are recited in a manner that merely uses the computer (i.e. interface, processor, datastore) as the tool to perform the abstract idea. These additional elements in claims 1-2 are not found to integrate the judicial exception into a practical application because alone, and in combination, these additional elements are seen as adding the words “apply it” (or an equivalent) with the judicial exception, or mere 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), adding insignificant extra-solution activity to the judicial exception - see MPEP 2106.05(g), and generally linking the use of the judicial exception to a particular technological environment or field of use – see MPEP 2106.05(h). The additional limitations do no more than link the judicial exception to a particular technological environment or field of use, i.e. computing system, and therefore do not integrate the abstract idea into a practical application. The courts decided that although the additional elements did limit the use of the abstract idea, the court explained that this type of limitation merely confines the use of the abstract idea to a particular technological environment and this fails to add an inventive concept to the claims (See Affinity Labs of Texas v. DirecTV, LLC,). Under Step 2A, Prong II, this claim remains directed towards an abstract idea.
Step 2B: Claims 1-2 recite additional limitations including at network-connected interface, from a payment processor, in a data store; and “verifying that the offered key code matches the unique key code of an existing transaction record in the data store and that the outgoing amount is less than or equal to the allocatable amount of the existing transaction record,”. The additional limitations reciting – “at network-connected interface, from a payment processor, and in a data store;” do not integrate the judicial exception (abstract idea) into a practical application because of the analysis provided in Step 2A, Prong II. Independent claims 1-2 also recite the additional limitation – “verifying that the offered key code matches the unique key code of an existing transaction record in the data store and that the outgoing amount is less than or equal to the allocatable amount of the existing transaction record”. However, merely determining that key codes match for stored transaction records in order to verify an outgoing payment detail is seen as storing transaction records with key codes and performing electronic recordkeeping to determine/verify if key code matches. The courts have noted that “electronic recordkeeping” (See: Alice Corp. Pty. Ltd. v. CLS Bank Int'l, 573 U.S. 208, 225, 110 USPQ2d 1984 (2014) (creating and maintaining "shadow accounts"); Ultramercial, 772 F.3d at 716, 112 USPQ2d at 1755 (updating an activity log)) and “Storing and retrieving information in memory” (See: Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93) are seen as well‐understood, routine, and conventional computer functions. The independent claims do not include additional elements or a combination of elements that result in the claims amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements listed amount to no more than mere instructions to apply an exception using a generic computer component. In addition, the applicant’s specifications describe “any programmable device”, page 27 lines 15-22, for implementing the system, which do not amount to significantly more than the abstract idea of itself, which is not enough to transform an abstract idea into eligible subject matter. There is no improvement in the functioning of the computer or technological field, and there is no transformation of subject matter into a different state. Under Step 2B in a test for patent subject matter eligibility, these claims are not patent eligible.
Claim Rejections - 35 USC § 103
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.
Claim(s) 1-2 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Publication 2011/0173122 to Singhal in view of U.S. Publication 2015/0228018 to Richman and U.S. Publication 2008/0120240 to Ginter and in further view of U.S. Publication 2017/0032338 to Szollar.
With respect to Claim 1:
Singhal teaches:
A system for providing on-demand outgoing payment details, the system comprising: a memory storing computer-readable instructions that when executed by a processor cause the processor to implement (Singhal: ¶ [0134]):
a network-connected interface to receive customer payment details, associated with a first payment type, for payment of an incoming amount, wherein the incoming amount includes a combination amount of one or more purchase types (i.e. authorization message is received which comprises amount of payment transaction and bankcard info, wherein the transaction information includes a combination of different purchase types) (Singhal: Fig. 2 and ¶ [0116] “The authorization message 37A from the MAS30 as illustrated in FIG. 2 may include sending to the identity data owner, (i) name of the transaction initiating entity, date and time, and optionally an amount for a payment transaction.” Furthermore, as cited in ¶ [0118] “The system 30 has a database of mobile identity that maintains mapping of the mobile contact information with identity data of the identity data owner. The identity data would be from a group of (i) social security number, (ii) bankcards, (iii) bank account numbers, (iv) name, (vi) date of birth, and (vii) zip code.” Furthermore, as cited in ¶ [0150] “At step 100, receiving, by a financial entity which maintains accounts of a customer, (i) a bankcard originated payment authorization request from a merchant point of sale, via a card authorization network and (ii) a payee originated request for payment via an ACH.” Furthermore, element 43 of Fig. 9 illustrates items or different purchase types in a transaction list and ¶ [0095] “As a simplified illustration of the use of the preauthorize transaction list 43 of MAS system 30, the customer, using their wireless mobile device 36 and the device 36's interface 37B with the MAS 30, would create a pre-authorized transaction list 43. The items on pre-authorized transaction list 43 could be from bank checks the customer has written or has electronically authorized through their online banking bill pay service.”);
a data store configured to store: a plurality of transaction tracking records, each transaction tracking record comprising a unique key code and an allocatable amount (i.e. MAS30 stores a plurality of transaction types which are designated by a unique key and payment amount) (Singhal: ¶ [0122] “The MAS 30 has a SMS send function 70B (i) to then create an SMS message embedded with the data as 37A for a payment transaction authorization or 37B for a data release authorization, (ii) then optionally encrypt the SMS data with a pre-placed and unique key between the MAS 30 and the mobile device 36, (iii) create a time out counter based on the type of the transaction,”);
a transaction router including a payment route optimizer for determining whether to process customer payment details through a supplier pass-through or through a payment gateway (i.e. payment route optimizer determines whether to pass transaction through payment gateway or additional authorization step) (Singhal: ¶¶ [0087] [0088] “Then, in this illustration, the transaction would be performed without the mobile authorization step, when the identity data owner is aware of and has initiated an identity data driven transaction. After the transaction is completed, then, the id data owner could press another function key to enable the enable/disable flag 79. Alternatively, the enable/disable flag 79 could be automatically enabled after a time out of, let us say five minutes, without the id data owner have to press the second function key…The combined mode, it is believed would provide the optimum id data abuse protection, while letting the payment systems work as now without the authorization process and let the authorization process kick in for unauthorized or fraudulent transactions.” Furthermore, as cited in ¶¶ [0146] [0147] “As a simplified illustration, if the id data owner wrote checks and mailed to a business. The business would process the check and then submit them to business's or payee's bank. The payee's bank would then submit them via ACH to the payer or data owner's bank. The payer or receiver bank may process the request in the night time, where the SMS would be sent in the night. So that the mobile device 36 owner can read the SMS the next day and provide an accept/reject authorization. Alternatively, when the bank account payment is via online, the authorization may happen immediately. In either case, the id data owner may choose to use a pre-authorize transaction list 43 feature as described above that would reduce the need for sending SMS messages for real time mobile authorizations…As has been described earlier, a proactive mode would use the data paths C and D, and a reactive mode would use the data paths B and C. A combined mode would use the data paths B, C, and D, and the combined mode would let the authorized payment transactions to be processed normally without any delay and with an advisory message and would let the fraudulent or unauthorized transactions to be proactively rejected, as they would not be accepted.”);
the payment gateway, communicably coupled to a payment processor and configured to: request authorization data for payment of the incoming amount from the payment processor (i.e. authorization message requests authorization data for incoming transaction not on the approved list) (Singhal: ¶ [0007] “Once the transaction information is passed through the "gateway" payment processor, the transaction is processed using the same ETF/ACH rules as other electronic transfers.” Furthermore, as cited in ¶ [0103] “For those payment authorization requests that are not on the pre-authorized list, establishing a contact via the secure contact means with the bank customer to seek authorization for the payment authorization request that is not on the list.”),
store a transaction tracking record in the data store upon receipt of the authorization data, […] (i.e. authorization is record is stored in database) (Singhal: Fig. 4 and ¶ [0117] “Further, the system 30 logs an authorization event in an event log database for use as an authorization record of the transaction.” Furthermore, as cited in ¶ [0142] “When the service choice flag 77 is set, the process entity 18 sends the request to MAS 30. However, if the dollar amount in a payment transaction is less than a threshold, such as ten dollars, the process entity may not send the request to MAS 30.”),
an outgoing payment generator configured to: receive at least one outgoing payment request, associated with the one or more purchase types, comprising an offered key code and an outgoing amount (i.e. receive transaction request to process transaction using the key code and payment amount) (Singhal: Fig. 7 and ¶ [0109] “Hence, the system 10 has a transaction processing entity 18 in the form of a payer's bank after receiving the identity data driven transaction from a transaction initiating entity or a payee's bank 16 via ACH 20, puts on hold processing of the transaction for a period of time and via the identity data owner's wireless mobile communication device 36, contacts the identity data owner for authorization of the transaction 37 A before the transaction processing may be completed. The mobile authorization may be implemented as defined as three operational modes of a proactive mode, a reactive mode and a combined mode.” Furthermore, as cited in ¶¶ [0121] [0122] “The mobile authorization function 70A has functions (i) to receive a mobile authorization request from a transaction processing entity, (ii) map the request to an existing record in the database 32 by mapping the identity data or the unique customer identifier, (ii) look up the enable/disable flag status for this particular identity data owner, (iii) then subsequently look up the identity data owner's mobile contact information.…The MAS 30 has a SMS send function 70B (i) to then create an SMS message embedded with the data as 37A for a payment transaction authorization or 37B for a data release authorization, (ii) then optionally encrypt the SMS data with a pre-placed and unique key between the MAS 30 and the mobile device 36, (iii) create a time out counter based on the type of the transaction, and (iv) then send the SMS via the mobile contact information to the mobile device seeking authorization of the transaction.”); and
for each outgoing payment request having an offered key code matching a unique key code of an existing transaction tracking record in the data store, generate outgoing payment details […] (i.e. for each transaction request having matching security/key code, to generate the authorization message) (Singhal: ¶ [0031] “The contact by the transaction processing entity or the mobile authorization service provider via the owner's wireless mobile communication device may include a SMS text message that embeds a pre-placed security code and may include sending to the identity data owner, (i) name of the transaction initiating entity, date and time, and an amount for a payment transaction.” Furthermore, as cited in ¶ [0123] “The MAS 30 also has a SMS receive function 70C (i) to receive a SMS reply response from the mobile device 36 (ii) identify the response by matching the response in the database 32, and (iii) optionally decrypt the response.”).
Singhal does not explicitly disclose a plurality of payment type profiles, each payment type profile associating a payment type with one or more payment attributes; the allocatable amount of the transaction tracking record being initialized to a value less than or equal to the incoming amount, […]; and reduce the allocatable amount of the existing transaction tracking record by the outgoing amount if the outgoing amount is less than or equal to the allocatable amount.
However, Richman further discloses:
a plurality of payment type profiles, each payment type profile associating a payment type with one or more payment attributes (i.e. credit management component stores a plurality of customer’s payment card types such as credits from a travel bank account and rewards from a loyalty award account) (Richman: ¶ [0059] “The system 1 includes a credit management component 10 that allows the consolidation of all different and disparate "credit" forms of payment issued by airlines to their customers into a unique account (based on a common currency) owned by consumer and agency customers. As explained in further detail herein, the credit management component 10 provides a comprehensive solution for customer credit management that links all the customer's forms of credit to a single, secured, profile that is accessible to all sales channels into a centralized "one account", dynamically converts balances held in different systems and "currencies" to the currency of the items the customer wishes to purchase at payment time, provides customers the ability to use every credit available to purchase products and services as multiple FOPs (Forms of Payment), and increases airlines ability to track, audit and report while eliminating all manual processes.” Furthermore, as cited in ¶¶ [0070] [0072] “The credit bank 24 may act as a general purpose credit account for customers, enabling a balance of credits to be maintained for each customer as a generic fulfillment mechanism for other forms of payment. For example, the credit bank 24 may provide airline customers the ability to grant and maintain commercial credit accounts to enrolled travel agencies and corporate customers. Additionally, the credit bank 24 may provide consumer customers the ability to store and use credits earned for things such as non-refundable ticket residual amounts, service compensation credits, and other redeemed value documents…External and internal credit systems 50 may function in cooperation with the credit management component 10, as necessary. Such systems may include, for example, travel banks, corporate servers, travel agency servers, electronic profile systems, and loyalty award databases, to name a few. This cooperation may occur through one or more communications portals and/or be performed by one or more computer program modules.”);
the allocatable amount of the transaction tracking record being initialized to a value less than or equal to the incoming amount, […] (i.e. available balance is initialized to a value less than the sale amount) (Richman: ¶¶ [0246] [0247] “Available Balance=Overall Credit Limit Amount(Posted Transactions+Pending Amount)…Available Daily Balance=Daily Transaction Limit Amount-(Daily Transactions+Pending Transactions)” Furthermore, as cited in ¶¶ [0271] [0272] “The available balance amount must be greater than or equal to the amount of the requested sale…The available daily balance must be greater than or equal to the requested sales amount.”); and
reduce the allocatable amount of the existing transaction tracking record by the outgoing amount if the outgoing amount is less than or equal to the allocatable amount (i.e. convert credit from one account such as a travel bank and rewards from loyalty account into credit of the item or the second payment type, wherein the available balance is reduced by the amount of the sale amount, wherein the sale amount is less than available balance) (Richman: ¶ [0059] “The system 1 includes a credit management component 10 that allows the consolidation of all different and disparate "credit" forms of payment issued by airlines to their customers into a unique account (based on a common currency) owned by consumer and agency customers. As explained in further detail herein, the credit management component 10 provides a comprehensive solution for customer credit management that links all the customer's forms of credit to a single, secured, profile that is accessible to all sales channels into a centralized "one account", dynamically converts balances held in different systems and "currencies" to the currency of the items the customer wishes to purchase at payment time, provides customers the ability to use every credit available to purchase products and services as multiple FOPs (Forms of Payment), and increases airlines ability to track, audit and report while eliminating all manual processes.” Furthermore, as cited in ¶¶ [0070] [0072] “The credit bank 24 may act as a general purpose credit account for customers, enabling a balance of credits to be maintained for each customer as a generic fulfillment mechanism for other forms of payment. For example, the credit bank 24 may provide airline customers the ability to grant and maintain commercial credit accounts to enrolled travel agencies and corporate customers. Additionally, the credit bank 24 may provide consumer customers the ability to store and use credits earned for things such as non-refundable ticket residual amounts, service compensation credits, and other redeemed value documents…External and internal credit systems 50 may function in cooperation with the credit management component 10, as necessary. Such systems may include, for example, travel banks, corporate servers, travel agency servers, electronic profile systems, and loyalty award databases, to name a few. This cooperation may occur through one or more communications portals and/or be performed by one or more computer program modules.” Furthermore, as cited in ¶¶ [0246] [0247] “Available Balance=Overall Credit Limit Amount(Posted Transactions+Pending Amount)…Available Daily Balance=Daily Transaction Limit Amount-(Daily Transactions+Pending Transactions)” Furthermore, as cited in ¶¶ [0271] [0272] “The available balance amount must be greater than or equal to the amount of the requested sale…The available daily balance must be greater than or equal to the requested sales amount.”).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to add Richman’s a plurality of payment type profiles, each payment type profile associating a payment type with one or more payment attributes, the allocatable amount of the transaction tracking record being initialized to a value less than or equal to the incoming amount; and wherein the second payment type, selected between multiple second payment types, is selected by a filter defined by a plurality of transaction preferences comprising one or more optimization goals in compliance with the filter to Singhal’s system and method for providing on-demand outgoing payment details. One of ordinary skill in the art would have been motivated to do so because it “provides customers the ability to use every credit available to purchase products and services as multiple FOPs (Forms of Payment), and increases airlines ability to track, audit and report while eliminating all manual processes.” (Richman: ¶ [0003]).
Singhal and Richman do not explicitly disclose the unique key code being initialized to a cryptographic hash value calculated based on the authorization data and a current date and time.
However, Ginter further discloses the unique key code being initialized to a cryptographic hash value calculated based on the authorization data and a current date and time (i.e. unique key code is initialized to cryptographic hash value based on authorization data and expiration date field which includes current date and time to compare with expiration time and date) (Ginter: ¶ [0866] “FIG. 48 shows au example architecture for certifying authority 500. In this example, certifying authority 500 may include a secure communications facility 544, an encryption/decryption processor 546, a billing system 548, a key generator 550, a query mechanism 552, and an electronic archive 554. In this example, secure communications 544 is used to communicate with other electronic appliances 100 and/or other Commerce Utility Systems 90. Electronic archive 554 stores keys, certificates 504 and other information required to maintain the operation of certifying authority 500. Encryption/decryption processor 546 is used to create digital certificates 504 by using strong cryptographic techniques. Billing system 548 issues bills 542. Query mechanism 552 is used to query electronic archive 554. Key generator 550 is used to generate cryptographic keys the certifying authority 500 needs for its own operation.” Furthermore, as cited in ¶ [0889] “Expiration field 560(3) is useful because people who skip checks of revocation lists have at least some assurance that a certificate is good if it must be renewed periodically. Expiration date field 560(3) provides an additional safeguard by insuring that certificates do not last forever-allowing certifying authorities 500 to use different cryptographic key pairs for example to provide overall integrity and trusted-ness of the certification process.”).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to add Ginter’s unique key code being initialized to a cryptographic hash value calculated based on the authorization data and a current date and time to Singhal’s system and method for providing on-demand outgoing payment details. One of ordinary skill in the art would have been motivated to do so because it “Changing the certifying authority 500's key pair reduces the incentives for an adversary to break a given key, because the amount of information protected by that key is limited, and the fraudulent use of a compromised key will only have a limited time of effectiveness.” (Ginter: ¶ [0889]).
Singhal, Richman, and Ginter do not explicitly disclose generate outgoing payment details, associated with at least a second payment type, wherein the second payment type is associated with one of a second brand, organization, or group alternative to the first payment type for purchase of an outgoing first purchase type and a third payment type, wherein the third payment type is associated with one of a third brand, organization, or group alternative to the first and second payment types for outgoing purchase of a second purchase type; and wherein the at least second and third payment types, selected between multiple second payment types, is selected by a filter defined by a plurality of transaction preferences comprising one or more optimization goals associated with the one of the second brands, organizations, or groups in compliance with the filter, and wherein the filter selection maintains an outgoing percentage or currency amount distributed between the multiple payment types within a predetermined period of time.
However, Szollar further discloses:
generate outgoing payment details, associated with at least a second payment type, wherein the second payment type is associated with one of a second brand, organization, or group alternative to the first payment type for purchase of an outgoing first purchase type and a third payment type, wherein the third payment type is associated with one of a third brand, organization, or group alternative to the first and second payment types for outgoing purchase of a second purchase type (i.e. generate payment details including a plurality of payment options, wherein a third second payment type is associated with a specific credit card organization/brand and third payment type is associated to another specific credit card organization/brand) (Szollar: Fig. 5 and ¶ [0085] “As the transaction is taking place or after the total has been calculated, computing device 102, via user interface 500, may display available payment methods 506, a cost 508 associated with each payment method, rewards 510 associated with each payment method, and notes 512 associated with each payment method. The user may review notes 512, rewards 510, and costs 508 and select a form of payment using selection boxes 514. Upon displaying user interface 500, computing device 102 may automatically select one of the selection boxes. The box selected may represent a recommendation to the user. The recommendation may be the best option or an option with the lowest cost of financial impact to the user. For example, computing device 102 may automatically select to user an American Express® SkyMiles® credit card because using the card with get the user closer to a free airline ticket and this is a form of payment the user currently has.”);
wherein the at least second and third payment types, selected between multiple second payment types, is selected by a filter defined by a plurality of transaction preferences comprising one or more optimization goals associated with the one of the second brands, organizations, or groups in compliance with the filter (i.e. selecting a second payment type of a plurality of payment types based on filters defined by cost/benefit to the user) (Szollar: ¶¶ [0066]-[0068] “If more payment methods are available, subroutine may proceed to stage 404 where another payment method may be selected and then to decision block 406 to determine if the payment method selected is available. If the payment method selected is available, subroutine may proceed from decision block 406 to stage 410 where a benefit of the payment method may be calculated…The benefit of the payment method may be calculated a number of ways. A benefit of a payment method may be encompassed by a variety of concepts. Non-limiting examples of a benefit include a lowest cost to a user, a maximization of rewards, a maximization of reduced or free merchandise or services, a maximization of available discounts, etc. The benefit may be quantitative or qualitative…As described herein, computing device 102 may utilize various information received to calculate a cost for using each payment method. The cost for using each payment method may include interest charges, overdraft charges, over-the-limit fees , surcharges, foreign exchange fees, etc. As shown in the above example, card C may have lowest cost to a user based on interest charges. Discount information also may be used in determine a cost. For example, a discount may be given for using card B instead of cards A and C. As a result, any interest charges or the principle amount may be reduced by discounts that may be available.”), and
wherein the filter selection maintains an outgoing percentage or currency amount distributed between the multiple payment types within a predetermined period of time (i.e. user sets preference or filter for which payment method is going to be used, wherein the preference maintains a balance or currency amount distributed between the different payment types for each month) (Szollar: ¶¶ [0077]-[0079] “The form of payment may be selected based on the costs or other financial impact to the user. For example, the form of payment may be selected because of a lower total cost to the user. The form of payment may be selected because of a minimal financial impact to the user…The user may also provide input to assist in selecting the form of payment. For example, the user may have a preference for a particular form of payment. As a result, the user can enter a preference that may skew the selection of a form of payment. For instance, a user may prefer to use his or her American Express® card. Thus the user may enter a preference that indicates his or her American Express® is to be used unless the cost of using his or her American Express® exceeds a certain dollar amount or percentage of another form of payment…For example, the user may enter a preference that says his or her American Express® card is to be used unless the cost of using the American Express® is greater than 10% or $50.00, whichever is lower, of another form of payment. For using card A the cost may be $2,500.00 and the cost for using the user's American Express® card may be $2,600.00. Thus, the cost difference is $100.00, or 4%. As a result, card A may be selected as the form of payment because, while the cost is less than 10%, the cost exceeds the dollar value, $50.00.” Furthermore, as cited in ¶ [0027] “In addition, computing device may factor in whether or not a user generally carries a balance or pays his or her balance in full each month. For example, probability calculation can be used based on payment history.”).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to add Szollar’s generate outgoing payment details, associated with at least a second payment type, wherein the second payment type is associated with one of a second brand, organization, or group alternative to the first payment type for purchase of an outgoing first purchase type and a third payment type, wherein the third payment type is associated with one of a third brand, organization, or group alternative to the first and second payment types for outgoing purchase of a second purchase type; and wherein the at least second and third payment types, selected between multiple second payment types, is selected by a filter defined by a plurality of transaction preferences comprising one or more optimization goals associated with the one of the second brands, organizations, or groups in compliance with the filter, and wherein the filter selection maintains an outgoing percentage or currency amount distributed between the multiple payment types within a predetermined period of time to Singhal’s system and method for providing on-demand outgoing payment details. One of ordinary skill in the art would have been motivated to do so because “The form of payment may be selected because of a minimal financial impact to the user.” (Szollar: ¶ [0077]).
With respect to Claim 2:
Singhal teaches:
A method for providing on-demand outgoing payment details by a network-connected computing system, the method comprising: receiving, at network-connected interface, customer payment details, associated with a first payment type, for payment of an incoming amount (i.e. authorization message is received which comprises amount of payment transaction and bankcard info) (Singhal: Fig. 2 and ¶ [0116] “The authorization message 37A from the MAS30 as illustrated in FIG. 2 may include sending to the identity data owner, (i) name of the transaction initiating entity, date and time, and optionally an amount for a payment transaction.” Furthermore, as cited in ¶ [0118] “The system 30 has a database of mobile identity that maintains mapping of the mobile contact information with identity data of the identity data owner. The identity data would be from a group of (i) social security number, (ii) bankcards, (iii) bank account numbers, (iv) name, (vi) date of birth, and (vii) zip code.” Furthermore, as cited in ¶ [0150] “At step 100, receiving, by a financial entity which maintains accounts of a customer, (i) a bankcard originated payment authorization request from a merchant point of sale, via a card authorization network and (ii) a payee originated request for payment via an ACH.”);
running a fraud check on the customer payment details wherein an error message is sent upon a fraud detection (i.e. fraud check is run on customer profile including payment details, wherein the user is notified to monitor his credit profile due to fraud) (Singhal: ¶ [0026] “Another solution has been that the card issuing industry uses fraud alert systems based on a customer profile, where a transaction based on such a profile is flagged for human intervention by a banks' automated fraud agent. As yet another solution, the id data owner is told to monitor his/her credit profile for unauthorized transactions or requests for data.” Furthermore, as cited in ¶ [0108] “The MAS 30 is not intended to replace or displace any existing fraud detection system the bank may be using but works in addition to those systems. As the bank's existing systems would be operational for all of their customers, whereas the MAS 30 would be operational for those who have chosen this service and would abide by its operation.”);
requesting authorization data for payment of the incoming amount from a payment processor (i.e. authorization message requests authorization data for incoming transaction not on the approved list) (Singhal: ¶ [0007] “Once the transaction information is passed through the "gateway" payment processor, the transaction is processed using the same ETF/ACH rules as other electronic transfers.” Furthermore, as cited in ¶ [0103] “For those payment authorization requests that are not on the pre-authorized list, establishing a contact via the secure contact means with the bank customer to seek authorization for the payment authorization request that is not on the list.”),
storing a transaction tracking record in a data store upon receipt of the authorization data, the transaction tracking record comprising a unique key code and an allocatable amount, […] (i.e. MAS30 stores a plurality of transaction types which are designated by a unique key and payment amount) (Singhal: ¶ [0122] “The MAS 30 has a SMS send function 70B (i) to then create an SMS message embedded with the data as 37A for a payment transaction authorization or 37B for a data release authorization, (ii) then optionally encrypt the SMS data with a pre-placed and unique key between the MAS 30 and the mobile device 36, (iii) create a time out counter based on the type of the transaction,”);
in response to receiving an outgoing payment request, associated with one or more purchase types, comprising an offered key code and an outgoing amount: verifying that the offered key code matches the unique key code of an existing transaction record in the data store and that the outgoing amount is less than or equal to the allocatable amount of the existing transaction record (i.e. in response to a transaction request for an outgoing payment, verifying that the key codes match in the database of transaction records and that the outgoing amount is less than allowable/allocatable amount) (Singhal: ¶ [0123] “The MAS 30 also has a SMS receive function 70C (i) to receive a SMS reply response from the mobile device 36 (ii) identify the response by matching the response in the database 32, and (iii) optionally decrypt the response. The system 30 may have a pre-set security code between the mobile device owner and the mobile authorization service to authenticate mobile authorization responses.” Furthermore, as cited in ¶ [0142] “When the service choice flag 77 is set, the process entity 18 sends the request to MAS 30. However, if the dollar amount in a payment transaction is less than a threshold, such as ten dollars, the process entity may not send the request to MAS 30.”), and
generating outgoing payment details for each purchase type, […] (i.e. for each transaction request having matching security/key code, to generate the authorization message) (Singhal: ¶ [0031] “The contact by the transaction processing entity or the mobile authorization service provider via the owner's wireless mobile communication device may include a SMS text message that embeds a pre-placed security code and may include sending to the identity data owner, (i) name of the transaction initiating entity, date and time, and an amount for a payment transaction.” Furthermore, as cited in ¶ [0123] “The MAS 30 also has a SMS receive function 70C (i) to receive a SMS reply response from the mobile device 36 (ii) identify the response by matching the response in the database 32, and (iii) optionally decrypt the response.”).
Singhal does not explicitly disclose the allocatable amount being initialized to a value less than or equal to the incoming amount […]; storing a plurality of payment type profiles in the data store, each payment type profile associating a payment type with one or more payment attributes; and reducing the allocatable amount of the existing transaction record by the outgoing amount […].
However, Richman further discloses:
the allocatable amount being initialized to a value less than or equal to the incoming amount […] (i.e. available balance is initialized to a value less than the sale amount) (Richman: ¶¶ [0246] [0247] “Available Balance=Overall Credit Limit Amount(Posted Transactions+Pending Amount)…Available Daily Balance=Daily Transaction Limit Amount-(Daily Transactions+Pending Transactions)” Furthermore, as cited in ¶¶ [0271] [0272] “The available balance amount must be greater than or equal to the amount of the requested sale…The available daily balance must be greater than or equal to the requested sales amount.”);
storing a plurality of payment type profiles in the data store, each payment type profile associating a payment type with one or more payment attributes (i.e. credit management component stores a plurality of customer’s payment card types such as credits from a travel bank account and rewards from a loyalty award account) (Richman: ¶ [0059] “The system 1 includes a credit management component 10 that allows the consolidation of all different and disparate "credit" forms of payment issued by airlines to their customers into a unique account (based on a common currency) owned by consumer and agency customers. As explained in further detail herein, the credit management component 10 provides a comprehensive solution for customer credit management that links all the customer's forms of credit to a single, secured, profile that is accessible to all sales channels into a centralized "one account", dynamically converts balances held in different systems and "currencies" to the currency of the items the customer wishes to purchase at payment time, provides customers the ability to use every credit available to purchase products and services as multiple FOPs (Forms of Payment), and increases airlines ability to track, audit and report while eliminating all manual processes.” Furthermore, as cited in ¶¶ [0070] [0072] “The credit bank 24 may act as a general purpose credit account for customers, enabling a balance of credits to be maintained for each customer as a generic fulfillment mechanism for other forms of payment. For example, the credit bank 24 may provide airline customers the ability to grant and maintain commercial credit accounts to enrolled travel agencies and corporate customers. Additionally, the credit bank 24 may provide consumer customers the ability to store and use credits earned for things such as non-refundable ticket residual amounts, service compensation credits, and other redeemed value documents…External and internal credit systems 50 may function in cooperation with the credit management component 10, as necessary. Such systems may include, for example, travel banks, corporate servers, travel agency servers, electronic profile systems, and loyalty award databases, to name a few. This cooperation may occur through one or more communications portals and/or be performed by one or more computer program modules.”); and
reducing the allocatable amount of the existing transaction record by the outgoing amount […] (i.e. convert credit from one account such as a travel bank and rewards from loyalty account into credit of the item or the second payment type, wherein the available balance is reduced by the amount of the sale amount, wherein the sale amount is less than available balance) (Richman: ¶ [0059] “The system 1 includes a credit management component 10 that allows the consolidation of all different and disparate "credit" forms of payment issued by airlines to their customers into a unique account (based on a common currency) owned by consumer and agency customers. As explained in further detail herein, the credit management component 10 provides a comprehensive solution for customer credit management that links all the customer's forms of credit to a single, secured, profile that is accessible to all sales channels into a centralized "one account", dynamically converts balances held in different systems and "currencies" to the currency of the items the customer wishes to purchase at payment time, provides customers the ability to use every credit available to purchase products and services as multiple FOPs (Forms of Payment), and increases airlines ability to track, audit and report while eliminating all manual processes.” Furthermore, as cited in ¶¶ [0070] [0072] “The credit bank 24 may act as a general purpose credit account for customers, enabling a balance of credits to be maintained for each customer as a generic fulfillment mechanism for other forms of payment. For example, the credit bank 24 may provide airline customers the ability to grant and maintain commercial credit accounts to enrolled travel agencies and corporate customers. Additionally, the credit bank 24 may provide consumer customers the ability to store and use credits earned for things such as non-refundable ticket residual amounts, service compensation credits, and other redeemed value documents…External and internal credit systems 50 may function in cooperation with the credit management component 10, as necessary. Such systems may include, for example, travel banks, corporate servers, travel agency servers, electronic profile systems, and loyalty award databases, to name a few. This cooperation may occur through one or more communications portals and/or be performed by one or more computer program modules.” Furthermore, as cited in ¶¶ [0246] [0247] “Available Balance=Overall Credit Limit Amount(Posted Transactions+Pending Amount)…Available Daily Balance=Daily Transaction Limit Amount-(Daily Transactions+Pending Transactions)” Furthermore, as cited in ¶¶ [0271] [0272] “The available balance amount must be greater than or equal to the amount of the requested sale…The available daily balance must be greater than or equal to the requested sales amount.”).
Singhal and Richman do not explicitly disclose the unique key code being initialized to a cryptographic hash value calculated based on the authorization data and a current date and time.
However, Ginter further discloses the unique key code being initialized to a cryptographic hash value calculated based on the authorization data and a current date and time (i.e. unique key code is initialized to cryptographic hash value based on authorization data and expiration date field which includes current date and time to compare with expiration time and date) (Ginter: ¶ [0866] “FIG. 48 shows au example architecture for certifying authority 500. In this example, certifying authority 500 may include a secure communications facility 544, an encryption/decryption processor 546, a billing system 548, a key generator 550, a query mechanism 552, and an electronic archive 554. In this example, secure communications 544 is used to communicate with other electronic appliances 100 and/or other Commerce Utility Systems 90. Electronic archive 554 stores keys, certificates 504 and other information required to maintain the operation of certifying authority 500. Encryption/decryption processor 546 is used to create digital certificates 504 by using strong cryptographic techniques. Billing system 548 issues bills 542. Query mechanism 552 is used to query electronic archive 554. Key generator 550 is used to generate cryptographic keys the certifying authority 500 needs for its own operation.” Furthermore, as cited in ¶ [0889] “Expiration field 560(3) is useful because people who skip checks of revocation lists have at least some assurance that a certificate is good if it must be renewed periodically. Expiration date field 560(3) provides an additional safeguard by insuring that certificates do not last forever-allowing certifying authorities 500 to use different cryptographic key pairs for example to provide overall integrity and trusted-ness of the certification process.”).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to add Ginter’s unique key code being initialized to a cryptographic hash value calculated based on the authorization data and a current date and time to Singhal’s system and method for providing on-demand outgoing payment details. One of ordinary skill in the art would have been motivated to do so because it “Changing the certifying authority 500's key pair reduces the incentives for an adversary to break a given key, because the amount of information protected by that key is limited, and the fraudulent use of a compromised key will only have a limited time of effectiveness.” (Ginter: ¶ [0889]).
Singhal, Richman, and Ginter do not explicitly disclose generating outgoing payment details for each purchase type, associated with at least a second payment type, alternative to the first payment type, wherein the third payment type is associated with one of a second brand, organization, or group for purchase of an outgoing first purchase type and a third payment type, wherein the third payment type is associated with one of a third brand, organization, or group alternative to the first and second payment types for outgoing purchase of a second purchase type; and wherein the at least second and third payment types, selected between multiple payment types, is automatically selected by a filter defined by a plurality of transaction preferences comprising one or more optimization goals in compliance with the filter, wherein each outgoing payment request is automatically processed and an outgoing payment generated for each outgoing payment without need for further user intervention.
However, Szollar further discloses:
generating outgoing payment details for each purchase type, associated with at least a second payment type, alternative to the first payment type, wherein the third payment type is associated with one of a second brand, organization, or group for purchase of an outgoing first purchase type and a third payment type, wherein the third payment type is associated with one of a third brand, organization, or group alternative to the first and second payment types for outgoing purchase of a second purchase type (i.e. generate payment details including a plurality of payment options, wherein a third second payment type is associated with a specific credit card organization/brand and third payment type is associated to another specific credit card organization/brand) (Szollar: Fig. 5 and ¶ [0085] “As the transaction is taking place or after the total has been calculated, computing device 102, via user interface 500, may display available payment methods 506, a cost 508 associated with each payment method, rewards 510 associated with each payment method, and notes 512 associated with each payment method. The user may review notes 512, rewards 510, and costs 508 and select a form of payment using selection boxes 514. Upon displaying user interface 500, computing device 102 may automatically select one of the selection boxes. The box selected may represent a recommendation to the user. The recommendation may be the best option or an option with the lowest cost of financial impact to the user. For example, computing device 102 may automatically select to user an American Express® SkyMiles® credit card because using the card with get the user closer to a free airline ticket and this is a form of payment the user currently has.”); and
wherein the at least second and third payment types, selected between multiple payment types, is automatically selected by a filter defined by a plurality of transaction preferences comprising one or more optimization goals in compliance with the filter (i.e. selecting a second payment type of a plurality of payment types based on filters defined by cost/benefit to the user) (Szollar: ¶¶ [0066]-[0068] “If more payment methods are available, subroutine may proceed to stage 404 where another payment method may be selected and then to decision block 406 to determine if the payment method selected is available. If the payment method selected is available, subroutine may proceed from decision block 406 to stage 410 where a benefit of the payment method may be calculated…The benefit of the payment method may be calculated a number of ways. A benefit of a payment method may be encompassed by a variety of concepts. Non-limiting examples of a benefit include a lowest cost to a user, a maximization of rewards, a maximization of reduced or free merchandise or services, a maximization of available discounts, etc. The benefit may be quantitative or qualitative…As described herein, computing device 102 may utilize various information received to calculate a cost for using each payment method. The cost for using each payment method may include interest charges, overdraft charges, over-the-limit fees , surcharges, foreign exchange fees, etc. As shown in the above example, card C may have lowest cost to a user based on interest charges. Discount information also may be used in determine a cost. For example, a discount may be given for using card B instead of cards A and C. As a result, any interest charges or the principle amount may be reduced by discounts that may be available.”),
wherein each outgoing payment request is automatically processed and an outgoing payment generated for each outgoing payment without need for further user intervention (i.e. user sets preference for which payment method is going to be used later for subsequent payment transactions or outgoing payment requests, wherein American Express payment method is automatically processed for the payment transaction unless exception occurs) (Szollar: ¶¶ [0077]-[0079] “The form of payment may be selected based on the costs or other financial impact to the user. For example, the form of payment may be selected because of a lower total cost to the user. The form of payment may be selected because of a minimal financial impact to the user…The user may also provide input to assist in selecting the form of payment. For example, the user may have a preference for a particular form of payment. As a result, the user can enter a preference that may skew the selection of a form of payment. For instance, a user may prefer to use his or her American Express® card. Thus the user may enter a preference that indicates his or her American Express® is to be used unless the cost of using his or her American Express® exceeds a certain dollar amount or percentage of another form of payment…For example, the user may enter a preference that says his or her American Express® card is to be used unless the cost of using the American Express® is greater than 10% or $50.00, whichever is lower, of another form of payment. For using card A the cost may be $2,500.00 and the cost for using the user's American Express® card may be $2,600.00. Thus, the cost difference is $100.00, or 4%. As a result, card A may be selected as the form of payment because, while the cost is less than 10%, the cost exceeds the dollar value, $50.00.”).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to add Szollar’s generating outgoing payment details for each purchase type, associated with at least a second payment type, alternative to the first payment type, wherein the third payment type is associated with one of a second brand, organization, or group for purchase of an outgoing first purchase type and a third payment type, wherein the third payment type is associated with one of a third brand, organization, or group alternative to the first and second payment types for outgoing purchase of a second purchase type; and wherein the at least second and third payment types, selected between multiple payment types, is automatically selected by a filter defined by a plurality of transaction preferences comprising one or more optimization goals in compliance with the filter, wherein each outgoing payment request is automatically processed and an outgoing payment generated for each outgoing payment without need for further user intervention to Singhal’s system and method for providing on-demand outgoing payment details. One of ordinary skill in the art would have been motivated to do so because “The form of payment may be selected because of a minimal financial impact to the user.” (Szollar: ¶ [0077]).
Response to Arguments
Applicant’s arguments see page 6 of the Remarks disclosed, filed on 12/30/2025, with respect to the nonstatutory double patenting rejection(s) of claim(s) 1-2 have been considered but are not persuasive. The Applicant has stated “The Terminal Disclaimer filed herewith is not intended, and shall not be construed under any circumstances, as an admission that any invention claimed in a patent granted on the instant application is obvious in view of the prior patent or that the prior patent constitutes prior art to the instant application. See MPEP 804.02(II) (citing Quad Environmental Technologies Corp. V. Union Sanitary District, 946 F.2d. 870, 874 (Fed. Cir. 1991)). The Terminal Disclaimer filed herewith does not disclaim any patent term extension under 35 U.S.C. § 156 of any patent granted on the instant application that may extend beyond the expiration date of the full statutory term defined in 35 U.S.C. § 154, as presently shortened by any terminal disclaimer, of prior U.S. Patent No. 12,118,519. See Merck & Co. V Hi-Tech Pharmacal Co., 482 F.3d 1317 (Fed. Cir. 2007). The Terminal Disclaimer filed herewith also does not disclaim any patent term adjustment that may be permitted under 35 U.S.C. § 154. Applicant respectfully requests the removal of the Double Patenting rejections.” Examiner notes, however, no Terminal Disclaimer has been filed. Therefore, the rejection(s) of claim(s) 1-2 under the nonstatutory double patenting rejection is maintained above.
Applicant’s arguments see pages 6-7 of the Remarks disclosed, filed on 12/30/2025, with respect to the 35 U.S.C. § 112(b) rejection(s) of claim(s) 1-2 have been considered and are persuasive. The Applicant has stated “Applicant has amended claim 2 to correct the error.” The Examiner agrees and therefore, the rejection(s) of claim(s) 1-2 under 35 U.S.C. § 112(b) has been withdrawn.
Applicant’s arguments see pages 7-9 of the Remarks disclosed, filed on 12/30/2025, with respect to the 35 U.S.C. § 101 rejection(s) of claim(s) 1-2 have been considered but are not persuasive. The Applicant asserts “Here, claims 1 and 2 recite, inter alia, both that "the unique key code is initialized to a cryptographic hash value calculated based on the authorization data and a current date and time" and that the offered key code received with an outgoing payment request must match the “the unique key code of an existing transaction record.”… To the extent that cryptographic hashing techniques are known in the art, the practical application consideration, as part of Step 2A, "specifically excludes consideration of whether the additional elements represent well-understood, routine, conventional activity." MPEP2106.04(d)(I). The unique key code that is initialized to a cryptographic hash value based on details of the incoming payment information therefore provides an improvement to payment processing technology, and it is this improvement, not any incidentally recited abstract idea to which the claims are directed.” The Examiner respectfully disagrees. The “cryptographic hashing technique” as being currently claimed merely describes the unique key code. There is no positive recitation of initializing the unique key code based on the authorization data and a current date and time but merely that the unique key code is used for “verifying that the offered key code matches the unique key code of an existing transaction record in the data store and that the outgoing amount is less than or equal to the allocatable amount of the existing transaction record”. However, merely determining that key codes match for stored transaction records in order to verify an outgoing payment detail is seen as storing transaction records with key codes and performing electronic recordkeeping to determine/verify if key code matches. The courts have noted that “electronic recordkeeping” (See: Alice Corp. Pty. Ltd. v. CLS Bank Int'l, 573 U.S. 208, 225, 110 USPQ2d 1984 (2014) (creating and maintaining "shadow accounts"); Ultramercial, 772 F.3d at 716, 112 USPQ2d at 1755 (updating an activity log)) and “Storing and retrieving information in memory” (See: Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93) are seen as well‐understood, routine, and conventional computer functions. Examiner recommends amending the claims to positively recite initializing the unique key code utilizing the cryptographic hashing technique and how the authorization data is used to initialize the unique key code. Therefore, the rejection(s) of claim(s) 1-2 under 35 U.S.C. § 101 is maintained above with an updated analysis.
Applicant’s arguments see pages 9-12 of the Remarks disclosed, filed on 12/30/2025, with respect to the 35 U.S.C. § 103 rejection(s) of claim(s) 1-2 over Singhal in view of Richman in view of Ginter and in further view of Szollar have been considered but are not persuasive. The Applicant asserts “Richman "allows the consolidation of all different and disparate 'credit' forms of payment" into a unique account." (Richman; [0059].) The credit card management component "provides a comprehensive solution for customer credit management that links all forms of credit to a single, secured profile" as a "centralized 'one account," which "dynamically converts balances held in different systems and 'currencies' to the currency of the items the customer wishes to purchase at payment time." (Richman; [0059].) This suggests that a single "payment type" (i.e., one centralized account) is utilized. The currency conversion may convert the balance reflected in an account to reflect the currency of the item in which the customer wishes to purchase. However, the currency conversion is merely a reflection of the same account (i.e., the same "payment type") adapted for a better consumer experience/interface while purchasing. (Richman; [0059] and [0067].) Converting or changing the units in which the account is measured does not change the account that is used, nor does it result in a separate and distinct payment type. To the contrary, as currently recited in claim 1, "customer payment details, associated with a first payment type;" and "outgoing payment details, associated with a second payment type" is required. As exemplified in the Specification as originally filed, "types" of payments may include methods of payments such as ACH payments (same-day or standard), various card payments (grouped by bank identification numbers or BINS), different brands or organizations, etc. (Spec.; [0053]). For example, multiple outgoing payment types may be chosen between to fulfill optimization targets or goals (e.g., 30% of a total value of outgoing transactions per day from a first card brand (i.e., a "second payment type") and 70% of the total value of outgoing transactions per day from a second card brand (i.e., a different "second payment type")), which are different than those associated with customer payment details (i.e., a "first payment type"). (Spec.; [0066]- [0067].) Therefore, such an interpretation that the same consolidated account reflected with converting units of measurement cannot be reasonably interpreted as two different "payment types," as currently claimed. Consequently, the obviousness rejection of claims 1 and 2 should be removed.” The Examiner respectfully disagrees. The Examiner would like to refer the Applicant to ¶¶ [0070] [0072] of the Richman reference; “The credit bank 24 may act as a general purpose credit account for customers, enabling a balance of credits to be maintained for each customer as a generic fulfillment mechanism for other forms of payment. For example, the credit bank 24 may provide airline customers the ability to grant and maintain commercial credit accounts to enrolled travel agencies and corporate customers. Additionally, the credit bank 24 may provide consumer customers the ability to store and use credits earned for things such as non-refundable ticket residual amounts, service compensation credits, and other redeemed value documents…External and internal credit systems 50 may function in cooperation with the credit management component 10, as necessary. Such systems may include, for example, travel banks, corporate servers, travel agency servers, electronic profile systems, and loyalty award databases, to name a few. This cooperation may occur through one or more communications portals and/or be performed by one or more computer program modules.” The disclosure of Richman above teaching “other forms of payment” clearly reads on “methods of payments such as ACH payments (same-day or standard), various card payments (grouped by bank identification numbers or BINS), different brands or organizations, etc.” Therefore, the rejection(s) of claim(s) 1-2 under 35 U.S.C. § 103 is provided above with updated citations.
Conclusion
The prior art made of record and not relied upon is considered pertinent to Applicant’s disclosure. The following reference are cited to further show the state of the art:
U.S. Publication 2012/0303425 to Katzin for disclosing receiving an activity request including merchant information associated with a merchant; retrieving a previously stored merchant record from a database; determining merchant information update indicia based on a comparison of the merchant information and the previously stored merchant record; determining a confidence metric for the merchant information update; retrieving a confidence requirement based on the activity request; determining, within a low-latency processing timeframe, whether the determined confidence metric satisfies the retrieved confidence requirement; performing the requested activity and updating the previously stored merchant record with the merchant information update indicia when the determined confidence metric satisfies the retrieved confidence requirement; and declining the activity request when the determined confidence metric satisfies the retrieved confidence requirement.
U.S. Publication 2009/0157518 to Bishop for disclosing a point of sale (POS) device may be configured to locate a payment system and transmit a payment authorization request from a remote location to a payment system, either directly, or via a payment system directory and/or a SSL Gateway. The invention also includes inserting third party account information into an encrypted portion of the payment request, so the payment request appears as a normal request to the issuing bank, but the third party account information may be used by the third party to bill the customer. The payment system directory is further configured to determine one or more payment processors to direct a payment authorization request, such that a single transaction may be allocated among multiple payment processors for authorization. Moreover, the payment system directory is able to format alternative payment methods into a format that is able to be processed over existing payment networks.
U.S. Patent 10,089,619 to Koeppel for disclosing an example electronic wallet device may include a plurality of card slots to receive transaction cards; a plurality of card readers, each card reader, of the plurality of card readers, being associated with a card slot of the plurality of card slots; a hub comprising: a processor, and a communication interface; and a switching component that connects the plurality of card readers to the hub.
U.S. Patent 9,619,792 to Aaron for disclosing a method and apparatus for associating an account with a proxy card based on a photo are disclosed. The proxy card can be associated with account data from multiple other cards, such as account data from a driver's license and from various payment cards, such as a credit card, a debit card, and a pre-paid gift card. In some embodiments, a cardholder can associate an additional card with the proxy card by taking a photo of the face of the additional card using a mobile device. The mobile device analyzes the photo to obtain text representing account information that appears in the photo of the additional card. The mobile device associates the additional card with the proxy card by causing updating of stored association information, that represents an association between the card and the account data of the multiple cards, with the account information.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Azam Ansari, whose telephone number is (571) 272-7047. The examiner can normally be reached from Monday to Friday between 8 AM and 4:30 PM.
If any attempt to reach the examiner by telephone is unsuccessful, the examiner's supervisor, Waseem Ashraf, can be reached at (571) 270-3948.
Another resource that is available to applicants is the Patent Application Information Retrieval (PAIR). Information regarding the status of an application can be obtained from the (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAX. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pairdirect.uspto.gov. Should you have questions on access to the Private PAIR system, please feel free to contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
Applicants are invited to contact the Office to schedule either an in-person or a telephonic interview to discuss and resolve the issues set forth in this Office Action. Although an interview is not required, the Office believes that an interview can be of use to resolve any issues related to a patent application in an efficient and prompt manner.
/AZAM A ANSARI/
Primary Examiner, Art Unit 3621
January 23, 2026