Global Configuration Services

Abstract

Certain aspects of the present disclosure generally relate to configuring an application used with a medical device to help monitor and improve a patient's health. Certain aspects include a method including receiving a request for an asset including access information associated with a user of a computing device, the access information including functionality customization information of the health intervention application and issued by an account management service of the health intervention application, and verifying that the access information is valid. The method may also include, in response to the verifying, generating configuration information based at least in part on the functionality customization information included in the access information, the configuration information identifying a set of assets to which the health intervention application is to be provisioned, and sending the configuration information to the health intervention application to configure the health intervention application with the identified set of assets.

Description

Technical Field

[0001] Cross - reference to Related Applications This application claims the benefit of U.S. Provisional Application No. 63 / 175,199, entitled "GLOBAL CONFIGURATION SERVICE," filed on April 15, 2021. The foregoing application is hereby incorporated by reference in its entirety.

Background Art

[0002] Diabetes is a metabolic disease related to the production or use of insulin in the body. Insulin is a hormone that enables the body to use glucose as energy or store glucose as fat.

[0003] When a human eats a diet containing carbohydrates, the food is processed in the digestive system and glucose is produced in the blood. Blood glucose can be used as energy or stored as fat. The body usually maintains blood glucose levels within a range sufficient to support bodily functions and avoids problems that can arise from glucose levels being too high or too low. Adjusting blood glucose levels depends on the production and use of insulin, which regulates the movement of blood glucose into cells.

[0004] When the body does not produce enough insulin or when the body cannot effectively use the insulin present, blood glucose levels can rise above the normal range. A state where blood glucose levels are higher than normal is called "hyperglycemia." Chronic hyperglycemia can cause many health problems, such as cardiovascular disease, cataracts and other eye diseases, neuropathy, and kidney damage. Hyperglycemia can also cause acute problems such as diabetic ketoacidosis (a state in which the body becomes overly acidic due to the presence of blood glucose and ketone bodies produced when the body cannot use glucose). A state where blood glucose levels are lower than normal is called "hypoglycemia." Severe hypoglycemia can lead to acute crises such as seizures or death.

[0005] Diabetic patients can receive insulin to manage their blood glucose levels. Insulin can be administered, for example, through manual injection using a needle. Wearable insulin pumps are also available. Diet and exercise also affect blood glucose levels.

[0006] Diabetes is sometimes referred to as "type 1" and "type 2." Individuals with type 1 diabetes typically can use insulin if present, but due to problems with the insulin-producing beta cells in the pancreas, they cannot produce sufficient amounts of insulin in their bodies. Individuals with type 2 diabetes can produce some insulin, but due to reduced sensitivity to insulin, they are "insulin resistant." As a result, even though insulin is present in the body, it is not adequately utilized and does not effectively regulate blood glucose levels.

[0007] Managing diabetes can present complex challenges for patients, clinicians, and caregivers, as a combination of many factors can influence a patient's glucose levels and glucose trends. To help patients better manage this condition, various health or disease intervention software applications (hereinafter, "Applications") have been developed by various providers. Diabetes is just one example of a condition for which a variety of software applications have been developed. Many other applications have been developed for other health-related conditions. For example, these applications may include intervention applications to support the treatment of other diseases, or applications that help improve a patient's overall health, such as activity tracking applications and diet applications.

[0008] These health applications are used in combination with various sensors that measure biological parameters, as well as tracking events such as activity and nutrition, to provide users with information about their health status and disease or health improvement. In most cases, the application is specifically designed for each use case to achieve specific goals for a particular set of users. This use case-specific approach is particularly important with respect to safety-critical information, as different rules or considerations must be applied to determine how the application interacts with the patient's health-related information. These regulations may depend, for example, on geographical location or on the capabilities or specifications of the patient's specific demographics or health status.

[0009] This background information is provided to introduce a brief context of the subsequent outline of the invention and the modes for carrying out the invention. This background information is not intended to help determine the scope of the claimed subject matter, nor to be considered to limit the claimed subject matter to any implementation that solves any or all of the defects or problems presented above. [Overview of the Initiative] [Means for solving the problem]

[0010] A particular embodiment provides a method for configuring a diabetes intervention application that runs on a computing device via a remote server, the method comprising: receiving a request from the diabetes intervention application for assets provided by the remote server, wherein the request includes access information associated with a user of the computing device, the access information includes functional customization information for the diabetes intervention application, and is issued by the account management service of the diabetes intervention application; verifying that the access information is valid; generating configuration information that identifies a set of assets for which the diabetes intervention application should be provisioned, at least in part, based on the functional customization information contained in the access information, in response to verifying that the access information is valid; and transmitting the configuration information to the diabetes intervention application in order to configure the diabetes intervention application with the identified set of assets.

[0011] In the above method, the function customization information includes location information associated with the geographical location of the user of the computing device. In the above method, generation includes identifying a set of URLs from a plurality of uniform resource locators (URLs) that should be used to configure the diabetes intervention application, and the configuration information includes the set of URLs. In the above method, generation includes identifying a set of application functions from a plurality of application functions that should be activated to configure the diabetes intervention application, and the configuration information includes one or more flags associated with the set of application functions that are set to a value indicating that the set of application functions is activated.

[0012] In the above method, the function customization information includes version information of the diabetes intervention application running on the computing device. In the above method, the function customization information includes operating environment information of the computing device and the glucose monitoring device connected to the computing device. In the above method, the access information includes the function customization information and an access token including token authentication information. In the above method, the configuration information includes the mapping of application parameters associated with application functions to values ​​corresponding to specific application function settings.

[0013] A particular aspect provides an alternative method for configuring a diabetes intervention application running on a computing device via a remote server, the method comprising: receiving a request from the diabetes intervention application to start a session on the diabetes intervention application, the request including a user certificate for a user account associated with a user of the diabetes intervention application; verifying that the user certificate is valid for the user account; generating access information for the diabetes intervention application for use in retrieving configuration information for the diabetes intervention application from a global configuration service based on the verification of the user certificate's validity; and transmitting the access information to the diabetes intervention application.

[0014] The above method further includes receiving a registration request from a computing device to create a user account for a user of a diabetes intervention application; retrieving information from a global configuration service that identifies multiple supported areas of the diabetes intervention application based on the information contained in the registration request; and establishing a user account for a user of the diabetes intervention application that includes identification information for one of the multiple supported areas of the diabetes intervention application.

[0015] In the above method, the registration request includes version information of the diabetes intervention application and operating environment information of the computing device and the glucose monitoring device connected to the computing device. In the above method, the information included in the registration request includes identification information of the language used within the diabetes intervention application. In the above method, establishing a user account for a user of the diabetes intervention application includes determining that the identified region does not match the current geographical location of the computing device included in the registration request, and establishing the user account based on one of several supported regions that corresponds to the current geographical location of the computing device instead of the identified region.

[0016] In the above method, a request to start a session on the diabetes intervention application includes version information of the diabetes intervention application. The above method further includes comparing the version information of the diabetes intervention application included in the request with the version information included in the access information, and updating the user account based on the version information included in the request if the comparison between the version information included in the request and the version information included in the user account results in the identification of a mismatch.

[0017] In the method described above, updating a user account based on version information included in a request includes determining that a feature supported by the version of the application corresponding to the version information included in the user account is deprecated in the version of the application corresponding to the version information included in the request, and sending one or more commands to the diabetes intervention application to revert to the version of the application corresponding to the version information included in the user account.

[0018] A particular embodiment provides yet another method used by a computing device to configure a diabetes intervention application running on the computing device via a remote server, the method comprising: sending a request to an authentication service for access to the functionality of the diabetes intervention application, the request including a user certificate for a user of the diabetes intervention application; receiving from the authentication service access information for the diabetes intervention application to use when retrieving configuration information for the diabetes intervention application from a global configuration service, the access information including functionality customization information for the diabetes intervention application; sending a request to the global configuration service for configuration information, the request including the access information; receiving from the global configuration service configuration information, the configuration information including a set of assets on which the diabetes intervention application should be provisioned, at least in part, based on the functionality customization information contained in the access information; and configuring the diabetes intervention application using the configuration information.

[0019] The above method further includes sending a registration request to an authentication service to create a user account for a user of a diabetes intervention application; receiving from the authentication service information identifying multiple supported areas of the diabetes intervention application based on the information contained in the registration request; and sending a request to establish a user account, wherein the request includes identification information for one of the multiple supported areas for the diabetes intervention application.

[0020] In the above method, the registration request includes version information of the diabetes intervention application and operating environment information of the computing device and the glucose monitoring device connected to the computing device. In the above method, the information included in the registration request includes language identification information used within the diabetes intervention application. In the above method, the request to access the functions of the diabetes intervention application includes version information of the diabetes intervention application.

[0021] In the above method, the set of assets includes multiple uniform resource locators (URLs) to be used to configure the diabetes intervention application, the URLs are associated with functional customization information, and the configuration includes configuring the diabetes intervention application to access the assets using the multiple URLs in order to configure and execute the functions of the diabetes intervention application. In the above method, the functional customization information includes location information associated with the geographical location of the user of the diabetes intervention application.

[0022] In the above method, the functional customization information includes version information of the diabetes intervention application running on the computing device. In the above method, the functional customization information includes operating environment information of the computing device and the glucose monitoring device connected to the computing device. In the above method, the set of assets includes one or more functional flags, where one or more functional flags indicate that the functional associated with one or more functional flags is activated for use within the diabetes intervention application, where one or more functional flags are associated with functional customization information, and configuring the diabetes intervention application includes activating the functional associated with one or more functional flags and disabling functionals not associated with one or more functional flags.

[0023] Another embodiment is an apparatus comprising two or more means for carrying out any one of the above methods.

[0024] Another aspect is an apparatus, the apparatus comprising at least one processor and a memory storing code that, when executed by the at least one processor, causes the apparatus to perform any one of the above methods.

