A wearable health measurement record time normalization method, system, device and storage medium based on time correction receipt and time uncertainty propagation

Abstract

The application discloses a wearable health measurement record time normalization method based on time correction feedback and time uncertainty propagation. A mobile terminal establishes a time correction transaction when writing a time zone and time to a wearable device, records device identification, firmware version, host sending and confirmation time, time zone parameters and command confirmation results; after time correction, the device clock offset and time uncertainty are calculated by using the feedback record with the device timestamp to form the time correction feedback. For historical or real-time health measurement records, the system only generates normalized measurement time based on the device time reference and clock offset when the time correction feedback matches the device, firmware, time interval and uncertainty; otherwise, the original time is retained and the time is output as untrusted. The system saves the records according to the time correction feedback boundary segmentation to avoid cross-day aggregation, repeated merging or incorrect sorting caused by time zone changes, device clock reset or Bluetooth transmission delay.

Description

Technical Field

[0001] This invention relates to the fields of Bluetooth communication for wearable devices, device clock synchronization, and health data processing, and particularly to a method, system, device, and storage medium for time normalization that verifies device time using time synchronization receipts and propagates time uncertainty to health measurement records. Background Technology

[0002] Wearable devices such as rings, watches, and bracelets typically record steps, sleep patterns, and real-time physiological measurements using their local clocks. Mobile devices read these records via Bluetooth and convert the device's second count or date and time to a unified time. However, if the device is powered off, restarted, offline for an extended period, its time zone changes, there are differences in daylight saving time settings, or the time synchronization command is not completed, the device's clock may become inconsistent with the mobile device's time. Furthermore, Bluetooth transmission has queuing and retry delays, so the recorded reception time cannot be simply used to replace the actual measurement time.

[0003] If an application only writes the current time to the device once without retaining command confirmation, device identifier, firmware version, echo time, and communication latency, it becomes impossible to determine the time zone and clock offset used for a historical record. Merging records from different time synchronization states by date or receiving time may incorrectly assign sleep segments spanning different days to the wrong date, mistakenly remove duplicates from records after clock rollback, or overwrite records with the same value but from different measurement periods.

[0004] Existing methods such as general clock synchronization or historical data transmission cannot directly solve the problem of time traceability of health records: the former typically does not propagate calibration reliability to each health record, while the latter usually only focuses on the frame transmission order without considering the relationship between the device clock, time zone, and actual measurement time. Therefore, a technical solution is needed that generates a verifiable receipt for the time calibration process and uses this receipt to determine whether health measurement records can participate in time sorting, merging, and cross-day calculations. Summary of the Invention

[0005] 3.1 Technical problems to be solved

[0006] This invention solves the following technical problems:

[0007] 1. How to prove that the device's time zone and time settings were successfully completed within a single Bluetooth session, rather than simply recording that the mobile terminal issued the setting command;

[0008] 2. How to establish the device clock offset and its uncertainty using command transmission time, device timestamp resolution, and echo records;

[0009] 3. How to ensure that each health measurement record is traceable to a specific time synchronization event, rather than mistaking the receiving time as the measurement time;

[0010] 4. How to prevent incorrect sorting, deduplication, and daily summarization across time boundaries when the device restarts, firmware changes, time zone changes, or clock jumps.

[0011] 3.2 Technical Solution

[0012] This invention employs a processing chain of "time synchronization, command confirmation, echo verification, offset and uncertainty calculation, record matching, and segmented isolation." The mobile terminal can be a mobile phone, tablet, or gateway; the target device can be a ring, watch, bracelet, or other wearable device with a local clock and Bluetooth interface.

[0013] 3.2.1 Time synchronization matters and confirmation receipts

[0014] After a successful device connection, the mobile terminal does not directly consider "time synchronization command sent" as a conclusion that the device has been calibrated. Instead, it generates a time synchronization transaction corresponding to clockSyncId. In one embodiment, the transaction stores the device identifier, firmware identifier, connection identifier, host reference time hostReferenceMs, host timezone offset timezoneOffsetMinutes, timezone setting command and time setting command, the monotonic sending time of each command, and the acknowledgment receiving time.

