An automated change system clock that simulates a test environment for application triggers generated using machine learning.

Abstract

A system and method are provided for simulating a test environment for digital therapeutic applications to address disease states over several time frames. The computing system is capable of selecting a trigger from a plurality of triggers in an event scheduler to address a pathological condition and setting a clock to a timestamp of the trigger, the clock being accessible to a service and a user device. The computing system is also capable of causing the service to send a message to the user device to address the pathological condition in response to the clock's timestamp matching the trigger's timestamp, determining that the message has been communicated between the service and the user device in accordance with the trigger, and determining that the event scheduler trigger has been validated in response to determining that the message has been communicated.

Description

Technical Field

[0001] Cross - reference to Related Applications This application claims the benefit and priority of U.S. Non - Provisional Application No. 18 / 748,002, filed on June 19, 2024, entitled "Automated Variable System Clock for Simulating a Test Environment of an Application Trigger Generated Using Machine Learning", the entire disclosure of which is hereby incorporated by reference in its entirety.

Background Art

[0002] Prior to deployment to a user device, an application may undergo testing and validation to confirm that its functions operate and behave appropriately as intended. One consideration in application design, when communication with a server hosting the application's resources is involved, is that the exchange of messages and responses between the application and the server may also be tested and validated over a certain time frame. Such tests can include an evaluation of the behavior and functionality of the application, including the interactivity provided to the user by the application. This validation can include an assessment of whether the application meets specified requirements and objectives, such as the successful transmission of messages and responses.

[0003] One of the technical challenges related to testing and validation can stem from the sequence dependency of application functionality and the complexity of message and response transmission, particularly over long timeframes. These issues can be exacerbated by the type of application and the messages and responses exchanged over the network. For example, in the case of digital therapeutic applications, the timeframes involved in functionality and message and response transmission can range from weeks to months. Digital therapeutic applications can directly deliver evidence-based therapeutic interventions (e.g., in the form of content or messages) with the aim of treating, relieving, or otherwise addressing a user's condition within this timeframe. Furthermore, the therapeutic interventions themselves can be complex, involving countless sequences, branches, or dynamic changes in application functionality and message and response transmission between the application and the server.

[0004] Due to this complexity, testing and validating all functionalities in real time, as well as every potential sequence of messages and responses transmitted between the application and the server, can be impractical and difficult. As a result, accurately pinpointing the factors causing performance degradation in the application and transmission, and identifying ways to optimize overall system performance, can be challenging. Because it is impossible to test and validate all functionalities and potential sequences in real time, application and server performance may not be optimized, potentially leading to wasted consumption of computing resources (processors, memory, network bandwidth, etc.). Furthermore, some functionalities or communications that were not tested or validated may not work properly, potentially degrading the overall functionality of the system. Application malfunctions can also lead to a decrease in the quality of human-computer interaction (HCI) between the user and the application.

[0005] In digital therapeutic applications, testing and validating all functionality and every sequence of messages and responses may require waiting a considerable amount of time (e.g., weeks or months) until the end of the therapeutic intervention. This can ultimately delay the deployment of digital therapeutic applications, and in some cases, require an even longer timeframe. Releasing a digital therapeutic application before complete testing and validation may result in some functionality and communication not working properly, but also suboptimal performance of the entire system (e.g., the digital therapeutic application and server). Furthermore, failures in functionality or communication during execution can lead to a decline in the quality of HCI between the user and the application. In the context of digital therapeutics, the application may even become ineffective in addressing the disease or worsen the disease associated with the user. [Overview of the Initiative]

[0006] This specification presents systems and methods for simulating application test environments over several timeframes. To address these and other technical challenges, a test management service can automatically alter the clock time progression of a digital therapeutic application to trigger message delivery. The test management service can maintain and operate a central clock and insert precise timestamps from the central clock to the respective clocks on the application and server. Automating clock time in this way during testing and validation of digital therapeutic applications can yield several advantages and benefits. For example, by using a centralized clock to advance the system clocks of the server and application, the test management service can reduce the testing and validation of triggers in a digital therapeutic application from weeks or months to minutes or hours. For instance, testing and validation that would have taken 30 to 90 days without automated clock progression can be completed in just 10 to 30 minutes. This allows the time and effort that would have been spent waiting for testing and validation to complete to be redirected to optimizing and improving the efficiency and functionality of the digital therapeutic application, as well as the message content. Needless to say, shortening the testing and validation period could allow for faster announcement and deployment of digital therapeutic applications to users.

[0007] Another advantage is that, due to the shorter testing and validation time, test management services can potentially test and validate more aspects of digital therapeutic applications. This ensures that more functionalities of the digital therapeutic application operate as intended and designed, and that more messages (according to sequences, branches, or dynamic changes) are properly communicated. Doing so can potentially save computational resources (e.g., processing and memory) and network bandwidth that would otherwise be wasted by improper functionality or inaccurate communication. Furthermore, obvious technical issues for the user (e.g., issues with content display) can be resolved before deployment, thereby improving the quality of HCI between the user and the digital therapeutic content. From a therapeutic standpoint, test management services can more reliably improve the effectiveness of digital therapeutic applications in addressing, treating, or otherwise alleviating the user's condition.

[0008] Therefore, automatic changes in the progression of clock time can enhance the nature of digital therapeutic applications. The delivery of therapeutic interventions in message format may depend on triggers defined in terms of time schedules (e.g., defined in hours, minutes, seconds, days, and months), among various factors and conditions. For example, when a specific message time has elapsed, a server can be triggered to send a message containing digital therapeutic content to an application on a computing device. The challenge here in testing is that time on the application and server may elapse according to the system clocks on the computing system and the server. Test management services can be configured using a centralized clock that defines the time at which the clocks on the server and application are set (e.g., in a virtual test environment). By systematically advancing the system clocks of the server and application using a centralized clock, the server can be triggered to send these messages earlier than the actual time.

[0009] The test management service can identify a set of triggers for the transmission of messages and responses defined by the event scheduler of the digital therapeutic application. This set of triggers may be fixed or predefined for the digital therapeutic application, or it may be dynamically generated during execution (e.g., by artificial intelligence or machine learning models) based on various inputs (e.g., user profiles or prior responses) within a set time frame (e.g., from one week to six months). Each trigger may specify a timestamp that defines the time when the server sends a specified message containing the digital therapeutic content. From each trigger, the test management service can identify the timestamp specified by that trigger and set a centralized clock to the identified timestamp. This setting allows the centralized clock to jump or fast-forward through hours, days, weeks, or months of real time in less than a second. This setting of the centralized clock also disables the application and server clocks (e.g., via transmitted commands or insertions) and can be set to this timestamp. As a result, the clocks on the application and server can be synchronized with the centralized clock of the test management service.

[0010] With this clock set, the server can determine whether a trigger corresponding to the timestamp is fired. This determination can be made by the server at regular time intervals (e.g., between every 30 seconds and every hour) or on demand to evaluate whether to send a message. For example, the server may use data associated with a computing device or user every 5 minutes to compare against the trigger criteria. If the criteria are not met and the server determines that the trigger is not fired, it may refrain from sending a message. Conversely, if the criteria are met and the server determines that the trigger has been fired, it can select a specified message and send it to a computing device for presentation via a digital therapeutic application. When presenting a message, the application can monitor whether user interaction or dialogue (e.g., actions taken to address a medical condition) is occurring with the message's user interface elements. The application can use data associated with the user interaction to generate a response and send this response to the server.

[0011] Furthermore, the test management service may monitor whether communication is taking place between the computing device and the server. From the monitoring, the test management service can determine whether a message to the user to address a condition has been communicated, i.e., transmitted, between the server and the computing device, as specified by the trigger. Monitoring of a specific message for a trigger can be performed at time intervals used by the server (e.g., between 30 seconds and 1 hour). Based on the trigger and the transmission of the message or response, the test management service can determine whether the associated trigger has been validated. If it is determined that the trigger has not been fired and it is identified that no message has been sent, the test management service can determine that the trigger has been validated. If it is determined that the trigger has been fired and it is identified that a message has been sent, the test management service can determine that the trigger has been validated. Conversely, if it is determined that the trigger has been fired and it is identified that no message has been sent, the test management service can determine that the trigger has not been validated. If it is determined that the trigger has been fired and it is identified that a message has been sent, the test management service can determine that the trigger has not been validated.

[0012] The test management service can repeat this process over a set of triggers over a set of timeframes, as specified by the event scheduler. The test management service can use responses from the digital therapeutic application as part of the validation process. If any trigger is determined to be unvalidated by the end of the timeframe, the test management service can determine that the event scheduler is unvalidated. Conversely, if all triggers are determined to be validated by the end of the timeframe, the test management service can determine that the event scheduler is validated. Based on the validation results, the test management service may generate output and present it to the administrator of the digital therapeutic application or the server hosting the application's resources.

[0013] By using a centralized clock to advance the system clocks of servers and applications, test management services can significantly reduce the time required to test and validate triggers in digital therapeutic applications from weeks or months to minutes or hours. Therefore, test management services can increase the likelihood that the functionality of digital therapeutic applications and communication and transmission between the application and the server will function correctly during execution, compared to approaches that do not rely on clock time progression. The functionality of digital therapeutic applications and communication between the application and the server can be optimized and improved, thereby saving computational resources (e.g., processing and memory) and network bandwidth that would have been wasted if the application had malfunctioned. In the context of digital therapy, test management services can more effectively ensure that the user's condition is addressed.

[0014] This specification relates to a system and method for simulating a test environment for a digital therapeutic application to address a pathological condition over several timeframes. One or more processors can select one trigger from a plurality of triggers of an event scheduler to address a pathological condition. Each of the plurality of triggers can identify its respective timestamp from a plurality of timestamps, at which timestamp a service sends a corresponding message to a user device to address the pathological condition. One or more processors can set a clock to the timestamp of one of the triggers, and the clock is accessible to the service and the user device. In response to the timestamp of the clock matching the timestamp of one of the triggers, one or more processors can cause the service to send a message to the user device to address the pathological condition. One or more processors can identify that the message has been transmitted between the service and the user device in accordance with one of the triggers. In response to the identification that the message has been transmitted, one or more processors can determine that the trigger of the event scheduler has been validated.

