DETAILED ACTION
1. The present application, filed on or after March 13, 2013, is being examined under the first inventor to file provisions of the AIA .
This is a 4th Continuation application with a claim of priority to the parent Application 15/261,093 filed September 9, 2016, now U.S. Patent No. 10,402,829.
The IDS filed June 23, 2025 in this Application has been considered.
NOTE: Interviews are encouraged, especially in this case given four (4) previously issued patents. Please use the AIR form, the link for which is found at the end of this Action, for scheduling an interview if such is desired.
Claims 1 - 20 are pending and examined as follows:
Claim Rejections – 35 USC § 101
2. 35 USC § 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture and composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
A. Rejection Based on Abstract Idea
Claims 1 – 20 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to a judicial exception (i.e., an abstract idea) without significantly more. Furthermore, this rejection is based on the 2019 Revised Patent Subject Matter Eligibility Guidance (2019 PEG).
B. Statutory Categories
Independent Claim 1 is a method claim and therefore falls into the statutory category of a “process.” Claim 8 is a device claim which recites various computer hardware components such as a processor and a memory, and it therefore falls into the statutory category of “machine/manufacture.” Claim 15 a non-transitory CRM claim and therefore falls into the statutory category of “machine/manufacture.”
C. The Claim Recites an Abstract Idea
Claim 1 is illustrative of the rejection of all claims on the grounds of abstract idea.
Claim 1 recites the limitation:
“receiving a transaction authorization request for a transaction originated by a user presenting a primary payment source payment vehicle, the transaction authorization request including an identifier identifying a primary payment source account of a user and an identifier of a specific merchant at which the transaction originates.”
This limitation, as drafted, is a process that, under its broadest reasonable interpretation, constitutes a method of organizing human activity, specifically, fundamental economic principles or practices. That is, analyzing this limitation in the context of the claim as a whole, it recites a process that falls within the grouping of abstract ideas comprising certain methods of organizing human activity. Fundamental economic principles or practices are examples of such methods. In this case, the fundamental economic principle or practice is the common practice of receiving a request to process and a transaction and applying a plurality of payment vehicles, such as payment cards, of the user in order to complete payment. This practice occurs millions of times every day. Even at the point of sale (POS), it is extremely common to apply more than one payment card and even cash to satisfy a single payment transaction.
Furthermore, the mere nominal recitation of a “processor” or “memory” does not remove the claim from the category of common or abstract methods of organizing human activity. These terms are recited at such a high level of generality as to not alter the designation of reciting an abstract idea.
Thus, Claim 1 recites a judicial exception, namely, an abstract idea.
D. The Claim Does Not Integrate the Abstract Idea into a Practical Application
Moreover, this judicial exception is not integrated into a practical application. The possible “additional limitations” recited in the Claim that must be considered are as follows:
identifying, with respect to the transaction authorization request, preference settings linked, in a database, to the primary payment source account based on the identifier of the primary payment source account and the identifier of the specific merchant at which the transaction originates;
processing the transaction using resources defined by an identified combination of payment source accounts from among a plurality of payment combinations based on the preference settings.
1. Lack of Computer Components and Interaction Among Same
No additional computerized components are mentioned in these limitations – other than a mere database. The only computer terms are recited only at a high level of generality. No other particular computer functions or computer component interactions within this system are recited. The few computer-related limitations are wholly generic in nature and are recited at such a high level of generality as to not provide any meaningful limitations on the claim.
The Claim merely recites receiving requests to process payment transactions and processing such transactions in accordance with previously stored instructions and identifiers. These are high level, broad and abstract concepts. Furthermore, the claim lacks concrete assignments of specific functions among these various components. One example of such concrete assignment is to assign, in the claim, certain functions to specific components and recite them as interacting in specific ways. This is not the case with this Claim.
2. No Technical Solution to a Technical Problem
Analyzing these additional limitations individually, and taking the claim as a whole and as an ordered combination, it is clear that these additional limitations do not serve to integrate the abstract idea into a practical application. They do not recite a technological solution to a technological problem. They do not improve the functioning of the computer system itself or represent an improvement to any technology or technical field. In fact, there are very few computerized system components or functions recited.
Thus, these limitations fail to recite with specificity any technical function or any improvement to the functioning of the computer system itself. Therefore, the claim lacks the specificity required to transform the claim from one claiming only an outcome or a result – allocating computing resources - to one claiming a specific way of achieving that outcome or result. See MPEP §2106.04(d)(I); 2106.04(d)(1); 2106.05(a)
3. The Claim Recites Mere Instructions to Apply the Abstract Idea
The recitation of these generic components amounts to no more than mere instructions “to apply” the abstract idea exception using generic computer components. It is clear that the claim recites only the idea of a solution or outcome i.e., the claim fails to recite details of how a solution to a problem is accomplished. Furthermore, the claim invokes computers or other machinery merely as a tool to perform an existing process.
As noted above, the only possible computer components are recited at a high level of generality. This means that the abstract idea can be applied to an extremely general field of devices and systems. A claim having broad applicability across many fields of endeavor does not provide meaningful limitations that integrate a judicial exception into a practical application or amount to significantly more. For instance, a claim that generically recites an effect of the abstract idea exception, or claims every mode of accomplishing that idea, amounts to a claim that is merely adding the words "apply it" to the abstract idea. See MPEP §2106.05(f)
Accordingly, the additional elements or limitations listed above do not integrate the abstract idea into a practical application because they do not impose any meaningful limitations on practicing the abstract idea. That is, the additional elements recited in the claim beyond the judicial exception(s) have been evaluated to determine whether those additional elements, considered individually and in combination, integrate the judicial exception(s) into a practical application. They do not.
F. Step 2B: The Claim Does Not Recite Significantly More than the Abstract Idea
This step involves the search for an “inventive concept.” However, it is clear from the case law and the MPEP that the considerations at issue are the same as those considered above with respect to the analysis of a practical application. See MPEP 2106.05(a) – (c) and (e). In other words, these analyses sharply overlap.
Therefore, based on the above analysis, the identified additional limitations do not provide “significantly more” than the abstract idea. The claim is therefore ineligible under §101. The other independent claims are, likewise, ineligible for the same reasons as they are virtually identical to Claim 1.
G. The Dependent Claims Do Not Recite Meaningful Additional Limitations
Similarly, Claim 2 recites the same abstract idea as Claim 1 by virtue of its dependency on Claim 1. Like Claim 1, this claim does not recite sufficient additional elements to integrate the abstract idea into a practical application. Claim 2 merely recites the abstract concept of supplemental payment sources linked in a database.
Claim 3 merely recites the abstract concept of a merchant identifier.
Claim 4 merely recites the abstract concept of merchant acquirer.
Claim 5 merely recites the abstract concept of a combination of payment sources and assigning amounts to each account.
Claim 6 merely recites the abstract concept of ranking payment sources.
Claim 7 merely recites the abstract concept of a default preference.
Claims 8 - 20 are virtually identical or analogous variations to various of the aforementioned claims and are ineligible for the same reasons as set forth above.
None of these claims provide any additional meaningful limitations, non-generic computer components, or specific assignments of functionality among those components. Likewise, if at all, these claims recite only generic, computer-related limitations which are recited at such a high level of generality as to be devoid of any meaningful Limitations. These limitations do not recite improvements in the functioning of the computer or to any other technology or technical field.
Therefore, these claims do not include additional elements that are sufficient to integrate the abstract idea into a practical application, nor do they amount to significantly more than the recited abstract idea because the additional elements, when considered both individually and as an ordered combination, constitute only a mere instruction to “apply” the abstract idea.
Thus, Claims 1 - 20 constitute ineligible subject matter under 35 USC § 101 as being directed to an abstract idea without more.
Claim Rejections - 35 USC § 103
3. 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 unpatentable over U.S. Patent Publication No. 2017/0293901 to Savla et al. (hereinafter “Savla”) in view of U.S. Patent Publication No. 2012/0101882 to Todd et al. (hereinafter “Todd”) and further in view of U.S. Patent Publication No. 2011/0218849 to Rutigliano et al. (hereinafter “Rutigliano”).
The Savla reference is in the same field of endeavor as the claimed invention – applying multiple payment vehicles to satisfy a single payment transaction.
The title is: Mobile transaction systems and devices
Savla teaches as follows in the Abstract:
“Systems and methods for processing mobile transactions include determining an indication to make a payment by a user to a payee; responsive to determining the indication, identifying, from a payment account associated with the user, a plurality of payment instruments; determining a first payment instrument in the plurality of payment instruments based at least in part on a first reward associated with making at least a portion of the payment using the first payment instrument; and generating a payment instrument alert to inform the user to make the payment using the first payment instrument.” (Emphasis Added)
The purpose of Savla is on point with the claimed invention - to use a “split payment” or a “split tender” technique to satisfy a payment transaction.
The problem recognized by the claimed invention is the same as addressed in Savla – the difficulty faced by a consumer when trying to apply a plurality of payment vehicles to a single transaction in the heat of the moment – “on the fly” as it where:
“[0002] Payment instruments such as, for example, credit cards or debit cards, have been widely used by consumers to make payments to various merchants. However, difficulties for selecting and using payment instruments for particular transactions still abound. For example, despite often carrying several payments cards, a user may always resort to a default payment card (e.g., a debit card linked to the user's primary checking account) when paying different types of merchants, even though the default payment card would not produce an optimal return (e.g., a discount associated with the use of a particular payment card) for the user in many of these transactions. This is because it is overly burdensome to a user to determine—on-the-fly—which payment instrument would produce the optimal return for a particular transaction..” (Emphasis Added)
Thus, Savla solves the problem in the exact manner as the claimed invention – receiving user preferences for applying various payment vehicles depending upon the different merchants with whom the user may be transaction.
“[0023] The customization module 166 may enable a user to provide preferences of payment instruments for consideration by the recommendation module 170, e.g., before or during a particular purchase. For example, a user already in credit card debt may prefer a credit card with a lower interest to that with a higher interest; a user with a low cash balance may prefer making a payment with credit (a credit card or a line of credit) to with a checking account, notwithstanding the potential interest. These user preferences may be provided to the customization module 166 as payment rules and applied by the recommendation module 170 when selecting a payment instrument. The reward calculation module 168 may determine rewards (e.g., cash backs or loyalty program points or rewards) for making a payment (or a portion thereof) with a particular payment instrument or with a payment reduction offer, or both. The recommendation module 170 may suggest to a user, or automatically select without user input, one or more payment instruments for application to a payment in accordance with user preferences provided by the customization module 166.” (Emphasis Added)
Thus, a split tender transaction can be easily carried out:
“[0043] In some embodiments, the new technologies discussed above are advantageous not only because payments may be split onto multiple payment instruments to produce greater rewards relative to using any single payment instrument, but also because automatically suggesting two or more payment instruments to produce greater rewards for a user may reduce (1) repetitive and often inefficient user operations on the payment device, e.g., switching between different applications in an attempt to manually calculate reward amount, and (2) data communication overhead between a user device and a remote computer service that result from, for example, numerous database queries and query results analysis for data relating to reward calculations.” (Emphasis Added)
The method of Savla is provided by a payment network or a so-called payment service, as shown in Fig. 2:
PNG
media_image1.png
893
784
media_image1.png
Greyscale
An efficient user interface is taught by Savla to simplify this process for the user by displaying various available payment vehicles, as shown below:
PNG
media_image2.png
832
518
media_image2.png
Greyscale
Accordingly, with regard to Claim 1, as outlined above, Savla teaches:
Broadest reasonable interpretation:
The Claims of a patent application must be “given their broadest reasonable interpretation consistent with the specification.” See MPEP §2111. Under a broadest reasonable interpretation (BRI), words of the claim must be given their plain meaning, unless such meaning is inconsistent with the specification (e.g. the specification gives the term a special meaning). The plain meaning of a term means the ordinary and customary meaning given to the term by those of ordinary skill in the art at the relevant time.
Here, no specialized meaning is detected from the specification; therefore, the plain and ordinary meaning of the Claim terms will be given.
Discussion of Cited References:
1. A method comprising: receiving a transaction authorization request for a transaction originated by a user presenting a primary payment source payment vehicle, the transaction authorization request including an identifier identifying a primary payment source account of a user and an identifier of a specific merchant at which the transaction originates;
(See at least Figs. 1 and 4 reproduced above and Abstract. As to an identifier for a payment source, Fig. 4 illustrates a 4 digit code under each payment method. As to a “primary” account, see 0002 relating to a “primary” checking account of the user. As to processing a request to process a transaction, see 0034 and Figs. 5A-5B, wherein a person of ordinary skill in the art would readily understand that processing a transaction with respect to discounts or offers offered by a specific merchant of necessity would involve identifying the merchant by its relevant identification mechanism, such as an identifier.)
(Moreover, the specification is replete with teachings regarding the identification or identifiers associated with payment source accounts, such as:
[0015] The present disclosure provides mobile devices, systems, and methods for optimizing mobile transactions. In an embodiment, after detecting that a user is making a purchase at a merchant (e.g., a grocery store or a website), the systems and methods may identify which payment instruments, e.g., credit cards and debit cards, are available in the user's account. The systems and methods may determine a reward (e.g., cash back, instant discount, loyalty program points, combinations thereof, etc.) for using each payment instrument such as, for example, a VISA® debit card offering a 5% cash back for any grocery purchases, a loyalty program credit card sponsored by the grocery store, a store-issued credit card offering $5 off a $20 or more purchase, and/or other rewards known in the art.” (Emphasis Added)
It would be well known and understood by a person of ordinary skill in the art that various encoded identifiers could be used to associate a payment account with the user.
As to a merchant identifier, 0002 refers to “different types of merchants,” thus indicating that Savla teaches merchant specific transactions. This is made clear in 0015 reproduced above. A merchant/payee identifier is also taught as follows:
“[0022] The user database 162 may store information identifying one or more user payment accounts 922. A user account 922 may include: one or more payment instruments 1018, one or more payment reduction offers (e.g., coupons) 102, and one or more user preferences 1022 for selecting payment instruments. The payee database 164 may store information identifying one or more payees (e.g., merchant names), payment restrictions, and payment reduction offers available from the one or more payees.” (Emphasis Added)
See also 0038 for savings/discounts offered by specific merchants, wherein “the payment service may determine” are available, clearly due to an identification of the merchant where the user is transacting. See also 0062.)
identifying, with respect to the transaction authorization request, preference settings linked, in a database, to the primary payment source account based on the identifier of the primary payment source account and the identifier of the specific merchant at which the transaction originates; and (See at least 0022 - 0023 as to user preferences and rules for applying payment sources. See also 0058 – 0066.)
processing the transaction using resources defined by an identified combination of payment source accounts from among a plurality of payment combinations based on the preference settings. (See at least [0042] – [0048] regarding a payment split.)
Therefore, Savla appears to teach all of the essential limitations of Claim 1; however, out of an abundance of caution, Todd is cited for its teachings related to linking accounts of the user and Rutigliano is cited for its teachings related to specific identifiers for linked accounts and a splitting a transaction or payment between two or more linked accounts.
Thus, Todd is in the same field of endeavor as the claimed invention and Savla – using multiple payment vehicles in a single payment transaction.
The title of Todd is: Multi-account payment consolidation system
The Abstract is as follows:
“A multi-account payment consolidation system and process, comprising a payment terminal at a point-of-sale. A central computer system is operatively coupled to the payment terminal through a network connection, the central computer system including at least a processor, and memory comprising program instructions. The program instructions are executable by the processor to register a plurality of external financial accounts and associate them with a user, register at least one customized rule-set for processing a payment associated with the user, authenticate the user when the user logs in at the payment terminal, automatically process the payment in accordance with the customized rule-set by accessing the external financial accounts, and receive a payment confirmation from the external financial accounts for display to the user on the payment terminal.” (Emphasis Added)
In Todd, a user can carry out the transaction according to pre-set rules or preferences or many apply payment vehicles manually, as illustrated in Fig. 2 below:
PNG
media_image3.png
879
624
media_image3.png
Greyscale
Thus, Todd teaches the user of an interface or display which gives the user various options, as listed above.
Rutigliano is also in the same field of endeavor as Savla and Todd and the claimed invention: linking multiple accounts.
The title is: Cloud platform for multiple account management & automated transaction processing
The Abstract reads as follows:
“Systems and corresponding methods for managing multiple accounts is provided comprising causing an interface screen to be displayed at a client device that allows a user to link a plurality of accounts to a unified payment device, each of the plurality of accounts having a unique identification number; receiving a request to purchase at least one item from a merchant at a point of sale using the unified payment device; identifying at least one of the plurality of accounts linked to the unique unified payment device to be used to pay for the purchase; processing the request to purchase the at least one item with the at least one of the plurality of accounts identified; and communicating approval for the purchase to the merchant.” (Emphasis Added)
Rutigliano’s teachings relating to Claim 1 are directly on point:
“[0016] In at least one embodiment, the at least one rule is merchant specific and wherein identifying the at least one account comprises identifying the merchant and processing the request to purchase the at least one item using a first account dictated by the at least one rule.” (Emphasis Added)
“[0035] Once these items are input into the system, the user is thereafter able to specify or input one or more purchase profiles. In this instance, the system receives the purchase profile data at 208. The purchase profile generally includes at least one rule that dictates how payment will be made when the unified payment card is used for purchases. The payment rule may be merchant or product specific. That is, a rule may apply to a specific merchant. For example, a purchase profile may include a rule that specifies that all purchases made at Starbucks or for coffee be paid automatically using a specific debit card. In this instance, upon swiping the unified payment card at Starbucks, the user's payment rule will be triggered automatically and the specified payment option will be used for the purchase. The rules may be set for broader categories of products. For example, another rule may be created for the “food” category, which dictates that these types of purchases be made using a specific credit card. The system or the user may keep record of which merchants are considered to be in the food business, and any time the user makes a purchase using the unified purchase card at a food category locale, the specified credit card will be used for payment.” (Emphasis Added)
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the multi-payment vehicle payment service of Savla to add the linking and display/interface features of Todd. The motivation to make this modification comes from Savla. It teaches, as quoted and illustrated above, that the user can store a combination of payment vehicles in advance, as preferences or rules. It would greatly enhance the efficiency and convenience of the system of Savla to add the display/interface features of Todd.
Furthermore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the combined multi-payment vehicle payment service of Savla in view of Todd to add the merchant identifier teachings of Rutigliano. The motivation to make this modification comes from Savla. It teaches, as quoted and illustrated above, that merchant identification is well known and understood by persons of ordinary skill in the art when processing payments. It would greatly enhance the efficiency and convenience of the system of Savla in view of Todd to add the identifiers of Rutigliano.
With regard to Claims 2 – 7, Savla in view of Todd in view of Rutigliano teaches:
2. The method of claim 1, wherein one or more identifiers of one or more supplemental payment source accounts are linked in the database to a primary payment source account of the user represented by a primary payment source payment vehicle, and wherein resources in the one or more supplemental payment source accounts are applicable to transactions by the user presenting only the primary payment source payment vehicle to originate the transactions. (See at least Savla: 0002 and 0028.)
3. The method of claim 1, wherein the preference settings comprise a payment combination comprising the primary payment source account and one or more supplemental payment source accounts, wherein the payment combination is linked to an identifier of the specific merchant and stored in the database linking the payment combination with the identifier of the primary payment source account and associating the payment combination with a specific merchant identifier. (See at least Savla: 0058 – 0066)
4. The method of claim 1, wherein the database is shared, at least with a merchant or a merchant acquirer, can be replicated, at least within a payment network, and can be updated using a block chain method. (See at least Savla: 0021, wherein a person of ordinary skill in the art would readily understand that shared databases or distributed databases can be implemented in a blockchain network.)
5. The method of claim 1, further comprising:querying the database to determine, using the identifier of the primary payment source account and the received identifier of the specific merchant, if there is, among the plurality of payment combinations, a combination of one or more payment source accounts to use in the transaction, from a group comprising one or more supplemental payment source accounts and the primary payment source account, and if there are one or more preference settings for applying the combination of payment source accounts in the transaction; andif the database has a combination of payment source accounts to use in the transaction and one or more preference settings for applying the combination of payment sources in the transaction, determining and assigning one or more amounts to be deducted for each of the one or more payment source accounts in the combination of payment source accounts to use in the transaction, using, one or more preference settings for applying the combination of payment source accounts in the transaction and based on the identifier of the specific merchant involved in the transaction; and if the database does not have a combination of payment source accounts to use in the transaction or one or more preference settings for applying the combination of payment sources in the transaction, assigning a transaction amount to be drawn from the primary payment source account. (See at least Savla: 0002 and 0042 – 0046.)
6. The method of claim 5, wherein the preference settings for applying the combination of payment source accounts in the transaction, includes, one or more of:ranking the one or more payment source accounts, from the combination of payment source accounts to use in the transaction, in an order in which accounts are to be drawn to satisfy the transaction amount during a transaction; assigning to each of the one or more payment source accounts, from the combination of payment source accounts to use in the transaction, a percentage of the transaction amount to be supplied by each payment source account to satisfy the transaction amount during the transaction; and assigning a minimum or maximum limit to an amount of funds that can be drawn from any one or more payment source accounts, from the combination of payment source accounts to use in the transaction. (See at least Savla: 0042 – 0046.)
7. The method of claim 5, wherein, one or more of the preference settings, the one or more supplemental payment source accounts, and the primary payment source account is assigned to be used by default in a transaction. (See at least Savla: 0002. See also Rutigliano: 0005 and 0036.)
With regard to Claim 8, this claim is essentially identical to Claim 1 and is obvious for the same reasons as set forth in that claim.
With regard to Claim 9, this claim is essentially identical to Claim 2 and is obvious for the same reasons as set forth in that claim.
With regard to Claim 10, this claim is essentially identical to Claim 3 and is obvious for the same reasons as set forth in that claim.
With regard to Claim 11, this claim is essentially identical to Claim 4 and is obvious for the same reasons as set forth in that claim.
With regard to Claim 12, this claim is essentially identical to Claim 5 and is obvious for the same reasons as set forth in that claim.
With regard to Claim 13, this claim is essentially identical to Claim 6 and is obvious for the same reasons as set forth in that claim.
With regard to Claim 14, this claim is essentially identical to Claim 7 and is obvious for the same reasons as set forth in that claim.
With regard to Claim 15, this claim is essentially identical to Claim 1 and is obvious for the same reasons as set forth in that claim.
With regard to Claim 16, this claim is essentially identical to Claim 2 and is obvious for the same reasons as set forth in that claim.
With regard to Claim 17, this claim is essentially identical to Claim 3 and is obvious for the same reasons as set forth in that claim.
With regard to Claim 18, this claim is essentially identical to Claim 4 and is obvious for the same reasons as set forth in that claim.
With regard to Claim 19, this claim is essentially identical to Claim 5 and is obvious for the same reasons as set forth in that claim.
With regard to Claim 20, this claim is essentially identical to Claim 6 and is obvious for the same reasons as set forth in that claim.
Conclusion
4. Applicant should carefully consider the following in connection with this Office Action:
A. Search and Prior Art
The search conducted in connection with this Office Action, as well as any previous Actions, encompassed the inventive concepts as defined in the Applicant’s specification. That is, the search(es) included concepts and features which are defined by the pending claims but also pertinent to significant although unclaimed subject matter. Accordingly, such search(es) were directed to the defined invention as well as the general state of the art, including references which are in the same field of endeavor as the present application as well as related fields (e.g. using a camera of a mobile device to capture a facial image of a user for authentication purposes). Indeed, there is a plethora of prior art in these fields.
Therefore, in addition to prior art references cited and applied in connection with this and any previous Office Actions, the following prior art is also made of record but not relied upon in the current rejection:
U.S. Patent Publication No.2015/0227957 to Bradley et a. This reference relates to the concept of identifying specific merchants.
U.S. Patent Publication No. 2017/0193484 to Pitz et al. This reference relates to the concept of linking payment accounts.
U.S. Patent Publication No. 2016/0171469 to Pugh et al. This reference relates to the concept of multiple payment sources at a POS.
U.S. Patent Publication No. 2012/0330825 to Shakkarwar. This reference relates to the concept of using preset rules.
U.S. Patent No. 9,235,831 to Rolf. This reference relates to the concept of merchant specific payment accounts.
U.S. Patent Publication No. 2017/0337546 to Holmes. This reference relates to the concept of merchant identifiers.
U.S. Patent Publication No. 2009/0119211 to Johnson. This reference relates to the concept of linking multiple accounts.
U.S. Patent Publication No. 2008/0301041 to Bruk. This reference relates to the concept of processing transactions using multiple accounts.
B. Responding to this Office Action
In view of the foregoing explanation of the scope of searches conducted in connection with the examination of this application, in preparing any response to this Action, Applicant is encouraged to carefully review the entire disclosures of the above-cited, unapplied references, as well as any previously cited references. It is likely that one or more such references disclose or suggest features which Applicant may seek to claim. Moreover, for the same reasons, Applicant is encouraged to review the entire disclosures of the references applied in the foregoing rejections and not just the sections mentioned.
C. Interviews and Compact Prosecution
The Office strongly encourages interviews as an important aspect of compact prosecution. Statistics and studies have shown that prosecution can be greatly advanced by way of interviews. Indeed, in many instances, during the course of one or more interviews, the Examiner and Applicant may reach an agreement on eligible and allowable subject matter that is supported by the specification.
Interviews are especially welcomed by this examiner at any stage of the prosecution process. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool (e.g. TEAMS). To facilitate the scheduling of an interview, the Examiner requests either a phone call at the number set forth below or the use of the AIR form as follows:
USPTO Automated Interview Request http://www.uspto.gov/interviewpractice.
Other forms of interview requests filed in this application may result in a delay in scheduling the interview because of the time required to appear on the Examiner's docket. Thus, the use of the AIR form is strongly encouraged.
D. Communicating with the Office
Any inquiry concerning this communication or earlier communications from the examiner should be directed to WILLIAM BUNKER whose telephone number is (571)272-0017. The examiner can normally be reached on M - F 8:30AM - 5:30PM, ET.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Abhishek Vyas, can be reached at 571-270-1836. Information regarding the status of an application, whether published or unpublished, may be obtained from the “Patent Center” system. For more information about the Patent Center system, see https://patentcenter.uspto.gov/
/William (Bill) Bunker/
U.S. Patent Examiner
AU 3691
(571) 272-0017 - office
william.bunker@uspto.gov
June 6, 2026
/ABHISHEK VYAS/Supervisory Patent Examiner, Art Unit 3691
Prosecution Insights