Synchronization objects for multi-device synchronization

Abstract

The present disclosure relates generally to synchronization objects for multi-device synchronization. A first user device associated with a user profile can receive a health database from a service provider configured to store the health database associated with the user profile. The first user device can receive first health information associated with the user profile. The first user device can generate a first health synchronization object based on the first health information. The first health synchronization object can include a first synchronization identity including a first hardware identifier indicative of the first user device and a first database identifier indicative of the health database. The first user device can determine to send the first health synchronization object to the service provider based on the first user device being responsible for sending health synchronization objects with the first synchronization identity to the service provider. The first user device can send the first health synchronization object to the service provider.

Description

[0001] This application is a divisional application of the application with international application number PCT / US2024 / 032370, international application date of June 4, 2024, entry into the Chinese national phase date of December 5, 2025, national application number 202480038062.3, and invention title "Synchronization Object for Multi-Device Synchronization". Cross-references to related applications

[0002] This application claims priority to U.S. Non-Provisional Application Serial No. 18 / 732,217, filed June 3, 2024, entitled “SYNCING OBJECTS FOR MULTIDEVICESYNCHRONIZATION,” which claims the benefit of U.S. Provisional Application Serial No. 63 / 471,232, filed June 5, 2023, entitled “MULTIDEVICESYNCHRONIZATION OF HEALTH INFORMATION,” each of which is incorporated herein by reference in its entirety. Background Technology

[0003] Electronic devices, especially portable electronic user devices, are rapidly becoming ubiquitous in modern society. These devices can be used to collect and store personal information about users, such as health data. Summary of the Invention

[0004] A system comprising one or more computers can be configured to perform a specific operation or action by means of software, firmware, hardware, or a combination thereof installed on the system, which, in operation, causes the system to perform the action. One or more computer programs can be configured to perform an action by means of instructions including instructions that, when executed by a data processing device, cause that device to perform a specific operation or action. One general aspect includes a computer-implemented method. The computer-implemented method includes receiving a health database from a service provider at a first user device associated with a user profile. The health database may be associated with the user profile. The service provider may be configured to store the health database. The computer-implemented method further includes receiving first health information associated with the user profile and at least partially collected by the first user device at the first user device. The computer-implemented method further includes generating a first health synchronization object at the first user device based on the first health information. The first health synchronization object may include a first synchronization identity, which includes a first hardware identifier indicating the first user device and a first database identifier indicating the health database. The computer-implemented method further includes determining, at the first user device, to send the first health synchronization object to the service provider based on the first user device being responsible for sending the health synchronization object with the first synchronization identity to the service provider. The computer-implemented method also includes sending the first health synchronization object to the service provider.

[0005] Another general aspect includes another computer-implemented method. The computer-implemented method includes sending a health database from a service provider to a first user equipment. The health database may be associated with a user profile. The service provider may be configured to store the health database. The computer-implemented method includes receiving a first health synchronization object from the first user equipment at the service provider. The first health synchronization object may be based on first health information collected at least partially at the first user equipment. The first health synchronization object may include a first synchronization identity, which includes a first hardware identifier indicating the first user equipment and a first database identifier indicating the health database. The computer-implemented method includes identifying a second user equipment at the service provider to receive the first health synchronization object. The second user equipment may be associated with the health database. The computer-implemented method includes determining that the first synchronization identity is different from a second synchronization identity associated with the second user equipment. The computer-implemented method includes sending the first health synchronization object to the second user equipment based on the determination that the first synchronization identity is different from the second synchronization identity.

[0006] Another general aspect includes another computer-implemented method. The computer-implemented method includes receiving, at the master device, a first health synchronization object based on first health information associated with a user profile. The user profile may be associated with a health database. A service provider may be configured to store the health database. The first health synchronization object may include a first synchronization identity, which includes a first hardware identifier indicating a secondary device and a first database identifier indicating the health database. The secondary device may be configured to send the first health synchronization object to the service provider. The computer-implemented method includes receiving, at the master device, an indication that the secondary device has not yet sent the first health synchronization object to the service provider according to a timing standard. The computer-implemented method includes sending the first health synchronization object to the service provider.

[0007] Another general aspect includes another computer-implemented method. The computer-implemented method includes receiving first health information associated with a user profile at a secondary device. The user profile may be associated with a health database stored by a service provider. The computer-implemented method includes generating a first health synchronization object at the secondary device based on the first health information. The first health synchronization object may include a first synchronization identity, which includes a first hardware identifier indicating the secondary device and a first database identifier indicating the health database. The secondary device may be configured to send the first health synchronization object to the service provider. The computer-implemented method includes sending the first health synchronization object to a primary device. The computer-implemented method includes determining, based on a timing criterion, that the secondary device has not yet sent the first health synchronization object to the service provider. The computer-implemented method includes sending an indication to the primary device that the secondary device has not yet sent the first health synchronization object to the service provider. This indication may be configured to cause the primary device to send the first health synchronization object to the service provider. Attached Figure Description

[0008] Figure 1 A block diagram illustrating the synchronization of health information across multiple devices, based on at least one example, is shown.

[0009] Figure 2 A block diagram illustrating the use of synchronized identities across multiple devices is shown, based on at least one example.

[0010] Figure 3 A flowchart illustrating a process for synchronizing health information using synchronized identities across multiple devices, based on at least one example, is provided.

[0011] Figure 4 A flowchart illustrating a process for synchronizing health information using synchronized identities across multiple devices, based on at least one example, is provided.

[0012] Figure 5A flowchart illustrating a process for synchronizing health information using synchronized identities across multiple devices, based on at least one example, is provided.

[0013] Figure 6 A block diagram illustrating the synchronization of health information across primary and secondary devices, based on at least one example, is shown.

[0014] Figure 7 A flowchart illustrating a process for synchronizing health information across a primary and secondary device, based on at least one example, is provided.

[0015] Figure 8 A flowchart illustrating a process for synchronizing health information across a primary and secondary device, based on at least one example, is provided.

[0016] Figure 9 A flowchart illustrating a process for synchronizing health information across a primary and secondary device, based on at least one example, is provided.

[0017] Figure 10 A block diagram illustrating, based on at least one example, for synchronizing health information across multiple devices using various synchronization methods.

[0018] Figure 11 Example architectures or environments are illustrated, based on at least one example, that are configured to implement technologies related to sharing health data updates between user devices and identifying changes in health data.

[0019] Figure 12 An electronic device is illustrated according to at least one example for implementing technologies related to sharing and identifying changes in health data for updating health data between user devices.

[0020] Figure 13 A simplified block diagram according to at least one example is illustrated, which includes components of an example electronic device for implementing techniques related to the sharing of health data updates between user devices and the identification of changes in health data.

[0021] Figure 14 A simplified diagram based on at least one example is illustrated, which includes an example electronic device for implementing technologies related to the sharing of health data updates between user devices and the identification of changes in health data. Detailed Implementation

[0022] Certain embodiments of this disclosure relate to apparatuses, computer-readable media, and methods for implementing various features of multi-device synchronization for health information. Various embodiments will be described in the following description. For purposes of explanation, numerous specific configurations and details are set forth to provide a thorough understanding of the embodiments. However, it will also be apparent to those skilled in the art that these embodiments can be implemented without these specific details. Furthermore, well-known features may be omitted or simplified to avoid obscuring the embodiments described herein.

[0023] The examples disclosed herein particularly relate to methods, systems, devices, and computer-readable media that provide mechanisms for synchronizing health information across multiple devices. The techniques described herein enable the synchronization of health information across multiple devices (including various types of devices) associated with a single profile (e.g., a single user account used on each of multiple devices). Example devices may include telephones, smartwatches, laptops, computers, computing devices, or any electronic user equipment.

[0024] In some conventional health information sharing systems involving multiple devices, the synchronization of health information across multiple devices (also known as synchronization or syncing) involves having a source of truth at a single device or service provider. Each device in the multi-device health information system can receive or generate health information and send it to the source of truth. When a device is sending health information to the source of truth, the synchronization operation can be called outgoing synchronization (or outgoing sync). When a device is receiving health information from the source of truth, the synchronization operation can be called incoming synchronization (or incoming sync).

[0025] Health information stored at the true source can be mirrored at each device. For a device to be the true source of all health information across multiple devices, a multi-device health information system may require a robust, fast, bandwidth-intensive, and power-intensive information synchronization system to ensure the true source has up-to-date health information from all devices to mirror across multiple devices. Such a multi-device health information system may require constant transmission of information from devices to the true source device / service provider, which will be bandwidth- and power-intensive for all involved devices. Synchronization from the device receiving / generating health information to the true source may require each specific device to send all health information at that specific device to verify that the true source has received all health information from that specific device. This can lead to redundant transmissions of health information already synchronized across multiple devices to the true source device / service provider. Similarly, health information synchronization with devices will require verifying that all health information from the true source is mirrored at each device. Therefore, each synchronization operation for a specific device may require some form of packaging or verification of all health information.

[0026] The techniques described herein enable each device in a multi-device health information system to optimize the outgoing synchronization of health information received or generated at a specific device to a real source. Similarly, the techniques described herein enable each device in a multi-device health information system to optimize the incoming synchronization of health information generated or synchronized at other devices from a real source. In this way, the synchronization of health information across a multi-device health information system does not require continuous mirroring and verification of all health information at each device. Here, whenever health information is received or generated at a specific device, that specific device adds an immutable synchronization identity to the health information. The synchronization identity is associated with the specific device and designates the specific device as responsible for the outgoing synchronization of health information. By using the synchronization identity, the specific device can determine which health information, such as health information generated or received at the specific device, should be included in the outgoing synchronization to the real source. The specific device can divide the health information into two groups: 1) health information that the specific device is responsible for synchronizing to the real source; and 2) health information that the specific device can trust another device to be responsible for synchronizing to the real source. Similarly, by using synchronization identities, the originating source can determine which health information to include in incoming synchronization to a specific device, such as health information generated or received at other devices in a multi-device health information system. When sending health information to a user device, the service provider can divide the health information into two groups: 1) health information not synchronized to the user device because the user device is responsible for and therefore already has the health information; and 2) health information to be synchronized to the user device because the user device is not responsible for the health information. This type of technology reduces the resources required to synchronize health information across multiple devices at both the originating source and each device.

[0027] Turning to a first specific example, a first user device (e.g., a smartphone) can perform an outgoing synchronization operation by synchronizing health information to a real source (e.g., a service provider) using the first user device's synchronization identity. This operation is considered an outgoing synchronization operation because, from the first user device's perspective, the health information is being sent out to the service provider. The first user device may have a health database (which may also be referred to as a health information data repository or health data repository) synchronized to the service provider's health database. The first user device may receive first health information associated with a user profile (also referred to as an account). For example, the first user device may receive the information by the user inputting health information into the first user device or via the first user device's sensors. The first user device may generate a first health synchronization object (also referred to as a health information object) based on the first health information. The health synchronization object may represent a basic unit of health information that can be synchronized between the first user device, the real source, and any other device in a multi-device health information system. When the first health synchronization object is generated by the first user device, the first health synchronization object includes an immutable synchronization identity associated with the first user device. The synchronization identity may include a hardware identifier indicating the first user device. The synchronization identity may also include a first database identifier indicating the health database associated with the user. In some examples, the first database identifier indicates a health database on the first user device. In some examples, the first database identifier indicates a service provider's health database, such that all user devices connected to the service provider's health database will use the same first database identifier. When the first user device performs an outgoing synchronization operation, the first user device identifies a health synchronization object (e.g., a first health synchronization object) with the synchronization identity of the first user device. The first user device can then synchronize these health synchronization objects to the real source. In some examples, the first user device is responsible for performing outgoing synchronization operations for health synchronization objects with synchronization identities other than those described herein. For example, the first user device may be responsible for synchronizing health synchronization objects of auxiliary devices (e.g., connected smartwatches) associated with the first user device or a deactivated user device.

[0028] Turning to a second specific example, a real source (e.g., a service provider) can perform an incoming synchronization operation on a first user device (e.g., a tablet) by synchronizing health information to the first user device using a synchronization identity of a second user device (e.g., a smartphone). This operation is considered an incoming synchronization operation because the health information is incoming from the perspective of the first user device. The service provider may have a health database synchronized to both the first and second user devices. The service provider may receive a second health synchronization object from the second user device, which is generated by the second user device after receiving the second health information. The second health synchronization object may have an immutable second synchronization identity associated with the second user device. The second synchronization identity may include a hardware identifier indicating the second user device. The second synchronization identity may also include a first database identifier indicating the health database associated with the user. In some examples, the first database identifier indicates the service provider's health database such that all user devices connected to the service provider's health database will use the same first database identifier. In some examples, the second synchronization identity may include a second database identifier indicating the health database on the second user device. The service provider may store information about which devices are associated with which synchronization identities. For example, the service provider may store information about the second user device associated with the second synchronization identity. Similarly, the service provider knows that the first user device is associated with the first synchronization identity. When the service provider receives a second health synchronization object, it may identify that the first user device has the first synchronization identity and has not yet received the second health synchronization object. In some examples, the service provider may track health synchronization objects received since the last incoming synchronization operation to the first user device. In some examples, when performing an incoming synchronization operation to the first user device, the service provider includes some or all health synchronization objects with synchronization identities other than the synchronization identity of the first user device. In some examples, the service provider knows that the first user device is responsible for multiple synchronization identities, such that the service provider includes some or all health synchronization objects with synchronization identities other than the synchronization identity responsible for the first user device.

[0029] The techniques described herein also enable a primary user device (e.g., a smartphone) to perform outgoing and incoming synchronization operations with a real source (e.g., a service provider) on behalf of an associated secondary user device (e.g., a smartwatch). As described herein, a secondary user device can be a device with limited functionality paired with a primary user device. In one example, the primary device is a smartphone, and the associated secondary device is a smartwatch. Due to hardware or software limitations, a smartwatch may have limited functionality compared to a smartphone. For example, a smartwatch may have limited memory, storage capacity, bandwidth, network capabilities, battery, and / or processing power compared to a smartphone. In another example, the primary device is a smartphone, and the secondary device is a smartphone with relatively limited functionality. Here, a smartphone with limited functionality may have limited functionality in the form of limited network capabilities, limited processing power, limited battery, or software limitations or other restrictions. The primary user device may be referred to as the parent device, and the secondary user device may be referred to as the child device.

[0030] As described herein, a primary user equipment (PUE) performs outgoing and incoming synchronization operations to a service provider on behalf of an associated secondary user equipment (SUE). In some examples, the PUE may connect, send, and receive information from the SUE via a less resource-intensive communication channel. For example, the PUE and SUE may communicate via a local area network (LAN) (e.g., WiFi) or a short-range communication medium (e.g., Bluetooth). This contrasts with potentially more resource-intensive long-range communication media (such as cellular networks). In this example, the SUE generates health synchronization objects from health information received by the SUE and then sends these health synchronization objects to the PUE. After a timing standard expires (e.g., within a period of time after the SUE has generated the health synchronization objects), the SUE may determine that it has not yet sent its health synchronization objects to the service provider. The SUE may send an instruction to the PUE instructing the PUE to perform outgoing synchronization operations for the health synchronization objects generated by the SUE. In some examples, the PUE may send a request to the SUE, inquiring whether the SUE has already performed outgoing synchronization operations for the health synchronization objects generated by the SUE.

[0031] However, in some examples, the secondary user equipment (SPUE) can perform outgoing synchronization operations to the real source on its own behalf under certain conditions. For example, the SPUE can communicate using a local area network (LAN) and a wide area network (WAN), and communicate with the real source via an extension.

[0032] Turning to a third specific example, a primary user device (e.g., a smartphone) can perform an outgoing synchronization operation to a real source (e.g., a service provider) on a health synchronization object received from a secondary user device (e.g., a smartwatch). Here, the secondary user device receives first health information and generates a first health synchronization object. For example, the smartwatch uses sensors to detect the user's heart rate. The secondary user device then generates the first health synchronization object based on the first health information. The first health synchronization object includes a first synchronization identity. The first synchronization identity may include a first hardware identifier associated with the secondary device and a database identifier associated with a database of the user's health information. The secondary user device sends the first health synchronization object to the primary user device. In some examples, after a timing criterion expires, the secondary user device sends an instruction to the primary user device indicating that the primary user device should send the first health synchronization object to the service provider. In some examples, after a second timing criterion expires, the primary user device sends a request to the secondary user device, inquiring whether the secondary user device has already sent the first health synchronization object to the service provider. The secondary user device can respond, indicating that it has not yet sent the first health synchronization object to the service provider. Here, the primary user equipment can send the first health synchronization object to the service provider.

[0033] The techniques described herein also enable user devices (e.g., smartphones) to perform outgoing and incoming synchronization operations to a real source (e.g., a service provider) using one or more synchronization methods. Different types of health information can be synchronized using different synchronization methods (in outgoing or incoming operations). Example types of health information may include streaming information, status information, and analytics information. In some examples, streaming information can be synchronized by changing the synchronization method (also referred to as synchronization). In some examples, status information can be synchronized via a status synchronization method. In some examples, analytics information can be synchronized via a context synchronization method.

[0034] Streaming information can include information representing changes over time. For example, streaming information can include step tracking, calorie burning, medication taken over time, heart rate, and any other suitable data or information that changes over time. Streaming data can be considered unbounded because it does not represent the absolute state of information, but rather changes from a previous state. Health information representing streaming information from a user device can be synchronized to the service provider and eventually to other user devices via a change synchronization method. The change synchronization method can send changes in the health information to the service provider via an outgoing synchronization operation. The change synchronization method can also include the service provider sending changes in the health information to other user devices via an incoming synchronization operation. In this way, the change synchronization method represents a stream of changes in health information that is periodically synchronized across service providers and user devices. When used for all types of health information, this type of streaming information, which maintains synchronization across multiple devices via a change synchronization method, can burden user devices' bandwidth consumption, network resources, computing / processing power, and battery life. Therefore, the change synchronization method can be used only for critical health information or health information that can be best represented as a change log. Examples of health information that can be best represented by changing the synchronization log include step tracking, calorie burn, heart rate, etc. However, changing the synchronization method may not be optimal when the device has limited resources for bandwidth, network, computing / processing power, and / or battery life. For example, syncing health information to a smartwatch via a different synchronization method may place excessive demands on the smartwatch's resources, such as bandwidth, network, and battery life.

[0035] Another type of health information can be status information. Status information represents a bounded segment of information that indicates the actual state of the information. Status information differs from streaming information intended to convey changes that have already occurred. In some examples, status information is defined to a time window, such that the status information represents the actual state during that time window. For example, a user's current list of medications can be stored as status information because the current list of medications represents the actual state of the medication list. Examples of streaming information associated with a medication list could be changes in medication dosage or changes in medication over time. Other examples of status information could include a list of a user's illnesses, ailments, and conditions at a specific time.

[0036] State information can be synchronized between user devices (e.g., smartphones, smartwatches, tablets, laptops, etc.) and a real source (e.g., a service provider) via state synchronization methods. State synchronization methods can be used to synchronize state information across multi-device health information systems. State synchronization methods enable user devices and service providers to send the actual state of health information, rather than changes in health information over time (e.g., streaming information as described herein). State synchronization methods can provide a high level of consistency and accuracy for health information represented as state information across multiple user devices, because each user device knows that the state information represents the actual health information, not the stream of changes to health information as seen in streaming information. State synchronization methods can also reduce the resources required to synchronize health information at user devices and service providers by reducing the need to constantly send and receive changes to health information. In some examples, streaming information can be delimited into state information. In one example, a user's medication history is a stream of medication names and dosages represented by streaming information. The dosage stream can be delimited into a window representing the history of dosage streams taken during a specific time window. By delimiting the dosage stream within a window, the dosage history becomes a state that can be synchronized via state synchronization methods.

[0037] Synchronizing health information via state synchronization methods can be less resource-intensive than changing synchronization methods. For example, changing synchronization methods can involve transmitting a stream of changes to health information over time so that the health information eventually becomes consistent across multiple devices. In one example, tracking taken medications via changing synchronization could include updates each time the medication is taken. This type of synchronization may place demands on bandwidth, network, computing / processing power, and / or battery life at the user's device and / or service provider. Alternatively, tracking taken medications as a state represents the state of the medication taken at a specific time or during a specific window. State synchronization can achieve relatively fast consistency across multi-device health information systems because the synchronization of health information represents a panorama of health information at a specific time, rather than a best-effort delivery of changes to health information over time.

