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 .
Receipt of Applicant’s Amendment filed April 28, 2026, is acknowledged.
Response to Amendment
Claim 1 has been amended. Claim 10 is new. Claims 1-10 are pending and are provided to be examined upon their merits.
Response to Arguments
Applicant's arguments filed April 28, 2026, have been fully considered but they are not persuasive. A response is provided below in bold where appropriate.
Applicant argues 35 USC §112(b) rejection, starting pg. 5 of Remarks:
II. RESPONSE TO REJECTION UNDER 35 U.S.C. § 112(b)
A. The Examiner's Rejection
The Examiner rejected Claims 1-9 as indefinite under 35 U.S.C. § 112(b), asserting that the term "high probability" in Claim 1 is a relative term that renders the claim indefinite because neither the claim nor the specification provides a standard for ascertaining the requisite degree. (Office Action, pp. 8-9.)
B. The Amendment Overcomes the Rejection
Applicant has amended Claim 1 to remove "high probability" and replace the limitation with the following language (shown in underline in the Amendment):
"...each recommended team being determined based on a probability model that calculates, using past user data including previous lifestyle habit information and goal achievement outcomes of a plurality of users, a likelihood that a respective team will improve the user's lifestyle habit, wherein a team is included in the plurality of recommended teams when the calculated likelihood satisfies a predetermined threshold..."
The amended language provides objectively clear boundaries: (i) a specific computational tool a probability model; (ii) specific inputs-past user data including previous lifestyle habit information and goal achievement outcomes; (iii) a specific output-a calculated likelihood; and (iv) a specific, objective criterion for selection-satisfaction of a predetermined threshold. A person of ordinary skill in the art would understand the scope of the claim with reasonable certainty.
Specification support for the amended "determining" limitation (Claim 1):
Support for "past user data including previous lifestyle habit information":
[0049]: User data 1000 stores "the lifestyle habit information (the number of steps (steps), a body weight (kg), meals (kcal), consumed calories (kcal), a sleeping time (hours; minutes), image data, text data, various kinds of data associated with dates in a calendar, and the like) "for each user. This constitutes 'past user data including previous lifestyle habit information."
Support for "goal achievement outcomes of a plurality of users":
[0051]: Team data 2000 includes "degree-of-achievement information (information shared in the team and regarding the degrees of achievement of the daily goals and the final goal, and the like)." This constitutes "goal achievement outcomes of a plurality of users." FIG. 5: Team data schema showing degree-of-achievement information as a stored field.
Support for "probability model...likelihood...predetermined threshold" (filtering to manageable set):
[0055]: "a manageable number of recommended teams may be provided to the user from among potentially thousands of available teams, so that the user is not swamped with more teams to choose from than they can practically evaluate." This establishes that a selection/filtering step-equivalent to applying a threshold to a calculated likelihood-is performed to arrive at a recommended subset.
Applicant has amended Claim 1 to include…
“… determining, according to information about the user and the team information of a plurality of teams, a plurality of recommended teams each recommended team being determined based on a probability model that calculates, using past user data including previous lifestyle habit information and goal achievement outcomes of a plurality of users, a likelihood that a respective team will improve the user’s lifestyle habit, wherein a team is included in the plurality of recommended teams when the calculated likelihood satisfies a predetermined threshold;…”
From Applicant’s specification on only use of “probability”…
“… In an embodiment, one or more teams may be recommended based on information on performance of teams in the past. The recommended teams may comprise members having characteristics that when combined with the characteristics of the user may match the characteristics of teams that were successful in the past, and accordingly may have a higher probability of success in improving the user's lifestyle. A trained machine learning (ML) model may be used to select the teams to recommend. Characteristics considered by the ML model) or by whatever algorithm used to recommend teams) may include basic information, lifestyle habit information, and degree-of-achievement information for the user and the members of the recommended teams. In such an embodiment, a manageable number of recommended teams may be provided to the user from among potentially thousands of available teams, so that the user is not swamped with more teams to choose from than they can practically evaluate…” [0055] (from Pub. No. 2025/0157620)
Respectfully, there is no teaching above of “probability model,” “probability model that calculates,” or “team is included in the plurality of recommended teams when the calculated likelihood satisfies a predetermined threshold.
The specification teaches match characteristics of teams in the past have a higher probability of success in improving a user’s lifestyle, and a manageable number of recommended teams may be provided.
FIG. 7A, FIG. 7B: Tutorial-based team recommendation interface showing teams presented to the user based on matching criteria.
Accordingly, the § 112(b) rejection of Claims 1-9 is overcome by amendment and is respectfully traversed. Applicant requests that the rejection be withdrawn as to all claims.
The 35 USC 112(b) rejection is withdrawn however the amendments have caused a new 35 USC 112(a) rejection.
Applicant argues 35 USC §103 rejection, starting pg. 7 of Remarks:
III. RESPONSE TO REJECTION UNDER 35 U.S.C. 103
A. Overview of the Cited References
1. Nagasaka (US 2022/0375569)
Nagasaka (the same inventor's prior publication) discloses a lifestyle habit improvement method in which users belonging to a team communicate via a chat communication interface, periodically report lifestyle habit information, and track goal achievement. The Examiner correctly acknowledges that Nagasaka does not teach determining a plurality of recommended teams based on probability of success.
2. Bhatia et al. (US 2014/02 79 720)
Bhatia discloses a "System and Method of Event Publication in a Goal Achievement Platform." Bhatia's system assigns users to groups based on a probability of success model, primarily to facilitate advertising, sponsorship, and endorsement monetization. Bhatia's "groups" are large categorical groupings used for commercial targeting-not small, member-capped chat teams with a mutual peer-confirmation mechanism.
3. Carmeli et al. (US 2013/0226612)
Carmeli discloses a "Framework for Evidence Based Case Structuring" in an oncology medical decision support context. Carmeli uses machine learning to divide cancer patient records into groups sharing common clinical characteristics (e.g., tumor size, lymph node status) for the purpose of recommending treatment options. Carmeli operates entirely within a clinical domain and has no chat communication interface, no lifestyle habit tracking, and no peer mission confirmation mechanism.
4. Kang et al. (US 2019/0198150)
Kang discloses a "Method for Tracking User Outcomes, Sentiment, and Satisfaction" during post-surgical physical therapy recovery, using a chat bot to deliver customized prompts and notifying care providers when a patient's profile deviates from recovery norms. Kang's system is directed entirely to medical rehabilitation.
B. Claims 1-5 and 8: Nagasaka + Bhatia - Rejection Is Traversed
1. The peer-confirmation-via-chat mechanism is not taught by the combination
The central distinguishing feature of Claim 1 is the following ordered sequence of limitations, which must be read together:
(a) "displaying the lifestyle habit information on the interface for chat communication"
(b) "receiving, from another user terminal of another user...a predetermined action with respect to the displaying of the lifestyle habit information of the user, to confirm that the user has achieved a predetermined mission...the other user belonging to the selected team"
(c) "determining that the user has achieved the predetermined mission based on the predetermined action to thereby specify a number of users who have achieved the predetermined mission in the selected team, compared to a total number of users who belong to the selected team"
This ordered combination requires: (i) posting lifestyle habit data to a shared team chat interface; (ii) a co-team-member who views that posted data performing a specific predetermined action through the same chat interface as peer attestation; and (iii) the server using that peer attestation to calculate an achievement ratio for the team. This is a specific, integrated social-accountability mechanism that is unique to the present invention.
Posting habit data is not claimed. co-team member who views the posted data is not claimed. Peer attestation to calculate a ratio is not claimed. Respectfully, Applicant needs to direct their arguments to their claim language.
Specification support - peer-confirmation mechanism:
[0058]: "Each user of the team views images and text posted by another user to confirm that this user has cleared a predetermined mission (for example, to measure the body weight every evening) with respect to the goal, and takes some action (for example, to make a stamp of a cat footprint) in order to prove the confirmation. According to these actions, the degree of achievement for the goal set by the team (or the goal of the day to be cleared for the goal) can be updated and visually displayed."
FIG. 8B: Shows the "3/5 PERSONS" achievement ratio display resulting from the peer-confirmation process.
[0031]: "Each team is composed of user members the upper limit number of which is defined (for example, five)"- establishing the "total number of users who belong to the selected team" denominator for the achievement ratio.
Neither Nagasaka nor Bhatia discloses this mechanism. In Bhatia, progress confirmation is obtained through self-declaration, demonstrations, or third-party evaluation-not through a specific peer action performed by a co-team-member viewing another member's lifestyle data posted to a shared chat interface and performing a confirmation action within that interface.
Applicant’s argument is not commensurate with the scope of their claims.
There is no teaching in Bhatia of: a shared chat display of lifestyle data serving as the trigger; a co-team-member's predetermined action in response to that display serving as confirmation; and the resulting peer-confirmed achievement being tallied as a ratio for team-level tracking.
Applicant’s arguments are not commensurate with the scope of their claims. For example, trigger and ratio are not claimed.
2. The server-side image processing sequence is not taught by the combination
Amended Claim 1 recites the following specific technical sequence:
(a) receiving, from the user terminal, image data of a body weight meter posted by the user;
(b) performing image processing on the received image data by the server terminal to extract text data included in the image data;
(c) identifying a body weight value from the extracted text data; and
(d) automatically inputting the identified body weight value into the storage unit as the lifestyle habit information.
This is a concrete, server-side technical implementation that transforms raw image data into structured numerical lifestyle data. The server terminal-not the user-performs the image processing. This data transformation cannot be performed mentally or with pen and paper.
The prior art of Nagasaka teaches user terminal and server terminal. From Nagasaka…
“Next, as the processing of step S103, the instruction acceptance unit 131 of the server terminal 100 accepts the lifestyle habit information from the user terminal 200 via the communication unit 110. The server terminal 100 accepts text and images regarding the lifestyle habits posted via the chat communication interface for the team which is displayed on the user terminal 100, for every predetermined period. For example, as shown in FIG. 8A, in the chat communication interface, when the user posts an image of a body weight meter, a region which the body weight value (kg) is entered in and a region which a message is entered in are displayed. The body weight value (kg) can also be extracted from the captured image as text data through OCR processing or the like and be automatically input. Moreover, input items (such, for example, as “today's body weight”) can also be displayed according to the goal shared in the team (for example, “recording the body weight every evening”). When accepting the lifestyle habit information from the user, the server terminal 100 displays the accepted information (for example, the body weight value (kg) input along with the image of the body weight meter (together with the message)), in the chat communication interface…” [0058]
The server terminal accepts images and OCR processes the image.
Specification support - image data reception and server-side image processing:
[0058]: "when the user posts an image of a body weight meter, a region which the body weight value (kg) is entered in and a region which a message is entered in are displayed." This describes receipt of image data of a body weight meter via the chat interface.
[0058]: "The body weight value (kg) can also be extracted from the captured image as text data through OCR processing or the like and be automatically input." The phrase "or the like" expressly indicates that the specification contemplates image-processing methods beyond OCR, providing written description support for the broader "performing image processing" language of amended Claim 1. The OCR-specific embodiment is separately claimed in new Claim 10.
[0049]: User data 1000 stores "image data" and "text data" as distinct data types within lifestyle habit information -consistent with the claim's description of transforming image data into text data.
FIG. 8A: Shows the body weight meter image posted by the user in the chat interface, with both an image region and a text (body weight value) region displayed.
Specification support - automatic storage:
[0058]: "...and be automatically input."Page 9 of
[0059]: "the user data management unit 132 of the server terminal 100 stores the accepted ifestyle habit information, associating it with the relevant user, in the user data 1000 stored in the user data storage 121."
Neither Nagasaka nor Bhatia discloses this four-step server-side image processing sequence. While the concept of posting body weight meter images appears in the underlying Nagasaka system, the combination of Nagasaka and Bhatia does not produce the specific server-side image data processing pipeline recited in amended Claim 1. Bhatia contains no image processing disclosure whatsoever.
Respectfully, Nagasaka alone teaches these steps as provided in the rejection. Applicant argues Nagasaka does not teach server-side image data processing.
From Nagasaka…
“Next, as the processing of step S103, the instruction acceptance unit 131 of the server terminal 100 accepts the lifestyle habit information from the user terminal 200 via the communication unit 110. The server terminal 100 accepts text and images regarding the lifestyle habits posted via the chat communication interface for the team which is displayed on the user terminal 100, for every predetermined period. For example, as shown in FIG. 8A, in the chat communication interface, when the user posts an image of a body weight meter, a region which the body weight value (kg) is entered in and a region which a message is entered in are displayed. The body weight value (kg) can also be extracted from the captured image as text data through OCR processing or the like and be automatically input. Moreover, input items (such, for example, as “today's body weight”) can also be displayed according to the goal shared in the team (for example, “recording the body weight every evening”). When accepting the lifestyle habit information from the user, the server terminal 100 displays the accepted information (for example, the body weight value (kg) input along with the image of the body weight meter (together with the message)), in the chat communication interface…” [0058]
Optical character recognition is image processing.
3. No motivation to combine
Bhatia is directed to an entirely different technical problem: monetizing user goal-achievement data through commercial advertising, sponsorship deals, and endorsements between brands and user communities. (Bhatia [0001]-[0003], [0029].) A person of ordinary skill in the art seeking to improve Nagasaka's lifestyle habit team system would have no reason to look to Bhatia's commercial advertising platform for guidance on implementing a peer-confirmation mechanism within a small chat team. The technical problem solved by the present invention-enabling lightweight peer-to-peer accountability within a small chat team through a simple confirmation action-is simply not the problem that Bhatia addresses.
Both Nagasaka and Bhatia are analogous prior art and motivation to combine was provided (see pg. 19 of Non-Final Rejection dated 1/28/2026).
For the foregoing reasons, the rejection of Claims 1-5 and 8 under § 103 is respectfully traversed.
Applicant has amended their claims. However, Nagasaka alone teaches most of the claimed elements. The rejection is respectfully modified for the claim amendments but maintained.
C. Claim 6: Nagasaka + Bhatia + Carmeli - Rejection Is Traversed
Carmeli discloses machine learning in an oncology treatment decision support context. Carmeli's ML is used to divide cancer patient records into groups sharing clinical characteristics (e.g., tumor stage, receptor status) to recommend treatment options. (Carmeli [0049].)
Carmeli is not analogous art to the present invention. The technical field (oncology treatment recommendation vs. lifestyle habit team recommendation), the nature of the "groups" (patient cohorts defined by clinical biomarkers vs. lifestyle improvement teams), the input data (clinical biomarker records vs. lifestyle habit history and achievement data), and the purpose of the ML model (predicting treatment outcomes vs. predicting team compatibility) are entirely distinct. No motivation to apply Carmeli's clinical ML grouping techniques to a social chat team recommendation system is established.
The combined references and Carmeli et al. are about recommend teams. Carmeli was only used to teach using machine learning to do this. It would be obvious machine learning can be used to recommend teams based on the combined prior art.
Specification support - Claim 6 (ML model for team recommendation):
[0055]: Server terminal presents teams to users based on matching of user characteristics and team attributes - implying an algorithmic/model-based determination of team fitness.
FIG. 7A, FIG. 7B: Tutorial-based team recommendation showing matching of user answers to team attributes.
Parent application 17/772,084: Additional ML-specific disclosure supporting the machine learning limitation.
Accordingly, the rejection of Claim 6 under § 103 is respectfully traversed.
The rejection is respectfully maintained as it is obvious machine learning can be used to recommend teams.
D. Claim 7: Nagasaka + Bhatia + Carmeli + Jain + Wagner - Rejection Is Traversed
Claim 7 further specifies that the ML model is selected from among a plurality of ML models respectively trained for groups of users having similar characteristics and goals. The Examiner relies on Jain et al. for the plurality-of-models feature and Wagner et al. for model selection.
The need to combine five references to arrive at Claim 7 itself demonstrates non-obviousness. Moreover, the combination would require taking a lifestyle chat team system (Nagasaka), adding probability modeling (Bhatia), applying medical ML grouping (Carmeli), incorporating plurality of ML models (Jain), and adding model selection (Wagner)-while maintaining the core peer- confirmation-via-chat mechanism that none of the references discloses.
The number of references used is not determinative of whether a claim is obvious. The combination teaches the claim element.
Specification support - Claim 7 (plurality of ML models for groups with similar characteristics and goals):
[0056]: "Here, each team is associated with major categories such as 'Recommended', 'Diet', and 'Fitness', and, for example, for the major category 'Fitness', minor categories such as 'Muscular Workout', 'Walking', and 'Walking Relay'." This categorical structure supports the concept of separate ML models trained for groups with similar goals.
[0051]: Team data 2000 includes "age restriction, sexuality restriction, an active period, an automatic leaving period, an assistant character, tag information"- establishing that teams are associated with user demographic characteristics that could serve as inputs for user-group-specific ML models.
FIG. 8B: Shows major and minor category classification including "University Entrance Examination" (corporate) and "ABC App Official" categories - illustrating the variety of group types that different ML models may be trained for.
Accordingly, the rejection of Claim 7 under § 103 is respectfully traversed.
The rejection is respectfully maintained.
E. Claim 9: Nagasaka + Bhatia + Kang - Rejection Is Traversed Kang discloses a chatbot in a post-surgical physical therapy recovery context that delivers customized prompts and notifies care providers when a patient deviates from recovery norms. (Kang [0007], [0020]-[0021].)
Claim 9 recites determining, from "prior interactions with the user," patterns of encouragement and praise that are "most effective in getting the user to perform a next action." This is a specific user-specific, interaction-history-based personalization mechanism-distinct from Kang's population-level grouping approach. Kang's system groups patients by clinical profile similarity to past patients; it does not analyze a specific user's own interaction history to identify which personalized encouragement patterns are most effective for that particular user.
Specification support - Claim 9 (chat bot encouragement from prior interactions):
[0070]: "in the server terminal 100 or another terminal, the lifestyle habit log(s) of one or a plurality of users can be analyzed to provide advice and to provide guidance for achieving the goal. For example, via the chat communication interface of the team, a chat bot, as an instructor, can encourage a user slowing down its actions and/or can advise a user falling behind with comparison of the lifestyle habit logs of a plurality of users."
[0049]: User data 1000 stores the full history of lifestyle habit information including "various kinds of data associated with dates in a calendar" -constituting the 'prior interactions with the user” from which patterns of most-effective encouragement are determined.
FIG. 10A: Lifestyle habit log display showing historical data over time -the stored history from which encouragement patterns are analyzed.
Furthermore, Kang is non-analogous art (medical rehabilitation vs. lifestyle habit improvement teams) and no motivation to combine is established.
Accordingly, the rejection of Claim 9 under § 103 is respectfully traversed.
The prior arts both teach chat bot. Motivation to combine was provided on pages 27-28 of the Non-Final Rejection dated 01/28/0226. The rejection is respectfully maintained.
Applicant argues 35 USC §101 rejection, starting pg. 12 of Remarks:
IV. RESPONSE TO REJECTION UNDER 35 U.S.C. § 101
A. Step 1- Statutory Category
The Examiner correctly found that Claims 1-9 are directed to a "method," which is a statutory category under § 101. (Office Action, p. 2.) This is not disputed.
B. Step 2A, Prong 1 - The Claims Are Not Directed to an Abstract Idea The
Examiner characterized the claim limitations as "Certain Methods of Organizing Human Activity" (managing personal behavior, following rules/instructions, teaching) and "Mental Processes" (steps performable mentally or with pen and paper). (Office Action, pp. 3-6.)Page 12 of 19
Applicant respectfully submits that this characterization improperly strips the claim of its specific technological context.
Amended Claim 1 recites a specific server-terminal-implemented sequence that transforms image data into structured numerical lifestyle data:
Step (i): The server terminal receives image data of a body weight meter from a user terminal.
Step (ii): The server terminal performs image processing on that image data to extract text data.
Step (iii): The server terminal identifies a body weight value from the extracted text data.
Step (iv): The server terminal automatically inputs the identified value into storage.
This four-step sequence-image data -- server-side image processing -- text extraction - automatic database entry-cannot be performed as a mental process or with pen and paper. A human cannot "perform image processing" to extract text from a body weight meter image and automatically store the result. This is a machine operation, not a method of organizing human activity.
Respectfully, a person can extract text data (e.g. copy text using pen and paper) included in image data.
Using a machine such as a server terminal to extract text is not enough to make abstract claims statutory and is recited at as a generic machine at a high level of generality.
Amended Claim 1 also recites a peer-confirmation mechanism intrinsically tied to the technical implementation of the chat interface:
Lifestyle habit data is displayed on the chat communication interface.
A co-team-member's viewing of that data and performance of a predetermined action through the same interface serves as peer attestation.
The server processes that peer attestation to update a team-level achievement ratio.
This is not merely "managing interactions between people." The chat interface simultaneously serves as: a display medium for posted lifestyle data; an input medium for peer confirmation actions; and the trigger for a server-side achievement computation. This specific, multi- functional technical role of the chat interface is not a generic computer function and cannot be reduced to a mental process.
Using a computer to automate a manual process has been shown not to be enough to make abstract claims statutory.
C. Step 2A, Prong 2 - The Claims Are Integrated into a Practical Application
Even assuming some elements recite an abstract idea, the claim as a whole is integrated into a practical application. The claimed invention concretely improves lifestyle habit improvement systems in three specific ways:
(1) Automated image processing reduces data entry burden and errors: By
receiving image data and automatically identifying and storing the body weight value through server-side image processing, the method eliminates manual numeric entry, reducing user effort and data entry errors.
(2) Novel peer-accountability mechanism via chat interface: The specific
combination of displaying lifestyle data on a chat interface and enabling co-team- members to perform a simple confirmation action through that same interface creates a frictionless peer-accountability mechanism that leverages existing chat infrastructure in a new and specific way.
(3) Probability-model-based team recommendation with threshold: The claimed probability model, trained on historical lifestyle habit data and goal achievement outcomes, with a predetermined threshold for team selection, provides a specific technical mechanism for matching users to teams likely to help them succeed-a practical improvement over manual or random team selection.
Automating a manual process is not enough as claimed to make abstract claims statutory.
Using a chat interface is recited at a high level of generality. Also, communicating between people is an abstract process as claimed (interaction between people).
The “probability model” is not taught and it would not be enough as it is itself abstract.
Specification support - practical benefits of the invention:
[0060]: "the user can take continuous actions for achieving the goal by posting appointed lifestyle habit information for every predetermined period under mutual communication for achieving the goal, and can continuously acquire the information regarding the lfestyle habits and acquire the history thereof comfortably under such communication." This describes the concrete practical benefit.
[0058]: The body weight extraction feature enables automatic input, directly reducing user burden in lfestyle data recording - a concrete improvement in system usability.
[0055]: The team recommendation feature prevents users from being "swamped" - a concrete improvement in usability.
The Office Action notes that the server terminal "can be generic computer hardware" (citing [0002]) and that chat communication is at a "high level of generality" (citing [0007]). (Office Action, p. 6.) However, this analysis fails to consider the specific technical manner in which these components are used together-specifically, the server terminal's server-side image processing function and the chat interface's simultaneous display-and-peer-input role-which are not generic computer functions.
The rejection is based on using a generic computer to perform functions at a high level of generality. A generic computer is performing the claimed functions. Functions can be novel, but abstract.
D. Step 2B - The Claims Provide Significantly More Even if the claims were found to recite an abstract idea not integrated into a practical application (which Applicant denies), the specific ordered combination of: (a) server-side image processing to extract and automatically store body weight values; (b) probability-model-based team recommendation with predetermined threshold; and (c) chat-interface-based peer confirmation updating a team achievement ratio-was not well-understood, routine, or conventional in the field of lifestyle habit improvement applications at the time of the invention. This combination represents an inventive concept significantly more than any abstract idea.
The rejection is not based on well-understood, routine, or conventional.
The Office Action states that "receiving and providing, and storing are steps that are considered insignificant extra solution activity." (Office Action, p. 7.) However, Step 2B requires consideration of the additional elements as an ordered combination-not individually. See MPEP § 2106.05(d). When the image processing, peer-confirmation, and probability-model elements are considered together, they provide significantly more.
Applicant respectfully requests that the § 101 rejection be withdrawn.
The rejection is respectfully maintained but modified for the claim amendments.
Applicant provides support for claim amendment, starting pg. 15 of Remarks:
Examiner thanks Applicant for providing the support. Respectfully disagree with Applicant on amendment about probability model and threshold being taught.
Priority
Applicant has filed the instant application as a continuation-in-part of parent application 17/772084.
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-10 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Claims 1-10 are directed to a method, which is a statutory category of invention. (Step 1: YES).
The Examiner has identified method Claim 1 as the claim that represents the claimed invention for analysis.
Claim 1 recites the limitations of:
A providing method of lifestyle habit improvement for a user, the method comprising performing, by a server terminal:
storing, in a storage unit of the server terminal, team information of a plurality of teams, the team information including information of each of the plurality of teams, information of members of each of the plurality of teams, goal of lifestyle habit, and a degree of achievement of the goal of lifestyle habit;
determining, according to information about the user and the team information of a plurality of teams, a plurality of recommended teams each recommended team being determined based on a probability model that calculates, using past user data including previous lifestyle habit information and goal achievement outcomes of a plurality of users, a likelihood that a respective team will improve the user’s lifestyle habit, wherein a team is included in the plurality of recommended teams when the calculated likelihood satisfies a predetermined threshold;
providing, to a user terminal, a list of teams including the plurality of recommended teams;
receiving, from a user terminal, a request for selecting from the list of teams one of the plurality of teams that is a desired team by a user;
storing, in the storage unit, information of the user to be associated with the selected team;
receiving, from the user terminal, lifestyle habit information of the user for every predetermined period, inputted by the user;
storing, in the storage unit, the lifestyle habit information of the user to be associated with the information of the user stored in the storage unit;
displaying the lifestyle habit information on the interface for chat communication;
receiving, from another user terminal of another user, which is different from the user, a predetermined action with respect to the displaying of the lifestyle habit information of the user, to confirm that the user has achieved a predetermined mission of a goal of lifestyle habit of the selected team, the other user belonging to the selected team;
determining that the user has achieved the predetermined mission based on the predetermined action to thereby specify a number of users who have achieved the predetermined mission in the selected team, compared to a total number of users who belong to the selected team;
storing, in the storage unit, the specified number of users as a degree of achievement to be associated with the information of the selected team; and
displaying information of the degree of achievement of the goal on the interface for chat communication, wherein the lifestyle habit information includes information of a body weight, and receiving the lifestyle habit information comprises:
receiving, from the user terminal, image data of a body weight meter posted by the user,
performing image processing on the received image data by the server terminal to extract text data included in the image data, identifying a body weight value from the extracted text data; and
automatically inputting the body weight value into the storage unit as the lifestyle habit information.
These above limitations, under their broadest reasonable interpretation, cover performance of the limitation as certain methods of organizing human activity. The claim recites elements, in bold above, which covers performance of the limitation as managing personal behavior and interactions between people. Determining a plurality of recommended teams (teaching), providing a list of teams of the recommended teams (teaching), receiving a request for selecting from the list of teams one team desired by a user (following rules and instructions), storing information of the user associated with the selected team, receiving lifestyle habit information of the user (following rules and instructions, storing the lifestyle habit information of the user, receiving an image of a body weight meter posted by a user (following rules and instructions), extracting a body weight value from the image, and input the body weight value into the storage unit as lifestyle habit information is managing personal behavior by following rules or instructions. Receiving from another user different from the user a predetermined action to confirm the user has achieved a predetermined mission of a goal of lifestyle habit of the selected team (teaching), determining the user has achieved the predetermined mission to specify a number of users who have achieved the predetermined mission in the selected team, and storing the specified number of users as a degree of achievement is managing interactions between people including following rules or instructions and teaching. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation as managing personal behavior and interactions between people, then it falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. Accordingly, the claim recites an abstract idea. Therefore, claim 1 is abstract. (Step 2A-Prong 1: YES. The claims are abstract)
The claims are also abstract as a mental process. A person can analyze (determine) data and receive (read) and provide/store (write down with pen and paper) various steps. The team information can be stored (written down), determine information about a user (mental process), providing a list (write down) of teams including recommended teams, receiving (read and comprehend) a request for selecting from a list of teams one of the teams (make judgement mentally), storing information (write down) of a user associated with the selected team, receiving lifestyle habit information of the user, store (write down) the information, receive from another user predetermined action (read action from other user), determining the user has achieved the predetermined action (mental analysis), store (write down) the number of users as a degree of achievement, display information (pen and paper) degree of achievement.
This judicial exception is not integrated into a practical application. In particular, the claims only recite: server terminal, storage unit, user terminal, interface, and another user terminal (Claim 1). The computer hardware is recited at a high-level of generality (i.e., as a generic processor performing a generic computer function) such that it amounts no more than mere instructions to apply the exception using a generic computer component. The server terminal can be generic computer hardware (para. [0002] of the specification) and the chat communication is recited and taught at a high level of generality (para. [0007] of the specification. The performing image processing on the received image is recited at a high level of generality. Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. Therefore claim 1 is directed to an abstract idea without a practical application. (Step 2A-Prong 2: NO. The additional claimed elements are not integrated into a practical application)
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when considered separately and as an ordered combination, they do not add significantly more (also known as an “inventive concept”) to the exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional element of using a computer hardware amounts to no more than mere instructions to apply the exception using a generic computer component. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. Steps such as receiving and providing, and storing are steps that are considered insignificant extra solution activity and mere instructions to apply the exception using general computer components (see MPEP 2106.05(d), II). Thus claim 1 is not patent eligible. (Step 2B: NO. The claims do not provide significantly more)
Dependent claims 2-10 further define the abstract idea that is present in their respective independent claim 1 and thus correspond to Certain Methods of Organizing Human Activity and Mental Processes and hence are abstract for the reasons presented above. The dependent claims do not include any additional elements that integrate the abstract idea into a practical application or are sufficient to amount to significantly more than the judicial exception when considered both individually and as an ordered combination. Claims 2-5 further limit the abstract idea or are abstract themselves. Claim 2 recites user terminal which is recited at a high level of generality. Claims 6 and 7 recite machine learning where at a high level of generality and where machine is a generic machine. Claims 8 and 9 recite chat bot at a high level of generality. Claim 10 recites optical character processing at a high level of generality. Therefore, the claims 2-10 are directed to an abstract idea. Thus, the claims 1-10 are not patent-eligible.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-10 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claim 1 recites…
“determining, according to information about the user and the team information of a plurality of teams, a plurality of recommended teams each recommended team being determined based on a probability model that calculates, using past user data including previous lifestyle habit information and goal achievement outcomes of a plurality of users, a likelihood that a respective team will improve the user’s lifestyle habit, wherein a team is included in the plurality of recommended teams when the calculated likelihood satisfies a predetermined threshold;
From Applicant’s specification:
“… In an embodiment, one or more teams may be recommended based on information on performance of teams in the past. The recommended teams may comprise members having characteristics that when combined with the characteristics of the user may match the characteristics of teams that were successful in the past, and accordingly may have a higher probability of success in improving the user's lifestyle. A trained machine learning (ML) model may be used to select the teams to recommend. Characteristics considered by the ML model) or by whatever algorithm used to recommend teams) may include basic information, lifestyle habit information, and degree-of-achievement information for the user and the members of the recommended teams. In such an embodiment, a manageable number of recommended teams may be provided to the user from among potentially thousands of available teams, so that the user is not swamped with more teams to choose from than they can practically evaluate…” [0055] (from Pub. No. 2025/0157620)
There is no teaching above of “probability model,” “probability model that calculates,” or “team is included in the plurality of recommended teams when the calculated likelihood satisfies a predetermined threshold.
The specification teaches match characteristics of teams in the past have a higher probability of success in improving a user’s lifestyle, and a manageable number of recommended teams may be provided.
Claims 2-10 are rejected as they depend from Claim 1.
Examiner Request
The Applicant is requested to indicate where in the specification there is support for amendments to claims should Applicant amend. The purpose of this is to reduce potential 35 U.S.C. §112(a) or §112 1st paragraph issues that can arise when claims are amended without support in the specification. The Examiner thanks the Applicant in advance.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-5, 8, and 10 are rejected under 35 U.S.C. 103 as being unpatentable over Pub. No. US 2022/0375569 to Nagasaka in view of Pub. No. US 2014/0279720 to Bhatia et al.
Regarding claim 1
A providing method of lifestyle habit improvement for a user, the method comprising performing, by a server terminal:
storing, in a storage unit of the server terminal, team information of a plurality of teams, the team information including information of each of the plurality of teams, information of members of each of the plurality of teams, goal of lifestyle habit, and a degree of achievement of the goal of lifestyle habit;
Nagasaka teaches:
Storing in a storage of a server terminal, lifestyle information…
“In a providing method of lifestyle habit improvement according to an aspect of the present invention, improvement is provided for a user belonging to a team in which a plurality of users communicate via an interface for chat communication, the method comprising, by a server terminal: accepting, from a user terminal, a request for selecting a desired team by a user; enrolling the user in the team; accepting, from the user terminal, lifestyle habit information of the user for every predetermined period; and storing the lifestyle habit information in a user data storage of the server terminal.” [0007]
Plurality of teams information can be stored…
“Team data 2000 shown in FIG. 5 stores the various kinds of data regarding the team. While FIG. 5 shows an example of one team (team identified by a team ID “20001”) for convenience of description, information of a plurality of teams can be stored. The various kinds of data regarding each team can include the basic information of the team (a team name, age restriction, sexuality restriction, an active period, an automatic leaving period, an assistant character, tag information, and the like), information of the members belonging to it (user IDs, user names, and the like), communication information (histories of messages and images posted to the chat communication interface for the team, and the like), and degree-of-achievement information (information shared in the team and regarding the degrees of achievement of the daily goals and the final goal, and the like), for example.
determining, according to information about the user and the team information of a plurality of teams, a plurality of recommended teams each recommended team being determined based on a probability model that calculates, using past user data including previous lifestyle habit information and goal achievement outcomes of a plurality of users, a likelihood that a respective team will improve the user’s lifestyle habit, wherein a team is included in the plurality of recommended teams when the calculated likelihood satisfies a predetermined threshold;
Lifestyle habit improvement by belonging to a team…
“In a providing method of lifestyle habit improvement according to an aspect of the present invention, improvement is provided for a user belonging to a team in which a plurality of users communicate via an interface for chat communication, the method comprising, by a server terminal: accepting, from a user terminal, a request for selecting a desired team by a user; enrolling the user in the team; accepting, from the user terminal, lifestyle habit information of the user for every predetermined period; and storing the lifestyle habit information in a user data storage of the server terminal.” [0007]
Presents some teams (determining a plurality of teams) to be selected…
“First, as the processing of step S101, the instruction acceptance unit 131 of the server terminal 100 receives a request for selecting a desired team from the user terminal 200 via the communication unit 110. For example, as shown in FIG. 7A and FIG. 7B, the server terminal 100 presents some teams to be selected for the user in some manners on user interface screens each displayed on the user terminal 100. For example, as shown in FIG. 7A, it can recommend a team on the basis of the contents of the user's answers with respect to some questions for the user on a tutorial screen that is for a beginner user. For example, it can recommend a team the goal of which is to “record the body weight every evening” when it questions the user about something to want to work on and the user answers “body weight management”. Otherwise, the server terminal 100 can present team candidates satisfying conditions through a keyword search request. When the user selects the desired team, the selection request for the team is transmitted to the server terminal 100 from the user terminal 200 via the network.” [0055]
Acquire history of lifestyle habits…
“As above, in a user group in which a plurality of users have the common goal and the chat communication is enabled among them, the user can take continuous actions for achieving the goal by posting appointed lifestyle habit information for every predetermined period under mutual communication for achieving the goal, and can continuously acquire the information regarding the lifestyle habits and acquire the history thereof comfortably under such communication” [0060]
See Probability and Success below.
providing, to a user terminal, a list of teams including the plurality of recommended teams;
Presents teams (lists) some teams…
“First, as the processing of step S101, the instruction acceptance unit 131 of the server terminal 100 receives a request for selecting a desired team from the user terminal 200 via the communication unit 110. For example, as shown in FIG. 7A and FIG. 7B, the server terminal 100 presents some teams to be selected for the user in some manners on user interface screens each displayed on the user terminal 100. For example, as shown in FIG. 7A, it can recommend a team on the basis of the contents of the user's answers with respect to some questions for the user on a tutorial screen that is for a beginner user. For example, it can recommend a team the goal of which is to “record the body weight every evening” when it questions the user about something to want to work on and the user answers “body weight management”. Otherwise, the server terminal 100 can present team candidates satisfying conditions through a keyword search request. When the user selects the desired team, the selection request for the team is transmitted to the server terminal 100 from the user terminal 200 via the network.” [0055]
receiving, from a user terminal, a request for selecting from the list of teams one of the plurality of teams that is a desired team by a user;
Receive request for selecting team from user terminal…
“First, as the processing of step S101, the instruction acceptance unit 131 of the server terminal 100 receives a request for selecting a desired team from the user terminal 200 via the communication unit 110. For example, as shown in FIG. 7A and FIG. 7B, the server terminal 100 presents some teams to be selected for the user in some manners on user interface screens each displayed on the user terminal 100. For example, as shown in FIG. 7A, it can recommend a team on the basis of the contents of the user's answers with respect to some questions for the user on a tutorial screen that is for a beginner user. For example, it can recommend a team the goal of which is to “record the body weight every evening” when it questions the user about something to want to work on and the user answers “body weight management”. Otherwise, the server terminal 100 can present team candidates satisfying conditions through a keyword search request. When the user selects the desired team, the selection request for the team is transmitted to the server terminal 100 from the user terminal 200 via the network.” [0055]
storing, in the storage unit, information of the user to be associated with the selected team;
Store user data of the selection request…
“Next, as the process of step S102, the user data processing unit 132 of the server terminal 100 refers to the user information of transmission of the selection request from the user data 1000 stored in the user data storage 121, and the team data processing unit 133 refers to the team data 2000 stored in the team data storage 122 on the basis of the user information referred to and performs processing of enrolling the user in the relevant team. For example, when the server terminal 100 accepts a request for selecting a team named “recording the body weight every evening” from a user X, it performs processing of enrolling the user X in “recording the body weight every evening”.” [0057]
receiving, from the user terminal, lifestyle habit information of the user for every predetermined period, inputted by the user;
Accepting from the user terminal lifestyle habit information for a predetermined period…
“In a providing method of lifestyle habit improvement according to an aspect of the present invention, improvement is provided for a user belonging to a team in which a plurality of users communicate via an interface for chat communication, the method comprising, by a server terminal: accepting, from a user terminal, a request for selecting a desired team by a user; enrolling the user in the team; accepting, from the user terminal, lifestyle habit information of the user for every predetermined period; and storing the lifestyle habit information in a user data storage of the server terminal.” [0007]
storing, in the storage unit, the lifestyle habit information of the user to be associated with the information of the user stored in the storage unit;
Storing in the user data storage lifestyle habit information…
“In a providing method of lifestyle habit improvement according to an aspect of the present invention, improvement is provided for a user belonging to a team in which a plurality of users communicate via an interface for chat communication, the method comprising, by a server terminal: accepting, from a user terminal, a request for selecting a desired team by a user; enrolling the user in the team; accepting, from the user terminal, lifestyle habit information of the user for every predetermined period; and storing the lifestyle habit information in a user data storage of the server terminal.” [0007]
displaying the lifestyle habit information on the interface for chat communication;
Chat communication and display mage (lifestyle habit information) …
“Next, as the processing of step S103, the instruction acceptance unit 131 of the server terminal 100 accepts the lifestyle habit information from the user terminal 200 via the communication unit 110. The server terminal 100 accepts text and images regarding the lifestyle habits posted via the chat communication interface for the team which is displayed on the user terminal 100, for every predetermined period. For example, as shown in FIG. 8A, in the chat communication interface, when the user posts an image of a body weight meter, a region which the body weight value (kg) is entered in and a region which a message is entered in are displayed. The body weight value (kg) can also be extracted from the captured image as text data through OCR processing or the like and be automatically input. Moreover, input items (such, for example, as “today's body weight”) can also be displayed according to the goal shared in the team (for example, “recording the body weight every evening”). When accepting the lifestyle habit information from the user, the server terminal 100 displays the accepted information (for example, the body weight value (kg) input along with the image of the body weight meter (together with the message)), in the chat communication interface. Each user of the team views images and text posted by another user to confirm that this user has cleared a predetermined mission (for example, to measure the body weight every evening) with respect to the goal, and takes some action (for example, to make a stamp of a cat footprint) in order to prove the confirmation. According to these actions, the degree of achievement for the goal set by the team (or the goal of the day to be cleared for the goal) can be updated and visually displayed. Moreover, as shown in FIG. 8B, one user which the team is composed of can also visually display the degree of achievement for itself as an individual using a predetermined image (acquired from the server terminal 100 or an external resource).” [0058]
receiving, from another user terminal of another user, which is different from the user, a predetermined action with respect to the displaying of the lifestyle habit information of the user, to confirm that the user has achieved a predetermined mission of a goal of lifestyle habit of the selected team, the other user belonging to the selected team;
Chat communication among user group and communication among them (receiving from another user) goal…
“As above, in a user group in which a plurality of users have the common goal and the chat communication is enabled among them, the user can take continuous actions for achieving the goal by posting appointed lifestyle habit information for every predetermined period under mutual communication for achieving the goal, and can continuously acquire the information regarding the lifestyle habits and acquire the history thereof comfortably under such communication.” [0060]
determining that the user has achieved the predetermined mission based on the predetermined action to thereby specify a number of users who have achieved the predetermined mission in the selected team, compared to a total number of users who belong to the selected team;
Confirm (determine) user has cleared (achieved) predetermined mission)…
“… Each user of the team views images and text posted by another user to confirm that this user has cleared a predetermined mission (for example, to measure the body weight every evening) with respect to the goal, and takes some action (for example, to make a stamp of a cat footprint) in order to prove the confirmation. According to these actions, the degree of achievement for the goal set by the team (or the goal of the day to be cleared for the goal) can be updated and visually displayed. Moreover, as shown in FIG. 8B, one user which the team is composed of can also visually display the degree of achievement for itself as an individual using a predetermined image (acquired from the server terminal 100 or an external resource).” [0058]
Upper limit (total number) of users and achieve shared goal…
“The server terminal 100 generates, by users as customers of the service or a service provider, a plurality of chat groups each called a “team” composed of a plurality of users. Each team is associated with predetermined categories associated with a habit the goal of which the users want to achieve, and is composed of user members the upper limit number of which is defined (for example, five). Each of the users aims to achieve the goal (for example, “to lose 10 kg of body weight”) shared in the team while they are posting messages and images regarding the challenges to achieve the goal and mutually encouraging the other users via a chat communication interface for the team. The server terminal 100 may be a general-purpose computer such, for example, as a workstation or a personal computer, or may be logically implemented through cloud computing. While in the present embodiment, one server terminal is exemplarily presented for convenience of description, there may be a plurality of those with no limitation.” [0031]
Degree of achievement…
“… According to these actions, the degree of achievement for the goal set by the team (or the goal of the day to be cleared for the goal) can be updated and visually displayed. Moreover, as shown in FIG. 8B, one user which the team is composed of can also visually display the degree of achievement for itself as an individual using a predetermined image (acquired from the server terminal 100 or an external resource).” [0058]
Fig. 8B teaches 3/5 persons, therefore, number of users to total number…
PNG
media_image1.png
376
306
media_image1.png
Greyscale
storing, in the storage unit, the specified number of users as a degree of achievement to be associated with the information of the selected team; and
Stores team data and degree-of achievement…
“Team data 2000 shown in FIG. 5 stores the various kinds of data regarding the team. While FIG. 5 shows an example of one team (team identified by a team ID “20001”) for convenience of description, information of a plurality of teams can be stored. The various kinds of data regarding each team can include the basic information of the team (a team name, age restriction, sexuality restriction, an active period, an automatic leaving period, an assistant character, tag information, and the like), information of the members belonging to it (user IDs, user names, and the like), communication information (histories of messages and images posted to the chat communication interface for the team, and the like), and degree-of-achievement information (information shared in the team and regarding the degrees of achievement of the daily goals and the final goal, and the like), for example.” [0051]
displaying information of the degree of achievement of the goal on the interface for chat communication, wherein the lifestyle habit information includes information of a body weight, and receiving the lifestyle habit information comprises:
receiving, from the user terminal, image data of a body weight meter posted by the user,
Post image of body weight meter…
“Next, as the processing of step S103, the instruction acceptance unit 131 of the server terminal 100 accepts the lifestyle habit information from the user terminal 200 via the communication unit 110. The server terminal 100 accepts text and images regarding the lifestyle habits posted via the chat communication interface for the team which is displayed on the user terminal 100, for every predetermined period. For example, as shown in FIG. 8A, in the chat communication interface, when the user posts an image of a body weight meter, a region which the body weight value (kg) is entered in and a region which a message is entered in are displayed. The body weight value (kg) can also be extracted from the captured image as text data through OCR processing or the like and be automatically input. Moreover, input items (such, for example, as “today's body weight”) can also be displayed according to the goal shared in the team (for example, “recording the body weight every evening”). When accepting the lifestyle habit information from the user, the server terminal 100 displays the accepted information (for example, the body weight value (kg) input along with the image of the body weight meter (together with the message)), in the chat communication interface. Each user of the team views images and text posted by another user to confirm that this user has cleared a predetermined mission (for example, to measure the body weight every evening) with respect to the goal, and takes some action (for example, to make a stamp of a cat footprint) in order to prove the confirmation. According to these actions, the degree of achievement for the goal set by the team (or the goal of the day to be cleared for the goal) can be updated and visually displayed. Moreover, as shown in FIG. 8B, one user which the team is composed of can also visually display the degree of achievement for itself as an individual using a predetermined image (acquired from the server terminal 100 or an external resource).” [0058]
Fig. 1, ref. 200 teach user terminal…
PNG
media_image2.png
302
492
media_image2.png
Greyscale
Accepting from user terminal lifestyle habit information of the user…
“In a providing method of lifestyle habit improvement according to an aspect of the present invention, improvement is provided for a user belonging to a team in which a plurality of users communicate via an interface for chat communication, the method comprising, by a server terminal: accepting, from a user terminal, a request for selecting a desired team by a user; enrolling the user in the team; accepting, from the user terminal, lifestyle habit information of the user for every predetermined period; and storing the lifestyle habit information in a user data storage of the server terminal.” [0007]
performing image processing on the received image data by the server terminal to extract text data included in the image data, identifying a body weight value from the extracted text data; and
Server accepts images and extract body weight from image using OCR (optical character recognition)…
“Next, as the processing of step S103, the instruction acceptance unit 131 of the server terminal 100 accepts the lifestyle habit information from the user terminal 200 via the communication unit 110. The server terminal 100 accepts text and images regarding the lifestyle habits posted via the chat communication interface for the team which is displayed on the user terminal 100, for every predetermined period. For example, as shown in FIG. 8A, in the chat communication interface, when the user posts an image of a body weight meter, a region which the body weight value (kg) is entered in and a region which a message is entered in are displayed. The body weight value (kg) can also be extracted from the captured image as text data through OCR processing or the like and be automatically input. Moreover, input items (such, for example, as “today's body weight”) can also be displayed according to the goal shared in the team (for example, “recording the body weight every evening”). When accepting the lifestyle habit information from the user, the server terminal 100 displays the accepted information (for example, the body weight value (kg) input along with the image of the body weight meter (together with the message)), in the chat communication interface. Each user of the team views images and text posted by another user to confirm that this user has cleared a predetermined mission (for example, to measure the body weight every evening) with respect to the goal, and takes some action (for example, to make a stamp of a cat footprint) in order to prove the confirmation. According to these actions, the degree of achievement for the goal set by the team (or the goal of the day to be cleared for the goal) can be updated and visually displayed. Moreover, as shown in FIG. 8B, one user which the team is composed of can also visually display the degree of achievement for itself as an individual using a predetermined image (acquired from the server terminal 100 or an external resource).” [0058]
automatically inputting the body weight value into the storage unit as the lifestyle habit information.
Extract body weight from image and automatically input the data…
“Next, as the processing of step S103, the instruction acceptance unit 131 of the server terminal 100 accepts the lifestyle habit information from the user terminal 200 via the communication unit 110. The server terminal 100 accepts text and images regarding the lifestyle habits posted via the chat communication interface for the team which is displayed on the user terminal 100, for every predetermined period. For example, as shown in FIG. 8A, in the chat communication interface, when the user posts an image of a body weight meter, a region which the body weight value (kg) is entered in and a region which a message is entered in are displayed. The body weight value (kg) can also be extracted from the captured image as text data through OCR processing or the like and be automatically input. Moreover, input items (such, for example, as “today's body weight”) can also be displayed according to the goal shared in the team (for example, “recording the body weight every evening”). When accepting the lifestyle habit information from the user, the server terminal 100 displays the accepted information (for example, the body weight value (kg) input along with the image of the body weight meter (together with the message)), in the chat communication interface. Each user of the team views images and text posted by another user to confirm that this user has cleared a predetermined mission (for example, to measure the body weight every evening) with respect to the goal, and takes some action (for example, to make a stamp of a cat footprint) in order to prove the confirmation. According to these actions, the degree of achievement for the goal set by the team (or the goal of the day to be cleared for the goal) can be updated and visually displayed. Moreover, as shown in FIG. 8B, one user which the team is composed of can also visually display the degree of achievement for itself as an individual using a predetermined image (acquired from the server terminal 100 or an external resource).” [0058]
Probability and Success
Nagasaka teaches teams to be selected. They do not teach a plurality of teams and probability of success.
Bhatia et al. also in the business of teams teaches:
Groups (teams) and success of goal achievement…
“Model, or models, 104 may be trained using data collected about users, user groups, goals, categories, advertisers, publishers, outcomes, e.g., success/failure, of previous attempts at goal achievement, etc. The data may also comprise data about actions taken, or motivators used, to motivate a group of users, such as without limitation to action taken, the point at which the action was taken the probability of success before the action was taken, the probability of success after the action was taken, etc. The data may further include a progression plan for a given category or goal, which plan may comprise a set of milestones, or states, in the progression toward achieving a goal and criteria for transitioning from one milestone/state to another. The data collected might be stored in data store(s) 114. While data store(s) 114 is/are shown as being internal to system 100, it should be apparent that some or all of the data may be stored and/or maintained externally, e.g., by one or more systems external to system 100. Additionally, it should be apparent that models 104 may be included in data stores 114. In accordance with one or more embodiments, model(s) 114 is/are trained using training data for users that succeeded in their endeavors and users that failed in their endeavors, as well as the items, e.g., goals, milestones, mechanisms, progression pathways, etc., associated with the users' successful and unsuccessful endeavors, and data collected about the items and the users' endeavors.” [0033]
Recommend to a user alternative groups to achieve a goal…
“Model(s) 104 may be used by recommender 106 of system 100 to recommend one or more goals to a user and/or recommend one or more alternative user groups for a user seeking to achieve a goal. Model(s) 104 may be used by progress manager 108 of system 100 to suggest timely interventions, e.g., in the form of one or more actions to be taken, which interventions/actions may be sourced across the community, including without limitation sourced by users/user groups 118, publishers/advertisers 116, and/or other entities 120. By way of a non-limiting example, progress manager 108 might suggest an event or competition. By way of another non-limiting example, progress manager 108 might make suggestions with regard to assigning a new user to a user group, reassigning a user to another user group, modifying the plan for progression toward a goal, etc.” [0035]
Recommend users for a group, based on likelihood of success given available groups….
“Recommender 106 may recommend users for a group, which group is pursuing a collective goal within a category. System 100 may be used to align users in a group based on proficiency, targeted improvement rates, or category specific distinctions. In accordance with one or more embodiments, recommendations are made based on a likelihood of success given the available groups and taking into account the impact of the individual users within a given group or groups.” [0039]
Match categories and recommend threshold probability of success for any value and may be set for some or all users…
“By way of a further non-limiting example, system 100 may use model(s) 114 to match a user with a set of categories and/or a category map as recommendation(s), and may present the user with the recommendation(s) so that the user is able to select a category. The category recommendation(s) may be based on a favorable probability of success, e.g., at least a threshold probability, such as without limitation a 75% probability, associated with the category recommendations. For example, the probability of success for a given category may be based on a probability of success of the user achieving a goal, or goals, associated with the category. It should be apparent that the threshold probability of success may be any value, and further that the value may be common for some or all of the users and/or may be uniquely set for some or all of the users.” [0049]
Another example of probably of success with threshold for group…
“Endorsements that are provided by system 100 may be micro-endorsements that provide an alternative to mega endorsement deals, e.g., mega endorsement deals by large brand advertisers with celebrities. Embodiments of the present disclosure allow for endorsements, and associations with users/user groups, which are conditioned on demonstrated progress, and system 100 may be used to identify alternative users/user groups that may replace currently-endorsed users/user groups where the current users/user groups fail to maintain a threshold progress and/or probability of success. This enables automatic and relevant dynamically selected endorsees for the message that needs to be communicated via campaigns.” [0095]
Where categories relate to improve category of breaking a habit…
“FIG. 2 provides examples of categories that may be used in system 100 in accordance with one or more embodiments of the present disclosure. A hierarchy, or map, of categories is shown, which map/hierarchy includes an achieve category and an improve category. Categories under the achieve category include grades, train, and learn categories. Other non-limiting examples of categories, which categories fall under the grades category include study and health categories. By way of a non-limiting example, a goal in the health category might be one to achieve a certain health-related status, e.g., one such goal might be to lose ten pounds. Other achievement-type categories are train and learn, and the learn category may include categories related to learning music or code. The example categories shown in FIG. 2 include an improve category, which includes categories for improvement, e.g., de-habit or breaking a bad habit or improve characteristics of one's personality, e.g., such as addressing issues with anger, sensitivity, fear, fight, etc.” [0051]
“The example provided in FIG. 4 includes some examples of teams and their members. In the example, teams may be formed from social connections, such as connections formed between friends or connections based on familial relationships, e.g., a team comprised of all of some members of a household, children, a spouse, etc. Teams might also be formed by members of a club, community, organization, etc. Teams might be formed based on a shared affinity for a merchant, or merchants, and/or a brand, or brands.” [0059]
Group recommendation based on goals, user’s compatibility…
“FIG. 5 illustrates some additional components for use in system 100 in accordance with one or more embodiments. As discussed herein, system 100, e.g., recommender 106, may make recommendations for assignments of users to user groups. By way of a non-limiting example, system 100 identify one or more user groups. The user group recommendation(s) may be identified based on possible goals in which the user has interest, a user's compatibility with a group's users/members, a likelihood that the user will have a positive impact on the group and/or that the group will have a positive impact on the user. In accordance with one or more embodiments, the likelihood may comprise a likelihood of success of the user group if the user is a member of the group as compared with the likelihood of success of the user group without the user.” [0062]
“Recommender 106 may use probability model(s) 104 to determine a likelihood/probability of success of a user and or user group in achieving a goal. In accordance with one or more embodiments, a path to achieving a goal may be defined using states, or milestones, each of which has one or more factors/criteria for evaluating progress and/or eligibility to advance/transition to another state/milestone.” [0064]
“One or more groups may be recommended to the user by system 100, and the user may be given an opportunity to select one or more groups of their choice. In accordance with one or more embodiments, a user may select a user group from the one or more user groups recommended by system 100. Once the user is associated with a user group, 608, e.g., a user group selected by the user or assigned by system 100, system 100 may track the user's initial engagement with the user group for a period of time to determine the fitness of the assignment. System 100 may conduct periodic reviews of each user's activity statistics relative to the group's statistics to determine whether or not it may be necessary to re-assign one or more users in the user group. By way of a non-limiting example, one or more re-assignments may be performed where system 100 determines that there is a better assignment for a user, which determination may be based on a determination that there is a greater probability of success for sustained progress for the affected group(s) and/or user(s) from the resulting re-assignment.” [0070]
Probability of success of the group of users and based on outcomes of various user groups…
“At step 708, at least one progression plan for progression is established for each goal. Each progression plan may have one or more associated states or milestones, which may be used to measure progress of a group of user's toward the goal. In accordance with one or more embodiments, the progression plan may be associated with the category associated with the goal. At step 710, users are assigned to form a group of users. The user group is associated with at least one goal. In accordance with one or more embodiments, the users assigned to form the group may be selected based on a probability of success of the group of users in achieving the group's goal, the probability of success may be determined using at least one probability model, e.g., at least one of model(s) 114, which may be trained from previous experience with the plurality of users, the plurality of goals and determined outcomes of various user groups.” [0076]
“In accordance with one or more embodiments and as discussed above with reference to step 808 of FIG. 8, system 100 may continue to monitor a probability of success associated with a user/user group and provide feedback to an advertiser, and an advertiser may have an option to cancel a sponsorship based on the feedback provided to the advertiser. In other words, a sponsorship may be conditioned on criteria, which criteria may include a threshold probability of success, and system 100 may provide feedback, which feedback may include a current probability of success, to an advertiser related to the criteria. System 100 may be configured to automatically cancel a sponsorship based on the criteria and feedback, e.g., a threshold probability of success is not satisfied by a sponsored user and/or user group.” [0093]
It would have been obvious to one of ordinary skill in the art before the effective filing date to include in the method and system of Nagasaka the ability to determine probability of success as taught by Bhatia et al. since the claimed invention is merely a combination of old elements and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. Further motivation is provided by Bhatia et al. who teaches the advantages predicting success for a group in order to achieve a group’s goal.
Regarding claim 2
The providing method according to Claim 1, further comprising:
receiving, from the user terminal, a request for displaying a lifestyle habit log of the user;
Nagasaka teaches:
Accepts (receives) instructions (requests) to process information including lifestyle habit log…
“The control unit 130 controls the entire operation of the server terminal 100 by executing the program(s) stored in the storage unit 120 and is composed of a CPU (Central Processing Unit), a GPU (Graphics Processing Unit), and the like. The control unit 130 has, as its functions, an instruction acceptance unit 131 which accepts instructions from the user terminals 200 and the like, a user data management unit 132 which refers to and processes the various kinds of data regarding the users, a team data management unit 133 which refers to and processes the various kinds of data regarding the team, and a lifestyle habit log generation unit 134 which generates lifestyle habit logs on the basis of lifestyle habit information accepted from the users. These instruction acceptance unit 131, user data management unit 132, team data management unit 133, and lifestyle habit log generation unit 134 are initiated by the program(s) stored in the storage unit 120 and performed by the server terminal 100 as a computer (electronic calculator).” [0037]
generating the lifestyle habit log on the basis of the lifestyle habit information stored in a user data storage of the storage unit; and
Generates lifestyle habit log…
“The control unit 130 controls the entire operation of the server terminal 100 by executing the program(s) stored in the storage unit 120 and is composed of a CPU (Central Processing Unit), a GPU (Graphics Processing Unit), and the like. The control unit 130 has, as its functions, an instruction acceptance unit 131 which accepts instructions from the user terminals 200 and the like, a user data management unit 132 which refers to and processes the various kinds of data regarding the users, a team data management unit 133 which refers to and processes the various kinds of data regarding the team, and a lifestyle habit log generation unit 134 which generates lifestyle habit logs on the basis of lifestyle habit information accepted from the users. These instruction acceptance unit 131, user data management unit 132, team data management unit 133, and lifestyle habit log generation unit 134 are initiated by the program(s) stored in the storage unit 120 and performed by the server terminal 100 as a computer (electronic calculator).” [0037]
causing the user terminal to display the lifestyle habit log.
Display them (lifestyle habit log)…
“The lifestyle habit log generation unit 134 generates, in response to requests from the users or regardless of such requests, lifestyle habit logs on the basis of the lifestyle habit information stored in the user data storage 121 and transmitted by the users, and performs processing to display them on the user terminals 200.” [0041]
Regarding claim 3
The providing method according to Claim 1, wherein the lifestyle habit information further includes any item of information of the number of steps, a meal, consumed calories and sleep of the user.
Nagasaka teaches:
Information such as number of steps, meals, consumed calories, sleeping time…
“User data 1000 shown in FIG. 4 stores the various kinds of data regarding the users. While FIG. 4 shows an example of one user (user identified by a user ID “10001”) for convenience of description, information of a plurality of users can be stored. The various kinds of data regarding each user can include the basic information of the user (a user password, the name, the age, the sexuality, SNS information, and the membership status (a fee-free membership user or a premium membership user) of the user, and status information (for example, a “badge”) given based on posts of text and images associated with missions in the team that it belongs to), the information of the team that it belongs to (a team ID, a team name, and the like), and the lifestyle habit information (the number of steps (steps), a body weight (kg), meals (kcal), consumed calories (kcal), a sleeping time (hours; minutes), image data, text data, various kinds of data associated with dates in a calendar, and the like), for example.” [0049]
Regarding claim 4
The providing method according to Claim 1, further comprising:
generating a lifestyle habit log of the user for every predetermined period.
Nagasaka teaches:
“Note that the user can share the lifestyle habit information as the lifestyle habit log, associating it with the date and/or the period, with other users via the chat communication interface, and the lifestyle habit logs of the users can be compared and displayed. Thereby, the predetermined missions for achieving the goal can be continued with reference to the lifestyle habit logs among the users.” [0069]
Predetermined period with log…
“The providing method according to claim 1, comprising generating a lifestyle habit log for every predetermined period.” (Claim 4)
Regarding claim 5
The providing method according to Claim 1, wherein a team is generated by an individual user or a corporate user, and is at least associated with one category of a plurality of categories, and the category is able to be generated by the corporate user.
Nagasaka teaches:
User or corporate user generate a team…
“Here, each team is associated with major categories such as “Recommended”, “Diet”, and “Fitness”, and, for example, for the major category “Fitness”, minor categories such as “Muscular Workout”, “Walking”, and “Walking Relay”. Moreover, a team can be generated by an individual user as a customer of the service, or a corporate user such as a service enterprise or a partner, and the corporate user, in particular, that is a partner can generate major categories relevant to the generated team (such, for example, as a “University Entrance Examination” category shown in FIG. 8B) or minor categories (such, for example, as an “ABC App Official” category generated in the “Diet” category) in order to advertise/promote the sale of merchandises and services provided by that corporate. Thereby, the users can take a shortcut to access the team generated by the corporate user.” [0056]
Regarding claim 8
The providing method according to Claim 1, further comprising providing, to the user on the interface for chat communication, encouragement using a chat bot.
Nagasaka teaches:
Chat bot and encourage a user…
“Furthermore, in the server terminal 100 or another terminal, the lifestyle habit log(s) of one or a plurality of users can be analyzed to provide advice and to provide guidance for achieving the goal. For example, via the chat communication interface of the team, a chat bot, as an instructor, can encourage a user slowing down its actions and/or can advise a user falling behind with comparison of the lifestyle habit logs of a plurality of users.” [0070]
Regarding claim 10
The providing method according to Claim 1, wherein performing image processing comprises applying optical character recognition (OCR) processing to the received image data to extract the text data.
Nagasaka teaches:
Extract text data from image using OCR processing…
“…The body weight value (kg) can also be extracted from the captured image as text data through OCR processing or the like and be automatically input. Moreover, input items (such, for example, as “today's body weight”) can also be displayed according to the goal shared in the team (for example, “recording the body weight every evening”). When accepting the lifestyle habit information from the user, the server terminal 100 displays the accepted information (for example, the body weight value (kg) input along with the image of the body weight meter (together with the message)), in the chat communication interface. Each user of the team views images and text posted by another user to confirm that this user has cleared a predetermined mission (for example, to measure the body weight every evening) with respect to the goal, and takes some action (for example, to make a stamp of a cat footprint) in order to prove the confirmation. According to these actions, the degree of achievement for the goal set by the team (or the goal of the day to be cleared for the goal) can be updated and visually displayed. Moreover, as shown in FIG. 8B, one user which the team is composed of can also visually display the degree of achievement for itself as an individual using a predetermined image (acquired from the server terminal 100 or an external resource).” [0058]
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over the combined references in section (9) above in further view of Pub. No. US 2013/0226612 to Carmeli et al.
Regarding claim 6
The providing method according to Claim 1, wherein determining the plurality of recommended teams is performed using a machine learning (ML) model.
The combined references teach recommend teams. They do not teach machine learning.
Carmeli et al. also in the business of recommend teams teaches:
Machine learning suggest (recommend) patient groups…
“As shown at 104, the patient records are now divided to a plurality of patient groups each includes patient records of patients having common and/or similar patient dependent clinical characteristics at the medical decision point. Optionally, machine learning techniques are used to suggest refined patient-similarity metrics, yielding fine-grained similar patient groups. Optionally, machine learning techniques are used to suggest patient groups other then those recommended by the model, based on retrospective analysis of physician decision and achieved outcome, yielding in knowledge and/or guideline refinements.” [0049]
It would have been obvious to one of ordinary skill in the art before the effective filing date to include in the method and system of the combined references the ability to use machine learning as taught by Carmei et al. since the claimed invention is merely a combination of old elements and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. Further motivation is provided by Carmeli et al. who teaches the benefits of using machine learning for determining recommend teams.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over the combined references in section (10) above in further view of Pub. No. US 2020/0380883 to Jain et al. and in further view of Pub. No. US 2022/0189636 to Wagner et al.
Regarding claim 7
The providing method according to Claim 6, wherein the machine learning model is selected from among a plurality of ML models respectively trained for groups of users having similar characteristics and goals, wherein the selection selects an ML model for a group among the groups of users that the user may be categorized as belonging to.
The combined references teach recommend teams. They do not teach machine learning.
Carmeli et al. also in the business of recommend teams teaches:
Machine learning suggest (recommend) patient groups…
“As shown at 104, the patient records are now divided to a plurality of patient groups each includes patient records of patients having common and/or similar patient dependent clinical characteristics at the medical decision point. Optionally, machine learning techniques are used to suggest refined patient-similarity metrics, yielding fine-grained similar patient groups. Optionally, machine learning techniques are used to suggest patient groups other then those recommended by the model, based on retrospective analysis of physician decision and achieved outcome, yielding in knowledge and/or guideline refinements.” [0049]
It would have been obvious to one of ordinary skill in the art before the effective filing date to include in the method and system of the combined references the ability to use machine learning as taught by Carmei et al. since the claimed invention is merely a combination of old elements and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. Further motivation is provided by Carmeli et al. who teaches the benefits of using machine learning for determining recommend teams.
Plurality of Models
The combined references teach machine learning. They do not teach plurality of models.
Jain et al. also in the business of machine learning teaches:
Groups of individuals…
“Embodiments consistent with the present disclosure may include a group of individuals. Groups may include any type of group of people, such as a family, a team, employees, co-workers, members of an organization, a group of friends, a class, parents, a community group, a neighborhood group, a group of groups, a society, or the like. Groups may be of any size. A group may include individuals related based on genealogy, likes/dislikes, subscription relevance, education, residence location, individuals linked by a study or a sub-study within a cohort, and/or any other relationship.” [0025]
Trained machine learning model…
“Embodiments consistent with the present disclosure may include a measurement goal. A measurement goal may be based on a measurement type. In some embodiments, a measurement goal may relate to a behavior or a health status. A measurement goal may include an internet use goal, a diet goal, a consumption goal, a sleep goal, an exercise goal, a medical treatment goal, or an activity goal. A measurement goal may include a threshold (i.e., a minimum or a maximum) of an indicator of a behavior or a health status. Examples of measurement goals may include a minimum number of hours spent studying during a week, a maximum anxiety score, a resting heart rate threshold, a maximum screen time, a minimum number of social interactions, a vegetables-consumed threshold, a medication adherence minimum, and/or any other threshold of an indicator of a behavior or a health status. In some embodiments, a measurement goal may include a coding function for processing data (e.g., sensor data). A coding function may include check statements, when statements, while statements, do statements, Boolean logical statements, or the like. In some embodiments, setting a measurement goal may include a machine learning model trained to predict an indicator of a behavior or a health status. In some embodiments, a measurement goal may include a fuzzy logic model, which may or may not be a machine learning model.” [0028]
Classification (categorization) of users and may include models (plural)…
“Applied rules and configurations 604 may include feature classification data. Feature classification data may be associated with a measurement goal or a marker. For example, feature classification data may include rules (e.g., models, logical expressions) to determine whether a condition is met. Feature classification data may include processed data indicating whether a condition is met. In some embodiments, the condition may include whether: a user is actively checking a phone; a user is actively visiting (using) an app; a user is rapidly changing apps; a user is using a fidget spinner; a user's biomarkers are changing; an environment has a sudden change; a user is pacing; a battery is rapidly depleting; a phone is intensely used; a user is avoiding social interactions; a social proximity is increasing; a user is watching television; a user has not moved; a user's typing accuracy has decreased; a user is shaking; a user is sleeping; a user is commuting; a user is sleeping well; a user's sleep is interrupted; a user is eating; a user is engaged in conversation; a user is actively moving; weather is altering a mood; or any other condition is satisfied.” [0122]
Retrieve (select) a trained machine learning model where there may be a plurality of models…
“In some embodiments, setting a measurement goal may include generating or retrieving a machine learning model trained to predict an indicator of behavior or health status. A machine learning model may include a neural network model, a recurrent neural network model, a random forest model, a support vector model, and/or any other machine learning model both unsupervised and supervised. In some embodiments, setting a measurement goal may include generating or retrieving a fuzzy logic model. A fuzzy logic model may be configured to estimate general truths. For example, a fuzzy logic model may be configured to determine that an indicator mostly satisfies a measurement goal, that an indicator is close to a threshold, and/or that an indicator is nearing a threshold.” [0140]
It would have been obvious to one of ordinary skill in the art before the effective filing date to include in the method and system of the combined references the ability to use a plurality of machine learning models as taught by Jain et al. since the claimed invention is merely a combination of old elements and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. Further motivation is provided by Jain et al. who teaches the benefits of using a plurality of machine learning models for users with similar characteristics.
Select Model
The combined references teach models. They do not specifically teach select.
Wagner et al. also in the business of models teaches:
Neural network models (plural) trained and select the highest performing one…
“In some embodiments, plurality of neural network models may be trained at process 320. For example, a different neural network model may be trained for each cohort identified at process 310. In this regard, the trained neural network models may perform more accurately compared to a neural network model in which the training data is undifferentiated or otherwise does not account for the differences among cohorts. In some embodiments, different models may be trained using diagnostic time series data (e.g., time series data captured near the time of diagnosis) versus pre-emptive time series data (e.g., time series data captured significantly before the diagnosis). Moreover, neural network models with different architectures, training procedures, and the like may be trained at process 320. The performance of the plurality of trained models may be compared to select one or more highest performing (e.g., most accurate) models to deploy at process 330. Tables 2 and 3 below illustrates a comparison of the accuracy of preliminary diagnostic and pre-emptive models, respectively, for different cohorts. The values in the “Patient Wise AUC” and “Age Gender Wise AUC” columns correspond to an “area under curve” (AUC) metric, where a higher value indicates better diagnostic precision and recall.” [0045]
It would have been obvious to one of ordinary skill in the art before the effective filing date to include in the method and system of the combined references the ability to select a model as taught by Wagner et al. since the claimed invention is merely a combination of old elements and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. Further motivation is provided by Wagner et al. who teaches the benefits of using a machine learning model that is most accurate.
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over the combined references in section (9) above in further view of Pub. No. US 2019/0198150 to Kang et al.
Regarding claim 9
The providing method according to Claim 8, wherein providing encouragement to the user includes determining, from prior interactions with the user, patterns of encouragement and praise that are most effective in getting the user to perform a next action, and generating the encouragement based on that determination.
Nagasaka teaches:
Chat bot and encourage a user…
“Furthermore, in the server terminal 100 or another terminal, the lifestyle habit log(s) of one or a plurality of users can be analyzed to provide advice and to provide guidance for achieving the goal. For example, via the chat communication interface of the team, a chat bot, as an instructor, can encourage a user slowing down its actions and/or can advise a user falling behind with comparison of the lifestyle habit logs of a plurality of users.” [0070]
The combined references teach chat bot. They do not teach encouragement.
Kang et al. also in the business of chat bot teaches:
Leveraging historical patient data for automated communications…
“Therefore, by leveraging historical patient and patient outcome data to customize automated and manual communications with a current patient based on the patient's actual physical and/or emotional status over time, the system can achieve higher patient satisfaction throughout her recovery and upon completion of her recovery while also efficiently allocating human resources (i.e., doctor and/or physical therapist time and energy) to patients most in need of human intervention.” [0013]
Chat bot and motivational quotes (encouragement)…
“For example, the chat bot can receive patient information for a particular patient indicating the particular patient is from the Midwest, enjoys swimming and cycling, recently tore her right rotator cuff partially, and has commenced a physical therapy regimen to rehabilitate her right rotator cuff so that she may swim the English Channel in eight months. Thus, the chat bot can intermittently serve: prompts to the particular patient inquiring about the progress of her swimming training while mimicking the particular patient's Midwestern dialect; prompts inquiring how the particular patient's shoulder feels while swimming and cycling; hyperlinks to articles about recent English Channel attempts; suggestions for local cycling routes; suggestions for physical therapy exercises helpful for preventing common injuries for swimmers and cyclists; motivational quotes; etc.” [0021]
It would have been obvious to one of ordinary skill in the art before the effective filing date to include in the method and system of the combined references the ability to use chat bot for encouragement as taught by Kang et al. since the claimed invention is merely a combination of old elements and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. Further motivation is provided by Kang et al. who teaches the benefits of using a chat bot for motivation and the combined references benefit as they are directed to users and teams reaching a goal.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KENNETH BARTLEY whose telephone number is (571)272-5230. The examiner can normally be reached Mon-Fri: 7:30 - 4:00 EST.
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, SHAHID MERCHANT can be reached at (571) 270-1360. 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.
/KENNETH BARTLEY/Primary Examiner, Art Unit 3684
Prosecution Insights