[0015] In some embodiments, one or more processors may select a second trigger from the plurality of triggers in response to the validation of the first trigger. The second trigger may identify a second timestamp corresponding to the end of a period spanning the plurality of timestamps. One or more processors may set the clock to the second timestamp of the second trigger. In response to the second timestamp of the clock matching the second timestamp of the first trigger, one or more processors may cause the service to send a second message to the user device to address the condition. One or more processors may identify that the service has sent the second message to the user device in accordance with the second trigger. In response to the identification of the service receiving the second response, one or more processors may determine that the event scheduler is validated prior to the end of the period. In some embodiments, one or more processors may determine that the event scheduler is validated in response to the identification of the service successfully sending each of the messages for each of the plurality of triggers to the user device.

[0016] In some embodiments, the one or more processors may set the clock to the second timestamp of the second trigger of the plurality of triggers. In response to the second timestamp of the clock matching the second timestamp of the second trigger, the one or more processors may cause the service to send a second message to the user device to address the condition. In response to the identification that the second message has not been delivered, the one or more processors may determine that the second trigger of the event scheduler is not validated. In some embodiments, in response to the identification that the second message has not been delivered on the first attempt, the one or more processors may attempt again to cause the service to send the second message on a second attempt.

[0017] In some embodiments, the one or more processors may, in response to a determination that the second trigger has not been validated, obtain a transaction log that identifies one or more of a plurality of messages transmitted between the service and the user device. The one or more processors may generate an output that includes at least one of the following: an instruction that the validation of the second trigger has failed and identification information of the transaction log. In some embodiments, the one or more processors may (i) cause the service to set its service clock from a first timestamp to the timestamp of the clock, and (ii) cause the user device to set its device clock from a second timestamp to the timestamp of the clock.

[0018] In some embodiments, the event scheduler may include a machine learning model that generates at least some of the multiple triggers in the schedule. In some embodiments, at least one of the multiple triggers may identify a respective criterion that the service should be satisfied with sending the corresponding message to address the condition. One or more processors may cause the service to send the message, which further includes causing the service to send the message in response that data associated with the user device satisfies the criterion identified by the trigger. In some embodiments, one or more processors may correct the clock from an initial timestamp corresponding to the current time to a timestamp corresponding to a subsequent time identified by one of the triggers, prior to the occurrence of the subsequent time.

[0019] In some embodiments, the one or more processors can determine that the message has been delivered by at least one of the following: (i) determining that the service has sent the message using the transmission log associated with the service; (ii) determining that the user device has received the message from the service using the reception log associated with the user device; or (iii) determining that the service has received a response from the user device within a certain time frame for sending the message. In some embodiments, the message may include at least one of a Short Message Service (SMS) message, a Multimedia Messaging Service (MMS) message, or an in-app message, and the message may be presented at least partially concurrently with the user taking the medication. [Brief explanation of the drawing]

[0020] The above-mentioned and other objects, aspects, features, and advantages of the present disclosure should become clearer and better understood by referring to the following description together with the accompanying drawings. [Figure 1] FIG. 1 shows a block diagram of a system for simulating a test environment of a digital therapy application for addressing a medical condition over several time frames, according to an exemplary embodiment. [Figure 2] FIG. 2 shows a block diagram of a process for obtaining event schedule data and modifying a global clock in a system for simulating a test environment, according to an exemplary embodiment. [Figure 3] FIG. 3 shows a block diagram of a process for validating message transmission in a system for simulating a test environment, according to an exemplary embodiment. [Figure 4] FIG. 4 shows a block diagram of a process for re-modifying a global clock and validating message transmission in a system for simulating a test environment, according to an exemplary embodiment. [Figure 5] FIGS. 5A-C show a flowchart of a method for simulating a test environment of a digital therapy application for addressing a medical condition over several time frames, according to an exemplary embodiment. [Figure 6] FIG. 6 is a block diagram of a server system and a client computer system, according to an exemplary embodiment.

BRIEF DESCRIPTION OF THE DRAWINGS

[0021] In reading the following description of the various embodiments, the explanations and their respective contents listed following each section of the specification should be helpful.

[0022] In Section A, a system and method for simulating a test environment of an application over several time frames are presented.

[0023] Section B describes network and computing environments that may be useful for carrying out the embodiments described herein.

[0024] A. We present a system and method for simulating the application's test environment over several timeframes. Referring now to FIG. 1, a block diagram of an environment or system 100 for simulating an application's test environment over a number of time frames is shown. Briefly, system 100 can include at least one test management service 105, at least one session management service 110, at least one test environment 115, and at least one database 120 communicatively coupled to each other via at least one network 125. The test management service 105 can include, for example, at least one schedule reader 130, at least one clock orchestrator 135, at least one trigger validator 140, at least one test evaluator 145, and at least one global clock 150. The session management service 110 can include, for example, at least one event scheduler 160, at least one session handler 165, and at least one server clock 150'. The test environment 115 can include, for example, at least one user device 170. The user device 170 can include, for example, at least one application 175 having at least one local clock 150". The application 175 can provide or include at least one user interface 185. The user interface 185 can include one or more user interface (UI) elements 190A-N (hereinafter generally referred to as UI elements 190). The database 120 can include a set of messages 195A-N (hereinafter generally referred to as messages 195). Each component of system 100 (e.g., test management service 105, session management service 110, test environment 115, and user device 170) can be implemented using a computing system as described in Section B.

[0025] More specifically, the test management service 105 (sometimes referred to herein more generally as the service or test service) may be any computing device that includes one or more processors coupled with memory and software and is capable of performing the various processes and tasks described herein. The test management service 105 may be associated with an entity that oversees or manages the testing, inspection, and validation of application 175 or session management service 110. The test management service 105 may communicate with session management service 110, a test environment 115 including user devices 170, and a database 120, etc. The test management service 105 may be located in, deployed to, or otherwise associated with at least one server group. This server group may correspond to a data center, branch office, or site where one or more servers corresponding to the test management service 105 are located. In some embodiments, the test management service 105 may be separate from session management service 110 (for example, as illustrated). For example, the test management service 105 may correspond to an administrator's computing device. In some embodiments, the test management service 105 may be part of the session management service 110 and can perform all the functions assigned to the session management service 110.

[0026] In the test management service 105, the schedule leader 130 interfaces with the session management service 110 and can acquire triggers defined by the event scheduler 160 and transmit messages to and from the application 175. The clock orchestrator 135 can modify or set the global clock 150 according to the time specified by the trigger. The trigger validation verifier 140 can determine whether a message has been transmitted between the session management service 110 and the application 175 in order to validate the trigger. The test evaluator 145 can generate output based on the validation of the trigger. The global clock 150 can always keep track of the time in the test management service 105. This time can be defined in units such as year, month, day, hour, minute, second, and millisecond. The global clock 150 may be a hardware clock (e.g., a real-time clock, system timer, or process clock) or a software clock (e.g., a virtual clock). The global clock 150 can be accessed by the session management service 110 and user devices 170, including the application 175. Global clock 150 serves as, or fulfills, the reference clock from which server clock 150' and local clock 150'' are synchronized.

[0027] The session management service 110 (sometimes referred to herein more generally as the service or messaging service) is a computing device comprising one or more processors coupled with memory and software, and may be any computing device capable of performing the various processes and tasks described herein. The session management service 110 may be associated with an entity that manages the provision of resources and content for application 175 or the provision of digital therapies to users of user device 170. In some embodiments, the session management service 110 may be associated with the same entity that oversees or manages the testing, inspection, and validation of application 175 or the session management service 110. The session management service 110 may communicate with a test management service 105, a test environment 115 including user device 170, and a database 120, etc. The session management service 110 may be located in, deployed to, or otherwise associated with at least one server group. This server group may correspond to a data center, branch office, or site where one or more servers corresponding to the session management service 110 are located. In some embodiments, the session management service 110 may be separate from the test management service 105 (for example, as shown in the figure). In some embodiments, the session management service 110 may be part of the test management service 105 and may perform all the functions assigned to the test management service 105.

[0028] On the session management service 110, the event scheduler 160 can maintain a set of triggers in which one or more messages 195 are sent to the user device 170 and presented via the application 175. The session handler 165 can manage the session with the application 175 in which one or more messages 195 and responses are communicated according to these triggers. The server clock 150' can keep track of the time on the session management service 110 at all times. This time can be defined in units such as year, month, day, hour, minute, second, or millisecond. The server clock 150 may be a hardware clock (e.g., a real-time clock, system timer, or process clock) or a software clock (e.g., a virtual clock). The server clock 150' may be synchronized with the global clock 150 of the test management service 105.

[0029] The test environment 115 corresponds to, or may include, an environment for testing, inspecting, validating, or otherwise evaluating the application 175 on the user device 170. In some embodiments, the test environment 115 may be created, instantiated, or otherwise generated by the test management service 105 to facilitate the evaluation of the application 175 on the user device 170. For example, the test environment 115 may be an isolated, controlled, sandboxed environment or secure container to facilitate testing of the application 175 on the user device 170. In some embodiments, the test environment 115 may include the session management service 110 together with the user device 170 to facilitate the evaluation of the application 175 on the user device 170 and the session management service 110.

[0030] The user device 170 (sometimes referred to herein as an end-user computing device) is a computing device comprising one or more processors coupled with memory and software, and may be any computing device capable of performing the various processes and tasks described herein. The user device 170 can communicate with the test management service 105, the test environment 115, and the database 120, etc. The application 175 can be accessed using the user device 170. In some embodiments, the application 175 can be downloaded (for example, via a digital distribution platform) and installed on the user device 170. In some embodiments, the application 175 may be a web application with resources accessible via the network 125.

[0031] In some embodiments, the user device 170 may correspond to a virtual machine running on hardware. For example, the user device 170 may be a virtual machine having an operating system and applications 175 running on a physical computing device such as a server, and can be managed by a hypervisor. The virtual machine may be part of an isolated and controlled sandbox environment corresponding to the test environment 115. In some embodiments, the user device 170 may be a physical device. For example, the user device 170 may be a smartphone, another mobile phone, a tablet computer, a wearable computing device (e.g., a smartwatch, glasses), or a laptop computer.

