WO2015183495A1 - Gestion d'informations utilisateur - Google Patents

Gestion d'informations utilisateur Download PDF

Info

Publication number
WO2015183495A1
WO2015183495A1 PCT/US2015/029494 US2015029494W WO2015183495A1 WO 2015183495 A1 WO2015183495 A1 WO 2015183495A1 US 2015029494 W US2015029494 W US 2015029494W WO 2015183495 A1 WO2015183495 A1 WO 2015183495A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
user
application
request
party
Prior art date
Application number
PCT/US2015/029494
Other languages
English (en)
Inventor
Daniel Keen
Justin S. RUSHING
Todd Allan SHORTLIDGE
Eliza C. Block
Guy L. Tribble
Jay C. Blahnik
Original Assignee
Apple Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US14/499,449 external-priority patent/US10236079B2/en
Application filed by Apple Inc. filed Critical Apple Inc.
Priority to EP19205864.2A priority Critical patent/EP3675135A1/fr
Priority to EP15724859.2A priority patent/EP3149634B1/fr
Priority to EP23181820.4A priority patent/EP4235682A1/fr
Priority to CN201580028726.9A priority patent/CN106462616B/zh
Publication of WO2015183495A1 publication Critical patent/WO2015183495A1/fr

Links

Classifications

    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
    • G16H10/60—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6245—Protecting personal data, e.g. for financial or medical purposes

