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 .
Status of Application
This action is in reply to the correspondence received through March 31, 2025.
Claims 1-16 are pending.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
Claims 1 and 3-10: This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: the various modules recited in claim 1 and further modified by the dependent claims.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
A review of the specification shows that software modules of computer-executable instructions, which are presumed to be executed by an undisclosed general-purpose computer appear to be the corresponding structures described in the specification for the pre-AIA 35 U.S.C. 112, sixth paragraph limitations. However, as further explained below in the section addressing the 35 U.S.C. § 112 rejections, without providing an explanation of the appropriate programming to accomplish the specific software functions, the specification does not provide an adequate disclosure of the corresponding structure to satisfy the requirements of 35 U.S.C. § 112, second paragraph. For examination purposes, these elements will be interpreted as software modules implemented on a general-purpose computer that perform the functions associated with their respective pre-AIA 35 U.S.C. § 112, sixth paragraph limitations.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 U.S.C. § 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 and 3-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 claims contain 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 inventors, at the time the application was filed, had possession of the claimed invention.
As noted above, a review of the specification shows that software modules of computer-executable instructions, which are presumed to be executed by an undisclosed general-purpose computer appear to be the corresponding structures described in the specification for the 35 U.S.C. § 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph limitations identified above. But the specification fails to disclose hardware (e.g., a general-purpose computer) to implement the software, as well as the algorithms needed to transform a general-purpose computer into a special purpose computer to perform the functions associated with their respective 35 U.S.C. § 112(f) or pre-AIA 35 U.S.C. § 112, sixth paragraph limitations. Accordingly, the specification fails to provide an adequate disclosure of the corresponding structures to satisfy the written description requirements of 35 U.S.C. § 112(a) or pre-AIA 35 U.S.C. 112, first paragraph.
Claims 3-10 are rejected for incorporating the deficiencies of the rejected claims on which they respectively depend.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1 and 3-10 are rejected under 35 U.S.C. § 112(b) or 35 U.S.C. § 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Claims 1 and 3-10 recite limitations that invoke 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function.
As noted above, a review of the specification shows that software modules of computer-executable instructions, which are presumed to be executed by an undisclosed general-purpose computer appear to be the corresponding structures described in the specification for the 35 U.S.C. § 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph limitations identified above. But the specification fails to disclose the algorithms needed to transform the general-purpose computer into a special purpose computer to perform the functions associated with their respective 35 U.S.C. § 112(f) or pre-AIA 35 U.S.C. § 112, sixth paragraph limitations. Accordingly, the specification fails to provide an adequate disclosure of the corresponding structures to satisfy the written description requirements of 35 U.S.C. § 112(a) or pre-AIA 35 U.S.C. 112, first paragraph.
Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph;
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
Claims 3-10 are rejected for incorporating the deficiencies of the rejected claims on which they respectively depend.
Claim Rejections - 35 U.S.C. § 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-16 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to non-statutory subject matter. Claims 1-16 are directed to an abstract idea without significantly more as required by the Alice test as discussed below.
Step 1
Claims 1-16 are directed to a process, machine, manufacture, or composition of matter.
Step 2A
Claims 1-16 are directed to abstract ideas, as explained below.
Prong one of the Step 2A analysis requires identifying the specific limitation(s) in the claim under examination that the examiner believes recites an abstract idea; and determining whether the identified limitation(s) falls within at least one of the groupings of abstract ideas of mathematical concepts, mental processes, and certain methods of organizing human activity.
The claims recite the following limitations. Claim 2 recites (a) receiving user profile data, including demographic information, health metrics, activity levels, and fitness goals; (b) processing real-time inputs, including voice commands, food scans, and wearable device data, using artificial intelligence models trained to analyze non-linear relationships, classify user activities, and extract nutritional information; (c) generating personalized recommendations for meal plans, fitness routines, and health monitoring based on the processed inputs, user profile data, and health metrics; (d) dynamically adjusting meal and fitness plans in response to logged user activities, nutritional intake, glucose levels, and other updated health metrics to align with user-specific goals; (e) enabling social connectivity by facilitating geo-tagged interactions, collaborative challenges, and content sharing, with ad revenue-sharing for user-generated content rated highly by the community; (f) facilitating transactions for health and fitness products using artificial intelligence-driven product suggestions, price comparison algorithms, and secure payment systems; and (g) synchronizing user data securely in real time while maintaining compliance with GDPR, HIPAA, and US data protection standards. Claim 1 recites similar features as claim 2. Claims 3-16 further specify features of the concepts identified in the independent claims or characteristics of the data used thereby.
These limitations describe abstract ideas that correspond to concepts identified as abstract ideas by the courts as mental processes—such as concepts performed in the human mind (including an observation, evaluation, judgment, or opinion)—because the claimed features identified above are concepts performed in the human mind (including an observation, evaluation, judgment, or opinion).
These limitations describe abstract ideas that correspond to concepts identified as abstract ideas by the courts as certain methods of organizing human activity—such as fundamental economic principles or practices (including hedging, insurance, mitigating risk), commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations), managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions)—because the claimed features identified above are commercial or legal interactions including advertising, marketing or sales activities or behaviors, as well as manage personal behavior or relationships or interactions between people including teaching and following rules or instructions.
Thus, the concepts set forth in claims 1-16 recite abstract ideas.
Prong two of the Step 2A requires identifying whether there are any additional elements recited in the claim beyond the judicial exception(s), and evaluating those additional elements to determine whether they integrate the exception into a practical application of the exception. “Integration into a practical application” requires an additional element or a combination of additional elements in the claim to apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that the claim is more than a drafting effort designed to monopolize the exception. Further, “integration into a practical application” uses the considerations laid out by the Supreme Court and the Federal Circuit to evaluate whether the judicial exception is integrated into a practical application, such as considerations discussed in M.P.E.P. § 2106.05(a)-(h).
The claims recite the following additional elements beyond those identified above as being directed to an abstract idea. Claim 1 recite various modules that have been interpreted as being software executing on a general-purpose computer, a cloud-based infrastructure, and wearable devices. Claim 2 recites similar features as claim 1 and further recites an e-commerce platform. Claim 6 recites synchronization with external glucose monitors.
The identified judicial exception(s) are not integrated into a practical application for the following reasons.
First, evaluated individually, the additional elements do not integrate the identified abstract ideas into a practical application.
The additional computer elements identified above—the modules, a cloud-based infrastructure, wearable devices, e-commerce platform, and glucose monitors—are recited at a high level of generality. Inclusion of these elements amounts to mere instructions to implement the identified abstract ideas on a computer. See M.P.E.P. § 2106.05(f). The use of conventional computer elements to transmit data between devices is the insignificant, extra-solution activity of mere data gathering or outputting in conjunction with a law of nature or abstract idea. See M.P.E.P. § 2106.05(g). To the extent that the claims transform data, the mere manipulation of data is not a transformation. See M.P.E.P. § 2106.05(c). Inclusion of computing system in the claims amounts to generally linking the use of the judicial exception to a particular technological environment or field of use. See M.P.E.P. § 2106.05(h). Thus, taken alone, the additional elements do not amount to significantly more than a judicial exception.
Second, evaluating the claim limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. See M.P.E.P. § 2106.05(a). Their collective functions merely provide an implementation of the identified abstract ideas on a computer system in the general field of use of fitness tracking and management. See M.P.E.P. § 2106.05(h).
Thus, claims 1-16 recite mathematical concepts, mental processes, or certain methods of organizing human activity without including additional elements that integrate the exception into a practical application of the exception.
Accordingly, claims 1-16 are directed to abstract ideas.
Step 2B
Claims 1-16 do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements, when considered both individually and as an ordered combination, do not amount to significantly more than the abstract idea.
The analysis above describes how the claims recite the additional elements beyond those identified above as being directed to an abstract idea, as well as why identified judicial exception(s) are not integrated into a practical application. These findings are hereby incorporated into the analysis of the additional elements when considered both individually and in combination. Additional features of these analyses are discussed below.
Evaluated individually, the additional elements do not amount to significantly more than a judicial exception. In addition to the factors discussed regarding Step 2A, prong two, these additional computer elements also provide conventional computer functions that do not add meaningful limits to practicing the abstract idea. Generic computer components recited as performing generic computer functions that are well-understood, routine and conventional activities amount to no more than implementing the abstract idea with a computerized system. The use of generic computer components to transmit data between devices is the well-understood, routine, and conventional computer functions of receiving or transmitting data over a network, e.g., the Internet, and does not impose any meaningful limit on the computer implementation of the identified abstract ideas. See M.P.E.P. § 2106.05(d)(II). Thus, taken alone, the additional elements do not amount to significantly more than a judicial exception.
Evaluating the claim limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually. In addition to the factors discussed regarding Step 2A, prong two, there is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely amount to mere instructions to implement the identified abstract ideas on a computer.
Thus, claims 1-16, taken individually and as an ordered combination of elements, are not directed to eligible subject matter since they are directed to an abstract idea without significantly more.
Claim Rejections - 35 U.S.C. § 103
The following is a quotation of 35 U.S.C. § 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. § 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-16 are rejected under AIA 35 U.S.C. § 103 as being unpatentable over Lyke et al. (U.S. Pub. No. 2021/0201691 A1) in view of Hadad et al. (U.S. Pub. No. 2019/0290172 A1), Asikainen et al. (U.S. Pub. No. 2022/0296966 A1), Cha et al. (U.S. Pub. No. 2009/0144133 A1), Akdogan et al. (U.S. Pub. No. 2020/0339339 A1), and Shelton (U.S. Pub. No. 2021/0210160 A1).
Claims 1 and 2: Lyke, as shown, discloses the following limitations:
(a) a cloud-based infrastructure configured to securely store, process, and retrieve user data, including health metrics, fitness logs, and user-generated content (see at least ¶ [0071]: workout, sleep, and/or meal tracking data can be directly retrieved from the devices, and/or indirectly obtained e.g., access via 3rd party application programming interfaces (APIs). For instance, a sleep tracking device, smart watch, and/or smart shoe can provide data to a smart phone via health tracking APIs; the data may be made locally available to any appropriately permissioned health tracking application of the smart phone. Similarly, a meal tracking blog may provide external web portal interfaces to enable recipe query and nutrition information retrieval; see also at least ¶ [0144]: the user may input workout data into the client device and receive dynamic feedback via a visual user interface. In one such variant, the user interface may be a natively executed application running on a user's device (e.g., smart phone, watch, laptop, etc.). Other common embodiments may use a web browser, or other intermediary web portal located at home or at a gym; see also at least ¶ [0137]: a smart phone may enable a user to log meals and/or schedule their day-to-day activities. A smart watch may allow a user to capture movement, monitor heart rate, and/or track sleep; see also at least ¶¶ [0153], [0167], and [0184]);
(b) artificial intelligence models, including artificial neural networks, decision tree algorithms, and […] neural networks, trained on datasets comprising food items, nutritional values, fitness routines, user behavior, health metrics, […] to generate personalized recommendations and analyze meal inputs (see at least ¶ [0107]: common examples of machine learning models include e.g., artificial neural networks, decision trees, support vector machines, Bayesian networks, genetic algorithms, and hybrids thereof. Common techniques for training include supervised learning, unsupervised learning, reinforcement learning, feature learning, sparse dictionary learning, anomaly detection, multi-variate association, etc.; see at least ¶ [0112]: various embodiments analyze workout and/or readiness/recovery data to extract relevant patterns in physiological and/or psychological data. Common examples of workout data may include, without limitation: fitness goal definition, progression of performance, muscle group, duration of exertion, intensity of exertion, absolute load, relative load, range of movement, repetition, recovery time, psychological parameters (e.g., behaviors, motivations, etc.), height, weight, age, sex, ethnicity, and/or any number of other user specific workout parameters. Common examples of readiness and/or recovery data may include, without limitation: date/time of sleep/consumption, suggested sleep time/consumable items, actual sleep time/consumption, contiguity of sleep, irregularity of sleep, quality of sleep, portion size, time interval over which a consumable was consumed, nutrient-related information, and/or any number of other subjective user data; see at least ¶ [0074]: the holistic program enables dynamic modifications to workouts based on current user readiness metrics; see also at least ¶ [0053]);
(c) a voice recognition module configured to interpret predefined phrases and user input for […], tracking workouts, recording health metrics, and executing hands-free commands (see at least ¶ [0062]: while the illustrated embodiment uses visual feedback, other implementations may provide e.g., audible (voice, music, etc.) and/or haptic (vibration, etc.) feedback. Voice instruction, feedback, and/or commands may be useful where the user cannot directly touch the fitness tracking device. For example, during a push-up, the user’s device may instruct the user to start a push-up with an audible “Down”; the user may respond with an audible “Up” to indicate the completion of a repetition. The user device may additionally provide feedback e.g., “That was too fast; for the next rep, slow down”, etc.; see also at least ¶ [0145]);
(e) an integration module configured to synchronize real-time data from wearable devices, including heart rate, activity levels, sleep patterns, and blood glucose monitors, to provide continuous health monitoring (see at least ¶ [0178]: certain ones of the user devices 550 may include wearable health-related parameter measurement and computing devices, such as e.g., a smart watch, an activity tracker, a heart rate monitor, a sleep tracking device, a smart scale, and/or smart eyeglasses. In addition, an exemplary user device 550 may include a smartphone having one or more of the foregoing capabilities and/or which enables user entry of the foregoing workout data. Alternatively, the user device 550 may be in communication with a health and/or activity monitoring device; see also at least ¶ [0179]: other examples of health parameter data may include data that the particular device 550 is configured to collect (such as athletic activity, biometric information, and environmental data). For example, an activity tracking device may be configured to collect activity data such as steps taken, distance traveled, rate or pace of a run, and/or flights of stairs climbed, etc.; a heart rate monitor may be configured to collect heartbeat data; a sleep tracking device collects data relating to how much time a user/wearer spends sleeping; a nutrition tracking device collects data relating to food and drinks consumed by a user; a smart scale collects data relating to a body weight, body fat percentage, and/or body mass index (BMI), etc. Furthermore, a smartwatch and/or smartphone, may be utilized as an activity tracking device, a heart rate monitor, a sleep tracking device, and/or a nutrition tracking device. The user device 550 may comprise any of the foregoing types of devices and/or may receive collected data from a first device at one or more applications running on the user device 550; see also at least ¶ [0176]: the specific data that are collected may include e.g., repetition count, set count, duration, as well as physiological information such as e.g., heart rate, blood oxygenation, carbon dioxide production, lactate production, blood occlusion, nervous system activation, sweat, blood sugar, etc.);
(f) a dynamic adjustment module configured to modify meal and workout plans in response to real-time user inputs, nutritional intake, and fitness goals, including adaptations for glycemic control (see at least ¶ [0064]: the user device adjusts the workout in accordance with the heuristics associated with the identified expected profile (revised interface 230 of FIG. 2C); see also at least ¶ [0077]: the holistic program also enables dynamic recovery coaching after workouts based on actual workout performance. For example, as shown in the exemplary personalized fitness program user interface 260 of FIG. 2F, at time 262, the user has skipped lunch and completed a modified workout. Unfortunately, the user has dropped into a caloric deficiency danger zone (as illustrated by the of caloric consumption over time 265). Caloric consumption may be estimated based on the actual workout metrics; more sophisticated variants may incorporate e.g., the user’s physiology and metabolism; see at least ¶ [0073]: the fitness program is seamlessly incorporated within the user's daily schedule for day-to-day activities. For example, the user's calendaring program may include a variety of personal and/or professional appointments as well as reminders or links for health and fitness activities (e.g., suggested meals/snacks, rest reminders, suggested workouts, etc.); see also at least ¶ [0133]: a client device may receive a fitness program that prescribes e.g., times for resting, meals for consumption, workouts and/or rules for adjusting the program if the user is underperforming due to lack of rest and/or nutrition; see also at least ¶¶ [0076]-[0079], [0098], [0157], and [0175]-[0179]);
(g) a user interface accessible via web and mobile platforms for displaying recommendations, tracking progress, visualizing trends, and enabling interactive user engagement (see at least ¶ [0157]: a user may be able to locally access their user workout data records. In some cases, the user's immediate access to previous user workout data records may be useful to e.g., track progress, plan for future workouts, and/or used for other motivational purposes. In some cases, the user workout data records can be made accessible via e.g., external application programming interfaces (APIs) to a variety of other tools; see also at least ¶ [0059]: FIG. 2A illustrates one exemplary personalized workout recommendation and dynamic feedback user interface 200 based on workout history, readiness/recovery information, and/or personal fitness goals; see also at least ¶ [0191]: the interface provides informative references for the exercise, and visual indication on routine progress. During the workout, the user is prompted to provide Rate of Perceived Effort (RPE) feedback along the way. RPE can be used to provide dynamic feedback as well as improve future workout recommendations; see also at least ¶ [0144]: the user interface may be a natively executed application running on a user's device (e.g., smart phone, watch, laptop, etc.). Other common embodiments may use a web browser, or other intermediary web portal located at home or at a gym);
(j) a security module configured to encrypt user data (see at least ¶ [0114]: the user may be able to protect workout related information (e.g., time, location, duration, frequency of workout, etc.) As but one example of anonymization, identifying information may be unidirectionally hashed, scrambled, encrypted, and/or otherwise obscured), ensure token-based authentication (see at least ¶ [0116]: the user may be required to verify their authenticity in order to e.g., create user accounts and/or generate workout data. For instance, the user may be required to provide proof of existence (via e.g., an external email account, phone number, or other personal verification method). Additionally, in some cases, a user account may be validated to ensure that the user profile information is reasonable. For example, age, height and/or weight inputs may be verified to lie within the realm of possibility. In some cases, external verification of personhood may require certification (trust credentials) or other root of trust (e.g., trusted 3rd party verification, etc.) Still other techniques for managing user database integrity may be substituted with equal success by artisans of ordinary skill in the related arts), […].
Lyke does not explicitly disclose, but Hadad, as shown, teaches the following limitations:
(b) artificial intelligence models, including […] convolutional neural networks, trained on datasets comprising […] food images to generate personalized recommendations and analyze meal inputs (see at least ¶ [0141]: to achieve the above goals, the food image recognition engine can include an algorithm comprising the following. First, a complete ontology of visual cues for foods (VICUF) is constructed. This is an ontology of any visual cue that human beings (or computers) may use to identify the food that is before them, and may include: (1) Combo food items (e.g. Greek salad, or a burrito); (2) Ingredients (e.g. banana, apple, shrimps); and (3) Other cues (e.g. cup, liquid, fried, etc.). Knowing the entire ontology of VICUF can be used in conjunction with other inputs to obtain a more accurate identification of restaurant dishes. Next, a robust corpus for each label in VICUF is created. Ideally each label in the training set is to be annotated. Next, a convolutional neural network (CNN) is trained on each label in the VICUF (binary classifier), or a CNN capable of multi-labeling is trained. The latter CNN may provide better results since certain foods often appear together, while other foods do not. Next, each time a new image is supplied, the CNN will map it to a probability vector, where each component represents the probability that a specific food-related visual cue is in the image. The above steps may be sufficient to create a food logging experience. Given an image, the food image recognition engine can sort items in the food logger depending on their probability value in the output vector. A threshold can be included such that items with low probability do not appear; see also at least ¶ [0227]: the device/data hub 220 can be a seamless food image logger. By using the GUI-based software interface that can be installed in a user device, the device/data hub 220 can gain unlimited access to a camera roll of the user device. Every time an image is taken by the user device, a convolutional network of the device/data hub 220 can analyze the image to decide whether or not the image contains at least one food or beverage);
(c) a voice recognition module configured to interpret predefined phrases and user input for logging meals (see at least ¶ [0228]: the device/data hub 220 can perform food tracking by textual and voice recognition analysis. By using the GUI-based software interface installed in the user device, the user can record and store at least one free text or at least one voice message about foods (e.g., foods the user has eaten, foods the user plans to eat, foods the user wants to learn more about, etc.) to the device/data hub 220. The device/data hub 220 can utilize a third-party service (e.g., Speech2Text) to automatically convert at least one voice message into a respective free text. The stored data of at least one free text or at least one voice message can be used for analyses by the food analysis system 210 and the insights and recommendation engine 230. In an example, if the user types a free text, “1 slice of bread with two eggs and a cup of coffee,” to the GUI-based software interface, the device/data hub 220 can save data of the free text to the database(s) 240 and instruct the food analysis system 210 for analysis of the data. The food analysis system 210 can abstract and classify nutritional information (e.g., carbohydrate or nutrient intake) of foods mentioned in the free text, and map the foods into the food ontology. Subsequently, the device-data hub 220, in communication with the food analysis system 210, can inform the user results of the analysis. The textual and voice recognition function of the device/data hub 220 can facilitate a tedious and incessant process of food tracking required for the food analysis system 210. Exemplary windows of the GUI-based software interface for the voice recognition analysis function are illustrated in FIGS. 18A-18C. The GUI-based software interface window can display example sentence structures that users may use to record a voice message to the device/data hub 220, as shown in FIG. 18A. After automatically converting the voice message into a free text, the GUI-based software interface window can display the free text to the user, as shown in FIG. 18B. After immediately analyzing food-related information from the free text, the GUI-based software interface window can display the results of the analysis (e.g. a food item and predicted calories and serving size), and also ask the user to validate or edit the result for accuracy prior to saving the result in the database(s) 240, as shown in FIG. 18C; see also at least ¶ [0348]);
(d) a computer vision module configured to analyze food labels and meal images to extract nutritional data, estimate portion sizes, and calculate caloric and nutrient values (see at least ¶ [0121]: nutritional information extraction as described herein may comprise extracting the nutritional facts, ingredients or allergens of a consumer product using an image of the product. This can be implemented by first dividing the image into multiple sub-images containing areas with text, using for example an image crop algorithm. The image crop algorithm may comprise a method for extracting parts of an image containing text. The method implemented by the image crop algorithm may comprise the following steps: (1) search and extract rectangles in the image; (2) calculate the standard deviation image and pull areas with large standard deviation; (3) remove overlapping areas and calculate the difference between standard deviation areas overlapping with rectangle areas; and (4) return a list of the areas pulled from the images. FIG. 42 shows an example of standard deviation image areas, and FIG. 43 shows an example of rectangle detection image areas. Referring to FIG. 42, the standard deviation image areas may include a plurality of free-form contours 4202 around the text and empty spaces 4204 therebetween. Referring to FIG. 43, the rectangle detection image areas include a plurality of rectangle boxes 4302 surrounding the text. Accordingly, areas (sub-images) of various shapes and sizes can be cropped from the original image; see also at least ¶¶ [0122]-[0132] and FIG. 45);
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine the techniques for image and voice recognition taught by Hadad with the health and nutrition tracking systems disclosed by Lyke, because Hadad teaches at ¶ [0275] that “provide users a better understanding of their bodies and/or a healthier diet.” See M.P.E.P. § 2143(I)(G).
Moreover, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine the techniques for image and voice recognition taught by Hadad with the health and nutrition tracking systems disclosed by Lyke, because the claimed invention is merely a combination of old elements (the techniques for image and voice recognition taught by Hadad and the health and nutrition tracking systems disclosed by Lyke), 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. See M.P.E.P. § 2143(I)(A).
Lyke does not explicitly disclose, but Asikainen, as shown, teaches the following limitations:
(h) a social networking module configured to facilitate geo-tagged interactions, collaborative fitness challenges, content sharing, […] user-generated content (see at least ¶ [0112]: the gamification engine 212 generates a recommendation for the user to join an online community of other users of interactive personal training device 108 or friends to stay accountable in adhering to their workout program. For example, when the user consistently adheres to a workout program exercising with the interactive personal training device 108 for a week, the gamification engine 212 shares this success streak of the user with the online community or friends of the user. The gamification engine 212 facilitates the sharing of workout related information, such as a video, avatar, score, statistics, rewards, progress, level-ups, achievement badges, etc. via a social media application for receiving social reinforcement in the form of indications of acknowledgment (e.g., likes, comments, shares, etc.), feedback, support, and recommendations from a social circle that help with motivating the user. For example, the user may record and share a short-form video of an exercise repetition or an exercise movement that they consider to be their personal record to their social circle via the interactive personal training device 108; see also at least ¶ [0128]: FIG. 14 shows an example graphical representation illustrating a user interface 1400 for displaying a leaderboard and user rankings on the interactive personal training device 108. The user interface 1400 shows a leaderboard and a user is able to select their preferred ranking category. The leaderboard may include a plurality of metrics, such as overall fitness, overall strength, overall endurance, most workouts, oldest members, most challenges won, similar performance (to the user), looking for a challenge, champions, most classes, age groups, sex, public challenges, my challenges, etc.; see also at least ¶ [0040]: this enables the interactive personal training device 108 to accurately detect and track acceleration, weight volume, equipment in use, equipment trajectory, and spatial location in three-dimensional space; see also at least ¶ [0060]: non-limiting examples of the sensor(s) 249 include various optical sensors (CCD, CMOS, 2D, 3D, light detection and ranging (LiDAR), cameras, etc.), audio sensors, motion detection sensors, magnetometer, barometers, altimeters, thermocouples, moisture sensors, infrared (IR) sensors, radar sensors, other photo sensors, gyroscopes, accelerometers, geo-location sensors, orientation sensor, wireless transceivers (e.g., cellular, Wi-Fi™, near-field, etc.), sonar sensors, ultrasonic sensors, touch sensors, proximity sensors, distance sensors, microphones, etc.; see also at least ¶ [0069]: the user profile received from the third-party social network server 140 may include one or more of the user's age, gender, interests, location, and other demographic information);
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine the techniques for providing connected digital fitness experiences taught by Asikainen with the health and nutrition tracking systems disclosed by Lyke, because Asikainen teaches at ¶ [0112] that its gamification aspects “help with motivating the user,” e.g., by encouraging the user to consistently adhere to a workout program exercising with the interactive personal training device. See M.P.E.P. § 2143(I)(G).
Moreover, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine the techniques for providing connected digital fitness experiences taught by Asikainen with the health and nutrition tracking systems disclosed by Lyke, because the claimed invention is merely a combination of old elements (the techniques for providing connected digital fitness experiences taught by Asikainen and the health and nutrition tracking systems disclosed by Lyke), 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. See M.P.E.P. § 2143(I)(A).
Lyke does not explicitly disclose, but Cha, as shown, teaches the following limitations:
ad revenue-sharing for user-generated content (see at least ¶ [0036]: in case of contents (UCC: User Created Contents) manufactured by a general user, the contents' owner may be recommender and/or evaluator at the same time. That is, the user can register contents (UCC) on a UCC service site and at the same time recommend an advertisement for their mapping. Therefore, the present invention can select an advertisement when putting a moving image at a UCC moving image portal and attach it thereto, and distribute a profit created thereby to the contents register; see also at least ¶ [0037]: while the existing context advertisement model is constituted by the advertiser, the contents owner and the consumer, the advertisement model by the AdHelper system of the present invention adds thereto a ‘recommender’ who offers effective mapping of contents and advertisement and an ‘evaluator’ who verifies the appropriateness of such mapping, thereby providing the recommender and the evaluator with a monetary or honorable profit. In addition, the consumer, the evaluator and the recommender are all Internet users and divided not individually but by role. Therefore, they can conduct more than two roles at the same time, which reflect the property of web 2.0 such as prosumer and collective intelligence).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine the monetization techniques taught by Cha with the health and nutrition tracking systems disclosed by Lyke (as modified by Asikainen), because Cha teaches at ¶ [0023] that “the advertisement recommender can also obtain a monetary benefit by the advertisement recommendation and a late context advertisement enterpriser can effectively enter an adverting market without holding a competitive search engine. Moreover, more effective advertisement effect can be created by implementing mapping with high connection of contents and advertisement through cooperation with the existing context advertisement enterpriser.” See M.P.E.P. § 2143(I)(G).
Moreover, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine the monetization techniques taught by Cha with the health and nutrition tracking systems disclosed by Lyke (as modified by Asikainen), because the claimed invention is merely a combination of old elements (the monetization techniques taught by Cha , the techniques for providing connected digital fitness experiences taught by Asikainen, and the health and nutrition tracking systems disclosed by Lyke), 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. See M.P.E.P. § 2143(I)(A).
Lyke does not explicitly disclose, but Akdogan et al. (U.S. Pub. No. 2020/0339339 A1), as shown, teaches the following limitations:
(i) an e-commerce module configured to facilitate transactions for health and fitness-related products, supported by artificial intelligence-driven product recommendations, price comparisons, and secure payment systems (see at least ¶ [0162]: the cloud may provide consumable usage trend identification via an analytics engine, for (1) input to medical professionals and systems (2) warnings/recommendations based on recognized patterns and medical input (3) on demand data/visuals for users (4) modification of pricing and supply chain (e.g. contract and internal manufacturing) of consumable products; see also at least ¶ [0146]: viewing and downloading analytics output, including but not limited to various healthiness metrics, personal goal progress and consumable recommendations based on user data (4) Browsing for pertinent medical information, including but not limited to drug facts, disease symptoms and treatments, physician locations and availabilities, healthcare news on medications and diseases, and site-specific content, in a manner tailored for user given user data (5) Receiving device-agnostic deliveries of this pertinent medical information, triggered by news events (e.g. drug recall, manufacturer warning letters) or user-specific events (e.g. user's family member commenced use of specific drug regimen), and tailored by user data (6) Viewing, downloading and sharing the above pertinent medical information; see also at least ¶ [0167]: Similarly various notification systems, monitoring functions, data storage functions, management and administration functions and the like may be distributed or centralized in various manners across available resources according to user preferences, security requirements, oversight required by health care professionals, data integrity requirements and so forth; see also at least ¶ [0190]: the system may include a financial processing system 3634 for processing various financial transactions associated with use of the base and/or cartridges); and
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine the techniques for providing an e-commerce platform taught by Akdogan with the health and nutrition tracking systems disclosed by Lyke, because Akdogan teaches at ¶ [0229] that its approach “advantageously ensures that all medications are accounted for by centralizing tracking at a single location.” See M.P.E.P. § 2143(I)(G).
Moreover, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine the v with the health and nutrition tracking systems disclosed by Lyke, because the claimed invention is merely a combination of old elements (the techniques for providing an e-commerce platform taught by Akdogan and the health and nutrition tracking systems disclosed by Lyke), 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. See M.P.E.P. § 2143(I)(A).
Lyke does not explicitly disclose, but Shelton, as shown, teaches the following limitations:
(j) a security module configured to […] maintain compliance with GDPR, US data protection standards, and HIPAA (see at least ¶ [0155]: such Other Criteria 549 may also include pre-conditions including selections and level of identity proofing and/or minimum authentication requirement placed on the resource seeker 517; state of consciousness or mental faculty of the subject 533 to whom data 518 applies (e.g., unconscious, incapacitated, unsound mind, etc.); the availability of said subject 533 (or their designated agent) for consultation (e.g., unable to contact by various methods for some period of time); a limit on number of accesses (e.g., one time only, up to three times, etc.); and the like. In addition, pre-conditions may include explicit requirements for securing prior express consent; the obligation to de-identify data 518 in accordance with HIPAA standards, Common Rule standards, or another jurisdictional standard; geographic areas for which a directive is applicable (e.g., facilities located in the state of New York, residents of any European Union member country, etc.); specific circumstances surrounding highly-sensitive conditions (e.g., AIDS, drug/alcohol use, psychiatric context, etc.); and other conditions embraced by the applicable law 507, policy 508, or preference 509; see also at least ¶ [0020]: the data protection law is currently under review to take into account important considerations such as globalization and technological developments like social networks and cloud computing. Presently, it is expected to result in adoption of the General Data Protection Regulation (GDPR) in 2015, with enforcement expected beginning in 2017. While still under discussion, it seems likely that the GDPR will contain a number of aspects that create challenges for traditional biobanking activity and other bioinformatic data acquired with prospective approvals that are not explicit as to the intended purpose, recipients, third-country transfers, and type of data and consequences of processing at the time such consent is sought).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine the privacy preservation techniques taught by Shelton with the health and nutrition tracking systems disclosed by Lyke, because Shelton teaches at ¶ [0033] that its techniques “enhance privacy protections for, and simultaneously to enable broad sharing, analysis and use of, such information.” See M.P.E.P. § 2143(I)(G).
Moreover, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine the privacy preservation techniques taught by Shelton with the health and nutrition tracking systems disclosed by Lyke, because the claimed invention is merely a combination of old elements (the privacy preservation techniques taught by Shelton and the health and nutrition tracking systems disclosed by Lyke), 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. See M.P.E.P. § 2143(I)(A).
Claim 3: The combination of Lyke, Hadad, Asikainen, Cha, Akdogan, and Shelton teaches the limitations as shown in the rejections above. Further, Lyke, as shown, discloses the following limitations:
wherein the artificial neural networks are trained to analyze non-linear relationships between user health metrics, activity patterns, and fitness goals to generate adaptive recommendations (see at least ¶ [0107]: common examples of machine learning models include e.g., artificial neural networks, decision trees, support vector machines, Bayesian networks, genetic algorithms, and hybrids thereof. Common techniques for training include supervised learning, unsupervised learning, reinforcement learning, feature learning, sparse dictionary learning, anomaly detection, multi-variate association, etc.; see at least ¶ [0112]: various embodiments analyze workout and/or readiness/recovery data to extract relevant patterns in physiological and/or psychological data. Common examples of workout data may include, without limitation: fitness goal definition, progression of performance, muscle group, duration of exertion, intensity of exertion, absolute load, relative load, range of movement, repetition, recovery time, psychological parameters (e.g., behaviors, motivations, etc.), height, weight, age, sex, ethnicity, and/or any number of other user specific workout parameters. Common examples of readiness and/or recovery data may include, without limitation: date/time of sleep/consumption, suggested sleep time/consumable items, actual sleep time/consumption, contiguity of sleep, irregularity of sleep, quality of sleep, portion size, time interval over which a consumable was consumed, nutrient-related information, and/or any number of other subjective user data; see at least ¶ [0074]: the holistic program enables dynamic modifications to workouts based on current user readiness metrics; see also at least ¶¶ [0053], [0064], [0073], [0076]-[0079], [0098], [0133], [0157], and [0175]-[0179]).
Claim 4: The combination of Lyke, Hadad, Asikainen, Cha, Akdogan, and Shelton teaches the limitations as shown in the rejections above. Further, Lyke, as shown, discloses the following limitations:
wherein the voice recognition module activates with a predefined phrase and supports hands-free interactions for […], tracking workouts, recording health metrics, and initiating real-time recommendations (see at least ¶ [0062]: while the illustrated embodiment uses visual feedback, other implementations may provide e.g., audible (voice, music, etc.) and/or haptic (vibration, etc.) feedback. Voice instruction, feedback, and/or commands may be useful where the user cannot directly touch the fitness tracking device. For example, during a push-up, the user’s device may instruct the user to start a push-up with an audible “Down”; the user may respond with an audible “Up” to indicate the completion of a repetition. The user device may additionally provide feedback e.g., “That was too fast; for the next rep, slow down”, etc.; see also at least ¶ [0145]).
Lyke does not explicitly disclose, but Hadad, as shown, teaches the following limitations:
wherein the voice recognition module activates with a predefined phrase and supports hands-free interactions for logging meals (see at least ¶ [0228]: the device/data hub 220 can perform food tracking by textual and voice recognition analysis. By using the GUI-based software interface installed in the user device, the user can record and store at least one free text or at least one voice message about foods (e.g., foods the user has eaten, foods the user plans to eat, foods the user wants to learn more about, etc.) to the device/data hub 220. The device/data hub 220 can utilize a third-party service (e.g., Speech2Text) to automatically convert at least one voice message into a respective free text. The stored data of at least one free text or at least one voice message can be used for analyses by the food analysis system 210 and the insights and recommendation engine 230. In an example, if the user types a free text, “1 slice of bread with two eggs and a cup of coffee,” to the GUI-based software interface, the device/data hub 220 can save data of the free text to the database(s) 240 and instruct the food analysis system 210 for analysis of the data. The food analysis system 210 can abstract and classify nutritional information (e.g., carbohydrate or nutrient intake) of foods mentioned in the free text, and map the foods into the food ontology. Subsequently, the device-data hub 220, in communication with the food analysis system 210, can inform the user results of the analysis. The textual and voice recognition function of the device/data hub 220 can facilitate a tedious and incessant process of food tracking required for the food analysis system 210. Exemplary windows of the GUI-based software interface for the voice recognition analysis function are illustrated in FIGS. 18A-18C. The GUI-based software interface window can display example sentence structures that users may use to record a voice message to the device/data hub 220, as shown in FIG. 18A. After automatically converting the voice message into a free text, the GUI-based software interface window can display the free text to the user, as shown in FIG. 18B. After immediately analyzing food-related information from the free text, the GUI-based software interface window can display the results of the analysis (e.g. a food item and predicted calories and serving size), and also ask the user to validate or edit the result for accuracy prior to saving the result in the database(s) 240, as shown in FIG. 18C; see also at least ¶ [0348]);
The rationales to modify/combine the teachings of these references are presented above in claims 1 and 2 and incorporated herein.
Claim 5: The combination of Lyke, Hadad, Asikainen, Cha, Akdogan, and Shelton teaches the limitations as shown in the rejections above.
Lyke does not explicitly disclose, but Hadad, as shown, teaches the following limitations:
wherein the computer vision module employs convolutional neural networks trained on labeled datasets of food items and meal images to identify food components and estimate portion sizes (see at least ¶ [0141]: the food image recognition engine can include an algorithm comprising the following. First, a complete ontology of visual cues for foods (VICUF) is constructed. This is an ontology of any visual cue that human beings (or computers) may use to identify the food that is before them, and may include: (1) Combo food items (e.g. Greek salad, or a burrito); (2) Ingredients (e.g. banana, apple, shrimps); and (3) Other cues (e.g. cup, liquid, fried, etc.). Knowing the entire ontology of VICUF can be used in conjunction with other inputs to obtain a more accurate identification of restaurant dishes. Next, a robust corpus for each label in VICUF is created. Ideally each label in the training set is to be annotated. Next, a convolutional neural network (CNN) is trained on each label in the VICUF (binary classifier), or a CNN capable of multi-labeling is trained. The latter CNN may provide better results since certain foods often appear together, while other foods do not. Next, each time a new image is supplied, the CNN will map it to a probability vector, where each component represents the probability that a specific food-related visual cue is in the image. The above steps may be sufficient to create a food logging experience. Given an image, the food image recognition engine can sort items in the food logger depending on their probability value in the output vector. A threshold can be included such that items with low probability do not appear; see also at least ¶ [0143]: the food analysis system 210 can include a labeling machine. The labeling machine can be a machine learning system to discover categories or abstraction layers (herein also referred to as labels) about foods. The labeling machine can be an automated system for textual analysis of food objects and labeling them. This allows adding another layer of metadata, which the system is using to understand various characteristics of every food. These characteristics (labels) can be used in different ways by the system, for example by a personalized recommendation engine; see also at least ¶¶ [0121]-[0132] and FIG. 45).
The rationales to modify/combine the teachings of these references are presented above in claims 1 and 2 and incorporated herein.
Claim 6: The combination of Lyke, Hadad, Asikainen, Cha, Akdogan, and Shelton teaches the limitations as shown in the rejections above. Further, Lyke, as shown, discloses the following limitations:
wherein the integration module supports synchronization with external glucose monitors to track blood sugar levels and provide dietary adjustments for glycemic control (see at least ¶ [0176]: The user devices 550 may include one or more portable computerized devices that are configured to measure, obtain, monitor, generate, collect, sense, or otherwise receive physiological and/or psychological impact experienced by a user. In an exemplary embodiment, the specific data that are collected may include e.g., repetition count, set count, duration, as well as physiological information such as e.g., heart rate, blood oxygenation, carbon dioxide production, lactate production, blood occlusion, nervous system activation, sweat, blood sugar, etc.; see also at least ¶ [0179]: other examples of health parameter data may include data that the particular device 550 is configured to collect (such as athletic activity, biometric information, and environmental data). For example, an activity tracking device may be configured to collect activity data such as steps taken, distance traveled, rate or pace of a run, and/or flights of stairs climbed, etc.; a heart rate monitor may be configured to collect heartbeat data; a sleep tracking device collects data relating to how much time a user/wearer spends sleeping; a nutrition tracking device collects data relating to food and drinks consumed by a user; a smart scale collects data relating to a body weight, body fat percentage, and/or body mass index (BMI), etc. Furthermore, a smartwatch and/or smartphone, may be utilized as an activity tracking device, a heart rate monitor, a sleep tracking device, and/or a nutrition tracking device. The user device 550 may comprise any of the foregoing types of devices and/or may receive collected data from a first device at one or more applications running on the user device 550; see also at least ¶¶ [0053], [0064], [0073], [0076]-[0079], [0098], [0133], [0157], and [0175]-[0179]).
Claim 7: The combination of Lyke, Hadad, Asikainen, Cha, Akdogan, and Shelton teaches the limitations as shown in the rejections above.
Lyke does not explicitly disclose, but Asikainen, as shown, teaches the following limitations:
wherein the social networking module includes leaderboards for collaborative fitness challenges and gamified elements, such as badges and rewards for maintaining fitness streaks (see at least ¶ [0112]: the gamification engine 212 generates a recommendation for the user to join an online community of other users of interactive personal training device 108 or friends to stay accountable in adhering to their workout program. For example, when the user consistently adheres to a workout program exercising with the interactive personal training device 108 for a week, the gamification engine 212 shares this success streak of the user with the online community or friends of the user. The gamification engine 212 facilitates the sharing of workout related information, such as a video, avatar, score, statistics, rewards, progress, level-ups, achievement badges, etc. via a social media application for receiving social reinforcement in the form of indications of acknowledgment (e.g., likes, comments, shares, etc.), feedback, support, and recommendations from a social circle that help with motivating the user. For example, the user may record and share a short-form video of an exercise repetition or an exercise movement that they consider to be their personal record to their social circle via the interactive personal training device 108; see also at least ¶ [0128]: FIG. 14 shows an example graphical representation illustrating a user interface 1400 for displaying a leaderboard and user rankings on the interactive personal training device 108. The user interface 1400 shows a leaderboard and a user is able to select their preferred ranking category. The leaderboard may include a plurality of metrics, such as overall fitness, overall strength, overall endurance, most workouts, oldest members, most challenges won, similar performance (to the user), looking for a challenge, champions, most classes, age groups, sex, public challenges, my challenges, etc.; see also at least ¶ [0040]: this enables the interactive personal training device 108 to accurately detect and track acceleration, weight volume, equipment in use, equipment trajectory, and spatial location in three-dimensional space; see also at least ¶ [0060]: non-limiting examples of the sensor(s) 249 include various optical sensors (CCD, CMOS, 2D, 3D, light detection and ranging (LiDAR), cameras, etc.), audio sensors, motion detection sensors, magnetometer, barometers, altimeters, thermocouples, moisture sensors, infrared (IR) sensors, radar sensors, other photo sensors, gyroscopes, accelerometers, geo-location sensors, orientation sensor, wireless transceivers (e.g., cellular, Wi-Fi™, near-field, etc.), sonar sensors, ultrasonic sensors, touch sensors, proximity sensors, distance sensors, microphones, etc.; see also at least ¶ [0069]: the user profile received from the third-party social network server 140 may include one or more of the user's age, gender, interests, location, and other demographic information).
The rationales to modify/combine the teachings of these references are presented above in claims 1 and 2 and incorporated herein.
Claim 8: The combination of Lyke, Hadad, Asikainen, Cha, Akdogan, and Shelton teaches the limitations as shown in the rejections above.
Lyke does not explicitly disclose, but Akdogan, as shown, teaches the following limitations:
wherein the e-commerce module provides real-time price comparisons for health-related products using artificial intelligence-driven analysis (see at least ¶ [0162]: the cloud may provide consumable usage trend identification via an analytics engine, for (1) input to medical professionals and systems (2) warnings/recommendations based on recognized patterns and medical input (3) on demand data/visuals for users (4) modification of pricing and supply chain (e.g. contract and internal manufacturing) of consumable products; see also at least ¶ [0146]: viewing and downloading analytics output, including but not limited to various healthiness metrics, personal goal progress and consumable recommendations based on user data (4) Browsing for pertinent medical information, including but not limited to drug facts, disease symptoms and treatments, physician locations and availabilities, healthcare news on medications and diseases, and site-specific content, in a manner tailored for user given user data (5) Receiving device-agnostic deliveries of this pertinent medical information, triggered by news events (e.g. drug recall, manufacturer warning letters) or user-specific events (e.g. user's family member commenced use of specific drug regimen), and tailored by user data (6) Viewing, downloading and sharing the above pertinent medical information; see also at least ¶ [0167]: Similarly various notification systems, monitoring functions, data storage functions, management and administration functions and the like may be distributed or centralized in various manners across available resources according to user preferences, security requirements, oversight required by health care professionals, data integrity requirements and so forth; see also at least ¶ [0190]: the system may include a financial processing system 3634 for processing various financial transactions associated with use of the base and/or cartridges).
The rationales to modify/combine the teachings of these references are presented above in claims 1 and 2 and incorporated herein.
Claim 9: The combination of Lyke, Hadad, Asikainen, Cha, Akdogan, and Shelton teaches the limitations as shown in the rejections above. Further, Lyke, as shown, discloses the following limitations:
wherein the security module implements token-based authentication for secure user access and end-to-end encryption for all data transmissions (see at least ¶ [0114]: the user may be able to protect workout related information (e.g., time, location, duration, frequency of workout, etc.) As but one example of anonymization, identifying information may be unidirectionally hashed, scrambled, encrypted, and/or otherwise obscured, see also at least ¶ [0116]: the user may be required to verify their authenticity in order to e.g., create user accounts and/or generate workout data. For instance, the user may be required to provide proof of existence (via e.g., an external email account, phone number, or other personal verification method). Additionally, in some cases, a user account may be validated to ensure that the user profile information is reasonable. For example, age, height and/or weight inputs may be verified to lie within the realm of possibility. In some cases, external verification of personhood may require certification (trust credentials) or other root of trust (e.g., trusted 3rd party verification, etc.) Still other techniques for managing user database integrity may be substituted with equal success by artisans of ordinary skill in the related arts ).
Claim 10: The combination of Lyke, Hadad, Asikainen, Cha, Akdogan, and Shelton teaches the limitations as shown in the rejections above. Further, Lyke, as shown, discloses the following limitations:
wherein the artificial intelligence models are trained on datasets comprising nutritional profiles, fitness routines, […], user activity logs, and glycemic control data to enhance prediction accuracy (see at least ¶ [0107]: common examples of machine learning models include e.g., artificial neural networks, decision trees, support vector machines, Bayesian networks, genetic algorithms, and hybrids thereof. Common techniques for training include supervised learning, unsupervised learning, reinforcement learning, feature learning, sparse dictionary learning, anomaly detection, multi-variate association, etc.; see at least ¶ [0112]: various embodiments analyze workout and/or readiness/recovery data to extract relevant patterns in physiological and/or psychological data. Common examples of workout data may include, without limitation: fitness goal definition, progression of performance, muscle group, duration of exertion, intensity of exertion, absolute load, relative load, range of movement, repetition, recovery time, psychological parameters (e.g., behaviors, motivations, etc.), height, weight, age, sex, ethnicity, and/or any number of other user specific workout parameters. Common examples of readiness and/or recovery data may include, without limitation: date/time of sleep/consumption, suggested sleep time/consumable items, actual sleep time/consumption, contiguity of sleep, irregularity of sleep, quality of sleep, portion size, time interval over which a consumable was consumed, nutrient-related information, and/or any number of other subjective user data; see at least ¶ [0074]: the holistic program enables dynamic modifications to workouts based on current user readiness metrics; see also at least ¶ [0075]: the user’s actual sleep and/or nutrition data may be used to estimate e.g., muscle recovery, response times, awareness, blood sugar, estimated caloric availability/deficiency, hydration/re-hydration, etc.; see also at least ¶¶ [0053] and [0108]-[0112]).
Lyke does not explicitly disclose, but Hadad, as shown, teaches the following limitations:
wherein the artificial intelligence models are trained on datasets comprising […] food image libraries (see at least ¶ [0141]: the food image recognition engine can include an algorithm comprising the following. First, a complete ontology of visual cues for foods (VICUF) is constructed. This is an ontology of any visual cue that human beings (or computers) may use to identify the food that is before them, and may include: (1) Combo food items (e.g. Greek salad, or a burrito); (2) Ingredients (e.g. banana, apple, shrimps); and (3) Other cues (e.g. cup, liquid, fried, etc.). Knowing the entire ontology of VICUF can be used in conjunction with other inputs to obtain a more accurate identification of restaurant dishes. Next, a robust corpus for each label in VICUF is created. Ideally each label in the training set is to be annotated. Next, a convolutional neural network (CNN) is trained on each label in the VICUF (binary classifier), or a CNN capable of multi-labeling is trained. The latter CNN may provide better results since certain foods often appear together, while other foods do not. Next, each time a new image is supplied, the CNN will map it to a probability vector, where each component represents the probability that a specific food-related visual cue is in the image. The above steps may be sufficient to create a food logging experience. Given an image, the food image recognition engine can sort items in the food logger depending on their probability value in the output vector. A threshold can be included such that items with low probability do not appear; see also at least ¶ [0143]: the food analysis system 210 can include a labeling machine. The labeling machine can be a machine learning system to discover categories or abstraction layers (herein also referred to as labels) about foods. The labeling machine can be an automated system for textual analysis of food objects and labeling them. This allows adding another layer of metadata, which the system is using to understand various characteristics of every food. These characteristics (labels) can be used in different ways by the system, for example by a personalized recommendation engine; see also at least ¶¶ [0121]-[0132] and FIG. 45).
The rationales to modify/combine the teachings of these references are presented above in claims 1 and 2 and incorporated herein.
Claim 11: The combination of Lyke, Hadad, Asikainen, Cha, Akdogan, and Shelton teaches the limitations as shown in the rejections above. Further, Lyke, as shown, discloses the following limitations:
wherein the meal plan recommendations are dynamically adjusted based on a user's remaining caloric target, nutrient balance, and blood glucose levels (see at least ¶ [0064]: the user device adjusts the workout in accordance with the heuristics associated with the identified expected profile (revised interface 230 of FIG. 2C); see also at least ¶ [0077]: the holistic program also enables dynamic recovery coaching after workouts based on actual workout performance. For example, as shown in the exemplary personalized fitness program user interface 260 of FIG. 2F, at time 262, the user has skipped lunch and completed a modified workout. Unfortunately, the user has dropped into a caloric deficiency danger zone (as illustrated by the of caloric consumption over time 265). Caloric consumption may be estimated based on the actual workout metrics; more sophisticated variants may incorporate e.g., the user’s physiology and metabolism; see at least ¶ [0073]: the fitness program is seamlessly incorporated within the user's daily schedule for day-to-day activities. For example, the user's calendaring program may include a variety of personal and/or professional appointments as well as reminders or links for health and fitness activities (e.g., suggested meals/snacks, rest reminders, suggested workouts, etc.); see also at least ¶ [0133]: a client device may receive a fitness program that prescribes e.g., times for resting, meals for consumption, workouts and/or rules for adjusting the program if the user is underperforming due to lack of rest and/or nutrition; see also at least ¶ [0075]: the user’s actual sleep and/or nutrition data may be used to estimate e.g., muscle recovery, response times, awareness, blood sugar, estimated caloric availability/deficiency, hydration/re-hydration, etc.; see also at least ¶ [0078]: the caloric deficiency event triggers an update to dynamic recovery coaching; responsively, the user is notified to consume their afternoon snack earlier. In some cases, the snack itself may be modified to provide e.g., more calories, a specific blend of macronutrients, etc. For example, the suggested refuel snack may be a much more substantial smoothie 266 (rather than a handful of nuts, etc.) When the user consumes the refuel smoothie, the caloric consumption graph is updated (the user exits the caloric deficiency danger zone 267). Alternatively, if the user does not consume a refueling snack (or refuels with a less substantial snack), then the user's recovery may be impacted. In some variants, the severity of impact may be estimated based on the expected profile modeling; see also at least ¶¶ [0076]-[0079], [0098], [0157], and [0175]-[0179]).
Claim 12: The combination of Lyke, Hadad, Asikainen, Cha, Akdogan, and Shelton teaches the limitations as shown in the rejections above.
Lyke does not explicitly disclose, but Hadad, as shown, teaches the following limitations:
wherein food scans are analyzed using computer vision models trained on datasets of food labels, meal images, and nutritional profiles (see at least ¶ [0141]: the food image recognition engine can include an algorithm comprising the following. First, a complete ontology of visual cues for foods (VICUF) is constructed. This is an ontology of any visual cue that human beings (or computers) may use to identify the food that is before them, and may include: (1) Combo food items (e.g. Greek salad, or a burrito); (2) Ingredients (e.g. banana, apple, shrimps); and (3) Other cues (e.g. cup, liquid, fried, etc.). Knowing the entire ontology of VICUF can be used in conjunction with other inputs to obtain a more accurate identification of restaurant dishes. Next, a robust corpus for each label in VICUF is created. Ideally each label in the training set is to be annotated. Next, a convolutional neural network (CNN) is trained on each label in the VICUF (binary classifier), or a CNN capable of multi-labeling is trained. The latter CNN may provide better results since certain foods often appear together, while other foods do not. Next, each time a new image is supplied, the CNN will map it to a probability vector, where each component represents the probability that a specific food-related visual cue is in the image. The above steps may be sufficient to create a food logging experience. Given an image, the food image recognition engine can sort items in the food logger depending on their probability value in the output vector. A threshold can be included such that items with low probability do not appear; see also at least ¶ [0143]: the food analysis system 210 can include a labeling machine. The labeling machine can be a machine learning system to discover categories or abstraction layers (herein also referred to as labels) about foods. The labeling machine can be an automated system for textual analysis of food objects and labeling them. This allows adding another layer of metadata, which the system is using to understand various characteristics of every food. These characteristics (labels) can be used in different ways by the system, for example by a personalized recommendation engine; see also at least ¶¶ [0121]-[0132] and FIG. 45).
The rationales to modify/combine the teachings of these references are presented above in claims 1 and 2 and incorporated herein.
Claim 13: The combination of Lyke, Hadad, Asikainen, Cha, Akdogan, and Shelton teaches the limitations as shown in the rejections above. Further, Lyke, as shown, discloses the following limitations:
wherein fitness routines are adapted using principles of muscle confusion to ensure diverse and progressive workouts that prevent fitness plateaus (see at least ¶ [0084]: The user workout history database 308 stores a plurality of user data records and their corresponding workout data records. Each user data record may include detailed information with regard to e.g., accuracy of data, fitness goal definition, progression of performance, psychological parameters (e.g., behaviors, motivations, etc.), height, weight, age, sex, ethnicity, and/or any number of other user specific parameters. Each workout data record may include detailed information with regard to e.g., date/time of past exercises, scheduled date/time of future exercises, type and/or number of exercises, frequency of exercise, exerted muscle groups, duration of exertion, intensity of exertion, absolute load, relative load, range of movement, repetition, recovery time, fatigue, dynamic feedback/user response, frequency of revision, revision success/failure, and/or any number of other workout specific parameters. More generally, artisans of ordinary skill in the related arts given the contents of the present disclosure, will readily appreciate that virtually any data regarding either the individual users and/or their specific workout history can be stored; see also at least ¶ [0089]: the expected profiles database 314 additionally includes heuristics and/or performance metrics that enable modifications based on readiness. Modification rules may e.g., scale back or adjust acceptable tolerances based on certain conditions. For example, instead of requiring a sleep deprived user to do 4 sets, their workout may be scaled down to 3 sets. Similarly, a user that would normally have a tolerance of plus/minus 5 repetitions may be allowed a range of plus/minus 10 repetitions when they've skipped a meal. Other methods for increasing or decreasing workout intensity may include changing e.g., sets, repetitions, duration, rest intervals; see also at least ¶¶ [0090]-[0092]).
Claim 14: The combination of Lyke, Hadad, Asikainen, Cha, Akdogan, and Shelton teaches the limitations as shown in the rejections above. Further, Lyke, as shown, discloses the following limitations:
wherein user recommendations are displayed via an interactive dashboard showing trends in caloric intake, fitness progress, blood glucose levels, and nutrient balance (see at least ¶ [0157]: a user may be able to locally access their user workout data records. In some cases, the user's immediate access to previous user workout data records may be useful to e.g., track progress, plan for future workouts, and/or used for other motivational purposes. In some cases, the user workout data records can be made accessible via e.g., external application programming interfaces (APIs) to a variety of other tools; see also at least ¶ [0059]: FIG. 2A illustrates one exemplary personalized workout recommendation and dynamic feedback user interface 200 based on workout history, readiness/recovery information, and/or personal fitness goals; see also at least ¶ [0191]: the interface provides informative references for the exercise, and visual indication on routine progress. During the workout, the user is prompted to provide Rate of Perceived Effort (RPE) feedback along the way. RPE can be used to provide dynamic feedback as well as improve future workout recommendations; see also at least ¶ [0192]: FIG. 6F illustrates updates to the aforementioned program view based on the user’s activity. In the illustrated embodiment, the program view has updated the user's daily tasks with information regarding the user's actual behavior. For example, as shown in FIG. 6F, the user's sleep quality is provided (e.g., 7 hr 49 min) along with qualitative measurements that were gathered from the user's sleep tracking devices. Similarly, the user's workout activity is updated to reflect caloric and/or hydration deficits as a function of time; this data can be used for updating (increasing/decreasing if necessary) post-workout refuel snack/meal suggestions; see also at least ¶ [0176]: the user devices 550 are additionally configured to enable a user to log actual workout activity. The user devices 550 may include one or more portable computerized devices that are configured to measure, obtain, monitor, generate, collect, sense, or otherwise receive physiological and/or psychological impact experienced by a user. In an exemplary embodiment, the specific data that are collected may include e.g., repetition count, set count, duration, as well as physiological information such as e.g., heart rate, blood oxygenation, carbon dioxide production, lactate production, blood occlusion, nervous system activation, sweat, blood sugar, etc.; see also at least ¶ [0144]: the user interface may be a natively executed application running on a user's device (e.g., smart phone, watch, laptop, etc.). Other common embodiments may use a web browser, or other intermediary web portal located at home or at a gym).
Claim 15: The combination of Lyke, Hadad, Asikainen, Cha, Akdogan, and Shelton teaches the limitations as shown in the rejections above.
Lyke does not explicitly disclose, but Akdogan, as shown, teaches the following limitations:
wherein transactions on the e-commerce platform are supported by artificial intelligence-driven product recommendations and secure payment gateways (see at least ¶ [0162]: the cloud may provide consumable usage trend identification via an analytics engine, for (1) input to medical professionals and systems (2) warnings/recommendations based on recognized patterns and medical input (3) on demand data/visuals for users (4) modification of pricing and supply chain (e.g. contract and internal manufacturing) of consumable products; see also at least ¶ [0146]: viewing and downloading analytics output, including but not limited to various healthiness metrics, personal goal progress and consumable recommendations based on user data (4) Browsing for pertinent medical information, including but not limited to drug facts, disease symptoms and treatments, physician locations and availabilities, healthcare news on medications and diseases, and site-specific content, in a manner tailored for user given user data (5) Receiving device-agnostic deliveries of this pertinent medical information, triggered by news events (e.g. drug recall, manufacturer warning letters) or user-specific events (e.g. user's family member commenced use of specific drug regimen), and tailored by user data (6) Viewing, downloading and sharing the above pertinent medical information; see also at least ¶ [0167]: similarly various notification systems, monitoring functions, data storage functions, management and administration functions and the like may be distributed or centralized in various manners across available resources according to user preferences, security requirements, oversight required by health care professionals, data integrity requirements and so forth; see also at least ¶ [0190]: the system may include a financial processing system 3634 for processing various financial transactions associated with use of the base and/or cartridges; see also at least ¶ [0161]: security of EMRs and other healthcare data structures may be enabled via data licensing and incremental digital signatures; see also at least ¶ [0156]: all communications may be fully compliant with US and international requirements, including but not limited to HIPAA, and may be encrypted with industry standard or industry leading cryptographic technologies, such as 256-bit Rijndael encryption. All communications may pass through cloud's system servers to ensure complete reliability and security).
The rationales to modify/combine the teachings of these references are presented above in claims 1 and 2 and incorporated herein.
Claim 16: The combination of Lyke, Hadad, Asikainen, Cha, Akdogan, and Shelton teaches the limitations as shown in the rejections above.
Lyke does not explicitly disclose, but Asikainen, as shown, teaches the following limitations:
wherein the social networking features allow users to geo-tag activities, share fitness milestones, […], and participate in location-based challenges (see at least ¶ [0112]: the gamification engine 212 generates a recommendation for the user to join an online community of other users of interactive personal training device 108 or friends to stay accountable in adhering to their workout program. For example, when the user consistently adheres to a workout program exercising with the interactive personal training device 108 for a week, the gamification engine 212 shares this success streak of the user with the online community or friends of the user. The gamification engine 212 facilitates the sharing of workout related information, such as a video, avatar, score, statistics, rewards, progress, level-ups, achievement badges, etc. via a social media application for receiving social reinforcement in the form of indications of acknowledgment (e.g., likes, comments, shares, etc.), feedback, support, and recommendations from a social circle that help with motivating the user. For example, the user may record and share a short-form video of an exercise repetition or an exercise movement that they consider to be their personal record to their social circle via the interactive personal training device 108; see also at least ¶ [0128]: FIG. 14 shows an example graphical representation illustrating a user interface 1400 for displaying a leaderboard and user rankings on the interactive personal training device 108. The user interface 1400 shows a leaderboard and a user is able to select their preferred ranking category. The leaderboard may include a plurality of metrics, such as overall fitness, overall strength, overall endurance, most workouts, oldest members, most challenges won, similar performance (to the user), looking for a challenge, champions, most classes, age groups, sex, public challenges, my challenges, etc.; see also at least ¶ [0040]: this enables the interactive personal training device 108 to accurately detect and track acceleration, weight volume, equipment in use, equipment trajectory, and spatial location in three-dimensional space; see also at least ¶ [0060]: non-limiting examples of the sensor(s) 249 include various optical sensors (CCD, CMOS, 2D, 3D, light detection and ranging (LiDAR), cameras, etc.), audio sensors, motion detection sensors, magnetometer, barometers, altimeters, thermocouples, moisture sensors, infrared (IR) sensors, radar sensors, other photo sensors, gyroscopes, accelerometers, geo-location sensors, orientation sensor, wireless transceivers (e.g., cellular, Wi-Fi™, near-field, etc.), sonar sensors, ultrasonic sensors, touch sensors, proximity sensors, distance sensors, microphones, etc.; see also at least ¶ [0069]: the user profile received from the third-party social network server 140 may include one or more of the user's age, gender, interests, location, and other demographic information).
The rationales to modify/combine the teachings of these references are presented above in claims 1 and 2 and incorporated herein.
Lyke does not explicitly disclose, but Cha, as shown, teaches the following limitations:
wherein the social networking features allow users to […] monetize content (see at least ¶ [0036]: in case of contents (UCC: User Created Contents) manufactured by a general user, the contents' owner may be recommender and/or evaluator at the same time. That is, the user can register contents (UCC) on a UCC service site and at the same time recommend an advertisement for their mapping. Therefore, the present invention can select an advertisement when putting a moving image at a UCC moving image portal and attach it thereto, and distribute a profit created thereby to the contents register; see also at least ¶ [0037]: while the existing context advertisement model is constituted by the advertiser, the contents owner and the consumer, the advertisement model by the AdHelper system of the present invention adds thereto a ‘recommender’ who offers effective mapping of contents and advertisement and an ‘evaluator’ who verifies the appropriateness of such mapping, thereby providing the recommender and the evaluator with a monetary or honorable profit. In addition, the consumer, the evaluator and the recommender are all Internet users and divided not individually but by role. Therefore, they can conduct more than two roles at the same time, which reflect the property of web 2.0 such as prosumer and collective intelligence).
The rationales to modify/combine the teachings of these references are presented above in claims 1 and 2 and incorporated herein.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure. The following references have been cited to further show the state of the art with respect to fitness monitoring platforms.
Tran et al. (U.S. Pub. No. 2021/0233656 A1) (health management via capturing activity and food consumption);
Crema et al. (“Characterization of a wearable system for automatic supervision of fitness exercises.” Measurement 147 (2019)).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Christopher Tokarczyk, whose telephone number is 571-272-9594. The examiner can normally be reached Monday-Thursday between 6:00 AM and 4:00 PM Eastern.
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, Mamon Obeid, can be reached at 571-270-1813. 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.
/CHRISTOPHER B TOKARCZYK/Primary Examiner, Art Unit 3687