DETAILED ACTION
This communication is a Final Office Action rejection on the merits. Claims 1-6, 8-9, 11-12, 17-24, and 26-27 are currently pending and have been addressed below.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant's arguments filed on 01/22/2026 (related to the 103 Rejection) have been fully considered but are moot in view of new grounds of rejection. Applicant's amendments necessitated the new ground(s) of rejection presented in this Office action. Rejection based on a newly cited reference(s) follows.
Applicant's arguments filed on 01/22/2026 (related to the 101 Rejection) have been fully considered but they are not persuasive.
Applicant states, on pages 8-15, that the limitations of claim do not fall into any of these categories as they instead relate to user authentication and ingesting data from multiple sources using an application programming interface (API).
Also, the claimed method of user authentication (matching the unique code in the hyperlink to the temporary unique code) allows a user to "instantaneously authenticate her account" and when the codes match, users may be "instantaneously authenticated into [their] account and presented with a unique message and digital experience inside a mobile web page." Specification, Paragraph [0073]. Applicant therefore asserts that, under factor I described above, a person of ordinary skill in the art would appreciate the improvement of the above claim limitations; namely, that the claimed system enables the consumer to easily view the personalized offer through a hyperlink with a built-in authentication mechanism which only requires the consumer to click the hyperlink and does not require the consumer to enter a password, a verification code, and the like.
Further, regarding the API mentioned in the instant claim limitations, paragraph [0061] of the specification says "[t]he Open Commerce product suite includes the Open Commerce API (2104), a programming interface that provides the capability for ingesting Wallet Capacity data from external sources." Applicant therefore asserts that, under factor 1 described above, a person of ordinary skill in the art would appreciate the improvement of the above claim limitations; namely, that the usage of the API allows for the automated ingestion of data from multiple different sources where all of the disparate data received through the API may be saved together to a database. This allows for users to easily ingest data from multiple different sources and centrally store it.
Examiner respectfully disagrees with Applicant. Claim 1 is considered to be an abstract idea because it’s directed to “certain methods of organizing human activity” which include “commercial or legal interactions.” In this case, the claim limitations given its broadest reasonable interpretation in light of the specification are directed to a method for generating an offer based on the consumer member profile, which is considered an advertisement activity (see MPEP 2106.04(a)(2)). If a claim limitation, under its broadest reasonable interpretation, covers commercial or legal interactions, then it falls within the “certain methods of organizing human activity” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
The main operations/functions of the additional elements are merely used to: collect data (e.g., transactional data from different merchants), analyze the data (e.g., create a consumer profile with the transactional data), and display certain results of the collection and analysis (e.g., generate and display an offer based on the consumer member profile and the subsequent transaction). Those are functions that the courts have described as merely indicating a field of use or technological environment in which to apply a judicial exception (see MPEP 2106.05(h)) at Step 2A Prong 2 and Step 2B. Also, the additional element of a user interface is merely used to receive information about the consumer’s wallet capacity for a wallet or set of wallets (see Figure 7 & Paragraphs 0057 & 0059, using a survey to gather consumer’s wallet capacity). In this case, the application programming interface (API) and the user interface are considered “field of use” MPEP 2106.05h at Step 2A, Prong 2, since they’re just used to receive inputs for a marketing analysis (e.g., a first wallet data element for the at least one good or service, a second wallet data element, and a third wallet data element), but the API and the user interface are not improved. At Step 2B, the API and the user interface are considered a conventional computer function of “receiving and transmitting over a network” (see MPEP 2106.05d). Further, at Step 2B, the step of “including an offer for at least one good or service related to the subsequent transaction” is considered a well-understood, routing, and conventional function since it’s just “performing repetitive calculations” (MPEP 2106.05(d)).
Examiner notes that the last step of claim 1 is merely used to provide new offers based on updated consumer profile transactional data, wherein the previous offers and transactional data are linked to a specific consumer using authentication techniques. The specification states that the authentication technique is called a magic link, which is merely a link used to authenticate the user and access the account (see Paragraph 0073 & MPEP 2106.07(a)(III), a commercially available product). Also, the published applications demonstrate that the additional element is widely prevalent or in common use in the relevant field (see MPEP 2106.07(a)(III), The nature of the publication and the description of the additional elements in the publication would need to demonstrate that the additional elements are widely prevalent or in common use in the relevant field; see Pages 435-437 of Matiushin, In this paper, we consider passwordless authentication methods. Systems based on such methods have a number of advantages - ease of use, protection against many common types of attacks, and the lack of need to create a large number of passwords. Passwordless authentication technologies are increasingly widespread, and are already in use by a number of large companies -Google, Medium, etc. In particular, the magic link technology is considered; see Page 1261 of Kumar, In terms of passwordless authentication systems, biometrics and magic links are the most prominent and effective techniques). Therefore, the step of “authenticating the consumer using magic link technology” is a well-known technique in the art (MPEP 2106.05(d)).
Claim 1 fails to recite any improvements to another technology or technical field, improvements to the functioning of the computer itself, use of a particular machine, effecting a transformation or reduction of a particular article to a different state or thing, adding unconventional steps that confine the claim to a particular useful application, and/or meaningful limitations beyond generally linking the use of an abstract idea to a particular environment. See 84 Fed. Reg. 55. Viewed individually or as a whole, these additional claim elements do not provide meaningful limitations to transform the abstract idea into a patent eligible application of the abstract idea such that the claim amounts to significantly more than the abstract idea itself. The claim is not patent eligible.
Independent claims 8 and 17 recite similar features and therefore are rejected for the same reasons as independent claim 1. Claims 2-6, 9, 11-12, 18-24, and 26-27 are rejected for having the same deficiencies as those set forth with respect to the claims that they depend from, independent claims 1, 8, or 17.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-6, 8-9, 11-12, 17-24, and 26-27 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., an abstract idea) without reciting significantly more.
Independent Claim 1
Step One - First, pursuant to step 1 in the January 2019 Revised Patent Subject Matter Eligibility Guidance (“2019 PEG”) on 84 Fed. Reg. 53, claim 1 is directed to a method which is a statutory category.
Step 2A, Prong One - Claim 1 recites: A method associated with a wallet steering program, the method comprising: receiving, during a transaction at a first merchant, a consumer identifier associated with the consumer; in response to receiving the consumer identifier during the transaction, automatically creating, in real-time, a consumer member profile for the consumer identifier; storing at least one transaction data element associated with the transaction in the consumer member profile; causing to be displayed, a wallet survey for at least one good or service; ingesting wallet data, wherein ingesting the wallet data comprises: receiving, via the wallet survey, a user input indicating at least a first wallet data element for the at least one good or service; receiving, from a financial services company, at least a second wallet data element; and receiving, from a third party data aggregator, at least a third wallet data element; saving the at least a first data element, the at least a second data element, and the at least a third data element to a member profile; storing the at least one wallet data element in the consumer member profile; generating at least one offer based on the consumer member profile, wherein the at least one offer is generated at least in part on the at least one wallet data element; in response to receiving, during a subsequent transaction, the consumer identifier at a second merchant, automatically transmitting, to a user associated with the consumer identifier, a hyperlink containing a unique code; in response to receiving a user input selecting the hyperlink, comparing the unique code contained in the hyperlink with a temporary unique code associated with the consumer identifier; and in response to the unique code contained in the hyperlink matching the temporary unique code with the consumer identifier, authenticating the consumer and causing to be displayed at least one first communication to the consumer, the at least one communication including an offer for at least one good or service related to the subsequent transaction. These claim elements are considered to be abstract ideas because they are directed to certain methods of organizing human activity which include commercial or legal interactions. In this case, generating an offer based on the consumer member profile is considered an advertisement activity. If a claim limitation, under its broadest reasonable interpretation, covers commercial or legal interactions, then it falls within the “certain methods of organizing human activity” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Step 2A Prong 2 - The judicial exception is not integrated into a practical application. Claim 1 includes additional elements: a processor; a memory; at a first point-of-sale device at a first merchant; a consumer member profile database; a user interface of a computer device; an application programming interface (API); at a second point-of-sale device at a second merchant; and a user computing device.
The computer/processor is merely used to execute instructions and acquire consumer product and services purchasing behavior across diverse operating platforms (Paragraphs 0006 & 0049). The memory is merely used to store instructions (Paragraph 0050). The first point-of-sale device at a first merchant is merely used to receive the final purchase/transaction data from (312) and the line-item purchase details of the purchase/transaction (Paragraph 0057). The consumer member profile database is merely used to store tables which include member profile wallet-related data such as transactions associated with the consumer identifier (Paragraphs 0058 & 0061). The user interface is merely used to learn about the consumer’s wallet capacity for a wallet or set of wallets (see Figure 7 & Paragraphs 0057 & 0059). The API is merely a programming interface that provides the capability for ingesting Wallet Capacity data from external sources (Paragraph 0061). The second point-of-sale device at a second merchant is merely used to receive a consumer identifier (Paragraph 0073, such as a phone number). The computing device is merely used to receive a hyperlink containing a unique code and receive a plurality of types of digital content (Paragraph 0038 & 0073). Merely stating that the step is performed by a computer component results in “apply it” on a computer (MPEP 2106.05f). These elements of “computer/processor,” “memory,” “first point-of-sale device,” “user interface,” “API,” “second point-of-sale device,” “and computing device” are recited at a high level of generality such that it amounts no more than mere instructions to apply the exception using a generic computer element. Also, the API and computing device are considered “field of use” since they’re just used to receive information (e.g., wallet data from multiple sources, offers, and an authentication hyperlink), but the technology is not improved (MPEP 2106.05h). Accordingly, alone and in combination, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. Therefore, the claims are directed to an abstract idea.
Step 2B - The claim does not include additional elements that are sufficient to amount significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the claims describe how to generally “apply” the concept of generating at least one offer based on the consumer member profile. The specification shows that the computer/processor is merely used to execute instructions and acquire consumer product and services purchasing behavior across diverse operating platforms (Paragraphs 0006 & 0049). The memory is merely used to store instructions (Paragraph 0050). The first point-of-sale device at a first merchant is merely used to receive the final purchase/transaction data from (312) and the line-item purchase details of the purchase/transaction (Paragraph 0057). The consumer member profile is merely used to store tables which include member profile wallet-related data such as transactions associated with the consumer identifier (Paragraphs 0058 & 0061). The user interface is merely used to learn about the consumer’s wallet capacity for a wallet or set of wallets (see Figure 7 & Paragraphs 0057 & 0059). The API is merely a programming interface that provides the capability for ingesting Wallet Capacity data from external sources (Paragraph 0061). The second point-of-sale device at a second merchant is merely used to receive a consumer identifier (Paragraph 0073, such as a phone number). The computing device is merely used to receive a hyperlink containing a unique code and receive a plurality of types of digital content (Paragraph 0038 & 0073). Also, the API and computing device is considered a conventional computer function of “receiving and transmitting over a network” (MPEP 2106.05d). The step of “including an offer for at least one good or service related to the subsequent transaction” is considered a well-understood, routing, and conventional function since it’s just “performing repetitive calculations” (MPEP 2106.05(d)). In this case, Examiner notes that the claim is merely providing new offers based on updated consumer profile transactional data, wherein the new offer and/or previously stored offer is linked to a specific consumer using authentication techniques. The step of “authenticating the consumer” is considered a well-known technique in the art (see Paragraph 0073 of Applicant’s specification, an authentication technique known as magic link; see Pages 435-437 of Matiushin, In this paper, we consider passwordless authentication methods. Systems based on such methods have a number of advantages - ease of use, protection against many common types of attacks, and the lack of need to create a large number of passwords. Passwordless authentication technologies are increasingly widespread, and are already in use by a number of large companies -Google, Medium, etc. In particular, the magic link technology is considered; see Page 1261 of Kumar, In terms of passwordless authentication systems, biometrics and magic links are the most prominent and effective techniques). Thus, nothing in the claim adds significantly more to an abstract idea. The claim is not patent eligible.
Independent claim 8 is directed to a method at step 1, which is a statutory category. Claim 8 recites similar limitations as claim 1 and is rejected for the same reasons at step 2a, prong one; step 2a, prong 2; and step 2b. Claim 8 further recites “digital wallet” – which is treated as just an explicit “computer” for storing information and is treated under MPEP 2106.05f in the same manner as claim 1. Accordingly, these limitations are viewed as “apply it on a computer” at step 2a, prong 2 and step 2b. Thus, nothing in the claim adds significantly more to the abstract idea. The claim is not patent eligible.
Independent claim 17 is directed to a method at step 1, which is a statutory category. Claim 17 recites similar limitations as claim 1 and claim 8 and is rejected for the same reasons at step 2a, prong one; step 2a, prong 2; and step 2b. The claim is not patent eligible.
Dependent claims 2-6 are not directed to any additional claim elements. Rather, these claims offer further descriptive limitations of elements found in the independent claims and addressed above - such as by: storing at least one transaction data element associated with the subsequent transaction; providing a communication including an offer in response to receiving the updated consumer data; wherein the request for the consumer comprises authenticating the consumer member profile, downloading an application, inputting additional personal information, or responding to the wallet survey; wherein the additional data is associated with at least one of a location of the transaction, at least one of a date or time associated with the transaction, a quantity associated with a good service purchased in the transaction, or a cost associated with a good or service purchased in the transaction. These processes are similar to the abstract idea noted in the independent claim because they further the limitations of the independent claim which are directed to certain methods of organizing human activity which include commercial or legal interactions. In addition, no additional elements are integrated into the abstract idea. Therefore, the claims still recite an abstract idea that can be grouped into certain methods of organizing human activity.
Dependent claims 9 and 12 are not directed to any additional claim elements. Rather, these claims offer further descriptive limitations of elements found in the independent claims and addressed above - such as by: wherein the consumer member profile includes the wallet opportunity; and generating at least one assumption based on the user input, and wherein the wallet opportunity is based at least in part on the at least one assumption. These processes are similar to the abstract idea noted in the independent claim because they further the limitations of the independent claim which are directed to certain methods of organizing human activity which include commercial or legal interactions. In addition, no additional elements are integrated into the abstract idea. Therefore, the claims still recite an abstract idea that can be grouped into certain methods of organizing human activity.
Dependent claim 11 is directed to an additional element such as: a third-party database. The third-party database is merely used to store third party data and transmit third-party data to the wallet (Paragraph 0042). The third-party database is considered “insignificant extra-solution activity” at Step 2A because is just “mere data gathering” to use it for a wallet capacity analysis (MPEP 2106.05g). Also, at Step 2B, the third-party database is considered a conventional computer function of “receiving or transmitting data over a network” and “storing information in a memory” (MPEP 2106.05d). Thus, nothing in the claim adds significantly more to the abstract idea. The claim is not patent eligible.
Dependent claims 18-24 are not directed to any additional claim elements. Rather, these claims offer further descriptive limitations of elements found in the independent claims and addressed above - such as by: wherein the first merchant-controlled device is distinct from the second merchant-controlled device; wherein the first merchant-controlled device is a fuel dispenser; wherein the merchant controlled-device is a merchant point of sale device or an ordering device; wherein the at least one wallet data element is associated with a wallet capacity for the at least one good or service; receiving at least one attribute of each of a plurality of consumer- initiated transactions; and generating, based on the at least one attribute, a wallet share associated with the at least one good or service; determining, based at least in part on the wallet share and the wallet capacity associated with the at least one good or service, a wallet opportunity of the at least one good or service for the consumer; and wherein the at least one offer is generated at least in part on the wallet opportunity. These processes are similar to the abstract idea noted in the independent claim because they further the limitations of the independent claim which are directed to certain methods of organizing human activity which include commercial or legal interactions. In addition, no additional elements are integrated into the abstract idea. Therefore, the claims still recite an abstract idea that can be grouped into certain methods of organizing human activity.
Dependent claims 26-27 are directed to an additional element such as: a wallet survey configuration. The wallet survey configuration is merely used to automatically deploy a wallet survey to specific consumers within a Dynamic Audience based on real-time purchase behavior within a defined and linked Wallet or sent automatically to a specific Dynamic Audience configuration as defined by a particular business (Paragraph 0042). This is considered “field of use” MPEP 2106.05h at Step 2A, Prong 2, since it’s merely used to collect configuration settings defined by the merchant (e.g. rules). At Step 2B, this is a conventional computer function of “receiving or transmitting data over a network” and “storing information in a memory” (see MPEP 2106.05d). Thus, nothing in the claim adds significantly more to the abstract idea. The claim is not patent eligible.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-6, 8-9, 11-12, and 21-24 are rejected under 35 U.S.C. 103 as being unpatentable over Winters (US 2011/0231305 A1), in view of Weiss et al. (US 2011/0099046 A1), in further view of Matiushin (Matiushin, I. and Korkhov, V., 2021, July. Passwordless authentication using magic link technology. In CEUR Workshop Proceedings (Vol. 3041, pp. 434-438)).
Regarding claim 1 (Currently Amended), Winters discloses a computer-implemented method associated with a wallet steering program (Paragraph 0312, In one embodiment, a transaction handler is configured to combine customer tracking data with transaction data (109) to generate merchant statistics to compare customer spending habits across different merchants, such as comparing the customer spending pattern related to spending with one merchant and the customer spending pattern related to corresponding spending with the competitive peer set of the merchant; Paragraph 0315, The merchant can adjust the advertisement campaigns to improve performance relative to the activities of the peers of the merchant; Paragraph 0336, The spending pattern of one embodiment is a distribution among a set of merchants (e.g., the merchant, the competitors of the merchant and/or the partners of the merchant). In one embodiment, the purchases from the competitors of the merchant are aggregated as spending associated with the group of the competitors as an aggregated entity (e.g., a peer set); Applicant defines a “wallet steering program” as a particular business executing couponing or promotional campaign. Based on broadest reasonable interpretation in light of the specification, Winters discloses a “wallet steering program” since a promotional campaign (e.g., advertisement) is established based on purchase/transaction data), the method implemented by a computing device including at least one processor in communication with at least one memory device, the method comprising (Paragraph 0559, Routines executed to implement the embodiments may be implemented as part of an operating system or a specific application, component, program, object, module or sequence of instructions referred to as "computer programs." The computer programs typically include one or more instructions set at various times in various memory and storage devices in a computer, and that, when read and executed by one or more processors in a computer, cause the computer to perform operations necessary to execute elements involving the various aspects; Paragraph 0560, A machine readable medium can be used to store software and data which when executed by a data processing system causes the system to perform various methods):
receiving, during a transaction at a first point-of-sale device at a first merchant, a consumer identifier associated with the consumer (Paragraph 0047, In FIG. 4, the transaction handler (103) is coupled between an issuer processor (145) in control of a consumer account (146) and an acquirer processor (147) in control of a merchant account (148). An account identification device (141) is configured to carry the account information (142) that identifies the consumer account (146) with the issuer processor (145) and provide the account information (142) to the transaction terminal (105) of a merchant to initiate a transaction between the user (101) and the merchant);
in response to receiving the consumer identifier during the transaction, automatically creating, in real-time, a consumer member profile for the consumer identifier (Paragraph 0060, In one embodiment, the profile generator (121) generates and updates the transaction profiles (127) in batch mode periodically. In other embodiments, the profile generator (121) generates the transaction profiles (127) in real-time, or just in time, in response to a request received in the portal (143) for such profiles);
storing at least one transaction data element associated with the transaction in the consumer member profile (Paragraph 0046, In one embodiment, a data warehouse (149) as illustrated in FIG. 4 is coupled with the transaction handler (103) to store the transaction data (109) and other data, such as account data (111), transaction profiles (127) and correlation results (123));
causing … a wallet survey for at least one good or service (Paragraph 0055, In one embodiment, the transaction data (109) is combined with external data, such as surveys, benchmarks, search engine statistics, demographics, competition information, emails, etc.; Paragraph 0074, In one embodiment, the advertisement selector (133) may query for specific information regarding the user (101) before providing the user specific advertisement data (119));
ingesting, using an application programming interface (API), wallet data, wherein ingesting the wallet data comprises (Paragraph 0380, Similarly, the profile generator (121) may consolidate transaction data for a group of persons, after the group is identified by certain characteristics, such as gender, income level, geographical location or region, preference, characteristics of past purchases (e.g., merchant categories, purchase types), cluster, propensity, demographics, social networking characteristics (e.g., relationships, preferences, activities on social networking websites), etc. The consolidated transaction data can be used to derive intelligence information about the group to generate a profile for the group (e.g., transaction profiles (127), or the user specific profile (131)); Paragraph 0384, In one embodiment, the entity operating the transaction handler (103) provides the intelligence information in real-time as the request for the intelligence information occurs. In other embodiments, the entity operating the transaction handler (103) may provide the intelligence information in batch mode. The intelligence information can be delivered via online communications (e.g., via an application programming interface (API) on a website, or other information server), or via physical transportation of a computer readable media that stores the data representing the intelligence information):
receiving, via … wallet survey and through the API, input indicating at least a first wallet data element for the at least one good or service (Paragraph 0055, In one embodiment, the transaction data (109) is combined with external data, such as surveys, benchmarks, search engine statistics, demographics, competition information, emails, etc., to flag key events and data values, to set customer, merchant, data or event triggers, and to drive new transactions and new customer contacts; Paragraph 0384, In one embodiment, the entity operating the transaction handler (103) provides the intelligence information in real-time as the request for the intelligence information occurs. In other embodiments, the entity operating the transaction handler (103) may provide the intelligence information in batch mode. The intelligence information can be delivered via online communications (e.g., via an application programming interface (API) on a website, or other information server), or via physical transportation of a computer readable media that stores the data representing the intelligence information; Paragraph 0463, Once the clusters are standardized, the clusters can be used to link purchase information based merchant categories (and/or SKU numbers, product descriptions) with search information based on search terms; Examiner interprets the survey data for a specific product as the first wallet data element for the at least one good or service);
receiving, through the API and from a financial services company, at least a second wallet data element (Paragraph 0032, In one embodiment, the computing apparatus of, or associated with, the transaction handler (e.g., a processor of credit cards, debit cards, prepaid cards, etc.) is configured to provide information based on, or derived from, transactional data to enhance third party product offerings; Paragraph 0338, FIG. 23 shows a system to identify spending patterns according to one embodiment. In FIG. 23, users (101) can use the transaction terminal (105) to conduct payment transactions (e.g., using credit cards, debit cards, prepaid cards). The transaction handler (103) processes the transactions between the users (101) and merchants to generate the transaction data (109). The profile generator (121) can use the transaction data (109) and/or the account data (111) to generate (e.g., periodically) the transaction profiles (127) to characterize the spending patterns of the users (101); Paragraph 0384, In one embodiment, the entity operating the transaction handler (103) provides the intelligence information in real-time as the request for the intelligence information occurs. In other embodiments, the entity operating the transaction handler (103) may provide the intelligence information in batch mode. The intelligence information can be delivered via online communications (e.g., via an application programming interface (API) on a website, or other information server), or via physical transportation of a computer readable media that stores the data representing the intelligence information; Paragraph 0463, Once the clusters are standardized, the clusters can be used to link purchase information based merchant categories (and/or SKU numbers, product descriptions) with search information based on search terms; Examiner interprets data received from a credit card as the second wallet data element);
and receiving, through the API and from a third party data aggregator, at least a third wallet data element (Paragraph 0031, A computing apparatus of, or associated with, the transaction handler uses the transaction data and/or other data, such as account data, merchant data, search data, social networking data, web data, etc., to develop intelligence information about individual customers, or certain types or groups of customers; Paragraph 0056, In FIG. 1, the profile generator (121) generates transaction profiles (127) based on the transaction data (109), the account data (111), and/or other data, such as non-transactional data, wish lists, merchant provided information, address information, information from social network websites; Paragraph 0135, In a further example, the user (101) may visit a third party website, which is the point of interaction (107) in FIG. 1. The third party website may be a web search engine, a news website, a blog, a social network site, etc. The behavior of the user (101) at the third party website may be tracked via a browser cookie, which uses a storage space of the browser to store information about the user (101) at the third party website; Paragraph 0384, In one embodiment, the entity operating the transaction handler (103) provides the intelligence information in real-time as the request for the intelligence information occurs. In other embodiments, the entity operating the transaction handler (103) may provide the intelligence information in batch mode. The intelligence information can be delivered via online communications (e.g., via an application programming interface (API) on a website, or other information server), or via physical transportation of a computer readable media that stores the data representing the intelligence information; Paragraph 0463, Once the clusters are standardized, the clusters can be used to link purchase information based merchant categories (and/or SKU numbers, product descriptions) with search information based on search terms; Examiner interprets data received from a social network as the third wallet data element);
saving the at least a first data element, the at least a second data element, and the at least a third data element to a member profile database (Paragraph 0055, In one embodiment, the transaction data (109) is combined with external data, such as surveys, benchmarks, search engine statistics, demographics, competition information, emails, etc., to flag key events and data values, to set customer, merchant, data or event triggers, and to drive new transactions and new customer contacts; Paragraph 0056, In FIG. 1, the profile generator (121) generates transaction profiles (127) based on the transaction data (109), the account data (111), and/or other data, such as non-transactional data, wish lists, merchant provided information, address information, information from social network websites, information from credit bureaus, information from search engines, information about insurance claims, information from DNA databanks, and other examples discussed in U.S. patent application Ser. No. 12/614,603, filed Nov. 9, 2009 and entitled "Analyzing Local Non-Transactional Data with Transactional Data in Predictive Models," the disclosure of which is hereby incorporated herein by reference; Paragraph 0059, Some of the transaction profiles (127) are specific to the user (101), or to an account of the user (101), or to a group of users of which the user (101) is a member, such as a household, family, company, neighborhood, city, or group identified by certain characteristics related to online activities, offline purchase activities, merchant propensity, etc.; Paragraph 0466, n FIG. 1, the transaction terminal (105) initiates the transaction for a user (101) (e.g., a customer) for processing by a transaction handler (103). The transaction handler (103) processes the transaction and stores transaction data (109) about the transaction, in connection with account data (111), such as the account profile of an account of the user (101). The account data (111) may further include data about the user (101), collected from issuers or merchants, and/or other sources, such as social networks, credit bureaus, merchant provided information, address information, etc.);
storing the at least one wallet data element in the consumer member profile (Paragraph 0159, For example, the merchant may provide the transaction handler (103) with purchase details at stock-keeping unit (SKU) level, which are then stored as part of the loyalty record (187); Paragraph 0191, In one embodiment, based on the SKU information and perhaps other transaction data, the profile generator (121) may create an SKU-level transaction profile for the user (101));
generating at least one offer based on the consumer member profile, wherein the at least one offer is generated at least in part on the at least one wallet data element (Paragraph 0043, FIG. 1 illustrates a system to provide services based on transaction data according to one embodiment. In FIG. 1, the system includes a transaction terminal (105) to initiate financial transactions for a user (101), a transaction handler (103) to generate transaction data (109) from processing the financial transactions of the user (101) (and the financial transactions of other users), a profile generator (121) to generate transaction profiles (127) based on the transaction data (109) to provide information/intelligence about user preferences and spending patterns, a point of interaction (107) to provide information and/or offers to the user (101), a user tracker (113) to generate user data (125) to identify the user (101) using the point of interaction (107), a profile selector (129) to select a profile (131) specific to the user (101) identified by the user data (125), and an advertisement selector (133) to select, identify, generate, adjust, prioritize and/or personalize advertisements for presentation to the user (101) on the point of interaction (107) via a media controller (115); Paragraph 0187, In one embodiment, the user specific profile (131) is an aggregated spending profile (341) that is generated using the SKU-level information. For example, in one embodiment, the factor values (344) correspond to factor definitions (331) that are generated based on aggregating spending in different categories of products and/or services. A typical merchant offers products and/or services in many different categories);
in response to receiving, during a subsequent transaction, the consumer identifier at a second point-of-sale device at a second merchant (Paragraph 0047, In FIG. 4, the transaction handler (103) is coupled between an issuer processor (145) in control of a consumer account (146) and an acquirer processor (147) in control of a merchant account (148). An account identification device (141) is configured to carry the account information (142) that identifies the consumer account (146) with the issuer processor (145) and provide the account information (142) to the transaction terminal (105) of a merchant to initiate a transaction between the user (101) and the merchant; and the condition(s) of the offer (401) is (are) based on information accessible to the transaction handler (103) during the processing of a payment transaction submitted from the transaction terminal (105). For example, the conditions may be based on the identity of the merchant, the timing of the transaction, and/or the amount of the transaction (e.g., 10% off a purchase above $10.00 within one hour of the advertisement that presents the offer (401)). For example, the conditions may be based on the information of multiple transactions (e.g., a discount on all purchases when total purchases made in a predetermined time period from the retail stores of a retail chain is above a predetermined threshold, a rebate when a time period between two purchases from two predetermined, related merchants is less than a predetermined threshold, etc.), automatically …, authenticating the consumer and causing to be displayed, on the user computing device, at least one first communication to the consumer, the at least one communication including an offer for at least one good or service related to the subsequent transaction (Paragraph 0183, The offers may be triggered by and/or tailored to a previous transaction, and may be valid only for a limited period of time starting from the date of the previous transaction. If the transaction handler (103) determines that a subsequent transaction processed by the transaction handler (103) meets the conditions for the redemption of an offer, the transaction handler (103) may credit the consumer account (146) for the redemption of the offer and/or provide a notification message to the user (101); Paragraph 0230, In one embodiment, when the link to the portal (143) is selected, the user (101) is to provide the account information (142) to the portal (143) via the point of interaction (107) to identify the consumer account (146) of the user (101). After both the consumer account (146) of the user (101) and the offer (186) are identified, the data warehouse (149) is to store the data to associate offer (186) with the account information (142) in the account data (111) of the user (101); Paragraph 0231, In one embodiment, the account information (142) is pre-stored in the account data (111) of the user (101). The portal (143) is to authenticate the identity of the user (101) in response to the user selection of the link to the portal (143). After the user (101) is identified via authentication, the data warehouse (149) stores the data to associate offer (186) with the account information (142) in the account data (111) of the user (101); Paragraph 0232, For example, in one embodiment, the portal (143) is to initially identify and authenticate the user (101) of the point of interaction (107) via a username and a password; Paragraph 0271, In some embodiments, the message (423) may include an advertisement which may present a new offer (e.g., selected based on a relationship with the current transaction). For example, based on past transactions, the transaction handler (103) may determine that, when the user (101) makes the current purchase, the likelihood of the user (101) to make a related purchase is higher than a threshold. Thus, to promote the related purchase, the transaction handler (103) may identify the new offer and transmit the new offer to the mobile phone (421) (e.g., with the notification message (423)). If the user (101) is interested in the new offer, the user (101) may select the new offer for storing in the account of the user (101) via the web portal (143). In some embodiments, the web portal (143) may include gateways for storing the offers via other communication channels, such as text message, email, etc.; Paragraph 0280, The unique code may be pre-associated with information about the advertisement that contains the offer (401), such as the identity of the website that presents the offer (401), the date and time of the presentation of the offer (401), the terms, conditions and benefits of the offer (401), etc. When the portion (403) is selected, the unique code is stored in the account to associate the information represented by the unique code with the account, which when used in a subsequent transaction that satisfies the terms and conditions of the offer (401) causes the automated redemption of the offer (401), as well as the linkage between the purchase and the information represented by the unique code; Examiner notes that Winters can keep track of offers provided to customers using known authentication techniques, wherein the customers can redeem those offers stored in their profile in subsequent transactions).
Although Winters discloses receiving consumer information from different sources to evaluate spending across all retailers (Paragraphs 0055 & 0312, Survey and customer spending patterns with the competitive peer set of the merchant), Winters does not specifically disclose wherein the survey includes a user interface to input customer spending data for the at least one wallet data element.
However, Weiss et al. discloses causing to be displayed on a user interface of a computing device, a wallet survey for at least one good or service; ingesting, using an … interface …, wallet data, wherein ingesting the wallet data comprises: receiving, via the user interface displaying the wallet survey and through the [interface], a user input indicating at least a first wallet data element for the at least one good or service (Paragraph 0036, inform a business of promotions or advertisements that may entice consumers; Paragraph 0052, How to encourage consumers 102 to visit the coffee shop 122; Paragraph 0063, Consumer purchase data may be provided by the consumer purchase data facility 206 with or without request by the consumer analytics engine 208. Consumer purchase data may include any suitable information about consumer purchases that may be provided by businesses at which consumer shop or financial companies with which customers have relationships. Purchase data may also be provided by consumers themselves, such as in responses to surveys. Businesses may obtain data about consumer purchases when the consumers provide to businesses personal information to associate the consumers with purchases. This may be the case when the consumers participate in programs (e.g., rewards or loyalty programs) with the businesses, such that the consumers identify themselves at the time they purchase goods or services. Similarly, financial companies may obtain information about consumer purchases when the consumers use credit cards, debit cards, checks, layaway programs, or other financial products to purchase goods or services; Paragraph 0138, In some embodiments, the consumer analytics system may incent consumers to opt-in to sharing electronically-captured location data with the consumer analytics system and/or to perform a task (e.g., provide information as part of a task, such as by completing a survey) requested by such a system as a result of location-triggered actions, in return for rewards. Such rewards may include, but are not limited to, food or beverage coupons or vouchers, merchandise discounts, discounts on their purchases (e.g., 15% off), entries into prize drawings, material goods, or cash. As illustrated in FIG. 5, for example, the consumer analytics system may render an interface, which may be displayed to a consumer via a mobile device, by which a consumer may view tasks the system 108 desires the consumer to perform (e.g., answering survey questions) and rewards that are offered to the consumer for performing the tasks. FIG. 6 illustrates an example of another interface that may be displayed to a consumer via a mobile device by which a consumer may perform a task that includes answering survey questions; Paragraph 0205, While not illustrated in FIG. 11, a computing device may additionally have one or more components and peripherals, including input and output devices. These devices can be used, among other things, to present a user interface. Examples of output devices that can be used to provide a user interface include printers or display screens for visual presentation of output and speakers or other sound generating devices for audible presentation of output. Examples of input devices that can be used for a user interface include keyboards, and pointing devices, such as mice, touch pads, and digitizing tablets. As another example, a computing device may receive input information through speech recognition or in other audible format; Paragraph 0189, The server may include one or more of memories, processors, storage media, ports (physical and virtual), communication devices, and interfaces capable of accessing other servers, clients, machines, and devices through a wired or a wireless medium, and the like; Examiner interprets “purchase data” as “the at least one wallet data element”).
It would have been obvious to one ordinary skill in the art before the effective filing date to modify the method used for aggregating transaction data in real-time based on information received from multiple sources (e.g., POS/merchant transaction data, credit card transaction data, and survey data) of the invention of Winters to further incorporate wherein the survey data is received via a user interface of a computing device of the invention of Weiss et al. because doing so would allow consumers to provide purchase data, such as in responses to surveys (see Weiss et al., Paragraphs 0063). As stated by Weiss in Paragraph 0063, there are different ways to acquire consumer transaction/purchase data (e.g., provided by businesses at which consumer shop, financial companies with which customers have relationships such as credit cards, and/or survey). Therefore, this is merely a simple substitution of a known technique used to acquire consumer transaction/purchase data (e.g., aggregating POS transaction data and credit card transaction data) for another known technique used to acquire consumer transaction/purchase data (e.g., survey). The simple substitution of one known technique for another producing a predictable result renders the claim obvious.
The combination of Winters and Weiss discloses: generating offers based on the aggregated consumer profile transactional data; and techniques used to authenticate a consumer when the consumer is redeeming an offer (see at least Winters, Paragraph 0230, provide account information; Paragraph 0232, identify and authenticate the user (101) of the point of interaction (107) via a username and a password). Although the combination of Winters and Weiss discloses authentication techniques to access a user account, the combination of Winters and Weiss does not specifically disclose wherein the authentication technique includes a hyperlink containing a unique code (e.g., magic link).
However, Matiushin discloses automatically transmitting, to a user computing device associated with the consumer identifier, a hyperlink containing a unique code; in response to receiving, via a user interface of the user computing device, a user input selecting the hyperlink, comparing the unique code contained in the hyperlink with a temporary unique code associated with the consumer identifier; and in response to the unique code contained in the hyperlink matching the temporary unique code with the consumer identifier, authenticating the consumer and causing to … (Pages 436-437, 3. Practical implementations, We have created a Keycloak magic link authentication module. The module allows the Keycloak administrator to set up e-mail-based passwordless authentication for a certain user, or a group of users. The authentication flow can be described as follows [4]: [Symbol font/0xB7] The user starts the authentication process [Symbol font/0xB7] The system requests the user’s e-mail address, which the user provides [Symbol font/0xB7] If the user doesn’t exist within the system’s database, a new user is created [Symbol font/0xB7] The system then generates a unique token for the magic link and forms the magic link [Symbol font/0xB7] The magic link URL is sent to the user’s e-mail [Symbol font/0xB7] The user clicks on the magic link and is redirected to the authentication page [Symbol font/0xB7] The system checks if the magic link is valid; if it is, the user successfully logs in. The authentication flow is shown in Figure 1).
PNG
media_image1.png
209
574
media_image1.png
Greyscale
It would have been obvious to one ordinary skill in the art before the effective filing date to modify the method used for generating and transmitting at least one offer based on the consumer member profile, wherein the offer can be subsequently redeemed by using an authentication technique (e.g., account information and/or a username and a password) of the invention of Winters to further incorporate other known authentication techniques of the invention of Matiushin because doing so would allow the method to authenticate the user using a magic link authentication process, which simplifies the process of registering new users and relieves them of the need to remember passwords (see Matiushin, Page 435, 1. Introduction & Page 436, 3. Practical implementations). Also, this is merely a simple substitution of a known technique used to authenticate users (e.g., account information and/or a username and a password) for another known technique used to authenticate users (e.g., magic link). The simple substitution of one known technique for another producing a predictable result renders the claim obvious.
Regarding claim 2 (Previously Presented), which is dependent of claim 1, the combination of Winters, Weiss et al., and Matiushin discloses all the limitations in claim 1. Winters further discloses storing at least one transaction data element associated with the subsequent transaction to the consumer member profile (Paragraph 0043, FIG. 1 illustrates a system to provide services based on transaction data according to one embodiment. In FIG. 1, the system includes a transaction terminal (105) to initiate financial transactions for a user (101), a transaction handler (103) to generate transaction data (109) from processing the financial transactions of the user (101) (and the financial transactions of other users), a profile generator (121) to generate transaction profiles (127) based on the transaction data (109) to provide information/intelligence about user preferences and spending patterns, a point of interaction (107) to provide information and/or offers to the user (101), a user tracker (113) to generate user data (125) to identify the user (101) using the point of interaction (107), a profile selector (129) to select a profile (131) specific to the user (101) identified by the user data (125), and an advertisement selector (133) to select, identify, generate, adjust, prioritize and/or personalize advertisements for presentation to the user (101) on the point of interaction (107) via a media controller (115); Paragraph 0046, In one embodiment, a data warehouse (149) as illustrated in FIG. 4 is coupled with the transaction handler (103) to store the transaction data (109) and other data, such as account data (111), transaction profiles (127) and correlation results (123); Paragraph 0183, The offers may be triggered by and/or tailored to a previous transaction, and may be valid only for a limited period of time starting from the date of the previous transaction. If the transaction handler (103) determines that a subsequent transaction processed by the transaction handler (103) meets the conditions for the redemption of an offer, the transaction handler (103) may credit the consumer account (146) for the redemption of the offer and/or provide a notification message to the user (101)).
Regarding claim 3 (Original), which is dependent of claim 1, the combination of Winters, Weiss et al., and Matiushin discloses all the limitations in claim 1. Winters further discloses wherein the at least one communication comprises at least one first communication including an offer (Paragraph 0043, FIG. 1 illustrates a system to provide services based on transaction data according to one embodiment. In FIG. 1, the system includes a transaction terminal (105) to initiate financial transactions for a user (101), a transaction handler (103) to generate transaction data (109) from processing the financial transactions of the user (101) (and the financial transactions of other users), a profile generator (121) to generate transaction profiles (127) based on the transaction data (109) to provide information/intelligence about user preferences and spending patterns, a point of interaction (107) to provide information and/or offers to the user (101), a user tracker (113) to generate user data (125) to identify the user (101) using the point of interaction (107), a profile selector (129) to select a profile (131) specific to the user (101) identified by the user data (125), and an advertisement selector (133) to select, identify, generate, adjust, prioritize and/or personalize advertisements for presentation to the user (101) on the point of interaction (107) via a media controller (115)), transmitting, to the consumer, at least one second communication including a request (Paragraph 0232, For example, in one embodiment, the portal (143) is to initially identify and authenticate the user (101) of the point of interaction (107) via a username and a password).
Regarding claim 4 (Original), which is dependent of claim 3, the combination of Winters, Weiss et al., and Matiushin discloses all the limitations in claim 3. Winters further discloses in response to the request being fulfilled, transmitting, to the consumer, at least one third communication including an offer (Paragraph 0232, For example, in one embodiment, the portal (143) is to initially identify and authenticate the user (101) of the point of interaction (107) via a username and a password; Paragraph 0271, In some embodiments, the message (423) may include an advertisement which may present a new offer (e.g., selected based on a relationship with the current transaction). For example, based on past transactions, the transaction handler (103) may determine that, when the user (101) makes the current purchase, the likelihood of the user (101) to make a related purchase is higher than a threshold. Thus, to promote the related purchase, the transaction handler (103) may identify the new offer and transmit the new offer to the mobile phone (421) (e.g., with the notification message (423)). If the user (101) is interested in the new offer, the user (101) may select the new offer for storing in the account of the user (101) via the web portal (143). In some embodiments, the web portal (143) may include gateways for storing the offers via other communication channels, such as text message, email, etc.).
Regarding claim 5 (Previously Presented), which is dependent of claim 3, the combination of Winters, Weiss et al., and Matiushin discloses all the limitations in claim 3. Winters further discloses wherein the request for the consumer comprises authenticating the consumer member profile, downloading an application, inputting additional personal information, or responding to the wallet survey (Paragraph 0232, For example, in one embodiment, the portal (143) is to initially identify and authenticate the user (101) of the point of interaction (107) via a username and a password; Paragraph 0271, In some embodiments, the message (423) may include an advertisement which may present a new offer (e.g., selected based on a relationship with the current transaction). For example, based on past transactions, the transaction handler (103) may determine that, when the user (101) makes the current purchase, the likelihood of the user (101) to make a related purchase is higher than a threshold. Thus, to promote the related purchase, the transaction handler (103) may identify the new offer and transmit the new offer to the mobile phone (421) (e.g., with the notification message (423)). If the user (101) is interested in the new offer, the user (101) may select the new offer for storing in the account of the user (101) via the web portal (143). In some embodiments, the web portal (143) may include gateways for storing the offers via other communication channels, such as text message, email, etc.; It can be noted that the claim language is written in alternative form. The limitation taught by Winters is based on “authenticating the consumer member profile").
Regarding claim 6 (Previously Presented), which is dependent of claim 1, the combination of Winters, Weiss et al., and Matiushin discloses all the limitations in claim 1. Winters further discloses wherein the at least one transaction data element is associated with at least one of a location of the transaction, at least one of a date or time associated with the transaction, a quantity associated with a good service purchased in the transaction, or a cost associated with a good or service purchased in the transaction (Paragraph 0388, Each of the transaction records (301) provides information about the particular transaction, such as the account number (302) of the consumer account (146) used to pay for the purchase, the date (303) (and/or time) of the transaction, the amount (304) of the transaction, the ID (305) of the merchant who receives the payment, the category (306) of the merchant, the channel (307) through which the purchase was made, etc. Examples of channels include online, offline in-store, via phone, etc.; It can be noted that the claim language is written in alternative form. The limitation taught by Winters is associated with a date or time associated with the transaction, and a cost associated with a good or service purchased in the transaction).
Regarding claim 8 (Currently Amended), Winters discloses a computer-implemented method associated with a wallet steering program, the method comprising (Paragraph 0312, In one embodiment, a transaction handler is configured to combine customer tracking data with transaction data (109) to generate merchant statistics to compare customer spending habits across different merchants, such as comparing the customer spending pattern related to spending with one merchant and the customer spending pattern related to corresponding spending with the competitive peer set of the merchant; Paragraph 0315, The merchant can adjust the advertisement campaigns to improve performance relative to the activities of the peers of the merchant; Paragraph 0336, The spending pattern of one embodiment is a distribution among a set of merchants (e.g., the merchant, the competitors of the merchant and/or the partners of the merchant). In one embodiment, the purchases from the competitors of the merchant are aggregated as spending associated with the group of the competitors as an aggregated entity (e.g., a peer set); Applicant defines a “wallet steering program” as a particular business executing couponing or promotional campaign. Based on broadest reasonable interpretation in light of the specification, Winters discloses a “wallet steering program” since a promotional campaign (e.g., advertisement) is established based on purchase/transaction data):
receiving into a digital wallet at least one attribute of each of a plurality of consumer-initiated transactions conducted at plurality of different point-of-sale devices (Paragraph 0130, In another example, the transaction terminal (105) is a POS terminal at the checkout station in a retail store (e.g., a self-service checkout register); Paragraph 0187, In one embodiment, the user specific profile (131) is an aggregated spending profile (341) that is generated using the SKU-level information. For example, in one embodiment, the factor values (344) correspond to factor definitions (331) that are generated based on aggregating spending in different categories of products and/or services. A typical merchant offers products and/or services in many different categories; Paragraph 0312, In one embodiment, a transaction handler is configured to combine customer tracking data with transaction data (109) to generate merchant statistics to compare customer spending habits across different merchants, such as comparing the customer spending pattern related to spending with one merchant and the customer spending pattern related to corresponding spending with the competitive peer set of the merchant);
generating, based on the at least one attribute a wallet share associated with at least one good or service (Paragraph 0187, In one embodiment, the user specific profile (131) is an aggregated spending profile (341) that is generated using the SKU-level information. For example, in one embodiment, the factor values (344) correspond to factor definitions (331) that are generated based on aggregating spending in different categories of products and/or services. A typical merchant offers products and/or services in many different categories; Paragraph 0312, In one embodiment, a transaction handler is configured to combine customer tracking data with transaction data (109) to generate merchant statistics to compare customer spending habits across different merchants, such as comparing the customer spending pattern related to spending with one merchant and the customer spending pattern related to corresponding spending with the competitive peer set of the merchant; Based on broadest reasonable interpretation in light of the specification, Winters discloses a wallet share since it tracks how much a customer is spending in a specific good or service at another retailer or competitor. See Paragraph 0057 of Applicant’s specification);
causing … a wallet survey for at least one good or service (Paragraph 0055, In one embodiment, the transaction data (109) is combined with external data, such as surveys, benchmarks, search engine statistics, demographics, competition information, emails, etc.; Paragraph 0074, In one embodiment, the advertisement selector (133) may query for specific information regarding the user (101) before providing the user specific advertisement data (119));
ingesting, using an application programming interface (API), wallet data, wherein ingesting the wallet data comprises (Paragraph 0380, Similarly, the profile generator (121) may consolidate transaction data for a group of persons, after the group is identified by certain characteristics, such as gender, income level, geographical location or region, preference, characteristics of past purchases (e.g., merchant categories, purchase types), cluster, propensity, demographics, social networking characteristics (e.g., relationships, preferences, activities on social networking websites), etc. The consolidated transaction data can be used to derive intelligence information about the group to generate a profile for the group (e.g., transaction profiles (127), or the user specific profile (131)); Paragraph 0384, In one embodiment, the entity operating the transaction handler (103) provides the intelligence information in real-time as the request for the intelligence information occurs. In other embodiments, the entity operating the transaction handler (103) may provide the intelligence information in batch mode. The intelligence information can be delivered via online communications (e.g., via an application programming interface (API) on a website, or other information server), or via physical transportation of a computer readable media that stores the data representing the intelligence information):
receiving, from … wallet survey and through the API, a user input indicating a wallet capacity associated with at least a first wallet data element for the at least one good or service (Paragraph 0055, In one embodiment, the transaction data (109) is combined with external data, such as surveys, benchmarks, search engine statistics, demographics, competition information, emails, etc., to flag key events and data values, to set customer, merchant, data or event triggers, and to drive new transactions and new customer contacts; Paragraph 0384, In one embodiment, the entity operating the transaction handler (103) provides the intelligence information in real-time as the request for the intelligence information occurs. In other embodiments, the entity operating the transaction handler (103) may provide the intelligence information in batch mode. The intelligence information can be delivered via online communications (e.g., via an application programming interface (API) on a website, or other information server), or via physical transportation of a computer readable media that stores the data representing the intelligence information; Paragraph 0463, Once the clusters are standardized, the clusters can be used to link purchase information based merchant categories (and/or SKU numbers, product descriptions) with search information based on search terms; Examiner interprets the survey data for a specific product as the first wallet data element for the at least one good or service);
receiving, through the API and from a financial services company, at least a second wallet data element (Paragraph 0032, In one embodiment, the computing apparatus of, or associated with, the transaction handler (e.g., a processor of credit cards, debit cards, prepaid cards, etc.) is configured to provide information based on, or derived from, transactional data to enhance third party product offerings; Paragraph 0338, FIG. 23 shows a system to identify spending patterns according to one embodiment. In FIG. 23, users (101) can use the transaction terminal (105) to conduct payment transactions (e.g., using credit cards, debit cards, prepaid cards). The transaction handler (103) processes the transactions between the users (101) and merchants to generate the transaction data (109). The profile generator (121) can use the transaction data (109) and/or the account data (111) to generate (e.g., periodically) the transaction profiles (127) to characterize the spending patterns of the users (101); Paragraph 0384, In one embodiment, the entity operating the transaction handler (103) provides the intelligence information in real-time as the request for the intelligence information occurs. In other embodiments, the entity operating the transaction handler (103) may provide the intelligence information in batch mode. The intelligence information can be delivered via online communications (e.g., via an application programming interface (API) on a website, or other information server), or via physical transportation of a computer readable media that stores the data representing the intelligence information; Paragraph 0463, Once the clusters are standardized, the clusters can be used to link purchase information based merchant categories (and/or SKU numbers, product descriptions) with search information based on search terms; Examiner interprets data received from a credit card as the second wallet data element);
and receiving, through the API and from a third party data aggregator, at least a third wallet data element (Paragraph 0031, A computing apparatus of, or associated with, the transaction handler uses the transaction data and/or other data, such as account data, merchant data, search data, social networking data, web data, etc., to develop intelligence information about individual customers, or certain types or groups of customers; Paragraph 0056, In FIG. 1, the profile generator (121) generates transaction profiles (127) based on the transaction data (109), the account data (111), and/or other data, such as non-transactional data, wish lists, merchant provided information, address information, information from social network websites; Paragraph 0135, In a further example, the user (101) may visit a third party website, which is the point of interaction (107) in FIG. 1. The third party website may be a web search engine, a news website, a blog, a social network site, etc. The behavior of the user (101) at the third party website may be tracked via a browser cookie, which uses a storage space of the browser to store information about the user (101) at the third party website; Paragraph 0384, In one embodiment, the entity operating the transaction handler (103) provides the intelligence information in real-time as the request for the intelligence information occurs. In other embodiments, the entity operating the transaction handler (103) may provide the intelligence information in batch mode. The intelligence information can be delivered via online communications (e.g., via an application programming interface (API) on a website, or other information server), or via physical transportation of a computer readable media that stores the data representing the intelligence information; Paragraph 0463, Once the clusters are standardized, the clusters can be used to link purchase information based merchant categories (and/or SKU numbers, product descriptions) with search information based on search terms; Examiner interprets data received from a social network as the third wallet data element);
saving the at least a first data element, the at least a second data element, and the at least a third data element to a member profile database (Paragraph 0055, In one embodiment, the transaction data (109) is combined with external data, such as surveys, benchmarks, search engine statistics, demographics, competition information, emails, etc., to flag key events and data values, to set customer, merchant, data or event triggers, and to drive new transactions and new customer contacts; Paragraph 0056, In FIG. 1, the profile generator (121) generates transaction profiles (127) based on the transaction data (109), the account data (111), and/or other data, such as non-transactional data, wish lists, merchant provided information, address information, information from social network websites, information from credit bureaus, information from search engines, information about insurance claims, information from DNA databanks, and other examples discussed in U.S. patent application Ser. No. 12/614,603, filed Nov. 9, 2009 and entitled "Analyzing Local Non-Transactional Data with Transactional Data in Predictive Models," the disclosure of which is hereby incorporated herein by reference; Paragraph 0059, Some of the transaction profiles (127) are specific to the user (101), or to an account of the user (101), or to a group of users of which the user (101) is a member, such as a household, family, company, neighborhood, city, or group identified by certain characteristics related to online activities, offline purchase activities, merchant propensity, etc.; Paragraph 0466, n FIG. 1, the transaction terminal (105) initiates the transaction for a user (101) (e.g., a customer) for processing by a transaction handler (103). The transaction handler (103) processes the transaction and stores transaction data (109) about the transaction, in connection with account data (111), such as the account profile of an account of the user (101). The account data (111) may further include data about the user (101), collected from issuers or merchants, and/or other sources, such as social networks, credit bureaus, merchant provided information, address information, etc.);
determining, based at least in part on the wallet share and the wallet capacity associated with the at least one good or service, a wallet opportunity of the at least one good or service for the consumer; generating an offer based on the wallet opportunity of the at least one good or service for a consumer (Paragraph 0043, a profile generator (121) to generate transaction profiles (127) based on the transaction data (109) to provide information/intelligence about user preferences and spending patterns, a point of interaction (107) to provide information and/or offers to the user (101); Paragraph 0053, For example, a third party strategic marketing analyst, statistician, marketer, promoter, business leader, etc., may access the centralized data warehouse (149) to analyze customer and shopper data, to provide follow-up analyses of customer contributions, to develop propensity models for increased conversion of marketing campaigns, to develop segmentation models for marketing, etc. The centralized data warehouse (149) can be used to manage advertisement campaigns and analyze response profitability; Paragraph 0187, In one embodiment, the user specific profile (131) is an aggregated spending profile (341) that is generated using the SKU-level information. For example, in one embodiment, the factor values (344) correspond to factor definitions (331) that are generated based on aggregating spending in different categories of products and/or services. A typical merchant offers products and/or services in many different categories; Paragraph 0201, In one embodiment, the SKU-level profile of the user (101) may reflect transactions with a particular merchant or merchants. The SKU-level profile of the user (101) may be provided to a business that is considered a peer with or similar to the particular merchant or merchants. For example, a merchant may be considered a peer of the business because the merchant offers goods and services that are similar to or related to those of the business. The SKU-level profile reflecting transactions with peer merchants may be used by the business to better predict the purchasing behavior of the user (101) and to optimize the presentation of targeted advertisements to the user (101); Paragraph 0312, In one embodiment, a transaction handler is configured to combine customer tracking data with transaction data (109) to generate merchant statistics to compare customer spending habits across different merchants, such as comparing the customer spending pattern related to spending with one merchant and the customer spending pattern related to corresponding spending with the competitive peer set of the merchant; Examiner interprets to provide advertisements to increase the share/month for a specific good or service as the wallet opportunity);
…, authenticating the consumer and causing to be displayed, on the user computing device, at least one first communication to the consumer, the at least one communication including an offer for at least one good or service related to the subsequent transaction (Paragraph 0183, The offers may be triggered by and/or tailored to a previous transaction, and may be valid only for a limited period of time starting from the date of the previous transaction. If the transaction handler (103) determines that a subsequent transaction processed by the transaction handler (103) meets the conditions for the redemption of an offer, the transaction handler (103) may credit the consumer account (146) for the redemption of the offer and/or provide a notification message to the user (101); Paragraph 0230, In one embodiment, when the link to the portal (143) is selected, the user (101) is to provide the account information (142) to the portal (143) via the point of interaction (107) to identify the consumer account (146) of the user (101). After both the consumer account (146) of the user (101) and the offer (186) are identified, the data warehouse (149) is to store the data to associate offer (186) with the account information (142) in the account data (111) of the user (101); Paragraph 0231, In one embodiment, the account information (142) is pre-stored in the account data (111) of the user (101). The portal (143) is to authenticate the identity of the user (101) in response to the user selection of the link to the portal (143). After the user (101) is identified via authentication, the data warehouse (149) stores the data to associate offer (186) with the account information (142) in the account data (111) of the user (101); Paragraph 0232, For example, in one embodiment, the portal (143) is to initially identify and authenticate the user (101) of the point of interaction (107) via a username and a password; Paragraph 0271, In some embodiments, the message (423) may include an advertisement which may present a new offer (e.g., selected based on a relationship with the current transaction). For example, based on past transactions, the transaction handler (103) may determine that, when the user (101) makes the current purchase, the likelihood of the user (101) to make a related purchase is higher than a threshold. Thus, to promote the related purchase, the transaction handler (103) may identify the new offer and transmit the new offer to the mobile phone (421) (e.g., with the notification message (423)). If the user (101) is interested in the new offer, the user (101) may select the new offer for storing in the account of the user (101) via the web portal (143). In some embodiments, the web portal (143) may include gateways for storing the offers via other communication channels, such as text message, email, etc.; Paragraph 0280, The unique code may be pre-associated with information about the advertisement that contains the offer (401), such as the identity of the website that presents the offer (401), the date and time of the presentation of the offer (401), the terms, conditions and benefits of the offer (401), etc. When the portion (403) is selected, the unique code is stored in the account to associate the information represented by the unique code with the account, which when used in a subsequent transaction that satisfies the terms and conditions of the offer (401) causes the automated redemption of the offer (401), as well as the linkage between the purchase and the information represented by the unique code; Examiner notes that Winters can keep track of offers provided to customers using known authentication techniques, wherein the customers can redeem those offers stored in their profile in subsequent transactions).
Although Winters discloses receiving consumer information from different sources to evaluate spending across all retailers (Paragraphs 0055 & 0312, Survey and customer spending patterns with the competitive peer set of the merchant), Winters does not specifically disclose wherein the survey includes a user interface to input customer spending data for the at least one wallet data element.
However, Weiss et al. discloses causing to be displayed on a user interface of a computing device, a wallet survey for at least one good or service; ingesting, using an … interface …, wallet data, wherein ingesting the wallet data comprises: receiving, via the user interface displaying the wallet survey and through the [interface], a user input indicating a wallet capacity associated with at least a first wallet data element for the at least one good or service (Paragraph 0036, inform a business of promotions or advertisements that may entice consumers; Paragraph 0052, How to encourage consumers 102 to visit the coffee shop 122; Paragraph 0063, Consumer purchase data may be provided by the consumer purchase data facility 206 with or without request by the consumer analytics engine 208. Consumer purchase data may include any suitable information about consumer purchases that may be provided by businesses at which consumer shop or financial companies with which customers have relationships. Purchase data may also be provided by consumers themselves, such as in responses to surveys. Businesses may obtain data about consumer purchases when the consumers provide to businesses personal information to associate the consumers with purchases. This may be the case when the consumers participate in programs (e.g., rewards or loyalty programs) with the businesses, such that the consumers identify themselves at the time they purchase goods or services. Similarly, financial companies may obtain information about consumer purchases when the consumers use credit cards, debit cards, checks, layaway programs, or other financial products to purchase goods or services; Paragraph 0065, Consumer purchase information may be aggregated for each consumer and provided to the consumer analytics engine; Paragraph 0138, In some embodiments, the consumer analytics system may incent consumers to opt-in to sharing electronically-captured location data with the consumer analytics system and/or to perform a task (e.g., provide information as part of a task, such as by completing a survey) requested by such a system as a result of location-triggered actions, in return for rewards. Such rewards may include, but are not limited to, food or beverage coupons or vouchers, merchandise discounts, discounts on their purchases (e.g., 15% off), entries into prize drawings, material goods, or cash. As illustrated in FIG. 5, for example, the consumer analytics system may render an interface, which may be displayed to a consumer via a mobile device, by which a consumer may view tasks the system 108 desires the consumer to perform (e.g., answering survey questions) and rewards that are offered to the consumer for performing the tasks. FIG. 6 illustrates an example of another interface that may be displayed to a consumer via a mobile device by which a consumer may perform a task that includes answering survey questions; Paragraph 0205, While not illustrated in FIG. 11, a computing device may additionally have one or more components and peripherals, including input and output devices. These devices can be used, among other things, to present a user interface. Examples of output devices that can be used to provide a user interface include printers or display screens for visual presentation of output and speakers or other sound generating devices for audible presentation of output. Examples of input devices that can be used for a user interface include keyboards, and pointing devices, such as mice, touch pads, and digitizing tablets. As another example, a computing device may receive input information through speech recognition or in other audible format; Paragraph 0189, The server may include one or more of memories, processors, storage media, ports (physical and virtual), communication devices, and interfaces capable of accessing other servers, clients, machines, and devices through a wired or a wireless medium, and the like; Examiner interprets “purchase data for a specific product/service” as the wallet capacity since it indicates how much money a customer is spending for a specific product/service).
It would have been obvious to one ordinary skill in the art before the effective filing date to modify the method used for aggregating transaction data in real-time based on information received from multiple sources (e.g., POS transaction data and credit card transaction data) of the invention of Winters to further incorporate wherein the survey data is received via a user interface of a computing device of the invention of Weiss et al. because doing so would allow consumers to provide purchase data, such as in responses to surveys (see Weiss et al., Paragraphs 0063). As stated by Weiss in Paragraph 0063, there are different ways to acquire consumer transaction/purchase data (e.g., provided by businesses at which consumer shop, financial companies with which customers have relationships such as credit cards, and/or survey). Therefore, this is merely a simple substitution of a known technique used to acquire consumer transaction/purchase data (e.g., aggregating POS transaction data and credit card transaction data) for another known technique used to acquire consumer transaction/purchase data (e.g., survey). The simple substitution of one known technique for another producing a predictable result renders the claim obvious.
The combination of Winters and Weiss discloses: generating offers based on the aggregated consumer profile transactional data; and techniques used to authenticate a consumer when the consumer is redeeming an offer (see at least Winters, Paragraph 0230, provide account information; Paragraph 0232, identify and authenticate the user (101) of the point of interaction (107) via a username and a password). Although the combination of Winters and Weiss discloses authentication techniques to access a user account, the combination of Winters and Weiss does not specifically disclose wherein the authentication technique includes a hyperlink containing a unique code (e.g., magic link).
However, Matiushin discloses transmitting to a user computing device associated with the consumer, a hyperlink containing a unique code; in response to receiving, via a user interface of the user computing device, a user input selecting the hyperlink, comparing the unique code contained in the hyperlink with a temporary unique code associated with the consumer; and in response to the unique code contained in the hyperlink matching the temporary unique code with the consumer, authenticating the consumer and causing to … (Pages 436-437, 3. Practical implementations, We have created a Keycloak magic link authentication module. The module allows the Keycloak administrator to set up e-mail-based passwordless authentication for a certain user, or a group of users. The authentication flow can be described as follows [4]: [Symbol font/0xB7] The user starts the authentication process [Symbol font/0xB7] The system requests the user’s e-mail address, which the user provides [Symbol font/0xB7] If the user doesn’t exist within the system’s database, a new user is created [Symbol font/0xB7] The system then generates a unique token for the magic link and forms the magic link [Symbol font/0xB7] The magic link URL is sent to the user’s e-mail [Symbol font/0xB7] The user clicks on the magic link and is redirected to the authentication page [Symbol font/0xB7] The system checks if the magic link is valid; if it is, the user successfully logs in. The authentication flow is shown in Figure 1).
PNG
media_image1.png
209
574
media_image1.png
Greyscale
It would have been obvious to one ordinary skill in the art before the effective filing date to modify the method used for generating and transmitting at least one offer based on the consumer member profile, wherein the offer can be subsequently redeemed by using an authentication technique (e.g., account information and/or a username and a password) of the invention of Winters to further incorporate other known authentication techniques of the invention of Matiushin because doing so would allow the method to authenticate the user using a magic link authentication process, which simplifies the process of registering new users and relieves them of the need to remember passwords (see Matiushin, Page 435, 1. Introduction & Page 436, 3. Practical implementations). Also, this is merely a simple substitution of a known technique used to authenticate users (e.g., account information and/or a username and a password) for another known technique used to authenticate users (e.g., magic link). The simple substitution of one known technique for another producing a predictable result renders the claim obvious.
Regarding claim 9 (Original), which is dependent of claim 8, the combination of Winters, Weiss et al., and Matiushin discloses all the limitations in claim 8. Winters further comprising storing the wallet opportunity of the at least one good or service for the consumer in a consumer member profile (Paragraph 0043, FIG. 1 illustrates a system to provide services based on transaction data according to one embodiment. In FIG. 1, the system includes a transaction terminal (105) to initiate financial transactions for a user (101), a transaction handler (103) to generate transaction data (109) from processing the financial transactions of the user (101) (and the financial transactions of other users), a profile generator (121) to generate transaction profiles (127) based on the transaction data (109) to provide information/intelligence about user preferences and spending patterns, a point of interaction (107) to provide information and/or offers to the user (101), a user tracker (113) to generate user data (125) to identify the user (101) using the point of interaction (107), a profile selector (129) to select a profile (131) specific to the user (101) identified by the user data (125), and an advertisement selector (133) to select, identify, generate, adjust, prioritize and/or personalize advertisements for presentation to the user (101) on the point of interaction (107) via a media controller (115); Paragraph 0046, In one embodiment, a data warehouse (149) as illustrated in FIG. 4 is coupled with the transaction handler (103) to store the transaction data (109) and other data, such as account data (111), transaction profiles (127) and correlation results (123)).
Regarding claim 11 (Previously Presented), which is dependent of claim 10, the combination of Winters, Weiss et al., and Matiushin discloses all the limitations in claim 10. Winters further comprising receiving, from a third-party database, third party data associated with a consumer identifier, and wherein the wallet capacity is further based at least in part on the third-party data (Paragraph 0003, Millions of transactions occur daily through the use of payment cards, such as credit cards, debit cards, prepaid cards, etc. Corresponding records of the transactions are recorded in databases for settlement and financial recordkeeping (e.g., to meet the requirements of government regulations). Such data can be mined and analyzed for trends, statistics, and other analyses. Sometimes such data are mined for specific advertising goals, such as to provide targeted offers to account holders; Paragraph 0187, In one embodiment, the user specific profile (131) is an aggregated spending profile (341) that is generated using the SKU-level information. For example, in one embodiment, the factor values (344) correspond to factor definitions (331) that are generated based on aggregating spending in different categories of products and/or services. A typical merchant offers products and/or services in many different categories; Paragraph 0312, In one embodiment, a transaction handler is configured to combine customer tracking data with transaction data (109) to generate merchant statistics to compare customer spending habits across different merchants, such as comparing the customer spending pattern related to spending with one merchant and the customer spending pattern related to corresponding spending with the competitive peer set of the merchant; Examiner notes that credit card information is considered third party information).
Regarding claim 12 (Previously Presented), which is dependent of claim 8, the combination of Winters, Weiss et al., and Matiushin discloses all the limitations in claim 8. Although Winters discloses receiving consumer information from different sources to generate a wallet opportunity (Paragraphs 0055 & 0312, Survey and customer spending patterns with the competitive peer set of the merchant), Winters does not specifically disclose wherein the wallet opportunity is based on at least one assumption.
However, Weiss et al. discloses further comprising generating at least one assumption based on the user input, and wherein the wallet opportunity is based at least in part on the at least one assumption (Paragraph 0036, inform a business of promotions or advertisements that may entice consumers; Paragraph 0052, How to encourage consumers 102 to visit the coffee shop 122; Paragraph 0063, Purchase data may also be provided by consumers themselves, such as in responses to surveys. Businesses may obtain data about consumer purchases when the consumers provide to businesses personal information to associate the consumers with purchases. This may be the case when the consumers participate in programs (e.g., rewards or loyalty programs) with the businesses, such that the consumers identify themselves at the time they purchase goods or services. Similarly, financial companies may obtain information about consumer purchases when the consumers use credit cards, debit cards, checks, layaway programs, or other financial products to purchase goods or services; Paragraph 0092, The consumer analytics engine 208 may determine characteristics in any suitable manner. In some embodiments, the engine 208 may examine patterns in paths and/or anchors, and/or patterns in purchase data, to infer characteristics of a consumer 202; Examiner interprets “infer characteristics of a consumer” as “the at least on assumption”).
It would have been obvious to one ordinary skill in the art before the effective filing date to modify the method used for aggregating transaction data in real-time based on information received from multiple sources (e.g., POS transaction data and credit card transaction data) of the invention of Winters to further incorporate transmitting a request to the customer (e.g. survey) to obtain additional consumer transaction data of the invention of Weiss et al. because doing so would allow the method to produce inferences and/or predictions regarding the plurality of customers based at least in part on profile data (see Weiss et al., Paragraph 0009). Further, the claimed invention is merely a combination of old elements, and in combination each element would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Regarding claim 21 (Previously Presented), which is dependent of claim 1, the combination of Winters, Weiss et al., and Matiushin discloses all the limitations in claim 1. Winters further discloses wherein the at least one wallet data element is associated with a wallet capacity for the at least one good or service (Paragraph 0187, In one embodiment, the user specific profile (131) is an aggregated spending profile (341) that is generated using the SKU-level information. For example, in one embodiment, the factor values (344) correspond to factor definitions (331) that are generated based on aggregating spending in different categories of products and/or services. A typical merchant offers products and/or services in many different categories; Paragraph 0312, In one embodiment, a transaction handler is configured to combine customer tracking data with transaction data (109) to generate merchant statistics to compare customer spending habits across different merchants, such as comparing the customer spending pattern related to spending with one merchant and the customer spending pattern related to corresponding spending with the competitive peer set of the merchant; Examiner interprets the total amount spent in different categories at multiple retailers as the wallet capacity).
Regarding claim 22 (Previously Presented), which is dependent of claim 21, the combination of Winters, Weiss et al., and Matiushin discloses all the limitations in claim 21. Winters further discloses receiving into a digital wallet at least one attribute of each of a plurality of consumer-initiated transactions; and generating, based on the at least one attribute, a wallet share associated with the at least one good or service (Paragraph 0187, In one embodiment, the user specific profile (131) is an aggregated spending profile (341) that is generated using the SKU-level information. For example, in one embodiment, the factor values (344) correspond to factor definitions (331) that are generated based on aggregating spending in different categories of products and/or services. A typical merchant offers products and/or services in many different categories; Paragraph 0312, In one embodiment, a transaction handler is configured to combine customer tracking data with transaction data (109) to generate merchant statistics to compare customer spending habits across different merchants, such as comparing the customer spending pattern related to spending with one merchant and the customer spending pattern related to corresponding spending with the competitive peer set of the merchant).
Regarding claim 23 (Previously Presented), which is dependent of claim 22, the combination of Winters, Weiss et al., and Matiushin discloses all the limitations in claim 22. Winters further discloses determining, based at least in part on the wallet share and the wallet capacity associated with the at least one good or service, a wallet opportunity of the at least one good or service for the consumer (Paragraph 0053, For example, a third party strategic marketing analyst, statistician, marketer, promoter, business leader, etc., may access the centralized data warehouse (149) to analyze customer and shopper data, to provide follow-up analyses of customer contributions, to develop propensity models for increased conversion of marketing campaigns, to develop segmentation models for marketing, etc. The centralized data warehouse (149) can be used to manage advertisement campaigns and analyze response profitability; Paragraph 0187, In one embodiment, the user specific profile (131) is an aggregated spending profile (341) that is generated using the SKU-level information. For example, in one embodiment, the factor values (344) correspond to factor definitions (331) that are generated based on aggregating spending in different categories of products and/or services. A typical merchant offers products and/or services in many different categories; Paragraph 0201, In one embodiment, the SKU-level profile of the user (101) may reflect transactions with a particular merchant or merchants. The SKU-level profile of the user (101) may be provided to a business that is considered a peer with or similar to the particular merchant or merchants. For example, a merchant may be considered a peer of the business because the merchant offers goods and services that are similar to or related to those of the business. The SKU-level profile reflecting transactions with peer merchants may be used by the business to better predict the purchasing behavior of the user (101) and to optimize the presentation of targeted advertisements to the user (101); Paragraph 0312, In one embodiment, a transaction handler is configured to combine customer tracking data with transaction data (109) to generate merchant statistics to compare customer spending habits across different merchants, such as comparing the customer spending pattern related to spending with one merchant and the customer spending pattern related to corresponding spending with the competitive peer set of the merchant; Examiner interprets to provide advertisements to increase the share/month for a specific good or service as the wallet opportunity).
Regarding claim 24 (Previously Presented), which is dependent of claim 23, the combination of Winters, Weiss et al., and Matiushin discloses all the limitations in claim 23. Sweeney further discloses wherein the at least one offer is generated at least in part on the wallet opportunity (Paragraph 0053, For example, a third party strategic marketing analyst, statistician, marketer, promoter, business leader, etc., may access the centralized data warehouse (149) to analyze customer and shopper data, to provide follow-up analyses of customer contributions, to develop propensity models for increased conversion of marketing campaigns, to develop segmentation models for marketing, etc. The centralized data warehouse (149) can be used to manage advertisement campaigns and analyze response profitability; Paragraph 0187, In one embodiment, the user specific profile (131) is an aggregated spending profile (341) that is generated using the SKU-level information. For example, in one embodiment, the factor values (344) correspond to factor definitions (331) that are generated based on aggregating spending in different categories of products and/or services. A typical merchant offers products and/or services in many different categories; Paragraph 0201, In one embodiment, the SKU-level profile of the user (101) may reflect transactions with a particular merchant or merchants. The SKU-level profile of the user (101) may be provided to a business that is considered a peer with or similar to the particular merchant or merchants. For example, a merchant may be considered a peer of the business because the merchant offers goods and services that are similar to or related to those of the business. The SKU-level profile reflecting transactions with peer merchants may be used by the business to better predict the purchasing behavior of the user (101) and to optimize the presentation of targeted advertisements to the user (101); Paragraph 0312, In one embodiment, a transaction handler is configured to combine customer tracking data with transaction data (109) to generate merchant statistics to compare customer spending habits across different merchants, such as comparing the customer spending pattern related to spending with one merchant and the customer spending pattern related to corresponding spending with the competitive peer set of the merchant; Examiner interprets to provide advertisements to increase the share/month for a specific good or service as the wallet opportunity).
Claims 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over of Winters (US 2011/0231305 A1), in view of Matiushin (Matiushin, I. and Korkhov, V., 2021, July. Passwordless authentication using magic link technology. In CEUR Workshop Proceedings (Vol. 3041, pp. 434-438)).
Regarding claim 17 (Currently Amended), Winters discloses a computer-implemented method associated with a wallet steering program, the method comprising (Paragraph 0312, In one embodiment, a transaction handler is configured to combine customer tracking data with transaction data (109) to generate merchant statistics to compare customer spending habits across different merchants, such as comparing the customer spending pattern related to spending with one merchant and the customer spending pattern related to corresponding spending with the competitive peer set of the merchant; Paragraph 0315, The merchant can adjust the advertisement campaigns to improve performance relative to the activities of the peers of the merchant; Paragraph 0336, The spending pattern of one embodiment is a distribution among a set of merchants (e.g., the merchant, the competitors of the merchant and/or the partners of the merchant). In one embodiment, the purchases from the competitors of the merchant are aggregated as spending associated with the group of the competitors as an aggregated entity (e.g., a peer set); Applicant defines a “wallet steering program” as a particular business executing couponing or promotional campaign. Based on broadest reasonable interpretation in light of the specification, Winters discloses a “wallet steering program” since a promotional campaign (e.g., advertisement) is established based on purchase/transaction data):
receiving, during a transaction for a good or service, a consumer identifier; identifying a consumer member profile using the consumer identifier (Paragraph 0047, In FIG. 4, the transaction handler (103) is coupled between an issuer processor (145) in control of a consumer account (146) and an acquirer processor (147) in control of a merchant account (148). An account identification device (141) is configured to carry the account information (142) that identifies the consumer account (146) with the issuer processor (145) and provide the account information (142) to the transaction terminal (105) of a merchant to initiate a transaction between the user (101) and the merchant);
generating a first offer based at least in part on a wallet opportunity stored in the consumer member profile, the wallet opportunity based at least in part on a wallet capacity (Paragraph 0043, a profile generator (121) to generate transaction profiles (127) based on the transaction data (109) to provide information/intelligence about user preferences and spending patterns, a point of interaction (107) to provide information and/or offers to the user (101); Paragraph 0053, For example, a third party strategic marketing analyst, statistician, marketer, promoter, business leader, etc., may access the centralized data warehouse (149) to analyze customer and shopper data, to provide follow-up analyses of customer contributions, to develop propensity models for increased conversion of marketing campaigns, to develop segmentation models for marketing, etc. The centralized data warehouse (149) can be used to manage advertisement campaigns and analyze response profitability; Paragraph 0187, In one embodiment, the user specific profile (131) is an aggregated spending profile (341) that is generated using the SKU-level information. For example, in one embodiment, the factor values (344) correspond to factor definitions (331) that are generated based on aggregating spending in different categories of products and/or services. A typical merchant offers products and/or services in many different categories; Paragraph 0201, In one embodiment, the SKU-level profile of the user (101) may reflect transactions with a particular merchant or merchants. The SKU-level profile of the user (101) may be provided to a business that is considered a peer with or similar to the particular merchant or merchants. For example, a merchant may be considered a peer of the business because the merchant offers goods and services that are similar to or related to those of the business. The SKU-level profile reflecting transactions with peer merchants may be used by the business to better predict the purchasing behavior of the user (101) and to optimize the presentation of targeted advertisements to the user (101); Paragraph 0312, In one embodiment, a transaction handler is configured to combine customer tracking data with transaction data (109) to generate merchant statistics to compare customer spending habits across different merchants, such as comparing the customer spending pattern related to spending with one merchant and the customer spending pattern related to corresponding spending with the competitive peer set of the merchant; Examiner interprets to provide advertisements to increase the share/month for a specific good or service as the wallet opportunity);
causing to be displayed, on a user interface of a first merchant-controlled device, the first offer in response to the transaction for the good or service (Paragraph 0130, In another example, the transaction terminal (105) is a POS terminal at the checkout station in a retail store (e.g., a self-service checkout register). When the user (101) pays for a purchase via a payment card (e.g., a credit card or a debit card), the transaction handler (103) provides a targeted advertisement having a coupon obtained from an advertisement network. The user (101) may load the coupon into the account of the payment card and/or obtain a hardcopy of the coupon from the receipt. When the coupon is used in a transaction, the advertisement is linked to the transaction; Paragraph 0133, In one embodiment, when the user (101) is conducting a transaction with a first merchant via the transaction handler (103), the transaction handler (103) may determine whether the characteristics of the transaction satisfy the conditions specified for an announcement, such as an advertisement, offer or coupon, from a second merchant. If the conditions are satisfied, the transaction handler (103) provides the announcement to the user (101). In one embodiment, the transaction handler (103) may auction the opportunity to provide the announcements to a set of merchants. Examples and details related to the delivery of such announcements in one embodiment are provided in U.S. patent application Ser. No. 12/428,241, filed Apr. 22, 2009 and entitled "Targeting Merchant Announcements Triggered by Consumer Activity Relative to a Surrogate Merchant," the disclosure of which is hereby incorporated herein by reference; Paragraph 0275, In one embodiment, the transaction handler (103) is configured to identify or select offers based on real-time transactions or near real-time transactions (e.g., based on transactions occurring within a predetermined period of time, such as a few minutes, half an hour, one hour or a day). For example, based on the transaction data (109) the transaction handler (103) may determine related second purchases that are likely to occur in close proximity (e.g., in time or geographic location) to first purchases. Thus, at the time of the first purchases (or shortly after the first purchases), the offers related to the second purchases may be presented to the user (101) (e.g., via the transaction terminal (105), such as a self-assist checkout terminal, ATM, vending machine, gas pump, POS terminal, or the point of interaction (107), such as a web browser, mobile phone, receipt, electronic kiosk, etc.) to promote the second purchases; Paragraph 0257, FIGS. 11-14 illustrate user interfaces for multi channel offer redemption according to one embodiment);
ingesting, using an application programming interface (API), wallet data, wherein ingesting the wallet data comprises (Paragraph 0380, Similarly, the profile generator (121) may consolidate transaction data for a group of persons, after the group is identified by certain characteristics, such as gender, income level, geographical location or region, preference, characteristics of past purchases (e.g., merchant categories, purchase types), cluster, propensity, demographics, social networking characteristics (e.g., relationships, preferences, activities on social networking websites), etc. The consolidated transaction data can be used to derive intelligence information about the group to generate a profile for the group (e.g., transaction profiles (127), or the user specific profile (131)); Paragraph 0384, In one embodiment, the entity operating the transaction handler (103) provides the intelligence information in real-time as the request for the intelligence information occurs. In other embodiments, the entity operating the transaction handler (103) may provide the intelligence information in batch mode. The intelligence information can be delivered via online communications (e.g., via an application programming interface (API) on a website, or other information server), or via physical transportation of a computer readable media that stores the data representing the intelligence information):
receiving, through the API, a user input indicating at least a first wallet data element for the at least one good or service (Paragraph 0055, In one embodiment, the transaction data (109) is combined with external data, such as surveys, benchmarks, search engine statistics, demographics, competition information, emails, etc., to flag key events and data values, to set customer, merchant, data or event triggers, and to drive new transactions and new customer contacts; Paragraph 0384, In one embodiment, the entity operating the transaction handler (103) provides the intelligence information in real-time as the request for the intelligence information occurs. In other embodiments, the entity operating the transaction handler (103) may provide the intelligence information in batch mode. The intelligence information can be delivered via online communications (e.g., via an application programming interface (API) on a website, or other information server), or via physical transportation of a computer readable media that stores the data representing the intelligence information; Paragraph 0463, Once the clusters are standardized, the clusters can be used to link purchase information based merchant categories (and/or SKU numbers, product descriptions) with search information based on search terms; Examiner interprets the survey data for a specific product as the first wallet data element for the at least one good or service);
receiving, through the API and from a financial services company, at least a second wallet data element (Paragraph 0032, In one embodiment, the computing apparatus of, or associated with, the transaction handler (e.g., a processor of credit cards, debit cards, prepaid cards, etc.) is configured to provide information based on, or derived from, transactional data to enhance third party product offerings; Paragraph 0338, FIG. 23 shows a system to identify spending patterns according to one embodiment. In FIG. 23, users (101) can use the transaction terminal (105) to conduct payment transactions (e.g., using credit cards, debit cards, prepaid cards). The transaction handler (103) processes the transactions between the users (101) and merchants to generate the transaction data (109). The profile generator (121) can use the transaction data (109) and/or the account data (111) to generate (e.g., periodically) the transaction profiles (127) to characterize the spending patterns of the users (101); Paragraph 0384, In one embodiment, the entity operating the transaction handler (103) provides the intelligence information in real-time as the request for the intelligence information occurs. In other embodiments, the entity operating the transaction handler (103) may provide the intelligence information in batch mode. The intelligence information can be delivered via online communications (e.g., via an application programming interface (API) on a website, or other information server), or via physical transportation of a computer readable media that stores the data representing the intelligence information; Paragraph 0463, Once the clusters are standardized, the clusters can be used to link purchase information based merchant categories (and/or SKU numbers, product descriptions) with search information based on search terms; Examiner interprets data received from a credit card as the second wallet data element);
and receiving, through the API and from a third party data aggregator, at least a third wallet data element (Paragraph 0031, A computing apparatus of, or associated with, the transaction handler uses the transaction data and/or other data, such as account data, merchant data, search data, social networking data, web data, etc., to develop intelligence information about individual customers, or certain types or groups of customers; Paragraph 0056, In FIG. 1, the profile generator (121) generates transaction profiles (127) based on the transaction data (109), the account data (111), and/or other data, such as non-transactional data, wish lists, merchant provided information, address information, information from social network websites; Paragraph 0135, In a further example, the user (101) may visit a third party website, which is the point of interaction (107) in FIG. 1. The third party website may be a web search engine, a news website, a blog, a social network site, etc. The behavior of the user (101) at the third party website may be tracked via a browser cookie, which uses a storage space of the browser to store information about the user (101) at the third party website; Paragraph 0384, In one embodiment, the entity operating the transaction handler (103) provides the intelligence information in real-time as the request for the intelligence information occurs. In other embodiments, the entity operating the transaction handler (103) may provide the intelligence information in batch mode. The intelligence information can be delivered via online communications (e.g., via an application programming interface (API) on a website, or other information server), or via physical transportation of a computer readable media that stores the data representing the intelligence information; Paragraph 0463, Once the clusters are standardized, the clusters can be used to link purchase information based merchant categories (and/or SKU numbers, product descriptions) with search information based on search terms; Examiner interprets data received from a social network as the third wallet data element);
saving the at least a first data element, the at least a second data element, and the at least a third data element to a member profile database (Paragraph 0055, In one embodiment, the transaction data (109) is combined with external data, such as surveys, benchmarks, search engine statistics, demographics, competition information, emails, etc., to flag key events and data values, to set customer, merchant, data or event triggers, and to drive new transactions and new customer contacts; Paragraph 0056, In FIG. 1, the profile generator (121) generates transaction profiles (127) based on the transaction data (109), the account data (111), and/or other data, such as non-transactional data, wish lists, merchant provided information, address information, information from social network websites, information from credit bureaus, information from search engines, information about insurance claims, information from DNA databanks, and other examples discussed in U.S. patent application Ser. No. 12/614,603, filed Nov. 9, 2009 and entitled "Analyzing Local Non-Transactional Data with Transactional Data in Predictive Models," the disclosure of which is hereby incorporated herein by reference; Paragraph 0059, Some of the transaction profiles (127) are specific to the user (101), or to an account of the user (101), or to a group of users of which the user (101) is a member, such as a household, family, company, neighborhood, city, or group identified by certain characteristics related to online activities, offline purchase activities, merchant propensity, etc.; Paragraph 0466, n FIG. 1, the transaction terminal (105) initiates the transaction for a user (101) (e.g., a customer) for processing by a transaction handler (103). The transaction handler (103) processes the transaction and stores transaction data (109) about the transaction, in connection with account data (111), such as the account profile of an account of the user (101). The account data (111) may further include data about the user (101), collected from issuers or merchants, and/or other sources, such as social networks, credit bureaus, merchant provided information, address information, etc.);
on a condition the consumer identifier is received during a subsequent transaction for the good or service within a first predetermined period of time after the transaction, determining an updated wallet opportunity based on at least one of a quantity of the good or service or a cost associated with the good or service being purchased during the subsequent transaction and generating a second offer based at least in part on the updated wallet opportunity (Paragraph 0231, In one embodiment, the account information (142) is pre-stored in the account data (111) of the user (101). The portal (143) is to authenticate the identity of the user (101) in response to the user selection of the link to the portal (143). After the user (101) is identified via authentication, the data warehouse (149) stores the data to associate offer (186) with the account information (142) in the account data (111) of the user (101); Paragraph 0232, For example, in one embodiment, the portal (143) is to initially identify and authenticate the user (101) of the point of interaction (107) via a username and a password; Paragraph 0271, In some embodiments, the message (423) may include an advertisement which may present a new offer (e.g., selected based on a relationship with the current transaction). For example, based on past transactions, the transaction handler (103) may determine that, when the user (101) makes the current purchase, the likelihood of the user (101) to make a related purchase is higher than a threshold. Thus, to promote the related purchase, the transaction handler (103) may identify the new offer and transmit the new offer to the mobile phone (421) (e.g., with the notification message (423)). If the user (101) is interested in the new offer, the user (101) may select the new offer for storing in the account of the user (101) via the web portal (143). In some embodiments, the web portal (143) may include gateways for storing the offers via other communication channels, such as text message, email, etc.; Paragraph 0280, The unique code may be pre-associated with information about the advertisement that contains the offer (401), such as the identity of the website that presents the offer (401), the date and time of the presentation of the offer (401), the terms, conditions and benefits of the offer (401), etc. When the portion (403) is selected, the unique code is stored in the account to associate the information represented by the unique code with the account, which when used in a subsequent transaction that satisfies the terms and conditions of the offer (401) causes the automated redemption of the offer (401), as well as the linkage between the purchase and the information represented by the unique code);
…, authenticating the consumer and causing to be displayed, on the user computing device, at least one communication to the consumer, the at least one communication including the second offer (Paragraph 0183, The offers may be triggered by and/or tailored to a previous transaction, and may be valid only for a limited period of time starting from the date of the previous transaction. If the transaction handler (103) determines that a subsequent transaction processed by the transaction handler (103) meets the conditions for the redemption of an offer, the transaction handler (103) may credit the consumer account (146) for the redemption of the offer and/or provide a notification message to the user (101); Paragraph 0230, In one embodiment, when the link to the portal (143) is selected, the user (101) is to provide the account information (142) to the portal (143) via the point of interaction (107) to identify the consumer account (146) of the user (101). After both the consumer account (146) of the user (101) and the offer (186) are identified, the data warehouse (149) is to store the data to associate offer (186) with the account information (142) in the account data (111) of the user (101); Paragraph 0231, In one embodiment, the account information (142) is pre-stored in the account data (111) of the user (101). The portal (143) is to authenticate the identity of the user (101) in response to the user selection of the link to the portal (143). After the user (101) is identified via authentication, the data warehouse (149) stores the data to associate offer (186) with the account information (142) in the account data (111) of the user (101); Paragraph 0232, For example, in one embodiment, the portal (143) is to initially identify and authenticate the user (101) of the point of interaction (107) via a username and a password; Paragraph 0271, In some embodiments, the message (423) may include an advertisement which may present a new offer (e.g., selected based on a relationship with the current transaction). For example, based on past transactions, the transaction handler (103) may determine that, when the user (101) makes the current purchase, the likelihood of the user (101) to make a related purchase is higher than a threshold. Thus, to promote the related purchase, the transaction handler (103) may identify the new offer and transmit the new offer to the mobile phone (421) (e.g., with the notification message (423)). If the user (101) is interested in the new offer, the user (101) may select the new offer for storing in the account of the user (101) via the web portal (143). In some embodiments, the web portal (143) may include gateways for storing the offers via other communication channels, such as text message, email, etc.; Paragraph 0280, The unique code may be pre-associated with information about the advertisement that contains the offer (401), such as the identity of the website that presents the offer (401), the date and time of the presentation of the offer (401), the terms, conditions and benefits of the offer (401), etc. When the portion (403) is selected, the unique code is stored in the account to associate the information represented by the unique code with the account, which when used in a subsequent transaction that satisfies the terms and conditions of the offer (401) causes the automated redemption of the offer (401), as well as the linkage between the purchase and the information represented by the unique code; Examiner notes that Winters can keep track of offers provided to customers using known authentication techniques, wherein the customers can redeem those offers stored in their profile in subsequent transactions).
Winters discloses: generating offers based on the aggregated consumer profile transactional data; and techniques used to authenticate a consumer when the consumer is redeeming an offer (see Winters, Paragraph 0230, provide account information; Paragraph 0232, identify and authenticate the user (101) of the point of interaction (107) via a username and a password). Although Winters discloses authentication techniques to access a user account, Winters does not specifically disclose wherein the authentication technique includes a hyperlink containing a unique code (e.g., magic link).
However, Matiushin discloses transmitting, to a user computing device associated with the consumer identifier, a hyperlink containing a unique code; in response to receiving, via a user interface of the user computing device, a user input selecting the hyperlink, comparing the unique code contained in the hyperlink with a temporary unique code associated with the consumer identifier; and in response to the unique code contained in the hyperlink matching the temporary unique code with the consumer identifier, authenticating the consumer and causing to … (Pages 436-37, 3. Practical implementations, We have created a Keycloak magic link authentication module. The module allows the Keycloak administrator to set up e-mail-based passwordless authentication for a certain user, or a group of users. The authentication flow can be described as follows [4]: [Symbol font/0xB7] The user starts the authentication process [Symbol font/0xB7] The system requests the user’s e-mail address, which the user provides [Symbol font/0xB7] If the user doesn’t exist within the system’s database, a new user is created [Symbol font/0xB7] The system then generates a unique token for the magic link and forms the magic link [Symbol font/0xB7] The magic link URL is sent to the user’s e-mail [Symbol font/0xB7] The user clicks on the magic link and is redirected to the authentication page [Symbol font/0xB7] The system checks if the magic link is valid; if it is, the user successfully logs in. The authentication flow is shown in Figure 1).
PNG
media_image1.png
209
574
media_image1.png
Greyscale
It would have been obvious to one ordinary skill in the art before the effective filing date to modify the method used for generating and transmitting at least one offer based on the consumer member profile, wherein the offer can be subsequently redeemed by using an authentication technique (e.g., account information and/or a username and a password) of the invention of Winters to further incorporate other known authentication techniques of the invention of Matiushin because doing so would allow the method to authenticate the user using a magic link authentication process, which simplifies the process of registering new users and relieves them of the need to remember passwords (see Matiushin, Page 435, 1. Introduction & Page 436, 3. Practical implementations). Also, this is merely a simple substitution of a known technique used to authenticate users (e.g., account information and/or a username and a password) for another known technique used to authenticate users (e.g., magic link). The simple substitution of one known technique for another producing a predictable result renders the claim obvious.
Regarding claim 18 (Previously Presented), which is dependent of claim 17, the combination of Winters and Matiushin discloses all the limitations in claim 17. Winters further discloses wherein the first merchant-controlled device is distinct from the user computing device (Paragraph 0122, After the offer is downloaded to the transaction terminal (105), the transaction terminal (105) automatically applies the offer when the condition of the offer is satisfied in one embodiment; Paragraph 0130, In another example, the transaction terminal (105) is a POS terminal at the checkout station in a retail store (e.g., a self-service checkout register). When the user (101) pays for a purchase via a payment card (e.g., a credit card or a debit card), the transaction handler (103) provides a targeted advertisement having a coupon obtained from an advertisement network. The user (101) may load the coupon into the account of the payment card and/or obtain a hardcopy of the coupon from the receipt. When the coupon is used in a transaction, the advertisement is linked to the transaction; Paragraph 0133, In one embodiment, when the user (101) is conducting a transaction with a first merchant via the transaction handler (103), the transaction handler (103) may determine whether the characteristics of the transaction satisfy the conditions specified for an announcement, such as an advertisement, offer or coupon, from a second merchant. If the conditions are satisfied, the transaction handler (103) provides the announcement to the user (101); Paragraph 0267, Alternatively, the web portal (143) may allow the user (101) to retrieve the offers (e.g., via a mobile communication device, such as a cell phone) in an electronic form when the user (101) makes the purchase at the transaction terminal (105)).
Regarding claim 19 (Original), which is dependent of claim 17, the combination of Winters and Matiushin discloses all the limitations in claim 17. Winters further discloses wherein the first merchant-controlled device is a fuel dispenser (Paragraph 0275, In one embodiment, the transaction handler (103) is configured to identify or select offers based on real-time transactions or near real-time transactions (e.g., based on transactions occurring within a predetermined period of time, such as a few minutes, half an hour, one hour or a day). For example, based on the transaction data (109) the transaction handler (103) may determine related second purchases that are likely to occur in close proximity (e.g., in time or geographic location) to first purchases. Thus, at the time of the first purchases (or shortly after the first purchases), the offers related to the second purchases may be presented to the user (101) (e.g., via the transaction terminal (105), such as a self-assist checkout terminal, ATM, vending machine, gas pump, POS terminal, or the point of interaction (107), such as a web browser, mobile phone, receipt, electronic kiosk, etc.) to promote the second purchases).
Regarding claim 20 (Previously Presented), which is dependent of claim 17, the combination of Winters and Matiushin discloses all the limitations in claim 17. Winters further discloses wherein the first merchant-controlled device is a merchant point of sale device or an ordering device (Paragraph 0275, In one embodiment, the transaction handler (103) is configured to identify or select offers based on real-time transactions or near real-time transactions (e.g., based on transactions occurring within a predetermined period of time, such as a few minutes, half an hour, one hour or a day). For example, based on the transaction data (109) the transaction handler (103) may determine related second purchases that are likely to occur in close proximity (e.g., in time or geographic location) to first purchases. Thus, at the time of the first purchases (or shortly after the first purchases), the offers related to the second purchases may be presented to the user (101) (e.g., via the transaction terminal (105), such as a self-assist checkout terminal, ATM, vending machine, gas pump, POS terminal, or the point of interaction (107), such as a web browser, mobile phone, receipt, electronic kiosk, etc.) to promote the second purchases).
Claims 26-27 are rejected under 35 U.S.C. 103 as being unpatentable over Winters (US 2011/0231305 A1), in view of Weiss et al. (US 2011/0099046 A1), in further view of Matiushin (Matiushin, I. and Korkhov, V., 2021, July. Passwordless authentication using magic link technology. In CEUR Workshop Proceedings (Vol. 3041, pp. 434-438)) and Simon (US 2021/0027326 A1)
Regarding claims 26 and 27 (New), which are dependent of claims 1 and 8, the combination of Winters, Weiss et al., and Matiushin discloses all the limitations in claims 1 and 8. Although the combination of Winters and Weiss et al. discloses receiving consumer information from different sources to evaluate spending across all retailers (see Winters, Paragraphs 0055 & 0312, Survey and customer spending patterns with the competitive peer set of the merchant; see Weiss et al., Paragraphs 0063 & 0138, to perform a task such as completing a survey), the combination of Winters and Weiss et al. does not specifically disclose the wallet survey configuration.
However, Simon discloses receiving a wallet survey configuration from a first merchant wherein: the first merchant is associated with at least one of the at plurality of different point-of-sale devices; and the wallet survey configuration includes a survey type and a follow-up configuration; and causing to be displayed on a user interface of a computing device, a wallet survey for at least one good or service is a function of the consumer visiting the first merchant a first number of times and the wallet survey configuration (Paragraph 0020, According to some embodiments, the method may include receiving real-time, near-time, or batch survey feedback data from the one or more computing devices associated with the one or more consumers. Throughout this specification, references to “real-time” should be understood to include “near-time” and any time reasonably proximate with respect to the transaction and the survey or other request for feedback conducted thereupon; Paragraph 0046, In an exemplary operation, consumer feedback incentivizing service 102 may be configured to select a consumer to provide feedback related to one or more transactions associated with the consumer. Consumer feedback incentivizing service 102 may then select a survey comprising one or more questions related to the one or more transactions associated with the consumer. For example, consumer feedback incentivizing service 102 may communicate information about the selected consumer and/or transaction(s) to survey generation module 114. In some embodiments, the information communicated to survey generation module 114 about the consumer may include all or part of a stored consumer profile 118. According to some embodiments, survey generation module 114 may then match the consumer or attributes of the consumer with one or more surveys stored in database 116 of survey generation module 114 and transmit the one or more selected surveys back to consumer feedback incentivizing service 102; Paragraph 0047, According to some embodiments, consumer feedback incentivizing service 102 may transmit, for display on a computing device of the consumer, the one or more selected surveys related to the one or more transactions associated with the consumer. The computing device may broadly be any user-operated device having computing hardware; however, it should be understood that a typical implementation may include any device capable of operating wirelessly, such as a smartphone, tablet, laptop, Internet of Things (IoT) device, or desktop computer; According to some embodiments, consumer feedback incentivizing service 102 transmits one or more surveys to user device 128 for display, via client application 130 showing on a user interface (e.g., a touch screen or other standard computing interface) of user device 128; Paragraph 0070, Merchant preference data 306, according to some embodiments, may include any information provided by a merchant or merchants about a desired consumer that the merchant or merchants would like to have survey feedback data from; Paragraph 0081, After payment is completed, according to some embodiments, the user is presented with screen 504. Interface 508 presents, as an example, a survey question in the simple and familiar “star rating” format; Examiner interprets “presenting the survey after the payment is completed” as the “function of the consumer visiting the first merchant a first number of times.” In this case, Examiner interprets a preconfigured first number of times as one time).
It would have been obvious to one ordinary skill in the art before the effective filing date to modify the method used for aggregating transaction data in real-time based on information received from multiple sources (e.g., POS/merchant transaction data, credit card transaction data, and survey data) of the invention of Winters and Weiss et al. to further incorporate wherein the survey is provided to a consumer based on a merchant survey configuration of the invention of Simon because doing so would allow the method to present the user with a survey after one or more transactions associated with the costumer are completed (see Simon, Paragraphs 0046 & 0081). Further, the claimed invention is merely a combination of old elements, and in combination each element would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
Kruger et al. (US 2012/0150587 A1) – discloses an organization that collects data from a group of consumers (e.g., by survey or other mechanism by which consumers self-report their behavior) without necessarily selling to or buying from the consumers. One class of questions involves ascertaining, predicting, or otherwise modeling the propensity that a consumer or group of consumers will behave in a certain way. For example, one might want to know the propensity of a group of consumers to buy one brand of detergent vs. another brand, or the propensity to buy a high-end version of a product vs. a low-end version, or the propensity to buy a given product at all, or the propensity to spend at least a certain amount of money buying a certain type of product or products. Generally, one may inquire about consumers' propensity to engage in virtually any measurable behavior, which may be quantified as a propensity score or the like indicative of a tendency of a consumer or group of consumers to engage in a specific behavior. Gain insight into virtually any analytic question about consumer behaviors, including shared wallet estimation (see at least Paragraphs 0015, 0052, & 0063).
Friedman (Friedman, D.C., Brown, T.A. and Taran, Z., 2011. Specialty store expertise as a driver of satisfaction and share of wallet. The International Review of Retail, Distribution and Consumer Research, 21(4), pp.375-389) – discloses a survey was chosen to collect data and investigate the hypotheses. The customer mailing list came from a small Pennsylvania retailer of dance shoes and apparel. The survey included multiple choice and Likert-type scale questions on satisfaction, intent to purchase again, word of mouth intent, store employee experience, customer (own) expertise, customer demographics, share of wallet, total annual spending on the category, and an open ended question on desired store improvements (see Page 5, Methodology).
Bethke et al. (US 2017/0300910 A1) – discloses access control server 150 may authenticate the account holder 105 (step 235). The access control server 150 may authenticate the account holder 105 in response to the account holder 105 submitting a security credential input. For example, the access control server 150 may authenticate the account holder 105 by comparing the submitted username and password against a stored username and password in the directory server 140, by comparing the submitted access code against a stored access code, and/or through any other suitable authentication method. In response to authenticating the account holder 105 credentials, the access control server 150 may transmit an authentication result to the merchant server 115, via the merchant plug-in 130. The eligibility and fulfillment system 135 may fulfill an accepted value added offer (step 240). In response to the account holder 105 accepting the value added offer, the access control server 150 may communicate with the eligibility and fulfillment system 135 to fulfill the value added offer. For example, in various embodiments, an authorization amount associated with the purchase transaction may be modified in response to the account holder 105 accepting the value added offer (e.g., wherein the value added offer comprises using reward points, a rebate, etc.). Specifically, for example, the authorization amount may be reduced based by subtracting a value added offer amount, by applying a percent rebate to the authorization amount, and/or the like to generate a second authorization amount. The second authorization amount may be transmitted by the eligibility and fulfillment system 135 to the merchant server 115, via the merchant plug-in 130. In various embodiments, an acceptance of the value added offer may not directly impact the purchase transaction. For example, the value added offer may include an option to apply a reward balance or a credit to offset an outstanding balance on the corresponding account holder's account (see at least Paragraph 0047).
Sweeney (US 2019/0130479 A1) – discloses a chart 500 of a complete customer wallet 115 for a given customer Jill over a certain time period (month) is shown in accordance with an embodiment. Although a month is represented, it should be appreciated that the time frame could be longer or shorter, e.g., a week, a quarter, semi-annually, a year, etc. The use of a month is merely for purposes of clarity. Moreover, although a single customer 302 Jill is shown, it should be appreciated that the monthly customer wallet 115 could be generated for any or all of the other customers (e.g., Becky, John, CX, etc. as shown in partiality in FIG. 7). In one embodiment, customer wallet 115 includes transaction data for each transaction, such as but not limited to, customer 502, retailer 510, date 520, cost 530, item 540, and other 550 (see at least Paragraph 0070).
Kumar (Kumar, Y. and Kumar, D., 2020. Secure and Efficient Authentication and Authorization Mechanisms: An Exploration of 2fa, Passwordless Authentication, and Role-Based Access Control) – discloses in terms of passwordless authentication systems, biometrics and magic links are the most prominent and effective techniques. Magic links, on the other hand, provides an effortless and easy way of authentication via a one-time link that is sent to the email of the user. With this, people can log in effortlessly without needing a password. Hence, it will improve the convenience of the system as well as provide with a highly efficient login mechanism. Further, it will reduce the potential phishing threats in securing a password, since there is no password used during log in, making it a robust and secure authentication framework in the digital systems (see at least Page 1261).
Aamir (WO 2011/119974 A1) – discloses linked databases (104) to store customer data associated with a loyalty program of a retailer (114), and an interface to receive customer input. A processor allocates customized offer to the retailer account using the purchase history associated with the customer, and displays a page including customized offer and an option for selection of customized offer. The processor redeems the customized offer upon receiving a purchase notification specifying the retailer account associated with customer and product (see at least Abstract).
Halak (WO 0102991 A2) – discloses enticing and inducing customers purchasing one category of product to purchase other products from physically separated retailers. Broadens the customer's perception of a retailer's breadth of offerings from physically separated locations and facilities. Provides incentives for current customers of a retailer to use other retail facilities operated or promoted by the retailer (see at least Abstract).
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MARJORIE PUJOLS-CRUZ whose telephone number is (571)272-4668. The examiner can normally be reached Mon-Thru 7:30 AM - 5:00 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Patricia H Munson can be reached at (571)270-5396. 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.
/M.P./Examiner, Art Unit 3624 /PATRICIA H MUNSON/Supervisory Patent Examiner, Art Unit 3624