Definitions

  • P23418USP1 P23418USP1
  • the present application is also related to Provisional Application Serial No. 62/006,032, filed May 30, 2014, entitled “ Wellness Aggregator,” by Kennedy, et al., the entire contents of which is hereby incorporated by reference as if fully set forth herein, under 35 U.S.C. ⁇ 120.
  • the present application is also related to Non-Provisional Application Serial No.
  • Embodiments of the present disclosure can provide systems, methods, and computer- readable medium for managing user information (e.g., personal information collected by one or more external devices).
  • a data interchange may he managed that enables and/or allows third-party applications to provide user information to the data interchange and potentially retrieve user information provided by other third-party applications. While managed, the data interchange may be configured to provide access to particular data types of the user data based at least in part on authorization from the user associated with the data,
  • a method may be executed by a computer system to at least receive health information of a user associated with at least a subset of a plurality of different data types.
  • the method may also cause the computer system to store the health information of the user in a secure storage device of the computing device.
  • the computer system may receive, from a third-party application, an authorization request for accessing at least one data type of the plurality of different data types for the user.
  • the method may also cause the computer system to provide, to the third-party application, an indication that the authorization request was provided to the user.
  • the computer system may receive, from the third-party application, a request for the health information corresponding to the at least one data type and provide an empty result to the third-party application when the user has not authorized access to the at least one data type.
  • the indication that the authorization request may have been provided to the user is provided to the third-party application without indicating whether the user denied access to the at least one data type.
  • the user may have provided the health information corresponding to the at least one data type, and the empty result may be provided to the third- party application without indicating that the user has provided the health information corresponding to the at least one data type.
  • data of the secure storage device may be accessible to the third-party application when the user is authe ticated with the computing device.
  • the method may cause computer system to receive, from a second third-party application, a second authorization request for accessing the at, least one data type of the plurality of different data types of the user, receive an authorization grant from the user for the second third-party application to access the at least one data type, and provide, to the second third-party application, a same as the indication to the second third-party application as was provided to the third-party application.
  • the same indication may be provided to the second third-party when the user has not provided the health information corresponding to the at least one data type.
  • a system may be implemented as a computing device configured with a memory and a processor.
  • the processor may be configured to execute instructions stored on the memory to configure the memory to store data of a user and provide a request, to a user interface of the user, for the user to authorize access of at least a portion of the data to an application of the device.
  • the processor may also be configured to execute the instructions to recei ve, from the user interface of the user, a response to the request and pro vide, to the application of the device, an indication that the request was provided to the user without indicating whether the user denied the request.
  • the application of the device may comprise a third-party application executed by the processor.
  • the user may be enabled to authorize access to first health data of a first data type and deny access to second health data of a second data type.
  • the memory may be configured to store the second health data and not store the first health data, in some cases, the processor may be further configured to execute the computer-executable instructions to at least receive, from the application, a first data request for the first health data and a second data request for the second health data, and provide an empty result to the application in response to both the first data request and the second data request.
  • the processor may be further configured to execute the computer-executable instructions to at least provide a read request, to the user, for the user to authorize the application to read the data stored in the memory, and provide, to the application, only information provided by the application to the memory when the user denies the read request.
  • a computer-readable medium may include instructions that, when executed, configure a computer processor to store information associated with a user in a. data store.
  • the instructions may further configure the processor to receive a first request, from an application, for authorization to access the information and/or a. second request, from the application, for the information.
  • the instructions may also configure the processor to provide the information to the application when the user associated with the information approves the first request for authorization and mask a denial of the first request for authorization in response to the second request when the user associated with the information denies the first request for authorization.
  • the application may be a third-party application configured to be capable of at least one of reading or writing at least a portion of the information to the data store, and at least one first party application may be configured to be capable of at least one of reading or writing at l east the portion of the information to the data store.
  • the user may be enabled to respond to the first request for authorization for each of a plurality of data types.
  • the denial of the first request for authorization may be masked by providing a response to the application that does not indicate that the user denied the first request for authorization, and the response to the application may not indicate that the user denied the first request for authorization by (a) providing an empty result, to the application, in response to the second request when requested data is not stored in the data store and (b) providing the empty result, to the application, in response to the second request when the user denied the first request for authorization.
  • FIG. 1 is a simplified block diagram illustrating an example architecture for managing user information as described herein, according to at least one example.
  • FIG. 2 is another simplified block diagram with connection flows illustrating at least some features of managing user information as described herein, according to at least one example.
  • FIG. 3 is another simplified block diagram illustrating another example architecture for managing user information as described herein, according to at least one example.
  • FIG. 4 is a sequence diagram illustrating additional features of managing user information as described herein, according to at least one example.
  • FIG. 5 is simplified data structure diagram illustrating at least some information associated with managing user information as described herein, according to at least one example.
  • FIG. 6 is a flowchart of a method for managing user information as described herein, according to at least one example.
  • FIG. 7 is another flowchart of a method for managing user information as described herein, according to at least one example.
  • FIG. 8 is another simplified block diagram illustrating another example architecture for managing user information as described herein, according to at least one example,
  • FIG. 9 is another flo wchart of a method for managing user information as described herein, according to at, least one example.
  • FIG. 10 is another flowchart of a method for managing user information as described herein, according to at, least one example.
  • FIG. 1 1 is another simplified block diagram illustrating another example architecture for managing user information as described herein, according to at least, one example.
  • FIG. 12 is another flowchart of a method for managing user information as described herein, according to at, least one example.
  • FIG. 13 is another flowchart of a method for managing user information as described herein, according to at, least one example.
  • FIG. 14 is another simplified block diagram illustrating another example architecture for managing user information as described herein, according to at least one example.
  • FIG . 15 is a simplified block diagram illustrating an example user interface for presenting user information as described herein, according to at least one example.
  • FIG. 16 is another flowchart of a method for managing user information as described herein, according to at, least one example.
  • FIG. 17 is another flowchart of a method for managing user information as described herein, according to at, least one example.
  • Examples of the present disclosure are directed to, among other things, managing personal information from external sources, or other remote peripheral device of a user.
  • the information collected by the data collection devices may be provided to a user device (e.g., a mobile phone, a tablet computer, a laptop computer, a wearable computing device, etc.) and/or one or more first-party or third-party applications of the user device.
  • a first-party application may be one that is provided with the operating system (O/S) of the user device, is configured to operate natively with the user device, provided by the de velopers of the O/S for use with the user device, and/or trusted by the O/S and/or de vice.
  • O/S operating system
  • a third-party application may be one that is provided by a third-party or entity other than the developer/manufacturer of the user device and/or it's O/S.
  • the information being collected and/or managed may be health, fitness, and/or activity information of the user (e.g., blood glucose levels, weight, height, calories burned, heart rate, etc.).
  • the user information may be categorized or otherwise identified by one or more data types (or categories). Weight, number of steps walked, number of calories burned, heart rate, etc., are each an example of a data type. Other data types (e.g., outside of health information) are also envisioned including, but not limited to, hours worked, hourly rate, miles per hour, pages read per minute, etc.
  • a first-party application framework may be executed on a user device that is configured to receive, store, manage, and/or provide such user information to a service provider, to third-party applications, to other first-party applications, and/or to local storage of the user device.
  • a first-party process may be executed by processors of the user device.
  • the first-party process may include, but is not limited to, a daemon or other background process configured to communicate with the third-party applications, the O/S of the user device, and/or electronic storage of the user device.
  • first-party process may be configured to manage a data interchange for sharing some user data with third- party applications.
  • the first-party process may enable third-party applications to access user information that was initially provided by the third-party application, a first-party application, or other third-party applications.
  • health information of a user may be considered extremely personal and/or confidential; thus, the user may be given the ability to protect or otherwise not share some of the heath information with some, any, or all of the third-party applications (even the ones that provided the health information to the first-party process initially).
  • each third-party application may be instructed to request authorization for accessing particular (or all) data types from the data interchange.
  • the first-party process when a third-party application requests authorization to access one or more data types of a user ' s information, the first-party process may be configured to mask whether the user has granted the authorization request. In other words, the third-party application may not be able to identify whether the user has granted authorization or whether the user has not entered data for that data type. In some examples, this masking may be implemented by providing the same response (e.g., an empty or null result) in either case. That is, the first-party process may instead indicate to the third-party application that the authorization request was provided to the user, and not indicate the user's response.
  • the third-party application may receive a null result when attempting to retrieve that data type.
  • the first- party process may also provide a null or empty result (even though a data entry for that data type exists).
  • third-party applications may be able to subscribe to certain data types, and the first-party process may be configured to automatically wake up the third-party application (e.g., in the background) and ensure that the third-party application is able to process the data.
  • a third-party application of the user may subscribe to a blood pressure data type and indicate an associated subscription frequency. Based at least in part on that frequency, when a new blood pressure reading is received by the first-party process, the process may wake up the appropriate third-party application background, provided with the new data and provide it with the updated data. The process may then wait for confirmation that the third-party application has processed the data. If the process does not receive the confirmation within a specified time, the process may again launch the third-party application, provide the data, and wait for confirmation. In this way, the process can ensure that the third-party application receives the data even if the user has not explicitly requested it.
  • a plug-in framework may be utilized to implement data types that are initially available for use by the first-party process and/or registered third-party applications.
  • Plug-ins of the plug-in framework may register new data types that adhere to different identifiers so they can store their own data in the database automatically.
  • the plug-ins may be implemented as code that can read application programming interface (API) method calls with identifiers and/or strings associated with the data types.
  • API application programming interface
  • a service provider may enable the addition of new data types not initially provided with the first-party process (e.g., on demand).
  • the sen Ice provider may identify one or more data types not initially implemented within the first-party framework that are being requested by users/developers.
  • the service provider may publish information about the new data type and'Or how to utilize it. Additionally, the service provider may provide data to the user device for the first-party process to interpret. Once interpreted, and registered with the process, the plug-ins may be utilized to implement these new data types.
  • a step counter may provide data to an associated third-party application.
  • This third- party application may provide step information to the first-party process.
  • the user may utilize a second type of data collection device that also provides step information about the user to a different third-party application.
  • the user may be enabled to provide priority information to the process such that the process is able to aggregate the step information from the two sources in a meaningful way.
  • the data may be aggregated from a statistical perspective (e.g., to determine the actual number of steps walked by the user) and/or the data may be aggregated to provide a user interface (IJI) that helps the user visualize the number of steps they walked.
  • IJI user interface
  • the priority information may identify which data (e.g., from which source) to use when there are multiple data entries for the same point in time.
  • the source with the highest priority may be rendered when there is overlap in cumulative data, (e.g., steps walked are cumulative because they can be summed to a total).
  • discrete data may be collected and presented in a way that shows the multiple different data entries for each point in time. For example, weight is an example of a discrete data type because one's weight would not be summed over the day to determine a. total weight.
  • FIG. 1 illustrates a simplified architecture diagram 100 depicting a user device 102 configured to implement a first-party application framework 104.
  • the first-party application framework 104 may be configured as an application framework for managing user data of a plurality of data collection devices. While health data is used as an example throughout much of this disclosure, any type of data that may be collected or otherwise provided about a user may be managed by the first-party application framework 104. In some examples, because the first-party application framework 104 is provided or otherwise controlled by developers of the user device 102 and'Or its associated O/S, the first-party application framework 104 may be considered a trusted framework with full access to all user data.
  • the first-party application framework 104 may be configured with one or more processes executed by the user de vice 502. For example, a first-party process 106 may be executed in the background such that the user is not aware that it is running. In this way, the first-party application framework 104 may be able to manage the user data whenever desired without interfering with the everyday use of the user device 102. Additionally, in this way, the first-party application framework 104 may be able to communicate with one or more third-party applications 108, also without interruption of the user's use of the user device 102.
  • the first-party process 506 may be configured to manage (e.g., store, retrieve, encrypt, etc.) user data via a database 509 of the user device 102.
  • the database 109 may be divided or otherwise logically separated into a plurality of classes of data stores.
  • the user data may be stored in at least one of a class A data store 1 10, a class B data store 1 12, a class C data store 1 14, and/or a class D data store.
  • the class A data store 1 10 may be configured to store personally identifiable user information (e.g., personal health, fitness, or activity data).
  • this data is only available to the third-party application 108 when the user device 102 is unlocked.
  • the user device 102 may be unlocked when the user associated with the user device 102 has correctly entered his or her user identifier (ID) and password (e.g., when logging in and/or unlocking the lock screen).
  • the class B data, store 1 12 may be configured to store "journal" type data. Journal data, may include, but is not limited to, personally identifiable user information and/or other metrics associated with use of one or more data collection devices and/or the third-party application 108. When the user device 102 is locked, the journal data of the class B data store 1 12 may be inaccessible to the third-party application 108.
  • data from a data collection device or an application may be read from or written to the class B data store 112 by the first-party process 106 while the device is locked as long as the first-party process 106 is active. If, however, the first-party process 106 fails or otherwise becomes inactive in the process of reading or writing data to the class B data store 1 12, the data may become permanently inaccessible, and new data may not be written to the class B data store 1 12 until the first-party process 106 and/or a new session of the third-party application 108 have relaunched.
  • the first-party process 106 fails or otherwise becomes inactive in the process of reading or writing data to the class B data store 1 12
  • the data may become permanently inaccessible, and new data may not be written to the class B data store 1 12 until the first-party process 106 and/or a new session of the third-party application 108 have relaunched.
  • the class C data store 1 14 may be configured to store metadata associated with the management of the user health, fitness, and/or activity data. This metadata, in some cases, may only be accessible after the first unlock of the user device 102, As such, if the user device 102 reboots (based at least in part on a software issue or a loss of battery power), this data may not be available until the user unlocks at least once. In some aspects, this may prevent jailbreaking or other hacking techniques from accessing this data.
  • the metadata stored in the class C data store 5 54 may include subscription information, access permission information, and/'or safe metadata, but may not, in some examples, identify or be directly associated with any health information (e.g., the data stored in the class A data store 1 10).
  • the class D data store 1 16 may be configured to store free-form (e.g., unstructured) information provided by the user. In some examples, this may be health data; however, it may not be updatable and/or linked to any third-party applications (e.g., the third-party application 108) or data collection devices.
  • the class D data may always be available to the first-party process 106 and/or the third-party application 108.
  • the class D data may be pre-filled using information from the third-party application 108 and/or one or more other applications or processes. However, the user may be able to enter additional data, update the data, include incorrect data, or otherwise configure the information in the class D data store 1 16 as they see fit.
  • the class D data may be available on the lock screen of the user device 102 without anyone (e.g., the user) logging in or otherwise unlocking the user device 102, In this way, the lock screen or another accessible screen of the user device 102 may be analogous to a medical ID bracelet.
  • an emergency icon or other function on the lock screen may enable the presentation or rendering of the class D data upon request for anyone (e.g., an emergency medical technician or the like) to see.
  • the third-party application 108 may not have access to the class D data, in part, because it may be unstructured data that would be difficult for the third-party application 108 to process.
  • FIG. 2 illustrates a simplified architecture diagram 200 depicting additional implementation details associated with the first-party application framework 104 and how user data stored in the database 109 can be accessed by the first-party process 106 and/or one or more different third-party applications 202, 204, 206 (e.g., the third-party application 108).
  • the database 109 may allow the first-party process 106 and/or the third-party applications 202, 204, 206 to write health and medical data into the database 109 and read it back out.
  • the third-party applications 202, 204, 206 may actually populate the database 509 with data more than the first-party process 506.
  • the first-party application framework 104 may be configured to act as a data interchange between the applications.
  • the database 509 may be configured to store data of various different data types.
  • the database 109 may store data corresponding to data type A 208 and/or data type B 210.
  • only certain data types may be accessed by certain applications.
  • some data types may be read only for certain applications, inaccessible to other applications, yet fully accessible to yet other applications.
  • the database 109 may be configured to store at least the following data types: weight, steps, blood pressure, heart rate, tobacco, glucose levels, others described herein, or the like.
  • the first-party process 106 may have read and write access to both data type A 208 and data type B 210.
  • the third-party application 204 may only have write access to data type B 210.
  • the third- party application 202 may only be able to read data type A 208, it may have both read and write access to data type B 210. Further, in some examples, the third-party application 206 may only be able to read data type B 210. However, any of these examples may be updated, changed, or otherwise configured by the user and/or by the first-party process 106. As noted, the metadata that identifies which application has which type of access to which data type may be stored in the class C data store 114 of FIG. 1.
  • FIG. 3 illustrates an example architecture 300 for implementing the management of personal information from external sources that includes the user device 102 of FIG. 1 as well as a data collection device 302 and one or more service provider computers 304.
  • the devices may be connected via one or more networks 308 and/or 312 (e.g., via Bluetooth, WiFi, or the like).
  • one or more users may utilize the user device 102 to manage, control, or otherwise utilize one or more data collection devices 302, via one or more networks 312.
  • the networks 308, 312 may include any one or a combination of many different types of networks, such as cable networks, the Internet, wireless networks, cellular networks, satellite networks, other private and/or public networks, or any combination thereof. While the illustrated example represents the user 102 accessing the service provider computers 304 via the networks 308, the described techniques may equally apply in instances where the user device 02 interacts with the service provider computers 304 over a landline phone, via a kiosk, or in any other manner. It is also noted that the described techniques may apply in other client/server arrangements, as well as in non-client/server arrangements (e.g., locally stored applications, peer to peer configurations, etc.).
  • the user device 102 may be configured to manage a data interchange for reading and/or writing user data to the database 109, and for sharing that user data among one or more authorized third-party applications.
  • the data collection device 302 may be configured to provide health, fitness, activity, and/or medical data of the user to a third- or first-party application (or process). In turn, this data may be shared, aggregated, and/or accessed via the first-party framework module 313 that may be configured to implement the first-party application framework 104 of FIG. 1.
  • the user device 102 may be any type of computing device such as, but not limited to, a mobile phone, a smartphone, a personal digital assistant (PDA), a personal computer (e.g., laptop or desktop), a thin-client device, a tablet computer, an electronic book (e-book) reader, a wearable device, etc.
  • the user device 102 may be in communication with the service provider computers 304 and/or the data collection device 302 via the networks 308, 312, or via other network connections.
  • the user device 102 may include at least one memory 314 and one or more processing units (or processor(s)) 316.
  • the processor(s) 316 may be implemented as appropriate in hardware, software (e.g., computer-executable instructions, firmware, etc.), or combinations thereof.
  • Computer-executable instruction or firmware implementations of the processor(s) 316 may include machine-executable instructions written in any suitable programming language to perform the various functions described.
  • the user device 102 may also include geo-location devices (e.g., a global positioning system (GPS) device or the like) for providing and/or recording geographic location information associated with the user device 102,
  • GPS global positioning system
  • the memory 314 may store program instructions that are loadable and executable on the processor(s) 316, as well as data generated during the execution of these programs.
  • the memory 314 may be volatile (e.g., random access memory (RAM)) and/or non-volatile (e.g., read-only memory (ROM), flash memory, etc.).
  • RAM random access memory
  • ROM read-only memory
  • the user device 102 may also include additional removable storage and/or nonremovable storage including, but not limited to, magnetic storage, optical disks, etc.
  • the disk drives and their associated non-transitory computer-readable media may provide non-volatile storage of computer-readable instructions, program modules, data structures, and other data for the computing devices, in some implementations, the memory 314 may include multiple different types of memory, such as RAM, static random access memory (SRAM), dynamic random access memory (DRAM), or ROM. While the volatile memory described herein may be referred to as RAM, any volatile memory (e.g., that does not maintain data stored therein once unplugged from a host and/or power) would be appropriate.
  • non-transitory computer-readable storage media may include volatile or non-volatile, removable or nonremovable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules, or other data.
  • the memory 314 and the additional storage 326 are all examples of non-transitory computer storage media.
  • Additional types of computer storage media may include, but are not limited to, phase-change RAM (PRAM), SRAM, electrically erasable programmable read-only memory (EEPROM), flash memory, compact disc read-only memory (CD-ROM), digital video disc (D VD), magnetic cassettes or tape, magnetic disk storage, or any other medium that can be used to store the desired information and that can be accessed by the user device 102. Combinations of any of the above should also be included within the scope of non-transitory computer-readable media.
  • computer-readable communication media may include computer-readable instructions, program modules, or other data, transmitted within a data signal, such as a carrier wave, or other transmission.
  • computer-readable storage media does not include computer-readable communication media.
  • the user device 102 may also contain communications connection(s) 328 that allow the user device 102 to communicate with a data store (e.g., the database 109), or another computing device via the networks 308, 312.
  • the user device 102 may also include I/O device(s) 330, such as a keyboard, a mouse, a pen, a voice input device, a touch input device, a display, speakers, etc.
  • the memory 314 may include an operating system 332 and/or one or more application programs or services for implementing the features disclosed herein including an authorization module 334, a background module 336, an extension module 338, and/or an aggregation module 340.
  • an authorization module 334 a background module 336
  • an extension module 338 a module that provides a service to the memory 314 to the memory 314 to the memory 314 to the memory 314.
  • authorization module 334 may be configured to manage authorization requests from third-party applications for access of user data stored in the database 1 09 (e.g., class A data of F IG. 1 ).
  • the authorization module 334 may also be configured to mask when a user denies authorization to a third-party application for a particular data type. In this way, the third-party application may not be able to infer anything about the user based at least in part on the denial.
  • the background module 336 may be configured to launch and/or relaunch third-party applications in as background process. In some examples, the background module 336 may also be configured to verify that the third-party application has finished processing the data it requested, by continuing to relaunch the third-party application in the background until notification is received that the third-party application has completed processing.
  • the extension module 338 may be configured to handle registering new data types with the first-party framework module in order to extend the functionality of the first-party application framework 104 of FIG. 1. Further, the aggregation module 340 may be configured to aggregate or otherwise combine (and, in some examples, provide presentation for) user data received from multiple different data sources.
  • the service provider computers 304 may also be any type of computing device such as, but not limited to, a mobile phone, a smartphone, a FDA, a personal computer, a thin-client device, a tablet computer, an e-book reader, a wearable device, etc.
  • the service provider computers 304 may be in communication with the user device 102 and/or the data collection device 302 via the networks 308, 312, or via other network connections.
  • the service provider computers 304 may also include at least one memory 342 and one or more processing units (or processor(s)) 344.
  • the processing units (or processor(s)) 344 may also include at least one memory 342 and one or more processing units (or processor(s)) 344.
  • processor(s) 344 may be implemented as appropriate in hardware, computer-executable instructions, firmware, or combinations thereof.
  • Computer-executable instruction or firmware implementations of the processor(s) 344 may include computer-executable or machine- executable instructions written in any suitable programming language to perform the various functions described.
  • the memory 342 may store program instructions that are loadable and executable on the processors) 344, as well as data generated during the execution of these programs.
  • the memory 342 may be volatile (such as RAM) and/or non-volatile (such as ROM, flash memory, etc.).
  • the service provider computer 304 may also include additional removable storage and/or nonremovable storage 346 including, but not limited to, magnetic storage, optical disks, and/or tape storage.
  • the disk drives and their associated non-transitory computer-readable media may provide non-volatile storage of computer-readable instructions, data structures, program modules, and other data for the computing devices.
  • the memory 342 may include multiple different types of memory, such as SRAM, DRAM, or ROM, While the volatile memory described herein may be referred to as RAM, any volatile memory that would not maintain data stored therein once unplugged from a host and/or power would be appropriate.
  • the memory 342 and the additional storage 346, both removable and non-removable, are all examples of non- transitory computer-readable storage media,
  • the service provider computer 304 may also contain communications connection(s) 348 that allow the service provider computer 304 to communicate with a data store (e.g., the database 109 of the user device 102 or another database), or another computing device via the networks 308, 312.
  • the service provider computer 304 may also include I/O device(s) 350.
  • the memory 342 may include an operating system 352 and/or one or more application programs or services for implementing the features disclosed herein including an asset upload module 354.
  • the asset upload module 354 may be configured to manage mobile assets and/or prepare or otherwise generate information for enabling the user device 102 and/or the first-party framework module 313 to extend the data types originally configured within the first-party application framework 104 of FIG, 1.
  • the asset upload module 354 may be configured to identify one or more new data types and generate data to be provided to the user device 102 for registering or otherwise effectuating the new data types.
  • FIG. 4 illustrates an example flow diagram 400 for describing additional features of the management of user data from a data collection device as described herein.
  • the flow 400 may be implemented, at least in part, by the authorization module 334 described above with reference to FIG, 3, As such, the flow r 400 may be from the perspective of the first-party process 106 residing on the user device 102 of FIG. 1 , Communication may be between the first-party process 106 and the third-party application 108 of FIG. 1 or between the first-party process 106 and any of the third-party applications 202, 204, 206 of FIG. 2, or any other applications.
  • the first-party process 106 may receive a request, 402 from, the third-party application 108.
  • the request may be an attempt, to identify whether the third-party application has requested authorization for a particular data type.
  • the third-party application may want to know whether it had already requested authorization for blood glucose levels, or weight, from the first-party process 106.
  • the first-party process 106 may respond with a "yes" or a "no.”
  • the third-party application 108 may end here, if they have already requested authorization for the particular data type. Additionally, in some examples, the request at 402 may be for all data types, as opposed to a particular data type. In other examples, if the third-party application 108 has not yet requested authorization for one, some, or all of the data types, the first-party process 506 may receive an authorization request 406, As noted above, the authorization request may be a set of data types, all the data types available (e.g., to limit the number of these requests 406), or a particular data type.
  • the first-party process 106 may forward this request to the user of the user device 102 (e.g., via a UI provided to the user).
  • the first-party process 106 may receive a response from the user indicating whether the user has authorized access to that third-party application 108.
  • the answer may be different for each data type and/or for each third-party application. For example, and as noted in FIG. 3, each application may have different access restrictions for different data types.
  • the first-part ⁇ ' process 106 may provide a response 412 to the first-party process 106 that indicates that the first-party process 106 has provided the data authorization request 408 to the user.
  • this response 412 may be a simple "ok, done” response, or any other response that indicates that this step has been completed. However, the response 412 may not indicate whether the user has authorized the access or not. In this way, the authorization grant or denial is masked to the third-party application 108. Future requests 414 for access to this particular data type (e.g., one where access authorization was denied) may receive an empty or null result 416.
  • future requests 414 for this data type may receive an empty or null result at 416 when not data value exists, even if the access authorization was granted.
  • a similar flow for write requests is envisioned as well; however, when write access authorization is not granted, the first-party process 106 may provide the last set of data that the third-party application 108 attempted to write. Thus, the third-party application 108 may not be able to tell when read authorization requests are denied or when write authorization requests are denied.
  • FIG . 5 illustrates an example table 500 of values for demonstrating sample results provided to a third-party application by the first-party process 106 of FIG. 1 , for different scenarios.
  • the first column represents data type 502
  • the second column represents values 504 for that data type received from a third-party application (or entered by a user)
  • the next column represents whether the authorization request was sent 506
  • the fourth column represents whether the authorization was approved 508 by the user
  • the final column represents an example result that would be provided to the requesting third-party application 510 based at least in part on the values of the other columns, per row.
  • row 552 may represent a scenario for the "heart rate” data type.
  • the user s heart rate may have been recorded as 78 beats per minute and the requesting application may have already provided an authorization request.
  • the user has approved the authorization request; as such, the result provided to the requesting application will match the value 78. This will even be the case if the application requesting the data value was not the application that provided to the data value to the first-party process 106.
  • row 514 may represent a scenario for the "glucose" level data type. In this example, the user's glucose levels may not have been recorded.
  • row 520 shows a "tobacco” data type that may indicate whether the user is a smoker and, if so, how many cigarettes (or other quantifiable measure) they smoke per day.
  • a value of "5" may indicate that the user is a smoker and smokes five cigarettes per day, while a value of "0" may indicate that the user is a non-smoker.
  • the data value indicates that the user is a smoker
  • the table 500 indicates that the application has requested access authorization. However, the user has denied the authorization request for this data type (e.g., maybe because this personal health information is not something the user wishes to share with third-party applications).
  • FIGS. 6 and 7 illustrate example flow diagrams showing processes 500 and 600 for managing persona! information from external sources, according to at least a few embodiments. These processes, and any other processes described herein, are illustrated as logical flow diagrams, each operation of which represents a sequence of operations that can be implemented in hardware, computer instructions, or a combination thereof.
  • the operations may represent computer-executable instructions stored on one or more non-transitory computer-readable storage media that, when executed by one or more processors, perform the recited operations.
  • computer-executable instructions include routines, programs, objects, components, data structures and the lilve that perform particular functions or implement particular data types.
  • the order in which the operations are described is not intended to be construed as a limitation, and any number of the described operations can be combined in any order and/or in parallel to implement the processes.
  • any, or all of the processes described herein may be performed under the control of one or more computer systems configured with specific executable instructions and may be implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications) executing collectively on one or more processors, by hardware, or combinations thereof.
  • code e.g., executable instructions, one or more computer programs, or one or more applications
  • the code may be stored on a non-transitory computer-readable storage medium, for example, in the form of a computer program including a plurality of instructions executable by one or more processors.
  • the user device 102 may perform the process 600 of FIG. 6.
  • the process 600 may begin at 602 by including receipt of health information of a user associated with a subset of a plurality of different data types. In some examples, this may include receiving a single data, entry of health data corresponding to a single data, type or a set of data entries of health data corresponding to a single data, type each. Additionally, in some cases, the health information may be received from one or more applications (e.g., a third-party application or a first-party application) of the user device 102, and may have initially been collected by a data collection device.
  • applications e.g., a third-party application or a first-party application
  • the process 600 may include storing the health information of the user in a secure storage device.
  • the health information may be stored in a database configured to restrict access of the data to particular applications based at least in part on configurable settings, the requesting application, and/or the data type being requested.
  • the process 600 may include receiving an authorization request for accessing a data type from a first application at 606.
  • the process 600 may also include providing an indication to the first application that the
  • authorization request was provided to the user at 608.
  • the process 600 may include receiving a request for health information corresponding to the data type. This request may he received from the first application.
  • the process 600 may also include providing an empty result to the first application when the user has not authorized access. In this way, the fact that the user denied the authorization request, the first application is not made of aware of this. In other words, the first application will not know whether the authorization request was denied or whether no data value existed in the data store for that data type.
  • the process 600 may include receiving another authorization request for accessing the data type at 614. This request may come from a second application.
  • the process 600 may include receiving an authorization grant for the second application to access the same data type.
  • the process 600 may end at 618, where the same indication given to the first application may be provided to the second application. That is, the same result (e.g., an empty result) may be provided to the first application when the data type info (e.g., a value) was not provided as is provided to the second application when the data value was provided but authorization was not granted.
  • the same result e.g., an empty result
  • the data type info e.g., a value
  • FIG. 7 illustrates another process 700 for managing personal information from external sources, according to at least a few embodiments.
  • the user device 102 e.g., utilizing at least the authorization module 334 shown in FIG. 3
  • the process 700 may begin at 702 by including storing informatio associated with a user in a data store.
  • the information may be health, fitness, activity, and/or medical information collected from a data collection device (e.g., a WiFi thermometer, scale, heart rate monitor, etc.).
  • the process 700 may include receiving a first request to access the information.
  • the first request may be received from an application being executed by the user device 102.
  • the first request may also be an access authorization request (e.g., to request access to the information).
  • the process 700 may also include receiving a second request from the application for the information at, 706.
  • the second request may be an access request, the response to which may depend on whether the user has granted or denied the first request.
  • the process 700 may include providing the information to the application when the user approves the first, request, at, 708. That is, if the user has approved the access authorization request, when the application requests the information, the process 700 may provide it.
  • the process 700 may end at 710, where denial of the first request (e.g., the authorization request) may be masked at least in response to the second request (e.g., the access request).
  • FIG. 8 illustrates another example architecture 800 for implementing additional features of the management of persona! information from external sources, depicting the user device 102, the first-party application framework 504, and the first-party process 506 of FIG . 5.
  • one or more third party applications e.g., third-party source application 802 and/or third-party application 804 may be in communication with the first-party application framework 104 and/or the first-party process 106 for providing user information collected by a data collection device 806.
  • the data collection device 806 may he any wearable or mobile device configured to collect activity, health, medical, and/or fitness information about a user.
  • This information may then be provided to one of the third-party applications (e.g., the third-party source application 802 in this example) via one or more networks 808. Once received by the third-party source application 802, the information can be provided to the first-party process 106 for storage in the database 109.
  • the third-party applications e.g., the third-party source application 802 in this example
  • the third-party application 804 may be configured to subscribe to one or more data types of the user information stored within the database 109.
  • the third-patty application 804 may also include a frequency corresponding to each subscription.
  • each subscription may be associated with a different data type and have its own associated frequency.
  • the third-party application 804 may subscribe to the "weight” data type with a frequency of "daily,” and also subscribe to the "blood glucose level” data, type with a frequency of "immediate,” As such, in some examples, the first-party process 106 may launch the third-part ⁇ ' application 804 in the background when certain actions occur based at least in part on the subscription, and provide the data to the third-party application 804 while it is launched.
  • the first-party process 106 may automatically launch the third-party application 804, enable it to request the new reading, and then provide the data to the third-party application 804 based at least in part on the reqeust.
  • the third-party application 804 was launched nearly immediately (e.g., within a second or so) after the new blood glucose reading was received because the subscription frequency was set to "immediate," thus, providing the data (e.g., the new blood glucose reading) nearly immediately .
  • the third-party application 804 may not have been launched (and the data provided) until the end of the day based at least in part on that subscription being set to "daily.”
  • the third-party application 804 may receive the new reading (e.g., the blood glucose reading noted above) and begin to process the data 810. While the processing 810 may be agnostic to the first-party process 106 (e.g., the first-party process 106 may not know what processing 810 is being done with the data reading), the first-party process 106 may be configured to look or otherwise poll for a transaction complete confirmation 852. In some examples, if the transaction complete confirmation 812 is not received within a particular time period, the first-party process 106 may relaunch the third-party application 804 until the confirmation 812 is received.
  • the new reading e.g., the blood glucose reading noted above
  • the processing 810 may be agnostic to the first-party process 106 (e.g., the first-party process 106 may not know what processing 810 is being done with the data reading)
  • the first-party process 106 may be configured to look or otherwise poll for a transaction complete confirmation 852. In some examples, if the transaction complete confirmation 8
  • the first-party process 106 may be also be configured to relaunch the third-party application 804 if the third-party application 804 crashes while running in the background.
  • the first-party process 106 may be configured to repeatedly relaunch the third-party application 804 in the background until the confirmation 810 is received, thus ensuring that the third-party application 804 was able to complete its processing 810.
  • a virtual service level agreement SLA may be provided to the third-party applications based at least in part on the subscription.
  • the frequency may be automatically determined based at least in part on the type of data and/or a historical frequency associated with the data. For example, weight data doesn't generally change that much within a day, so the frequency may be automatically set at daily. Alternatively, blood glucose level can change drastically within a few minutes and can be life threatening. As such, the frequency for a subscription to blood glucose level may be automatically set at "immediate" or every "minute.” Additionally, in some examples, the amount of time the first-party process 106 waits before relaunching the third-party application 804 in the background may change between each relaunch.
  • the first-party process 106 may launch the third-party application 804 in the background upon the initial new blood glucose reading (e.g., using the example above) and wait 2 minutes for the third-party application 804 to provide the confirmation 812. If no confirmation 812 is received within the two minute period, the first-party process 106 might relaunch the third-parly application 804 and wait a second period of time. In some cases, the period of time that the first-party process 106 waits may increase for each relaunch. An exponential backoff function may be used to determine the wait period between each relaunch. For example, if the first wait period is two minutes, the second wait period might be four minutes, then eight minutes, and so on.
  • the first-party process 106 may start the cycle over by waiting two minutes each period or it may switch to waiting for a more consistent period of time (e.g., relaunching the third-party application 804 every day). Once confirmation is received, the first-party process 106 may stop rel aunching the third-party application 804. However, if the confirmation is never received, the first-party process 106 may continue to relaunch and wait for confirmation 812 until confirmation 812 is eventually recei ved that the processing 810 of the requested data is complete. For certain third-party applications, this continual relaunch may save a user's life.
  • the first-party process 106 may not be configured to provide the activity and'or health data to the third-party application 804 when the user device 102 is locked (e.g., if that data is stored in the class A data store 1 10).
  • This configuration may be based at least in part on privacy and/or security restrictions.
  • some third-party applications 804 that are subscribed to certain data types may not be able to receive data if the device 102 is locked (typically because most health and/or activity data is stored in the class A data store 1 10). Even if the third-party application 804 is able to be launched, it is possible that the first-party process 106 may not be able to send the data.
  • the corresponding data when a third-party application is subscribed to a data, type, the corresponding data may instead be stored in the class C data store 1 14 so that it can be served even with the user device 102 is locked.
  • the first-party process 106 may remove or otherwise delete the corresponding data from the class C data store 1 14 and/or move the corresponding data, to the class A data store 1 10.
  • a notification or alert may be provided on the lock screen that indicates that data is waiting to be sent to a third-party application 802, but that the data cannot be sent until the device 102 is unlocked. Once unlocked, the device 102 can provide the corresponding data from the class A data store 1 10.
  • FIGS. 9 and 10 illustrate example flow diagrams showing processes 900 and 1 000 for managing personal information from external sources, according to at least, a few embodiments.
  • the user device 102 e.g., utilizing at least the background module 336 shown in FIG. 3 may perform, the process 900 of FIG. 9.
  • the process 900 may begin at 902 by including maintenance of a secure storage device configured to store health data corresponding to a plurality of data types.
  • the secure data store may be configured similar to the database 109 described above with reference to FIG. 1 (e.g. , including class A, B, C, and'or D types of data).
  • the process 900 may include receiving, from a third-party application, a subscription to a data type and a frequency of the subscription.
  • the process 900 may also include receiving a portion of health data corresponding to the data type at 906.
  • the first- party process 106 of FIG. 1 may receive weight data, heart rate information, etc. of a user.
  • the process 900 may include launching the third-party application in the background based at least in part on the frequency associated with the subscription. Additionally, in some examples, the process 900 may include setting a trigger to relaunch the third-party application in the background within a time period at 910.
  • the time period may be configurable (e.g., by the first-party process 106, the third-party application, and/or a user) and/or may be implemented using an exponential backoff algorithm or other method systematically changing the time period between relaunches.
  • the trigger may correspond to the time period and/or an event (e.g., receipt of the confirmation described above). Additionally, setting the trigger may include identifying the triggering event (e.g., receipt of the confirmation or tolling of a time period).
  • the process 900 may include determining whether confirmation of the third-party application processi g is received.
  • the process 900 may end at 914, where the process 900 may cancel the trigger (e.g., close the polling loop that looks for the time period to end or the confirmation to be received). Alternatively, if the confirmation is not received, the process 900 may end at 916, where the process 900 may relaunch the third-party application in the background and continue to wait for the confirmation.
  • the process 900 may cancel the trigger (e.g., close the polling loop that looks for the time period to end or the confirmation to be received).
  • the process 900 may end at 916, where the process 900 may relaunch the third-party application in the background and continue to wait for the confirmation.
  • FIG. 10 illustrates another process 1000 for managing personal information from external sources, according to at least a few embodiments.
  • the user device 102 e.g., utilizing at least the background module 336 shown in FIG. 3
  • the process 1000 may begin at 1002 by including storage of first data of a plurality of data types of a user.
  • the process 1000 may include receiving, from a first application, a subscription to one of the plurality of data types.
  • the process 1000 may also include receiving, from a second application, second data of the plurality of data types at 1006.
  • the process 1000 may include launching a first application in the background after a first time period when the subscription matches the second data.
  • FIG. 1 5 illustrates another example architecture i 100 for implementing additional features of the management of persona! information from external sources, depicting the user device 102, the first-party application framework 504, and the first-party process 506 of FIG . 5 .
  • one or more service pro vider computers 304 may be in communication with the first-party application framework 104 and/or the first-party process 106 for providing one or more asset downloads 1 102 for extending the functionality of the first-party application framework 104.
  • an extension framework has been built into the first- party application framework 104 to extend the list of data types originally included with the first- party application framework 104 to include new data types, when desired. For example, if a new product is released on the market (e.g., a new data collection device), and the first-party application framework 104 does not include a data type for managing the data that is collected by this new device (e.g., brisk minutes), the extension framework will be able to enable the new data type to be added to the first-party application framework 104 in between software releases (e.g., in between software code updates for the user device 102. In this way, new data types can be added, managed, and/or utilized without waiting for the next O/S release for the user device 102,
  • a third-party application may ask for a sample type using an API method that includes an identifier.
  • the identifier may be a string that can be predefined and/or baked into the code for existing data types. How r ever, in some examples, once implemented via the asset download 1 102 and published, a new string may be utilized to read from and/or write to the new data type. Additionally, once implemented, any application (e.g., third-party applicatio s and/or first-paxty applications) may utilize the new data type.
  • the asset download 1 102 may also include additional information about the ew data type i cluding, but not limited to, what type it is (e.g., cumulative or discrete), what string should be used, the identifier, metadata about display, descriptions, etc.
  • the first-party process 106 may have the ability to load plug-ins.
  • the first-party process 106 may look for plug-ins in one or more particular directories, and the plug-ins may be configured to enable changes in behavior of the first-party process 106. For example, based at, least in part on the device that the plug-ins are installed on, they may- enable different behavior changes.
  • plug-ins may be utilized for creating differences in behavior (e.g., to make the first-party process 106 behave differently than initially programmed).
  • a plug-in may be utilized to enable the first-party process 106 to register for notifications and/or harvesting different data.
  • the plug- ins may be utilized for registering the new data types, as described above.
  • a third-party application may ask for a data type by making an API call, and passing in an identifier and/or a "kind.”
  • the "kind” may include particular types of the data type (e.g., cumulative, discrete, or category).
  • the identifier in some cases, may be represented as a string that is passed in via the API, and a data type may be returned to the requesting application.
  • the plug-ins can register new data types that adhere to different identifiers so they can store their own data in the database automatically.
  • the first-party process 106 may not need to manage or provide the new data type data to the database 1 104, Instead, the plug-ins may provide the data to the updated database 1 106, that includes the new data types and/or both the original data types and the new data types.
  • the asset download 1 102 may be a data file (e.g., not executable code) that can be downloaded to the device to provide the appropriate information for extending the data types as described above.
  • the asset download 1 102 may include data type definition updates.
  • the user device 102 can download the asset download 1 102 and have that information available on the device for access/use by third-party applications.
  • the third-party applications can write to the new data type and read back from it.
  • the APIs for reading and writing to the new data type may be extensible so that the executable code for the user device 102 does not need to be changed, but the first-party process 106 can still support the new data type.
  • the asset download 1 102 may be provided by the service provider computers 304 and, as noted, may include all the information for the new data types. In this way, the first-party process 106 may utilize the information in the asset download 1 102 to register the new data, types identified in the asset download 1 102 instead of (or in addition to) using the plug-ins described above.
  • the service provider computers 304 may also publish the identifiers listed in the asset download 1 102 to a. network resource over a private or public network (e.g., the Internet).
  • plug-ins are executable code that include appropriate information for making changes to the functionality, while the asset download 1 102 is merely data. As such, code within first-party process 106 may be executed to interpret the data of the asset download 1102 and turn it into actual data types.
  • data types may also include analysis of the data values (e.g., whether a data value for a particular data type is good or bad for a particular user). This analysis information may also be included in the asset download 1 102 and'Or published to the network resource for availability to the developers and/or third-party' applications.
  • Database 1 104 may represent the state of the data types prior to implementation of the asset download 1 102 (e.g., with the original data types), while the database 1 106 may represent the state of the data types after the implementation of the asset download 1 102 (e.g., including the new data types).
  • FIGS. 12 and 13 illustrate example flow diagrams showing processes 1200 and 1300 for managing personal information from external sources, according to at least a few
  • the sendee provider computers 304 may perform the process 1200 of FIG. 12.
  • the process 1200 may begin at 1202 by including maintenance of a plurality of data types.
  • the data types may identify a category or attribute of health information including, but not limited to, weight, glucose levels, steps per minute, heart rate, miles traveled, etc.
  • the process 1200 may include enabling storage, on the user device 102, of first health information of a subset of the plurality of data types. In other words, the user device 102 may receive health information corresponding to a single data type, even though multiple data types may exist or be possible.
  • the process 1200 may include identifying a new data type requested for use with a third-party application of the user device 102.
  • these new data types may be identified by the service provider computers 302 receiving a request from a developer or other user of the framework.
  • the process 122 may include providing data (e.g., the mobile asset) to the user device 102 that identifies the information about the new data type.
  • the process 1200 may also include publishing this information (e.g., the identifiers, descriptions, etc.) at 1210 to a network resource (e.g., a web page or other resource accessible over a network) that may be accessible to the public or at least to developers of third-party applications.
  • a network resource e.g., a web page or other resource accessible over a network
  • the process 1200 may include causing a background process (e.g., the first-party process 106) of the user device 102 to interpret the data to implement the new data type.
  • the process 1200 may include enabling the background process of the user device to manage second health information (e.g., associated with the new data type).
  • the process 1200 may end at 1216, where the service provider computer may update the maintained data types with the new data type. In other words, the service provider computers 304 may update their own tables or databases to include the new data type.
  • FIG. 13 illustrates another process 1300 for managing personal information from external sources, according to at least a few embodiments.
  • the user device 102 e.g., utilizing at least the extension module 334 shown in FIG. 3
  • the process 1300 may begin at 1302 by including reception of instructions for implementing a background process to manage a first set of data types. In some cases, this first set of data types may be based at least in part on the data types in the original image for the user device 102 and/or for the first-party process 106.
  • the process 1300 may include receiving a data download that includes information about the new data type.
  • the process 1300 may include receiving, from an application (e.g., a third-party application), a request to access data of the new data type. That is, once the new data type is implemented, third-party applications can make API method calls that include that new data, type as a parameter.
  • the process 1300 may and at 1308, where the first-party process 106 may provide the data entry corresponding to the new data type to the requesting application,
  • FIG. 14 illustrates another example architecture 1400 for implementing additional features of the management of personal information from external sources, depicting the user device 102, the first-party application framework 104, and the first-party process 106 of FIG. 1.
  • one or more third party applications e.g., third-party application A 1402 and/or third-party application B 1404
  • data collection devices e.g., data collection device A 1406 and/or data collection device B 1408
  • the data collection devices 1406, 1408 may be any wearable or mobile device configured to collect activity, health, medical, and/or fitness information about a user. This information may then be provided to one of the third-party applications (e.g., the third-party application A 1402 may receive data from the data collection device A 1406 and/or the data collection device B 1408) via one or more networks 1410 or 1412. Once received by the third-party application A 1402, the information can be provided to the first-party process 106 for storage in a database or other storage system.
  • the data collection device A 1406 is shown communicating with the third-party application A 1402 over a network 1412
  • the data collection device B 1408 is shown communicating with the third-party application B 1404 over the network 1412
  • any combination of application-to-device(s) pairings are possible and that such pairings may be facilitated by any number of different or same network connections.
  • the first-party process 106 may request priority information from a user of the user device 102. In this way, the user may provide priority information associated with which of the data collection devices 1406, 1408 the user would prefer to track when multiple devices 1406, 1408 are providing data for the same data type and/or for the same time period.
  • the first-party process 106 may receive data entries from both the data collection device A 1406 and the data collection device B 1408 for the same time period.
  • the data may correspond to a particular data type (e.g., heart rate), yet the data entries may differ slightly (e.g., the two collection devices 1406, 1408 may not be calibrated the same or one might be more sensitive than the other).
  • the first-party process 106 may determine to track only one of the sets of data entries.
  • the first-party process 106 may determine to track one set of data for a first set of time and the other set of data of data for a. second set of time.
  • the determination of which data entries to track may be based at least in part on a priority set by the user, a type or kind of the data type (e.g., whether it is cumulative or discrete), timing information (e.g., what time the data was received), and/or other information about the data, entry.
  • a type or kind of the data type e.g., whether it is cumulative or discrete
  • timing information e.g., what time the data was received
  • the first-party application framework 104 may be configured to implement a UI 1414 for presenting collected data (e.g., from a single or multiple data collection devices 1406, 1408) and/or aggregated data (e.g., the data record).
  • the data record may also be provided to one or more requesting entities (e.g., either or both of the third-party applications 1402, 1404, or other third-party applications.
  • the UI 1414 may be configured to present the aggregated data record or subsets of the data record to the user,
  • the UI may present a different looking representation of the data than for cumulative data.
  • the first-party process 106 may first identify whether the data to be provided to the UI 1414 is discrete or cumulative. The first-party process 106 may also identify if there is priority information provided by the user. If not, the first-party process 106 may determine priority information based at least in part on previous configurations of the user, historical and/or use information from other users of the device 102 or of other devices (e.g., a probability that the user will use the data collection device 1406 at a particular time), and/or information about accuracy of the respective coll ection devices 1406, 1408.
  • the first-party process 106 may use that priority information to determine which collected data for a single data type should be included in the data record for each time period or for each time segment of the time period (e.g., each second of the 5 minute window of collected data, etc.).
  • the priority information may be configured via the UI 1414, such that the user may slide, drag, or otherwise virtually move the sources (e.g., the data collection devices 1406, 1408) up and down to identify a preferred priority.
  • the priority information and the received data entries may correspond to any number of data, collection devices and/or applications.
  • the collected data may be segmented for each time period such that data is represented in a meaningful manner. For example, if a person never takes more than a single step per millisecond, using milliseconds as the segmentation for steps would probably not provide meaningful results. However, if the lower bounds for steps were half a second (e.g., when someone is running) and 2 seconds (e.g., when someone is walking very slow), then the segments for steps should be somewhere between 0.5 and 2 seconds for a particular time window (e.g., an entire day or at least the hours that the user spends awake). As such, historical and/or use information for each data type may be collected and analyzed to automatically identify appropriate segment bounds.
  • the first-party process 106 and/or the first-party application framework 104 may provide API methods for third parties (e.g., the third-party application 1402) to utilize to retrieve the aggregated data records. In this way, the third-party application 1402 may be able to customize a request for aggregated data o ver a particular period of time and/or for a particular data type.
  • the first-party process 106 may respond to the API method calls by providing an aggregated data record that includes data collected from sources other than the requestor (e.g., other than the third-party application 1402). This may enable one application to receive an aggregated data record that is not solely based on the data the data provided by that application. Additionally, the UI1414 may be configured to provide cumulative and/or discrete data for multiple data sources to a user or other application.
  • FIG. 15 illustrates several example UI renderings within the UI 1414 of FIG. 14.
  • the UI 1414 may be configured to represent each data entry as a data point on a time graph.
  • a user may have three different devices collecting their weight over the course of a day, week, month, etc.
  • the discrete data type presentation 1502 may include each data entry received by the first-party process 106 from the three different sources. Since weight is not a data type that would be added up over time (e.g., it is discrete), it may be appropriate to present each different data point for each segment.
  • a prioritized source may be identified by a line or other interface object/element that highlights the data points from that source.
  • the line connecting the square points on the presentation 1502 is one example of a way to represent priority or a preferred data source.
  • the data when the data is cumulative, the data may be summed or otherwise added up over the entire time period. As shown in the cumulative data, type presentation 1504, this may cause a double counting problem when multiple sources provide data for the same time segments. For example, over the first third of the time period, the first-party process 106 may only have received data from a first source (e.g., A number of steps). For a cumulative data type (e.g., steps walked), the data entries at, each segment may be added together to get a total.
  • a first source e.g., A number of steps
  • the first-party process 106 may also have only received data from the first, source (e.g., C number of steps). However, if two sources provided step data during the middle third of the time period, adding both B number of steps and alpha number of steps would not, provide an accurate total step count because the number of steps during that time period would be double counted or at least counted from two different sources. As such, using the priority information collected from the user, the UI 1414 may be able to present a piecemeal representation such as the prioritized cumulative data type presentation 1506. In this presentation 1506, the alpha number of steps may have been identified as the user's prioritized data source for this subset of the time period.
  • alpha number of steps e.g., coming from one source
  • a and C number of steps e.g., coming from a different source
  • the total number of steps aggregated over the time period in this presentation 1506 may be A + alpha + C, as opposed to A + B + alpha + C from the cumulative data type presentation 1504.
  • FIGS. 16 and 17 illustrate example flow diagrams showing processes 1600 and 1700 for managing personal information from external sources, according to at least a few
  • the user device 102 may perform the process 1600 of FIG. 16.
  • the process 1600 may begin at 1602 by including identification of a particular data type of a plurality of data types, identification of the particular data type may include identifying the data type itself (e.g., number of steps, weight, heart rate, etc.) or identifying a type or kind of the data type (e.g., cumulative or discrete).
  • the process 1600 may include receiving health data corresponding to particular the particular data entry from at least a first data source and a. second data, source.
  • the data, sources may be third-party applications, other (e.g., first-party) applications, and/or data collection devices.
  • the process 1600 may include receiving priority information identifying a priority of the first and second sources. This priority information may be received via a. UI where the user can virtually move icons or other source identifiers up and down to indicate position, or it may be done in code, or using other techniques such as, but not limited to, check boxes, radio buttons, drop down lists, text entry (e.g., 1 , 2, 3, etc.), or the like.
  • the process 1600 may include identifying a time interval for partitioning the health data. These partitions (also referred to as segments) may be based at least in part on user information, data type information, historical and/or use data, or the like.
  • the process 1600 may include identifying a data entry corresponding to a source with the highest priority during each time interval or segment. In some examples, this may only apply when a data entry exists for that segment.
  • the process 1600 may include aggregating each identified data record over the amount of time (e.g., the day, an hour, etc.). In some cases, the process 1600 may end at 1 614, where the process 1600 may include providing the aggregated data record for presentation (e.g., to the user).
  • FIG. 17 illustrates another process 1700 for managing personal information from external sources, according to at least a few embodiments.
  • the user device 102 e.g., utilizing at least the aggregation module 340 shown in FIG. 3 may perform the process 1700 of FIG. 1 7.
  • the process 1700 may begin at 1702 by including recei ving data of a particular data type from a first source and a second source.
  • the process 5700 may include identifying priority information associated with the first source and the second source.
  • the priority information may indicate which of the first or second source, the user prefers to view data from when they both provide data for the same data type.
  • the process 1700 may include aggregating the received data to form a data record over a period of time.
  • the aggregated data record may be based at least in part on the priority information and/or a probability that the user will prefer (and/or use) one of the sources over the other one.
  • the process 1700 may include providing an API to the third-party applications for request the aggregated data record.
  • the process 1700 may end at 1710, where the process 1700 may include providing the data record to an application for presentation.
  • a UI may be provided that represents the aggregated data record such as, but not limited to, the prioritized cumulative data type presentation 1506 or something similar.
  • the various embodiments further can be implemented in a wide variety of operating environments, which in some cases can include one or more user computers, computing devices or processing devices which can be used to operate any of a number of applications.
  • User de vices e.g., client devices
  • client devices can include any type of general purpose personal computer such as, but not limited to, desktop or laptop computers running a standard operating system, as well as cellular, wireless, and/or handheld devices running mobile software and capable of supporting a number of networking and messaging protocols.
  • These devices can also include other electronic devices, such as dummy terminals, thin-clients, gaming systems, or other devices capable of communicating via a network.
  • Most embodiments utilize at least one network that would be familiar to those skilled in the art for supporting communications using any of a variety of commercially-available protocols, such as TCP/IP, OS1, FTP, UPnP, NFS, CIFS, and AppleTalk.
  • the network can be, for example, a local area network, a wide-area network, a virtual private network, the Internet, an intranet, an extranet, a public switched telephone network, an infrared network, a wireless network, and any combination thereof.
  • the environment can include a variety of data stores and other memory and storage media as discussed above. These can reside in a variety of locations, such as on a storage medium local to (and/or resident in) one or more of the computers. Alternatively, the memory can be remote from any or all of the computers across the network. In a particular set of embodiments, the information may reside in a storage-area network (SAN) familiar to those skilled in the art. Similarly, any necessary files for performing the functions attributed to the computers, servers or other network devices may be stored locally and/or remotely, as desired.
  • SAN storage-area network
  • the system and various devices may also include one or more software applications, modules, services, or other elements located within at least one working memory device, including an operating system and application programs, such as a client application or browser. It should be appreciated that alternate embodiments may have numerous variations from that described above. For example, customized hardware might also be used and/or particular elements might be implemented in hardware, software (including portable software, such as applets) or both. Further, connection to other computing devices such as network input/output devices may be employed.
  • containing are to be construed as open-ended terms (i.e., meaning “including, but not limited to,”) unless otherwise noted.
  • the term “connected” is to be construed as partly or wholly contained within, attached to, or joined together, even if there is something intervening.
  • Disjunctive language such as the phrase "at least one of X, Y, or Z," unless specifically stated otherwise, is otherwise understood within the context as used in general to present that an item, term, etc., may be either X, Y, or Z, or any combination thereof (e.g., X, Y, and/ or Z). Thus, such disjunctive language is not generally intended to, and should not, imply that, certain embodiments require at least one of X, at least one of Y, or at least one of Z to each be present. [0099] Any of the methods described herein may be totally or partially performed with a computer system including one or more processors, which can be configured to perform the steps.
  • embodiments can be directed to computer systems configured to perform the steps of any of the methods described herein, potentially with different components performing a respective steps or a respective group of steps.
  • steps of methods herein can be performed at a same time or in a different order. Additionally, portions of these steps may be used with portions of other steps from other methods. Also, ail or portions of a step may be optional.
  • any of the steps of any of the methods can be performed with modules, circuits, or other means for performing these steps.
  • a computer-implemented method comprising:
  • Clause 2 The computer-implemented method of clause 1 , wherein the indication that the authorization request was provided to the user is provided to the third-party application without indicating whether the user denied access to the at least one data type.
  • Clause 3 The computer-implemented method of clause 1 , wherein the user has provided the health information corresponding to the at least one data type.
  • Clause 4 The computer-implemented method of clause 3, wherein the empty result is provided to the third-party application without indicating that the user has provided the health information corresponding to the at least one data type.
  • Clause 5 The computer-implemented method of clause 1 , wherein data of the secure storage device is accessible to the third-party application when the user is
  • a memory configured to store computer-executable instructions
  • a processor in communication with the memory configured to execute the computer-executable instructions to at least:
  • Clause 10 The system of clause 8, wherein the user is enabled to authorize access to first health data of a first data type and deny access to second health data of a second data type.
  • Clause 11 The system of clause 10, wherein the memory is configured to store the second health data and not store the first health data.
  • Clause 12 The system of clause 1 1, wherein the processor is further configured to execute the computer-executable instructions to at least receive, from the application, a first data request, for the first health data and a second data request for the second health data.
  • Clause 13 The system of clause 12, wherein the processor is further configured to execute the computer-executable instructions to at least provide an empty result to the application in response to both the first, data request and the second data request. Clause 14. The system of clause 8, wherein the processor is further configured to execute the computer-executable instructions to at least provide a read request, to the user, for the user to authorize the application to read the data stored in the memory.
  • Clause 15 The system of clause 14, wherein the processor is further configured to execute the computer-executable instructions to at least provide, to the application, only information provided by the application to the memory when the user denies the read request.
  • A. computer-readable storage medium storing computer-executable instructions that, when executed by a processor, configure the processor to perform operations comprising:
  • Clause 17 The one or more computer-readable media of clause 16, wherein the application is a third-party appl ication configured to be capable of at least one of reading or writing at least a portion of the information to the data store, and wherein at least one first party application is configured to be capable of at least one of reading or writing at least the portion of the information to the data store.
  • the application is a third-party appl ication configured to be capable of at least one of reading or writing at least a portion of the information to the data store
  • at least one first party application is configured to be capable of at least one of reading or writing at least the portion of the information to the data store.
  • Clause 18 The computer-readable medium of clause 1 7, wherein the user is enabled to respond to the first request for authorization for each of a plurality of data types.
  • Clause 19 The computer-readable medium of clause 16, wherein the denial of the first request for authorization is masked by providing a response to the application that does not indicate that the user denied the first request for authorization. Clause 20, The computer-readable medium of clause 19, wherein the response to the application does not indicate that the user denied the first request for authorization by:
  • a computer-implemented method comprising;
  • a secure storage configured to store health data corresponding to a plurality of data types
  • Clause 2 The computer-implemented method of clause 1 , wherein the portion of the health data corresponding to the at least one data type is received from an application associated with a data collection device.
  • Clause 3 The computer-implemented method of clause 1 , wherein the frequency is configured by the third-party application.
  • Clause 4 The computer-implemented method of clause 1 , wherein the frequency identifies an amo unt of time between receipt of the portion of the health data and launching the third-party application as the background process.
  • Clause 5 The computer-implemented method of clause 1 , wherein the third- party application is launched without a request from, a data collection device or the third-party application.
  • Clause 6 The computer-implemented method of clause 1 , wherein the time period is configured to be increased for each relaunching of the third-party application.
  • Clause 7 The computer-implemented method of clause 6, wherein the increase is exponential to a threshold amount of time.
  • a system comprising:
  • a memory configured to store computer-executable instructions
  • a processor in communication with the memory configured to execute the computer-executable instructions to at least:
  • Clause 9 The system, of clause 8, wherein the application is enabled to request the received portion of the information while running as the background process.
  • Clause 10 The system, of clause 9, wherein the application is enabled to process the received portion of the information and return the confirmation that the application has processed the portion of the information while running as the background process.
  • Clause 1 1. The system of clause 8, wherein the subscription information identifies the data type and a frequency associated with the subscription. Clause 12. The system of clause 1 1, wherein the frequency identifies an amount of time between the receipt of the portion of the information and launching the application as the background process.
  • Clause 13 The system of clause 8, wherein the processor is further configured to execute the computer-executable instructions to at least, relaunch the application as the background process based at least, in part on a time interval when the confirmation is not received within the time interval.
  • Clause 14 The system of clause 13, wherein the time interval is increased after each relaunch of the application as the background process.
  • a computer-readable storage medium storing computer-executable instructions that, when executed by a processor, configure the processor to perform operations comprising:
  • Clause 16 The one or more computer-readable media of clause 15, wherein the first application is a third-party application configured to process health information associated with the plurality of health data types.
  • Clause 17 The computer-readable medium of clause 15, wherein the second application is configured to receive the second data from a data collection device configured to collect health information of the user. Clause 18. The computer-readable medium of clause 17, wherein the first application is at least one of launched or relaunched as the background process without receipt of an instruction, from the data collection device or the first application, to launch or relaunch the first application.
  • Clause 19 The computer-readable medium of clause 15, wherein the first application is configured to request the second data while launched or relaunched as the background process.
  • Clause 20 The computer-readable medium of clause 15, wherein the first time period is configurable by the first application, and wherein the second time period changes by a configurable amount after each relaunch of the first application as the background process.
  • a computer-implemented method comprising;
  • Clause 2 The computer-implemented method of clause 1 , wherein the information about the new data type is published to a network resource for developers associated with the computer system. Clause 3, The computer-implemented method of clause 1 , further comprising updating the plurality of maintained data types to include the new data type.
  • Clause 4 The computer-implemented method of clause 1 , wherein the information about the new data type includes at least one of an identifier, a name, a type, or a description.
  • Clause 5 The computer-implemented method of clause 4, wherein the type comprises at least a cumulative type or a discrete type.
  • Clause 6 The computer-implemented method of clause 1 , wherein the request, from the third-party application, comprises an application programming interface method call.
  • a system comprising:
  • a memory configured to store computer-executable instructions
  • a processor in communication with the memory configured to execute the computer-executable instructions to at least:
  • Clause 8 The system, of clause 7, wherein the processor is further configured to execute the computer-executable instructions to at least publish the information about the new data type to a network resource.
  • Clause 9 The system of clause 8, wherein the information about, the new data type is published to the network resource after the data is provided for the user device to download.
  • Clause 10 The system of clause 9, wherein the processor is further configured to execute the computer-executable instructions to at least cause the user device to return an error message when the request using the format is received before the data is downloaded by the device.
  • Clause 11 The system, of clause 7, wherein the first set of data types is provided to the user device as part of a new software release for the user device.
  • managing the health data comprises at least one of reading the health data corresponding to the new data type from the user device or writing the health data corresponding to the new data type to the user device.
  • a computer-readable storage medium storing computer-executable instructions that, when executed by a. processor, configure the processor to perform operations comprising:
  • Clause .15 The one or more computer-readable media of clause 14, wherein the operations further comprise registering the new data type with the background process prior to receiving the request to access the data corresponding to the new data type. Clause 16. The one or more computer-readable media of clause 14, wherein the new data type was not included in the first set of data types provided with the instructions for implementing the background process.
  • Clause 17 The computer-readable medium of clause 14, wherein the operations further comprise enabling the service provider to identify the new data type from a network source updated by developers.
  • Clause 18 The computer-readable medium of clause 14, wherein the operations further comprise enabling the service provider to publish the information about the new data type.
  • Clause 19 The computer-readable medium of clause 18, wherein the information about the new data type includes at least one of an identifier, a name, a type, or a description.
  • Clause 20 The computer-readable medium of clause 14, wherein the request to access the data corresponding to the new data, type comprises an application programming interface method call received from, the application.
  • a computer-implemented method comprising:
  • Clause 2 The computer-implemented method of clause 1 , further comprising providing the aggregated record to a user device for presentation within a user interface to a user.
  • Clause 3 The computer-implemented method of clause 1 , further comprising receiving a request from, the first source for the aggregated record that, at least includes the received health data from the second source.
  • Clause 4 The computer-implemented method of clause 1 , further comprising identifying a type of the particular data type based at least in part on metadata associated with the received health data.
  • Clause 5 The computer-implemented method of clause 4, wherein the aggregated record only includes each identified data entry corresponding to the highest identified priority when the identified type is cumulative.
  • Clause 6 The computer-implemented method of clause 4, wherein the aggregated record includes each identified data entry corresponding to the highest identified priority and other identified data entries for the identified time period when the identified type is discrete.
  • a memory configured to store computer-executable instructions
  • a processor in communication with the memory configured to execute the computer-executable instructions to at least
  • Clause 8 The system, of clause 7, wherein the at least one application is a particular one of the plurality of so urces, and wherein the data record includes at least, one data point not, received from the particular one of the plurality of sources.
  • Clause 9 The system of clause 7, wherein at least one of the plurality of sources comprises a. third-party application or a first-party application.
  • Clause 10 The system of clause 9, wherein the received data is based at least in part on metrics collected by a data, collection device associated with at least, one of the third- party application or the first-party application.
  • Clause 11 The system of clause 7, wherein the processor is further configured to execute the computer-executable instructions to at least identify priority information for at l east a s ubset of the plurality of so urces and a. time interval for the period of tim e.
  • Clause 12 The system of clause 1 1, wherein the processor is further configured to execute the computer-executable instructions to at least identify a data entry for the particular data type with a highest identified priority for each time interval.
  • Clause 13 The system of clause 12, where in the provided data record only includes each identified data entry corresponding to the highest identified priority when the particular data type is cumulative.
  • Clause 14 The system of clause 7, wherein the provided data record includes data entries corresponding to the particular data, type from the plurality of sources for individual time intervals of the period of time, wherein at least one time interval of the individual time intervals include des a plurality of different data, entries, and wherein at least one of the plurality of data, entries is from a different, source of the plurality of sources.
  • a computer-readable storage medium storing computer-executable instructions that, when executed by a. processor, configure the processor to perform operations comprising:
  • Clause 16 The one or more computer-readable media of clause 55, wherein the data record represents individual data entries of the particular data type for each of a plurality of time intervals during the period of time.
  • Clause 17 The computer-readable medium of clause 16, wherein a length of the plurality of time intervals is determined based at least in part on at least one of the particular data type, an activity associated with the particular data type, or historical information associated with a user of the at least one application.
  • Clause 18 The computer-readable medium of clause 15, wherein the identified priority information is determined based at least in part on at least one of a preference of a user, historical behavior of the user, or activity behavior associated with the first data source or the second data source.
  • Clause 19 The computer-readable medium of clause 15, wherein the at least one application comprises a third-party application configured to provide a user interface corresponding to the data record to a user of the third-party appl ication.
  • Clause 20 The computer-readable medium of clause 1 9, wherein the operations further comprise providing an application programming interface method to the third- party application for requesting the data record, the data record including at least some health information of the user not provided by the third-party application.

Landscapes

  • Engineering & Computer Science (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Theoretical Computer Science (AREA)
  • Epidemiology (AREA)
  • Primary Health Care (AREA)
  • Public Health (AREA)
  • Bioethics (AREA)
  • Databases & Information Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Storage Device Security (AREA)

Abstract

L'invention concerne des systèmes, des procédés et un support lisible par ordinateur permettant de gérer des informations utilisateur. Des données de l'utilisateur peuvent être stockées dans une mémoire, par exemple. Une demande pour qu'un utilisateur autorise l'accès à au moins une partie des données peut être fournie. L'autorisation peut être pour une demande d'accès à cette partie des données. Dans certains exemples, une réponse à la demande peut être reçue et l'indication que la demande a été présentée à l'utilisateur peut être fournie sans qu'il soit mentionné si l'utilisateur a refusé la demande.
PCT/US2015/029494 2014-05-30 2015-05-06 Gestion d'informations utilisateur WO2015183495A1 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP19205864.2A EP3675135A1 (fr) 2014-05-30 2015-05-06 Gestion d'informations d'utilisateur
EP15724859.2A EP3149634B1 (fr) 2014-05-30 2015-05-06 Gestion d'informations utilisateur
EP23181820.4A EP4235682A1 (fr) 2014-05-30 2015-05-06 Gestion d'informations d'utilisateur
CN201580028726.9A CN106462616B (zh) 2014-05-30 2015-05-06 管理用户信息

Applications Claiming Priority (10)

Application Number Priority Date Filing Date Title
US201462006031P 2014-05-30 2014-05-30
US62/006,031 2014-05-30
US14/499,519 2014-09-29
US14/499,461 2014-09-29
US14/499,449 US10236079B2 (en) 2014-05-30 2014-09-29 Managing user information—authorization masking
US14/499,461 US9582642B2 (en) 2014-05-30 2014-09-29 Managing user information—background processing
US14/499,519 US9582643B2 (en) 2014-05-30 2014-09-29 Managing user information—source prioritization
US14/499,512 2014-09-29
US14/499,512 US11404146B2 (en) 2014-05-30 2014-09-29 Managing user information—data type extension
US14/499,449 2014-09-29

Publications (1)

Publication Number Publication Date
WO2015183495A1 true WO2015183495A1 (fr) 2015-12-03

Family

ID=53267608

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2015/029494 WO2015183495A1 (fr) 2014-05-30 2015-05-06 Gestion d'informations utilisateur

Country Status (1)

Country Link
WO (1) WO2015183495A1 (fr)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9582642B2 (en) 2014-05-30 2017-02-28 Apple Inc. Managing user information—background processing
US9996678B2 (en) 2014-05-30 2018-06-12 Apple, Inc. Systems and methods for facilitating health research using a personal wearable device with research mode
CN111176864A (zh) * 2019-12-31 2020-05-19 中国银行股份有限公司 App服务数据调用方法及装置
US10733266B2 (en) 2014-05-30 2020-08-04 Apple Inc. Systems and methods of providing patient apps
EP3616098A4 (fr) * 2017-06-02 2020-12-09 Apple Inc. Partage de données entre plusieurs dispositifs informatiques
CN113191592A (zh) * 2021-03-31 2021-07-30 青岛海尔科技有限公司 用于用户信息管理的方法、电子设备及存储介质
US11107578B2 (en) 2014-05-30 2021-08-31 Apple Inc. Systems and methods for facilitating health research
US11728030B2 (en) 2014-09-29 2023-08-15 Apple Inc. Methods of treatment and diagnosis using enhanced patient-physician communication

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060248592A1 (en) * 2005-04-28 2006-11-02 International Business Machines Corporation System and method for limiting disclosure in hippocratic databases
US20100306827A1 (en) * 2009-06-02 2010-12-02 Microsoft Corporation Opaque Quarantine and Device Discovery
US20140059695A1 (en) * 2012-08-24 2014-02-27 Environmental Systems Research Institute (ESRI) Systems and methods for managing location data and providing a privacy framework

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060248592A1 (en) * 2005-04-28 2006-11-02 International Business Machines Corporation System and method for limiting disclosure in hippocratic databases
US20100306827A1 (en) * 2009-06-02 2010-12-02 Microsoft Corporation Opaque Quarantine and Device Discovery
US20140059695A1 (en) * 2012-08-24 2014-02-27 Environmental Systems Research Institute (ESRI) Systems and methods for managing location data and providing a privacy framework

Cited By (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11056217B2 (en) 2014-05-30 2021-07-06 Apple Inc. Systems and methods for facilitating health research using a personal wearable device with research mode
US11107578B2 (en) 2014-05-30 2021-08-31 Apple Inc. Systems and methods for facilitating health research
US9996678B2 (en) 2014-05-30 2018-06-12 Apple, Inc. Systems and methods for facilitating health research using a personal wearable device with research mode
US10236079B2 (en) 2014-05-30 2019-03-19 Apple Inc. Managing user information—authorization masking
US10290367B2 (en) 2014-05-30 2019-05-14 Apple Inc. Managing user information—background processing
US10460834B2 (en) 2014-05-30 2019-10-29 Apple Inc. Systems and methods for facilitating health research using a personal wearable device with research mode
US9582643B2 (en) 2014-05-30 2017-02-28 Apple Inc. Managing user information—source prioritization
US10733266B2 (en) 2014-05-30 2020-08-04 Apple Inc. Systems and methods of providing patient apps
US9582642B2 (en) 2014-05-30 2017-02-28 Apple Inc. Managing user information—background processing
US11404146B2 (en) 2014-05-30 2022-08-02 Apple Inc. Managing user information—data type extension
US11728030B2 (en) 2014-09-29 2023-08-15 Apple Inc. Methods of treatment and diagnosis using enhanced patient-physician communication
EP3616098A4 (fr) * 2017-06-02 2020-12-09 Apple Inc. Partage de données entre plusieurs dispositifs informatiques
CN111176864A (zh) * 2019-12-31 2020-05-19 中国银行股份有限公司 App服务数据调用方法及装置
CN111176864B (zh) * 2019-12-31 2023-09-19 中国银行股份有限公司 App服务数据调用方法及装置
CN113191592A (zh) * 2021-03-31 2021-07-30 青岛海尔科技有限公司 用于用户信息管理的方法、电子设备及存储介质

Similar Documents

Publication Publication Date Title
US10290367B2 (en) Managing user information—background processing
WO2015183495A1 (fr) Gestion d'informations utilisateur
JP7186245B2 (ja) デバイスの使用管理
US9667661B2 (en) Privileged account manager, dynamic policy engine
US20240037274A1 (en) Secure storage and retrieval of sensitive information
JP6833711B2 (ja) 連続グルコース監視のための分散システムアーキテクチャ
US10069703B2 (en) Methods and systems for monitoring and/or managing device data
ES2906101T3 (es) Mecanismos de pronóstico de situación para plataforma de integración de Internet de las Cosas
US20140123299A1 (en) Methods and systems for managing one or more services and/or device data
US10346441B2 (en) Systems and methods for providing predictions to applications executing on a computing device
US9953188B2 (en) System, method, and program for storing and controlling access to data representing personal behavior
US20220392633A1 (en) Personalized data graphs including user domain concepts
US20210397427A1 (en) Training an agent-based healthcare assistant model
Stach et al. The Privacy Management Platform

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15724859

Country of ref document: EP

Kind code of ref document: A1

REEP Request for entry into the european phase

Ref document number: 2015724859

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2015724859

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE