DETAILED ACTION
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 .
Priority
The examiner acknowledges Applicant’s claim of benefit to Provisional Patent Application No. 63/647,152 filed on 5/14/2024.
Information Disclosure Statement
The information disclosure statement (IDS) filed on 8/12/2025 has been considered by the Examiner.
Status of Claims
Applicant’s communications filed on 5/14/2025 have been considered.
Claims 1-20 are currently pending and have been examined.
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 do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitations are:
means for receiving a type of venue selection in claim 9
means for receiving at least one preference in claim 9
means for providing, via an artificial intelligence model, at least one recommendation of a venue in claim 9
means for receiving feedback in claim 9
means for providing the feedback in claim 9
means for determining in claim 10
means for prompting in claim 10
means for determining in claim 15
means for prompting in claim 15
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof. Claims 11 and 12 inherit the interpretation as discussed with regards to claims 9 and 10 by virtue of their respective dependencies.
Note: The means-plus-function limitations in claims 9 and 10 have been interpreted differently than those recited in claim 15, as the limitations of claims 9 and 10 are directed to the user interface of claim 9, while the limitations of claim 15 are directed to the mobile device of claim 13.
Regarding claim 9, the specification discloses that the system, executed on a mobile terminal or device, comprises a processor executing instructions stored on a non-transitory computer readable medium, causing the system to receive user inputs via a graphical user interface (GUI) of the mobile device (see at least [0042][Figs. 8-16]). The specification further discloses that the graphical user interface prompts the user to select a type of venue ([Fig. 3][0052][Fig. 9]), select preferences ([Fig. 3][0052][Fig. 10]), and provide feedback ([Fig. 3][0054][Fig. 15]), where the feedback is sent to the server to be stored in memory and used to update the model to improve recommendations ([Fig. 3][0055]). Regarding claim 10, the specification discloses that the user device prompts the user for feedback of the selected venue upon a GPS sensor in the user device determining that the user device is in the location of the selected venue. A feedback screen is subsequently generated and presented on the graphical user interface of the user device ([Fig. 3][0054][Fig. 15]). While the specification does not explicitly disclose the claimed means of claim 9 as a graphical user interface generated by the system, it describes functions that one of ordinary skill in the art would recognize as being performed on a graphical user interface provided by a system comprising a processor, including receiving a type of venue selection, receiving at least one preference, providing at least one recommendation of a venue, and receiving and providing feedback. Accordingly, “means for receiving a type of venue selection”, “means for receiving at least one preference”, “means for providing, via an artificial intelligence model, at least one recommendation of a venue”, “means for receiving feedback”, “means for providing the feedback”, “means for determining that the user is located at the recommended venue,” and “means for prompting the user for the feedback” have been interpreted as encompassing graphical user interface functionality provided by a processor-based system.
Regarding claim 15, the specification discloses that a GPS sensor in the user device determines that the user device is in the location of the selected venue ([Fig. 3][0054]). Accordingly, “means for determining that the user is located at the recommended venue” has been interpreted as GPS sensor functionality provided by a mobile device. The specification further discloses the graphical user interface prompting a user for feedback upon the GPS sensor determining that the user device is in the location of the selected venue, via a feedback screen ([Fig. 3][0054][Fig. 15]). Accordingly, “means for prompting the user for the feedback” has been interpreted as encompassing graphical user interface functionality provided by a processor-based system, further in view of the above paragraph.
If applicant does not intend to have this/these limitation(s) 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 avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Objections
Claim 1-8 are objected to because of the following informalities:
Claim 1 (as interpreted) recites the limitation “wherein the machine learning model is configured to dynamically adapt to evolving user preferences over time, and the method is implemented within a networked computing environment comprising a mobile device and a server system”. Appropriate correction is required.
Claim 1 (as interpreted) recites the limitation “receiving at least one user preference related to a selected type of venue”. Appropriate correction is required.
Dependent claims 2-8 inherit the objection of independent claim 1, noted above.
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 an abstract idea without significantly more. The claims recite an abstract idea. The judicial exception is not integrated into a practical application. The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception.
Under Step 1 of the Subject Matter Eligibility Test for Products and Processes, the claims must be directed to one of the four statutory categories. See MPEP 2106.03. Claims 1-8 are directed towards a process. Claims 9-20 are directed towards a machine. Therefore, claims 1-20 are directed to one of the four statutory categories (Step 1: YES, regarding claims 1-20).
Under Step 2A of the MPEP, it is determined whether the claims are directed to a judicially recognized exception. See MPEP 2106.04. Step 2A is a two-prong inquiry.
Under Prong 1, it is determined whether the claim recites a judicial exception. In determining whether the claims are directed to a judicial exception, the claims are analyzed to evaluate whether the claims recite a judicial exception.
Taking Claim 1 as representative, claim 1 recites limitations that fall within the certain methods of organizing human activity groupings of abstract ideas, including:
A method for recommending a venue to a user comprising:
receiving a user input indicating a type of venue selection;
receiving at least one user preference related to the selected type of venue;
providing at least one recommendation of a venue based on the selected type of venue and the user preference;
receiving user feedback on the recommendation; and
using the feedback to improve accuracy of future venue recommendations,
adapt to evolving user preferences over time, and
the method is implemented.
Claim 9 additionally recites the same abstract limitations as recited in claim 1.
Claim 13 additionally recites the following abstract limitations:
recommending a venue to a user comprising:
receiving a user input indicating a selection of a type of venue;
receiving at least one user preference associated with the selected type of venue;
generating at least one venue recommendation based on the selected type of venue and the user preference;
transmitting the at least one venue recommendation for display;
receiving feedback related to the recommended venue; and
using the feedback to improve accuracy of future venue recommendations.
Claim 1, 9 and 13 recite certain methods of organizing human activity, such as performing commercial interactions. See MPEP 2106.04(a)(2). The MPEP defines the “Certain Methods of Organizing Human Activity” grouping as including fundamental economic principles or practices (including hedging, insurance, mitigating risk); commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations); managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions) (see MPEP § 2106.04(a)(2). The abstract ideas recited in representative claims 1, 9 and 13 are certain methods of organizing human activity because receiving user preferences associated with a type of venue, generating a venue recommendation based on the type of venue and user preference, receiving user feedback on the recommendation, and using the feedback to improve accuracy of future venue recommendations is a commercial or legal interaction because it is an advertising, marketing or sales activity, or business relations.
Accordingly, under Prong One of Step 2A of the Alice/Mayo test, claims 1, 9 and 13 recite an abstract idea (Step 2A, Prong One: YES).
Under Step 2A (prong 2), if it is determined that the claims recite a judicial exception, it is then necessary to evaluate whether the claims recite additional elements that integrate the judicial exception into a practical application of that exception (see MPEP 2106.04). As stated in the MPEP, when “an additional element merely recites the words ‘apply it (or an equivalent) with the judicial exception, or merely uses a computer as a tool to perform an abstract idea,” the judicial exception has not been integrated into a practical application. In this case, representative claim 1 includes additional elements such as (additional elements are bolded):
A computer-implemented method for recommending a venue to a user comprising:
executing, by a processor of a computing device, instructions stored in a non- transitory computer-readable medium, wherein the instructions cause the computing device to perform:
receiving, via a graphical user interface (GUI) of a venue recommendation application, a user input indicating a type of venue selection;
receiving at least one user preference related to the selected type of venue;
providing, using a trained machine learning model executed by the processor, at least one recommendation of a venue based on the selected type of venue and the user preference;
receiving, through the GUI, user feedback on the recommendation; and
updating the machine learning model using the feedback via an incremental learning algorithm to improve accuracy of future venue recommendations,
wherein the machine learning model is configured to dynamically adapt to evolving user preferences over time, and
the method is implemented within a networked computing environment comprising a mobile device and a server system.
Claim 9 additionally recites the following additional elements:
A user interface for recommending a venue to a user comprising:
means for receiving a type of venue selection;
means for receiving at least one preference related to the selected type of venue;
means for providing, via an artificial intelligence model, at least one recommendation of a venue based on the selected type of venue and preference;
means for receiving feedback on the selected preferences of the recommended venue; and
means for providing the feedback to the artificial intelligence model to improve an accuracy of a subsequent recommendation.
Claim 13 additionally recites the following additional elements:
A system for recommending a venue to a user comprising: at least one processing device; a non-transitory computer-readable medium storing instructions that, when executed by the at least one processing device, cause the system to:
receiving, over a network, from a mobile device, a user input indicating a selection of a type of venue via a graphical user interface (GUI);
receiving, from the mobile device, at least one user preference associated with the selected type of venue;
generating, using a trained machine learning model executed by the at least one processing device, at least one venue recommendation based on the selected type of venue and the user preference;
transmitting the at least one venue recommendation to the mobile device for display on the GUI;
receiving, from the mobile device, feedback related to the recommended venue; and
updating the machine learning model using the feedback via an incremental learning algorithm to improve accuracy of future venue recommendations,
wherein the system is configured to operate in a distributed computing environment including the mobile device and a server system, and
the machine learning model is dynamically updated without requiring retraining.
These additional elements are described at a high level in Applicant’s specification without any meaningful detail about their structure or configuration. As such, these computer-related limitations are not found to be sufficient to integrate the abstract idea into a practical application. Claims 1, 9 and 13 specifying that the abstract idea is executed in a computer environment merely indicates a field of use in which to apply the abstract idea because this requirement merely limits the claims to the computer field, i.e., to execution on a generic computer. As such, under Prong Two of Step 2A of the Alice/Mayo test, when considered both individually and as a whole, the limitations of claims 1, 9 and 13 are not indicative of integration into a practical application (Step 2A, Prong Two: NO).
Since claims 1, 9 and 13 recite an abstract idea and fail to integrate the abstract idea into a practical application, claims 1, 9 and 13 are “directed to” an abstract idea (Step 2A: YES). Accordingly, the judicial exception is not integrated into a practical application.
Next, under Step 2B, examiners should evaluate additional elements individually and in combination to determine whether they provide an inventive concept (i.e., whether the additional elements amount to significantly more than the exception itself). In this case, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. Returning to representative claims 1, 9 and 13, taken individually or as a whole the additional elements of claims 1, 9 and 13 amount to no more than mere instructions to apply the exception using a generic computer and/or no more than a general link to a technological environment. For the same reason these elements are not sufficient to provide an inventive concept. Therefore when considering the additional elements alone, and in combination, there is no inventive concept in the claim, and thus the claim is not patent eligible (Step 2B: NO).
Dependent claims 2-8, 10-12, and 14-20, when analyzed as a whole, are held to be patent ineligible under 35 U.S.C. 101 because they do not add “significantly more” to the abstract idea. As for dependent claims 2-5, 7, 10-12, 15, and 19, these claims recite limitations that further define the same abstract idea noted in independent claims 1, 9 and 13, and do not recite any additional elements other than what is disclosed in independent claims 1, 9 and 13. Therefore, claims 2-5, 7, 10-12, 15, and 19 are considered patent ineligible for the reasons given above.
As for dependent claims 6, 8, 14, 16-18, and 20, these claims recite limitations that further define the abstract idea noted in independent claims 1, 9 and 13. Additionally, they recite the following additional limitations:
wherein the prompting is generated on a user interface of a mobile device;
storing, in a memory, the received at least one user preference;
determining, via a sensor, a location of the user;
further comprising a plurality of mobile devices, wherein each mobile device provides feedback to create crowd-sourced feedback;
wherein the trained machine learning model comprises a neural network or gradient-boosted decision tree trained on historical venue selection data;
wherein the feedback is used to adjust model weights in real-time using a learning algorithm; and
wherein the mobile device comprises a smartphone, tablet, or wearable device configured to communicate with the server system via a RESTful API.
The additional elements of a user interface of a mobile device, a memory, a sensor, a plurality of mobile devices, wherein the trained machine learning model comprises a neural network or gradient-boosted decision tree trained, using a learning algorithm, and wherein the mobile device comprises a smartphone, tablet, or wearable device configured to communicate with the server system via a RESTful API are all recited at a high level of generality such that they amount to no more than instructions to apply the judicial exception in a generic technological environment. Even in combination, these additional elements do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself. Accordingly, under the Alice/Mayo test, claims 1-20 are ineligible.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 9 is/are rejected under 35 U.S.C. 102(a)(1) and (a)(2) as being anticipated by Wilson et al. (US 2022/0207575 A1).
Regarding Claim 9, Wilson discloses A user interface for recommending a venue to a user comprising ([Fig. 14]; [0130-0132] user interface for deployment at a web portal or client device such as… a smart phone; [0306] users trigger the recommendation engine 112 by entering through a web portal, client application, etc.… a request for a recommendation; see [Fig. 1A][0064] functionality described herein may be relocated to a client device application (such as a smart phone application)):
means for receiving a type of venue selection ([0306] users trigger the recommendation engine 112 by entering through a web portal, client application, etc… a request for a recommendation be generated based on provided venue attributes such as… type; see [0084] in response to a triggering event such as a request for a new recommendation the system required the user to input various data including… favorite venue information (in one or more venue categories); [Fig. 1A][0064]);
means for receiving at least one preference related to the selected type of venue ([0306-0307] users trigger the recommendation engine 112 by entering through a web portal, client application, etc… a request for a recommendation be generated… the user may request recommendations filtered by various venue attributes and may request a venue near particular coordinates; [Fig. 1A][0064]);
means for providing, via an artificial intelligence model, at least one recommendation of a venue based on the selected type of venue and preference ([0306-0307] users trigger the recommendation engine 112 by entering through a web portal, client application, etc… a request for a recommendation be generated… the user may request recommendations filtered by various venue attributes and may request a venue near particular coordinates; [0311] the recommendation engine personalizes recommendations by applying user attribute weights to the venues and venue attributes… to provide a total excitation score for each venue… a ranked listing of the venues can be provided to the user based on score; see [Fig. 14][0132] recommendation panel 1410; [Fig. 1A][0064]; [0187] the recommendation engine 112 determines a recommendation set based on the neural network methodology);
means for receiving feedback on the selected preferences of the recommended venue ([0350] Users may provide feedback on recommendations that they are given, which can be either binary (approve or disapprove) or they can be continuous (e.g., 1 to 10, or −10 to 10); see [Fig. 14][0133] The panel also provides buttons to book a reservation; [Fig. 1A][0064]); and
means for providing the feedback to the artificial intelligence model to improve an accuracy of a subsequent recommendation ([317] recommendation processing described herein with respect to various link strengths can be used… to provide recommendations to the user; see [0113] Users' feedback concerning recommended venues and the associated “take rates” may likewise be factored in by the recommendation engine… link strengths may be increased for venues for which users more frequently make reservations based on the recommendations; [0188-0189] the recommendation engine 112 compares the current recommendation to aggregate recommendation data stored in the data repository 118… to determine and propagate deficiencies into the neural network to establish increased accuracy within the nodal links, including increasing link strength; [Fig. 14][0133] The panel also provides buttons to book a reservation).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-2, 7-8, 13-14, and 16-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Wilson et al. in view of Buzzell et al. (US 2023/0377023 A1).
Regarding Claim 1, Wilson discloses A computer-implemented method for recommending a venue to a user comprising ([Fig. 38]; [0307]):
executing, by a processor of a computing device, instructions stored in a non-transitory computer-readable medium, wherein the instructions cause the computing device to perform ([Fig. 1A][0064-0066]; see [0365] method steps are performed by a programmable processor executing a program of instructions to perform functions of the described implementations by operating on input data and generating output):
receiving, via a graphical user interface (GUI) of a venue recommendation application, a user input indicating a type of venue selection ([Fig. 38]; [0307] receiving a recommendation request from a user for a personalized recommendation; see [0306] users 108 may trigger the recommendation engine 112… by entering through a client application a request that a recommendation be generated based on provided venue attributes such as… type; [0312-0314] a user request for an American restaurant);
receiving at least one user preference related to a selected type of venue ([Fig. 38]; [0306-0307] accessing a user profile to collect the user attribute data identified in FIG. 30 from the user profile such as other venues liked, gender, profession, or age… the user may request recommendations filtered by various venue attributes and may request a venue near particular coordinates; [0312-0314] parsing a recommendation request (e.g., a user request for recommendations for an American restaurant) to determine venue attributes and user weighting values; see [0084-0085] in response to a triggering event such as a request for a new recommendation… the user is asked to list favorite or preferred venues);
providing, using a machine learning model executed by the processor, at least one recommendation of a venue based on the selected type of venue and the user preference ([Fig. 38]; [0306-0310] the user may enter a recommendation request based on type… the user may request recommendations filtered by various venue attributes and may request a venue near particular coordinates; [0311] the recommendation engine personalizes recommendations by applying user attribute weights to the venues and venue attributes… to provide a total excitation score for each venue… a ranked listing of the venues can be provided to the user based on score; see [Figs. 30 and 31] depicting user attributes and user weighting values; [0187] the recommendation engine 112 determines a recommendation set based on the neural network methodology; [0365]);
receiving, through the GUI, user feedback on the recommendation ([0350] Users may provide feedback on recommendations that they are given, which can be either binary (approve or disapprove) or they can be continuous (e.g., 1 to 10, or −10 to 10); [0362] The user can enter feedback on their recommendations by clicking on thumbs up / thumbs down or other feedback mechanisms); and
updating the machine learning model using the feedback to improve accuracy of future venue recommendations ([317] recommendation processing described herein with respect to various link strengths can be used… to provide recommendations to the user; see [0113] Users' feedback concerning recommended venues and the associated “take rates” may likewise be factored in by the recommendation engine… link strengths may be increased for venues for which users more frequently make reservations based on the recommendations; [0188-0189] the recommendation engine 112 compares the current recommendation to aggregate recommendation data stored in the data repository 118… to determine and propagate deficiencies into the neural network to establish increased accuracy within the nodal links, including increasing link strength… thereby ensuring increased consideration in any future recommendations provided by the recommendation engine),
wherein the machine learning model is configured to dynamically adapt to evolving user preferences over time ([0175] the recommendation engine 112 generates recommendations for venues based on… link strengths between nodes of the neural network; [0095] the neural network of links may be reweighted based on the fact that the user requesting a recommendation has affinities or attributes held in common with certain reviewers), and
the method is implemented within a networked computing environment comprising a mobile device and a server system ([0306] users 208 trigger the recommendation engine 112 by entering through a web portal via the network 120; [Fig 1A]; [0064-0067] client device application (such as a smart phone application)… user interface module 110 resides on the server 102).
Wilson discloses providing, using a machine learning model executed by the processor, at least one recommendation of a venue based on the selected type of venue and the user preference (see at least Wilson [Fig. 38]; [0187] [0306-0311]; [0365]), and updating the machine learning model using feedback to improve accuracy of future venue recommendations (see at least Wilson [0113][0188-0189][0317]). However, Wilson does not explicitly teach wherein the machine learning model is a trained machine learning model; and updating the machine learning model via an incremental learning algorithm.
However, in the field of providing personalized recommendations based on user preferences/habits (See at least Buzzell [abstract][0048-0049]), Buzzell, on the other hand, teaches wherein the machine learning model is a trained machine learning model ([0072] AI/ML Engines 420 can be implemented in Recommendation System 400, utilizing advanced algorithms and techniques to generate accurate and personalized recommendations; see [0055] the machine learning model architecture enables models to train on data sets before being deployed); and
updating the machine learning model via an incremental learning algorithm ([0111] collecting data on user interactions, feedback loops, and user preferences… the analysis identifies patterns, trends, and changes in user preferences over time… the recommendation system learns and adapts its models and algorithms to incorporate the evolving user preferences. This adaptation can involve updating the AI/ML models, adjusting weights or parameters).
The steps of Buzzell are applicable to the method of Wilson, as they share characteristics and capabilities, namely, they are directed to providing user recommendations according to user preferences. It would have been obvious to one of ordinary skill in the art at the time of filing to modify the recommendation method as taught by Wilson, to include wherein the machine learning model is a trained machine learning model; and updating the machine learning model via an incremental learning algorithm, as taught by Buzzell. One of ordinary skill in the art at the time of filing would have been motivated to expand the recommendation method of Wilson in order to enhance the recommendation process through continuously learning from data and generating more accurate and relevant recommendations that reflect evolving user preferences, ensuring a personalized user experience (Buzzell, [0071][0111]).
Regarding Claim 2, Wilson in view of Buzzell teaches the method of claim 1.
Wilson further discloses wherein the receiving feedback includes receiving crowd-sourced feedback from a plurality of users ([0350] Users may provide feedback on recommendations that they are given, which can be either binary (approve or disapprove) or they can be continuous (e.g., 1 to 10, or −10 to 10); [0362] The user can enter feedback on their recommendations by clicking on thumbs up / thumbs down or other feedback mechanisms; see [0113] Users' feedback concerning recommended venues and the associated “take rates” may likewise be factored in by the recommendation engine).
Regarding Claim 7, Wilson in view of Buzzell teaches the method of claim 1.
Wilson further discloses wherein the type of venue includes at least one of a restaurant, a bar, a pub, a night club, and/or an adult cabaret ([0056] venues may include restaurants; [0061] generating a night club recommendation; [0312-0314] parsing a recommendation request (e.g., a user request for recommendations for an American restaurant)).
Regarding Claim 8, Wilson in view of Buzzell teaches the method of claim 1.
Wilson further discloses storing, in a memory, the received at least one user preference ([0274] the matrix builder stores user data in the data repository 118… a list of preferred venues in various different venue categories is included in the user profile; see [Fig. 38]; [0306]);
determining, via a sensor, a location of the user ([Fig. 38]; [0308] the system 100 may determine the location of the user via GPS based on a user's mobile devices and applications); and
providing, using the machine learning model executed by the processor, at least one second recommendation of a venue based on the stored user preference and determined location ([Fig. 38]; [0306-0315] the user may request recommendations filtered by various venue attributes and may request a venue near particular coordinates … a recommendation request from a user for a personalized recommendation based on a location of the user… a ranked listing of the venues can be provided to the user based on score. The recommendation engine 112 can also provide a plurality of venues to give the user some choice by always providing a predetermined amount of venues; [0187] the recommendation engine 112 determines a recommendation set based on the neural network methodology). However, Wilson does not explicitly teach wherein the model is the trained machine learning model.
Buzzell, on the other hand, teaches wherein the machine learning model is the trained machine learning model ([0072] AI/ML Engines 420 can be implemented in Recommendation System 400, utilizing advanced algorithms and techniques to generate accurate and personalized recommendations; see [0055] the machine learning model architecture enables models to train on data sets before being deployed).
It would have been obvious to one of ordinary skill in the art at the time of filing to modify the recommendation method as taught by Wilson, to include wherein the model is a trained machine learning model, as taught by Buzzell, for the same reasons discussed above with respect to claim 1.
Regarding Claim 13, Wilson discloses A system for recommending a venue to a user comprising ([Fig. 1A]; [0064-0067]; [0306]):
at least one processing device ([Fig. 1A]; see [0365]);
a non-transitory computer-readable medium storing instructions that, when executed by the at least one processing device, cause the system to ([0365-0366]):
receiving, over a network, from a mobile device, a user input indicating a selection of a type of venue via a graphical user interface (GUI) ([Fig. 38]; [0307] receiving a recommendation request from a user for a personalized recommendation; see [0306] users 108 may trigger the recommendation engine 112… by entering through a client application a request that a recommendation be generated based on provided venue attributes such as… type; see [Fig. 1A] users 108 communicate with the system over network 120; [Fig. 14][0130-0146] an exemplary user interface for deployment at a web portal or client device such as a desktop computer, smart phone, etc.));
receiving, from the mobile device, at least one user preference associated with the selected type of venue ([Fig. 38]; accessing a user profile to collect the user attribute data identified in FIG. 30 from the user profile such as other venues liked, gender, profession, or age… the user may request recommendations filtered by various venue attributes and may request a venue near particular coordinates; [0312-0314] parsing a recommendation request (e.g., a user request for recommendations for an American restaurant) to determine venue attributes and user weighting values; see [Fig. 1A][0084-0085] the system 100 may require a user to input various data… in response to a triggering event such as a request for a new recommendation… the user is asked to list favorite or preferred venues);
generating, using a machine learning model executed by the at least one processing device, at least one venue recommendation based on the selected type of venue and the user preference ([Fig. 38]; [0306-0310] the user may enter a recommendation request based on type… the user may request recommendations filtered by various venue attributes and may request a venue near particular coordinates; [0311] the recommendation engine personalizes recommendations by applying user attribute weights to the venues and venue attributes… to provide a total excitation score for each venue… a ranked listing of the venues can be provided to the user based on score; see [0187] the recommendation engine 112 determines a recommendation set based on the neural network methodology; [Fig. 1A]; [0365]);
transmitting the at least one venue recommendation to the mobile device for display on the GUI ([Fig. 38]; [0311] the recommendation engine personalizes recommendations by applying user attribute weights to the venues and venue attributes… to provide a total excitation score for each venue… a ranked listing of the venues can be provided to the user based on score; see [0198] the recommendation engine 112 may only serve recommended venues having nodal link strengths exceeding the recommendation threshold; [0228] venues are generated by the recommendation engine 112 and served to the user via the user interface);
receiving, from the mobile device, feedback related to the recommended venue ([0350] Users may provide feedback on recommendations that they are given, which can be either binary (approve or disapprove) or they can be continuous (e.g., 1 to 10, or −10 to 10); [0362] The user can enter feedback on their recommendations by clicking on thumbs up / thumbs down or other feedback mechanisms); and
updating the machine learning model using the feedback to improve accuracy of future venue recommendations ([317] recommendation processing described herein with respect to various link strengths can be used… to provide recommendations to the user; see [0113] Users' feedback concerning recommended venues and the associated “take rates” may likewise be factored in by the recommendation engine… link strengths may be increased for venues for which users more frequently make reservations based on the recommendations; [0188-0189] the recommendation engine 112 compares the current recommendation to aggregate recommendation data stored in the data repository 118… to determine and propagate deficiencies into the neural network to establish increased accuracy within the nodal links, including increasing link strength… thereby ensuring increased consideration in any future recommendations provided by the recommendation engine),
wherein the system is configured to operate in a distributed computing environment including the mobile device and a server system ([0306] users 208 trigger the recommendation engine 112 by entering through a web portal via the network 120; [Fig 1A]; [0064-0067] client device application (such as a smart phone application)… user interface module 110 resides on the server 102), and the machine learning model is dynamically updated without requiring retraining ([0175] the recommendation engine 112 generates recommendations for venues based on… link strengths between nodes of the neural network; [0095] the neural network of links may be reweighted based on the fact that the user requesting a recommendation has affinities or attributes held in common with certain reviewers).
Wilson discloses generating, using a machine learning model executed by the at least one processing device, at least one venue recommendation based on the selected type of venue and the user preference (see at least Wilson [Fig. 1A][Fig. 38][0187][0306-0311][0365]), and updating the machine learning model using the feedback to improve accuracy of future venue recommendations (see at least Wilson [0113][0188-0189][0317]). However, Wilson does not explicitly teach wherein the machine learning model is a trained machine learning model; and updating the machine learning model via an incremental learning algorithm.
However, in the field of providing personalized recommendations based on user preferences/habits (See at least Buzzell [abstract][0048-0049]), Buzzell, on the other hand, teaches wherein the model is a trained machine learning model ([0072] AI/ML Engines 420 can be implemented in Recommendation System 400, utilizing advanced algorithms and techniques to generate accurate and personalized recommendations; see [0055] the machine learning model architecture enables models to train on data sets before being deployed); and
updating the machine learning model via an incremental learning algorithm ([0111] collecting data on user interactions, feedback loops, and user preferences… the analysis identifies patterns, trends, and changes in user preferences over time… the recommendation system learns and adapts its models and algorithms to incorporate the evolving user preferences. This adaptation can involve updating the AI/ML models, adjusting weights or parameters).
The steps of Buzzell are applicable to the system of Wilson, as they share characteristics and capabilities, namely, they are directed to providing user recommendations according to user preferences. It would have been obvious to one of ordinary skill in the art at the time of filing to modify the recommendation system as taught by Wilson, to include wherein the model is a trained machine learning model; and updating the machine learning model via an incremental learning algorithm, as taught by Buzzell. One of ordinary skill in the art at the time of filing would have been motivated to expand the recommendation system of Wilson in order to enhance the recommendation process through continuously learning from data and generating more accurate and relevant recommendations that reflect evolving user preferences, ensuring a personalized user experience (Buzzell, [0071][0111]).
Regarding Claim 14, Wilson in view of Buzzell teaches the system of claim 13.
Wilson further discloses a plurality of mobile devices, wherein each mobile device provides feedback to create crowd-sourced feedback ([Fig. 1A] users 108; [0113] Users' feedback concerning recommended venues and the associated “take rates” may likewise be factored in by the recommendation engine; [0350] Users may provide feedback on recommendations that they are given, which can be either binary (approve or disapprove) or they can be continuous (e.g., 1 to 10, or −10 to 10)).
Regarding Claim 16, Wilson in view of Buzzell teaches the system of claim 13.
Wilson discloses wherein the machine learning model comprises a neural network or gradient-boosted decision tree updated on historical venue selection data ([0113] Users' feedback concerning recommended venues and the associated “take rates” may likewise be factored in by the recommendation engine… link strengths may be increased for venues for which users more frequently make reservations based on the recommendations; [0188-0189] the recommendation engine 112 compares the current recommendation to aggregate recommendation data stored in the data repository 118… to determine and propagate deficiencies into the neural network to establish increased accuracy within the nodal links, including increasing link strength… thereby ensuring increased consideration in any future recommendations provided by the recommendation engine). However, Wilson does not explicitly disclose wherein the trained machine learning model comprises a neural network or gradient-boosted decision tree trained on historical data.
Buzzell, on the other hand, teaches wherein the trained machine learning model comprises a neural network or gradient-boosted decision tree trained ([0055] the machine learning model architecture enables models to train on data sets before being deployed; [0077] The AI/ML Engines Module can define and compile the model architecture. This API allows for the sequential assembly of layers in a neural network… dense layers, convolutional layers, or recurrent layers can be added and configured).
It would have been obvious to one of ordinary skill in the art at the time of filing to modify the recommendation system as taught by Wilson, to include wherein the trained machine learning model comprises a neural network or gradient-boosted decision tree trained, as taught by Buzzell, for the same reasons discussed above with respect to claim 13.
Regarding Claim 17, Wilson in view of Buzzell teaches the system of claim 13.
Wilson further discloses wherein the feedback is used to adjust model weights in real-time ([0113] Users' feedback concerning recommended venues and the associated “take rates” may likewise be factored in by the recommendation engine… link strengths may be increased for venues for which users more frequently make reservations based on the recommendations; [0189] increasing link strength thereby ensuring increased consideration in any future recommendations provided by the recommendation engine). However, Wilson does not explicitly teach using a learning algorithm.
Buzzell, on the other hand, teaches using a learning algorithm ([0111] collecting data on user interactions, feedback loops, and user preferences… the analysis identifies patterns, trends, and changes in user preferences over time… the recommendation system learns and adapts its models and algorithms to incorporate the evolving user preferences. This adaptation can involve updating the AI/ML models, adjusting weights or parameters).
It would have been obvious to one of ordinary skill in the art at the time of filing to modify the recommendation system as taught by Wilson, to include using a learning algorithm, as taught by Buzzell, for the same reasons discussed above with respect to claim 13.
Regarding Claim 18, Wilson in view of Buzzell teaches the system of claim 13.
Wilson further discloses wherein the mobile device comprises a smartphone, tablet, or wearable device configured to communicate with the server system ([Fig. 1A] depicts users 108 communicating with server 102 over network 120). However, Wilson does not explicitly teach communication via a RESTful API.
Buzzell, on the other hand, teaches communication via a RESTful API ([0116] Runtime Services and Libraries 455 power the microservices within Recommendation System 400. These services facilitate inter-process and service communications… including RESTful APIs; see [0195-0199]).
It would have been obvious to one of ordinary skill in the art at the time of filing to modify the recommendation system as taught by Wilson, to include using a learning algorithm, as taught by Buzzell, for the same reasons discussed above with respect to claim 13. One of ordinary skill in the art at the time of filing would have been further motivated to expand the recommendation system of Wilson in order to ensure reliable and efficient communication between system components (Wilson, [0116][0195-0199]).
Regarding Claim 19, Wilson in view of Buzzell teaches the system of claim 13.
Wilson further discloses wherein the server system stores user preference profiles ([0274] the matrix builder stores user data in the data repository 118… a list of preferred venues in various different venue categories is included in the user profile; see [Fig. 38]; [0306] accessing a user profile to collect the user attribute data identified in FIG. 30 from the user profile) and
adapts future recommendations based on a combination of individual and aggregate usage data ([317] recommendation processing described herein with respect to various link strengths can be used… to provide recommendations to the user; see [0110] arithmetic blending or averaging the user attribute values to arrive at a composite group user profile; [0113] Users' feedback concerning recommended venues and the associated “take rates” may likewise be factored in by the recommendation engine… link strengths may be increased for venues for which users more frequently make reservations based on the recommendations; [0189] increasing link strength thereby ensuring increased consideration in any future recommendations provided by the recommendation engine; see [Figs. 30 and 31]).
Regarding Claim 20, Wilson in view of Buzzell teaches the system of claim 13.
Wilson further discloses a memory that stores received at least one user preference ([0274] the matrix builder stores user data in the data repository 118… a list of preferred venues in various different venue categories is included in the user profile; see [Fig. 38]; [0306]);
wherein the at least one processing device provides, using the machine learning model, at least one second recommendation of a venue based on the stored user preference and a determined location of the mobile device ([Fig. 38]; [0306-0315] a recommendation may be generate based on… accessing a user profile to collect the user attribute data identified in FIG. 30 from the user profile such as other venues liked, gender, profession, or age… a recommendation request from a user for a personalized recommendation based on a location of the user… a ranked listing of the venues can be provided to the user based on score. The recommendation engine 112 can also provide a plurality of venues to give the user some choice by always providing a predetermined amount of venues). However, Wilson does not explicitly teach wherein the model is the trained machine learning model.
Buzzell, on the other hand, teaches wherein the machine learning model is the trained machine learning model ([0055][0072]).
It would have been obvious to one of ordinary skill in the art at the time of filing to modify the recommendation system as taught by Wilson, to include wherein the machine learning model is the trained machine learning model, as taught by Buzzell, for the same reasons discussed above with respect to claim 13.
Claim(s) 3-6 and 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Wilson et al. in view of Buzzell et al., and further in view of Brooks (US 2023/0334536 A1).
Regarding Claim 3, Wilson in view of Buzzell teaches the method of claim 2.
Wilson further discloses wherein the receiving feedback includes prompting a user for the feedback when near the recommended venue ([0111] the system may prompt the user to access an interface… if a user is known to be proximate to a theater shortly before a show which the recommendation engine ranks highly for that particular user; [0113] Users' feedback concerning recommended venues and the associated “take rates” may likewise be factored in by the recommendation engine… link strengths may be increased for venues for which users more frequently make reservations based on the recommendations; see [Fig. 14][[0131-0133] the user interface provides buttons to book a reservation for the various [recommended] venues).
Note: The broadest reasonable interpretation of a method (or process) claim having contingent limitations requires only those steps that must be performed and does not include steps that are not required to be performed because the condition(s) precedent are not met. MPEP 2111.04. Claim 3 recites “when at the recommended venue,” however does not set precedent for the user being at the recommended venue, and accordingly the limitation has been granted little to no patentable weight. Nevertheless, the limitation has been examined.
While Wilson discloses prompting a user for the feedback when near the recommended venue (see at least Wilson [0111][0113][Fig. 14][0131-0133]), Wilson in view of Buzzell does not explicitly teach prompting a user when at the venue.
However, in the field of providing real time venue recommendations (see at least Brooks [abstract]), Brooks, on the other hand, teaches prompting a user when at the venue ([Fig. 6]; [0103] sending a notification to the user 132 that the location of the user 132 has been verified and associated with a particular acceptable range within an established geographical location of the venue 212 and that the user 132 may leave a review or rating of the venue 212; [0090-0091] verifying a user’s geographic location 326 including geofencing 328… geofencing refers to a virtual perimeter or boundary or fence for a real-world geographic area that includes a venue 212).
The steps of Brooks are applicable to the method of Wilson in view of Buzzell, as they share characteristics and capabilities, namely, they are directed to providing real time venue recommendations. It would have been obvious to one of ordinary skill in the art at the time of filing to modify the recommendation method as taught by Wilson in view of Buzzell, to include prompting a user when at the venue, as taught by Brooks. One of ordinary skill in the art at the time of filing would have been motivated to expand the recommendation method of Wilson in view of Buzzell in order to prevent fraudulent reviews left by people who want to skew the impression that the public has of a particular venue (Brooks, [0088]).
Regarding Claim 4, Wilson in view of Buzzell teaches the method of claim 2.
Wilson further discloses wherein the receiving feedback includes determining that the user is located near the recommended venue ([0111] Recommendations may also be provided based on real-time location information, such as that provided by smart-phone GPS data… the system may prompt the user to access an interface… if a user is known to be proximate to a theater shortly before a show which the recommendation engine ranks highly for that particular user); and
prompting the user for the feedback in real-time when near the recommended venue ([0111] the system may prompt the user to access an interface… if a user is known to be proximate to a theater shortly before a show which the recommendation engine ranks highly for that particular user; [0113] Users' feedback concerning recommended venues and the associated “take rates” may likewise be factored in by the recommendation engine… link strengths may be increased for venues for which users more frequently make reservations based on the recommendations; see [Fig. 14][[0131-0133] the user interface provides buttons to book a reservation for the various [recommended] venues). However, Wilson in view of Buzzell does not explicitly disclose determining that the user is located at the venue and prompting the user when at the venue.
Brooks, on the other hand, teaches determining that the user is located at the venue and prompting the user when at the venue ([Fig. 6]; [0103] sending a notification to the user 132 that the location of the user 132 has been verified and associated with a particular acceptable range within an established geographical location of the venue 212 and that the user 132 may leave a review or rating of the venue 212; [0090-0091] verifying a user’s geographic location 326 including geofencing 328… geofencing refers to a virtual perimeter or boundary or fence for a real-world geographic area that includes a venue 212).
It would have been obvious to one of ordinary skill in the art at the time of filing to modify the recommendation method as taught by Wilson in view of Buzzell, to include determining that the user is located at the venue and prompting the user when at the venue, as taught by Brooks, for the same reasons discussed above with respect to claim 3.
Regarding Claim 5, Wilson in view of Buzzell and Brooks teaches the method of claim 4.
Wilson discloses prompting at least one second user for feedback when the at least one second user is near a predetermined venue ([0111] the system may prompt the user to access an interface… if a user is known to be proximate to a theater shortly before a show which the recommendation engine ranks highly for that particular user; [0113] Users' feedback concerning recommended venues and the associated “take rates” may likewise be factored in by the recommendation engine… link strengths may be increased for venues for which users more frequently make reservations based on the recommendations; see [Fig. 1A] users 108; [Fig. 14][[0131-0133] the user interface provides buttons to book a reservation for the various [recommended] venues) (Wilson discloses multiple users 108 that interact with the system for venue recommendations, and accordingly these steps are possible for a second user). However, Wilson in view of Buzzell does not explicitly teach prompting the user when at the venue.
Brooks, on the other hand, teaches prompting the user when at the venue ([Fig. 6]; [0103] sending a notification to the user 132 that the location of the user 132 has been verified and associated with a particular acceptable range within an established geographical location of the venue 212 and that the user 132 may leave a review or rating of the venue 212; [0090-0091] verifying a user’s geographic location 326 including geofencing 328… geofencing refers to a virtual perimeter or boundary or fence for a real-world geographic area that includes a venue 212).
It would have been obvious to one of ordinary skill in the art at the time of filing to modify the recommendation method as taught by Wilson in view of Buzzell, to include prompting the user when at the venue, as taught by Brooks, for the same reasons discussed above with respect to claim 3.
Regarding Claim 6, Wilson in view of Buzzell and Brooks teaches the method of claim 5.
Wilson further discloses wherein the prompting is generated on a user interface of a mobile device ([0111] the system may prompt the user to access an interface… if a user is known to be proximate to a theater shortly before a show which the recommendation engine ranks highly for that particular user; [0113] Users' feedback concerning recommended venues and the associated “take rates” may likewise be factored in by the recommendation engine… link strengths may be increased for venues for which users more frequently make reservations based on the recommendations; [Fig. 14][[0131-0133] the user interface provides buttons to book a reservation for the various [recommended] venues).
Regarding Claim 15, Wilson in view of Buzzell teaches the system of claim 13.
Wilson further discloses wherein the mobile device includes means for determining that the user is located near the recommended venue ([0111] Recommendations may also be provided based on real-time location information, such as that provided by smart-phone GPS data… the system may prompt the user to access an interface… if a user is known to be proximate to a theater shortly before a show which the recommendation engine ranks highly for that particular user) and
means for prompting the user for the feedback in real-time when near the recommended venue ([0111] the system may prompt the user to access an interface… if a user is known to be proximate to a theater shortly before a show which the recommendation engine ranks highly for that particular user; [0113] Users' feedback concerning recommended venues and the associated “take rates” may likewise be factored in by the recommendation engine… link strengths may be increased for venues for which users more frequently make reservations based on the recommendations; see [Fig. 14][[0131-0133] the user interface provides buttons to book a reservation for the various [recommended] venues). However, Wilson in view of Buzzell does not explicitly disclose determining that the user is located at the venue and prompting the user when at the venue.
Brooks, on the other hand, teaches determining that the user is located at the venue and prompting the user when at the venue ([Fig. 6]; [0103] sending a notification to the user 132 that the location of the user 132 has been verified and associated with a particular acceptable range within an established geographical location of the venue 212 and that the user 132 may leave a review or rating of the venue 212; [0090-0091] verifying a user’s geographic location 326 including geofencing 328… geofencing refers to a virtual perimeter or boundary or fence for a real-world geographic area that includes a venue 212).
The steps of Brooks are applicable to the system of Wilson in view of Buzzell, as they share characteristics and capabilities, namely, they are directed to providing real time venue recommendations. It would have been obvious to one of ordinary skill in the art at the time of filing to modify the recommendation system as taught by Wilson in view of Buzzell, to include determining that the user is located at the venue and prompting the user when at the venue, as taught by Brooks. One of ordinary skill in the art at the time of filing would have been motivated to expand the recommendation system of Wilson in view of Buzzell in order to prevent fraudulent reviews left by people who want to skew the impression that the public has of a particular venue (Brooks, [0088]).
Claim(s) 10-12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Wilson et al. in view of Brooks.
Regarding Claim 10, Wilson teaches the limitations of claim 9.
Wilson further discloses means for determining that the user is located near the recommended venue ([0111] Recommendations may also be provided based on real-time location information, such as that provided by smart-phone GPS data… the system may prompt the user to access an interface… if a user is known to be proximate to a theater shortly before a show which the recommendation engine ranks highly for that particular user) and
means for prompting the user for the feedback in real-time when near the recommended venue ([0111] the system may prompt the user to access an interface… if a user is known to be proximate to a theater shortly before a show which the recommendation engine ranks highly for that particular user; [0113] Users' feedback concerning recommended venues and the associated “take rates” may likewise be factored in by the recommendation engine… link strengths may be increased for venues for which users more frequently make reservations based on the recommendations; see [Fig. 14][[0131-0133] the user interface provides buttons to book a reservation for the various [recommended] venues). However, Wilson in view of Buzzell does not explicitly disclose determining that the user is located at the venue and prompting the user when at the venue.
Brooks, on the other hand, teaches determining that the user is located at the venue and prompting the user when at the venue ([Fig. 6]; [0103] sending a notification to the user 132 that the location of the user 132 has been verified and associated with a particular acceptable range within an established geographical location of the venue 212 and that the user 132 may leave a review or rating of the venue 212; [0090-0091] verifying a user’s geographic location 326 including geofencing 328… geofencing refers to a virtual perimeter or boundary or fence for a real-world geographic area that includes a venue 212).
The steps of Brooks are applicable to the system of Wilson in view of Buzzell, as they share characteristics and capabilities, namely, they are directed to providing real time venue recommendations. It would have been obvious to one of ordinary skill in the art at the time of filing to modify the recommendation system as taught by Wilson in view of Buzzell, to include determining that the user is located at the venue and prompting the user when at the venue, as taught by Brooks. One of ordinary skill in the art at the time of filing would have been motivated to expand the recommendation system of Wilson in view of Buzzell in order to prevent fraudulent reviews left by people who want to skew the impression that the public has of a particular venue (Brooks, [0088]).
Regarding Claim 11, Wilson in view of Brooks teaches the limitations of claim 10.
Wilson further discloses wherein the type of venue includes at least one of a restaurant, a bar, a pub, a night club, and/or an adult cabaret ([0056] venues may include restaurants; [0061] generating a night club recommendation; [0312-0314] parsing a recommendation request (e.g., a user request for recommendations for an American restaurant)).
Regarding Claim 12, Wilson in view of Brooks teaches the limitations of claim 11.
Wilson further discloses wherein the at least one preference related to the selected type of venue includes a location, specials offered, venue setting, music played at venue, crowd age range, preferred attire and/or atmosphere ([0312] coordinates (“located near (42.03, -71.10)”) and “hipster” attire are parsed from a user recommendation request for an American restaurant).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
U.S Patent Application No. 2020/0090249 A1 to Weislo – Location based venue recommendation including category and user attribute selection.
NPL Reference U “Interactive Multimodal Learning for Venue Recommendation” (see Notice of References Cited) – Venue recommendation framework matching the interacting user to users of social media platforms exhibiting similar tastes.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ZACHARY R DONAHUE whose telephone number is (571)272-5850. The examiner can normally be reached M-F 8a-5p.
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, Marissa Thein can be reached at (571) 272-6764. 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.
/ZACHARY RYAN DONAHUE/Examiner, Art Unit 3689
/MARISSA THEIN/Supervisory Patent Examiner, Art Unit 3689
Prosecution Insights