Adaptively generating personalized schedules for delivering messages to user using machine learning model

Abstract

Aspects of the present disclosure relate to systems and methods for dynamically generating an individualized or personalized time for providing messages over a networked environment. The computing system may obtain a set of event data regarding a user device that identifies a plurality of interaction times corresponding to a plurality of interactions performed by a user with an application on the user device for addressing a condition of the user over an instant time window. The computing system may apply the event data set to a machine learning (ML) model. The computing system may generate a prescribed time to provide messages to the user equipment during a subsequent time window based on applying the event data set to the ML model. The computing system may provide a message according to the specified time for presentation on the user device to address a condition of the user.

Description

[0001] Cross-reference to related applications

[0002] This application claims priority to U.S. non-provisional application No. 18 / 756,322, filed June 27, 2024, entitled “ADAPTIVE GENERATION OF PERSONALIZED SCHEDULE FOR DELIVERY OF MESSAGES TO USERS USING MACHINELEARNING MODELS”, the entire contents of which are incorporated herein by reference. Background Technology

[0003] Under the guidance of a clinician, a patient with a medical condition may participate in a medical treatment plan to address the symptoms or cause of that condition. However, poor adherence to such treatment plans can be a serious problem in healthcare. Patients may find it difficult to stick to the plan, resulting in a lack of improvement in their condition, and increasing costs for clinicians due to monitoring, as well as for patients due to the extra effort required to adhere to the plan. A method is needed to improve patient adherence and ultimately impact clinical outcomes. Digital therapy may offer some hope for addressing the problems associated with treatment adherence. In digital therapy, messages can be sent and displayed to the user's mobile device as part of an evidence-based treatment intervention, delivered directly to the user. These messages may include digital therapy content (e.g., in the form of text, audio, or visual content) prompting the user to perform activities to further address symptoms or indications. Users can be guided to respond to these messages by performing actions and interacting with their devices.

[0004] However, one of the technical challenges of digital therapy may be choosing the optimal time to transmit and display messages on the user's device. This challenge can be exacerbated by the fact that the optimal time can depend on a variety of factors, such as the user, the condition, the type of message being sent, and the specific digital therapy intervention. Sending and displaying messages at a suboptimal time may result in the user being unable to interact on their device. Suboptimal times can lead to a waste of computing resources (such as processing and memory) on the user's device and servers, as well as network bandwidth for message transmission. This can be exacerbated when an application programming interface (API) provided by another service imposes communication capacity limits. Each message transmission may call the API and consume some capacity, resulting in a drain on computing resources. Furthermore, if the user does not respond to the message at all, computing resources may be wasted and inefficiently allocated. Repeatedly displaying messages at a suboptimal time can also create a message blind spot on the user's side, where overexposure can cause the user to become desensitized or unresponsive to messages. Therefore, message blind spots can lead to a decline in the quality of human-computer interaction between the user and their device.

[0005] Beyond this technical challenge, for therapeutic interventions to effectively address a user's symptoms, the user must interact with the message to perform activities prompted via their device. Delivering the message at the next best time may reduce or worsen the effectiveness of the therapeutic intervention. Furthermore, message blind spots may lead to decreased user adherence to digital therapy, manifested as less or no interaction in response to the message. This can significantly impact the user's condition and potentially prolong symptoms. It may also waste computational resources and network bandwidth. Addressing this technical challenge might involve prompting the user to indicate their preference for the timing of the message before receiving it. However, these methods may not readily adapt to changes in when a user is most likely to respond to the message and further rely on the user's self-reported or self-awareness of the optimal time, which can be inaccurate. Therefore, this approach may not solve the technical problem of delivering messages at the next best time. Summary of the Invention

[0006] This paper introduces a system and method for adaptively generating personalized message delivery schedules to users using machine learning models, with the goal of maximizing user engagement and managing user symptoms. Delivering messages through the messaging service disclosed in this paper offers numerous benefits to users of digital therapy applications. First, by delivering messages to users at optimal times, the performance and effectiveness of therapy solutions in managing user symptoms are significantly improved. This optimal timing reduces the likelihood of message fatigue, ensuring users remain focused and engaged when receiving messages on their devices. Consequently, users are more likely to adhere to prescribed activities and treatment plans. This adherence significantly enhances the overall effectiveness of interventions.

[0007] Second, the messaging service leverages machine learning models to dynamically adjust messaging schedules at both the group and individual levels, thereby enhancing user experience and intervention effectiveness. At the group level, the machine learning model categorizes users into different groups based on similar behaviors in response to digital therapy content. Individual user activity data is then mapped to these groups to deliver messages to new users exhibiting similar behavior at the optimal time. This approach ensures that even new users receive messages at the time when a positive response is most likely, based on the behavioral patterns of their assigned group. At the individual level, the machine learning model personalizes the messaging schedule by continuously analyzing and adapting to each user's unique behavioral patterns. As more data is collected, the model refines the schedule to optimize message delivery timing, ensuring messages are sent when users are most likely to engage. This personalization approach eliminates the biases and inaccuracies that can arise from relying solely on user-indicated preferences, resulting in more effective and timely interventions.

[0008] Third, the messaging service collects event data during the onboarding process and throughout the treatment course to adaptively generate optimal schedules using machine learning models. This addresses the challenge of limited initial behavioral data at the start of treatment by utilizing new data to determine the optimal time to deliver messages to each user. Even as user behavior and preferences change during treatment, the messaging service continuously updates and personalizes the delivery schedule to remain responsive. By leveraging this data-driven approach in conjunction with machine learning techniques, the messaging service can provide users with efficient, personalized interventions, thereby improving health outcomes while reducing treatment time. Therefore, the messaging service represents an advancement compared to methods that rely on user-indicated preferences.

[0009] Fourth, messaging simplifies the use of machine learning models, offering a significant improvement over other methods that require continuous monitoring of user activity and repeated calls to identify opportunities to send messages. These other methods involve an agent or module that continuously tracks user actions to determine the optimal time to send a message when events are anticipated on the user's device. This approach not only requires a continuous network connection to the user's device but also places a heavy burden on computational resources, especially when computationally complex models need to be repeatedly called to determine when to send messages. This problem can be exacerbated when application programming interface (API) imposes call or communication constraints. In contrast, messaging services can invoke timed models to process batches of interaction data collected over specific time periods, thereby generating a schedule. This approach minimizes the frequency of model calls, effectively reducing the computational demands on the service and the consumption of network bandwidth. By limiting the number of times the model is invoked during user treatment, messaging services can conserve computational resources and improve treatment outcomes by providing timely and relevant communication.

[0010] To this end, messaging services can use timing models to generate and select optimal schedules to deliver messages with digital therapeutic content at the times when users are most likely to interact with the messages, thereby addressing the user's symptoms. The messaging service can train the timing model using a training dataset comprising a set of examples. Each example may include an event dataset. The event dataset may include a set of times corresponding to user interactions with the user's device in response to the display of a message. These messages may be provided based on a sample schedule. The timing model may be, for example, a clustering model with a feature space whose dimensions correspond to interaction times, etc. The messaging service can generate feature vectors using the interaction times of the event dataset for each example in the training data. After mapping the feature vectors to the dimensions of the feature space, the messaging service can perform cluster analysis to generate a set of regions within the feature space of the timing model. Each region may correspond to a group of users with similar behavioral patterns and can be used to define the timing of message delivery.

[0011] When a user first interacts with a digital therapy app during the onboarding process, the messaging service receives an initial set of information about the user. For example, this initial information may include the user's indicated time preferences. Using this initial information, the messaging service can identify groups whose behavioral patterns most closely resemble the user's preferences. Based on these identified groups, the messaging service can select a launch schedule. This launch schedule defines a set of times during which appropriate messages (e.g., short-messaging service, multimedia messaging service, or in-app messages) will be delivered to the user's device. This set of times can span a period of time (e.g., 3 days to 1 month).

[0012] According to the launch schedule, the messaging service can send messages to the user device for display. After display, the user device can monitor interactions with the digital therapy application. Using interactions aggregated within the time period of the schedule, the user device can generate an event dataset that identifies a set of times when users interacted with the application during the message display. The user device can then send the event dataset and aggregated interactions to the messaging service. The messaging service can then generate feature vectors to map to the dimensions of the feature space of the timing model. By mapping the feature vectors, the messaging service can identify which region the feature vectors belong to. Based on the identified region, the messaging service can determine the time (e.g., the centroid corresponding to the region) for each message to be included in the user's new schedule. This new schedule can define a set of times for delivering the corresponding messages to the user device.

[0013] In addition, the messaging service can determine a confidence score for the new schedule. If the confidence score meets a threshold, the messaging service can use the new schedule to deliver messages to the user device. This new schedule can be user-specific. Otherwise, if the confidence score does not meet the threshold, the messaging service can identify a group with a behavioral pattern most similar to the behavioral pattern determined from the user event dataset. The messaging service can then select another schedule associated with that group to deliver messages to the user device. As more event data is collected from user devices, the messaging service can generate schedules with higher confidence values. The messaging service can also create timing model instances for users to generate personalized schedules.

[0014] In this way, messaging services can use timing models to generate schedules to deliver messages at the optimal times when users are most likely to interact with digital therapy applications. By delivering messages at optimal times, messaging services can reduce and conserve computational resources (such as processors and memory) and network bandwidth that would otherwise be wasted on unresponsive messages. Messaging services can also improve the efficiency of these resource allocations by limiting message delivery to the times when users are most likely to interact. Compared to methods that rely on continuous communication and invocation models, messaging services can reduce the frequency of invoking timing models during digital therapy interventions, thus saving computational resources for other processes. From the user's perspective, delivering messages at optimal times according to a schedule reduces messaging blind spots, thereby improving the quality of human-computer interaction (HCI) between the user and the application. Furthermore, messaging services can improve user adherence to digital therapies delivered in message form, thereby improving the user's condition.

