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 .
Response to Amendment
The Amendment filed 9/23/2025 has been entered. The Amendments to the claims overcome all Objections and Rejections under 35 U.S.C. 112(b) previously presented. Claims 1, 3-13, and 21-27 remain pending in the application.
Examiner Notes
Examiner cites particular columns and line numbers in the references as applied to the claims below for convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references cited in their 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.
Claim Objections
Claims 1, 4-5, 9, 11, and 21 are objected to because of the following informalities:
In claim 1, line 19, “a first data type” should be corrected to recite “the first data type” if it is referring to the same first data type recited in line 6.
In claim 4, line 3, “a second data type” should be corrected to recite “the second data type” if it is referring to the same second data type recited in claim 1, line 6.
In claim 5, lines 5 and 6, “a second data type” should be corrected to recite “the second data type” if it is referring to the same second data type recited in claim 1, line 6.
In claim 9, line 5, “a second data type” should be corrected to recite “the second data type” if it is referring to the same second data type recited in claim 1, line 6.
In claim 11, line 2, “a second data type” should be corrected to recite “the second data type” if it is referring to the same second data type recited in claim 1, line 6.
In claim 21, line 2, “a second data type” should be corrected to recite “the second data type” if it is referring to the same second data type recited in claim 1, line 6.
Appropriate correction is required.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1, 4-13, and 21 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea of a mental process without significantly more. Claim 1 recites the method including the mental process of obtaining a type of data to be transmitted, wherein the data to be transmitted is data of a first data type or data of a second data type, the data of the first data type and the data of the second data type are obtained from a same sensor and configured to be transmitted from the first operation system to the second operation system, the data of the first data type has a real-time characteristic, the data of the second data type has an accumulated characteristic, and an interval between every two adjacent obtaining of the data of the second data type is longer than an interval between every two adjacent obtaining of the data of the first data type; and determining target data according to the current screen state information of the wearable apparatus and the type of data to be transmitted […]; wherein determining target data according to the current screen state information of the wearable apparatus and the type of data to be transmitted, comprises: determining a current single-batch data of a first data type as the target data when the current screen state information of the wearable apparatus indicates a screen-on state and the type of data to be transmitted is the first data type, wherein the current single-batch data of the first data type is configured to be reported to the second operation system based on a first reporting interval, and the first reporting interval is an interval between every two adjacent reporting of the current single-batch data of the first data type to the second operation system. These functions can reasonably be performed in the human mind, through observation, evaluation, judgement and opinion, with the aid of pen and paper, therefore the claim is reciting a judicial exception.
This judicial exception is not integrated into a practical application because the method is generally linked to a particular technological environment (A data transmission method, performed by a wearable apparatus configured with a first operation system and a second operation system, and a power consumption of the first operation system being lower than a power consumption of the second operation system), with additional elements recited in the steps of the method comprising only insignificant extra-solution activity of necessary data outputting (transmitting the target data from the first operation system of the wearable apparatus to the second operation system of the wearable apparatus).
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. The additional element of transmitting the target data from the first operation system of the wearable apparatus to the second operation system of the wearable apparatus is insignificant extra-solution activity of necessary data outputting (i.e., outputting the “target data” which can be determined mentally – see MPEP 2106.06(g)), and is also well-understood, routine or conventional activity of transmitting data (see MPEP 2106.05(d)). These additional elements of insignificant extra-solution activity and generally linking an exception to a particular technological environment, when considered alone and in combination, are not indicative of integration into a practical application (see MPEP 2106.04). Even when considered in combination, the additional elements do not provide an inventive concept that amounts to significantly more than the recited judicial exceptions (see MPEP 2106.05), thus the claim is not eligible.
Claim 4 is dependent on claim 1 and therefore inherits the same judicial exception recited in claim 1. Claim 4 also recites the steps of detecting whether a batch to be transmitted of a data of a second data type reaches a preset batch when the current state information of the wearable apparatus indicates a screen-off state and the target data is the data of the second data type; and determining the data of the second data type of the preset batch as the target data when the batch to be transmitted of the data of the second type has reached the preset batch. These functions can reasonably be performed in the human mind, through observation, evaluation, judgement and opinion, with the aid of pen and paper, and therefore are reciting a mental process.
The judicial exceptions recited in claims 1 and 4 are not integrated into a practical application because the mental processes are generally linked to a particular technological environment, with the only other additional elements comprising insignificant extra-solution activity. Claim 4 does not recite any additional elements beyond those in claim 1. Even when considering the limitations of claims 1 and 4 in combination, the additional elements of insignificant extra-solution activity and generally linking to a particular technological environment are not indicative of integration into a practical application (see MPEP 2106.04), and the additional elements do not provide an inventive concept that amounts to significantly more than the judicial exception (see MPEP 2106.05). Thus, the claim is not eligible.
Claim 5 is dependent on claim 1 and therefore inherits the same judicial exception recited in claim 1. Claim 5 also recites the steps of when the current screen state information of the wearable apparatus indicates a screen-on state and the type of data to be transmitted is a second data type, detecting the screen state information corresponding to data of a second data type sent last time; and determining a current single-batch data of the second data type as the target data when the screen state information corresponding to the data of the second data type transmitted last time indicates the screen-on state, wherein the current single-batch data of the second data type is configured to be reported to the second operation system based on a second reporting interval, and the second reporting interval is an interval between every two adjacent reporting of the current single-batch data of the second data type to the second operation system. These functions can reasonably be performed in the human mind, through observation, evaluation, judgement and opinion, with the aid of pen and paper, and therefore are reciting a mental process.
The judicial exceptions recited in claims 1 and 5 are not integrated into a practical application because the mental processes are generally linked to a particular technological environment, with the only additional elements comprising insignificant extra-solution activity. Even when considering the limitations of claims 1 and 5 in combination, the additional elements of insignificant extra-solution activity and generally linking to a particular technological environment are not indicative of integration into a practical application (see MPEP 2106.04), and the additional elements do not provide an inventive concept that amounts to significantly more than the judicial exception (see MPEP 2106.05). Thus, the claim is not eligible.
Claim 6 is dependent on claim 5 and therefore inherits the same judicial exceptions recited in claims 1 and 5. Claim 6 also recites the steps of when the screen state information corresponding to the data of the second data type sent last time indicates a screen-off state, detecting an ending time point of the data of the second data type sent last time; and determining the target data according to a current time point and the ending time point of the data of the second data type sent last time. These functions can reasonably be performed in the human mind, through observation, evaluation, judgement and opinion, with the aid of pen and paper, and therefore are reciting a mental process.
The judicial exceptions recited in claims 1, 5 and 6 are not integrated into a practical application because the mental processes are generally linked to a particular technological environment, with the only additional elements comprising insignificant extra-solution activity. Even when considering the limitations of claims 1, 5, and 6 in combination, the additional elements of insignificant extra-solution activity and generally linking to a particular technological environment are not indicative of integration into a practical application (see MPEP 2106.04), and the additional elements do not provide an inventive concept that amounts to significantly more than the judicial exception (see MPEP 2106.05). Thus, the claim is not eligible.
Claim 7 is dependent on claim 1 and therefore inherits the same judicial exception recited in claim 1. Claim 7 also recites the step of obtaining data to be recovered when the first operation system restarting is detected. This function can reasonably be performed in the human mind, through observation, evaluation, judgement and opinion, with the aid of pen and paper, and therefore is reciting a mental process.
The judicial exceptions recited in claims 1 and 7 are not integrated into a practical application because the mental process is generally linked to a particular technological environment, with the only additional elements comprising insignificant extra-solution activity.
Claim 7 recites the additional element of transmitting the data to be recovered from the second operation system to the first operation system which is well-understood, routine or conventional activity of transmitting data, and is therefore insignificant extra-solution activity. These additional elements of insignificant extra-solution activity are not indicative of integration into a practical application. Even when considered in combination with the additional elements of claim 1, the additional elements of insignificant extra-solution activity and generally linking to a particular technological environment are not indicative of integration into a practical application (see MPEP 2106.04), and the additional elements do not provide an inventive concept that amounts to significantly more than the judicial exception (see MPEP 2106.05). Thus, the claim is not eligible.
Claim 8 is dependent on claim 7 and therefore inherits the same judicial exception recited in claim 1. The judicial exceptions recited in claims 1 and 7 are not integrated into a practical application because the mental process is generally linked to a particular technological environment, with the only additional elements comprising insignificant extra-solution activity.
Claim 8 recites the limitation wherein the data to be recovered is a data that the first operation system has reported to the second operation system which is merely specifying the data obtained in the mental process of claim 7, and can still be considered part of the mental process. At best, this limitation is specifying data gathered for the mental process of claim 7, and can be considered an additional element of insignificant extra-solution activity, specifically mere data gathering. This additional element of insignificant extra-solution activity is not indicative of integration into a practical application. Even when considered in combination with the additional elements of claims 1 and 7, the additional elements of insignificant extra-solution activity and generally linking to a particular technological environment are not indicative of integration into a practical application (see MPEP 2106.04), and the additional elements do not provide an inventive concept that amounts to significantly more than the judicial exception (see MPEP 2106.05). Thus, the claim is not eligible.
Claim 9 is dependent on claim 7, and therefore inherits the same judicial exception recited in claim 1. Claim 9 also recites the step of determining the target data according to the data to be recovered and a newly detected data of a second data type. This function can reasonably be performed in the human mind, through observation, evaluation, judgement and opinion, with the aid of pen and paper, and therefore is reciting a mental process.
The judicial exceptions recited in claims 1, 7, and 9 are not integrated into a practical application because the mental processes are generally linked to a particular technological environment, with the only additional elements comprising insignificant extra-solution activity. Claim 9 does not recite any additional elements beyond those recited in claims 1 and 7; therefore, they are not sufficient to amount to significantly more than the judicial exception. Thus, the claim is not eligible.
Claim 10 is dependent on claim 9, and therefore inherits the same judicial exceptions recited in claims 1 and 9. Claim 10 also recites the steps of setting a preset restart identification when the first operation system has received the data to be recovered; and determining data of the second data type according to the data to be recovered and clearing the preset restart identification when the preset restart identification is detected. These functions can reasonably be performed in the human mind, through observation, evaluation, judgement and opinion, with the aid of pen and paper, and therefore are reciting a mental process.
The judicial exceptions recited in claims 1, 9 and 10 are not integrated into a practical application because the mental processes are generally linked to a particular technological environment, with the only additional elements comprising insignificant extra-solution activity. Claim 10 does not recite any additional elements beyond those recited in claims 1, 7 and 9; therefore, they are not sufficient to amount to significantly more than the judicial exception. Thus, the claim is not eligible.
Claim 11 is dependent on claim 1 and therefore inherits the same judicial exception recited in claim 1. The judicial exception recited in claim 1 is not integrated into a practical application because the mental process is generally linked to a particular technological environment, with the only additional elements comprising insignificant extra-solution activity.
Claim 11 recites the limitation wherein the type of data to be transmitted comprises a second data type and wherein the first data type is a data collected during a first collecting period, the second data type is a data collected during a second collecting period, and the second collecting period is longer than the first collecting period, which is merely describing the data obtained in the mental process of claim 1 (“obtaining a type of data to be transmitted”), and a person is still capable of mentally obtaining this data. At best, this limitation can be considered insignificant extra-solution activity of mere data gathering. These additional elements of insignificant extra-solution activity are not indicative of integration into a practical application. Even when considered in combination with the additional elements of claim 1, the additional elements of insignificant extra-solution activity and generally linking to a particular technological environment are not indicative of integration into a practical application (see MPEP 2106.04), and the additional elements do not provide an inventive concept that amounts to significantly more than the judicial exception (see MPEP 2106.05). Thus, the claim is not eligible.
Claim 12 is dependent on claim 4 and therefore inherits the same judicial exceptions recited in claims 1 and 4. The judicial exceptions recited in claims 1 and 4 are not integrated into a practical application because the mental process is generally linked to a particular technological environment, with the only additional elements comprising insignificant extra-solution activity.
Claim 12 recites the limitation of wherein the first data type is a real-time data type, the second data type is a detail data type, the target data is at least one of heart rate, altitude, steps, distance, speed, calories, step rate, which is describing data obtained or determined in the mental processes of claim 1. A person is still mentally capable of obtaining and determining this recited data, so this limitation can still be considered part of the mental process. At best, this limitation is considered insignificant extra-solution activity of mere data gathering. This additional element of insignificant extra-solution activity is not indicative of integration into a practical application. Even when considered in combination with the additional elements of claims 1 and 4, the additional elements of insignificant extra-solution activity and generally linking to a particular technological environment are not indicative of integration into a practical application (see MPEP 2106.04), and the additional elements do not provide an inventive concept that amounts to significantly more than the judicial exception (see MPEP 2106.05). Thus, the claim is not eligible.
Claim 13 is dependent on claim 1 and therefore inherits the same judicial exception recited in claim 1. The judicial exception recited in claim 1 is not integrated into a practical application because the mental process is generally linked to a particular technological environment, with the only additional elements comprising insignificant extra-solution activity.
Claim 13 recites the additional element of wherein the first operation system is supported by a first chip, the second operation system is supported by a second chip, and a power consumption of the first chip is lower than a power consumption of the second chip, which is generally linking the mental process to a particular technological environment. This additional element of generally linking to a particular technological environment is not indicative of integration into a practical application. Even when considered in combination with the additional elements of claim 1, the additional elements of insignificant extra-solution activity and generally linking to a particular technological environment are not indicative of integration into a practical application (see MPEP 2106.04), and the additional elements do not provide an inventive concept that amounts to significantly more than the judicial exception (see MPEP 2106.05). Thus, the claim is not eligible.
Claim 21 is dependent on claim 1 and therefore inherits the same judicial exception recited in claim 1. The judicial exception recited in claim 1 is not integrated into a practical application because the mental process is generally linked to a particular technological environment, with the only additional elements comprising insignificant extra-solution activity.
Claim 21 recites the limitation wherein the type of data to be transmitted comprises a second data type, and data of the second data type is determined based on data of the first data type which is merely describing the data obtained in the mental process of claim 1 (“obtaining a type of data to be transmitted”), and a person is still capable of mentally obtaining this data. At best, this limitation can be considered insignificant extra-solution activity of mere data gathering. This additional element of mere data gathering is not indicative of integration into a practical application. Even when considered in combination with the additional elements of claim 1, the additional elements of insignificant extra-solution activity and generally linking to a particular technological environment are not indicative of integration into a practical application (see MPEP 2106.04), and the additional elements do not provide an inventive concept that amounts to significantly more than the judicial exception (see MPEP 2106.05). Thus, the claim is not eligible.
Claims 23-24 and 26-27 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea of a mental process without significantly more. Claim 23 recites the method including the mental process of obtaining a type of data to be transmitted; wherein the data to be transmitted is a first data type or data of a second data type, and data of the second data type the data of the first data type and the data of the second data type are obtained from a same sensor and configured to be transmitted from the first operation system to the second operation system, the data of the first data type has a real-time characteristic, the data of the second data type has an accumulated characteristic, and an interval between every two adjacent obtaining of the data of the second data type is longer than an interval between every two adjacent obtaining of the data of the first data type; detecting current screen state information of the wearable apparatus; and determining target data according to the current screen state information of the wearable apparatus and the type of data to be transmitted. These functions can reasonably be performed in the human mind, through observation, evaluation, judgement and opinion, with the aid of pen and paper, therefore the claim is reciting a judicial exception.
This judicial exception is not integrated into a practical application because the method is generally linked to a particular technological environment (A data transmission method, performed by a wearable apparatus configured with a first operation system and a second operation system, and a power consumption of the first operation system being lower than a power consumption of the second operation system; the method comprising:), with additional elements recited in the steps of the method comprising insignificant extra-solution activity of necessary data outputting (and transmitting the target data from the first operation system of the wearable apparatus to the second operation system of the wearable apparatus).
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. The additional element of transmitting the target data from the first operation system of the wearable apparatus to the second operation system of the wearable apparatus is insignificant extra-solution activity of necessary data outputting (i.e., outputting the “target data” that can be determined mentally – see MPEP 2106.06(g)), and is also well-understood, routine or conventional activity of transmitting data (see MPEP 2106.05(d)). These additional elements of insignificant extra-solution activity and generally linking an exception to a particular technological environment, when considered alone and in combination, are not indicative of integration into a practical application (see MPEP 2106.04). Even when considered in combination, the additional elements do not provide an inventive concept that amounts to significantly more than the recited judicial exceptions (see MPEP 2106.05), thus the claim is not eligible.
Claim 24 depends from claim 23, and therefore inherits the same judicial exception recited in claim 23. Claim 24 also recites wherein the determining the target data according to the current screen state information of the wearable apparatus and the type of data to be transmitted, comprises: determining a single-batch data of the first data type as the target data in response to the current screen state information of the wearable apparatus indicating a screen-on state and the type of data to be transmitted being the first data type, wherein the single-batch data of the first data type is data reported to the second operation system at a first reporting interval. This function can reasonably be performed in the human mind, through observation, evaluation, judgement and opinion, with the aid of pen and paper, and is therefore reciting a mental process.
The judicial exceptions recited in claims 23 and 24 are not integrated into a practical application because the mental processes are generally linked to a particular technological environment, with the only other additional elements comprising insignificant extra-solution activity. Claim 24 does not recite any additional elements beyond those recited in claim 23; therefore, they are not sufficient to amount to significantly more than the judicial exception. Thus, the claim is not eligible.
Claim 26 depends from claim 23, and therefore inherits the same judicial exception recited in claim 23. The judicial exception recited in claim 23 is not integrated into a practical application because the mental process is generally linked to a particular technological environment, with the only additional elements comprising insignificant extra-solution activity.
Claim 26 recites the limitation wherein the first data type is a real-time data type, the second data type is a detail data type, the target data is at least one of heart rate, altitude, steps, distance, speed, calories, step rate, which is merely describing the data obtained in the mental process of claim 23 (“obtaining a type of data to be transmitted”), and a person is still capable of mentally obtaining this data. At best, this limitation can be considered insignificant extra-solution activity of mere data gathering. This additional element of mere data gathering is not indicative of integration into a practical application. Even when considered in combination with the additional elements of claim 23, the additional elements of insignificant extra-solution activity and generally linking to a particular technological environment are not indicative of integration into a practical application (see MPEP 2106.04), and the additional elements do not provide an inventive concept that amounts to significantly more than the judicial exception (see MPEP 2106.05). Thus, the claim is not eligible.
Claim 27 depends from claim 23, and therefore inherits the same judicial exception recited in claim 23. Claim 27 also recites detecting the screen state information corresponding to data of the second data type sent last time in response to the current screen state information of the wearable apparatus indicating a screen-on state and the type of data to be transmitted being the second data type; and determining a single-batch data of the second data type as the target data in response to the screen state information corresponding to the data of the second data type transmitted last time indicating the screen-on state, wherein the single-batch data of the second data type is data reported to the second operation system after a second reporting interval. These functions can reasonably be performed in the human mind, through observation, evaluation, judgement and opinion, with the aid of pen and paper, and is therefore reciting a mental process.
The judicial exceptions recited in claims 23 and 27 are not integrated into a practical application because the mental processes are generally linked to a particular technological environment, with the only additional elements comprising insignificant extra-solution activity. Claim 27 does not recite any additional elements beyond those recite in claim 23. Even when considering the limitations of claim 27 in combination with the limitations of claim 23, the additional elements of insignificant extra-solution activity and generally linking to a particular technological environment are not indicative of integration into a practical application (see MPEP 2106.04), and the additional elements do not provide an inventive concept that amounts to significantly more than the judicial exception (see MPEP 2106.05). Thus, the claim is not eligible.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 3-4, 7-13, and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Zhong (U.S. Pub. No. 2022/0137232) in view of Kupermann et al. (U.S. Pub. No. 2017/0171645), hereinafter Kupermann, Hasegawa (U.S. Pub. No. 2013/0165181), and Weast et al. (U.S. Pub. No. 2013/0191034), hereinafter Weast.
Regarding claim 1, Zhong teaches A data transmission method, performed by a wearable apparatus ([0096] – “FIG. 8A and FIG. 8B are a schematic flowchart of an exercise track recording method according to another embodiment of this application”; [0104] – “The electronic device in this embodiment of this application may be […] a wearable electronic device”) […]; the method comprising:
obtaining a type of data to be transmitted, wherein the data to be transmitted is data of a first data type or data of a second data type (FIG. 8B, S204; [0259] – “S204: An MCU receives the GPS data sent by the GPS chip”. The type of data transmitted in the exemplary embodiment detailed for FIG. 8 is GPS data. The MCU may receive other types of data as well: [0116] – “The MCU is not limited to being connected to the GPS chip. In a specific implementation, the MCU may be further connected to various sensors, such as the gyroscope sensor 180B, the acceleration sensor 180C, and the optical proximity sensor 180E, to process data from various sensor devices.”) […]; and
determining target data according to current screen state information of the wearable apparatus and the type of data to be transmitted (FIG. 8B steps 204, 205, 206 and 207; [0260] – “Specifically, when the exercise track is recorded in the second mode, the GPS chip is connected to the MCU, and sends the GPS data to the MCU. The MCU may process the GPS data by using the second positioning algorithm. […] The MCU may store a plurality of pieces of processed GPS data.” The system is in a “second mode”, or a low-power mode, when the display is off. At step 204, in the second mode, the MCU determines the “target data” by processing the GPS data as described in [0256]-[0257]. [0261] – “S205: Determine whether the stored processed GPS data reaches a threshold B, and perform S208 if the stored processed GPS data reaches the threshold B.”; [0264] – “S206: Determine, based on the stored processed GPS data, whether a wake-up condition of the application processor is met, and perform S208 if the wake-up condition of the application processor is met.”; [0268] – “S207: Determine whether the display is on, and perform S208 if the display is on.” In steps 205, 206, and 207, the MCU further checks conditions to determine if the target data (processed GPS data) should be sent to the application processor.), and transmitting the target data from the first operation system of the wearable apparatus to the second operation system of the wearable apparatus (FIG. 8B, S208; [0270] – “The MCU sends the processed GPS data of the at least two location points to the application processor.”);
wherein determining target data according to the current screen state information of the wearable apparatus and the type of data to be transmitted, comprises:
determining a current single-batch data of a first data type as the target data when the current screen state information of the wearable apparatus indicates a screen-on state and the type of data to be transmitted is the first data type ([0280] – “In the second mode, the MCU may receive the GPS data sent by the GPS chip, process the GPS data, and store a plurality of pieces of processed GPS data. When a switching condition is met, the MCU sends the stored plurality of pieces of processed GPS data to the application processor in batches, so that the application processor enters a sleep state in the second mode.”; [0206] – “The condition for switching from the low power consumption mode to the normal mode may include any one of the following: […] 3. A display 192 of the electronic device 100 is on.”) […].
Zhong fails to expressly teach the wearable apparatus configured with a first operation system and a second operation system, and a power consumption of the first operation system being lower than a power consumption of the second operation system; […] the data of the first data type and the data of the second data type are obtained from a same sensor and configured to be transmitted from the first operation system to the second operation system, the data of the first data type has a real-time characteristic, the data of the second data type has an accumulated characteristic, and an interval between every two adjacent obtaining of the data of the second data type is longer than an interval between every two adjacent obtaining of the data of the first data type; and […] wherein the current single-batch data of the first data type is configured to be reported to the second operation system based on a first reporting interval, and the first reporting interval is an interval between every two adjacent reporting of the current single-batch data of the first data type to the second operation system.
However, Kupermann teaches a wearable apparatus ([0028] – “device 203 (e.g., smart watch) includes a sensing architecture that uses a VM and a HW IP block ( or HW sensor hub).”) configured with a first operation system and a second operation system ([0030] – “FIG. 3 illustrates computer system 300 (or a sensing system) with a sensing architecture formed from a combination of a VM and HW IP block”; [0031] – “computer system 300 comprises Processor 301, Resource Optimized Sensor Hub 302 (or HW IP block 302) […] Processor 301 comprises Virtualization Environment 307. In some embodiments, Virtualization Environment 307 comprises: Operating System Software (OS SW) stack 308”; [0035] – “HW IP block 302 comprises two components. In some embodiments, the first component is a real-time operating system”), and a power consumption of the first operation system being lower than a power consumption of the second operation system ([0012]-[0013] – “Various embodiments described here provide a low power sensing scheme by splitting the sensing functionality between a virtual machine (VM) and a small dedicated hardware (HW) Intellectual Property (IP) block. In some embodiments, the VM includes sufficient memory and compute capabilities, while the dedicated small HW IP block provides cost effective sensing solution for low power use cases. Some embodiments enable keeping all the sensing usage under a black box sensor hub interface and maintain low power budget for selected use cases (e.g., wake detect, step counting, etc.) using quarter of the gate count of a full featured sensor hub dedicated HW block (e.g., SH 102 of FIG. 1). A software only VM solution may not meet the power requirements of a small computing device”; [0034] – “HW IP block 302 is optimized for lower power”; [0049] – “when Processor 301 is in low power mode (e.g., sleep state), HW IP block 302 may continue to operate (because it is designed to operate at a low power state)”; FIGS. 5A-5C); […] the data of the first data type and the data of the second data type are obtained from a same sensor and configured to be transmitted from the first operation system to the second operation system ([0035]-[0036] – “HW IP block 302 includes firmware (FW) that implements sensor algorithms for the virtual sensors and calibration of sensors. […] An example of a virtual sensor is a step counter which consumes data from an accelerometer sensor (which is physical sensor driver) and produces step counter as output.”; [0038] – “the first set of one or more sensors 305 includes one or more of: […] Accelerometer”; [0044] – “the sensor algorithms in VM 310 can request AON SH 302 to buffer sensor data and send it up to VM 310 (e.g., accelerometer data sent once in 5 seconds, etc.).”; [0049] – “HW IP block 302 is to wake up VM 310 when an event is detected by the one or more sensors of the first set 305 or when the data collected from the one or more sensors of the first set 305 is to be delivered to Processor 301”; [0056] – “Logic 405 (e.g., a Finite State Machine) is a low power logic which is operable to perform basic functions such as to monitor which sensors of first set of one or more sensors 305 are active and operating, collect data sensed by first set of one or more sensors 305, in some cases analyze the collected data, initiate communication with VM 310, and receive instructions from VM 310. In some embodiments, Logic 405 executes a real-time operating system (RTOS).”; [0058] – “Logic 405 is capable of communicating with derived or virtual sensors. In some embodiments, Logic 405 is operable to perform various algorithms to process sensor data.”; [0072] – “VM 310 instructs HW IP block 302 to transmit the sensor data it has collected. In some embodiments, VM 310 instructs HW IP block 302 to transmit the sensor data collected in real-time to VM 310. For example, sensor data is transmitted to VM 310 as it is collected. In some embodiments, VM 310 instructs HW IP block 302 to transmit the sensor data stored in Memory 406.” Data to be transmitted from the HW IP block 302 with the RTOS may comprise accelerometer data (“data of the first data type”), as well as derived step counter data (“data of the second data type”) obtained from the accelerometer data, and thus also obtained from the accelerometer (the “same sensor”).), the data of the first data type has a real-time characteristic ([0057] – “RTOS is capable of processing sensor data from the first set 305 in real-time”; [0072] – “to transmit the sensor data collected in real-time to VM 310”).
Zhong and Kupermann are considered to be analogous art to the claimed invention because they are in the same field as the invention of reducing power consumption within wearable devices. Zhong teaches an MCU of the wearable device operates to collect data and process data from one or more sensors while the application processor is in a sleep state and then report the data to the application processor when a condition is met in order to reduce power consumption (see [0005], [0007] and [0116]). Kupermann similarly teaches the HW IP block 302 (see [0034] and [0056]) of the wearable device, on which the first operation system is implemented, collects and processes sensor data from a plurality of sensors 305 while processor 301, on which the second operation system is implemented, is in a sleep state and reports the sensor data to the processor 301 when a condition is met (see [0032]-[0033], [0049], and [0057]-[0058]). Therefore, it would have been obvious to one of ordinary skill in the art that the MCU and application processor of Zhong could be substituted for the HW IP block 302 and processor 301 of Kupermann since they are both capable of performing analogous functions in a wearable device. Further, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method performed by the wearable device taught by Zhong to include two operation systems as taught by Kupermann, where a first operation system has a lower power consumption than a second operation system, and the data to be transmitted which is obtained by the first operation system comprises data of a first type and a second type obtained from a same sensor, where the data of the first type has a real-time characteristic. The hardware and software structure of Kupermann including two operation systems provides a cost effective low power sensing solution for wearable devices without sacrificing compute capabilities and sufficient memory (Kupermann: [0012]-[0015]). Further, the first, lower power, operation system of Kupermann enables servicing real-time applications without buffering delays (Kupermann: [0035] and [0056]). Lastly, Zhong suggests the MCU collecting and processing data from an acceleration sensor and further suggests a quantity of steps obtained using data collected from the acceleration sensor (Zhong: [0116] and [0174]), analogous to the first data type and second data type taught by Kupermann.
The combination of Zhong in view of Kupermann fails to expressly teach the data of the second data type has an accumulated characteristic, and an interval between every two adjacent obtaining of the data of the second data type is longer than an interval between every two adjacent obtaining of the data of the first data type; and […] wherein the current single-batch data of the first data type is configured to be reported to the second operation system based on a first reporting interval, and the first reporting interval is an interval between every two adjacent reporting of the current single-batch data of the first data type to the second operation system.
However, Hasegawa teaches wherein the current single-batch data of the first data type is configured to be reported to the second operation system based on a first reporting interval, and the first reporting interval is an interval between every two adjacent reporting of the current single-batch data of the first data type to the second operation system ([0056] – “If the real-time transmission of the sensor data is desired for the application that uses the sensor data and is executed in the foreground, 0 (seconds) is described in the item 404 as a time interval to transmit the sensor data in order not to buffer the sensor data. If the real-time transmission of the sensor data is not desired for the application that uses the sensor data and is executed in the foreground, 2 (seconds) is described in the item 404 as the time interval to transmit the sensor data in order to buffer the sensor data.”; [0088] – “The sensor data buffer managing unit 304 transmits the sensor data to the microcomputer controller 226 "if the minimum transmission interval has elapsed after the previous transmission and the sensor data satisfies the conditions for the values of the sensor data" or "if the maximum transmission interval has elapsed after the previous transmission". In the present embodiment, if the screen is in the ON state, the maximum transmission interval is set to 0 milliseconds, and the sensor data buffer managing unit 304 transmits the sensor data to the microcomputer controller 226 without causing the sensor data to be buffered.”).
Hasegawa is considered to be analogous art to the claimed invention because it is reasonably pertinent to the problems faced by the inventor of reducing power consumption of the wearable device and ensuring a real-time characteristic of data. Hasegawa teaches a lower-power microcomputer 226, 300 collecting sensor data from a plurality of sensors 218 to 220 and transmitting the collected sensor data when the sensor data meets a condition (see [0004]-[0005], [0044], and [0048]) to a higher-power processor CPU 201 which controls the entire device and execution of application programs (see [0034] and [0045]). Therefore, it would have been obvious to one of ordinary skill in the art to have modified the teachings of Zhong in view of Kupermann such that when the current screen state information indicates a screen-on state, the data of the first type is reported to the second operation system at a first reporting interval as taught by Hasegawa. Reporting collected sensor data at different frequencies based on the current state of the device balances the advantages of reducing power consumption by allowing the CPU to enter a sleep state and ensuring real-time transmission of the sensor data when it is desired (Hasegawa: [0121]-[0122]).
The combination of Zhong in view of Kupermann and Hasegawa fails to expressly teach the data of the second data type has an accumulated characteristic, and an interval between every two adjacent obtaining of the data of the second data type is longer than an interval between every two adjacent obtaining of the data of the first data type.
However, Weast teaches the data of the second data type has an accumulated characteristic, and an interval between every two adjacent obtaining of the data of the second data type is longer than an interval between every two adjacent obtaining of the data of the first data type ([0008] – “quantify steps taken by the user based upon the motion data, such as by detecting arm swings peaks and bounce peaks in the motion data. […] motion data is obtained from an accelerometer. Accelerometer magnitude vectors may be obtained for a time frame and values, such as an average value from magnitude vectors for the time frame may be calculated. The average value (or any other value) may be utilized to determine whether magnitude vectors for the time frame meet an acceleration threshold to qualify for use in calculating step counts for the respective time frame.”; [0066]-[0067] – “a plurality of samples from one or more sensors may be obtained during a first time period. In one embodiment, at least one sensor comprises an accelerometer. […] utilizing a 25 Hz sampling rate to obtain accelerometer data from an appendage-worn (e.g., wrist-worn) portable device may adequately obtain data, such as for example, step counts while obtaining acceptable battery life […] the first time period may be 1 second. In one embodiment, 64 samples of data may be obtained during the first time period”; [0068] – “The collected data may be analyzed or processed, which may occur upon collection, at predefined intervals”; [0069]-[0070] – “Samples (or data relating to the received samples) from the first time period may be placed in a buffer (see, e.g., block 404) […] In one embodiment, about 128 samples may be placed in a first buffer In certain embodiments, the buffer may be about twice (e.g., 2x) the first time period.”; [0075]-[0076] – “systems and methods may be implemented to quantify steps based upon the data (or a portion thereof). In one embodiment, block 408 may be implemented to process at least a portion of the data. Analysis (and/or other statistical measures) may be performed on the entire buffer or at least one of the sub-buffers […] data (such as the data within the buffer or a sub-buffer) may be compared with a threshold as part of block 408 or another process (see, e.g., decision 410). […] Further logic may be utilized to determine if the sub-buffers have valid data (e.g., data that met the threshold), and if so, that data is utilized in further step count determinations.”; [0091] – “Block 412f may be implemented to identify a subgroup ( or sub-groups) of peaks within the frequency data to utilize in the determinations of step quantification. […] a specific peak ( or peaks) within the data (such as for example, data obtained within the first buffer and/or data obtained during first time frame) may be utilized.” To determine step counts (data of a “second data type) from accelerometer data (data of a “first data type”), the accelerometer data must be accumulated (a plurality of accelerometer samples must be obtained before steps can be identified within the accelerometer data), i.e., the step count has an “accumulated characteristic”. Further, since the step data requires analysis over a plurality of accelerometer samples (e.g., for the buffer comprising samples from the “first time period” disclosed in [0066]-[0070]), the interval between quantifying the step data is necessarily longer than the interval between obtaining each accelerometer sample (e.g., the sampling rate disclosed in [0067]).).
Weast is considered to be analogous art to the claimed invention because it is reasonably pertinent to the problem faced by the inventor of obtaining types of data from sensors in a wearable apparatus. Therefore, it would have been obvious to have modified the data of the first data type, e.g., accelerometer data, and the data of the second data type, e.g., a step count derived from accelerometer data, as taught by Zhong in view of Kupermann such that the data of the second data type has an accumulated characteristic, and an interval between every two adjacent obtaining of the data of the second data type is longer than an interval between every two adjacent obtaining of the data of the first data type as taught by Weast. The methods of quantifying steps from obtained accelerometer data as taught by Weast provide the benefit of a low power, high-fidelity step counter in a wearable apparatus which improves battery life and reduces false positives in step counting by accumulating accelerometer data for analysis (Weast: [0056] and [0061]).
Regarding claim 3, the combination of Zhong in view of Kupermann, Hasegawa, and Weast teaches the data transmission method as claimed in claim 1. Zhong teaches the method further comprising:
not transmitting data of the first data type when the current screen state information of the wearable apparatus indicates a screen-off state and the type of data to be transmitted is the first data type (FIG. 8B, S205, S206 and S207; [0261] – “S205: Determine whether the stored processed GPS data reaches a threshold B, and perform S208 if the stored processed GPS data reaches the threshold B.”; [0264] – “S206: Determine, based on the stored processed GPS data, whether a wake-up condition of the application processor is met, and perform S208 if the wake-up condition of the application processor is met.”; [0268] – “S207: Determine whether the display is on, and perform S208 if the display is on.” If the display is not on (evaluated at S207), and a condition based on the GPS data (a first data type) is not met (evaluated at S205 and S206), the data is not sent to the application processor (S208 is not performed).).
Regarding claim 4, the combination of Zhong in view of Kupermann, Hasegawa, and Weast teaches the data transmission method as claimed in claim 1. Zhong further teaches wherein the determining target data according to current screen state information of the wearable apparatus and the type of data to be transmitted, comprises:
detecting whether a batch to be transmitted of a data of a second data type reaches a preset batch when the current state information of the wearable apparatus indicates a screen-off state and the target data is the data of the second data type ([0010] – “when the electronic device is screen-off, the electronic device may receive, by using the MCU, the plurality of pieces of GPS data reported by the GPS chip, and the MCU may process the plurality of pieces of GPS data by using the first positioning algorithm, and then report the plurality of pieces of processed GPS data to the application processor in batches.”; Fig. 8B, S205; [0261] – “S205: Determine whether the stored processed GPS data reaches a threshold B, and perform S208 if the stored processed GPS data reaches the threshold B.”; [0208] – “that the stored GPS data reaches a threshold B may be that memory for storing the GPS data reaches the threshold B, where B may be but is not limited to 10 kb, 20 kb, 25 kb, or the like.” The condition for transmitting data from the MCU, operating in low-power mode while the screen is off, may be based on the accumulated data reaching a threshold size (“preset batch”). [0116] – “The MCU is not limited to being connected to the GPS chip. In a specific implementation, the MCU may be further connected to various sensors, such as the gyroscope sensor 180B, the acceleration sensor 180C, and the optical proximity sensor 180E, to process data from various sensor devices.” Although the method of operation is described only in terms of GPS data, the method can be applied to other data types.); and
determining the data of the second data type of the preset batch as the target data when the batch to be transmitted of the data of the second type has reached the preset batch (Fig. 8B, S205 and S208; [0261] – “S205: Determine whether the stored processed GPS data reaches a threshold B, and perform S208 if the stored processed GPS data reaches the threshold B.”; [0208] – “that the stored GPS data reaches a threshold B may be that memory for storing the GPS data reaches the threshold B, where B may be but is not limited to 10 kb, 20 kb, 25 kb, or the like.”; [0270] – “S208: The MCU sends the processed GPS data of the at least two location points to the application processor.”).
Regarding claim 7, the combination of Zhong in view of Kupermann, Hasegawa, and Weast teaches the data transmission method as claimed in claim 1. Zhong teaches the method further comprising:
obtaining data to be recovered when the first operation system restarting is detected ([0209] – “the application processor is in a sleep state in the low power consumption mode. If a user specifies that voice broadcast is performed when running reaches an integral kilometer during an exercise ( content of voice broadcast may be, for example, a current running distance, running duration, and running pace for the latest one kilometer distance), the application processor in the sleep state cannot learn of current exercise data of the user”; [0211]-[0212] – “If the MCU triggers the electronic device 100 to switch from the normal mode to the low power consumption mode, when the electronic device 100 switches from the normal mode to the low power consumption mode for the first time, the application processor may send the next-time wake-up condition to the MCU when the display 192 of the electronic device 100 is off. When the electronic device 100 switches from the normal mode to the low power consumption mode for a non-first time, the application processor may send the next-time wake-up condition to the MCU when the GPS data stored by the electronic device 100 in the low power consumption mode has been sent in batches. The next-time wake-up condition may be determined based on a voice broadcast condition set by the user.”; [0215] – “When the application processor switches from the normal mode to the low power consumption mode for a non-first time, it is assumed that a current exercise distance is 3.2 kilometers, and a first distance is 0.1 kilometer, the application processor may send to the MCU, the next-time wake-up condition that is continuously keeping exercise for 0.7 kilometer.”. The MCU triggers the device to switch to the low power mode in which the GPS data is first processed by the MCU before being transmitted to the application processor. This can be interpretated as operations performed by the MCU “restarting”, or the operation system being run on the MCU restarting. In response to the MCU restarting operations, the application processor (performing the second operation system as described with respect to claim 1) obtains a wake-up condition to send to the MCU, wherein the wake-up condition can indicate a distance or time for which GPS data should be collected by the MCU before the MCU wakes the application processor and transmits the collected data to the application processor, i.e., the application processor “recovers” the data collected by the MCU as specified by the wake-up condition while it was in a sleep state.); and
transmitting the data to be recovered from the second operation system to the first operation system ([0211] – “the application processor may send the next-time wake-up condition to the MCU”. The next-time wake-up condition (“data to be recovered”) is sent to the MCU from the application processor.).
Regarding claim 8, the combination of Zhong in view of Kupermann, Hasegawa, and Weast teaches the data transmission method as claimed in claim 7. Zhong further teaches wherein the data to be recovered is a data that the first operation system has reported to the second operation system ([0175] – “The accumulated exercise distance displayed in the accumulated exercise information display area 304 may be obtained based on GPS data obtained by a GPS chip 230.”; [0211] – “When the electronic device 100 switches from the normal mode to the low power consumption mode for a non-first time, the application processor may send the next-time wake-up condition to the MCU when the GPS data stored by the electronic device 100 in the low power consumption mode has been sent in batches.”; [0215] – “When the application processor switches from the normal mode to the low power consumption mode for a non-first time, it is assumed that a current exercise distance is 3.2 kilometers, and a first distance is 0.1 kilometer, the application processor may send to the MCU, the next-time wake-up condition that is continuously keeping exercise for 0.7 kilometer.” When the electronic device enters low-power mode for a non-first time, the MCU has previously sent GPS data indicating distance to the application processor.).
Regarding claim 9, the combination of Zhong in view of Kupermann, Hasegawa, and Weast teaches the data transmission method as claimed in claim 7. Zhong further teaches wherein the transmitting the data to be recovered from the second operation system to the first operation system, comprises:
determining the target data according to the data to be recovered and a newly detected data ([0215] – “When the application processor switches from the normal mode to the low power consumption mode for a non-first time, it is assumed that a current exercise distance is 3.2 kilometers, and a first distance is 0.1 kilometer, the application processor may send to the MCU, the next-time wake-up condition that is continuously keeping exercise for 0.7 kilometer. When the MCU in the low power consumption mode estimates that an exercise distance reaches 0.7 kilometer based on the GPS data sent by the GPS chip, the MCU switches to the normal mode and wakes up the application processor. In this case, the application processor may be woken up before an exercise distance reaches 4 kilometers, to perform voice broadcast in time.”; [0259] – “S204: An MCU receives the GPS data sent by the GPS chip, processes the GPS data by using a second positioning algorithm, and stores processed GPS data of at least two location points.”; [0264] – “S206: Determine, based on the stored processed GPS data, whether a wake-up condition of the application processor is met, and perform S208 if the wake-up condition of the application processor is met.”; [0270]-[0271] – “S208: The MCU sends the processed GPS data of the at least two location points to the application processor. In this case, the application processor of the electronic device is woken up and receives the processed GPS data of the at least two location points that is sent by the MCU”. The target data (sent in S208), is determined based on the wake-up condition received from the application processor (the “data to be recovered”) and an estimated distance determined based on the newly collected and stored GPS data.) of a second data type ([0116] – “The MCU is not limited to being connected to the GPS chip. In a specific implementation, the MCU may be further connected to various sensors, such as the gyroscope sensor 180B, the acceleration sensor 180C, and the optical proximity sensor 180E, to process data from various sensor devices.” Therefore, although the method of operation is described in terms of GPS data, the method can be applied to other data types.).
Regarding claim 10, the combination of Zhong in view of Kupermann, Hasegawa, and Weast teaches the data transmission method as claimed in claim 9. Zhong teaches the method further comprising:
setting a preset restart identification when the first operation system has received the data to be recovered ([0225] – “It is assumed that the user specifies that voice broadcast is performed at the fixed time interval (for example, 5 minutes) during the exercise. […] When the application processor switches from the normal mode to the low power consumption mode for a non-first time, the application processor may send, to the MCU, the next-time wake-up condition that is continuously keeping exercise for 1 minute and 55 seconds. The MCU in the low power consumption mode triggers a timer, where duration of the timer is 1 minute and 55 seconds.”. In response to receiving the next-time wake-up condition (the “data to be recovered”), the MCU sets a timer (“preset restart identification”) that indicates when data should be sent to the application processor and normal mode should restart.”); and
determining data of the second data type according to the data to be recovered and clearing the preset restart identification, when the preset restart identification is detected ([0225]-[0226] – “the application processor may send, to the MCU, the next-time wake-up condition that is continuously keeping exercise for 1 minute and 55 seconds. The MCU in the low power consumption mode triggers a timer, where duration of the timer is 1 minute and 55 seconds. After the timer expires, the MCU triggers the electronic device to switch from the low power consumption mode to the normal mode, so that the application processor may be woken up in advance to perform voice broadcast in time based on exercise duration of 20 minutes. […] In a specific implementation, the application processor may send an actual wake-up distance, an actual wake-up moment, or actual wake-up duration to the MCU, and then the MCU calculates a final wake-up distance or a final wake-up moment based on the advance wake-up distance or duration (the first distance or the first duration), to wake up the application processor.”; [0264] – “S206: Determine, based on the stored processed GPS data, whether a wake-up condition of the application processor is met, and perform S208 if the wake-up condition of the application processor is met.”; [0267] – “If the voice broadcast condition set by the user is broadcast at a fixed time interval, the wake-up condition may be a target wake-up time that is calculated based on current exercise duration and at which a next broadcast moment is reached.”; [0270]-[0271] – “S208: The MCU sends the processed GPS data of the at least two location points to the application processor. In this case, the application processor of the electronic device is woken up and receives the processed GPS data of the at least two location points that is sent by the MCU”. The MCU may determine a final wake-up moment and start a timer based on the wake-up condition received from the application processor. When the timer expires (i.e., the preset restart identification is cleared), the MCU wakes the application processor – see S208 – by sending the collected and processed GPS data (“determined data of a second data type”). As indicated regarding claim 9, although the method of operation is described in terms of GPS data, the method can be applied to other data types as indicated in [0116].).
Regarding claim 11, the combination of Zhong in view of Kupermann, Hasegawa, and Weast teaches the data transmission method as claimed in claim 1. Zhong further teaches wherein the type of data to be transmitted comprises a second data type ([0116] – “The MCU is not limited to being connected to the GPS chip. In a specific implementation, the MCU may be further connected to various sensors, such as the gyroscope sensor 180B, the acceleration sensor 180C, and the optical proximity sensor 180E, to process data from various sensor devices.”. A first data type may be GPS data, whereas a second data type may be gyroscope data and/or acceleration data.);
wherein the first data type is a data collected during a first collecting period, the second data type is a data collected during a second collecting period, and the second collecting period is longer than the first collecting period ([0260]-[0261] – “the GPS chip is connected to the MCU, and sends the GPS data to the MCU. The MCU may process the GPS data […] The MCU may store a plurality of pieces of processed GPS data. S205: Determine whether the stored processed GPS data reaches a threshold B, and perform S208 if the stored processed GPS data reaches the threshold B.”; [0207] – “the stored GPS data reaches a threshold B may be that duration for storing the GPS data reaches the threshold B, where B may be but is not limited to 1 minute, 3 minutes, 5 minutes, or the like.”. For example, the GPS data may be received from the GPS chip for a period of 1 minute. As disclosed in [0116], the MCU may collect and process other data types according to the method described. Therefore, the embodiment in which data of a second data type, such as gyroscope data, may be collected from the gyroscope sensor and stored for a period longer than the period for the GPS data, such as a period of 5 minutes, is taught by Zhong.
Further, as modified by Kupermann and Weast with respect to claim 1, when the first data type is accelerometer data and the second data type is a step count derived from the accelerometer data, the second collecting period (e.g. the first time period or the length of the buffer described in [0066]-[0070] of Weast) is necessarily longer than the first collecting period (e.g. the period between samples corresponding to the sampling rate disclosed in [0067] of Weast), since the steps are obtained based on a plurality of accelerometer samples.).
Regarding claim 12, the combination of Zhong in view of Kupermann, Hasegawa, and Weast teaches the data transmission method as claimed in claim 4. Kupermann further teaches wherein the first data type is a real-time data type ([0057] – “RTOS is capable of processing sensor data from the first set 305 in real-time.”; [0072] – “In some embodiments, VM 310 instructs HW IP block 302 to transmit the sensor data collected in real-time to VM 310. For example, sensor data is transmitted to VM 310 as it is collected. In some embodiments, VM 310 instructs HW IP block 302 to transmit the sensor data stored in Memory 406.” Some of the data to be transmitted from sensors 305, including an accelerometer – see [0038] – may be collected, processed, and transmitted in real-time.), the second data type is a detail data type ([0036] – “Here, the term "virtual sensor" generally refers to software based sensors that consume sensor data from other sensors and produce their own sensor output as opposed to physical sensor drivers that retrieve sensor data from a physical sensor device via an input-output (IO) interface such as I2C or SPI (Serial Peripheral Interface). An example of a virtual sensor is a step counter which consumes data from an accelerometer sensor (which is physical sensor driver) and produces step counter as output.” The output of the virtual sensors can be considered “detail data” about the data of the physical sensor from which it is derived. For example, the step counter provides details about the number of steps that are represented in the measured accelerometer data.), and the target data is at least one of heart rate, altitude, steps, distance, speed, calories, step rate ([0036] and [0058] – a virtual sensor which the RTOS (Logic 405) communicates with, collects from, and processes data for may include a step counter; [0038] – set of sensors 305 from which HW IP block 302 collects data to be transmitted to processor 301 may include a pedometer).
Zhong teaches an MCU of the wearable device operates to collect data and process data from a plurality of sensors while the application processor is in a sleep state and then report the data to the application processor when a condition is met in order to reduce power consumption (see [0005], [0007] and [0116]). Kupermann similarly teaches the HW IP block 302 (see [0034] and [0056]) of the wearable device, on which the first operation system is implemented, collects and processes sensor data from a plurality of sensors 305 while processor 301, on which the second operation system is implemented, is in a sleep state and reports the sensor data to the processor 301 when a condition is met (see [0032]-[0033], [0049], and [0057]-[0058]). Therefore, it would have been obvious to one of ordinary skill in the art that the MCU and application processor of Zhong could be substituted for the HW IP block 302 and processor 301 of Kupermann since they are capable of performing analogous functions in a wearable device. Further, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method performed by the wearable device taught by Zhong to incorporate the teachings of Kupermann, including the two operation systems and virtual sensors which derive data from other sensor measurements, because they provide a cost effective low power sensing solution for wearable devices without sacrificing compute and sensing capabilities of the wearable device (Kupermann: [0012]-[0015]). Further, the first, lower power, operation system of Kupermann enables servicing real-time applications without buffering delays (Kupermann: [0035] and [0056]). Lastly, Zhong suggests the MCU collecting and processing data from an acceleration sensor and further suggests a quantity of steps obtained using data collected from the acceleration sensor (Zhong: [0116] and [0174]), analogous to the first data type and second data type taught by Kupermann.
Regarding claim 13, the combination of Zhong in view of Kupermann, Hasegawa, and Weast teaches the data transmission method as claimed in claim 1. Kupermann further teaches wherein the first operation system is supported by a first chip, the second operation system is supported by a second chip, and a power consumption of the first chip is lower than a power consumption of the second chip ([0032] – “In some embodiments, Processor 301 and HW IP block 302 are separately packaged integrated circuits.”; [0034] – “HW IP block 302 is optimized for lower power”; [0049] – “when Processor 301 is in low power mode (e.g., sleep state), HW IP block 302 may continue to operate (because it is designed to operate at a low power state)”; FIGS. 5A-5C).
Zhong teaches an MCU of the wearable device operates to collect data and process data from one or more sensors while the application processor is in a sleep state and then report the data to the application processor when a condition is met in order to reduce power consumption (see [0005], [0007] and [0116]). Kupermann similarly teaches the HW IP block 302 (see [0034] and [0056]) of the wearable device, on which the first operation system is implemented, collects and processes sensor data from a plurality of sensors 305 while processor 301, on which the second operation system is implemented, is in a sleep state and reports the sensor data to the processor 301 when a condition is met (see [0032]-[0033], [0049], and [0057]-[0058]). Therefore, it would have been obvious to one of ordinary skill in the art that the MCU and application processor of Zhong could be substituted for the HW IP block 302 and processor 301 of Kupermann since they are both capable of performing analogous functions in a wearable device. Further, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method performed by the wearable device taught by Zhong to include two operation systems as taught by Kupermann, where a first operation system has a lower power consumption than a second operation system. The hardware and software structure of Kupermann including two operation systems provides a cost effective low power sensing solution for wearable devices without sacrificing compute capabilities and sufficient memory (Kupermann: [0012]-[0015]).
Regarding claim 21, the combination of Zhong in view of Kupermann, Hasegawa, and Weast teaches the data transmission method as claimed in claim 1. Kupermann further teaches wherein the type of data to be transmitted comprises a second data type, and data of the second data type is determined based on data of the first data type ([0056] – “Logic 405 (e.g., a Finite State Machine) is a low power logic which is operable to perform basic functions such as to monitor which sensors of first set of one or more sensors 305 are active and operating, collect data sensed by first set of one or more sensors 305, in some cases analyze the collected data, initiate communication with VM 310, and receive instructions from VM 310. In some embodiments, Logic 405 executes a real-time operating system (RTOS).”; [0058] – “Logic 405 includes sensor drivers for communicating with sensors of first set 305. […] Logic 405 is capable of communicating with derived or virtual sensors.”; [0035]-[0036] – “HW IP block 302 includes firmware (FW) that implements sensor algorithms for the virtual sensors and calibration of sensors. Here, the term "virtual sensor" generally refers to software based sensors that consume sensor data from other sensors and produce their own sensor output as opposed to physical sensor drivers that retrieve sensor data from a physical sensor device via an input-output (IO) interface such as I2C or SPI (Serial Peripheral Interface). An example of a virtual sensor is a step counter which consumes data from an accelerometer sensor (which is physical sensor driver) and produces step counter as output. Other examples of virtual sensor or derived sensors (that providing sensing data which is derived from other sensors) are calibrated accelerometer (that derives data from an accelerometer) and activity context detection sensor.” Sensor data collected by the RTOS (Logic 405) of the HW IP block 302 may include data of a first type from a physical sensor, such as data from an accelerometer in set 305, and data of a second type from a virtual sensor implemented by the HW IP block 302 which derives data from the physical sensor data of the first type, such as a step counter which derives step count data from the accelerometer data.).
Zhong teaches the MCU is configured to process data from a plurality of sensors, including an acceleration sensor (see Zhong: [0116]), which is analogous to the accelerometer of Kupermann. As discussed with respect to claim 1, it would have been obvious to one of ordinary skill in the art that the MCU and application processor of Zhong could be substituted for the HW IP block 302 and processor 301 of Kupermann since they are capable of performing analogous functions in a wearable device. Further, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method performed by the wearable device taught by Zhong to incorporate the teachings of Kupermann, including the two operation systems and virtual sensors which derive data from other sensor measurements, because they provide a cost effective low power sensing solution for wearable devices without sacrificing compute capabilities and sufficient memory (Kupermann: [0012]-[0015]). Further, the first, lower power, operation system of Kupermann enables servicing real-time applications without buffering delays (Kupermann: [0035] and [0056]). Lastly, Zhong suggests the MCU collecting and processing data from an acceleration sensor and further suggests a quantity of steps obtained using data collected from the acceleration sensor (Zhong: [0116] and [0174]), analogous to the first data type and second data type taught by Kupermann.
Claim 22 is rejected under 35 U.S.C. 103 as being unpatentable over Zhong in view of Kupermann and LEWIS (U.S. Pub. No. 2015/0160881).
Regarding claim 22, Zhong teaches A data transmission method, performed by a wearable apparatus ([0096] – “FIG. 8A and FIG. 8B are a schematic flowchart of an exercise track recording method according to another embodiment of this application”; [0104] – “The electronic device in this embodiment of this application may be […] a wearable electronic device”)
detecting restarting of the first operation system ([0211]-[0212] – “If the MCU triggers the electronic device 100 to switch from the normal mode to the low power consumption mode, when the electronic device 100 switches from the normal mode to the low power consumption mode for the first time, the application processor may send the next-time wake-up condition to the MCU when the display 192 of the electronic device 100 is off. When the electronic device 100 switches from the normal mode to the low power consumption mode for a non-first time, the application processor may send the next-time wake-up condition to the MCU when the GPS data stored by the electronic device 100 in the low power consumption mode has been sent in batches. The next-time wake-up condition may be determined based on a voice broadcast condition set by the user.” The MCU triggers the device to switch to the low power mode in which the GPS data is first processed by the MCU before being transmitted to the application processor. This can be interpretated as operations performed by the MCU “restarting” (i.e., the first operation system is restarting).);
transmitting data to be recovered from the second operation system to the first operation system, wherein the data to be recovered has an accumulated characteristic, ([0175] – “The accumulated exercise distance displayed in the accumulated exercise information display area 304 may be obtained based on GPS data obtained by a GPS chip 230.”; [0211] – “When the electronic device 100 switches from the normal mode to the low power consumption mode for a non-first time, the application processor may send the next-time wake-up condition to the MCU when the GPS data stored by the electronic device 100 in the low power consumption mode has been sent in batches.”; [0213] – “The next-time wake-up condition of the application processor is that a difference between a current exercise distance and an exercise distance for next voice broadcast is a first distance, where the exercise distance for the next voice broadcast is longer than the current exercise distance.”; [0215] – “When the application processor switches from the normal mode to the low power consumption mode for a non-first time, it is assumed that a current exercise distance is 3.2 kilometers, and a first distance is 0.1 kilometer, the application processor may send to the MCU, the next-time wake-up condition that is continuously keeping exercise for 0.7 kilometer.” When the electronic device enters low-power mode for a non-first time, the MCU has previously sent GPS data indicating distance to the application processor, and the wake-up condition is based on the current distance (i.e., the previously accumulated and sent GPS data).); and
transmitting target data from the first operation system to the second operation system, wherein the target data is obtained by using the data to be recovered ([0264] – “S206: Determine, based on the stored processed GPS data, whether a wake-up condition of the application processor is met, and perform S208 if the wake-up condition of the application processor is met.”; [0270]-[0271] – “S208: The MCU sends the processed GPS data of the at least two location points to the application processor. In this case, the application processor of the electronic device is woken up and receives the processed GPS data of the at least two location points that is sent by the MCU”. The target data (sent in S208), is determined based on the wake-up condition received from the application processor (the “data to be recovered”) and an estimated distance determined based on the newly collected and stored GPS data.)
ZHONG fails to expressly teach the wearable apparatus configured with a first operation system and a second operation system, the data to be recovered is data that the first operation system has reported to the second operation system and the target data is obtained by using the data to be recovered as a base.
However, Kupermann teaches a wearable apparatus ([0028] – “device 203 (e.g., smart watch) includes a sensing architecture that uses a VM and a HW IP block ( or HW sensor hub).”) configured with a first operation system and a second operation system ([0030] – “FIG. 3 illustrates computer system 300 (or a sensing system) with a sensing architecture formed from a combination of a VM and HW IP block”; [0031] – “computer system 300 comprises Processor 301, Resource Optimized Sensor Hub 302 (or HW IP block 302) […] Processor 301 comprises Virtualization Environment 307. In some embodiments, Virtualization Environment 307 comprises: Operating System Software (OS SW) stack 308”; [0035] – “HW IP block 302 comprises two components. In some embodiments, the first component is a real-time operating system”).
Zhong and Kupermann are considered to be analogous art to the claimed invention because they are in the same field as the invention of reducing power consumption within wearable devices. Zhong teaches an MCU of the wearable device operates to collect data and process data from one or more sensors while the application processor is in a sleep state and then report the data to the application processor when a condition, such as the wake-up condition specified by the application processor, is met (see [0005], [0007], [0116], and [0206]). Kupermann similarly teaches the HW IP block 302 (see [0034] and [0056]) of the wearable device, on which the first operation system is implemented, collects and processes sensor data from a plurality of sensors 305 while processor 301, on which the second operation system is implemented, is in a sleep state and reports the sensor data to the processor 301 when a condition is met, wherein an instruction sent from the OS on processor 301 may cause the reporting of data from HW IP block 302 to processor 301 (see [0032]-[0033], [0049], [0057]-[0058], and [0072]). Therefore, it would have been obvious to one of ordinary skill in the art that the MCU and application processor of Zhong could be substituted for the HW IP block 302 and processor 301 implementing operating systems of Kupermann since they are both capable of performing analogous functions in a wearable device. Further, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method performed by the wearable device taught by Zhong to include two operation systems as taught by Kupermann, where a first operation system has a lower power consumption than a second operation system, and the first operation system obtains data to be transmitted to the second operation system from a plurality of physical and virtual sensors. The hardware and software structure of Kupermann including two operation systems provides a cost effective low power sensing solution for wearable devices without sacrificing compute capabilities and sufficient memory (Kupermann: [0012]-[0015]).
ZHONG in view of Kupermann fails to expressly teach the data to be recovered is data that the first operation system has reported to the second operation system and the target data is obtained by using the data to be recovered as a base.
However, LEWIS teaches data to be recovered is data that the first operation system has reported to the second operation system (Abstract – “embodiments of the present invention utilize the clipboard facilities supported by the operating systems, along with firmware and helper software in each OS, to move data back and forth when switching between an active and inactive operating system. The clipboard contents are preserved in non-volatile storage that is not lost across the sleep-state transitions used to switch operating systems.”; [0025] – “after the user has initiated the OS switch, the OS broadcasts messages to all agents (drivers, daemons, etc.) to indicate that it is transitioning into one of the previously mentioned sleep states. A first agent operating in the current active first OS identifies the upcoming switch based upon one of the messages and based on that identification, retrieves the contents of the clipboard available to the first OS, and copies the data into non-volatile storage (step 206).”; [0026] – “the OS completes its sleep state transition and the system is reset, giving control back to the firmware (step 208). The firmware either returns to the second OS using the Firmware ACPI Control Structure (for S3 sleep states) or via a boot to the second OS (for S4 or S5 sleep states). During the resume process (S3) or the boot process (S4 or S5), a second OS agent in the second operating system retrieves the data previously saved in the non-volatile storage location, converts it into a format understood by the second operating system's clipboard facilities and updates the second operating system's clipboard (step 210).” Data may be moved back and forth (i.e., it may be transmitted from a first OS to the second OS and back to the first OS, or from a second OS to a first OS and back to the second OS). Thus, the data moving from the first OS to the second described in paragraphs [0025]-[0026] may be data sent from the second OS to the first OS during a previous switch.), and the target data is obtained by using the data to be recovered as a base ([0026] – “The data may subsequently be retrieved from the clipboard, programmatically via an API, with the keyboard (e.g.: Ctrl- V) or with a user-interface (e.g.: paste), for use by an application under control of the second OS (step 212).” The application of the second OS uses the data transferred from the first OS to execute an application, i.e., as a base for the data generated during execution of the application.).
LEWIS is considered to be analogous art to the claimed invention because it is reasonably pertinent to the problem faced by the inventor of transmitting data between two independent operation systems in a same apparatus. Therefore, it would have been obvious to one of ordinary skill in the art to have implemented the methods of transferring data between two operation systems on a same computing device to the wearable device comprising two operation systems of Zhong in view of Kupermann. The methods of LEWIS enable moving data between applications on different operating systems, and specifically between applications on an active operating systems and an inactive operating system, preserving the data between system sleep state transitions, and ensuring the data is properly formatted for the different operating systems (LEWIS: [0012]-[0014]).
Claims 23-27 are rejected under 35 U.S.C. 103 as being unpatentable over Zhong in view of Kupermann and Weast.
Regarding claim 23, Zhong teaches A data transmission method, performed by a wearable apparatus ([0096] – “FIG. 8A and FIG. 8B are a schematic flowchart of an exercise track recording method according to another embodiment of this application”; [0104] – “The electronic device in this embodiment of this application may be […] a wearable electronic device”) […]; the method comprising:
obtaining a type of data to be transmitted; wherein the data to be transmitted is data of a first data type or data of a second data type (FIG. 8B, S204; [0259] – “S204: An MCU receives the GPS data sent by the GPS chip”. The type of data transmitted in the exemplary embodiment detailed for FIG. 8 is GPS data. The MCU may receive other types of data as well: [0116] – “The MCU is not limited to being connected to the GPS chip. In a specific implementation, the MCU may be further connected to various sensors, such as the gyroscope sensor 180B, the acceleration sensor 180C, and the optical proximity sensor 180E, to process data from various sensor devices.”), the data of the first data type and the data of the second data type are obtained from a same sensor and configured to be transmitted from the first operation system to the second operation system, the data of the first data type has a real-time characteristic, the data of the second data type has an accumulated characteristic, and an interval between every two adjacent obtaining of the data of the second data type is longer than an interval between every two adjacent obtaining of the data of the first data type;
detecting current screen state information of the wearable apparatus (FIG. 8A and 8B, S203 and/or S207; [0256]-[0257] – “S203: Determine whether a display is off, and perform S204 if the display is off. Specifically, when the electronic device records the exercise track in the first mode for the first time, the electronic device may determine, based on whether the display is off, whether to record the exercise track in the second mode.”; [0268] – “S207: Determine whether the display is on, and perform S208 if the display is on.”); and
determining target data according to the current screen state information of the wearable apparatus and the type of data to be transmitted (FIG. 8B steps 204, 205, 206 and 207; [0260] – “Specifically, when the exercise track is recorded in the second mode, the GPS chip is connected to the MCU, and sends the GPS data to the MCU. The MCU may process the GPS data by using the second positioning algorithm. […] The MCU may store a plurality of pieces of processed GPS data.” The system is in a “second mode”, or a low-power mode, when the display is off. At step 204, in the second mode, the MCU determines the “target data” by processing the GPS data as described in [0256]-[0257]. [0261] – “S205: Determine whether the stored processed GPS data reaches a threshold B, and perform S208 if the stored processed GPS data reaches the threshold B.”; [0264] – “S206: Determine, based on the stored processed GPS data, whether a wake-up condition of the application processor is met, and perform S208 if the wake-up condition of the application processor is met.”; [0268] – “S207: Determine whether the display is on, and perform S208 if the display is on.” In steps 205, 206, and 207, the MCU further checks conditions to determine if the target data (processed GPS data) should be sent to the application processor.), and transmitting the target data from the first operation system of the wearable apparatus to the second operation system of the wearable apparatus (FIG. 8B, S208; [0270] – “The MCU sends the processed GPS data of the at least two location points to the application processor.”).
Zhong fails to expressly teach the wearable apparatus configured with a first operation system and a second operation system, and a power consumption of the first operation system being lower than a power consumption of the second operation system and the data of the first data type and the data of the second data type are obtained from a same sensor and configured to be transmitted from the first operation system to the second operation system, the data of the first data type has a real-time characteristic, the data of the second data type has an accumulated characteristic, and an interval between every two adjacent obtaining of the data of the second data type is longer than an interval between every two adjacent obtaining of the data of the first data type.
However, Kupermann teaches a wearable apparatus ([0028] – “device 203 (e.g., smart watch) includes a sensing architecture that uses a VM and a HW IP block ( or HW sensor hub).”) configured with a first operation system and a second operation system ([0030] – “FIG. 3 illustrates computer system 300 (or a sensing system) with a sensing architecture formed from a combination of a VM and HW IP block”; [0031] – “computer system 300 comprises Processor 301, Resource Optimized Sensor Hub 302 (or HW IP block 302) […] Processor 301 comprises Virtualization Environment 307. In some embodiments, Virtualization Environment 307 comprises: Operating System Software (OS SW) stack 308”; [0035] – “HW IP block 302 comprises two components. In some embodiments, the first component is a real-time operating system”), and a power consumption of the first operation system being lower than a power consumption of the second operation system ([0012]-[0013] – “Various embodiments described here provide a low power sensing scheme by splitting the sensing functionality between a virtual machine (VM) and a small dedicated hardware (HW) Intellectual Property (IP) block. In some embodiments, the VM includes sufficient memory and compute capabilities, while the dedicated small HW IP block provides cost effective sensing solution for low power use cases. Some embodiments enable keeping all the sensing usage under a black box sensor hub interface and maintain low power budget for selected use cases (e.g., wake detect, step counting, etc.) using quarter of the gate count of a full featured sensor hub dedicated HW block (e.g., SH 102 of FIG. 1). A software only VM solution may not meet the power requirements of a small computing device”; [0034] – “HW IP block 302 is optimized for lower power”; [0049] – “when Processor 301 is in low power mode (e.g., sleep state), HW IP block 302 may continue to operate (because it is designed to operate at a low power state)”; FIGS. 5A-5C) […] the data of the first data type and the data of the second data type are obtained from a same sensor and configured to be transmitted from the first operation system to the second operation system ([0035]-[0036] – “HW IP block 302 includes firmware (FW) that implements sensor algorithms for the virtual sensors and calibration of sensors. […] An example of a virtual sensor is a step counter which consumes data from an accelerometer sensor (which is physical sensor driver) and produces step counter as output.”; [0038] – “the first set of one or more sensors 305 includes one or more of: […] Accelerometer”; [0044] – “the sensor algorithms in VM 310 can request AON SH 302 to buffer sensor data and send it up to VM 310 (e.g., accelerometer data sent once in 5 seconds, etc.).”; [0049] – “HW IP block 302 is to wake up VM 310 when an event is detected by the one or more sensors of the first set 305 or when the data collected from the one or more sensors of the first set 305 is to be delivered to Processor 301”; [0056] – “Logic 405 (e.g., a Finite State Machine) is a low power logic which is operable to perform basic functions such as to monitor which sensors of first set of one or more sensors 305 are active and operating, collect data sensed by first set of one or more sensors 305, in some cases analyze the collected data, initiate communication with VM 310, and receive instructions from VM 310. In some embodiments, Logic 405 executes a real-time operating system (RTOS).”; [0058] – “Logic 405 is capable of communicating with derived or virtual sensors. In some embodiments, Logic 405 is operable to perform various algorithms to process sensor data.”; [0072] – “VM 310 instructs HW IP block 302 to transmit the sensor data it has collected. In some embodiments, VM 310 instructs HW IP block 302 to transmit the sensor data collected in real-time to VM 310. For example, sensor data is transmitted to VM 310 as it is collected. In some embodiments, VM 310 instructs HW IP block 302 to transmit the sensor data stored in Memory 406.” Data to be transmitted from the HW IP block 302 with the RTOS may comprise accelerometer data (“data of the first data type”), as well as derived step counter data (“data of the second data type”) obtained from the accelerometer data, and thus also obtained from the accelerometer (the “same sensor”).), the data of the first data type has a real-time characteristic ([0057] – “RTOS is capable of processing sensor data from the first set 305 in real-time”; [0072] – “to transmit the sensor data collected in real-time to VM 310”).
Zhong and Kupermann are considered to be analogous art to the claimed invention because they are in the same field as the invention of reducing power consumption within wearable devices. Zhong teaches an MCU of the wearable device operates to collect data and process data from one or more sensors while the application processor is in a sleep state and then report the data to the application processor when a condition is met in order to reduce power consumption (see [0005], [0007] and [0116]). Kupermann similarly teaches the HW IP block 302 (see [0034] and [0056]) of the wearable device, on which the first operation system is implemented, collects and processes sensor data from a plurality of sensors 305 while processor 301, on which the second operation system is implemented, is in a sleep state and reports the sensor data to the processor 301 when a condition is met (see [0032]-[0033], [0049], and [0057]-[0058]). Therefore, it would have been obvious to one of ordinary skill in the art that the MCU and application processor of Zhong could be substituted for the HW IP block 302 and processor 301 of Kupermann since they are both capable of performing analogous functions in a wearable device. Further, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method performed by the wearable device taught by Zhong to include two operation systems as taught by Kupermann, where a first operation system has a lower power consumption than a second operation system, and the data to be transmitted which is obtained by the first operation system comprises data of a first type and a second type obtained from a same sensor, where the data of the first type has a real-time characteristic. The hardware and software structure of Kupermann including two operation systems provides a cost effective low power sensing solution for wearable devices without sacrificing compute capabilities and sufficient memory (Kupermann: [0012]-[0015]). Further, the first, lower power, operation system of Kupermann enables servicing real-time applications without buffering delays (Kupermann: [0035] and [0056]). Lastly, Zhong suggests the MCU collecting and processing data from an acceleration sensor and further suggests a quantity of steps obtained using data collected from the acceleration sensor (Zhong: [0116] and [0174]), analogous to the first data type and second data type taught by Kupermann.
The combination of Zhong in view of Kupermann fails to expressly teach the data of the second data type has an accumulated characteristic, and an interval between every two adjacent obtaining of the data of the second data type is longer than an interval between every two adjacent obtaining of the data of the first data type.
However, Weast teaches the data of the second data type has an accumulated characteristic, and an interval between every two adjacent obtaining of the data of the second data type is longer than an interval between every two adjacent obtaining of the data of the first data type ([0008] – “quantify steps taken by the user based upon the motion data, such as by detecting arm swings peaks and bounce peaks in the motion data. […] motion data is obtained from an accelerometer. Accelerometer magnitude vectors may be obtained for a time frame and values, such as an average value from magnitude vectors for the time frame may be calculated. The average value (or any other value) may be utilized to determine whether magnitude vectors for the time frame meet an acceleration threshold to qualify for use in calculating step counts for the respective time frame.”; [0066]-[0067] – “a plurality of samples from one or more sensors may be obtained during a first time period. In one embodiment, at least one sensor comprises an accelerometer. […] utilizing a 25 Hz sampling rate to obtain accelerometer data from an appendage-worn (e.g., wrist-worn) portable device may adequately obtain data, such as for example, step counts while obtaining acceptable battery life […] the first time period may be 1 second. In one embodiment, 64 samples of data may be obtained during the first time period”; [0068] – “The collected data may be analyzed or processed, which may occur upon collection, at predefined intervals”; [0069]-[0070] – “Samples (or data relating to the received samples) from the first time period may be placed in a buffer (see, e.g., block 404) […] In one embodiment, about 128 samples may be placed in a first buffer In certain embodiments, the buffer may be about twice (e.g., 2x) the first time period.”; [0075]-[0076] – “systems and methods may be implemented to quantify steps based upon the data (or a portion thereof). In one embodiment, block 408 may be implemented to process at least a portion of the data. Analysis (and/or other statistical measures) may be performed on the entire buffer or at least one of the sub-buffers […] data (such as the data within the buffer or a sub-buffer) may be compared with a threshold as part of block 408 or another process (see, e.g., decision 410). […] Further logic may be utilized to determine if the sub-buffers have valid data (e.g., data that met the threshold), and if so, that data is utilized in further step count determinations.”; [0091] – “Block 412f may be implemented to identify a subgroup (or sub-groups) of peaks within the frequency data to utilize in the determinations of step quantification. […] a specific peak ( or peaks) within the data (such as for example, data obtained within the first buffer and/or data obtained during first time frame) may be utilized.” To determine step counts (data of a “second data type) from accelerometer data (data of a “first data type”), the accelerometer data must be accumulated (a plurality of accelerometer samples must be obtained before steps can be identified within the accelerometer data), i.e., the step count has an “accumulated characteristic”. Further, since the step data requires analysis over a plurality of accelerometer samples (e.g., for the buffer comprising samples from the “first time period” disclosed in [0066]-[0070]), the interval between quantifying the step data is necessarily longer than the interval between obtaining each accelerometer sample (e.g., the sampling rate disclosed in [0067]).).
Weast is considered to be analogous art to the claimed invention because it is reasonably pertinent to the problem faced by the inventor of obtaining types of data from sensors in a wearable apparatus. Therefore, it would have been obvious to have modified the data of the first data type, e.g., accelerometer data, and the data of the second data type, e.g., a step count derived from accelerometer data, as taught by Zhong in view of Kupermann such that the data of the second data type has an accumulated characteristic, and an interval between every two adjacent obtaining of the data of the second data type is longer than an interval between every two adjacent obtaining of the data of the first data type as taught by Weast. The methods of quantifying steps from obtained accelerometer data as taught by Weast provide the benefit of a low power, high-fidelity step counter in a wearable apparatus which improves battery life and reduces false positives in step counting by accumulating accelerometer data for analysis (Weast: [0056] and [0061]).
Regarding claim 24, the combination of Zhong in view of Kupermann and Weast teaches the data transmission method as claimed in claim 23. Zhong further teaches wherein the determining the target data according to the current screen state information of the wearable apparatus and the type of data to be transmitted, comprises:
determining a single-batch data of the first data type as the target data in response to the current screen state information of the wearable apparatus indicating a screen-on state and the type of data to be transmitted being the first data type ([0280] – “In the second mode, the MCU may receive the GPS data sent by the GPS chip, process the GPS data, and store a plurality of pieces of processed GPS data. When a switching condition is met, the MCU sends the stored plurality of pieces of processed GPS data to the application processor in batches, so that the application processor enters a sleep state in the second mode.”; [0206] – “The condition for switching from the low power consumption mode to the normal mode may include any one of the following: […] 3. A display 192 of the electronic device 100 is on.”), wherein the single-batch data of the first data type is data reported to the second operation system at a first reporting interval ([0200] – “Specifically, an MCU may include a timer, and duration of the timer is A seconds. When the MCU starts to send the data to the application processor in batches, the timer may be triggered to start timing. After the timer expires, the MCU may determine that the electronic device 100 works in the normal mode for A seconds.” When the batch of data is sent to the application processor, an interval of A seconds is allowed for reporting/processing in normal mode before another batch may be sent.).
Regarding claim 25, the combination of Zhong in view of Kupermann and Weast teaches the data transmission method as claimed in claim 23. Zhong teaches the method further comprising:
not transmitting data of the first data type in response to the current screen information of the wearable apparatus indicating a screen-off state and the type of data to be transmitted being the first data type (FIG. 8B, S205, S206 and S207; [0261] – “S205: Determine whether the stored processed GPS data reaches a threshold B, and perform S208 if the stored processed GPS data reaches the threshold B.”; [0264] – “S206: Determine, based on the stored processed GPS data, whether a wake-up condition of the application processor is met, and perform S208 if the wake-up condition of the application processor is met.”; [0268] – “S207: Determine whether the display is on, and perform S208 if the display is on.” If the display is not on (evaluated at S207), and a condition based on the GPS data (a first data type) is not met (evaluated at S205 and S206), the data is not sent to the application processor (S208 is not performed).).
Regarding claim 26, the combination of Zhong in view of Kupermann and Weast teaches the data transmission method as claimed in claim 23. Kupermann further teaches wherein the first data type is a real-time data type ([0057] – “RTOS is capable of processing sensor data from the first set 305 in real-time.”; [0072] – “In some embodiments, VM 310 instructs HW IP block 302 to transmit the sensor data collected in real-time to VM 310. For example, sensor data is transmitted to VM 310 as it is collected. In some embodiments, VM 310 instructs HW IP block 302 to transmit the sensor data stored in Memory 406.” Some of the data to be transmitted from sensors 305, including an accelerometer – see [0038] – may be collected, processed, and transmitted in real-time.), the second data type is a detail data type ([0036] – “Here, the term "virtual sensor" generally refers to software based sensors that consume sensor data from other sensors and produce their own sensor output as opposed to physical sensor drivers that retrieve sensor data from a physical sensor device via an input-output (IO) interface such as I2C or SPI (Serial Peripheral Interface). An example of a virtual sensor is a step counter which consumes data from an accelerometer sensor (which is physical sensor driver) and produces step counter as output.” The output of the virtual sensors can be considered “detail data” about the data of the physical sensor from which it is derived. For example, the step counter provides details about the number of steps that are represented in the measured accelerometer data.), and the target data is at least one of heart rate, altitude, steps, distance, speed, calories, step rate ([0036] and [0058] – a virtual sensor which the RTOS (Logic 405) communicates with, collects from, and processes data for may include a step counter; [0038] – set of sensors 305 from which HW IP block 302 collects data to be transmitted to processor 301 may include a pedometer).
Zhong teaches an MCU of the wearable device operates to collect data and process data from a plurality of sensors while the application processor is in a sleep state and then report the data to the application processor when a condition is met in order to reduce power consumption (see [0005], [0007] and [0116]). Kupermann similarly teaches the HW IP block 302 (see [0034] and [0056]) of the wearable device, on which the first operation system is implemented, operates to collect and process sensor data from a plurality of sensors 305 while processor 301, on which the second operation system is implemented, is in a sleep state and then report the sensor data to the processor 301 when a condition is met (see [0032]-[0033], [0049], and [0057]-[0058]). Therefore, it would have been obvious to one of ordinary skill in the art that the MCU and application processor of Zhong could be substituted for the HW IP block 302 and processor 301 of Kupermann since they are capable of performing analogous functions in a wearable device. Further, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method performed by the wearable device taught by Zhong to incorporate the teachings of Kupermann, including the two operation systems and virtual sensors which derive data from other sensor measurements, because they provide a cost effective low power sensing solution for wearable devices without sacrificing compute and sensing capabilities of the wearable device (Kupermann: [0012]-[0015]). Further, the first, lower power, operation system of Kupermann enables servicing real-time applications without buffering delays (Kupermann: [0035] and [0056]). Lastly, Zhong suggests the MCU collecting and processing data from an acceleration sensor and further suggests a quantity of steps obtained using data collected from the acceleration sensor (Zhong: [0116] and [0174]), analogous to the first data type and second data type taught by Kupermann.
Regarding claim 27, the combination of Zhong in view of Kupermann and Weast teaches the data transmission method as claimed in claim 23. Zhong further teaches wherein the determining the target data according to the current screen state information of the wearable apparatus and the type of data to be transmitted, comprises:
detecting the screen state information corresponding to data of the second data type sent last time in response to the current screen state information of the wearable apparatus indicating a screen-on state ([0268] – “S207: Determine whether the display is on, and perform S208 if the display is on.”; [0270]-[0271] – “S208 : The MCU sends the processed GPS data of the at least two location points to the application processor. In this case, the application processor of the electronic device is woken up and receives the processed GPS data of the at least two location points that is sent by the MCU, and the exercise track of the user is displayed on the map of the exercise app based on the processed GPS data of the at least two location points.”; [0192] – “When a condition for switching from the low power consumption mode to the normal mode is met, the MCU sends the stored GPS data to the application processor in batches. After receiving the GPS data sent by the MCU, the application processor performs second processing on the GPS data, and displays, in a point form on a map of an exercise app, GPS data obtained after the second processing. The second processing is mainly processing such as noise reduction and smoothing performed on the GPS data obtained after the first processing. After the GPS data is sent in batches, the MCU can clear the stored GPS data to release memory, so as to store GPS data obtained after first processing for a next time in the low power consumption mode. It can be learned that a plurality of points may be connected to form a line, and a line finally displayed on the map of the exercise app is an exercise track of a user. Therefore, the user can view the exercise track of the user on the map.” In short, when the screen is on, the exercise track 5011 (a line connecting GPS points received) is displayed. The line is updated with the new points received from the MCU after a screen is turned on again. The previous data received by the application processor to render the line the last time the screen was on would necessarily be “detected” in order to connect the new data points gathered while the application processor was asleep to the old data points from the last time the application processor was awake.) and the type of data to be transmitted being the second data type ([0116] – “The MCU is not limited to being connected to the GPS chip. In a specific implementation, the MCU may be further connected to various sensors, such as the gyroscope sensor 180B, the acceleration sensor 180C, and the optical proximity sensor 180E, to process data from various sensor devices.” Therefore, although the method of operation is described only in terms of GPS data, the method can be applied to other data types.); and
determining a single-batch data of the second data type as the target data in response to the screen state information corresponding to the data of the second data type transmitted last time indicating the screen-on state, wherein the single-batch data of the second data type is data reported to the second operation system after a second reporting interval ([0280] – “In the second mode, the MCU may receive the GPS data sent by the GPS chip, process the GPS data, and store a plurality of pieces of processed GPS data. When a switching condition is met, the MCU sends the stored plurality of pieces of processed GPS data to the application processor in batches, so that the application processor enters a sleep state in the second mode.”; [0206] – “The condition for switching from the low power consumption mode to the normal mode may include any one of the following: […] 3. A display 192 of the electronic device 100 is on.”; [0200]-[0201] – “Specifically, an MCU may include a timer, and duration of the timer is A seconds. When the MCU starts to send the data to the application processor in batches, the timer may be triggered to start timing. After the timer expires, the MCU may determine that the electronic device 100 works in the normal mode for A seconds. The A seconds may be but is not limited to 10 seconds, 30 seconds, 60 seconds, or the like.” When the batch of data is sent to the application processor, an interval of A seconds is allowed for reporting/processing in normal mode before another batch may be sent.).
Allowable Subject Matter
Claims 5-6 would be allowable if rewritten to overcome the rejection(s) under 35 U.S.C. 101 set forth in this Office action and to include all of the limitations of the base claim and any intervening claims. The following is a statement of reasons for the indication of allowable subject matter:
There was no prior art nor combination of prior art found which taught the limitations when the current screen state information of the wearable apparatus indicates a screen-on state and the type of data to be transmitted is a second data type, detecting the screen state information corresponding to data of a second data type sent last time; and determining a current single-batch data of the second data type as the target data when the screen state information corresponding to the data of the second data type transmitted last time indicates the screen-on state as recited in claim 5.
Additionally, there was no prior art found which taught when the screen state information corresponding to the data of the second data type sent last time indicates a screen-off state, detecting an ending time point of the data of the second data type sent last time as recited in claim 6.
Accordingly, claims 5 and 6 may be allowable if rewritten to overcome the rejection(s) under 35 U.S.C. 101 set forth in this Office action and to include all of the limitations of the base claim and any intervening claims.
Response to Arguments
Applicant's arguments filed 9/23/2025 with respect to the rejections under 35 U.S.C. 101, see pages 11-13, have been fully considered but they are not persuasive.
Regarding claims 1 and 23 (see page 11 of the Remarks):
Applicant alleges the limitation “performed by a wearable apparatus” indicates the claims are not directed to an abstract idea under step 2A, Prong 1.
Examiner disagrees. Under Step 2A, Prong 1, it is determined if a claim recites a judicial exception. As shown in the eligibility analysis presented above (see section titled Claim Rejections - 35 USC § 101), the steps obtaining a type of data to be transmitted, wherein the data to be transmitted is data of a first data type or data of a second data type, the data of the first data type and the data of the second data type are obtained from a same sensor and configured to be transmitted from the first operation system to the second operation system, the data of the first data type has a real-time characteristic, the data of the second data type has an accumulated characteristic, and an interval between every two adjacent obtaining of the data of the second data type is longer than an interval between every two adjacent obtaining of the data of the first data type; and determining target data according to the current screen state information of the wearable apparatus and the type of data to be transmitted […]; wherein determining target data according to the current screen state information of the wearable apparatus and the type of data to be transmitted, comprises: determining a current single-batch data of a first data type as the target data when the current screen state information of the wearable apparatus indicates a screen-on state and the type of data to be transmitted is the first data type, wherein the current single-batch data of the first data type is configured to be reported to the second operation system based on a first reporting interval, and the first reporting interval is an interval between every two adjacent reporting of the current single-batch data of the first data type to the second operation system as recited in claim 1, are considered to be steps which could be performed in the human mind, and thus are reciting an abstract idea of a mental process. Similarly, the limitations obtaining a type of data to be transmitted; wherein the data to be transmitted is data of a first data type or data of a second data type, the data of the first data type and the data of the second data type are obtained from a same sensor and configured to be transmitted from the first operation system to the second operation system, the data of the first data type has a real-time characteristic, the data of the second data type has an accumulated characteristic, and an interval between every two adjacent obtaining of the data of the second data type is longer than an interval between every two adjacent obtaining of the data of the first data type; detecting current screen state information of the wearable apparatus; and determining target data according to the current screen state information of the wearable apparatus and the type of data to be transmitted as recited in claim 23, are considered to be steps which could be performed in the human mind, and thus are reciting an abstract idea of a mental process.
Under Step 2A, Prong 2, it is determined whether the claims recite additional elements that integrate the judicial exception into a practical application. The limitation “A data transmission method, performed by a wearable apparatus configured with a first operation system and a second operation system, and a power consumption of the first operation system being lower than a power consumption of the second operation system; the method comprising” amounts to generally linking the use of the judicial exceptions recited in the steps of the method to a particular technological environment (i.e., to a wearable apparatus with a lower power operation system and a higher power operation system). Generally linking the use of the recited exception to a particular technological environment is not indicative of integration into a practical application (see MPEP 2106.04(d) and 2016.05(h)). Alternatively, stating the method is “performed by a wearable apparatus” could be considered mere instructions to apply the exception, as it is merely stating a computing device is performing the steps of the method which include at least one judicial exception. Mere instructions to apply the exception are also not indicative of integration into a practical application (see MPEP 2106.04(d) and 2106.05(f)). The other additional element recited is a step of insignificant extra-solution activity (transmitting the target data from the first operation system of the wearable apparatus to the second operation system of the wearable apparatus), which is not indicative of integration into a practical application and has not been argued. The courts have identified limitations which merely use a computer to perform an abstract idea, add insignificant extra-solution activity, and generally link the use of the judicial exception to a particular technological environment do not integrate a judicial exception into a practical application (see MPEP 2106.04(d)(I)).
As such, claims 1 and 23 fail to recite additional elements which integrate the recited judicial exceptions into a practical application. Thus, the claims are directed to the recited judicial exceptions under Step 2A.
Applicant further argues “amended claims 1 and 23 recite that "the data to be transmitted is data of a first data type or data of a second data type, the data of the first data type and the data of the second data type are obtained from a same sensor and configured to be transmitted from the first operation system to the second operation system, the data of the first data type has a real-time characteristic, the data of the second data type has an accumulated characteristic, and an interval between every two adjacent obtaining of the data of the second data type is longer than an interval between every two adjacent obtaining of the data of the first data type." Accordingly, the first operation system can selectively transmit different types of data from the same sensor based on the screen state, thereby achieving both real-time performance and power consumption savings for the wearable apparatus, and is directed to improvement of a physical apparatus.”
Examiner disagrees. Reciting the first data type has a real-time characteristic and the second data type has an accumulated characteristic, and only specifying the interval between obtaining data of the second data type is longer than the interval between obtaining data of the first data type does not achieve real-time performance as argued, e.g., it does not specify the interval for obtaining the first data type is in real-time or even close to real-time, and it further does not require that the first reporting interval at which data of the first data type is transmitted to the second operation system when the wearable apparatus indicates a screen-on state is in real-time or close to real-time. For example, even if the data of the first data type is obtained in real-time, e.g., once every second, it is not necessarily reported to the second operation system in real time; thus the real-time performance is not maintained for the second operation system.
It is further unclear how power consumption is saved as alleged in the arguments. The Specification teaches power consumption of the second operation system may be reduced by decreasing the number of times it is wakened while the wearable apparatus is in a screen-off state, e.g. from accumulating data of the second data type to a preset batch and then reporting the data (see [0057]); however, the claims only specify the data of the second data type has an accumulated characteristic and is obtained at an interval longer than the interval for obtaining the data of the first type. The claims do not specify how or when the data of the second data type is reported to the second operation system (or, more importantly, how and when it is not reported to the second operation system and therefore is not waking the second operation system). Thus, it is unclear how the argued limitations provide the benefit of power consumption savings.
Accordingly, the limitations of claims 1 and 23 do not provide a technological improvement and the claims are not integrated into a practical application. As such, the claims are directed to the recited judicial exceptions.
Regarding claim 22 (see page 12 of the Remarks):
The amendments to claim 22 have removed any previously recited judicial exception. Accordingly, the rejection of claim 22 under 35 U.S.C. 101 has been withdrawn.
Since the rejection of claim 22 under 35 U.S.C. 101 has been withdrawn, Applicant’s arguments are moot.
To overcome the rejection under 35 U.S.C. 101, the Examiner recommends amending claims 1 and 23 to include the limitations recited in claims 3 or 25, as those limitations clearly provide the technical improvement of reducing power consumption when the wearable apparatus is in a screen-off state.
Applicant’s arguments with respect to claims 1 and 23, see pages 13-15 of the Remarks filed 9/23/2023 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Specifically, Applicant argues Zhong fails to teach “the data of the first data type and the data of the second data type are obtained from a same sensor and configured to be transmitted from the first operation system to the second operation system, the data of the first data type has a real-time characteristic, the data of the second data type has an accumulated characteristic, and an interval between every two adjacent obtaining of the data of the second data type is longer than an interval between every two adjacent obtaining of the data of the first data type” as recited in claims 1 and 23.
However, as shown in the rejection of claims 1 and 23 above, the combination of Kupermann in view of Weast is relied upon to teach the argued limitations. Specifically, Kupermann teaches the data of the first data type and the data of the second data type are obtained from a same sensor and configured to be transmitted from the first operation system to the second operation system (see cited portions of [0035]-[0036], [0038], [0044], [0049], [0056], [0058], [0072] which teach data to be transmitted from the HW IP block 302 with the RTOS may comprise accelerometer data (“data of the first data type”), as well as derived step counter data (“data of the second data type”) obtained from the accelerometer data, and thus also obtained from the accelerometer (the “same sensor”).), the data of the first data type has a real-time characteristic (see cited portions of [0057] and [0072]).
As outlined in the rejections of claims 1 and 23 above, it would have been obvious to one of ordinary skill in the art that the MCU and application processor of Zhong could be substituted for the HW IP block 302 and processor 301 of Kupermann since they are both capable of performing analogous functions in a wearable device. Further, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method performed by the wearable device taught by Zhong to include two operation systems as taught by Kupermann, where a first operation system has a lower power consumption than a second operation system, and the data to be transmitted which is obtained by the first operation system comprises data of a first type and a second type obtained from a same sensor, where the data of the first type has a real-time characteristic. The hardware and software structure of Kupermann including two operation systems provides a cost effective low power sensing solution for wearable devices without sacrificing compute capabilities and sufficient memory (Kupermann: [0012]-[0015]). Further, the first, lower power, operation system of Kupermann enables servicing real-time applications without buffering delays (Kupermann: [0035] and [0056]).
Lastly, and most importantly with respect to the argued limitations, it would have been obvious to one of ordinary skill in the art that the data of the first and second type taught by Kupermann could be data of a first and second type obtained by the MCU of Zhong, which teaches an accelerometer may be one of the sensors the MCU may collect and process data from (see Zhong: [0116] and [0174]).
New reference, Weast (U.S. Pub. No. 2013/0191034), is relied upon to teach the data of the second data type has an accumulated characteristic, and an interval between every two adjacent obtaining of the data of the second data type is longer than an interval between every two adjacent obtaining of the data of the first data type (see cited portions of [0008], [0066]-[0070], [0075]-[0076], and [0091] which teach that to determine step counts (data of a “second data type) from accelerometer data (data of a “first data type”), the accelerometer data must be accumulated (a plurality of accelerometer samples must be obtained before steps can be identified within the accelerometer data), i.e., the step count has an “accumulated characteristic”. Further, since the step data requires analysis over a plurality of accelerometer samples (e.g., for the buffer comprising samples from the “first time period” disclosed in [0066]-[0070]), the interval between quantifying the step data is necessarily longer than the interval between obtaining each accelerometer sample (e.g., the sampling rate disclosed in [0067]).).
It would have been obvious to have modified the data of the first data type, e.g., accelerometer data, and the data of the second data type, e.g., a step count derived from accelerometer data, as taught by Zhong in view of Kupermann such that the data of the second data type has an accumulated characteristic, and an interval between every two adjacent obtaining of the data of the second data type is longer than an interval between every two adjacent obtaining of the data of the first data type as taught by Weast. The methods of quantifying steps from obtained accelerometer data as taught by Weast provide the benefit of a low power, high-fidelity step counter in a wearable apparatus which improves battery life and reduces false positives in step counting by accumulating accelerometer data for analysis (Weast: [0056] and [0061]).
Applicant argues “those skilled in the art would have no motivation to modify Zhong's scheme into the scheme of claim 1 of the present disclosure. For example, if Zhong's GPS chip were to transmit a single location point to the application processor at different transmission frequencies without sending GPS data to the MCU, Zhong's normal mode and low power consumption mode could not be achieved, and the switching between normal mode and low power consumption mode would also be unrealizable”; however, the Examiner has not modified Zhong’s scheme to require the GPS chip transmitting “a single location point to the application processor at different transmission frequencies without sending GPS data to the MCU” as argued. The modification of the MCU of Zhong in view of Kupermann and Weast would merely require the MCU, e.g., while operating in the low power mode, collects and processes accelerometer data in real-time as described with respect to the analogous HW-IP block of Kupermann, and derives a step count from accumulated accelerometer data, and thus has an accumulated characteristic.
Accordingly, claim 1 is rejected as being unpatentable over Zhong in view of Kupermann, Hasegawa and Weast, and claim 23 is rejected as being unpatentable over Zhong in view of Kupermann and Weast.
Applicant’s arguments with respect to claim 22, see pages 16-17 of the Remarks filed 9/23/2025, have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Specifically, Applicant argues Zhong fails to teach the MCU does not send the wake-up condition to the application processor before the application processor sends the wake-up condition to the MCU. Examiner would like to point to paragraph [0213] which teaches the next-time wake-up condition (i.e., the wake-up condition for when the device switches to the low power mode for a non-first time), comprises a difference between a current exercise distance and an exercise distance for the next broadcast (i.e., the next time the application processor needs to be awoken), and further suggests the wake-up distance may be determined by the MCU based on a distance received from the application processor (see [0226]). The “current exercise distance” of the next-time wake-up condition would comprise GPS data previously sent from the MCU to the application processor (e.g., the data collected during a previous time the device was in a low power mode), and thus the next-time wake-up condition comprises data the MCU has reported to the application processor.
Regardless, Examiner has relied upon new reference, LEWIS (U.S. Pub. No. 2015/0160881) to teach the data to be recovered which is transferred from a second operation to a first operation system when the first operation system is restarting “is data that the first operation system has reported to the second operation system” (see cited portions of the Abstract, [0025]-[0026]) and target data is obtained by the first operation system by using the data to be recovered “as a base” (see cited portions of [0026]).
Accordingly, claim 22 is rejected as being unpatentable over Zhong in view of Kupermann and LEWIS.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Kahn et al. (U.S. Patent No. 8,320,578) teaches accumulating accelerometer data, and determining whether a step has been detected in the accumulated accelerometer data (see Col. 8, lines 8-13).
North (U.S. Patent No. 9,996,378) teaches a technique for failure monitoring and recovery of a first application executing on a first virtual machine includes storing machine state information during execution of the first virtual machine at predetermined checkpoints (see Abstract). It further teaches high-availability checkpointing is used to mirror a first virtual machine with an OS to another virtual machine with an OS by sending changed data periodically, such that if the first machine suffers a failure, the workload of the first VM can be resumed by the another VM from the last checkpoint with minimal loss of data (see Col. 2, lines 25-53).
LIN (U.S. Pub. No. 2016/0179626) teaches a coprocessor executing a hibernation procedure, which controls the CPU to backup status data to a non-volatile memory, and the subsequently coprocessor sending an awaking signal causing the CPU to read and load the backup status data according to the awaking signal (see [0043]-[0049]).
JEONG et al. (U.S. Pub. No. 2020/0249969) teaches a method for managing dynamic memory between a host operation system and a guest operating systems, wherein the host OS requests to recover memory previously transmitted to the guest OS (see [0090]-[0092]).
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 nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JENNIFER MARIE GUTMAN whose telephone number is (703)756-1572. The examiner can normally be reached M-F: 9:00 am - 5:00 pm.
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, Kevin Young can be reached at 571-270-3180. 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.
/JENNIFER MARIE GUTMAN/Examiner, Art Unit 2194 /KEVIN L YOUNG/Supervisory Patent Examiner, Art Unit 2194
Prosecution Insights