[0025] Another aspect is a non - transitory computer - readable medium storing computer - executable code, the non - transitory computer - readable medium including code for performing any one of the above methods. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] [Figure 1A] Illustrate an exemplary glucose monitoring system, including an application configured via a global configuration service (GCS) and an authentication service, according to some embodiments disclosed herein. [Figure 1B] Illustrate in more detail the glucose monitoring system of FIG. 1A, together with some mobile devices, according to some embodiments disclosed herein. [Figure 2] Illustrate an example of a system in which GCS and an authentication service are used to configure a diabetes intervention application, according to some embodiments disclosed herein. [Figure 3] A message flow diagram that illustrates messages exchanged between a diabetes intervention application, an authentication service, and GCS to generate a user certificate for an application configured through GCS, according to some embodiments described herein. [Figure 4] A message flow diagram that illustrates messages exchanged between a diabetes intervention application, an authentication service, and GCS to configure a diabetes intervention application, according to some embodiments described herein. [Figure 5]This flowchart illustrates the actions performed to authenticate a user of a diabetes intervention application configured through a GCS, such as the GCS in Figure 1A, Figure 1B, or Figure 2, according to some embodiments described herein. [Figure 6] This flowchart illustrates the actions performed to initiate and configure a diabetes intervention application running on a user device through GCS and authentication services, according to some embodiments described herein. [Figure 7] This flowchart illustrates the operations performed to constitute a diabetes intervention application through a GCS, such as the GCS shown in Figure 1A, Figure 1B, or Figure 2, according to some embodiments disclosed herein. [Figure 8] This is a block diagram illustrating a computing device configured to perform the operations shown in Figures 5-7 according to a particular embodiment disclosed herein. [Modes for carrying out the invention]

[0027] Detailed description of a particular inventive embodiment Typically, an application (e.g., a mobile application) is deployed on a patient's device (e.g., a mobile device, such as a smartphone or smart wearable device) through an application store that can distribute different versions of the same application based on factors such as user-related location information, cost considerations, and device capabilities. Location information may indicate the location from which the user is accessing the application store (which may not be the user's permanent location) or the user's registered location (e.g., the user's permanent location).

[0028] For example, a safety-critical application may be subject to regulation and approval by one or more regulatory authorities. Since some features may not be approved for use in certain geographical locations, different versions of the application may exist, each containing a set of features approved by the regulatory authority for the specific location where the application is deployed. In another example, cost considerations may motivate the deployment of multiple versions of a software application. One version of a software application may contain a more limited set of features than another, but may be available at a lower cost. By implementing different sets of features in different versions of the application at different end-user costs, users may be able to choose one of several versions of the application and the corresponding features, according to their ability and / or willingness to pay for different sets of features. Yet another example is when different versions of an application are deployed to address different use cases. For example, a diabetes management application may implement different features based on whether the application is used to treat or manage type 1 or type 2 diabetes, and whether the application is used to treat pregnant patients, etc.

[0029] However, maintaining and provisioning different versions of the same application presents many different technical issues and challenges. For example, typically, an application is provisioned by an application provider to users in different locations around the world through an application store. However, because the specifications differ in the different locations where the application is deployed, the application provider may maintain different application binary files ("application binaries") for the same application in the application data store to comply with or conform to the relevant specifications, and provision different application binaries to corresponding users in different locations. Note that various specifications may include location-based and location-independent specifications. Location-based specifications may include regulatory guidelines (e.g., a regulatory body in a particular location may prohibit the use of certain features), user preferences (e.g., research may determine that users in a particular location may dislike certain features), strategic decisions made by application providers (e.g., an application provider may determine that certain features should be provided in one location but not another, or should be provided as an optional feature that users in one location may choose to enable but which is not available to users in another location), and technical limitations (e.g., due to restricted access to the internet in a particular location).

[0030] Location-independent specifications may include specifications relating to user-specific information other than the user's location. For example, a particular feature may be subscription-based regardless of the user's location. In another example, a particular feature may be appropriate based on use cases or goals associated with the app. For example, a use case may relate to the user's health status, with a particular feature being appropriate for treating a particular disease, while other features may be appropriate for other diseases. In yet another example, a use case may relate to the app's goals, such as disease management, health and wellness, diagnosis, or clinical use cases. In yet another example, app content may vary depending on the nature of app use, such as length of use (e.g., limited use, intermittent use, long-term use), primary user (e.g., clinician versus patient), or other use information that may influence the type of features and capabilities provided through the app. In a particular implementation, a particular feature may be made available according to application cost tiers, subscriptions, etc. Furthermore, a particular feature may be made available based on considerations such as user sophistication, preferences, input, or other users or hosted data.

[0031] Typically, each application binary corresponds to a different configuration of the same application, and each configuration corresponds to a unique set of features, feature settings, and / or resources. This unique set of features, feature settings, and resources is hardcoded in each of the different application binaries. To illustrate this with an example, a feature X of an application might be preferred by a user, or approved for use at location A, but not at location B. In such an example, application binary A, which includes feature X, is provided to the user at location A, while application binary B, which may be similar to or identical to application binary A except for the lack of feature X, is provided to the user at location B. Therefore, different application binaries associated with different configurations of an application may be maintained for provisioning to users at different locations. When downloaded and executed on a user's device, each of these different application binaries provides a different configuration of the application. Generally, for each application binary maintained by the application provider, a corresponding codebase is also maintained to allow developers to modify or update the corresponding version of the application. The codebase contains higher-level code written by the developer to create the application.

[0032] However, maintaining different application binaries and corresponding codebases for different configurations of the same application can have major technical drawbacks, including resource inefficiency. Firstly, these application binaries and corresponding codebases can be significantly redundant in content. For example, code associated with some common functionality of an application may be reused for all of a particular different configuration of the application. As a result, storing different application binaries and corresponding codebases for different configurations of the same application means duplication, or common code being stored multiple times, which is memory inefficient. For example, given several n location-specific application binaries (and corresponding codebases), the total amount of code stored for these applications may be n*commonCodebaseSize+locationSpecificCodebaseSize. In other words, for these n location-specific application binaries, the amount of wasted memory space on the memory system where the codebases are maintained may be (n-1)*commonCodebaseSize.

[0033] For applications where the location-specific version shares a significant amount of common code and other assets for location-independent functionality, such as login, core computing and visualization features, and shared graphic assets, this can mean that a considerable amount of storage space and other computing resources may be required to build and maintain the application. Similarly, for application stores, the amount of resources required to make multiple application binaries available for distribution may be significantly greater than the minimum amount of resources that would be required to store an application containing all of the location-specific functionality implemented across multiple application binaries.

[0034] In addition, if certain common code needs to be updated or debugged, developers must propagate the changes to each and all of the codebase, and recompile and deploy each application binary in the codebase. This is computationally inefficient and increases the amount of work that needs to be done to maintain the various configurations for the application. Furthermore, if changes to common code are propagated to only some of the codebase, errors may remain in some application binaries, or some application binaries may remain outdated. Some failures in maintaining application binaries may result in minor issues (or be unresolved), such as inconsistencies in the graphical user interface, but other failures can have more serious consequences. For example, if a security vulnerability is resolved in some application binaries but not in others, the security vulnerability can still be exploited by a malicious actor to steal sensitive data, inject malicious code for execution, or perform other malicious activities. In another example, if a problem with communicating with an external sensor is resolved in some application binaries but not in others, some users of the application may continue to experience connectivity issues, which could cause the application to perform incorrect actions based on incorrect or non-existent data.

[0035] Accordingly, certain embodiments described herein aim to solve the technical problems described above by deploying a single, unified collection of available features, feature settings, and / or resources for an application. Hereinafter, features, feature settings, and / or resources for an application may be referred to as “assets.” In certain embodiments, a collection of assets may be provided as a unified application binary. In some examples, in addition to a collection of assets, a global configuration service (hereinafter, “GCS (global configuration service)”) maintains mappings that map different specifications to different sets of assets within the asset collection. In various embodiments, the GCS uses the mappings to generate configuration information for configuring an application to be downloaded onto a user device by mapping user-associated specifications to a specific subset of assets within the asset collection. In certain embodiments, the configuration information is then used to configure an application on a user device using a specific subset of assets. As used herein, “features” refers to features implemented in an application that can be enabled or disabled based on user-specific configurations. As used herein, “feature settings” refers to various options that modify the functionality of a given feature within an application, such as settings that specify units of measurement or user interface appearance options. As used herein, “Resources” refers to code, graphics files, Uniform Resource Locator (URL) audio files, or other content that may be used by the application while the application is running.

[0036] For example, as will be discussed in more detail herein, when a user requests to download an application from an application store, a single set of assets is downloaded to the user's device, for example, as a unified application binary, regardless of the specifications associated with the user. Such specifications may include the type of device used by the user to download and run the application, the product package associated with the user or the user's specimen monitoring system (e.g., transmitter, sensor, mobile device, receiver, etc.), the set of features subscribed to by the user, the user's type, the user's disease type or progression, the application use case, the region where the user is located, or other user characteristics that may dictate the features, feature settings, or assets to be provided to the user. In one example, when the set of assets is first downloaded to the user's device, the application is not yet configured based on the user-specific specifications. Therefore, the application sends a configuration request to the GCS, which in turn maps the user-specific specifications associated with the user to a set of assets in the set of assets and sends configuration information to the application indicating the mapped set of assets. Using the configuration information, the application configures itself with the corresponding set of assets. For example, an application activates a set of assets indicated by configuration information and deactivates or disables the rest of the assets within the application binary. In one example, an application may automatically configure itself using the functions within the set of assets indicated by configuration information. Furthermore, the application may automatically configure certain settings of those functions as part of its configuration. Additionally, an application may automatically configure resources so that they are accessible to the user according to the configuration information.