[0015] This disclosure relates to systems and methods for generating the timing of messages delivered via a networked environment. One or more processors coupled to memory can acquire an event dataset about a user device, which identifies multiple interaction times corresponding to multiple interactions performed by the user and an application on the user device within an immediate time window to address the user's symptoms. The one or more processors can apply the event dataset to a machine learning (ML) model. The ML model can be built using a training dataset comprising multiple examples. Each of the multiple examples may include a corresponding event dataset that identifies corresponding multiple interaction times corresponding to corresponding multiple interactions performed by the corresponding user and a corresponding application on the corresponding user device within a corresponding time window. At least one of these corresponding multiple interactions may be detected in response to the delivery of one or more messages.

[0016] One or more processors can generate a predetermined time to deliver a message to the user device during a subsequent time window by applying an event dataset to an ML model. The one or more processors can then deliver the message according to this predetermined time so that it can be displayed on the user device to address the user's symptoms.

[0017] In some embodiments, the ML model may include a clustering model that defines multiple clusters built using multiple samples. In some embodiments, each of the multiple clusters corresponds to a corresponding subset of multiple interaction times. In some embodiments, each of the multiple clusters is associated with a corresponding specified time of a corresponding message among multiple messages provided within a set time window. In some embodiments, one or more processors may compare multiple interaction times of a user's event dataset with one or more of the multiple clusters of the clustering model. In some embodiments, one or more processors may identify a cluster from the multiple clusters that corresponds to at least one of the multiple interaction times. In some embodiments, one or more processors may use the corresponding specified time of the cluster as the specified time.

[0018] In some embodiments, one or more processors may compare multiple interaction times of a user's event dataset with one or more clusters of a clustering model. In some embodiments, one or more processors may identify cluster subsets from multiple clusters for corresponding subsets of multiple interaction times. In some embodiments, one or more processors may use the corresponding specified time of each cluster in the cluster subset as multiple specified times of a timetable.

[0019] In some embodiments, one or more processors may generate a schedule that identifies the corresponding message type of a plurality of messages to be provided to a user device for each of a plurality of specified times. In some embodiments, at least one of a plurality of samples in the training dataset may identify at least one of the following: (i) a corresponding schedule that identifies the corresponding plurality of specified times for providing the corresponding plurality of messages to the corresponding user device within a set time window; or (ii) a corresponding indication as to whether the corresponding schedule increases the corresponding response rate of the corresponding plurality of interactions by at least one threshold.

[0020] In some embodiments, one or more processors may generate a score indicating confidence in a specified time based on applying an event dataset to an ML model. In some embodiments, the one or more processors may determine that the specified time will be used to provide a message to a user device in response to the score meeting a threshold. In some embodiments, the one or more processors may receive a subsequent event dataset that identifies subsequent interaction times corresponding to subsequent interactions between the user and the application in response to the provision of at least one of a plurality of messages within a subsequent time window. In some embodiments, the one or more processors may update the ML model using the subsequent event dataset and the specified time.

[0021] In some embodiments, one or more processors may select a launch schedule in response to identifying a lack of prior event data for the user, prior to acquiring an event dataset. This launch schedule identifies initial multiple predetermined times within an initial time window for providing initial multiple messages to the user device. In some embodiments, one or more processors may provide initial multiple messages according to the initial multiple predetermined times of the launch schedule for display on the user device. In some embodiments, one or more processors may acquire an event dataset identifying multiple interaction times corresponding to multiple interactions performed by the user with the application in response to the display of at least one of the initial multiple messages of the launch schedule.

[0022] In some embodiments, one or more processors may determine a user's category from multiple categories based on one or more event datasets. In some embodiments, each of the multiple categories may be associated with a corresponding behavioral pattern. In some embodiments, one or more processors may identify a launch schedule based on the category determined for the user. The launch schedule may identify initial multiple scheduled times for providing initial multiple messages to the user's device. In some embodiments, the event dataset may include at least one of the following: (i) health indicators associated with the user's condition, (ii) the interaction rate of multiple interactions within an immediate time window, or (iii) characteristic messages associated with the user, at least one of the multiple interactions corresponding to an interaction with the application, regardless of the delivery of any messages. In some embodiments, the messages include at least one of Short Message Service (SMS) messages, Multimedia Messaging Service (MMS) messages, in-app messages, or chatbot messages, wherein the messages will be displayed to the user at least for a portion of the time the user is taking medication to resolve their condition. Attached Figure Description

[0023] The above and other objects, aspects, features and advantages of this disclosure will become more apparent and better understood with reference to the following description taken in conjunction with the accompanying drawings.

[0024] Figure 1 A system block diagram is described, illustrating an illustrative embodiment of adaptively generating the desired time for message delivery via a digital therapy application.

[0025] Figure 2 A flowchart describing the process of training a machine learning (ML) model according to an illustrative embodiment to generate the desired time for message delivery through a digital therapy application is provided.

[0026] Figure 3 A flowchart describing a process for accessing a database to retrieve an initial desired time to generate a schedule for delivering messages to users via a digital therapy application, according to an illustrative embodiment, is provided.

[0027] Figure 4A flowchart describing a process for acquiring an event dataset from a digital therapy application to generate a new schedule by applying an illustrative embodiment is provided.

[0028] Figure 5 A flowchart describing a process for updating an ML model according to an illustrative embodiment is provided, which involves providing messages based on a new schedule to obtain a dataset of subsequent events.

[0029] Figure 6 A visualization example of an event dataset according to an illustrative embodiment is described.

[0030] Figure 7 A process diagram describing an adaptive method for generating the desired time for message delivery via a digital therapy application, according to an illustrative embodiment; and

[0031] Figure 8 A block diagram of a server system and a client computer system according to an illustrative embodiment is described. Detailed Implementation

[0032] To facilitate reading the following description of the various embodiments, the following sections of this specification and their corresponding contents will be helpful:

[0033] Part A describes a system and method for adaptively generating and delivering messages to address user symptoms; and

[0034] Part B describes a networking and computing environment that may facilitate the implementation of the embodiments described herein.

[0035] A. Systems and methods for adaptively generating and delivering messages to address user symptoms on a schedule.

[0036] Now for reference Figure 1The figure illustrates a block diagram of a system 100 that adaptively generates and delivers messages to address symptoms. In summary, system 100 may include at least one session management service 105, a group of user devices 110A-N (collectively referred to as user devices 110), and a database 120, which are communicatively coupled to each other via at least one network 115. At least one of the user devices 110 (as shown in the figure, the first user device 110A) may include at least one application 125. Application 125 may include or provide at least one user interface 130 having one or more user interface (UI) elements 135A-N (collectively referred to as UI elements 135). Session management service 105 may include at least one model trainer 140, at least one interaction evaluator 145, at least one schedule manager 150, at least one message passer 155, and at least one timing model 165, etc. Session management service 105 may include or access at least one database 120. The functionality of application 125 on user device 110 may be partially executed on session management service 105, and vice versa. Each component of system 100 can be implemented using the computing system described in Part B.

[0037] More specifically, the session management service 105 (sometimes collectively referred to herein as a messaging service, service, or server) can be any computing device, including one or more processors coupled to memory and software, capable of performing the various processes and tasks described herein. The session management service 105 can communicate with one or more user devices 110 and database 120 via network 115. The session management service 105 may originate from or reside in at least one computer system, or be otherwise associated with it. The computer system may correspond to a data center, branch office, or site, where one or more computers corresponding to the session management service 105 are located.

[0038] On the session management service 105, the model trainer 140 can train, improve, or update the timing model 165 related to messages provided by the session management service to users of application 125. The interaction evaluator 145 can evaluate interactions in the event dataset and transmit indications to the schedule manager 150. The schedule manager 150 can extract and transmit schedules from or to various components of system 100. The message passer 155 can transmit messages to user device 110 according to the schedule. The timing model 165 can be any machine learning model used to estimate or predict the time and date of user interaction with application 125 on user device 110. The timing model 165 can be any clustering algorithm or model used to perform cluster analysis on response data related to user-performed activities. Clustering models can include, for example, hierarchical clustering (e.g., linked clustering), centroid-based clustering (e.g., k-means), distribution-based clustering (e.g., Gaussian mixture model), and density-based clustering (e.g., density-based spatial clustering or DBSCAN), etc. The timing model 165 can be specific to a given user or user group.

[0039] User equipment 110 (sometimes referred to herein as an end-user computing device) can be any computing device, including one or more processors coupled to memory and software, capable of performing the various processes and tasks described herein. User equipment 110 can communicate with session management service 105 and database 120 via network 115. User equipment 110 can be a smartphone, other mobile phone, tablet, wearable computing device (such as a smartwatch, glasses), or laptop. User equipment 110 can be used to access application 125. In some embodiments, application 125 can be downloaded and installed on user equipment 110 (e.g., via a digital distribution platform). In some embodiments, application 125 can be a web application whose resources are accessible via network 115.