[0032] An application 175 running on the user device 170 may be a digital therapeutic application. The application 175 may present or provide a session (which may also be referred to herein as a therapeutic session) to address at least one of the user's medical conditions. End-user conditions include, for example, chronic pain (e.g., associated with or including arthritis, migraine, fibromyalgia, back pain, Lyme disease, endometriosis, recurrent stress injury, irritable bowel syndrome, inflammatory bowel disease, and cancer pain), skin lesions (e.g., atopic dermatitis, psoriasis, dermatophyte, and eczema), cognitive impairment (e.g., mild cognitive impairment (MCI), Alzheimer's disease, multiple sclerosis, schizophrenia, etc.), mental disorders (e.g., affective disorders, bipolar disorder, obsessive-compulsive disorder, borderline personality disorder, attention deficit / hyperactivity disorder, etc.), substance use disorders (e.g., opioid use disorder, alcohol use disorder, tobacco use disorder, hallucinogen use disorder, etc.), and other conditions (e.g., narcolepsy, tumors, or cancer, etc.).

[0033] End users may be taking medication to address their condition at least partially (for example, over several sessions) concurrently with their use of Application 175. For example, if the medication is for pain management, the end user may be taking acetaminophen, nonsteroidal anti-inflammatory compositions, antidepressants, anticonvulsants, or other compositions. In the case of skin lesions, the end user may be taking steroids, antihistamines, or topical antiseptics. For cognitive impairment, the end user may be taking cholinesterase inhibitors or memantine. In the case of mental illness, the end user may be taking antidepressants, mood stabilizers, antipsychotics, anxiolytics, or stimulants. In the case of substance abuse disorder, the end user may be receiving or taking naltrexone, disulfiram, acamprosate, or nicotine replacement therapy. The end user may also be receiving other psychotherapies for these conditions. In some embodiments, digital therapeutic content can be provided to the end user within the digital therapeutic application to achieve the end user's endpoint. Endpoints may be, for example, end-user physical or behavioral goals, completion of a medication regimen, or endpoints indicated by a physician or end-user. At least one of the end-user devices 170 may have a digital therapeutic application that can provide a session (sometimes referred to herein as a therapeutic session) to address at least one condition of the end-user.

[0034] Application 175 may include, present, or otherwise provide to the user of user device 170 at least one user interface 185 that includes one or more user interface elements 190A-N (hereinafter generally referred to as UI elements 190). User interface 185 may be provided according to the configuration of application 175. UI elements 190 may correspond to visual components of user interface 185, such as command buttons, text boxes, checkboxes, radio buttons, menu items, and sliders. In some embodiments, application 175 may be a digital therapeutic application that can provide sessions (sometimes referred to herein as therapeutic sessions) for addressing a medical condition via user interface 185. User interface 185 may include a set of UI elements 190 for presenting digital therapeutic content. In some embodiments, application 175 may include functionality provided herein to session management service 110, such as an event scheduler 160 and a session handler 165. Although Application 175 is described herein primarily as a digital therapeutic application, Application 175 may include other types of applications, such as messaging applications, word processors, spreadsheet programs, email agents, web browsers, video games, database management software, or computer-aided design software.

[0035] Database 120 can store and maintain various resources and data associated with the test management service 105, session management service 110, and application 175, among others. Database 120 may include a database management system (DBMS) for organizing and structuring the data maintained on the database, such as instances of data elements. Database 120 can communicate with the test management service 105, session management service 110, and application 175 via network 125. While performing various operations, the test management service 105, session management service 110, and application 175 can each access database 120 to send and retrieve data identified from it. They can also write data to database 120 from the execution of such operations.

[0036] The database 120 can store and maintain a set of messages 195 to address the medical condition of a user of application 175. Each message 195 may include digital therapeutic content. Messages 195 can be transmitted, sent, or otherwise provided and presented to the user device 170 by the session management service 110. The messages 195 themselves may be in any format. In some embodiments, at least one message 195 may be a short message / messaging service (SMS) message. An SMS message may include text of a length (e.g., a limit on the number of alphanumeric characters) set to be sent over a cellular network. In some embodiments, at least one message 195 may be a multimedia messaging service (MMS) message. An MMS message may include multimedia content such as text, images, videos, or audio. In some embodiments, at least one message 195 may be an in-app message. An in-app message may include instructions for presenting multimedia content (e.g., in the form of text, images, videos, audio content, or any combination thereof) via the UI element 190 of the user interface 185 of application 175. The instructions can identify or specify one or more UI elements 190 that are rendered, displayed, or otherwise presented within the user interface 185 of the application 175.

[0037] The digital therapeutic content of message 195 may be any modality, or any combination thereof, such as text, images, audio, video, or multimedia content. Message 195 can be stored and maintained in database 120 using one or more files. For example, in the case of text, the digital therapeutic content may be stored as a text file (TXT), rich text file (RTF), extensible markup language (XML), and hypertext markup language (HTML), among others. For images, the digital therapeutic content may be stored as a Joint Photographic Expert Group (JPEG) format, Portable Network Graphics (PNG) format, Graphics Exchange (GIF) format, or Scalable Vector Graphics (SVG) format, among others. For audio, the digital therapeutic content may be stored as a waveform audio file (WAV), video expert group format (e.g., MP3 and MP4), and Ogg Vorbis (OGG) format, among others. For video, digital therapeutic content can be stored in video professional formats (e.g., MP3 and MP4), QuickTime Movie (MOV), and Windows Movie Video (WMV). For multimedia content, digital therapeutic content can be in audio-video interleaved format (AVI), video professional formats (e.g., MP3 and MP4), QuickTime Movie (MOV), and Windows Movie Video (WMV).

[0038] In some embodiments, the digital therapeutic content of message 195 may include a set of stimuli (e.g., in the form of audio, visual, or text) 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 modification training (ABMT) (e.g., training the user to divert attention from a specific stimulus), emotional faces memory tasks (EFMT) (e.g., testing whether the user recognizes and remembers the emotions expressed on a particular face), digital support tools (DST) (e.g., providing messages based on the user's state), and adaptive goal setting (AGS) (e.g., providing messages based on the user's dynamic goals). While message 195 is described herein in terms of digital therapeutic content, message 195 may include other types of content.

[0039] Referring next to Figure 2, a block diagram of a process 200 for acquiring event schedule data and correcting the global clock in a system 100 for simulating a test environment is shown. Process 200 may include, or correspond to, actions performed in system 100 to identify triggers and set the clock according to the triggers. Under process 200, an event scheduler 160 running in session management service 110 may create, occur, or otherwise generate at least one schedule 205 for sending and presenting a message 190 to application 175 to address a medical condition (e.g., a potential user). Schedule 205 may define, specify, or otherwise include a set of triggers 210A-N (hereinafter generally referred to as triggers 210) and a corresponding set of timestamps 215A-N (hereinafter generally referred to as timestamps 215). In some embodiments, schedule 205 may define, specify, or identify a sequence of triggers 210. This sequence may include, or specify, one or more branches between the set of triggers 210. For example, the sequence in schedule 205 can specify that trigger 210B should be evaluated when trigger 210A is satisfied and activated. Conversely, the sequence in schedule 205 can specify that trigger 210C should be evaluated if trigger 210A fails to be satisfied.

[0040] Each trigger 210 can define, specify, or otherwise identify its respective timestamp 215, at which time the session management service sends, provides, or otherwise transmits at least one corresponding message 195 to the user device 170 to address the condition. Each timestamp 215 can define, specify, or otherwise identify the time at which the corresponding message 195 is sent. The timestamp 215 can be defined in units such as years, months, days, hours, minutes, seconds, and milliseconds. A set of timestamps 215 spans at least one period 220, which is, for example, a range of 5 to 6 months. The period 220 can correspond to a period during which digital treatment is provided (for example, in the form of a message 195). In some embodiments, this period can correspond to or be defined by the session management service 110 with respect to the application 175. In some embodiments, the period can correspond to or be defined by the duration between the first timestamp 215A and the last timestamp 215N in the schedule 205.

[0041] In some embodiments, at least one of a set of triggers 210 can define, specify, or otherwise identify at least one corresponding criterion that must be satisfied for the session management service 110 to send a corresponding message 195. This criterion can specify, define, or otherwise identify one or more conditions that data associated with a user device 170 (or an application 175 running on the user device 170) must satisfy for the session management service 110 to send the corresponding message 195. The data may include user profile information, interaction data, instructions for completion of a previous activity or task, device type, or location of the user device 170. In some embodiments, the criterion conditions may be added to a timestamp 215. For example, the criterion of trigger 210 may specify that, in order to provide the corresponding message 195, the user has completed a previous task by the time specified by the timestamp 215. In some embodiments, the criterion conditions may be a substitute for or independent of the timestamp 215. For example, the criteria for trigger 210 may specify that a user requests the provision of one or more corresponding messages 195 via application 175, regardless of time. Once schedule 205 is generated, event scheduler 160 may save and maintain schedule 205 in the storage device of session management service 110 using one or more files (e.g., Extended Markup Language (XML), comma-separated format (CSV) delimited text file, or Structural Query Language (SQL) file).

[0042] In some embodiments, the event scheduler 160 may generate the schedule 205 in a fixed manner. For example, the event scheduler 160 may generate the schedule 205 to include a set of triggers 210 during the initialization phase of a digital therapeutic intervention. The set of triggers 210 may remain fixed and unmodified throughout the period of a set of timestamps 215. In some embodiments, the event scheduler 160 may dynamically generate the schedule 205 when additional data (e.g., user profile information or user interaction data) is received from the user device 170 (or application 175). For example, the event scheduler 160 may use data received from the user device 170 during the period in which the digital therapeutic is provided (e.g., in the form of a message 195) to update or modify at least a portion of the set of triggers 210. The event scheduler 160 may use the new data received from the user device 170 to add new portions of the triggers 210 and timestamps 215 to the schedule 205. The event scheduler 160 can continue to generate triggers 210 and corresponding timestamps 215 for the entire period 220 (for example, for digital treatment). Once each trigger 210 and corresponding timestamp 215 of schedule 205 has been generated, the event scheduler 160 can send, provide, or transmit the trigger 210 and corresponding timestamp 215 to the test management service 105.