[0038] Another type of health information can be stored as analytical information on both the user's device and the service provider. Analytical information includes observations, recommendations, diagnoses, algorithms, predictions, and any other suitable information that can be used for analysis, based on raw health information. For example, diagnosing a person with a disease or ailment based on symptoms is an example of analytical information. Analytical information is highly dependent on the algorithms and / or processing of the raw health information. Raw health information may include symptoms, heart rate, temperature, blood oxygen, etc. However, the algorithms used in different health applications can change with the version of the application. Algorithms can also differ based on computing and / or other resources on the user's device, or can change due to updates in science / understanding. To synchronize analytical information across multiple devices with potentially different algorithms, context synchronization methods can be used to synchronize applicable health information.

[0039] Analytical information can be synchronized between user devices (e.g., smartphones, smartwatches, tablets, laptops, etc.) and the real source (e.g., the service provider) via context synchronization methods. One way to use context synchronization methods is to synchronize analytical information across multi-device health information systems. Context synchronization methods can be used to create consistent analytical information from multi-device health information systems by merging analytical information from multiple user devices, which may have generated different analytical information based on algorithms for each user device.

[0040] To generate consistent analytics, service providers need to understand the context of each user's device. Service providers can store device information for each user's device. For example, they can store the type of user device, such as whether it's a smartphone, smartwatch, laptop, tablet, etc. Storing device information enables smarter synchronization of health information. When synchronizing health information across multiple devices, smarter synchronization can reduce power consumption requirements. Each device can see the reduction in power consumption used for synchronizing health information.

[0041] When a user device is configured to connect to a multi-device health information system, the service provider can receive device information. When the user device first enables synchronization of health data with the service provider via its account, the user device (or its software) can create a device context record and transmit it to the service provider. The device context record may include device information such as a unique device identifier and / or device type. The device context record may be stored in a database table at the service provider's location.

[0042] Other device-specific information can also be used by the service provider and / or user devices in the multi-device health information system. For example, the service provider may also store device-specific key value data that can be used for software and applications on the user device. Example key value data may include other device-specific information, such as the operating system version for the operating system on the device and / or the application version for the applications on the device. The user device and / or service provider can query the service provider for the device-specific key value data of the user device in the multi-device health information system.

[0043] Software and / or applications on the user device, as well as service providers, can use device context records and device-specific key value data to determine how to merge health information (e.g., analytics information) across a user's health information account, thereby merging health information at the user device's health information database and at the service provider's location. The user device can query key value data and device context records from other devices for synchronization operations.

[0044] Context-based synchronization methods can also be used in conjunction with other synchronization methods to determine the optimal time and / or circumstances for synchronizing health information to a specific user's device. For example, a service provider can use device information to determine if a specific user's device is a smartwatch with limited resources. The service provider can then use information about the specific user's device to determine when not to synchronize health information and / or when to synchronize health information to the specific user's device.

[0045] The examples described in this paper address numerous technical problems and provide many technical improvements. In some examples, these improvements additionally enhance the functionality of various components within the systems in which these techniques are implemented. Compared to conventional systems, the techniques described in this paper provide synchronization of health information that minimizes network traffic and power consumption for user devices. For example, the techniques described in this paper enable each user device (e.g., smartphone, smartwatch, laptop, etc.) in a multi-device health information system to optimize outgoing health information synchronization to focus health information received or generated at a particular user device on the true source (e.g., the service provider). Similarly, the techniques described in this paper enable each device in a multi-device health information system to optimize incoming health information synchronization to focus on health information generated or synchronized at other devices. The techniques described in this paper also enable the synchronization of new types of health information, such as status health information and analytics information, while minimizing resource consumption for synchronizing health information across multi-device health information systems by using state synchronization methods and context synchronization methods, in addition to changing the synchronization method.

[0046] Additionally, when a secondary user device (SMP) is unable to perform synchronization operations due to limited functionality (such as limited network capabilities, limited processing power, limited battery or software limitations, or other constraints), the techniques described herein also enable a primary user device (e.g., a smartphone) to perform outgoing and incoming synchronization operations with the real source (e.g., a service provider) on behalf of the associated SMP (e.g., a smartwatch). This allows a multi-device health information system to include user devices with limited functionality while maintaining consistency of health information across the multi-device health information system. Similarly, including user devices with limited functionality as part of a multi-device health information system enables the system to receive and analyze information from more devices, and thus provide better health information services to users.

[0047] For example, instead of sending notifications to be displayed between devices, each device generates its own notification based on its own health information. In a system where notifications are constantly being sent between devices, devices will continuously transmit messages over the network and consume power to continuously send and receive notifications. By minimizing the transmission of notifications and other messages between devices, devices can reduce network traffic, bandwidth usage, and increase battery life.

[0048] Now turn to the attached image. Figure 1 A block diagram illustrating the synchronization of health information across multiple devices, according to at least one example, is provided. A multi-device health information system may include a user device 102 storing health information associated with an account belonging to user 150. The health information may include steps taken, calories burned, calorie / food intake, menstrual cycle tracking, medication tracking, health-related recommendations / advice, insights into the user's health, indications of trends in health data, the user's personal health records (e.g., medical records, dental records, etc.), and / or any other type of health information. The health information on user device 102 may be synchronized to an account associated with user 150 (e.g., a health information account) via service provider 130. User devices 102, 104, 106, 146, and 148 may communicate with service provider 130 via network 120. Network 120 may be any type of network. For example, network 120 may be a local area network (LAN) or a wide area network (WAN). Network 120 may be a WiFi network or an equivalent network. The network may be a Bluetooth network or other short-range network that only connects two devices. A network can be a proprietary communication channel between two devices, such as the communication channel between a phone and a smartwatch.

[0049] An account can be accessed through communication with service provider 130. Health information associated with the account can be stored in health information database 132. Service provider 130 can communicate with health information database 132 and synchronize health information between user devices 102, 104, 106, 146, and 148 (e.g., each of these user devices may include its own health information data repository for storing health information) and health information database 132. When user device 102 receives new health information 110, user device 102 can synchronize the new health information 110 with service provider 130. As illustrated, a user may also have other user devices 104, 106, 146, and 148 sharing the same account. Thus, each of these other user devices 104, 106, 146, and 148 may also have access to the user's health information 110. Each user device may have its own health information data repository associated with the user. User devices 102, 104, and 106 are exemplified as handheld portable user devices, such as smartphones. As described herein, the example user devices can be any suitable user device, such as smartphones, tablets, media players, laptops, wearable devices, smartwatches, etc. In some examples, the user device may include one or more applications, which may include custom algorithms and other logic to achieve the performance of at least some of the techniques described herein. The user device may also include storage media for storing computer-executable instructions (e.g., those constituting the applications) and other data such as those described herein. In some examples, user devices 102, 104, 106, 146, and 148 may be associated with a single user 150. In some examples, user devices 102, 104, 106, 146, and 148 may be associated with different users, but all may have access to a health information database 132 containing health information associated with user 150.

[0050] User equipment 102 may also be referred to as primary user equipment 102. Primary user equipment 102 can be used as a primary user equipment associated with user equipment 146, 148. User equipment 146, 148 may also be referred to as secondary user equipment 146, 148. Secondary user equipment 146, 148 can also receive health information in the same manner as the primary user equipment including primary user equipment 102 can receive health information as described herein. For example, secondary user equipment 146 receives health information 112. As described herein, secondary user equipment 146, 148 may be devices with limited functionality paired with primary user equipment 102. In one example, primary device 102 is a smartphone, and secondary device 146 is a smartwatch. Due to hardware or software limitations, secondary user equipment 146 may have limited functionality compared to primary user equipment 102. For example, secondary user equipment 146 may have limited memory, storage devices, bandwidth, network capabilities, battery, and / or processing power compared to primary user equipment 102. In another example, primary device 102 is a smartphone, and secondary device 148 is a smartphone with relatively limited functionality. Here, secondary user equipment 148 may have limited functionality in the form of limited network capabilities, limited processing power, limited battery or software limitations, or other restrictions. Primary user equipment 102 may be referred to as the parent device, and secondary user equipment 146, 148 may be referred to as the child devices.