[0040] Application 125 running on user device 110 may be a digital therapy application. Application 125 may present or provide a session (sometimes referred to herein as a therapy session) to address at least one of the user's conditions. The end-user's conditions may include, for example, chronic pain (e.g., related to or including arthritis, migraine, fibromyalgia, back pain, Lyme disease, endometriosis, repetitive stress injury, irritable bowel syndrome, inflammatory bowel disease, and cancer pain), dermatopathologies (e.g., atopic dermatitis, psoriasis, pruritus, and eczema), cognitive impairments (e.g., mild cognitive impairment (MCI), Alzheimer's disease, multiple sclerosis, and schizophrenia), mental illnesses (e.g., affective disorders, depression, bipolar disorder, obsessive-compulsive disorder, borderline personality disorder, and attention deficit / hyperactivity disorder), substance use disorders (e.g., opioid use disorder, alcohol use disorder, or tobacco use disorder), and other conditions (e.g., narcolepsy and tumors or cancer).

[0041] End users may use Application 125 concurrently with medications they are taking or given to manage their condition (e.g., any number of sessions). For example, if medication is for pain relief, the end user may be taking acetaminophen, a nonsteroidal anti-inflammatory drug (NSAID), an antidepressant, an anticonvulsant, or another combination. For skin conditions, the end user may be taking steroids, antihistamines, or antibiotics. For cognitive impairment, the end user may be taking cholinesterase inhibitors or memantine. For mental illness, the end user may be taking antidepressants, mood stabilizers, antipsychotics, or anti-anxiety medications. For substance abuse, the end user may be taking naltrexone, disulfiram, acamprine, or nicotine replacement therapy. Application 125 can enhance the effectiveness of the medications the user is taking to manage their condition.

[0042] End users can also participate in other psychotherapies targeting these conditions. In some embodiments, digital therapy content may be provided to the end user within a digital therapy application to achieve the end user's endpoint. The endpoint may be, for example, the end user's physical or behavioral goals, completion of a medication regimen, or an endpoint instructed by a doctor or the end user. At least one of the end user devices 110 may have a digital therapy application and may provide therapy sessions (sometimes referred to herein as therapy sessions) to address at least one condition of the end user.

[0043] Database 120 can store and maintain various resources and data related to session management service 105 and application 125. Database 120 may include a database management system (DBMS) to arrange and organize the data maintained therein, such as user profiles 170 and training data 175. Database 120 can communicate with session management service 105 and one or more user devices 110 via network 115. During various operations, session management service 105 and application 125 can access database 120 to retrieve identified data. Session management service 105 and application 125 can also write data to database 120 by performing such operations.

[0044] On database 120, each user profile 170 (sometimes referred to herein as a user account, user message, or subject profile) can store and maintain messages related to the user of application 125 via user device 110. Each user profile 170 can be associated with or correspond to a corresponding user of application 125. User profile 170 can identify various information about the user, such as user identifier, ailment to be addressed, information about the user's sessions (e.g., completed activities or courses), message preferences, user characteristic information, and progress status of ailment resolution (e.g., completion status of endpoints), etc. Information about sessions may include various parameters (initially possibly empty) of sessions previously performed by the user. Message preferences may include treatment preferences and user input preferences, such as preferred message type or message time. Message preferences may also include preferences determined by session management service 105, such as the type of message the user can respond to. Progress may initially be set to a starting value (e.g., empty or "0") and may correspond to the reduction, relief, or treatment of the ailment. User profile 170 can be continuously updated via application 125 and session management service 105.

[0045] In some embodiments, user profile 170 may identify or include information about the treatment regimens taken by the user, such as treatment type (e.g., therapy, medication, or psychotherapy), duration (e.g., days, weeks, or years), and frequency (e.g., daily, weekly, quarterly, annually). User profile 170 may include an activity log of at least one message provided to the user, interactions that identify specific user performance by the user, and responses from user devices 110 associated with the user. User profile 170 may be stored and maintained in database 120 using one or more files (e.g., Extensible Markup Language (XML), comma-separated value (CSV) delimited text files, or Structured Query Language (SQL) files).

[0046] Database 120 can store and maintain a set of messages from application 125 for addressing a user's symptoms. Each message may include digital therapeutic content. Messages may be transmitted, sent, or otherwise provided to user device 110 for display by session management service 105. The messages themselves may be in any format. In some embodiments, at least one message may be a Short Message Service (SMS) message. SMS messages may include text of a set length (such as an alphanumeric character limit) for transmission over a cellular network. In some embodiments, at least one message may be a Multimedia Messaging Service (MMS) message. MMS messages may include multimedia content such as text, images, video, or audio. In some embodiments, at least one message may be an in-app message. In-app messages may include instructions to display multimedia content (e.g., text, images, video, or audio content, or any combination thereof) through UI elements of the user interface of application 125. The instructions may identify or specify one or more UI elements to be presented, displayed, or otherwise presented in the user interface of application 125.

[0047] The digital therapeutic content of a message can be in any format, such as text, images, audio, video, or multimedia content, or any combination thereof. Messages can be stored and saved in database 120 through one or more files. For example, for text, digital therapeutic content can be stored as a text file (TXT), a rich text file (RTF), Extensible Markup Language (XML), and Hypertext Markup Language (HTML), etc. For images, digital therapeutic content can be stored as Joint Photographic Experts Group (JPEG) format, Portable Web Graphics (PNG) format, Graphics Interchange Format (GIF), or Scalable Vector Graphics (SVG) format, etc. For audio, digital therapeutic content can be stored as waveform audio files (WAV), Moving Picture Experts Group (MP3 and MP4) formats, and Ogg Vorbis (OGG) format, etc. For video, digital therapeutic content can be stored as Moving Picture Experts Group (MP3 and MP4) formats, QuickTime Movie (MOV), and Windows Movie Video (WMV), etc. For multimedia content, digital therapy content can be audio-video interleaved (AVI), moving picture expert group formats (such as MP3 and MP4), QuickTime Movie (MOV), and Windows Movie Video (WMV), etc.

[0048] In some embodiments, the digital therapeutic content of a message may include a set of stimuli (e.g., in audio, visual, or text form) for the user to perform a specific task. Tasks may include, for example, implicit association tasks (IAT) (e.g., associating stimuli with concepts); attention bias correction training (ABMT) (e.g., training a user to shift their attention away from certain stimuli); emotional face memory tasks (EFMT) (e.g., testing a user to recognize and remember certain facial expressions); digital support tools (DST) (e.g., providing messages based on the user's state); adaptive goal setting (AGS) (e.g., providing messages based on the user's dynamic goals), and so on. Although this document describes messages as digital therapeutic content, messages may include other types of content.

[0049] Now for reference Figure 2 The diagram illustrates a block diagram of a process 200 for training a timing model 165 to generate the desired timing for message delivery via a digital therapy application. Process 200 may include or correspond to operations performed by system 100 for training the timing model 165. In process 200, a model trainer 140 may train, initiate, or otherwise establish the timing model 165. The model trainer 140 may train the timing model 165 according to its architecture. For example, when the timing model 165 is a clustering model, training may be performed iteratively until clustering converges, the clustering results are appropriate, the algorithm converges, or post-training validation is completed based on the learning of the clustering model. Training data 175 may be accessed, retrieved, or otherwise obtained from database 120.

[0050] Training data 175 may include a set of examples for training timing model 165. This set of examples may be constructed or generated using historical data from interaction and messaging schedules. For each example, training data 175 may include at least one sample event dataset 205. Sample event dataset 205 may include a set of times 220A-N (collectively referred to as interaction times 220) and a set of interactions 225A-N (collectively referred to as interactions 225). Each interaction time 220 may identify a time of day, a day of week, or a date (e.g., year, month, day) related to the associated interaction 225. In some embodiments, interaction time 220 may be associated with another established reference time, such as the start time of treatment (e.g., the initial use time of application 125) or the start time of a week (e.g., Sunday or Monday). This set of times 220 may span a time window between 3 hours and 3 months. Interaction 225 can identify the type of interaction (e.g., mouse click, screen swipe, hover, tilt, or screen touch), the type of activity (e.g., performed by user 302 and recorded by application 125), and indications about whether the activity has been performed, etc.

[0051] Sample event dataset 205 may include health metrics related to a user's condition. Health metrics can represent the current user's health status relative to the condition (e.g., symptoms or severity). For example, a user who has not made progress in application 125 may have low health metrics. Sample event dataset 205 may have an interaction rate for this set of interactions 225. The interaction rate can identify the frequency of interactions 225 within the duration of this set of times 220. Sample event dataset 205 may include user-related characteristic information. Characteristic information may identify or include age, location, or device type, etc. In some embodiments, at least one of these interactions 225 may correspond to an interaction with application 125, regardless of the provision of any messages. For example, sample event dataset 205 may include interactions 225 of a user corresponding to logging into application 125.

[0052] In some embodiments, training data 175 may include at least one sample timetable 210. Sample timetable 210 may identify a set of delivery times 230A-N (collectively referred to as delivery times 230) and a set of messages 235A-N (collectively referred to as messages 235). Each message 235 may have been previously transmitted on its corresponding delivery time 230. Each delivery time 230 may identify a time of day, a day of week, or a date (e.g., year, month, day) related to the associated message 235. This set of delivery times 230 may span a time window between 6 hours and 3 months. Sample timetable 210 may be associated with a sample event dataset 205. For example, at least some interactions 225 in the sample event dataset 205 may be responses to the display of message 235. For each delivery time 230, sample timetable 210 may identify a message type or message identifier (e.g., referring to a specific message). Message 235 may include at least one of Short Message Service (SMS) messages, Multimedia Messaging Service (MMS) messages, in-app messages, or chatbot messages.

[0053] In some embodiments, training data 175 may include an indication 215. Indicator 215 may be associated with sample event dataset 205 and sample timetable 210. Indicator 215 may identify whether sample timetable 210 causes an increase (or decrease) in the interaction rate in a set of interactions 225 of sample event dataset 205. The increase in interaction rate may reach at least a threshold. In some embodiments, model trainer 140 may select samples (including sample event dataset 205 and sample timetable 210) from training data 175 based on indication 215. When the increase in interaction rate meets (e.g., is greater than or equal to) the threshold, model trainer 140 may select the sample for training timing model 165. Otherwise, when the increase in interaction rate does not meet (e.g., is less than) the threshold, model trainer 140 may not use the sample to train timing model 165.

[0054] Using training data 175, model trainer 140 can initiate, train, and build a timing model 165. The timing model 165 can include at least one feature space 250. Feature space 250 can be an n-dimensional space where each feature vector 265A-N (hereinafter collectively referred to as feature vector 265) can be defined, referenced, or mapped. Dimensions of feature space 250 can include, for example, interaction 225 or interaction time 220. Each feature vector 265 can be a data point corresponding to at least one interaction time 220 in which a user interacts with application 125. In some embodiments, each feature vector 265 can be a data point corresponding to interaction time 220, interaction 225, delivery time 230, and message 235, or any combination thereof. For example, the dimension of feature vector 265 can correspond to the delivery time 230 of a given message 235, the interaction 225 in response to the display of message 235, and the interaction time 220. Time-related dimensions can include a range of values ​​for a time window (e.g., 6 hours to 3 months) related to the sample event dataset 205 or sample timetable 210. The eigenvector 265 may define or correspond to a set of n-dimensional coordinates in the feature space 250. The feature space 250 may define or otherwise include a set of clusters or centroids 260A-N (hereinafter collectively referred to as centroids 260). Each centroid 260 may correspond to a point in the n-dimensional feature space 250.

[0055] Next, this set of centroids 260 can be used to partition, label, or otherwise define a set of corresponding regions 255A-N (hereinafter collectively referred to as regions 255, and sometimes referred to herein as clusters) in the feature space 250. The number of centroids 260 and the number of regions 255 can be preset or pre-assigned to a value (e.g., a fixed value). For example, the number of centroids 260 and regions 255 can correspond to the number of different categories of users. Each region 255 can correspond to a portion of the feature space 250. Each region 255 can be associated with at least one delivery time, or can be used to determine at least one delivery time in which a corresponding message is provided within a time window. In some embodiments, each region 255 can correspond to a portion of the feature space 250 based on the distance of the associated centroid 260 in the feature space 250. The distance can be, for example, proximity to the centroid 260 that defines the corresponding region 255, expressed in terms of Euclidean distance or L-norm distance.

[0056] When establishing the timing model 165, the model trainer 140 can parse the sample event dataset 205 to identify a set of interactions 225 associated with interaction times 220. For each interaction 225, the model trainer 140 can generate data points as feature vectors 265 to be included in the feature space 250 of the timing model 165. The model trainer 140 can convert interaction times 220 into data points of feature vector 265. Feature vector 265 may include a set of coordinates in the feature space 250 corresponding to interaction times 220. In some embodiments, the model trainer 140 can convert interaction times 220, interactions 225, transmission times 230, and messages 235 into corresponding feature vectors 265. The feature vector 265 may include a set of coordinates in the feature space 250 corresponding to interaction times 220, interactions 225, transmission times 230, and messages 235. The model trainer 140 can generate feature vectors 265 and map feature vectors 265 into regions 255 of the feature space 250. While training the timing model 165, the model trainer 140 can repeatedly generate feature vectors 265 for each interaction 225 in the sample event dataset 205.

[0057] Using feature vectors 265, model trainer 140 can identify, generate, or otherwise determine a set of centroids 260 and a set of regions 255 in the feature space 250 of timing model 165. Since interactions 225 may be associated with daily interaction times 220, model trainer 140 can assign at least one centroid 260 corresponding to an interaction time 220 to the coordinates of feature vectors 265. Model trainer 140 can define regions 255 based on distances with respect to centroids 260 (e.g., proximity expressed as Euclidean distance or L-norm distance). Based on this, model trainer 140 can fine-tune and adjust timing model 165 by maintaining the set of interactions 225 and the interaction times 220 associated with each interaction (i.e., past and present). After training, model trainer 140 can store, generate, or identify associations between timing models 165.

[0058] With the creation of region 255, centroid 260, and feature vector 265 in feature space 250, timing model 165 can generate, determine, or otherwise create new centroids 260 in the corresponding region 255. The new centroids 260 may correspond to interaction 225 and be associated with a defined delivery time 230 to leverage the association between the user and timing model 165 to deliver message 235. In this way, timing model 165 can generate a prescribed time to deliver a message to the corresponding user. In some embodiments, timing model 165 may generate, create, or otherwise generate a schedule for the user based on region 255, centroid 260, and feature vector 265, identifying the message to be sent within a defined window. Based on this, model trainer 140 can compare the generated prescribed time with the delivery time 230 in sample schedule 210. Model trainer 140 can determine the degree of deviation based on the comparison. Model trainer 140 can use indicator 215 to identify whether the generated prescribed time increases the response rate corresponding to message 235 based on the degree of deviation. Using indicator 215, model trainer 140 can adjust region 255, centroid 260, and feature vector 265 to create a specified time with positive indicator 215, and repeat process 200 until the training of timed model 165 exceeds a threshold or each user has positive indicator 215.

[0059] In some embodiments, the model trainer 140 may use the feature space 250 of the timing model 165 to determine, create, or otherwise generate a set of categories 270A-N. Each category 270 may correspond to at least one region 255 (or cluster). Each category 270 may correspond to a user group (or cluster) that has similar behavioral patterns based on the interaction time 220 used to generate the feature vector 265. Each group may include one or more users who interact 225 at similar interaction times 220. For example, a first region 255A may correspond to category 270A where users interact when the message 235 is displayed in the morning. A second region 255B may correspond to another category 270B where users interact when the message 235 is displayed in the evening.

[0060] Now for reference Figure 3The diagram illustrates a block diagram of a process 300 involving accessing database 106 to retrieve interaction time 320 to generate a schedule 304 for delivering messages 306 to user 302 via a digital therapy application. Process 300 may include or correspond to operations performed by system 100 to provide messages using a startup schedule. Session management service 105 can generate, create, or otherwise establish at least one user profile 170 for each user 302 of application 125. Application 125 can display multiple questions, prompts, images, videos, etc., to the user to generate the user profile 170. For example, user 302 may specify a name, date of birth, initial time of receiving messages from application 125, user 302's symptoms, user 302's medications, etc. In some embodiments, a doctor may provide information related to user 302 to the corresponding user profile 170 of user 302. Based on this, application 125 can transmit user 302's information to session management service 105 to generate the corresponding user profile 170.

[0061] Using user profile 170, schedule manager 150 can identify or select at least one startup schedule 310 for user 302. Startup schedule 310 can be selected in response to any event data from user 302. Startup schedule 310 can be used by user 302 during the onboarding phase relative to application 125. Startup schedule 310 can include a set of delivery times 330A-N (collectively referred to as delivery times 330) and a corresponding set of messages 335A-N (collectively referred to as messages 335). Startup schedule 310 can instruct the delivery of at least one message 335 at delivery time 330. Each delivery time 330 can identify a time of day, a day of week, or a date (e.g., year, month, day) related to the associated message 335. This set of delivery times 330 can span a time window between 6 hours and 3 months. For each delivery time 330, startup schedule 310 can identify a message type or message identifier (e.g., referring to a specific message). Message 335 may include at least one of Short Message Service (SMS) messages, Multimedia Messaging Service (MMS) messages, in-app messages, or chatbot messages. Message 335 may be displayed to user 302 through application 125 or directly through user device 110. For example, message 335 may appear as a notification in application 125. In some embodiments, message 335 may be provided during a portion of the time that user 302 is taking medication to treat a symptom.

[0062] In some embodiments, the schedule manager 150 may access the database 120 to extract or identify a set of start schedules 310. Using user profiles 170, the schedule manager 150 may identify or otherwise select start schedules 310 associated with a user profile type corresponding to user profile 170 of user 302. Each start schedule 310 may be associated with a user profile type. In operation, the schedule manager 150 may receive or retrieve information about the user (e.g., medications, symptoms, free time, working hours, etc.) from user profiles 170. For example, the schedule manager 150 may use user 302's working hours to select start schedules 310 with the corresponding profile type. In another instance, the schedule manager 150 may use user 302's medications, symptoms, and age to select start schedules 310.

[0063] In some embodiments, the schedule manager 150 may select a launch schedule 310 based on application history. For example, user device 110 may include previous versions of application 125 during user 302's interaction with application 125. Application 125 may track, monitor, or otherwise detect user 302's interaction time 320 and store the interactions in an interaction log in the user device 110's memory. In some embodiments, the schedule manager 150 may select an initial schedule based on a group. Interaction evaluator 145 may use application history and geolocation to determine habits associated with each user 302 in a group that is geographically similar.

[0064] Messenger 155 may output, transmit, or otherwise provide at least one message 335 for display on user equipment 110 at delivery time 330. When schedule manager 150 retrieves delivery time 330 to send one or more messages 335, messager 155 may create, generate, or use data structures to store messages 335 until the relevant delivery time 330 occurs. Messager 155 may store messages 335 in, for example, queues, stacks, linked lists, arrays, hash maps, heaps, multisets, etc., until delivery time 330 occurs. For example, messager 155 may store messages 335 in a linked list, where the head of the list is the first message 335A at morning delivery time 330A, and the tail of the list is the last message 335B at nighttime.

[0065] Messenger 155 may transmit, send, or otherwise provide a message to user equipment 110 in response to the occurrence of a delivery time 330 for message 335. Messenger 155 may transmit multiple messages 335 to user equipment 110 based on a set of delivery times 330. In some embodiments, messager 155 may transmit multiple messages 335 at different delivery times 330 throughout the day based on a set of times. Each message 335 may correspond to at least one delivery time 330 in the schedule. For example, according to the start schedule 310, messager 155 may transmit the first message 335A, the second message 335B, and the third message 335C to user equipment 110 at a delivery time 330A in the early morning. However, messager 155 may transmit the fourth message 335D and the fifth message 335E to user equipment 110 at a delivery time 330B in the late afternoon.

[0066] Upon receipt, user device 110 may display, provide, or otherwise show message 335. In some embodiments, application 125 on user device 110 may use UI elements of user device 110 to display message 335. Message 335 may correspond to treatments, therapies, exercises, psychotherapy, and medications, for user 302 to perform or implement. For example, message 335 may encourage user 302 to perform breathing exercises to treat asthma. In another instance, message 335 may encourage user 302 to take pills to treat lung cancer-related pain. In yet another instance, message 335 may encourage user 302 to perform physical therapy exercises to promote recovery from leg surgery. By displaying message 335 at delivery time 330, user device 110 can capture more interactions between user 302 and application 125. In response to the provision of message 335, user device 110 (or application 125) may monitor interactions between user 302 and user device 110.

[0067] As user equipment 110 detects, captures, and otherwise identifies interactions, user equipment 110 can generate at least one event dataset 305. In some embodiments, application 125 can generate event dataset 305 at intervals (e.g., every 1 day, every 5 days, or every 2 weeks) within a time window (e.g., 6 hours to 3 months) of the launch schedule 310. In some embodiments, application 125 can generate event dataset 305 at the end of or near the end of a time window of the launch schedule 310 (e.g., within 1 to 3 days). Event dataset 305 may include a set of interaction times 320A-N (collectively referred to as interaction times 320) and a corresponding set of interactions 325A-N (collectively referred to as interactions 325). Each interaction time 320 can identify a time of day, a day of week, or a date (e.g., year, month, day) related to the associated interaction 325. In some embodiments, interaction time 320 may be relative to another established reference time, such as treatment start time or week start time.

[0068] Next, interaction 325 can identify the interaction type (e.g., mouse click, screen swipe, hover, tilt, or screen touch), activity type (e.g., performed by user 302 and recorded by application 125), indication of whether the activity has been performed, etc. User device 110 can generate event dataset 305 by using application 125 to collect, store, or otherwise capture each interaction 325 and its corresponding interaction time 320. Each interaction time 320 can be a duration or a moment in time. For example, interaction time 320A can correspond to multiple interactions 325 occurring within a 2-6 minute time window. In another instance, interaction time 320A can correspond to a single interaction 325A.

[0069] User equipment 110 may transmit, send, or otherwise provide event dataset 305 to interaction evaluator 145. User equipment 110 may transmit a send request to session management service 105. This send request may indicate that user equipment 110 is online and has event dataset 305 to send. The send request may include metadata associated with event dataset 305, such as the size of event dataset 305, the duration of user equipment 110's offline status, user equipment 110 corresponding to event dataset 305, device ID, etc. After connection is established, user equipment 110 may transmit event dataset 305 to session management service 105.

[0070] Interaction evaluator 145 may acquire, receive, or otherwise retrieve event dataset 305 from user device 110. Upon receipt, interaction evaluator 145 may parse event dataset 305 to extract or identify a set of interaction times 320 and a corresponding set of interactions 325. To evaluate startup schedule 310, interaction evaluator 145 may compare the delivery times 330 in startup schedule 310 with the interaction times 320 in event dataset 305 and output a performance score. The performance score may indicate the effectiveness of a set of delivery times 330 in startup schedule 310 based on the number of interactions 325. In some embodiments, the interaction times 320 in event dataset 305 may not deviate from the times in startup schedule 310, indicating a performance score indicating the efficiency of startup schedule 310. In some embodiments, the interaction times 320 in event dataset 305 may deviate from the times in startup schedule 310, indicating a performance score indicating the inefficiency of startup schedule 310.

[0071] Now for reference Figure 4 The diagram illustrates a block diagram of a process 400 for obtaining an event dataset 305 from application 125 to generate a new schedule 410 by applying a timing model 165. Process 400 may include or correspond to operations performed by system 100 to generate a new schedule 410 by applying the timing model 165 to the event dataset 305. In process 400, schedule manager 150 may receive, retrieve, or otherwise obtain the event dataset 305 from interaction evaluator 145. Upon receiving the event dataset 305, schedule manager 150 may extract interactions 325 and interaction times 320. Schedule manager 150 may also use performance scores from interaction evaluator 145 to determine whether to update timing model 165.

[0072] The schedule manager 150 can input, apply, or provide the event dataset 305 to the timing model 165 to generate at least one new schedule 410 (sometimes referred to herein as a follow-up schedule). The new schedule 410 may be structurally similar to the launch schedule 310. The new schedule 410 may include a set of new delivery times 430A-N (collectively referred to as new delivery times 430) and a set of corresponding messages 435A-N to be displayed to the user (collectively referred to as messages 435). Each delivery time 430 may identify a time of day, a day of week, or a date (e.g., year, month, day) related to the associated message 435. The delivery time set 430 may span a time window of 3 days to 1 month. The time window of the new schedule 410 may be after the time window of the launch schedule 310. For each delivery time 430, the new schedule 410 may identify a message type or message identifier (e.g., referring to a specific message). Messages 435 may include at least one of Short Message Service (SMS) messages, Multimedia Messaging Service (MMS) messages, in-app messages, or chatbot messages.

[0073] Upon input, the schedule manager 150 may calculate, determine, or otherwise generate at least one feature vector 405. In some embodiments, the schedule manager 150 may generate a feature vector 405 for each interaction time 320 in the sample event dataset 205. In some embodiments, the schedule manager 150 may generate a feature vector 405 for a combination of interaction time 320, interaction 325, delivery time 330, and message 335, etc. For example, the feature vector 405 may represent a data point generated as a function of the interaction time 320, interaction 325 (e.g., interaction type), and delivery time 330 for a given message 335.

[0074] As a new feature vector 405 is generated, the schedule manager 150 can map or compare the new feature vector 405 with the feature space 250 of the timing model 165. By comparing the feature vector 405 of each interaction time 320, the schedule manager 150 can compare a set of interaction times 320 with regions 255 of the feature space 250. For each new feature vector 405, the schedule manager 150 can select or identify a region 255 in the feature space 250 corresponding to the interaction time 320. The schedule manager 150 can use the region 255 to identify the corresponding delivery time 430 to include it in the new schedule 410. Through identification, the schedule manager 150 can determine or identify the centroid 260 defining the region 255. Based on the centroid 260, the schedule manager 150 can calculate or determine the corresponding delivery time 430 to insert into the new schedule 410. In some embodiments, using the centroid 260, the schedule manager 150 can also select or identify the corresponding message 435 for the delivery time 430. The schedule manager 150 can repeat this process on all new feature vectors 405 corresponding to the interaction time 320 of the sample event dataset 205 to generate a new schedule 410. The new delivery time 430 can indicate when to display a message 435 based on the user 302's behavioral pattern. For example, the user 302's work schedule may change, and they may interact with the application 125 earlier than the initial delivery time 330. Utilizing the earlier interaction, the timing model 165 can generate a new delivery time 430 to adapt to changes in the specific user 302's behavioral pattern.

[0075] While generating a new schedule 410, the schedule manager 150 may use the timing model 165 to generate, create, or otherwise calculate at least one confidence score 415 for the new schedule 410. The confidence score 415 may indicate that this set of delivery times 430 in the new schedule 410 represents the optimal confidence level for the user 302. For example, the confidence score 415 may indicate the confidence level at which the user 302 might respond to a message 435 delivered at a set of delivery times 430 specified by the new schedule 410. The confidence score 415 may be determined as a function of the new feature vector 405 for each interaction time 320 and the feature vector 265 in the feature space 250 of the timing model 165. In some embodiments, the schedule manager 150 may determine the confidence score 415 based on the distance between the new feature vector 405 and the centroid 260 in the region 255. In some embodiments, the schedule manager 150 may calculate a profile coefficient as the confidence score 415 based on the new feature vector 405 and the feature vector 265 in the same region 255. The silhouette coefficient represents the similarity between feature vectors 265 and 405 within region 255. The timetable manager 150 can repeat this determination for all feature vectors 405 and generate a total value (e.g., a weighted sum or average) for the confidence score 415.

[0076] To determine whether to use the new schedule 410, the schedule manager 150 may compare a confidence score 415 to a threshold. This threshold may identify, define, or delineate the value of the confidence score 415 for selecting the new schedule 410 to deliver message 435 to user 302. When the confidence score 415 meets (e.g., is greater than or equal to) the threshold, the schedule manager 150 may determine, identify, or otherwise indicate that the new schedule 410 can be used. Otherwise, when the confidence score 415 does not meet (e.g., is less than) the threshold, the schedule manager 150 may determine, identify, or otherwise indicate that the new schedule 410 cannot be used.

[0077] In some embodiments, the schedule manager 150 may use a timing model 165 to identify or select at least one category 270 for user 302. When the confidence score 415 does not meet a threshold, the schedule manager 150 may use the timing model 165 to select or identify category 270 for user 302. For identification, the schedule manager 150 may identify or determine behavioral patterns associated with user 302. In some embodiments, the schedule manager 150 may use an event dataset 305 to determine behavioral patterns. Behavioral patterns may characterize interactions 325 performed by user 302 with application 125. For example, if interaction 325 indicates that user 302 interacts with application 125 more frequently in the morning, the schedule manager 150 may classify user 302's behavioral pattern as a morning interactor.

[0078] In some embodiments, the schedule manager 150 may determine a behavioral pattern based on a new feature vector 405 generated according to the interaction time 320 of interaction 325. The schedule manager 150 may determine which region 255 the new feature vector 405 belongs to. Based on the identified region 255, the schedule manager 150 may determine the behavioral pattern of user 302. For example, if feature vector 265 belongs to region 255 associated with users who interacted between noon and 3:00 pm on Mondays, the schedule manager 150 may classify user 302 as such a user.

[0079] Based on behavioral patterns, the schedule manager 150 can select or identify a category 270 for user 302. Based on the event dataset 305, category 270 can correspond to a user group (or cluster) with behavioral patterns similar to user 302. The schedule manager 150 can identify or select a new schedule 410 corresponding to category 270. In some embodiments, the schedule manager 150 can select a new schedule 410 pre-generated for category 270. For example, the schedule manager 150 can identify a new schedule 410 generated from another user in category 270. In some embodiments, the schedule manager 150 can generate a new schedule 410 using one or more regions 255 associated with category 270. For each region 255 associated with category 270, the schedule manager 150 can determine or identify a centroid 260 defining region 255. Based on the centroid 260, the schedule manager 150 can calculate or determine the corresponding delivery time 430 to insert into the new schedule 410. In some embodiments, using the centroid 260, the schedule manager 150 can also select or determine the corresponding message 435 for the delivery time 430.

[0080] Now for reference Figure 5The diagram illustrates a block diagram of a process 500 for providing message 435 according to a new schedule 410 to obtain a subsequent event dataset 505' to update the timing model 165. Process 500 may include or correspond to operations performed by system 100 to provide message 435 and update the timing model 165. In process 500, message passer 155 may output, transmit, or otherwise provide at least one message 435 at delivery time 430 according to the new schedule 410 for display on user device 110. When schedule manager 150 retrieves delivery time 430 to deliver one or more messages 435, message passer 155 may create, generate, or use data structures to store message 435 until the associated delivery time 430 occurs. Message passer 155 may store message 435 in, for example, a queue, stack, linked list, array, hash graph, heap, multiset, etc., until delivery time 430 occurs. For example, message transmitter 155 can store message 435 in a linked list, where the head of the linked list is the first message 435A delivered at dawn time 330A, and the tail of the linked list is the last message 435B delivered at midnight time 330B.

[0081] Messenger 155 may transmit, send, or otherwise provide a message to user equipment 110 in response to the occurrence of a delivery time 430 for message 435. Messenger 155 may transmit a set of messages 435 to user equipment 110 at the same delivery time 430. In some embodiments, message messenger 155 may transmit a set of messages 435 at different delivery times 430. Each message 435 may correspond to at least one delivery time 430 in a schedule. For example, according to a new schedule 410, message messenger 155 may transmit a first message 435A, a second message 435B, and a third message 435C to user equipment 110 at different delivery times 430A-C at 6:15 AM, 7:00 AM, and 8:30 AM. Messenger 155 may transmit a fourth message 435D and a fifth message 435E to user device 110 at a later time of 3:45 and 3:50 p.m., within a short period of 330D and 330E, as chatbot messages to be displayed (e.g., displayed within the chatbox message interface of application 125).

[0082] Upon receiving the message, user device 110 may display, provide, or otherwise show message 435. In some embodiments, application 125 on user device 110 may use UI elements of user device 110 to display message 435. Message 435 may correspond to treatments, therapies, exercises, treatments, and medications, etc., for user 302 to perform or implement. For example, message 435 may encourage user 302 to perform breathing exercises to treat asthma. In another instance, message 335 may encourage user 302 to take a pill to treat lung cancer-related pain. In yet another instance, message 435 may encourage user 302 to perform physical therapy exercises to promote recovery from leg surgery. By displaying message 435 at delivery time 430, user device 110 can capture more interactions between user 302 and application 125. In response to the provision of message 435, user device 110 (or application 125) may monitor interactions between user 302 and user device 110.

[0083] As user equipment 110 detects, captures, and otherwise identifies interactions, user equipment 110 can generate event dataset 505. Event dataset 505 can be generated in a manner similar to that of event dataset 305. In some embodiments, application 125 can generate event dataset 505 at intervals (e.g., every 1 day to 4 weeks) within a time window (e.g., 5 days to 1 month) of launch schedule 510. In some embodiments, application 125 can generate event dataset 505 at the end of or near the end of a time window of launch schedule 510 (e.g., within 1 to 5 days).

[0084] Event dataset 505 may include a set of interaction times 520A-N (collectively referred to as interaction times 520) and a corresponding set of interactions 525A-N (collectively referred to as interactions 525). Each interaction time 520 may identify a time of day, a day of week, or a date (e.g., year, month, day) related to the associated interaction 525. In some embodiments, interaction time 520 may be relative to another set reference time, such as treatment start time or week start time. Interaction 525 may then identify the interaction type (e.g., mouse click, screen swipe, hover, tilt, or screen touch), activity type (e.g., performed by user 502 and recorded by application 125), indication of whether the activity has been performed, etc. User device 110 may generate event dataset 505 by collecting, storing, or otherwise capturing each interaction 525 and its corresponding interaction time 520 using application 125. Each interaction time 520 may be a duration or a moment in time. For example, interaction time 520A may correspond to multiple interactions 525 occurring within a 2-6 minute time window. In another instance, an interaction time of 520A can correspond to a single interaction of 525A.

[0085] User equipment 110 may transmit, send, or otherwise provide event dataset 305 to interaction evaluator 145. User equipment 110 may transmit a send request to session management service 105. The send request may indicate that user equipment 110 is online and has event dataset 505 to send. The send request may include metadata associated with event dataset 505, such as the size of event dataset 505, the duration of user equipment 110's offline status, user equipment 110 corresponding to event dataset 505, device ID, etc. After connection is established, user equipment 110 may transmit event dataset 505 to session management service 105.

[0086] Interaction evaluator 145 may acquire, receive, or otherwise retrieve event dataset 505 from user device 110. Upon receipt, interaction evaluator 145 may parse event dataset 505 to extract or identify the set of interaction times 520 and the corresponding set of interactions 525. To evaluate startup schedule 510, interaction evaluator 145 may compare the delivery times 530 of startup schedule 510 with the interaction times 520 in event dataset 505 and output a performance score. The performance score may indicate the effectiveness of a set of delivery times 530 of startup schedule 510 based on the number of interactions 525. In some embodiments, the interaction times 520 in event dataset 505 may not deviate from the times in startup schedule 510, which indicates a performance score indicating the efficiency of startup schedule 510. In some embodiments, the interaction times 520 in event dataset 505 may deviate from the times in startup schedule 510, which indicates a performance score indicating the inefficiency of startup schedule 510. Interaction evaluator 145 may communicate, send, or otherwise provide event dataset 505 and new schedule 410 to model trainer 140.

[0087] In some embodiments, the interactive evaluator 145 may transmit, send, or otherwise provide the performance score to the model trainer 140. This performance score can be used to update the timing model 165. For example, a performance score indicating efficiency of the new timetable 410 can be used to fine-tune the timing model 165 by adding parameters, thereby improving the timing model 165. Conversely, an inefficient performance score can generate a new feature vector 405 associated with the interaction time 520 of the event dataset 505 to improve region 255 of the timing model 165. In some embodiments, when the performance score meets a threshold, the interactive evaluator 145 may provide the event dataset 505 and the associated new timetable 410.

[0088] Using the event dataset 505 and the associated new timetable 410, model trainer 140 can update timing model 165. Updating timing model 165 can be similar to the startup, training, and setup of timing model 165 as detailed herein. For example, model trainer 140 can create new feature vectors 405 within the corresponding region 255'AN (hereinafter collectively referred to as region 255') to update timing model 165. In some embodiments, model trainer 140 can continuously train timing model 165 until timing model 165 converges for each user of application 125. Using the new feature vectors 405, model trainer 140 can populate region 255 with interaction times 520 that can improve timing model 165. In some embodiments, model trainer 140 can create another instance of timing model 165 for user 302. Timing model 165 can generate a timetable specifically for user 302. After creation, model trainer 140 can train new instances of timing model 165 using event dataset 505 (and previous event datasets of user 302) to modify or update regions 255 defined in feature space 250. For example, model trainer 140 can add at least one new feature vector 265' to update region 255' of feature space 250 of timing model 165. Timing model 165 can be updated through multiple iterations of generating schedule 410 and receiving event dataset 505.