[0043] In some embodiments, the event scheduler 160 may apply a machine learning (ML) model to the data to identify at least a portion of the trigger 210 and a corresponding portion of the timestamp 215, and generate the schedule 205 in a dynamic manner. The event scheduler 160 may include an ML model for generating the trigger 210 and the corresponding portion of the timestamp 215. The ML model can be any architecture such as an artificial neural network (ANN) (e.g., an autoencoder, a convolutional neural network (CNN), or a transformer), a support vector machine (SVM), a clustering model (e.g., a k-nearest neighbor model), a Bayesian classifier, a decision tree, or a random forest. Generally, the ML model may include at least one input (e.g., data), at least one output (e.g., schedule 205), and a set of weights relating the input to the output.

[0044] Next, the ML model may be trained using a training dataset. The training dataset may include, for example, historical data associated with a user device or application (e.g., user profile information or user interaction data) and corresponding portions of triggers and timestamps. The weights of the ML model may be trained (e.g., by the session management service 110 or another service, according to supervised, unsupervised, or weakly supervised learning) to learn patterns in the training dataset. Once the ML model is established, the event scheduler 160 can apply the ML model to incoming data from the user device 170 (or application 175). The event scheduler 160 can process the data according to a set of weights of the ML model. From processing, the event scheduler 160 may generate portions of the trigger 210 and timestamp 215 of the schedule 205.

[0045] A schedule reader 130 running on the test management service 105 can retrieve, receive, or otherwise identify a schedule 205 from the event scheduler 160 that includes a set of triggers 210 and a set of corresponding timestamps 215. The schedule 205 may be generated in a fixed manner or may continue to be generated in a dynamic manner. In some embodiments, the schedule reader 130 can access the event scheduler 160 to identify, retrieve, or otherwise obtain a set of triggers 210 and a set of corresponding timestamps 215. If the schedule 205 is generated in a fixed manner, the schedule reader 130 can retrieve a schedule 205 that includes all of a set of triggers 210 and all of this set of corresponding timestamps 215 for a given period. If the schedule 205 is generated in a dynamic manner, the schedule reader 130 can retrieve, identify, or otherwise receive individual triggers 210 and their corresponding timestamps 215 as they are generated and provided by the event scheduler 160.

[0046] The schedule reader 130 can obtain or otherwise identify a set of triggers 210 and a set of corresponding timestamps 215 by accessing the event scheduler 160. In some embodiments, the schedule reader 130 can process or parse the schedule 205 to extract or identify a set of triggers 210 and a set of corresponding timestamps 215 from the schedule 205. The schedule reader 130 can identify or select at least one trigger 210 (e.g., trigger 210A) from the set of triggers 210. In the illustrated example, trigger 210A may be the first trigger 210 in the set of triggers 210 and may correspond to the initiation portion of a digital therapeutic intervention provided in the form of a message 195 corresponding to the user device 170. Trigger 210A may also correspond to the initiation portion of a digital therapeutic intervention during testing and validation. The schedule reader 130 can select or identify a trigger 210 from the initiation portion of a digital therapeutic intervention defined by the event scheduler 160. Once trigger 210 is identified, the schedule leader 130 can extract or identify the timestamp 215 of trigger 210. In the illustrated example, the schedule leader 130 can identify the timestamp 215A associated with the first trigger 210A. The timestamp 215A can correspond to the start of period 220.

[0047] A clock orchestrator 135 running on the test management service 105 can assign or set the global clock 150 to a timestamp 215 identified by a trigger 210. In the illustrated example, when the first trigger 210A is selected, the clock orchestrator 135 can assign or set the global clock 150 to the first timestamp 215A. In setting the global clock 150, the clock orchestrator 135 can change, modify, or otherwise correct the global clock 150 from an initial timestamp to a timestamp 215 (e.g., timestamp 215A) identified by a trigger 210 (e.g., trigger 210A). The initial timestamp can match the current time (e.g., the actual time). The timestamp 215 identified by the trigger 210 can match a time subsequent to the current time. Thus, the clock orchestrator 135 can correct the global clock 150 to timestamp 215 so as to override the current time prior to the actual time that matches timestamp 215. Once configured, the global clock 150 can keep track of the time and increment the time from the timestamp 215.

[0048] In response to setting the global clock 150 to timestamp 215, the clock orchestrator 135 may change, set, or otherwise modify the server clock 150' on the session management service 110 to set to timestamp 215 (e.g., timestamp 215A). Furthermore, the clock orchestrator 135 may change, set, or otherwise modify the local clock 150" on the user device 170 (or application 175) to set to timestamp 215 (e.g., timestamp 215A). As described above, the global clock 150 on the test management service 105 can access the server clock 150' on the session management service 110 and the local clock 150" on the user device 170. In some embodiments, the clock orchestrator 135 may cause the server clock 150' to set from an initial time (e.g., the current time) to timestamp 215 of the global clock 150. In some embodiments, the clock orchestrator 135 may cause the local clock 150" to set from an initial time (e.g., the current time) to a timestamp 215 of the global clock 150.

[0049] In some embodiments, the clock orchestrator 135 may create, generate, or otherwise produce at least one instruction 225. The instruction 225 may include or specify a timestamp 215 in which the global clock 150 is set. The instruction 225 may be generated in response to the setting of the global clock 150. The instruction 225 may change, set, or otherwise modify other clocks (e.g., server clock 150' and local clock 150") to the timestamp 215 (e.g., timestamp 215A) in which the global clock 150 is set. For example, the instruction 225 may include a command to synchronize the time of a receiving clock (e.g., server clock 150' and local clock 150") with the timestamp 215 of the global clock 150. The instruction 225 may be generated according to the Network Time Protocol (NTP), Precision Time Protocol (PTP), or timestamp insertion, etc. In some embodiments, the instruction 225 may include a command to the session management service 110 to evaluate a trigger 210 associated with the timestamp 215. This generation allows the clock orchestrator 135 to provide, transmit, or otherwise send commands 225 to the session management service 110 and the user device 170.

[0050] The session management service 110 (of the event scheduler 160) can change, set, or modify the server clock 150' from its initial timestamp to timestamp 215. In some embodiments, the session management service 110 can interface with or access the global clock 150 on the test management service 105 and obtain, retrieve, or identify the timestamp 215 of the global clock 150. The session management service 110 can access the global clock 150 according to a predefined cycle (e.g., intervals from 5 to 30 minutes). This identification allows the session management service 110 to modify or set the server clock 150' to timestamp 215. The timestamp 215 on the server clock 150' may be very similar (e.g., within 95%) to the timestamp 215 on the global clock 150. In some embodiments, the session management service 110 can obtain, retrieve, or receive an instruction 225 from the test management service 105. Upon receipt, the session management service 110 can extract or identify the timestamp 215 from the instruction 225. This identification allows the session management service 110 to correct or set the server clock 150' to timestamp 215. Once set, the server clock 150' can keep track of the time and increment the time from timestamp 215.

[0051] The user device 170 (or its application 175) can change, set, or otherwise modify the local clock 150" from its initial timestamp to timestamp 215. In some embodiments, the user device 170 can interface with or access the global clock 150 on the test management service 105 to retrieve, obtain, or identify timestamp 215. The user device 170 can access the global clock 150 according to a predefined cycle (e.g., intervals from 5 to 30 minutes). This identification allows the user device 170 to modify or set the local clock 150" to timestamp 215. In some embodiments, the user device 170 can retrieve, identify, or otherwise receive an instruction 225 from the test management service 105. Upon receipt, the user device 170 can extract or identify timestamp 215 from the instruction 225. A timestamp 215 on the local clock 150" may be very similar (e.g., within 95%) to a timestamp 215 on the global clock 150". This identification allows the user device 170 to modify or set the local clock 150" to timestamp 215. Once set, the local clock 150" can always keep track of the time and increment the time from timestamp 215.

[0052] Referring next to Figure 3, a block diagram of a process 300 for validating message delivery in a system 100 for simulating a test environment is shown. Process 300 includes, or can correspond to, an operation performed by system 100 to evaluate a trigger in order to validate message delivery. In process 300, with the server clock 150' set to timestamp 215 (e.g., illustrated timestamp 215A), a session handler 165 running on the session management service 110 can identify or determine whether to provide, send, or otherwise forward at least one message 195' to the user device 170. In some embodiments, in response to the time on the global clock 150 being set to or changed to timestamp 215, the test management service 105 can cause the session handler 165 to determine whether to send message 195'. In some embodiments, in response to the receipt of instruction 225, the test management service 105 can cause the session handler 165 to evaluate a trigger 210 and determine whether to send message 195' identified by the trigger 210. Message 195' can correspond to at least one of a set of messages 195 identified by the trigger 210. In some embodiments, message 195' can be identified by a criterion defined by the trigger 210 and sent to the user device 170. For example, message 195' can correspond to a message identified by the first trigger 210A and sent to the user device 170 if the criterion is satisfied.

[0053] To determine whether transmission is necessary, the session handler 165 can identify or determine whether the data associated with the user device 170 satisfies the criteria defined by the trigger 210. The evaluation of whether the criteria defined by the trigger 210 are satisfied can be performed according to a defined cycle (e.g., every 30 seconds to every hour). The data may identify or include, for example, user profile information, interaction data, instructions for completion of previous activities or tasks, device type, or the location of the user device 170. The data associated with the user device 170 can be received from the user device 170 (or application 175, or another device associated with the user device 170) or from the database 120 by aggregation, collection, or other means. The time of this data can extend to the timestamp 215 associated with the trigger 210. For example, the session handler 165 can acquire, identify, or otherwise receive data to check against the criteria over a time frame up to the time corresponding to the timestamp 215A specified by the trigger 210A. In some embodiments, this data may also be included as part of the test data of a test environment 115 that tests, validates, or evaluates the event scheduler 160 (or schedule 205).

[0054] If the data associated with the user device 170 satisfies the trigger criteria, the session handler 165 may decide to send message 195' to the user device 170. In some embodiments, the session handler 165 may determine that the data obtained up to timestamp 215 satisfies the trigger criteria. Once this determination is made, the session handler 165 may decide that message 195' should be sent to the user device 170. Once the decision to send message 195' is made, the session handler 165 may identify or select message 195' from a set of messages 195 in the database 120. Message 195' may correspond to at least one of a set of messages 195 defined by the trigger 210. Message 195' may include, for example, a short message / messaging service (SMS) message, a multimedia messaging service (MMS) message, or an in-app message. Message 195' may be presented in part concurrently with a drug treatment that the user (e.g., a potential user of the user device 170 or application 175) is receiving to address a medical condition. In certain cases, the session management service 110 may send or, in error, refrain from sending message 195' due to a software bug, a code defect, or a soft error. The behavior of the session management service 110 may be unexpected, unforeseen, or deviate from the developer's intentions.

[0055] Once a selection is made, the session handler 165 can send, provide, or otherwise transmit message 195' to the user device 170. In some embodiments, the session handler 165 can also update at least one transmission log 305 (also known here as a transaction log). This transmission log 305 may contain or identify a set of messages (or responses) exchanged between the session management service 110 and the user device 170. The transmission log 305 may be stored and maintained in a database (e.g., a database local to the session management service 110 or database 120) using one or more files (e.g., an Extended Markup Language (XML), a comma-separated values ​​(CSV) text file, or a Structured Query Language (SQL) file). The transmission log 305 may also contain or identify a timestamp corresponding to the transmission time of each message. The transmission log 305 is accessible by the test management service 105. In some embodiments, the transmission log 305 is maintained and updated by the test management service 105. When message 195' is sent, session handler 165 may update the transmission log 305 to include the identification information of message 195' and a timestamp corresponding to the time message 195' was sent.

[0056] Conversely, if the data associated with the user device 170 does not satisfy the trigger criteria, the session handler 165 may decide not to send message 195' to the user device 170. In some embodiments, the session handler 165 may determine that the data acquired up to timestamp 215 does not satisfy the trigger criteria. If this determination is made, the session handler 165 may decide not to send message 195' to the user device 170. If the decision not to send the message is made, the session handler 165 may refrain from sending the message associated with trigger 210 to the user device 170. The session handler 165 may proceed to evaluate the next trigger 210 (e.g., trigger 210B) after the time on the server clock 150' has passed the timestamp 215 (e.g., timestamp 215A) associated with the previous trigger 210 (e.g., trigger 210A). The session handler 165 can send, provide, or otherwise communicate its decision result (for example, whether or not to send message 195' associated with trigger 210 at timestamp 215) to the test management service 105.

