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
For the purpose of examination with regard to prior art, the effective filing date of the instant application is December 28th, 2023.
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-4 and 6-9 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1: Whether a Claim is to a Statutory Category
In the instant case, claims 1-4 and 6-8 recite a method/ process and claim 9 recites a server/ machine that are performing a series of functions. Therefore, these claims fall within the four statutory categories of invention of a machine. Step 1 is satisfied.
Step2A – Prong 1: Does the Claim Recite a Judicial Exception
Exemplary claim 1 (and similarly claim 9) recites the following abstract concepts that are found to include an enumerated “abstract idea”:
A method of operation of a server in a communication system in which the server includes a transceiver, a memory, and a processor, the method comprising:
a process of receiving basic restaurant menu information including restaurant information, dish information, and ingredient information from a first user terminal through the transceiver;
a process of sending the basic restaurant menu information to a restaurant terminal corresponding to the basic restaurant menu information and a plurality of second user terminals through the transceiver;
a process of receiving feedback information related to accuracy of the basic restaurant menu information from one or more of the restaurant terminal and the plurality of second user terminals through the transceiver;
a process of, based on the basic restaurant menu information and the feedback information, generating by the processor, verified restaurant menu information including dish and ingredient information for each restaurant through the processor by performing the steps of:
(i)calculating, by the processor, an information provider weighted value for the first user terminal based on a historical accuracy of previously provided basic restaurant menu information from the first user terminal,
(ii) calculating, by the processor, a feedback provider weighted value for each of the plurality of second user terminals,
(iii) determining, by the processor, that a total amount of the feedback information has reached a critical amount of feedback, wherein the critical amount of feedback is adjusted based on the information provider weighted value, and
(iv) based on the feedback provider weighted values, calculating, by the processor, a reliability score for the basic restaurant menu information to determine if the basic restaurant menu information is verified as accurate or inaccurate;
a process of receiving restaurant visit information including information on a visited restaurant and an eaten dish by date from a third user terminal through the transceiver;
a process of, based on the verified restaurant menu information and the restaurant visit information, generating or updating statistical information of nutritional components consumed by date for the third user terminal through the processor; and
a process of sending the statistical information of the nutritional components consumed by date to the third user terminal through the transceiver,
wherein the verified restaurant menu information corresponds to information verified based on the feedback information among the basic restaurant menu information,
the feedback information is based on one or more of information of a photo of a menu on which dish and ingredient information is written, information of a confirmation of the basic restaurant menu information from the restaurant terminal, and positive or negative feedback on the basic restaurant menu information from the plurality of second user terminals that correspond to a plurality of users who have visited the restaurant corresponding to the basic restaurant menu information,
when verification of the basic restaurant menu information is based on the positive or negative feedback on the basic restaurant menu information from the plurality of second user terminals that correspond to the plurality of users who have visited the restaurant, the verification is performed when the total amount of feedback, including positive or negative feedback, is a critical amount of feedback or more, and the verification is performed based on whether positive feedback accounts for a critical proportion or more,
the critical amount of feedback is based on a product of an information provider weighted value relating to the first user terminal and a set reference critical amount of feedback,
the information provider weighted value is set to decrease with an increase in the number of results verified to be accurate among previously provided basic restaurant menu information of the first user terminal,
the information provider weighted value is set to increase with an increase in the number of results verified to be inaccurate among the previously provided basic restaurant menu information of the first user terminal,
when the total amount of feedback is the critical amount of feedback or more and positive feedback scores account for the critical proportion or more relative to negative feedback scores, the basic restaurant menu information is verified as accurate,
when the total amount of feedback is the critical amount of feedback or more and the positive feedback scores account for less than the critical proportion relative to the negative feedback scores, the basic restaurant menu information is verified as inaccurate, and
the positive feedback scores or the negative feedback scores are each based on a product of a feedback provider weighted value set for each of the plurality of second user terminals and a set reference feedback score,
wherein the restaurant information among the basic restaurant menu information is configured to be selected among restaurants registered in a restaurant portal database, the restaurant menu information is newly generated or selected among previously generated menu information, and the ingredient information is configured in the form of text, and
when the feedback information is based on confirmation of the basic restaurant menu information of the restaurant terminal,
the method further comprises:
a process of, after the sending of the statistical information of the nutritional components consumed by date to the third user terminal through the transceiver, sending a message asking whether to approve or disapprove use of reward points of a service run by the server to pay for food to the restaurant terminal through the transceiver;
a process of receiving a response message approving the use of the reward points to pay for food from the restaurant terminal through the transceiver; and
a process of sending the basic restaurant menu information and information informing that it is possible to use the reward points of the service to pay for food to a plurality of fifth user terminals subscribed to the service run by the server through the transceiver,
wherein eligibility for the use of the reward points at the restaurant is dynamically controlled by the server based on a determination that the reliability score for the restaurant's basic restaurant menu information indicates the information is verified as accurate.
[Emphasis added to show the abstract idea being executed by additional elements that do not meaningfully limit the abstract idea]
This method claim is grouped within the “certain methods of organizing human activity” grouping of abstract ideas in prong one of step 2A of the Alice/Mayo test because the claims involve a series of steps for sales activities for sending a message asking whether to approve or disapprove use of reward points to pay for food, which is a process that is encompassed by the abstract idea of commercial or legal interactions. The examiner has reviewed each abstract idea from each step individually and in combination with each other limitation, and still finds that the claim 1 recites abstract idea. See e.g., MPEP 2106.04(a)(2); 2106.05(h); and July 2024 Subject Matter Eligibility Example 47 claim 2 as the specification of the instant application describes use of an “artificial intelligence based cooking simulation model” to propose modified recipes. Accordingly, claim 1 (and similarly claim 9) recite an abstract idea.
Step2A – Prong 2: Does the Claim Recite Additional Elements that Integrate the Judicial Exception into a Practical Application
This judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A of the Alice/Mayo test, the additional elements of the claims such as server, transceiver, memory, processor, first/second/ third/ fifth user terminals and restaurant terminal merely use a computer as a tool to perform an abstract idea and/or generally link the use of a judicial exception to a particular technological environment. Specifically, the server, transceiver, memory, processor, first/second/ third/ fifth user terminals and restaurant terminal perform the steps or functions of sales activities for sending a message asking whether to approve or disapprove use of reward points to pay for food. The use of a processor/computer as a tool to implement the abstract idea and/or generally linking the use of the abstract idea to a particular technological environment does not integrate the abstract idea into a practical application because it requires no more than a computer (or technical elements disclosed at a high level of generality such as server, transceiver, memory, processor, first/second/ third/ fifth user terminals and restaurant terminal) performing functions of receiving, sending, generating or updating, calculating, determining, verifying, selecting, confirming, relating, approving or disapproving, running, paying and dynamically controlling that correspond to acts required to carry out the abstract idea (MPEP 2106.05(f) and (h)). Accordingly, the additional elements do not impose any meaningful limits on practicing the abstract idea, and the claims are directed to an abstract idea.
Step2B: Does the Claim Amount to Significantly More
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when analyzed under step 2B of the Alice/Mayo test, the additional elements of server, transceiver, memory, processor, first/second/ third/ fifth user terminals and restaurant terminal being used to perform the steps of receiving, sending, generating or updating, calculating, determining, verifying, selecting, confirming, relating, approving or disapproving, running, paying and dynamically controlling amounts to no more than using a computer or processor to automate and/or implement the abstract idea of sales activities for sending a message asking whether to approve or disapprove use of reward points to pay for food. As discussed above, taking the claim elements separately, server, transceiver, memory, processor, first/second/ third/ fifth user terminals and restaurant terminal perform the steps or functions of commercial or legal interactions of sales activities for sending a message asking whether to approve or disapprove use of reward points to pay for food. These functions correspond to the actions required to perform the abstract idea. Viewed as a whole, the combination of elements recited in the claims merely recite the concept of commercial or legal interactions of sales activities for sending a message asking whether to approve or disapprove use of reward points to pay for food because said combination of elements remains disclosed at a high level of generality. Therefore, the use of these additional elements does no more than employ the computer as a tool to automate and/or implement the abstract idea. The use of a computer or processor to merely automate and/or implement the abstract idea cannot provide significantly more than the abstract idea itself (MPEP 2106.05(l)(A)(f) & (h)). Therefore, the claims are not patent eligible.
Independent claim 9 describes a system performing the functions of receiving, sending, generating or updating, calculating, determining, verifying, selecting, confirming, relating, approving or disapproving, running, paying and dynamically controlling also relating to commercial or legal interactions without additional elements beyond technical elements disclosed at a high level of generality such as a server, transceiver, memory, processor, first/second/ third/ fifth user terminals and restaurant terminal that provide significantly more than the abstract idea of commercial or legal interactions of sales activities for sending a message asking whether to approve or disapprove use of reward points to pay for food as noted above regarding claim 1. Therefore, this independent claim is also not patent eligible.
Dependent claims 2-4, 6 and 8 further describe the abstract idea of commercial or legal interactions of sales activities. These claims do not include additional elements to perform their respective functions of receiving, sending, generating, updating, determining, selecting and setting beyond the technical elements disclosed at a high level of generality such as transceiver, processor, first/second/ third/ fourth/ fifth user terminals, restaurant terminal and as disclosed in independent claim 1 that integrate the abstract idea into a practical application or that provide significantly more than the abstract idea. Therefore, these dependent claims are also not patent eligible. Further, the dependency of these claims on ineligible independent claim 1 also renders dependent claims 2-4, 6 and 8 as not patent eligible.
Dependent claim 7 further describes the abstract idea of commercial or legal interactions of sales activities. In addition to the technical elements of a third user terminal, transceiver and processor disclosed at a high level of generality and performing the functions of sending, receiving, generating, dividing, setting, training, validating and regularizing this dependent claim adds a trained artificial intelligence (AI) cooking simulation model to generate cooking simulation information. However, this claim does not include additional elements to perform their respective functions beyond the technical elements disclosed at a high level of generality and as disclosed in independent claim 1 that integrate the abstract idea into a practical application or that provide significantly more than the abstract idea. This is because the claim does not reflect a training process to show how said cooking simulation model is trained, rather, the claims merely label multiple sets of data, parameters and training periods (epochs) as being used for training the model. A clear training process is still missing from the claim limitations. See July 2024 Subject Matter Eligibility Example 47. Therefore, this dependent claim is also not patent eligible. Further, the dependency of this claim on ineligible independent claim 1 also renders dependent claim 7 as not patent eligible.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-4 and 6-9 are rejected under 35 U.S.C. 103 as being unpatentable over Kolawa et al. (US 8,429,026 B1) in view of Rathod (US 2021/0042724 A1).
Regarding Claim 1 and 9, Kolawa teaches:
A method of operation of a server/ a server in a communication system in which the server includes a transceiver, a memory, and a processor (See Kolawa Col. 4 lines 64 – Col. 5 line 8 – network server or platform computer having a microprocessor and Col. 5 lines 34-65 – network server or platform computer transmitting and receiving [transceiver by example] data between user devices and databases [memory]), the method comprising:
a process of receiving basic restaurant menu information including restaurant information, dish information, and ingredient information from a first user terminal through the transceiver (See Kolawa Col. 25 lines 22-39 – FIG. 23 illustrates an exemplary recipe displayed ... The ingredients necessary may be added to a shopping list ... Furthermore, the recipe may be e-mailed and/or faxed to the user, if so desired. According to one embodiment of the invention, multimedia presentations are used in conjunction with the written instructions to instruct a family member in how to prepare the recommended dish. The multimedia presentation will typically include a video/audio presentation... For a day specified as an eat-out, take-out, or delivery day, the system recommends a restaurant along with dishes which cater to the user's tastes. In doing so, the system accesses a restaurant database including a list of restaurants in the user's geographical area.);
a process of sending the basic restaurant menu information to a restaurant terminal corresponding to the basic restaurant menu information and a plurality of second user terminals through the transceiver (See Kolawa Col. 26 lines 17-35 – a particular member of a group invites other members of the group to submit their orders from a predetermined menu. In this regard, the particular member communicates an invite to the other members via e-mail, instant messaging, or the like. The invite preferably includes a time, place of meal, menu of available foods, and time by which the orders are to be submitted. Each receiving member preferably selects the desired food items from the menu, such as, by clicking on the items, and submits them to a group shopping cart maintained in memory by the server upon actuating a submit button. The items may be submitted over a period of time, by the different members, from different locations and potentially from different types of input devices, such as, for example, a browser, portable device, cell phone, and the like. The server preferably invokes its microprocessor to automatically aggregate the orders in the group shopping cart and submit them to a particular restaurant or retailer as a single order request via the Internet connection.);
a process of receiving feedback information related to accuracy of the basic restaurant menu information from one or more of the restaurant terminal and the plurality of second user terminals through the transceiver (See Kolawa Col. 12 lines 27-45 – As an individual uses the system over time, the system learns and adapts to the user's preferences. FIG. 9 illustrates the initial learning and adaptation process according to one embodiment of the invention… the program proposes an initial list of items to the user… the user either accepts or rejects the recommended items. If the items are rejected, the program asks feedback questions to ascertain why the items were rejected. Similarly, if the items are accepted, the program asks questions to ascertain why each item was accepted… the user preference vector is updated, if necessary, and used for future choices. For instance, if a recommended recipe was rejected because it was too spicy, the value in the spiciness field of the user preference vector might be decreased. As a user uses the system over time, the recommendations become more and more accurate and feedback from the user becomes less and less required. In this case, the system may no longer require this type of initial feedback from the user.);
a process of, based on the basic restaurant menu information and the feedback information, generating by the processor, verified restaurant menu information including dish and ingredient information for each restaurant through the processor (See Kolawa Col. 26 lines 4-35 – each member of the group might be requested to select a menu item from any of the restaurants in the restaurant database. The system then analyzes the recipe vectors of the chosen items, and selects a restaurant that best satisfies the menu items selected. If a particular menu item is not located in the selected restaurant's record, the system finds the closest substitute menu item and proposes it to the individual whose menu item was not located. The individual may accept the recommended item, or select a different item from the selected restaurant's menu. The system may further add the various menu items (e.g. 6 cheeseburgers, 2 fries, 5 cokes), and transmit the order via the Internet, fax, or other known communication means... The server preferably invokes its microprocessor to automatically aggregate the orders in the group shopping cart and submit them to a particular restaurant or retailer as a single order) by performing the steps of:
(i) calculating, by the processor, an information provider weighted value for the first user terminal based on a historical accuracy of previously provided basic restaurant menu information from the first user terminal (see Col. 11 lines 4-12 - If all of the exclusive positions match, the rest of the positions in the product vector, that is, the inclusive positions, are used to preferably calculate a suitability weight. The suitability weight preferably represents how well the item matches with the user's preferences. In the described embodiment, the vector distance between a product vector and the user vector [information provider weighted value] preferably determines the suitability weight. The closer the vector distance, the higher the suitability weight, Col. 12 lines 38-45 - if a recommended recipe was rejected because it was too spicy, the value in the spiciness field of the user preference vector might be decreased. As a user uses the system over time, the recommendations become more and more accurate and feedback from the user becomes less and less required [historical accuracy of previously provided basic restaurant menu information]. In this case, the system may no longer require this type of initial feedback and Col. 31 lines 30-40 - the program inquires if the distance is closer than a pre-determined threshold distance. The threshold distance selected preferably depends on the user's preference topography. For instance, if the preference topography is densely populated with many product ratings, the threshold is preferably small. If the distance is closer than the threshold distance, the program assigns to the product the rating of the selected user-rated product. If the answer is NO, the program assigns a default rating to the product or leaves the product unrated.),
(ii) calculating, by the processor, a feedback provider weighted value for each of the plurality of second user terminals (see Col. 11 lines 4-12 - If all of the exclusive positions match, the rest of the positions in the product vector, that is, the inclusive positions, are used to preferably calculate a suitability weight. The suitability weight preferably represents how well the item matches with the user's preferences. In the described embodiment, the vector distance between a product vector and the user vector preferably determines the suitability weight. The closer the vector distance, the higher the suitability weight and Col. 12 lines 38-45 - if a recommended recipe was rejected because it was too spicy, the value in the spiciness field of the user preference vector might be decreased [calculating, by the processor, a feedback provider weighted value]. As a user uses the system over time, the recommendations become more and more accurate and feedback from the user becomes less and less required. In this case, the system may no longer require this type of initial feedback),
(iii) determining, by the processor, that a total amount of the feedback information has reached a critical amount of feedback, wherein the critical amount of feedback is adjusted based on the information provider weighted value (see Col. 12 lines 38-45 - if a recommended recipe was rejected because it was too spicy [information provider weighted value], the value in the spiciness field of the user preference vector might be decreased. As a user uses the system over time, the recommendations become more and more accurate and feedback from the user becomes less and less required [a total amount of the feedback information has reached a critical amount of feedback]. In this case, the system may no longer require this type of initial feedback [the critical amount of feedback is adjusted]), and
(iv) based on the feedback provider weighted values, calculating, by the processor, a reliability score for the basic restaurant menu information to determine if the basic restaurant menu information is verified as accurate or inaccurate (see Col. 27 lines 14-34 - The system utilizes the feedback received from the user to modify his or her food preference vector. According to one embodiment of the invention, a highly rated dish (e.g. dishes with rating of “7” or above) is merged into an existing cluster, as is described in further detail above. The ratings [feedback provider weighted values] of the dishes are used to modify the values of the inclusive fields of the user's food preference vector. The amount by which a value is modified is proportional to the degree of dislike expressed by the user. For instance, if the protein field in the user's preference vector has a value of 30 (a value that is below average on a scale of 0 to 100), and the user gives a rating of “1” to a sampled dish, expressing a great dislike to the dish, the system might modify the protein field to a value of 90 (a value that is above average). This is done for every inclusive field in the user's preference vector [reliability score for the basic restaurant menu information]. On the other hand, if the user only slightly disliked a dish, the inclusive field values may be modified only slightly, such as modifying the protein field to a value of 35. For the lowly rated dishes (e.g. dishes with ratings of “2” or below) the system further creates negative cluster vectors to ensure that these dishes, or similar dishes are not recommended in the future [determine if the basic restaurant menu information is verified as accurate or inaccurate]);
a process of receiving restaurant visit information including information on a visited restaurant and an eaten dish by date from a third user terminal through the transceiver (See Kolawa Col. 11 line 47 – storing the latest date on which an item was sampled, Col. 25 lines 40-60 – restaurant information comprising dish names, dates and comments relating to said dish and Col. 27 lines 6-12 – user rating whether liked or disliked a dish/ recipe);
a process of, based on the verified restaurant menu information and the restaurant visit information, generating or updating statistical information of nutritional components consumed by date for the third user terminal through the processor (See Kolawa Col. 11 line 47 – storing the latest date on which an item was sampled and Col. 27 lines 35-54 – graphical user interfaces (GUI) for adjusting a composition of a dish based on user preference, wherein said adjusting is of nutritional components, such as protein); and
a process of sending the statistical information of the nutritional components consumed by date to the third user terminal through the transceiver (See Kolawa Col. 27 lines 45-65 – GUIs for adjusting a composition of a dish based on user preference, wherein said adjusting is of nutritional components, such as protein and Col. 28 lines 12-19 – GUIs are communicated from a server to a user through an internet connection [transceiver]),
wherein the verified restaurant menu information corresponds to information verified based on the feedback information among the basic restaurant menu information (See Kolawa Col. 27 lines 6-34 – GUI receiving feedback by a user rating a recommended dish [menu information]),
the feedback information is based on one or more of information of a photo of a menu on which dish and ingredient information is written (See Kolawa Col. 28 lines 35-40 – In a menu recommendation system, a virtual chef presents to the user various types of recipes, including a picture of the meal, the ingredients present, and cooking instructions. The user then gives a rating of the meal based on the information being presented and/or based on his or her past experience with the meal), information of a confirmation of the basic restaurant menu information from the restaurant terminal (See Kolawa Col. 27 line 5 – Col. 28 line 10 – system programmer creating new recipes for menu items or modifying existing recipes and mapping ingredients to said recipes, wherein said mapping is functioning as a confirmation of said recipes), and positive or negative feedback on the basic restaurant menu information from the plurality of second user terminals that correspond to a plurality of users who have visited the restaurant corresponding to the basic restaurant menu information (See Kolawa Col. 11 line 47 – storing the latest date on which an item was sampled and Col. 13 lines 10-41 – user preference is tracked based on positive or negative ratings of food items),
when verification of the basic restaurant menu information (See Kolawa Col. 27 lines 6-34 – GUI receiving feedback by a user rating a recommended dish [menu information]) is based on the positive or negative feedback on the basic restaurant menu information from the plurality of second user terminals that correspond to the plurality of users who have visited the restaurant (See Kolawa Col. 11 line 47 – storing the latest date on which an item was sampled and Col. 13 lines 10-41 – user preference is tracked based on positive or negative ratings of food items), the verification is performed when the total amount of feedback, including positive or negative feedback, is a critical amount of feedback or more, and the verification is performed based on whether positive feedback accounts for a critical proportion or more (The specification of the instant application gives no special definition for the limitation critical amount of feedback, therefore, for the purpose of examination herein, said limitation is interpreted as a user preference. Therefore, see Kolawa Col. 27 lines 14-34 – using dish ratings as an amount of feedback received from a user to modify his or her food preference vector, wherein the amount by which a value is modified is proportional to the degree of dislike expressed by the user. For instance, if the protein field in the user's preference vector has a value of 30 (a value that is below average on a scale of 0 to 100), and the user gives a rating of “1” to a sampled dish, expressing a great dislike to the dish, the system might modify the protein field to a value of 90 (a value that is above average). This is done for every inclusive field in the user's preference vector. On the other hand, if the user only slightly disliked a dish, the inclusive field values may be modified only slightly, such as modifying the protein field to a value of 35. For the lowly rated dishes (e.g. dishes with ratings of “2” or below) the system further creates negative cluster vectors to ensure that these dishes, or similar dishes, are not recommended in the future and Col. 32 lines 10-15 - the program identifies portions of the N-dimensions of the topography where the user preferences lie. These areas of positive association are referred to as positive preference clusters. In making a recommendation[verification by example], the program selects products that lie within a user's positive preference cluster.),
the critical amount of feedback is based on a product of an information provider weighted value relating to the first user terminal and a set reference critical amount of feedback (As noted above, the limitation critical amount of feedback is interpreted as a user preference, therefore, see Col. 11 lines 4-12 - If all of the exclusive positions match, the rest of the positions in the product vector, that is, the inclusive positions, are used to preferably calculate a suitability weight. The suitability weight preferably represents how well the item matches with the user's preferences. In the described embodiment, the vector distance between a product vector and the user vector [information provider weighted value] preferably determines the suitability weight. The closer the vector distance, the higher the suitability weight and Col. 31 lines 30-40 - the program inquires if the distance is closer than a pre-determined threshold distance. The threshold distance selected preferably depends on the user's preference topography. For instance, if the preference topography is densely populated with many product ratings, the threshold is preferably small. If the distance is closer than the threshold distance, the program assigns to the product the rating of the selected user-rated product. If the answer is NO, the program assigns a default rating to the product or leaves the product unrated.),
the information provider weighted value is set to decrease with an increase in the number of results verified to be accurate among previously provided basic restaurant menu information of the first user terminal (See Kolawa Col. 12 lines 36-45 – the user preference vector is updated, if necessary, and used for future choices. For instance, if a recommended recipe was rejected because it was too spicy, the value in the spiciness field of the user preference vector might be decreased. As a user uses the system over time, the recommendations become more and more accurate and feedback from the user becomes less and less required. In this case, the system may no longer require this type of initial feedback from the user),
the information provider weighted value is set to increase with an increase in the number of results verified to be inaccurate among the previously provided basic restaurant menu information of the first user terminal (See Kolawa Col. 12 lines 36-45 – the program proposes an initial list of items to the user, wherein, the user either accepts or rejects the recommended items. If the items are rejected [verified to be inaccurate], the program preferably asks feedback questions to ascertain why the items were rejected, thereby increasing importance on the information provider [the user]),
when the total amount of feedback is the critical amount of feedback or more and positive feedback scores account for the critical proportion or more relative to negative feedback scores, the basic restaurant menu information is verified as accurate (The specification of the instant application gives no special definition for the limitation critical amount of feedback, therefore, for the purpose of examination herein, said limitation is interpreted as a user preference. Therefore, see Kolawa Col. 27 lines 14-34 – using dish ratings as an amount of feedback received from a user to modify his or her food preference vector, wherein the amount by which a value is modified is proportional to the degree of dislike expressed by the user. For instance, if the protein field in the user's preference vector has a value of 30 (a value that is below average on a scale of 0 to 100), and the user gives a rating of “1” to a sampled dish, expressing a great dislike to the dish, the system might modify the protein field to a value of 90 (a value that is above average). This is done for every inclusive field in the user's preference vector. On the other hand, if the user only slightly disliked a dish, the inclusive field values may be modified only slightly, such as modifying the protein field to a value of 35. For the lowly rated dishes (e.g. dishes with ratings of “2” or below) the system further creates negative cluster vectors to ensure that these dishes, or similar dishes, are not recommended in the future, Col. 29 lines 5-6 – to provide accurate preference information for increased accuracy in the recommended choices and Col. 32 lines 10-15 - the program identifies portions of the N-dimensions of the topography where the user preferences lie. These areas of positive association are referred to as positive preference clusters. In making a recommendation [verification by example], the program selects products that lie within a user's positive preference cluster),
when the total amount of feedback is the critical amount of feedback or more and the positive feedback scores account for less than the critical proportion relative to the negative feedback scores, the basic restaurant menu information is verified as inaccurate (The specification of the instant application gives no special definition for the limitation critical amount of feedback, therefore, for the purpose of examination herein, said limitation is interpreted as a user preference. Therefore, see Kolawa Col. 27 lines 14-34 – using dish ratings as an amount of feedback received from a user to modify his or her food preference vector, wherein the amount by which a value is modified is proportional to the degree of dislike expressed by the user. For instance, if the protein field in the user's preference vector has a value of 30 (a value that is below average on a scale of 0 to 100), and the user gives a rating of “1” to a sampled dish, expressing a great dislike to the dish, the system might modify the protein field to a value of 90 (a value that is above average). This is done for every inclusive field in the user's preference vector. On the other hand, if the user only slightly disliked a dish, the inclusive field values may be modified only slightly, such as modifying the protein field to a value of 35. For the lowly rated dishes (e.g. dishes with ratings of “2” or below) the system further creates negative cluster vectors to ensure that these dishes, or similar dishes, are not recommended in the future [verified as inaccurate by example), and
the positive feedback scores or the negative feedback scores are each based on a product of a feedback provider weighted value set for each of the plurality of second user terminals and a set reference feedback score (See Kolawa Col. 11 lines 4-12 - If all of the exclusive positions match, the rest of the positions in the product vector, that is, the inclusive positions, are used to preferably calculate a suitability weight. The suitability weight preferably represents how well the item matches with the user's preferences. In the described embodiment, the vector distance between a product vector and the user vector [information provider weighted value] preferably determines the suitability weight. The closer the vector distance, the higher the suitability weight, Col. 11 line 47 – storing the latest date on which an item was sampled, Col. 13 lines 10-41 – user preference is tracked based on positive or negative ratings of food items),
wherein the restaurant information among the basic restaurant menu information is configured to be selected among restaurants registered in a restaurant portal database (See Kolawa Col. 25 lines 34-51 – recommending a restaurant to a user from a list of registered restaurants based on the dishes [restaurant menu information] offered by each restaurant), the restaurant menu information is newly generated or selected among previously generated menu information, and the ingredient information is configured in the form of text (See Kolawa Col. 27 line 55 – Col. 28 line 10 – entering ingredients for new recipes or modifying ingredients of existing recipes and Fig. 23 – “Text area for dish ingredients”), and
when the feedback information is based on confirmation of the basic restaurant menu information of the restaurant terminal (See Kolawa Col. 12 lines 27-45 – as noted above in claim 1),
the method further comprises:
a process of, after the sending of the statistical information of the nutritional components consumed by date to the third user terminal through the transceiver (See Kolawa Col. 11 line 47 – storing the latest date on which an item was sampled and Col. 27 lines 35-54 – graphical user interfaces (GUI) for adjusting a composition of a dish based on user preference, wherein said adjusting is of nutritional components, such as protein), sending a message asking whether to approve or disapprove … the server to pay for food to the restaurant terminal through the transceiver (See Kolawa Col. 16 lines 32-56 – sending an order to a retailer [restaurant terminal] to be purchased and if said order is to be purchased a purchase transaction is performed to complete checkout for said order and Col. 26 lines 17-35 – the server sending orders to a particular restaurant);
a process of receiving a response message approving … to pay for food from the restaurant terminal through the transceiver (See Kolawa Col. 16 lines 32-56 – sending an order to a retailer [restaurant terminal] to be purchased and if said order is to be purchased when approved by a user, a purchase transaction is performed to complete checkout for said order and Col. 26 lines 17-35 – the server sending orders to a particular restaurant); and
a process of sending the basic restaurant menu information and information informing that it is possible (See Kolawa Col. 26 lines 4-8 – Alternatively, each member of the group might be requested to select a menu item from any of the restaurants in the restaurant database. The system then analyzes the recipe vectors of the chosen items, and selects a restaurant that best satisfies the menu items selected) …,
… based on a determination that the reliability score for the restaurant's basic restaurant menu information indicates the information is verified as accurate (see Col. 27 lines 14-34 - The system utilizes the feedback received from the user to modify his or her food preference vector. According to one embodiment of the invention, a highly rated dish (e.g. dishes with rating of “7” or above) is merged into an existing cluster, as is described in further detail above. The ratings of the dishes are used to modify the values of the inclusive fields of the user's food preference vector. The amount by which a value is modified is proportional to the degree of dislike expressed by the user. For instance, if the protein field in the user's preference vector has a value of 30 (a value that is below average on a scale of 0 to 100), and the user gives a rating of “1” to a sampled dish, expressing a great dislike to the dish, the system might modify the protein field to a value of 90 (a value that is above average). This is done for every inclusive field in the user's preference vector [reliability score for the basic restaurant menu information]. On the other hand, if the user only slightly disliked a dish, the inclusive field values may be modified only slightly, such as modifying the protein field to a value of 35. For the lowly rated dishes (e.g. dishes with ratings of “2” or below) the system further creates negative cluster vectors to ensure that these dishes, or similar dishes are not recommended in the future [indicates the information is verified as accurate]).
While Kolawa teaches a system for approving payment of food orders (Kolawa Col. 16 lines 32-56 and Col. 26 lines 17-35), Kolawa does not explicitly teach that said payment is done by the use of the reward points of a service to pay for food to a plurality of fifth user terminals subscribed to the service run by the server through the transceiver, wherein eligibility for the use of the reward points at the restaurant is dynamically controlled by the server. This is taught by Rathod (See Rathod ¶ [0153] - manage listing of said place by sending request to server system and provide required one or more types of data or information or documents, [0155] - supports all payment methods, track their transactions and payments on a real-time [dynamic] basis [0313-0314] – apply redeemable points to pay for products in a virtual cart shown on a user’s mobile device, [0415] – an advertiser or sponsor can associate an offer for redeemable points to all participating [eligible] users [subscribed by example]). It would have been obvious to one of ordinary skill in the art before the effective filing date of the instant application to include in the food order payment system of Kolawa the use of redeemable points offered to participating users as taught by Rathod so that the user can easily make a payment to the merchant through the user device (Rathod ¶ [0001]), thereby improving the efficiency of Kolawa’s food order payment system.
Regarding Claim 2, modified Kolawa teaches:
The method of claim 1, further comprising:
a process of, after the sending of the statistical information of the nutritional components consumed by date to the third user terminal through the transceiver, receiving a dish order request including information on a dish relating to the visited restaurant from the third user terminal through the transceiver (See Kolawa Col. 12 lines 36-41 – user preferences are updated for future recipe/ dish recommendation choices, Col. 11 line 47 – storing the latest date on which an item was sampled, Col. 17 line 23-40 – user adjusting ingredient quantities and submitting an order request to one or more retailers for fulfillment, Col. 26 lines 4-16 – restaurants functioning as retailers and Col. 27 lines 45-65 – GUIs for adjusting a composition of a dish based on user preference, wherein said adjusting is of nutritional components, such as protein);
a process of sending the dish order request of the third user terminal to the restaurant terminal corresponding to the restaurant through the transceiver (See Kolawa Col. 26 lines 4-16 – sending the order to the restaurant through the internet or other means);
a process of receiving a confirmation response to the dish order request from the restaurant terminal through the transceiver (See Kolawa Col. 16 lines 32-45 – receiving order confirmation from a retailer by example and Col. 26 lines 4-16 – restaurants functioning as retailers);
a process of sending the confirmation response to the third user terminal through the transceiver (See Kolawa Col. 16 lines 32-45 – receiving order confirmation from a retailer by example of populating a virtual shopping cart of ingredients, wherein said order confirmation example is sent to a user and Col. 26 lines 4-16 – restaurants functioning as retailers);
a process of, based on the dish order request, generating or updating the statistical information of the nutritional components consumed by date relating to the third user terminal through the processor (See Kolawa Col. 11 line 47 – storing the latest date on which an item was sampled, Col. 12 lines 36-41 – user preferences are updated for future recipe/ dish recommendation choices, Col. 17 line 23-40 – user adjusting ingredient quantities and submitting an order request to one or more retailers for fulfillment, Col. 26 lines 4-16 – restaurants functioning as retailers and Col. 27 lines 45-65 – GUIs for adjusting a composition of a dish based on user preference, wherein said adjusting is of nutritional components, such as protein);
a process of receiving payment information corresponding to the dish order request from the third user terminal through the transceiver (See Kolawa Col. 16 lines 32-37 – receiving order information, including payment information); and
a process of sending the payment information to the restaurant terminal through the transceiver (See Kolawa Col. 18 lines 1-21 – sending order information to a retailer, wherein said order information includes user payment method [information]).
Regarding Claim 3, modified Kolawa teaches:
The method of claim 1, further comprising:
a process of, after the sending of the statistical information of the nutritional components consumed by date to the third user terminal through the transceiver (See Kolawa Col. 11 line 47 – storing the latest date on which an item was sampled and Col. 27 lines 35-54 – graphical user interfaces (GUI) for adjusting a composition of a dish based on user preference, wherein said adjusting is of nutritional components, such as protein), receiving user health-related information from the third user terminal through the transceiver (See Kolawa Col. 10 lines 10-43 – using health related questions, among others, to determine user preferences);
a process of, based on the user health-related information, generating one or more of information on recommended nutritional components and recommended nutritional ingredients corresponding to the third user terminal (See Kolawa Col. 10 lines 10-43 – using health related questions, among others, to determine user preferences and make recommendations for certain foods/ dishes [nutritional components by example] and Col. 27 lines 35-54 – graphical user interfaces (GUI) for adjusting a composition of a dish based on user preference, wherein said adjusting is of nutritional components/ ingredients, such as protein) and information on nutritional components to avoid or nutritional ingredients to avoid corresponding to the third user terminal thr