[0089] In this way, using the systems and methods described herein, session management service 105 can deliver message 435 at the optimal time when user 302 is most likely to respond. Furthermore, session management service 105 can improve adherence during the digital therapy process provided through application 125. Pairing model trainer 140 with interaction evaluator 145 allows session management service 105 to aggregate real-time data related to user 302 over a specified time period. Interaction evaluator 145 can provide model trainer 140 with changes in behavioral patterns to establish real-time adjustments to timing model 165, while limiting the number of calls to aggregate data within the specified time period. Model trainer 140 can further update timing model 165 to adapt to changes in user 302's behavioral patterns. Schedule manager 150 can generate and select start schedule 310 and new schedule 410 for the corresponding user 302 using timing model 165. By delivering messages at the optimal time according to the selected schedule (startup schedule 310 or new schedule 410), session management service 105 can reduce the consumption of computing resources and network bandwidth that would otherwise be used to transmit poorly performing messages.

[0090] Now for reference Figure 6The figure illustrates an example of the feature space 600 for event datasets (i.e., event datasets 305 and 505). Feature space 600 may include a timeline 605 that identifies a set of data points corresponding to notifications 610A and 610B, and a set of data points corresponding to user activities 615A-N. During a given day, different users may interact with their respective instances of application 125 at different times relative to other users. For example, notification 610A may occur in the morning, which could allow for a high volume of user activities 615A-N in the morning. Conversely, notification 610B may be sent in the evening, which could allow for a high volume of user activities 615A-N in the evening. The occurrence of high activity levels may be based on behavioral patterns such as exercise habits, sleep duration, work hours, eating habits, etc.

