Global Configuration Service

This application is a continuation of U.S. Application No. Ser. No. 17/659,457, filed Apr. 15, 2022, which claims the benefit of and priority to U.S. Provisional Application No. 63/175,199, filed on Apr. 15, 2021, both of which are assigned to the assignee of the present application and are hereby expressly incorporated by reference in their entireties for all applicable purposes, as if fully set forth herein.

Diabetes is a metabolic condition relating to the production or use of insulin by the body. Insulin is a hormone that allows the body to use glucose for energy, or store glucose as fat.

When a person eats a meal that contains carbohydrates, the food is processed by the digestive system, which produces glucose in the person's blood. Blood glucose can be used for energy or stored as fat. The body normally maintains blood glucose levels in a range that provides sufficient energy to support bodily functions and avoids problems that can arise when glucose levels are too high, or too low. Regulation of blood glucose levels depends on the production and use of insulin, which regulates the movement of blood glucose into cells.

When the body does not produce enough insulin, or when the body is unable to effectively use insulin that is present, blood sugar levels can elevate beyond normal ranges. The state of having a higher than normal blood sugar level is called “hyperglycemia.” Chronic hyperglycemia can lead to a number of health problems, such as cardiovascular disease, cataract and other eye problems, nerve damage (neuropathy), and kidney damage. Hyperglycemia can also lead to acute problems, such as diabetic ketoacidosis—a state in which the body becomes excessively acidic due to the presence of blood glucose and ketones, which are produced when the body cannot use glucose. The state of having lower than normal blood glucose levels is called “hypoglycemia.” Severe hypoglycemia can lead to acute crises that can result in seizures or death.

A diabetes patient can receive insulin to manage blood glucose levels. Insulin can be received, for example, through a manual injection with a needle. Wearable insulin pumps are also available. Diet and exercise also affect blood glucose levels.

Diabetes conditions are sometimes referred to as “Type 1” and “Type 2.” A Type 1 diabetes patient is typically able to use insulin when it is present, but the body is unable to produce sufficient amounts of insulin, because of a problem with the insulin-producing beta cells of the pancreas. A Type 2 diabetes patient may produce some insulin, but the patient has become “insulin resistant” due to a reduced sensitivity to insulin. The result is that even though insulin is present in the body, the insulin is not sufficiently used by the patient's body to effectively regulate blood sugar levels.

Management of diabetes can present complex challenges for patients, clinicians, and caregivers, as a confluence of many factors can impact a patient's glucose level and glucose trends. To assist patients with better managing this condition, a variety of health or disease intervention software applications (hereinafter “applications”) have been developed by various providers. Diabetes is one example of a condition for which a variety of software applications have been developed. Numerous other applications have been developed for other health-related conditions. For example, these applications may include intervention applications for supporting the treatment of other diseases or applications that help with improving a patient's health overall, such as activity tracking applications, dieting applications, and the like.

These health applications are used in conjunction with various sensors measuring biological parameters, as well as tracking events such as activity and nutrition to provide the user with information regarding the user's health state as well as disease or health progress. In most cases, applications are designed specifically for each use case to achieve the specific goals relating to the use case for a specific set of users. This use-case specific approach is especially important with regard to safety critical information as different regulations or considerations must be applied to determine how the application interacts with a patient's health related information. These regulations may, for example, be dependent on geographical locations, or based on capabilities or specifications around the patient's specific demographics or health state.

This background is provided to introduce a brief context for the summary and detailed description that follow. This background is not intended to be an aid in determining the scope of the claimed subject matter nor be viewed as limiting the claimed subject matter to implementations that solve any or all of the disadvantages or problems presented above.

Certain aspects provide a method for configuring a diabetes intervention application executing on a computing device via a remote server, comprising: receiving, from the diabetes intervention application, a request for assets provided by the remote server, the request including access information associated with a user of the computing device, the access information including feature customization information for the diabetes intervention application and being issued by an account management service for the diabetes intervention application; validating that the access information is valid; responsive to validating that the access information is valid, generating configuration information identifying a set of assets with which the diabetes intervention application is to be provisioned based, at least in part, on the feature customization information included in the access information; and transmitting the configuration information to the diabetes intervention application to configure the diabetes intervention application with the identified set of assets.

In the above method, the feature customization information comprises location information associated with a geographical location of the user of the computing device. In the above method, the generating comprises: based on the feature customization information, identifying, from a plurality of uniform resource locators (URLs), a set of URLs to be used for configuring the diabetes intervention application, wherein the configuration information includes the set of URLs. In the above method, the generating comprises: based on the feature customization information, identifying, from a plurality of application features, a set of application features to be activated for configuring the diabetes intervention application, wherein the configuration information includes one or more flags associated with set of application features set to a value indicating that the set of application features are activated.

In the above method, the feature customization information includes version information for the diabetes intervention application executing on the computing device. In the above method, the feature customization information includes operating environment information for the computing device and glucose monitoring devices connected with the computing device. In the above method, the access information comprises an access token including the feature customization information and token authentication information. In the above method, the configuration information comprises a mapping of application parameters associated with application features to values corresponding to specific application feature settings.

Certain aspects provide another method for configuring a diabetes intervention application executing on a computing device via a remote server, comprising: receiving, from the diabetes intervention application, a request to initiate a session on the diabetes intervention application, the request including user credentials for a user account associated with a user of the diabetes intervention application; validating that the user credentials are valid for the user account; based on validating that the user credentials are valid, generating access information for the diabetes intervention application to use in retrieving configuration information for the diabetes intervention application from a global configuration service; and transmitting the access information to the diabetes intervention application.

The above method further comprises: receiving, from the computing device, a registration request to create the user account for the user of the diabetes intervention application; retrieving, from the global configuration service, information identifying a plurality of supported regions for the diabetes intervention application based on information included in the registration request; and establishing the user account for the user of the diabetes intervention application including an identification of a region of the plurality of supported regions for the diabetes intervention application.

In the above method, the registration request includes version information for the diabetes intervention application and operating environment information for the computing device and glucose monitoring devices connected with the computing device. In the above method, the information included in the registration request includes an identification of a language to use within the diabetes intervention application. In the above method, establishing the user account for the user of the diabetes intervention application comprises: determining that the identified region is a mismatch to a current geographic location of the computing device included in the registration request; and establishing the user account based on a region of the plurality of supported regions corresponding to the current geographic location of the computing device instead of the identified region.

In the above method, the request to initiate the session on the diabetes intervention application includes version information for the diabetes intervention application. The above method further comprises: comparing the version information for the diabetes intervention application included in the request to version information included in the access information; and based on a comparison of the version information included in the request to version information included in the user account resulting in identification of a mismatch, updating the user account based on the version information included in the request.

In the above method, updating the user account based on the version information included in the request comprises: determining that a feature supported by a version of the application corresponding to the version information included in the user account is deprecated in a version of the application corresponding to the version information included in the request; and transmitting, to the diabetes intervention application, one or more instructions to revert to the version of the application corresponding to the version information included in the user account.

Certain aspects provide yet another method for use by a computing device for configuring a diabetes intervention application executing on the computing device via a remote server, comprising: transmitting, to an authentication service, a request to access features of the diabetes intervention application, the request including user credentials for a user of the diabetes intervention application; receiving, from the authentication service, access information for the diabetes intervention application to use in retrieving configuration information for the diabetes intervention application from a global configuration service, the access information including feature customization information for the diabetes intervention application; transmitting, to the global configuration service, a request for the configuration information, the request including the access information; receiving the configuration information from the global configuration service, the configuration information including a set of assets with which the diabetes intervention application is to be provisioned based, at least in part, on the feature customization information included in the access information; and configuring the diabetes intervention application with the configuration information.

The above method further comprises: transmitting, to the authentication service, a registration request to create the user account for the user of the diabetes intervention application; and receiving, from the authentication service, information identifying a plurality of supported regions for the diabetes intervention application based on information included in the registration request; and transmitting a request to establish the user account, the request including an identification of a region of the plurality of supported regions for the diabetes intervention application.

In the above method, the registration request includes version information for the diabetes intervention application and operating environment information for the computing device and glucose monitoring devices connected with the computing device. In the above method, the information included in the registration request includes an identification of a language to use within the diabetes intervention application. In the above method, the request to access features of the diabetes intervention application includes version information for the diabetes intervention application.

In the above method, the set of assets comprises a plurality of uniform resource locators (URLs) to be used for configuring the diabetes intervention application, the URLs being associated with the feature customization information, and the configuring comprises configuring the diabetes intervention application to access assets using the plurality of URLs for configuring and executing features of the diabetes intervention application. In the above method, the feature customization information includes location information associated with a geographical location of the user of the diabetes intervention application.