[0037] Regardless of user-specific specifications, remembering, maintaining, and provisioning a single, unified application to different users leads to significant resource efficiency. More specifically, when a single application binary and codebase is remembered and maintained, in contrast to many different things with duplicate code, a large amount of memory resources are freed up and can be used for other purposes. In addition, significantly fewer computing resources can be consumed when updating, compiling, and debugging a single application binary and a single codebase, in contrast to many application binaries and codebases. Furthermore, maintaining a single codebase reduces the possibility of introducing errors into the code during code updates, or resolving errors that exist in some, but not all, versions of the application.

[0038] Furthermore, as discussed above, some applications may be safety-critical applications, requiring regulatory approval before features can be made available to users in a given location (for example, to ensure that new features do not harm patients using the software application, or that new features comply with security requirements or best practices). New features in safety-critical applications may be approved faster in some areas than in others. Therefore, when deploying new features in safety-critical applications, developers may choose to deploy different versions of the application, with the version containing the new feature deployed in areas where regulatory approval has been obtained, and the version without the new feature deployed in areas where regulatory approval has not been obtained. If multiple codebases exist for multiple versions of an application, adding new features piecemeal (for example, when features are approved by the relevant regulatory authorities) can introduce additional complexity.

[0039] The availability of multiple versions of an application can also complicate user selection of the appropriate application for installation and use. For example, different versions of an application may use the same (or similar) application icon and thumbnail in the application repository and have the same (or similar) package name. This can lead to user confusion when selecting the appropriate version of an application, such as selecting an inappropriate version of the application (which the user may not discover until they try to use the application) or selecting an application version that is incompatible with one or more user devices.

[0040] An example of an application that may be maintained, provisioned, and configured by GCS according to the embodiments described herein is a diabetes intervention application. In one example, as described herein, a diabetes intervention application delivers guidance that can assist patients, caregivers, healthcare providers, or other users in the management of diabetes. Thus, while certain aspects of an application are described herein as an example with respect to a diabetes intervention application, it should be noted that the techniques described herein are also applicable to other suitable types of applications, including applications that provide health-related information or health-related guidance to users. Diabetes intervention applications, such as those described herein, may deliver guidance on lifestyle or clinical / patient outcomes by addressing a variety of challenges, such as nocturnal glucose control (e.g., reducing the incidence of hypoglycemic events or hyperglycemic deviations), in-meal and post-meal glucose control (e.g., using historical information and trends that increase blood glucose control), hyperglycemia correction (e.g., increasing time in the target zone while avoiding hypoglycemic events due to overcorrection), hypoglycemia treatment (e.g., addressing hypoglycemia while avoiding "rebound" hyperglycemia), exercise, and / or other health factors. In certain embodiments, the application may further comprise an optimization tool that learns the patient's physiological functions and behaviors and calculates guidance to help the patient identify optimal or desirable therapeutic parameters, such as basal insulin requirements, insulin-to-carbohydrate ratio, corrective factors, and / or exercise-induced changes in insulin sensitivity.

[0041] In certain embodiments, the application utilizes input from one or more physiological sensors, such as one or more sample sensors, to provide relevant and effective guidance. Examples of sample sensors described herein are glucose monitoring sensors that measure the concentration of glucose and / or substances indicating the concentration or presence of glucose and / or another sample in the user's body. In some embodiments, the glucose monitoring sensor is a continuous blood glucose monitoring system device, e.g., subcutaneous, transdermal, transocular, and / or intravascular (e.g., intravenous) device. The glucose monitoring sensor can use any method of glucose measurement, including enzyme, chemical, physical, electrochemical, optical, photochemical, fluorescence-based, spectrophotometric, spectroscopy (e.g., optical absorption spectroscopy, Raman spectroscopy, etc.), polarization analysis, calorimetry, iontophoresis, and radiometry.

[0042] Glucose monitoring sensors can use any method, including invasive, minimally invasive, and non-invasive detection techniques, to provide a data stream indicating the concentration of a sample within the host. The data stream typically includes a stream of raw data signals used to provide a useful sample value for patients or healthcare professionals (HCPs, e.g., physicians, internists, nurses, caregivers) who may be using the sensor.

[0043] In some embodiments, the glucose monitoring sensor is an implantable sensor, as described with reference to U.S. Patent No. 6,001,067 and U.S. Patent Publication No. US-2011-0027127-A1. In some embodiments, the glucose monitoring sensor is a transdermal sensor, as described with reference to U.S. Patent Application Publication No. 2006-0020187-A1. In some embodiments, the glucose monitoring sensor is a dual-electrode sample sensor, as described with reference to U.S. Patent Publication No. US-2009-0137887-A1. In some embodiments, the glucose monitoring sensor is configured to be implanted in a host blood vessel or outside the body, as described in U.S. Patent Publication No. US-2007-0027385-A1. These patents and publications are incorporated herein by reference in their entirety.

[0044] While much of the following description and examples are described in relation to diabetes intervention applications, the systems and methods of the embodiments described herein may be used in conjunction with any health-related applications provided to a user to improve the user's health. For example, a health-related application may help a user treat a particular disease or help improve the health of a user who has not necessarily been diagnosed with a disease.

[0045] Exemplary System Figure 1A illustrates an exemplary system 100 for maintaining, provisioning, and configuring application 106, which monitors the symptoms of user 102 (hereinafter referred to as "User"), provides decision support guidance to User, and / or determines or directs the administration of one or more treatments for User. In certain embodiments, User may be a patient or a patient's caregiver, healthcare provider, or other entity that monitors a patient's health parameters. In embodiments described herein, User is assumed to be a patient for the sake of simplification, but is not limited to that. System 100 includes a glucose monitoring system 104, a mobile device 107 running application 106, a decision support engine 112, a user database 110, an authentication service 130, a GCS 140, and a configuration data store 150.

[0046] In certain embodiments, the glucose monitoring system 104 includes a sensor electronics module and a glucose sensor that measures the concentration of blood glucose and / or substances indicating the concentration or presence of glucose and / or other samples in the user's body. In certain embodiments, the glucose sensor is configured to perform measurements continuously. The sensor electronics module transmits the blood glucose measurements to a mobile device 107 for use by application 106. In some embodiments, the sensor electronics module transmits the glucose measurements to the mobile device 107 via a wireless connection (e.g., Bluetooth connection). In certain embodiments, the mobile device 107 is a smartphone. However, in certain embodiments, the mobile device 107 may instead be any other type of computing device, such as a laptop computer, a smartwatch, a tablet, or any other computing device capable of running application 106.

[0047] While System 100 illustrates a glucose monitoring system 104, it should be recognized that the embodiments described herein are similarly applicable to any other type of physiological monitoring system that may be used as part of System 100 to monitor and / or treat a patient. Exemplary physiological monitoring systems may include electrical or optical heart rate monitoring systems, pulse oxygen metering systems, temperature monitors, blood pressure monitors, moisture monitors, and various sample sensors (e.g., lactate sensors, ketone sensors, etc.). Furthermore, it should be recognized that the glucose monitoring system 104 or any other physiological monitoring system may include one or more sensors providing input to such a system.

[0048] In certain embodiments, the decision support engine 112 refers to a set of software instructions having one or more software modules. In some embodiments, the decision support engine 112 runs entirely on one or more computing devices in a private or public cloud. In such embodiments, the application 106 communicates with the decision support engine 112 over a network (e.g., the internet). In some other embodiments, the decision support engine 112 runs partially on one or more local devices, such as a mobile device 107, and partially on one or more computing devices in a private or public cloud. In some other embodiments, the decision support engine 112 runs entirely on one or more local devices, such as a mobile device 107.

[0049] In a particular embodiment, the decision support engine 112 is configured to process a set of inputs received from the application 106 and calculate a number of indices 128, which may then be stored in the user profile 116. The inputs 127 and indices 128 may be used by the application 106, for example, by different functions of the application 106, to provide the user with real-time guidance and treatment. Various data points of the user profile 116 are described in more detail below. In a particular embodiment, the user profile, including the user profile 116, is stored in a user database 110, which is accessible to the application 106 and the decision support engine 112 via one or more networks (not shown). In some embodiments, the user database 110 refers to a storage server that may operate in a public or private cloud.

[0050] Real-time guidance and treatment provided to the user helps improve the user's physiological state and / or enables the user to make more informed decisions. In certain embodiments, in order to provide the user with effective, relevant, and timely guidance and treatment, the functionality of application 106 may take as input information about the user stored in the user profile 116 and / or information about a pool of similar users stored in the user profile of such a user in the user database 110. In certain embodiments, the functionality of application 106 may interact with the user through various methods such as text, email, notifications (e.g., push notifications), telephone, and / or other forms of communication such as displaying content (e.g., graphs, trends, charts, etc.) on the user interface of application 106.

[0051] As shown in Figure 1A, application 106 is uniquely configured in a particular configuration, which is logically represented as application configuration 108. Application configuration 108 corresponds to a set of functions 109 and resources 111 that are active and available for use by users of application 106. In a particular embodiment, each of the functions 109 is configured to monitor the symptoms of user 102, provide decision-making support guidance to the user, and / or determine / administer one or more treatments for the user. As shown, functions (e.g., functions 1 and 2) may also have settings that define the operation of the functions. In a particular embodiment, changing the settings of a function may result in changing how the function operates, such as how the function provides guidance and interacts with the user. For example, changing the settings of a function may, among other things, result in changing the unit of measurement for the function to calculate and display information to the user (e.g., pounds versus kilograms). Resources 111 may also include uniform resource locators (URLs) that point to remote resources and other types of resources.

[0052] Features 109 and Resource 111 represent a subset of a larger set of assets. The larger set of assets represents all features, feature settings, and / or resources contained in the binary file of application 106 and / or provisioned through GCS140. In the example in Figure 1A, the remaining assets (of the larger set of assets) are deactivated (e.g., not configured) for application 106. In other words, users of application 106 cannot access or use the remaining assets of application 106. Some exemplary features, though not limited to this list, may include one or more of the following: objective setting and identification features, reward features, reporting features, behavioral intervention features, exercise management features, medication reminder features, blood glucose effect estimator features, educational features, onboarding features, application logging features, etc.