[0091] Now for reference Figure 7 The figure illustrates a flowchart of a method 700 for adaptively generating the expected timing of message delivery via a digital therapy application. This method 700 can be implemented or performed using any of the components described herein, such as session management service 105 and user device 110, or any combination thereof. In method 700, a computing system (e.g., session management service 105 or user device 110) can acquire an event dataset (705). The computing system can apply the event dataset to an ML model (710). The computing system can generate a schedule and associated confidence values ​​for the user (715). The computing system can determine whether the confidence values ​​meet a threshold. The computing system can select a schedule for a specific user (725). The computing system can select a schedule for a user category (730). The computing system can deliver messages based on the schedule (735).

[0092] B. Network and Computing Environment

[0093] The various operations described in this article can be implemented on a computer system. Figure 8 A simplified block diagram of a representative server system 800, client computer system 814, and network 826 for implementing certain embodiments of this disclosure is shown. In various embodiments, server system 800 or similar systems may implement the services or servers or parts thereof described herein. Client computer system 814 or similar systems may implement the clients described herein. System 100 described herein may be similar to server system 800. Server system 800 may have a modular design that incorporates multiple modules 802 (e.g., blades in a blade server embodiment); although two modules 802 are shown in the figures, any number of modules may be provided. Each module 802 may include a processing unit 804 and local storage 806.