[0057] The user device 170 (or application 175) can retrieve, identify, or receive message 195' from the session management service 110. Upon receiving this message, the user device 170 can display, render, or otherwise present message 195'. If message 195' is an SMS or MMS message, the user device 170 can present the contents of message 195' using a messaging application. This messaging application may be, for example, the default application used by the operating system on the user device 170, and can present and transmit messages using the SMS or MMS protocol. If message 195' is an in-app message, the application 175 running on the user device 170 can present the contents of message 195' via the UI element 190 of the user interface 185, according to the instructions in message 195'.

[0058] In some embodiments, the user device 170 may update at least one receive log 315 (also known here as a transaction log). The receive log 315 may contain or identify a set of messages or responses exchanged between the user device 170 and the session management service 110. The receive log 315 may be stored and maintained in a database (e.g., a database local to the session management service 110 or database 120) using one or more files (e.g., an Extended Markup Language (XML), a comma-separated values ​​(CSV) text file, or a Structured Query Language (SQL) file). The receive log 315 may contain or identify a timestamp corresponding to the time each message or response was delivered. The receive log 315 is accessible by the test management service 105. In some embodiments, the receive log 315 is maintained and updated by the test management service 105. When message 195' is received, the user device 170 may update the receive log 315 to include identification information for the receipt of message 195' and a timestamp corresponding to the receipt of message 195'.

[0059] When message 195' is presented, the user device 170 (or application 175) can create, generate, or otherwise produce at least one response 310. The response 310 may include an acknowledgment of receipt of message 195' or an indication that message 195' was presented via the user device 170. In some embodiments, the user device 170 can retrieve, acquire, or identify data associated with the presentation of message 195'. This data may include interaction data or event data for processes on the user device 170, and may also be part of the test data for a test environment 115 to test, validate, or evaluate the event scheduler 160 (or schedule 205). In some embodiments, the user device 170 can generate a response 310 that includes data (e.g., user interaction data or event data).

[0060] Once response 310 is generated, user device 170 can send, provide, or otherwise transmit response 310 to session management service 110. Upon transmission of response 310, user device 170 can update the receive log 315 to include the identification information of response 310 and a timestamp corresponding to the transmission time of response 310. The session handler 165 can then retrieve, identify, or receive response 310 from user device 170. Upon receiving response 310, session handler 165 can update the transmission log 305 to include the identification information of response 310 and a timestamp corresponding to the reception time of response 310. Furthermore, session handler 165 can store and maintain response 310 in database 120.

[0061] Furthermore, the trigger validator 140, running on the test management service 105, can determine or identify whether message 195' is being transmitted between the session management service 110 and the user device 170 according to the trigger 210. Based on whether message 195' is being properly transmitted as specified in the trigger 210, the trigger validator 140 can determine whether to validate the trigger 210 associated with the timestamp 215. To determine this, the trigger validator 140 can determine whether the criteria for the trigger 210 are being met. The trigger validator 140 can interface with or access the session handler 165 and obtain, retrieve, or otherwise identify the evaluation results of the trigger 210 executed by the session handler 165 of the session management service 110. In addition, the trigger validator 140 can monitor or verify the transmission of message 195' between the session management service 110 and the user device 170. In some embodiments, the trigger validator 140 may monitor or verify whether the response 310 is transmitted from the user device 170 to the session management service 110 within a timeframe (e.g., 30 seconds to 1 hour) relative to the transmission of the previous message 195'. In some embodiments, the trigger validator 140 may monitor updates to the transaction log (e.g., transmission log 305 or reception log 315) of the transmitted message and response.

[0062] If the criteria for trigger 210 are met, the trigger validator 140 can determine or identify whether message 195' is being transmitted between the session management service 110 and the user device 170 in accordance with trigger 210. If it is determined that message 195' is being sent from the session management service 110 and the user device 170 (e.g., from monitoring or from the transaction log), the trigger validator 140 can determine that message 195' is being transmitted in accordance with trigger 210. In some embodiments, if a response 310 to message 195' is received within the time frame of message 195', the trigger validator 140 can further determine that message 195' is being transmitted in accordance with trigger 210. Furthermore, if it is confirmed that message 195' is being transmitted in accordance with trigger 210, the trigger validator 140 can determine or identify that trigger 210 of the event scheduler 160 (or schedule 205) is valid.

[0063] On the other hand, if it is determined that message 195' has not been sent from the session management service 110 and the user device 170, the trigger validator 140 may determine that message 195' has not been propagated according to the trigger 210. Furthermore, if it is determined that message 195' has not been propagated as specified in the trigger 210, the trigger validator 140 may determine or decide that the trigger 210 of the event scheduler 160 (or schedule 205) has not been validated. In some embodiments, in response to the determination in the first attempt that message 195' has not been propagated according to the trigger 210, the trigger validator 140 may retry or attempt again to cause the session management service 110 to send message 195'. For example, the trigger validator 140 may create, generate, or otherwise produce an instruction for the session management service 110 to re-evaluate the trigger 210. Upon receiving this, the session handler 165 re-evaluates the criteria for trigger 210, and the system 100 can repeat the functions detailed herein as a second attempt.

[0064] Conversely, if the criteria for trigger 210 are not met, the trigger validator 140 can determine or identify whether message 195' has not been transmitted between the session management service 110 and the user device 170 in accordance with trigger 210. If it is determined that message 195' has not been sent from the session management service 110 and the user device 170 (e.g., from monitoring or from the transaction log), the trigger validator 140 can determine that message 195' has not been transmitted in accordance with trigger 210. Furthermore, if it is determined that message 195' has not been transmitted as specified in trigger 210, the trigger validator 140 can determine or determine that trigger 210 of the event scheduler 160 (or schedule 205) is valid. On the other hand, if it is determined that message 195' has been sent from the session management service 110 and the user device 170, the trigger validator 140 can determine that message 195' has not been transmitted in accordance with trigger 210. Furthermore, if it is confirmed that message 195' is being transmitted according to trigger 210, the trigger validator 140 may identify or determine that trigger 210 of event scheduler 160 (or schedule 205) has not been validated. In some embodiments, in response to the determination that at least one trigger 210 (e.g., trigger 210A) has not been validated, the trigger validator 140 may stop testing and validating a set of triggers 210 of event scheduler 160 (or scheduler 205).

[0065] Referring next to Figure 4, a block diagram of process 400 for readjusting the global clock and validating message delivery in system 100 for simulating a test environment is shown. Process 400 includes, or may include, operations to readjust the clock in accordance with a subsequent trigger and evaluate the trigger to validate message delivery. Process 400 may overlap with, or be a repetition of, the operations of processes 200 and 300 detailed herein for another trigger 210 or timestamp 215. Under process 400, the schedule leader 130 can identify or select at least one subsequent trigger 210 from a set of triggers 210 of the event scheduler 160 (or schedule 205). The selection of a subsequent trigger 210 may be similar to the selection of a previous trigger 210 (e.g., trigger 210A), as detailed herein. In some embodiments, the schedule leader 130 may select a subsequent trigger 210 if it determines that a previous trigger 210 has been validated. In some embodiments, the schedule leader 130 can select a subsequent trigger 210 regardless of whether the previous trigger 210 has been validated. In some embodiments, the subsequent trigger 210 is identified by the previous trigger 210 as the next trigger to be evaluated in schedule 205.

[0066] The schedule leader 130 can access the event scheduler 160 (or schedule 205) to obtain, retrieve, or otherwise identify subsequent triggers 210. Subsequent triggers 210 may be generated by the event scheduler 160 in a fixed manner or in a dynamic manner. Once triggers 210 are identified, the schedule leader 130 can extract or identify the timestamp 215 of triggers 210. In the illustrated example, trigger 210N is the last trigger 210 in a set of triggers 210 and can define a timestamp 215N corresponding to the end of period 220. In some embodiments, trigger 210N may correspond to the end of a digital therapeutic intervention provided to the user device 170 in the form of a corresponding message 195.