[0015] The system first sets the time zone, obtains confirmation, and then sets the device time. This process is repeated until the device interprets the year, month, day, hour, minute, and second as its local time, consistent with the time zone parameters. Any command write failure, confirmation timeout, connection switch, or device identifier change will result in the time synchronization transaction failing. Failed transactions do not generate time synchronization receipts that can be used for normalization.

[0016] A time synchronization transaction can be represented as:

[0017] {

[0018] "clockSyncId": "clock_8f3a",

[0019] "deviceId": "ring_001",

[0020] "firmwareVersion": "1.2.3",

[0021] "hostReferenceMs": 1780000000000,

[0022] "timezoneOffsetMinutes": 480,

[0023] "timezoneSentMonotonicMs": 90001,

[0024] "timezoneAckMonotonicMs": 90120,

[0025] "timeSentMonotonicMs": 90135,

[0026] "timeAckMonotonicMs": 90260,

[0027] "state": "confirmed"

[0028] }

[0029] The monotonic moments are used to calculate transmission intervals and are unaffected by changes in the host wall clock during time synchronization. This example is for illustrative purposes only and does not represent actual device identification or performance records.

[0030] 3.2.2 Calculation of Offset and Uncertainty

[0031] After command confirmation, the system reads the echo record, real-time record, or historical record containing the device's original timestamp. The device's original timestamp is converted to deviceEpochMs relative to the device's defined time base. The host time interval is obtained using the host's monotonic transmit and receive times adjacent to this record and the host reference time; the midpoint of the interval can be used as an estimated reference time, and the following calculations are performed:

[0032] clockOffsetMs = hostReferenceAtEchoMs - deviceEpochMs

[0033] uncertaintyMs>= (echoReceiveMonotonicMs - echoSendMonotonicMs) / 2 +deviceTimestampResolutionMs

[0034] The hostReferenceAtEchoMs is obtained from the host reference time and the monotonic time difference. In practice, a more conservative upper bound on the communication delay, the write activation point defined by the device protocol, or the median of multiple echoes can be used; however, the calculation rules, sample size, and uncertainty must be saved in the time synchronization receipt. Without an echo record, the offset cannot be fabricated as zero based on the send time of the write command.

[0035] A time synchronization receipt should include at least the clockSyncId, device and firmware identifier, time base, offset, uncertainty, time zone parameters, device timestamp, valid start and end conditions, and status. A valid end condition can be any of the following: maximum time synchronization age, device disconnection and reconnection, device restart, firmware version change, time zone change, or detection of an abnormal clock transition.

[0036] 3.2.3 Measurement record normalization and reliability status

[0037] When reading records such as steps, sleep, heart rate, blood oxygen, heart rate variability, stress, blood pressure, blood glucose, or PPG collection summaries, the system first retains the original device timestamp and mobile terminal reception time from the protocol. Only when the recorded device identifier, firmware identifier, and time range match a valid time synchronization receipt, and the uncertainty of that receipt does not exceed the threshold corresponding to that metric type, is the calculation performed.

[0038] normalizedMeasuredAtMs = deviceEpochBaseMs + rawDeviceTimestamp *1000 + clockOffsetMs

[0039] For each record, the system saves clockSyncId, normalizedMeasuredAtMs, uncertaintyMs, timeTrustState, rawDeviceTimestamp, and receivedAtMs. receivedAtMs is used for handling arrival order and anomaly troubleshooting and cannot replace normalizedMeasuredAtMs. For records that are uncalibrated, have expired receipts, time zone conflicts, firmware changes, suspected device clock resets, or excessive transmission delays, the system retains the original fields, outputs an untrusted status, and avoids their direct participation in merging and cross-day calculations that rely on actual measurement times.

[0040] 3.2.4 Time segmentation, deduplication, and cross-day boundaries

[0041] The system uses clockSyncId as the time segment boundary and continuously monitors the original timestamps of consecutive devices. When the device time changes forward or backward relative to the previous record by more than a threshold, and there is no new valid time synchronization receipt to explain the change, the system ends the current segment and writes the clock anomaly reason.