[0094] Processing unit 804 may include a single processor (which may have one or more cores) or multiple processors. In some embodiments, processing unit 804 may include a multi-purpose main processor and one or more dedicated coprocessors, such as a graphics processor, digital signal processor, or similar device. In some embodiments, some or all of processing unit 804 may be implemented using custom circuitry, such as an application-specific integrated circuit (ASIC) or a field-programmable gate array (FPGA). In some embodiments, such integrated circuits may execute instructions stored within the circuit itself. In other embodiments, processing unit 804 may execute instructions stored in local memory 806. Processing unit 804 may include any combination of any type of processor.

[0095] Local memory 806 may include volatile storage media (e.g., DRAM, SRAM, SDRAM, etc.) and / or non-volatile storage media (e.g., disk or optical disk, flash memory, etc.). Depending on the needs, the storage media in local memory 806 may be fixed, removable, or upgradeable. Local memory 806 may be physically or logically divided into multiple sub-units, such as system memory, read-only memory (ROM), and permanent storage devices. System memory may be a read-write memory device or a volatile read-write memory, such as dynamic random access memory. System memory may store some or all of the instructions and data required by processing unit 804 during operation. ROM may store static data and instructions required by processing unit 804. Permanent storage devices may be non-volatile read-write memory devices that can store instructions and data even when module 802 is powered off. The term "storage media" as used herein includes any medium capable of storing data indefinitely (unaffected by coverage, electrical interference, power outages, or similar conditions), excluding carrier waves and transient electronic signals propagated via wireless or wired connections.

