DETAILED ACTION
1. This office action is in response to the amendment filed on 06/04/2026.
2. Claims 2 and 5 are canceled.
3. Claims 1, 3, 4, and 6-15 are currently pending and have been considered below.
Response to Arguments
4. Applicant's arguments filed on 06/04/2026 have been fully considered but they are not persuasive.
In the remarks, the Applicant argues in substance that:
The cited reference, Keen, fails to teach or suggest claim 1 limitations.
In response to argument:
a) Examiner respectfully disagrees. First, the Examiner would like to remind the applicant that the rejection is based on the broadest reasonable interpretation of the claims. The Applicant argues on pages 10-14 of the remarks that the cited art does not teach or suggest claim 1 limitations. However, Keen in [0025], [0029], [0046] discloses the service provider may receive historical activity data of a user corresponding to a particular time of day. For example, the service provider may receive information indicating that the user burned 50 calories by 11 am on the previous day, or by 11 am on a previous Tuesday. The service provider may then generate a user interface that displays an activity goal of the user (e.g., 1000 calories burned) along with a first indicator that displays that by 11 am of the current day (e.g., today), the user has burned 100 calories or 10% of the goal. The user interface may also display another indicator that displays that by 11 am of the current day, the users predicted accumulated activity level would be 50 calories based at least in part on the historical data that indicated that the user had burned 50 calories by 11 am previously. The user interface may then be provided to a computing device of the user. Further, Keen in [0007] discloses additionally, the historical activity data may comprise calories burned by the user, heart beats of the user, steps walked by the user, distance traveled by the user, or minutes exercised by the user, which corresponds to the limitations obtaining a set of data relating to preceding time windows and including, for each preceding time window, the value reached by said parameter over said preceding time window and the target value associated with said preceding time window within the claim,
Further, Keen in [0029] discloses the service provider may receive historical activity data of a user corresponding to a particular time of day. For example, the service provider may receive information indicating that the user burned 50 calories by 11 am on the previous day, or by 11 am on a previous Tuesday. Further, Keen in [0045]-[0046] discloses in this example, the user may have cumulatively (or during that hour) burned 600 calories by or at 7 am on Day 1 as indicated by 308 of flow 302 (e.g., Interval 1). Additionally, the user may have burned a total of 850 hours by 9 pm of Day 2 as indicated by 310 of 302. As such, on Day 2, the pacer dot 124(A) may indicate a predicted amount of about 600 calories burned. It should be noted that while FIG. 3 illustrates Day 1 and Day 1, Interval 1 and Interval 2, etc., any number of previous days or time periods (e.g., weeks, months, etc.) may be used for calculating and/or collecting historical activity data. For example, Day 1 may actually correspond to a Monday of a previous week or year, and Day 2 may actually correspond to a Monday of the current week. Furthermore, [0065] discloses Figs. 5-7 illustrate example flow diagrams showing processes 500, 600, and 700 for providing and/or managing pacing activity data of a user…The process 500 may begin at 502 where the user device 102 may receive historical activity data of a user. This historical activity data may be of a cumulative type such as calories burned, amount of time exercised, number of steps walked or ran, etc. The historical data may be collected over a period of time (e.g., hours, days, weeks, etc.). Additionally, in some examples, the historical activity data may be received from a data collection device (e.g., a heart rate monitor, a calorie tracker, or the like, which corresponds to the limitation a time scale among at least two predetermined time scales depends on the variations in the parameter value over one or more preceding time windows within the claim.
Furthermore, Keen in [0029] discloses receive information indicating that the user burned 50 calories by 11 am on the previous day, or by 11 am on a previous Tuesday. Further, in [0045]-[0046] discloses in this example, the user may have cumulatively (or during that hour) burned 600 calories by or at 7 am on Day 1 as indicated by 308 of flow 302 (e.g., Interval 1). Additionally, the user may have burned a total of 850 hours by 9 pm of Day 2 as indicated by 310 of 302. As such, on Day 2, the pacer dot 124(A) may indicate a predicted amount of about 600 calories burned… It should be noted that while FIG. 3 illustrates Day 1 and Day 1, Interval 1 and Interval 2, etc., any number of previous days or time periods (e.g., weeks, months, etc.) may be used for calculating and/or collecting historical activity data. For example, Day 1 may actually correspond to a Monday of a previous week or year, and Day 2 may actually correspond to a Monday of the current week. Also, in [0065] discloses the process 500 may begin at 502 where the user device 102 may receive historical activity data of a user. This historical activity data may be of a cumulative type such as calories burned, amount of time exercised, number of steps walked or ran, etc. The historical data may be collected over a period of time (e.g., hours, days, weeks, etc.). Additionally, in some examples, the historical activity data may be received from a data collection device (e.g., a heart rate monitor, a calorie tracker, or the like); which corresponds to the limitation retrieving data relating to one or more preceding time windows based on said time scale within the claim.
Moreover, Keen in in [0029] discloses receive historical activity data of a user corresponding to a particular time of day. For example, the service provider may receive information indicating that the user burned 50 calories by 11 am on the previous day, or by 11 am on a previous Tuesday... The service provider may then generate a user interface that displays an activity goal of the user (e.g., 1000 calories burned) along with a first indicator that displays that by 11 am of the current day (e.g., today), the user has burned 100 calories or 10% of the goal); which corresponds to the limitation calculating a success factor based on a comparison between the value reached by said parameter over one or more preceding time windows and the associated target value within the claim.
Furthermore, Keen in [0029], [0034] discloses a service provider may be configured to provide a user interface with an indicator that displays cumulative daily progress (e.g., calories burned or the like) towards a goal…Additionally, the user interface may also include another indicator that displays a predicted cumulative daily progress for the same time of day, for at least one day occurring before the current day... The service provider may then generate a user interface that displays an activity goal of the user (e.g., 1000 calories burned) along with a first indicator that displays that by 11 am of the current day (e.g., today), the user has burned 100 calories or 10% of the goal… The user interface may also display another indicator that displays that by 11 am of the current day, the users predicted accumulated activity level would be 50 calories based at least in part on the historical data that indicated that the user had burned 50 calories by 11 am previously, which corresponds to the limitation determining the target value for the upcoming time window based on said success factor and the value reached by said parameter over each preceding time window of the retrieved data within the claim.
Keen discloses a time scale among at least two predetermined time scales depends on the variations in the parameter value over one or more preceding time windows as discloses above. Keen may not explicitly disclose
selecting a time scale among at least two predetermined time scales. However, Keen discloses in some implementations, a temporal forecast can be generated for an attribute or attribute value. The temporal forecast can indicate, for example, what values for the attributes are likely to occur at what times of the day and/or at what time of day an event associated with the attribute or attribute value is likely to occur. For example, a client of the sampling daemon can request a temporal forecast for the attribute (e.g., calories burned) over the last week (e.g., last 7 days). To generate the forecast, a 24-hour day can be divided into 96 15-minute timeslots. For a particular timeslot (e.g., 1:00-1:15 pm) on each of the last seven days, the sampling daemon can determine how many calories were burned during each time slot and generate a score for each timeslot that indicates the maximal expected calorie burn... It should be noted that while FIG. 3 illustrates Day 1 and Day 1, Interval 1 and Interval 2, etc., any number of previous days or time periods (e.g., weeks, months, etc.) may be used for calculating and/or collecting historical activity data…Further, in some examples, any time prior to the current time period (e.g., current time interval) may be considered a first time period, and the current day may be considered a second time period. As such, at a high level, predicted activity data for any interval of the current day (or the second time period) may be based at least in part on historical activity data from intervals of the first time period (see, [0029], [0034], [0046]). Further, Keen in [0065] discloses Figs. 5-7 illustrate example flow diagrams showing processes 500, 600, and 700 for providing and/or managing pacing activity data of a user. The process 500 may begin at 502 where the user device 102 may receive historical activity data of a user. This historical activity data may be of a cumulative type such as calories burned, amount of time exercised, number of steps walked or ran, etc. The historical data may be collected over a period of time (e.g., hours, days, weeks, etc.). Additionally, in some examples, the historical activity data may be received from a data collection device (e.g., a heart rate monitor, a calorie tracker, or the like. Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Keen to use selecting a time scale among at least two predetermined time scales based on the teaching of Keen as disclosed above. The motivation for doing so would have been in order to indicate the relative likelihood of the target value occurring during a predetermined time period of interest (Keen, [0034]-[0035]). Thus, Keen teaches the scope of broadly claimed limitation as currently presented.
In response to the Applicant’s argument that the references fail to show certain features of applicant’s invention, it is noted that the features upon which applicant relies (i.e., Further, Applicant respectfully submits that the claimed features would also not have been obvious in view of Keen. Applicant's Claim 1 aims at determining a target value to be reached for a parameter. Such target value notably corresponds to a goal value to be reached by an individual in the context of a parameter quantifying a physical activity of the individual. For example, the parameter may be a number of steps taken by the individual (page 10, line 2 of the specification) and the target value to be reached for such parameter in a given time window may be a target number of steps taken by the individual in a fixed time interval (e.g., 5000 steps per day). In particular, Claim 1 addresses the technical issue of how to determine such target value for a specific individual, having specific and evolving health record, health profile, lifestyle, habits, etc. For example, values of the parameter corresponding to a number of steps taken by the individual may vary throughout time windows depending on periods the individual goes to work, rests at home, hikes on vacation, is hospitalized, etc. Consequently, a target number of steps to be set for the individual for an upcoming time window should be determined while taking such potential variations into account) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). Applicant is encouraged to amend the claims to require the distinction and to advance prosecution. As claimed today, Keen still discloses broadly claimed limitations.
b) In regard to 101 rejection, the Applicant has provided arguments, “… The claimed target value is determined from values of a parameter quantifying
physical activity, and those values are expressly measured by a portable device adapted to be worn by the individual. The claimed time scale selection is also tied to variations in that measured physical activity parameter over preceding time windows. Thus, the wearable device and the measured physical activity data are integral to the operation of the claimed method, because they provide real-world measurements from which the claimed target value is determined. The claimed invention also provides additional advantages, as discussed below with respect to the art-based rejection.
The claims are thus directed to a "practical application," and the rejection must therefore be withdrawn. Moreover, it is believed the claims are also directed to "significantly more" at least due to the technical improvements noted herein and because the recited features are not "well-understood, routine, or conventional." Accordingly, in view of the present amendment and the above remarks, Applicant respectfully requests the § 101 rejection be withdrawn.” (pages 11-14).
In response to argument:
b) In Response, the Examiner respectfully disagrees. Foremost, the decision of the Supreme Court in regard to Alice vs CLS Bank is succinctly discussed as follows. In their decision, Supreme Court has stated that the mere recitation of a generic computer cannot transform a patent-ineligible abstract ideas (such as algorithms) into a patent eligible invention. Because the algorithm was an abstract idea, the claim had to supply a “new and useful" application of the idea in order to be patent eligible (Alice, Page 12). Furthermore, the additional limitations had to be significantly more than a patent upon the ineligible concept itself (Alice, page 7, 15).
Regarding independent Claim 15, we recognize that the limitations “select a time scale among at least two predetermined time scales depending on variations in the value reached by said parameter over one or more preceding time window, calculate a success factor based on a comparison between the value reached by said parameter over one or more preceding time windows and the associated target value, and determine the target value for the upcoming time window based on said success factor and the value reached by said parameter over each preceding time window of the retrieved data”, as abstract ideas. The abstract idea of claim 15 can be characterized as processes, under their broadest reasonable interpretation, covers mental processes and/or mathematical concepts.
Beyond the abstract idea, we next look at additional elements that can be considered to integrate the abstract idea into a practical application. In particular, the claim limitations “circuitry configured to receive a set of data relating to a plurality of preceding time windows; and a memory configured to store the received set of data, the data relating to a preceding time window including the value reached by said parameter over said preceding time window and the associated target value, the value reached by said parameter being measured by a portable device adapted to be worn by the individual and adapted to be received by the circuitry, wherein the circuitry configured to:
retrieve, from the memory, data relating to one or more preceding time windows based on said time scale” are additional element. However, the claim limitations “circuitry configured to receive a set of data relating to a plurality of preceding time windows, and the value reached by said parameter being measured by a portable device adapted to be worn by the individual and adapted to be received by the circuitry”, are recited at a high level of generality, and are nothing more than data collection activity for gathering parameters using a well-known conventional portable device and activity previously known in the industry in order to execute an abstract idea, which also do not further limit and integrate the abstract idea in practical application, and as such, do not amount to significantly more than the abstract idea itself. As shown in the prior art, Keen et al. US 2016/0058331 (hereinafter, Keen), ([0025], [0105], Fig. 1), and Ohnemus et al. US 2014/0135592 (hereinafter, Ohnemus), ([0068], Figs. 1-2), both show that the circuitry configured to receive a set of data relating to a plurality of preceding time windows, and the value reached by said parameter being measured by a portable device adapted to be worn by the individual and adapted to be received by the circuitry are well-understood and purely conventional in the relevant art and would be routinely used by those of ordinary skill in the art in order to apply the abstract idea(s) and/or activities previously known to the pertinent industry, such that they amount to no more than data collection or gathering required to perform the abstract idea.
Further, the claim limitations “a memory configured to store the received set of data, the data relating to a preceding time window including the value reached by said parameter over said preceding time window and the associated target value,…, wherein the circuitry configured to: retrieve, from the memory, data relating to one or more preceding time windows based on said time scale” is also recited at a high level of generality” are nothing more than a storing and retrieving data using a generic computer components. As shown in the prior art, Keen, ([0025], [0105], Fig. 1), and Ohnemus, ([0068], Figs. 1-2), both show that the “a memory configured to store the received set of data, the data relating to a preceding time window including the value reached by said parameter over said preceding time window and the associated target value,…, wherein the circuitry configured to: retrieve, from the memory, data relating to one or more preceding time windows based on said time scale” is also recited at a high level of generality” are a well-known conventional computer components previously known in the industry in order to execute an abstract idea, which also do not further limit and integrate the abstract idea in practical application, and as such, do not amount to significantly more than the abstract idea itself. Accordingly, these additional elements do not integrate the abstract idea into a practical application because these elements do not impose any meaningful limits on practicing the abstract idea. The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. The combination of elements, when considered individually and as an ordered combination, do not amount to “significantly more” than the identified abstract idea. The claim is not patent eligible. Therefore, the 101 rejection is maintained.
Claim Rejections - 35 USC § 101
5. 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.
6. Claims 1, 3, 4, and 6-15 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The representative claim 15 recites:
A system for determining a target value to be reached for a parameter over an upcoming time window, said parameter quantifying an intensity or quality of an individual's physical activity, the system comprising:
circuitry configured to receive a set of data relating to a plurality of preceding time windows; and
a memory configured to store the received set of data, the data relating to a preceding time window including the value reached by said parameter over said preceding time window and the associated target value, the value reached by said parameter being measured by a portable device adapted to be worn by the individual and adapted to be received by the circuitry, wherein
the circuitry configured to:
select a time scale among at least two predetermined time scales depending on variations in the value reached by said parameter over one or more preceding time window,
retrieve, from the memory, data relating to one or more preceding time windows based on said time scale,
calculate a success factor based on a comparison between the value reached by said parameter over one or more preceding time windows and the associated target value, and
determine the target value for the upcoming time window based on said success factor and the value reached by said parameter over each preceding time window of the retrieved data.
The claim limitations in the abstract idea have been highlighted in bold above; the remaining limitations are “additional elements”.
Under step 1 of the eligibility analysis, we determine whether the claims are to a statutory category by considering whether the claimed subject matter falls within the four statutory categories of patentable subject matter identified by 35 U.S.C. 101: process, machine, manufacture, or composition of matter. The above claims are considered to be in a statutory category (process).
Under Step 2A, Prong One, we consider whether the claim recites a judicial exception (abstract idea). In the above claim, the highlighted portion constitutes an abstract idea because, under a broadest reasonable interpretation, it recites limitation that fall into/recite abstract idea exceptions. Specifically, under the 2019 Revised Patent Subject Matter Eligibility Guidance, it falls into the grouping of subject matter that, when recited as such in a claim limitation, covers mathematical concepts (mathematical relationships, mathematical formulas or equations, mathematical calculations) and/or mental processes – concepts performed in the human mind including an observation, evaluation, judgement, and/or opinion.
Next, under Step 2A, Prong Two, we consider whether the claim that recites a judicial exception is integrated into a practical application. In this step, we evaluate whether the claim recites additional elements that integrate the exception into a practical application of that exception.
This judicial exception is not integrated into a practical application because the additional limitations in the claim are only: circuitry configured to receive a set of data relating to a plurality of preceding time windows; and a memory configured to store the received set of data, the data relating to a preceding time window including the value reached by said parameter over said preceding time window and the associated target value, the value reached by said parameter being measured by a portable device adapted to be worn by the individual and adapted to be received by the circuitry, wherein the circuitry configured to: retrieve, from the memory, data relating to one or more preceding time windows based on said time scale. The limitations “circuitry configured to receive a set of data relating to a plurality of preceding time windows; and the value reached by said parameter being measured by a portable device adapted to be worn by the individual and adapted to be received by the circuitry” are recited at a high level of generality (i.e., gathering or collecting data using a portable device and a generic computer components) such that they amount no more than mere instructions to apply the exception using a generic device and computer components.
Further, the claim limitations “a memory configured to store the received set of data, the data relating to a preceding time window including the value reached by said parameter over said preceding time window and the associated target value, and wherein the circuitry configured to: retrieve, from the memory, data relating to one or more preceding time windows based on said time scale”, are recited at a high level of generality (i.e., as a generic computer structures performing a generic computer function of storing and retrieving, and processing data or information) such that they amount no more than mere instructions to apply the exception using a generic computer components.
Finally, under Step 2B, we consider whether the additional elements are sufficient to amount to significantly more than the abstract idea.
Claim 15 does not include additional elements that are sufficient to amount to significantly more than the judicial exception because, as noted above, the additional limitations recited at a high level of generality (i.e., as collecting and gathering data using a generic portable device and computer structures performing a generic computer function of receiving, retrieving, processing, and storing information). Further, the additional elements are conventional in the art, as evidenced by the art of record (see, Keen et al. US 2016/0058331 (hereinafter, Keen), ([0025], [0105], Fig. 1), and Ohnemus et al. US 2014/0135592 (hereinafter, Ohnemus), ([0068], Figs. 1-2). Therefore, claim 15 is directed to an abstract idea without significantly more.
The claim is not patent eligible.
Independent claim 1, the claim is rejected with the same rationale as in claim 15.
Dependent claim 3, recites addition element of “wherein the portable device is a pedometer type device sensitive to motion”. However, this limitation is recited at a high level of generality (i.e., gathering data using a portable device) such that it amounts no more than mere instructions to apply the exception using a generic device. Further, the additional element is conventional in the art, as evidenced by the art of record (see, Keen, ([0025]), and Ohnemus ([0059], Fig. 1). Therefore, the claim is directed to an abstract idea without significantly more. The claim is not patent eligible.
Dependent claims 4 and 6-13, add further details of the identified abstract idea. The claims are not patent eligible.
Dependent claim 14, the claim is rejected with the same rationale as in claim 15.
Claim Rejections - 35 USC § 103
7. In the event the determination of the status of the application as subject to AlA 35 U.S.C. 102 and 103 (or as subject to pre-AlA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, 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.
8. Claims 1, 3-4, 6-10, 14, and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Keen et al. US 2016/0058331 (hereinafter, Keen).
9. Regarding claim 1, Keen discloses a computer-implemented method for determining a target value to be reached for a parameter over an upcoming time window, said parameter quantifying an intensity or quality of an individual's physical activity([0025]), the method comprising:
obtaining a set of data relating to preceding time windows and including, for each preceding time window, the value reached by said parameter over said preceding time window and the target value associated with said preceding time window([0025], [0029], [0046]: the service provider may receive historical activity data of a user corresponding to a particular time of day. For example, the service provider may receive information indicating that the user burned 50 calories by 11 am on the previous day, or by 11 am on a previous Tuesday. The service provider may then generate a user interface that displays an activity goal of the user (e.g., 1000 calories burned) along with a first indicator that displays that by 11 am of the current day (e.g., today), the user has burned 100 calories or 10% of the goal. The user interface may also display another indicator that displays that by 11 am of the current day, the users predicted accumulated activity level would be 50 calories based at least in part on the historical data that indicated that the user had burned 50 calories by 11 am previously. The user interface may then be provided to a computing device of the user….[Further], [0007]: Additionally, the historical activity data may comprise calories burned by the user, heart beats of the user, steps walked by the user, distance traveled by the user, or minutes exercised by the user),
the value reached by said parameter being measured by a portable device adapted to be worn by the individua ([0025], [0070]).
a time scale among at least two predetermined time scales depends on the variations in the parameter value over one or more preceding time windows ([0029]: the service provider may receive historical activity data of a user corresponding to a particular time of day. For example, the service provider may receive information indicating that the user burned 50 calories by 11 am on the previous day, or by 11 am on a previous Tuesday… [Further], [0045]-[0046]: In this example, the user may have cumulatively (or during that hour) burned 600 calories by or at 7 am on Day 1 as indicated by 308 of flow 302 (e.g., Interval 1). Additionally, the user may have burned a total of 850 hours by 9 pm of Day 2 as indicated by 310 of 302. As such, on Day 2, the pacer dot 124(A) may indicate a predicted amount of about 600 calories burned… It should be noted that while FIG. 3 illustrates Day 1 and Day 1, Interval 1 and Interval 2, etc., any number of previous days or time periods (e.g., weeks, months, etc.) may be used for calculating and/or collecting historical activity data. For example, Day 1 may actually correspond to a Monday of a previous week or year, and Day 2 may actually correspond to a Monday of the current week….[0065]: FIGS. 5-7 illustrate example flow diagrams showing processes 500, 600, and 700 for providing and/or managing pacing activity data of a user,..The process 500 may begin at 502 where the user device 102 may receive historical activity data of a user. This historical activity data may be of a cumulative type such as calories burned, amount of time exercised, number of steps walked or ran, etc. The historical data may be collected over a period of time (e.g., hours, days, weeks, etc.). Additionally, in some examples, the historical activity data may be received from a data collection device (e.g., a heart rate monitor, a calorie tracker, or the like) ;
retrieving data relating to one or more preceding time windows based on said time scale ([0029]: receive information indicating that the user burned 50 calories by 11 am on the previous day, or by 11 am on a previous Tuesday…[Further], [0045]-[0046]: In this example, the user may have cumulatively (or during that hour) burned 600 calories by or at 7 am on Day 1 as indicated by 308 of flow 302 (e.g., Interval 1). Additionally, the user may have burned a total of 850 hours by 9 pm of Day 2 as indicated by 310 of 302. As such, on Day 2, the pacer dot 124(A) may indicate a predicted amount of about 600 calories burned… It should be noted that while FIG. 3 illustrates Day 1 and Day 1, Interval 1 and Interval 2, etc., any number of previous days or time periods (e.g., weeks, months, etc.) may be used for calculating and/or collecting historical activity data. For example, Day 1 may actually correspond to a Monday of a previous week or year, and Day 2 may actually correspond to a Monday of the current week….[0065]: the process 500 may begin at 502 where the user device 102 may receive historical activity data of a user. This historical activity data may be of a cumulative type such as calories burned, amount of time exercised, number of steps walked or ran, etc. The historical data may be collected over a period of time (e.g., hours, days, weeks, etc.). Additionally, in some examples, the historical activity data may be received from a data collection device (e.g., a heart rate monitor, a calorie tracker, or the like);
calculating a success factor based on a comparison between the value reached by said parameter over one or more preceding time windows and the associated target value ([0029]: receive historical activity data of a user corresponding to a particular time of day. For example, the service provider may receive information indicating that the user burned 50 calories by 11 am on the previous day, or by 11 am on a previous Tuesday... The service provider may then generate a user interface that displays an activity goal of the user (e.g., 1000 calories burned) along with a first indicator that displays that by 11 am of the current day (e.g., today), the user has burned 100 calories or 10% of the goal); and
determining the target value for the upcoming time window based on said success factor and the value reached by said parameter over each preceding time window of the retrieved data ([0029], [0034]: a service provider may be configured to provide a user interface with an indicator that displays cumulative daily progress (e.g., calories burned or the like) towards a goal…Additionally, the user interface may also include another indicator that displays a predicted cumulative daily progress for the same time of day, for at least one day occurring before the current day... The service provider may then generate a user interface that displays an activity goal of the user (e.g., 1000 calories burned) along with a first indicator that displays that by 11 am of the current day (e.g., today), the user has burned 100 calories or 10% of the goal… The user interface may also display another indicator that displays that by 11 am of the current day, the users predicted accumulated activity level would be 50 calories based at least in part on the historical data that indicated that the user had burned 50 calories by 11 am previously).
Keen does not disclose:
selecting a time scale among at least two predetermined time scales.
However, Keen discloses:
“ In some implementations, a temporal forecast can be generated for an attribute or attribute value. The temporal forecast can indicate, for example, what values for the attributes are likely to occur at what times of the day and/or at what time of day an event associated with the attribute or attribute value is likely to occur. For example, a client of the sampling daemon can request a temporal forecast for the attribute (e.g., calories burned) over the last week (e.g., last 7 days). To generate the forecast, a 24-hour day can be divided into 96 15-minute timeslots. For a particular timeslot (e.g., 1:00-1:15 pm) on each of the last seven days, the sampling daemon can determine how many calories were burned during each time slot and generate a score for each timeslot that indicates the maximal expected calorie burn... It should be noted that while FIG. 3 illustrates Day 1 and Day 1, Interval 1 and Interval 2, etc., any number of previous days or time periods (e.g., weeks, months, etc.) may be used for calculating and/or collecting historical activity data…Further, in some examples, any time prior to the current time period (e.g., current time interval) may be considered a first time period, and the current day may be considered a second time period. As such, at a high level, predicted activity data for any interval of the current day (or the second time period) may be based at least in part on historical activity data from intervals of the first time period (see, [0029], [0034], [0046]…[Further]: FIGS. 5-7 illustrate example flow diagrams showing processes 500, 600, and 700 for providing and/or managing pacing activity data of a user,..The process 500 may begin at 502 where the user device 102 may receive historical activity data of a user. This historical activity data may be of a cumulative type such as calories burned, amount of time exercised, number of steps walked or ran, etc. The historical data may be collected over a period of time (e.g., hours, days, weeks, etc.). Additionally, in some examples, the historical activity data may be received from a data collection device (e.g., a heart rate monitor, a calorie tracker, or the like,” (see, [0065]).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Keen to use selecting a time scale among at least two predetermined time scales based on the teaching of Keen as disclosed above. The motivation for doing so would have been in order to indicate the relative likelihood of the target value occurring during a predetermined time period of interest (Keen, [0034]-[0035]).
10. Regarding claims 14 and 15, the claims are rejected with the same rationale as in claim 1.
11. Regarding claim 3, Keen discloses the method of claim 1, as disclosed above.
Keen further discloses wherein the portable device is a pedometer-type device sensitive to motion, wherein the parameter quantifying the intensity or quality of the individual's physical activity, corresponds to at least one among a number of steps, a distance traveled by the individual, a number of calories burned or duration of said physical activity ([0007], [0025]).
12. Regarding claim 4, Keen discloses the method of claim 3, as disclosed above.
Keen further discloses wherein the success factor is calculated based on a profile of said individual depending on physiological characteristics or data relating to a regular physical activity or health of said individual ([0029]: receive historical activity data of a user corresponding to a particular time of day. For example, the service provider may receive information indicating that the user burned 50 calories by 11 am on the previous day, or by 11 am on a previous Tuesday... The service provider may then generate a user interface that displays an activity goal of the user (e.g., 1000 calories burned) along with a first indicator that displays that by 11 am of the current day (e.g., today), the user has burned 100 calories or 10% of the goal).
13. Regarding claim 6, Keen discloses the method of claim 1, as disclosed above.
Keen further discloses wherein each time scale of the at least two predetermined time scales relates to a period of time, and wherein selecting the time scale comprises: for each time scale of the at least two predetermined time scales: selecting data relating to preceding time windows spaced from the upcoming time window by a multiple of the period of time to which said time scale relates ([0029]: the service provider may receive historical activity data of a user corresponding to a particular time of day. For example, the service provider may receive information indicating that the user burned 50 calories by 11 am on the previous day, or by 11 am on a previous Tuesday. The service provider may then generate a user interface that displays an activity goal of the user (e.g., 1000 calories burned) along with a first indicator that displays that by 11 am of the current day (e.g., today), the user has burned 100 calories or 10% of the goal. The user interface may also display another indicator that displays that by 11 am of the current day, the users predicted accumulated activity level would be 50 calories based at least in part on the historical data that indicated that the user had burned 50 calories by 11 am previously….[Further], [0034], [0044]: For example, a client of the sampling daemon can request a temporal forecast for the attribute (e.g., calories burned) over the last week (e.g., last 7 days). To generate the forecast, a 24-hour day can be divided into 96 15-minute timeslots. For a particular timeslot (e.g., 1:00-1:15 pm) on each of the last seven days, the sampling daemon can determine how many calories were burned during each time slot and generate a score for each timeslot that indicates the maximal expected calorie burn),
calculating, for each pair of two consecutive preceding time windows of the selected data, a difference between the values reached by the parameter respectively over each preceding time window of said pair of two consecutives preceding time windows ([0029], [0045]-[0046]), and
assigning to said time scale a stability score characterizing one or more calculated differences; and selecting the time scale based on the respective stability scores of the time scales of the at least two predetermined time scales ([0029], [0034], [0045]-[0046]).
14. Regarding claim 7, Keen discloses the method of claim 6, as disclosed above.
Keen further discloses wherein the stability score assigned to a time scale depends on a ratio of pair of two consecutive preceding time windows of the selected data for which the calculated difference is lower than or equal to a predetermined threshold ([0005], [0029]: In some examples, the activity may be capable of being tracked cumulatively. The predicted amount of activity may be based at least in part on a probability that the user will meet a threshold activity level during the at least one interval. The at least one interval may comprise the current interval and/or the predicted amount of activity may be based at least in part on historical activity data of the user…the service provider may receive historical activity data of a user corresponding to a particular time of day. For example, the service provider may receive information indicating that the user burned 50 calories by 11 am on the previous day, or by 11 am on a previous Tuesday. The service provider may then generate a user interface that displays an activity goal of the user (e.g., 1000 calories burned) along with a first indicator that displays that by 11 am of the current day (e.g., today), the user has burned 100 calories or 10% of the goal...[Further], [0034], [0045]: To generate the forecast, a 24-hour day can be divided into 96 15-minute timeslots. For a particular timeslot (e.g., 1:00-1:15 pm) on each of the last seven days, the sampling daemon can determine how many calories were burned during each time slot and generate a score for each timeslot that indicates the maximal expected calorie burn. In some implementations, the temporal forecast can be generated based on an event history window specification. For example, if the client provides a window specification that specifies a 4-hour time period of interest, the temporal forecast will only generate likelihood scores for the 15-minute timeslots that are in the 4-hour time period of interest. For example, if the time period of interest corresponds to 12:00-4:00 pm for each of the last 3 days, then 16 timeslots will be generated during the 4 hour period of interest and a score will be generated for each of the 16 15 minute timeslots. Scores will not be generated for timeslots outside the specified 4 hour time period of interest).
15. Regarding claim 8, Keen discloses the method of claim 1, as disclosed above.
Keen further discloses wherein each time scale of the at least two predetermined time scales relates to a period of time, and wherein selecting the time scale comprises: for each time scale of the at least two predetermined time scales: selecting data relating to one or more preceding time windows spaced from the upcoming time window by a multiple of the period of time to which said time scale relates ([0029]: the service provider may receive historical activity data of a user corresponding to a particular time of day. For example, the service provider may receive information indicating that the user burned 50 calories by 11 am on the previous day, or by 11 am on a previous Tuesday. The service provider may then generate a user interface that displays an activity goal of the user (e.g., 1000 calories burned) along with a first indicator that displays that by 11 am of the current day (e.g., today), the user has burned 100 calories or 10% of the goal. The user interface may also display another indicator that displays that by 11 am of the current day, the users predicted accumulated activity level would be 50 calories based at least in part on the historical data that indicated that the user had burned 50 calories by 11 am previously….[Further], [0034], [0044]: For example, a client of the sampling daemon can request a temporal forecast for the attribute (e.g., calories burned) over the last week (e.g., last 7 days). To generate the forecast, a 24-hour day can be divided into 96 15-minute timeslots. For a particular timeslot (e.g., 1:00-1:15 pm) on each of the last seven days, the sampling daemon can determine how many calories were burned during each time slot and generate a score for each timeslot that indicates the maximal expected calorie burn),
calculating, for each preceding time window of the selected data, a difference between the value reached by the parameter over said preceding time window and the target value associated with said preceding time window ([0029], [0045]-[0046]), and
assigning to said time scale a regularity score characterizing one or more calculated differences; and selecting the time scale based on the respective regularity scores of the time scales of the at least two predetermined time scales ([0029], [0034], [0045]-[0046]).
16. Regarding claim 9, Keen discloses the method of claim 8, as disclosed above.
Keen further discloses wherein the regularity score assigned to a time scale depends on a ratio of preceding time windows of the selected data for which the calculated difference is lower than or equal to a predetermined threshold ([0005], [0029]: In some examples, the activity may be capable of being tracked cumulatively. The predicted amount of activity may be based at least in part on a probability that the user will meet a threshold activity level during the at least one interval. The at least one interval may comprise the current interval and/or the predicted amount of activity may be based at least in part on historical activity data of the user…the service provider may receive historical activity data of a user corresponding to a particular time of day. For example, the service provider may receive information indicating that the user burned 50 calories by 11 am on the previous day, or by 11 am on a previous Tuesday. The service provider may then generate a user interface that displays an activity goal of the user (e.g., 1000 calories burned) along with a first indicator that displays that by 11 am of the current day (e.g., today), the user has burned 100 calories or 10% of the goal...[Further], [0034], [0045]: To generate the forecast, a 24-hour day can be divided into 96 15-minute timeslots. For a particular timeslot (e.g., 1:00-1:15 pm) on each of the last seven days, the sampling daemon can determine how many calories were burned during each time slot and generate a score for each timeslot that indicates the maximal expected calorie burn. In some implementations, the temporal forecast can be generated based on an event history window specification. For example, if the client provides a window specification that specifies a 4-hour time period of interest, the temporal forecast will only generate likelihood scores for the 15-minute timeslots that are in the 4-hour time period of interest. For example, if the time period of interest corresponds to 12:00-4:00 pm for each of the last 3 days, then 16 timeslots will be generated during the 4 hour period of interest and a score will be generated for each of the 16 15 minute timeslots. Scores will not be generated for timeslots outside the specified 4 hour time period of interest).
17. Regarding claim 10, Keen discloses the method of claim 1, as disclosed above.
Keen further discloses wherein each time scale of the at least two predetermined time scales relates to a period of time, and wherein the retrieved data relate to one or more preceding time windows spaced from the upcoming time window by a multiple of the period of time to which the selected time scale relates ([0029], [0034], [0046]).
18. Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Keen, in view of Ohnemus et al. US 2014/0135592 (hereinafter, Ohnemus).
19. Regarding claim 11, Keen discloses the method of claim 1, as disclosed above.
Keen further discloses wherein determining the target value for the upcoming time window comprises weighting of the value reached by the parameter over each preceding time window of the retrieved data ([0026], [0064]: the probability graph may illustrate what the user's collected activity data is expected to resemble and/or the maximal likelihood activity data collected for any given moment in time (e.g., the attribute value with the highest probability may be provided). For example, if a user typically exercises on Monday mornings, the probability graph may show a high probability that during the morning hours on Monday, the user may have accumulated a higher than average (or at least higher than during other parts of the day) value for the activity…In some cases, the sampling daemon can generate duration statistics. For example, the sampling daemon can determine a duration associated with an attribute value by comparing an attribute's start event with the attribute's stop event. The time difference between when the start event occurred and when the stop event occurred will be the duration of the event. In some implementations, a client can request and the sampling daemon can return the minimum, maximum, mean, mode, or standard deviation for all durations associated with the specified attribute or attribute value within the specified history window).
Keen does not disclose:
weighting of the value reached by the parameter over each preceding time window of the retrieved data so that a weighting coefficient of the value reached by the parameter over a given time window is greater than or equal to a weighting coefficient of the value reached by the parameter over a time window prior to said given time window.
However, Ohnemus discloses:
“ a weighting module recalls weighting factors from the memory. The weighting factors can be multiplication coefficients that are used to increase or decrease the relative value of each health parameters. A weighting factor is assigned to each health parameter as shown in the formulas herein. The weighting factors are used to control the relative values of the health parameters. Some health parameters are more important than others in the calculation of the users' health score. Accordingly, weighting factors are applied to the health parameters increase or decrease the relative affect each factor has in the calculation of the user's health score. For example, a user's current body weight can be more important than the amount of fitness activity the user engages in. In this example, the body weight parameter would be weighted more heavily by assigning a larger weighting factor to this parameter. At step 750, the weighting module applies the recalled weighting factors to the collected health parameter values to provide weighted health parameter values. The weighting factor can be zero in which case a particular parameter has no impact on the health score. The weighting factor can be a negative value for use in some algorithms” (see, [0068]-[0069])).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Keen to use weighting of the value reached by the parameter over each preceding time window of the retrieved data so that a weighting coefficient of the value reached by the parameter over a given time window is greater than or equal to a weighting coefficient of the value reached by the parameter over a time window prior to said given time window as taught by Ohnemus. The motivation for doing so would have been in order to quantifying and weighting the relative values of the parameters (Ohnemus, [0068]).
20. Claims 12 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Keen, in view of Kerber US 10602964 (hereinafter, Kerber).
21. Regarding claim 12, Keen discloses the method of claim 1, as disclosed above.
Keen further discloses generating a time series including values of the parameter, said time series being updated with each new value reached by said parameter over a given time window ([0025], [0029], [0034]); and
generating at least one predictive model of the value of the parameter for a given time window as a function of a time component characterizing said time window, wherein the target value for the upcoming time window is determined using said at least one predictive model ([0025], [0028]-[0029], [0034]).
Keen does not disclose:
generating by learning at least one predictive model of the value of the parameter for a given time window as a function of a time component characterizing said time window.
However, Kerber discloses:
generating by learning at least one predictive model of the value of the parameter for a given time window as a function of a time component characterizing said time window (column 3, line 6 - column 4, line 7, and column 9, lines 56-67).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Keen to use generating by learning at least one predictive model of the value of the parameter for a given time window as a function of a time component characterizing said time window as taught by Kerber. The motivation for doing so would have been in order to enhance the accuracy and reliability of the target value (Kerber, column 9, lines 56-67).
22. Regarding claim 13, Keen discloses the method of claim 12, as disclosed above.
Keen further discloses wherein the time series is segmented into a plurality of groups of time windows according to a criterion related to the respective time components of said time windows ([0029], [0034], [0046]); and
the predictive model is generated for each group of time windows, and wherein determining the target value for the upcoming time window comprises: applying said criterion to the time component of the upcoming time window in order to determine the corresponding group of time windows ([0029], [0034], [0046]); and
using the predictive model associated with said group of time windows to determine the target value for the upcoming time window ([0025], [0029], [0034]).
Keen does not disclose:
the predictive model is generated by learning for each group of time windows.
However, Kerber discloses:
the predictive model is generated by learning for each group of time windows (column 3, line 6-column 4, line 7, and column 9, lines 56-67).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Keen to use the predictive model is generated by learning for each group of time windows as taught by Kerber. The motivation for doing so would have been in order to enhance the accuracy and reliability of the target value (Kerber, column 9, lines 56-67).
Conclusion
23. Examiner has cited particular columns and line numbers, and/or paragraphs, and/or pages in the references applied to the claims above for the convenience of the applicant. Although the specified citations are representative of the teachings of the art and are applied to specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested from the applicant in preparing responses, to fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner. In the case of amending the claimed invention, Applicant is respectfully requested to indicate the portion(s) of the specification which dictate(s) the structure on for proper interpretation and also to verify and ascertain the metes and bounds of the claimed invention.
24. Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
25. Any inquiry concerning this communication or earlier communications from the examiner should be directed to EYOB HAGOS whose telephone number is (571)272-3508. The examiner can normally be reached on 8:30-5:30PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor Shelby Turner can be reached on 571-272-6334. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Eyob Hagos/
Primary Examiner, Art Unit 2857
Prosecution Insights