DETAILED ACTION
Claims 1-20 are presented for examination.
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 .
Claim Objections
Claims 3, 7, 11 and 17 are objected to because of the following informalities:
There is no antecedent basis for “the use case of the system” in lines 3-4 of claim 3. Instead, this phrase should likely say “the use case specific information” (referencing possible antecedent basis in independent claim 1).
There is no antecedent basis for “the use case of the method” in lines 3-4 of claim 7. Instead, this phrase should likely say “the use case specific information” (referencing possible antecedent basis in independent claim 5).
There is no antecedent basis for “the use case of the method” in lines 4-5 of claim 11. Instead, this phrase should likely say “the use case specific information” (referencing possible antecedent basis in independent claim 9).
Claim 17 recites “including comprises” in line 2, which seems to be redundant. Instead, only one of these words is likely needed.
Appropriate correction is required.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claimed invention is directed to “monitoring a user’s shopping behavior across multiple channels” (Spec: ¶ 2) without significantly more.
Step
Analysis
1: Statutory Category?
Yes – The claims fall within at least one of the four categories of patent eligible subject matter. Process (claims 5-8, 15, 18), Apparatus (claims 1-4, 14, 17, 20), Article of Manufacture (claims 6-13, 16, 19)
Independent claims:
Step
Analysis
2A – Prong 1: Judicial Exception Recited?
Yes – Aside from the additional elements identified in Step 2A – Prong 2 below, the claims recite:
[Claims 1, 5, 9] A system/method/operations to:
communicate with each of a plurality of customers;
store a plurality of customer identities of the plurality of customers in a database;
generate, in response to a purchase received from at least one of the plurality of customers, a transaction record having customer identity data;
identify a set of related customer identities from the customer identity data including one or more pairs of customer identities and each of the one or more pairs of customer identities includes one customer identity that is associated with one or more data elements that match one or more data elements of another customer identity;
convert each customer identity to edge data based on a connection type between the customer identities, the edge data identifying a period of validity for the customer identities;
convert each of the set of related customer identities to node data, the node data identifying a customer identity type based; and
generate use case specific information for each customer identity associated with the edge data and node data, said use case specific information including purchase information associated with the purchase.
A database may simply be a collection of data. “Automatically” may simply mean “in direct response to.”
Aside from the additional elements, the aforementioned claim details exemplify the abstract idea(s) of a mental process (since the details include concepts performed in the human mind, including an observation, evaluation, judgment, and/or opinion). As explained in MPEP § 2106(a)(2)(C)(III), “The courts consider a mental process (thinking) that ‘can be performed in the human mind, or by a human using a pen and paper’ to be an abstract idea. CyberSource Corp. v. Retail Decisions, Inc., 654 F.3d 1366, 1372, 99 USPQ2d 1690, 1695 (Fed. Cir. 2011). As the Federal Circuit explained, ‘methods which can be performed mentally, or which are the equivalent of human mental work, are unpatentable abstract ideas the ‘basic tools of scientific and technological work’ that are open to all.’’ 654 F.3d at 1371, 99 USPQ2d at 1694 (citing Gottschalk v. Benson, 409 U.S. 63, 175 USPQ 673 (1972)).” The limitations reproduced above, as drafted, are a process that, under its broadest reasonable interpretation, covers performance of the limitations in the mind but for the recitation of generic computer components. That is, other than reciting the additional elements identified in Step 2A – Prong 2 below, nothing in the claim elements precludes the steps from practically being performed in the mind and/or by a human using a pen and paper. For example, but for the recitations of generic computer and other processing components (identified in Step 2A – Prong 2 below), the respectively recited steps/functions of the claims, as drafted and set forth above, are a process that, under its broadest reasonable interpretation, covers performance of the limitations in the mind and/or with the use of pen and paper. A human user can gather information related to the purchase transactions of customers, create (generate) transaction records, convert various types of information, generate use case information, store information in databases, etc. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind (and/or with pen and paper) but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claims recite an abstract idea.
Aside from the additional elements, the aforementioned claim details exemplify a method of organizing human activity (since the details include examples of commercial or legal interactions, including advertising, marketing or sales activities or behaviors, and/or business relations and managing personal behavior or relationships or interactions between people, including social activities, teaching, and following rules or instructions). More specifically, the evaluated process is related to “monitoring a user’s shopping behavior across multiple channels” (Spec: ¶ 2), which (under its broadest reasonable interpretation) is an example of marketing and managing personal behavior and/or relationships between people (i.e., organizing human activity); therefore, aside from the recitations of generic computer and other processing components (identified in Step 2A – Prong 2 below), the limitations identified in the more detailed claim listing above encompass the abstract idea of organizing human activity.
2A – Prong 2: Integrated into a Practical Application?
No – The judicial exception(s) is/are not integrated into a practical application.
Claim 1 recites a system comprising:
a communications interface configured to communicate with a computing device of each of a plurality of customers, a plurality of computing systems associated with an online ordering system and an in-store terminal;
a database storing a plurality of customer identities of the plurality of customers associated with the online ordering system and the in-store terminal;
a memory having instructions stored thereon; and
a processor communicatively coupled to the database, the communications interface and the memory, the processor being configured to execute the instructions to perform the recited operations.
Claim 1 further recites that the step of generating a computer-readable transaction record having customer identity data is performed in response to a purchase received from the computing device of at least one of the plurality of customers.
Claim 5 recites a computer-implemented method comprising the recited steps. Claim 5 further recites storing, within a database, a plurality of customer identities of a plurality of customers associated with an online ordering system and an in-store terminal; generating, in response to a purchase received from a computing device of at least one of the plurality of customers, a computer-readable transaction record having customer identity data.
Claim 9 recites a non-transitory computer readable medium having instructions stored thereon, wherein the instructions, when executed by a processor cause a device to perform the recited operations.
Claim 9 further recites storing, within a database, a plurality of customer identities of a plurality of customers associated with an online ordering system and an in-store terminal; generating, in response to a purchase received from a computing device of at least one of the plurality of customers, a computer-readable transaction record having customer identity data.
The fact that transactions are associated with an online ordering system and an in-store terminal is an example of a general link to a field of use.
The claims as a whole merely describe how to generally “apply” the abstract idea(s) in a computer environment. The claimed processing elements are recited at a high level of generality and are merely invoked as a tool to perform the abstract idea(s). Simply implementing the abstract idea(s) on a general-purpose processor is not a practical application of the abstract idea(s); Applicant’s specification discloses that the invention may be implemented using general-purpose processing elements and other generic components (Spec: ¶¶ 26-31, 58-60).
The use of a processor/processing elements (e.g., as recited in all of the claims) facilitates generic processor operations. The use of a memory or machine-readable media with executable instructions facilitates generic processor operations.
The additional elements are recited at a high-level of generality (i.e., as generic processing elements performing generic computer functions) such that the incorporation of the additional processing elements amounts to no more than mere instructions to apply the judicial exception(s) using generic computer components. There is no indication in the Specification that the steps/functions of the claims require any inventive programming or necessitate any specialized or other inventive computer components (i.e., the steps/functions of the claims may be implemented using capabilities of general-purpose computer components). Accordingly, the additional elements do not integrate the abstract ideas into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claims are directed to an abstract idea(s).
The processing components presented in the claims simply utilize the capabilities of a general-purpose computer and are, thus, merely tools to implement the abstract idea(s). As seen in MPEP § 2106.05(a)(I) and § 2106.05(f)(2), the court found that accelerating a process when the increased speed solely comes from the capabilities of a general-purpose computer is not sufficient to show an improvement in computer-functionality and it amounts to a mere invocation of computers or machinery as a tool to perform an existing process (see FairWarning IP, LLC v. Iatric Sys., 839 F.3d 1089, 1095, 120 USPQ2d 1293, 1296 (Fed. Cir. 2016)).
There is no transformation or reduction of a particular article to a different state or thing recited in the claims.
Additionally, even when considering the operations of the additional elements as an ordered combination, the ordered combination does not amount to significantly more than what is present in the claims when each operation is considered separately.
2B: Claim(s) Provide(s) an Inventive Concept?
No – The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception(s). As discussed above with respect to integration of the abstract idea(s) into a practical application, the use of the additional elements to perform the steps identified in Step 2A – Prong 1 above amounts to no more than mere instructions to apply the exceptions using a generic computer component(s). Mere instructions to apply an exception using a generic computer component(s) cannot provide an inventive concept. The claims are not patent eligible.
Dependent claims:
Step
Analysis
2A – Prong 1: Judicial Exception Recited?
Yes – Aside from the additional elements identified in Step 2A – Prong 2 below, the claims recite:
[Claims 2, 6, 10] extract payment information from the transaction record;
normalize the payment information; and
apply a secure hash algorithm to the payment information to generate a secure identity token, wherein the secure identity token is a customer identity among the plurality of customer identities.
[Claims 3, 7, 11] generate a graph based on the plurality of customer identities that are related to a user;
retrieve a set of linkage rules, wherein the set of linkage rules retrieved is based on the use case of the system; and
apply the linkage rules to each customer identity in the graph and discard each customer identity that does not meet the set of linkage rules.
[Claims 4, 8, 12] store, in the database, one or more linkage rules including one or more use case criteria, the one or more use case criteria including a predefined attribute criterion for customer identities.
[Claim 13] wherein the plurality of customer identities link criteria comprise predefined links between different customer identities.
[Claims 14, 15, 16] wherein each customer identity type is associated with attributes that differ from attributes of other customer identity types, the attributes of the customer identity types differ in form, the period of validity, reliability, and security.
[Claims 17, 18, 19] store, in the database, one or more linkage rules including one or more use case criteria, the one or more use case criteria including comprises a predefined customer identity link criterion for customer identities.
[Claim 20] display a dynamic visual representation of the generated use case specific information, the dynamic visual representation including a purchase bar having a plurality of items from online purchases and in-store purchases of the generated use case specific information;
receive selection of a selected item of the plurality of items; and
upon receipt of the selection, automatically re-purchase the selected item.
The dependent claims further present details of the abstract ideas identified in regard to the independent claims.
A database may simply be a collection of data. “Automatically” may simply mean “in direct response to.”
Aside from the additional elements, the aforementioned claim details exemplify the abstract idea(s) of a mental process (since the details include concepts performed in the human mind, including an observation, evaluation, judgment, and/or opinion). As explained in MPEP § 2106(a)(2)(C)(III), “The courts consider a mental process (thinking) that ‘can be performed in the human mind, or by a human using a pen and paper’ to be an abstract idea. CyberSource Corp. v. Retail Decisions, Inc., 654 F.3d 1366, 1372, 99 USPQ2d 1690, 1695 (Fed. Cir. 2011). As the Federal Circuit explained, ‘methods which can be performed mentally, or which are the equivalent of human mental work, are unpatentable abstract ideas the ‘basic tools of scientific and technological work’ that are open to all.’’ 654 F.3d at 1371, 99 USPQ2d at 1694 (citing Gottschalk v. Benson, 409 U.S. 63, 175 USPQ 673 (1972)).” The limitations reproduced above, as drafted, are a process that, under its broadest reasonable interpretation, covers performance of the limitations in the mind but for the recitation of generic computer components. That is, other than reciting the additional elements identified in Step 2A – Prong 2 below, nothing in the claim elements precludes the steps from practically being performed in the mind and/or by a human using a pen and paper. For example, but for the recitations of generic computer and other processing components (identified in Step 2A – Prong 2 below), the respectively recited steps/functions of the claims, as drafted and set forth above, are a process that, under its broadest reasonable interpretation, covers performance of the limitations in the mind and/or with the use of pen and paper. A human user can gather information related to the purchase transactions of customers, create (generate) transaction records, convert various types of information, generate use case information, store information in databases, etc. A human user can also extract and normalize payment information as well as apply a hash algorithm (claims 2, 6, 10). A human user can create a graph, receive linkage rules, and apply the linkage rules to the graphs (claims 3, 7, 11). A human user can create a database of linkage rules (claims 4, 8, 12). If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind (and/or with pen and paper) but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claims recite an abstract idea.
Aside from the additional elements, the aforementioned claim details exemplify a method of organizing human activity (since the details include examples of commercial or legal interactions, including advertising, marketing or sales activities or behaviors, and/or business relations and managing personal behavior or relationships or interactions between people, including social activities, teaching, and following rules or instructions). More specifically, the evaluated process is related to “monitoring a user’s shopping behavior across multiple channels” (Spec: ¶ 2), which (under its broadest reasonable interpretation) is an example of marketing and managing personal behavior and/or relationships between people (i.e., organizing human activity); therefore, aside from the recitations of generic computer and other processing components (identified in Step 2A – Prong 2 below), the limitations identified in the more detailed claim listing above encompass the abstract idea of organizing human activity.
2A – Prong 2: Integrated into a Practical Application?
No – The judicial exception(s) is/are not integrated into a practical application.
The dependent claims include the additional elements of their independent claims.
Claim 1 recites a system comprising:
a communications interface configured to communicate with a computing device of each of a plurality of customers, a plurality of computing systems associated with an online ordering system and an in-store terminal;
a database storing a plurality of customer identities of the plurality of customers associated with the online ordering system and the in-store terminal;
a memory having instructions stored thereon; and
a processor communicatively coupled to the database, the communications interface and the memory, the processor being configured to execute the instructions to perform the recited operations.
Claim 1 further recites that the step of generating a computer-readable transaction record having customer identity data is performed in response to a purchase received from the computing device of at least one of the plurality of customer.
Claim 20 recites wherein said system is configured to:
display, on a user interface, a dynamic visual representation of the generated use case specific information, the dynamic visual representation including a purchase bar having a plurality of items from online purchases and in-store purchases of the generated use case specific information;
receive, via the user interface, selection of a selected item of the plurality of items from the purchase bar; and
upon receipt of the selection, automatically re-purchase the selected item.
Claim 5 recites a computer-implemented method comprising the recited steps. Claim 5 further recites storing, within a database, a plurality of customer identities of a plurality of customers associated with an online ordering system and an in-store terminal; generating, in response to a purchase received from a computing device of at least one of the plurality of customers, a computer-readable transaction record having customer identity data.
Claim 9 recites a non-transitory computer readable medium having instructions stored thereon, wherein the instructions, when executed by a processor cause a device to perform the recited operations.
Claim 9 further recites storing, within a database, a plurality of customer identities of a plurality of customers associated with an online ordering system and an in-store terminal; generating, in response to a purchase received from a computing device of at least one of the plurality of customers, a computer-readable transaction record having customer identity data.
The fact that transactions are associated with an online ordering system and an in-store terminal is an example of a general link to a field of use. The ability to make an online purchase (e.g., as recited in claim 20) is also an example of a general link to technology and to a field of use.
The claims as a whole merely describe how to generally “apply” the abstract idea(s) in a computer environment. The claimed processing elements are recited at a high level of generality and are merely invoked as a tool to perform the abstract idea(s). Simply implementing the abstract idea(s) on a general-purpose processor is not a practical application of the abstract idea(s); Applicant’s specification discloses that the invention may be implemented using general-purpose processing elements and other generic components (Spec: ¶¶ 26-31, 58-60).
The use of a processor/processing elements (e.g., as recited in all of the claims) facilitates generic processor operations. The use of a memory or machine-readable media with executable instructions facilitates generic processor operations.
The additional elements are recited at a high-level of generality (i.e., as generic processing elements performing generic computer functions) such that the incorporation of the additional processing elements amounts to no more than mere instructions to apply the judicial exception(s) using generic computer components. There is no indication in the Specification that the steps/functions of the claims require any inventive programming or necessitate any specialized or other inventive computer components (i.e., the steps/functions of the claims may be implemented using capabilities of general-purpose computer components). Accordingly, the additional elements do not integrate the abstract ideas into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claims are directed to an abstract idea(s).
The processing components presented in the claims simply utilize the capabilities of a general-purpose computer and are, thus, merely tools to implement the abstract idea(s). As seen in MPEP § 2106.05(a)(I) and § 2106.05(f)(2), the court found that accelerating a process when the increased speed solely comes from the capabilities of a general-purpose computer is not sufficient to show an improvement in computer-functionality and it amounts to a mere invocation of computers or machinery as a tool to perform an existing process (see FairWarning IP, LLC v. Iatric Sys., 839 F.3d 1089, 1095, 120 USPQ2d 1293, 1296 (Fed. Cir. 2016)).
There is no transformation or reduction of a particular article to a different state or thing recited in the claims.
Additionally, even when considering the operations of the additional elements as an ordered combination, the ordered combination does not amount to significantly more than what is present in the claims when each operation is considered separately.
2B: Claim(s) Provide(s) an Inventive Concept?
No – The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception(s). As discussed above with respect to integration of the abstract idea(s) into a practical application, the use of the additional elements to perform the steps identified in Step 2A – Prong 1 above amounts to no more than mere instructions to apply the exceptions using a generic computer component(s). Mere instructions to apply an exception using a generic computer component(s) cannot provide an inventive concept. The claims are not patent eligible.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-19 are rejected under 35 U.S.C. 103 as being unpatentable over Zhou et al. (US 2018/0212931) in view of Achan et al. (US 2014/0358742) in view of Prabhu et al. (US 2017/0061428).
[Claim 1] Zhou discloses a system (fig. 9) comprising:
a communications interface configured to communicate with a computing device of each of a plurality of customers (fig. 1; ¶ 15 – “FIG. 1 is a system environment including one or more client devices 110 connected through a network 120 to an online system 130. The online system 130 may include a user login module 150, a content presentation module 160, and a user sync module 300. Additionally, a partner system 140 may also be connected to the network 120 to communicate with the one or more client device 110 and the online system 130. The partner system 140 may also include a user activity module 200.”; ¶ 22 – “monitor users visiting the websites that have not opted out of tracking”), a plurality of computing systems associated with an online ordering system (¶ 15 – online system) and an offline terminal (fig. 3; ¶ 36 – “FIG. 3 illustrates a flow diagram of the user sync module 300 of the online system 130, in accordance with one embodiment. In various embodiments, the user sync module 300 receives information from the partner system 140 through a tracking pixel placed on the web page of the partner system 140 or via an app event from a mobile application of the partner system.”; ¶ 19 – “The partner system 140 represents any external system outside of the online system 130. For example, the partner system 140 may be a third party retailer that sells products of interest to users.”);
a database storing a plurality of customer identities of the plurality of customers associated with the online ordering system and the offline terminal (¶ 23 – “The online system 130 includes a user login module 150, a content presentation module 160, and a user sync module 300. The user login module 150 may receive, from a client device 110, a user login request that includes the user's identifier (e.g. online system user ID) and a user password associated with the online system user ID. If the user provides a correct pairing of an online system user ID and password, the online system 130 provides content, such as a user profile, of the online system 130 to the client device 110.”; ¶ 36 – “In other embodiments, the user sync module 300 receives information from the partner system 140 in response to a request for a stored cookie. The information may be stored in a cookie on the browser and includes identifiers 230 associated with the user that performed the user action, the user action performed by the user on the partner system 140, and/or hashed PII 225 that may be used to identify the user. The user sync module 300 uses the identifiers 230 and/or the hashed PII 225 to sync user activity on a partner system 140 to a user profile that is associated with the user on the online system 130.”);
a memory having instructions stored thereon (¶¶ 58-60); and
a processor communicatively coupled to the database, the communications interface and the memory, the processor being configured to execute the instructions (¶¶ 58-60) to:
generate, in response to a purchase received from the computing device of at least one of the plurality of customers, a computer-readable transaction record having customer identity data (¶ 20 – “In various embodiments, the partner system 140 includes a user activity module 200 that handles the activity generated by a user on the web page of the partner system 140. For example, the user activity module 200 manages the activity of a user on a web page of the partner system 140 such as the purchases made by a user for one or more products of the partner system 140. As the user completes the purchase process, the user activity module 200 receives PII belonging to the user (e.g. name, shipping address, billing address, email, phone number, other contact information). In some cases, if the user has already logged onto the partner system 140, the partner system will have already associated the user with a user account and certain PII stored for the user. Additionally, the user activity module 200 may associate the PII of the user with a user-specific login identifier to the partner system 140 (e.g. a user's partner system ID).”; ¶ 21 – “In various embodiments, the user activity module 200 stores this information including the PII and/or the user's partner system ID. Additional information associated with the user may include the user's browsing history (e.g. user actions). More specifically, the user activity module 200 may store the information as a cookie on the user's browser. Therefore, if the user returns to the web page of the partner system 140 in the future, the partner system 140 can retrieve the user's partner system ID and PII of the user from the stored cookie such that a user purchase can proceed rapidly without having to reenter information.”);
identify a set of related customer identities from the customer identity data including one or more pairs of customer identities and each of the one or more pairs of customer identities includes one customer identity that is associated with one or more data elements that match one or more data elements of another customer identity (¶ 26 – “The online system 130 maintains a social graph made up of nodes and edges. The nodes represent objects in the online system 130 such as a user profile associated with a user of the online system 130. Additionally, a node may be represented by a profile page of a partner system 140. The online system 130 connects two nodes together using edges when there is an association between the two nodes. For example, a user of the online system 130 may purchase products from a partner system 140. The online system 130 receives this information through a stored cookie and creates an edge between the node representing the user and a node representing the partner system 140 to indicate that an association between the two nodes occurred.”; ¶ 40 – “The user identification module 315 identifies a user of the online system 130 that performed the user action 235 on a web page of the partner system 140 based on the hashed PII 225. For example, the user identification module 315 may receive a hashed email address that originated from the partner system 140 and a hashed email address generated by the information hashing module 310 and compares the two to determine whether there is a match. Each hashed email address may be a fixed-length, e.g., 128 bits. Therefore, the user identification module 315 applies an individual bit by bit comparison between the two hashed email addresses. In various embodiments, if one or more bits differ between the two hashed emailed addresses, the user identification module 315 deems the comparison a non-match. When every bit between the two hashed email addresses is determined to be a match, then the comparison is deemed a match. The user identification module 315 may apply this comparison for any type of hashed PII including, but not limited to, the user's first name, user's last name, phone number, address (billing or shipping), business address, and business name. Thus, the user identification module 315 identifies a user of the online system 130 based on this comparison.”; ¶ 41 – “In various embodiments, the user identification module 315 generates a confidence score (e.g. between 0-100) that reflects a strength of certainty that the identified user of the online system 130 is truly the individual that performed the user action 235 on a web page of the partner system 140. The confidence score is dependent on the comparison between the hashed PII and the hashed personal information from a user profile. For example, the received hashed PII from the partner system 140 may only include a user's hashed email address. The user identification module 315 may compare the user's hashed email address but detect that more than one bit differs. Therefore, the user identification module 315 may assign a score of 0 to the comparison between the hashed email address from the partner system 140 and the hashed email address of the user. Alternatively, if the user identification module 315 successfully identifies a matching hashed email address in a user profile, then the user identification module 315 may assign a score of 75 (out of 100), indicating a high likelihood that the user associated with that user profile likely performed the user action 235 on the web page of the partner system 140.”; ¶ 60 – “Embodiments of the invention may also relate to a product that is produced by a computing process described herein. Such a product may comprise information resulting from a computing process, where the information is stored on a non-transitory, tangible computer readable storage medium and may include any embodiment of a computer program product or other data combination described herein.”);
convert each customer identity to edge data based on a connection type between the customer identities (¶ 26 – “The online system 130 maintains a social graph made up of nodes and edges. The nodes represent objects in the online system 130 such as a user profile associated with a user of the online system 130. Additionally, a node may be represented by a profile page of a partner system 140. The online system 130 connects two nodes together using edges when there is an association between the two nodes. For example, a user of the online system 130 may purchase products from a partner system 140. The online system 130 receives this information through a stored cookie and creates an edge between the node representing the user and a node representing the partner system 140 to indicate that an association between the two nodes occurred.”; ¶¶ 40-41 – Conditions to verify a match of users/user identities.);
convert each of the set of related customer identities to node data, the node data identifying a customer identity type based (¶ 26 – “The online system 130 maintains a social graph made up of nodes and edges. The nodes represent objects in the online system 130 such as a user profile associated with a user of the online system 130. Additionally, a node may be represented by a profile page of a partner system 140. The online system 130 connects two nodes together using edges when there is an association between the two nodes. For example, a user of the online system 130 may purchase products from a partner system 140. The online system 130 receives this information through a stored cookie and creates an edge between the node representing the user and a node representing the partner system 140 to indicate that an association between the two nodes occurred.”).
Zhou does not explicitly disclose that its offline transactions (i.e., transactions performed while a purchaser is logged out) are transactions performed at an in-store terminal. Achan maps in-store transactions of a customer to the profiles of online customers based on certain attributes (Achan: abstract – “Example systems and methods for mapping in-store transactions to customer profiles are described. In one implementation, a method receives information of a plurality of customer profiles of a plurality of online customers. Each of the customer profiles includes a plurality of types of attributes associated with a respective one of the online customers. The types of attributes include a first type of attribute. The method also receives information of a plurality of in-store transactions by a plurality of in-store customers. The information of each of the in-store transactions includes the first type of attribute associated with the respective in-store customer. The method further maps, for at least one of the in-store customers, one or more of the customer profiles of online customers to the at least one of the in-store customers based at least in part on the first type of attribute.”). Achan’s in-store transactions are akin to Zhou’s external transactions since both are performed outside of the main tracking capabilities for internal transactions, yet they are mapped to one of multiple possible customer profiles based on attributes correlated to the internal transactions and customer profiles. Also like Zhou, Achan maps out attributes using nodes and edges of social graphs (Achan: figs. 2-5A). The Examiner submits that it would have been obvious to one of ordinary skill in the art before the effective filing date of Applicant’s invention to modify Zhou such that its offline transactions (i.e., transactions performed while a purchaser is logged out) are transactions performed at an in-store terminal because “[g]iven that in-store transactions contribute towards the majority of sales for a brick-and-mortar business, the task of identifying retail store customers of the brick-and-mortar business with high fidelity is fundamental towards any attempt to obtaining a unified view of customers and their transactions” (as explained by Achan: ¶ 16).
Zhou does not explicitly disclose the edge data identifying a period of validity for the customer identities or generate use case specific information for each customer identity associated with the edge data and node data, said use case specific information including purchase information associated with the purchase. Prabhu issues tokens for online or offline payments (Prabhu: ¶ 37) and a token may be given a limited time of use (Prabhu: ¶ 38 – “A token service provider may issue a token and define a set of parameters surrounding the token, may be specifically deic, which can restrict or permit the access and use of the token. One or more parameters of the set of parameters may include, but are not limited to, a card network (e.g., the name of a credit card company's network); a time to live, which is the period from the moment of issuance until the token expires or is no longer valid (e.g., 30 seconds, 1 minute, 8 hours, 2 days, 1 year, etc.); scheme/BIN (e.g., debit, credit, prepaid, or token); currency accepted (e.g., US dollars, Euro, Canadian dollar, Vietnamese dong, etc.); merchant type (MCC) (e.g., digital goods , travel, online retail store, etc.); merchant information, which may include a choice of merchant preferences such as funding sources, brands, closed loop, dollar limits, etc.; merchant location, which may be the country in which the merchant is registered (e.g., United States or Canada), terminal location (e.g., Global Positioning System coordinates or registered card reader terminal location), or whether the merchant is online only or offline only; consumer location radius (e.g., GPS coordinates of the user's mobile device); security features (e.g., cryptogram required or step-up authentication required); routing mechanism (e.g., open or closed loop); type of interaction, which may include funding (e.g., private label credit card (PLCC), points, cards, or banks), identity (e.g., access to hotel, gym or car or other environments that need identity verification), and contextual information (e.g., address, etc.); and amount (e.g., the amount that can be used for payment authorization using the token).”). A common ID may be used to represent a relationship between a user and a commerce partner for a specific funding instrument and “[t]he exact combination or configuration differs by use case and is driven by product design and business need” (Prabhu: ¶ 46). Based on the particular attributes, a transaction risk level may be determined, including based on attributes gleaned from a social graph, and the transaction risk level may affect how the transaction may be performed (Prabhu: ¶¶ 57-74). A token may also be replaced with a Cryptogram to provide additional security (Prabhu: ¶ 67). The risk levels and corresponding transaction requirements may be viewed as use cases. The attributes of a transaction (like a user being in a foreign country and the validation requirements to confirm a user’s identity in light of the given scenario) may also present use cases. The Examiner submits that it would have been obvious to one of ordinary skill in the art before the effective filing date of Applicant’s invention to modify Zhou with the edge data identifying a period of validity for the customer identities and to generate use case specific information for each customer identity associated with the edge data and node data, said use case specific information including purchase information associated with the purchase in order to establish appropriate transaction conditions in light of the identified transaction risk level, thereby protecting all parties involved in a transaction (as suggested in ¶¶ 67, 70, 74 of Prabhu).
[Claim 2] Zhou does not explicitly disclose wherein the processor is configured to execute the instructions further to:
extract payment information from the transaction record;
normalize the payment information; and
apply a secure hash algorithm to the payment information to generate a secure identity token, wherein the secure identity token is a customer identity among the plurality of customer identities.
Prabhu determines an amount that is authorized for payment with a token by (in effect) extracting information related to the token (Prabhu: ¶ 38), including maximum limits based on local regulations (Prabhu: ¶ 42). A user requests transaction completion, which includes a transaction amount (Prabhu: ¶¶ 65-66, 80). The risk associated with a transaction may affect how the transaction is completed (Prabhu: ¶ 74). The token has an associated format (Prabhu: ¶ 45), which implies at least a basic level of normalization of information associated with the token, including the transaction amount information. In Prabhu, a token may also be replaced with a Cryptogram to provide additional security (Prabhu: ¶ 67). While Prabhu does not explicitly apply a secure hash algorithm to the payment information to generate a secure identity token, wherein the secure identity token is a customer identity among the plurality of customer identities, Zhou states, “In various embodiments, the received hashed PII 225 may have undergone an encryption process instead of hashing. Therefore, the information hashing module 310 may receive associated information that provides instructions as to how to de-encrypt the PII. Thus, the information hashing module 310 de-encrypts the received PII and provides the de-encrypted PII to the user identification module 315 to identify a user of the online system 130.” (Zhou: ¶ 39) In other words, hashing may be used in conjunction with or in lieu of encryption. Hashing is another means of maintaining the security of information. For example, Zhou explains that “[t]he personal information hasher module 215 receives the user's PII and proceeds to encrypt or hash the information to protect the privacy of the user.” (Zhou: ¶ 32) Increased security and protection of private information are achieved by encryption and by hashing regardless of the nature of the data content itself. The Examiner submits that it would have been obvious to one of ordinary skill in the art before the effective filing date of Applicant’s invention to modify Zhou wherein the processor is configured to execute the instructions further to:
extract payment information from the transaction record;
normalize the payment information; and
apply a secure hash algorithm to the payment information to generate a secure identity token, wherein the secure identity token is a customer identity among the plurality of customer identities
in order to establish appropriate transaction conditions in light of the identified transaction risk level, thereby protecting all parties involved in a transaction (as suggested in ¶¶ 67, 70, 74 of Prabhu) while layering in options for increased security and protection of private information, like transaction information, payment information, and customer identity information.
[Claim 3] Zhou discloses wherein said system is configured to:
generate a graph based on the plurality of customer identities that are related to a user (¶ 26 – “The online system 130 maintains a social graph made up of nodes and edges. The nodes represent objects in the online system 130 such as a user profile associated with a user of the online system 130. Additionally, a node may be represented by a profile page of a partner system 140. The online system 130 connects two nodes together using edges when there is an association between the two nodes. For example, a user of the online system 130 may purchase products from a partner system 140. The online system 130 receives this information through a stored cookie and creates an edge between the node representing the user and a node representing the partner system 140 to indicate that an association between the two nodes occurred.”; ¶ 40 – “The user identification module 315 identifies a user of the online system 130 that performed the user action 235 on a web page of the partner system 140 based on the hashed PII 225. For example, the user identification module 315 may receive a hashed email address that originated from the partner system 140 and a hashed email address generated by the information hashing module 310 and compares the two to determine whether there is a match. Each hashed email address may be a fixed-length, e.g., 128 bits. Therefore, the user identification module 315 applies an individual bit by bit comparison between the two hashed email addresses. In various embodiments, if one or more bits differ between the two hashed emailed addresses, the user identification module 315 deems the comparison a non-match. When every bit between the two hashed email addresses is determined to be a match, then the comparison is deemed a match. The user identification module 315 may apply this comparison for any type of hashed PII including, but not limited to, the user's first name, user's last name, phone number, address (billing or shipping), business address, and business name. Thus, the user identification module 315 identifies a user of the online system 130 based on this comparison.”; ¶ 41 – “In various embodiments, the user identification module 315 generates a confidence score (e.g. between 0-100) that reflects a strength of certainty that the identified user of the online system 130 is truly the individual that performed the user action 235 on a web page of the partner system 140. The confidence score is dependent on the comparison between the hashed PII and the hashed personal information from a user profile. For example, the received hashed PII from the partner system 140 may only include a user's hashed email address. The user identification module 315 may compare the user's hashed email address but detect that more than one bit differs. Therefore, the user identification module 315 may assign a score of 0 to the comparison between the hashed email address from the partner system 140 and the hashed email address of the user. Alternatively, if the user identification module 315 successfully identifies a matching hashed email address in a user profile, then the user identification module 315 may assign a score of 75 (out of 100), indicating a high likelihood that the user associated with that user profile likely performed the user action 235 on the web page of the partner system 140.”; ¶ 60 – “Embodiments of the invention may also relate to a product that is produced by a computing process described herein. Such a product may comprise information resulting from a computing process, where the information is stored on a non-transitory, tangible computer readable storage medium and may include any embodiment of a computer program product or other data combination described herein.”); and
applying the linkage rules to each customer identity in the graph and discarding each customer identity that does not meet the set of linkage rules (¶ 41 – “In various embodiments, the user identification module 315 generates a confidence score (e.g. between 0-100) that reflects a strength of certainty that the identified user of the online system 130 is truly the individual that performed the user action 235 on a web page of the partner system 140. The confidence score is dependent on the comparison between the hashed PII and the hashed personal information from a user profile. For example, the received hashed PII from the partner system 140 may only include a user's hashed email address. The user identification module 315 may compare the user's hashed email address but detect that more than one bit differs. Therefore, the user identification module 315 may assign a score of 0 to the comparison between the hashed email address from the partner system 140 and the hashed email address of the user.” In other words, a confidence score of 0 is understood to identify a non-matching user to be excluded.).
Zhou does not explicitly disclose retrieving a set of linkage rules, wherein the set of linkage rules retrieved is based on the use case of the system. Prabhu issues tokens for online or offline payments (Prabhu: ¶ 37) and a token may be given a limited time of use (Prabhu: ¶ 38 – “A token service provider may issue a token and define a set of parameters surrounding the token, may be specifically deic, which can restrict or permit the access and use of the token. One or more parameters of the set of parameters may include, but are not limited to, a card network (e.g., the name of a credit card company's network); a time to live, which is the period from the moment of issuance until the token expires or is no longer valid (e.g., 30 seconds, 1 minute, 8 hours, 2 days, 1 year, etc.); scheme/BIN (e.g., debit, credit, prepaid, or token); currency accepted (e.g., US dollars, Euro, Canadian dollar, Vietnamese dong, etc.); merchant type (MCC) (e.g., digital goods , travel, online retail store, etc.); merchant information, which may include a choice of merchant preferences such as funding sources, brands, closed loop, dollar limits, etc.; merchant location, which may be the country in which the merchant is registered (e.g., United States or Canada), terminal location (e.g., Global Positioning System coordinates or registered card reader terminal location), or whether the merchant is online only or offline only; consumer location radius (e.g., GPS coordinates of the user's mobile device); security features (e.g., cryptogram required or step-up authentication required); routing mechanism (e.g., open or closed loop); type of interaction, which may include funding (e.g., private label credit card (PLCC), points, cards, or banks), identity (e.g., access to hotel, gym or car or other environments that need identity verification), and contextual information (e.g., address, etc.); and amount (e.g., the amount that can be used for payment authorization using the token).”). A common ID may be used to represent a relationship between a user and a commerce partner for a specific funding instrument and “[t]he exact combination or configuration differs by use case and is driven by product design and business need” (Prabhu: ¶ 46). Based on the particular attributes, a transaction risk level may be determined, including based on attributes gleaned from a social graph, and the transaction risk level may affect how the transaction may be performed (Prabhu: ¶¶ 57-74). A token may also be replaced with a Cryptogram to provide additional security (Prabhu: ¶ 67). The risk levels and corresponding transaction requirements may be viewed as use cases. The attributes of a transaction (like a user being in a foreign country and the validation requirements to confirm a user’s identity in light of the given scenario) may also present use cases. The Examiner submits that it would have been obvious to one of ordinary skill in the art before the effective filing date of Applicant’s invention to modify Zhou to perform the step of retrieving a set of linkage rules, wherein the set of linkage rules retrieved is based on the use case of the system in order to establish appropriate transaction conditions in light of the identified transaction risk level, thereby protecting all parties involved in a transaction (as suggested in ¶¶ 67, 70, 74 of Prabhu).
[Claim 4] Zhou does not explicitly disclose wherein the database stores one or more linkage rules including one or more use case criteria, the one or more use case criteria including a predefined attribute criterion for customer identities. Prabhu issues tokens for online or offline payments (Prabhu: ¶ 37) and a token may be given a limited time of use (Prabhu: ¶ 38 – “A token service provider may issue a token and define a set of parameters surrounding the token, may be specifically deic, which can restrict or permit the access and use of the token. One or more parameters of the set of parameters may include, but are not limited to, a card network (e.g., the name of a credit card company's network); a time to live, which is the period from the moment of issuance until the token expires or is no longer valid (e.g., 30 seconds, 1 minute, 8 hours, 2 days, 1 year, etc.); scheme/BIN (e.g., debit, credit, prepaid, or token); currency accepted (e.g., US dollars, Euro, Canadian dollar, Vietnamese dong, etc.); merchant type (MCC) (e.g., digital goods , travel, online retail store, etc.); merchant information, which may include a choice of merchant preferences such as funding sources, brands, closed loop, dollar limits, etc.; merchant location, which may be the country in which the merchant is registered (e.g., United States or Canada), terminal location (e.g., Global Positioning System coordinates or registered card reader terminal location), or whether the merchant is online only or offline only; consumer location radius (e.g., GPS coordinates of the user's mobile device); security features (e.g., cryptogram required or step-up authentication required); routing mechanism (e.g., open or closed loop); type of interaction, which may include funding (e.g., private label credit card (PLCC), points, cards, or banks), identity (e.g., access to hotel, gym or car or other environments that need identity verification), and contextual information (e.g., address, etc.); and amount (e.g., the amount that can be used for payment authorization using the token).”). A common ID may be used to represent a relationship between a user and a commerce partner for a specific funding instrument and “[t]he exact combination or configuration differs by use case and is driven by product design and business need” (Prabhu: ¶ 46). Based on the particular attributes, a transaction risk level may be determined, including based on attributes gleaned from a social graph, and the transaction risk level may affect how the transaction may be performed (Prabhu: ¶¶ 57-74). A token may also be replaced with a Cryptogram to provide additional security (Prabhu: ¶ 67). The risk levels and corresponding transaction requirements may be viewed as use cases. The attributes of a transaction (like a user being in a foreign country and the validation requirements to confirm a user’s identity in light of the given scenario) may also present use cases. The Examiner submits that it would have been obvious to one of ordinary skill in the art before the effective filing date of Applicant’s invention to modify Zhou wherein the database stores one or more linkage rules including one or more use case criteria, the one or more use case criteria including a predefined attribute criterion for customer identities in order to establish appropriate transaction conditions in light of the identified transaction risk level, thereby protecting all parties involved in a transaction (as suggested in ¶¶ 67, 70, 74 of Prabhu).
[Claim 14] Zhou does not explicitly disclose wherein each customer identity type is associated with attributes that differ from attributes of other customer identity types, the attributes of the customer identity types differ in form, the period of validity, reliability, and security.
Prabhu identifies users based on:
attributes that differ from attributes of other customer identity types (Prabhu: ¶ 32 – “ By using information provided by the user on a social media website, it may be unnecessary to request information from the user. For example, rather than ask the user where she lives (e.g., United States), this information may be readily available on her social media profile. In this example, if the user attempts a transaction while in another country (e.g., in India), this transaction may be identified as a high-risk transaction in terms of transaction location. If, however, the user has posted on her social media profile that she is in India along with a photograph of herself in front of the Taj Mahal, the transaction may be identified as a low-risk transaction in terms of transaction location. Additionally, rather than ask the user where she works, this information may be readily available on her social media profile. The likelihood of a user telling the truth on her profile in terms of such information may be perceived as high. Additionally, rather than ask the user her date of birth, this information may be readily available on her social media profile because her friends are wishing her a happy birthday on her social media profile.” Trustworthiness and level of risk are distinguishing customer-related attributes and they can be measured with varying approaches, such as by comparing location to a social media profile.),
the attributes of the customer identity types differ in form (Prabhu: ¶ 32 – “ By using information provided by the user on a social media website, it may be unnecessary to request information from the user. For example, rather than ask the user where she lives (e.g., United States), this information may be readily available on her social media profile. In this example, if the user attempts a transaction while in another country (e.g., in India), this transaction may be identified as a high-risk transaction in terms of transaction location. If, however, the user has posted on her social media profile that she is in India along with a photograph of herself in front of the Taj Mahal, the transaction may be identified as a low-risk transaction in terms of transaction location. Additionally, rather than ask the user where she works, this information may be readily available on her social media profile. The likelihood of a user telling the truth on her profile in terms of such information may be perceived as high. Additionally, rather than ask the user her date of birth, this information may be readily available on her social media profile because her friends are wishing her a happy birthday on her social media profile.” Trustworthiness and level of risk are distinguishing customer-related attributes and they can be measured with varying approaches, such as by comparing location to a social media profile.),
the period of validity (Prabhu: ¶ 38 – “A token service provider may issue a token and define a set of parameters surrounding the token, may be specifically deic, which can restrict or permit the access and use of the token. One or more parameters of the set of parameters may include, but are not limited to, a card network (e.g., the name of a credit card company's network); a time to live, which is the period from the moment of issuance until the token expires or is no longer valid (e.g., 30 seconds, 1 minute, 8 hours, 2 days, 1 year, etc.); scheme/BIN (e.g., debit, credit, prepaid, or token); currency accepted (e.g., US dollars, Euro, Canadian dollar, Vietnamese dong, etc.); merchant type (MCC) (e.g., digital goods , travel, online retail store, etc.); merchant information, which may include a choice of merchant preferences such as funding sources, brands, closed loop, dollar limits, etc.; merchant location, which may be the country in which the merchant is registered (e.g., United States or Canada), terminal location (e.g., Global Positioning System coordinates or registered card reader terminal location), or whether the merchant is online only or offline only; consumer location radius (e.g., GPS coordinates of the user's mobile device); security features (e.g., cryptogram required or step-up authentication required); routing mechanism (e.g., open or closed loop); type of interaction, which may include funding (e.g., private label credit card (PLCC), points, cards, or banks), identity (e.g., access to hotel, gym or car or other environments that need identity verification), and contextual information (e.g., address, etc.); and amount (e.g., the amount that can be used for payment authorization using the token).”; ¶ 41 – “In another example, the scope of the token may be based on the preference(s) of the token service provider. The token service provider may modify the scope of a token to maximize the meeting or exceeding of business objectives or business needs (e.g., lower cost, lower risk, higher revenue, etc.). For example, the token service provider may issue a token with a more favorable interchange to merchants or partners based on preferred pricing details. In another example, if a consumer desires to pay with a closed loop gift card, the token service provider may issue a click fee based token to save on interchange. In another example, for a high risk merchant category or consumer, the token service provider may decline issuance of the token itself based on past behavior of the consumer.”),
reliability (Prabhu: ¶ 33 – “A trusted framework may be created based on the information associated with users based on their social media profiles to more accurately identify users and their habits. Additionally, the more connections the user has to other users (e.g., friends on FACEBOOK), the higher the user's reliability score may be. This information may be used in electronic commerce to prevent fraud and high-risk activities.”), and
security (Prabhu: ¶ 38 – “security features (e.g., cryptogram required or step-up authentication required)”; ¶ 67 – “Accordingly, companies may be able to adopt techniques disclosed in the present disclosure without modifying their systems. In some examples, the token is replaced with a Cryptogram to provide additional security.”; ¶ 73 – “In some examples, the token service provider provides the token to the website, which provides it to the third-party merchant, to be used at most once. The token identifier, expiration date, and security context may be interpreted by the merchant and processed accordingly. If the merchant or website attempts to use the token a second time, the token service provider may fail the transaction and send the website an error message.”).
The Examiner submits that it would have been obvious to one of ordinary skill in the art before the effective filing date of Applicant’s invention to modify Zhou wherein each customer identity type is associated with attributes that differ from attributes of other customer identity types, the attributes of the customer identity types differ in form, the period of validity, reliability, and security in order to establish appropriate transaction conditions in light of the identified transaction risk level, thereby protecting all parties involved in a transaction (as suggested in ¶¶ 67, 70, 74 of Prabhu).
[Claim 17] Zhou does not explicitly disclose wherein the database stores one or more linkage rules including one or more use case criteria, the one or more use case criteria including comprises a predefined customer identity link criterion for customer identities. Prabhu issues tokens for online or offline payments (Prabhu: ¶ 37) and a token may be given a limited time of use (Prabhu: ¶ 38 – “A token service provider may issue a token and define a set of parameters surrounding the token, may be specifically deic, which can restrict or permit the access and use of the token. One or more parameters of the set of parameters may include, but are not limited to, a card network (e.g., the name of a credit card company's network); a time to live, which is the period from the moment of issuance until the token expires or is no longer valid (e.g., 30 seconds, 1 minute, 8 hours, 2 days, 1 year, etc.); scheme/BIN (e.g., debit, credit, prepaid, or token); currency accepted (e.g., US dollars, Euro, Canadian dollar, Vietnamese dong, etc.); merchant type (MCC) (e.g., digital goods , travel, online retail store, etc.); merchant information, which may include a choice of merchant preferences such as funding sources, brands, closed loop, dollar limits, etc.; merchant location, which may be the country in which the merchant is registered (e.g., United States or Canada), terminal location (e.g., Global Positioning System coordinates or registered card reader terminal location), or whether the merchant is online only or offline only; consumer location radius (e.g., GPS coordinates of the user's mobile device); security features (e.g., cryptogram required or step-up authentication required); routing mechanism (e.g., open or closed loop); type of interaction, which may include funding (e.g., private label credit card (PLCC), points, cards, or banks), identity (e.g., access to hotel, gym or car or other environments that need identity verification), and contextual information (e.g., address, etc.); and amount (e.g., the amount that can be used for payment authorization using the token).”). A common ID may be used to represent a relationship between a user and a commerce partner for a specific funding instrument and “[t]he exact combination or configuration differs by use case and is driven by product design and business need” (Prabhu: ¶ 46). Based on the particular attributes, a transaction risk level may be determined, including based on attributes gleaned from a social graph, and the transaction risk level may affect how the transaction may be performed (Prabhu: ¶¶ 57-74). A token may also be replaced with a Cryptogram to provide additional security (Prabhu: ¶ 67). The risk levels and corresponding transaction requirements may be viewed as use cases. The attributes of a transaction (like a user being in a foreign country and the validation requirements to confirm a user’s identity in light of the given scenario) may also present use cases. The Examiner submits that it would have been obvious to one of ordinary skill in the art before the effective filing date of Applicant’s invention to modify Zhou wherein the database stores one or more linkage rules including one or more use case criteria, the one or more use case criteria including comprises a predefined customer identity link criterion for customer identities in order to establish appropriate transaction conditions in light of the identified transaction risk level, thereby protecting all parties involved in a transaction (as suggested in ¶¶ 67, 70, 74 of Prabhu).
[Claims 5-8, 15, 18] Claims 5-8, 15, and 18 recite limitations already addressed by the rejections of claims 1-4, 14, and 17 above; therefore, the same rejections apply.
[Claims 9-13, 16, 19] Claims 9-13, 16, and 19 recite limitations already addressed by the rejections of claims 1-4, 14, and 17 above; therefore, the same rejections apply.
Furthermore, Zhou discloses a non-transitory computer readable medium having instructions stored thereon, wherein the instructions, when executed by a processor cause a device to perform the disclose operations (Zhou: ¶¶ 58-60).
Regarding claim 13, Zhou discloses wherein the plurality of customer identities link criteria comprise predefined links between different customer identities (Zhou: ¶¶ 26, 40-41).
Claims 20 is rejected under 35 U.S.C. 103 as being unpatentable over Zhou et al. (US 2018/0212931) in view of Achan et al. (US 2014/0358742) in view of Prabhu et al. (US 2017/0061428), as applied to claim 1, in view of Blank et al. (US 2012/0191565).
[Claim 20] Zhou does not explicitly disclose wherein said system is configured to:
display, on a user interface, a dynamic visual representation of the generated use case specific information, the dynamic visual representation including a purchase bar having a plurality of items from online purchases and in-store purchases of the generated use case specific information;
receive, via the user interface, selection of a selected item of the plurality of items from the purchase bar; and
upon receipt of the selection, automatically re-purchase the selected item.
Blank discloses a system (Blank: ¶¶ 70-71) configured to:
display, on a user interface, a dynamic visual representation of the generated use case specific information, the dynamic visual representation including a purchase bar having a plurality of items from online purchases and in-store purchases of the generated use case specific information (Blank: ¶ 34 – “Further, with embodiments, a receipt program can generate digital receipts that are adaptive or dynamic in that they can be changed or updated to reflect merchant inventory or item availability such that consumers know which merchants offer the specific item to be purchased again and are not required to spend time searching in-store and on-line for the item. This can be particularly helpful in cases in which consumers want to purchase a specific item again but the specific item has been discontinued or has limited or availability.”; ¶ 45 – “Embodiments may involve consumer 235 purchasing various items 212, goods and services (G/S) (generally "items" 212) from various types of merchants 215. References to an "item" 212 are defined to include goods and services, and references to purchasing item 212 from a "merchant" 215 are defined to include purchases from in-store or brick and mortar merchants, from websites 217 of merchants 215 who also have stores, and from on-line merchants 215 that sell items 212 through respective websites 217 or other on-line or electronic methods or channels. For example, merchant 215 may offer items 212 in stores and on-line (e.g. merchants 215 such as MACYS, TARGET and HOME DEPOT) whereas other merchants 215 are on-line merchants such as AMAZON and EBAY. Payment may be made using a transaction card (e.g., credit card, debit card, gift card, etc.), check, cash and other forms of payment. Further, at the time of payment, a consumer 235 membership or club card can be entered or scanned by merchant 215 such that transaction data 216 transmitted from merchant 215 to host identifies consumer 235 as making the purchase.”; ¶ 55 – “Receipt program 221 will eventually access table 500 to identified merchant 215 that offers item 212 for sale, and will have to select one or multiple merchants 215 for this purpose. According to one embodiment, the order of merchants 215 to be selected is prioritized such that when merchant 215 is to be identified as offering a certain item 212 for sale, certain merchants 215 will be identified whereas others are not or identified first or more frequently than other merchants 215. For example, according to one embodiment, pre-determined prioritization criteria includes whether consumer 235 purchased item 212 from merchant 215 in the past, and if so, then that merchant 215 is identified or identified first and has priority over other merchants 215. As another example, if consumer 235 purchased the same item 216 from multiple merchants, pre-determined criteria may be the most recent purchase such that the merchant 215 from whom consumer 235 has purchased item 212 most recently is identified, identified first or identified more frequently than other merchants. Pre-determined criteria may also involve a number of times consumer 235 has purchased the item 212 from each merchant 215. Pre-determined criteria may also involve a combination of these and/or other factors.”; fig. 13B --
PNG
media_image1.png
876
1046
media_image1.png
Greyscale
);
receive, via the user interface, selection of a selected item of the plurality of items from the purchase bar (Blank: fig. 13B; ¶ 64 – “According to a further embodiment, consumer 235 clicks on input element 226 and is then directed to a website 217 in which item 212 is already added to an electronic shopping cart and the page includes a "purchase" button that may be clicked or selected by consumer 235 to purchase item 212. Thus, embodiments can be configured such that consumer 235 can purchase the item 212 again with a single click of input element 226 or a single click of a purchase button within a screen or page of website 217 to which consumer was directed as a result of clicking input element 226. In yet another embodiment, clicking input element 226 is a request to purchase item 212 again with no further navigation required such that 1-click repurchase is possible from digital receipt 223.”); and
upon receipt of the selection, automatically re-purchase the selected item (Blank: fig. 13B – “BUY IT AGAIN”; ¶ 64 – “According to a further embodiment, consumer 235 clicks on input element 226 and is then directed to a website 217 in which item 212 is already added to an electronic shopping cart and the page includes a "purchase" button that may be clicked or selected by consumer 235 to purchase item 212. Thus, embodiments can be configured such that consumer 235 can purchase the item 212 again with a single click of input element 226 or a single click of a purchase button within a screen or page of website 217 to which consumer was directed as a result of clicking input element 226. In yet another embodiment, clicking input element 226 is a request to purchase item 212 again with no further navigation required such that 1-click repurchase is possible from digital receipt 223.”).
The Examiner submits that it would have been obvious to one of ordinary skill in the art before the effective filing date of Applicant’s invention to modify Zhou wherein said system is configured to:
display, on a user interface, a dynamic visual representation of the generated use case specific information, the dynamic visual representation including a purchase bar having a plurality of items from online purchases and in-store purchases of the generated use case specific information;
receive, via the user interface, selection of a selected item of the plurality of items from the purchase bar; and
upon receipt of the selection, automatically re-purchase the selected item
in order to facilitate a more convenient shopping experience for users. As explained in Blank, “Further, with embodiments, a receipt program can generate digital receipts that are adaptive or dynamic in that they can be changed or updated to reflect merchant inventory or item availability such that consumers know which merchants offer the specific item to be purchased again and are not required to spend time searching in-store and on-line for the item. This can be particularly helpful in cases in which consumers want to purchase a specific item again but the specific item has been discontinued or has limited or availability.” (Blank: ¶ 34)
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Bax et al. (US 2015/0347591) – Identifies matching users from multiple graphs and normalizes fields before hashing.
Dhawan et al. (US 2017/0169455) – Links customers in an influence graph.
Banerjee et al. (US 2018/0196694) – Generates graph-oriented data structures to identify relationships between pairs of users.
Davis et al. (US 2013/0191887) – Authenticates transactions based on relationships among users.
Lipshitz et al. (US 2017/0053347) – Identifies key persons of an entity.
Aggarwal (US 2012/0054129) – Classifies objects using labels and edges in a graph.
Faith et al. (US 2013/0246215) – Correlates entities using a social graph.
Smith et al. (US 2017/0249660) – Validates the identity of a user.
Bar et al. (US 2016/0180442) – Makes recommendations for purchase (including for repeat purchases) based on on-line and in-store activity.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SUSANNA M DIAZ whose telephone number is (571)272-6733. The examiner can normally be reached M-F, 8 am-4:30 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, Brian Epstein can be reached at (571) 270-5389. 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.
/SUSANNA M. DIAZ/
Primary Examiner
Art Unit 3625A