[0096] In some embodiments, local memory 806 may store one or more software programs executed by processing unit 804, such as operating systems and / or programs that implement various server functions, such as the functions of system 100 or any other system described herein, or the functions of any other server associated with system 100 or any other system described herein.

[0097] "Software" generally refers to a sequence of instructions that, when executed by processing unit 804, cause server system 800 (or a portion thereof) to perform various operations, thereby defining one or more specific machine embodiments for executing and performing software program operations. Instructions may be stored as firmware residing in read-only memory and / or program code stored in non-volatile storage media, which can be read into volatile working memory for execution by processing unit 804. Software may be implemented as a single program or as a collection of independent programs or program modules that interact as needed. Processing unit 804 may retrieve program instructions to be executed and data to be processed from local storage 806 (or non-local storage as described below) to perform the various operations described above.

[0098] In some server systems 800, multiple modules 802 can be interconnected via a bus or other interconnect 808 to form a local area network (LAN). This LAN supports communication between the modules 802 and other components of the server system 800. The interconnect 808 can be implemented using various technologies, including server racks, hubs, routers, etc.

[0099] The wide area network (WAN) interface 810 provides data communication capabilities between a local area network (e.g., via interconnection 808) and a network 826 (e.g., the Internet). Other technologies can be used to communicatively couple the server system to the network 826, including wired technologies (e.g., Ethernet, IEEE 802.3 standard) and / or wireless technologies (e.g., Wi-Fi, IEEE 802.11 standard).

[0100] In some embodiments, local memory 806 provides working memory for processing unit 804, providing fast access to programs and / or data to be processed while reducing traffic on interconnect 808. Storage of large amounts of data may be provided on a local area network by one or more mass storage subsystems 812 connected to interconnect 808. Mass storage subsystem 812 may be based on magnetic, optical, semiconductor, or other data storage media. Direct-attached storage, storage area networks, network-attached storage, etc., may be used. Any data storage or other data collections generated, consumed, or maintained by a service or server as described herein may be stored in mass storage subsystem 812. In some embodiments, other data storage resources may be accessed via WAN interface 810 (which may increase latency).

[0101] Server system 800 can operate in response to requests received through WAN interface 810. For example, one of the modules 802 can implement a monitoring function and, in response to a received request, assign discrete tasks to other modules 802. Work assignment techniques can be used. While processing a request, the result can be returned to the requester through WAN interface 810. This operation can generally be automated. Furthermore, in some embodiments, WAN interface 810 can interconnect multiple server systems 800, thereby providing a scalable system capable of managing a large number of activities. Other technologies can also be used to manage server systems and server clusters (collections of cooperating server systems), including dynamic resource allocation and reallocation.

[0102] Server system 800 can interact with various user-owned or user-operated devices via a wide area network (such as the Internet). Examples of user-operated devices are shown in... Figure 8 The image shows a client computing system 814. The client computing system 814 can be implemented as a consumer device such as a smartphone, other mobile phone, tablet computer, wearable computing device (e.g., smartwatch, glasses), desktop computer, laptop computer, etc.

[0103] For example, the client computing system 814 can communicate via WAN interface 810. The client computing system 814 may include computer components such as processing unit 816, storage device 818, network interface 820, user input device 822, and user output device 824. The client computing system 814 can be a computing device implemented in various forms, such as a desktop computer, laptop computer, tablet computer, smartphone, other mobile computing device, wearable computing device, or similar device.

[0104] The processing unit 816 and storage device 818 can be similar to the processing unit 804 and local memory 806 described above. Appropriate devices can be selected based on the requirements of the client computing system 814. For example, the client computing system 814 can be implemented as a "thin" client with limited processing power or a high-power computing device. The client computing system 814 can be equipped with program code executable by the processing unit 816 to enable various interactions with the server system 800.

[0105] Network interface 820 can provide connectivity to network 826, such as a wide area network (e.g., the Internet), to which the WAN interface 810 of server system 800 is also connected. In various embodiments, network interface 820 may include a wired interface (e.g., Ethernet) and / or a wireless interface that implements various radio frequency (RF) data communication standards (e.g., Wi-Fi, Bluetooth, or cellular data network standards (e.g., 3G, 4G, LTE, etc.)).

[0106] User input device 822 may include any device (or multiple devices) through which a user can provide signals to client computing system 814; client computing system 814 may interpret these signals as signals indicating specific user requests or information. In various embodiments, user input device 822 may include any or all of the following: keyboard, touchpad, touchscreen, mouse or other pointing device, scroll wheel, click wheel, dial, button, switch, keyboard, microphone, etc.

[0107] User output device 824 may include any device that the client computing system 814 can use to provide information to the user. For example, user output device 824 may include display-to-display images generated or transmitted by the client computing system 814. The display may incorporate various image generation technologies, such as liquid crystal displays (LCDs), light-emitting diode (LED) displays including organic light-emitting diodes (OLEDs), projection systems, cathode ray tubes (CRTs), or similar devices, as well as supporting electronic devices (e.g., digital-to-analog or analog-to-digital converters, signal processors, or similar devices). In some embodiments, a device that can function as both an input and output device, such as a touchscreen, may also be included. In some embodiments, other user output devices 824 may be provided in addition to or in lieu of a display, such as indicator lights, speakers, haptic "display" devices, printers, etc.

[0108] Some embodiments include electronic components, such as microprocessors, memories, and memory, that store computer program instructions in a computer-readable storage medium. Many of the functions described herein can be implemented as programs, which are specified as sets of program instructions encoded on a computer-readable storage medium. When one or more processing units execute these program instructions, they cause the processing units to perform various operations indicated in the program instructions. Embodiments of program instructions or computer code include machine code (such as code generated by a compiler) and files including high-level code that are executed by a computer, electronic components, or a microprocessor using an interpreter. With appropriate programming, processing units 804 and 816 can provide various functions for server system 800 and client computing system 814, including any or other functions described herein that are performed by a server or client.

[0109] It is understood that the server system 800 and client computing system 814 are exemplary and can be varied and modified. Computer systems associated with embodiments of this disclosure may have other functionalities not specifically described herein. Furthermore, while the server system 800 and client computing system 814 are described with reference to specific blocks, it is to be understood that these blocks are defined for ease of description and do not imply a specific physical arrangement of component portions. For example, different blocks may, but do not necessarily, reside on the same device, the same server rack, or the same motherboard. Moreover, blocks do not necessarily correspond to physically different components. Blocks may be configured to perform various operations, for example, by programming a processor or providing appropriate control circuitry, and various blocks may or may not be reconfigurable based on how the initial configuration is obtained. Embodiments of this disclosure can be implemented in various devices, including electronic devices implemented using any combination of circuitry and software.

[0110] While this disclosure has described specific embodiments, those skilled in the art will recognize that numerous modifications can be made. Embodiments of this disclosure can be implemented using various computer systems and communication technologies, including but not limited to the specific examples described herein. Embodiments of this disclosure can be implemented by any combination of dedicated components and / or programmable processors and / or other programmable devices. The various processes described herein can be implemented on the same or different processors in any combination. When describing components configured to perform certain operations, such configuration can be implemented by designing electronic circuitry that performs the operations, programming programmable electronic circuitry (such as a microprocessor) that performs the operations, or any combination thereof. Furthermore, while the embodiments described above may refer to specific hardware and software components, those skilled in the art will understand that different combinations of hardware and / or software components can also be used, and specific operations described as implemented in hardware can also be implemented in software, and vice versa.

