DETAILED ACTION
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on August 18, 2026 has been entered.
Status of the Claims
1. This action is in reply to the Request for Continued Examination dated August 18, 2026.
2. Claims 1-20 are currently pending and have been examined.
3. Claims 9 and 15-20 have been amended.
Notice of Pre-AIA or AIA Status
4. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Interpretation – Broadest Reasonable Interpretation
5. In determining patentability of an invention over the prior art, all claim limitations have been considered and interpreted using the “broadest reasonable interpretation consistent with the specification during the examination of a patent application since the applicant may then amend his claims.” See In re Prater and Wei, 162 USPQ 541, 550 (CCPA 1969); MPEP § 2111. Applicant always has the opportunity to amend the claims during prosecution, and broad interpretation by the examiner reduces the possibility that the claim, once issued, will be interpreted more broadly than is justified. See In re Prater, 162 USPQ 541, 550-51 (CCPA 1969); MPEP § 2111. Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 26 USPQ2d 1057 (Fed. Cir. 1993). See also MPEP 2173.05(q) All claim limitations have been considered. Additionally, all words in the claims have been considered in judging the patentability of the claims against the prior art. See MPEP 2143.03.
Claim limitations that contain statement(s) such as “if, may, might, can, could”, are treated as containing optional language. As matter of linguistic precision, optional claim elements do not narrow claim limitations, since they can always be omitted.
Claim limitations that contain statement(s) such as “wherein, whereby”, that fail to further define the steps or acts to be performed in method claims or the discrete physical structure required of system claims.
Similarly, a method step exercised or triggered upon the satisfaction of a condition, where there remains the possibility that the condition was not satisfied under the broadest reasonable interpretation, is an optional claim limitation. see MPEP § 2103(I)(C); In re Johnson, 77 USPQ2d 1788 (Fed Cir 2006). As the Applicant does not address what happens should the optional claim limitations fail, Examiner assumes that nothing happens (i.e., the method stops). An alternate interpretation is that merely the claim limitations based upon the condition are not triggered or performed.
The subject matter of a properly construed claim is defined by the terms that limit its scope. It is this subject matter that must be examined.
As a general matter, grammar and the plain meaning of terms as understood by one having ordinary skill in the art used in a claim will dictate whether, and to what extent, the language limits the claim scope. see MPEP §2013(I)(C). Language that suggests or makes a feature or step optional but does not require that feature or step does not limit the scope of a claim under the broadest reasonable claim interpretation. see MPEP §2013(I)(C).
Claim scope is not limited by claim language that suggests or makes optional but does not require steps to be performed, or by claim language that does not limit a claim to a particular structure. In addition, when a claim requires selection of an element from a list of alternatives, the prior art teaches the element if one of the alternatives is taught by the prior art. See, e.g., Fresenius USA, Inc. v. Baxter Int’l, Inc., 582 F.3d 1288, 1298 (Fed. Cir. 2009). See MPEP 2111.04, 2143.03.
Language in a method or system claim that states only the intended use or intended result, but does not result in a manipulative difference in the steps of the method claim nor a structural difference between the system claim and the prior art, fails to distinguish the claims from the prior art. In other words, if the prior art structure is capable of performing the intended use, then it meets the claim.
The following types of claim language may raise a question as to its limiting effect (this list is not exhaustive):
Statements of intended use or field of use, including statements of purpose or intended use in the preamble (MPEP 2111.02);
Clauses such as “adapted to”, “adapted for”, “wherein”, and “whereby” (MPEP 2111.04)
Contingent limitations (MPEP 2111.04)
Printed matter (MPEP 2111.05) and
Functional language associated with a claim term (MPEP 2181)
Examiner notes that during examination, “claims … are to be given their broadest reasonable interpretation consistent with the specification, and … claim language should be read in light of the specification as it would be interpreted by one of ordinary skill in the art.” See In re Bond, 15 USPQ 1566, 1568 (Fed. Cir. 1990), citing In re Sneed, 218 USPQ 385, 388 (Fed. Cir. 1983). However, "in examining the specification for proper context, [the examiner] will not at any time import limitations from the specification into the claims". See CollegeNet, Inc. v. ApplyYourself, Inc., 75 USPQ2d 1733, 1738 (Fed. Cir. 2005). Construing claims broadly during prosecution is not unfair to the applicant, because the applicant has the opportunity to amend the claims to obtain more precise claim coverage. See In re Yamamoto, 222 USPQ 934, 936 (Fed. Cir. 1984), citing In re Prater, 162 USPQ 541, 550 (CCPA 1969).
As such, while all claim limitations have been considered and all words in the claims have been considered in judging the patentability of the claimed invention, the following italicized language is interpreted as expressing the intended result of a process step positively recited and are not given additional weight:
As in Claim 1:
utilizing, after said transaction is completed, said customer file in conjunction with said identified sub-merchant and information from said completed transaction to automatically determine a reward value for said credit account customer;
As in Claim 2:
searching, in said database, said sub-merchant identifier to identify said sub-merchant;
As in Claim 3:
searching, in said database, said sub-merchant identifier in conjunction with said merchant aggregator to identify said sub-merchant;
As in Claim 9:
utilizing, after said transaction is completed, said customer file in conjunction with said identified sub-merchant and information from said completed transaction to automatically determine a reward value for said credit account customer;
As in Claim 15:
utilize, after said transaction is completed, said customer file in conjunction with said identified sub-merchant and information from said completed transaction to automatically determine a reward value for said credit account customer;
As in Claim 16:
searching, said database utilizing said sub-merchant identifier in conjunction with said merchant aggregator, to identify said sub-merchant;
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.
6. Claims 1-20 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to an abstract idea without significantly more.
ANALYSIS:
STEP 1:
Does the claimed invention fall within one of the four statutory categories of invention (process, machine, manufacture or composition matter?
Yes. Claim 1 recites a method claim. Claim 9 recites a non-transitory computer readable storage medium claim. Claim 15 recites a system claim.
STEP 2A:
Prong One: Does the Claim Recite A Judicial Exception (An Abstract Idea, Law of Nature or Natural Phenomenon)? (If Yes, Proceed to Prong Two, If No, the claim is not directed to a judicial exception and qualifies as subject matter patent eligible material)
Claim 1 recites the abstract idea of sub-merchant identification in a transaction authorization request as part of processing financial transactions. The idea is described by the following limitations:
receiving, from merchant aggregator, a transaction authorization request for a credit account customer;
scraping the transaction authorization request for data identifying a sub-merchant and a location of said sub-merchant;
identifying said sub-merchant;
storing said identified sub-merchant, said location of said sub-merchant, and said data identifying said sub-merchant;
providing a transaction authorization approval to said merchant aggregator;
determining a transaction related to said transaction authorization approval is completed;
accessing a customer file for said credit account customer;
utilizing, after said transaction is completed, said customer file in conjunction with said identified sub-merchant and information from said completed transaction to determine a reward value for said credit account customer; and
crediting the credit account customer with the determined reward value.
Claim 9 recites the abstract idea of sub-merchant identification in a transaction authorization request as part of processing financial transactions. The idea is described by the following limitations:
receiving, from merchant aggregator, a transaction authorization request for a credit account customer;
scraping the transaction authorization request for data identifying a sub-merchant and a location of said sub-merchant;
identifying said sub-merchant;
storing said identified sub-merchant, said location of said sub-merchant and said data identifying said sub-merchant;
providing a transaction authorization approval to said merchant aggregator;
determining a transaction related to said transaction authorization approval is was completed;
accessing a customer file for said credit account customer;
utilizing, after said transaction is completed, said customer file in conjunction with said identified sub-merchant and information from said completed transaction to determine identity a reward value for said credit account customer;
crediting the credit account customer with the determined reward value.
Claim 15 recites the abstract idea of sub-merchant identification in a transaction authorization request as part of processing financial transactions. The idea is described by the following limitations:
receiving, from a merchant aggregator, a transaction authorization request for a credit account customer;
scraping the transaction authorization request for data identifying a sub-merchant and a location of said sub-merchant;
identifying said sub-merchant;
storing said identified sub-merchant, said location of said sub-merchant and said data identifying said sub-merchant;
providing a transaction authorization approval to said merchant aggregator;
determining a transaction related to said transaction authorization approval is completed;
accessing a customer file for said credit account customer;
utilizing, after said transaction is completed, said customer file in conjunction with said identified sub-merchant and information from said completed transaction to determine a reward value for said credit account customer; and
crediting the credit account customer with the determined reward value.
The abstract ideas describe certain methods of organizing human activity.
As to certain methods of organizing human activity, the steps involve fundamental economic practices or principles [processing financial transactions]; commercial interactions [transaction processing], marketing or sales activities or behaviors [transaction processing by a merchant; determining rewards activities]; business relations; and/or managing personal behavior or relationships or interactions between people [transaction processing steps to identify relationships or interactions between merchants and sub-merchants; following rules; determining rewards activities]: (i.e., receiving, from merchant aggregator, a transaction authorization request for a credit account customer; scraping the transaction authorization request for data identifying a sub-merchant and a location of said sub-merchant; identifying said sub-merchant; storing said identified sub-merchant, said location of said sub-merchant, and said data identifying said sub-merchant; providing a transaction authorization approval to said merchant aggregator; determining a transaction related to said transaction authorization approval is completed; accessing a customer file for said credit account customer; utilizing, after said transaction is completed, said customer file in conjunction with said identified sub-merchant and information from said completed transaction to determine a reward value for said credit account customer; and crediting the credit account customer with the determined reward value)
In the case of the instant claims, the claims may recite no more than receiving information from a merchant aggregator about a transaction authorization request for a credit account customer; identifying a sub-merchant from data of a transaction authorization request, including a location of said sub-merchant; storing the data; providing a transaction approval to the merchant aggregator; determining a transaction related to the transaction authorization approval is completed; retrieving a customer file of the credit account customer; reviewing the data to determine a reward was warranted and the reward value; and crediting the credit account customer with the determined reward. (Step 2A, Prong 1: Yes, the claims are abstract)
Prong Two: Does the Claim Recite Additional Elements That Integrate The Judicial Exception Into A Practical Application of the Exception? (If Yes, the claim is not directed to a judicial exception and qualifies as subject matter patent eligible material. If No, Proceed to Step 2B)
The claims do not include additional elements that integrate the judicial exception into a practical application of the exception because the claims do not provide improvements to another technology or technical field, improvements to the functioning of the computer itself, are not applying or using a judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition, are not applying the judicial exception with, or by use of a particular machine, are not effecting a transformation or reduction of a particular article to a different state or thing, and are not applying the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment.
Claim 1 recites in the preamble that the claim is computer-implemented, a network, an electronic data transmission; that some steps are automatically undertaken and recites a database in the body of the claim.
Claim 9 recites a non-transitory computer-readable storage medium having instructions embodied therein, an electronic data transmission, that some steps are automatically undertaken, a database, a network and a computer system.
Claim 15 recites one or more processors, a computing system, a network, a memory storing instructions, a database, an electronic data transmission, that some steps are automatically undertaken, and one or more processors.
In particular, the claims only recite computer-implemented; a non-transitory computer-readable storage medium having instructions embodied therein, a network, a computer system, a memory storing instructions, a database, an electronic data transmission, that some steps are automatically undertaken, and one or more processors which are recited at a high level of generality (i.e., as a generic processor performing generic computer functions) such that it amounts to no more than mere instructions to apply the exception using a generic computer component. Use of a computer in its ordinary capacity for economic or other tasks (e.g., to receive, store or transmit data) or simply adding a general-purpose computer or computer components after the fact to the abstract idea does not integrate a judicial exception into a practical application or provide significantly more. (See MPEP 2106.05(f))
Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits of practicing the abstract idea. Therefore, Claims 1, 9 and 15 are directed to an abstract idea without a practical application. (Step 2A – Prong 2: No, the additional claimed elements are not integrated into a practical application)
STEP 2B: If there is an exception, determine if the claim as a whole recites significantly more than the judicial exception itself.
The courts have recognized the following computer functions as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity: i) receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network); but see DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 1258, 113 USPQ2d 1097, 1106 (Fed. Cir. 2014) ("Unlike the claims in Ultramercial, the claims at issue here specify how interactions with the Internet are manipulated to yield a desired result‐‐a result that overrides the routine and conventional sequence of events ordinarily triggered by the click of a hyperlink." (emphasis added)); ii) performing repetitive calculations, Flook, 437 U.S. at 594, 198 USPQ2d at 199 (recomputing or readjusting alarm limit values); Bancorp Services v. Sun Life, 687 F.3d 1266, 1278, 103 USPQ2d 1425, 1433 (Fed. Cir. 2012) ("The computer required by some of Bancorp’s claims is employed only for its most basic function, the performance of repetitive calculations, and as such does not impose meaningful limits on the scope of those claims."); iii) electronic recordkeeping, Alice Corp., 134 S. Ct. at 2359, 110 USPQ2d at 1984 (creating and maintaining "shadow accounts"); Ultramercial, 772 F.3d at 716, 112 USPQ2d at 1755 (updating an activity log); iv) storing and retrieving information in memory, 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; v) electronically scanning or extracting data from a physical document, Content Extraction and Transmission, LLC v. Wells Fargo Bank, 776 F.3d 1343, 1348, 113 USPQ2d 1354, 1358 (Fed. Cir. 2014) (optical character recognition); and vi) a web browser’s back and forward button functionality, Internet Patent Corp. v. Active Network, Inc., 790 F.3d 1343, 1348, 115 USPQ2d 1414, 1418 (Fed. Cir. 2015). (MPEP §2106.05(d)(II))
This listing is not meant to imply that all computer functions are well‐understood, routine, conventional activities, or that a claim reciting a generic computer component performing a generic computer function is necessarily ineligible. Courts have held computer‐implemented processes not to be significantly more than an abstract idea (and thus ineligible) where the claim as a whole amounts to nothing more than generic computer functions merely used to implement an abstract idea, such as an idea that could be done by a human analog (i.e., by hand or by merely thinking). On the other hand, courts have held computer-implemented processes to be significantly more than an abstract idea (and thus eligible), where generic computer components are able in combination to perform functions that are not merely generic. (MPEP §2106.05(d)(II) – emphasis added)
Below are examples of other types of activity that the courts have found to be well-understood, routine, conventional activity when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity: recording a customer’s order, Apple, Inc. v. Ameranth, Inc., 842 F.3d 1229, 1244, 120 USPQ2d 1844, 1856 (Fed. Cir. 2016); shuffling and dealing a standard deck of cards, In re Smith, 815 F.3d 816, 819, 118 USPQ2d 1245, 1247 (Fed. Cir. 2016); restricting public access to media by requiring a consumer to view an advertisement, Ultramercial, Inc. v. Hulu, LLC, 772 F.3d 709, 716-17, 112 USPQ2d 1750, 1755-56 (Fed. Cir. 2014); identifying undeliverable mail items, decoding data on those mail items, and creating output data, Return Mail, Inc. v. U.S. Postal Service, -- F.3d --, -- USPQ2d --, slip op. at 32 (Fed. Cir. August 28, 2017); presenting offers and gathering statistics, OIP Techs., 788 F.3d at 1362-63, 115 USPQ2d at 1092-93; determining an estimated outcome and setting a price, OIP Techs., 788 F.3d at 1362-63, 115 USPQ2d at 1092-93; and arranging a hierarchy of groups, sorting information, eliminating less restrictive pricing information and determining the price, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1331, 115 USPQ2d 1681, 1699 (Fed. Cir. 2015) (MPEP 2106.05(d))
Here, the steps are receiving or transmitting data over a network (Symantec, TLI, OIP Techs – MPEP 2106.05(d)(II); storing and retrieving information in memory (Versata, OIP Techs – MPEP 2106.05(d)(II) and electronically scanning or extracting data (Content Extraction – MPEP 2106.05(d)(II)– all of which have been recognized by the courts as well-understood, routine and conventional functions.
The claims are directed to an abstract idea with additional generic computer elements that do not add meaningful limitations to the abstract idea because they require no more than a generic computer to perform generic computer functions that are well-understood, routine, and conventional activities previously known in the industry.
For the next step of the analysis, it must be determined whether the limitations present in the claims represent a patent-eligible application of the abstract idea. A claim directed to a judicial exception must be analyzed to determine whether the elements of the claim, considered both individually and as an ordered combination are sufficient to ensure that the claim as a whole amounts to significantly more than the exception itself.
For the role of a computer in a computer implemented invention to be deemed meaningful in the context of this analysis, it must involve more than performance of “well-understood, routine, [and] conventional activities previously known to the industry.” Further, “the mere recitation of a generic computer cannot transform a patent ineligible abstract idea into a patent-eligible invention.”
Applicant’s specification discloses the following:
“Referring now to Figure 1, a block diagram of the components of the aggregated purchase environment 100 is shown. Although a number of components are shown, it should be appreciated that other, different, more, or fewer components may be used in different embodiments. In one embodiment, aggregated purchase environment 100 includes a merchant aggregator 10, one or more sub merchants (e.g., sub-merchant A 20, sub-merchant B 23, sub-merchant n, etc.), a customer 26, a credit account provider 200, and at least one network (e.g., cloud 50).” (See Applicant Spec para 23)
“In one embodiment, merchant aggregator 10 includes a computing system with one or more components similar to the computing system described in Figure 5. Merchant aggregator 10 can be a single machine, a virtual machine, a distributed system, a plurality of machines, or the like.” (See Applicant Spec para 27)
“In one embodiment, sub-merchant A 20, B 23, and n include one or more components of a computing system similar to the computing system described in Figure 5. In one embodiment, one, or some, of all of sub-merchant A 20, B 23, and n communicate with merchant aggregator 10 over a network such as network 50.” (See Applicant Spec para 28)
“In one embodiment, customer 36 is a customer’s computing system such as a mobile device, laptop, desktop, tablet, or the like. In one embodiment, customer 36 uses a computer system with one or more components similar to the computing system described in Figure 5. In one embodiment, the customer 36 computing system communicates with merchant aggregator 10 over a network such as network 50.” (See Applicant Spec para 29)
“In one embodiment, credit account provider 200 include one or more components of a computing system similar to the computing system described in Figure 5. Credit account provider 200 can be a single machine, a virtual machine, a distributed system, a plurality of machines, or the like. In one embodiment, credit account provider 200 communicates with merchant aggregator 10 over a network such as network 50.” (See Applicant Spec para 30)
“In one embodiment, credit provider system 200 can be a single machine, a virtual machine, a distributed system, a plurality of machines, or the like utilizing a network 226 connection between one or more of the components, the database 227, or the like. In one embodiment, network 226 is the Internet, a secure network, local area network, cellular network, a hybrid of two or more different networks, and the like.” (See Applicant Spec para 34)
“Database 227 could be a local database, a virtual database, a cloud database, a plurality of databases, or a combination thereof. In one embodiment, database 227 includes customer information such as, but not limited to, shopping preferences, credit account(s), shopping history, and the like.” (See Applicant Spec para 35)
“With reference now to Figure 5, portions of the technology for providing a communication composed of computer-readable and computer-executable instructions that reside, for example, in non-transitory computer-readable medium (or storage media, etc.) of a computer system. That is, Figure 5 illustrates one example of a type of computer that can be used to implement embodiments of the present technology. Figure 5 represents a system or components that may be used in conjunction with aspects of the present technology. In one embodiment, some or all of the components described herein may be combined with some or all of the components of Figure 5 to practice the present technology.” (See Applicant Spec para 53)
“Figure 5 illustrates an example computer system 500 used in accordance with embodiments of the present technology. It is appreciated that computer system 500 of Figure 5 is an example only and that the present technology can operate on or within a number of different computer systems including general purpose networked computer systems, embedded computer systems, routers, switches, server devices, user devices, various intermediate devices/artifacts, stand-alone computer systems, mobile phones, personal data assistants, televisions and the like. As shown in Figure 5, computer system 500 of Figure 5 is well adapted to having peripheral computer readable media 502 such as, for example, a disk, a compact disc, a flash drive, and the like coupled thereto.” (See Applicant Spec para 54)
“Computer system 500 of Figure 5 includes an address/data/control bus 504 for communicating information, and a processor 505A coupled to bus 504 for processing information and instructions. As depicted in Figure 5, computer system 500 is also well suited to a multi-processor environment in which a plurality of processors 505A, 505B, and 505C are present. Conversely, computer system 500 is also well suited to having a single processor such as, for example, processor 505A. Processors 505A, 505B, and 505C may be any of various types of microprocessors. Computer system 500 also includes data storage features such as a computer usable volatile memory 508, e.g., random access memory (RAM), coupled to bus 504 for storing information and instructions for processors 505A, 505B, and 505C.” (See Applicant Spec para 55)
“Computer system 500 also includes computer usable non-volatile memory 510, e.g., read only memory (ROM), coupled to bus 504 for storing static information and instructions for processors 505A, 505B, and 505C. Also present in computer system 500 is a data storage unit 512 (e.g., a magnetic disk drive, optical disk drive, solid state drive (SSD), and the like) coupled to bus 504 for storing information and instructions. Computer system 500 can also optionally include an alpha-numeric input device 514 including alphanumeric and function keys coupled to bus 504 for communicating information and command selections to processor 505A or processors 505A, 505B, and 505C. Computer system 500 can also optionally include an alpha-numeric input device 514 including alphanumeric and function keys coupled to bus 504 for communicating information and command selections to processor 505A or processors 505A, 505B, and 505C. Computer system 500 also can optionally include a cursor control device 515 coupled to bus 504 for communicating user input information and command selections to processor 505A or processors 505A, 505B, and 505C. Cursor control device may be a touch sensor, gesture recognition device, and the like. Computer system 500 of the present embodiment can optionally include a display 518 coupled to bus 504 for displaying information.” (See Applicant Spec para 56)
“Referring still to Figure 5, various other components are depicted for computer system 500. Specifically, when present, an operating system 522, applications 524, modules 525, and data 528 are shown as typically residing in one or some combination of computer usable volatile memory 508, e.g., random-access memory (RAM), and data storage unit 512. However, it is appreciated that in some embodiments, operating system 522 may be stored in other locations such as on a network or on a flash drive; and that further, operating system 522 may be accessed from a remote location via, for example, a coupling to the internet. In one embodiment, the present technology, for example, is stored as application 524 or module 525 in memory locations within RAM 508 and memory areas within data storage unit 512. The present technology may be applied to one or more elements of described computer system 500.” (See Applicant Spec para 59)
“Computer system 500 is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the present technology. Neither should the computing environment be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the example computer system 500.” (See Applicant Spec para 61)
“The present technology may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform particular tasks or implement particular abstract data types. The present technology may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communication network. In a distributed computing environment, program modules may be located in both local and remote computer-storage media including memory-storage devices.” (See Applicant Spec para 62)
Generic computer components recited as performing generic computer functions that are well-understood, routine and conventional activities amount to no more than implementing the abstract idea with a computerized system.
Looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. The collective functions appear to be implemented using conventional computer systemization.
For the reasons identified with respect to Step 2A, Prong 2, claims 1, 9 and 15 fail to recite additional elements that amount to an inventive concept. Use of a computer in its ordinary capacity for tasks (e.g., to receive, store or transmit data) or simply adding a general purpose computer or computer components after the fact to the abstract idea does not integrate a judicial exception into a practical application or provide significantly more. (See MPEP 2106.05(f))
Therefore, the claims do not include additional elements that are sufficient to amount to significantly more that the judicial exception. Upon reconsideration of the indicia noted under Step 2A in concert with the Step 2B considerations, the additional claim element(s) amounts to no more than mere instructions to apply the exception using generic computer components. The same analysis applies in Step 2B, i.e., mere instructions to apply an exception using a generic computer component cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. The claim does not provide an inventive concept significantly more than the abstract idea.
Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The independent claims 1, 9 and 15 are not patent eligible. (Step 2B: NO. The claims do not provide significantly more)
Dependent claims 2-8, 10-14 and 16-20 further define the abstract idea that is presented in the respective Independent claims 1, 9, and 15 and are further grouped as mental processes and certain methods of organizing human activity and are abstract for the same reasons and basis as presented above.
No further additional hardware components other than those found in the respective independent claims is recited, thus it is presumed that the claim is utilizing the same generic systemization as presented above. The dependent claims do not include any additional elements that integrate the abstract idea into a practical application of the exception or are sufficient to amount to significantly more than the judicial exception when considered both individually and as an ordered combination.
Thus, Claims 1-20 are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
7. Claim(s) 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Beer et al.
(US 2016/0048864) (“Beer”) in view of Carter et al. (US 2017/0286987) (“Carter”)
Regarding Claim 1, Beer discloses the following:
A computer-implemented method comprising:
receiving, from a merchant aggregator via a network, an electronic data transmission comprising a transaction authorization request for a credit account customer; (See Beer paras 18-20, 38, 46, 48-49, 54, 59-62 – user may add an item to their virtual cart on a merchant website, the transaction account holder may click on the merchant aggregator’s digital wallet to checkout. The transaction account holder sees the order total and saved payment information and completes the order. The merchant aggregator makes a request to the membership rewards program host to see if points can be used for the payment; in response to the transaction being eligible for the membership rewards program, the transaction account holder will verify the amount of points that can be used for the total order. The transaction account holder selects to pay with points and the merchant aggregator may transmit a service call to the membership rewards program host system to indicate that the transaction account holder wants to use points; merchant aggregator and merchant may be distinct entities)
automatically scraping the transaction authorization request for data identifying a sub-merchant and a location of said sub-merchant; (See Beer paras 19, 31-33, 48 – the merchant aggregator may transmit to the membership rewards program host the merchant name (e.g., merchant identifier) and total dollar amount to be exchanged for points. The membership rewards program host system records the pay with points intent and translates the merchant name into a merchant identifier. The merchant aggregator and merchant process the payment similar to a traditional transaction; the membership rewards program host system may translate merchant data communicated to the membership rewards program host into a known merchant identifier. The merchant aggregator may not have access to the merchant identifier used for authorizing/submitting charges, so the reference used by the merchant aggregator is provided to the membership rewards program host system. The membership rewards program host system may translate the merchant aggregator reference of the merchant to a known merchant identifier used by the transaction account processor, such as through referencing a database and/or use of a look-up table; merchant may request authorization of the transaction account for payment with a transaction account authorization system)
identifying said sub-merchant; (See Beer paras 19, 31 – merchant aggregator transmits merchant name {e.g., merchant identifier), membership rewards program host system records PWP intent and translates the merchant name into a merchant identifier)
storing said identified sub-merchant, said location of said sub-merchant, and said data in response to the merchant submitting the settlement for the charge to the membership rewards program host system, the membership rewards host system matches and/or links the record to the PWP intent that is being stored and requests that reward points be applied to the charge; membership rewards program host system may translate the merchant aggregator reference of the merchant to a known merchant identifier used by the transaction account processor, such as through referencing a database and/or use of a look-up table)
providing a transaction authorization approval to said merchant aggregator; (See Beer para 19, 31-33, 54, 59-62- the merchant aggregator and merchant process the payment similar to a traditional transaction in response to the merchant submitting the settlement for the charge to membership rewards program host system, the membership rewards program host system matches and/or links the record to the PWP intent that is being stored and requests that the rewards points to be applied to the charge; merchant may request authorization of the transaction account for payment with the transaction account authorization system)
determining a transaction related to said transaction authorization approval is completed; (See Beer paras 5, 19, 31-35 – the membership program host system checks eligibility for the redemption, accepts it and issues the statement credit to the transaction account used for the payment; membership rewards module may deduct points for redemption from the transaction account holders account and record charge details of the transaction and settlement. The membership rewards program host system may confirm redemption to the system. The database storing an intention registered by the transaction account holder to the PWP for the transaction may be updated to reflect the completed transaction)
accessing a customer file for said credit account customer; (See Beer paras 35-36 – transaction account holder may request the membership rewards program host system populate a list of intended pending charges/intended reward point redemption requests for selected transaction account from a membership reward interface)
utilizing, after said transaction is completed, said customer file in conjunction with said identified sub-merchant and information from said completed transaction to automatically determine a reward value for said credit account customer; (See Beer paras 5-6, 19, 33, 35-36, 46-48 - in response to the merchant submitting the settlement for the charge to the membership rewards program host system, the membership rewards host system matches and/or links the record to the PWP intent that is being stored and requests that reward points be applied to the charge; match and link the merchant charger and/or merchant transaction request with the intention registered by the transaction account holder to pay with points; list of intended pending redemption of reward points may be displayed)
automatically crediting the credit account customer with the determined reward value. (See Beer para 19 – the membership rewards program host system checks eligibility for the redemption, accepts it and issues the statement credit to the transaction account used for the payment. Points are deducted from the transaction account holder’s point balance in response to the merchant submitting the settlement charge (in contrast to be deducted at the time of purchase)
While Beer discloses the invention as claimed, it does not fully disclose the transaction authorization request or the location data of a sub-merchant as claimed. Further, while Beer does disclose the distinction between merchants versus a merchant aggregator, thus disclosing the limitations as to a merchant versus a sub-merchant, Carter also directly recites a sub-merchant and also details location data of a sub-merchant and identifying reward values.
Carter discloses methods and systems for real-time calculation of rewards associated with a commercial transaction. (See Carter Abstract) At the time a commercial transaction occurs, a user can be made aware of payment information associated with the transaction, made aware of reward information associated with the transaction and complete the transaction according to the associated payment information and reward information. (See Carter paras 26-27)
The system can comprise a merchant device to process an exchange (e.g., commercial transaction) between the merchant and consumers where the merchant device can be configured to receive account identifiers, product identifiers, and/or the like to process an exchange. (See Carter para 32) The merchant device can request the intermediary device to authorize, process, complete and/or the like, the exchange. (See Carter para 32) In an aspect, the merchant can be in communication with a reward device. (See Carter para 33)
In an aspect, the merchant device can be associated with a merchant identifier, which can be any identifier, token, character, string or the like, for differentiating one merchant and/or merchant device from another merchant or merchant device. (See Carter para 34) In a further aspect, the merchant identifier can identify a merchant or merchant device as belonging to a particular class of merchants or merchant devices. (See Carter para 34) The merchant device can report a current commercial transaction (e.g., current product purchase activity). (See Carter paras 34-35)
The system can comprise an intermediary device that can comprise a device supporting a payment network. (See Carter para 36) For example, a payment network can comprise system or network used for the transfer of money via the use of cash-substitutes (e.g., credit card, bank card, reward card, etc.) and in an aspect, the network can comprise a payment network. (See Carter para 36) The intermediary device can be managed by a third-party intermediary. (See Carter para 36 – merchant aggregator) The intermediary device can be configured to process exchanges (e.g., commercial transactions) between merchants and users (e.g., consumers). (See Carter para 36)
For example, a credit card can be swiped through a card reading device (e.g., POS, merchant device) to provide payment for a commercial transaction. (See Carter para 36) When the credit card is swiped through the card reading device, the card reading device can transmit an authorization request to a third party (e.g., a remote transaction card service provider, intermediary device). (See Carter para 36 – transaction authorization request, sent to merchant aggregator) For example, the intermediary device can operate as a third party processor and be configured to determine whether a current exchange is authorized. (See Carter para 36 – merchant aggregator) An authorization request can comprise a request for payment authorization of the commercial transaction and the request for payment authorization can comprise financial services information, description information, date information, time information, and payment information. (See Carter para 36 – transaction authorization request has financial information, description information, date and time information and payment information)
The authorization unit 134 [part of the intermediary device as seen in Fig. 1] can be configured to receive and process the authorization requests. (See Carter para 36 and Fig. 1) The request can comprise a merchant identifier, a product identifier, an account identifier and the like. (See Carter para 36)
The system can also comprise a reward device that can be in communication with a network and can comprise rewards data for calculation of one or more rewards and can comprise information related to a reward. (See Carter para 37) Reward information (e.g., merchant provided rewards, provisional rewards, etc.) can be associated with a user account and stored in memory. (See Carter para 37) The reward device 102 can receive and store information (e.g., user preference for certain types of rewards or other preference) associated with the user device and can provide, notify, send notification information to the user device, notifying the user of the user device of one or more merchants offering rewards associated with a particular commercial transaction. (See Carter para 38 – stores information) The user device can communicate commercial transaction information, location information, and other information associated with the user to reward device 102. (See Carter para 39 – user device can communicate location information) User device can communicate information associated with a current commercial transaction to, such as payment information, to reward device 102 through network 126, enabling reward device 102 to associate user device 118 to a user account based on an account identifier 112. (See Carter para 39) The association between the user device and the account identifier can enable reward device to automatically determine rewards associated with the user device. (See Carter para 39) For example, a user device may be used to communicate location information or other information associated with a commercial transaction at one or more merchant devices and can enable the reward device to determine a reward available to the user based on reward data associated with the current commercial transaction. (See Carter para 39 – customer information can be associated with the commercial transaction and one or more merchants to determine a reward available [identify reward value for said credit account customer using the transaction information [customer file] with one or more merchants [identified sub-merchant]; the user device may communicate location information or other information associated with a commercial transaction at one or more merchant devices)
In an aspect, the reward device can comprise rewards data for determining one or more rewards. (See Carter para 40 – identify reward value for credit account customer, see also paras 43-45) The reward data can comprise information related to a reward. (See Carter para 40) For example, the reward data can comprise one or more (e.g., a collection of) merchant identifiers. (See Carter para 40 – reward data includes merchant identifiers)
The reward device can comprise one or more (e.g., a collection of) merchant identifiers where the collection of merchant identifiers can comprise identifiers for business chains, individual locations of a chain, categories of merchants, terminals (e.g., transaction terminal of a specific merchant, identifying a sub-merchant) and/or the like that collectively form a merchant network. (See Carter para 40 – identifying a sub-merchant, wherein location [individual locations of a chain, identifying a transaction terminal of a specific merchant, identifying a sub-merchant] of a sub-merchant is part of the data)
Figure 8 further discloses a flowchart illustrating an example method where a user device can transmit to a rewards provider reward device, a provider of commercial based digital rewards and content for marketing promotions a notification of a pending commercial transaction at a merchant location (e.g., merchant device, retail store, business, gas pump, payment kiosk, etc.). (See Carter para 54 and Fig. 8) In an aspect, the notification can comprise information associated with a user (e.g., consumer), the commercial transaction, combinations thereof, and the like. (See Carter para 54) As an example, the notification can comprise consumer information, financial services information, description information, date information, time information and payment information associated with the commercial transaction and can additionally comprise location information, product information, merchant information, payment type information, combinations thereof and the like. (See Carter para 54)
Fig. 9 is a flowchart illustrating an example method 900. (See Carter para 61) In step 902, a rewards provider (e.g., reward device 102, a provider of commercial based digital rewards and content for marketing promotions, a provider of consumer loyalty rewards, etc.) can receive, from a computer device (e.g., user device 118), a notification of a pending commercial transaction at a merchant location (e.g., merchant device 124, retail store, business, gas pump, payment kiosk, etc.) (See Carter para 61 – notification of a pending commercial transaction at a merchant includes merchant location) In an aspect, the notification can comprise information associated with a user (e.g., a consumer) and/or commercial transaction. (See Carter para 61) As an example, the notification can comprise consumer information, financial services information, description information, data information, time information, and payment information associated with the commercial transaction and can additionally can comprise location information, product information, merchant information, payment type information, combinations thereof, and the like. (See Carter para 61 – notification includes merchant location information)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the instant invention to have modified the system, method and computer program product for utilizing loyalty and/or reward points as disclosed by Beer with the additional details of the contents of transaction authorization requests as taught by Carter in order to provide faster reward determinations associated with commercial transactions.
Regarding Claim 9, this claim recites substantially similar limitations as those seen in Claim 1 and as to those limitations is rejected for the same basis and reasons as disclosed above. Further, Beer discloses the following:
A non-transitory computer-readable storage medium having instructions embodied therein that when executed on a computer system cause said computer system to perform a method comprising: (See Beer paras 37, 67-68, 70-72, 91, 93)
Regarding Claim 15, this claim recites substantially similar limitations as those seen in Claim 1 and as to those limitations is rejected for the same basis and reasons as disclosed above. Further, Beer discloses the following:
A computing system comprising:
one or more processors; and (See Beer paras 37, 70-72, Cl. 20)
a memory; communicatively coupled with said one or more processors, the memory storing instructions that, when executed by said one or more processors, cause said computing system to perform a method comprising: (See Beer paras 37, 67-68, 70-72, Cl. 20)
Regarding Claim 2, this claim recites the limitations of Claim 1 and as to those limitations is rejected for the same basis and reasons as disclosed above. Further, Beer in view of Carter discloses the following:
wherein said identifying said sub-merchant further comprises:
obtaining a sub-merchant identifier from said transaction authorization request; and (See Beer para 31 - The merchant aggregator and merchant process the payment similar to a traditional transaction; the membership rewards program host system may translate merchant data communicated to the membership rewards program host into a known merchant identifier. The merchant aggregator may not have access to the merchant identifier used for authorizing/submitting charges, so the reference used by the merchant aggregator is provided to the membership rewards program host system.)
searching, in said database, said sub-merchant identifier to identify said sub-merchant; and (See Beer para 31 - The merchant aggregator and merchant process the payment similar to a traditional transaction; the membership rewards program host system may translate merchant data communicated to the membership rewards program host into a known merchant identifier. The merchant aggregator may not have access to the merchant identifier used for authorizing/submitting charges, so the reference used by the merchant aggregator is provided to the membership rewards program host system. The membership rewards program host system may translate the merchant aggregator reference of the merchant to a known merchant identifier used by the transaction account processor, such as through referencing a database and/or use of a look-up table)
relating said sub-merchant identifier with said identified sub-merchant at said database. (See Beer paras 19, 31 – membership rewards program host systems records the PWP intent and translates the merchant name into a merchant identifier; membership program host system may translate the merchant aggregator reference of the merchant to a known merchant identifier used by the transaction account processor, such as through referencing a database and/or use of a lookup table)
While Beer discloses the invention as claimed, it does not fully disclose the transaction authorization request or the location data of a sub-merchant as claimed. Further, while Beer does disclose the distinction between merchants versus a merchant aggregator, thus disclosing the limitations as to a merchant versus a sub-merchant, Carter also directly recites a sub-merchant and also details location data of a sub-merchant and identifying reward value.
Carter discloses methods and systems for real-time calculation of rewards associated with a commercial transaction. (See Carter Abstract) At the time a commercial transaction occurs, a user can be made aware of payment information associated with the transaction, made aware of reward information associated with the transaction and complete the transaction according to the associated payment information and reward information. (See Carter paras 26-27)
The system can comprise a merchant device to process an exchange (e.g., commercial transaction) between the merchant and consumers where the merchant device can be configured to receive account identifiers, product identifiers, and/or the like to process an exchange. (See Carter para 32) The merchant device can request the intermediary device to authorize, process, complete and/or the like, the exchange. (See Carter para 32) In an aspect, the merchant can be in communication with a reward device. (See Carter para 33)
In an aspect, the merchant device can be associated with a merchant identifier, which can be any identifier, token, character, string or the like, for differentiating one merchant and/or merchant device from another merchant or merchant device. (See Carter para 34) In a further aspect, the merchant identifier can identify a merchant or merchant device as belonging to a particular class of merchants or merchant devices. (See Carter para 34) The merchant device can report a current commercial transaction (e.g., current product purchase activity). (See Carter paras 34-35)
The system can comprise an intermediary device that can comprise a device supporting a payment network. (See Carter para 36) For example, a payment network can comprise system or network used for the transfer of money via the use of cash-substitutes (e.g., credit card, bank card, reward card, etc.) and in an aspect, the network can comprise a payment network. (See Carter para 36) The intermediary device can be managed by a third-party intermediary. (See Carter para 36 – merchant aggregator) The intermediary device can be configured to process exchanges (e.g., commercial transactions) between merchants and users (e.g., consumers). (See Carter para 36)
For example, a credit card can be swiped through a card reading device (e.g., POS, merchant device) to provide payment for a commercial transaction. (See Carter para 36) When the credit card is swiped through the card reading device, the card reading device can transmit an authorization request to a third party (e.g., a remote transaction card service provider, intermediary device). (See Carter para 36 – transaction authorization request, sent to merchant aggregator) For example, the intermediary device can operate as a third party processor and be configured to determine whether a current exchange is authorized. (See Carter para 36 – merchant aggregator) An authorization request can comprise a request for payment authorization of the commercial transaction and the request for payment authorization can comprise financial services information, description information, date information, time information, and payment information. (See Carter para 36 – transaction authorization request has financial information, description information, date and time information and payment information)
The authorization unit 134 [part of the intermediary device as seen in Fig. 1] can be configured to receive and process the authorization requests. (See Carter para 36 and Fig. 1) The request can comprise a merchant identifier, a product identifier, an account identifier and the like. (See Carter para 36)
The system can also comprise a reward device that can be in communication with a network and can comprise rewards data for calculation of one or more rewards and can comprise information related to a reward. (See Carter para 37) Reward information (e.g., merchant provided rewards, provisional rewards, etc.) can be associated with a user account and stored in memory. (See Carter para 37) The reward device 102 can receive and store information (e.g., user preference for certain types of rewards or other preference) associated with the user device and can provide, notify, send notification information to the user device, notifying the user of the user device of one or more merchants offering rewards associated with a particular commercial transaction. (See Carter para 38 – stores information) The user device can communicate commercial transaction information, location information, and other information associated with the user to reward device 102. (See Carter para 39 – user device can communicate location information) User device can communicate information associated with a current commercial transaction to, such as payment information, to reward device 102 through network 126, enabling reward device 102 to associate user device 118 to a user account based on an account identifier 112. (See Carter para 39) The association between the user device and the account identifier can enable reward device to automatically determine rewards associated with the user device. (See Carter para 39) For example, a user device may be used to communicate location information or other information associated with a commercial transaction at one or more merchant devices and can enable the reward device to determine a reward available to the user based on reward data associated with the current commercial transaction. (See Carter para 39 – customer information can be associated with the commercial transaction and one or more merchants to determine a reward available [identify reward value for said credit account customer using the transaction information [customer file] with one or more merchants [identified sub-merchant]; the user device may communicate location information or other information associated with a commercial transaction at one or more merchant devices)
In an aspect, the reward device can comprise rewards data for determining one or more rewards. (See Carter para 40 – identify reward value for credit account customer, see also paras 43-45) The reward data can comprise information related to a reward. (See Carter para 40) For example, the reward data can comprise one or more (e.g., a collection of) merchant identifiers. (See Carter para 40 – reward data includes merchant identifiers)
The reward device can comprise one or more (e.g., a collection of) merchant identifiers where the collection of merchant identifiers can comprise identifiers for business chains, individual locations of a chain, categories of merchants, terminals (e.g., transaction terminal of a specific merchant, identifying a sub-merchant) and/or the like that collectively form a merchant network. (See Carter para 40 – identifying a sub-merchant, wherein location [individual locations of a chain, identifying a transaction terminal of a specific merchant, identifying a sub-merchant] of a sub-merchant is part of the data)
Figure 8 further discloses a flowchart illustrating an example method where a user device can transmit to a rewards provider reward device, a provider of commercial based digital rewards and content for marketing promotions a notification of a pending commercial transaction at a merchant location (e.g., merchant device, retail store, business, gas pump, payment kiosk, etc.). (See Carter para 54 and Fig. 8) In an aspect, the notification can comprise information associated with a user (e.g., consumer), the commercial transaction, combinations thereof, and the like. (See Carter para 54) As an example, the notification can comprise consumer information, financial services information, description information, date information, time information and payment information associated with the commercial transaction and can additionally comprise location information, product information, merchant information, payment type information, combinations thereof and the like. (See Carter para 54)
Fig. 9 is a flowchart illustrating an example method 900. (See Carter para 61) In step 902, a rewards provider (e.g., reward device 102, a provider of commercial based digital rewards and content for marketing promotions, a provider of consumer loyalty rewards, etc.) can receive, from a computer device (e.g., user device 118), a notification of a pending commercial transaction at a merchant location (e.g., merchant device 124, retail store, business, gas pump, payment kiosk, etc.) (See Carter para 61 – notification of a pending commercial transaction at a merchant includes merchant location) In an aspect, the notification can comprise information associated with a user (e.g., a consumer) and/or commercial transaction. (See Carter para 61) As an example, the notification can comprise consumer information, financial services information, description information, data information, time information, and payment information associated with the commercial transaction and can additionally can comprise location information, product information, merchant information, payment type information, combinations thereof, and the like. (See Carter para 61 – notification includes merchant location information)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the instant invention to have modified the system, method and computer program product for utilizing loyalty and/or reward points as disclosed by Beer with the additional details of the contents of transaction authorization requests as taught by Carter in order to provide faster reward determinations associated with commercial transactions.
Regarding Claim 3, this claim recites the limitations of Claim 1 and as to those limitations is rejected for the same basis and reasons as disclosed above. Further, Beer in view of Carter discloses the following:
wherein said identifying said sub-merchant further comprises:
obtaining a merchant aggregator identifier from said transaction authorization request; (See Beer paras 19, 31-32, 48, 54, 59-62)
obtaining a sub-merchant identifier from said transaction authorization request; (See Beer para 31 - The merchant aggregator and merchant process the payment similar to a traditional transaction; the membership rewards program host system may translate merchant data communicated to the membership rewards program host into a known merchant identifier. The merchant aggregator may not have access to the merchant identifier used for authorizing/submitting charges, so the reference used by the merchant aggregator is provided to the membership rewards program host system.)
searching, in said database, said sub-merchant identifier in conjunction with said merchant aggregator to identify said sub-merchant. (See Beer para 31 - The merchant aggregator and merchant process the payment similar to a traditional transaction; the membership rewards program host system may translate merchant data communicated to the membership rewards program host into a known merchant identifier. The merchant aggregator may not have access to the merchant identifier used for authorizing/submitting charges, so the reference used by the merchant aggregator is provided to the membership rewards program host system. The membership rewards program host system may translate the merchant aggregator reference of the merchant to a known merchant identifier used by the transaction account processor, such as through referencing a database and/or use of a look-up table)
relating said merchant aggregator identifier and said sub-merchant identifier with said identified sub-merchant at said database. (See Beer paras 19, 31, 54, 59-62 – membership rewards program host systems records the PWP intent and translates the merchant name into a merchant identifier; membership program host system may translate the merchant aggregator reference of the merchant to a known merchant identifier used by the transaction account processor, such as through referencing a database and/or use of a lookup table)
While Beer discloses the invention as claimed, it does not fully disclose the transaction authorization request or the location data of a sub-merchant as claimed. Further, while Beer does disclose the distinction between merchants versus a merchant aggregator, thus disclosing the limitations as to a merchant versus a sub-merchant, Carter also directly recites a sub-merchant and also details location data of a sub-merchant and identifying reward expectations.
Carter discloses methods and systems for real-time calculation of rewards associated with a commercial transaction. (See Carter Abstract) At the time a commercial transaction occurs, a user can be made aware of payment information associated with the transaction, made aware of reward information associated with the transaction and complete the transaction according to the associated payment information and reward information. (See Carter paras 26-27)
The system can comprise a merchant device to process an exchange (e.g., commercial transaction) between the merchant and consumers where the merchant device can be configured to receive account identifiers, product identifiers, and/or the like to process an exchange. (See Carter para 32) The merchant device can request the intermediary device to authorize, process, complete and/or the like, the exchange. (See Carter para 32) In an aspect, the merchant can be in communication with a reward device. (See Carter para 33)
In an aspect, the merchant device can be associated with a merchant identifier, which can be any identifier, token, character, string or the like, for differentiating one merchant and/or merchant device from another merchant or merchant device. (See Carter para 34) In a further aspect, the merchant identifier can identify a merchant or merchant device as belonging to a particular class of merchants or merchant devices. (See Carter para 34) The merchant device can report a current commercial transaction (e.g., current product purchase activity). (See Carter paras 34-35)
The system can comprise an intermediary device that can comprise a device supporting a payment network. (See Carter para 36) For example, a payment network can comprise system or network used for the transfer of money via the use of cash-substitutes (e.g., credit card, bank card, reward card, etc.) and in an aspect, the network can comprise a payment network. (See Carter para 36) The intermediary device can be managed by a third-party intermediary. (See Carter para 36 – merchant aggregator) The intermediary device can be configured to process exchanges (e.g., commercial transactions) between merchants and users (e.g., consumers). (See Carter para 36)
For example, a credit card can be swiped through a card reading device (e.g., POS, merchant device) to provide payment for a commercial transaction. (See Carter para 36) When the credit card is swiped through the card reading device, the card reading device can transmit an authorization request to a third party (e.g., a remote transaction card service provider, intermediary device). (See Carter para 36 – transaction authorization request, sent to merchant aggregator) For example, the intermediary device can operate as a third party processor and be configured to determine whether a current exchange is authorized. (See Carter para 36 – merchant aggregator) An authorization request can comprise a request for payment authorization of the commercial transaction and the request for payment authorization can comprise financial services information, description information, date information, time information, and payment information. (See Carter para 36 – transaction authorization request has financial information, description information, date and time information and payment information)
The authorization unit 134 [part of the intermediary device as seen in Fig. 1] can be configured to receive and process the authorization requests. (See Carter para 36 and Fig. 1) The request can comprise a merchant identifier, a product identifier, an account identifier and the like. (See Carter para 36)
The system can also comprise a reward device that can be in communication with a network and can comprise rewards data for calculation of one or more rewards and can comprise information related to a reward. (See Carter para 37) Reward information (e.g., merchant provided rewards, provisional rewards, etc.) can be associated with a user account and stored in memory. (See Carter para 37) The reward device 102 can receive and store information (e.g., user preference for certain types of rewards or other preference) associated with the user device and can provide, notify, send notification information to the user device, notifying the user of the user device of one or more merchants offering rewards associated with a particular commercial transaction. (See Carter para 38 – stores information) The user device can communicate commercial transaction information, location information, and other information associated with the user to reward device 102. (See Carter para 39 – user device can communicate location information) User device can communicate information associated with a current commercial transaction to, such as payment information, to reward device 102 through network 126, enabling reward device 102 to associate user device 118 to a user account based on an account identifier 112. (See Carter para 39) The association between the user device and the account identifier can enable reward device to automatically determine rewards associated with the user device. (See Carter para 39) For example, a user device may be used to communicate location information or other information associated with a commercial transaction at one or more merchant devices and can enable the reward device to determine a reward available to the user based on reward data associated with the current commercial transaction. (See Carter para 39 – customer information can be associated with the commercial transaction and one or more merchants to determine a reward available [identify reward value for said credit account customer using the transaction information [customer file] with one or more merchants [identified sub-merchant]; the user device may communicate location information or other information associated with a commercial transaction at one or more merchant devices)
In an aspect, the reward device can comprise rewards data for determining one or more rewards. (See Carter para 40 – identify reward value for credit account customer, see also paras 43-45) The reward data can comprise information related to a reward. (See Carter para 40) For example, the reward data can comprise one or more (e.g., a collection of) merchant identifiers. (See Carter para 40 – reward data includes merchant identifiers)
The reward device can comprise one or more (e.g., a collection of) merchant identifiers where the collection of merchant identifiers can comprise identifiers for business chains, individual locations of a chain, categories of merchants, terminals (e.g., transaction terminal of a specific merchant, identifying a sub-merchant) and/or the like that collectively form a merchant network. (See Carter para 40 – identifying a sub-merchant, wherein location [individual locations of a chain, identifying a transaction terminal of a specific merchant, identifying a sub-merchant] of a sub-merchant is part of the data)
Figure 8 further discloses a flowchart illustrating an example method where a user device can transmit to a rewards provider reward device, a provider of commercial based digital rewards and content for marketing promotions a notification of a pending commercial transaction at a merchant location (e.g., merchant device, retail store, business, gas pump, payment kiosk, etc.). (See Carter para 54 and Fig. 8) In an aspect, the notification can comprise information associated with a user (e.g., consumer), the commercial transaction, combinations thereof, and the like. (See Carter para 54) As an example, the notification can comprise consumer information, financial services information, description information, date information, time information and payment information associated with the commercial transaction and can additionally comprise location information, product information, merchant information, payment type information, combinations thereof and the like. (See Carter para 54)
Fig. 9 is a flowchart illustrating an example method 900. (See Carter para 61) In step 902, a rewards provider (e.g., reward device 102, a provider of commercial based digital rewards and content for marketing promotions, a provider of consumer loyalty rewards, etc.) can receive, from a computer device (e.g., user device 118), a notification of a pending commercial transaction at a merchant location (e.g., merchant device 124, retail store, business, gas pump, payment kiosk, etc.) (See Carter para 61 – notification of a pending commercial transaction at a merchant includes merchant location) In an aspect, the notification can comprise information associated with a user (e.g., a consumer) and/or commercial transaction. (See Carter para 61) As an example, the notification can comprise consumer information, financial services information, description information, data information, time information, and payment information associated with the commercial transaction and can additionally can comprise location information, product information, merchant information, payment type information, combinations thereof, and the like. (See Carter para 61 – notification includes merchant location information)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the instant invention to have modified the system, method and computer program product for utilizing loyalty and/or reward points as disclosed by Beer with the additional details of the contents of transaction authorization requests as taught by Carter in order to provide faster reward determinations associated with commercial transactions.
Regarding Claims 4, 12 and 17, these substantially similar claims recite the limitations of Claims 1, 9 and 15 and as to those limitations are rejected for the same basis and reasons as disclosed above. Further, Beer in view of Carter discloses the following:
obtaining an item description from said transaction authorization request; and
automatically determining said reward value based on said item description and said identified sub-merchant. (See Beer paras 19, 33, 48)
While Beer discloses the invention as claimed, it does not fully disclose the transaction authorization request or the location data of a sub-merchant as claimed. Further, while Beer does disclose the distinction between merchants versus a merchant aggregator, thus disclosing the limitations as to a merchant versus a sub-merchant, Carter also directly recites a sub-merchant and also details location data of a sub-merchant and identifying reward expectations.
Carter discloses methods and systems for real-time calculation of rewards associated with a commercial transaction. (See Carter Abstract) At the time a commercial transaction occurs, a user can be made aware of payment information associated with the transaction, made aware of reward information associated with the transaction and complete the transaction according to the associated payment information and reward information. (See Carter paras 26-27)
The system can comprise a merchant device to process an exchange (e.g., commercial transaction) between the merchant and consumers where the merchant device can be configured to receive account identifiers, product identifiers, and/or the like to process an exchange. (See Carter para 32) The merchant device can request the intermediary device to authorize, process, complete and/or the like, the exchange. (See Carter para 32) In an aspect, the merchant can be in communication with a reward device. (See Carter para 33)
In an aspect, the merchant device can be associated with a merchant identifier, which can be any identifier, token, character, string or the like, for differentiating one merchant and/or merchant device from another merchant or merchant device. (See Carter para 34) In a further aspect, the merchant identifier can identify a merchant or merchant device as belonging to a particular class of merchants or merchant devices. (See Carter para 34) The merchant device can report a current commercial transaction (e.g., current product purchase activity). (See Carter paras 34-35)
The system can comprise an intermediary device that can comprise a device supporting a payment network. (See Carter para 36) For example, a payment network can comprise system or network used for the transfer of money via the use of cash-substitutes (e.g., credit card, bank card, reward card, etc.) and in an aspect, the network can comprise a payment network. (See Carter para 36) The intermediary device can be managed by a third-party intermediary. (See Carter para 36 – merchant aggregator) The intermediary device can be configured to process exchanges (e.g., commercial transactions) between merchants and users (e.g., consumers). (See Carter para 36)
For example, a credit card can be swiped through a card reading device (e.g., POS, merchant device) to provide payment for a commercial transaction. (See Carter para 36) When the credit card is swiped through the card reading device, the card reading device can transmit an authorization request to a third party (e.g., a remote transaction card service provider, intermediary device). (See Carter para 36 – transaction authorization request, sent to merchant aggregator) For example, the intermediary device can operate as a third party processor and be configured to determine whether a current exchange is authorized. (See Carter para 36 – merchant aggregator) An authorization request can comprise a request for payment authorization of the commercial transaction and the request for payment authorization can comprise financial services information, description information, date information, time information, and payment information. (See Carter para 36 – transaction authorization request has financial information, description information, date and time information and payment information)
The authorization unit 134 [part of the intermediary device as seen in Fig. 1] can be configured to receive and process the authorization requests. (See Carter para 36 and Fig. 1) The request can comprise a merchant identifier, a product identifier, an account identifier and the like. (See Carter para 36)
The system can also comprise a reward device that can be in communication with a network and can comprise rewards data for calculation of one or more rewards and can comprise information related to a reward. (See Carter para 37 - calculation of one or more rewards) Reward information (e.g., merchant provided rewards, provisional rewards, etc.) can be associated with a user account and stored in memory. (See Carter para 37) The reward device 102 can receive and store information (e.g., user preference for certain types of rewards or other preference) associated with the user device and can provide, notify, send notification information to the user device, notifying the user of the user device of one or more merchants offering rewards associated with a particular commercial transaction. (See Carter para 38 – stores information) The user device can communicate commercial transaction information, location information, and other information associated with the user to reward device 102. (See Carter para 39 – user device can communicate location information) User device can communicate information associated with a current commercial transaction to, such as payment information, to reward device 102 through network 126, enabling reward device 102 to associate user device 118 to a user account based on an account identifier 112. (See Carter para 39) The association between the user device and the account identifier can enable reward device to automatically determine rewards associated with the user device. (See Carter para 39) For example, a user device may be used to communicate location information or other information associated with a commercial transaction at one or more merchant devices and can enable the reward device to determine a reward available to the user based on reward data associated with the current commercial transaction. (See Carter para 39 – customer information can be associated with the commercial transaction and one or more merchants to determine a reward available [identify reward value for said credit account customer using the transaction information [customer file] with one or more merchants [identified sub-merchant]; the user device may communicate location information or other information associated with a commercial transaction at one or more merchant devices)
In an aspect, the reward device can comprise rewards data for determining one or more rewards. (See Carter para 40 – identify reward value for credit account customer, see also paras 43-45) The reward data can comprise information related to a reward. (See Carter para 40) For example, the reward data can comprise one or more (e.g., a collection of) merchant identifiers. (See Carter para 40 – reward data includes merchant identifiers)
The reward device can comprise one or more (e.g., a collection of) merchant identifiers where the collection of merchant identifiers can comprise identifiers for business chains, individual locations of a chain, categories of merchants, terminals (e.g., transaction terminal of a specific merchant, identifying a sub-merchant) and/or the like that collectively form a merchant network. (See Carter para 40 – identifying a sub- merchant, wherein location [individual locations of a chain, identifying a transaction terminal of a specific merchant, identifying a sub-merchant] of a sub-merchant is part of the data)
Figure 8 further discloses a flowchart illustrating an example method where a user device can transmit to a rewards provider reward device, a provider of commercial based digital rewards and content for marketing promotions a notification of a pending commercial transaction at a merchant location (e.g., merchant device, retail store, business, gas pump, payment kiosk, etc.). (See Carter para 54 and Fig. 8) In an aspect, the notification can comprise information associated with a user (e.g., consumer), the commercial transaction, combinations thereof, and the like. (See Carter para 54) As an example, the notification can comprise consumer information, financial services information, description information, date information, time information and payment information associated with the commercial transaction and can additionally comprise location information, product information, merchant information, payment type information, combinations thereof and the like. (See Carter para 54 – information also includes product information and description information [item description])
Fig. 9 is a flowchart illustrating an example method 900. (See Carter para 61) In step 902, a rewards provider (e.g., reward device 102, a provider of commercial based digital rewards and content for marketing promotions, a provider of consumer loyalty rewards, etc.) can receive, from a computer device (e.g., user device 118), a notification of a pending commercial transaction at a merchant location (e.g., merchant device 124, retail store, business, gas pump, payment kiosk, etc.) (See Carter para 61 – notification of a pending commercial transaction at a merchant includes merchant location) In an aspect, the notification can comprise information associated with a user (e.g., a consumer) and/or commercial transaction. (See Carter para 61) As an example, the notification can comprise consumer information, financial services information, description information, data information, time information, and payment information associated with the commercial transaction and can additionally can comprise location information, product information, merchant information, payment type information, combinations thereof, and the like. (See Carter para 61 – notification includes merchant location information)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the instant invention to have modified the system, method and computer program product for utilizing loyalty and/or reward points as disclosed by Beer with the additional details of the contents of transaction authorization requests as taught by Carter in order to provide faster reward determinations associated with commercial transactions.
Regarding Claims 5, 13, and 18, these substantially similar claims recite the limitations of Claims 1, 9, and 15 and as to those limitations are rejected for the same basis and reasons as disclosed above. Further, Beer in view of Carter discloses the following:
obtaining a cost from said transaction authorization request; and
automatically determining said reward value based on said cost and said identified sub-merchant. (See Beer paras 19, 33, 48)
While Beer discloses the invention as claimed, it does not fully disclose the cost from said transaction authorization request or the location data of a sub-merchant as claimed. Further, while Beer does disclose the distinction between merchants versus a merchant aggregator, thus disclosing the limitations as to a merchant versus a sub-merchant, Carter also directly recites a sub-merchant, obtaining a cost and details location data of a sub-merchant and identifying reward expectations.
Carter discloses methods and systems for real-time calculation of rewards associated with a commercial transaction. (See Carter Abstract) At the time a commercial transaction occurs, a user can be made aware of payment information associated with the transaction, made aware of reward information associated with the transaction and complete the transaction according to the associated payment information and reward information. (See Carter paras 26-27)
The system can comprise a merchant device to process an exchange (e.g., commercial transaction) between the merchant and consumers where the merchant device can be configured to receive account identifiers, product identifiers, and/or the like to process an exchange. (See Carter para 32) The merchant device can request the intermediary device to authorize, process, complete and/or the like, the exchange. (See Carter para 32) In an aspect, the merchant can be in communication with a reward device. (See Carter para 33)
In an aspect, the merchant device can be associated with a merchant identifier, which can be any identifier, token, character, string or the like, for differentiating one merchant and/or merchant device from another merchant or merchant device. (See Carter para 34) In a further aspect, the merchant identifier can identify a merchant or merchant device as belonging to a particular class of merchants or merchant devices. (See Carter para 34) The merchant device can report a current commercial transaction (e.g., current product purchase activity). (See Carter paras 34-35 – price is the cost)
The system can comprise an intermediary device that can comprise a device supporting a payment network. (See Carter para 36) For example, a payment network can comprise system or network used for the transfer of money via the use of cash-substitutes (e.g., credit card, bank card, reward card, etc.) and in an aspect, the network can comprise a payment network. (See Carter para 36) The intermediary device can be managed by a third-party intermediary. (See Carter para 36 – merchant aggregator) The intermediary device can be configured to process exchanges (e.g., commercial transactions) between merchants and users (e.g., consumers). (See Carter para 36)
For example, a credit card can be swiped through a card reading device (e.g., POS, merchant device) to provide payment for a commercial transaction. (See Carter para 36) When the credit card is swiped through the card reading device, the card reading device can transmit an authorization request to a third party (e.g., a remote transaction card service provider, intermediary device). (See Carter para 36 – transaction authorization request, sent to merchant aggregator) For example, the intermediary device can operate as a third party processor and be configured to determine whether a current exchange is authorized. (See Carter para 36 – merchant aggregator) An authorization request can comprise a request for payment authorization of the commercial transaction and the request for payment authorization can comprise financial services information, description information, date information, time information, and payment information. (See Carter para 36 – transaction authorization request has financial information, description information, date and time information and payment information [cost information])
The authorization unit 134 [part of the intermediary device as seen in Fig. 1] can be configured to receive and process the authorization requests. (See Carter para 36 and Fig. 1) The request can comprise a merchant identifier, a product identifier, an account identifier and the like. (See Carter para 36)
The system can also comprise a reward device that can be in communication with a network and can comprise rewards data for calculation of one or more rewards and can comprise information related to a reward. (See Carter para 37 – calculation of one or more rewards) Reward information (e.g., merchant provided rewards, provisional rewards, etc.) can be associated with a user account and stored in memory. (See Carter para 37) The reward device 102 can receive and store information (e.g., user preference for certain types of rewards or other preference) associated with the user device and can provide, notify, send notification information to the user device, notifying the user of the user device of one or more merchants offering rewards associated with a particular commercial transaction. (See Carter para 38 – stores information) The user device can communicate commercial transaction information, location information, and other information associated with the user to reward device 102. (See Carter para 39 – user device can communicate location information) User device can communicate information associated with a current commercial transaction to, such as payment information, to reward device 102 through network 126, enabling reward device 102 to associate user device 118 to a user account based on an account identifier 112. (See Carter para 39) The association between the user device and the account identifier can enable reward device to automatically determine rewards associated with the user device. (See Carter para 39) For example, a user device may be used to communicate location information or other information associated with a commercial transaction at one or more merchant devices and can enable the reward device to determine a reward available to the user based on reward data associated with the current commercial transaction. (See Carter para 39 – customer information can be associated with the commercial transaction and one or more merchants to determine a reward available [identify reward value for said credit account customer using the transaction information [customer file] with one or more merchants [identified sub-merchant]; the user device may communicate location information or other information associated with a commercial transaction at one or more merchant devices)
In an aspect, the reward device can comprise rewards data for determining one or more rewards. (See Carter para 40 – identify reward value for credit account customer, see also paras 43-45) The reward data can comprise information related to a reward. (See Carter para 40) For example, the reward data can comprise one or more (e.g., a collection of) merchant identifiers. (See Carter para 40 – reward data includes merchant identifiers)
The reward device can comprise one or more (e.g., a collection of) merchant identifiers where the collection of merchant identifiers can comprise identifiers for business chains, individual locations of a chain, categories of merchants, terminals (e.g., transaction terminal of a specific merchant, identifying a sub-merchant) and/or the like that collectively form a merchant network. (See Carter para 40 – identifying a sub-merchant, wherein location [individual locations of a chain, identifying a transaction terminal of a specific merchant, identifying a sub-merchant] of a sub-merchant is part of the data)
Figure 8 further discloses a flowchart illustrating an example method where a user device can transmit to a rewards provider reward device, a provider of commercial based digital rewards and content for marketing promotions a notification of a pending commercial transaction at a merchant location (e.g., merchant device, retail store, business, gas pump, payment kiosk, etc.). (See Carter para 54 and Fig. 8) In an aspect, the notification can comprise information associated with a user (e.g., consumer), the commercial transaction, combinations thereof, and the like. (See Carter para 54) As an example, the notification can comprise consumer information, financial services information, description information, date information, time information and payment information associated with the commercial transaction and can additionally comprise location information, product information, merchant information, payment type information, combinations thereof and the like. (See Carter para 54)
Fig. 9 is a flowchart illustrating an example method 900. (See Carter para 61) In step 902, a rewards provider (e.g., reward device 102, a provider of commercial based digital rewards and content for marketing promotions, a provider of consumer loyalty rewards, etc.) can receive, from a computer device (e.g., user device 118), a notification of a pending commercial transaction at a merchant location (e.g., merchant device 124, retail store, business, gas pump, payment kiosk, etc.) (See Carter para 61 – notification of a pending commercial transaction at a merchant includes merchant location) In an aspect, the notification can comprise information associated with a user (e.g., a consumer) and/or commercial transaction. (See Carter para 61) As an example, the notification can comprise consumer information, financial services information, description information, data information, time information, and payment information associated with the commercial transaction and can additionally can comprise location information, product information, merchant information, payment type information, combinations thereof, and the like. (See Carter para 61 – notification includes merchant location information)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the instant invention to have modified the system, method and computer program product for utilizing loyalty and/or reward points as disclosed by Beer with the additional details of the contents of transaction authorization requests as taught by Carter in order to provide faster reward determinations associated with commercial transactions.
Regarding Claims 6, 14, and 19, these substantially similar claims recite the limitations of Claims 1, 9, and 15 and as to those limitations are rejected for the same basis and reasons as disclosed above. Further, Beer in view of Carter discloses the following:
obtaining a date from said transaction authorization request; and
automatically determining said reward value based on said date and said identified sub-merchant. (See Beer paras 19, 33, 48)
While Beer discloses the invention as claimed, it does not fully disclose the date from said transaction authorization request or the location data of a sub-merchant as claimed. Further, while Beer does disclose the distinction between merchants versus a merchant aggregator, thus disclosing the limitations as to a merchant versus a sub-merchant, Carter also directly recites a sub-merchant and also details location data of a sub-merchant and identifying reward expectations.
Carter discloses methods and systems for real-time calculation of rewards associated with a commercial transaction. (See Carter Abstract) At the time a commercial transaction occurs, a user can be made aware of payment information associated with the transaction, made aware of reward information associated with the transaction and complete the transaction according to the associated payment information and reward information. (See Carter paras 26-27)
The system can comprise a merchant device to process an exchange (e.g., commercial transaction) between the merchant and consumers where the merchant device can be configured to receive account identifiers, product identifiers, and/or the like to process an exchange. (See Carter para 32) The merchant device can request the intermediary device to authorize, process, complete and/or the like, the exchange. (See Carter para 32) In an aspect, the merchant can be in communication with a reward device. (See Carter para 33)
In an aspect, the merchant device can be associated with a merchant identifier, which can be any identifier, token, character, string or the like, for differentiating one merchant and/or merchant device from another merchant or merchant device. (See Carter para 34) In a further aspect, the merchant identifier can identify a merchant or merchant device as belonging to a particular class of merchants or merchant devices. (See Carter para 34) The merchant device can report a current commercial transaction (e.g., current product purchase activity). (See Carter paras 34-35 – price is the cost)
The system can comprise an intermediary device that can comprise a device supporting a payment network. (See Carter para 36) For example, a payment network can comprise system or network used for the transfer of money via the use of cash-substitutes (e.g., credit card, bank card, reward card, etc.) and in an aspect, the network can comprise a payment network. (See Carter para 36) The intermediary device can be managed by a third-party intermediary. (See Carter para 36 – merchant aggregator) The intermediary device can be configured to process exchanges (e.g., commercial transactions) between merchants and users (e.g., consumers). (See Carter para 36)
For example, a credit card can be swiped through a card reading device (e.g., POS, merchant device) to provide payment for a commercial transaction. (See Carter para 36) When the credit card is swiped through the card reading device, the card reading device can transmit an authorization request to a third party (e.g., a remote transaction card service provider, intermediary device). (See Carter para 36 – transaction authorization request, sent to merchant aggregator) For example, the intermediary device can operate as a third party processor and be configured to determine whether a current exchange is authorized. (See Carter para 36 – merchant aggregator) An authorization request can comprise a request for payment authorization of the commercial transaction and the request for payment authorization can comprise financial services information, description information, date information, time information, and payment information. (See Carter para 36 – transaction authorization request has financial information, description information, date and time information and payment information [date information])
The authorization unit 134 [part of the intermediary device as seen in Fig. 1] can be configured to receive and process the authorization requests. (See Carter para 36 and Fig. 1) The request can comprise a merchant identifier, a product identifier, an account identifier and the like. (See Carter para 36)
The system can also comprise a reward device that can be in communication with a network and can comprise rewards data for calculation of one or more rewards and can comprise information related to a reward. (See Carter para 37 – calculation of one or more rewards) Reward information (e.g., merchant provided rewards, provisional rewards, etc.) can be associated with a user account and stored in memory. (See Carter para 37) The reward device 102 can receive and store information (e.g., user preference for certain types of rewards or other preference) associated with the user device and can provide, notify, send notification information to the user device, notifying the user of the user device of one or more merchants offering rewards associated with a particular commercial transaction. (See Carter para 38 – stores information) The user device can communicate commercial transaction information, location information, and other information associated with the user to reward device 102. (See Carter para 39 – user device can communicate location information) User device can communicate information associated with a current commercial transaction to, such as payment information, to reward device 102 through network 126, enabling reward device 102 to associate user device 118 to a user account based on an account identifier 112. (See Carter para 39) The association between the user device and the account identifier can enable reward device to automatically determine rewards associated with the user device. (See Carter para 39) For example, a user device may be used to communicate location information or other information associated with a commercial transaction at one or more merchant devices and can enable the reward device to determine a reward available to the user based on reward data associated with the current commercial transaction. (See Carter para 39 – customer information can be associated with the commercial transaction and one or more merchants to determine a reward available [identify reward value for said credit account customer using the transaction information [customer file] with one or more merchants [identified sub-merchant]; the user device may communicate location information or other information associated with a commercial transaction at one or more merchant devices)
In an aspect, the reward device can comprise rewards data for determining one or more rewards. (See Carter para 40 – identify reward value for credit account customer, see also paras 43-45) The reward data can comprise information related to a reward. (See Carter para 40) For example, the reward data can comprise one or more (e.g., a collection of) merchant identifiers. (See Carter para 40 – reward data includes merchant identifiers)
The reward device can comprise one or more (e.g., a collection of) merchant identifiers where the collection of merchant identifiers can comprise identifiers for business chains, individual locations of a chain, categories of merchants, terminals (e.g., transaction terminal of a specific merchant, identifying a sub-merchant) and/or the like that collectively form a merchant network. (See Carter para 40 – identifying a sub-merchant, wherein location [individual locations of a chain, identifying a transaction terminal of a specific merchant, identifying a sub-merchant] of a sub-merchant is part of the data)
Figure 8 further discloses a flowchart illustrating an example method where a user device can transmit to a rewards provider reward device, a provider of commercial based digital rewards and content for marketing promotions a notification of a pending commercial transaction at a merchant location (e.g., merchant device, retail store, business, gas pump, payment kiosk, etc.). (See Carter para 54 and Fig. 8) In an aspect, the notification can comprise information associated with a user (e.g., consumer), the commercial transaction, combinations thereof, and the like. (See Carter para 54) As an example, the notification can comprise consumer information, financial services information, description information, date information, time information and payment information associated with the commercial transaction and can additionally comprise location information, product information, merchant information, payment type information, combinations thereof and the like. (See Carter para 54)
Fig. 9 is a flowchart illustrating an example method 900. (See Carter para 61) In step 902, a rewards provider (e.g., reward device 102, a provider of commercial based digital rewards and content for marketing promotions, a provider of consumer loyalty rewards, etc.) can receive, from a computer device (e.g., user device 118), a notification of a pending commercial transaction at a merchant location (e.g., merchant device 124, retail store, business, gas pump, payment kiosk, etc.) (See Carter para 61 – notification of a pending commercial transaction at a merchant includes merchant location) In an aspect, the notification can comprise information associated with a user (e.g., a consumer) and/or commercial transaction. (See Carter para 61) As an example, the notification can comprise consumer information, financial services information, description information, data information, time information, and payment information associated with the commercial transaction and can additionally can comprise location information, product information, merchant information, payment type information, combinations thereof, and the like. (See Carter para 61 – notification includes merchant location information)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the instant invention to have modified the system, method and computer program product for utilizing loyalty and/or reward points as disclosed by Beer with the additional details of the contents of transaction authorization requests as taught by Carter in order to provide faster reward determinations associated with commercial transactions.
Regarding Claim 7, this claim recites the limitations of Claim 1 and as to those limitations is rejected for the same basis and reasons as disclosed above. Further, Beer in view of Carter discloses the following:
obtaining an item description from said transaction authorization request;
obtaining a cost from said transaction authorization request; and
automatically determining said reward value based on said item description, said cost, and said identified sub-merchant. (See Beer paras 19, 33, 48)
While Beer discloses the invention as claimed, it does not fully disclose the item or cost description from said transaction authorization request or the location data of a sub-merchant as claimed. Further, while Beer does disclose the distinction between merchants versus a merchant aggregator, thus disclosing the limitations as to a merchant versus a sub-merchant, Carter also directly recites a sub-merchant and also details location data of a sub-merchant and identifying reward expectations.
Carter discloses methods and systems for real-time calculation of rewards associated with a commercial transaction. (See Carter Abstract) At the time a commercial transaction occurs, a user can be made aware of payment information associated with the transaction, made aware of reward information associated with the transaction and complete the transaction according to the associated payment information and reward information. (See Carter paras 26-27)
The system can comprise a merchant device to process an exchange (e.g., commercial transaction) between the merchant and consumers where the merchant device can be configured to receive account identifiers, product identifiers, and/or the like to process an exchange. (See Carter para 32) The merchant device can request the intermediary device to authorize, process, complete and/or the like, the exchange. (See Carter para 32) In an aspect, the merchant can be in communication with a reward device. (See Carter para 33)
In an aspect, the merchant device can be associated with a merchant identifier, which can be any identifier, token, character, string or the like, for differentiating one merchant and/or merchant device from another merchant or merchant device. (See Carter para 34) In a further aspect, the merchant identifier can identify a merchant or merchant device as belonging to a particular class of merchants or merchant devices. (See Carter para 34) The merchant device can report a current commercial transaction (e.g., current product purchase activity). (See Carter paras 34-35)
The system can comprise an intermediary device that can comprise a device supporting a payment network. (See Carter para 36) For example, a payment network can comprise system or network used for the transfer of money via the use of cash-substitutes (e.g., credit card, bank card, reward card, etc.) and in an aspect, the network can comprise a payment network. (See Carter para 36) The intermediary device can be managed by a third-party intermediary. (See Carter para 36 – merchant aggregator) The intermediary device can be configured to process exchanges (e.g., commercial transactions) between merchants and users (e.g., consumers). (See Carter para 36)
For example, a credit card can be swiped through a card reading device (e.g., POS, merchant device) to provide payment for a commercial transaction. (See Carter para 36) When the credit card is swiped through the card reading device, the card reading device can transmit an authorization request to a third party (e.g., a remote transaction card service provider, intermediary device). (See Carter para 36 – transaction authorization request, sent to merchant aggregator) For example, the intermediary device can operate as a third party processor and be configured to determine whether a current exchange is authorized. (See Carter para 36 – merchant aggregator) An authorization request can comprise a request for payment authorization of the commercial transaction and the request for payment authorization can comprise financial services information, description information, date information, time information, and payment information. (See Carter para 36 – transaction authorization request has financial information, description information, date and time information and payment information [cost information)
The authorization unit 134 [part of the intermediary device as seen in Fig. 1] can be configured to receive and process the authorization requests. (See Carter para 36 and Fig. 1) The request can comprise a merchant identifier, a product identifier, an account identifier and the like. (See Carter para 36)
The system can also comprise a reward device that can be in communication with a network and can comprise rewards data for calculation of one or more rewards and can comprise information related to a reward. (See Carter para 37 – calculation of one or more rewards) Reward information (e.g., merchant provided rewards, provisional rewards, etc.) can be associated with a user account and stored in memory. (See Carter para 37) The reward device 102 can receive and store information (e.g., user preference for certain types of rewards or other preference) associated with the user device and can provide, notify, send notification information to the user device, notifying the user of the user device of one or more merchants offering rewards associated with a particular commercial transaction. (See Carter para 38 – stores information) The user device can communicate commercial transaction information, location information, and other information associated with the user to reward device 102. (See Carter para 39 – user device can communicate location information) User device can communicate information associated with a current commercial transaction to, such as payment information, to reward device 102 through network 126, enabling reward device 102 to associate user device 118 to a user account based on an account identifier 112. (See Carter para 39) The association between the user device and the account identifier can enable reward device to automatically determine rewards associated with the user device. (See Carter para 39) For example, a user device may be used to communicate location information or other information associated with a commercial transaction at one or more merchant devices and can enable the reward device to determine a reward available to the user based on reward data associated with the current commercial transaction. (See Carter para 39 – customer information can be associated with the commercial transaction and one or more merchants to determine a reward available [identify reward value for said credit account customer using the transaction information [customer file] with one or more merchants [identified sub-merchant]; the user device may communicate location information or other information associated with a commercial transaction at one or more merchant devices)
In an aspect, the reward device can comprise rewards data for determining one or more rewards. (See Carter para 40 – identify reward value for credit account customer, see also paras 43-45) The reward data can comprise information related to a reward. (See Carter para 40) For example, the reward data can comprise one or more (e.g., a collection of) merchant identifiers. (See Carter para 40 – reward data includes merchant identifiers)
The reward device can comprise one or more (e.g., a collection of) merchant identifiers where the collection of merchant identifiers can comprise identifiers for business chains, individual locations of a chain, categories of merchants, terminals (e.g., transaction terminal of a specific merchant, identifying a sub-merchant) and/or the like that collectively form a merchant network. (See Carter para 40 – identifying a sub-merchant, wherein location [individual locations of a chain, identifying a transaction terminal of a specific merchant, identifying a sub-merchant] of a sub-merchant is part of the data)
Figure 8 further discloses a flowchart illustrating an example method where a user device can transmit to a rewards provider reward device, a provider of commercial based digital rewards and content for marketing promotions a notification of a pending commercial transaction at a merchant location (e.g., merchant device, retail store, business, gas pump, payment kiosk, etc.). (See Carter para 54 and Fig. 8) In an aspect, the notification can comprise information associated with a user (e.g., consumer), the commercial transaction, combinations thereof, and the like. (See Carter para 54) As an example, the notification can comprise consumer information, financial services information, description information, date information, time information and payment information associated with the commercial transaction and can additionally comprise location information, product information, merchant information, payment type information, combinations thereof and the like. (See Carter para 54 – information also includes product information and description information [item description])
Fig. 9 is a flowchart illustrating an example method 900. (See Carter para 61) In step 902, a rewards provider (e.g., reward device 102, a provider of commercial based digital rewards and content for marketing promotions, a provider of consumer loyalty rewards, etc.) can receive, from a computer device (e.g., user device 118), a notification of a pending commercial transaction at a merchant location (e.g., merchant device 124, retail store, business, gas pump, payment kiosk, etc.) (See Carter para 61 – notification of a pending commercial transaction at a merchant includes merchant location) In an aspect, the notification can comprise information associated with a user (e.g., a consumer) and/or commercial transaction. (See Carter para 61) As an example, the notification can comprise consumer information, financial services information, description information, data information, time information, and payment information associated with the commercial transaction and can additionally can comprise location information, product information, merchant information, payment type information, combinations thereof, and the like. (See Carter para 61 – notification includes merchant location information)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the instant invention to have modified the system, method and computer program product for utilizing loyalty and/or reward points as disclosed by Beer with the additional details of the contents of transaction authorization requests as taught by Carter in order to provide faster reward determinations associated with commercial transactions.
Regarding Claims 8 and 20, these substantially similar claims recite the limitations of Claims 1 and 15 and as to those limitations is rejected for the same basis and reasons as disclosed above. Further, Beer in view of Carter discloses the following:
obtaining a date from said transaction authorization request;
obtaining an item description from said transaction authorization request;
obtaining a cost from said transaction authorization request; and
automatically determining said reward value based on said date, said item description, said cost, and said identified sub-merchant. (See Beer paras 19, 33, 48)
While Beer discloses the invention as claimed, it does not fully disclose the item, cost or date description from said transaction authorization request or the location data of a sub-merchant as claimed. Further, while Beer does disclose the distinction between merchants versus a merchant aggregator, thus disclosing the limitations as to a merchant versus a sub-merchant, Carter also directly recites a sub-merchant and also details location data of a sub-merchant and identifying reward expectations.
Carter discloses methods and systems for real-time calculation of rewards associated with a commercial transaction. (See Carter Abstract) At the time a commercial transaction occurs, a user can be made aware of payment information associated with the transaction, made aware of reward information associated with the transaction and complete the transaction according to the associated payment information and reward information. (See Carter paras 26-27)
The system can comprise a merchant device to process an exchange (e.g., commercial transaction) between the merchant and consumers where the merchant device can be configured to receive account identifiers, product identifiers, and/or the like to process an exchange. (See Carter para 32) The merchant device can request the intermediary device to authorize, process, complete and/or the like, the exchange. (See Carter para 32) In an aspect, the merchant can be in communication with a reward device. (See Carter para 33)
In an aspect, the merchant device can be associated with a merchant identifier, which can be any identifier, token, character, string or the like, for differentiating one merchant and/or merchant device from another merchant or merchant device. (See Carter para 34) In a further aspect, the merchant identifier can identify a merchant or merchant device as belonging to a particular class of merchants or merchant devices. (See Carter para 34) The merchant device can report a current commercial transaction (e.g., current product purchase activity). (See Carter paras 34-35)
The system can comprise an intermediary device that can comprise a device supporting a payment network. (See Carter para 36) For example, a payment network can comprise system or network used for the transfer of money via the use of cash-substitutes (e.g., credit card, bank card, reward card, etc.) and in an aspect, the network can comprise a payment network. (See Carter para 36) The intermediary device can be managed by a third-party intermediary. (See Carter para 36 – merchant aggregator) The intermediary device can be configured to process exchanges (e.g., commercial transactions) between merchants and users (e.g., consumers). (See Carter para 36)
For example, a credit card can be swiped through a card reading device (e.g., POS, merchant device) to provide payment for a commercial transaction. (See Carter para 36) When the credit card is swiped through the card reading device, the card reading device can transmit an authorization request to a third party (e.g., a remote transaction card service provider, intermediary device). (See Carter para 36 – transaction authorization request, sent to merchant aggregator) For example, the intermediary device can operate as a third party processor and be configured to determine whether a current exchange is authorized. (See Carter para 36 – merchant aggregator) An authorization request can comprise a request for payment authorization of the commercial transaction and the request for payment authorization can comprise financial services information, description information, date information, time information, and payment information. (See Carter para 36 – transaction authorization request has financial information, description information, date and time information and payment information [cost information and date information])
The authorization unit 134 [part of the intermediary device as seen in Fig. 1] can be configured to receive and process the authorization requests. (See Carter para 36 and Fig. 1) The request can comprise a merchant identifier, a product identifier, an account identifier and the like. (See Carter para 36)
The system can also comprise a reward device that can be in communication with a network and can comprise rewards data for calculation of one or more rewards and can comprise information related to a reward. (See Carter para 37 – calculation of one or more rewards) Reward information (e.g., merchant provided rewards, provisional rewards, etc.) can be associated with a user account and stored in memory. (See Carter para 37) The reward device 102 can receive and store information (e.g., user preference for certain types of rewards or other preference) associated with the user device and can provide, notify, send notification information to the user device, notifying the user of the user device of one or more merchants offering rewards associated with a particular commercial transaction. (See Carter para 38 – stores information) The user device can communicate commercial transaction information, location information, and other information associated with the user to reward device 102. (See Carter para 39 – user device can communicate location information) User device can communicate information associated with a current commercial transaction to, such as payment information, to reward device 102 through network 126, enabling reward device 102 to associate user device 118 to a user account based on an account identifier 112. (See Carter para 39) The association between the user device and the account identifier can enable reward device to automatically determine rewards associated with the user device. (See Carter para 39) For example, a user device may be used to communicate location information or other information associated with a commercial transaction at one or more merchant devices and can enable the reward device to determine a reward available to the user based on reward data associated with the current commercial transaction. (See Carter para 39 – customer information can be associated with the commercial transaction and one or more merchants to determine a reward available [identify reward value for said credit account customer using the transaction information [customer file] with one or more merchants [identified sub-merchant]; the user device may communicate location information or other information associated with a commercial transaction at one or more merchant devices)
In an aspect, the reward device can comprise rewards data for determining one or more rewards. (See Carter para 40 – identify reward value for credit account customer, see also paras 43-45) The reward data can comprise information related to a reward. (See Carter para 40) For example, the reward data can comprise one or more (e.g., a collection of) merchant identifiers. (See Carter para 40 – reward data includes merchant identifiers)
The reward device can comprise one or more (e.g., a collection of) merchant identifiers where the collection of merchant identifiers can comprise identifiers for business chains, individual locations of a chain, categories of merchants, terminals (e.g., transaction terminal of a specific merchant, identifying a sub-merchant) and/or the like that collectively form a merchant network. (See Carter para 40 – identifying a sub-merchant, wherein location [individual locations of a chain, identifying a transaction terminal of a specific merchant, identifying a sub-merchant] of a sub-merchant is part of the data)
Figure 8 further discloses a flowchart illustrating an example method where a user device can transmit to a rewards provider reward device, a provider of commercial based digital rewards and content for marketing promotions a notification of a pending commercial transaction at a merchant location (e.g., merchant device, retail store, business, gas pump, payment kiosk, etc.). (See Carter para 54 and Fig. 8) In an aspect, the notification can comprise information associated with a user (e.g., consumer), the commercial transaction, combinations thereof, and the like. (See Carter para 54) As an example, the notification can comprise consumer information, financial services information, description information, date information, time information and payment information associated with the commercial transaction and can additionally comprise location information, product information, merchant information, payment type information, combinations thereof and the like. (See Carter para 54 – information also includes product information and description information [item description])
Fig. 9 is a flowchart illustrating an example method 900. (See Carter para 61) In step 902, a rewards provider (e.g., reward device 102, a provider of commercial based digital rewards and content for marketing promotions, a provider of consumer loyalty rewards, etc.) can receive, from a computer device (e.g., user device 118), a notification of a pending commercial transaction at a merchant location (e.g., merchant device 124, retail store, business, gas pump, payment kiosk, etc.) (See Carter para 61 – notification of a pending commercial transaction at a merchant includes merchant location) In an aspect, the notification can comprise information associated with a user (e.g., a consumer) and/or commercial transaction. (See Carter para 61) As an example, the notification can comprise consumer information, financial services information, description information, data information, time information, and payment information associated with the commercial transaction and can additionally can comprise location information, product information, merchant information, payment type information, combinations thereof, and the like. (See Carter para 61 – notification includes merchant location information)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the instant invention to have modified the system, method and computer program product for utilizing loyalty and/or reward points as disclosed by Beer with the additional details of the contents of transaction authorization requests as taught by Carter in order to provide faster reward determinations associated with commercial transactions.
Regarding Claim 10, this claim recite the limitations of Claim 9 and as to those limitations is rejected for the same basis and reasons as disclosed above. Further, Beer in view of Carter discloses the following:
wherein said identifying said sub-merchant further comprises:
obtaining a sub-merchant identifier from said transaction authorization request; and (See Beer para 31 - The merchant aggregator and merchant process the payment similar to a traditional transaction; the membership rewards program host system may translate merchant data communicated to the membership rewards program host into a known merchant identifier. The merchant aggregator may not have access to the merchant identifier used for authorizing/submitting charges, so the reference used by the merchant aggregator is provided to the membership rewards program host system.)
searching, said database utilizing said sub-merchant identifier identifying said sub-merchant; and (See Beer para 31 - The merchant aggregator and merchant process the payment similar to a traditional transaction; the membership rewards program host system may translate merchant data communicated to the membership rewards program host into a known merchant identifier. The merchant aggregator may not have access to the merchant identifier used for authorizing/submitting charges, so the reference used by the merchant aggregator is provided to the membership rewards program host system. The membership rewards program host system may translate the merchant aggregator reference of the merchant to a known merchant identifier used by the transaction account processor, such as through referencing a database and/or use of a look-up table)
relating said sub-merchant identifier with said identified sub-merchant at said database. (See Beer paras 19, 31 – membership rewards program host systems records the PWP intent and translates the merchant name into a merchant identifier; membership program host system may translate the merchant aggregator reference of the merchant to a known merchant identifier used by the transaction account processor, such as through referencing a database and/or use of a lookup table)
While Beer discloses the invention as claimed, it does not fully disclose the transaction authorization request or the location data of a sub-merchant as claimed. Further, while Beer does disclose the distinction between merchants versus a merchant aggregator, thus disclosing the limitations as to a merchant versus a sub-merchant, Carter also directly recites a sub-merchant and also details location data of a sub-merchant and identifying reward expectations.
Carter discloses methods and systems for real-time calculation of rewards associated with a commercial transaction. (See Carter Abstract) At the time a commercial transaction occurs, a user can be made aware of payment information associated with the transaction, made aware of reward information associated with the transaction and complete the transaction according to the associated payment information and reward information. (See Carter paras 26-27)
The system can comprise a merchant device to process an exchange (e.g., commercial transaction) between the merchant and consumers where the merchant device can be configured to receive account identifiers, product identifiers, and/or the like to process an exchange. (See Carter para 32) The merchant device can request the intermediary device to authorize, process, complete and/or the like, the exchange. (See Carter para 32) In an aspect, the merchant can be in communication with a reward device. (See Carter para 33)
In an aspect, the merchant device can be associated with a merchant identifier, which can be any identifier, token, character, string or the like, for differentiating one merchant and/or merchant device from another merchant or merchant device. (See Carter para 34) In a further aspect, the merchant identifier can identify a merchant or merchant device as belonging to a particular class of merchants or merchant devices. (See Carter para 34) The merchant device can report a current commercial transaction (e.g., current product purchase activity). (See Carter paras 34-35)
The system can comprise an intermediary device that can comprise a device supporting a payment network. (See Carter para 36) For example, a payment network can comprise system or network used for the transfer of money via the use of cash-substitutes (e.g., credit card, bank card, reward card, etc.) and in an aspect, the network can comprise a payment network. (See Carter para 36) The intermediary device can be managed by a third-party intermediary. (See Carter para 36 – merchant aggregator) The intermediary device can be configured to process exchanges (e.g., commercial transactions) between merchants and users (e.g., consumers). (See Carter para 36)
For example, a credit card can be swiped through a card reading device (e.g., POS, merchant device) to provide payment for a commercial transaction. (See Carter para 36) When the credit card is swiped through the card reading device, the card reading device can transmit an authorization request to a third party (e.g., a remote transaction card service provider, intermediary device). (See Carter para 36 – transaction authorization request, sent to merchant aggregator) For example, the intermediary device can operate as a third party processor and be configured to determine whether a current exchange is authorized. (See Carter para 36 – merchant aggregator) An authorization request can comprise a request for payment authorization of the commercial transaction and the request for payment authorization can comprise financial services information, description information, date information, time information, and payment information. (See Carter para 36 – transaction authorization request has financial information, description information, date and time information and payment information)
The authorization unit 134 [part of the intermediary device as seen in Fig. 1] can be configured to receive and process the authorization requests. (See Carter para 36 and Fig. 1) The request can comprise a merchant identifier, a product identifier, an account identifier and the like. (See Carter para 36)
The system can also comprise a reward device that can be in communication with a network and can comprise rewards data for calculation of one or more rewards and can comprise information related to a reward. (See Carter para 37 – calculation of one or more rewards) Reward information (e.g., merchant provided rewards, provisional rewards, etc.) can be associated with a user account and stored in memory. (See Carter para 37) The reward device 102 can receive and store information (e.g., user preference for certain types of rewards or other preference) associated with the user device and can provide, notify, send notification information to the user device, notifying the user of the user device of one or more merchants offering rewards associated with a particular commercial transaction. (See Carter para 38 – stores information) The user device can communicate commercial transaction information, location information, and other information associated with the user to reward device 102. (See Carter para 39 – user device can communicate location information) User device can communicate information associated with a current commercial transaction to, such as payment information, to reward device 102 through network 126, enabling reward device 102 to associate user device 118 to a user account based on an account identifier 112. (See Carter para 39) The association between the user device and the account identifier can enable reward device to automatically determine rewards associated with the user device. (See Carter para 39) For example, a user device may be used to communicate location information or other information associated with a commercial transaction at one or more merchant devices and can enable the reward device to determine a reward available to the user based on reward data associated with the current commercial transaction. (See Carter para 39 – customer information can be associated with the commercial transaction and one or more merchants to determine a reward available [identify reward value for said credit account customer using the transaction information [customer file] with one or more merchants [identified sub-merchant]; the user device may communicate location information or other information associated with a commercial transaction at one or more merchant devices)
In an aspect, the reward device can comprise rewards data for determining one or more rewards. (See Carter para 40 – identify reward value for credit account customer, see also paras 43-45) The reward data can comprise information related to a reward. (See Carter para 40) For example, the reward data can comprise one or more (e.g., a collection of) merchant identifiers. (See Carter para 40 – reward data includes merchant identifiers)
The reward device can comprise one or more (e.g., a collection of) merchant identifiers where the collection of merchant identifiers can comprise identifiers for business chains, individual locations of a chain, categories of merchants, terminals (e.g., transaction terminal of a specific merchant, identifying a sub-merchant) and/or the like that collectively form a merchant network. (See Carter para 40 – identifying a sub-merchant, wherein location [individual locations of a chain, identifying a transaction terminal of a specific merchant, identifying a sub-merchant] of a sub-merchant is part of the data)
Figure 8 further discloses a flowchart illustrating an example method where a user device can transmit to a rewards provider reward device, a provider of commercial based digital rewards and content for marketing promotions a notification of a pending commercial transaction at a merchant location (e.g., merchant device, retail store, business, gas pump, payment kiosk, etc.). (See Carter para 54 and Fig. 8) In an aspect, the notification can comprise information associated with a user (e.g., consumer), the commercial transaction, combinations thereof, and the like. (See Carter para 54) As an example, the notification can comprise consumer information, financial services information, description information, date information, time information and payment information associated with the commercial transaction and can additionally comprise location information, product information, merchant information, payment type information, combinations thereof and the like. (See Carter para 54)
Fig. 9 is a flowchart illustrating an example method 900. (See Carter para 61) In step 902, a rewards provider (e.g., reward device 102, a provider of commercial based digital rewards and content for marketing promotions, a provider of consumer loyalty rewards, etc.) can receive, from a computer device (e.g., user device 118), a notification of a pending commercial transaction at a merchant location (e.g., merchant device 124, retail store, business, gas pump, payment kiosk, etc.) (See Carter para 61 – notification of a pending commercial transaction at a merchant includes merchant location) In an aspect, the notification can comprise information associated with a user (e.g., a consumer) and/or commercial transaction. (See Carter para 61) As an example, the notification can comprise consumer information, financial services information, description information, data information, time information, and payment information associated with the commercial transaction and can additionally can comprise location information, product information, merchant information, payment type information, combinations thereof, and the like. (See Carter para 61 – notification includes merchant location information)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the instant invention to have modified the system, method and computer program product for utilizing loyalty and/or reward points as disclosed by Beer with the additional details of the contents of transaction authorization requests as taught by Carter in order to provide faster reward determinations associated with commercial transactions.
Regarding Claims 11 and 16, these substantially similar claims recite the limitations of Claims 9 and 15 and as to those limitations are rejected for the same basis and reasons as disclosed above. Further, Beer in view of Carter discloses the following:
obtaining a merchant aggregator identifier from said transaction authorization request; (See Beer paras 19, 31-32, 48, 54, 59-62)
obtaining a sub-merchant identifier from said transaction authorization request; (See Beer para 31 - The merchant aggregator and merchant process the payment similar to a traditional transaction; the membership rewards program host system may translate merchant data communicated to the membership rewards program host into a known merchant identifier. The merchant aggregator may not have access to the merchant identifier used for authorizing/submitting charges, so the reference used by the merchant aggregator is provided to the membership rewards program host system.)
searching, said database utilizing said sub-merchant identifier in conjunction with said merchant aggregator, and identifying said sub-merchant. (See Beer para 31 - The merchant aggregator and merchant process the payment similar to a traditional transaction; the membership rewards program host system may translate merchant data communicated to the membership rewards program host into a known merchant identifier. The merchant aggregator may not have access to the merchant identifier used for authorizing/submitting charges, so the reference used by the merchant aggregator is provided to the membership rewards program host system. The membership rewards program host system may translate the merchant aggregator reference of the merchant to a known merchant identifier used by the transaction account processor, such as through referencing a database and/or use of a look-up table)
relating said merchant aggregator identifier and said sub-merchant identifier with said identified sub-merchant at said database. (See Beer paras 19, 31 – membership rewards program host systems records the PWP intent and translates the merchant name into a merchant identifier; membership program host system may translate the merchant aggregator reference of the merchant to a known merchant identifier used by the transaction account processor, such as through referencing a database and/or use of a lookup table)
While Beer discloses the invention as claimed, it does not fully disclose the transaction authorization request or the location data of a sub-merchant as claimed. Further, while Beer does disclose the distinction between merchants versus a merchant aggregator, thus disclosing the limitations as to a merchant versus a sub-merchant, Carter also directly recites a sub-merchant and also details location data of a sub-merchant and identifying reward expectations.
Carter discloses methods and systems for real-time calculation of rewards associated with a commercial transaction. (See Carter Abstract) At the time a commercial transaction occurs, a user can be made aware of payment information associated with the transaction, made aware of reward information associated with the transaction and complete the transaction according to the associated payment information and reward information. (See Carter paras 26-27)
The system can comprise a merchant device to process an exchange (e.g., commercial transaction) between the merchant and consumers where the merchant device can be configured to receive account identifiers, product identifiers, and/or the like to process an exchange. (See Carter para 32) The merchant device can request the intermediary device to authorize, process, complete and/or the like, the exchange. (See Carter para 32) In an aspect, the merchant can be in communication with a reward device. (See Carter para 33)
In an aspect, the merchant device can be associated with a merchant identifier, which can be any identifier, token, character, string or the like, for differentiating one merchant and/or merchant device from another merchant or merchant device. (See Carter para 34) In a further aspect, the merchant identifier can identify a merchant or merchant device as belonging to a particular class of merchants or merchant devices. (See Carter para 34) The merchant device can report a current commercial transaction (e.g., current product purchase activity). (See Carter paras 34-35)
The system can comprise an intermediary device that can comprise a device supporting a payment network. (See Carter para 36) For example, a payment network can comprise system or network used for the transfer of money via the use of cash-substitutes (e.g., credit card, bank card, reward card, etc.) and in an aspect, the network can comprise a payment network. (See Carter para 36) The intermediary device can be managed by a third-party intermediary. (See Carter para 36 – merchant aggregator) The intermediary device can be configured to process exchanges (e.g., commercial transactions) between merchants and users (e.g., consumers). (See Carter para 36)
For example, a credit card can be swiped through a card reading device (e.g., POS, merchant device) to provide payment for a commercial transaction. (See Carter para 36) When the credit card is swiped through the card reading device, the card reading device can transmit an authorization request to a third party (e.g., a remote transaction card service provider, intermediary device). (See Carter para 36 – transaction authorization request, sent to merchant aggregator) For example, the intermediary device can operate as a third party processor and be configured to determine whether a current exchange is authorized. (See Carter para 36 – merchant aggregator) An authorization request can comprise a request for payment authorization of the commercial transaction and the request for payment authorization can comprise financial services information, description information, date information, time information, and payment information. (See Carter para 36 – transaction authorization request has financial information, description information, date and time information and payment information)
The authorization unit 134 [part of the intermediary device as seen in Fig. 1] can be configured to receive and process the authorization requests. (See Carter para 36 and Fig. 1) The request can comprise a merchant identifier, a product identifier, an account identifier and the like. (See Carter para 36)
The system can also comprise a reward device that can be in communication with a network and can comprise rewards data for calculation of one or more rewards and can comprise information related to a reward. (See Carter para 37 – calculation of one or more rewards) Reward information (e.g., merchant provided rewards, provisional rewards, etc.) can be associated with a user account and stored in memory. (See Carter para 37) The reward device 102 can receive and store information (e.g., user preference for certain types of rewards or other preference) associated with the user device and can provide, notify, send notification information to the user device, notifying the user of the user device of one or more merchants offering rewards associated with a particular commercial transaction. (See Carter para 38 – stores information) The user device can communicate commercial transaction information, location information, and other information associated with the user to reward device 102. (See Carter para 39 – user device can communicate location information) User device can communicate information associated with a current commercial transaction to, such as payment information, to reward device 102 through network 126, enabling reward device 102 to associate user device 118 to a user account based on an account identifier 112. (See Carter para 39) The association between the user device and the account identifier can enable reward device to automatically determine rewards associated with the user device. (See Carter para 39) For example, a user device may be used to communicate location information or other information associated with a commercial transaction at one or more merchant devices and can enable the reward device to determine a reward available to the user based on reward data associated with the current commercial transaction. (See Carter para 39 – customer information can be associated with the commercial transaction and one or more merchants to determine a reward available [identify reward value for said credit account customer using the transaction information [customer file] with one or more merchants [identified sub-merchant]; the user device may communicate location information or other information associated with a commercial transaction at one or more merchant devices)
In an aspect, the reward device can comprise rewards data for determining one or more rewards. (See Carter para 40 – identify reward value for credit account customer, see also paras 43-45) The reward data can comprise information related to a reward. (See Carter para 40) For example, the reward data can comprise one or more (e.g., a collection of) merchant identifiers. (See Carter para 40 – reward data includes merchant identifiers)
The reward device can comprise one or more (e.g., a collection of) merchant identifiers where the collection of merchant identifiers can comprise identifiers for business chains, individual locations of a chain, categories of merchants, terminals (e.g., transaction terminal of a specific merchant, identifying a sub-merchant) and/or the like that collectively form a merchant network. (See Carter para 40 – identifying a sub-merchant, wherein location [individual locations of a chain, identifying a transaction terminal of a specific merchant, identifying a sub-merchant] of a sub-merchant is part of the data)
Figure 8 further discloses a flowchart illustrating an example method where a user device can transmit to a rewards provider reward device, a provider of commercial based digital rewards and content for marketing promotions a notification of a pending commercial transaction at a merchant location (e.g., merchant device, retail store, business, gas pump, payment kiosk, etc.). (See Carter para 54 and Fig. 8) In an aspect, the notification can comprise information associated with a user (e.g., consumer), the commercial transaction, combinations thereof, and the like. (See Carter para 54) As an example, the notification can comprise consumer information, financial services information, description information, date information, time information and payment information associated with the commercial transaction and can additionally comprise location information, product information, merchant information, payment type information, combinations thereof and the like. (See Carter para 54)
Fig. 9 is a flowchart illustrating an example method 900. (See Carter para 61) In step 902, a rewards provider (e.g., reward device 102, a provider of commercial based digital rewards and content for marketing promotions, a provider of consumer loyalty rewards, etc.) can receive, from a computer device (e.g., user device 118), a notification of a pending commercial transaction at a merchant location (e.g., merchant device 124, retail store, business, gas pump, payment kiosk, etc.) (See Carter para 61 – notification of a pending commercial transaction at a merchant includes merchant location) In an aspect, the notification can comprise information associated with a user (e.g., a consumer) and/or commercial transaction. (See Carter para 61) As an example, the notification can comprise consumer information, financial services information, description information, data information, time information, and payment information associated with the commercial transaction and can additionally can comprise location information, product information, merchant information, payment type information, combinations thereof, and the like. (See Carter para 61 – notification includes merchant location information)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the instant invention to have modified the system, method and computer program product for utilizing loyalty and/or reward points as disclosed by Beer with the additional details of the contents of transaction authorization requests as taught by Carter in order to provide faster reward determinations associated with commercial transactions.
Response to Arguments
Applicant's arguments filed August 18, 2026 have been fully considered as further detailed below.
As to the Claim Objections:
Applicant has amended Claim 9 to address Examiner’s raised objection. (See Applicant’s Arguments dated 08/18/2026, page 10) The previous objection to claim 9 has been mooted and withdrawn accordingly.
As to the 101 Rejections:
Examiner has updated the rejection to account for the claims as amended, as seen in the rejection in chief.
Applicant traverses the rejection. (Id. at page 10) Under step 1, Applicant also amended the claims that had separate statutory issues to resolve those issues and is thanked for those corrections. (Id.)
Applicant then asserts that the Office has not provided any factual basis that the identification of a sub-merchant in a transaction authorization request falls under any enumerated abstract concept. (Id. at page 11)
This is incorrect. The rejection clearly set for the abstract idea of sub-merchant identification in a transaction authorization request as part of processing financial transactions and provided which limitations were part of the abstract idea and how the claims reflected certain methods of organizing human activity.
Applicant then argues that while the Office Action has demonstrated an abstract element, the argument fails when expanded to include identification of a sub-merchant, which Applicant asserts is an additional element. (Id. at pages 12-16)
The identification of the sub-merchant is data that is part of the transaction authorization request. This is still transaction authorization request data.
Applicant also refers to paragraph 1 of their specification and emphasizes not being able to clearly identify transactions at a merchant level when made through merchant aggregators and the actual merchant or sub-merchant providing the transacted for goods is not usually identified by the merchant aggregator. (Id. at page 12) This is an articulation of the problem, not the contours of the solution.
Applicant argues that the claim includes additional elements resulting in an inventive concept which amounts to significantly more and refers to case law regarding determining significantly more. (Id. at pages 12-14)
Applicant then makes the argument that the term “merchant aggregator” has been misunderstood and argues that the merchant aggregator refers to an aggregation of merchants operating under the umbrella of a single merchant on the merchant side of the transaction. (Id. at page 14) Applicant continues, arguing that a second transaction then occurs between the merchant aggregator and the sub-merchant. (Id. at pages 14-15) This argued for second transaction does not occur in the claims. The claims recite a merchant aggregator on the merchant side of the transaction receiving payment from a customer.
Applicant asserts that the additional element is related to the identifying of the sub-merchant and argue that the additional elements do not change the fundamental or abstract concept of processing financial transactions as the financial transactions are processed regardless of the identity of the sub-merchant. (Id. at page 15) The argued for additional element is data and as noted in the discussion of certain methods of organizing human activity, the steps involve transaction processing steps to identify relationships or interactions between merchants and sub-merchants; following rules; determining rewards activities.
Applicant argues that any aspects of the claims related to the identification of the sub-merchant must be “additional” and not part of the abstract concept and argues that “automatically scraping the transaction authorization request for data identifying a sub-merchant and a location of said sub-merchant; identifying said sub-merchant; storing said identified sub-merchant and said data identifying said sub-merchant at a database; providing a transaction authorization approval to said merchant aggregator; determining a transaction related to said transaction authorization approval is completed; accessing a customer file for said credit account customer; utilizing, after said transaction is completed, said customer file in conjunction with said identified sub-merchant and information from said completed transaction to automatically determine a reward value for said credit account customer.” (Id. at pages 15-16)
Applicant refers to paragraph 20 of their specification and argue that the embodiments provide a novel approach for automatic SMID ingestion that automatically identifies a sub-merchant that provided the transacted for goods in a merchant aggregator transaction and utilizes network relationships, communications and interactivity to identify and provide a proffered reward to the appropriate customers. (Id. at page 16)
Applicant argues that the additional elements provide an improvement to technology and therefore amount to significantly more than a judicial exception under Step 2B and concludes that the claims are subject matter patent eligible. (Id. at pages 16-17) Notably, the alleged improvement to technology is not disclosed in the specification as anything more than a variety of computer systems being able to implement directions. (See Applicant Spec paras 53-54, 59, 61-62)
Examiner disagrees. The elements that Applicant is attempting to frame as additional elements are data gathering steps, from the transaction authorization request, scanning or extracting data, retrieval of stored data and storing data. These are not additional elements - these are various types of data being retrieved and utilized. There is no improvement of the functioning of a computer disclosed in the specification, rather it appears that the invention is using a computer as a tool.
In particular, Examiner notes that Applicant’s specification only mentions “automatically scrapes the transaction authorization request…” once in their specification. (See Applicant Specification para 43) There is no particular mechanism by which the scraping is occurring in the specification. There is no clear connection to any particular hardware or software construct that is utilized to scrape data either in the specification or the claims. Under a broadest reasonable interpretation, scraping could refer to screen scraping, the use of spreadsheet software like Excel or Google Sheets, manual data scraping, etc.
Applicant’s arguments are not persuasive. The 101 Rejection is maintained.
As to the 103 Rejections:
Applicant asserts that they are traversing the rejection. (See Applicant Arguments dated 08/18/2026, page 18) Applicant also notes that the 103 rejection discloses that Beer does not fully disclose the transaction authorization request or the location data of a sub-merchant as claimed. (Id. at page 19)
Applicant argues that the term “merchant aggregator” as disclosed by Beer is not analogous to the term “merchant aggregator” in the claims and as defined by the Applicant’s specification, pointing to paragraphs 24-26. (Id. at page 19) Applicant emphasizes that the merchant aggregator is an entity that might contract with a number of different sub-merchants and that a credit account provider identifies that sub-merchant used by the merchant aggregator. (Id.)
Applicant argues that in Beer, the merchant aggregator is analogous to a third-party digital wallet. (Id. at pages 19-20) Applicant concludes that the merchant aggregator of Beer refers to an aggregation of payment information under the umbrella of a digital wallet at the payment side of a transaction while the Applicant’s merchant aggregator refers to an aggregation of merchants operating under the umbrella of a single merchant on the merchant side of the transaction. (Id. at page 20)
In response to Applicant’s argument, Examiner additionally notes that Beer discloses that an “entity” may include any individual, consumer, customer, group, business, organization, government entity, transaction account issuer or processor (e.g., credit, charge, etc.), merchant, consortium of merchants, account holder, charitable organization, software, hardware and/or any other type of entity. (See Berr para 54) Beer further discloses that as used in their disclosure, phrases or terms similar to financial institution or transaction account issuer may include an entity that offers transaction account services. (See Beer para 59) The financial institution may represent any type of bank, lender or other type of account issuing institution such as credit card companies, card sponsoring companies, or third party issuers under contract with financial institutions. (See Beer para 59) Further, Beer discloses that business or merchant can mean any person, entity, distributor system, software and/or hardware that are a provider, broker and/or any other entity in the distribution chain of goods or services. (See Beer para 60) The term payment processor may include a company (e.g., a third party) appointed (e.g., by a merchant) to handle transactions. (See Beer para 62) A payment processor may include an issuer, acquirer, authorizer, and/or any other system or entity involved in the transaction process and can be front or back end where front end payment processors have connections to various transaction accounts and supply authorization and settlement services to the merchant banks’ merchants and back end payment processors accept settlements from front end payment processors. (See Beer para 62)
As such, the disclosure of Beer discloses the merchant aggregator.
Applicant concludes that Beer fails to teach or render obvious the claimed elements of receiving from a merchant aggregator, via a network, an electronic data transmission comprising a transaction authorization request for a credit account customer, automatically scraping the transaction authorization request for data identifying a sub-merchant and a location of said sub-merchant. (Id. at pages 20-21) Applicant continues, alleging that they do not understand how Carter overcomes the shortcomings of Beer and alleges that Carter has nothing to do with scraping a transaction authorization request, identifying a sub-merchant and a location of a sub-merchant and contends that the claims are allowable over Beer and Carter. (Id. at pages 21-23)
Applicant argues that scraping the transaction authorization request for data identifying a sub-merchant and a location of said sub-merchant is not taught by either Beer or Carter or in combination. (Id. at pages 20-22)
Applicant refers to a small portion of the rejection and concludes that there is no teaching that the location information provided by the user’s device is a location of a sub-merchant. (Id. at page 22)
Examiner disagrees. As an initial matter, Applicant’s specification only notes the term “scrapes” in one instance, at paragraph 43. The disclosure indicates at in one embodiment “…automatically scrapes the transaction authorization request 201 for a sub-merchant n identifier and/or information from the transaction authorization request 201 in conjunction with (or in place of) sub-merchant ID n to perform the identification of the sub-merchant n.” (See Applicant Spec para 43)
There is no additional context as to how the scraping is occurring or any further disclosure. As such, the term is being construed under a broadest reasonable interpretation, which in this case is automatic extraction of data from the transaction authorization request by any means. In combination, Beer and Carter disclose data being pulled from the transaction authorization request.
As disclosed in the rejection in chief, Examiner pointed not only to paragraph 39, but also to paragraph 40, which more fully detailed the disclosure of Carter as to this aspect. When viewed together and not in a piecemeal manner referring to one sentence of the disclosure, the disclosed paragraphs of Beer in view of Carter meet the limitations claimed. Carter discloses the following:
“User device 118 can communicate commercial transaction information, location information, and other information associated with the user to reward device 102. For example, user device 118 can communicate information associated with a current commercial transaction to, such as payment information, to reward device 102 through network 126, enabling reward device 102 to associate user device 111 to a user account based on an account identifier 112. Reward device 102 can determine whether the user device 118 is associated with a user account by relating the device identifier 108 to the account identifier 112. The association between the user device 118 and the account identifier 112 can enable reward device 102 to automatically determine rewards associated with the user device 118. For example, a user device may be used to communicate location information or other information associated with a commercial transaction at one or more merchant devices. The information can enable the reward device 102 to determine a reward available to the user based on reward data associated with the current commercial transaction.” (See Carter para 39- emphasis added)
“In an aspect the reward device 102 can comprise rewards data 104 for determining one or more rewards. The reward data can comprise information related to a reward. For example, the reward data 104 can comprise one or more (e.g., a collection of) merchant identifiers 128. A merchant can comprise any entity offering a product and/or service for purchase. The collection of merchant identifiers 128 can comprise identifiers for business clients, individual locations of a chain, categories of merchants (e.g., health, food, office supplier, fuel, etc.), terminals (e.g., transaction terminal of a specific merchant, identifying a sub-merchant) and/or the like that collectively form a merchant network. The merchant identifier 124 can identify merchants that are associated with pre-established rewards, reward programs, deals and/or combinations thereof. The merchant identifier 124 can identify merchants that are associated with the merchant network.” (See Carter para 40 – emphasis added)
While the initial communication of location information, when viewed in isolation, could refer to the user’s location, the user device is also additionally communicating the commercial transaction information and other information associated with the user to the reward device. Additionally, as cited to and disclosed by the rejection, the commercial transaction information, location information, and other information includes payment information and is all sent to the reward device through the network enabling the reward device to associated user device to a user account based on an account identifier. This association can enable automatic determination of rewards associated with the user device.
In particular, the user device may be used to communicate location information or other information associated with a commercial transaction at one or more merchant devices. Thus, the location information is not limited to the location of the user device at the time of transaction as argued by Applicant, rather the location information or other information is associated with a commercial transaction at one or more merchant devices, certainly indicating that this location is also related to the merchant device. However, Carter continues and notes that the reward data comprises information related to a reward and can comprise one or more (e.g., a collection of) merchant identifiers. Here again, this implies a sub-merchant may be involved, but does not directly state it.
Again, Carter’s disclosure continues in paragraph 40 where Carter directly discloses that the collection of merchant identifiers can comprise identifiers for business chains, individual locations of a chain, categories of merchants (e.g., health, food, office supplier, fuel, etc.), terminals (e.g., transaction terminal of a specific merchant, identifying a sub-merchant) and/or the like that collectively form a merchant network. (See Carter para 40). Thus, Carter directly discloses identification of a sub-merchant and the individual locations and devices associated with the merchant, thus meeting the claim limitations.
When considered in combination as disclosed, the disclosure of Beer in view of Carter discloses the invention as claimed. Applicant’s arguments to the contrary are not persuasive. The 103 rejection is maintained and has been updated to account for amendments and arguments made.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMBREEN A. ALLADIN whose telephone number is (571)270-3533. The examiner can normally be reached Monday - Friday 9-5.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Abhishek Vyas can be reached at 571-270-1836. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/AMBREEN A. ALLADIN/Primary Examiner, Art Unit 3691 September 22, 2026
Prosecution Insights