[0042] For records of the same type with similar measurement times, the system first verifies whether they come from the same time synchronization transaction. Only when the time synchronization transactions are the same, or the uncertain intervals of the two normalized times meet the preset overlap relationship, will the system further determine whether they are duplicates based on the device record identifier, sampling sequence number, or measurement value summary. This step avoids mistakenly merging records with the same value from different time periods due to device callback or reception delay.

[0043] Sleep sessions or daily statistics only use continuous and time-reliable segments. When crossing midnight, the system determines date boundaries based on normalized measurement time and time zone parameters in the receipt; for unreliable segments, only the original records and abnormal states are retained, with a decision made on whether to supplement the summary after the next successful time synchronization or manual review. This process does not output disease diagnoses or infer any medical conclusions.

[0044] 3.3 Beneficial Effects

[0045] Compared to methods that simply write the current time to the device and sort by the recorded reception time, this invention has at least the following verifiable technical advantages:

[0046] 1. By saving the order of time zone and time commands, confirmation results, and device echo records, it is possible to distinguish between different states: command sent, command confirmed, and device time verifiable.

[0047] 2. By converting communication delay and device timestamp resolution into time uncertainty, upper-layer data processing can reject records that do not have sufficient time reliability;

[0048] 3. By associating clockSyncId with the trusted time status to each health measurement record, the time source of the record can be traced, preventing the arrival time from masking device clock anomalies;

[0049] 4. By segmenting transactions and clock transitions by time synchronization, the risks of cross-day classification errors, incorrect deduplication, and incorrect merging caused by time zone changes, device restarts, or clock rollbacks can be reduced.

[0050] The above results can be verified by Bluetooth command logs, time synchronization receipts, original device timestamps, normalization results, and segmented state reproduction, but do not include diagnostic accuracy, clinical efficacy, or health improvement promises. Attached Figure Description

[0051] Figure 1 shows the overall architecture of mobile terminals, wearable devices, time synchronization transactions, and health record storage.

[0052] Figure 2 is a sequence diagram of time synchronization tasks, including time zone setting, time setting, confirmation, and time display.

[0053] Figure 3 shows the data structure and validity judgment flowchart of the time synchronization receipt.

[0054] Figure 4 is a flowchart of matching health measurement records with time synchronization receipts and generating normalized measurement times.

[0055] Figure 5 is a flowchart of time segmentation under time zone changes, firmware changes, device restarts, and clock jumps.

[0056] Figure 6 shows the constraints for deduplication, merging, and cross-day aggregation based on time synchronization transactions and uncertain intervals. Detailed Implementation

[0057] 5.1 Engineering Fundamentals of Time Fields in Wearable Devices

[0058] The ring Bluetooth service in this project already has the capability to set time zones and device time: time zones are encoded in 15-minute units, and time commands include year, month, day, hour, minute, and second; the synchronization function first writes the time zone, then the time, and records the most recent time synchronization result. Device-side timestamps are also retained in device history and real-time data parsing and converted to milliseconds counting from the device-defined start point. Related project references can be found in `miniprogram / services / RingBleMiniprogram.js`, including `setTimezone`, `setTime`, `syncDeviceTime`, `secondsSince2000ToEpochMs`, and various historical record parsing logic; the mobile PPG saving logic distinguishes between recorded time and the original data collection object, see `health-app / services / RingTaskExecutor.js`.

[0059] The applicant confirms that the minimum prototype and real machine or protocol simulation playback of the echo verification, offset calculation, time uncertainty propagation, and cross-time segmentation described in this invention have been completed. This confirmation serves to support the implementability of this draft; the prototype, raw logs, and playback results should still be archived in a controlled manner, and the above design should not be presented as already deployed or its performance verified.

[0060] 5.2 Example of Time Synchronization Receipt

[0061] After connecting to ring_001, the mobile terminal creates a time synchronization transaction. The terminal calculates the current time zone offset in 15-minute increments, sends a time zone command, and waits for protocol confirmation. Upon successful confirmation, it sends a time command and records the monotonic transmission and confirmation times of both commands. Subsequently, it reads the real-time heart rate record from the device, which includes a second-level device timestamp. The terminal uses the monotonic transmission and reception times of this read request to define a communication interval, and uses the device timestamp resolution and half of the communication interval to define a lower bound for uncertainty.