[0111] Computer programs incorporating the various features of this disclosure can be encoded and stored on a variety of computer-readable storage media; suitable media include optical storage media such as magnetic disks or magnetic tapes, optical discs (CDs) or digital multifunction discs (DVDs), flash memory, and other non-transitory media. The computer-readable medium encoding the program code may be packaged with a compatible electronic device, or the program code may be provided separately from the electronic device (e.g., downloaded via the Internet or as a separately packaged computer-readable storage medium).

[0112] Therefore, although this disclosure has been described with reference to specific embodiments, it is to be understood that this disclosure is intended to cover all modifications and equivalents within the scope of the following claims.

Claims

1. A method of generating a time for providing a message through a networked environment, comprising: obtaining, by one or more processors, an event data set for a user device, the event data set identifying a plurality of interaction times corresponding to a plurality of interactions of a user with an application on the user device at an instant time window for resolving a condition of the user; applying, by the one or more processors, the event data set to a machine learning (ML) model, wherein the ML model is established using a training data set comprising a plurality of examples, each of the plurality of examples comprising a respective event data set identifying a respective plurality of interaction times corresponding to a respective plurality of interactions of a respective user with a respective application on a respective user device at a respective time window, at least one of the respective plurality of interactions being detected in response to a provision of one or more messages; generating, by the one or more processors, a prescribed time for providing a message to the user device during a subsequent time window based on applying the event data set to the ML model; and providing, by the one or more processors, the message in accordance with the prescribed time for presentation on the user device to resolve the condition of the user.

2. The method of claim 1, wherein the ML model comprises a clustering model defining a plurality of clusters established using the plurality of examples, each of the plurality of clusters corresponding to a respective subset of the plurality of interaction times, each of the plurality of clusters being associated with a respective prescribed time for providing a respective message of a plurality of messages within a set time window.

3. The method of claim 2, wherein generating the prescribed time further comprises: comparing the plurality of interaction times of the event data set of the user to one or more of the plurality of clusters of the clustering model, identifying a cluster from the plurality of clusters corresponding to at least one of the plurality of interaction times, and using the respective prescribed time of the cluster as the prescribed time.

4. The method of claim 2, wherein generating the prescribed time further comprises: comparing the plurality of interaction times of the event data set of the user to one or more of the plurality of clusters of the clustering model, identifying a subset of clusters from the plurality of clusters for a corresponding subset of the plurality of interaction times, and using the respective prescribed time of each of the subset of clusters as a plurality of prescribed times of a schedule.

5. The method of claim 1, wherein generating the prescribed time further comprises generating a schedule identifying for each of a plurality of prescribed times a respective message type of a corresponding message of a plurality of messages to be provided to the user device.

6. The method of claim 1, wherein at least one of the plurality of examples of the training data set further identifies at least one of: (i) a respective schedule identifying a corresponding plurality of prescribed times for providing a respective plurality of messages to a respective user device within a set time window; or (ii) a respective indication as to whether the respective schedule improves a corresponding response rate of the respective plurality of interactions by at least a threshold value. ​ 7. The method of claim 1, wherein generating the prescribed time further comprises generating, based on applying the event dataset to the ML model, a score indicative of a confidence of the prescribed time, and determining, by the one or more processors, that the prescribed time is to be used to provide a message to a user device in response to the score satisfying a threshold.

8. The method of claim 1, further comprising: receiving, by the one or more processors, a subsequent event dataset, the subsequent event dataset identifying a subsequent plurality of interaction times corresponding to a subsequent plurality of interactions by the user with the application in response to provision of at least one of the plurality of messages in a subsequent time window; and updating, by the one or more processors, the ML model using the subsequent event dataset and the prescribed time.

9. The method of claim 1, further comprising: prior to obtaining the event dataset, selecting, by the one or more processors, a launch schedule in response to identifying a lack of prior event datasets for the user, the launch schedule identifying an initial plurality of prescribed times at which an initial plurality of messages are to be provided to a user device in an initial time window, to; and providing, by the one or more processors, the initial plurality of messages in accordance with the initial plurality of prescribed times of the launch schedule for presentation on the user device, and wherein obtaining the event dataset further comprises obtaining an event dataset identifying a plurality of interaction times corresponding to a plurality of interactions by the user with the application in response to presentation of at least one message of the initial plurality of messages of the launch schedule.

10. The method of claim 1, further comprising: determining, by the one or more processors, a category of the user from a plurality of categories based on one or more event datasets, each category of the plurality of categories being associated with a respective behavior pattern; and identifying, by the one or more processors, a launch schedule based on the category determined for the user, the launch schedule identifying an initial plurality of prescribed times at which an initial plurality of messages are to be provided to a user device.

11. The method of claim 1, wherein the event dataset further comprises at least one of: (i) a health indicator associated with a condition of the user, (ii) an interaction rate of a plurality of interactions within an instant time window, or (iii) a characteristic message associated with the user, at least one of the plurality of interactions corresponding to an interaction with the application independent of provision of any message.

12. The method of claim 1, wherein the message comprises at least one of a short message service (SMS) message, a multimedia message service (MMS), an in-app message, or a chatbot message, wherein the message is to be presented to the user at least for a portion of time in which the user is taking medication to address the condition.

13. A system for generating a time at which to provide a message over a networked environment, comprising one or more processors configured to: obtain an event dataset for a user device, the event dataset identifying a plurality of interaction times corresponding to a plurality of interactions by a user with an application on the user device in an instant time window to address a condition of the user; ​ ​ applying the event dataset to a machine learning (ML) model, wherein the ML model is established using a training dataset comprising a plurality of examples, each of the plurality of examples comprising a respective event dataset identifying a respective plurality of interaction times corresponding to a respective plurality of interactions by a respective user with a respective application on a respective user device in a respective time window, at least one of the respective plurality of interactions being detected in response to a provision of one or more messages; generating, based on applying the event dataset to the ML model, a prescribed time at which to provide a message to the user device during a subsequent time window; and providing the message in accordance with the prescribed time for presentation on the user device to address the condition of the user.

14. The system of claim 13, wherein the ML model comprises a clustering model defining a plurality of clusters established using the plurality of examples, each of the plurality of clusters corresponding to a respective subset of the plurality of interaction times, each of the plurality of clusters being associated with a respective prescribed time at which to provide a respective message of the plurality of messages within a set time window.

15. The system of claim 14, wherein when generating the prescribed time, the one or more processors are further configured to: compare the plurality of interaction times of the event dataset of the user to one or more of the plurality of clusters of the clustering model, identify, from the plurality of clusters, a cluster corresponding to at least one of the plurality of interaction times, and use the respective prescribed time of the cluster as the prescribed time.

16. The system of claim 14, wherein when generating the prescribed time, the one or more processors are further configured to: compare the plurality of interaction times of the event dataset of the user to one or more of the plurality of clusters of the clustering model, identify, from the plurality of clusters, a subset of clusters for a corresponding subset of the plurality of interaction times, and use the respective prescribed time of each of the subset of clusters as the plurality of prescribed times of the schedule.

17. The system of claim 13, wherein when generating the prescribed time, the one or more processors are further configured to generate a schedule identifying, for each of the plurality of prescribed times, a respective message type of a corresponding message of the plurality of messages to provide to the user device.

18. The system of claim 13, wherein at least one of the plurality of examples of the training dataset further identifies at least one of: (i) a respective schedule identifying a corresponding plurality of prescribed times at which to provide a respective plurality of messages to a respective user device within a set time window; or (ii) a respective indication as to whether a corresponding response rate of the respective plurality of interactions was increased by at least a threshold value by the respective schedule.

19. The system of claim 13, wherein when generating the prescribed time, the one or more processors are further configured to generate, based on applying the event dataset to the ML model, a score indicative of a confidence of the prescribed time, and In response to the score satisfying a threshold, determining that the prescribed time will be used to provide the message to the user device.

20. The system of claim 13, the one or more processors further configured to: receive a subsequent event dataset identifying a subsequent plurality of interaction times corresponding to a subsequent plurality of interactions by the user with the application within a subsequent time window in response to provision of at least one of the plurality of messages; and update the ML model using the subsequent event dataset and the prescribed time.

21. The system of claim 13, the one or more processors further configured to: prior to obtaining the event dataset, in response to identifying a lack of prior event datasets for the user, select a launch schedule, the launch schedule identifying an initial plurality of prescribed times at which an initial plurality of messages are to be provided to the user device at an initial time window; provide the initial plurality of messages in accordance with the initial plurality of prescribed times of the launch schedule for presentation on the user device; and wherein in obtaining the event dataset, the one or more processors are further configured to obtain an event dataset identifying a plurality of interaction times corresponding to a plurality of interactions by the user with the application in response to presentation of at least one of the initial plurality of messages of the launch schedule.

22. The system of claim 13, the one or more processors further configured to: determine a category of the user from a plurality of categories based on one or more event datasets, each category of the plurality of categories being associated with a respective behavior pattern; and identify a launch schedule based on the category determined for the user, the launch schedule identifying a plurality of initial prescribed times at which a plurality of initial messages are to be provided to the user device.

23. The system of claim 13, wherein the event dataset further comprises at least one of (i) a health indicator associated with a condition of the user, (ii) an interaction rate of the plurality of interactions within an immediate time window, or (iii) a characteristic message associated with the user, at least one of the plurality of interactions corresponding to an interaction with the application independent of provision of any message.

24. The system of claim 13, wherein the message comprises at least one of a short message service (SMS) message, a multimedia message service (MMS), an in-application message, or a chatbot message, wherein the message is to be presented to the user at least during a portion of time in which the user is taking medication to address the condition. ​

Images