In the above method, the feature customization information includes version information for the diabetes intervention application executing on the computing device. In the above method, the feature customization information includes operating environment information for the computing device and glucose monitoring devices connected with the computing device. In the above method, the set of assets comprise one or more feature flags indicating that features associated with the one or more feature flags are activated for use within the diabetes intervention application, the one or more feature flags being associated with the feature customization information, and configuring the diabetes intervention application comprises activating the features associated with the one or more feature flags and disabling features not associated with the one or more feature flags.

Another aspect is an apparatus, comprising: two or more means for performing any one of the above methods.

Another aspect is an 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.

Another aspect is a non-transitory computer readable medium storing computer executable code, comprising: code for performing any one of the above methods.

Typically, applications (e.g., mobile applications) are deployed on a patient's device (e.g., mobile device, such as a smartphone, smart wearable device, or the like) through an application store that may deliver different versions of the same application based on, for example, location information associated with the user, cost considerations, device capabilities, etc. 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 of residence), etc.

1 2 As an example, a safety critical application may be subject to regulation and approval by one or more regulatory authorities. Because some features may not be approved for use in some geographic locations, different versions of the application may exist, with each version including a set of features approved by the regulatory authorities for a specific location in which the application is being deployed. In another example, cost considerations may prompt the deployment of multiple versions of a software application. One version of the software application may include a more limited set of features than another version of the software application, but may be made 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 select one of a number of versions of the application, and the corresponding features, according to their ability and/or willingness to pay for different sets of features. In still another example, different versions of an application may be deployed to address different use cases. For example, in a diabetes management application, different features may be implemented based on whether the application is being used to treat or manage Typediabetes or Typediabetes; whether the application is being used to treat gestational patients; and the like.

However, maintaining and provisioning different versions of the same application presents many different technical problems and challenges. For example, typically, an application is provisioned by an application provider to users in different locations in the world through an application store. Because of varying specifications in different locations where the application is deployed, however, application providers may maintain different application binary files (“application binaries”) for the same application in an application data store and provision the different application binaries to corresponding users in the different locations in order to comply with or comport to the relevant specifications. Note that the varying specifications may include location based and non-location based specifications. Location based specifications may include regulatory guidelines (e.g., regulatory bodies in one location may prohibit the use of certain features), user preferences (e.g., based on research, it may be determined that users in one location may dislike certain features), strategic decisions made by the application provider (e.g., the 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 can choose to enable but is not available to users in another location), technological limitations (e.g., because of limited access to the Internet in a certain location), etc.

Non-location based specifications may include specifications that relate to user-specific information, other than the user's location. For example, certain features may be subscription-based, regardless of the user's location. In another example, certain features may be appropriate based on the use case or goals associated with the app. For example, the use case may relate to the health state of the user, where certain features may be appropriate for treating certain diseases, while other features may be appropriate for other diseases. In another example, the use case may be related to the goals of the app, e.g., disease management, health and wellness, diagnostics, clinical use cases. In yet another example, the app contents may vary according to the nature of the usage of the app, such as the length of use (e.g., limited use, intermittent use, long term use), primary user (e.g. clinician vs. patient), or other usage information that may affect the type of features and capabilities provided through the app. In certain implementations, certain features may be made available according to application cost tiers, subscriptions, etc. Still further, certain features may be made available based on considerations such as user sophistication, preferences, input, or other user or host data.

Typically, each application binary corresponds to a different configuration of the same application, where each configuration corresponds to a unique set of features, feature settings, and/or resources. The unique set of features, feature settings, and resources is hard-coded in each of the different application binaries. To illustrate this with an example, feature X of an application may be preferred by users or approved for use in location A, but not location B. In such an example, application binary A, which includes feature X, is provided to users in location A, while application binary B, which may be similar or identical to application binary A, except for application binary B not having feature X, is provided to users in location B. Thus, different application binaries, associated with different configurations of an application, may be maintained for provisioning to users in different locations. When downloaded and executed on a user's device, each of these different application binaries provide a different configuration of the application. Generally, for each application binary that is maintained by an application provider, a corresponding codebase is also maintained to allow developers to change or update the corresponding version of the application. A codebase comprises higher level code written by developers to create an application.