[0067] The clock orchestrator 135 can assign or set the global clock 150 to the timestamp 215 identified by the trigger 210. Setting the global clock 150 using timestamp 215 (e.g., timestamp 215N) can be similar to setting the global clock 150 as described herein (e.g., using timestamp 215A). In the illustrated example, when the last trigger 210N is selected, the clock orchestrator 135 can assign or set the global clock 150 to the last timestamp 215N. In setting the global clock 150, the clock orchestrator 135 can change, modify, or otherwise correct the global clock 150 from a previously tested timestamp to the timestamp 215 (e.g., timestamp 215N) identified by the trigger 210 (e.g., trigger 210N). The previous timestamp matches the timestamp 215 of the previous trigger 210 and is incremented by some amount from the previous evaluation of the previous trigger 210. In response to setting the global clock 150 to timestamp 215, the clock orchestrator 135 may change, set, or otherwise modify the server clock 150' and local clock 150'' to be set to timestamp 215 (e.g., timestamp 215N).

[0068] In some embodiments, the clock orchestrator 135 can create, generate, or otherwise produce at least one instruction 225'. The instruction 225 may include or specify a timestamp 215 (timestamp 215N) on which the global clock 150 is set. Once generated, the clock orchestrator 135 can provide, transmit, or otherwise send the instruction 225 to the session management service 110 and the user device 170. The session management service 110 (of the event scheduler 160) can change, set, or modify the server clock 150' from a previous timestamp to timestamp 215. Furthermore, the user device 170 (or its application 175) can change, set, or otherwise modify the local clock 150' from a previous timestamp to timestamp 215. The previous timestamp matches the timestamp 215 of a previous trigger 210 and is incremented by some amount from the previous evaluation of the previous trigger 210.

[0069] The session handler 165 on the session management service 110 can determine or decide whether to provide, send, or otherwise forward at least one message 195" to the user device 170, given that the server clock 150' is set to timestamp 215 (e.g., timestamp 215N as shown). Sending message 195" may be the same as sending message 195' as described above. To determine whether sending is necessary, the session handler 165 can determine or decide whether the data associated with the user device 170 satisfies the criteria defined by the trigger 210. The evaluation of whether the criteria defined by the trigger 210 are satisfied may be performed according to a defined cycle. As described above, the data associated with the user device 170 can be received from the user device 170 (or application 175, or another device associated with the user device 170) or from the database 120 by aggregation, collection, or other means. The time of this data may extend to timestamp 215 associated with the trigger 210 (e.g., up to timestamp 215N).

[0070] If the data associated with user device 170 satisfies the trigger criteria, session handler 165 may decide to send message 195" to user device 170. In some embodiments, session handler 165 may determine that the data obtained up to timestamp 215 satisfies the trigger criteria. Once this determination is made, session handler 165 may decide that message 195" should be sent to user device 170. Once the decision to send message 195" is made, session handler 165 may identify or select message 195" from a set of messages 195 in database 120. Once the selection is made, session handler 165 may send, provide, or otherwise transmit message 195" to user device 170. In some embodiments, session handler 165 may also update the transmission log 305 to include or specify the transmission at timestamp 214. Conversely, if the data associated with user device 170 does not satisfy the trigger criteria, session handler 165 may decide not to send message 195" to user device 170. In some embodiments, the session handler 165 may determine that the data acquired up to timestamp 215 does not satisfy the trigger criteria. If this determination is made, the session handler 165 may decide not to send message 195" to the user device 170.

[0071] User device 170 (or application 175) can obtain, identify, or receive message 195" from session management service 110. Upon receiving this message, user device 170 can display, render, or otherwise present message 195"." In some embodiments, the user device 170 may also update at least one receive log 315 to include or identify the receipt of message 195''. Once message 195'' is presented, the user device 170 (or application 175) may create, generate, or otherwise produce at least one response 310''. The production of response 310'' may be similar to the production of response 310'' described above. Response 310'' may include an acknowledgment of receipt of message 195'' or an indication that message 195'' was presented via the user device 170. Once response 310 is produced, the user device 170 may send, provide, or otherwise transmit response 310 to the session management service 110. Once response 310 is sent, the user device 170 may update the receive log 315 to include identification information for response 310 and a timestamp corresponding to the time response 310 was sent.

[0072] The trigger validator 140 can determine or identify whether message 195" is being transmitted between the session management service 110 and the user device 170 in accordance with the trigger 210. The identification information and validation for message 195" may be similar to those for message 195' as described above. Based on whether message 195" is being properly transmitted as specified in the trigger 210, the trigger validator 140 can determine whether to validate the trigger 210 associated with the timestamp 215.

[0073] If the criteria for trigger 210 are satisfied, the trigger validator 140 can determine or identify whether message 195" is being transmitted between the session management service 110 and the user device 170 in accordance with trigger 210. If it is determined that message 195" is being sent from the session management service 110 and the user device 170 (for example, from monitoring or from the transaction log), the trigger validator 140 can identify that message 195" is being transmitted in accordance with trigger 210. In some embodiments, the trigger validator 140 can further identify that message 195" is being transmitted in accordance with trigger 210 if a response 310 to message 195" is received within the time frame of message 195". Furthermore, if it is confirmed that message 195" is being transmitted according to trigger 210, the trigger validator 140 can identify or determine that trigger 210 of event scheduler 160 (or schedule 205) is valid. On the other hand, if it is determined that message 195" is not being sent from session management service 110 and user device 170, the trigger validator 140 can identify that message 195" is not being transmitted according to trigger 210. Furthermore, if it is determined that message 195" is not being transmitted as specified in trigger 210, the trigger validator 140 can identify or determine that trigger 210 of event scheduler 160 (or schedule 205) is not valid.

[0074] Conversely, if the criteria for trigger 210 are not met, the trigger validator 140 can determine or identify whether message 195" has not been transmitted between the session management service 110 and the user device 170 in accordance with trigger 210. If it is determined that message 195" has not been sent from the session management service 110 and the user device 170 (e.g., from monitoring or from the transaction log), the trigger validator 140 can determine that message 195" has not been transmitted in accordance with trigger 210. Furthermore, if it is determined that message 195" has not been transmitted as specified in trigger 210, the trigger validator 140 can determine or determine that trigger 210 of the event scheduler 160 (or schedule 205) is valid. On the other hand, if it is determined that message 195" has been sent from the session management service 110 and the user device 170, the trigger validator 140 can determine that message 195" has not been transmitted in accordance with trigger 210. Furthermore, if it is confirmed that message 195" is being propagated according to trigger 210, the trigger validator 140 may identify or determine that trigger 210 of event scheduler 160 (or schedule 205) is not validated.

[0075] A test evaluator 145 running on the test management service 105 can identify or determine whether the event scheduler 160 (or schedule 205) has been validated, based on whether the triggers 210 have been validated. Validation can be performed before the actual time corresponding to the end of the period 220. For example, the test evaluator 145 can determine that all triggers 210 in a set have been successfully validated, and therefore, even though the period 220 spans from 60 to 90 days, the validation of the event scheduler 160 (or schedule 205) will be completed within 30 minutes. If it is determined that the message 195 for each trigger 210 in a set of triggers 210 has been successfully delivered, the test evaluator 145 can identify or determine that the event scheduler 160 (or schedule 205) has been validated. In some embodiments, the test evaluator 145 may determine that the event scheduler 160 (or schedule 205) is validated if it determines that each trigger 210 of a set of triggers 210 has been successfully validated. In some embodiments, the test evaluator 145 may identify or determine that the event scheduler 160 is validated if it determines that the last trigger 210 (e.g., trigger 210N) of a time frame 220 has been successfully validated. Conversely, the test evaluator 145 may identify or determine that the event scheduler 160 (or schedule 205) is not validated if it determines that the message 195 of at least one trigger 210 of a set of triggers 210 has not been successfully delivered. In some embodiments, the test evaluator 145 may determine that the event scheduler 160 (or schedule 205) is not validated if it determines that at least one trigger 210 of a set of triggers has not been successfully validated.

[0076] Based on the validation results, the test evaluator 145 may create, generate, or otherwise produce at least one output 405. If the event scheduler 160 (or schedule 205) is determined to be validated, the test evaluator 145 may generate an output 405 that indicates the event scheduler 160 (or schedule 205) is validated or includes an indicator indicating this. In some embodiments, the test evaluator 145 may generate an output 405 that indicates all triggers 210 in a set have been validated. On the other hand, if the event scheduler 160 (or schedule 205) is determined to be unvalidated, the test evaluator 145 may generate an output 405 that identifies the event scheduler 160 (or schedule 205) as unvalidated or includes an indicator indicating this. In some embodiments, the test evaluator 145 may generate an output 405 that includes at least one identifier corresponding to at least one trigger 210 of a set of unvalidated triggers.

[0077] In some embodiments, the test evaluator 145 may use at least a portion of the transaction log (e.g., the send log 305 or the receive log 315) to generate output 405. Output 405 may be generated to include an identifier for the transaction log corresponding to at least one of the send log 305 or the receive log 315. The identifier can uniquely refer to the transaction log and may include, for example, a uniform resource locator (URL). The receiver can use the identifier to access the transaction log containing a set of messages and responses transmitted between the session management service 110 and the user device 170. If it is determined that the event scheduler 160 (or schedule 205) has been validated, the test evaluator 145 may generate output 405 containing an indication that the event scheduler 160 (or schedule 205) has been successfully validated and the identifier for the transaction log. If the event scheduler 160 (or schedule 205) is determined to be unvalidated, the test evaluator 145 may generate output 405 which includes an indication that the event scheduler 160 (or schedule 205) is unvalidated and a transaction log identifier. In some embodiments, the test evaluator 145 may generate output 405 which includes at least one identifier corresponding to at least one trigger 210 of a set of unvalidated triggers and a transaction log identifier.

