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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on March 25, 2026 has been entered.
Status of the Claims
Claims 1-5, 7-11, 13-16, and 18-20 are all the claims pending in the application.
Claims 1, 8, and 16 are amended.
Claims 1-5, 7-11, 13-16, and 18-20 are rejected.
The following is a Non-Final Office Action in response to amendments and remarks filed Mar. 25, 2026.
Response to Arguments
Regarding the 101 rejections, the rejections are maintained for the following reasons. Applicant asserts the claims reflect an improvement because the claims solve the problems associated with different providers providing differing information for a business. Examiner respectfully does not find this assertion persuasive because persuasive because an improvement in the abstract idea is not an improvement in technology, see MPEP 2106.05(a) (discussing Trading Technologies Int’l v. IBG). That is, monitoring a business’s information to ensure it is reliable is not a technological problem, it is a business or administrative problem. Accordingly the rejections are maintained, please see below for the complete rejections of the claims as amended.
Regarding the 103 rejections, the rejections are withdrawn because the cited references do not teach completing missing fields. Please see below for the new rejections of the claims as amended.
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-5, 7-11, 13-16, and 18-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Under Step 1 of the patent eligibility analysis, it must first be determined whether the claims are directed to one of the four statutory categories of invention. Applying Step 1 to the claims it is determined that: claims 1-5 and 7 are directed to a process; and claims 8-11, 13-16, and 18-20 are directed.
Independent Claims
Under Step 2A Prong 1 of the patent eligibility analysis, it must be determined whether the claims recite an abstract idea that falls within one or more designated categories or “buckets” of patent ineligible subject matter that amount to a judicial exception to patentability.
The independent claims recite an abstract idea. Specifically, independent claim 1 recites an abstract idea in the limitations (emphasized):
…providing, in response to a search query associated with a first merchant system, a business listing of the first merchant system;
monitoring, by a processing device, activity of a cluster of merchant systems comprising the first merchant system, wherein the activity relates to an updating of a plurality of data fields of business listings of the cluster of merchant systems;
determining, by the processing device, in view of analytics based on the activity of the cluster of merchant systems, a frequency that the cluster of merchant systems updates a data field of the plurality of data fields associated with the first merchant system, wherein the data field is identified based on an updating frequency of the data field associated with other merchant systems in the cluster of merchant systems;
generating, by the processing device, based on the frequency, a rule defining a time period associated with updating the data field of the business listing associated with the first merchant system, wherein the rule is established based on one or more selections provided by the first merchant system and at least one of the analytics based on the activity of the first merchant and one or more search query activities associated with the first merchant system, and wherein the one or more selections indicate a first frequency to update a first data field and a second frequency different from the first frequency to update a second data field of the plurality of data fields;
monitoring, by the processing device, the first merchant system to determine an occurrence of an event corresponding to the rule and the data field, wherein the event comprises passage of the time period during which no update to the data field has been made by the first merchant system;
in response to a request from a first user to update the rule, updating the rule when the request is approved by a second user, wherein the first user is a non-admin user of the first merchant system and the second user is an admin user of the first merchant system;
in response to the occurrence of the event, transmitting, by the processing device, a notification to the first merchant system via a communication platform of a plurality of communication platforms, wherein the notification comprises a prompt to update a value stored in the data field of the business listing of the first merchant system, and wherein updating the value comprises completing a missing data field of the business listing;
receiving, by the processing device via a dialog interface associated with the first merchant system, a response from the first merchant system comprising an updated value corresponding to the data field of the business listing of the first merchant system;
causing, by the processing device, the updated value corresponding to the data field to be stored in an updated record associated with the business listing;
automatically transmitting, by the processing device, at least a portion of the updated record to a plurality of business listing provider systems; and
subsequent to the transmitting, providing, in response to a subsequent search query associated with the first merchant system, the business listing including the updated value.
These limitations recite an abstract ide because these limitations encompass a mental process (i.e. observation, evaluation, judgment and opinion). These limitations encompass a mental process (i.e. observation, evaluation, judgment and opinion) because these limitations encompass observation (i.e., monitoring the merchant systems for updates), evaluation (i.e., determining the frequency of updates of the merchant systems), and judgment and opinion (i.e., generating and updating the rule defining the time period). Accordingly, claims 1, 8, and 16 recite an abstract idea.
Under Step 2A Prong 2 of the patent eligibility analysis, it must be determined whether the identified, recited abstract idea includes additional elements that integrate the abstract idea into a practical application.
The additional elements of the independent claims do not integrate the abstract idea into a practical application. Claim 1 recites the additional elements (emphasized):
…providing, in response to a search query associated with a first merchant system, a business listing of the first merchant system;
monitoring, by a processing device, activity of a cluster of merchant systems comprising the first merchant system, wherein the activity relates to an updating of a plurality of data fields of business listings of the cluster of merchant systems;
determining, by the processing device, in view of analytics based on the activity of the cluster of merchant systems, a frequency that the cluster of merchant systems updates a data field of the plurality of data fields associated with the first merchant system, wherein the data field is identified based on an updating frequency of the data field associated with other merchant systems in the cluster of merchant systems;
generating, by the processing device, based on the frequency, a rule defining a time period associated with updating the data field of the business listing associated with the first merchant system, wherein the rule is established based on one or more selections provided by the first merchant system and at least one of the analytics based on the activity of the first merchant and one or more search query activities associated with the first merchant system, and wherein the one or more selections indicate a first frequency to update a first data field and a second frequency different from the first frequency to update a second data field of the plurality of data fields;
monitoring, by the processing device, the first merchant system to determine an occurrence of an event corresponding to the rule and the data field, wherein the event comprises passage of the time period during which no update to the data field has been made by the first merchant system;
in response to a request from a first user to update the rule, updating the rule when the request is approved by a second user, wherein the first user is a non-admin user of the first merchant system and the second user is an admin user of the first merchant system;
in response to the occurrence of the event, transmitting, by the processing device, a notification to the first merchant system via a communication platform of a plurality of communication platforms, wherein the notification comprises a prompt to update a value stored in the data field of the business listing of the first merchant system, and wherein updating the value comprises completing a missing data field of the business listing;
receiving, by the processing device via a dialog interface associated with the first merchant system, a response from the first merchant system comprising an updated value corresponding to the data field of the business listing of the first merchant system;
causing, by the processing device, the updated value corresponding to the data field to be stored in an updated record associated with the business listing;
automatically transmitting, by the processing device, at least a portion of the updated record to a plurality of business listing provider systems; and
subsequent to the transmitting, providing, in response to a subsequent search query associated with the first merchant system, the business listing including the updated value.
These additional elements do not integrate the abstract idea into a practical application for the following reasons. First, the additional elements of providing the listings in response to the search queries, when considered individually or in combination, do not integrate the abstract idea into a practical application because the additional elements are only using software to tailor information and provide it to a user, which is not more than mere instructions to apply the exception, see MPEP 2106.05(f) (discussing Intellectual Ventures I LLC v. Capital One Bank (USA)).
Second, the additional elements of a first user requesting to update the rule and the second user approving it, when considered individually or in combination, do not integrate the abstract idea into a practical application because the additional elements encompass a generic computer process of receiving user inputs.
Third, the additional elements of transmitting a notification, receiving a response, causing updated values to be stored and transmitting the updated record, when considered individually or in combination, do not integrate the abstract idea into a practical application because the additional elements encompass a generic computer function of sending, receiving data and storing data, see MPEP 2106.05(f)(2) (noting the use of computers in their ordinary capacity to receive, store, or transmit data does not integrate a judicial exception into a practical application).
Fourth, claim 1 further recites the additional elements the processing device performing the various steps and claims 8 and 16 further recite the additional elements “a memory to store instructions; and a processing device operatively coupled to the memory” and a “non-transitory computer readable storage medium having instructions”, respectively. These additional elements, when considered individually or in combination, do not integrate the abstract idea into a practical application because the additional elements are recited at a high-level of generality (i.e., as a generic computer) such that it amounts to no more than mere instructions to apply the exception. Claims 1, 8, and 16 are directed to an abstract idea.
Under Step 2B of the patent eligibility analysis, the additional elements are evaluated to determine whether they amount to something “significantly more” than the recited abstract idea (i.e., an innovative concept).
The independent claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements amount to no more than mere instructions to apply the exception. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. Claims 1, 8 and 16 are not patent eligible.
Dependent Claims
The dependent claims are rejected under 35 USC 101 as directed to an abstract idea for the following reasons.
Claims 2-5 recite the same abstract idea as the independent claim because generating the rule based on inputs is a part of the mental process.
Claim 2 further recites the additional elements of receiving inputs. These additional elements, when considered individually or in combination, do not integrate the abstract idea into a practical application because the additional elements encompass a generic computer function of receiving data (e.g., receiving input), see MPEP 2106.05(f)(2) (noting the use of computers in their ordinary capacity to receive, store, or transmit data does not integrate a judicial exception into a practical application).
Claim 7 recites the same abstract idea as the independent claims because an expiration of a time period is still within the scope of a mental process.
Claims 9 and 10 recite the same abstract idea as the independent claims because monitoring the data is still a part of a mental process.
Claims 11, 13, 14, and 18 recites the additional elements of transmitting the notification to a device, updating the value and transmitting the updated records. These additional elements, when considered individually or in combination, do not integrate the abstract idea into a practical application because the additional elements encompass a generic computer function of sending data and storing, see MPEP 2106.05(f)(2) (noting the use of computers in their ordinary capacity to receive, store, or transmit data does not integrate a judicial exception into a practical application).
Claim 15 recites the additional elements of a website associated with the merchant system. These additional elements, when considered individually or in combination, do not integrate the abstract idea into a practical application because the additional elements are only a general link to a field of use or technological environment, see MPEP 2106.05(h) (discussing Affinity Labs). That is, although these additional elements do limit the use of the abstract idea, this type of limitation merely confines the use of the abstract idea to a particular technological environment (e.g., the internet) and does not integrate the abstract idea into a practical application or add an inventive concept to the claims.
Claims 19 and 20 essentially recite the additional elements of searching for a data field. These additional elements, when considered individually or in combination, do not integrate the abstract idea into a practical application because the additional elements are only using software to tailor information and provide it to a user, which is not more than mere instructions to apply the exception, see MPEP 2106.05(f) (discussing Intellectual Ventures I LLC v. Capital One Bank (USA)).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-5, 7-11, 13-16, and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Application Publication No. 20120046998 A1 to Staib et al. (hereinafter Staib), in view of WIPO International Application Publication No. WO 2015103269 A1 to Vierra, in view of U.S. Patent Application Publication No. 20140358629 A1 to Shivaswamy et al. (hereinafter Shivaswamy), in view of U.S. Patent Application Publication No. 20150092227 A1 to Rosenberg et al. (hereinafter Rosenberg)
Referring to Claims 1, 8, and 16 (substantially similar in scope and language), Staib discloses a method, system and non-transitory computer readable storage medium (see at least Staib: ¶ 38-39) comprising:
monitoring, by a processing device, activity of a cluster of merchant systems comprising the first merchant system, wherein the activity relates to an updating of a plurality of data fields of business listings of the cluster of merchant systems;
Specifically, Staib discloses storing a rule associated with a data field of a business listing associated with a merchant system where the system includes a plurality of merchants and tracking activity of a business listing (see at least Staib: ¶ 15, 35, 39, 42-43, 46, 49-52, 56-66, and 81-83). Staib further discloses monitoring and recording data related to various merchants and activities associate with those merchants (see at least Staib: ¶ 48). Furthermore, the storage of information is further addressed by Staib (see at least Staib: ¶ 39, 42, 72, 76, 80, and 83-84).
Staib further discloses the system having the Price Updater module which is triggered by the price analyzer which “can periodically or on command be sent to analyze the price and market data obtained by the SSB and TS modules 170, 172 and then compute adjusted prices according to strategies and algorithms selected by the merchant” (see at least Staib: ¶ 49) and the price updater module “can be triggered by the PA module 174 or on a merchant command to push updated price data out to the appropriate sales channels” (see at least ¶ 58).
Staib does not explicitly state wherein the activity relates to an updating of a plurality of data fields of business listings of the cluster of merchant systems (further addressed below).
determining, by the processing device, in view of analytics based on the activity of the cluster of merchant systems, a frequency that the cluster of merchant systems updates a data field of the plurality of data fields associated with the first merchant system, wherein the data field is identified based on an updating frequency of the data field associated with other merchant systems in the cluster of merchant systems, wherein the rule is established based on one or more selections provided by the first merchant system and at least one of the analytics based on the activity of the first merchant and one or more search query activities associated with the first merchant system, and wherein the one or more selections indicate a first frequency to update a first data field and a second frequency different from the first frequency to update a second data field of the plurality of data fields
Examiner notes that Staib discloses the system applying pricing rules that are input by the user (see at least Staib: ¶ 59, 62. and 66), wherein sales status information such as trends, inventory levels, other measures of past success or difficulty with sales, and pricing results for other merchants or channels after detecting a pricing change should be explored (see at least Staib: ¶ 51).
Staib further discloses the system automatically updating multiple sales channels (see at least Staib: ¶ 36) wherein the update can be triggered automatically by the PA module or on a merchant command (see at least Staib: ¶ 58), wherein the merchant command and “the pricing rules are set up with easily varied parameters so that as data is collected the parameters can be updated (see at least Staib: ¶ 81).
Staib further discloses that the user can place restrictions on “how frequently” prices may be changed which amounts to inputting the frequency of updating a price for all stored items within the system (see at least Staib: ¶ 61 “there may be restrictions placed on how frequently prices may be changed”; see also Staib: ¶ 36 “system uses the new, channel-specific prices to update multiple sales channels used by the merchant for conducting business in conjunction with special sales channel recognition data that allows the merchant to pursue sales' goals”; see also Staib: ¶ 58 “the Price Updater (PU) module 176 can be triggered by the PA module 174 or on a merchant command to push updated price data out to the appropriate sales channels”; see also Staib: ¶ ).
Staib further discloses that the whole system operates on predefined price setting rules that analyzes sales status data in the database for the products and channels using predefined parameters (see at least Staib: ¶ 62), wherein the system is then directed to take one of the several paths “based on the price setting goal that is predefined in the price setting rules for Product XYZ for particular sales trends, seasonality, inventory levels and storage costs or selected by the user, if the goal is selectable at the time of analysis” (see at least Staib: ¶ 62).
Staib further discloses that the price setting rules are selected and defined by the merchant through goals, parameters, and constraints (see at least Staib: ¶ 49 “The merchant's objectives and constraints are embodied in a set of price setting rules, which may have a number of selling parameters that are adjustable across all products or are specific to only one product”; see also Staib: ¶ 57 “the price setting rules can be configured to incorporate complex calculations or cost constraints that vary by channel and by recent sale data from the channel”; see also Staib: ¶ 59 “FIG. 5 shows the general flow of analysis for an example of a set of price setting rules, which assumes that there is data in the database 142 for the products and channels to be analyzed, including the various parameters necessary to define the price setting rules”; see also Staib: ¶ 59-62, 66, and 81).
Staib further discloses that the price of the products can be adjusted at any defined frequency such as daily, yearly, weekly, or any other uniquely defined parameters (see Staib: ¶ 35 “system may optimize profit margin by considering sales channel characteristics and selling parameters controllable by a merchant other than price and costs, such as making an offer based on time of day, time of year and day of week that are unique to a channel, such as those that may be found on an auction site (for example, raise a price on Sundays)”; see also Staib: ¶ 48 “The demand curve constructed is used to find an optimized or more favorable price point for the particular product. In addition to testing the market for price, the TS module 172 can test the market for other selling parameters that may be unique to a particular channel, such as what are the optimal times of day or days of week for ending an auction or how long should an auction last. The TS module 172 monitors and records the selling parameters of all sales of these tests in the database for further analysis, in particular the development of price and demand curves.”; see also Staib: ¶ 56 “TS 172 may be statistically significant to model price/sales behavior for a given product by channel, time of day, day of week, season, web site entry page, customer location, quantity discount schedule or other variables”; see also Staib: ¶ 62, 66, 69, 73, 81, 89-91, and 93).
generating, by the processing device, based on the frequency, a rule defining a time period associated with updating the data field of the business listing associated with the first merchant system;
Specifically, Staib discloses monitoring, by processing device, the merchant system to determine an occurrence of an event corresponding to the rule (see at least Staib: ¶ 46-52).
Specifically, Staib discloses receiving a response from the merchant system comprising an updated value corresponding to the data field of the business listing (see at least Staib: ¶ 29, 36, 58, and 81).
Staib discloses storing the updated value corresponding to the data field in an updated record associated with the business listing and transmitting at least a portion of the updated record to a business listing provider system (see at least Staib: ¶ 29, 36, 58, and 81). Furthermore, the storage of information is further addressed by Staib (see at least Staib: ¶ 39, 42, 72, 76, 80, and 83-84).
Staib further discloses the system having the Price Updater module which is triggered by the price analyzer which “can periodically or on command be sent to analyze the price and market data obtained by the SSB and TS modules 170, 172 and then compute adjusted prices according to strategies and algorithms selected by the merchant” (see at least Staib: ¶ 49) and the price updater module “can be triggered by the PA module 174 or on a merchant command to push updated price data out to the appropriate sales channels” (see at least ¶ 58).
Examiner notes that Staib discloses the system applying pricing rules that are input by the user (see at least Staib: ¶ 59, 62. and 66), wherein sales status information such as trends, inventory levels, other measures of past success or difficulty with sales, and pricing results for other merchants or channels after detecting a pricing change should be explored (see at least Staib: ¶ 51).
Staib further discloses the system automatically updating multiple sales channels (see at least Staib: ¶ 36) wherein the update can be triggered automatically by the PA module or on a merchant command (see at least Staib: ¶ 58), wherein the merchant command and “the pricing rules are set up with easily varied parameters so that as data is collected the parameters can be updated (see at least Staib: ¶ 81).
Staib further discloses that the user can place restrictions on “how frequently” prices may be changed which amounts to inputting the frequency of updating a price for all stored items within the system (see at least Staib: ¶ 61 “there may be restrictions placed on how frequently prices may be changed”; see also Staib: ¶ 36 “system uses the new, channel-specific prices to update multiple sales channels used by the merchant for conducting business in conjunction with special sales channel recognition data that allows the merchant to pursue sales' goals”; see also Staib: ¶ 58 “the Price Updater (PU) module 176 can be triggered by the PA module 174 or on a merchant command to push updated price data out to the appropriate sales channels”; see also Staib: ¶ ).
Staib further discloses that the whole system operates on predefined price setting rules that analyzes sales status data in the database for the products and channels using predefined parameters (see at least Staib: ¶ 62), wherein the system is then directed to take one of the several paths “based on the price setting goal that is predefined in the price setting rules for Product XYZ for particular sales trends, seasonality, inventory levels and storage costs or selected by the user, if the goal is selectable at the time of analysis” (see at least Staib: ¶ 62).
Staib further discloses that the price setting rules are selected and defined by the merchant through goals, parameters, and constraints (see at least Staib: ¶ 49 “The merchant's objectives and constraints are embodied in a set of price setting rules, which may have a number of selling parameters that are adjustable across all products or are specific to only one product”; see also Staib: ¶ 57 “the price setting rules can be configured to incorporate complex calculations or cost constraints that vary by channel and by recent sale data from the channel”; see also Staib: ¶ 59 “FIG. 5 shows the general flow of analysis for an example of a set of price setting rules, which assumes that there is data in the database 142 for the products and channels to be analyzed, including the various parameters necessary to define the price setting rules”; see also Staib: ¶ 59-62, 66, and 81).
Staib further discloses that the price of the products can be adjusted at any defined frequency such as daily, yearly, weekly, or any other uniquely defined parameters (see Staib: ¶ 35 “system may optimize profit margin by considering sales channel characteristics and selling parameters controllable by a merchant other than price and costs, such as making an offer based on time of day, time of year and day of week that are unique to a channel, such as those that may be found on an auction site (for example, raise a price on Sundays)”; see also Staib: ¶ 48 “The demand curve constructed is used to find an optimized or more favorable price point for the particular product. In addition to testing the market for price, the TS module 172 can test the market for other selling parameters that may be unique to a particular channel, such as what are the optimal times of day or days of week for ending an auction or how long should an auction last. The TS module 172 monitors and records the selling parameters of all sales of these tests in the database for further analysis, in particular the development of price and demand curves.”; see also Staib: ¶ 56 “TS 172 may be statistically significant to model price/sales behavior for a given product by channel, time of day, day of week, season, web site entry page, customer location, quantity discount schedule or other variables”; see also Staib: ¶ 62, 66, 69, 73, 81, 89-91, and 93).
Staib discloses determining statistics (analytics) related to various activities of merchants but fails to explicitly state determines a frequency that the cluster of merchant systems updates a data field of the plurality of data fields associated with the first merchant system, wherein the data field is identified based on an updating frequency of the data field associated with other merchant systems in the cluster of merchant systems, and generating, by the processing device, based on the frequency, a rule defining a time period associated with updating the data field of a business listing associated with the first merchant system (further addressed below).
monitoring, by the processing device, the first merchant system to determine an occurrence of an event corresponding to the rule and the data field, wherein the event comprises passage of the time period during which no update to the data field has been made by the first merchant system
Examiner notes that this limitation is further addressed below.
in response to a request from a first user to update the rule, updating the rule when the request is approved by a second user, wherein the first user is a non-admin user of the first merchant system and the second user is an admin user of the first merchant system
Specifically, Staib discloses in response to the occurrence of the event, transmit a notification to the merchant system, wherein the notification includes a prompt to update a value stored in the data field of the business listing is submitted via a request from a merchant specifically (non-admin) or automatically adjusted based on the administrative capabilities of the system (admin request to update) (see at least Staib: ¶ 48, 51 and 58 “As seen in FIG. 1, the Price Updater (PU) module 176 can be triggered by the PA module 174 or on a merchant command to push updated price data out to the appropriate sales channels. This module is fairly standard to those familiar with the art, but is indispensable in implementing the price analysis results and achieving the merchant's goals. This can be implemented via database updates followed by generation of XML or CSV files which are then copied via FTP protocol to remote machines. Pursuing the merchants' goals on their self-managed ecommerce stores 180 is directly accomplished by the PA module 174 in updating the catalog database, or a merchant can choose to manually intervene through the PU and PA module controls”; see also Staib: ¶ 38 “Referring now to FIG. 1, the types of hardware and software within the computer system 100 may vary depending upon the implementation. For example, certain embodiments may have components, such as the display 110, keyboard 112, and/or printer 114, depending upon the specific capabilities of the system. In addition, the computer system 100 may support additional conventional functionality not described in detail herein, such as displaying images in a variety of formats, protecting the system from cyber-threats, allowing users to securely log into the system, and supporting administrative capabilities”).
Specifically, Staib discloses receiving a response from the merchant system comprising an updated value corresponding to the data field of the business listing (see at least Staib: ¶ 29, 36, 58, and 81).
Staib discloses storing the updated value corresponding to the data field in an updated record associated with the business listing and transmitting at least a portion of the updated record to a business listing provider system (see at least Staib: ¶ 29, 36, 58, and 81). Furthermore, the storage of information is further addressed by Staib (see at least Staib: ¶ 39, 42, 72, 76, 80, and 83-84).
Examiner notes that receiving a request from a first user that is not an admin user is further addressed below.
in response to the occurrence of the event, transmitting, by the processing device, a notification to the first merchant system transmitting, by the processing device, a notification to the first merchant system, wherein the notification comprises a prompt to update a value stored in the data field of the business listing first merchant system;
Specifically, Staib discloses in response to the occurrence of the event, transmit a notification to the merchant system, wherein the notification includes a prompt to update a value stored in the data field of the business listing (see at least Staib: ¶ 48, 51 and 58; see also ¶).
Specifically, Staib discloses receiving a response from the merchant system comprising an updated value corresponding to the data field of the business listing (see at least Staib: ¶ 29, 36, 58, and 81).
Staib discloses storing the updated value corresponding to the data field in an updated record associated with the business listing and transmitting at least a portion of the updated record to a business listing provider system (see at least Staib: ¶ 29, 36, 58, and 81). Furthermore, the storage of information is further addressed by Staib (see at least Staib: ¶ 39, 42, 72, 76, 80, and 83-84).
receiving, by the processing device, via a dialog interface associated with the first merchant system, a response from the merchant system comprising an updated value corresponding to the data field of the business listing of the first merchant system;
Specifically, Staib discloses receiving a response from the merchant system comprising an updated value corresponding to the data field of the business listing (see at least Staib: ¶ 29, 36, 58, and 81; see also ¶ 38 discussing user interfaces).
Staib discloses storing the updated value corresponding to the data field in an updated record associated with the business listing and transmitting at least a portion of the updated record to a business listing provider system (see at least Staib: ¶ 29, 36, 58, and 81). Furthermore, the storage of information is further addressed by Staib (see at least Staib: ¶ 39, 42, 72, 76, 80, and 83-84).
causing, by the processing device, the updated value corresponding to the data field to be stored in an updated record associated with the business listing; and
automatically transmitting, by the processing device, at least a portion of the updated record to a business listing provider system and displaying the business listing associated with the merchant system in response to a search query
Specifically, Staib discloses storing the updated value corresponding to the data field in an updated record associated with the business listing and transmitting at least a portion of the updated record to a business listing provider system displaying the business listing associated with the merchant system in response to a search query (see at least Staib: ¶ 29, 36, 58, 68, and 81). Furthermore, the storage of information is further addressed by Staib (see at least Staib: ¶ 39, 42, 72, 76, 80, and 83-84).
Staib does not explicitly state:
providing, in response to a search query associated with a first merchant system, a business listing of the first merchant system
monitoring, by a processing device, activity of a cluster of merchant systems comprising the first merchant system, wherein the activity relates to an updating of a plurality of data fields of business listings of the cluster of merchant systems
determining a frequency that the cluster of merchant systems updates a data field of the plurality of data fields associated with the first merchant system, wherein the data field is identified based on an updating frequency of the data field associated with other merchant systems in the cluster of merchant systems
generating, by the processing device, based on the frequency, a rule defining a time period associated with updating the data field of the business listing associated with the first merchant system
monitoring, by the processing device, the first merchant system to determine an occurrence of an event corresponding to the rule and the data field, wherein the event comprises passage of the time period during which no update to the data field has been made by the first merchant system
receiving a request from a non-admin user
automatically transmitting, by the processing device, a notification to the first merchant system via a communication platform of a plurality of communications platforms
and subsequent to the transmitting, providing, in response to a subsequent search query associated with the first merchant system, the business listing including the updated value
However, Vierra, which talks about a product re-pricing system, teaches using internet searches to search prices (see at least Vierra: ¶ 55)
Vierra further teaches it is known to monitor the activities of a plurality of merchants within the system wherein the activity related to the updating of data fields associated to a business listing of a particular merchant (see at least Vierra: ¶ 14-19, 36, 40-48, and 51-59).
Vierra further discloses a method and system for monitoring, by the processing device, the first merchant system to determine an occurrence of an event corresponding to the rule and the data field, wherein the event comprises passage of the time period during which no update to the data field has been made by the first merchant system (see at least Vierra: ¶ 14-19, 36, 40-48, and 51-59; see also ¶ 41 discussing the predetermined schedule or updating).
Vierra further teaches the system receiving a plurality of requests and demands for updating and adjusting price rules such as a request from a non-admin user (see at least Vierra: ¶ 18 “Examiner notes that receiving a request from a first user that is not an admin user is further addressed below.”; see also Vierra: ¶ 47-48).
Vierra further teaches transmitting data using various communications platforms, e.g., ¶ 13, 26.
Vierra further teaches using internet searches to search updated prices, e.g., every evening (see at least Vierra: ¶ 55)
Therefore, it would have been obvious to one of ordinary skill in the art at the time of filing to incorporate the feature of monitoring activity of a plurality of merchants and their respective listings, presenting updates and changes that is recommended based on the updates and changes made by competitors, and changing that merchants listing after notification and confirmation (as disclosed by Vierra) into the method and system for monitoring business listings via a computerized system where the system generates and transmits information related to business listings to merchants (as disclosed by Staib). One of ordinary skill in the art would have been motivated to incorporate the feature of monitoring activity of a plurality of merchants and their respective listings, presenting updates and changes that is recommended based on the updates and changes made by competitors, and changing that merchants listing after notification and confirmation because it would create an advantage of having the lower price for a particular product prior to one or more competitors lowering their prices for the particular product (see Vierra: ¶ 18).
Furthermore, it would have been obvious to one of ordinary skill in the art at the time of filing to incorporate the feature of monitoring activity of a plurality of merchants and their respective listings, presenting updates and changes that is recommended based on the updates and changes made by competitors, and changing that merchants listing after notification and confirmation (as disclosed by Vierra) into the method and system for monitoring business listings via a computerized system where the system generates and transmits information related to business listings to merchants (as disclosed by Staib), because the claimed invention is merely a simple arrangement of old elements, with each performing the same function it had been known to perform, yielding no more than one would expect from such arrangement. See KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 406 (2007). In other words, all of the claimed elements were known in the prior art and one skilled in the art could have combined the elements as claimed by known methods with no change in their respective functions, and the combination would have yielded nothing more than predictable results to one of ordinary skill in the art at the time of the invention (i.e., predictable results are obtained by adding the well-known feature of monitoring activity of a plurality of merchants and their respective listings, presenting updates and changes that is recommended based on the updates and changes made by competitors, and changing that merchants listing after notification and confirmation into the method and system for monitoring business listings via a computerized system where the system generates and transmits information related to business listings to merchants). See also MPEP § 2143(I)(A).
The combination of Staib and Vierra fails to state:
determining a frequency that the cluster of merchant systems updates a data field of the plurality of data fields associated with the first merchant system, wherein the data field is identified based on an updating frequency of the data field associated with other merchant systems in the cluster of merchant systems
generating, by the processing device, based on the frequency, a rule defining a time period associated with updating the data field of the business listing associated with the first merchant system
Examiner notes that Staib discloses the system applying pricing rules that are input by the user (see at least Staib: ¶ 59, 62. and 66), wherein sales status information such as trends, inventory levels, other measures of past success or difficulty with sales, and pricing results for other merchants or channels after detecting a pricing change should be explored (see at least Staib: ¶ 51).
Staib further discloses the system automatically updating multiple sales channels (see at least Staib: ¶ 36) wherein the update can be triggered automatically by the PA module or on a merchant command (see at least Staib: ¶ 58), wherein the merchant command and “the pricing rules are set up with easily varied parameters so that as data is collected the parameters can be updated (see at least Staib: ¶ 81).
Staib further discloses that the user can place restrictions on “how frequently” prices may be changed which amounts to inputting the frequency of updating a price for all stored items within the system (see at least Staib: ¶ 61 “there may be restrictions placed on how frequently prices may be changed”; see also Staib: ¶ 36 “system uses the new, channel-specific prices to update multiple sales channels used by the merchant for conducting business in conjunction with special sales channel recognition data that allows the merchant to pursue sales' goals”; see also Staib: ¶ 58 “the Price Updater (PU) module 176 can be triggered by the PA module 174 or on a merchant command to push updated price data out to the appropriate sales channels”; see also Staib: ¶ ).
Staib further discloses that the whole system operates on predefined price setting rules that analyzes sales status data in the database for the products and channels using predefined parameters (see at least Staib: ¶ 62), wherein the system is then directed to take one of the several paths “based on the price setting goal that is predefined in the price setting rules for Product XYZ for particular sales trends, seasonality, inventory levels and storage costs or selected by the user, if the goal is selectable at the time of analysis” (see at least Staib: ¶ 62).
Staib further discloses that the price setting rules are selected and defined by the merchant through goals, parameters, and constraints (see at least Staib: ¶ 49 “The merchant's objectives and constraints are embodied in a set of price setting rules, which may have a number of selling parameters that are adjustable across all products or are specific to only one product”; see also Staib: ¶ 57 “the price setting rules can be configured to incorporate complex calculations or cost constraints that vary by channel and by recent sale data from the channel”; see also Staib: ¶ 59 “FIG. 5 shows the general flow of analysis for an example of a set of price setting rules, which assumes that there is data in the database 142 for the products and channels to be analyzed, including the various parameters necessary to define the price setting rules”; see also Staib: ¶ 59-62, 66, and 81).
Staib further discloses that the price of the products can be adjusted at any defined frequency such as daily, yearly, weekly, or any other uniquely defined parameters (see Staib: ¶ 35 “system may optimize profit margin by considering sales channel characteristics and selling parameters controllable by a merchant other than price and costs, such as making an offer based on time of day, time of year and day of week that are unique to a channel, such as those that may be found on an auction site (for example, raise a price on Sundays)”; see also Staib: ¶ 48 “The demand curve constructed is used to find an optimized or more favorable price point for the particular product. In addition to testing the market for price, the TS module 172 can test the market for other selling parameters that may be unique to a particular channel, such as what are the optimal times of day or days of week for ending an auction or how long should an auction last. The TS module 172 monitors and records the selling parameters of all sales of these tests in the database for further analysis, in particular the development of price and demand curves.”; see also Staib: ¶ 56 “TS 172 may be statistically significant to model price/sales behavior for a given product by channel, time of day, day of week, season, web site entry page, customer location, quantity discount schedule or other variables”; see also Staib: ¶ 62, 66, 69, 73, 81, 89-91, and 93).
However, Shivaswamy, which talks about techniques for competitive pricing analysis and inventory management are described. According to various exemplary embodiments, a competitive pricing system is configured to crawl competitor websites for comparative pricing information at various time intervals, teaches determining, by the processing device, in view of analytics based on the activity of the cluster of merchant systems a frequency that the cluster of merchant systems updates a data field of the plurality of data fields associated with the first merchant system, wherein the data field is identified based on an updating frequency of the data field associated with other merchant systems in the cluster of merchant systems, generating, by the processing device, based on the frequency, a rule defining a time period associated with updating of a data field of a business listing associated with the first merchant system in that “the crawling module 202 is configured to determine the specific time interval, based on a popularity score associated with the first product offered for sale on the home retailer website. For example, by analyzing sales records and purchase history information associated with the home retailer website, the crawling module 202 may assign popularity scores to each of the products offered for sale, and may adjust the crawling intervals for crawling competitor pricing information of these products accordingly” (see at least Shivaswamy: ¶ 29 and 34). The Shivaswamy reference teaches “a competitive pricing system is configured to crawl competitor websites for comparative pricing information at various time intervals” (see at least Shivaswamy: Abstract).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of filing to apply the known technique of determining, by the processing device, in view of analytics based on the activity of the cluster of merchant systems a frequency that the cluster of merchant systems updates a data field of the plurality of data fields, generating, by the processing device, based on the frequency, a rule defining a time period associated with updating of a data field of a business listing associated with the first merchant system (as disclosed by Shivaswamy) to the known method and system for monitoring business listings via a computerized system where the system generates and transmits information related to business listings to merchants (as disclosed by the combination of Staib and Vierra) to <>. One of ordinary skill in the art would have been motivated to apply the known technique of determining, by the processing device, in view of analytics based on the activity of the cluster of merchant systems a frequency that the cluster of merchant systems updates a data field of the plurality of data fields, generating, by the processing device, based on the frequency, a rule defining a time period associated with updating of a data field of a business listing associated with the first merchant system because it would provide a system configured to crawl competitor websites for comparative pricing information at various time intervals (see Shivaswamy ¶ 73).
Furthermore, it would have been obvious to one of ordinary skill in the art at the time of filing to apply the known technique of determining, by the processing device, in view of analytics based on the activity of the cluster of merchant systems a frequency that the cluster of merchant systems updates a data field of the plurality of data fields, generating, by the processing device, based on the frequency, a rule defining a time period associated with updating of a data field of a business listing associated with the first merchant system to the known method and system for monitoring business listings via a computerized system where the system generates and transmits information related to business listings to merchants (as disclosed by the combination of Staib and Vierra) to provide a system configured to crawl competitor websites for comparative pricing information at various time intervals, because the claimed invention is merely applying a known technique to a known method ready for improvement to yield predictable results. See KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 406 (2007). In other words, all of the claimed elements were known in the prior art and one skilled in the art could have combined the elements as claimed by known methods with no change in their respective functions, and the combination would have yielded nothing more than predictable results to one of ordinary skill in the art at the time of the invention (i.e., predictable results are obtained by applying the known technique of determining, by the processing device, in view of analytics based on the activity of the cluster of merchant systems a frequency that the cluster of merchant systems updates a data field of the plurality of data fields, generating, by the processing device, based on the frequency, a rule defining a time period associated with updating of a data field of a business listing associated with the first merchant system to the known method and system for monitoring business listings via a computerized system where the system generates and transmits information related to business listings to merchants to provide a system configured to crawl competitor websites for comparative pricing information at various time intervals). See also MPEP § 2143(I)(D).
However the combination of Staib, Vierra and Shivaswamy does not teach but Rosenberg does teach:
and wherein updating the value comprises completing a missing data field of the business listing
Rosenberg teaches a conversion process that completes missing data and corrects data, ¶ 42, 87, and 88 and Fig. 4
Further, it would have been obvious before the effective filing date of the claimed invention, to combine the online merchant price setting of Staib, Vierra and Shivaswamy with the data conversion of Rosenberg because known work in one field of endeavor may prompt variations of it for use in the same field based on design incentives, see MPEP 2143.I.F. That is, one of ordinary skill would have recognized the data gathered in Staib, Vierra and Shivaswamy may be incomplete and would have modified Staib, Vierra and Shivaswamy to address situations where the gathered data is complete, e.g., as in Rosenberg
Referring to Claim 8, Staib discloses the additional claim language directed to a system comprising: a memory to store instructions; and a processing device operatively coupled to the memory,
Staib discloses a memory to store instructions; and a processing device operatively coupled to the memory (see at least Staib: ¶ 38-39). Furthermore, the storage of information is further addressed by Staib (see at least Staib: ¶ 39, 42, 72, 76, 80, and 83-84). Therefore, the combination teaches the limitations.
Referring to Claim 2, The combination of Staib, Vierra, Shivaswamy and Rosenberg teaches the method of claim 1, Staib discloses further comprising: receiving, from the merchant system, one or more inputs identifying the data field and a time parameter corresponding to the rule; and generating the rule based on the one or more inputs (see at least Staib: ¶ 11, 35, 48, 56, 59, 69, 81, and 88-93).
Referring to Claim 3, The combination of Staib, Vierra, Shivaswamy and Rosenberg teaches the method of claim 1, Staib discloses further comprising generating, by the processing device, the rule, wherein the rule identifies the data field and a time parameter (see at least Staib: ¶15, 35, 39, 42-43, 46, 49-52, 56-66, and 81-83).
Referring to Claim 4, The combination of Staib, Vierra, Shivaswamy and Rosenberg teaches the method of claim 3, Staib discloses wherein the time parameter comprises a time frame during which at least one of the notification or one or more follow-up notifications are to be transmitted to the merchant system (see at least Staib: ¶ 11, 35, 48, 56, 59, 69, 81, and 88-93).
Referring to Claim 5, The combination of Staib, Vierra, Shivaswamy and Rosenberg teaches the method of claim 4, Staib discloses wherein the time parameter comprises a frequency associated with transmitting the notification or the one or more follow-up notifications (see at least Staib: ¶ 11, 35, 48, 56, 59, 69, 81, and 88-93).
Referring to Claim 7, The combination of Staib, Vierra, Shivaswamy and Rosenberg teaches the method of claim 1, Staib discloses wherein the event comprises an expiration of a time period associated with updating the data field (see at least Staib: ¶ 11, 35, 48, 56, 59, 69, 81, and 88-93; see also see at least Staib: ¶ 29, 36, 58, and 81).
Referring to Claim 9, The combination of Staib, Vierra, Shivaswamy and Rosenberg teaches the system of claim 8, including wherein the activity comprises a set of data relating to updates to the data field by a plurality of third party systems in a cluster comprising the merchant system (see at least Staib: ¶ 68).
Referring to Claim 10, The combination of Staib, Vierra, Shivaswamy and Rosenberg teaches the system of claim 8, including wherein the activity comprises a set of data relating to updates to the data field by the merchant system (see at least Staib: ¶ 29, 36, 58, and 81).
Referring to Claim 11, The combination of Staib, Vierra, Shivaswamy and Rosenberg teaches the system of claim 8, including wherein the notification is transmitted to one or more devices associated with the merchant system (see at least Staib: ¶ 29, 36, 48, 51, 58, and 81).
Referring to Claim 13, The combination of Staib, Vierra, Shivaswamy and Rosenberg teaches the system of claim 12, including wherein the updated value comprises at least one of new data to complete the data field, a changed value for data corresponding to the data field, or additional data added to the data field (see at least Staib: ¶ 29, 36, 58, and 81).
Referring to Claim 14, The combination of Staib, Vierra, Shivaswamy and Rosenberg teaches the system of claim 12, including the processing device to execute the instructions to transmit at least a portion of the updated record to a business listing provider system (see at least Staib: ¶ 29, 36, 58, and 81).
Referring to Claim 15, The combination of Staib, Vierra, Shivaswamy and Rosenberg teaches the system of claim 14, including wherein the business listing provider system comprises at least one of a website associated with the merchant system or a third party search engine system (see at least Staib: ¶ 68).
Referring to Claim 18, The combination of Staib, Vierra, Shivaswamy and Rosenberg teaches the non-transitory computer readable storage medium of claim 17, including the processing device further to transmit the updated record to a business listing provider system (see at least Staib: ¶ 29, 36, 58, and 81).
Referring to Claim 19, The combination of Staib, Vierra, Shivaswamy and Rosenberg teaches the non-transitory computer readable storage medium of claim 16, including wherein the processing device identifies the data field to target for updating based on determining that a search activity associated with the data field satisfies a search activity condition, wherein the search activity comprises search queries executed by an end user systems relating to business listing data of the merchant system. Staib and Vierra fail to specifically disclose wherein the processing device identifies the data field to target for updating based on determining that a search activity associated with the data field satisfies a search activity condition, wherein the search activity comprises search queries executed by an end user systems relating to business listing data of the merchant system.
However, Shivaswamy teaches wherein the processing device identifies the data field to target for updating based on determining that a search activity associated with the data field satisfies a search activity condition, wherein the search activity comprises search queries executed by an end user systems relating to business listing data of the merchant system in that “the crawling module 202 is configured to determine the specific time interval, based on a popularity score associated with the first product offered for sale on the home retailer website. For example, by analyzing sales records and purchase history information associated with the home retailer website, the crawling module 202 may assign popularity scores to each of the products offered for sale, and may adjust the crawling intervals for crawling competitor pricing information of these products accordingly” (see at least Shivaswamy: ¶ 29 and 34).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of filing to apply the known technique of determining, by the processing device, in view of analytics based on the activity of the cluster of merchant systems a frequency that the cluster of merchant systems updates a data field of the plurality of data fields, generating, by the processing device, based on the frequency, a rule defining a time period associated with updating of a data field of a business listing associated with the first merchant system (as disclosed by Shivaswamy) to the known method and system for monitoring business listings via a computerized system where the system generates and transmits information related to business listings to merchants (as disclosed by the combination of Staib and Vierra) to <>. One of ordinary skill in the art would have been motivated to apply the known technique of determining, by the processing device, in view of analytics based on the activity of the cluster of merchant systems a frequency that the cluster of merchant systems updates a data field of the plurality of data fields, generating, by the processing device, based on the frequency, a rule defining a time period associated with updating of a data field of a business listing associated with the first merchant system because it would provide a system configured to crawl competitor websites for comparative pricing information at various time intervals (see Shivaswamy ¶ 73).
Referring to Claim 20, The combination of Staib, Vierra, and Katzin teaches the non-transitory computer readable storage medium of claim 19, including wherein the search activity condition comprises a first percentage of search activity associated with the data field exceeds a threshold value of a total search activity associated with the business listing (see at least Staib: ¶ 51, 57, 68, 81, and 86).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BRENDAN S O'SHEA whose telephone number is (571)270-1064. The examiner can normally be reached Monday to Friday 11-7.
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, Nathan Uber can be reached at (571) 270-3923. 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.
/BRENDAN S O'SHEA/Examiner, Art Unit 3626
Prosecution Insights