[0053] As will be described in more detail below, application 106 is configured using application configuration 108 based on configuration information received from GCS 140 (and retrieved from configuration data store 150) after application 106 has been downloaded by the user onto the mobile device 107. Generally, application 106 can start from a non-started state (e.g., the first launch after the user has downloaded the application binary of application 106, after a session has timed out, etc.). From this non-started state, application 106 may present a login screen to the user of application 106. If the user has account certificates that allow the user to use and access the functions within application 106, the user may enter those certificates on the login screen and submit the certificates to authentication service 130 in order to authenticate the user and start an active session within the application. Otherwise, as will be discussed in more detail below, the user may require authentication service 130 that the user create credentials that will allow the user to use application 106.

[0054] The authentication service 130 generally authenticates or verifies the user using user identification information and provides application 106 with access information that application 106 can use to retrieve configuration information from GCS 140. In some embodiments, the authentication service 130 verifies the user certificate (e.g., user ID and password / passkey) provided by the user through the login screen of application 106, and if the user certificate is verified to belong to an active account, the authentication service 130 generates and returns access information for application 106 for use in configuring application 106 through GCS 140. Generally, the access information generated by the authentication service 130 includes user identification-related information (e.g., information indicating that the user has been authenticated by the authentication service 130, such as a cryptographic hash or magic number) and functional customization information. In some embodiments, the access information returned by the authentication service 130 may include or be structured as an access token.