[0051] Figure 2 A block diagram 200 illustrating a method for synchronizing health information using synchronized identities across multiple devices, based on at least one example, is illustrated. A multi-device health information system may include user equipment 202 (e.g., Figure 1 User equipment 102), the user equipment stores information with the user (e.g., user ... Figure 1 Health information associated with the account of user 150 (e.g., Figure 1 Health information 110. Health information may include steps taken, calories burned, calorie / food intake, menstrual cycle tracking, medication tracking, health-related recommendations / advice, insights into the user's health, indications of trends in health data, and / or any other kind of health information. Health information on user device 202 may be transmitted via service provider 230 (e.g., Figure 1 The service provider 130) synchronizes the data to the user's associated account (e.g., a health information account). User devices 202 and 204 can be connected via network 220 (e.g., Figure 1Network 120 communicates with service provider 230. Network 220 can be any type of network. For example, network 220 can be a local area network (LAN) or a wide area network (WAN). Network 220 can be a WiFi network or an equivalent network. Network can be a Bluetooth network or other short-range network that only connects two devices. Network can be a proprietary communication channel between two devices, such as a communication channel between a phone and a smartwatch.

[0052] The account can be accessed through communication with service provider 230. Health information associated with the account can be stored in health information database 232 (e.g., Figure 1 The health information database 232 is used for data exchange. Service provider 230 can communicate with health information database 232 and synchronize health information between user devices 202, 204 and health information database 232. Users can also have other user devices, such as user device 204, sharing the same account. Thus, another user device 204 may also have access to the user's health information. Each user device may have its own repository of health information data associated with the user. User devices 202, 204 are exemplified as handheld portable user devices, such as smartphones. In some examples, user devices 202, 204 may be associated with a single user. In some examples, user devices 202, 204 may be associated with different users, but all may have access to health information database 232 containing health information associated with the user.

[0053] User device 202 may have a health information data repository 212. The health information data repository may include health synchronization objects. When user device 202 receives new health information, it may generate a health synchronization object based on the new health information. In some examples, health information may be received by user device 202 via user input. In some examples, health information may be obtained via sensors of user device 202. In some examples, health information may be collected from a web server. In some examples, health information may be obtained from a server accessible via a network (such as a database from a healthcare provider). In some examples, health information may be obtained from a gateway of a health database system. In some examples, health information may be received from another user device that receives the health information. For example, the other user device may be a secondary or accessory device, such as a smartwatch. In some examples, the other user device may receive health information via user input or via sensors of the other user device.

[0054] Health synchronization objects may include new health information and / or analytical information based on the new health information. In some examples, the new health information may be raw health information including symptoms, heart rate, temperature, blood oxygen, etc. Analytical information may include observations, suggestions, diagnoses, algorithms, predictions, and any other suitable information that can be used for analysis based on the raw health information. For example, diagnosing a person with a disease or ailment based on symptoms is an example of analytical information.

[0055] When a health synchronization object is generated, user device 202 includes a synchronization identity associated with the health synchronization object. The synchronization identity can be used to help user device 202 (and other user devices in the multi-device health information system) divide health information into two groups: 1) health information that user device 202 is responsible for synchronizing to service provider 230; and 2) health information that user device 202 can trust another device (e.g., user device 204) to be responsible for synchronizing to service provider 230. The synchronization identity can be a tuple of two or three fields including two unique identifiers and an optional string. The two unique identifiers of the synchronization identity can be a hardware identifier and a database identifier, and the string can be an optional instance discriminator. The hardware identifier can be bound to the specific hardware that generated the health synchronization object. For example, for a health synchronization object generated on user device 202, the hardware identifier will indicate user device 202. Similarly, if the database on user device 202 is moved to another device, a new synchronization identity will be formed because the different hardware will have different hardware identifiers. The database identifier can be bound to the specific database involved in the health synchronization object. For example, a health synchronization object can be associated with a first user, and the associated health information database can be associated with the first user. In some examples, user device 202 may have access to multiple health information databases, such as a health information database for the owner of user device 202 and a health information database for relatives (such as children, parents, or other family members). In some examples, user device 202 may have access to multiple health information databases, which may have access to different information about the same user. Each of these health information databases will be associated with a different database identifier. In some examples, the first database identifier refers to the health database on user device 202, rather than a health information database associated with the first user across multiple devices. As previously mentioned, user device 202 may have multiple health information databases, each with a separate database identifier. An optional instance discriminator can be a string that can be used to distinguish synchronization identities that may have the same hardware identifier and the same database identifier. For example, a new synchronization identity can be generated if the hardware identifier and database identifier do not change.

[0056] In Figure 2 In a related example, user equipment 202 has a health information data repository 212, depicted as a table, which includes health synchronization objects (also referred to as health objects) with associated synchronization identities. In one example, health object A has LX <string>The synchronization identity. L indicates the hardware identifier associated with user equipment 202, which indicates that health object A was generated on user equipment 202. X indicates the database identifier associated with the owner of user equipment 202, which indicates that health object A includes health information for a health information database associated with the owner of the user equipment. <string>Indicates the instance discriminator. In another example, healthy object B has LY. <string>The synchronization identity of health object B. Health object B has the same hardware identifier L as health object A, indicating that user device 202 generated both health object A and health object B. However, health object B has a different database identifier Y than health object A. This indicates that health object B is associated with a different database than health object A. In one example, health object B may be associated with a database for the owner of user device 202's relatives (such as children, parents, or other family members). In another example, health object B may be associated with a second health information database associated with the owner of device 202. For various reasons, a user can be associated with multiple health information databases. In some examples, the user device may have multiple health information data repositories corresponding to different database identifiers.

[0057] In another example, the health object C has MX <string>The health object C has a hardware identifier M that is different from the hardware identifier L of the health object A. This indicates that the health object C was generated by a device different from user device 202; for example, user device 204 could be the device that generated the health object C. The health object C may have the same database identifier as the health object A, indicating that the health object C and the health object A involve the same database.

[0058] User equipment 202 can use the synchronization identity of health synchronization objects to determine which health synchronization objects to synchronize to service provider 230 during outgoing synchronization operations. User equipment 202 can synchronize health synchronization objects with the synchronization identity associated with user equipment 202 to service provider 230. In some examples, user equipment 202 can synchronize health objects with the hardware identifier of user equipment 202. For example, referring to the examples of health objects A and B above, user equipment 202 can synchronize health synchronization objects with synchronization identities LX and LY to service provider 230 because user equipment 202 is associated with hardware identifier L. In some examples, user equipment 202 can be authorized to synchronize only health synchronization objects associated with a specific health information database. For example, referring to the examples of health objects A and B above, user equipment 202 can synchronize health synchronization objects with synchronization identity LX to service provider 230 because user equipment 202 is associated with database identifier X and authorized to synchronize objects with database identifier X. On the other hand, user equipment 202 can be associated with database identifier Y and is not authorized to synchronize objects with database identifier Y. Thus, user equipment 202 does not synchronize health object B to service provider 230.

[0059] User equipment 202 may also be responsible for synchronizing health synchronization objects with other synchronization identities to the service provider. User equipment 202 may be responsible for synchronizing health synchronization objects with hardware identifiers for deactivated or migrated devices. A deactivated device can be a device that is no longer active, no longer connected to a specific health information database, or no longer associated with the user. For example, when a user upgrades from an old smartphone to a new smartphone, the old smartphone will be deactivated and / or inactive. The new smartphone may be responsible for synchronizing health synchronization objects with hardware identifiers associated with the old smartphone. Alternatively, a migrated device refers to a device whose information is migrated to a new device. For example, when a user decides to acquire a new smartphone and hand over their old smartphone to a relative (such as a child), health information on the old smartphone can be migrated to the new smartphone. In this way, the old smartphone can be considered a migrated device. In some examples, when the health synchronization object becomes the responsibility of user equipment 202, the old synchronization identity can be replaced by the synchronization identity of user equipment 202.

[0060] In Figure 2 In the relevant examples, the healthy object D has NX <string>The synchronization identity. Health object D has a hardware identifier N that is different from the hardware identifier L of health object A. This indicates that health object D is controlled by a device different from user device 202 ( Figure 2 (Not shown in the image) is generated. Here, the device that generates health object D can be a deactivated device or a migrated device, meaning that the device is no longer active or connected to the health information database X. Here, user equipment 202 can be responsible for synchronizing health objects with hardware identifier N to service provider 230. Thus, user equipment 202 is responsible for synchronizing health objects with hardware identifier L and health objects with hardware identifier N.

[0061] In this way, outgoing synchronization operations can be restricted to health objects with a synchronization identity associated with the user equipment performing the outgoing synchronization operation. This limits redundant transmission of health information within a multi-device health information system, and thus restricts the use of resources by service provider 230 and user equipment 202, 204. Such resources may include the bandwidth, network, computing / processing power, and / or battery life of service provider 230 and / or user equipment 202, 204. In this way, user equipment can trust another user equipment to be responsible for health synchronization objects not generated by the user equipment itself.

[0062] In some examples, a synchronization identity bound to a specific device can be moved to be bound to another device in a multi-device information system. When a synchronization identity is moved from one device to another, the original device can generate a new synchronization identity. For example, user device 202 may have a synchronization identity MX that has been moved to user device 204. In some examples, synchronization identity MX is intentionally moved to user device 204 by a user, or it may be moved by a malicious actor. User device 202 can detect that synchronization identity MX has been moved to another device (user device 202 may not be able to detect which device synchronization identity MX has been moved to) and generates a new synchronization identity QX, using a new hardware identifier Q instead of M. Here, user device 202 can still use the database identifier X because user device 202 still has access to the health database shared among multiple devices and uses the appropriate database identifier X. In other examples, user device 202 can generate a new synchronization identity QU, where the database identifier U indicates that a new health database is stored on user device 202.

[0063] Similarly, service provider 230 can use the synchronization identity of health synchronization objects to determine which health synchronization objects to synchronize to the user equipment during outgoing synchronization operations. When sending health information to the user equipment (e.g., user equipment 202), service provider 230 can divide the health information into two groups: 1) health information not to be synchronized to the user equipment because the user equipment is responsible for the health information and therefore already has it; and 2) health information to be synchronized to the user equipment because the user equipment is not responsible for the health information. During outgoing synchronization operations to user equipment 202, service provider 230 can synchronize health synchronization objects with synchronization identities not associated with user equipment 202. For example, referring to the examples of health objects A, B, C, and D above, service provider 230 can synchronize a health synchronization object with synchronization identity MX to user equipment 202 because user equipment 202 is not associated with hardware identifier M (user equipment 202 is associated with hardware identifiers L and N). Similarly, during an outgoing synchronization operation on user equipment 204, service provider 230 can synchronize healthy synchronization objects with synchronization identities not associated with user equipment 204. For example, referring to the examples of healthy objects A, B, C, and D above, service provider 230 can synchronize healthy synchronization objects with synchronization identities LX and NX (and potentially LY) to user equipment 204 because user equipment 204 is not associated with hardware identifiers L and N (user equipment 202 is associated with hardware identifier M).

[0064] In this way, incoming synchronization operations can be restricted to health objects with synchronization identities not associated with the user equipment receiving the incoming synchronization operation. This limits redundant transmission of health information within a multi-device health information system, and thus restricts the use of resources by service provider 230 and user equipment 202, 204. Such resources may include bandwidth, network, computing / processing power, and / or battery life of service provider 230 and / or user equipment 202, 204.

[0065] Figures 3 to 5 , Figures 7 to 9 Example flowcharts illustrating processes 300, 400, 500, 700, 800, and 900 are shown according to at least several examples. These processes, and any other processes described herein, are illustrated as logic flowcharts, where each operation represents a series of operations that can be implemented in hardware, computer instructions, or combinations thereof. In the context of computer instructions, an operation may represent computer-executable instructions stored on one or more non-transitory computer-readable storage media that perform the operation when executed by one or more processors. Generally, computer-executable instructions include routines, programs, objects, components, data structures, etc., that perform a particular function or implement a particular data type. The order in which operations are described is not intended to be construed as limiting, and any number of described operations may be combined in any order and / or in parallel to implement the described process.

[0066] Figure 3 A flowchart illustrating a process 300 for synchronizing health information using a synchronized identity across multiple devices, according to at least one example, is shown. According to at least one example, process 300 includes: a) a first user device 302 (e.g., Figure 2 User equipment 202) executes the sending of a healthy synchronization object with the first synchronization identity to the real source (such as service provider 330, which is...). Figure 2 (a) the outgoing synchronization operation of service provider 230; and b) the real source performing the sending of a first healthy synchronization object with the first synchronization identity to the second user equipment 304 (e.g., Figure 2 The first user equipment 302 receives the first health information (e.g., the user equipment 204) for the incoming synchronization operation. Figure 1 When the first health information 110 is received, the first user equipment 302 can generate a first health synchronization object with a first synchronization identity associated with the first user equipment 302. The first user equipment 302 can perform an outgoing synchronization operation after determining that it is responsible for sending the health synchronization object with the first synchronization identity to the service provider 330. The service provider 330 can determine that the second synchronization identity of the second user equipment 304 is different from the first synchronization identity of the first health synchronization object, thereby determining to send the first health synchronization object to the second user equipment 304. Process 300 includes... Figure 2 The various components shown perform various functions. Health application 1110 ( Figure 11 ) Whether in wearable electronic devices 1105 ( Figure 11 User equipment 1102 Figure 11 ), or the service provider's computer 1104 ( Figure 11 Whether it is reflected in the aforementioned devices or in any suitable combination thereof, it can be executed. Figure 3 The process is part 300.

[0067] Process 300 can be completed at 350 by communicating with the user profile (e.g., with...). Figure 1 The first user device 302 associated with user 150 (the account associated with user 150) (e.g., Figure 2 User equipment 202) from service provider 330 (e.g., Figure 2 The service provider (230) receives the health database to begin. The health database can be a health information database (e.g., Figure 2 The health information is stored in a health information database (132). The health database may also be referred to as a health information data repository. The health database may be associated with a user profile. In some examples, the service provider 330 may be configured to store the health database. In some examples, the service provider 330 may be configured to communicate with the health information database to receive health information.

[0068] At 352, process 300 may include a first user device 302 receiving first health information associated with a user profile and collected at least in part by the first user device 302. In some examples, the first health information may be received by the first user device 302 via input from a user. In some examples, the first health information may be obtained via sensors of the first user device 302. In some examples, the first health information may be collected from a web server. In some examples, the first health information may be obtained from a server accessible via a network (such as a database from a healthcare provider). In some examples, the first health information may be obtained from a gateway of a health database system. In some examples, the first health information may be received from another user device that receives the health information. For example, the other user device may be a secondary or accessory device, such as a smartwatch. In some examples, the other user device may receive the health information via user input or via sensors of the other user device.

[0069] At 354, process 300 may include a first user device 302 generating a first health synchronization object based on first health information. The first health synchronization object may include a first synchronization identity. The first synchronization identity may include a first hardware identifier indicating the first user device 302 and a first database identifier indicating a health database. In some examples, the first user device 302 may have access to multiple health information databases, for example, a health information database for the owner of the first user device 302 and a health information database for relatives (such as children, parents, or other family members). In some examples, the first user device 302 may have access to multiple health information databases, which may have access to different information about the same user. Each of these health information databases will be associated with a different database identifier.

[0070] At 356, process 300 may include a first user equipment 302 determining to send a health synchronization object to service provider 330 based on the fact that the first user equipment 302 is responsible for sending a health synchronization object with a first synchronization identity to service provider 330. The first user equipment 302 may use the synchronization identity of the health synchronization object to determine which health synchronization objects to synchronize to service provider 330 during outgoing synchronization operations. In some examples, the first user equipment 302 may synchronize health objects having a hardware identifier of the first user equipment 302. For example, the first user equipment 302 determines to send a first health synchronization object. At 358, process 300 may include the first user equipment 302 sending the determined health synchronization object to service provider 330. For example, the first user equipment 302 may send the first health synchronization object.

[0071] At 360, process 300 may include service provider 330 identifying second user equipment 304 (e.g., Figure 2 The second user equipment (204) receives the first health synchronization object. The second user equipment (204) may be associated with a health database. At 362, process 300 may include service provider 330 determining that the first synchronization identity is different from the second synchronization identity associated with the second user equipment (204). Here, service provider 330 may use the synchronization identity of the health synchronization object to determine which health synchronization objects to synchronize to the user equipment during outgoing synchronization operations.

[0072] At 364, process 300 may include service provider 330 sending a first health synchronization object to second user equipment 304 based on determining that the first synchronization identity is different from the second synchronization identity. In some examples, sending the first health synchronization object to second user equipment 304 may also be based on service provider 330 determining that second user equipment 304 is not responsible for sending a health synchronization object with the first synchronization identity to service provider 330.

[0073] In some examples, process 300 may further include a first user equipment 302 receiving a second health synchronization object. The second health synchronization object may include a second synchronization identity, which includes instructions for the second user equipment 304 (e.g., Figure 1 The second user equipment 304) has a second hardware identifier and a first database identifier indicating the health database. In some examples, process 300 may further include the first user equipment 302 determining not to send a second health synchronization object to service provider 330 based on the first user equipment 302 not being responsible for sending a health synchronization object with a second synchronization identity to service provider 330. In some examples, the second health synchronization object is received from service provider 330, wherein service provider 330 is configured to send the second health synchronization object to the first user equipment 302 based on determining that the second synchronization identity associated with the second health synchronization object is different from the first synchronization identity associated with the first user equipment 302.

[0074] In some examples, process 300 may include a first user equipment 302 determining to send a second health synchronization object to service provider 330 based on the first user equipment 302 being responsible for sending a health synchronization object with a second synchronization identity to service provider 330. In some examples, and regarding the following... Figure 6 The second synchronization identity can be used with and as the primary user device (e.g., Figure 1 The primary user equipment 102) and the secondary user equipment associated with the first user equipment 302 (e.g., the secondary user equipment). Figure 1 The process 300 may also include the first user equipment 302 sending a second health synchronization object to the service provider 330. The process 300 may also include the first user equipment 302 receiving an indication that the auxiliary equipment has not yet sent the first health synchronization object to the health database according to a timing standard. The timing standard may be within the time period for generating the first health synchronization object, within the time period for receiving first health information used to generate the first health synchronization object, or within the time period for sending the first health synchronization object to the master equipment.

[0075] In some examples, the second synchronization identity can be associated with a second user device 304 (e.g., Figure 2 The first user equipment 302 is associated with the second user equipment 304, and the second user equipment 304 is inactive. For example, the second user equipment 304 may have been deactivated, damaged, or not associated with the user's profile. Here, the first user equipment 302 may be responsible for sending a health synchronization object with the second synchronization identity to the service provider 330. Similarly, data from the second user equipment 304 (including health information on the second user equipment 304) may have been migrated to the first user equipment 302.

[0076] In some examples, process 300 may also include service provider 330 receiving a third health synchronization object. The third health synchronization object may be associated with a third synchronization identity. The third synchronization identity may be associated with a third user device that is no longer active.

[0077] In some examples, process 300 may further include service provider 330 receiving a second health synchronization object from second user equipment 304. The second health synchronization object may include a second synchronization identity. The second synchronization identity may include a second hardware identifier indicating second user equipment 304 and a first database identifier indicating a health database. Process 300 may further include service provider 330 identifying first user equipment 302 to receive the second health synchronization object. Process 300 may further include determining that the second synchronization identity is different from the first synchronization identity. Process 300 may further include service provider 330 sending the second health synchronization object to first user equipment 302 based on the determination that the second synchronization identity is different from the first synchronization identity.

[0078] In some examples, process 300 may also include service provider 330 identifying a third user device associated with the health database. The third user device may be a secondary device. Process 300 may also include service provider 330 determining not to send a first health synchronization object to the third user device based on the fact that the third user device is a secondary device.

[0079] In some examples, the first user equipment 302 may be a master device as described herein (e.g., regarding the following). Figure 6 In some examples, process 300 may also include service provider 330 identifying a third user device associated with the health database. The third user device may be a secondary device associated with the first user device 302. Process 300 may also include service provider 330 determining not to send the first health synchronization object to the third user device based on the fact that the third user device is a secondary device associated with the first user device 302.

[0080] In some examples, the first user equipment 302 may be an auxiliary device as described herein (e.g., regarding the following). Figure 6 In some examples, process 300 may also include service provider 330 identifying a third user device associated with the health database. The third user device may be a master device associated with first user device 302. Process 300 may also include service provider 330 determining not to send a first health synchronization object to the third user device based on the fact that the third user device is a master device associated with first user device 302.

[0081] Figure 4 A flowchart illustrating a process 400 for synchronizing health information using a synchronized identity across multiple devices, according to at least one example, is shown. According to at least one example, process 400 includes a user device (e.g., Figure 2 User equipment 202) performs an operation to direct traffic to the real source (e.g., Figure 2 The service provider 230) sends an outgoing synchronization operation to the first health synchronization object with the first synchronization identity. When the user equipment receives the first health information (e.g., ...), Figure 1 When the user equipment receives the first health information (110), it can generate a first health synchronization object with a first synchronization identity associated with the user equipment. After determining that the user equipment is responsible for sending the health synchronization object with the first synchronization identity to the service provider, the user equipment can perform an outgoing synchronization operation. Process 400 is a variation of process 300, which includes... Figure 2 The various components shown perform various functions. Health application 1110 ( Figure 11 ) Whether in wearable electronic devices 1105 ( Figure 11 User equipment 1102 Figure 11 ), or the service provider's computer 1104 ( Figure 11 Whether it is reflected in the aforementioned devices or in any suitable combination thereof, it can be executed. Figure 4 The process 400. Therefore, although process 400 is described as being executed by the user equipment, it should be understood that the primary user equipment (e.g., Figure 2 Primary user equipment 202) and secondary user equipment (e.g., Figure 2 Both auxiliary user equipment 146 and 148 can perform process 400 with limited adjustments.

[0082] Process 400 can be performed at box 402 via a user profile (e.g., with...). Figure 1 The first user device associated with the 150 associated accounts of user 150 (e.g., Figure 2 User equipment 202) from the service provider (e.g., Figure 2 The service provider (230) receives the health database to begin. The health database can be a health information database (e.g., Figure 2 The health information database (132) contains some or all of the health information. The health database can also be referred to as a health information data repository. The health database can be associated with a user profile. In some examples, the service provider can be configured to store the health database. In some examples, the service provider can be configured to communicate with the health information database to receive health information.

[0083] At box 404, process 400 may include a first user device receiving first health information associated with a user profile and collected at least in part by the first user device. In some examples, the first health information may be received by the first user device via input from a user. In some examples, the first health information may be obtained via sensors of the first user device. In some examples, the first health information may be collected from a web server. In some examples, the first health information may be obtained from a server accessible over a network, such as a database from a healthcare provider. In some examples, the first health information may be obtained from a gateway of a health database system. In some examples, the first health information may be received from another user device that receives the health information. For example, the other user device may be a secondary or accessory device, such as a smartwatch. In some examples, the other user device may receive the health information via user input or via sensors of the other user device.

[0084] At box 406, process 400 may include a first user device generating a first health synchronization object based on first health information. The first health synchronization object may include a first synchronization identity. The first synchronization identity may include a first hardware identifier indicating the first user device and a first database identifier indicating a health database. In some examples, the first user device may have access to multiple health information databases, such as a health information database for the owner of the first user device and a health information database for relatives (such as children, parents, or other family members). In some examples, the first user device may have access to multiple health information databases, which may have access to different information about the same user. Each of these health information databases will be associated with a different database identifier.

[0085] At box 408, process 400 may include a first user equipment determining to send a first health synchronization object to the service provider based on the first user equipment's responsibility to send a health synchronization object with a first synchronization identity to the service provider. The first user equipment may use the synchronization identity of the health synchronization object to determine which health synchronization objects to synchronize to the service provider during outgoing synchronization operations. In some examples, the first user equipment may synchronize health objects having the first user equipment's hardware identifier. At box 410, process 400 may include the first user equipment sending the first health synchronization object to the service provider.

[0086] In some examples, process 400 may also include a first user equipment receiving a second health synchronization object. The second health synchronization object may include a second synchronization identity, which includes an indication to the second user equipment (e.g., Figure 1 The second user equipment (104) has a second hardware identifier and a first database identifier indicating the health database. In some examples, process 400 may further include the first user equipment determining not to send a second health synchronization object to the service provider based on the first user equipment not being responsible for sending a health synchronization object with a second synchronization identity to the service provider. In some examples, the second health synchronization object is received from the service provider, wherein the service provider is configured to send the second health synchronization object to the first user equipment based on determining that the second synchronization identity associated with the second health synchronization object is different from the first synchronization identity associated with the first user equipment.

[0087] In some examples, process 400 may include a first user equipment determining to send a second health synchronization object to the service provider based on the first user equipment being responsible for sending a health synchronization object with a second synchronization identity to the service provider. In some examples and referring to the following... Figure 6 The second synchronization identity can be used with and as the primary user device (e.g., Figure 1 The primary user equipment 102) is associated with a secondary user equipment (e.g., secondary user equipment). Figure 1 The process 400 may also include the first user equipment (146) being associated with the secondary user equipment. The process 400 may further include the first user equipment sending a second health synchronization object to the service provider. The process 400 may also include the first user equipment receiving an indication that the secondary equipment has not yet sent the first health synchronization object to the health database according to a timing standard. The timing standard may be within the time period for generating the first health synchronization object, within the time period for receiving first health information used to generate the first health synchronization object, or within the time period for sending the first health synchronization object to the primary equipment.

[0088] In some examples, the second synchronization identity can be associated with a second user device (e.g., Figure 2 The first user equipment (104) is associated with the second user equipment, and the second user equipment is inactive. For example, the second user equipment may have been deactivated, damaged, or not associated with the user's profile. Here, the first user equipment may be responsible for sending a health synchronization object with the second synchronization identity to the service provider. Similarly, data from the second user equipment (including health information on the second user equipment) may have been migrated to the first user equipment.

[0089] Figure 5 A flowchart illustrating a process 500 for synchronizing health information using a synchronized identity across multiple devices, according to at least one example, is shown. According to at least one example, process 500 includes a real source (e.g., Figure 2 Service provider 239) from the first user equipment (e.g., Figure 2 The first user equipment 202) receives a first health synchronization object with a first synchronization identity and performs the operation of sending data to the second user equipment (e.g., Figure 2 The second user equipment 204) sends an incoming synchronization operation to a first health synchronization object with a first synchronization identity. When the first user equipment can, based on the first health information received by the first user equipment (e.g., ...), Figure 1 When generating the first health synchronization object using the first health information 110, the service provider can determine that the second synchronization identity of the second user equipment is different from the first synchronization identity of the first health synchronization object, thereby determining to send the first health synchronization object to the second user equipment. Process 500 is a variation of process 300, which includes... Figure 2 The various components shown perform various functions.

[0090] Process 500 can be completed at box 502 via the service provider (e.g., Figure 2 Service provider 230) to the first user equipment (e.g., Figure 2 The user equipment 202) sends a health database to initiate the process. The health database may be a health information database (e.g., ...). Figure 2 The health information database (132) contains some or all of the health information. The health database can also be referred to as a health information data repository. The health database can be associated with a user profile. In some examples, the service provider can be configured to store the health database. In some examples, the service provider can be configured to communicate with the health information database to receive health information.

[0091] At box 504, process 500 may include a service provider receiving a first health synchronization object from a first user device. The first health synchronization object may be based on first health information collected at least partially at the first user device. In some examples, the first health information may be received by the first user device via input from a user. In some examples, the first health information may be obtained via sensors of the first user device. In some examples, the first health information may be collected from a web server. In some examples, the first health information may be obtained from a server accessible over a network, such as a database from a healthcare provider. In some examples, the first health information may be obtained from a gateway of a health database system. In some examples, the first health information may be received from another user device that receives the health information. For example, the other user device may be a secondary or accessory device, such as a smartwatch. In some examples, the other user device may receive the health information via user input or via sensors of the other user device. The first health synchronization object may include a first synchronization identity, which includes a first hardware identifier indicating the first user device and a first database identifier indicating a health database.

[0092] At box 506, process 500 may include a service provider identifier for the second user equipment (e.g., Figure 2 The second user equipment (204) receives the first health synchronization object. The second user equipment may be associated with a health database. At block 508, process 500 may include the service provider determining that the first synchronization identity is different from the second synchronization identity associated with the second user equipment. Here, the service provider can use the synchronization identity of the health synchronization objects to determine which health synchronization objects to synchronize to the user equipment during outgoing synchronization operations.

[0093] At box 510, process 500 may include the service provider sending a first health synchronization object to the second user equipment based on determining that the first synchronization identity is different from the second synchronization identity. In some examples, sending the first health synchronization object to the second user equipment may also be based on the service provider determining that the second user equipment is not responsible for sending a health synchronization object with the first synchronization identity to the service provider.

[0094] In some examples, process 500 may also include the service provider receiving a third health synchronization object. The third health synchronization object may be associated with a third synchronization identity. The third synchronization identity may be associated with a third user device that is no longer active.

[0095] In some examples, process 500 may further include a service provider receiving a second health synchronization object from a second user equipment. The second health synchronization object may include a second synchronization identity. The second synchronization identity may include a second hardware identifier indicating the second user equipment and a first database identifier indicating a health database. Process 500 may further include a service provider identifying the first user equipment to receive the second health synchronization object. Process 500 may further include determining that the second synchronization identity is different from the first synchronization identity. Process 500 may further include the service provider sending the second health synchronization object to the first user equipment based on the determination that the second synchronization identity is different from the first synchronization identity.

[0096] In some examples, process 500 may also include the service provider identifying a third user device associated with the health database. The third user device may be a secondary device. Process 500 may also include the service provider determining, based on the third user device being a secondary device, not to send a first health synchronization object to the third user device.

[0097] In some examples, the first user device may be a master device as described herein (e.g., regarding the following). Figure 6 In some examples, process 500 may also include a service provider identifying a third user device associated with the health database. The third user device may be a secondary device associated with the first user device. Process 500 may also include the service provider determining not to send a first health synchronization object to the third user device based on the fact that the third user device is a secondary device associated with the first user device.

[0098] In some examples, the first user equipment may be a secondary equipment as described herein (e.g., regarding the following). Figure 6 In some examples, process 500 may also include a service provider identifying a third user device associated with the health database. The third user device may be a master device associated with the first user device. Process 500 may also include the service provider determining not to send a first health synchronization object to the third user device based on the fact that the third user device is a master device associated with the first user device.

[0099] Figure 6 A block diagram 600 illustrating a method for synchronizing health information across a primary and secondary device, according to at least one example, is shown. Block diagram 600 includes a multi-device health information system using the multi-device health information synchronization technology described herein. The multi-device health information system may include a primary device 602 (e.g., Figure 1 The main user equipment 102), which stores data with users (e.g., Figure 1 Health information associated with the account of user 150 (e.g., Figure 1 Health information 110. Health information may include steps taken, calories burned, calorie / food intake, menstrual cycle tracking, medication tracking, health-related recommendations / advice, insights into the user's health, indications of trends in health data, and / or any other kind of health information. Health information on the main device 602 can be transmitted via service provider 630 (e.g., Figure 1 The service provider 130) synchronizes the data to the user's associated account (e.g., a health information account).

[0100] The main device 602 can be connected with auxiliary devices 646, 648 (for example, Figure 1 The secondary user equipment 646, 648 is associated with the primary user equipment 602. The secondary devices 646, 648 can also receive health information in the same manner as the primary user equipment 602 can receive health information as described herein. As described herein, the secondary user equipment 646, 648 can be devices with limited functionality paired with the primary user equipment 602. In one example, the primary device 602 is a smartphone, and the secondary device 646 is a smartwatch. Due to hardware or software limitations, the secondary user equipment 646 may have limited functionality compared to the primary user equipment 602. For example, compared to the primary user equipment 602, the secondary user equipment 646 may have limited memory, storage capacity, bandwidth, network capabilities, battery, and / or processing power. In another example, the primary device 602 is a smartphone, and the secondary device 648 is a smartphone with relatively limited functionality. Here, the secondary user equipment 648 may have limited functionality in the form of limited network capabilities, limited processing power, limited battery or software limitations, or other restrictions. The primary user equipment 602 can be referred to as the parent device, and the secondary user equipment 646 and 648 can be referred to as the child devices.

[0101] The main device 602 and auxiliary devices 646 and 648 can be connected via network 620 (e.g., Figure 1 Network 620 communicates with service provider 630. Network 620 can be any type of network. For example, network 620 can be a local area network (LAN) or a wide area network (WAN). Network 620 can be a WiFi network or an equivalent network. Network can be a Bluetooth network or other short-range network that only connects two devices. Network can be a proprietary communication channel between two devices, such as a communication channel between a phone and a smartwatch.

[0102] The account can be accessed through communication with service provider 630. Health information associated with the account can be stored in health information database 632 (e.g., Figure 1 The health information database 632 is used for data storage. Service provider 630 can communicate with health information database 632 and synchronize health information between primary device 602, secondary devices 646, 648, and health information database 632. Users can also have other user devices (besides secondary devices 646, 648) sharing the same account. Thus, other user devices (including secondary devices 646, 648) also have access to the user's health information. Each user device can have its own repository of health information data associated with the user. User device 602 is exemplified as a handheld portable user device such as a smartphone. In some examples, primary device 602 and secondary devices 646, 648 can be associated with a single user. In some examples, primary device 602 and secondary devices 646, 648 can be associated with different users, but all can have access to health information database 632 containing health information associated with the user.

[0103] The primary device 602 may have a health information data repository 612. The health information data repository may include health synchronization objects. When the primary device 602 receives new health information, it can generate a health synchronization object based on the new health information. In some examples, the health information may be received by the primary device 602 via user input. In some examples, the health information may be obtained via sensors of the primary device 602. In some examples, health information may be collected from a web server. In some examples, health information may be obtained from a server accessible via a network (such as a database from a healthcare provider). In some examples, health information may be obtained from a gateway of a health database system. Similarly, the secondary device 646 may have a health information data repository 612. When the secondary device 646 receives new health information, it can generate a health synchronization object based on the new health information. In some examples, the health information may be received by the secondary device 646 via user input. In some examples, the health information may be obtained via sensors of the secondary device 646. In some examples, health information can be collected from a web server. In some examples, health information can be obtained from a server accessible over a network, such as a database from a healthcare provider. In some examples, health information can be obtained from a gateway to a health database system.

[0104] Health synchronization objects may include new health information and / or analytical information based on the new health information. In some examples, the new health information may be raw health information including symptoms, heart rate, temperature, blood oxygen, etc. Analytical information may include observations, suggestions, diagnoses, algorithms, predictions, and any other suitable information that can be used for analysis based on the raw health information. For example, diagnosing a person with a disease or ailment based on symptoms is an example of analytical information.

[0105] When a health synchronization object is generated, the primary device 602 and / or secondary device 646 includes a synchronization identity associated with the health synchronization object. The synchronization identity may include a hardware identifier, a database identifier, and an optional instance authenticator. The hardware identifier may be bound to the specific hardware that generated the health synchronization object. For example, for a health synchronization object generated on the primary device 602, the hardware identifier would indicate the primary device 602. The database identifier may be bound to a specific database involved in the health synchronization object. For example, the health synchronization object may be associated with a first user, and the associated health information database may be associated with that first user. In some examples, the primary device 602 and / or secondary device 646 may have access to multiple health information databases, such as a health information database for the owner of the primary device 602 and a health information database for relatives (such as children, parents, or other family members). In some examples, the primary device 602 and / or secondary device 646 may have access to multiple health information databases, which may have access to different information about the same user. Each of these health information databases will be associated with a different database identifier. An optional instance discriminator can be a string that can be used to distinguish synchronization identities that may have the same hardware identifier and the same database identifier.

[0106] In Figure 6 In a related example, the master device 602 has a health information data repository 612, depicted as a table, that includes health synchronization objects (also referred to as health objects) with associated synchronization identities. In one example, health object A has LX <string>The synchronization identity. L indicates a hardware identifier associated with master device 602, indicating that health object A was generated on master device 602. X indicates a database identifier associated with the owner of master device 602, indicating that health object A includes health information for a health information database associated with the owner of the user device. <string>Indicates the instance discriminator. In another example, healthy object B has LY. <string>The synchronization identity of health object B. Health object B has the same hardware identifier L as health object A, indicating that master device 602 generated both health object A and health object B. However, health object B has a different database identifier Y than health object A. This indicates that health object B is associated with a different database than health object A. In one example, health object B may be associated with a database for the owner of master device 602's relatives (such as children, parents, or other family members). In another example, health object B may be associated with a second health information database associated with the owner of master device 602. For various reasons, a user can be associated with multiple health information databases. In some examples, the user device may have multiple health information data repositories corresponding to different database identifiers.

[0107] In another example, the health object C has MX <string>The health object C has a hardware identifier M that is different from the hardware identifier L of the health object A. This indicates that the health object C was generated by a device different from the master device 602; for example, the slave device 646 could be the device that generated the health object C. The health object C may have the same database identifier as the health object A, indicating that the health object C and the health object A involve the same database.

[0108] The primary device 602 and secondary device 646 can use the synchronization identity of the health synchronization objects to determine which health synchronization objects to synchronize to the service provider 630 during the outgoing synchronization operation. (See also: Regarding...) Figure 2 As described in user equipment 202, primary device 602 can synchronize health synchronization objects with the associated synchronization identity of primary device 602 to service provider 630. In some examples, primary device 602 can synchronize health objects with the hardware identifier of primary device 602. For example, referring to the examples of health objects A and B above, primary device 602 can synchronize health synchronization objects with synchronization identities LX and LY to service provider 630 because primary device 602 is associated with hardware identifier L. Similarly, secondary device 646 can synchronize health synchronization objects with the associated synchronization identity of secondary device 646. In some examples, secondary device 646 can synchronize health objects with the hardware identifier of secondary device 646. For example, referring to the example of health object C above, secondary device 646 can synchronize health synchronization objects with the synchronization identity MX to service provider 630 because secondary device 646 is associated with hardware identifier M.

[0109] In some examples, primary device 602 and secondary device 646 can be authorized to synchronize only health synchronization objects associated with a specific health information database. For example, referring to the example of health objects A and B above, primary device 602 can synchronize a health synchronization object with synchronization identity LX to service provider 630 because user device 602 is associated with database identifier X and is authorized to synchronize objects with database identifier X. On the other hand, primary device 602 can be associated with database identifier Y and is not authorized to synchronize objects with database identifier Y. Therefore, primary device 602 does not synchronize health object B to service provider 630.

[0110] Secondary devices 646 and 648 can also use the synchronization identity of the health synchronization objects to determine which health synchronization objects to send to the associated primary device, such as primary device 602. For example, secondary device 646 can send a health synchronization object with a synchronization identity associated with secondary device 646 to primary device 602. For example, referring to the example of health object C above, secondary device 646 can send a health synchronization object with synchronization identity MX to primary device 602 because secondary device 646 is associated with hardware identifier M. In some examples, secondary device 646 can connect, send, and receive information (including health synchronization objects) from primary device 602 via a less resource-intensive communication channel. For example, primary device 602 and secondary device 646 can communicate via a local area network (e.g., WiFi) or a short-range communication medium (e.g., Bluetooth). This contrasts with potentially more resource-intensive long-range communication media (such as cellular networks).

[0111] Additionally, user equipment 602 may also be responsible for synchronizing health synchronization objects with other synchronization identities to the service provider. User equipment 602 may be responsible for synchronizing health synchronization objects with hardware identifiers for associated secondary devices (such as secondary devices 646, 648). In some examples, secondary devices 646, 648 may send health synchronization objects with their associated synchronization identities to service provider 630 based on a timing standard. For example, secondary devices 646, 648 may be able to send health synchronization objects with their associated synchronization identities to service provider 630 based on a timing standard that is established within three days of the generation of the health synchronization object. The timing standard may be within 5 minutes, 10 minutes, 15 minutes, 20 minutes, 30 minutes, 1 hour, 2 hours, 3 hours, 4 hours, 5 hours, 6 hours, 12 hours, 24 hours, 2 days, 3 days, 4 days, 5 days, 7 days, 8 days, 10 days, 14 days, 3 weeks, 4 weeks, or 1 month, or any time period within these periods. The timing standard can be any time period within which health information used to generate health synchronization objects is received, such as 5 minutes, 10 minutes, 15 minutes, 20 minutes, 30 minutes, 1 hour, 2 hours, 3 hours, 4 hours, 5 hours, 6 hours, 12 hours, 24 hours, 2 days, 3 days, 4 days, 5 days, 7 days, 8 days, 10 days, 14 days, 3 weeks, 4 weeks, or 1 month, or any time period within that range. The timing standard can be within any time period of 5 minutes, 10 minutes, 15 minutes, 20 minutes, 30 minutes, 1 hour, 2 hours, 3 hours, 4 hours, 5 hours, 6 hours, 12 hours, 24 hours, 2 days, 3 days, 4 days, 5 days, 7 days, 8 days, 10 days, 14 days, 3 weeks, 4 weeks, or 1 month, or any time interval thereof, when sending health synchronization objects to the master device 602.

[0112] In some examples, secondary devices 646 and 648 cannot send health synchronization objects with associated synchronization identities to service provider 630 according to predetermined timing standards because secondary devices 646 and 648 have limited memory, storage devices, bandwidth, network capabilities, battery, and / or processing power. In such examples, the primary device can send health synchronization objects with the associated synchronization identities of the secondary devices to the service provider. For example, primary device 602 can send a health synchronization object with the synchronization identity MX associated with secondary device 646 to service provider 630 on behalf of secondary device 646.

[0113] In some examples, the master device 602 can determine, based on timing criteria, that the slave device 646 has not yet sent a specific health synchronization object to the service provider. In some examples, the master device 602 sends a request to the slave device indicating whether the slave device has sent a specific health synchronization object to the service provider. If the master device 602 does not receive a response within a second time period (e.g., the slave device 646 has or has not yet sent an indication of a specific health synchronization object to the service provider 630), the master device can send the health synchronization object associated with the slave device 646 to the service provider. This second time period can be 5 minutes, 15 minutes, 30 minutes, 1 hour, 2 hours, 3 hours, 6 hours, 12 hours, 1 day, 2 days, 3 days, 4 days, 5 days, 7 days, 8 days, 10 days, 2 weeks, 1 month, or any time interval thereof. In some examples, the slave device 646 can determine, based on timing criteria, that the slave device 646 has not yet sent a specific health synchronization object to the service provider 630. In some examples, the slave device sends an indication to the master device 602 that the slave device has not yet sent a first health synchronization object to the service provider. This instruction can be configured to cause the primary device 602 to send a specific health synchronization object to the service provider 630. In some examples, the instruction and / or request may involve two or more health synchronization objects generated by the secondary device 646.

[0114] Timing standards can be important because secondary devices may have a limited health information data repository compared to the primary device. In some examples, a secondary device may have a health information data repository that includes only health information from the most recent time period. For example, secondary device 646 may have a health information data repository that includes only health information from the most recent eight days. The most recent time period can be last year, six months, three months, two months, one month, eight weeks, four weeks, two weeks, ten days, eight days, seven days, five days, four days, three days, two days, one day, or any period in between. Once health information is associated with a time other than the most recent time period, it can be deleted on secondary device 646. In this way, the timing standard sent to the service provider ensures that once secondary device 646 deletes the health information, the health information received by secondary device 646 is not lost.

[0115] In this way, outgoing synchronization operations can be restricted to health objects with a synchronization identity associated with the user equipment performing the outgoing synchronization operation. This limits redundant transmission of health information within a multi-device health information system, and thus restricts the use of resources by service provider 630 and user equipment 602, 604. Such resources may include the bandwidth, network, computing / processing power, and / or battery life of service provider 630 and / or user equipment 602, 604. In this way, user equipment can trust another user equipment to be responsible for health synchronization objects not generated by the user equipment itself.

[0116] Figure 7 A flowchart illustrating a process 700 for synchronizing health information across a master device and a slave device is shown according to at least one example. According to at least one example, process 700 includes a master device 702 (e.g., Figure 6 The primary user equipment 602) sends a request to the service provider 730 (e.g., Figure 6 Service provider 630) sends data to auxiliary equipment 746 (e.g., Figure 6 The secondary user equipment 746 generates a health synchronization object. The secondary equipment 746 receives health information (e.g., ...). Figure 1 The secondary device 746 can be configured to send a health synchronization object to the service provider 730. However, due to resource constraints such as network capacity, bandwidth, power, and / or battery life, the secondary device 746 may be unable to send a health synchronization object to the service provider 730. The secondary device 746 can send a health synchronization object to the primary device 702. Once the timing criteria associated with the secondary device 746 sending a health synchronization object to the service provider 730 have not been met, the primary device 702 can send a health synchronization object to the service provider 730. Process 700 includes... Figure 6 The various components shown perform various functions. The health application on the main device 702 (e.g., Figure 11 The health application 1110 can perform Figure 8 The process is 800.

[0117] Process 700 may begin at 750 by receiving first health information associated with a user profile via auxiliary device 746. The user profile may be associated with a health database stored by service provider 730. In some examples, auxiliary device 746 has storage limited to health information associated with the health database from the last time period. In some examples, auxiliary device 746 deletes health information associated with times other than the last time period.

[0118] At 752, process 700 may include a secondary device 746 generating a first health synchronization object based on first health information. The first health synchronization object may include a first synchronization identity, which includes a first hardware identifier indicating the secondary device 746 and a first database identifier indicating a health database. The secondary device 746 may be configured to send the first health synchronization object to service provider 730. The primary device 702 may be configured to generate a second health synchronization object including a second synchronization identity, which includes a second hardware identifier indicating the primary device 702 and a first database identifier. The primary device 702 may be configured to send the second health synchronization object to service provider 730. The primary device 702 may be configured to be responsible for sending the health synchronization object with the first synchronization identity and the health synchronization object with the second synchronization identity to service provider 730.

[0119] At 754, process 700 may include a secondary device 746 sending a first health synchronization object to a primary device 702. The secondary device 746 may also use the synchronization identity of the health synchronization object to determine which health synchronization objects to send to the primary device 702. For example, the secondary device 746 may send health synchronization objects with a synchronization identity associated with the secondary device 746 to the primary device 702. In some examples, the secondary device 746 may send and receive information from the primary device 702 via a short-range communication medium.

[0120] At 756, process 700 may include the master device 702 determining, based on a timing standard, that the slave device 746 has not yet sent the first health synchronization object 730 to the service provider. The timing standard may be within the time period for generating the first health synchronization object, within the time period for receiving the first health information used to generate the first health synchronization object, or within the time period for sending the first health synchronization object to the master device 702.

[0121] At 758, process 700 may include the master device 702 sending a request to the slave device 746 regarding whether the slave device 746 has sent an indication to the service provider 730 of a first health synchronization object. In some examples, if the master device 702 does not receive a response within a certain period of time (e.g., the slave device 746 has or has not yet sent an indication of a specific health synchronization object to the service provider 730), the master device 702 may send the health synchronization object associated with the slave device 746 to the service provider 730.

[0122] At 760, process 700 may include auxiliary device 746 determining, based on a timing standard, that auxiliary device 746 has not yet sent the first health synchronization object 730 to the service provider. The timing standard may be within the time period for generating the first health synchronization object, within the time period for receiving the first health information used to generate the first health synchronization object, or within the time period for sending the first health synchronization object to master device 702.

[0123] In some examples, process 700 includes only one of steps 756, 758, and 760. In some examples, process 700 includes only two of steps 756, 758, and 760.

[0124] At 762, process 700 may include the secondary device 746 sending an indication to the primary device 702 that the secondary device 746 has not yet sent the first health synchronization object to the service provider 730. This indication may be configured to cause the primary device 702 to send the first health synchronization object to the service provider 730. At 764, process 700 may include the primary device 702 sending the first health synchronization object to the service provider 730.

[0125] In some examples, process 700 may also include the master device 702 sending a request to the slave device 746 to indicate whether the slave device 746 has sent a first health synchronization object to the service provider 730.

[0126] In some examples, process 700 may further include master device 702 receiving second health information associated with a user profile. Process 700 may further include master device 702 generating a second health synchronization object based on the second health information. The second health synchronization object may include a second synchronization identity, which includes a second hardware identifier indicating master device 702 and a first database identifier. Process 800 may further include master device 702 sending the second health synchronization object to service provider 730.

[0127] In some examples, process 700 may also include a request from primary device 702 for secondary device 746 to receive an indication of whether secondary device 746 has sent a first health synchronization object 730 to the service provider.

[0128] In some examples, process 700 may further include a secondary device 746 receiving second health information associated with a user profile. Process 700 may also include the secondary device 746 generating a second health synchronization object based on the second health information. The second health synchronization object may include a first synchronization identity. Process 700 may further include the secondary device 746 sending the second health synchronization object to the service provider 730.

[0129] In some examples, auxiliary device 746 can be configured to store health information limited to health information associated with a health database from the last time period. In some examples, auxiliary device 746 can be configured to delete health information associated with times other than the last time period.

[0130] Figure 8 A flowchart illustrating a process 800 for synchronizing health information across a primary and secondary device, according to at least one example, is shown. According to at least one example, process 800 includes a primary device (e.g., Figure 6 The primary user equipment 602) sends a request to the service provider (e.g., Figure 6 Service provider 630) sends data via auxiliary equipment (e.g., Figure 6 The secondary user equipment (646) generates a health synchronization object. The secondary equipment receives health information (e.g., Figure 1 The secondary device can be configured to send a health synchronization object to the service provider. However, due to resource constraints such as network capacity, bandwidth, power, and / or battery life, the secondary device may be unable to send a health synchronization object to the service provider. The secondary device can send a health synchronization object to the primary device. Once the timing criteria associated with the secondary device sending a health synchronization object to the service provider have not been met, the primary device can send a health synchronization object to the service provider. Health applications on the primary device (e.g., health information 112) generate a health synchronization object. Figure 11 The health application 1110 can perform Figure 8 Process 800. Process 800 is a variation of process 700, which includes... Figure 6 The various components shown perform various functions.

[0131] Process 800 can begin at block 802 by the primary device receiving a first health synchronization object based on first health information associated with a user profile linked to a health database. The service provider can be configured to store the health database. The first health synchronization object may include a first synchronization identity, which includes a first hardware identifier indicating the secondary device and a first database identifier indicating the health database. The secondary device can be configured to send the first health synchronization object to the service provider.

[0132] At box 804, process 800 may include the master device receiving an indication that the slave device has not yet sent a first health synchronization object to the service provider according to a timing standard. The timing standard may be within the time period for generating the first health synchronization object, within the time period for receiving first health information used to generate the first health synchronization object, or within the time period for sending the first health synchronization object to the master device. In some examples, the master device may send and receive information from the slave device via a short-range communication medium.

[0133] At box 806, process 800 may include the primary device sending a first health synchronization object to the service provider. In some examples, the primary device may be responsible for sending a health synchronization object with a first synchronization identity and a health synchronization object with a second synchronization identity to the service provider. The second synchronization identity may be associated with a third user device that is no longer active. In some examples, the primary device may be responsible for sending a health synchronization object with a synchronization identity other than the first synchronization identity to the secondary device.

[0134] In some examples, process 800 may also include the master device sending a request to the slave device indicating whether the slave device has sent a first health synchronization object to the service provider.

[0135] In some examples, the auxiliary device can be configured to store health information limited to health information associated with a health database from the last time period. In some examples, the auxiliary device can be configured to delete health information associated with times other than the last time period.

[0136] In some examples, process 800 may further include the master device receiving second health information associated with a user profile. Process 800 may also include the master device generating a second health synchronization object based on the second health information. The second health synchronization object may include a second synchronization identity, which includes a second hardware identifier indicating the master device and a first database identifier. Process 800 may also include the master device sending the second health synchronization object to a service provider.

[0137] Figure 9 A flowchart illustrating a process 900 for synchronizing health information across a primary and secondary device, according to at least one example, is shown. According to at least one example, process 900 includes a secondary device (e.g., Figure 6 The secondary user equipment 646) sends a signal to the primary equipment (e.g., Figure 6 The primary user equipment (602) sends an instruction to the service provider to send a health synchronization object generated by the secondary equipment. The secondary equipment receives health information (e.g., Figure 1 The secondary device can be configured to send a health synchronization object to the service provider. However, due to resource constraints such as network capacity, bandwidth, power, and / or battery life, the secondary device may be unable to send a health synchronization object to the service provider. The secondary device can send a health synchronization object to the primary device. Once the timing criteria associated with the secondary device sending a health synchronization object to the service provider have not been met, the secondary device can send an instruction to the primary device to send a health synchronization object to the service provider. Process 900 is a variation of process 700, which includes... Figure 6 The various components shown perform various functions. Health applications on auxiliary devices (e.g., Figure 11 The health application 1110 can perform Figure 9 The process is 900.

[0138] Process 900 can begin at box 902 by receiving first health information associated with a user profile via a secondary device. The user profile may be associated with a health database stored by a service provider. In some examples, the secondary device has storage for health information limited to health information associated with the health database from the last time period. In some examples, the secondary device deletes health information associated with times other than the last time period.

[0139] At block 904, process 900 may include a secondary device generating a first health synchronization object based on first health information. The first health synchronization object may include a first synchronization identity, which includes a first hardware identifier indicating the secondary device and a first database identifier indicating a health database. The secondary device may be configured to send the first health synchronization object to a service provider. The primary device may be configured to generate a second health synchronization object including a second synchronization identity, which includes a second hardware identifier indicating the primary device and a first database identifier. The primary device may be configured to send the second health synchronization object to the service provider. The primary device may be configured to be responsible for sending the health synchronization object with the first synchronization identity and the health synchronization object with the second synchronization identity to the service provider.

[0140] At box 906, process 900 may include the secondary device sending a first health synchronization object to the primary device. The secondary device may also use the synchronization identity of the health synchronization object to determine which health synchronization objects to send to the primary device. For example, the secondary device may send a health synchronization object with a synchronization identity associated with the secondary device to the primary device. In some examples, the secondary device may send and receive information from the primary device via a short-range communication medium.

[0141] At box 908, process 900 may include the auxiliary device determining, based on a timing criterion, that it has not yet sent a first health synchronization object to the service provider. The timing criterion may be within the time period for generating the first health synchronization object, within the time period for receiving first health information used to generate the first health synchronization object, or within the time period for sending the first health synchronization object to the master device.

[0142] At block 910, process 900 may include the secondary device sending an indication to the primary device that the secondary device has not yet sent a first health synchronization object to the service provider. This indication may be configured to cause the primary device to send the first health synchronization object to the service provider.

[0143] In some examples, process 900 may also include the secondary device receiving a request from the primary device indicating whether the secondary device has sent a first health synchronization object to the service provider.

[0144] In some examples, process 900 may further include the secondary device receiving second health information associated with a user profile. Process 900 may also include the secondary device generating a second health synchronization object based on the second health information. The second health synchronization object may include a first synchronization identity. Process 900 may also include the secondary device sending the second health synchronization object to a service provider.

[0145] Figure 10 A block diagram 1000 is illustrated according to at least one example for synchronizing health information across multiple devices using various synchronization methods. Block diagram 1000 includes a multi-device health information system using the multi-device health information synchronization technology described herein. The multi-device health information system may include user equipment 1002 (e.g., Figure 1 First user equipment 102), the user equipment stores information with the user (e.g., Figure 1 Health information associated with the account of user 150 (e.g., Figure 1 Health information 110. Health information may include steps taken, calories burned, calorie / food intake, menstrual cycle tracking, medication tracking, health-related recommendations / advice, insights into the user's health, indications of trends in health data, and / or any other kind of health information. Health information on the main device 1002 can be transmitted via service provider 630 (e.g., Figure 1 The service provider 130) synchronizes the data to the user's associated account (e.g., a health information account).

[0146] The account can be accessed through communication with service provider 1030. Health information associated with the account can be stored in health information database 1032 (e.g., Figure 1 The health information database 1032 is used for data exchange. Service provider 1030 can communicate with health information database 1032 and synchronize health information between user devices 1002, 1046 and health information database 1032. Users can also have other user devices sharing the same account, such as user device 1046 (e.g., ...). Figure 1 User device 1002 is exemplified as a handheld portable user device such as a smartphone, while user device 1046 is exemplified as a smartwatch. As described herein, the example user devices can be any suitable user device, such as a smartphone, tablet, media player, laptop, wearable device, smartwatch, etc. In some examples, user devices 1002 and 1046 can be associated with a single user. In some examples, user devices 1002 and 1046 can be associated with different users, but all can have access to the health information database 1032 containing the user's associated health information.

[0147] The techniques described herein also enable user devices 1002 and 1046 to perform outgoing and incoming synchronization operations to service provider 1030 via one or more synchronization methods. Different types of health information can be synchronized using different synchronization methods (in outgoing or incoming operations). Example types of health information may include streaming information, status information, and analytics information. In some examples, streaming information can be synchronized by changing the synchronization method (also referred to as synchronization). In some examples, status information can be synchronized via a status synchronization method. In some examples, analytics information can be synchronized via a context synchronization method.

[0148] Streaming information can include information representing changes over time. For example, streaming information may include step tracking, calorie burn, medication taken over time, heart rate, and any other suitable data or information that changes over time. Streaming data can be considered unbounded because it does not represent the absolute state of information, but rather a change from a previous state. Health information representing streaming information from a user device can be synchronized to the service provider via a change in synchronization method and ultimately to other user devices. Changing the synchronization method can send changes in the health information to the service provider via an outgoing synchronization operation.

[0149] The change synchronization method may also include changes sent by the service provider to other user equipment via an incoming synchronization operation. For example, health information 1010 may be health information synchronized via the change synchronization method. Here, health information 1010 represents streaming information in an outgoing synchronization operation to user equipment 1002. Health object A has changes W and X associated with health object A. When an outgoing synchronization operation is performed on health object A to user equipment 1002, both changes W and X of health object A must be synchronized to user equipment 1002 so that user equipment 1002 has complete information about health object B. Similarly, health object B has changes Y and Z associated with health object B. When an outgoing synchronization operation is performed on health object B to user equipment 1046, both changes Y and Z of health object B must be synchronized to user equipment 1046 so that user equipment 1046 has complete information about health object B.

[0150] In this way, the change synchronization method represents a stream of changes in health information that is periodically synchronized across service provider 1030 and user devices 1002 and 1046. When used for all types of health information, this type of streaming information, kept synchronized across multiple devices via the change synchronization method, can burden the user devices' bandwidth consumption, network resources, computing / processing power, and battery life. Therefore, the change synchronization method can only be used for critical health information or health information that can be optimally represented as a change log. Examples of health information that can be optimally represented as a change log include step tracking, calorie burning, heart rate, etc. However, the change synchronization method may not be optimal when devices have limited resources for bandwidth, network, computing / processing power, and / or battery life. For example, synchronizing health information to user device 1046 (a smartwatch) via the change synchronization method may place excessive demands on user device 1046's resources (such as bandwidth, network, and battery life). For this reason, synchronizing state information via the state synchronization method as described herein may be better when synchronizing health information to devices such as user device 1046.

[0151] Another type of health information can be status information. Status information represents a bounded segment of information that indicates the actual state of the information. Status information differs from streaming information intended to convey changes that have already occurred. In some examples, status information is defined to a time window, such that the status information represents the actual state during that time window. For example, a user's current list of medications can be stored as status information because the current list of medications represents the actual state of the medication list. Examples of streaming information associated with a medication list could be changes in medication dosage or changes in medication over time. Other examples of status information could include a list of a user's illnesses, ailments, and conditions at a specific time.

[0152] State information can be synchronized between user equipment 1002, 1046 and service provider 1030 via a state synchronization method. This state synchronization method can be used to synchronize state information across a multi-device health information system. The state synchronization method enables user equipment 1002, 1046 and service provider 1030 to send the actual state of health information, rather than changes in health information over time (e.g., streaming information as described herein). The state synchronization method can provide a high level of consistency and accuracy for health information represented as state information across multiple user equipments, because each user equipment knows that the state information represents the actual health information, not the stream of changes to health information as seen in streaming information. The state synchronization method can also reduce the resources required to synchronize health information at user equipment 1002, 1046 and service provider 1030 by reducing the need to constantly send and receive changes to health information. This can be seen with respect to health object A in health information 1010, which requires both changes W and X, while health object D in health information 1012 only requires state L. As more changes related to health are recorded, more health information will need to be sent and received across multi-device health information systems to maintain consistent information across multiple devices. In some examples, streaming information can be defined within state information. In one example, a user's medication history is represented by a stream of medication names and dosages. The dosage stream can be defined within a window of the history of dosages taken during a specific time period. By defining the dosage stream within a window, the dosage history becomes a state that can be synchronized via state synchronization methods.

[0153] refer to Figure 10 Health information 1012 can be health information synchronized via a state synchronization method. Here, health information 1012 represents state information (also known as bounded information) in an outgoing synchronization operation to user equipment 1002. Health object D has state L. When an outgoing synchronization operation of health object D to user equipment 1002 is performed, only the state L of health object D must be synchronized to user equipment 1002 so that user equipment 1002 has complete information about health object D. Similarly, health object E has state M. When an outgoing synchronization operation of health object E to user equipment 1046 is performed, only the state M of health object E must be synchronized to user equipment 1046 so that user equipment 1046 has complete information about health object E.

[0154] Synchronizing health information via state synchronization methods can be less resource-intensive than changing synchronization methods. For example, changing synchronization methods can involve transmitting a stream of changes to health information over time so that the health information eventually becomes consistent across multiple devices. In one example, tracking taken medications via changing synchronization could include updates each time the medication is taken. This type of synchronization may place demands on bandwidth, network, computing / processing power, and / or battery life at the user's device and / or service provider. Alternatively, tracking taken medications as a state represents the state of the medication taken at a specific time or during a specific window. State synchronization can achieve relatively fast consistency across multi-device health information systems because the synchronization of health information represents a panorama of health information at a specific time, rather than a best-effort delivery of changes to health information over time.

[0155] Another type of health information can be stored as analytical information on both the user's device and the service provider. Analytical information includes observations, recommendations, diagnoses, algorithms, predictions, and any other suitable information that can be used for analysis, based on raw health information. For example, diagnosing a person with a disease or ailment based on symptoms is an example of analytical information. Analytical information is highly dependent on the algorithms and / or processing of the raw health information. Raw health information may include symptoms, heart rate, temperature, blood oxygen, etc. However, the algorithms used in different health applications can change with the version of the application. Algorithms can also differ based on computing and / or other resources on the user's device, or can change due to updates in science / understanding. To synchronize analytical information across multiple devices with potentially different algorithms, context synchronization methods can be used to synchronize applicable health information.

[0156] To generate consistent analytics across a multi-device health information system, the service provider needs to understand the context of each user device. The service provider can store device information for each user device. For example, the service provider can store the type of user device, such as whether the user device is a smartphone, smartwatch, laptop, tablet, etc. An example of device information can be seen at device information 1034, which includes a device identifier (or name), device type, and key value. Service provider 1030 can store device information 1034 for all devices associated with the user account, service provider 1030, and health information database 1032. The device identifier can be a unique identifier for a particular type of device. Device types can include types of user devices such as smartphones, tablets, smartwatches, laptops, and other types. By storing device information, smarter synchronization of health information can be achieved. When synchronizing health information across multiple devices, smarter synchronization can reduce power consumption requirements. Each device can see the reduction in power consumption used for synchronizing health information.

[0157] Analysis information can be synchronized between user devices 1002 and 1046 and service provider 1030 via context synchronization methods. One way to use context synchronization methods is to synchronize analysis information across a multi-device health information system. Context synchronization methods can be used to create consistent analysis information from a multi-device health information system by merging analysis information from multiple user devices, which may have generated different analysis information based on the algorithms of each user device. When determining how to merge health information (e.g., analysis information) across users' health information databases, software and / or applications on the user devices and service provider can use device context records and device-specific key value data. User devices can query key value data and device context records of other devices for use in the synchronization operation. In some examples, service provider 1030 will use device information and / or associated key values ​​to determine which specific device in the user devices has access to a more accurate and / or more precise algorithm, allowing the service provider to merge analysis information by selecting which analysis information to store from that specific device. Service provider 1030 can then perform an incoming synchronization operation to transmit the analysis information back to all user devices in the multi-device health information system.

[0158] When a user device is configured to connect to a multi-device health information system, service provider 1030 can receive device information. For example, when user device 1002 first enables synchronization of health data to service provider 1030 via an account, user device 1002 (or software on the user device) can create a device context record and transmit the device context record to the service provider. The device context record may include device information such as a unique device identifier and / or device type. The device context record may be stored in a database table (such as device information 1034) at service provider 1030.

[0159] Other device-specific information can also be used by the service provider 1030 and / or user devices 1002 and 1046 in the multi-device health information system. For example, the service provider 1030 may also store device-specific key value data that can be used for software and applications on the user devices. Example key value data may include other device-specific information, such as the operating system version for the operating system on the device and / or the application version for the applications on the device. User devices 1002 and 1046 and / or service provider 1030 can query the device-specific key value data of the user devices in the multi-device health information system from the service provider 1030. The key value can be specified by the software and / or applications on user devices 1002 and 1046.

[0160] The context synchronization method can also be used in conjunction with other synchronization methods to determine the optimal time and / or circumstances for synchronizing health information to and from specific user devices 1002 and 1046. For example, service provider 1030 can use device information to determine that specific user device 1046 is a smartwatch with limited resources. Service provider 1030 can determine when not to synchronize health information to specific user devices and / or when to synchronize health information to specific user devices. For example, if the receiving user device is a smartwatch or other device with limited functionality (such as a secondary device), service provider 1030 can perform incoming synchronization operations less frequently. Alternatively, service provider 1030 can determine to perform incoming synchronization operations to the primary device rather than the secondary device. In such cases, the primary device can then synchronize health information to the secondary device.

[0161] Figure 11 An example architecture or environment 1100, configured to implement techniques related to the sharing of health data updates between user devices, is illustrated according to at least one example. In some examples, example architecture 1100 may also be configured to enable user device 1102 (e.g., user devices 102, 104, 106, 146, 148), service provider computer 1104 (e.g., service provider 130), and wearable electronic device 1105 (e.g., example auxiliary devices such as auxiliary device 146) to share information. In some examples, these devices may be connected via one or more networks 1108 and / or 1106 (e.g., via Bluetooth, WiFi, the Internet, etc.). In architecture 1100, one or more users may use user device 1102 to manage, control, or otherwise utilize wearable electronic device 1105 via one or more networks 1106. Additionally, in some examples, wearable electronic device 1105, service provider computer 1104, and user device 1102 may be configured or otherwise constructed as a single device. For example, wearable electronic device 1105 and / or user device 1102 can be configured to implement the examples described herein as a single computing unit, performing the examples described above and below without requiring the description of other devices.

[0162] In some examples, networks 1106 and 1108 may include any or a combination of many different types of networks, such as wired networks, the Internet, wireless networks, cellular networks, satellite networks, other private networks and / or public networks, or any combination thereof. While the illustrated examples represent user equipment 1102 accessing service provider computer 1104 via network 1108, the described techniques can be equally applied to instances where user equipment 1102 interacts with service provider computer 1104 via a landline telephone, a public phone booth, or any other means. It should also be noted that the described techniques can be applied to other client / server deployments (e.g., set-top boxes, etc.) as well as non-client / server deployments (e.g., locally stored applications, peer-to-peer configurations, etc.).

[0163] As described above, user device 1102 may be configured to collect and / or manage user activity data that may be received from wearable electronic device 1105. In some examples, wearable electronic device 1105 may be configured to provide the user's health, fitness, activity, and / or medical data to third-party or first-party applications (e.g., service provider computer 1104). This data may then be used by user device 1102 to identify trends and / or for sharing. User device 1102 may be any type of computing device, such as, but not limited to, mobile phones, smartphones, personal digital assistants (PDAs), laptops, desktop computers, thin client devices, tablet computers, wearable devices, etc. In some examples, user device 1102 may communicate with service provider computer 1104 and / or wearable electronic device 1105 via network 1108, 1106, or other network connections.

[0164] In one exemplary configuration, user equipment 1102 may include at least one memory 1114 and one or more processing units (or processors) 1116. Processor 1116 may be implemented in hardware, computer-executable instructions, firmware, or a combination thereof, as appropriate. The computer-executable instructions or firmware implementation of processor 1116 may include computer-executable instructions or machine-executable instructions written in any suitable programming language to perform the various functions described. User equipment 1102 may also include a geolocation device (e.g., a Global Positioning System (GPS) device, etc.) for providing and / or recording geolocation information associated with user equipment 1102. In some examples, wearable user equipment 1105 may also include a geolocation device for providing and / or recording geolocation information associated with wearable user equipment 1105.

[0165] Memory 1114 may store program instructions that can be loaded and executed on processor 1116, as well as data generated during the execution of these programs. Depending on the configuration and type of user equipment 1102, memory 1114 may be volatile memory (such as random access memory (RAM)) and / or non-volatile memory (such as read-only memory (ROM), flash memory, etc.). User equipment 1102 may also include additional removable storage devices and / or non-removable storage devices 1126, including but not limited to magnetic storage devices, optical disc and / or magnetic tape storage devices. Disk drives and their associated non-transitory computer-readable media may provide non-volatile storage devices for computer-readable instructions, data structures, program modules and other data for computing devices. In some specific implementations, memory 1114 may include a variety of different types of memory, such as static random access memory (SRAM), dynamic random access memory (DRAM) or ROM. Although the volatile memory described herein may be referred to as RAM, any volatile memory in which the data stored will not be retained after being removed from the host and / or power supply is appropriate.

[0166] The removable and non-removable memory 1114 and the additional storage device 1126 are examples of non-transitory computer-readable storage media. For example, non-transitory computer-readable storage media may include volatile or non-volatile, removable or non-removable media implemented by any method or technology for storing information such as computer-readable instructions, data structures, program modules, or other data. Memory 1114 and additional storage device 1126 are examples of non-transitory computer storage media. Additional types of computer storage media that may be present in user equipment 102, 104, 106, 146, 148 may include, but are not limited to: phase-change RAM (PRAM), SRAM, DRAM, RAM, ROM, electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, optical disc read-only memory (CD-ROM), digital video disc (DVD) or other optical storage devices, magnetic tape cassettes, magnetic tape, disk storage devices or other magnetic storage devices, or any other medium that can be used to store desired information and can be accessed by user equipment 1102. Any combination of the above should also be included within the scope of non-transitory computer-readable storage media. Alternatively, a computer-readable communication medium may include computer-readable instructions, program modules, or other data transmitted within a data signal such as a carrier wave or other transmission means. However, as used herein, a computer-readable storage medium does not include a computer-readable communication medium.

[0167] User device 1102 may also include a communication connection 1128 that allows user device 1102 to communicate with a data repository, another computing device or server, user terminal and / or other devices via networks 1108, 1106. User device 1102 may also include I / O devices 1130, such as a keyboard, mouse, pen, voice input device, touch input device, display, operating system 1132 and / or one or more applications or services for implementing the features disclosed herein, including health application 1110 (1). In some examples, health application 1110 (1) may be configured to implement the features described herein. As detailed in the following figures, wearable user device 1105 may include memory that includes a similar health application 1110 (2) that may be accessed by one or more processors of wearable user device 1105. Service provider computer 1104 may also include memory 1142 that includes health application 1110 (3). In this way, the technology described herein can be implemented by any one or a combination of more than one of computing devices (e.g., wearable user device 1105, user device 1102, or service provider computer 1104).

[0168] The service provider computer 1104 can also be any type of computing device, such as, but not limited to, mobile phones, smartphones, PDAs, laptops, desktop computers, thin client devices, tablet computers, wearable devices, server computers, virtual machine instances, etc. In some examples, the service provider computer 1104 can communicate with the user equipment 1102 and / or wearable user equipment 1105 via networks 1108, 1106 or other network connections.

[0169] In one exemplary configuration, the service provider computer 1104 may include at least one memory 1142 and one or more processing units (or processors) 1144. The processor 1144 may be implemented, as appropriate, in hardware, computer-executable instructions, firmware, or a combination thereof. The specific implementation of the computer-executable instructions or firmware of the processor 1144 may include computer-executable instructions or machine-executable instructions written in any suitable programming language to perform the various functions described.

[0170] Memory 1142 may store program instructions that can be loaded and executed on processor 1144, as well as data generated during the execution of these programs. Depending on the configuration and type of service provider computer 1104, memory 1142 may be volatile memory (such as RAM) and / or non-volatile memory (such as ROM, flash memory, etc.). Service provider computer 1104 may also include additional removable storage devices and / or non-removable storage devices 1146, including but not limited to magnetic storage devices, optical disk and / or magnetic tape storage devices. Disk drives and their associated non-transitory computer-readable media may provide non-volatile storage devices for computer-readable instructions, data structures, program modules, and other data to computing devices. In some specific implementations, memory 1142 may include a variety of different types of memory, such as SRAM, DRAM, or ROM. Although the volatile memory described herein may be referred to as RAM, any volatile memory in which the data stored will not be retained after being removed from the host and / or power supply is appropriate. Removable and non-removable memory 1142 and additional storage device 1146 are additional examples of non-transitory computer-readable storage media.

[0171] The service provider computer 1104 may also include a communication connection 1148 that allows the service provider computer 1104 to communicate with a data repository, another computing device or server, user terminals and / or other devices via networks 1108 and 1106. The service provider computer 1104 may also include I / O devices 1150, such as a keyboard, mouse, pen, voice input device, touch input device, monitor, speaker, printer, etc.

[0172] Turning to the contents of memory 1142 in more detail, memory 1142 may include operating system 1152 and / or one or more applications or services for implementing the features disclosed herein, including health application 1110 (3).

[0173] The examples described herein can take the form of suitable wearable electronic devices, be incorporated into suitable wearable electronic devices, or operate together with suitable wearable electronic devices. One example of such a device is... Figure 12 The figure illustrates and takes the form of a wearable mechanism 1200. As shown, the mechanism 1200 can be worn on a user's wrist and secured to the wrist by a strap. The mechanism 1200 can have various functions, including but not limited to: keeping time; monitoring the user's physiological signals and providing health-related information based at least in part on these signals; communicating with other electronic devices (via wired or wireless means), which can be different types of devices with different functions; providing alerts to the user, which may include audio, tactile, visual and / or other sensory outputs, any one or all of which can be synchronized with each other; visually depicting data on a display; collecting data from one or more sensors that can be used to activate, control or modify the operation of the device; determining the location of a touch on the device surface and / or the magnitude of the force applied to the device, and using any one or both as input; accepting voice input to control one or more functions; accepting tactile input to control one or more functions; and so on.

[0174] Other suitable electronic devices include telephones; tablet computing devices; portable media players; and so on. Other suitable electronic devices may include laptops / notebooks, personal digital assistants, touchscreens, input-sensitive tablets, or Surface tablets.

[0175] In some examples, the electronic device may accept various straps, strips, or other retaining mechanisms (collectively, "belts"). These straps can be removably attached to the electronic device via lugs received in recesses or other openings within the device. The lugs may be part of the strap or may be detachable (and / or independent) from the strap. Generally, the lugs lock into recesses in the electronic device to maintain the connection between the strap and the device. The user can release the locking mechanism to allow the lugs to slide out or otherwise remove from the recess. In some examples, the recess may be formed in the strap, and the lugs may be attached to or integrated into the device.

[0176] Users can change the combination of the belt and the electronics, allowing for mixing and matching of the two categories. It should be understood that devices with other forms and / or functions can include similar recesses and can releasably mate with lugs and / or belts in combination with lugs. In this way, an ecosystem of belts and devices can be envisioned, where each belt and device can be compatible with each other. As another example, a single belt can be used to connect devices; in such examples, the belt can include electrical interconnects that allow two devices to send signals to each other and thus interact with each other.

[0177] In many examples, electronic devices can tell and display time, essentially functioning as watches, etc. Time can be displayed in analog or digital format, depending on the device, its settings, and (in some cases) the user's preferences. Typically, the time is displayed on a digital display overlay that forms part of the device's exterior.

[0178] Display stacks may include overlay elements, such as cover glass, that cover the display. The cover glass does not necessarily have to be made of glass, but glass is an option; it can be made of sapphire, zirconium oxide, alumina, chemically strengthened glass, hardened plastic, etc. Similarly, the display can be a liquid crystal display, an organic light-emitting diode display, or any other suitable display technology. Among other components, in some examples, display stacks may include a backlight.

[0179] The device may also include one or more touch sensors to determine the location of a touch on the cover glass. The touch sensors may be integrated into or on the display stack to determine the location of the touch. In some examples, the touch sensors may be self-capacitive, in others they may be mutual-capacitive, or a combination thereof.

[0180] Similarly, the device may include a pressure sensor to determine the magnitude of the force applied to the cover glass. In some examples, the force sensor may be a capacitive sensor, while in others it may be a strain sensor. In either example, the force sensor is typically transparent and made of a transparent material, or located below or away from the display to avoid interfering with the view of the display. The force sensor may, for example, take the form of two capacitive plates separated by silicone or other deformable materials. As the capacitive plates are brought closer together under the action of an external force, the change in capacitance can be measured, and the value of the external force is correlated with the change in capacitance. Furthermore, by comparing the relative capacitance changes from the force sensor or from multiple points on the force sensor, one or more locations where the force is applied can be determined. In one example, the force sensor may take the form of a pad extending below the periphery of the display. Depending on the example, the pad may be segmented or integral.

[0181] Electronic devices can also provide alerts to users. Alerts can be generated in response to: changes in device status (one example being low power); the device receiving information (such as receiving a message); communication between the device and another entity / device (such as a second-type device notifying the device that a message is pending or communication is in progress); the running status of an application (such as when it is part of a game or when an appointment on the calendar is approaching) or the running status of the operating system (such as when the device is powered on or off); and so on. The number and types of alerts triggered are diverse.

[0182] Alarms can be auditory, visual, tactile, or a combination thereof. A tactile actuator can be housed within the device and can move linearly to generate a tactile output (but in alternative examples, the tactile actuator can be rotary or any other type). A speaker can provide the auditory component of the alarm, and the aforementioned display can provide the visual alarm component. In some examples, a dedicated light, display, or other visual output component can be used as part of the alarm.

[0183] The auditory, tactile, and / or visual components of an alarm can be synchronized to provide the user with an overall experience. One or more components can be delayed relative to other components to create the desired synchronization between them. These components can be synchronized such that they are perceived substantially simultaneously; as an example, the initiation of a tactile output can precede the auditory output, as tactile outputs may require a longer time to be perceived compared to audio. As another example, a tactile output (or a portion thereof) can be initiated substantially before the auditory output, but at a weaker or even subthreshold level, thus allowing the wearer to receive the auditory output.

[0184] Figure 13 An example schematic diagram of an electronic device 1300 is depicted. Electronic device 1300 is an example of wearable user device 1105 and / or user device 1102 (and other user devices described herein). Figure 13 As shown, device 1300 includes one or more processing units 1302 configured to access memory 1304 on which instructions are stored.

[0185] Both removable and non-removable memory 1304 are examples of non-transitory computer-readable storage media. For example, non-transitory computer-readable storage media may include volatile or non-volatile, removable or non-removable media implemented by any method or technology for storing information such as computer-readable instructions, data structures, program modules, or other data. Memory 1304 is an example of non-transitory computer storage media. Additional types of computer storage media that may be present in user equipment 102, 104, 106, 146, 148 may include, but are not limited to: phase-change RAM (PRAM), SRAM, DRAM, RAM, ROM, EEPROM, flash memory or other memory technologies, optical disc read-only memory (CD-ROM), digital video disc (DVD) or other optical storage devices, magnetic tape cassettes, magnetic tape, disk storage devices or other magnetic storage devices, or any other medium that can be used to store desired information and can be accessed by user equipment 1300. Any combination of the above should also be included within the scope of non-transitory computer-readable storage media. Alternatively, computer-readable communication media may include computer-readable instructions, program modules, or other data transmitted within data signals such as carrier waves or other transmission means. However, as used herein, computer-readable storage media do not include computer-readable communication media.

[0186] Instructions or computer programs may be configured to perform one or more of the operations or functions described relative to device 1300 (e.g., health application 710(2)). For example, instructions may be configured to control or coordinate the operation of various components of the device. Such components include, but are not limited to, a display 1306, one or more input / output components 1308, one or more communication channels 1310, one or more sensors 1312, a speaker 1314, a microphone 1316, a battery 1318, a wireless power supply 1320, a biosensor 1322, and / or one or more haptic feedback devices 1324. In some examples, the speaker and microphone may be combined into a single unit and / or share a common port through the device's housing.

[0187] Figure 13 The processing unit 1302 can be implemented as any electronic device capable of processing, receiving, or transmitting data or instructions. For example, the processing unit 1302 may include one or more of the following: a microprocessor, a central processing unit (CPU), an application-specific integrated circuit (ASIC), a digital signal processor (DSP), or a combination of such devices. As described herein, the term "processor" is intended to cover a single processor or processing unit, multiple processors, multiple processing units, or one or more other suitably configured computing elements.

[0188] like Figure 13 As shown, device 1300 may also include one or more acoustic elements, including a speaker 1314 and / or a microphone 1316. The speaker 1314 may include driving electronics or circuitry and may be configured to generate audible sound or sound signals in response to a command or input. Similarly, the microphone 1316 may also include driving electronics or circuitry and is configured to receive audible sound or sound signals in response to a command or input. The speaker 1314 and microphone 1316 may be acoustically coupled to a port or opening in the housing that allows acoustic energy to pass through but prevents the ingress of liquids and other debris.

[0189] The exemplary electronic device can communicate with other electronic devices via wired or wireless connections. Data can be transferred between devices, allowing one device to relay information to another; control another device; utilize the sensors, outputs, and / or inputs of another device; and so on. Figure 14 A user 1400 wearing a first electronic device 1402 is depicted, with a second electronic device 1404 in the user's pocket. Data can be wirelessly transmitted between the electronic devices 1402 and 1404, allowing the user 1400 to receive, view, and interact with data from the second device 1404 via the first electronic device 1402. Therefore, the user 1400 can access some or all of the functionality of the second device through the first electronic device 1402 without actually interacting directly with the second device 1404. In some examples, the second electronic device 1404 may be an example of a user device 1202. The first electronic device 1402 may be an example of a wearable user device 1205.

[0190] Furthermore, electronic devices 1402 and 1404 can not only cooperate to share data, but also share functionality. For example, one of these devices can combine sensors, applications, or functions lacking in the other device. An electronic device lacking such functionality can request these capabilities from another device, which can wirelessly share them with the requesting device. Thus, multiple devices can operate together to provide extended functionality, software, access, etc., between two devices and ultimately to the user. As a non-limiting example, electronic device 1402 may not be able to make or receive calls, while the second device 1404 may be able to perform these operations. Nevertheless, a user can make and / or receive calls through the first device 1402, which can utilize the second device 1404 to actually make or receive calls.

[0191] As another non-limiting example, electronic device 1402 can wirelessly communicate with nearby point-of-sale terminals, allowing users to conduct transactions quickly and efficiently, such as selling, buying, or returning goods. The electronic device can use near-field communication (NFC) technology to perform these and other functions.

[0192] As mentioned above, a strip can connect two electronic devices and can serve as a wired communication path between them. As another example, the devices can communicate wirelessly, allowing one device to relay information from a second device to a user. This latter example can be particularly useful when the second device is inaccessible.

[0193] Some examples may include one or more biometric sensors to measure certain physiological characteristics of a user. For example, the device may include a photoplethysmography (PPG) sensor to determine a user's heart rate or blood oxygen level. The device may also, or alternatively, include electrodes for measuring the user's body impedance, which can allow the device to estimate body fat percentage, body electrical activity, body impedance, etc. Blood pressure, ultraviolet exposure, etc., are also included. Depending on the sensors incorporated into or associated with the electronic device, various user characteristics can be measured and / or estimated, allowing for the provision of diverse health data to the user. In some examples, the sensed biometric data can be used in part to determine a user's historical activity data, current activity data, and / or predict the user's activity data.

[0194] Some examples can be wirelessly charged. For instance, an inductive charging dock can send power to an inductive receiver within the device to charge its battery. Furthermore, data can be transferred between the device and the dock by altering the inductive field between them. As a simple, non-limiting example, this can be used to wake the dock from a low-power sleep state to an active charging state when the device is placed on it. Other wireless charging systems (e.g., near-field magnetic resonance and radio frequency) can also be used. Alternatively, the device can also employ wired charging via electrodes.

[0195] In some examples, the device may include a rotary input, which may take the form of a crown with a rod. The crown and rod can be rotated to provide the rotary input. The rotation of the rod and / or crown can be sensed optically, electrically, magnetically, or mechanically. Furthermore, in some examples, the crown and rod may also move laterally, thereby providing a second type of input to the device.

[0196] Similarly, electronic devices may include one or more buttons. A button (or one or more buttons) can be pressed to provide another input to the device. In various examples, a button may be a spring switch, a rocker switch, an electrical contact, a magnetic switch, etc. In some examples, a button may be waterproof or otherwise sealed to protect it from environmental influences.

[0197] Various examples may include or otherwise combine one or more motion sensors. Motion sensors can detect movement of the device and, at least in part, provide, modify, stop, or otherwise influence the state, output, or input of the device or associated applications based on that movement. As a non-limiting example, movement can be used to mute the device or acknowledge alarms generated by the device. Example motion sensors include accelerometers, gyroscopes, magnetometers, GPS sensors, distance sensors, etc. Some examples may use GPS sensors to facilitate or enable location and / or navigation assistance.

[0198] Some examples may incorporate ambient light sensors. Ambient light sensors allow devices to sense the brightness of their surroundings and adjust certain operating parameters accordingly. For example, electronic devices can modify the brightness of their displays in response to sensed ambient light. As another example, if very little light or no light is sensed for a period of time, the electronic device can turn off the display.

[0199] These functions, as well as other features, operations, and capabilities of the electronic device, will become apparent as you read through the instruction manual.

[0200] Some examples of wearable electronic devices may include one or more sensors that can be used to calculate health indicators or other health-related information. As an example, a wearable electronic device can function as a wearable health assistant that provides health-related information (in real-time or non-real-time) to the user, an authorized third party, and / or associated monitoring devices.

[0201] The exemplary methods and systems for managing user equipment connections are described above. Some or all of these systems and methods may, but do not necessarily need to, be at least partially comprised of, such as at least Figures 1 to 14 The architectures shown are used to implement this. While many examples have been described above with reference to personal, activity, and / or health-related information, it should be understood that these techniques can be used to manage any type of user information or non-user information (e.g., any type of data). Furthermore, various non-limiting examples have been described in the foregoing description. For illustrative purposes, many specific configurations and details have been elaborated to provide a thorough understanding of the examples. However, it will also be apparent to those skilled in the art that some examples can be implemented without these specific details. Additionally, well-known features have sometimes been omitted or simplified to prevent confusion with the examples described herein.

[0202] Further embodiments are described below to facilitate understanding of this disclosure.

[0203] Example 1. In this example, a computer-implemented method is provided, the method comprising: A health database is received from a service provider at a first user device associated with a user profile, the health database being associated with the user profile and the service provider being configured to store the health database. Receive first health information associated with the user profile and collected at least in part by the first user equipment at the first user equipment; A first health synchronization object is generated at the first user equipment based on the first health information. The first health synchronization object includes a first synchronization identity, which includes a first hardware identifier indicating the first user equipment and a first database identifier indicating the health database. At the first user equipment, the first health synchronization object is determined to be sent to the service provider based on the first user equipment's responsibility to send a health synchronization object with the first synchronization identity to the service provider; and Send the first health synchronization object to the service provider.

[0204] Example 2. In this example, a method according to any one of the foregoing or subsequent examples is provided, the method further comprising: receiving a second health synchronization object, the second health synchronization object including a second synchronization identity, the second synchronization identity including a second hardware identifier indicating a second user equipment and a first database identifier indicating the health database.

[0205] Example 3. In this example, a method according to any one of the foregoing or subsequent examples is provided, the method further comprising: determining, at the first user equipment, not to send the second health synchronization object to the service provider based on the first user equipment not being responsible for sending the health synchronization object with the second synchronization identity to the service provider.

[0206] Example 4. In this example, a method according to any one of the foregoing or subsequent examples is provided, the method further comprising: At the first user equipment, the system determines to send the second health synchronization object to the service provider based on the first user equipment's responsibility to send a health synchronization object with the second synchronization identity to the service provider; and Send the second health synchronization object to the service provider.

[0207] Example 5. In this example, a method according to any one of the foregoing or subsequent examples is provided, wherein the second synchronization identity is associated with a secondary device, and wherein the method further includes: receiving at the first user equipment an indication that the secondary device has not sent the first health synchronization object to the health database according to a timing standard.

[0208] Example 6. In this example, a method according to any one of the foregoing or subsequent examples is provided, wherein the second synchronization identity is associated with a second user equipment, wherein the second user equipment is no longer active.

[0209] Example 7. In this example, a method according to any one of the foregoing or subsequent examples is provided, wherein the second health synchronization object is received from the service provider, wherein the service provider is configured to send the second health synchronization object to the first user equipment based on determining that the second synchronization identity associated with the second health synchronization object is different from the first synchronization identity associated with the first user equipment.

[0210] Example 8. In this example, a first user equipment is provided, the first user equipment comprising: Memory, the memory being configured to store computer-executable instructions; and One or more processors, the one or more processors communicating with the memory and configured to access the memory and execute the computer-executable instructions to: The first device receives a health database from a service provider, the health database being associated with a user profile, the first device being associated with the user profile, and the service provider being configured to store the health database. Receive first health information associated with the user profile and collected at least in part by the first user device; A first health synchronization object is generated based on the first health information. The first health synchronization object includes a first synchronization identity. The first synchronization identity includes a first hardware identifier indicating the first user equipment and a first database identifier indicating the health database. Based on the fact that the first user equipment is responsible for sending a health synchronization object with the first synchronization identity to the service provider, the first health synchronization object is determined to be sent to the service provider; and Send the first health synchronization object.

[0211] Example 9. In this example, a first user equipment according to any one of the foregoing or subsequent examples is provided, wherein one or more processors are further configured to access the memory and execute the computer-executable instructions to: receive a second health synchronization object, the second health synchronization object including a second synchronization identity, the second synchronization identity including a second hardware identifier indicating the second user equipment and a first database identifier indicating the health database.

[0212] Example 10. In this example, a first user equipment according to any one of the foregoing or subsequent examples is provided, wherein one or more processors are further configured to access the memory and execute the computer-executable instructions to: determine not to send the second health synchronization object to the service provider based on the first user equipment not being responsible for sending the health synchronization object with the second synchronization identity to the service provider.

[0213] Example 11. In this example, a first user equipment according to any one of the foregoing or subsequent embodiments is provided, wherein the one or more processors are further configured to access the memory and execute the computer-executable instructions to: Based on the first user equipment's responsibility to send a health synchronization object with the second synchronization identity to the service provider, the second health synchronization object is determined to be sent to the service provider; and Send the second health synchronization object to the service provider.

[0214] Example 12. In this example, a first user equipment according to any one of the foregoing or subsequent examples is provided, wherein the second synchronization identity is associated with a secondary device, and wherein one or more processors are further configured to access the memory and execute the computer-executable instructions to: receive an indication that the secondary device has not sent the first health synchronization object to the health database according to a timing standard.

[0215] Example 13. In this example, a first user equipment according to any one of the foregoing or subsequent examples is provided, wherein the second synchronization identity is associated with a second user equipment, wherein the second user equipment is no longer active.

[0216] Example 14. In this example, one or more non-transitory computer-readable media are provided, the one or more non-transitory computer-readable media including computer-executable instructions, which, when executed by one or more processors on a first device, cause the one or more processors to perform operations, the operations including: A health database is received from a service provider at a first user device associated with a user profile, the health database being associated with the user profile and the service provider being configured to store the health database. Receive first health information associated with the user profile and collected at least in part by the first user equipment at the first user equipment; A first health synchronization object is generated at the first user equipment based on the first health information. The first health synchronization object includes a first synchronization identity, which includes a first hardware identifier indicating the first user equipment and a first database identifier indicating the health database. At the first user equipment, the first health synchronization object is determined to be sent to the service provider based on the first user equipment's responsibility to send a health synchronization object with the first synchronization identity to the service provider; and Send the first health synchronization object to the service provider.

[0217] Example 15. In this example, one or more non-transitory computer-readable media according to any one of the foregoing or subsequent examples are provided, wherein the operation further includes receiving a second health synchronization object, the second health synchronization object including a second synchronization identity, the second synchronization identity including a second hardware identifier indicating a second user equipment and a first database identifier indicating the health database.

[0218] Example 16. In this example, one or more non-transitory computer-readable media according to any of the foregoing or subsequent examples are provided, wherein the operation further includes determining, at the first user equipment, not to send the second health synchronization object to the service provider based on the first user equipment not being responsible for sending the health synchronization object with the second synchronization identity to the service provider.

[0219] Example 17. In this example, one or more non-transitory computer-readable media according to any one of the foregoing or subsequent embodiments are provided, wherein the operation further includes: At the first user equipment, the system determines to send the second health synchronization object to the service provider based on the first user equipment's responsibility to send a health synchronization object with the second synchronization identity to the service provider; and Send the second health synchronization object to the service provider.

[0220] Example 18. In this example, one or more non-transitory computer-readable media according to any of the foregoing or subsequent embodiments are provided, wherein the second synchronization identity is associated with a secondary device, and wherein the operation further includes: The first user equipment receives an indication that the auxiliary device has not yet sent the first health synchronization object to the health database according to the timing standard.

[0221] Example 19. In this example, one or more non-transitory computer-readable media according to any of the foregoing or subsequent examples are provided, wherein the second synchronization identity is associated with a second user equipment, wherein the second user equipment is no longer active.

[0222] Example 20. In this example, one or more non-transitory computer-readable media according to any of the foregoing or subsequent examples are provided, wherein the service provider is configured to send the second health synchronization object to the first user equipment based on determining that the second synchronization identity associated with the second health synchronization object is different from the first synchronization identity associated with the first user equipment.

[0223] Example 20. In this example, a computer-implemented method is provided, the method comprising: A health database from a service provider is sent to a first user equipment. The health database is associated with a user profile, and the service provider is configured to store the health database. The service provider receives a first health synchronization object from the first user equipment, wherein the first health synchronization object is based on first health information collected at least in part at the first user equipment, and the first health synchronization object includes a first synchronization identity, the first synchronization identity including a first hardware identifier indicating the first user equipment and a first database identifier indicating the health database. The second user equipment is identified at the service provider to receive the first health synchronization object, wherein the second user equipment is associated with the health database; Determine that the first synchronization identity is different from the second synchronization identity associated with the second user equipment; and Based on the determination that the first synchronization identity is different from the second synchronization identity, the first health synchronization object is sent to the second user equipment.

[0224] Example 21. In this example, a computer-implemented method according to any one of the foregoing or subsequent embodiments is provided, the method further comprising: Receive a third health synchronization object at the service provider, wherein the third health synchronization object is associated with a third synchronization identity, the third synchronization identity is associated with a third user equipment, and the third user equipment is no longer active; and The service provider determines not to send the third health synchronization object to the first user equipment based on the fact that the first user equipment is responsible for sending the health synchronization object with the third synchronization identity to the service provider.

[0225] Example 22. In this example, a computer-implemented method according to any one of the foregoing or subsequent embodiments is provided, the method further comprising: The service provider receives a second health synchronization object from the second user equipment. The second health synchronization object includes a second synchronization identity, which includes a second hardware identifier indicating the second user equipment and a first database identifier indicating the health database. The first user equipment is identified at the service provider to receive the second health synchronization object; Determine that the second synchronization identity is different from the first synchronization identity; and Based on the determination that the second synchronization identity is different from the first synchronization identity, the second health synchronization object is sent to the first user equipment.

[0226] Example 24. In this example, a computer-implemented method according to any one of the foregoing or subsequent embodiments is provided, the method further comprising: A third user device is identified at the service provider, wherein the third user device is associated with the health database, and wherein the third user device is a secondary device. The service provider determines not to send the first health synchronization object to the third user equipment based on the fact that the third user equipment is a secondary device.

[0227] Example 25. In this example, a computer-implemented method according to any one of the foregoing or subsequent embodiments is provided, the method further comprising: A third user device is identified at the service provider, wherein the third user device is associated with the health database, and wherein the third user device is an auxiliary device associated with the first user device; The service provider determines not to send the first health synchronization object to the third user equipment based on the fact that the third user equipment is a secondary device associated with the first user equipment.

[0228] Example 26. In this example, a computer-implemented method according to any one of the foregoing or subsequent embodiments is provided, the method further comprising: A third user device is identified at the service provider, wherein the third user device is associated with the health database, and wherein the third user device is a master device associated with the first user device; The service provider determines not to send the first health synchronization object to the third user equipment based on the fact that the third user equipment is a master equipment associated with the first user equipment.

[0229] Example 27. In this example, a computer-implemented method according to any one of the foregoing or subsequent examples is provided, wherein sending the first health synchronization object to the second user equipment is further based on determining that the second user equipment is not responsible for sending a health synchronization object with the first synchronization identity to the service provider.

[0230] Example 28. In this example, a computer system is provided, the computer system comprising: Memory, the memory being configured to store computer-executable instructions; and One or more processors, the one or more processors communicating with the memory and configured to access the memory and execute the computer-executable instructions to: A health database from a service provider is sent to a first user equipment. The health database is associated with a user profile, and the service provider is configured to store the health database. A first health synchronization object is received from the first user equipment, wherein the first health synchronization object is based on first health information collected at least in part at the first user equipment, and the first health synchronization object includes a first synchronization identity, the first synchronization identity including a first hardware identifier indicating the first user equipment and a first database identifier indicating the health database; Identify a second user equipment to receive the first health synchronization object, wherein the second user equipment is associated with the health database; Determine that the first synchronization identity is different from the second synchronization identity associated with the second user equipment; and Based on the determination that the first synchronization identity is different from the second synchronization identity, the first health synchronization object is sent to the second user equipment.

[0231] Example 28. In this example, a computer system according to any one of the foregoing or subsequent embodiments is provided, wherein the one or more processors are further configured to access the memory and execute the computer-executable instructions to: Receive a third health synchronization object, wherein the third health synchronization object is associated with a third synchronization identity, the third synchronization identity is associated with a third user equipment, and wherein the third user equipment is no longer active; and Based on the fact that the first user equipment is responsible for sending a health synchronization object with the third synchronization identity to the service provider, it is determined not to send the third health synchronization object to the first user equipment.

[0232] Example 29. In this example, a computer system according to any one of the foregoing or subsequent embodiments is provided, wherein the one or more processors are further configured to access the memory and execute the computer-executable instructions to: Receive a second health synchronization object from the second user equipment. The second health synchronization object includes a second synchronization identity, which includes a second hardware identifier indicating the second user equipment and a first database identifier indicating the health database. Identify the first user equipment to receive the second health synchronization object; Determine that the second synchronization identity is different from the first synchronization identity; and Based on the determination that the second synchronization identity is different from the first synchronization identity, the second health synchronization object is sent to the first user equipment.

[0233] Example 30. In this example, a computer system according to any one of the foregoing or subsequent embodiments is provided, wherein the one or more processors are further configured to access the memory and execute the computer-executable instructions to: Identify a third user device, wherein the third user device is associated with the health database, and wherein the third user device is a secondary device; Based on the fact that the third user equipment is a secondary device, it is determined not to send the first health synchronization object to the third user equipment.

[0234] Example 31. In this example, a computer system according to any one of the foregoing or subsequent embodiments is provided, wherein the first user equipment is a main device, and wherein the one or more processors are further configured to access the memory and execute the computer-executable instructions to: Identify a third user device, wherein the third user device is associated with the health database, and wherein the third user device is an auxiliary device associated with the first user device; The decision is made not to send the first health synchronization object to the third user equipment based on the fact that the third user equipment is an auxiliary device associated with the first user equipment.

[0235] Example 31. In this example, a computer system according to any one of the foregoing or subsequent embodiments is provided, wherein the first user equipment is a secondary device, and wherein the one or more processors are further configured to access the memory and execute the computer-executable instructions to: Identify a third user device, wherein the third user device is associated with the health database, and wherein the third user device is a master device associated with the first user device; Based on the fact that the third user equipment is a master equipment associated with the first user equipment, it is determined not to send the first health synchronization object to the third user equipment.

[0236] Example 34. In this example, a computer system according to any one of the foregoing or subsequent examples is provided, wherein sending the first health synchronization object to the second user equipment is further based on determining that the second user equipment is not responsible for sending a health synchronization object with the first synchronization identity to the service provider.

[0237] Example 35. In this example, one or more non-transitory computer-readable media are provided, the one or more non-transitory computer-readable media including computer-executable instructions, which, when executed by one or more processors of a first device, cause the one or more processors to perform operations, the operations including: A health database from a service provider is sent to a first user equipment. The health database is associated with a user profile, and the service provider is configured to store the health database. A first health synchronization object is received from a first user equipment at the service provider, wherein the first health synchronization object is based on first health information collected at least in part at the first user equipment, and the first health synchronization object includes a first synchronization identity, the first synchronization identity including a first hardware identifier indicating the first user equipment and a first database identifier indicating the health database; The second user equipment is identified at the service provider to receive the first health synchronization object, wherein the second user equipment is associated with the health database; Determine that the first synchronization identity is different from the second synchronization identity associated with the second user equipment; and Based on the determination that the first synchronization identity is different from the second synchronization identity, the first health synchronization object is sent to the second user equipment.

[0238] Example 36. In this example, one or more non-transitory computer-readable media according to any one of the foregoing or subsequent embodiments are provided, wherein the operation further includes: Receive a third health synchronization object at the service provider, wherein the third health synchronization object is associated with a third synchronization identity, the third synchronization identity is associated with a third user equipment, and the third user equipment is no longer active; and The service provider determines not to send the third health synchronization object to the first user equipment based on the fact that the first user equipment is responsible for sending the health synchronization object with the third synchronization identity to the service provider.

[0239] Example 37. In this example, one or more non-transitory computer-readable media according to any one of the foregoing or subsequent embodiments are provided, wherein the operation further includes: The service provider receives a second health synchronization object from the second user equipment. The second health synchronization object includes a second synchronization identity, which includes a second hardware identifier indicating the second user equipment and a first database identifier indicating the health database. The first user equipment is identified at the service provider to receive the second health synchronization object; Determine that the second synchronization identity is different from the first synchronization identity; and Based on the determination that the second synchronization identity is different from the first synchronization identity, the second health synchronization object is sent to the first user equipment.

[0240] Example 38. In this example, one or more non-transitory computer-readable media according to any one of the foregoing or subsequent embodiments are provided, wherein the operation further includes: A third user device is identified at the service provider, wherein the third user device is associated with the health database, and wherein the third user device is a secondary device. The service provider determines not to send the first health synchronization object to the third user equipment based on the fact that the third user equipment is a secondary device.

[0241] Example 39. In this example, one or more non-transitory computer-readable media according to any one of the foregoing or subsequent embodiments are provided, wherein the operation further includes: A third user device is identified at the service provider, wherein the third user device is associated with the health database, and wherein the third user device is an auxiliary device associated with the first user device; The service provider determines not to send the first health synchronization object to the third user equipment based on the fact that the third user equipment is a secondary device associated with the first user equipment.

[0242] Example 40. In this example, one or more non-transitory computer-readable media according to any one of the foregoing or subsequent embodiments are provided, wherein the first user equipment is an auxiliary device, and wherein the operation further includes: A third user device is identified at the service provider, wherein the third user device is associated with the health database, and wherein the third user device is a master device associated with the first user device; The service provider determines not to send the first health synchronization object to the third user equipment based on the fact that the third user equipment is a master equipment associated with the first user equipment.

[0243] Example 41. In this example, a computer-implemented method is provided, the method comprising: The primary device receives a first health synchronization object based on first health information associated with a user profile, the user profile being associated with a health database, the service provider being configured to store the health database, the first health synchronization object including a first synchronization identity, the first synchronization identity including a first hardware identifier indicating a secondary device and a first database identifier indicating the health database, the secondary device being configured to send the first health synchronization object to the service provider; The primary device receives an indication that the secondary device has not yet sent the first health synchronization object to the service provider according to the timing standard; and Send the first health synchronization object to the service provider.

[0244] Example 42. In this example, a computer-implemented method according to any one of the foregoing or subsequent examples is provided, the method further comprising sending a request to the auxiliary device regarding whether the auxiliary device has sent an indication of the first health synchronization object to the service provider.

[0245] Example 43. In this example, a computer-implemented method according to any one of the foregoing or subsequent examples is provided, wherein the auxiliary device is configured to have storage of health information limited to health information associated with the health database from the last time period.

[0246] Example 44. In this example, a computer-implemented method according to any one of the foregoing or subsequent examples is provided, wherein the auxiliary device is configured to delete health information associated with a time other than the last time period.

[0247] Example 45. In this example, a computer-implemented method according to any one of the foregoing or subsequent embodiments is provided, the method further comprising: Receive second health information associated with the user profile at the main device; A second health synchronization object is generated at the master device based on the second health information. The second health synchronization object includes a second synchronization identity, which includes a second hardware identifier indicating the master device and the first database identifier. Send the second health synchronization object to the service provider.

[0248] Example 46. In this example, a computer-implemented method according to any one of the foregoing or subsequent examples is provided, wherein the master device sends and receives information from the auxiliary device via a short-range communication medium.

[0249] Example 47. In this example, a computer-implemented method according to any one of the foregoing or subsequent examples is provided, wherein the master device is responsible for sending a health synchronization object having a first synchronization identity and a health synchronization object having a second synchronization identity to the service provider, the second synchronization identity being associated with a third user device, wherein the third user device is no longer active.

[0250] Example 48. In this example, a computer-implemented method according to any one of the foregoing or subsequent examples is provided, wherein the master device is responsible for sending a health synchronization object having a synchronization identity other than the first synchronization identity to the auxiliary device.

[0251] Example 49. In this example, a main device is provided, the main device comprising: Memory, the memory being configured to store computer-executable instructions; and One or more processors, the one or more processors communicating with the memory and configured to access the memory and execute the computer-executable instructions to: The system receives a first health synchronization object based on first health information associated with a user profile, the user profile being associated with a health database, the service provider being configured to store the health database, the first health synchronization object including a first synchronization identity, the first synchronization identity including a first hardware identifier indicating a secondary device and a first database identifier indicating the health database, the secondary device being configured to send the first health synchronization object to the service provider; The auxiliary device has not yet sent an indication to the service provider regarding the first health synchronization object according to the timing standard; and Send the first health synchronization object to the service provider.

[0252] Example 50. In this example, a main device according to any one of the foregoing or subsequent embodiments is provided, wherein the one or more processors are further configured to access the memory and execute the computer-executable instructions to: Send a request to the auxiliary device regarding whether the auxiliary device has sent an indication of the first health synchronization object to the service provider.

[0253] Example 51. In this example, a primary device according to any one of the foregoing or subsequent examples is provided, wherein the secondary device is configured to have storage of health information limited to health information associated with the health database from the last time period, wherein the secondary device is configured to delete health information associated with times other than the last time period.

[0254] Example 52. In this example, a main device according to any one of the foregoing or subsequent embodiments is provided, wherein the one or more processors are further configured to access the memory and execute the computer-executable instructions to: Receive second health information associated with the user profile; A second health synchronization object is generated based on the second health information. The second health synchronization object includes a second synchronization identity, which includes a second hardware identifier indicating the master device and the first database identifier. Send the second health synchronization object to the service provider.

[0255] Example 53. In this example, a master device according to any one of the foregoing or subsequent examples is provided, wherein the master device is responsible for sending a health synchronization object with the first synchronization identity and a health synchronization object with the second synchronization identity to the service provider, wherein the second synchronization identity is associated with a third user device, wherein the third user device is no longer active.

[0256] Example 54. In this example, a master device according to any one of the foregoing or subsequent examples is provided, wherein the master device is responsible for sending a health synchronization object having a synchronization identity other than the first synchronization identity to the auxiliary device.

[0257] Example 55. In this example, one or more non-transitory computer-readable media are provided, the one or more non-transitory computer-readable media including computer-executable instructions, which, when executed by one or more processors on a first device, cause the one or more processors to perform operations, the operations including: The primary device receives a first health synchronization object based on first health information associated with a user profile, the user profile being associated with a health database, the service provider being configured to store the health database, the first health synchronization object including a first synchronization identity, the first synchronization identity including a first hardware identifier indicating a secondary device and a first database identifier indicating the health database, the secondary device being configured to send the first health synchronization object to the service provider; The primary device receives an indication that the secondary device has not yet sent the first health synchronization object to the service provider according to the timing standard; and Send the first health synchronization object to the service provider.

[0258] Example 56. In this example, one or more non-transitory computer-readable media according to any of the foregoing or subsequent examples are provided, wherein the operation further includes sending a request to the auxiliary device regarding whether the auxiliary device has sent an indication to the service provider of the first health synchronization object.

[0259] Example 57. In this example, one or more non-transitory computer-readable media according to any of the foregoing or subsequent examples are provided, wherein the auxiliary device is configured to have storage of health information limited to health information associated with the health database from a last time period, wherein the auxiliary device is configured to delete health information associated with times other than the last time period.

[0260] Example 58. In this example, one or more non-transitory computer-readable media according to any one of the foregoing or subsequent embodiments are provided, wherein the operation further includes: Receive second health information associated with the user profile at the main device; A second health synchronization object is generated at the master device based on the second health information. The second health synchronization object includes a second synchronization identity, which includes a second hardware identifier indicating the master device and the first database identifier. Send the second health synchronization object to the service provider.

[0261] Example 59. In this example, one or more non-transitory computer-readable media according to any of the foregoing or subsequent examples are provided, wherein the master device is responsible for sending a health synchronization object having a first synchronization identity and a health synchronization object having a second synchronization identity to the service provider, the second synchronization identity being associated with a third user device, wherein the third user device is no longer active.

[0262] Example 60. In this example, one or more non-transitory computer-readable media according to any of the foregoing or subsequent examples are provided, wherein the master device is responsible for sending a healthy synchronization object having a synchronization identity other than the first synchronization identity to the auxiliary device.

[0263] Example 61. In this example, a computer-implemented method is provided, the method comprising: Receive first health information associated with a user profile at the auxiliary device, the user profile being associated with a health database stored by the service provider; A first health synchronization object is generated at the auxiliary device based on the first health information. The first health synchronization object includes a first synchronization identity, which includes a first hardware identifier indicating the auxiliary device and a first database identifier indicating the health database. The auxiliary device is configured to send the first health synchronization object to the service provider. Send the first health synchronization object to the master device; Based on timing criteria, it is determined that the auxiliary device has not yet sent the first health synchronization object to the service provider; and Send an indication to the master device that the slave device has not yet sent the first health synchronization object to the service provider, wherein the indication is configured to cause the master device to send the first health synchronization object to the service provider.

[0264] Example 62. In this example, a computer-implemented method according to any one of the foregoing or subsequent examples is provided, the method further comprising receiving from the master device a request regarding whether the auxiliary device has sent an indication of the first health synchronization object to the service provider.

[0265] Example 63. In this example, a computer-implemented method according to any one of the foregoing or subsequent examples is provided, the method further comprising: Receive second health information associated with the user profile at the auxiliary device; At the auxiliary device, a second health synchronization object is generated based on the second health information, the second health synchronization object including the first synchronization identity; and Send the second health synchronization object to the service provider.

[0266] Example 64. In this example, a computer-implemented method according to any one of the foregoing or subsequent examples is provided, wherein the auxiliary device has storage of health information limited to health information associated with the health database from the last time period.

[0267] Example 65. In this example, a computer-implemented method according to any one of the foregoing or subsequent examples is provided, wherein the auxiliary device deletes health information associated with a time other than the last time period.

[0268] Example 66. In this example, a computer-implemented method according to any one of the foregoing or subsequent examples is provided, wherein the auxiliary device sends and receives information from the master device via a short-range communication medium.

[0269] Example 67. In this example, a computer-implemented method according to any one of the foregoing or subsequent examples is provided, wherein the master device is configured to generate a second health synchronization object including a second synchronization identity, the second synchronization identity including a second hardware identifier indicating the master device and a first database identifier, wherein the master device is configured to send the second health synchronization object to the service provider.

[0270] Example 68. In this example, a computer-implemented method according to any one of the foregoing or subsequent examples is provided, wherein the master device is configured to be responsible for sending a health synchronization object having the first synchronization identity and a health synchronization object having the second synchronization identity to the service provider.

[0271] Example 62. In this example, an auxiliary device is provided, the auxiliary device comprising: Memory, the memory being configured to store computer-executable instructions; and One or more processors, the one or more processors communicating with the memory and configured to access the memory and execute the computer-executable instructions to: Receive first health information associated with a user profile, which is associated with a health database stored by the service provider; A first health synchronization object is generated based on the first health information. The first health synchronization object includes a first synchronization identity. The first synchronization identity includes a first hardware identifier indicating the auxiliary device and a first database identifier indicating the health database. The auxiliary device is configured to send the first health synchronization object to the service provider. Send the first health synchronization object to the master device; Based on timing criteria, it is determined that the auxiliary device has not yet sent the first health synchronization object to the service provider; and Send an indication to the master device that the slave device has not yet sent the first health synchronization object to the service provider, wherein the indication is configured to cause the master device to send the first health synchronization object to the service provider.

[0272] Example 70. In this example, a secondary device according to any one of the foregoing or subsequent examples is provided, wherein the one or more processors are further configured to access the memory and execute the computer-executable instructions to: receive from the primary device a request regarding whether the secondary device has sent an indication to the service provider of the first health synchronization object.

[0273] Example 71. In this example, an auxiliary device according to any one of the foregoing or subsequent embodiments is provided, wherein the one or more processors are further configured to access the memory and execute the computer-executable instructions to: Receive second health information associated with the user profile; A second health synchronization object is generated based on the second health information, the second health synchronization object including the first synchronization identity; and Send the second health synchronization object to the service provider.

[0274] Example 72. In this example, an auxiliary device according to any one of the foregoing or subsequent examples is provided, wherein the auxiliary device has storage of health information limited to health information associated with the health database from the last time period.

[0275] Example 73. In this example, an auxiliary device according to any one of the foregoing or subsequent examples is provided, wherein the auxiliary device sends and receives information from the master device via a short-range communication medium.

[0276] Example 74. In this example, an auxiliary device according to any one of the foregoing or subsequent examples is provided, wherein the master device is configured to generate a second health synchronization object including a second synchronization identity, the second synchronization identity including a second hardware identifier indicating the master device and a first database identifier, wherein the master device is configured to send the second health synchronization object to the service provider, wherein the master device is configured to be responsible for sending the health synchronization object with the first synchronization identity and the health synchronization object with the second synchronization identity to the service provider.

[0277] Example 75. In this example, one or more non-transitory computer-readable media are provided, the one or more non-transitory computer-readable media including computer-executable instructions, which, when executed by one or more processors on a first device, cause the one or more processors to perform operations, the operations including: Receive first health information associated with a user profile at the auxiliary device, the user profile being associated with a health database stored by the service provider; A first health synchronization object is generated at the auxiliary device based on the first health information. The first health synchronization object includes a first synchronization identity, which includes a first hardware identifier indicating the auxiliary device and a first database identifier indicating the health database. The auxiliary device is configured to send the first health synchronization object to the service provider. Send the first health synchronization object to the master device; Based on timing criteria, it is determined that the auxiliary device has not yet sent the first health synchronization object to the service provider; and Send an indication to the master device that the slave device has not yet sent the first health synchronization object to the service provider, wherein the indication is configured to cause the master device to send the first health synchronization object to the service provider.

[0278] Example 76. In this example, one or more non-transitory computer-readable media according to any of the foregoing or subsequent examples are provided, wherein the operation further includes receiving from the master device a request regarding whether the auxiliary device has sent an indication to the service provider of the first health synchronization object.

[0279] Example 77. In this example, one or more non-transitory computer-readable media according to any one of the foregoing or subsequent embodiments are provided, wherein the operation further includes: Receive second health information associated with the user profile at the auxiliary device; At the auxiliary device, a second health synchronization object is generated based on the second health information, the second health synchronization object including the first synchronization identity; and Send the second health synchronization object to the service provider.

[0280] Example 78. In this example, one or more non-transitory computer-readable media according to any of the foregoing or subsequent examples are provided, wherein the auxiliary device has storage of health information limited to health information associated with the health database from the last time period.

[0281] Example 79. In this example, one or more non-transitory computer-readable media according to any of the foregoing or subsequent examples are provided, wherein the auxiliary device deletes health information associated with a time other than the last time period.

[0282] Example 80. In this example, one or more non-transitory computer-readable media according to any one of the foregoing or subsequent examples are provided, wherein the master device is configured to generate a second health synchronization object including a second synchronization identity, the second synchronization identity including a second hardware identifier indicating the master device and a first database identifier, wherein the master device is configured to send the second health synchronization object to the service provider, wherein the master device is configured to be responsible for sending the health synchronization object having the first synchronization identity and the health synchronization object having the second synchronization identity to the service provider.

[0283] Various examples can be further implemented in a wide variety of operating environments. In some cases, the operating environment may include one or more user computers, computing devices, or processing devices that can be used to operate any of a number of applications. User devices or client devices may include any of many general-purpose personal computers, such as desktop or laptop computers running standard operating systems, as well as cellular devices, wireless devices, and handheld devices running mobile software and capable of supporting multiple networking protocols and instant messaging protocols. Such systems may also include multiple workstations running a variety of commercially available operating systems and any of other known applications for purposes such as development and database management. These devices may also include other electronic devices, such as virtual terminals, thin clients, gaming systems, and other devices capable of communicating via a network.

[0284] Most examples utilize at least one network familiar to those skilled in the art to support communication using any of the various commercial protocols such as TCP / IP, OSI, FTP, UPnP, NFS, CIFS, and AppleTalk. The network can be, for example, a local area network (LAN), a wide area network (WAN), a virtual private network (VPN), the Internet, an intranet, an extranet, the public switched telephone network (PSTN), an infrared network, a wireless network, and any combination thereof.

[0285] In the example utilizing a web server, the web server can run any of a variety of server or middleware applications, including HTTP servers, FTP servers, CGI servers, data servers, Java servers, and business application servers. The server can also execute programs or scripts in response to requests from user devices, such as by executing one or more applications, which can be implemented as one or more scripts or programs written in any programming language, such as Java. ® The server may be C, C#, or C++, or any scripting language such as Perl, Python, or TCL, and combinations thereof. The server may also include a database server, including but not limited to those retrievable from Oracle. ® Microsoft ® Sybase ® and IBM ® Those obtained through commercial purchases.

[0286] The environment can include various data repositories and other storage media, as discussed above. These can reside in various locations, such as on storage media local to one or more computers or on storage media of any or all computers on a network (and / or reside within one or more computers). In a particular set of examples, information can reside in a storage area network (SAN) familiar to those skilled in the art. Similarly, any necessary files for performing functions belonging to a computer, server, or other network device may be stored locally and / or remotely as needed. Where the system includes computerized devices, each such device can include hardware elements that can be electrically coupled via a bus, including, for example, at least one central processing unit (CPU), at least one input device (e.g., mouse, keyboard, controller, touchscreen, or keypad), and at least one output device (e.g., display device, printer, or speaker). Such systems may also include one or more storage devices, such as disk drives, optical storage devices, and solid-state storage devices such as RAM or ROM, as well as removable media devices, memory cards, flash memory cards, and so on.

[0287] Such devices may also include computer-readable storage medium readers, communication devices (e.g., modems, network interface cards (wireless or wired), infrared communication devices, etc.), and working memory as described above. Computer-readable storage medium readers may be connected to or configured to receive non-transitory computer-readable storage media representing remote, local, fixed, and / or removable storage devices, as well as storage media for temporarily and / or more permanently containing, storing, transmitting, and retrieving computer-readable information. Systems and various devices typically also include multiple software applications, modules, services, or other elements residing within at least one working memory device, including operating systems and applications such as client applications or browsers. It should be understood that alternative examples may have many variations as described above. For example, custom hardware may also be used, and / or specific elements may be implemented in hardware, software (including portable software such as applets), or both. Furthermore, connections to other computing devices such as network input / output devices may be employed.

[0288] Non-transitory storage media and computer-readable media used for containing code or portions thereof may include any suitable media known or used in the art, including storage media such as, but not limited to, volatile and non-volatile, removable and non-removable media, which may be implemented in any method or technique for storing information such as computer-readable instructions, data structures, program modules or other data, including RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, DVD or other optical storage devices, magnetic tape cassettes, magnetic tape, disk storage devices or other magnetic storage devices, or any other media that may be used to store desired information and may be accessed by system devices. Other ways and / or methods for implementing the various examples will be understood by those skilled in the art, at least in part, based on the disclosure and teachings provided herein.

[0289] Accordingly, the specification and drawings should be regarded as illustrative rather than restrictive. However, it will be apparent that various modifications and changes may be made thereto without departing from the broader spirit and scope of this disclosure as set forth in the claims.

[0290] Other variations are within the scope of this disclosure. Therefore, although the disclosed technology is susceptible to various modifications and alternative constructions, certain illustrative examples are shown in the accompanying drawings and have been described in detail above. However, it should be understood that this disclosure is not intended to be limited to the specific forms disclosed, but rather is intended to cover all modifications, alternative constructions, and equivalents falling within the scope and spirit of this disclosure as defined by the appended claims.

[0291] In the context of describing the disclosed examples (particularly in the context of the claims below), the terms "a," "an," and "the," as well as similar indicator words, shall be interpreted to cover both singular and plural forms, unless otherwise stated or clearly contradicted by the context. Unless otherwise indicated, the terms "comprising," "having," "including," and "containing" shall be understood as open-ended terms (e.g., meaning "including but not limited to"). The term "connected" is interpreted as being partially or wholly included, attached, or joined together, even if there is interference. Unless otherwise stated herein, the description of numerical ranges herein is intended merely as a simple way of referring separately to each individual value falling within that range, and each individual value is incorporated into the specification as if separately referenced herein. All methods described herein can be performed in any suitable order unless otherwise stated or clearly contradicted by the context. Unless otherwise stated, the use of any and all examples or exemplary language (e.g., "such as") provided herein is intended merely to better illustrate examples of this disclosure and does not limit the scope of this disclosure. Nothing in the specification should be construed as indicating that any unstated element is essential to the practice of this disclosure.

[0292] Unless otherwise specifically stated, parse languages ​​such as the phrase "at least one of X, Y, or Z" are understood in context to be generally used to represent items, terms, etc., which can be X, Y, or Z, or any combination thereof (e.g., X, Y, and / or Z). Therefore, such parse languages ​​are generally not intended and should not imply that some examples require that at least one of X, at least one of Y, or at least one of Z each exist.

[0293] This document describes preferred examples of the present disclosure, including the best modes known to the inventors for carrying out the present disclosure. Variations of those preferred examples will become apparent to those skilled in the art after reading the foregoing description. The inventors expect those skilled in the art to appropriately employ such variations, and the inventors intend to practice the present disclosure in ways different from those specifically described herein. Therefore, as permitted by applicable law, this disclosure includes all modifications and equivalents to the subject matter recited in the appended claims. Furthermore, unless otherwise indicated herein or clearly contradicted by the context, this disclosure encompasses any combination of all possible variations of the foregoing elements.

[0294] All references cited in this article, including publications, patent applications and patents, are incorporated herein by reference, as each reference is individually and specifically indicated to be incorporated by reference and elaborated in the entire text.

[0295] As described above, one aspect of the present invention is sharing health data updates between user devices, which may include storing some aspect of the data on a server. This disclosure contemplates that, in some cases, this collected data may include personally identifiable information (PII) data that uniquely identifies or can be used to contact or locate a specific person. Such personal information data may include demographic data, location-based data, telephone numbers, email addresses, Twitter IDs, home addresses, data or records related to a user's health or fitness level (e.g., vital sign measurements, medication information, exercise information), date of birth, health record data, or any other identifying information or personal or health information.

[0296] This disclosure recognizes that the use of such personal information data in the techniques of this invention can be used to benefit users. For example, personal information data can be used to provide family members or friends with a view of updated health data. Furthermore, this disclosure also contemplates other uses of personal information data that are beneficial to users. For example, health and fitness data can be used to provide insights into a user's overall health status or can be used as positive feedback for individuals using the technology to pursue health goals.

[0297] This disclosure anticipates that entities responsible for the collection, analysis, disclosure, transmission, storage, or other use of such personal information data will comply with robust privacy policies and / or privacy measures. Specifically, such entities should implement and adhere to privacy policies and measures that are recognized as meeting or exceeding industry or governmental requirements for maintaining the privacy and security of personal information data. These policies should be readily accessible to users and should be updated as data collection and / or use change. Personal information from users should be collected for legitimate and reasonable entity purposes and should not be shared or sold outside of these legitimate purposes. Furthermore, such collection / sharing should be conducted only after receiving informed consent from users. Additionally, such entities should consider taking any necessary steps to protect and safeguard the right to access such personal information data and ensure that other entities with access to such personal information data comply with the privacy policies and procedures of those other entities. Additionally, such entities may subject themselves to third-party assessments to demonstrate their compliance with widely accepted privacy policies and privacy measures. Moreover, policies and measures should be adapted to the specific types of personal information data collected and / or accessed, and to applicable laws and standards, including considerations of specific jurisdictions. For example, in the United States, the collection or acquisition of certain health data may be governed by federal and / or state laws, such as the Health Insurance Portability and Accountability Act (HIPAA); while in other countries, health data may be subject to other regulations and policies and should be handled accordingly. Therefore, different privacy practices should be maintained for different types of personal data in each country.

[0298] Regardless of the foregoing, this disclosure also anticipates implementation schemes for users to selectively block the use or access to personal information data. That is, this disclosure anticipates providing hardware and / or software components to prevent or block access to such personal information data. For example, in relation to advertising delivery services or other services related to health record management, the inventive technology can be configured to allow users to opt-in or opt-out at any time during or after service registration to participate in the collection of personal information data. In addition to providing "opt-in" and "opt-out" options, this disclosure also anticipates providing notifications related to access to or use of personal information. For example, users may be notified when downloading an application that their personal information data will be accessed, and then reminded again just before the application accesses the personal information data.

[0299] Furthermore, the intent of this disclosure is that personal information data should be managed and processed in a manner that minimizes the risk of unintentional or unauthorized access or use. Once data is no longer needed, this risk can be minimized by restricting data collection and deleting data. Additionally, and where applicable, including in certain health-related applications, data deidentification can be used to protect user privacy. Where appropriate, deidentification can be facilitated by removing specific identifiers (e.g., date of birth), controlling the amount or characteristics of stored data (e.g., collecting location data at the city level rather than the address level), controlling how data is stored (e.g., aggregating data among users), and / or other methods.

[0300] Therefore, while this disclosure broadly covers the use of personal information data to implement one or more of the various disclosed embodiments, it is also contemplated that various embodiments can be implemented without access to such personal information data. That is, various embodiments of the present invention will not become inoperable due to the absence of all or part of such personal information data.< / string> < / string> < / string> < / string> < / string> < / string> < / string> < / string> < / string>

Claims

1. A computer-implemented method, the method comprising: A health database is received from a service provider at a first user device associated with a user profile, the health database being associated with the user profile and the service provider being configured to store the health database. Receive first health information associated with the user profile and collected at least in part by the first user equipment at the first user equipment; At the first user equipment, a first health synchronization object is generated based on the first health information. The first health synchronization object includes a first synchronization identity, which includes a first hardware identifier that indicates the first user equipment to generate the first health synchronization object and a first database identifier that indicates the health database. At the first user equipment, the first health synchronization object is determined to be sent to the service provider based on the first user equipment being configured to send a health synchronization object with the first synchronization identity to the service provider and based on the first user equipment being configured to avoid sending a health synchronization object with a synchronization identity different from the first synchronization identity to the service provider. Send the first health synchronization object to the service provider; A second health synchronization object is received at the first user equipment. The second health synchronization object includes a second synchronization identity, which includes a second hardware identifier indicating the second user equipment and a first database identifier indicating the health database. as well as At the first user equipment, it is determined not to send the second health synchronization object to the service provider based on the fact that the first user equipment does not send a health synchronization object with the second synchronization identity to the service provider.

2. The computer-implemented method according to claim 1, further comprising: The first user equipment receives a third health synchronization object, the third health synchronization object including a third synchronization identity, the third synchronization identity including a third hardware identifier indicating the third user equipment and a first database identifier indicating the health database, and the first user equipment is also configured to send a health synchronization object with the third synchronization identity to the service provider. At the first user equipment, the third health synchronization object is sent to the service provider based on the first user equipment sending a health synchronization object with the third synchronization identity to the service provider; as well as Send the third health synchronization object to the service provider.

3. The computer-implemented method according to claim 2, wherein the third synchronization identity is associated with the auxiliary device, and wherein the method further comprises: The first user equipment receives an indication that the auxiliary device has not yet sent the third health synchronization object to the health database according to the timing standard.

4. The computer-implemented method of claim 2, wherein the third synchronization identity is associated with the third user equipment, wherein the third user equipment is no longer active.

5. The computer-implemented method of claim 1, further comprising receiving a third health synchronization object from the service provider at the first device, the third health synchronization object including a third synchronization identity, the third synchronization identity including a third hardware identifier indicating a third user device and a first database identifier indicating the health database, wherein the service provider is configured to send the third health synchronization object to the first user device based on determining that the third synchronization identity associated with the third health synchronization object is different from the first synchronization identity associated with the first user device.

6. A first user equipment, the first user equipment comprising: A memory configured to store computer-executable instructions; and One or more processors, the one or more processors communicating with the memory and configured to access the memory and execute the computer-executable instructions to: The first user device receives a health database from a service provider, the health database being associated with a user profile, the service provider being configured to store the health database; Receive first health information associated with the user profile and collected at least in part by the first user device; At the first user equipment, a first health synchronization object is generated based on the first health information. The first health synchronization object includes a first synchronization identity, which includes a first hardware identifier that indicates the first user equipment to generate the first health synchronization object and a first database identifier that indicates the health database. The first health synchronization object is determined to be sent to the service provider based on the first user equipment being configured to send a health synchronization object with the first synchronization identity to the service provider and based on the first user equipment being configured to avoid sending a health synchronization object with a synchronization identity different from the first synchronization identity to the service provider. Send the first health synchronization object; Receive a second health synchronization object, the second health synchronization object including a second synchronization identity, the second synchronization identity including a second hardware identifier indicating a second user equipment and a first database identifier indicating the health database; as well as The decision not to send the second health synchronization object to the service provider is based on the fact that the first user equipment does not send a health synchronization object with the second synchronization identity to the service provider.

7. The first user equipment of claim 6, wherein the one or more processors are further configured to access the memory and execute the computer-executable instructions to: The first user equipment receives a third health synchronization object, which includes a third synchronization identity. The third synchronization identity includes a third hardware identifier indicating a third user equipment and a first database identifier indicating the health database. The first user equipment is also configured to send a health synchronization object with the third synchronization identity to the service provider. Based on the first user equipment sending a health synchronization object with the third synchronization identity to the service provider, the third health synchronization object is determined to be sent to the service provider; and Send the third health synchronization object.

8. The first user equipment of claim 7, wherein the third synchronization identity is associated with a secondary device, and wherein the one or more processors are further configured to access the memory and execute the computer-executable instructions to: The auxiliary device has not yet sent the third health synchronization object to the health database according to the timing standard.

9. The first user equipment according to claim 7, wherein the third synchronization identity is associated with the third user equipment, wherein the third user equipment is no longer active.

10. One or more non-transitory computer-readable media, the one or more non-transitory computer-readable media comprising computer-executable instructions, which, when executed by one or more processors on a first user device, cause the one or more processors to perform operations, the operations including: A health database is received from a service provider at the first user device associated with a user profile, the health database being associated with the user profile, and the service provider being configured to store the health database; Receive first health information associated with the user profile and collected at least in part by the first user equipment at the first user equipment; At the first user equipment, a first health synchronization object is generated based on the first health information. The first health synchronization object includes a first synchronization identity, which includes a first hardware identifier that indicates the first user equipment to generate the first health synchronization object and a first database identifier that indicates the health database. At the first user equipment, the first health synchronization object is determined to be sent to the service provider based on the first user equipment being configured to send a health synchronization object with the first synchronization identity to the service provider and based on the first user equipment being configured to avoid sending a health synchronization object with a synchronization identity different from the first synchronization identity to the service provider. Send the first health synchronization object to the service provider; A second health synchronization object is received at the first user equipment. The second health synchronization object includes a second synchronization identity, which includes a second hardware identifier indicating the second user equipment and a first database identifier indicating the health database. as well as At the first user equipment, it is determined not to send the second health synchronization object to the service provider based on the fact that the first user equipment does not send a health synchronization object with the second synchronization identity to the service provider.

11. The one or more non-transitory computer-readable media of claim 10, wherein the operation further comprises: The first user equipment receives a third health synchronization object, the third health synchronization object including a third synchronization identity, the third synchronization identity including a third hardware identifier indicating the third user equipment and a first database identifier indicating the health database, and the first user equipment is also configured to send a health synchronization object with the third synchronization identity to the service provider. At the first user equipment, the third health synchronization object is sent to the service provider based on the first user equipment sending a health synchronization object with the third synchronization identity to the service provider; as well as Send the third health synchronization object to the service provider.

12. The one or more non-transitory computer-readable media of claim 11, wherein the third synchronization identity is associated with a secondary device, wherein the operation further comprises: The first user equipment receives an indication that the auxiliary device has not yet sent the third health synchronization object to the health database according to the timing standard.

13. One or more non-transitory computer-readable media according to claim 11, wherein the third synchronization identity is associated with the third user equipment, wherein the third user equipment is no longer active.

14. The one or more non-transitory computer-readable media of claim 10, wherein the operation further comprises receiving a third health synchronization object from the service provider at the first device, the third health synchronization object including a third synchronization identity, the third synchronization identity including a third hardware identifier indicating a third user device and a first database identifier indicating the health database, wherein the service provider is configured to send the third health synchronization object to the first user device based on determining that the third synchronization identity associated with the third health synchronization object is different from the first synchronization identity associated with the first user device.

15. The computer-implemented method according to claim 1, wherein, The first health synchronization object includes discrete and basic units that can synchronize the first health information between the first user equipment and the second user equipment or the service provider.

16. The computer-implemented method according to claim 3, wherein, The determination to send the third health synchronization object to the service provider is based at least in part on the instruction that the auxiliary device has not yet sent the third health synchronization object to the health database according to the timing standard.

17. The first user equipment according to claim 6, wherein, The first health synchronization object includes discrete and basic units that can synchronize the first health information between the first user equipment and the second user equipment or the service provider.

18. The first user equipment according to claim 8, wherein, The determination to send the third health synchronization object to the service provider is based at least in part on the instruction that the auxiliary device has not yet sent the third health synchronization object to the health database according to the timing standard.

19. One or more non-transient computer-readable media according to claim 10, wherein, The first health synchronization object includes discrete and basic units that can synchronize the first health information between the first user equipment and the second user equipment or the service provider.

20. One or more non-transient computer-readable media according to claim 12, wherein, The determination to send the third health synchronization object to the service provider is based at least in part on the instruction that the auxiliary device has not yet sent the third health synchronization object to the health database according to the timing standard.

Images