[0078] Once output 405 is generated, the test evaluator 145 can send, transmit, or otherwise provide output 405. Output 405 can be provided and displayed on a display (or computing device) communicatively coupled to the test management service 105. Users of the test management service 105 can use output 405 to view the results of the testing and validation of the event scheduler 160. If there are unvalidated triggers 210, the user can further examine the contents of output 405 to determine which triggers 210 contributed to the failure of the event scheduler 160 validation. Based on output 405, the user can adjust, modify, or otherwise correct the configuration (e.g., programming code or scripts) of the session management service 110, user device 170, or application 175.

[0079] By using the global clock 150 to systematically set, disable, and advance the time of the server clock 150' and local clock 150", the test management service 105 can significantly reduce and streamline the time it would take to test and validate a set of triggers 210 and the event scheduler 160 of application 175. The required time can be reduced from weeks or months (for example, to minutes or hours) to minutes or hours. Thus, the test management service 105 can streamline the testing and validation process itself. This increases the number of functions that can be tested within a defined time. As more functions can be tested and validated, the overall capabilities of the session management service 110 and the user device 170, as well as the communication between them, can be significantly improved and optimized. This optimization can lead to savings in computing resources (e.g., processing and memory) and reduced network bandwidth consumption in both the session management service 110 and the user device 170. In the context of digital therapy, the test management service 105 can further ensure that the session management service 110 and the application 175 address the user's condition more efficiently.

[0080] Referring here to Figures 5A-C, a block diagram of Method 500 for simulating the application's test environment over several timeframes is shown. Method 500 can be implemented or run using any of the components described herein, or any combination thereof, such as the test management service 105, the session management service 110, or the user device 110. According to Method 500, the computing system can identify a set of triggers in the event scheduler (502). The computing system can select one trigger from the set of triggers (504). The computing system can set a clock to the timestamp of the trigger (506). The computing system can have the service evaluate this trigger (508). The computing system can determine whether the trigger has been satisfied (510).

[0081] If the trigger is satisfied, the computing system can determine whether the message has been delivered (530). If it is determined that the message has not been delivered, the computing system can determine that the trigger is not validated (532). The computing system can determine that the event scheduler is not validated (534). On the other hand, if it is determined that the message has been delivered, the computing system can determine that the trigger is validated (536). The computing system can determine whether there are any additional triggers (538). If there are no additional triggers, the computing system can generate output (540). In contrast, if there are additional triggers, the computing system can identify the next trigger (542) and repeat the function from step (506).

[0082] Conversely, if the trigger is not satisfied, the computing system can determine whether the message has been delivered (560). If it is determined that the message has been delivered, the computing system can determine that the trigger is not validated (562). The computing system can determine that the event scheduler is not validated (564). On the other hand, if it is determined that the message has not been delivered, the computing system can determine that the trigger is validated (566). The computing system can determine whether there are additional triggers (568). If there are no additional triggers, the computing system can generate output (570). In contrast, if there are additional triggers, the computing system can identify the next trigger (572) and repeat the function from step (506).

[0083] C. Network and Computing Environment The various operations described herein can be performed on a computer system. Figure 6 shows a simplified block diagram of a typical server system 600, a client computer system 614, and a network 626 that can be used to implement a particular embodiment of this disclosure. In various embodiments, the server system 600 or a similar system can implement the services or servers or parts thereof described herein. The client computer system 614 or a similar system can implement the clients described herein. System 100 described herein may be similar to the server system 600. The server system 600 may have a modular design incorporating many modules 602 (e.g., blades in an embodiment of a blade server), and although two modules 602 are shown, any number can be provided. Each module 602 may include one or more processing units 604 and local storage devices 606.

[0084] One or more processing units 604 may include a single processor having one or more cores, or multiple processors. In some embodiments, one or more processing units 604 may include a general-purpose primary processor in addition to one or more dedicated coprocessors, such as a graphics processor or a digital signal processor. In some embodiments, some or all of the processing units 604 may be implemented using customized circuits such as application-specific integrated circuits (ASICs) or user-writable grid arrays (FPGAs). In some embodiments, such integrated circuits execute instructions stored in the circuit itself. In other embodiments, one or more processing units 604 may execute instructions stored in local memory 606. Any combination of any type of processor may be included in one or more processing units 604.

[0085] The local storage device 606 may include volatile storage media (e.g., DRAM, SRAM, SDRAM, etc.) and / or non-volatile storage media (e.g., magnetic disks or optical disks, flash memory, etc.). The storage media incorporated into the local storage device 606 may be fixed, removable, or upgradeable, as desired. The local storage device 606 may be physically or logically divided into various units such as system memory, read-only memory (ROM), and permanent storage. The system memory may be a read-write memory device or a volatile read-write memory such as dynamic random-access memory. The system memory may store some or all of the instructions and data required by one or more processing units 604 at runtime. The ROM may store static data and instructions required by one or more processing units 604. The permanent storage may be a non-volatile read-write memory device that can store instructions and data even when the power to module 602 is turned off. As used herein, the term “storage medium” includes any medium capable of storing data indefinitely (without overwriting, electrical interference, power loss, etc.), but does not include carrier waves or transient electronic signals propagated wirelessly or via wired connections.

[0086] In some embodiments, the local storage device 606 can store one or more software programs executed by one or more processing units 604, such as an operating system, and / or programs that implement various server functions, such as functions of system 100 or any other system described herein, or any other one or more servers associated with system 100 or any other system described herein.

[0087] "Software" generally refers to a sequence of instructions that, when executed by one or more processing units 604, cause the server system 600 (or a part thereof) to perform various operations, and thus defines a specific implementation example of one or more particular machines that execute and perform the operations of a software program. Instructions can be stored as firmware residing in read-only memory for execution by one or more processing units 604, and / or as program code stored in a non-volatile storage medium that can be loaded into volatile working memory. Software can be implemented as a single program, or as a collection of separate programs or program modules that interact as desired. To perform the various operations described above, one or more processing units 606 can retrieve program instructions to execute and data to process from local storage devices 604 (or non-local storage devices described later).

[0088] In some server systems 600, multiple modules 602 can be interconnected via a bus or other interconnect 608 to form a local area network that supports communication between the modules 602 and other components of the server system 600. The interconnect 608 can be implemented using various technologies, including server racks, hubs, routers, etc.

[0089] The wide area network (WAN) interface 610 can enable data communication between the local area network (e.g., via interconnect 608) and a network 626 such as the Internet. The server system can be connected to network 626 in a communicative manner using other technologies, including wired technologies (e.g., Ethernet, IEEE 802.3 standard) and / or wireless technologies (e.g., Wi-Fi, IEEE 802.11 standard).

[0090] In some embodiments, the local storage device 606 is intended to provide working memory to one or more processing units 604, providing high-speed access to programs and / or data being processed while reducing traffic on the interconnect 608. Storage for larger amounts of data can be provided on the local area network by one or more mass storage subsystems 608 connectable to the interconnect 612. The mass storage subsystem 612 can be based on magnetic, optical, semiconductor, or other data storage media. Direct-attached storage, storage area networks, network-attached storage, etc., can be used. Any stored data or other aggregates of data described herein as generated, consumed, or maintained by a service or server can be stored in the mass storage subsystem 612. In some embodiments, additional data storage resources are accessible via the WAN interface 610 (although this may increase latency).

[0091] The server system 600 can operate in response to requests received via the WAN interface 610. For example, one of several modules 602 may implement a management function and, in response to a received request, assign individual tasks to other modules 602. Task assignment techniques can be used. Once a request is processed, the result can be returned to the requesting party via the WAN interface 610. Generally, such operations can be automated. Furthermore, in some embodiments, the WAN interface 610 can connect multiple server systems 600 to each other, providing a scalable system capable of managing a large volume of activity. Other techniques can be used to manage server systems and server farms (collections of server systems cooperating with each other), including dynamic resource allocation and reallocation.

[0092] The server system 600 can interact with various user-owned or user-operated devices via a wide-area network such as the Internet. An example of a user-operated device is shown in Figure 6 as a client computing system 614. The client computing system 614 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, or laptop computer.

[0093] For example, the client computing system 614 can communicate via the WAN interface 610. The client computing system 614 may include computer components such as one or more processing units 616, a storage device 618, a network interface 620, a user input device 622, and a user output device 624. The client computing system 614 may be a computing device implemented in various form factors, such as a desktop computer, a laptop computer, a tablet computer, a smartphone, other mobile computing devices, or a wearable computing device.

[0094] The processing unit 616 and the storage device 618 can be the same as the one or more processing units 604 and local storage device 606 described above. The appropriate devices can be selected based on the requirements imposed on the client computing system 614. For example, the client computing system 614 can be implemented as a "thin" client with limited processing power, or as a high-performance computing device. The client computing system 614 may include program code executable by one or more processing units 616 to enable various interactions with the server system 600.

[0095] The network interface 620 can provide a connection to a network 626, such as a wide area network (e.g., the Internet), to which the WAN interface 610 of the server system 600 is also connected. In various embodiments, the network interface 620 may include a wired interface (e.g., Ethernet) and / or a wireless interface that implements various wireless data communication standards such as Wi-Fi, Bluetooth, or cellular data network standards (e.g., 3G, 4G, LTE, etc.).

[0096] The user input device 622 may include any device (or more devices) on which the user can send signals to the client computing system 614, which can interpret such signals as indicating a specific user request or information. In various embodiments, the user input device 622 may include any or all of the following: a keyboard, touchpad, touchscreen, mouse or other pointing device, scroll wheel, click wheel, dial, button, switch, keypad, microphone, etc.

[0097] The user output device 624 may include any device on which the client computing system 614 can provide information to the user. For example, the user output device 624 may include a display-to-display shared image generated by or transmitted to the client computing system 614. 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, and cathode ray tubes (CRTs), along with auxiliary electronic equipment (e.g., digital-to-analog or analog-to-digital converters, signal processors, etc.). Some embodiments may include a device such as a touchscreen that functions as both an input and an output device. In some embodiments, other user output devices 624 may be provided in addition to, or instead of, the display. Examples include indicator lights, speakers, haptic "display" devices, and printers.