[0062] If the device identifier, firmware version, and connection identifier of the read record are consistent with the time synchronization transaction, the terminal generates a time synchronization receipt with a status of "calibrated". If any step of the write confirmation or subsequent echo fails, the receipt status is "untrusted", and the system does not assign a new normalized time to the record of that device.

[0063] 5.3 Example of Historical Record Processing

[0064] The terminal reads a batch of step counts and sleep records. Each raw record contains at least the device's original timestamp, metric type, value or status, device identifier, and reception time. The system selects valid time synchronization receipts based on the raw timestamps of the records. If the selected receipt meets the threshold, the system saves the normalized time and the corresponding uncertainty; if the raw timestamps in the batch of records are backwards and there are no new receipts, the system creates a new segment, writes it to clock_jump_suspected, and excludes this segment from the automatic sleep session splicing.

[0065] For two step records whose normalized time difference is less than the merge window, the system merges them only if they belong to the same time synchronization transaction, or if their uncertain intervals satisfy a preset overlap and the device record identifiers are the same. Records with the same value but different time segments are not considered duplicates simply because the values ​​are equal.

[0066] 5.4 Failure Handling and Auditing Fields

[0067] The time synchronization, echo, and normalization processes can use the following status codes: timezone_write_failed, time_write_failed, time_write_unacknowledged, echo_missing, echo_device_mismatch, uncertainty_exceeded, firmware_changed, timezone_changed, and clock_jump_suspected. Each failure saves the time synchronization transaction identifier, device identifier, firmware identifier, command stage, timestamp, and reason code; failures should not be silently replaced with "calibrated".

[0068] 5.5 Submission Replay Validation and Boundaries

[0069] The applicant confirms that real device or protocol simulation playback has been completed for normal time synchronization, time zone switching, time write confirmation failure, Bluetooth interruption, device restart, device clock rollback, firmware upgrade, and historical record delay arrival. Command sending / confirmation logs, original timestamps, receipts, normalization results, and segmentation judgments for each playback should be archived as controlled evidence and reviewed by the actual inventor. The verification scope is used to confirm that untrusted records will not be incorrectly incorporated into trusted segments; this draft does not advocate PPG filtering, health prediction, disease diagnosis, historical frame cursor advancement, or hot updates of device policies.

Claims

1. A time normalization method for wearable health measurement records based on time synchronization receipts and time uncertainty propagation, characterized in that, include: After the mobile terminal establishes communication with the target wearable device, a time synchronization transaction is created. The time synchronization transaction includes at least a time synchronization transaction identifier, a target wearable device identifier, a device firmware identifier, a host reference time, a host time zone parameter, a host transmission monotonic time, and a time synchronization validity period. Time zone setting commands and time setting commands are sent to the target wearable device in a preset order, and confirmation results corresponding to the time zone setting commands and time setting commands are obtained respectively; after obtaining the confirmation results, a time echo record or health measurement record with the original timestamp of the device is obtained from the target wearable device, and the device clock offset and time uncertainty are calculated based on the monotonic time sent by the host, the monotonic time of the confirmation result, the host reference time and the original timestamp of the device, and a time synchronization receipt is generated; a health measurement record to be normalized containing the original timestamp of the device is received, and a time synchronization receipt is matched for the health measurement record to be normalized; When the device identifier and device firmware identifier in the time synchronization receipt are consistent with the health measurement record to be normalized, the original timestamp of the device is within the valid time period of the time synchronization receipt, and the time uncertainty is not greater than a preset threshold, a normalized measurement time is generated based on the device time base, the original timestamp of the device, and the device clock offset. The normalized measurement time, the time synchronization transaction identifier, the time uncertainty, and the time reliability status are associated and saved with the health measurement record to be normalized. When no time synchronization receipt is matched, the device identifier or firmware identifier is inconsistent, the original timestamp of the device crosses the time synchronization receipt boundary, or the time uncertainty is greater than the preset threshold, the original timestamp of the device and the receiving time are retained, the time unreliable status is output, and the normalized health measurement record is prohibited from being directly merged with the records corresponding to different time synchronization receipts according to the same measurement time.