[0055] Functional customization information may indicate user specifications and may include, for example, version information of application 106, user location information (which may be determined based on user specifications of the user's location or based on location information obtained from mobile device 107), type of user or user disease, operating environment information of mobile device 107, type of mobile device 107, user subscription layer, information about application 106 and / or glucose monitoring system 104, various device and / or sensor codes associated with the user, and other information that may be used to uniquely identify the user and help identify an application configuration 108 suitable for the user. In some embodiments in which access information is received in the form of an access token, the access token may also include information that may be used to verify that the token is authentic (e.g., that it was legitimately generated by an authentication service 130 and not generated by a fake service). For example, the access token may include a validity period, after which application 106 may require user 102 to re-authenticate with the authentication service 130 in order to continue using application 106 or cryptographic information used to authenticate the token.

[0056] After receiving access information from the authentication service 130, application 106 may request application configuration 108 for the user of application 106 from GCS 140. Generally, the request for configuration information includes access information (e.g., access token) received from the authentication service 130. GCS 140 can determine whether the access token is valid. If the access information is determined to be valid, GCS 140 can generate and send configuration information for application 106 so that application 106 can be configured with assets that are enabled for the user based on the function customization information. The configuration information may include, for example, flags corresponding to various functions and / or function settings of application 106, or resource identifiers (e.g., uniform resource locators (URLs) pointing to remote resources that implement the activated functions). The configuration information may be generated by GCS 140 based on configuration rules and other information stored in the configuration data store 150, for example. These configuration rules, previously referred to as mappings, map user-associated feature customization information to a set of assets (i.e., various features and / or feature settings of application 106, resource identifiers, etc.). In other words, GCS140 uses configuration rules to map user-associated feature customization information to a set of assets, and then generates configuration information that indicates the mapped set of assets.

[0057] Application 106 then configures the application by using the received configuration information to activate various functions and / or function settings and pointing to remote resources identified within the application configuration information. Application 106 may then be ready to be used to monitor the user's blood glucose measurements and take various actions in response to the user's blood glucose measurements by acquiring data from the glucose monitoring system 104 and / or other resources (e.g., an accelerometer or location information device in or connected to the mobile device 107, data input from the mobile device 107, etc.).

[0058] In some embodiments, if the user does not have a certificate that would allow them to use application 106, application 106 directs the user to a certificate creation workflow provided by authentication service 130. Authentication service 130 may require the user to provide contact information and information identifying the location associated with the user, which may be manually entered or determined based on a location information device integrated into or otherwise connected to the mobile device 107 (e.g., satellite positioning systems such as NAVSTAR GPS, GLONASS, or GALILEO, IP address location acquisition, etc.). Authentication service 130 may then authenticate the user's contact information and, depending on the authentication, proceed to generate an account certificate for the user.

[0059] When generating a user account certificate, the authentication service 130 may retrieve a list of supported locations from the GCS 140 (or an associated data store, such as the configuration data store 150) and display the list of supported locations to the user for selection. In some embodiments, the authentication service 130 may automatically select a location from the list of supported locations based on user-provided information that identifies a location associated with the user (as considered above), or based on one or more location pieces or the location of the mobile device 107 determined based on an identification device or service within or connected to the mobile device 107. However, the automatically selected location may be invalidated by the user selecting another location from the supported locations. In some embodiments, the authentication service 130 may determine that the determined location of the user's mobile device 107 does not match the user-provided location information. In such cases, the authentication service 130 may invalidate the user-provided location information at the determined location of the user's mobile device 107 and proceed with establishing the user account based on the determined location of the user's mobile device 107. After creating an appropriate certificate (for example, username, password, location, and other information that may be requested by the authentication service 130), the authentication service 130 can create an account containing the created certificate for the user and generate an access token that should be used by application 106 to configure the user's application, as considered above.

[0060] As can be considered, the GCS140 is generally configured to receive a request to configure application 106 and to provide the requesting device with configuration information generated based on access information, such as an access token, contained in the received request. Upon receiving access information from application 106, the GCS140 can attempt to verify the access information. In some embodiments, the access information may be encrypted using an encryption key known to the authentication service 130 and the GCS140. Thus, if the GCS140 is unable to decrypt the access information (e.g., by attempting to decrypt the token and then recovering meaningless information), the GCS140 can determine that the access information is invalid and the configuration of application 106 may be terminated. In other embodiments, the access information may include a legitimacy identifier that the GCS140 can use to authenticate the access information. The legitimacy identifier may be data that the GCS140 can derive from other information in the access information, or it may be information that the GCS140 can use to request verification of the access information from the authentication service 130. However, it should be noted that various techniques may be used to determine the legitimacy of the access information and, accordingly, whether application 106 can be configured for the user.

[0061] If GCS140 determines that the received access information is indeed legitimate, the configuration service can use the received access information to generate configuration information for use when configuring application 106. For example, GCS140 can use some or all of the feature customization information contained in the received access information, such as location information (e.g., location information associated with the user), version information of application 106 from which the configuration request was received, information about the operating environment in which application 106 is being used (e.g., information about sensors used to generate data analyzed by application 106, the operating system of the mobile device 107 on which application 106 is being used, the type of mobile device 107, etc.), and / or other information, to identify configuration options to activate and / or deactivate for the user. The configuration information may include flag settings that identify which flags corresponding to features and / or feature settings within application 106 to activate or deactivate, information that identifies the locations of remote resources that application 106 can use, and other information that constitutes the operation of application 106.

[0062] In some embodiments, GCS140 can perform various actions on a user's account using the version information contained in the access information and the version information of application 106 from which the configuration request was received. For example, if GCS140 determines that there is a mismatch between the version information contained in the access information and the version information of application 106, GCS140 can update the user account to reflect that the user is using a newer (or different) version of application 106. In another example, GCS140 can use the version information contained in the access information and the version information of application 106 to determine whether a feature in the version of application 106 specified in the access token is deprecated in the version of application 106 from which the configuration request was received. If the feature is deprecated in the version of application 106 from which the configuration request was received, GCS140 can send an instruction to application 106 to revert to a previous version of the application from which the feature is not deprecated. For example, GCS140 can instruct application 106 to revert to the version of the application identified in the access token.

[0063] As described above, in certain embodiments, application 106 is configured to receive information about the user as input and store that information in the user's user profile 116. For example, application 106 may acquire the user's demographic information 118, disease progression information 120, and / or medication information 122 and record it in the user profile 116. In certain embodiments, demographic information 118 may include one or more of the user's age, BMI (body mass index), ethnicity, and sex. In certain embodiments, disease progression information 120 may include information about the user's disease, such as whether the user has type 1, type 2, or prediabetes, or whether the user has gestational diabetes. In certain embodiments, information about the user's disease may also include the length of time since diagnosis, the level of diabetes management, the level of adherence to diabetes management therapy, predicted pancreatic function, and / or other types of diagnoses (e.g., heart disease, obesity), or measures of health (e.g., heart rate, exercise, stress, sleep, etc.). In a particular embodiment, the drug information 122 may include information regarding the amount and type of insulin or non-insulin-based diabetes medication and / or non-diabetic medication taken by the user.

[0064] In certain embodiments, application 106 may obtain demographic information 118, disease progression information 120, and / or drug information 122 from the user or from other sources in the form of user input. In certain embodiments, if any part of this information changes, application 106 may receive updates from the user or other sources. In certain embodiments, user profiles, including user profile 116, are stored in a user database 110, which is accessible to application 106 and the decision support engine 112 via one or more networks (not shown). In some embodiments, the user database 110 refers to a storage server that may operate in a public or private cloud.

[0065] In certain embodiments, in addition to user demographic information 118, disease progression information 120, disease type, and / or drug information 122, application 106 acquires an additional set of inputs 127, which are also utilized by function 109 to provide output to the user. In certain embodiments, such inputs 127 are acquired on a sequential basis. In certain embodiments, application 108 receives inputs 127 through user input, as well as through a plurality of other sources including glucose monitoring system 104, other applications running on mobile device 107, and / or one or more other sensors and devices. These inputs may include, for example, device identification information (e.g., a serial number that can be mapped to a unique device model), sensor identification information, firmware version information of a connected device or sensor, etc. In certain embodiments, such sensors and devices include, but are not limited to, one or more of the following: an insulin pump, other types of sample sensors, sensors or devices provided by a mobile device 107 (e.g., an accelerometer, a camera, a global positioning system (GPS), a heart rate monitor, etc.), or other user accessories (e.g., a smartwatch), or any other sensors or devices that provide relevant information about the user.

[0066] In certain embodiments, application 106 further uses at least a portion of input 127 to obtain a plurality of metrics 128, such as behavioral metrics or outcome metrics. As further illustrated in relation to Figure 2, in some embodiments, application 106 sends at least a portion of input 127 to decision support engine 112 for processing, and based thereon, decision support engine 112 generates a plurality of metrics. In certain embodiments, the metrics 128 may then be used by application 106 as input to function 109 to provide output to the user. In certain embodiments, the metrics 128 are also stored in user profile 116, which may be stored for future analysis, used to adapt application configuration 108, and so on.

[0067] In certain embodiments, metric 128 may include behavioral data that can indicate user behavior and habits, such as one or more of the following: user behavior or interaction with the application, user behavior regarding disease treatment, health-related behaviors, etc. Behavioral metrics may include real-time metrics, historical metrics, and / or trends. Outcome metrics may, in some cases, generally indicate one or more of the following: user health or state, e.g., user physiological or psychological state (e.g., stress level, well-being, etc.), trends associated with user health or state, distance to the user achieving their goals based on user health or state. In certain embodiments, outcome metrics may be directly correlated with behavioral metrics, meaning that outcome metrics may be the result of user behavior or behavioral patterns. Examples of outcome metrics include one or more of the following: metabolic rate, glucose levels and trends, user health or illness, etc. In certain embodiments, outcome metrics may include real-time metrics, historical metrics, and / or trends.

[0068] Figure 1B illustrates the glucose monitoring system 104 in more detail. Figure 1B also illustrates several mobile devices 107a, 107b, 107c, and 107d. Note that mobile device 107 in Figure 1A may be any one of mobile devices 107a, 107b, 107c, or 107d. In other words, any one of mobile devices 107a, 107b, 107c, or 107d may be configured to run application 106. The glucose monitoring system 104 may be communicatively coupled to mobile devices 107a, 107b, 107c, and / or 107d.

[0069] As an overview and example, the glucose monitoring system 104 may be implemented as an encapsulated microcontroller, which performs sensor measurements, generates sample data (e.g., by calculating values ​​for continuous blood glucose monitoring system data), and engages in wireless communication (e.g., via Bluetooth and / or other wireless protocols) to transmit such data to remote devices such as mobile devices 107a, 107b, 107c, and / or 107d. Paragraphs

[0137] to

[0140] of U.S. Patent Application Publication 2019 / 0336053 and Figures 3A, 3B, and 4 further describe a skin sensor assembly that may be used in connection with the glucose monitoring system 104 in a particular embodiment. Paragraphs

[0137] to

[0140] of U.S. Patent Application Publication 2019 / 0336053 and Figures 3A, 3B, and 4 are incorporated herein by reference.

[0070] In a particular embodiment, the glucose monitoring system 104 includes a sample sensor electronic module 138 and a glucose sensor 139 associated with the sample sensor electronic module 138. In a particular embodiment, the sample sensor electronic module 138 includes electronic circuits related to the measurement and processing of sample sensor data or information, including algorithms related to the processing and / or calibration of sample sensor data / information. The sample sensor electronic module 138 may be physically / mechanically connected to the glucose sensor 139 and may be integrated with the glucose sensor 139 (i.e., permanently mounted) or may be mountable in a removable manner.

[0071] The sample sensor electronics module 138 may also be electrically coupled to the glucose sensor 139 so that its components can be electromechanically coupled to one another. The sample sensor electronics module 138 may include hardware, firmware, and / or software that enable the measurement and / or estimation of the sample level in the user via the glucose sensor 139 (which may be / may include a glucose sensor). For example, the sample sensor electronics module 138 may include one or more constant-potential devices, a power supply for providing power to the glucose sensor 139, other components useful for signal processing and data storage, and a telemetry module for transmitting data from the sensor electronics module to one or more display devices. The electronics can be mounted on a printed circuit board (PCB) or platform within the glucose monitoring system 104 and can take various forms. For example, the electronics can take the form of an integrated circuit (IC), such as an Application-Specific Integrated Circuit (ASIC), a microcontroller, a processor, and / or a state machine.

[0072] The sample sensor electronics module 138 may include sensor electronics configured to process sensor information such as sensor data and generate converted sensor data and displayable sensor information. Examples of systems and methods for processing sensor sample data are described herein and in more detail in U.S. Patents Nos. 7,310,544 and 6,931,327, and U.S. Patent Publications Nos. 2005 / 0043598, 2007 / 0032706, 2007 / 0016381, 2008 / 0033254, 2005 / 0203360, 2005 / 0154271, 2005 / 0192557, 2006 / 0222566, 2007 / 0203966, and 2007 / 0208245, all of which are incorporated herein by reference as a whole.

[0073] The glucose sensor 139 is configured to measure the concentration or level of a sample within the user 102. The term "sample" is further defined by paragraph

[0117] of U.S. Patent Application Publication 2019 / 0336053, which is incorporated herein by reference. In some embodiments, the glucose sensor 139 includes a continuous glucose sensor such as a subcutaneous, transdermal (e.g., transdermal) or intravascular device. In some embodiments, the glucose sensor 139 can analyze multiple intermittent biological samples. The glucose sensor 139 can use any glucose measurement method, such as enzymatic, chemical, physical, electrochemical, spectrophotometric, polarimetric, calorimetry, iontophoresis, radiometric, or immunochemical methods. Additional details relating to the continuous glucose sensor are provided in paragraphs

[0072] -

[0076] of U.S. Patent Application 13 / 827,577. Paragraphs

[0072] to

[0076] of U.S. Patent Application No. 13 / 827,577 are incorporated herein by reference.

[0074] Referring further to Figure 1B, mobile devices 107a, 107b, 107c, and / or 107d may be configured to display (and / or warn) displayable sensor information that can be transmitted by the sensor electronics module 138 (e.g., in customized data packages transmitted to the display device based on each preference). Each of the mobile devices 107a, 107b, 107c, and / or 107d may include, respectively, touchscreen displays 109a, 109b, 109c, and / or 109d for displaying a graphical user interface of application 106 for presenting sensor information and / or sample data to user 102 and / or receiving input from user 102. In certain embodiments, the mobile device may include other types of user interfaces, such as a voice user interface, instead of, or in addition to, the touchscreen displays for communicating sensor information to user 102 of the mobile device and / or receiving user input. In certain embodiments, one, some, or all of the mobile devices 107a, 107b, 107c, and / or 107d may be configured to display or otherwise communicate sensor information when communicated from the sensor electronics module 138 (for example, within data packages sent to each display device) without any additional expected processing required for calibration and / or real-time display of sensor data.

[0075] The multiple mobile devices 107a, 107b, 107c, and / or 107d depicted in Figure 1B may include a custom or proprietary display device, such as a sample display device 107b specifically designed to display a certain type of displayable sensor information (e.g., numerical values ​​and / or arrows in a particular embodiment) associated with sample data received from a sensor electronics module 138. In a particular embodiment, one of the multiple mobile devices 107a, 107b, 107c, and / or 107d may include a smartphone, such as a mobile phone 107c based on another operating system, such as Android, iOS, or configured to display a graphical representation of continuous sensor data (e.g., including current and / or historical data).

[0076] Figure 2 illustrates an example of a computing system 200 in which a GCS 140 and an authentication service 130 are used to configure an application 106 (e.g., a diabetes intervention application) according to some embodiments disclosed herein. As illustrated, the computing system 200 includes a mobile device 107, an authentication service 130, a GCS 140, and a configuration data store 150.

[0077] The authentication service 130 generally represents a service that can create certificates for users of application 106 to use application 106 and request access to application 106. As illustrated, the authentication service 130 includes an account generator 212 and a certificate checker 214.

[0078] The account generator 212 is configured to generate a user certificate in response to a request from application 106 to create a user account. In some embodiments, the request may include contact information about the user and other information that may be used to verify the user and the user's contact information. Upon receiving a request to create an account, the account generator 212 may provide information about supported locations for application 106 as part of the process to complete user registration and certificate generation for the user. Once the certificate generation process is complete, the account generator 212 may store the user's account information in a data store (not shown) for later use when authenticating the user of application 106.

[0079] Figure 3 is a message flow diagram 300 illustrating an example of messages exchanged between application 106, authentication service 130 (more specifically, account generator 212), and GCS 140 to generate a user certificate for an application configured through GCS, according to some embodiments described herein.

[0080] As illustrated, in order to generate a user certificate for a diabetes intervention application, the application can load an account creation widget (302). When loading the account creation widget, the application can provide information about the application version to the authentication service 130, which can then send a request from the GCS 140 for a list of supported locations (e.g., countries) for the application version (304). Accordingly, the GCS 140 provides the authentication service 130 with a list of supported countries (306), and the authentication service 130 can provision the list of supported countries received from the GCS into the location selector in the account creation widget. After receiving the list of supported countries, the application 106 completes loading the account creation widget (308).

[0081] After receiving user input 310 which includes at least user contact information and a selection of one of the supported countries, application 106 sends a request 312 to authentication service 130 to create a user account with the user input. Authentication service 130 verifies the user contact information (314) and sends the user a message containing a link to complete user registration, for example, within or outside the application (316). Furthermore, once verified, authentication service may have user information stored in user data store, which authentication service can then access to process login requests and generate access information, such as an access token, which the application can use to request configuration information from GCS, as considered herein.

[0082] The certificate checker 214 is generally configured to check the user's certificate and provide application 106 with access information (e.g., an access token) to use when requesting configuration information from GCS 140. As illustrated, the certificate checker 214 may receive a login request from application 106, which initiates the process of authenticating the user of application 106 and generating access information for the user. The login request may include a username and password (or other access code) generated when the user created the user account and associated user certificate through the account generator 212, as considered above. If the username and password (or other access code) match an entry in the user account repository, the certificate checker 214 can determine that the login request was a legitimate login request and generate access information about the user. The generated access information generally indicates that the user can legitimately log in to the user account and start a session in application 106. In some embodiments, the access information may have a timeout period, after which the user may be required to provide their certificate to the certificate checker 214 again in order to generate a new set of access information or to update an already issued set of access information.

[0083] The certificate checker 214 can generate access information for a user based on various user specifications that may be stored in the user account repository or received from application 106 (for example, in a login request received from application 106). For example, the certificate checker 214 can generate access information that includes functional customization information. This functional customization information can be generated based on various user specifications, such as user identification information and attributes (e.g., user-provided region information indicating the country in which the user resides, user illness, user preferences, user type, etc.), information about the mobile device 107 and the version of application 106 running on mobile device 107 (e.g., primary version number, build number, or other information identifying the specific version of application 106 from which the login request was received), information about the operating environment in which application 106 is running, information about one or more sensors used by the user (e.g., glucose sensor system 104), and other information that may be used by GCS 140 to configure application 106.

[0084] In some embodiments, the certificate checker 214 may encrypt the access information using a cryptographic key (or set of cryptographic keys) known to the authentication service 130 and GCS 140, enabling the configuration service to verify the access information. In some embodiments, the certificate checker 214 may generate other information that can be used to check the access information, such as a cryptographic hash generated based on the access information (e.g., carried within the access token), and include the generated information in the access information for use by the configuration service 220 when checking the access information. For example, the certificate checker 214 may concatenate a username, a timestamp associated with the login request (e.g., the time the login request was received, an expiration date calculated from the time the login request was received, etc.), and location information associated with the user, and generate a check code based on the cryptographic hash of the concatenated username, timestamp, and location information. However, it should be recognized that this is only an example of generated information that the certificate checker 214 may generate for use when verifying the access information, and other information and other techniques may be used to generate data for use when verifying the access information.

[0085] Generally speaking, GCS140 represents a service in which application 106 is configured based on access information provided by authentication service 130. As illustrated, GCS140 includes application configurator 222.

[0086] The application configurator 222 generates configuration information for application 106 based on the received configuration request and received access information. The configuration request may be received, for example, after the application is launched or updated on the mobile device 107. To configure application 106, the application configurator 222 can first determine whether the configuration request is valid based on whether the access information is valid. For example, if the access information is received as an access token, the application configurator 222 can determine whether the received access token is a valid access token by attempting to decrypt the access token using a predefined cryptographic key (or set of cryptographic keys).

[0087] Since only the correct encryption key (or set of encryption keys) allows for the extraction of understandable data from encrypted data, the application configurator 222 can determine whether an access token is legitimate by attempting to decrypt the access token and determining whether the decrypted access token contains understandable data. Determining whether the decrypted access token contains understandable data may include, for example, searching for one or more defined strings within the decrypted access token or identifying a special value within the decrypted access token. If the application configurator 222 determines that it has successfully decrypted the access token, it can proceed to generate configuration information for use by application 106, as will be discussed in more detail below. Otherwise, the application configurator 222 may send an error message to application 106 indicating that the verification of the access token failed.

[0088] In another example, the application configurator 222 can determine whether the access information is legitimate by attempting to match the authentication code contained in the access information with a version of the authentication code generated from the data contained in the access information. In such a case, the application configurator 222 may be configured to generate the authentication code using the same technique (e.g., the same algorithm) used by the certificate checker 214 to generate the authentication code, as considered above. If the authentication code contained in the received access information matches the version of the authentication code generated by the application configurator 222, the application configurator 222 can determine that the access information is legitimate and proceed to generate configuration information for use by application 106. Otherwise, the application configurator 222 can send an error message to application 106 indicating that the verification of the access information failed.

[0089] To generate configuration information for application 106, application configurator 222 can retrieve information from configuration data store 150 and use the function customization information contained in the access information to identify assets that should be enabled for users of application 106. For example, if the function customization information includes user location information, application configurator 222 can search the configuration data store 150 for configuration rules or mappings that identify supported assets for users located at the location associated with the user who received the configuration request and access token. These configuration rules may indicate not only resource information pointing to resources that application 106 should access during execution, but also which flags should be enabled or indicated as enabled in the configuration information. As an example, a configuration rule may indicate that for a user in Germany, function X may be activated, but function Y may be deactivated. In such an example, the configuration information generated for the user by application configurator 222 would include a flag indicating that function X should be activated for the user.

[0090] Flags or other information for enabling assets within Application 106 may include flags indicating functions and function settings. For example, a flag may indicate that the exercise management function should be enabled for the user. In another example, a flag may indicate that a specific function setting of the exercise management function should be enabled. In yet another example, a flag may indicate whether a function setting such as units of measurement should be set to metric or imperial. For example, a first value of the units of measurement flag may indicate that Application 106 or a specific function of Application 106 interprets sensor data and generates measurements based on the metric system, and a second value of the units of measurement flag may indicate that Application 106 or a specific function of Application 106 interprets sensor data and generates measurements based on the imperial system.

[0091] In another example, flags may be used to identify how data should be encrypted for transmission from application 106 to other external systems, such as the decision support engine 112 or user database 110 illustrated in Figures 1A and 1B. For example, one value of the encryption flag may indicate that the data should be transmitted in plaintext; a second value of the encryption flag may indicate that the data should be transmitted using a first form of encryption (e.g., a first set of keys associated with a first geographical area, a first encryption scheme, etc.); a third value of the encryption flag may indicate that the data should be transmitted using a second form of encryption (e.g., a second set of keys associated with a second geographical area, a second encryption scheme, etc.); and so on. In yet another example, flags or other information may be set in the configuration information to control the periodicity at which application 106 invokes various functions exposed by remote resources. Different values ​​of the flags, or different flag settings, may indicate different periodicities at which data should be reported or functions exposed by remote resources should be invoked by application 106.

[0092] In yet another example, flags can be used to identify the configuration of an onboard function configured to provide a set of onboard commands. For example, an onboard function may have various sensor placement settings to provide the user with different sensor placement commands. Which setting is selected by the application configurator 220 and indicated by a flag in the configuration information may be based, for example, on the user's location or other types of function customization information. For example, if the function customization information indicates that the user is at location X, the application configurator 222 may generate configuration information that includes a flag indicating a first setting for the application corresponding to location X. The first setting may then configure application 106 to provide the user with a command to attach a sensor to the user's arm. In another example, if the user is at location Y, a second setting corresponding to location Y may configure application 106 to provide the user with a command to attach a sensor to either their arm or abdomen.

[0093] In another example, flags can be used to identify the settings for the application logging function to log application events. Examples of application events include application exceptions, major events (e.g., startup, shutdown, restart, and security events), error event notifications, debugging information, SQL logs, and warnings about insufficient disk space. The logging function may have various logging settings corresponding to different levels of logging. For example, the first setting may correspond to a high logging level, and the second setting to a low logging level. Which setting the application configurator 222 selects for a particular user may depend on user-associated feature customization information, which may indicate the user's location, the application version of application 106, the operating system of the user's mobile device, etc. For example, if users at location X report many technical problems, when new users at location X download application 106, the application configurator 222 may configure the application for those users using the first setting so that more application events can be captured and analyzed by the technical team responsible for maintaining the application. However, the second setting, corresponding to a lower logging level, may be used for users at locations where fewer technical problems are reported.

[0094] Flags can be used to indicate the enablement or disablement of many different functions and function settings. In addition to the exemplary functions and function settings provided above, some other exemplary functions include alert functions, Bluetooth® communication functions, security functions, time provider functions, secure networking application programming interface (API), and bulk data functions (associated with how data is transmitted in bulk from sensor system 104 to application 106).

[0095] Configuration information may be generated as a structured file that can be parsed by application 106. For example, configuration information may be generated as an eXtensible Markup Language (XML) file, a JavaScript Object Notation (JSON) message, a graph data structure, or other parsable data that application 106 can use to identify which assets should be activated in application 106 (e.g., which functions should be activated within application 106 and which resources application 106 should communicate with). In some embodiments, configuration information may be encrypted before transmission to application 106 using an encryption key associated with the GCS 140 and / or the user of application 106 to protect the cryptographic information from modification during transmission from application configurator 222 to application 106.

[0096] Figure 4 is a message flow diagram 400 illustrating an example of messages exchanged between an application (such as application 106 illustrated in Figures 1A and 2), an authentication service (such as authentication service 130 illustrated in Figures 1A and 2), and a GCS (such as GCS 140 illustrated in Figures 1A and 2) to configure an application via GCS, according to some embodiments described herein.

[0097] As illustrated, application 106 may begin by loading a login widget in which the user provides a user certificate to which the user should be authenticated by authentication service 130 402. After the user provides the user certificate 404 and submits the certificate in a login request via the login widget 406, authentication service 130 verifies the user certificate included in the login request 406 408. If the user certificate corresponds to an existing user account, authentication service 130 may generate and issue an access token 410 (or access information in a form other than a token) that application 106 can use to request application configuration via GCS 140. Otherwise, authentication service 130 may generate an error message (not shown) that indicates the user certificate was invalid and which application 106 can use to request the input of another set of user certificates.

[0098] After receiving an access token from the authentication service 130, application 106 can request configuration information from the GCS 140 by sending a request 412 for a URL (or identification information of a remote resource to which application 106 is provisioned) to the GCS 140. Generally, the request 412 for a URL includes the access token 410 provided by the authentication service 130 and offered to application 106. Accordingly, the GCS 140 verifies the token, and if it determines that the token is valid, it sends a URL configuration information response 414 containing a URL (or other identification information of a remote resource) to which the diabetes intervention application is permitted to communicate, based at least on the location information contained in the access token. Similarly, application 106 can request configuration information from the GCS 140 by sending an asset request 416 for information identifying application assets to be enabled for the user. This request also includes the access token provided by the authentication service. Accordingly, GCS140 verifies the token, and if it determines that the token is valid, it sends an asset configuration response 418 containing various flags corresponding to assets to be activated or deactivated for the user. The values ​​of the flags corresponding to assets to be activated for the user may be set based on mapping information (e.g., configuration rules) that identifies assets to be enabled for the user's location, and / or mapping information that identifies optional assets enabled by the user. Note that in certain embodiments, a set of features and feature settings (associated with the application downloaded by the user) corresponds to core features and feature settings. In certain embodiments, these core features and feature settings may be enabled for all users, regardless of what the user specification and feature customization information indicates. Therefore, in such embodiments, the configuration information may not include any flags corresponding to core features and feature settings.

[0099] Figure 5 illustrates exemplary operations 500 that may be performed by an authentication service (such as the authentication service 130 illustrated in Figures 1A and 2) to authenticate a user of a diabetes intervention application (such as application 106 illustrated in Figures 1A and 2) configured via a GCS (such as GCS 140 illustrated in Figures 1A and 2), according to some embodiments disclosed herein.

[0100] As illustrated, operation 500 begins in block 510, when the authentication service receives a request from the diabetes intervention application to initiate a session on the diabetes intervention application. The request generally includes a user certificate for a user account associated with a user of the diabetes intervention application.

[0101] In block 520, the authentication service verifies that the user certificate is valid for the user account. Verifying the user certificate generally involves determining, at a minimum, whether the provided username and password match the certificate in the records within the user database. In some embodiments, multi-factor authentication may be used to verify that the user certificate is valid for the user account, and additional information, such as user biometric information or a one-time authentication code, may also be verified.

[0102] In block 530, the authentication service generates access information for the diabetes intervention application for use when retrieving configuration information for the diabetes intervention application from GCS. The access information is generated based on verifying that the user certificate is valid for the user account.

[0103] In block 540, the authentication service transmits access information to the diabetes intervention application. In some embodiments, the access information may be transmitted via an encrypted channel so that the access information is protected from modification during transit between the authentication service and the mobile device on which the diabetes intervention application is running.

[0104] Figure 6 illustrates exemplary operations 600 that can be performed by a diabetes intervention application 106 illustrated in Figures 1A and 2 to constitute an application via the GCS 140 illustrated in Figures 1A and 2, according to some embodiments described herein.

[0105] As illustrated, operation 600 begins in block 610, in which the application sends a request to the authentication service to access assets associated with or within the diabetes intervention application. The request generally includes a user certificate for a user of the diabetes intervention application. The user certificate generally includes a username and password or access code and may optionally include other information used in multi-factor authentication, such as a biometric code or one-time code provided by the authentication service.

[0106] In block 620, the application receives access information from the authentication service. The access information may be used by the diabetes intervention application to request configuration information from the GCS and may include information associated with the user. In some embodiments, the access information may be encrypted using an encryption key known to the authentication service and the GCS, and the application can pass the access information to the GCS without decrypting it.

[0107] In block 630, the application sends a request for configuration information to GCS. The request generally includes access information received from the authentication service, which GCS uses to determine whether the request is genuine (as discussed above).

[0108] In block 640, the application receives configuration information from GCS. This configuration information generally includes information identifying the set of assets for which the diabetes intervention application should be provisioned. As will be considered, in one illustrative and non-limiting example, the set of assets may be determined at least in part based on location information contained in the access token. Thus, the diabetes intervention application may be provisioned with assets appropriate to the geographic location associated with the application's user, and may not be provisioned with assets not supported in the geographic location associated with the application's user.

[0109] In block 650, the application is configured based on the configuration application. For example, the diabetes intervention application can analyze the configuration information to identify which functions and function settings to activate or deactivate, and identify remote resources (e.g., URLs) that the diabetes intervention application is permitted to communicate with. Once configured, the activated functions and user interface functions, aspects, pages, etc. associated with the identified remote resources can be provided and displayed to the user by the diabetes intervention application (e.g., automatically in response to user input, or through other mechanisms).

[0110] Figure 7 illustrates exemplary operations 700 that can be performed by the GCS140 illustrated in Figures 1A and 2 to constitute a diabetes intervention application according to some embodiments described herein.

[0111] As illustrated, operation 700 may begin in block 710, where GCS receives a configuration request from a diabetes intervention application. The configuration request may, in some embodiments, be a request for configuration information that can be used by the diabetes intervention application to enable or disable certain functions, function settings, and / or resources.

[0112] In block 720, GCS verifies that the access information included in the configuration request is legitimate. As can be considered, legitimate access information may be access information that GCS can decrypt into known or understandable data, or access information from which a matching authentication code can be generated.

[0113] In block 730, GCS generates configuration information that identifies a set of assets to which the diabetes intervention application should be provisioned, based on verifying the validity of the access information. The configuration information may be generated at least in part based on the functional customization information contained in the access information. For example, the configuration information may be generated based on location information, application version information, information about the environment in which the diabetes intervention application operates, device hardware or firmware information, sensor hardware or firmware information, user disease information, and other information that may be relevant to configuring the diabetes intervention application, as contained in the functional customization information. In a particular embodiment, the configuration information includes flags that identify the functions of the diabetes intervention application to be enabled, and / or pointers (or links) to remote resources that the diabetes intervention application uses while running.

[0114] In block 740, GCS sends configuration information to the diabetes intervention application in order to configure the diabetes intervention application using the set of assets indicated by the configuration information. As will be considered, the diabetes intervention application is generally configured by GCS sending configuration information to the diabetes intervention application. The diabetes intervention application can parse the configuration information contained in the parsable file to identify which functions and function settings to activate or deactivate, and to identify remote resources (e.g., URLs) that the diabetes intervention application is permitted to communicate with.

[0115] It should be noted that in certain embodiments described above, applications such as diabetes intervention applications are downloaded onto the user device (e.g., mobile device 107) and later configured using configuration information generated by the GCS. However, in certain other embodiments, when the user accesses the application store, a single integrated binary of the diabetes intervention application is not downloaded to the user device at that time. In such embodiments, functional customization information is sent to the GCS, causing the GCS to map the functional customization information to a set of assets for the user. In such embodiments, instead of generating and sending configuration information to the application, the GCS sends the mapped set of assets to the user device (directly or indirectly), and the user device downloads and runs the set of assets (corresponding to the application customized based on user specifications).

[0116] Figure 8 illustrates an exemplary system 800 for authenticating and configuring applications. For example, system 800 may correspond to one or more of the authentication services 130 and / or GCS 140 illustrated in Figures 1 and 2.

[0117] As shown, system 800 includes a central processing unit (CPU) 802, one or more I / O device interfaces 804 that can enable connections of various I / O devices 814 (e.g., keyboard, display, mouse device, pen input, etc.) to system 800, a network interface 806 to which system 800 is connected to a network 890 (which may be a local network, intranet, internet, or any other group of computing devices connected to communicate with each other), memory 808, and interconnects 812.

[0118] The CPU 802 can retrieve and execute programming instructions stored in memory 808. Similarly, the CPU 802 can retrieve and store application data resident in memory 808. The interconnect 812 transmits programming instructions and application data between the CPU 802, the I / O device interface 804, the network interface 806, and memory 808.

[0119] CPU802 is included to represent a single CPU, multiple CPUs, and a single CPU with multiple processing cores, etc.

[0120] Memory 808 represents volatile memory such as random access memory, and / or non-volatile random access memory, or non-volatile memory such as phase-change random access memory. As shown, memory 808 includes an account generator 820, a certificate checker 830, an application configurer 840, and a configuration data repository 850. The account generator 820 generally receives requests to create user accounts for diabetes intervention applications and creates a record in the user repository for each user of the application, which includes at least a user certificate and user location information that can be used to determine the configuration of the diabetes intervention application for the user. In some embodiments, the account generator 820 may further include in the user record other information that can be used to determine the configuration of the diabetes intervention application, including application version information, operating environment information, and other information related to the configuration of the application.

[0121] The certificate checker 830 generally receives login requests from applications running on mobile devices and verifies that the certificate included in the received login request matches the certificate included in the record generated by the account generator 820. If the user certificate included in the received login request is determined to be valid, the authentication information checker generates an access token containing information that the application configurer 840 can use to configure the application. The certificate checker 830 then provides the generated access token to the application running on the mobile device.

[0122] The application configurator 840 receives a configuration request from the application and configures the application using the access token included in the configuration request and the information stored in the configuration data repository 850. Generally, to configure an application, the application configurator 840 can retrieve configuration data from the configuration data repository 850 based at least on the location information included in the access token and generate a parseable file based on the retrieved configuration data. The configuration data generally includes information identifying remote resources that the application can communicate with and flags identifying whether assets within the application are enabled or disabled. The parseable file is then sent to the application for further processing, and as a result, the application is configured with assets appropriate to the location associated with the application's user.

[0123] Accordingly, certain embodiments described herein provide technical solutions to technical problems in the art of personalizing software application configurations based on user information (e.g., feature customization information). For example, certain embodiments relate to deploying a single, unified collection of assets (e.g., features, feature settings, and / or resources) available for an application, regardless of user-specific specifications. Storing, maintaining, and provisioning a single, unified application to different users, regardless of user-specific specifications, leads to significant resource efficiency. More specifically, when a single application binary and codebase is stored and maintained, in contrast to many different ones with overlapping code, a large amount of storage resources can be freed up and used for other purposes. In addition, significantly fewer computing resources can be consumed when updating, compiling, and debugging a single application binary and a single codebase, in contrast to many application binaries and codebases. Furthermore, maintaining a single codebase reduces the possibility of introducing errors into the code during code updates, or resolving errors in some, but not all, versions of the application.

[0124] Furthermore, as discussed above, some applications may be safety-critical applications, requiring regulatory approval before features can be made available to users in a given location (for example, to ensure that new features do not harm patients using the software application, or that new features comply with security requirements or best practices). New features in safety-critical applications may be approved faster in some areas than in others. Therefore, when deploying new features in safety-critical applications, developers may choose to deploy different versions of the application, with the version containing the new feature deployed in areas where regulatory approval has been obtained, and the version without the new feature deployed in areas where regulatory approval has not been obtained. If multiple codebases exist for multiple versions of an application, adding new features piecemeal (for example, when features are approved by the relevant regulatory authorities) can introduce additional complexity.

[0125] Furthermore, utilizing the systems, methods, and techniques described herein makes it possible to customize diabetes intervention applications for users based on their specifications. An application with customized functionality, features, settings, and resources tailored to the user's unique preferences and needs provides a more personalized experience, making it far more useful, beneficial, and engaging for the user, thereby helping to improve their health.

[0126] Each of these non-limiting examples can stand alone or be combined in various permutations or combinations with one or more of the other examples. The embodiments for carrying out the invention described above include references to accompanying drawings which constitute part of the embodiments for carrying out the invention. The drawings illustrate specific embodiments in which the invention can be carried out as an example. These embodiments are also referred to herein as “examples.” Such examples may include elements in addition to the illustrated or described elements. However, the inventors also intend examples in which only the illustrated or described elements are provided. Furthermore, the inventors also intend examples in which, with respect to a particular example (or one or more embodiments thereof) or with respect to other examples (or one or more embodiments thereof) illustrated or described herein, any combination or permutation of those illustrated or described elements (or one or more embodiments thereof) is used.

[0127] In the event of any discrepancy in usage between this document and any document incorporated by reference, the usage described in this document shall prevail.

[0128] In this text, the terms “a” or “an” are used to include one or more, independently of other instances or uses of “at least one” or “one or more,” as is common in patent documents. In this text, the term “or” is used to refer to non-exclusive elements, such that “A or B” includes “A but not B,” “B but not A,” and “A and B,” unless otherwise indicated. In this text, the terms “including” and “in which” are used as their plain English equivalents, “comprising” and “wherein.” Furthermore, in the following claims, the terms “including” and “comprising” are open-ended, meaning that a system, device, article, composition, formulation, or process that includes elements in addition to those described after such terms in a given claim is still considered to be within the scope of that claim. Furthermore, in the following claims, terms such as "first," "second," and "third" are used merely as designations and are not intended to impose numerical requirements on the subject.

[0129] Geometric terms such as "parallel," "perpendicular," "circular," and "square" are not intended to require absolute mathematical precision unless otherwise indicated by the context. Instead, such geometric terms allow for variations due to manufacturing or equivalent function. For example, if an element is described as "circular" or "approximately circular," components that are not perfectly round (e.g., slightly elliptical or polygonal) are still included in this description.

[0130] Examples of the methods described herein can be implemented, at least in part, by a machine or a computer. Some examples may include computer-readable or machine-readable media coded with instructions that can be used to configure an electronic device to perform the methods described in the above examples. Implementations of such methods may include code such as microcode, assembly language code, or high-level language code. Such code may include computer-readable instructions for performing various methods. This code may form part of a computer program product. Furthermore, in the examples, the code may be tangibly stored in one or more volatile, non-temporary, or non-volatile tangible computer-readable media during execution or at other times. Examples of these tangible computer-readable media include, but are not limited to, hard disks, removable magnetic disks, removable optical disks (e.g., compact disks and digital video disks), magnetic cassettes, memory cards or sticks, random access memory (RAM), read-only memory (ROM), and others.

[0131] The above description is intended to be illustrative and not restrictive. For example, the above examples (or one or more of them) may be used in combination with each other. Other embodiments may be used, such as those by those skilled in the art, when considering the above description. The abstract is provided in accordance with Section 1.72(b) of the U.S. Patent Law Enforcement Rules to enable the reader to quickly grasp the nature of the technical disclosure. It is submitted with the understanding that it is not to be used to interpret or limit the scope or intent of the claims. Furthermore, in the above “Modes for Carrying Out the Invention,” various features may be grouped together to streamline the disclosure. This should not be interpreted as meaning that any disclosed features not claimed are essential to any claim. Rather, the subject matter of the invention may lie in fewer features than all the features of a particular disclosed embodiment. Accordingly, the following claims are incorporated into the “Modes for Carrying Out the Invention” as examples or embodiments, and each claim stands independently as a separate embodiment, and it is intended that such embodiments can be combined with each other in various combinations or permutations. The scope of the invention should be determined by referring to the appended claims together with the full scope of equivalents to which such claims are entitled. [Explanation of symbols]

[0132] 100 Systems 102 users 104 Glucose Sensor System 106 Applications 107 Mobile Devices 108 Application Configurations 109 functions 110 User Database 111 Resources 112 Decision Support Engine 116 User Profiles 118 Demographic information 120 Disease progression information 122 Drug Information 127 inputs 128 indicators 130 Authentication Services 138 Sensor Electronics Module 139 Continuous Sample Sensor 150 Configuration Datastores 200 Computing Systems 212 Account Generator 214 Certificate Inspector 222 Application Configuration 300 Message Flow Diagrams 400 Message Flow Diagrams 500 operations 600 operations 700 operations 800 System 802 Central Processing Unit (CPU) 804 Device Interface 806 Network Interface 808 memory 812 Interconnection 814 devices 820 Account Generator 830 Certificate Inspector 840 Application Configuration 850 Configuration Data Repository 890 Network

Claims

1. A method for configuring a health intervention application that runs on a computing device via a remote server, Receiving a request from the health intervention application for an asset provided by the remote server, wherein the request includes access information associated with the user of the computing device, the access information includes functional customization information for the health intervention application, and the request is issued by the account management service of the health intervention application. To verify that the aforementioned access information is legitimate, In response to verifying that the access information is valid, configuration information is generated that identifies the set of assets on which the health intervention application should be provisioned, based at least in part on the function customization information contained in the access information. To configure the health intervention application using the identified set of assets, the configuration information is transmitted to the health intervention application. Methods that include...

2. The method according to claim 1, wherein the function customization information includes location information associated with the geographical location of the user of the computing device.

3. The above generation is The method according to claim 1, comprising identifying a set of URLs to be used to configure the health intervention application from a plurality of uniform resource locators (URLs) based on the function customization information, wherein the configuration information includes the set of URLs.

4. The above generation is The method according to claim 1, wherein, based on the function customization information, a set of application functions to be activated from a plurality of application functions to constitute the health intervention application is identified, wherein the configuration information includes one or more flags associated with the set of application functions that are set to a value indicating that the set of application functions is activated.

5. The method according to claim 1, wherein the function customization information includes version information of the health intervention application running on the computing device.

6. The method according to claim 1, wherein the function customization information includes operating environment information for the computing device and a glucose monitoring device connected to the computing device.

7. The method according to claim 1, wherein the access information includes an access token that includes the function customization information and token authentication information.

8. The method according to claim 1, wherein the configuration information includes mapping of application parameters associated with application functions to values ​​corresponding to specific application function settings.

9. A computing system, At least one memory containing executable instructions, At least one processor, which communicates data with the at least one memory and is configured to execute the instructions, and which is in the computing system Receiving a request from a health intervention application running on a computing device for assets provided by the computing system, wherein the request includes access information associated with a user of the computing device, the access information includes functional customization information for the health intervention application, and the request is issued and received by the account management service of the health intervention application. To verify that the aforementioned access information is legitimate, In response to verifying that the access information is valid, configuration information is generated that identifies the set of assets on which the health intervention application should be provisioned, based at least in part on the function customization information contained in the access information. To configure the health intervention application using the identified set of assets, the configuration information is transmitted to the health intervention application. A processor that performs the following: A computing system equipped with [the following features].

10. The computing system according to claim 9, wherein the function customization information includes location information associated with the geographical location of the user of the computing device.

11. The at least one processor configured to cause the computing system to generate the configuration information is configured in the computing system The computing system according to claim 9, comprising at least one processor configured to identify a set of URLs from a plurality of uniform resource locators (URLs) that are to be used to configure the health intervention application, based on the function customization information, wherein the configuration information includes the set of URLs.

12. The at least one processor configured to cause the computing system to generate the configuration information is configured in the computing system The computing system according to claim 9, comprising at least one processor, configured to identify, from a plurality of application functions, a set of application functions that should be activated to constitute the health intervention application, based on the function customization information, wherein the configuration information includes one or more flags associated with the set of application functions that are set to a value indicating that the set of application functions is activated.

13. The computing system according to claim 9, wherein the function customization information includes version information of the health intervention application executed on the computing device.

14. The computing system according to claim 9, wherein the function customization information includes operating environment information for the computing device and a glucose monitoring device connected to the computing device.

15. The computing system according to claim 9, wherein the access information includes an access token that includes the function customization information and token authentication information.

16. The computing system according to claim 9, wherein the configuration information includes mapping of application parameters associated with application functions to values ​​corresponding to specific application function settings.

17. A non-temporary computer-readable medium in which instructions are stored internally, wherein when the instructions are executed by a computing system, the computing system... Receiving a request from a health intervention application running on a computing device for assets provided by the computing system, wherein the request includes access information associated with a user of the computing device, the access information includes functional customization information for the health intervention application, and the request is issued and received by the account management service of the health intervention application. To verify that the aforementioned access information is legitimate, In response to verifying that the access information is valid, configuration information is generated that identifies the set of assets on which the health intervention application should be provisioned, based at least in part on the function customization information contained in the access information. To configure the health intervention application using the identified set of assets, the configuration information is transmitted to the health intervention application. A non-temporary computer-readable medium that enables the execution of a method, including the use of such a medium.

18. The non-temporary computer-readable medium according to claim 17, wherein the function customization information includes location information associated with the geographical location of the user of the computing device.

19. The above generation is The non-temporary computer-readable medium according to claim 17, which includes identifying a set of URLs to be used to configure the health intervention application from a plurality of uniform resource locators (URLs) based on the function customization information, wherein the configuration information includes the set of URLs.

20. The above generation is A non-temporary computer-readable medium according to claim 17, which identifies a set of application functions from a plurality of application functions to constitute the health intervention application, wherein the configuration information includes one or more flags associated with the set of application functions set to a value indicating that the set of application functions is activated.

Images