[0098] Some embodiments include electronic components such as microprocessors, storage devices, and memory that store computer program instructions on a computer-readable storage medium. Many of the features described herein can be implemented as processes designated as a set of program instructions encoded on a computer-readable storage medium. When one or more processing units execute these program instructions, they cause one or more processing units to perform the various operations indicated by the program instructions. Examples of program instructions or computer code include machine code generated by a compiler and files containing higher-level code that is executed by a computer, electronic components, or microprocessor using an interpreter. With appropriate programming, one or more processing units 604 and 616 can provide a variety of functions, including any or other functions described herein as being executed by a server or client, to the server system 600 and the client computing system 614.

[0099] It will be understood that the server system 600 and client computing system 614 are illustrative and are subject to modification and alteration. Computer systems used in connection with embodiments of this disclosure may have other functions not specifically described herein. Furthermore, while the server system 600 and client computing system 614 are described with reference to specific blocks, it should be understood that these blocks are defined for illustrative purposes only and are not intended to imply a specific physical arrangement of components. For example, different blocks may, but are not required to, be located in the same facility, in the same server rack, or on the same motherboard. Moreover, these blocks do not need to correspond to physically separate components. Blocks may be configured to perform various operations, for example, by programming a processor or by providing appropriate control circuits, and the different blocks may be reconfigurable or non-reconfigurable depending on how the initial configuration is obtained. Embodiments of this disclosure can be realized in a variety of devices, including electronic devices implemented using any combination of circuitry and software.

[0100] While this disclosure has described specific embodiments, those skilled in the art will recognize that numerous modifications are possible. Embodiments of this disclosure can be implemented using a variety of computer systems and communication technologies, including but not limited to the specific examples described herein. Embodiments of this disclosure can be implemented using dedicated components and / or any combination of programmable processors and / or other programmable devices. The various operations described herein can be performed with the same processor or any combination of different processors. Where a component is described as being configured to perform a particular operation, such configuration can be achieved, for example, by designing an electronic circuit to perform that operation, by programming a programmable electronic circuit (such as a microprocessor) to perform that operation, or by 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 may also be used, that a particular operation described as being implemented in hardware may also be implemented in software, and vice versa.

[0101] Computer programs incorporating 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 tapes, compact discs (CDs) or digital versatile discs (DVDs), flash memory, and other non-transient media. The computer-readable media encoded with the program code may be packaged together with compatible electronic devices, or the program code may be provided separately from the electronic devices (for example, via internet download or as separately packaged computer-readable storage media).

[0102] Thus, although this disclosure has described specific embodiments, it will be understood that this disclosure is intended to cover all modifications and equivalents within the scope of the following claims.

Claims

1. A method for simulating a test environment for digital therapeutic applications to address disease conditions over several timeframes: The step of selecting one or more triggers from a plurality of triggers of an event scheduler to address a pathological condition, wherein each of the plurality of triggers identifies a timestamp from a plurality of timestamps, and at each of the selected timestamps, the service sends a corresponding message to the user device to address the pathological condition; The steps include setting a clock by one or more processors to the timestamp of one of the triggers, wherein the clock is accessible to the service and the user device; The steps include: causing one or more processors to cause the service to send a message to the user device to address the condition in response to the timestamp of the clock matching the timestamp of one of the triggers; The steps include: determining by one or more processors that the message is being transmitted between the service and the user device in accordance with one of the triggers; A method comprising the step of determining that one of the event scheduler triggers has been validated in response to the identification of the message being delivered by one or more processors.

2. A step of selecting a second trigger from the plurality of triggers in response to the validation of one of the triggers by one or more processors, wherein the second trigger identifies a second timestamp corresponding to the end of a period spanning the plurality of timestamps; The steps include setting the clock to the second timestamp of the second trigger using one or more of the aforementioned processors; The steps include: causing one or more processors to cause the service to send a second message to the user device to address the condition in response to the second timestamp of the clock matching the second timestamp of one of the triggers; The steps include: determining by one or more processors that the service has sent the second message to the user device in accordance with the second trigger; The method according to claim 1, further comprising the step of determining that the event scheduler is validated prior to the end of the period, in response to the identification by one or more processors that the service has received the second message.

3. The method according to claim 2, wherein the step of determining that the event scheduler is valid further includes the step of determining that the event scheduler is valid in response to the service determining that it has successfully sent each of the trigger messages of the plurality of triggers to the user device.

4. The steps include: setting the clock to the second timestamp of the second trigger of the plurality of triggers using one or more of the aforementioned processors; The steps include: causing one or more processors to cause the service to send a second message to the user device to address the condition in response to the second timestamp of the clock matching the second timestamp of the second trigger; The method according to claim 1, further comprising the step of determining that the second trigger of the event scheduler has not been validated in response to one or more processors determining that the second message has not been propagated.

5. The method according to claim 4, further comprising the step of having one or more processors, in response to the determination that the second message was not delivered in the first attempt, attempt again to cause the service to send the second message to the user device in a second attempt.

6. The steps include: one or more processors, in response to a determination that the second trigger has not been validated, obtaining a transaction log that identifies one or more of the multiple messages transmitted between the service and the user device; The method according to claim 4, further comprising the step of having one or more processors generate an output including at least one of an instruction for failure to validate the second trigger and identification information for the transaction log.

7. The method according to claim 1, further comprising the steps of (i) causing the service to set a service clock from a first timestamp to the timestamp of the clock, and (ii) causing the user device to set a device clock from a second timestamp to the timestamp of the clock, by one or more processors.

8. The method according to claim 1, wherein the event scheduler includes a machine learning model that generates at least some of the plurality of triggers of the event scheduler.

9. At least one of the aforementioned triggers further identifies the respective criteria that the service should be satisfied with sending the corresponding message to address the condition. The method according to claim 1, further comprising the step of causing the service to send the message in response that the data associated with the user device satisfies the respective criteria identified by the trigger.

10. The method according to claim 1, wherein the step of setting the clock further includes the step of modifying the clock from an initial timestamp corresponding to the current time to a timestamp corresponding to a subsequent time identified by the one trigger, prior to the occurrence of the subsequent time.

11. The method according to claim 1, wherein the steps of determining that the message has been delivered further include: (i) determining that the service has sent the message using the transmission log associated with the service; (ii) determining that the user device has received the message from the service using the reception log associated with the user device; or (iii) determining that the service has received a response from the user device within a certain time frame for sending the message.

12. The method according to claim 1, wherein the message comprises at least one of a Short Message Service (SMS) message, a Multimedia Messaging Service (MMS) message, or an in-app message, and the message is presented at least partially concurrently with the user taking the drug.

13. A system that simulates a test environment for digital therapeutic applications to address disease conditions over several timeframes: It includes one or more processors coupled to memory, and such processors are: To address a condition, one trigger is selected from multiple triggers in the event scheduler, each of which identifies a timestamp from multiple timestamps, and at each of these timestamps, the service sends a corresponding message to the user device to address the condition; The clock is set to the timestamp of the one trigger, and the clock is accessible to the service and the user device; In response to the timestamp of the clock matching the timestamp of the one trigger, the service causes the user device to send a message to address the condition; Identifying that the message is being transmitted between the service and the user device in accordance with the one trigger; A system that, in response to the identification of the transmission of the aforementioned message, determines that the one trigger of the event scheduler has been validated.

14. The aforementioned one or more processors: In response to the validation of the first trigger, a second trigger is selected from the plurality of triggers, the second trigger identifies a second timestamp corresponding to the end of the period spanning the plurality of timestamps; Set the aforementioned clock to the second timestamp of the second trigger; In response to the second timestamp of the clock matching the second timestamp of the one trigger, the service causes the user device to send a second message to address the condition; The service identifies that it has sent the second message to the user device in accordance with the second trigger; The system according to claim 13, further configured to determine that the event scheduler is valid prior to the end of the period in response to the identification that the service has received the second message.

15. The system according to claim 14, wherein the one or more processors are further configured to determine that the event scheduler is valid in response to the identification that the service has successfully sent a message for each of the plurality of triggers to the user device.

16. The aforementioned one or more processors: The aforementioned clock is set to the second timestamp of the second trigger of the plurality of triggers; In response to the second timestamp of the clock matching the second timestamp of the second trigger, the service is instructed to send a second message to the user device to address the condition; The system according to claim 13, further configured to determine that the second trigger of the event scheduler is not valid in response to the determination that the second message has not been transmitted.

17. The system according to claim 16, wherein the one or more processors are further configured to, in response to the determination that the second message was not delivered in the first attempt, attempt again to cause the service to send the second message to the user device in a second attempt.

18. The aforementioned one or more processors: In response to the determination that the second trigger has not been validated, obtain a transaction log that identifies one or more of the multiple messages transmitted between the service and the user device; The system according to claim 14, further configured to generate output including at least one of an instruction for a failure to validate the second trigger and identification information for the transaction log.

19. The system according to claim 13, wherein the one or more processors are further configured to (i) cause the service to set a service clock from a first timestamp to the timestamp of the clock, and (ii) cause the user device to set a device clock from a second timestamp to the timestamp of the clock.

20. The system according to claim 13, wherein the event scheduler includes a machine learning model that generates at least some of the plurality of triggers of the event scheduler.

21. At least one of the aforementioned triggers further identifies the respective criteria that the service should be satisfied with sending the corresponding message to address the condition. The system according to claim 13, wherein the one or more processors are further configured to cause the service to send the message, which further includes causing the service to send the message in response that data associated with the user device satisfies the respective criteria identified by the trigger.

22. The system according to claim 13, wherein the one or more processors are further configured to modify the clock from an initial timestamp corresponding to the current time to a timestamp corresponding to a subsequent time identified by one of the triggers, prior to the occurrence of the subsequent time.

23. The system according to claim 13, wherein the one or more processors are further configured to determine that the message has been delivered by at least one of: (i) determining that the service has sent the message using the transmission log associated with the service; (ii) determining that the user device has received the message from the service using the reception log associated with the user device; or (iii) determining that the service has received a response from the user device within a certain time frame for sending the message.

24. The system according to claim 13, wherein the message comprises at least one of a Short Message Service (SMS) message, a Multimedia Messaging Service (MMS) message, or an in-app message, and the message is presented at least partially concurrently with the user taking the drug.

Images