2. The method according to claim 1, characterized in that, The parameters of the time zone setting command include the host time zone offset expressed in a preset time unit, and the parameters of the time setting command include year, month, day, hour, minute, and second; the preset order is to first send the time zone setting command and obtain a confirmation result, and then send the time setting command and obtain a confirmation result, so that the device local date interpretation in the same time synchronization receipt has the corresponding time zone parameters.

3. The method according to claim 1, characterized in that, The time synchronization transaction also includes time zone setting command bytes, time setting command bytes, command sending time, confirmation receiving time, communication round-trip time, device connection identifier, and time synchronization failure reason code; if any setting command is not confirmed, the time synchronization transaction is marked as failed, and no usable time synchronization receipt is generated for subsequent health measurement records to be normalized.

4. The method according to claim 1, characterized in that, The time uncertainty is determined at least based on the difference between the monotonic moment of sending the time setting command and the monotonic moment of acknowledgment of receipt, the resolution of the device's original timestamp, and the reception delay of the time echo record or health measurement record; the time uncertainty is set to unreliable when it exceeds a preset threshold, the device is reconnected, the device is restarted, the device firmware changes, the time zone parameter changes, or the time synchronization validity period expires.

5. The method according to claim 1, characterized in that, The device time reference is the starting time defined by the target wearable device; the normalized measurement time is calculated from the starting time, the original timestamp of the device, and the clock offset of the device; the receiving time does not replace the normalized measurement time, but is used to calculate the time uncertainty and retain the arrival order in the case of time unreliability.

6. The method according to claim 1, characterized in that, For multiple health measurement records belonging to the same measurement type and whose normalized measurement times differ by no more than the merging window, deduplication or merging is performed only if their time synchronization transaction identifiers are the same or if there is a preset overlap relationship in the uncertain intervals of their normalized measurement times. For records with different time synchronization transaction identifiers and whose uncertain intervals do not meet the preset overlap relationship, they are saved as records of different time periods.

7. The method according to claim 1, characterized in that, The health measurement records to be normalized include at least one of the following: steps, sleep status, heart rate, blood oxygen, heart rate variability, stress value, blood glucose value, blood pressure value, or photoplethysmography (PPG) pulse wave acquisition summary; the time reliability status includes at least calibrated, uncalibrated, expired receipt, time zone conflict, firmware change, suspected clock reset, and excessive transmission delay.

8. The method according to claim 1, characterized in that, The system divides the time segments of health measurement records according to the time synchronization transaction identifier; when it detects that the original timestamp of a continuous device has a reverse jump or forward jump greater than the preset threshold relative to the previous record, and the current record does not match a new valid time synchronization receipt, the current time segment ends, the cause of the clock abnormality is recorded, and the current record is prohibited from participating in the daily summary or sleep session boundary calculation across segments.

9. A wearable health measurement recording time normalization system based on time synchronization receipt and time uncertainty propagation, characterized in that, include: The time synchronization transaction module is used to create time synchronization transactions that include host reference time, time zone parameters, and monotonic time. The command confirmation module is used to send time zone setting commands and time setting commands in sequence and obtain confirmation results; the time synchronization receipt module is used to calculate the device clock offset and time uncertainty based on the device's original timestamp and the monotonic moments of the host's transmission and reception. The record matching module is used to match time synchronization receipts for health measurement records to be normalized; The time normalization module is used to generate normalized measurement times when the matching conditions are met; And a time segmentation module, used to save unreliable time states and isolate health measurement records of different time synchronization transactions when matching conditions are not met or clock jumps are detected.

10. An electronic device, characterized in that, The method includes a processor, a memory, a Bluetooth communication interface, and a computer program stored in the memory and executable by the processor, wherein the processor executes the computer program to implement the method according to any one of claims 1 to 8.

11. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method according to any one of claims 1 to 8.

Images