DETAILED ACTION
This communication is a Non-Final Office Action rejection on the merits. Claims 1-20 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 .
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that use the word “means” or “step” but are nonetheless not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph because the claim limitations recite sufficient structure, materials, or acts to entirely perform the recited function. Such claim limitations are: a script management module, wherein the script management module manages a number of vendor-specific scripts; a user identification module, wherein the user identification module uniquely identifies visitors to a network and associate each identified visitor with a unique identifier; an activity tracking module, wherein the activity tracking module monitors activities of visitors and leads identified by the user identification module; a suppression module, wherein the suppression module receives and determines suppression information relating to a user corresponding to user records stored in a user database; an attribution module, wherein the attribution module associates purchases or abandoned purchases made by leads at the network location with a provider of the service based on predetermined attribution criteria; and a reporting module, wherein the reporting module transmits or displays some or all user information contained in one or more of the user records via one or more reports, notifications, alerts, webhooks, or API calls … in claims 1-20.
Because these claim limitations are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, they are not being interpreted to cover only the corresponding structure, material, or acts described in the specification as performing the claimed function, and equivalents thereof.
If applicant intends to have these limitations interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to remove the structure, materials, or acts that performs the claimed function; or (2) present a sufficient showing that the claim limitation(s) does/do not recite sufficient structure, materials, or acts to perform the claimed function.
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 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, the claim 1 is directed to an apparatus which is a statutory category.
Step 2A, Prong One - Claim 1 recites: A system for user identification and monitoring, the system comprising to: identify visitors to a website or other network location, wherein identifying visitors to the website or other network locations includes: manages a number of vendor-specific scripts; uniquely identifies visitors to a network based on a user’s selection to opt in for one or more promotions and associate each identified visitor with a unique identifier; monitors activities of visitors identified; receives and determines suppression information relating to a user corresponding to user records; associates an abandoned eCommerce cart made by the visitor at a network location with a provider of a service based on predetermined attribution criteria; and transmits or displays some or all user information contained in one or more of the user records. 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, “monitoring activities of users based on the identified user” is considered “sales activities or behaviors” (e.g., tracking purchases/activities made by the visitors at a website by collecting user information from multiple sources). 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; a plurality of user devices and applications; a script management module; a user identification module; an activity tracking module; a suppression module; a user database; an attribution module; a reporting module; and via one or more reports, notifications, alerts, webhooks, or API calls.
The processor is merely used to execute instructions (Paragraph 0126). The memory is merely used to store instructions (Paragraph 0129). The plurality of user devices and application are merely used to interact with electronic content provided by a vendor at a network location (Paragraph 0035). The script management module is merely used to employ vendor-specific scripts (e.g., JavaScript files) or other software components installed at a network location to collect and report data and events back to one or more databases (Paragraph 0046). The user identification module is merely used to uniquely identify visitors to a network location and to associate identified visitors (i.e., leads) with unique identifiers linked to characteristics of the web browser (Paragraph 0049). The activity tracking module is merely used to monitor activities of visitors and leads identified by the identification module (Paragraph 0051). The suppression module is merely used to generate suppression records associated with user records, which inform the service that a user's information should not be shared with a vendor (Paragraph 0057). The user database is merely used to store user records (Paragraph 0057). The attribution module is merely used to associate purchases or abandoned purchases made by leads at the network location with a provider of the service based on predetermined attribution criteria (Paragraph 0062). The reporting module is merely used to aggregate, summarize, analyze, and/or format user information associated with any number of leads and facilitate the sharing of such information (Paragraph 0064). The one or more reports, notifications, alerts, webhooks, or API calls is merely used to transmit or display some or all user information contained in one or more of the user records (Paragraph 0005). Merely stating that the step is performed by a computer component results in “apply it” on a computer (MPEP 2106.05f). Those elements 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 activity tracking module is considered “insignificant extra-solution activity” (MPEP 2106.05g) since it’s just “mere data gathering” to use it for analyzing purchases across multiple devices (MPEP 2106.05g). 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 claim is 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 identifying visitors to a website or other network location across a plurality of user devices and applications. The specification shows that the processor is merely used to execute instructions (Paragraph 0126). The memory is merely used to store instructions (Paragraph 0129). The plurality of user devices and application are merely used to interact with electronic content provided by a vendor at a network location (Paragraph 0035). The script management module is merely used to employ vendor-specific scripts (e.g., JavaScript files) or other software components installed at a network location to collect and report data and events back to one or more databases (Paragraph 0046). The user identification module is merely used to uniquely identify visitors to a network location and to associate identified visitors (i.e., leads) with unique identifiers linked to characteristics of the web browser (Paragraph 0049). The activity tracking module is merely used to monitor activities of visitors and leads identified by the identification module (Paragraph 0051). The suppression module is merely used to generate suppression records associated with user records, which inform the service that a user's information should not be shared with a vendor (Paragraph 0057). The user database is merely used to store user records (Paragraph 0057). The attribution module is merely used to associate purchases or abandoned purchases made by leads at the network location with a provider of the service based on predetermined attribution criteria (Paragraph 0062). The reporting module is merely used to aggregate, summarize, analyze, and/or format user information associated with any number of leads and facilitate the sharing of such information (Paragraph 0064). The one or more reports, notifications, alerts, webhooks, or API calls is merely used to transmit or display some or all user information contained in one or more of the user records (Paragraph 0005). Also, the activity tracking module is considered a conventional computer function of “receiving or transmitting data over a network” and “performing repetitive calculations” (MPEP 2106.05d). Thus, nothing in the claim adds significantly more to the abstract idea. The claim is ineligible.
Independent claim 11 is directed to a method at step 1, which is a statutory category. Claim 11 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. Therefore, the claim is not patent eligible.
Dependent claims 2-4 and 12-14 are not directed to any additional claim elements. Rather, these claims describe further functions performed by the script management module - such as to: manage configuration settings and data supporting the one or more vendor-specific scripts; and generate a unique script for each vendor. Merely stating that the step is performed by a computer component results in “apply it” on a computer (MPEP 2106.05f) being applicable at both Step 2A, Prong 2 and Step 2B. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. Thus, nothing in the claim adds significantly more to the abstract idea. The claim is ineligible.
Dependent claims 5-6 and 15-16 are not directed to any additional claim elements. Rather, these claims describe further functions performed by the user identification module - such as to: determine a subset of the received user information and match the subset of the received user information; and create the user record corresponding to the unique identifier. Merely stating that the step is performed by a computer component results in “apply it” on a computer (MPEP 2106.05f) being applicable at both Step 2A, Prong 2 and Step 2B. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. Thus, nothing in the claim adds significantly more to the abstract idea. The claim is ineligible.
Dependent claims 7-9 and 17-19 are not directed to any additional claim elements. Rather, these claims describe further functions performed by the activity tracking module - such as to: track visits to a network location, and use and conversion activities performed by a user; associate the visit, use, and conversion information with the corresponding user record; and identify and track activities performed by the user based on one or more predetermined events. The main functions are merely used to: collect data (e.g., track activities performed by the user) and analyze the data (e.g., associate the visit, use, and conversion information with the corresponding user record). 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)). Thus, nothing in the claim adds significantly more to the abstract idea. The claim is ineligible.
Dependent claims 10 and 20 are not directed to any additional claim elements. Rather, these claims describe further functions performed by the reporting module - such as to: determine aggregate information across a user population. The main functions are merely used to: collect data (e.g., activities performed by the user) and analyze the data (e.g., aggregate information across a user population). 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)). Thus, nothing in the claim adds significantly more to the abstract idea. The claim is ineligible.
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-20 are rejected under 35 U.S.C. 103 as being unpatentable over Hust et al. (US 9,972,023 B1), in view of Frederick et al. (US 2020/0211080 A1), in further view of Francis et al (US 2021/0241351 A1).
Regarding claim 1, Hust et al. discloses a system for user identification and monitoring, the system comprising (Abstract, An e-commerce system is provided that tracks purchase transaction across multiple client devices; Column 2, lines 12-20, When a customer's client device is referred to a vendor's website via advertising on an affiliate's website, the customer activity information for the customer is updated. By storing the customer activity information at the marketplace server rather than on a cookie at the customer's client device, the marketplace server can accurately monitor or track the affiliates involved in transactions with vendors even if those transactions occurred using multiple client devices that are associated with the customer; Column 5, lines 4-28, Furthermore, each device record 203 comprises one or more fingerprints that represent the client device 105 associated with the device record 203. A fingerprint for a client device 105 may be used to identify the client device 105 if the client device 105 lacks a cookie with a device ID):
a processor; a memory; and instructions stored on the memory, the instructions, when executed by the processor, cause the processor to (Column 4, lines 23-28, In one embodiment, program modules are stored on a non-transitory storage device (i.e., a computer program product), loaded into a memory, and executed by a computer processor):
identify visitors to a website or other network location across a plurality of user devices and applications, wherein identifying visitors to the website or other network locations across a plurality of user devices and applications includes (Column 1, lines 51-52, A customer may use a first client device to visit a product page of a vendor through advertising on an affiliate's website; Column 7, lines 14-21, Referring back to FIG. 1, the marketplace server 103 comprises a transaction module 113. Generally, the transaction module 113 facilitates transactions between customers on client devices 105 and vendors 107. More particularly, the transaction module 113 tracks a customer's purchase transactions across a plurality of client devices 105 and updates the customer's activity information in the account database 111):
a script management module, wherein the script management module manages a number of vendor-specific scripts (Column 1, lines 26-28, The URL link redirects the client device to a vendor's product page which allows the user to purchase the product; Column 5, lines 29-35, Each device record 203 may also comprises a second level fingerprint. The second level fingerprint is based on device information that the marketplace server 103 requests from the client device 105 associated with the device record 203. The marketplace server 203 may store a script which requests device information from the device 203 that is used to create the second level fingerprint; Column 3, lines 49-55, Each product sold by a vendor 107 has an associated pitch (product) page that describes the product and a download URL if the product is a digital product. In one embodiment, each pitch page is associated with a pitch page URL that links to the pitch page. Typically, the pitch page URL is displayed on the marketplace server, in an affiliate's website, and/or a vendor's website for advertisement purposes; Column 10, lines 9-17, The transaction module 113 may identify the hop records associated with the product based on the hop attributes for the hop records. Particularly, the transaction module 113 identifies one or more hop records that comprise a URL of the pitch page associated with the requested product. The inclusion of the URL of the pitch page of the requested product in a hop record indicates that the customer viewed the pitch page for the product through the website of an affiliate 115 indicated in the hop record; As stated in Paragraph 0049 of Applicant’s specification, each script may be used to receive user information that uniquely identifies a client device and/or a user who operates such device (e.g., email address, device fingerprints, etc.). Therefore, based on broadest reasonable interpretation in light of the specification, Hust et al. discloses a script management since it includes a script which requests device information);
a user identification module, wherein the user identification module uniquely identifies visitors to a network … for one or more promotions and associate each identified visitor with a unique identifier (Column 4, lines 44-55, As shown in FIG. 2, the data record tree 200 comprises a customer record 201. Customers are represented in the marketplace server 103 by their associated customer record 201. In one embodiment, each customer record 201 comprises a unique customer identifier (ID) that is associated with the customer. The customer record 201 may also store contact information for the customer such as the user's name, electronic mail (e-mail) address(es), residence address, business address, and telephone number. The customer record 201 may also store financial information for the customer such as credit card information, bank account information, and/or a payer ID (e.g., a PayPal™ ID; Column 4, lines 56-64, For each customer record 201, the account database 111 stores a set of n devices records 203 that are associated with the customer record 201. The set of n device records 203 represents the known client devices that are used by the customer when interacting with the marketplace server 103. In the example illustrated in FIG. 2, customer record 201 is associated with two device records: device record 203A and device record 203B. Each device record 203 comprises a unique device ID that is associated with a client device 105; Column 5, lines 4-8, Furthermore, each device record 203 comprises one or more fingerprints that represent the client device 105 associated with the device record 203. A fingerprint for a client device 105 may be used to identify the client device 105 if the client device 105 lacks a cookie with a device ID; As stated in Paragraph 0028 of Applicant’s specification, “device fingerprints” may be used to uniquely identity a client device and/or a user who operates such device);
an activity tracking module, wherein the activity tracking module monitors activities of visitors identified by the user identification module (Column 7, lines 14-21, Referring back to FIG. 1, the marketplace server 103 comprises a transaction module 113. Generally, the transaction module 113 facilitates transactions between customers on client devices 105 and vendors 107. More particularly, the transaction module 113 tracks a customer's purchase transactions across a plurality of client devices 105 and updates the customer's activity information in the account database 111. The transaction module 113 also updates the customer's activity information when the customer is exposed to affiliates of the marketplace server 103. The transaction module 113 utilizes the activity information of a customer stored in the account database 111 to unify the information across multiple client devices; Column 7, lines 27-37, For example, when a cookie is not stored in a client device 105 or the cookie lacks the unique device ID of the client device 105, the transaction module 113 uses the customer activity information stored in the account database 111 to determine the customer ID of the customer thereby exposing which affiliate(s) should be compensated for the purchase order. Thus, the transaction module 113 can identify one or more affiliates that are associated with a purchase order even when multiple client devices 105 are used by the customer to complete the transaction or if cookies are not enabled (or unavailable) on the client device 105; Column 8, lines 25-30, In one embodiment, the transaction module 113 also creates 317 a fingerprint for the client device 105 and stores the fingerprint in the customer's data record tree. The fingerprint may be a first level fingerprint. The fingerprint may be used to identify the client device 105 at a later time if the cookie is no longer stored at the client device 105);
a suppression module, wherein the suppression module receives and determines suppression information relating to a user corresponding to user records … (Column 6, lines 14-16, A tracking indication from the client device 105 indicative of whether tracking the customer's interaction with the marketplace server 103 is allowed);
an attribution module, wherein the attribution module associates [clicks/impressions] made by the visitor at a network location with a provider of a service based on predetermined attribution criteria (Column 10, lines 35-47, The transaction module 113 determines the amount of credit attributed to an affiliate 115 from among a plurality of affiliates that contributed to a customer's purchase of a product based on various factors. Particularly, the transaction module 113 measures the contribution of each affiliate that influenced the purchase transaction. A customer's product interactions that influenced the customer to purchase a product may be a result of advertisements displayed on an affiliate's website (e.g., pay per click advertisements or advertisement impressions), e-mail campaigns developed by the affiliate, special offers offered the affiliate, and/or organic search queries through the affiliate's website resulting in the identification of the product; Column 10, lines 48-67, The affiliate with the greatest influence may receive the greatest attribution. In one embodiment, the amount of credit that an affiliate receives is based on the number of times the affiliate referred a purchased product to a customer and the total number of times that the product was referred to the customer. For example, the hop records in the account database 111 may indicate that a first affiliate and a second affiliate both influenced a customer to purchase a product. The transaction module 113 may identify that the product was referred to the customer a total of 5 times with the first affiliate contributing 4 of the referrals and the second affiliate contributing only 1 of the referrals. The transaction module 113 may determine that the first affiliate contributed 80% to the customer's decision to purchase the product and the second affiliate contributed 20% to the customer's decision to purchase the product based on the total number of referrals and the number of times each affiliate referred the product);
and a reporting module, wherein the reporting module transmits or displays some or all user information contained in one or more of the user records via one or more reports, notifications, alerts, webhooks, or API calls (Column 8, lines 4-24, Responsive to creating 311 the data record tree or responsive to determining 309 that the device ID is included in the account database 111, the transaction module 113 creates 313 a hop record and associates the hop record with the customer's data tree record. The created hop record includes the hop attributes of the affiliate 115 that referred the customer to the requested pitch page. By creating the hop record, the affiliate information associated with the hop record can be accessed by the transaction module 113 to determine the affiliate 115 that referred the product even if the product is not purchased until a later time. Thus, if the customer uses another client device 105 to purchase the product at a later time without the customer accessing the pitch page for the product via the affiliate's website, the affiliate's referral of the product is still tracked since it is stored in the hop record. Thus, by updating the data record tree for a customer when the customer interacts with an affiliate 115, the resulting hop record ensures that the affiliate 115 will be properly compensated for referring the product to the customer; Examiner interprets the hop record as the reporting module since the user information can be accessed and transmitted to the transaction module, see Figure 1 of Hust et al. Also, it can be noted that the claim language is written in alternative form. The limitation taught by Hust et al. is based on “one or more reports").
Although Hust et al. discloses a suppression module, wherein the suppression module receives and determines suppression information relating to a user (Column 6, lines 14-16, whether tracking the customer's interaction with the marketplace server 103 is allowed), Hust et al. does not specifically disclose wherein the suppression module receives and determines suppression information relating to a user corresponding to user records stored in a user database (e.g., inform the service that a user's information should not be shared with a vendor).
However, Frederick et al. discloses a user identification module, wherein the user identification module uniquely identifies visitors to a network based on a user’s selection to opt in for one or more promotions and associate each identified visitor with a unique identifier (Paragraph 0035, Prior to and/or along with being asked to allow information sharing with a third party (e.g., in this case, the codeshare principal), the user may also be informed that the partner system 104 would like to track the user's interactions with the partner's website or other platform (e.g., for the purpose of customizing dynamic website portions and/or improving the user experience) and asked for his affirmative consent to such tracking; Paragraph 0037, FIG. 3 is a flow chart depicting various acts of a method 300 performed by the codeshare partner in furtherance of providing user behavioral data to the codeshare principal, in accordance with various embodiments. The method 300 involves receiving, from the user, identifying information, such as an email address or telephone number (act 302), as well as consent to tracking the user's behavior on the website (or within some other platform) and sharing user data with the codeshare principal (act 304). As discussed above, the user's information and consent may be obtained as part of a registration process. It is, however, also possible that the user provides the information, and consent to share some user-specific data, during a guest-check-out process that does not require registration);
an activity tracking module, wherein the activity tracking module monitors activities of visitors identified by the user identification module (Paragraph 0040, With renewed reference to FIG. 3, the partner system 104 tracks the user's behavior on the partner platform (e.g., the partner site) and/or beyond (act 308). Tracked behavioral data may include, e.g., click data (i.e., which item-listings or, more generally, web-page elements the user clicks on), broader browsing data (e.g., which pages or item listings the user views, and for how long, as may be gleaned, for instance, from tracked mouse-overs, scroll-throughs, etc.), purchase data (including, e.g., a list of purchased items and associated prices, total spending over a specified period, average spending per month or over some specified duration, fluctuations in spending over time, a break-down of purchased items by category, time of purchase, etc.), and combinations thereof (e.g., correlations between views of item listings and any resulting purchases));
a suppression module, wherein the suppression module receives and determines suppression information relating to a user corresponding to user records stored in a user database (Paragraph 0035, To permit data sharing about the end user between the codeshare partner and principal in accordance herewith, the user registration process also involves obtaining, at 208, the user's affirmative consent to such information sharing. A request for consent may be made in conjunction with presenting the user with, and asking for his acknowledgement of, the partner's privacy policy and/or any applicable privacy laws. Prior to and/or along with being asked to allow information sharing with a third party (e.g., in this case, the codeshare principal), the user may also be informed that the partner system 104 would like to track the user's interactions with the partner's website or other platform (e.g., for the purpose of customizing dynamic website portions and/or improving the user experience) and asked for his affirmative consent to such tracking).
It would have been obvious to one ordinary skill in the art before the effective filing date to modify the system for user identification and monitoring, wherein the system includes a suppression module to receive and determine suppression information relating to the user (e.g., whether tracking the customer's interaction with the marketplace server 103 is allowed) of the invention of Hust et al. to further specify wherein the suppression information relating to a user corresponding to user records is stored in a user database of the invention of Frederick et al. because doing so would allow the system to share information with a third party based on affirmative consent provided by the user (see Frederick et al., Paragraph 0035). 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.
Although Hust et al. discloses wherein the attribution module associates a click made by the visitor at a network location with a provider of a service based on predetermined attribution criteria (e.g., pay per click advertisements or advertisement impressions), the combination of Hust et al. and Frederick et al. does not specifically discloses wherein the attribution module associates an abandoned eCommerce cart made by the visitor at a network location with a provider of a service based on predetermined attribution criteria (see Paragraph 0078 of Applicant’s specification, add to cart on the website and then leave the website).
However, Francis et al. discloses an attribution module, wherein the attribution module associates an abandoned eCommerce cart made by the visitor at a network location with a provider of a service based on predetermined attribution criteria (Paragraph 0095, Each time a user device accesses a merchant website or related function (e.g. “add to online cart”) within the e-commerce platform 310, user tracker 604 records a new entry with information about the device used to access the website/function; Paragraph 0097, FIG. 11 is an example database 1100 having headings 1108 of activity information 1106 tracked about a single user 1102 across multiple visits 1104. The database 1100 is stored on a memory in a server, e.g. memory 614. The database 1100 has been populated with example information for illustrative purposes. Activity information 1106 includes information about products visited by a user in a visit 1104, how many items they added to their cart, the campaign source that brought them to the store, the time they spent on the store or particular page, and the page navigation path (e.g. that the user started on a merchant store splash page, then proceeded to navigate to a specific section of a merchant store, then a product in the section, etc.). In contrast to purchase information shown in FIG. 10, each time a user interacts with a merchant website within the e-commerce system 310, the user tracker 604 records a new entry with information about the activity, regardless of whether or not a purchase was made; Paragraph 0100, In some embodiments, the user information tracked by the user tracker 604 may include source of a user visit (e.g. the user arrived at a merchant webpage from a particular one or more online advertisements); Paragraph 0136, In some embodiments, the user's previous online activity is or includes the user's previous online activity on the e-commerce platform, e.g. “an item was added to the online cart at 09:13 22 sec 12/3/2019”. However, the user's previous online activity does not necessarily have to be on the e-commerce platform, e.g. “user follows Merchant A on Facebook™”. In some embodiments, if the user's previous online activity is not online activity on the e-commerce platform, then the e-commerce platform may not know about the previous online activity. To obtain such online activity information in these situations, information associated with the identity of the user (e.g. the user's email address) may be sent to a 3.sup.rd party service that provides the online activity information for the user. The 3.sup.rd party service may be a social media platform itself. For example, the user's email address stored in the e-commerce platform may be used to send a request to Facebook™. The request asks for a list of Facebook™ users that the user associated with the email address follows; Examiner notes that Francis et al. discloses “wherein the attribution module associates an abandoned eCommerce cart made by the visitor at a network location with a provider of a service based on predetermined attribution criteria” since the item added to the cart is attributed to previous online activity such as interacting with one or more online advertisements on social media).
It would have been obvious to one ordinary skill in the art before the effective filing date to modify the system for user identification and monitoring, wherein the system includes a attribution module to associate user interactions made by the visitor at a network location with a provider of a service based on predetermined attribution criteria (e.g., pay per click advertisements or advertisement impressions) of the invention of Hust et al. to further specify wherein the attribution module associates an abandoned eCommerce cart made by the visitor at a network location with a provider of a service based on predetermined attribution criteria of the invention of Francis et al. because doing so would allow the system to track user's previous online activity (see Francis et al., Paragraph 0100, 0136 & 0176, a user that arrived at a webpage of the e-commerce platform from a particular one or more online advertisements). 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 11, Hust et al. discloses a method for tracking user activities across user devices, the method comprising (Abstract, An e-commerce system is provided that tracks purchase transaction across multiple client devices; Column 2, lines 12-20, When a customer's client device is referred to a vendor's website via advertising on an affiliate's website, the customer activity information for the customer is updated. By storing the customer activity information at the marketplace server rather than on a cookie at the customer's client device, the marketplace server can accurately monitor or track the affiliates involved in transactions with vendors even if those transactions occurred using multiple client devices that are associated with the customer; Column 5, lines 4-28, Furthermore, each device record 203 comprises one or more fingerprints that represent the client device 105 associated with the device record 203. A fingerprint for a client device 105 may be used to identify the client device 105 if the client device 105 lacks a cookie with a device ID):
identifying visitors to a website or other network location across a plurality of user devices and applications, wherein identifying visitors to the website or other network locations across a plurality of user devices and applications includes (Column 1, lines 51-52, A customer may use a first client device to visit a product page of a vendor through advertising on an affiliate's website; Column 7, lines 14-21, Referring back to FIG. 1, the marketplace server 103 comprises a transaction module 113. Generally, the transaction module 113 facilitates transactions between customers on client devices 105 and vendors 107. More particularly, the transaction module 113 tracks a customer's purchase transactions across a plurality of client devices 105 and updates the customer's activity information in the account database 111):
assigning the user to a unique identifier, via a user identification module, configured to be linked to a characteristic of the website (Column 4, lines 44-55, As shown in FIG. 2, the data record tree 200 comprises a customer record 201. Customers are represented in the marketplace server 103 by their associated customer record 201. In one embodiment, each customer record 201 comprises a unique customer identifier (ID) that is associated with the customer. The customer record 201 may also store contact information for the customer such as the user's name, electronic mail (e-mail) address(es), residence address, business address, and telephone number. The customer record 201 may also store financial information for the customer such as credit card information, bank account information, and/or a payer ID (e.g., a PayPal™ ID; Column 4, lines 56-64, For each customer record 201, the account database 111 stores a set of n devices records 203 that are associated with the customer record 201. The set of n device records 203 represents the known client devices that are used by the customer when interacting with the marketplace server 103. In the example illustrated in FIG. 2, customer record 201 is associated with two device records: device record 203A and device record 203B. Each device record 203 comprises a unique device ID that is associated with a client device 105; Column 5, lines 4-8, Furthermore, each device record 203 comprises one or more fingerprints that represent the client device 105 associated with the device record 203. A fingerprint for a client device 105 may be used to identify the client device 105 if the client device 105 lacks a cookie with a device ID; Column 8, lines 10-24, By creating the hop record, the affiliate information associated with the hop record can be accessed by the transaction module 113 to determine the affiliate 115 that referred the product even if the product is not purchased until a later time. Thus, if the customer uses another client device 105 to purchase the product at a later time without the customer accessing the pitch page for the product via the affiliate's website, the affiliate's referral of the product is still tracked since it is stored in the hop record. Thus, by updating the data record tree for a customer when the customer interacts with an affiliate 115, the resulting hop record ensures that the affiliate 115 will be properly compensated for referring the product to the customer; As stated in Paragraph 0028 of Applicant’s specification, “device fingerprints” may be used to uniquely identity a client device and/or a user who operates such device. Also, Examiner interprets the website for selling a specific product as the characteristic of the website);
managing, via a script management module, a number of vendor-specific scripts (Column 1, lines 26-28, The URL link redirects the client device to a vendor's product page which allows the user to purchase the product; Column 5, lines 29-35, Each device record 203 may also comprises a second level fingerprint. The second level fingerprint is based on device information that the marketplace server 103 requests from the client device 105 associated with the device record 203. The marketplace server 203 may store a script which requests device information from the device 203 that is used to create the second level fingerprint; Column 3, lines 49-55, Each product sold by a vendor 107 has an associated pitch (product) page that describes the product and a download URL if the product is a digital product. In one embodiment, each pitch page is associated with a pitch page URL that links to the pitch page. Typically, the pitch page URL is displayed on the marketplace server, in an affiliate's website, and/or a vendor's website for advertisement purposes; Column 10, lines 9-17, The transaction module 113 may identify the hop records associated with the product based on the hop attributes for the hop records. Particularly, the transaction module 113 identifies one or more hop records that comprise a URL of the pitch page associated with the requested product. The inclusion of the URL of the pitch page of the requested product in a hop record indicates that the customer viewed the pitch page for the product through the website of an affiliate 115 indicated in the hop record; As stated in Paragraph 0049 of Applicant’s specification, each script may be used to receive user information that uniquely identifies a client device and/or a user who operates such device (e.g., email address, device fingerprints, etc.). Therefore, based on broadest reasonable interpretation in light of the specification, Hust et al. discloses a script management since it includes a script which requests device information);
logging, via user activity, [clicks/impressions]; logging, via user activity, [clicks/impressions] (Column 7, lines 14-21, Referring back to FIG. 1, the marketplace server 103 comprises a transaction module 113. Generally, the transaction module 113 facilitates transactions between customers on client devices 105 and vendors 107. More particularly, the transaction module 113 tracks a customer's purchase transactions across a plurality of client devices 105 and updates the customer's activity information in the account database 111; Column 10, lines 35-47, The transaction module 113 determines the amount of credit attributed to an affiliate 115 from among a plurality of affiliates that contributed to a customer's purchase of a product based on various factors. Particularly, the transaction module 113 measures the contribution of each affiliate that influenced the purchase transaction. A customer's product interactions that influenced the customer to purchase a product may be a result of advertisements displayed on an affiliate's website (e.g., pay per click advertisements or advertisement impressions), e-mail campaigns developed by the affiliate, special offers offered the affiliate, and/or organic search queries through the affiliate's website resulting in the identification of the product);
uniquely identifying, via a user identification module, visitors to a network and associate each identified visitor with a unique identifier (Column 4, lines 44-55, As shown in FIG. 2, the data record tree 200 comprises a customer record 201. Customers are represented in the marketplace server 103 by their associated customer record 201. In one embodiment, each customer record 201 comprises a unique customer identifier (ID) that is associated with the customer. The customer record 201 may also store contact information for the customer such as the user's name, electronic mail (e-mail) address(es), residence address, business address, and telephone number. The customer record 201 may also store financial information for the customer such as credit card information, bank account information, and/or a payer ID (e.g., a PayPal™ ID; Column 4, lines 56-64, For each customer record 201, the account database 111 stores a set of n devices records 203 that are associated with the customer record 201. The set of n device records 203 represents the known client devices that are used by the customer when interacting with the marketplace server 103. In the example illustrated in FIG. 2, customer record 201 is associated with two device records: device record 203A and device record 203B. Each device record 203 comprises a unique device ID that is associated with a client device 105; Column 5, lines 4-8, Furthermore, each device record 203 comprises one or more fingerprints that represent the client device 105 associated with the device record 203. A fingerprint for a client device 105 may be used to identify the client device 105 if the client device 105 lacks a cookie with a device ID; Column 8, lines 10-24, By creating the hop record, the affiliate information associated with the hop record can be accessed by the transaction module 113 to determine the affiliate 115 that referred the product even if the product is not purchased until a later time. Thus, if the customer uses another client device 105 to purchase the product at a later time without the customer accessing the pitch page for the product via the affiliate's website, the affiliate's referral of the product is still tracked since it is stored in the hop record. Thus, by updating the data record tree for a customer when the customer interacts with an affiliate 115, the resulting hop record ensures that the affiliate 115 will be properly compensated for referring the product to the customer; As stated in Paragraph 0028 of Applicant’s specification, “device fingerprints” may be used to uniquely identity a client device and/or a user who operates such device);
monitoring, via an activity tracking module, activities of visitors identified by the user identification module (Column 5, lines 4-8, Furthermore, each device record 203 comprises one or more fingerprints that represent the client device 105 associated with the device record 203. A fingerprint for a client device 105 may be used to identify the client device 105 if the client device 105 lacks a cookie with a device ID; Column 8, lines 10-24, By creating the hop record, the affiliate information associated with the hop record can be accessed by the transaction module 113 to determine the affiliate 115 that referred the product even if the product is not purchased until a later time. Thus, if the customer uses another client device 105 to purchase the product at a later time without the customer accessing the pitch page for the product via the affiliate's website, the affiliate's referral of the product is still tracked since it is stored in the hop record. Thus, by updating the data record tree for a customer when the customer interacts with an affiliate 115, the resulting hop record ensures that the affiliate 115 will be properly compensated for referring the product to the customer);
receiving and determining, via a suppression module, suppression information relating to a user corresponding to user records … (Column 6, lines 14-16, A tracking indication from the client device 105 indicative of whether tracking the customer's interaction with the marketplace server 103 is allowed);
associating, via an attribution module, the [clicks/impressions] made by the visitor at a network location with a provider of a service based on predetermined attribution criteria (Column 10, lines 35-47, The transaction module 113 determines the amount of credit attributed to an affiliate 115 from among a plurality of affiliates that contributed to a customer's purchase of a product based on various factors. Particularly, the transaction module 113 measures the contribution of each affiliate that influenced the purchase transaction. A customer's product interactions that influenced the customer to purchase a product may be a result of advertisements displayed on an affiliate's website (e.g., pay per click advertisements or advertisement impressions), e-mail campaigns developed by the affiliate, special offers offered the affiliate, and/or organic search queries through the affiliate's website resulting in the identification of the product; Column 10, lines 48-67, The affiliate with the greatest influence may receive the greatest attribution. In one embodiment, the amount of credit that an affiliate receives is based on the number of times the affiliate referred a purchased product to a customer and the total number of times that the product was referred to the customer. For example, the hop records in the account database 111 may indicate that a first affiliate and a second affiliate both influenced a customer to purchase a product. The transaction module 113 may identify that the product was referred to the customer a total of 5 times with the first affiliate contributing 4 of the referrals and the second affiliate contributing only 1 of the referrals. The transaction module 113 may determine that the first affiliate contributed 80% to the customer's decision to purchase the product and the second affiliate contributed 20% to the customer's decision to purchase the product based on the total number of referrals and the number of times each affiliate referred the product);
and transmitting or displaying, via a reporting module, some or all user information contained in one or more of the user records via one or more reports, notifications, alerts, webhooks, or API calls (Column 8, lines 4-24, Responsive to creating 311 the data record tree or responsive to determining 309 that the device ID is included in the account database 111, the transaction module 113 creates 313 a hop record and associates the hop record with the customer's data tree record. The created hop record includes the hop attributes of the affiliate 115 that referred the customer to the requested pitch page. By creating the hop record, the affiliate information associated with the hop record can be accessed by the transaction module 113 to determine the affiliate 115 that referred the product even if the product is not purchased until a later time. Thus, if the customer uses another client device 105 to purchase the product at a later time without the customer accessing the pitch page for the product via the affiliate's website, the affiliate's referral of the product is still tracked since it is stored in the hop record. Thus, by updating the data record tree for a customer when the customer interacts with an affiliate 115, the resulting hop record ensures that the affiliate 115 will be properly compensated for referring the product to the customer; Examiner interprets the hop record as the reporting module since the user information can be accessed and transmitted to the transaction module, see Figure 1 of Hust et al. Also, it can be noted that the claim language is written in alternative form. The limitation taught by Hust et al. is based on “one or more reports").
Although Hust et al. discloses receiving and determining suppression information relating to a user (Column 6, lines 14-16, whether tracking the customer's interaction with the marketplace server 103 is allowed), Hust et al. does not specifically disclose receiving and determining suppression information relating to a user stored in a user database (e.g., inform the service that a user's information should not be shared with a vendor).
However, Frederick et al. discloses receiving and determining, via a suppression module, suppression information relating to a user corresponding to user records stored in a user database (Paragraph 0035, Prior to and/or along with being asked to allow information sharing with a third party (e.g., in this case, the codeshare principal), the user may also be informed that the partner system 104 would like to track the user's interactions with the partner's website or other platform (e.g., for the purpose of customizing dynamic website portions and/or improving the user experience) and asked for his affirmative consent to such tracking; Paragraph 0037, FIG. 3 is a flow chart depicting various acts of a method 300 performed by the codeshare partner in furtherance of providing user behavioral data to the codeshare principal, in accordance with various embodiments. The method 300 involves receiving, from the user, identifying information, such as an email address or telephone number (act 302), as well as consent to tracking the user's behavior on the website (or within some other platform) and sharing user data with the codeshare principal (act 304). As discussed above, the user's information and consent may be obtained as part of a registration process. It is, however, also possible that the user provides the information, and consent to share some user-specific data, during a guest-check-out process that does not require registration)
It would have been obvious to one ordinary skill in the art before the effective filing date to modify the system for user identification and monitoring, wherein the system includes a suppression module to receive and determine suppression information relating to the user (e.g., whether tracking the customer's interaction with the marketplace server 103 is allowed) of the invention of Hust et al. to further specify wherein the suppression information relating to a user corresponding to user records is stored in a user database of the invention of Frederick et al. because doing so would allow the system to share information with a third party based on affirmative consent provided by the user (see Frederick et al., Paragraph 0035). 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.
Although Hust et al. discloses associating a click made by the visitor at a network location with a provider of a service based on predetermined attribution criteria (e.g., pay per click advertisements or advertisement impressions), the combination of Hust et al. and Frederick et al. does not specifically discloses associating an abandoned eCommerce cart made by the visitor at a network location with a provider of a service based on predetermined attribution criteria (see Paragraph 0078 of Applicant’s specification, add to cart on the website and then leave the website).
However, Francis et al. discloses logging, via user activity, items put into an eCommerce cart on the website; logging, via user activity, an abandonment of the eCommerce cart (Paragraph 0095, Each time a user device accesses a merchant website or related function (e.g. “add to online cart”) within the e-commerce platform 310, user tracker 604 records a new entry with information about the device used to access the website/function; Paragraph 0097, FIG. 11 is an example database 1100 having headings 1108 of activity information 1106 tracked about a single user 1102 across multiple visits 1104. The database 1100 is stored on a memory in a server, e.g. memory 614. The database 1100 has been populated with example information for illustrative purposes. Activity information 1106 includes information about products visited by a user in a visit 1104, how many items they added to their cart, the campaign source that brought them to the store, the time they spent on the store or particular page, and the page navigation path (e.g. that the user started on a merchant store splash page, then proceeded to navigate to a specific section of a merchant store, then a product in the section, etc.). In contrast to purchase information shown in FIG. 10, each time a user interacts with a merchant website within the e-commerce system 310, the user tracker 604 records a new entry with information about the activity, regardless of whether or not a purchase was made); …;
associating, via an attribution module, the abandoned eCommerce cart made by the visitor at a network location with a provider of a service based on predetermined attribution criteria (Paragraph 0095, Each time a user device accesses a merchant website or related function (e.g. “add to online cart”) within the e-commerce platform 310, user tracker 604 records a new entry with information about the device used to access the website/function; Paragraph 0097, FIG. 11 is an example database 1100 having headings 1108 of activity information 1106 tracked about a single user 1102 across multiple visits 1104. The database 1100 is stored on a memory in a server, e.g. memory 614. The database 1100 has been populated with example information for illustrative purposes. Activity information 1106 includes information about products visited by a user in a visit 1104, how many items they added to their cart, the campaign source that brought them to the store, the time they spent on the store or particular page, and the page navigation path (e.g. that the user started on a merchant store splash page, then proceeded to navigate to a specific section of a merchant store, then a product in the section, etc.). In contrast to purchase information shown in FIG. 10, each time a user interacts with a merchant website within the e-commerce system 310, the user tracker 604 records a new entry with information about the activity, regardless of whether or not a purchase was made; Paragraph 0100, In some embodiments, the user information tracked by the user tracker 604 may include source of a user visit (e.g. the user arrived at a merchant webpage from a particular one or more online advertisements); Paragraph 0136, In some embodiments, the user's previous online activity is or includes the user's previous online activity on the e-commerce platform, e.g. “an item was added to the online cart at 09:13 22 sec 12/3/2019”. However, the user's previous online activity does not necessarily have to be on the e-commerce platform, e.g. “user follows Merchant A on Facebook™”. In some embodiments, if the user's previous online activity is not online activity on the e-commerce platform, then the e-commerce platform may not know about the previous online activity. To obtain such online activity information in these situations, information associated with the identity of the user (e.g. the user's email address) may be sent to a 3.sup.rd party service that provides the online activity information for the user. The 3.sup.rd party service may be a social media platform itself. For example, the user's email address stored in the e-commerce platform may be used to send a request to Facebook™. The request asks for a list of Facebook™ users that the user associated with the email address follows; Examiner notes that Francis et al. discloses “wherein the attribution module associates an abandoned eCommerce cart made by the visitor at a network location with a provider of a service based on predetermined attribution criteria” since the item added to the cart is attributed to previous online activity such as interacting with one or more online advertisements on social media).
It would have been obvious to one ordinary skill in the art before the effective filing date to modify the system for user identification and monitoring, wherein the system includes a attribution module to associate user interactions made by the visitor at a network location with a provider of a service based on predetermined attribution criteria (e.g., pay per click advertisements or advertisement impressions) of the invention of Hust et al. to further specify wherein the attribution module associates an abandoned eCommerce cart made by the visitor at a network location with a provider of a service based on predetermined attribution criteria of the invention of Francis et al. because doing so would allow the system to track user's previous online activity (see Francis et al., Paragraph 0100, 0136 & 0176, a user that arrived at a webpage of the e-commerce platform from a particular one or more online advertisements). 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 claims 2 and 12, which are dependent of claims 1 and 11, the combination of Hust et al., Frederick et al., and Francis et al. discloses all the limitations in claims 1 and 11. Hust et al. further discloses wherein the script management module further manages configuration settings and data supporting the vendor-specific scripts (Column 1, lines 26-28, The URL link redirects the client device to a vendor's product page which allows the user to purchase the product; Column 5, lines 29-35, Each device record 203 may also comprises a second level fingerprint. The second level fingerprint is based on device information that the marketplace server 103 requests from the client device 105 associated with the device record 203. The marketplace server 203 may store a script which requests device information from the device 203 that is used to create the second level fingerprint; Column 3, lines 49-55, Each product sold by a vendor 107 has an associated pitch (product) page that describes the product and a download URL if the product is a digital product. In one embodiment, each pitch page is associated with a pitch page URL that links to the pitch page. Typically, the pitch page URL is displayed on the marketplace server, in an affiliate's website, and/or a vendor's website for advertisement purposes; Column 10, lines 9-17, The transaction module 113 may identify the hop records associated with the product based on the hop attributes for the hop records. Particularly, the transaction module 113 identifies one or more hop records that comprise a URL of the pitch page associated with the requested product. The inclusion of the URL of the pitch page of the requested product in a hop record indicates that the customer viewed the pitch page for the product through the website of an affiliate 115 indicated in the hop record; As stated in Paragraph 0048 of Applicant’s specification, the configuration may include a unique URL such that the corresponding vendor may import the script to one or more network locations. Therefore, based on broadest reasonable interpretation in light of the specification, Hust et al. discloses “configuration settings” since each vendor is associated with a unique URL).
Regarding claims 3 and 13, which are dependent of claims 2 and 12, the combination of Hust et al., Frederick et al., and Francis et al. discloses all the limitations in claims 2 and 12. Hust et al. further discloses wherein the script management module further generates a unique script for each vendor (Column 1, lines 26-28, The URL link redirects the client device to a vendor's product page which allows the user to purchase the product; Column 5, lines 29-35, Each device record 203 may also comprises a second level fingerprint. The second level fingerprint is based on device information that the marketplace server 103 requests from the client device 105 associated with the device record 203. The marketplace server 203 may store a script which requests device information from the device 203 that is used to create the second level fingerprint; Column 3, lines 49-55, Each product sold by a vendor 107 has an associated pitch (product) page that describes the product and a download URL if the product is a digital product. In one embodiment, each pitch page is associated with a pitch page URL that links to the pitch page. Typically, the pitch page URL is displayed on the marketplace server, in an affiliate's website, and/or a vendor's website for advertisement purposes; Column 10, lines 9-17, The transaction module 113 may identify the hop records associated with the product based on the hop attributes for the hop records. Particularly, the transaction module 113 identifies one or more hop records that comprise a URL of the pitch page associated with the requested product. The inclusion of the URL of the pitch page of the requested product in a hop record indicates that the customer viewed the pitch page for the product through the website of an affiliate 115 indicated in the hop record; Examiner notes that each vendor has a unique script such as an URL).
Regarding claims 4 and 14, which are dependent of claims 1 and 11, the combination of Hust et al., Frederick et al., and Francis et al. discloses all the limitations in claims 1 and 11. Hust et al. further discloses wherein the script management module further generates a unique script for each vendor (Column 1, lines 26-28, The URL link redirects the client device to a vendor's product page which allows the user to purchase the product; Column 5, lines 29-35, Each device record 203 may also comprises a second level fingerprint. The second level fingerprint is based on device information that the marketplace server 103 requests from the client device 105 associated with the device record 203. The marketplace server 203 may store a script which requests device information from the device 203 that is used to create the second level fingerprint; Column 3, lines 49-55, Each product sold by a vendor 107 has an associated pitch (product) page that describes the product and a download URL if the product is a digital product. In one embodiment, each pitch page is associated with a pitch page URL that links to the pitch page. Typically, the pitch page URL is displayed on the marketplace server, in an affiliate's website, and/or a vendor's website for advertisement purposes; Column 10, lines 9-17, The transaction module 113 may identify the hop records associated with the product based on the hop attributes for the hop records. Particularly, the transaction module 113 identifies one or more hop records that comprise a URL of the pitch page associated with the requested product. The inclusion of the URL of the pitch page of the requested product in a hop record indicates that the customer viewed the pitch page for the product through the website of an affiliate 115 indicated in the hop record; Examiner notes that each vendor has a unique script such as an URL).
Regarding claims 5 and 15, which are dependent of claims 1 and 11, the combination of Hust et al., Frederick et al., and Francis et al. discloses all the limitations in claims 1 and 11. Hust et al. further discloses wherein the user identification module further receives user information, determines a subset of the received user information that uniquely identifies a client device or user of the client device, and matches the subset of the received user information to the user records (Column 4, lines 44-55, As shown in FIG. 2, the data record tree 200 comprises a customer record 201. Customers are represented in the marketplace server 103 by their associated customer record 201. In one embodiment, each customer record 201 comprises a unique customer identifier (ID) that is associated with the customer. The customer record 201 may also store contact information for the customer such as the user's name, electronic mail (e-mail) address(es), residence address, business address, and telephone number. The customer record 201 may also store financial information for the customer such as credit card information, bank account information, and/or a payer ID (e.g., a PayPal™ ID; Column 4, lines 56-64, For each customer record 201, the account database 111 stores a set of n devices records 203 that are associated with the customer record 201. The set of n device records 203 represents the known client devices that are used by the customer when interacting with the marketplace server 103. In the example illustrated in FIG. 2, customer record 201 is associated with two device records: device record 203A and device record 203B. Each device record 203 comprises a unique device ID that is associated with a client device 105; Column 5, lines 4-8, Furthermore, each device record 203 comprises one or more fingerprints that represent the client device 105 associated with the device record 203. A fingerprint for a client device 105 may be used to identify the client device 105 if the client device 105 lacks a cookie with a device ID; As stated in Paragraph 0028 of Applicant’s specification, “device fingerprints” may be used to uniquely identity a client device and/or a user who operates such device).
Regarding claims 6 and 16, which are dependent of claims 5 and 15, the combination of Hust et al., Frederick et al., and Francis et al. discloses all the limitations in claims 5 and 15. Hust et al. further discloses wherein the user identification module further creates the user record in the user database corresponding to the unique identifier (Column 4, lines 44-55, As shown in FIG. 2, the data record tree 200 comprises a customer record 201. Customers are represented in the marketplace server 103 by their associated customer record 201. In one embodiment, each customer record 201 comprises a unique customer identifier (ID) that is associated with the customer. The customer record 201 may also store contact information for the customer such as the user's name, electronic mail (e-mail) address(es), residence address, business address, and telephone number. The customer record 201 may also store financial information for the customer such as credit card information, bank account information, and/or a payer ID (e.g., a PayPal™ ID; Column 4, lines 56-64, For each customer record 201, the account database 111 stores a set of n devices records 203 that are associated with the customer record 201. The set of n device records 203 represents the known client devices that are used by the customer when interacting with the marketplace server 103. In the example illustrated in FIG. 2, customer record 201 is associated with two device records: device record 203A and device record 203B. Each device record 203 comprises a unique device ID that is associated with a client device 105; Column 5, lines 4-8, Furthermore, each device record 203 comprises one or more fingerprints that represent the client device 105 associated with the device record 203. A fingerprint for a client device 105 may be used to identify the client device 105 if the client device 105 lacks a cookie with a device ID).
Regarding claims 7 and 17, which is dependent of claims 1 and 11, the combination of Hust et al., Frederick et al., and Francis et al. discloses all the limitations in claims 1 and 11. Hust et al. further discloses wherein the activity tracking module further tracks visits to a network location, and use and conversion activities performed by a user (Column 7, lines 14-21, Referring back to FIG. 1, the marketplace server 103 comprises a transaction module 113. Generally, the transaction module 113 facilitates transactions between customers on client devices 105 and vendors 107. More particularly, the transaction module 113 tracks a customer's purchase transactions across a plurality of client devices 105 and updates the customer's activity information in the account database 111. The transaction module 113 also updates the customer's activity information when the customer is exposed to affiliates of the marketplace server 103. The transaction module 113 utilizes the activity information of a customer stored in the account database 111 to unify the information across multiple client devices; Column 7, lines 27-37, For example, when a cookie is not stored in a client device 105 or the cookie lacks the unique device ID of the client device 105, the transaction module 113 uses the customer activity information stored in the account database 111 to determine the customer ID of the customer thereby exposing which affiliate(s) should be compensated for the purchase order. Thus, the transaction module 113 can identify one or more affiliates that are associated with a purchase order even when multiple client devices 105 are used by the customer to complete the transaction or if cookies are not enabled (or unavailable) on the client device 105; Column 8, lines 10-24, By creating the hop record, the affiliate information associated with the hop record can be accessed by the transaction module 113 to determine the affiliate 115 that referred the product even if the product is not purchased until a later time. Thus, if the customer uses another client device 105 to purchase the product at a later time without the customer accessing the pitch page for the product via the affiliate's website, the affiliate's referral of the product is still tracked since it is stored in the hop record. Thus, by updating the data record tree for a customer when the customer interacts with an affiliate 115, the resulting hop record ensures that the affiliate 115 will be properly compensated for referring the product to the customer; Column 8, lines 25-30, In one embodiment, the transaction module 113 also creates 317 a fingerprint for the client device 105 and stores the fingerprint in the customer's data record tree. The fingerprint may be a first level fingerprint. The fingerprint may be used to identify the client device 105 at a later time if the cookie is no longer stored at the client device 105; Examiner interprets the “website” as the “network location”).
Regarding claims 8 and 18, which are dependent of claims 7 and 17, the combination of Hust et al., Frederick et al., and Francis et al. discloses all the limitations in claims 7 and 17. Hust et al. further discloses wherein the activity tracking module associates the visit, use, and conversion information with the corresponding user record on the user database (Column 7, lines 14-21, Referring back to FIG. 1, the marketplace server 103 comprises a transaction module 113. Generally, the transaction module 113 facilitates transactions between customers on client devices 105 and vendors 107. More particularly, the transaction module 113 tracks a customer's purchase transactions across a plurality of client devices 105 and updates the customer's activity information in the account database 111. The transaction module 113 also updates the customer's activity information when the customer is exposed to affiliates of the marketplace server 103. The transaction module 113 utilizes the activity information of a customer stored in the account database 111 to unify the information across multiple client devices; Column 7, lines 27-37, For example, when a cookie is not stored in a client device 105 or the cookie lacks the unique device ID of the client device 105, the transaction module 113 uses the customer activity information stored in the account database 111 to determine the customer ID of the customer thereby exposing which affiliate(s) should be compensated for the purchase order. Thus, the transaction module 113 can identify one or more affiliates that are associated with a purchase order even when multiple client devices 105 are used by the customer to complete the transaction or if cookies are not enabled (or unavailable) on the client device 105; Column 8, lines 10-24, By creating the hop record, the affiliate information associated with the hop record can be accessed by the transaction module 113 to determine the affiliate 115 that referred the product even if the product is not purchased until a later time. Thus, if the customer uses another client device 105 to purchase the product at a later time without the customer accessing the pitch page for the product via the affiliate's website, the affiliate's referral of the product is still tracked since it is stored in the hop record. Thus, by updating the data record tree for a customer when the customer interacts with an affiliate 115, the resulting hop record ensures that the affiliate 115 will be properly compensated for referring the product to the customer; Column 8, lines 25-30, In one embodiment, the transaction module 113 also creates 317 a fingerprint for the client device 105 and stores the fingerprint in the customer's data record tree. The fingerprint may be a first level fingerprint. The fingerprint may be used to identify the client device 105 at a later time if the cookie is no longer stored at the client device 105).
Regarding claims 9 and 19, which are dependent of claims 1 and 11, the combination of Hust et al., Frederick et al., and Francis et al. discloses all the limitations in claims 1 and 11. Hust et al. further discloses wherein the activity tracking module further identifies and tracks activities performed by the user based on one or more predetermined events (Column 7, lines 14-21, Referring back to FIG. 1, the marketplace server 103 comprises a transaction module 113. Generally, the transaction module 113 facilitates transactions between customers on client devices 105 and vendors 107. More particularly, the transaction module 113 tracks a customer's purchase transactions across a plurality of client devices 105 and updates the customer's activity information in the account database 111. The transaction module 113 also updates the customer's activity information when the customer is exposed to affiliates of the marketplace server 103. The transaction module 113 utilizes the activity information of a customer stored in the account database 111 to unify the information across multiple client devices; Column 7, lines 27-37, For example, when a cookie is not stored in a client device 105 or the cookie lacks the unique device ID of the client device 105, the transaction module 113 uses the customer activity information stored in the account database 111 to determine the customer ID of the customer thereby exposing which affiliate(s) should be compensated for the purchase order. Thus, the transaction module 113 can identify one or more affiliates that are associated with a purchase order even when multiple client devices 105 are used by the customer to complete the transaction or if cookies are not enabled (or unavailable) on the client device 105; Column 8, lines 25-30, In one embodiment, the transaction module 113 also creates 317 a fingerprint for the client device 105 and stores the fingerprint in the customer's data record tree. The fingerprint may be a first level fingerprint. The fingerprint may be used to identify the client device 105 at a later time if the cookie is no longer stored at the client device 105; Column 10, lines 35-47, The transaction module 113 determines the amount of credit attributed to an affiliate 115 from among a plurality of affiliates that contributed to a customer's purchase of a product based on various factors. Particularly, the transaction module 113 measures the contribution of each affiliate that influenced the purchase transaction. A customer's product interactions that influenced the customer to purchase a product may be a result of advertisements displayed on an affiliate's website (e.g., pay per click advertisements or advertisement impressions), e-mail campaigns developed by the affiliate, special offers offered the affiliate, and/or organic search queries through the affiliate's website resulting in the identification of the product; Examiner interprets tracking “clicks and/or purchases” as the “one or more predetermined events”).
Regarding claims 10 and 20, which are dependent of claims 1 and 11, the combination of Hust et al., Frederick et al., and Francis et al. discloses all the limitations in claims 1 and 11. Hust et al. further discloses wherein the reporting module further determines aggregate information across a user population, or subset thereof, based on the user records and tracked activities performed by the user (Column 5, lines 4-8, Furthermore, each device record 203 comprises one or more fingerprints that represent the client device 105 associated with the device record 203. A fingerprint for a client device 105 may be used to identify the client device 105 if the client device 105 lacks a cookie with a device ID; Column 8, lines 4-24, Responsive to creating 311 the data record tree or responsive to determining 309 that the device ID is included in the account database 111, the transaction module 113 creates 313 a hop record and associates the hop record with the customer's data tree record. The created hop record includes the hop attributes of the affiliate 115 that referred the customer to the requested pitch page. By creating the hop record, the affiliate information associated with the hop record can be accessed by the transaction module 113 to determine the affiliate 115 that referred the product even if the product is not purchased until a later time. Thus, if the customer uses another client device 105 to purchase the product at a later time without the customer accessing the pitch page for the product via the affiliate's website, the affiliate's referral of the product is still tracked since it is stored in the hop record. Thus, by updating the data record tree for a customer when the customer interacts with an affiliate 115, the resulting hop record ensures that the affiliate 115 will be properly compensated for referring the product to the customer; As stated in Paragraph 0088 of Applicant’s specification, the subset may be device parameters that uniquely identify the client device and a user who operates such devices (i.e., “fingerprints”). Therefore, based on broadest reasonable interpretation in light of the specification, Hust et al. discloses a subset since it can create a record for a customer based on the device ID such as a fingerprint).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
Phillips (GB 2593890 A) – discloses configuration of the JavaScript file so that the browser is able to determine when predetermined events have occurred is conventionally laborious. Conventionally, elements for which events are to be detected are manually identified in a process involving manually inspecting an element to find an identifier of the element and then manually configuring the JavaScript file to identify the elements and the events relating to the identified elements. For example, a JavaScript file can be configured for a website on which a product can be bought to specify that the browser is to detect when a corresponding add-to-basket element on a webpage is selected (see at least Page 2, lines 7-14).
Nikiforakis (Nikiforakis, N., Kapravelos, A., Joosen, W., Kruegel, C., Piessens, F. and Vigna, G., 2013, May. Cookieless monster: Exploring the ecosystem of web-based device fingerprinting. In 2013 IEEE Symposium on Security and Privacy (pp. 541-555). IEEE) – discloses how web-based device fingerprinting currently works on the Internet. By analyzing the code of three popular browser-fingerprinting code providers, we reveal the techniques that allow websites to track users without the need of client-side identifiers. Among these techniques, we show how current commercial fingerprinting approaches use questionable practices, such as the circumvention of HTTP proxies to discover a user’s real IP address and the installation of intrusive browser plugins.
Akimova (Akimova, O., 2019. Tracking user behavior on the web for digital marketing personalization with Salesforce. (Year: 2019)) - When the user comes to the website for the first time, Einstein tracking code creates a cookie with an identifier and starts building his anonymous profile. All collected activity data is saved in the user profile. When the user returns to the website the next time, Einstein continues tracking his activity and saving the data into his existing profile. This approach allows targeting the visitors with personalized content even without knowing their identity, but simply based on their patterns and interests during the previous visits to the online store. However, the identification of visitors is still highly desirable. When the visitor “raises a digital hand” (provides information such as his email address), his profile stops being anonymous and continues to expand with the new incoming tracking data (see at least Page 15).
Kieviet et al. (US 2020/0127904 A1) – discloses configuring a resource (e.g., a webpage, website, online document, electronic document, or networked application) for network traffic analysis. The network traffic analysis can be performed by a network traffic analysis tool, server or analytics engine. The analytics engine can, for example, track browsing activity prior to a conversion to generate a report that indicates pages, content, or advertisements viewed or accessed by a user prior to making a purchase. A content provider, advertiser, online retailer or other website publisher can configure tags (e.g., HTML tags) or scripts (e.g., Java scripts) on, in, or with their webpage or advertisements to facilitate identification of details associated with a browsing session. When a user selects a link to purchase a product, for example, the HTML or Java tag or script can identify the event and store the event in a database for further processing, analytics, or reporting by the tool. However, due to the complexity and variability of configuring a webpage with these tags, it can be challenging for website developers to confirm that they have correctly tagged all the content on their webpage in order to produce useful and accurate analytics and reports, In an illustrative example, a content provider configures their landing page with analytics tags or scripts. The content provider initiates an extension configured on their webpage to record browsing activity. The content provider selects their advertisement (e.g., via search advertisements displayed with a search results page), which re-directs them to the advertisement's landing page on the advertiser's website. The content provider proceeds to select items (e.g., products on sale) and add them to an online shopping cart. Prior to checking out the shopping cart, the content provider may proceed to browse the company's blogs, specials, etc. (see at least Paragraphs 0019-0023).
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.
/MARJORIE PUJOLS-CRUZ/Examiner, Art Unit 3624 /PATRICIA H MUNSON/Supervisory Patent Examiner, Art Unit 3624
Prosecution Insights