However, maintaining different application binaries and corresponding codebases for different configurations of the same application may have major technical drawbacks, including resource inefficiency. First, these application binaries and corresponding codebases may significantly overlap in content. As an example, code associated with certain common functionalities of the application may be reused for all of the different configurations of the application. As a result, storing different application binaries and the corresponding codebases for different configurations of the same application means that the overlapping or common code is being stored multiple times, which is storage inefficient. For example, given a number n of location-specific application binaries (and the 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 storage space on the storage systems on which the codebases are maintained may be (n−1)*commonCodebaseSize.

For an application in which location-specific versions share a significant amount of common code and other assets for location-agnostic functionality, such as login, core calculation and visualization functionality, shared graphical assets, and the like, this may mean that a significant amount of storage space and other compute resources may be needed for building and maintaining the application. Similarly, for the application store, the amount of resources needed to make multiple application binaries available for distribution may be significantly more than the minimum amount of resources that would be needed to store an application including all of the location-specific functionality implemented across the multiple application binaries.

In addition, when certain common code needs to be updated or debugged, developers have to propagate that change to each and every one of the codebases and recompile and deploy application binaries for each of the codebases, which is compute inefficient and increases the amount of work that needs to be performed to maintain the various configurations for the application. Further, if changes to the common code are propagated to only some of the codebases, errors may remain in some application binaries, or some application binaries may remain outdated. While some failures to maintain the application binaries may result in (or fail to solve) minor issues such as inconsistencies in a graphical user interface, other failures may have more severe ramifications. For example, if a security vulnerability is resolved in some application binaries but not resolved in other application binaries, the security vulnerability may still be exploited by malicious actors to exfiltrate sensitive data, inject malicious code for execution, or perform other nefarious activity. In another example, if problems communicating with external sensors are resolved in some application binaries but not resolved in other application binaries, some users of the application may continue to experience connectivity issues, which may cause the application to perform erroneous actions based on erroneous or nonexistent data.

Accordingly, certain embodiments described herein are directed to solving the technical problems described above by deploying a single, unified collection of available features, feature settings, and/or resources of an application. Hereinafter features, feature settings, and/or resources of an application may be referred to as “assets.” The collection of assets may be, in certain embodiments, provided as a unified application binary. In some examples, in addition to the collection of assets, a global configuration service (hereinafter “GCS”) maintains a mapping that maps different specifications to different sets of assets in the collection of assets. In various embodiments, the GCS uses the mapping to generate configuration information for configuring an application that is downloaded on a user device by mapping specifications associated with the user to a certain subset of assets in the collection of assets. In certain embodiments, the configuration information is then used to configure the application on the user device with the certain subset of assets. As used herein, “features” refer to functionality implemented in an application that may be enabled or disabled based on a user-specific configuration. As used herein, “feature settings” refer to various options that change the functionality of a given feature in the application, such as settings that specify units of measure, user interface appearance options, or the like. As used herein, “resources” refer to code, graphics files, uniform resource locators (URLs) audio files, or other content that can be used by the application during application execution.

For example, as discussed in further detail herein, when a user requests to download the application from an application store, a single collection of assets, for example as a unified application binary, is downloaded to the user's device, regardless of the specifications associated with the user. Such specifications may include a type of device being used by the user for downloading and executing the application, the product packaging associated with the user or the user's analyte monitoring system (e.g., transmitter, sensor, mobile device, receiver, etc.), the set of features subscribed to by the user, the type of user, user disease type or progression, app use case, the region in which the user is located or other user characteristics that may dictate the features, feature settings or assets that should be provided to the user. In one example, when the collection of assets is first downloaded to the user's device, the application is not yet configured based on user-specific specifications. Accordingly, the application sends a configuration request to the GCS, in response to which the GCS maps the user-specific specifications associated with the user to a set of assets in the collection of assets and transmits configuration information to the application that is indicative of the mapped set of assets. Using the configuration information, the application configures itself with the corresponding set of assets. For example, the application activates the set of assets indicated by the configuration information and deactivates or disables the rest of the assets in the application binary. In one example, the application may automatically configure itself with features in the set of assets indicated by the configuration information. Further, the application may automatically configure certain settings of those features as part of the configuration. Additionally, the application may automatically configure the resources to be accessible to the user according to the configuration information.

Storing, maintaining, and provisioning a single, unified application to different users, regardless of user-specific specifications leads to significant resource efficiency. More specifically, a large amount of storage resources may be freed and used for other purposes if a single application binary and codebase are stored and maintained, as opposed to many different ones with overlapping code. In addition, significantly less computing resources may be spent when updating, compiling, and debugging a single application binary and a single codebase, as opposed to many application binaries and codebases. Further, maintaining a single codebase reduces the likelihood of introducing errors into the code during code updates or resolving extant errors in some, but not all, versions of the application.

Further, as discussed above, some applications may be safety critical applications for which regulatory approval is needed before features are made available to users in a given location (e.g., to ensure that the new features do not harm patients using the software application, that the new features comply with security requirements or best practices, etc.). New features in a safety critical application may be approved in some regions earlier than in other regions. Thus, in deploying a new feature in a safety critical application, a developer can choose to deploy different versions of an application, with versions including the new feature being deployed in regions where regulatory approval has been obtained and versions excluding the new feature being deployed in regions where regulatory approval has not been obtained. When multiple codebases exist for multiple versions of an application, additional complexity may be introduced by adding new features in a piecemeal fashion (e.g., as features are approved by the relevant regulatory authorities).

The availability of multiple versions of an application may also complicate user selection of the appropriate application to install and use as well. For example, different versions of an application may use the same (or similar) application icons and thumbnails in an application repository and may have the same (or similar) package names. This may lead to user confusion in selecting the appropriate version of the application; user selection of a version of the application that is inappropriate for the user (which the user may not discover until trying to use the application); user selection of a version of the application that is incompatible with one or more user devices; and the like.

An example of an application that may be maintained, provisioned, and configured by the GCS, according to the embodiments described herein, is a diabetes intervention application. In one example, as described herein, the diabetes intervention application delivers guidance, which may assist patients, caregivers, healthcare providers, or other users in the management of diabetes. Accordingly, certain aspects of an application are described herein with respect to a diabetes intervention application as an example, but 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 a user. Diabetes intervention applications such as those described herein may deliver guidance with respect to lifestyle or clinical/patient outcomes by meeting a variety of challenges, such as overnight glucose control (e.g., reduce incidence of hypoglycemic events or hyperglycemic excursions), glucose control during and after meals (e.g. use historical information and trends to increase glycemic control), hyperglycemia corrections (e.g., increase time in target zone while avoiding hypoglycemic events from over-correction), hypoglycemia treatments (e.g., address hypoglycemia while avoiding “rebound” hyperglycemia), exercise, and/or other health factors. In certain embodiments, the application may further be configured with optimization tools that learn a patient's physiology and behavior and calculate guidance to help the patient identify optimal or desirable therapy parameters, such as basal insulin requirements, insulin to carbohydrate ratios, correction factors, and/or changes to insulin sensitivity due to exercise.

In certain embodiments, to provide relevant and effective guidance, the application utilizes input from one or more physiological sensors, such as one or more analyte sensors. An example of an analyte sensor described herein is a glucose monitoring sensor that measures a concentration of glucose and/or a substance indicative of the concentration or presence of glucose and/or another analyte in the user's body. In some embodiments, the glucose monitoring sensor is a continuous glucose monitoring device, for example a subcutaneous, transdermal, transcutaneous, intraocular and/or intravascular (e.g., intravenous) device. The glucose monitoring sensor can use any method of glucose measurement, including enzymatic, chemical, physical, electrochemical, optical, optochemical, fluorescence-based, spectrophotometric, spectroscopic (e.g., optical absorption spectroscopy, Raman spectroscopy, etc.), polarimetric, calorimetric, iontophoretic, radiometric, and the like.

The glucose monitoring sensor can use any known detection method, including invasive, minimally invasive, and noninvasive sensing techniques, to provide a data stream indicative of the concentration of the analyte in a host. The data stream typically incudes a stream of raw data signals used to provide useful analyte values, such as a patient or health care professional (HCP, e.g., doctor, physician, nurse, caregiver), who may be using the sensor.

In some embodiments, the glucose monitoring sensor is an implantable sensor, such as described with reference to U.S. Pat. No. 6,001,067 and U.S. Patent Publication No. US- 2011-0027127-Al. In some embodiments, the glucose monitoring sensor is a transcutaneous sensor, such as described with reference to U.S. Patent Publication No. US-2006-0020187-Al. In some embodiments, the glucose monitoring sensor is a dual electrode analyte sensor, such as described with reference to U.S. Patent Publication No. US-2009-0137887-Al. In some embodiments, the glucose monitoring sensor is configured to be implanted in a host vessel or extracorporeally, such as the sensor described in U.S. Patent Publication No. US-2007-0027385- Al. These patents and publications are incorporated herein by reference in their entirety.

Although much of the description and examples below are described in relation to a diabetes intervention application, the system and methods of the embodiment described herein may be used in conjunction with any health-related application that is provided to the user to improve the user's health. For example, a health-related application may help the user with treating a certain disease or just help with improving the health of a user who is not necessarily diagnosed with a disease.

1 FIG.A 100 106 102 100 104 107 106 112 110 130 140 150 illustrates an example systemfor maintaining, provisioning, and configuring application, which monitors a condition of, provides decision-support guidance to, and/or determines or directs administration of one or more treatments for user(hereinafter “the user”). The user, in certain embodiments, may be the patient or the patient's caregiver, healthcare provider or other entity that monitors patient health parameters. In the embodiments described herein, the user is assumed to be the patient for simplicity only but is not so limited. Systemincludes a glucose monitoring system, a mobile devicethat executes application, a decision support engine, a user database, an authentication service, a GCS, and a config data store.

104 107 106 107 107 107 106 In certain embodiments, glucose monitoring systemincludes a sensor electronics module and a glucose sensor that measures a concentration of blood glucose and/or a substance indicative of the concentration or presence of glucose and/or another analyte in the user's body. In certain embodiments, the glucose sensor is configured to perform measurements on a continuous basis. The sensor electronics module transmits the blood glucose measurements to mobile devicefor use by application. In some embodiments, the sensor electronics module transmits the glucose measurements to mobile devicethrough a wireless connection (e.g., Bluetooth connection). In certain embodiments, mobile deviceis a smart phone. However, in certain embodiments, mobile devicemay instead be any other type of computing device such as a laptop computer, a smart watch, a tablet, or any other computing device capable of executing application.

100 104 100 104 While systemillustrates a glucose monitoring system, it should be recognized that the embodiments described herein are similarly applicable to any other type of physiological monitoring systems that may be used, for example, as part of systemto monitor and/or treat a patient. Example physiological monitoring systems may include electrical or optical heart rate monitoring systems, pulse oximeters, temperature monitors, blood pressure monitors, hydration monitors, various analyte sensors (e.g., lactate sensor, ketone sensor, etc.), and so on. Further, it should be recognized that glucose monitoring systemor other physiological monitoring systems may include one or more sensors providing input into such systems.

112 112 106 112 112 107 112 107 In certain embodiments, decision support enginerefers to a set of software instructions with one or more software modules. In some embodiments, decision support engineexecutes entirely on one or more computing devices in a private or a public cloud. In such embodiments, applicationcommunicates with decision support engineover a network (e.g., Internet). In some other embodiments, decision support engineexecutes partially on one or more local devices, such as mobile device, and partially on one or more computing devices in a private or a public cloud. In some other embodiments, decision support engineexecutes entirely on one or more local devices, such as mobile device.

112 106 128 116 127 128 106 106 116 116 110 106 112 110 In certain embodiments, decision support engineis configured to process a set of inputs received from applicationand compute a plurality of metrics, which can then be stored in user profile. Inputsand metricsmay be used by application, such as by different features of application, to provide real-time guidance and treatments to the user. The various data points of user profileare described in further detail below. In certain embodiments, user profiles, including user profile, are stored in a user database, which is accessible to applicationas well as decision support engineover one or more networks (not shown). User database, in some embodiments, refers to a storage server that may operate in a public or private cloud.

106 116 110 106 106 The real-time guidance and treatments provided to the user help improve the user's physiological conditions and/or enable the user with making more informed decisions. To provide effective, relevant, and on-time guidance and treatments to the user, in certain embodiments, a feature of applicationmay take as input information relating to the user, which is stored in user profile, and/or information relating to a pool of similar users, which is stored in user profiles of such users in user database. In certain embodiments, a feature of applicationmay interact with the user through various ways such as text, email, notifications (e.g., push notifications), phone calls, and/or other forms of communication such as displaying content (e.g., graphs, trends, charts, etc.) on the user interface of application.

1 FIG.A 106 108 108 109 111 106 109 102 1 2 111 As shown in, applicationis uniquely configured with a certain configuration, which is logically represented as application configuration. Application configurationcorresponds to a set of featuresand resourcesthat are active and available for use by a user of application. In certain embodiments, each of featuresis configured to monitor a condition of, provide decision-support guidance to, and/or determine/administer one or more treatments for user. As shown, a feature (e.g., featuresand) may also comprise a setting that defines the operations of the feature. In certain embodiments, changing a feature's setting may result in changing the way the feature operates, such as the way the feature provides guidance and interacts with the user. For example, changing a feature's setting may result in, among other things, changing the feature's unit of measurement for calculating and displaying information to a user (e.g., pounds versus kilos). Resourcesmay also include uniform resource locators (URLs) pointing to remote resources and other types of resources.

109 111 106 140 106 106 106 1 FIG.A Featuresand resourcesrepresent subsets of larger sets of assets. The larger sets of assets represent all the features, feature settings, and/or resources that are included in the application's binary file and/or provisioned through GCS. In the example of, the remaining assets (of the larger sets of assets) are deactivated (e.g., not configured) for application. In other words, a user of applicationis not able to access or use the remaining assets of application. Although not limited to this list, some example features may include one or more of an objective setting and identification feature, reward features, reporting features, behavioral intervention features, exercise management feature, medication reminder features, a glycemic impact estimator feature, an educational feature, on-boarding features, application logging features, etc.

106 108 140 150 106 107 106 106 106 106 106 130 130 106 As described in further detail below, applicationis configured with application configuration, based on configuration information received from GCS(and retrieved from config data store), after applicationis downloaded on mobile deviceby the user. Generally, applicationmay begin from an uninitiated state (e.g., on initial launch after a user downloads the application binary for application, after a session times out, etc.). From this uninitiated state, applicationmay present a login screen to a user of application. If the user has account credentials that allow the user to use and access features in application, the user can enter those credentials into the login screen and submit the credentials to authentication servicein order to authenticate the user and initiate an active session in the application. Otherwise, as discussed in further detail below, the user can request that authentication servicecreate credentials that will allow the user to use the application.

130 106 106 140 130 106 130 106 106 140 130 130 130 Authentication servicegenerally uses user identification information to authenticate or validate a user and provide access information to applicationthat applicationcan use to obtain configuration information from GCS. In some examples, authentication servicevalidates the user credentials (e.g., user ID and password/passkey) provided by a user through the login screen of applicationand, if the user credentials are validated as belonging to an active account, authentication servicegenerates and returns access information for applicationto use to configure the applicationthrough GCS. Generally, the access information generated by authentication serviceincludes user identity-related information (e.g., information indicating that the user has been authenticated by authentication service, such as a cryptographic hash, a magic number, or the like) and feature customization information. In some aspects, the access information returned by authentication servicemay comprise or be structured as an access token.

106 107 107 107 106 104 108 130 106 102 130 106 The feature customization information may indicate user specifications and may include, for example, version information for the application, location information for the user (which may be determined based on user specification of the user's location or based on geolocation information from mobile device), the type of user or user disease, operating environment information for the mobile device, type of mobile device, user subscription tier, information about applicationand/or glucose monitoring system, various device and/or sensor codes associated with the user, and other information that can be used to uniquely identify a user and aid in identifying an application configurationthat is appropriate for the user. In some aspects, where the access information is received in the form of an access token, the access token may also include information that can be used to validate that the token is authentic (e.g., was validly generated by authentication serviceand not generated by an imposter service). For example, the access token may include a validity period after which applicationmay require that the userre-authenticate with authentication serviceto continue using the application, cryptographic information used to authenticate the token, or the like.

130 106 108 106 140 130 140 140 106 106 106 140 150 106 140 After receiving the access information from authentication service, applicationmay request application configurationfor the user of applicationfrom GCS. Generally, the request for configuration information includes the access information (e.g., an access token) received from authentication service. GCScan determine whether the access token is valid. If the access information is determined to be valid, GCScan then generate and transmit configuration information for applicationsuch that applicationcan be configured with assets that are enabled for the user based on the feature customization information. The configuration information may include, for example, flags corresponding to various features and/or feature settings of application, resource identifiers (e.g., uniform resource locators (URLs) pointing to remote resources that implement the activated features), or the like. The configuration information may be generated by GCSbased on configuration rules and other information stored, for example, in config data store. These configuration rules, which were previously referred to as a mapping, map feature customization information associated with a user to a set of assets (i.e., various features and/or feature settings of application, resource identifiers, etc.). In other words, the GCSmaps feature customization information associated with a user to a set of assets, using the configuration rules, and then generates configuration information that indicates the mapped set of assets.

106 106 104 107 107 Applicationthen uses the received configuration information to configure the application by activating the various features and/or feature settings and pointing to remote resources identified in the application configuration information. The applicationmay then be ready for use to obtain data from glucose monitoring systemand/or other resources (e.g., accelerometers or location information devices in or connected with mobile device, data entry from mobile device, etc.) to monitor the user's blood glucose measurements and take various actions in response to the user's blood glucose measurements.

106 106 130 130 107 130 In some examples, if a user does not have credentials allowing the user to use application, applicationdirects the user to a credential creation workflow provided by authentication service. The authentication servicemay request that the user provide contact information and information identifying a location associated with the user, which may be manually entered or determined based on location information devices (e.g., satellite positioning systems such as NAVSTAR GPS, GLONASS, or GALILEO; IP address geolocation, etc.) integrated into or otherwise connected with mobile device. Authentication servicemay then authenticate the user's contact information, and upon authentication, continue with the process of generating account credentials for the user.

130 140 150 130 107 107 130 107 130 107 107 130 130 106 In generating account credentials for the user, authentication servicemay obtain a list of supported locations from GCS(or a data store associated therewith, such as config data store) and display the list of supported locations to the user for selection. In some aspects, authentication servicemay automatically select a location from the list of supported locations based on user-provided information identifying the location associated with the user (as discussed above) or based on a location of the mobile devicedetermined based on one or more location information or identification devices or services in or connected with mobile device. The automatically selected location, however, may be overridden by user selection of another one of the supported locations. In some aspects, authentication servicecan determine that a determined location of the user's mobile deviceis a mismatch with user-provided location information. In such a case, authentication servicecan override the user-provided location information with the determined location of the user's mobile deviceand proceed with establishing a user account based on the determined location of the user's mobile device. After creating the appropriate credentials (e.g., username, password, location, and other information that may be requested by authentication service), authentication servicecan create an account including the created credentials for the user and generate an access token to be used by applicationto configure the application for the user, as discussed above.

140 106 106 140 130 140 140 140 106 140 140 140 130 106 As discussed, GCSis generally configured to receive requests to configure an applicationand provide, to the requesting devices, configuration information generated based on access information, such as an access token, included in the received requests. Upon receiving the access information from an application, GCScan attempt to validate the access information. In some aspects, the access information may be encrypted using a cryptographic key known to the authentication serviceand the GCS. If the GCSis thus unable to decrypt the access information (e.g., recovers nonsensical information after an attempt to decrypt the token), GCScan determine that the access information is invalid, and configuration of the applicationmay be terminated. In another aspect, the access information may include a validity identifier that GCScan use to authenticate the access information. The validity identifier may be data that GCScan derive from other information in the access information or may be information that GCScan use to request validation of the access information from authentication service. It should be noted, however, that various techniques can be used to determine the validity of the access information, and correspondingly, whether the applicationcan be configured for the user.

140 106 140 106 106 106 107 106 107 106 106 106 If GCSdetermines that the received access information is, in fact, valid, configuration service can use the received access information to generate configuration information for use in configuring application. For example, GCScan use some or all of the feature customization information included in the received access information, such as location information (e.g., the location information associated with the user), version information of the applicationfrom which the configuration request was received, information about the operating environment in which applicationis being used (e.g., information about sensors being used to generate data analyzed by application, the operating system of the mobile deviceon which applicationis being used, the type of the mobile device, etc.), and/or other information, to identify configuration options to activate and/or deactivate for the user. The configuration information may include flag settings identifying which flags, corresponding to features and/or feature settings in the application, to activate or deactivate, information identifying the location of remote resources that applicationcan use, and other information that configures the operations of application.

140 106 140 106 140 106 140 106 106 106 106 140 106 140 106 In some aspects, GCScan use the version information included in the access information and the version information of the application, from which the configuration request was received, to perform various actions with respect to the user's account. For example, if GCSdetermines that there is a mismatch between the version information included in the access information and the version information for the application, GCScan update the user account to reflect that the user is using a new (or different) version of application. In another example, GCScan use the version information included in the access information and the version information of the applicationto determine whether features of the version of applicationspecified in the access token are deprecated in the version of the applicationfrom which the configuration request was received. If a feature is deprecated in the version of the applicationfrom which the configuration request was received, GCScan transmit, to application, instructions to revert to a previous version of the application in which the feature is not deprecated. For example, GCScan instruct applicationto revert to the version of the application identified in the access token.

106 116 106 118 120 122 116 118 120 122 As described above, in certain embodiments, applicationis configured to take as input information relating to the user and store the information in a user profileof the user. For example, applicationmay obtain and record the user's demographic info, disease progression info, and/or medication infoin user profile. In certain embodiments, demographic infomay include one or more of the user's age, BMI (body mass index), ethnicity, gender, etc. In certain embodiments, disease progression infomay include information about the user's disease, such as whether the user is Type 1, Type 2, or pre-diabetes 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 control, level of compliance with diabetes management therapy, predicted pancreatic function, other types of diagnosis (e.g., heart disease, obesity) or measures of health (e.g., heart rate, exercise, stress, sleep, etc.), and/or the like. In certain embodiments, medication infomay include information about the amount and type of insulin or non-insulin diabetes medications and/or non-diabetes medication taken by the user.

106 118 120 122 106 116 110 106 112 110 In certain embodiments, applicationmay obtain demographic info, disease progression info, and/or medication infofrom the user in the form of user input or from other sources. In certain embodiments, as some of this information changes, applicationmay receive updates from the user or other sources. In certain embodiments, user profiles, including user profile, are stored in a user database, which is accessible to applicationas well as decision support engineover one or more networks (not shown). User database, in some embodiments, refers to a storage server that may operate in a public or private cloud.

118 120 122 106 127 109 127 108 127 104 107 In certain embodiments, in addition to the user's demographic info, disease progression info, disease type, and/or medication info, applicationobtains an additional set of inputsthat are also utilized by featuresto provide output to the user. In certain embodiments, such inputsare obtained on a continuous basis. In certain embodiments, applicationreceives inputsthrough user input and/or a plurality of other sources, including glucose monitoring system, other applications running on mobile device, and/or one or more other sensors and devices. These inputs may include, for example, device identifying information (e.g., a serial number which can be mapped to a

107 specific device model), sensor identifying information, firmware version information for connected devices or sensors, etc. In certain embodiments, such sensors and devices include one or more of, but are not limited to, an insulin pump, other types of analyte sensors, sensors or devices provided by mobile device(e.g., accelerometer, camera, global positioning system (GPS), heart rate monitor, etc.) or other user accessories (e.g., a smart watch), or any other sensors or devices that provide relevant information about the user.

106 127 128 106 127 112 112 128 106 109 128 116 108 2 FIG. In certain embodiments, applicationfurther uses at least part of inputsto obtain a plurality of metrics, such as behavioral metrics or outcome metrics. As further described in relation to, in some embodiments, applicationtransmits at least part of inputsto decision support enginefor processing, based on which decision support enginegenerates the plurality of metrics. In certain embodiments, metricsmay then be used by applicationas input to featuresfor providing output to the user. In certain embodiments, metricsare also stored in user profile, which may be stored for future analysis, used to adapt application configuration, or the like.

128 In certain embodiments, metricsmay include behavioral data that may be indicative of the user's behaviors and habits, such as one or more of the user's behavior or interaction with respect to the application, the user's behavior with respect to the treatment of the disease, health-related behaviors, etc. Behavioral metrics may include real-time metrics, past metrics, and/or trends. Outcome metrics may, at lease in some cases, be generally indicative of the user's health or state, such as one or more of the user's physiological or psychological state (e.g., stress level, happiness, etc.), trends associated with the user's health or state, how far or close the user is to meeting their objectives based on the user's health or state, etc. In certain embodiments, outcome metrics may be directly correlated with the behavioral metrics, meaning that outcome metrics may be the result of the user's behavior or pattern of behaviors. Examples of outcome metrics include one or more of metrics associated with metabolic rates, glucose levels and trends, the user's health or sickness, etc. In certain embodiments, outcome metrics may include real-time metrics, past metrics, and/or trends.

1 FIG.B 1 FIG.B 1 FIG.A 104 107 107 107 107 107 107 107 107 107 107 107 107 107 106 104 107 107 107 107 a b c d a b c d a b c d a b c d illustrates glucose monitoring systemin more detail.also illustrates a number of mobile devices,,, and. Note that mobile deviceofmay be any one of mobile devices,,, or. In other words, any one of mobile devices,,, ormay be configured to execute application. Glucose monitoring systemmay be communicatively coupled to mobile devices,,, and/or.

104 107 107 107 107 104 a b c d 3 3 4 FIGS.A,B, and 3 3 4 FIGS.A,B, and By way of an overview and an example, glucose monitoring systemmay be implemented as an encapsulated microcontroller that makes sensor measurements, generates analyte data (e.g., by calculating values for continuous glucose monitoring data), and engages in wireless communications (e.g., via Bluetooth and/or other wireless protocols) to send such data to remote devices, such as mobile devices,,, and/or. Paragraphs [0137]-[0140] andof U.S. App. No. 2019/0336053 further describe an on-skin sensor assembly that, in certain embodiments, may be used in connection with glucose monitoring system. Paragraphs [0137]-[0140] andof U.S. App. No. 2019/0336053 are incorporated herein by reference.

104 138 139 138 138 138 139 139 In certain embodiments, glucose monitoring systemincludes an analyte sensor electronics moduleand a glucose sensorassociated with analyte sensor electronics module. In certain embodiments, analyte sensor electronics moduleincludes electronic circuitry associated with measuring and processing analyte sensor data or information, including algorithms associated with processing and/or calibration of the analyte sensor data/information. Analyte sensor electronics modulemay be physically/mechanically connected to glucose sensorand can be integral with (i.e., non-releasably attached to) or releasably attachable to glucose sensor.

138 139 138 139 138 139 104 Analyte sensor electronics modulemay also be electrically coupled to glucose sensor, such that the components may be electromechanically coupled to one another. Analyte sensor electronics modulemay include hardware, firmware, and/or software that enable measurement and/or estimation of levels of the analyte in the user via glucose sensor(e.g., which may be/include a glucose sensor). For example, analyte sensor electronics modulecan include one or more potentiostats, a power source for providing power to glucose sensor, 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. Electronics can be affixed to a printed circuit board (PCB) within glucose monitoring system, or platform or the like, and can take a variety of 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.

138 Analyte sensor electronics modulemay include sensor electronics that are configured to process sensor information, such as sensor data, and generate transformed sensor data and displayable sensor information. Examples of systems and methods for processing sensor analyte data are described in more detail herein and in U.S. Pat. Nos. 7,310,544 and 6,931,327 and U.S. Patent Publication 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 in their entireties.

139 102 139 139 139 Glucose sensoris configured to measure a concentration or level of the analyte in the user. The term analyte is further defined by paragraph [0117] of U.S. App. No. 2019/0336053. Paragraph [0117] of U.S. App. No. 2019/0336053 is incorporated herein by reference. In some embodiments, glucose sensorcomprises a continuous glucose sensor, such as a subcutaneous, transdermal (e.g., transcutaneous), or intravascular device. In some embodiments, glucose sensorcan analyze a plurality of intermittent blood samples. Glucose sensorcan use any method of glucose-measurement, including enzymatic, chemical, physical, electrochemical, spectrophotometric, polarimetric, calorimetric, iontophoretic, radiometric, immunochemical, and the like. Additional details relating to a continuous glucose sensor are provided in paragraphs [0072]-[0076] of U.S. application Ser. No. 13/827,577. Paragraphs [0072]-[0076] of U.S. application Ser. No. 13/827,577 are incorporated herein by reference.

1 FIG.B 107 107 107 107 138 107 107 107 107 109 109 109 109 106 102 102 102 107 107 107 107 138 a b c d a b c d a b c d a b c d With further reference to, mobile devices,,, and/orcan be configured for displaying (and/or alarming) displayable sensor information that may be transmitted by sensor electronics module(e.g., in a customized data package that is transmitted to the display devices based on their respective preferences). Each of mobile devices,,, and/ormay respectively include a display such as touchscreen display,,, and/orfor displaying a graphical user interface of applicationfor presenting sensor information and/or analyte data to userand/or receiving inputs from user. In certain embodiments, the mobile devices may include other types of user interfaces such as voice user interface instead of or in addition to a touchscreen display for communicating sensor information to userof the mobile device and/or receiving user inputs. In certain embodiments, one, some, or all of mobile devices,,, and/ormay be configured to display or otherwise communicate the sensor information as it is communicated from sensor electronics module(e.g., in a data package that is transmitted to respective display devices), without any additional prospective processing required for calibration and/or real-time display of the sensor data.

107 107 107 107 107 138 107 107 107 107 107 a b c d b a b c d c 1 FIG.B The plurality of mobile devices,,, and/ordepicted inmay include a custom or proprietary display device, for example, analyte display device, especially designed for displaying certain types of displayable sensor information associated with analyte data received from sensor electronics module(e.g., a numerical value and/or an arrow, in certain embodiments). In certain embodiments, one of the plurality of mobile devices,,, and/orincludes a smartphone, such as mobile phone, based on an Android, iOS, or another operating system configured to display a graphical representation of the continuous sensor data (e.g., including current and/or historic data).

2 FIG. 200 140 130 106 200 107 130 140 150 illustrates an example of a computing systemin which GCSand authentication serviceare used to configure application(e.g., diabetes intervention application), according to some embodiments disclosed herein. As illustrated, computing systemincludes a mobile device, authentication service, GCS, and a config data store.

130 106 106 106 130 212 214 Authentication servicegenerally represents a service through which users of applicationcan create credentials for using the applicationand request access to the application. As illustrated, authentication serviceincludes an account generatorand a credential verifier.

212 106 212 106 212 106 Account generatoris configured to generate user credentials in response to a request to create an account for a user received from application. In some aspects, the request may include contact information for the user and other information that can be used to validate the user and the user's contact information. Upon receiving the request to create the account, account generatorcan provide information about the supported locations for applicationas part of a process to complete user registration and credential generation for the user. Upon completion of the credential creation process, account generatorcan persist the user's account information to a data store (not shown) for use in subsequently authenticating a user of the application.

3 FIG. 300 106 130 212 140 is a message flow diagramillustrating an example of messages exchanged between an application, authentication service(and more specifically, account generator), and GCSto generate user credentials for an application configured through the GCS, according to some embodiments described herein.

302 130 130 304 140 140 306 130 130 106 308 As illustrated, to generate user credentials for the diabetes intervention application, the application can loadan account creation widget. In loading the account creation widget, the application can provide, to authentication service, information about the version of the application, and the authentication servicecan transmit a requestfor a list of supported locations (e.g., countries) for the version of the application from the GCS. In response, the GCSprovides the list of supported countriesto the authentication service, and the authentication servicecan provision a location selector in the account creation widget with the list of supported countries received from the GCS. After receiving the list of supported countries, the applicationcompletes loadingthe account creation widget.

310 106 312 130 130 314 316 After receiving user input, including at least user contact information and a selection of one of the supported countries, the applicationtransmits a requestto create a user account including the user input to the authentication service. The authentication servicevalidatesthe user contact information and transmits a messageto the user including, for example, a link to complete user registration within or outside of the application. Further, once validated, the authentication service can persist user information to a user data store which the authentication service can subsequently access to process login requests and generate access information, such as access tokens, that the application can use to request configuration information from the GCS, as discussed herein.

214 106 140 214 106 106 212 214 106 214 Credential verifiergenerally is configured to verify a user's credentials and provide access information (e.g., an access token) to applicationfor use in requesting configuration information from GCS. As illustrated, credential verifiermay receive a login request from application, which initiates a process of authenticating the user of applicationand 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 the associated user credentials through account generator, as discussed above. If the username and password (or other access code) match an entry in a user account repository, credential verifiercan determine that the login request was a valid login request and generate access information for the user. The generated access information generally indicates that the user is validly logged into the user account and can initiate a session in application. In some aspects, the access information may have a timeout period, after which the user may be requested to provide the user's credentials to credential verifieragain in order to generate a new set of access information or renew an already issued set of access information.

214 106 106 214 107 106 107 106 106 104 140 106 Credential verifiermay generate access information for the user based on various user specifications that may be stored in a user account repository or received from application(e.g., in the login request received from application). For example, credential verifiercan generate access information including feature customization information. This feature customization information may be generated based on the various user specifications, such as user identifying information and attributed (e.g., user-provided locality information indicating the country in which the user resides, user disease, user preferences, type of user, etc.), information about mobile deviceand the version of applicationexecuting on mobile device(e.g., major version number, build number, or other information identifying the specific version of the applicationfrom which the login request was received), information about the operating environment in which applicationis executing, information about one or more sensors (e.g., glucose sensor system) used by the user, and other information that can be used by GCSto configure application.

214 130 140 214 220 214 214 In some aspects, credential verifiercan encrypt the access information using a cryptographic key (or a set of cryptographic keys) known to authentication serviceand GCSto allow configuration service to validate the access information. In some aspects, credential verifiermay generate other information that can be used to verify the access information, such as a cryptographic hash generated based on the access information (e.g., carried in an access token), and include the generated information in the access information for use by configuration servicein verifying the access information. For example, credential verifiermay concatenate the username, a timestamp associated with the login request (e.g., the time at which the login request was received, an expiration time calculated from the time at which the login request was received, etc.), and location information associated with the user, and generate a verification code based on a cryptographic hash of the concatenated username, timestamp, and location information. It should be recognized, however, that this is only one example of the generated information that credential verifiercan generate for use in validating the access information, and that other information and other techniques for generating data for use in validating the access information can be used.

140 106 130 140 222 GCSgenerally represents a service through which applicationis configured based on access information provided by authentication service. As illustrated, GCSincludes an application configurer.

222 106 107 106 222 222 Application configurergenerates configuration information for applicationbased on a received configuration request and received access information. The configuration request may be received, for example, after an application is launched or updated at mobile device. To configure the application, application configurercan first determine whether the configuration request is valid based on whether the access information is valid. For example, where the access information is received as an access token, application configurercan determine whether the received access token is a valid access token by attempting to decrypt the access token using an a priori defined cryptographic key (or set of cryptographic keys).

222 222 222 106 222 106 Because only the correct cryptographic key (or set of cryptographic keys) allows for intelligible data to be retrieved from encrypted data, application configurercan determine whether the access token is valid by attempting to decrypt the access token and determining whether the decrypted access token includes intelligible data. The determination of whether the decrypted access token includes intelligible data may include, for example, searching for one or more defined strings in the decrypted access token, identifying a special value in the decrypted access token, or the like. If application configurerdetermines that the access token was successfully decrypted, application configurercan proceed to generate configuration information for use by application, as discussed in further detail below. Otherwise, application configurercan transmit an error message to applicationindicating that validation of the access token failed.

222 222 214 222 222 106 222 106 In another example, application configurercan determine whether the access information is valid by attempting to match an authentication code included in the access information with a version of the authentication code generated from data included in the access information. In such a case, application configurermay be configured to generate authentication codes using the same techniques (e.g., same algorithms) used by credential verifierto generate authentication codes, as discussed above. If the authentication code included in the received access information matches the version of the authentication code generated by application configurer, application configurercan determine that the access information is valid and can proceed to generate configuration information for use by application. Otherwise, application configurercan transmit an error message to applicationindicating that validation of the access information failed.

106 222 150 106 222 150 106 222 To generate configuration information for application, application configurercan retrieve information from config data storeand use the feature customization information included in the access information to identify the assets that are to be enabled for the user of application. For example, where the feature customization information includes user location information, application configurercan search config data storefor configuration rules or mappings identifying assets that are supported for users located in the location associated with the user from which the configuration request and access token was received. These configuration rules may dictate which flags are to be enabled or indicated as enabled in the configuration information, as well as resource information pointing to resources that applicationare to access during execution. As an example, a configuration rule may dictate that for a user in Germany, feature X may be activated but feature Y may be deactivated. In such an example, the configuration information generated for the user by the application configurerincludes a flag indicating that feature X should be activated for the user.

106 106 106 106 106 Flags or other information to enable assets in applicationmay include flags indicating features and feature settings. For example, a flag may indicate that an exercise management feature should be enabled for the user. In another example, a flag may indicate that a certain feature setting of the exercise management feature should be enabled. In yet another example, a flag may indicate whether a feature setting, such as a unit of measure, should be set to the metric system or the imperial system. For example, a first value of a units of measure flag may indicate that the applicationor a certain feature of the applicationis to interpret sensor data and generate measurements based on the metric system, while a second value of the units of measure flag may indicate that the applicationor a certain feature of the applicationis to interpret sensor data and generate measurements based on the imperial system.

106 112 110 106 106 1 1 FIGS.A andB In another example, flags may be used to identify how data is to be encrypted for transmission from applicationto other external systems, such as decision support engineor user databaseillustrated in. For example, one value of an encryption flag may indicate that data is to be transmitted in the clear, a second value of the encryption flag may indicate that data is to be transmitted using a first form of encryption (e.g., a first set of keys associated with a first geographical region, a first encryption scheme, etc.), a third value of the encryption flag may indicate that data is to be transmitted using a second form of encryption (e.g., a second set of keys associated with a second geographical region, a second encryption scheme, etc.), and so on. In still another example, flags or other information may be set in the configuration information to control a periodicity at which the applicationinvokes various functions exposed by remote resources. Different values of the flags, or the setting of different flags, may indicate different periodicities at which data is to be reported or functions exposed by remote resources are to be invoked by application.

220 222 106 106 In yet another example, flags may be used to identify a setting of an on-boarding feature configured to provide a set of on-boarding instructions. For example, an on-boarding feature may have various sensor placement settings for providing different sensor placement instructions to users. Which setting is selected by application configurerand indicated by a flag in the configuration information may be based, for example, on the user's location or other types of feature customization information. For example, where the feature customization information indicates that that user is in location X, application configurermay generate configuration information including a flag that indicates a first setting for the application corresponding to location X. The first setting may then configure applicationto provide instructions to the user to wear the sensor on their arms. In another example, if the user is in location Y, a second setting corresponding to location Y may configure applicationto provide instructions to the user to wear the sensor either on their arms or their abdomen.

222 106 106 222 In another example, flags may be used to identify a setting of an application logging feature for logging application events. Examples of application events include application exceptions, major events (e.g., startups, stops, restarts, and security events), error event notifications, debugging information, SQL logs, warnings about low disk space, etc. A logging feature may have various logging settings corresponding to various levels of logging. For example, a first setting may correspond to a high logging level and a second setting may correspond to a low logging level. Which setting is selected by application configurerfor a certain user may depend on the feature customization information associated with the user, which may indicate the location of the user, application version of application, operating system of the user's mobile device, etc. As an example, if users in location X report a lot of technical issues, when new users in location X download application, application configurermay configure the application for those users with the first setting so that a larger amount of application events can be obtained and analyzed by technical teams in charge of maintaining the application. A second setting corresponding to a low logging level, however, may be used for users in locations where a lower number of technical issues is reported.

104 106 Flags can be used to indicate the enablement or disablement of many different features and feature settings. In addition to the example features and feature settings provided above, some other example features include an alert feature, a BlueTooth communication feature, a security feature, a time provider feature, a secure networking application programming interface (API), a bulk data feature (associated with how data is transmitted from the sensor systemto applicationin bulk), etc.

106 106 106 106 106 106 140 106 222 106 The configuration information may be generated as a structured file parseable by application. For example, the configuration information may be generated as an eXtensible Markup Language (XML) file, a JavaScript Object Notation (JSON) message, a graph data structure, or other parseable data that applicationcan use to identify which assets are to be activated in application(e.g., which features to activate within applicationand which resources with which the applicationis to communicate). In some aspects, the configuration information may be encrypted prior to transmission to applicationusing a cryptographic key associated with the GCSand/or the user of the applicationto protect the cryptographic information from modification during transmission from application configurerto application,

4 FIG. 1 2 FIGS.A and 1 2 FIGS.A and 1 2 FIGS.A and 400 106 130 140 is a message flow diagramillustrating an example of messages exchanged between an application (such as applicationillustrated in), an authentication service (such as authentication serviceillustrated in), and a GCS (such as GCSillustrated in) to configure the application through the GCS, according to some embodiments described herein.

106 402 130 404 406 130 408 406 130 410 106 140 130 106 As illustrated, the applicationmay begin by loadinga login widget in which a user provides user credentials to be authenticated by the authentication service. After the user provides the user credentialsand submits the credentials in a login requestthrough the login widget, the authentication servicevalidatesthe user credentials included in the login request. If the user credentials correspond to an existing user account, the authentication servicecan generate and issue an access token(or access information in a form other than a token) that the applicationcan use to request configuration of the application through the GCS. Otherwise, the authentication servicecan generate an error message (not shown) which the applicationcan use to indicate that the user credentials were invalid and request entry of another set of user credentials.

130 106 140 140 412 106 412 410 130 106 140 414 106 140 140 416 140 418 After receiving the access token from the authentication service, the applicationcan request configuration information from the GCSby transmitting, to the GCS, a request for URLs(or an identification of remote resources with which the applicationis to be provisioned). Generally, the request for URLsincludes the access tokenprovided by the authentication serviceand provided to application. In response, the GCSvalidates the token and, upon determining that the token is valid, transmits a URL configuration information responseincluding the URLs (or other identification of remote resources) with which the diabetes intervention application is allowed to communicate, based at least on location information included in the access token. Similarly, the applicationcan request configuration information from the GCSby transmitting, to the GCS, an asset requestfor information identifying application assets that are enabled for the user. This request also includes the access token provided by the authentication service. In response, the GCSvalidates the token and, upon determining that the token is valid, transmits an asset configuration responseincluding various flags corresponding to assets that are activated or disabled for the user. The values of the flags corresponding to assets that are activated for the user may be set based on mapping information (e.g., configuration rules) identifying assets that are enabled for the location of the user and/or mapping information identifying optional assets that the user has enabled. Note that, in certain embodiments, a set of features and feature settings (associated with the application that is downloaded by the user) correspond to core features and feature settings. In certain embodiments, these core features and feature settings may be enabled for all users regardless of the user specifications and what the feature customization information indicates. As such, in such embodiments, the configuration information may not include any flags corresponding to the core features and feature settings.

5 FIG. 1 2 FIGS.A and 1 2 FIGS.A and 1 2 FIGS.A and 500 130 106 140 illustrates example operationsthat may be performed by an authentication service (such as authentication serviceillustrated in) to authenticate a user of a diabetes intervention application (such as applicationillustrated in) configured through a GCS (such as GCSillustrated in), according to some embodiments disclosed herein.

500 510 As illustrated, operationsbegin at block, where the authentication service receives, from the diabetes intervention application, a request to initiate a session on the diabetes intervention application. The request generally includes user credentials for a user account associated with a user of the diabetes intervention application.

520 At block, the authentication service validates that the user credentials are valid for the user account. Validating the user credentials generally involves at least determining whether the provided username and password match credentials in a record in the user database. In some aspects, multifactor authentication may be used in which additional information, such as a user biometric or a one-time authentication code, is also validated in order to validate that the user credentials are valid for the user account.

530 At block, the authentication service generates access information for the diabetes intervention application to use in retrieving configuration information for the diabetes intervention application from a GCS. The access information is generated based on validating that the user credentials are valid for the user account.

540 At block, the authentication service transmits the access information to the diabetes intervention application. The access information may be transmitted, in some aspects, over an encrypted channel so that the access information is protected against modification during transit between the authentication service and the mobile device on which the diabetes intervention application executes.

6 FIG. 1 2 FIGS.A and 1 2 FIGS.A and 600 106 140 illustrates example operationsthat may be performed by a diabetes intervention applicationillustrated into configure the application through GCSillustrated in, according to some embodiments described herein.

600 610 As illustrated, operationsbegin at block, where the application transmits, to an authentication service, a request to access assets associated with or in a diabetes intervention application. The request generally includes user credentials for a user of the diabetes intervention application. The user credentials generally include a username and password or access code, and may optionally include other information used in multi-factor authentication, such as a biometric or a one-time code provided by the authentication service.

620 At block, the application receives, from the authentication service, access information. 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 aspects, the access information may be encrypted using a cryptographic key known to the authentication service and the GCS, and the application can pass the access information to the GCS without decrypting the access information.

630 At block, the application transmits, to the GCS, a request for the configuration information. The request generally includes the access information received from the authentication service, which the GCS uses to determine whether the request is a legitimate request (as discussed above).

640 At block, the application receives the configuration information from the GCS. The configuration information generally includes information identifying a set of assets with which the diabetes intervention application is to be provisioned. As discussed, in one illustrative and non-limiting example, the set of assets may be determined based, at least in part, on location information included in the access token. Thus, the diabetes intervention application may be provisioned with assets that are appropriate for the geographic location associated with the user of the application and may not be provisioned with assets that are not supported in the geographic location associated with the user of the application.

650 At block, the application is configured based on the configuration application. For example, the diabetes intervention application can parse the configuration information to identify which features and feature settings to activate or deactivate and to identify the remote resources (e.g., URLs) with which the diabetes intervention application is allowed to communicate. Once configured, user interface features, aspects, pages, etc., associated with the activated features and the identified remote resources may be provided and displayed by the diabetes intervention application to the user (e.g., in response to user input, automatically, or through other mechanisms).

7 FIG. 1 2 FIGS.A and 700 140 illustrates example operationsthat may be performed by GCSillustrated in, to configure a diabetes intervention application, according to some embodiments described herein.

700 710 As illustrated, operationsmay begin at block, where the GCS receives, from a diabetes intervention application, a configuration request. The configuration request may, in some aspects, be a request for configuration information that can be used by the diabetes intervention application for enabling or disabling certain features, feature settings, and/or resources.

720 At block, the GCS validates that the access information included in the configuration request is valid. As discussed, valid access information may be access information that the GCS can decrypt into known or intelligible data or access information for which a matching authentication code can be generated.

730 At block, the GCS generates configuration information identifying a set of assets with which the diabetes intervention application is to be provisioned based on validating that the access information is valid. The configuration information may be generated based, at least in part, on the feature customization information included in the access information. For example, the configuration information may be generated based on location information included in the feature customization 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. In certain embodiments, the configuration information includes flags identifying features of the diabetes intervention application that are enabled and/or pointers (or links) to remote resources that the diabetes intervention application is to use during execution.

740 At block, the GCS transmits the configuration information to the diabetes intervention application to configure the diabetes intervention application with the set of assets indicated by the configuration information. As discussed, the diabetes intervention application is generally configured by the GCS transmitting the configuration information to the diabetes intervention application. The diabetes intervention application can parse the configuration information included in the parseable file to identify which features and feature settings to activate or deactivate and to identify the remote resources (e.g., URLs) with which the diabetes intervention application is allowed to communicate.

107 Note that in certain embodiments described above, an application, such as the diabetes intervention application, is downloaded on a user device (e.g., mobile device) and is later configured using the configuration information generated by the GCS. However, in certain other embodiments, when the user accesses the application store, a single, unified binary of the diabetes intervention application is not downloaded at that time on to the user device. In such embodiments, feature customization information is transmitted to the GCS, causing the GCS to map the feature customization information to a set of assets for the user. In such embodiments, instead of generating and transmitting configuration information to the application, the GCS transmits (directly or indirectly) the mapped set of assets to the user device, which downloads and executes the set of assets (corresponding to an application that is customized based on the user specifications).

8 FIG. 1 2 FIGS.and 800 800 130 140 illustrates an example systemfor authenticating and configuring an application. For example, systemmay correspond to one or more of the authentication serviceand/or GCSillustrated in.

800 802 804 814 800 806 800 890 808 812 As shown, systemincludes a central processing unit (CPU), one or more I/O device interfacesthat may allow for the connection of various I/O devices(e.g., keyboards, displays, mouse devices, pen input, etc.) to the system, network interfacethrough which systemis connected to network(which may be a local network, an intranet, the internet, or any other group of computing devices communicatively connected to each other), a memory, and an interconnect.

802 808 802 808 812 802 804 806 808 802 CPUmay retrieve and execute programming instructions stored in the memory. Similarly, the CPUmay retrieve and store application data residing in the memory. The interconnecttransmits programming instructions and application data, among the CPU, I/O device interface, network interface, and memory. CPUis included to be representative of a single CPU, multiple CPUs, a single CPU having multiple processing cores, and the like.

808 808 820 830 840 850 820 820 Memoryis representative of a volatile memory, such as a random access memory, and/or a non-volatile memory, such as nonvolatile random access memory, phase change random access memory, or the like. As shown, memoryincludes an account generator, credential verifier, application configurer, and configuration data repository. Account generatorgenerally receives requests to create user accounts for a diabetes intervention application and creates records in a user repository including, for each user of the application, at least user credentials and user location information that can be used to determine a configuration of the diabetes intervention application for the user. In some aspects, account generatorcan additionally include, in a 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 relevant to a configuration of the application.

830 820 840 830 Credential verifiergenerally receives login requests from an application executing on a mobile device and verifies that the credentials included in the received login requests match the credentials included in records generated by account generator. If the user credentials included in a received login request are determined to be valid, credential verifier generates an access token including information that application configurercan use to configure the application. Credential verifierthen provides the generated access token to the application executing on the mobile device.

840 850 840 850 Application configurerreceives configuration requests from the application and uses the access token included in a configuration request and information stored in configuration data repositoryto configure the application. Generally, to configure the application, application configurercan search for configuration data from configuration data repositorybased at least on 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 with which the application can communicate and flags identifying whether assets in the application are enabled or disabled. The parseable file is then transmitted to the application for further processing, which results in the application being configured with assets that are appropriate for the location associated with the user of the application.

Accordingly, certain embodiments described herein provide a technical solution to a technical problem in the technical field of personalizing software application configuration based on user information (e.g., feature customization information). For example, certain embodiments relate to deploying a single, unified collection of available assets (e.g., features, feature settings, and/or resources) 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, a large amount of storage resources may be freed and used for other purposes if a single application binary and codebase are stored and maintained, as opposed to many different ones with overlapping code. In addition, significantly less computing resources may be spent when updating, compiling, and debugging a single application binary and a single codebase, as opposed to many application binaries and codebases. Further, maintaining a single codebase reduces the likelihood of introducing errors into the code during code updates or resolving errors in some, but not all, versions of the application.

Further, as discussed above, some applications may be safety critical applications for which regulatory approval is needed before features are made available to users in a given location (e.g., to ensure that the new features do not harm patients using the software application, that the new features comply with security requirements or best practices, etc.). New features in a safety critical application may be approved in some regions earlier than in other regions. Thus, in deploying a new feature in a safety critical application, a developer can choose to deploy different versions of an application, with versions including the new feature being deployed in regions where regulatory approval has been obtained and versions excluding the new feature being deployed in regions where regulatory approval has not been obtained. When multiple codebases exist for multiple versions of an application, additional complexity may be introduced by adding new features in a piecemeal fashion (e.g., as features are approved by the relevant regulatory authorities).

Further, utilizing the systems, methods, and techniques described herein allow for customizing a diabetes intervention application for a user based on the user's specifications. An application with functionalities, features, feature settings, and resources that are customized to a user's unique preferences and needs will provide a more personalized experience and be much more useful, beneficial, and engaging to a user, thereby helping improve the user's health.

Each of these non-limiting examples can stand on its own or can be combined in various permutations or combinations with one or more of the other examples. The above detailed description includes references to the accompanying drawings, which form a part of the detailed description. The drawings show, by way of illustration, specific embodiments in which the invention can be practiced. These embodiments are also referred to herein as “examples.” Such examples can include elements in addition to those shown or described. However, the present inventors also contemplate examples in which only those elements shown or described are provided. Moreover, the present inventors also contemplate examples using any combination or permutation of those elements shown or described (or one or more aspects thereof), either with respect to a particular example (or one or more aspects thereof), or with respect to other examples (or one or more aspects thereof) shown or described herein.

In the event of inconsistent usages between this document and any documents so incorporated by reference, the usage in this document controls.

In this document, the terms “a” or “an” are used, as is common in patent documents, to include one or more than one, independent of any other instances or usages of “at least one” or “one or more.” In this document, the term “or” is used to refer to a nonexclusive or, such that “A or B” includes “A but not B,” “B but not A,” and “A and B,” unless otherwise indicated. In this document, the terms “including” and “in which” are used as the plain-English equivalents of the respective terms “comprising” and “wherein.” Also, in the following claims, the terms “including” and “comprising” are open-ended, that is, a system, device, article, composition, formulation, or process that includes elements in addition to those listed after such a term in a claim are still deemed to fall within the scope of that claim. Moreover, in the following claims, the terms “first,” “second,” and “third,” etc. are used merely as labels, and are not intended to impose numerical requirements on their objects.

Geometric terms, such as “parallel”, “perpendicular”, “round”, or “square”, are not intended to require absolute mathematical precision, unless the context indicates otherwise. Instead, such geometric terms allow for variations due to manufacturing or equivalent functions. For example, if an element is described as “round” or “generally round”, a component that is not precisely circular (e.g., one that is slightly oblong or is a many-sided polygon) is still encompassed by this description.

Method examples described herein can be machine or computer-implemented at least in part. Some examples can include a computer-readable medium or machine-readable medium encoded with instructions operable to configure an electronic device to perform methods as described in the above examples. An implementation of such methods can include code, such as microcode, assembly language code, a higher-level language code, or the like. Such code can include computer readable instructions for performing various methods. The code may form portions of computer program products. Further, in an example, the code can be tangibly stored on one or more volatile, non-transitory, or non-volatile tangible computer-readable media, such as during execution or at other times. Examples of these tangible computer-readable media can 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 memories (RAMs), read only memories (ROMs), and the like.

The above description is intended to be illustrative, and not restrictive. For example, the above-described examples (or one or more aspects thereof) may be used in combination with each other. Other embodiments can be used, such as by one of ordinary skill in the art upon reviewing the above description. The Abstract is provided to comply with 37 C.F.R. §1.72(b), to allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. Also, in the above Detailed Description, various features may be grouped together to streamline the disclosure. This should not be interpreted as intending that an unclaimed disclosed feature is essential to any claim. Rather, inventive subject matter may lie in less than all features of a particular disclosed embodiment. Thus, the following claims are hereby incorporated into the Detailed Description as examples or embodiments, with each claim standing on its own as a separate embodiment, and it is contemplated that such embodiments can be combined with each other in various combinations or permutations. The scope of the invention should be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.