Patent Publication Number: US-2022237728-A1

Title: Modeling provisioning of network-based services using statecharts

Description:
RELATED APPLICATION(S) 
     This application claims benefit of priority to Provisional U.S. Patent Application No. 63/142,834, filed Jan. 28, 2021; the aforementioned priority application being hereby incorporated by reference in its entirety. 
    
    
     BACKGROUND 
     A network-based service can enable users to request and receive various services through applications executing on computing devices such as mobile phones, tablets, personal computers, and the like. The network-based service can match a service provider with a requesting user based on the current location of the service provider and a start location specified by the requesting user or determined based on the current location of the requesting user. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The disclosure herein is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings in which like reference numerals refer to similar elements, and in which: 
         FIG. 1A  is a block diagram illustrating an example network system configured to implement statecharts in fulfilling a network service, in accordance with examples described herein; 
         FIG. 1B  is a block diagram illustrating the storage of data relating to statechart objects, in accordance with examples described herein; 
         FIG. 2A to 2C  illustrate example statechart objects associated with a user&#39;s requests for service, in accordance with examples described herein; 
         FIGS. 3A to 3C  illustrate exemplary states and state transitions of statechart objects, in accordance with examples described herein; 
         FIGS. 4A to 4D  are flowchart diagrams illustrating example methods of instantiating and managing statechart objects in response to detected triggers or events, in accordance with examples described herein; 
         FIG. 5  is a block diagram illustrating an example service provider device executing and operating a designated service provider application for communicating with a network service, according to examples described herein; 
         FIG. 6  is a block diagram illustrating an example user device executing and operating a designated user application for communicating with a network system, as described herein; and 
         FIG. 7  is a block diagram illustrating a computer system upon which examples described herein may be implemented. 
     
    
    
     DETAILED DESCRIPTION 
     A network system is provided herein that manages an on-demand network-based service linking available service providers with service requesters throughout a given region (e.g., a metroplex such as the San Francisco Bay Area). In doing so, the network system can receive service requests for on-demand services (e.g., transport service, delivery service, micro-mobility ser) from requesting users (e.g., a rider) via a designated service requester application executing on the users&#39; mobile computing devices. Based on a service location, the network system can identify a number of proximate available service providers (e.g., a driver) and transmit a service invitation to one or more service provider devices of the proximate available service providers to fulfil the service request. In many examples, the service providers can either accept or decline the invitation based on, for example, the service location being impractical for the service provider. 
     In selecting a service provider to fulfill a given service request, the network system can identify a service provider based, at least in part, on a start location indicated in the service request. For example, the network system can determine a geo-fence surrounding the start location (or a geo-fence defined by a radius away from the start location), identify a set of candidate service providers (e.g., twenty or thirty service providers within the geo-fence), and select an optimal service provider (e.g., closest service provider to the service location, service provider with the shortest estimated travel time from the service location, service provider traveling to a location within a specified distance or specified travel time to the destination location, etc.) from the candidate service providers to fulfill the service request. According to examples provided herein, the network system can compile historical data for individual service requesters with regard to the network-based service. Thus, the network system can manage a service requester profile for each service requester indicating routine start and/or end locations (or regions), and/or routine routes (e.g., for a transportation service from home to work and/or vice versa) and preferred service types (e.g., transportation, delivery, mailing, etc.). In some examples, the network system can further synchronize with a service requester device to, for example, identify the service requester&#39;s contacts, the service requester&#39;s schedule and appointments, travel plans (e.g., a scheduled trip), and the like. 
     According to embodiments, the network system is configured to model various aspects of fulfilling users&#39; requests for network-based services (e.g., transport services, delivery services, etc.) using statecharts. A statechart is a hierarchical computational representation of a state machine. In contrast with conventional finite state machines (FSMs), a statechart can have nested or hierarchical states where each state in the statechart can include subordinate states or substates (and those subordinate states can include their own substates). The network system can instantiate a plurality of statechart object types or classes, with each statechart object type being used to model a particular aspect of processing and fulfilling the users&#39; requests. For instance, to model the fulfillment cycle of a user&#39;s request for service, the network system can instantiate a fulfillment order statechart object. To model a point-to-point transport job for transporting the user or for transporting one or more items for delivery to the user, the network system can use a transport job statechart object. An offer statechart object can be used to model an offer or an invitation to a transport service provider to fulfill the request. A waypoint statechart object can be used to model the transport service provider&#39;s progress towards a location (e.g., a start location specified by the user) and/or progress in completing one or more tasks at the location (e.g., picking up the user at the start location). The users and transport service providers can also be modelled using statechart objects. As used herein, a statechart object instantiated by the network system to represent one or more aspects of the network service can be referred to as a statechart. Thus “statechart objects” and “statecharts” may be used interchangeably. 
     In various implementations, as statuses and conditions relating to the fulfillment of the user&#39;s request change and as events relating to the service request occur, the statecharts can be triggered to transition to a different state. These can be referred to herein as statechart state transitions or statechart transitions. A statechart can be triggered to transition states in response to a trigger or a detected event, such as receiving a user or transport service provider input via their respective service applications. The network system can also monitor certain events to trigger the instantiation of one or more statechart objects. As one example, receiving a request for service can trigger the instantiation of a fulfillment order statechart object and that fulfillment order statechart object can be used to model the fulfillment cycle of the received request. The statecharts can also be linked to one another such that a statechart transition of one statechart object can trigger one or more other statechart transitions of other linked statechart objects. In addition, the linking of statechart objects can be dynamic. In other words, links and associations between statechart objects are not predetermined or predefined—statechart objects can be linked at time of instantiation of the statechart objects or after instantiation in response to detected events or triggers or in response to other statechart transitions. In this manner, through the use of dynamically linked hierarchical statecharts, the computational constructs used to model the fulfillment of the users&#39; requests can be scaled up or down as the situations require or demand. The result is a flexible computational architecture that is capable of modelling a vast array of possible situations and statuses without making the basic building blocks of the architecture itself too cumbersome to develop and implement. 
     According to embodiments, data relating to the statechart objects, including their current states, can be written to one or more databases for persistent storage. Such data may need to be written to persistent storage for logging purposes, for system integrity considerations (e.g., to recovery from a server shut down, a power loss, a memory corruption, etc.), and for access by other components of the system that need to retrieve data relating to the statechart objects. To preserve data consistency such that inconsistent data are not written to persistent storage, the network system can include a transaction coordinator to monitor whether each of a set of related statechart transactions (e.g., a set of statechart transactions that are trigger or performed in response to a detected event) is successfully completed before committing such data to persistent storage. If at least one of the set of related statechart transitions is not successfully performed, the transaction coordinator can determine not to commit any data to persistent storage, roll back the other statechart transitions, and cause the network system to perform one or more recovery actions (depending on the particular failure). 
     In contrast to the embodiments described herein, conventional systems use FSMs to represent aspects of a transport service or a delivery service. In these conventional systems, the state transitions of FSMs are predefined or predetermined and adding or modifying aspects of the service being represented by the FSMs quickly add complexities in coding the FSM transitions. In contrast with this conventional approach, embodiments described herein can utilize statechart objects that can be implemented as one or more microservices and are dynamically linked to one another at runtime and/or at time of instantiation. Rather using than static FSM state transition diagrams, dynamically linked statecharts can pass state transition information and other data to one another. A first statechart object can be dynamically linked to a second statechart object at runtime and during the modelling of the transport or delivery service, a transition in the state of the first statechart object can cause or trigger a transition in the state of the second statechart object. In this manner, the framework of modelling the various aspects of the transport or delivery service is made much more flexible and scalable. For example, dependencies between statechart objects can be dynamically updated and determined at runtime without the need to re-program or re-code the FSM state frameworks. 
     Another disadvantage of conventional systems using FSMs to represent aspects of transport or delivery services is the complexity and shortcomings in ensuring data integrity and ACID (atomicity, consistency, isolation, and durability) compliance in storing data relating to services. In particular, state transitions of FSMs can fail for a variety of reasons such as power failure at the data storage level, data inconsistency in the FSMs, etc. In such cases, ensuring data integrity in a complex system modelled by individual FSMs can be a tremendous challenge. In contrast, embodiments described herein provide for dynamically linked statechart objects that each maintain a degree of atomicity. A transaction coordinator can identify, based on the dynamic links between the statechart objects, a set of state transitions of various statechart objects that are to be performed and if any of the set of state transitions fail or return an error, the other state transitions can be immediately rolled back. In this manner, the states of various linked statechart objects are not out of sync. Moreover, the transaction coordinator can ensure that data representing a particular transaction or data representing the processing of a detected event is stored in the databases (e.g., in data tables corresponding to the statechart objects) only if each of the set of state transitions is successfully completed. 
     As used herein, the terms “optimize,” “optimization,” “optimizing,” and the like are not intended to be restricted or limited to processes that achieve the most optimal outcomes. Rather, these terms encompass technological processes (e.g., heuristics, stochastics modelling, machine learning, reinforced learning, Monte Carlo methods, Markov decision processes, etc.) that aim to achieve desirable results. Similarly, terms such as “minimize” and “maximize” are not intended to be restricted or limited to processes or results that achieve the absolute minimum or absolute maximum possible values of a metric, parameter, or variable. 
     As used herein, a computing device refers to devices corresponding to desktop computers, cellular devices or smartphones, personal digital assistants (PDAs), laptop computers, virtual reality (VR) or augmented reality (AR) headsets, tablet devices, television (IP Television), etc., that can provide network connectivity and processing resources for communicating with the system over a network. A computing device can also correspond to custom hardware, in-vehicle devices, or on-board computers, etc. The computing device can also operate a designated application configured to communicate with the network service. 
     One or more examples described herein provide that methods, techniques, and actions performed by a computing device are performed programmatically, or as a computer-implemented method. Programmatically, as used herein, means through the use of code or computer-executable instructions. These instructions can be stored in one or more memory resources of the computing device. A programmatically performed step may or may not be automatic. 
     One or more examples described herein can be implemented using programmatic modules, engines, or components. A programmatic module, engine, or component can include a program, a sub-routine, a portion of a program, or a software component or a hardware component capable of performing one or more stated tasks or functions. As used herein, a module or component can exist on a hardware component independently of other modules or components. Alternatively, a module or component can be a shared element or process of other modules, programs or machines. 
     Some examples described herein can generally require the use of computing devices, including processing and memory resources. For example, one or more examples described herein may be implemented, in whole or in part, on computing devices such as servers, desktop computers, cellular or smartphones, personal digital assistants (e.g., PDAs), laptop computers, VR or AR devices, printers, digital picture frames, network equipment (e.g., routers) and tablet devices. Memory, processing, and network resources may all be used in connection with the establishment, use, or performance of any example described herein (including with the performance of any method or with the implementation of any system). 
     Furthermore, one or more examples described herein may be implemented through the use of instructions that are executable by one or more processors. These instructions may be carried on a computer-readable medium. Machines shown or described with figures below provide examples of processing resources and computer-readable mediums on which instructions for implementing examples disclosed herein can be carried and/or executed. In particular, the numerous machines shown with examples of the invention include processors and various forms of memory for holding data and instructions. Examples of computer-readable mediums include permanent memory storage devices, such as hard drives on personal computers or servers. Other examples of computer storage mediums include portable storage units, such as CD or DVD units, flash memory (such as carried on smartphones, multifunctional devices or tablets), and magnetic memory. Computers, terminals, network enabled devices (e.g., mobile devices, such as cell phones) are all examples of machines and devices that utilize processors, memory, and instructions stored on computer-readable mediums. Additionally, examples may be implemented in the form of computer-programs, or a computer usable carrier medium capable of carrying such a program. 
     System Descriptions 
       FIG. 1A  is a block diagram illustrating an example network system configured to implement statecharts in fulfilling a network service, in accordance with examples described herein. In some implementations, the network system  100  can comprise a plurality of physical computer systems or server systems that may reside at disparate physical locations. The network system  100  can implement and manage the network service which connects requesting users  171  with transport service providers  181  that are available to service the users&#39; requests  176  for service. The network service can provide a platform that facilitates services to be requested and provided between requesting users  171  (“users” or “requesters”) and available transport service providers  181  by way of a user application  172  executing on the user devices  170  and a service provider application  182  executing on the provider devices  180 . As used herein, a user device  170  and a provider device  180  can correspond to a computing device with functionality to execute a designated application (e.g., a user application, a provider application, etc.) associated with the network service managed by the network system  100 . According to embodiments, the user device  170  and the provider device  180  can correspond to mobile computing devices, such as smartphones, tablet computers, VR or AR headsets, on-board computing systems of vehicles, smart watches, and the like. 
     The network system  100  can include a network interface  110  to communicate with user devices  170  and provider devices  180  over one or more networks  190  via the designated applications (e.g., user application  172 , service provider application  182 , etc.) executing on the devices. According to examples, a requesting user  171  wishing to utilize the network service can launch the user application  172  and transmit a request for service (e.g., request  176 ) over network  190  to the network system  100 . In certain implementations, the requesting user  171  can view multiple different services (e.g., transport service, delivery service, etc.) managed by the network system  100 . Within each service, there may be multiple classes or types of service that the user  171  may request. For instance, to request transportation, the user  171  may be able to select from ride-pooling, a basic or economy transport service, a luxury vehicle transport service, a multi-modal transport service, a van or large vehicle service, a professional service provider service (e.g., in which the service providers are certified), a self-driving vehicle service, a rickshaw service, and the like. The network system  100  can utilize the service provider location data  184  to provide the user devices  170  with ETA data of proximate service providers for each respective service. For example, the user application  172  can enable the user  171  to scroll through each service type. In response to a soft selection of a particular service type, the network system  100  can provide ETA data on a user interface of the user application  172  that indicates an ETA for the service type and/or the locations of all proximate available vehicles for that service type. As the user scrolls through each service type, the user interface can update to show visual representations of vehicles for that service type on a map centered around the user  171  or a start location set by the user. The user can interact with the user interface of the user application  172  to select a particular service class, and transmit a request  176 . 
     According to embodiments, the network system  100  can be configured to manage and implement the network service by modeling various aspects of the network service using statecharts. Instantiated statechart objects  153  can be maintained, at the persistent data storage level, in a database  150 . As described herein, different types of statechart objects can be used to model various aspects of fulfilling a user&#39;s request for a transport service or a delivery service. Types or categories of statecharts objects instantiated and used by the network system  100  in managing the network service can include fulfillment order statechart objects  153 A, transport job statechart objects  153 B, offer statechart objects  153 C, transport provider statechart objects  153 D, waypoint statechart objects  153 E, and requester statechart objects  153 F. A fulfillment order statechart object  153 A can be used to model the fulfillment cycle of the user&#39;s request  176  for service and a new fulfillment order statechart object can be instantiated by the network system  100  in response to each user request  176  received over the network  190 . A transport job statechart object  153 B can be used to model a point-to-point transport job for transporting a requesting user or for delivery one or more items. An offer statechart objects  153 C can be used to model an offer or invitation for transport service provider to provided services to fulfill one or more user&#39;s requests  176 . A transport provider statechart object  153 D can model the current status of a transport service provider. A waypoint statechart object  153 E can model the progress of a transport service provider&#39;s progress towards arriving at a waypoint and/or performing one or more actions at the waypoint (e.g., a location on a route of the transport service provider) upon arrival. And a requester statechart object  153 F can be used to model the current status of a user  171 . The network system  100  can instantiate, maintain, and use other types of statecharts that are not illustrated in  FIG. 1A  to manage and provision services for requesting users  171 . For example, entity statechart objects can be used to model the current statuses of entities  191  such as restaurants and stores that provide items (e.g., food items, groceries, etc.) that are requested for delivery for a delivery service. Procurement job statechart objects can model the progress of preparing and/or packaging the requested items. 
     Statecharts objects can be dynamically linked to one another and can be organized in a hierarchical manner. For instance, a fulfillment order statechart object  153 A can be linked with a transport job statechart object  153 B and the transport job statechart object  153 B can, in turn, be linked with an offer statechart object  153 C, a transport provider statechart object  153 D, and a plurality of waypoint statechart objects  153 E. Two statechart objects can be linked at time of instantiation, in response to a state transition of one of the statechart objects, or in response to an detecting a trigger or an event. Moreover, linked statechart objects can pass information relating to their current states to each other. As an example, ETA delay information embodied in a waypoint statechart object can be passed to the transport job statechart object that is linked with the waypoint statechart object. Remedial actions can be taken at the transport job level in response to this information. If remedial actions are unavailable at the transport job level, the ETA delay information can further be passed to the fulfillment order statechart object that is linked to the transport job statechart object and remedial actions can be taken at the fulfillment order level. 
     The network system  100  can include a trigger monitoring module  120  to monitor for triggers and/or events to cause the statechart instantiation and transition engine  130  of the network system  100  to instantiate new statechart objects, transition the states of existing statechart objects in response to detecting the triggers and/or events, and/or dynamically link statechart objects. The monitored triggers and/or events can include user requests  176  for service, other user input  175  (e.g., user input provided during interactions with the user application  172 ), provider input  183  provided by the service provider  181  in interacting with the transport service provider application  182  (e.g., an acceptance of an offer or invitation to fulfill the service request  176 ), and ETA updates  146  determined by an ETA determination component  145 . 
     As an example, the trigger monitoring module  120  can receive the request  176  from the user device requesting a service (e.g., a request for a transport service, a request for a multi-modal transport service, or a request for a delivery service, etc.). In response, the trigger monitoring can generate a trigger signal  121  to cause the statechart instantiation and transition engine  130  to instantiate a new statechart object (e.g., fulfillment order statechart object  153 A) to model the fulfillment cycle of the request  176  submitted by the user  171 . The trigger monitoring module  120  can further monitor user inputs  175  received from the user device  170 . As one example, the statechart instantiation and transition engine  130  can trigger the fulfillment order statechart object  153 A to transition to a different state (e.g., to the cancelled state) in response to a user input  175  indicating a cancellation of the request  176 . Furthermore, the trigger monitoring module  120  can monitor provider inputs  183  received from the provider device  180  to generate the trigger signal  121 . For instance, in response to receiving a provider input  183  indicating an acceptance of an offer or invitation  141  to fulfill a request  176 , the trigger monitoring module  120  can generate trigger signal to cause the statechart instantiation and transition engine to transition the offer statechart object associated with the invitation  141  to an accepted state and link the transport provider statechart object of the transport service provider to the transport job statechart object associated with the invitation  141 . 
     According to embodiments, the network system  100  further includes provider matching  140  to match users with transport service providers. At a high level, available transport service providers  181  can be matched with requesting users  171  based on their respective locations. The matching can be performed based on one or more multi-variate optimizations to, for example, minimize the wait times for users, minimize the distance travelled by transport service providers to rendezvous with users, etc. In some implementations, the provider matching  140  can determine optimal user-to-provider pairings based on a group optimization of computed matching parameters. In this manner, provider matching can perform group matching to optimize one or more matching parameters across a group of requesting users and a group of transport service providers. In one implementation, the provider matching  140  can resolve a bipartite graph to select the optimal user-to-provider pairings. 
     To perform user to provider matching, the statechart instantiation and transition engine  130  can relay information regarding open transport jobs  131  (e.g., transport job statechart objects having particular certain state(s), such as a Processing:Open state (see  FIG. 3B )) to the provider matching  140 . The provider matching  140  can match the open transport jobs  131  with available or soon-to-be available transport service providers  181 . In response to a transport service provider  181  being matched to fulfill a request  176 , an invitation  141  can be transmitted to the provider device  180  of the transport service provider  181 . The invitation  141  can cause the provider device  180  to present a user interface for the transport service provider  181  to accept or decline the invitation  141 . Furthermore, the provider matching  140  can provide an indication of a match (matched signal  142 ) to the statechart instantiation and transition engine  130  to cause the statechart instantiation and transition engine  130  to instantiate a new offer statechart object  153 C to model the invitation  141 . If a matched transport service provider  181  accepts the invitation  141  (e.g., via a received provider input  183 ), the statechart instantiation and transition engine  130  can transition the associated offer statechart object to an appropriate state. Furthermore, in response to the acceptance, the statechart instantiation and transition engine  130  can further link the transport provider statechart object  153 D that corresponds to that transport service provider to a transport job statechart object  153 B (e.g., the transport job statechart object  153 B that is linked to the offer statechart object  153 C of the invitation  126 ). If the matched transport service provider  181  declines the invitation  141 , the statechart instantiation and transition engine  130  can transition the offer statechart object to a different state and cause the provider matching  140  to re-perform matching. 
     The network system  100  can further include transition and recovery action executor  125  to perform various functions in response to state transitions of statechart objects (e.g., by retrieving one or more recovery action instructions  154  from database  150 ). According to embodiments, the network system  100  can further include a transaction coordinator  135  to write transaction data to the database  150  once a set of statechart transitions are successfully completed. 
       FIG. 1B  is a block diagram illustrating the storage of data relating to statechart objects, in accordance with examples described herein. Referring back to  FIG. 1A , the elements illustrated in  FIG. 1B  can be implemented by the network system  100  of  FIG. 1 . For instance, transaction coordinator  1035  of  FIG. 1B  can correspond to the transaction coordinator  1035  of  FIG. 1A . Furthermore, databases  1040  and  1050  of  FIG. 1B  can collectively implement the database  150  of  FIG. 1A . The databases  1050 - 1  and  1050 - 2  can be physically separate and maintained by separate servers  1055 - 1  and  1055 - 2 , respectively. To process and fulfill requests for service received from user devices over a network, the network system can instantiate and implement a plurality of statechart objects. The plurality of statechart objects can be of various classes or types, each used for modelling a corresponding aspect of fulfilling the user&#39;s requests. As discussed herein, fulfillment order statechart objects, transport job statechart objects, waypoint statechart objects, and other classes of statechart objects can be instantiated and maintained by the network system. 
     The network system can monitor one or more events (e.g., timer expiry, location data of user device and/or provider device, ETA determination, user or provider input, user request, context data, sensor data, etc.) to trigger a first state transition of a first statechart. In response to triggering the first state transition, a statechart transition engine (e.g., statechart instantiation and transition engine  130  of  FIG. 1A ) can retrieve a set of state transitions that are to be triggered in response to the first statechart transition. This can be performed based on the statechart class or type of the first statechart, the state transition of the first state transition (e.g., the beginning and ending states), and the statechart class or type of the linked statechart. The statechart transition engine can, for example, look up a predefined set of state transition rules that can dictate what related statechart transitions are to be triggered by the first state transition. This can be performed for each state transition such that the network system can dynamically determine a set of related state transitions to be triggered in response to the detected event. In addition, information pertaining to the set of related state transitions and the outcomes of each of the state transitions of the set of related state transitions can be passed to the transaction coordinator  1035  (or database write coordinator). The transaction coordinator  1035  can determine whether to write to the database(s) based on whether each of the set of related transactions is successfully completed. For instance, in response to determining that all of the state transitions of the set of related state transitions are successfully completed, the transaction coordinator  1035  can commit data relating to the state transitions to the database(s) (e.g., database  1050 - 1  and database  1050 - 2 ). In contrast, in response to determining that one state transition of the set of related state transitions failed, the transaction coordinator  1035  does not write any data relating to the set of related state transitions to the database and can instead cause set of related transitions to be rolled back to avoid inconsistent data being recorded the data tables. By ensuring that all related statechart transitions are successfully completed before committing data writes to the databases  1050 - 1  and  1050 - 2 , the transaction coordinator  1035  can improve the integrity of the data stored in the databases  1050 - 1  and  1050 - 2 . The chances of conflicting data being stored on the databases  1050 - 1  and  1050 - 2  can be significantly reduced in comparison to existing systems and solutions. 
     In the figure illustrated in  FIG. 1B , four statechart objects of three classes or types of statecharts are illustrated: statechart A  1010  of Class I, statechart B  1015  of Class II, and statechart C  1020  and statechart D of Class III. As one example, statechart A  1010  can be an instantiated fulfillment order statechart object, statechart B  1015  can be an instantiated transport job statechart object, and statechart C  1020  and statechart D  1025  can be waypoint statechart objects. The statechart objects illustrated in  FIG. 1B  can be dynamically linked such that a state transition of one statechart object can trigger one or more linked statechart objects to transition states. For instance, as illustrated in  FIG. 2A , a fulfillment order statechart object (e.g., statechart A  1010  of  FIG. 1B ) can be dynamically linked to a transport job statechart object (e.g., statechart B  1015  of  FIG. 1B ), and the transport job statechart object can in turn be dynamically linked to two waypoint statechart objects (e.g., statechart C  1020  and statechart D  1025  of  FIG. 1B ). 
     The network system can monitor one or more events (Statechart A Monitored Event) to trigger a state transition of statechart A  1010  (statechart transition  1  or ST 1 ). The statechart transition engine determine one or more statechart transitions that are to be performed in response to ST 1  (ST 1  related STs). To do so, the statechart transition engine can perform a lookup of the dynamic links of statechart A  1010  and determine which of the statecharts linked to statechart A  1010  should be triggered to transition states (as well as to which states those statecharts should be transitioned). As an example, whether to transition statechart B  1015  and/or to which state statechart B  1015  should be transitioned in response to ST 1  can be determined based on one or more of: (i) statechart class or type of statechart A  1010 , (ii) statechart class or type of statechart B  1015 , (iii) statechart transition of ST 1  (e.g., beginning state, ending state, etc.), (vi) current state of statechart B  1015 , or (v) current state of one or more statecharts linked to statechart A  1010  and/or statechart B  1015 . The network system can maintain, for example, a set of statechart transition rules for this purpose (e.g., statechart transition rules  152  of  FIG. 1A ). 
     The statechart transition engine can pass information pertaining to statechart transitions that are triggered by or related to ST 1  (ST 1  Related STs) to the transaction coordinator  1035 . In this manner, the transaction coordinator  1035  can monitor whether statechart transitions that are triggered by ST 1  are successfully completed. The statechart transition engine can also pass information relating to whether ST 1  was successfully completed (ST 1  Outcome) to the transaction coordinator  1035 . In the example illustrated in  FIG. 1B , ST 1  can trigger statechart transition  2  (ST 2 ) of statechart B  1015 . ST 2  can trigger two statechart transitions, statechart transition  3  (ST 3 ) of statechart C  1020  and statechart transition  4  (ST 4 ) of statechart D. The statechart transition engine can also pass information pertaining to the statechart transitions that are triggered by ST 2  (ST 2  Related STs) to the transaction coordinator  1035 . In addition, the statechart transition engine can transmit to the transaction coordinator  1035  information relating to whether ST 2  was successfully completed (ST 2  Outcome). Furthermore, the statechart transition engine can transit to the transaction coordinator  1035  whether ST 3  was successfully completed (ST 3  Outcome) and whether ST 4  was successfully completed (ST 4  Outcome). 
     As illustrated in  FIG. 1B , through the use of dynamically linked statechart objects, Statechart A Monitored Event triggered statechart transitions ST 1 , ST 2 , ST 3 , and ST 4 . Accordingly, ST 1  through ST 4  can be considered a set of related statechart transitions that corresponds to Statechart A Monitored Event. The transaction coordinator  1035  can monitor the outcomes of the set of related statechart transitions (ST 1  Outcome to ST 4  Outcome) to determine whether each of the set of related statechart transitions was successfully completed. If ST 1  through ST 4  were each successfully completed, the transaction coordinator can write the resulting states of the statechart objects A through C to the databases  1050 - 1  and  1050 - 2 . 
     According to embodiments, a plurality of data tables can be used to as persistent storage of statechart information. Each data table can be used to store instantiated statechart objects of a corresponding class or type. As illustrated in  FIG. 1B , data table  1041  can store data corresponding to the instantiated statechart objects of Statechart Class I, data table  1042  can store data corresponding to the instantiated statechart objects of Statechart Class II, and data table  1043  can store data corresponding to the instantiated statechart objects of Statechart Class III. As an example, data table  1041  can store the instantiated fulfillment order statechart objects (Statechart Class or Type I) maintained by the network system across all service regions. As an alternative, data table  1041  can store the instantiated fulfillment order statechart objects corresponding to a particular service region (e.g., a region in which requests for services are received and fulfilled, such as the San Francisco Bay Area). Similarly, data table  1042  can store the transport job statechart objects (Statechart Class or Type II) maintained by the network system and data table  1043  can store the waypoint statechart objects (Statechart Class or Type III) maintained by the network system. 
     In various implementations, each statechart object can be represented by one row in the data table. For instance, Statechart A  1010  can be represented by a row of data (e.g., data entry  1041 A) within data table  1041 . Similarly, Statechart B  1015  can be represented by a row of data (e.g., data entry  1042 B) within data table  1042 , Statechart C  1020  can be represented by a first row of data (e.g., data entry  1043 C) within data table  1043 , and Statechart D  1025  can be represented by a second row of data (e.g., data entry  1043 D) within data table  1043 . Each data entry can include, for example, a unique identifier of the statechart object, the current state of the statechart object, identifiers of other statecharts that are dynamically linked to the statechart object, a timestamp (e.g., corresponding to when the last set of data was written to the data entry), and the like. 
     According to embodiments, transaction coordinator  1035  can monitor whether each of the set of related statechart transitions triggered by the Statechart A Monitored Event (ST 1 , ST 2 , ST 3 , and ST 4 ) are successfully completed. In response to determining that each of the set of related statechart transitions are successfully completed, the transaction coordinator  1035  can write data to the databases  1050 - 1  and  1050 - 2  to update the entries within each data table that correspond to the statechart objects. For instance, data is written to entry  1041 A within data table  1041  to reflect the updated state of statechart A  1010  and data is written to entry  1042 B to reflect ST 2  of statechart B  1015 . Similarly, data entries  1043 C and  1043 D are updated. 
     In the manner described herein, the likelihood of inconsistent statechart information data (e.g., data indicating only a subset of the related statechart transitions being completed) being maintained across the data tables  1041  through  1043  is significantly reduced. And when state information of the statecharts A through D are retrieved by querying the databases  1050 - 1  and  1050 - 2 , data that is internally consistent can be retrieved. Statecharts objects related to past service requests can also be maintained in the same data tables for logging purposes. For instance, statechart B can correspond to a transport job statechart object. Once the transport job is completed, statechart B can be persistently maintained within data table  1042  (e.g., while having a Transport Job Completed state). 
     Statechart Objects 
       FIGS. 2A through 2C  illustrate example statechart objects associated with a user&#39;s request for a service, in accordance with examples described herein. The exemplary statechart objects illustrated in  FIGS. 2A through 2C  can be used to model various aspects of the processes performed by a network system (e.g., network system  100  of  FIG. 1A ) to fulfill the services (e.g., a transport service, a multi-modal transport service, a delivery service, etc.) requested by the user. For instance, the entities involved in the fulfillment of the requested services (e.g., a transport service provider for a transport request, a restaurant or store and a courier for a delivery service, etc.) and the information associated with these entities can be modelled using statecharts. Similarly, fulfillment cycle of the user&#39;s request can be modelled as fulfillment order statechart objects. The statechart objects illustrated in  FIG. 2A  can be dynamically linked and unlinked as needed to model and/or represent information needed to fulfill the user&#39;s request. 
     In  FIG. 2A , block diagram  2000  illustrates a set of statechart objects for modelling various aspects of fulfilling a user&#39;s request for a transport service. In particular, to fulfill the request for the transport service, the network system can instantiate and/or manage fulfillment order statechart object  2010 , transport job statechart object  2020 , offer or invitation statechart object  2030 , provider statechart object  2040 , a first waypoint (WP 1 ) statechart object  2050 , a second waypoint (WP 2 ) statechart object  2060 , and a requester statechart object  2070 . 
     The statechart objects shown in  FIG. 2A  can be associated with one another via dynamic links. The block diagram illustrates the relationships and dynamic links between the statechart objects. For instance, the fulfillment order statechart object  2010  can be dynamically linked to the transport job statechart object  2020 . The transport job statechart object  2020  in turn can be dynamically linked to each of the offer statechart object  2030 , the transport provider statechart object  2040 , the first waypoint (WP 1 ) statechart object  2050 , and the second waypoint (WP 2 ) statechart object  2060 . The dynamic links between the statechart objects can be created (or removed) at the time of instantiation of a statechart object, in response to a trigger event, or in response to a statechart state transition, as described herein. By dynamically linking one statechart object with another, state transition and other information can be passed between the linked statechart objects. For instance, a first statechart object can be caused to transition to a different state in response to a state transition of a second statechart object that is dynamically linked to the first statechart object. Furthermore, information pertaining to the dynamic links of each statechart object can be maintained in the manner described in, for example,  FIG. 1B . As described in  FIG. 1B , data pertaining to an instantiated dynamic statechart object can be maintained as a data entry (e.g., a row of data) within a data table for storing instances of statechart objects of the same statechart type. And the dynamic links of a statechart object can be stored along with other statechart information in the data entry. 
     Fulfillment order statechart object  2010  can be instantiated by the network system  100  in response to receiving a request for service received from a user device over a network. The fulfillment order statechart object  2010  can be used to model the fulfillment cycle of the user&#39;s request and each request being serviced by the network system can be modeled using a unique fulfillment order statechart object. Like any statechart object, the fulfillment order statechart object  2010  can be transitioned to one of a plurality of states (e.g., fulfillment order states) depending on the current state of the fulfillment cycle. Additional details regarding the states and transitions of states of fulfillment order statechart object  2010  is illustrated in and described with respect to  FIG. 3A . The fulfillment order statechart object  2010  can include information such as state information (FO state  2011 ) of the fulfillment order statechart object  2010 , information pertaining to the user&#39;s request associated with the fulfillment order (FO request information  2012 ), transaction data needed to process the financial transaction(s) that will be performed as a result of the fulfillment of the user&#39;s request (FO transaction data  2014 ), and a set of instructions for performing recovery actions (FO recovery actions  2015 ) in the event of a failure of a state transition or a transport job associated with the fulfillment order statechart object  2010  (e.g., transport job statechart object  2020 ) reaching a critical state. State information of a statechart object, such as FO state  2011 , can include information regarding current state(s) (e.g., current hierarchical states), permissible state transitions, impermissible state transitions (transition guards), etc. Examples of states and state transitions of the fulfillment order statechart object  2010  are illustrated in and described with respect to  FIG. 3A . The fulfillment order statechart object  2010  can be linked with a requester statechart object  2070  that models the state and status of the requesting user (e.g., using requester state  2071 ). 
     According to embodiments, the FO request information  2012  can include detailed information regarding the users request, including the type of service requested. The creation and linking of subordinate or dependent statechart objects can be performed based on the FO request information  2012 . For instance, in the block diagram  2000  illustrated in  FIG. 2A , the request received from the user device can be a request for point-to-point transport service (e.g., a rideshare service). As a result, a single transport job statechart object  2020  can be instantiated and linked to fulfillment order statechart object  2010  in response to the fulfillment order state chart object  2010  being instantiated. In other cases, the received request can be for a delivery service or for multi modal transport service. In such cases, the fulfillment order statechart object can be dynamically linked to other and/or additional statechart object. 
     The fulfillment order statechart object  2010  can be linked to the transport job statechart object  2020 , which can be instantiated by the network system in response to the fulfillment order statechart object  2010  being instantiated. The transport job statechart object  2020  can be used to model and represent a point-to-point transport job associated with the request that is associated with the fulfillment order statechart object  2010  (e.g., to transport the requesting user via the point-to-point transport service requested). The transport job statechart object  2020  can include information such as the state information (TJ state  2021 ) of the transport job statechart object  2020 , the route plan of the transport job (TJ route plan  2022 ), and a set of instructions to perform route delay recovery actions (TJ route delay recovery actions  2023 ). Examples of states and state transitions of the transfer job statechart object  2020  are illustrated in and described with respect to  FIG. 3B . 
     The transport job statechart object  2020  can in turn be linked to the offer statechart object  2030 , which can be dependent or subordinate to the transport job statechart object  2020 . The offer statechart object  2030  can be used to model an offer or invitation to a transport service provider that has been identified to provide the requested service for the requesting user. The offer statechart object  2030  can include information such as state information (O state  2031 ) of the offer statechart object  2030 , a set of parameters related to the offer (O offer parameters  2032 ), and expiration time associated with the offer (O offer expiry  2033 ). As an example, the network system can perform a matching process to identify a transport service provider from a plurality of available transport service providers to fulfill the request received from the requesting user device. The transport service provider can be identified based at least in part on the provider&#39;s current location (or ETA) relative to the requesting user&#39;s location. In response to identifying the transport service provider, the offer or invitation statechart object  2030  can be instantiated. As illustrated, the offer statechart object  2030  can also be linked to the transport provider statechart object  2040 . The parameters determined during the matching process (e.g., value of payment that can be expected by the matched transport service provider for fulfilling the service request) can be stored as offer parameters  2032 . Moreover, in response to identifying the transport service provider and/or in response to instantiating the offer or invitation statechart object  2030 , a set of data corresponding to an invitation to provide service to fulfill the request can be transmitted to a provider device of the identified service provider. The set of data corresponding to the invitation can cause the provider device to display information relating to the invitation to provide services to fulfill the request (e.g., the expected value, requested service type, pick-up location, destination location, etc.). The provider device can also present one or more user interface features on the provider application executing on the provider device to allow the identified service provider to accept or decline the invitation. The offer may also have an expiration such that if the identified service provider does not respond or accept the invitation prior to the expiration, the offer or invitation can be invalidated or cancelled. The information relating to the offer expiration can be stored as O offer expiry  2033 . 
     Once the identified service provider accepts the invitation, the transport provider statechart object  2040  can be dynamically associated with the transport job statechart object  2020 . For instance, the transport provider statechart object  2040  can be dynamically linked to the transport job statechart object  2020  in response to the network system receiving an acceptance message from the provider device of the service provider. The provider statechart object  2040  can be used by the network system to model the status, state, and information relating to a transport service provider in providing transport services and/or delivery/courier services. Each transport provider statechart object maintained by the network system can be associated with a corresponding one of a plurality of transport service providers. As the transport service providers go online and offline (e.g., via the provider application executing on their respective provider devices), accept invitations, arrive at waypoints, and complete tasks, the network system can transition the states of the provider statechart objects to model the transport service provider actions and their statuses. The transport provider statechart object  2040  can include state information (P state  2041 ) of the provider statechart object  2040 , current location or location coordinates (P location data  2042 ) of the transport service provider, and identification of transport jobs statechart objects (P associated TJs  2043 ) associated with the provider statechart object. As described herein, a provider statechart object can be simultaneously linked to or associated with a plurality of transport job statechart objects, each of which is associated with a different fulfillment order statechart object. In this manner, a transport service provider can be simultaneously associated with a plurality of transport jobs (e.g., when the transport service provider provides a rideshare transport service simultaneously for multiple users, when the transport service provider is provisionally associated with a second requesting user while being en-route to drop off a first requesting user, etc.). 
     According to embodiments, the transport job statechart object  2020  is associated with or dynamically linked with a plurality of waypoint statechart objects (e.g., WP 1  statechart object  2050  and WP 2  statechart object  2060 ). A waypoint can be a location on the route plans (e.g., TJ route plan  2022 ) of the transport job statechart objects. And according to embodiments, a waypoint statechart object can be used to model or track a transport service provider&#39;s progress in arriving at that location and/or in completing one or more tasks the transport service provider is to complete (e.g., pick-up or drop off requesting user, pick up or drop off item(s) to be delivered, etc.). Each of the waypoint statechart objects  2050  and  2060  can include state information (WP 1  state  2051  and WP 2  state  2061 ), location information (WP 1  location data  2052  and WP 2  location data  2062 ) such as the location coordinates of the corresponding waypoints, actions that the transport service provider is to perform at the waypoints (WP 1  actions  2053  and WP 2  actions  2054 ), and timing and estimated time of arrival information (WP 1  timing &amp; ETA  2054  and WP 2  timing &amp; ETA  2064 ). As illustrated in  FIG. 2A , WP 1  waypoint statechart object  2050  can model the transport service provider&#39;s progress towards the pick-up location and WP 2  waypoint statechart object  2060  can model the transport service provider&#39;s progress towards the drop-off location. WP 1  actions  2053  can indicate that the transport service provider is to pick up the requesting user at the location indicated by WP 1  location data  2052 . Similarly, WP 2  actions  2063  can indicate that the transport service provider is to drop off the requesting user at the location indicated by WP 2  location data  2062 . Examples of states and state transitions of the waypoint statechart object  2050  or  2060  are illustrated in and described with respect to  FIG. 3C . 
     In various implementations, the two statechart objects  2050  and  2060  can also be linked to the transport provider statechart object  2040 . For instance, the transport provider statechart object  2040  can be linked to the two waypoint statechart objects  2050  and  2060  in response to the transport provider accepting the offer. The service provider application executing on the transport provider device can access the waypoint information in displaying a navigation route for the transport provider. By linking the transport provider statechart object  2040  with the waypoint statechart objects, an update of either of the waypoints (e.g., via a requester input) processed at the transport job or fulfillment order level can be quickly propagated to the transport provider. 
     In  FIG. 2B , block diagram  2100  illustrates a set of statechart objects for modelling various aspects of fulfilling a user&#39;s request for a delivery service. As illustrated in  FIG. 2B , to fulfill a user&#39;s request for a delivery service, the network system can instantiate and/or manage fulfillment order statechart object  2110 , transport job statechart object  2120 , offer statechart object  2130 , provider statechart object  2140 , a first waypoint (WP 1 ) statechart object  2150 , and a second waypoint (WP 2 ) statechart object  2160 . The statechart objects  2110  through  2160  can be similar to those described with respect to  FIG. 2A  (e.g., statechart objects  2010  through  2060 ). The transport job statechart object  2120  can be used for modeling transporting or more items for delivery rather than the transportation for the request user. Accordingly, WP 1   2150  can model, among other aspects, the progress of the transport provider in picking up one or more delivery items rather than the progress of the transport provider in picking up the requesting user (as does WP 1   2050  of  FIG. 2A ). Similarly, WP 2   2160  can model the progress of the service provider in delivering one or more items for delivery rather than the progress of the transport provider in dropping off the requesting user (as does WP 2   2060  of  FIG. 2A ). In addition to these statechart objects, a procurement job statechart object  2180  and a procurement entity statechart object  2190  can also be instantiated. The procurement job statechart object  2180  in particular can be linked to the fulfillment order statechart object  2110  and the procurement entity statechart object  2190  can be linked to the procurement job statechart object  2180 . The procurement job statechart object  2180  can be used to model the progress of the preparation of one or more items (e.g., one or more food items) requested by the user and the procurement entity statechart object  2190  can be used to model the entity (e.g., restaurant, bar, store, merchant, etc.) that is to provide the one or more requested items. 
     In  FIG. 2C , block diagram  2200  illustrates a set of statechart objects for modelling various aspects of fulfilling a user&#39;s request for a multi-modal transport service. A multi-modal transport service can involve multiple segments, at least some of the multiple segments can be provided using different transport service types. For instance, a multi-modal transport service can include a first segment that is provided by a first transport service provider, a second segment that is taken on a public transit (e.g., bus or train), and a third segment that is provided by a second transport service provider. The first and third segments can be provided as the same transport service type (e.g., a rideshare transport type) or provided using different transport service types. As another example, the first segment can be provided as a rideshare transport, the second segment can be taken on a public transit, and the third segment can be fulfilled as a micro-mobility service (e.g., a bicycle or scooter rental service). 
     As illustrated in  FIG. 2C , to fulfill a user&#39;s request for a multi-modal transport service, the network system can instantiate a fulfillment order (FO) statechart object  2210 . As described with other examples, the fulfillment order statechart object  2210  can be linked with a requester statechart object  2290  that models the state and status of the requesting user. Additionally, the fulfillment order statechart object  2210  can be dynamically linked to a plurality of transport job statechart objects (e.g., transport job (TJ 1 ) statechart object  2215 , transport statechart (TJ 2 ) object  2240 , and transport statechart (TJ 3 ) object  2245 ). As described with other examples, the transport job statechart object  2215  in turn can be dynamically linked to each of the offer statechart object (O 1 )  2220  and the transport provider statechart object (P 1 )  2225 . Likewise, in an example shown, the transport job statechart object (TJ 3 )  2245  can be dynamically linked to each of the offer statechart object (O 2 )  2250  and the transport provider statechart object (P 1 )  2255 . 
     In examples, each of the transport statechart objects associated with or linked to the fulfillment order statechart object  2210  can model a corresponding one of the multiple segments of the multi-modal transport service being provided for the requesting user. For instance, TJ 1  statechart object  2215  can model the first segment of the multi-modal transport service (e.g., a first transport service provider transporting the requesting user to a public transit origination location), TJ 2  statechart object  2240  can model the second segment (e.g., the public or mass transit taken by the requesting user from the public transit origination location to a public transit destination location), and TJ 3  statechart object  2245  can model the third segment (e.g., a second transport service provider transporting the requesting user from the public transit destination location to a drop off location). In certain implementations, one or more waypoint statechart objects  2230 ,  2235 ,  2260 ,  2270  can be used in modeling the public transit segment of the multi-modal transport service. For instance, a waypoint statechart object can be used to model the user&#39;s progress towards a transit on/off-boarding location (e.g., a train station). 
     Statechart State Transitions 
       FIGS. 3A to 3C  illustrate exemplary states and state transitions of statechart objects, in accordance with examples described herein.  FIG. 3A  illustrates exemplary states and state transitions of a fulfillment order statechart object. As illustrated in  FIG. 3A , a fulfillment order statechart object can be in one of a plurality of states, including a Create state  3010 , an Active state  3015 , a Cancelled state  3020 , a Completed state  3030 , and a Failed state  3025 . The Active state  3015  can be a compound state having two sub-states including an On-Track sub-state  3015 -A and an Off-Track state  3015 -B. Because other statechart object types can have state names that are similar, for clarity, the Created state  3010  can be referred to herein as the Fulfillment Order Created state, the Completed State  3030  can be referred to herein as the Fulfillment Order Completed state, and the like. 
     The fulfillment statechart object can be instantiated in the Created state in response to the network system receiving a request for service from a requesting user device. From the Created state  3010 , the fulfillment order statechart object can transition to the Active state  3015 . In many cases, the fulfillment statechart object can automatically transition to the Active state  3015  when the network system begins the process to fulfill the request associated with the fulfillment order statechart object. In some other cases, the Active state can be transitioned into depending on the parameters and details of the request. For instance, if the request for service is a scheduled request for service at a future time (e.g., a transport request for a future pick-up time, a scheduled delivery request, etc.), the network system can determine a time at which the fulfillment statechart object should transition into the active state to begin the fulfillment process of the scheduled request. The fulfillment statechart object can remain in the Created state  3010  and transition into the Active state  3015  at the determined time (e.g., upon expiry of a timer associated with the state transition). 
     In certain implementations, the fulfillment order statechart object can also be instantiated in the Created state  3010  in response to receiving context information from the user device indicating that user is likely to submit a request for service in the near future. The context information can include data indicating user interactions with the user service application, location and other sensor data collected by the user device, and the like. Thus, the fulfillment order statechart object can be instantiated prior to the user submitting a request for service via the user service application. In such cases, the fulfillment order statechart object can transition to the Active state  3015  in response to receiving the request from the user device. 
     According to embodiments, the Active state  3015  of the fulfillment order statechart object can be used to model the active fulfillment of a request from the user. The Active state  3015  can be a compound state that includes two sub-states, including an On-Track state  3015 -A and an Off-Track state  3015 -B. The statechart object can be in the On-Track state  3015 -A when the fulfillment cycle is on-track to be completed and in the Off-Track state  3015 -B when one or more issues are detected (e.g., detected delays of the transport service provider in arriving at one or more waypoints, etc.) during the fulfillment process that needs to be resolved at the fulfillment order level (e.g., creation of a new transport job etc.). As illustrated in  FIG. 3A , in certain implementations, the fulfillment order statechart object transitioning to the Active state  3015  can cause the instantiation of a linked transport job statechart object. As an alternative, the linked transport job statechart object can be instantiated when the fulfillment order statechart is first instantiated (e.g., in the Created state  3010 ). For requests for service types other than a point-to-point transport service, such as requests for a delivery service, or requests for a multi-modal transport service, and the like, the fulfillment order statechart object transitioning to the Active state  3015  (or being instantiated) can cause other statechart objects to be instantiated. For instance, for a request for a delivery service, the fulfillment order statechart object transitioning to the Active state  3015  can cause a procurement job statechart object, in addition to the transport job statechart, to be instantiated and linked to the fulfillment order statechart object. For a request for a multi-modal transport service, multiple transport jobs can be instantiated and linked to the fulfillment order statechart object. 
     The fulfillment order statechart object can transition to a Cancelled state  3020  from either the Created state  3010  or the Active state  3015  in response to a user input to cancel the submitted request. The state transition from the Active state  3015  to the Cancelled state  3020  can cause one or more other statechart objects to be transitioned to their respective cancelled states. For instance, a transport job statechart object and/or a procurement job statechart object can be transitioned to their respective cancelled states in response to the fulfillment order statechart object transitioning from the Active state  3015  to the Cancelled state  3020 . 
     The fulfillment order statechart object can transition to a Completed state  3030  upon the completion of the fulfillment of requested services. The fulfillment order statechart object can transition to the Completed State  3030  from the Active state  3015 . The fulfillment order statechart object can transition to the Completed state  3030  in response to all of the transport job statechart objects and procurement job statechart objects linked to the fulfillment order statechart object transitioning to their respective completion states. Furthermore, the fulfillment order statechart object can transition to the Failed state  3025  from the Active state  3015  in response to an unrecoverable error being encountered during the fulfillment cycle of the user&#39;s request. 
       FIG. 3B  illustrates exemplary states and state transitions of a transport job statechart object. A transport job statechart object can be in one of a plurality of states, including (i) Processing state  3101 , (ii) Transporting or In-Progress state  3102 , (iii) Completed state  3103 , (iv) Failed or Cancelled state  3104 , and (v) an Expire or Unfulfilled state  3105 . The transport job statechart object can be instantiated in response to a fulfillment order statechart object being transitioned to the Fulfillment Order Active state. Upon being instantiated, the transport job statechart object can be in the Processing state  3101 . The Processing state  3101  can be used to model the transport job before the transport service provider picks up the requesting user and can be a composite state having a plurality of substates including: (i) an Open sub-state  3101 -A for representing the transport job not yet been assigned to a particular transport service provider, (ii) a Linking sub-state  3101 -B for representing a transport service provider in the process of being associated with or assigned to the transport job, and (iii) an Assigned sub-state  3101 -C. In particular, the Assigned sub-state  3101 -C can be entered into in response to an identified transport service provider accepting an offer or invitation to fulfill the request of the requesting user. 
     From the Assigned sub-state  3101 -C of the Processing state  3101 , the transport job statechart object can transition to the Transporting or In-Progress state  3102 . This state can represent portion of the transport job in which the transport service provider is actively providing transport service for the requesting user. In particular, the transport job statechart object can enter into the In-Progress state  3102  from the Assigned sub-state  3101 -C in response to a waypoint statechart object that corresponds to the start location transitioning to the Waypoint Complete state. From the In-Progress state  3102 , the transport job statechart object can transition to the Complete state  3103  or the Failed/Cancelled state  3104 . 
       FIG. 3C  illustrates exemplary states and state transitions of a waypoint statechart object. A waypoint job statechart object can be in one of a plurality of states, including (i) Waypoint Created state  3201 , (ii) Waypoint Pending state  3202 , (iii) Waypoint Waiting state  3203 , (iv) Waypoint Completed state  3204 , (v) Waypoint Failed state  3205 , and (vi) Waypoint Removed state  3206 . The Waypoint Pending state  3202  can model the progress of a transport provider in traveling to the waypoint while the Waypoint Waiting state  3203  can model the progress of the service provider in completing one or more tasks (e.g., drop off the requesting user, picking up the requesting user, picking up one or more delivery items, dropping off one or more delivery items, etc.). The Waypoint Pending state  3202  can be a compound state having a plurality of sub-states used for more detailed monitoring of the progress of the service provider in traveling to the waypoint. For instance, an On-Time substate  3202 -A of the Waypoint Pending state  3202  can signify that the service provider is currently on-track to arrive at the waypoint within a threshold of the estimated time of arrival computed for the service provider. The Delayed sub-state  3202 -B of the Waypoint Pending state  3202  can represent the service provider being delayed and the Critical  3202 -C sub-state can signify that the service provider is critically delayed. In response to transitioning to the Critical  3202 -C sub-state, the network system can trigger the performance of one or more recovery actions to prevent the failure of the transport job. Similarly, the Waypoint Waiting state  3203  can also be a compound state having a plurality of sub-states, including: On-Time  3203 -A, Delayed  3203 -B, and Critical  3203 -C. 
     Methodology 
       FIGS. 4A to 4D  are flowchart diagrams illustrating example methods of instantiating and managing statechart objects in response to detected triggers or events, in accordance with examples described herein. The methods illustrated in  FIGS. 4A to 4C  can be performed by the network system  100  illustrated in and described with respect to  FIGS. 1A and 1B . 
       FIG. 4A  is a flowchart diagram illustrating an example method of monitoring for events and trigger statechart transitions. While  FIG. 4A  illustrates a generic example of processing a detected event, specific examples of processing specific events and triggers are illustrated in  FIGS. 4B to 4D . At step  4001 , the network system can monitor events and inputs. The monitored events and inputs can include, for example, requests for service received from user devices, acceptance of offers or invitations received from provider devices, other input via user or provider service applications, location data, ETA updates, context data, device sensor data, etc. 
     At step  4002 , the network system can receive the event trigger. As part of processing the detected event, the network system can perform a number of statechart transitions (e.g., a set of related statechart transitions) in response to receiving the event trigger. As illustrated in  FIG. 1A , the set of related statechart transitions can include four statechart transitions (steps  4003  through  4006 ) of four statechart objects. The detected event can be a statechart transition or instantiation trigger for a first statechart object which can a first statechart transition at step  4003 . The detected event can also be a trigger for a second statechart object which transitions to a new state at step  4004 . In other words, the detected event can be a trigger event for both the first and second statechart objects. In some implementations, the first statechart transition at step  4003  and the second statechart transition at step  4004  can be performed in parallel by the network system to reduce processing time. As illustrated in  FIG. 1A , the first statechart transition at step  4003  does not trigger additional statechart transitions. On the other hands, the second statechart transition of the second statechart object at step  4004  can trigger two statechart transitions: a third statechart transition at step  4005  of a third statechart object and a fourth statechart transition at step  4006  of a fourth statechart object. The third and fourth statechart objects can be dynamically linked to the second statechart object. In response to triggering the second statechart transition of the second statechart object (step  4004 ), a statechart instantiation and transition engine can look up the statechart objects linked to the second statechart object and determine that the third and fourth statechart objects should be transitioned in response to step  4004 . Similar to steps  4003  and  4004 , the network system is configured to process steps  4005  and  4006  in parallel to reduce computation time. 
     A transaction coordinator can monitor each of the statechart transitions (steps  4003  through  4006 ). At step  4007 , the transaction coordinator can determine whether all the statechart transitions that were performed in response to the detected event (e.g., steps  4003  through  4006 ) were successfully completed. At step  4008 , if each of the statechart transitions were successfully completed, the transaction coordinator can write data to one or more databases to record the new states of the statechart objects (e.g., the resulting state the first statechart object after the first statechart transition performed at step  4003 , etc.) in persistent storage. If at least one of the statechart transitions failed, the transaction coordinator can, at step  4009 , cause the other statechart transitions (e.g., the statechart transitions that did not fail) to be rolled back. In this manner, the transaction coordinator can prevent inconsistent data regarding the statechart objects to be written into persistent storage and data consistency and integrity is improved. In addition, the network system can further perform one or more recovery functions at step  4010  in response to the transaction coordinator determining that at least one of the statechart transitions was not successfully completed. 
       FIG. 4B  is a flowchart diagram illustrating an example method of instantiating statechart objects in response to a transport request received from a requesting user. At step  4101 , the network system can receive a transport request from a requesting user device. The transport request can indicate a start location (e.g., where a transport service provider is to rendezvous with and pick up the requesting user) and a service location (e.g., where the transport service provider is to drop off the requesting user). In response to receiving the transport request, at Step  4102 , a first state transition (ST 1 ) can be triggered. The first state transition can be the instantiation of a fulfillment order statechart object that is used to model the fulfillment cycle of the transport request of the requesting user. The fulfillment order statechart object can be instantiated in the initial state of Fulfillment Order Created (e.g., Created state  3010  of  FIG. 3A ). At step  4103 , in response to the instantiation of the fulfillment statechart object, a second state transition (ST 2 ) can be triggered. The second state transition can be the instantiation of a transport job statechart object, which can be instantiated in the initial state(s) of Transport Job Processing:Open (e.g., Processing state  3101  and Open sub-state of  FIG. 3B ). In response to the instantiation of the transport job statechart object, a third state transition (ST 3 ) at step  4104  and a fourth state transition (ST 4 ) can be triggered at step  4105 . The third state transition (step  4104 ) can correspond to the instantiation of a first waypoint statechart object (WP 1 ) and the fourth state transition (step  4105 ) can correspond to the instantiation of a second waypoint statechart object (WP 2 ). Step  4104  and step  4105  can be performed in parallel by the network system. And the first waypoint statechart object can be used to model the transport service provider&#39;s progress towards the start location and the second waypoint statechart object can be used to model the transport service provider&#39;s progress towards the service location. Each of the first and second waypoint statechart objects can be instantiated in the Waypoint Created state. At step  4106 , a transaction coordinator can determine whether each of the state transitions represented by steps  4102  to  4105  have been successfully completed. If the transitions are all successfully completed, transaction data associated with the state transitions can be committed to a database for storing statechart object data (step  4107 ). 
       FIG. 4C  is a flowchart diagram illustrating an example method of transitioning states of statechart objects in response to an detecting an event corresponding to a transport service provider picking up a requesting user, in accordance with examples described herein. The flowchart  4200  can illustrate an exemplary process that begins with step  4201  in which the network system monitors the location of a service provider that is assigned to fulfill a transport request of a user and is progressing towards a start location to rendezvous with the requesting user. At or prior to step  4201 , a fulfillment order statechart object has been instantiated and is in the FO Active state. A transport job statechart object has also been instantiated, is linked to the fulfillment order statechart object, and is in the Transport Job Processing:Assigned state and sub-state. Two waypoint statechart objects are instantiated and linked to the transport job statechart. A first waypoint statechart object (WP 1 ) can correspond to the start location and is in the Waypoint Pending state whereas a second waypoint statechart object (WP 2 ) can correspond to the service location and is in the Waypoint Created state. In step  4201 , the network system can continuously or periodically communicate with the provider device of the assigned transport service provider to receive location data (e.g., GPS data, GLONASS data, etc.) to determine the transport service provider&#39;s location relative to the next waypoint (e.g., WP 1 ) on the route plan determined for the transport service provider. If it is determined at step  4202  that the transport service provider is within a predetermined distance threshold (or within an ETA threshold) from the start location, the network system can trigger a first state transition (ST 1 ) to cause WP 1  to transition from the Waypoint Pending state to the Waypoint Waiting state (step  4203 ). While in the Waypoint Waiting state, the network system can monitor for a transport event indication from the provider device step  4204 . At step  4205 , the network system can receive such a transport event indication. This transport event indication can be a provider input received via a provider service application executing on the provider device indicating that the transport service provider has rendezvoused and picked up the requesting user. In response to receiving the provider input, the network system can trigger a second state transition (ST 2 ) to transition WP 1  from the Waypoint Waiting state to the Waypoint Complete state at step  4206 . In response to WP 1  transitioning to the Waypoint Complete state, the network system can, at step  4207 , trigger a third state transition (ST 3 ) to transition the transport job statechart object from the Transport Job Processing:Assigned state and sub-state to the Transport Job In-Progress state. At step  4208 , the transition of the transport job statechart object to the In-Progress state can trigger a fourth state transition (ST 4 ) in which the second waypoint statechart object (WP 2 ) is transitioned from the Waypoint Created state to the Waypoint Pending state. At step  4209 , the transaction coordinator determines whether each of the state transitions related to the provider input received at step  4205  (ST 2  to ST 4 ) have been successfully completed. If the state transitions of ST 2  to ST 4  have all been successfully completed, transaction data associated with the state transitions can be committed to a database for storing statechart object data (step  4210 ). 
       FIG. 4D  is a flowchart diagram illustrating an example method of transitioning states of statechart objects in response to an detecting an event corresponding to a transport service provider dropping off a requesting user, in accordance with examples described herein. The flowchart  4300  can illustrate an exemplary process that begins with step  4301  in which the network system monitors the location of a service provider that is providing transportation for a requesting user and progressing towards a service location to drop off the requesting user. At or prior to step  4301 , a fulfillment order statechart object has been instantiated and is in the FO Active state. A transport job statechart object has also been instantiated, is linked to the fulfillment order statechart object, and is in the Transport Job In Progress state. Two waypoint statechart objects are instantiated and linked to the transport job statechart. A first waypoint statechart object (WP 1 ) can correspond to the start location and is in the Waypoint Complete state whereas a second waypoint statechart object (WP 2 ) can correspond to the service location and is in the Waypoint Pending state. In step  4301 , the network system can continuously or periodically communicate with the provider device of the assigned transport service provider to receive location data (e.g., GPS data, GLONASS data, etc.) to determine the transport service provider&#39;s location relative to the next waypoint (e.g., WP 2 ) on the route plan determined for the transport service provider. If it is determined at step  4302  that the transport service provider is within a predetermined distance threshold (or within an ETA threshold) from the service location, the network system can trigger a first state transition (ST 1 ) to cause WP 2  to transition from the Waypoint Pending state to the Waypoint Waiting state (step  4303 ). While in the Waypoint Waiting state, the network system can monitor for a transport event indication from the provider device step  4304 . At step  4205 , the network system can receive such a transport event indication. This transport event indication can be a provider input received via a provider service application executing on the provider device indicating that the transport service provider dropped off the requesting user at the service location. In response to receiving the provider input, the network system can trigger a second state transition (ST 2 ) to transition WP 2  from the Waypoint Waiting state to the Waypoint Complete state at step  4306 . In response to WP 2  transitioning to the Waypoint Complete state, the network system can, at step  4207 , trigger a third state transition (ST 3 ) to transition the transport job statechart object from the Transport Job In-Progress state to the Transport Job Complete state. At step  4208 , the transition of the transport job statechart object to the Transport Job Complete can trigger a fourth state transition (ST 4 ) in which the fulfillment order statechart object is transitioned to the Fulfillment Order Complete state. The transition of the fulfillment order statechart object to the FO Complete state can further trigger a set of actions to be completed by the network system including, for example, processing one or more financial transactions associated with the user&#39;s request (step  4308 -A). At step  4209 , the transaction coordinator determines whether each of the state transitions related to the provider input received at step  4205  (ST 2  to ST 4 ) have been successfully completed. If the state transitions of ST 2  to ST 4  have all been successfully completed, transaction data associated with the state transitions can be committed to a database for storing statechart object data (step  4210 ). 
     Hardware Diagrams 
       FIG. 5  is a block diagram illustrating an example service provider device executing and operating a designated service provider application for communicating with a network service, according to examples described herein. In many implementations, the service provider device  500  can comprise a mobile computing device, such as a smartphone, tablet computer, laptop computer, VR or AR headset device, and the like. As such, the service provider device  500  can include typical telephony features such as a microphone  545 , a camera  550 , and a communication interface  510  to communicate with external entities using any number of wireless communication protocols. The service provider device  500  can store a designated application (e.g., a service provider app  532 ) in a local memory  530 . In response to a service provider input  518 , the service provider app  532  can be executed by a processor  540 , which can cause an app interface  542  to be generated on a display screen  520  of the service provider device  500 . The app interface  542  can enable the service provider to, for example, accept or reject invitations  592  in order to service requests throughout a given region. 
     In various examples, the service provider device  500  can include a GPS module  560 , which can provide location data  562  indicating the current location of the service provider to the network system  590  over a network  580 . Thus, the network system  590  can utilize the current location  562  of the service provider to determine whether the service provider is optimally located to service a particular request. If the service provider is optimal to service the request, the network system  590  can transmit an invitation  592  to the service provider device  500  over the network  580 . The invitation  592  can be displayed on the app interface  542 , and can be accepted or declined by the service provider. If the service provider accepts the invitation  592 , then the service provider can provide a service provider input  518  on the displayed app interface  542  to provide a confirmation  522  to the network system  590  indicating that the service provider will rendezvous with the requesting user at the start location to service the ride request. 
     In certain implementations, the service provider device  500  is configured to generate and transmit, to the network system  590 , context data  563  that can be used by the network system to determine a propensity of the service provider who operates the service provider device  500  to perform an action via the service provider application  532 . The context data  563  can include service provider application interaction data indicating interactions or inputs of the service provider with the service provider application  532 . The context data  463  can further include sensor data such accelerometer data, gyroscope data, e-compass data, and the like. In certain implementations, the network system  590  can further utilize location data  562  as context data in making certain determinations. Using the context data  563 , the network system  590  can determine, using one or more context models, a propensity of the service provider to, for example, decline an invitation corresponding to a service request form a user or cancel an acceptance after the service provider has accepted the invitation. 
       FIG. 6  is a block diagram illustrating an example user device executing and operating a designated user application for communicating with a network system, according to examples described herein. In many implementations, the user device  600  can comprise a mobile computing device, such as a smartphone, tablet computer, laptop computer, VR or AR headset device, and the like. As such, the user device  600  can include typical telephony features such as a microphone  645 , a camera  650 , and a communication interface  610  to communicate with external entities using any number of wireless communication protocols. In certain aspects, the user device  600  can store a designated application (e.g., a user application  632 ) in a local memory  630 . In variations, the memory  630  can store additional applications executable by one or more processors  640  of the user device  600 , enabling access and interaction with one or more host servers over one or more networks  680 . 
     In response to a user input  618 , the user application  632  can be executed by a processor  640 , which can cause an application interface  642  to be generated on a display screen  620  of the user device  600 . The application interface  642  can enable the user to, for example, check current value levels and availability for the network service. In various implementations, the application interface  642  can further enable the user to select from multiple service types. 
     The user can generate a service request  667  via user inputs  618  provided on the application interface  642 . For example, the user can select a start location, view the various service types and estimated costs, and select a particular service to an inputted destination. In many examples, the user can input the destination prior to pick-up. As provided herein, the user application  632  can further enable a communication link with a network system  690  over the network  680 , such as the network system  100  as shown and described with respect to  FIG. 1 . The processor  640  can generate user interface features  628  (e.g., map, trip progress bar, content cards, etc.) using content data  626  received from the network system  690  over network  680 . Furthermore, as discussed herein, the user application  632  can enable the network system  690  to cause the generated user interface features  628  to be displayed on the application interface  642 . 
     The processor  640  can transmit the service requests  667  via a communications interface  610  to the backend network system  690  over a network  680 . In response, the user device  600  can receive a confirmation  669  from the network system  690  indicating the selected service provider and vehicle that will fulfill the service request  667  and rendezvous with the user at the start location. In various examples, the user device  600  can further include a GPS module  660 , which can provide location data  662  indicating the current location of the requesting user to the network system  690  to, for example, establish the start location and/or select an optimal service provider or autonomous vehicle to service the request  667 . 
     In certain implementations, the user device  600  is configured to generate and transmit, to the network system  690 , context data  663  that can be used by the network system to determine a propensity of the user who operates the user device  600  to perform an action via the user application  632 . The context data  663  can include user application interaction data indicating interactions, inputs, selections, or a degree of progress through a particular user interface flow (e.g., a user interface flow to submit a service request). The context data  663  can further include sensor data such as barometer or elevation data, ambient light sensor data, accelerometer data, gyroscope data, location data  662 , and the like. The context data  663  can further include user application status data indicating, for example, whether the user application  632  is executing as a background process or as a foreground process on the user device  600 . The user application status data can further indicate a duration of time the user application  632  has been executing as a foreground process or a duration of time the user application  632  has been executing as a background process. Using the context data  663 , the network system  690  can determine, using one or more context models, a propensity of the user to, for example, submit a service request within the next 2 minutes, or cancel a submitted service request  667  once the user is matched by the network system  690  with a service provider in response to the service request  667 . 
       FIG. 7  is a block diagram that illustrates a computer system upon which examples described herein may be implemented. A computer system  700  can be implemented on, for example, a server or combination of servers. For example, the computer system  700  may be implemented as part of a network service, such as described in  FIGS. 1 through 6 . In the context of  FIG. 1 , the computer system  700  may be implemented using a computer system  700  such as described by  FIG. 6 . The network system  100  may also be implemented using a combination of multiple computer systems as described in connection with  FIG. 7 . 
     In one implementation, the computer system  700  includes processing resources  710 , a main memory  720 , a read-only memory (ROM)  730 , a storage device  740 , and a communication interface  750 . The computer system  700  includes at least one processor  710  for processing information stored in the main memory  720 , such as provided by a random access memory (RAM) or other dynamic storage device, for storing information and instructions which are executable by the processor  710 . The main memory  720  also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by the processor  710 . The computer system  700  may also include the ROM  730  or other static storage device for storing static information and instructions for the processor  710 . A storage device  740 , such as a magnetic disk or optical disk, is provided for storing information and instructions. 
     The communication interface  750  enables the computer system  700  to communicate with one or more networks  780  (e.g., cellular network) through use of the network link (wireless or wired). Using the network link, the computer system  700  can communicate with one or more computing devices, one or more servers, and/or one or more self-driving vehicles. In accordance with examples, the computer system  700  receives requests  782  from mobile computing devices of individual users. The executable instructions stored in the memory  720  can include service provider selection instructions  722 , which the processor  710  executes to select a service provider to service the request  782 . In doing so, the computer system can receive service provider locations  784  of service providers operating throughout the given region, and the processor can execute the service provider selection instructions  722  to identify a plurality of candidate service providers and transmit invitation messages  752  to each of the candidate service providers to enable the service providers to accept or decline the invitations. The processor can further execute the service provider selection instructions  722  to select a service provider among interested candidate service providers to service the request  782 . 
     The executable instructions stored in the memory  720  can also include content generation instructions  724 , which enable the computer system  700  to access user profiles  726  and other user information in order to select and/or generate user content  754  for display on the user devices. As described throughout, user content  754  can be generated based on information pertaining to the state of the request (e.g., ETA/destination info). In addition, instructions executed by the processor  710  can further include statechart instructions  728  that pertain to the instantiation, maintenance, and state transitions of statechart objects as described herein. By way of example, the instructions and data stored in the memory  720  can be executed by the processor  710  to implement an example network system  100  of  FIG. 1 . In performing the operations, the processor  710  can receive requests  782  and service provider locations  784 , and submit invitation messages  752  to facilitate the servicing of the requests  782 . The processor  710  is configured with software and/or other logic to perform one or more processes, steps and other functions described with implementations, such as described by  FIGS. 1 and 2 , and elsewhere in the present application. 
     Examples described herein are related to the use of the computer system  700  for implementing the techniques described herein. According to one example, those techniques are performed by the computer system  700  in response to the processor  710  executing one or more sequences of one or more instructions contained in the main memory  720 . Such instructions may be read into the main memory  720  from another machine-readable medium, such as the storage device  740 . Execution of the sequences of instructions contained in the main memory  720  causes the processor  710  to perform the process steps described herein. In alternative implementations, hard-wired circuitry may be used in place of or in combination with software instructions to implement examples described herein. Thus, the examples described are not limited to any specific combination of hardware circuitry and software. 
     It is contemplated for examples described herein to extend to individual elements and concepts described herein, independently of other concepts, ideas or systems, as well as for examples to include combinations of elements recited anywhere in this application. Although examples are described in detail herein with reference to the accompanying drawings, it is to be understood that the concepts are not limited to those precise examples. As such, many modifications and variations will be apparent to practitioners skilled in this art. Accordingly, it is intended that the scope of the concepts be defined by the following claims and their equivalents. Furthermore, it is contemplated that a particular feature described either individually or as part of an example can be combined with other individually described features, or parts of other examples, even if the other features and examples make no mentioned of the particular feature. Thus, the absence of describing combinations should not preclude claiming rights to such combinations.