BACKGROUND

[1] Transportation services may provide transportation on demand, drawing from a transportation supply pool that includes vehicles of multiple types to meet the needs of those requesting transportation as such needs arise. Some transportation services may include personal mobility vehicles including, but not limited to, shareable or rentable bicycles and scooters in a dynamic transportation network in order to enable users to complete portions of a journey more efficiently. Such personal mobility vehicles provide an additional dimension of transportation flexibility. Shareable or rentable mobility vehicles may need to be redistributed between several locations to enhance their availability to users to account for popular journey start or end locations. Managing the redistribution for a large mobility vehicle fleet deployed in operation is labor and cost intensive as the vehicles may be rented and moved around the urban environment by users. There is a need to improve upon service task and operation management technology by implementing an automated platform that allows for dynamic updating of service tasks using realtime and learned historic data to increase productivity and operations efficiency and provide for greater availability of mobility vehicles and related infrastructural services.

BRIEF DESCRIPTION OF THE DRAWINGS

[2] FIG. 1 illustrates a block diagram of a portion of a dynamic transportation matching system including a transit vehicle.

[3] FIG. 2 illustrates a block diagram of a dynamic transportation matching system incorporating a variety of transportation modalities.

[4] FIGS. 3A-3C illustrate respective diagrams of mobility transit vehicles for use in a dynamic transportation matching system.

[5] FIG. 3D illustrates a diagram of a docking station for docking one or more mobility transit vehicles.

[6] FIG. 4 illustrates an example flow diagram for generating rider experience features.

[7] FIGS. 5A-5B illustrate example user interface for showing estimated waiting time for the next available dock.

[8] FIG. 6 illustrates an example user interface for showing probabilities of station availability. [9] FIG. 7 illustrates an example method for estimating waiting time for next available docking station.

[10] FIG. 8 illustrates an example method for pre-trip routing based on station availability.

[11] FIG. 9 illustrates an example method for reserving an available docking station.

[12] FIG. 10 illustrates an example method for forecasting availabilities of mobility vehicles.

[13] FIG. 11 illustrates an example of a computing system.

DESCRIPTION OF EXAMPLE EMBODIMENTS

[14] In the following description, various embodiments will be described. For purposes of explanation, specific configurations and details are set forth in order to provide a thorough understanding of the embodiments. However, it will also be apparent to one skilled in the art that the embodiments may be practiced without the specific details. Furthermore, well-known features may be omitted or simplified in order not to obscure the embodiment being described. In addition, the embodiments disclosed herein are only examples, and the scope of this disclosure is not limited to them. Particular embodiments may include all, some, or none of the components, elements, features, functions, operations, or steps of the embodiments disclosed above. Embodiments according to the invention are in particular disclosed in the attached claims directed to a method, a storage medium, a system and a computer program product, wherein any feature mentioned in one claim category, e.g., method, can be claimed in another claim category, e.g., system, as well. The dependencies or references back in the attached claims are chosen for formal reasons only. However, any subject matter resulting from a deliberate reference back to any previous claims (in particular multiple dependencies) can be claimed as well, so that any combination of claims and the features thereof are disclosed and can be claimed regardless of the dependencies chosen in the attached claims. The subject-matter which can be claimed comprises not only the combinations of features as set out in the attached claims but also any other combination of features in the claims, wherein each feature mentioned in the claims can be combined with any other feature or combination of other features in the claims. Furthermore, any of the embodiments and features described or depicted herein can be claimed in a separate claim and/or in any combination with any embodiment or feature described or depicted herein or with any of the features of the attached claims. [15] FIG. 1 illustrates a block diagram of a portion of a dynamic transportation matching system 100 including a transit vehicle 110. In the embodiment shown in FIG. 1, system 100 may include transit vehicle 110 and an optional user device 130. In general, transit vehicle 110 may be a passenger vehicle designed to transport a single person (e.g., a mobility transit vehicle, a transit bike and scooter vehicle, or the like) or a group of people (e.g., a typical car or truck). Transit vehicle 110 may be implemented as a motorized or electric kick scooter, bicycle, and/or motor scooter designed to transport one or more people at once typically on a paved road (collectively, mobility transit vehicles). Transit vehicle 110 may be implemented as an automobile configured to transport up to 4, 7, 10, or more people at once, or according to a variety of different transportation modalities (e.g., transportation mechanisms). Transit vehicles similar to transit vehicle 110 may be owned, managed, and/or serviced primarily by a fleet manager/servicer providing transit vehicle 110 for use by the public as one or more types of transportation modalities offered by a dynamic transportation matching system, for example. In some embodiments, transit vehicles similar to transit vehicle 110 may be owned, managed, and/or serviced by a private owner using the dynamic transportation matching system to match their vehicle to a transportation request, such as with ridesharing or ride-sourcing applications typically executed on a mobile user device, such as user device 130 as described herein. User device 130 may be a smartphone, tablet, near field communication (NFC) or radio-frequency identification (RFID) enabled smart card, or other personal or portable computing and/or communication device that may be used to facilitate rental and/or operation of transit vehicle 110.

[16] As shown in FIG. 1, transit vehicle 110 may include one or more of a controller 112, a user interface 113, an orientation sensor 114, a gyroscope/accelerometer 116, a global navigation satellite system (GNSS) receiver 118, a wireless communications module 120, a camera 148, a propulsion system 122, an air quality sensor 150, and other modules 126. Operation of transit vehicle 110 may be substantially manual, autonomous, and/or partially or completely controlled by user device 130, which may include one or more of a user interface 132, a wireless communications module 134, a camera 138, and other modules 136. In other embodiments, transit vehicle 110 may include any one or more of the elements of user device 130. In some embodiments, one or more of the elements of system 100 may be implemented in a combined housing or structure that can be coupled to or within transit vehicle 110 and/or held or carried by a user of system 100. [17] Controller 112 may be implemented as any appropriate logic device (e.g., processing device, microcontroller, processor, application specific integrated circuit (ASIC), field programmable gate array (FPGA), memory storage device, memory reader, or other device or combinations of devices) that may be adapted to execute, store, and/or receive appropriate instructions, such as software instructions implementing a control loop for controlling various operations of transit vehicle 110 and/or other elements of system 100, for example. Such software instructions may also implement methods for processing images such as those provided by camera 148, and/or other sensor signals or data, determining sensor information, providing user feedback (e.g., through user interface 113 or 132), querying devices for operational parameters, selecting operational parameters for devices, or performing any of the various operations described herein (e.g., operations performed by logic devices of various devices of system 100).

[18] In addition, a non-transitory medium may be provided for storing machine readable instructions for loading into and execution by controller 112. In these and other embodiments, controller 112 may be implemented with other components where appropriate, such as volatile memory, non-volatile memory, one or more interfaces, and/or various analog and/or digital components for interfacing with devices of system 100. For example, controller 112 may be adapted to store sensor signals, sensor information, parameters for coordinate frame transformations, calibration parameters, sets of calibration points, and/or other operational parameters, over time, for example, and provide such stored data to a user via user interface 113 or 132. In some embodiments, controller 112 may be integrated with one or more other elements of transit vehicle 110, for example, or distributed as multiple logic devices within transit vehicle 110 and/or user device 130.

[19] In some embodiments, controller 112 may be configured to substantially continuously monitor and/or store the status of and/or sensor data provided by one or more elements of transit vehicle 110 and/or user device 130, such as the position and/or orientation of transit vehicle 110 and/or user device 130, for example, and the status of a communication link established between transit vehicle 110 and/or user device 130. Such communication links may be established and then provide for transmission of data between elements of system 100 substantially continuously throughout operation of system 100, where such data includes various types of sensor data, control parameters, and/or other data. [20] User interface 113 of transit vehicle 110 may be implemented as one or more of a display, a touch screen, a keyboard, a mouse, a joystick, a knob, a steering wheel, a yoke, and/or any other device capable of accepting user input and/or providing feedback to a user. In various embodiments, user interface 113 may be adapted to provide user input (e.g., as a type of signal and/or sensor information transmitted by wireless communications module 134 of user device 130) to other devices of system 100, such as controller 112. User interface 113 may also be implemented with one or more logic devices (e.g., similar to controller 112) that may be adapted to store and/or execute instructions, such as software instructions, implementing any of the various processes and/or methods described herein. For example, user interface 113 may be adapted to form communication links, transmit and/or receive communications (e.g., infrared images and/or other sensor signals, control signals, sensor information, user input, and/or other information), for example, or to perform various other processes and/or methods described herein.

[21] In one embodiment, user interface 113 may be adapted to display a time series of various sensor information and/or other parameters as part of or overlaid on a graph or map, which may be referenced to a position and/or orientation of transit vehicle 110 and/or other elements of system 100. For example, user interface 113 may be adapted to display a time series of positions, headings, and/or orientations of transit vehicle 110 and/or other elements of system 100 overlaid on a geographical map, which may include one or more graphs indicating a corresponding time series of actuator control signals, sensor information, and/or other sensor and/or control signals. In some embodiments, user interface 113 may be adapted to accept user input including a user- defined target heading, waypoint, route, and/or orientation, for example, and to generate control signals to cause transit vehicle 110 to move according to the target heading, route, and/or orientation. In other embodiments, user interface 113 may be adapted to accept user input modifying a control loop parameter of controller 112, for example.

[22] Orientation sensor 114 may be implemented as one or more of a compass, float, accelerometer, and/or other device capable of measuring an orientation of transit vehicle 110 (e.g., magnitude and direction of roll, pitch, and/or yaw, relative to one or more reference orientations such as gravity and/or Magnetic North), camera 148, and/or other elements of system 100, and providing such measurements as sensor signals and/or data that may be communicated to various devices of system 100. Gyroscope/accelerometer 116 may be implemented as one or more electronic sextants, semiconductor devices, integrated chips, accelerometer sensors, accelerometer sensor systems, or other devices capable of measuring angular velocities/accelerations and/or linear accelerations (e.g., direction and magnitude) of transit vehicle 110 and/or other elements of system 100 and providing such measurements as sensor signals and/or data that may be communicated to other devices of system 100 (e.g., user interface 132, controller 112).

[23] GNSS receiver 118 may be implemented according to any global navigation satellite system, including a GPS, GLONASS, and/or Galileo based receiver and/or other device capable of determining absolute and/or relative position of transit vehicle 110 (e.g., or an element of transit vehicle 110) based on wireless signals received from space-born and/or terrestrial sources (e.g., eLoran, and/or other at least partially terrestrial systems), for example, and capable of providing such measurements as sensor signals and/or data (e.g., coordinates) that may be communicated to various devices of system 100. In some embodiments, GNSS receiver 118 may include an altimeter, for example, or may be used to provide an absolute altitude.

[24] Wireless communications module 120 may be implemented as any wireless communications module configured to transmit and receive analog and/or digital signals between elements of system 100. For example, wireless communications module 120 may be configured to directly or indirectly receive control signals and/or data from user device 130 and provide them to controller 112 and/or propulsion system 122. In other embodiments, wireless communications module 120 may be configured to receive images and/or other sensor information (e.g., still images or video images) and relay the sensor data to controller 112 and/or user device 130. In some embodiments, wireless communications module 120 may be configured to support spread spectrum transmissions, for example, and/or multiple simultaneous communications channels between elements of system 100. Wireless communication links formed by wireless communications module 120 may include one or more analog and/or digital radio communication links, such as WiFi, Bluetooth, NFC, RFID, LTE, and others, as described herein, and may be direct communication links established between elements of system 100, for example, or may be relayed through one or more wireless relay stations configured to receive and retransmit wireless communications. In various embodiments, wireless communications module 120 may be configured to support wireless mesh networking, as described herein.

[25] In some embodiments, wireless communications module 120 may be configured to be physically coupled to transit vehicle 110 and to monitor the status of a communication link directly or indirectly established between transit vehicle 110 and/or user device 130. Such status information may be provided to controller 112, for example, or transmitted to other elements of system 100 for monitoring, storage, or further processing, as described herein. In addition, wireless communications module 120 may be configured to determine a range to another device, such as based on time of flight, and provide such range to the other device and/or controller 112. Communication links established by communication module 120 may be configured to transmit data between elements of system 100 substantially continuously throughout operation of system 100, where such data includes various types of sensor data, control parameters, and/or other data, as described herein.

[26] Propulsion system 122 may be implemented as one or more motor-based propulsion systems, and/or other types of propulsion systems that can be used to provide motive force to transit vehicle 110 and/or to steer transit vehicle 110. In some embodiments, propulsion system 122 may include elements that can be controlled (e.g., by controller 112 and/or user interface 113) to provide motion for transit vehicle 110 and to provide an orientation for transit vehicle 110. In various embodiments, propulsion system 122 may be implemented with a portable power supply, such as a battery. In some embodiments, propulsion system 122 may be implemented with a combustion engine/generator and fuel supply.

[27] For example, in some embodiments, such as when propulsion system 122 is implemented by an electric motor (e.g., as with many mobility transit vehicles), transit vehicle 110 may include battery 124. Battery 124 may be implemented by one or more battery cells (e.g., lithium ion battery cells) and be configured to provide electrical power to propulsion system 122 to propel transit vehicle 110, for example, as well as to various other elements of system 100, including controller 112, user interface 113, and/or wireless communications module 120. In some embodiments, battery 124 may be implemented with its own safety measures, such as thermal interlocks and a fire-resistant enclosure, for example, and may include one or more logic devices, sensors, and/or a display to monitor and provide visual feedback of a charge status of battery 124 (e.g., a charge percentage, a low charge indicator, etc.).

[28] Other modules 126 may include other and/or additional sensors, actuators, communications modules/nodes, and/or user interface devices, for example, and may be used to provide additional environmental information related to operation of transit vehicle 110, for example. In some embodiments, other modules 126 may include a humidity sensor, a wind and/or water temperature sensor, a barometer, an altimeter, a radar system, a proximity sensor, a visible spectrum camera or infrared camera (with an additional mount), and/or other environmental sensors providing measurements and/or other sensor signals that can be displayed to a user and/or used by other devices of system 100 (e.g., controller 112) to provide operational control of transit vehicle 110 and/or system 100. In further embodiments, other modules 126 may include a light, such as a headlight or indicator light, and/or an audible alarm, both of which may be activated to alert passersby to possible theft, abandonment, and/or other critical statuses of transit vehicle 110. In particular, and as shown in FIG. 1, other modules 126 may include camera 148 and/or air quality sensor 150.

[29] Camera 148 may be implemented as an imaging device including an imaging module including an array of detector elements that can be arranged in a focal plane array. In various embodiments, camera 148 may include one or more logic devices (e.g., similar to controller 112) that can be configured to process imagery captured by detector elements of camera 148 before providing the imagery to communications module 120 or other elements of the system 100. More generally, camera 148 may be configured to perform any of the operations or methods described herein, at least in part, or in combination with controller 112 and/or user interface 113 or 132. In some embodiments, camera 148 may be a visible light imager and/or thermal imager.

[30] In various embodiments, air quality sensor 150 may be implemented as an air sampling sensor configured to determine an air quality of an environment about transit vehicle 110 and provide corresponding air quality sensor data. Air quality sensor data provided by air quality sensor 150 may include particulate count, methane content, ozone content, and/or other air quality sensor data associated with common street level sensitivities and/or health monitoring typical when in a street level environment, such as that experienced when riding on a typical mobility transit vehicle, as described herein.

[31] Transit vehicles implemented as mobility transit vehicles may include a variety of additional features designed to facilitate fleet management and user and environmental safety. For example, as shown in FIG. 1, transit vehicle 110 may include one or more of docking mechanism 140, operator safety measures 142, vehicle security device 144, and/or user storage 146, as described in more detail herein by reference to Figs. 3A-C.

[32] User interface 132 of user device 130 may be implemented as one or more of a display, a touch screen, a keyboard, a mouse, a joystick, a knob, a steering wheel, a yoke, and/or any other device capable of accepting user input and/or providing feedback to a user. In various embodiments, user interface 132 may be adapted to provide user input (e.g., as a type of signal and/or sensor information transmitted by wireless communications module 134 of user device 130) to other devices of system 100, such as controller 112. User interface 132 may also be implemented with one or more logic devices (e.g., similar to controller 112) that may be adapted to store and/or execute instructions, such as software instructions, implementing any of the various processes and/or methods described herein. For example, user interface 132 may be adapted to form communication links, transmit and/or receive communications (e.g., infrared images and/or other sensor signals, control signals, sensor information, user input, and/or other information), for example, or to perform various other processes and/or methods described herein.

[33] In one embodiment, user interface 132 may be adapted to display a time series of various sensor information and/or other parameters as part of or overlaid on a graph or map, which may be referenced to a position and/or orientation of transit vehicle 110 and/or other elements of system 100. For example, user interface 132 may be adapted to display a time series of positions, headings, and/or orientations of transit vehicle 110 and/or other elements of system 100 overlaid on a geographical map, which may include one or more graphs indicating a corresponding time series of actuator control signals, sensor information, and/or other sensor and/or control signals. In some embodiments, user interface 132 may be adapted to accept user input including a user- defined target heading, waypoint, route, and/or orientation, for example, and to generate control signals to cause transit vehicle 110 to move according to the target heading, route, and/or orientation. In other embodiments, user interface 132 may be adapted to accept user input modifying a control loop parameter of controller 112, for example.

[34] Wireless communications module 134 may be implemented as any wireless communications module configured to transmit and receive analog and/or digital signals between elements of system 100. For example, wireless communications module 134 may be configured to directly or indirectly transmit control signals from user interface 132 to wireless communications module 120 or 134. In some embodiments, wireless communications module 134 may be configured to support spread spectrum transmissions, for example, and/or multiple simultaneous communications channels between elements of system 100. In various embodiments, wireless communications module 134 may be configured to monitor the status of a communication link established between user device 130 and/or transit vehicle 110 (e.g., including packet loss of transmitted and received data between elements of system 100, such as with digital communication links), and/or determine a range to another device, as described herein. Such status information may be provided to user interface 132, for example, or transmitted to other elements of system 100 for monitoring, storage, or further processing, as described herein. In various embodiments, wireless communications module 134 may be configured to support wireless mesh networking, as described herein.

[35] Other modules 136 of user device 130 may include other and/or additional sensors, actuators, communications modules/nodes, and/or user interface devices used to provide additional environmental information associated with user device 130, for example. In some embodiments, other modules 136 may include a humidity sensor, a wind and/or water temperature sensor, a barometer, a radar system, a visible spectrum camera, an infrared camera, a GNSS receiver, and/or other environmental sensors providing measurements and/or other sensor signals that can be displayed to a user and/or used by other devices of system 100 (e.g., controller 112) to provide operational control of transit vehicle 110 and/or system 100 or to process sensor data to compensate for environmental conditions. As shown in FIG. 1, other modules 136 may include camera 138.

[36] Camera 138 may be implemented as an imaging device including an imaging module including an array of detector elements that can be arranged in a focal plane array. In various embodiments, camera 138 may include one or more logic devices (e.g., similar to controller 112) that can be configured to process imagery captured by detector elements of camera 138 before providing the imagery to communications module 120. More generally, camera 138 may be configured to perform any of the operations or methods described herein, at least in part, or in combination with controller 138 and/or user interface 113 or 132.

[37] In general, each of the elements of system 100 may be implemented with any appropriate logic device (e.g., processing device, microcontroller, processor, application specific integrated circuit (ASIC), field programmable gate array (FPGA), memory storage device, memory reader, or other device or combinations of devices) that may be adapted to execute, store, and/or receive appropriate instructions, such as software instructions implementing a method for providing sensor data and/or imagery, for example, or for transmitting and/or receiving communications, such as sensor signals, sensor information, and/or control signals, between one or more devices of system 100. [38] In addition, one or more non-transitory mediums may be provided for storing machine readable instructions for loading into and execution by any logic device implemented with one or more of the devices of system 100. In these and other embodiments, the logic devices may be implemented with other components where appropriate, such as volatile memory, nonvolatile memory, and/or one or more interfaces (e.g., inter-integrated circuit (I2C) interfaces, mobile industry processor interfaces (MIPI), joint test action group (JTAG) interfaces (e.g., IEEE 1149.1 standard test access port and boundary-scan architecture), and/or other interfaces, such as an interface for one or more antennas, or an interface for a particular type of sensor).

[39] Sensor signals, control signals, and other signals may be communicated among elements of system 100 and/or elements of other systems similar to system 100 using a variety of wired and/or wireless communication techniques, including voltage signaling, Ethernet, WiFi, Bluetooth, Zigbee, Xbee, Micronet, Near-field Communication (NFC) or other medium and/or short range wired and/or wireless networking protocols and/or implementations, for example. In such embodiments, each element of system 100 may include one or more modules supporting wired, wireless, and/or a combination of wired and wireless communication techniques, including wireless mesh networking techniques. In some embodiments, various elements or portions of elements of system 100 may be integrated with each other, for example, or may be integrated onto a single printed circuit board (PCB) to reduce system complexity, manufacturing costs, power requirements, coordinate frame errors, and/or timing errors between the various sensor measurements.

[40] Each element of system 100 may include one or more batteries, capacitors, or other electrical power storage devices, for example, and may include one or more solar cell modules or other electrical power generating devices. In some embodiments, one or more of the devices may be powered by a power source for transit vehicle 110, using one or more power leads. Such power leads may also be used to support one or more communication techniques between elements of system 100

[41] FIG. 2 illustrates a diagram of a dynamic transportation matching system 200 incorporating a variety of transportation modalities. For example, as shown in FIG. 2, dynamic transportation matching system 200 may include multiple embodiments of system 100. In the embodiment shown in FIG. 2, dynamic transportation matching system 200 includes a management system/server 240 in communication with a number of transit vehicles HOa-d and user devices 130a-b over a combination of a typical wide area network (WAN) 250, WAN communication links 252 (solid lines), a variety of mesh network communication links 254 (curved dashed lines), and NFC, RFID, and/or other local communication links 256 (curved solid lines). Dynamic transportation matching system 200 also includes a public transportation status system 242 in communication with a variety of public transportation vehicles, including one or more buses 210a, trains 210b, and/or other public transportation modalities, such as ships, ferries, light rail, subways, streetcars, trolleys, cable cars, monorails, tramways, and aircraft. As shown in FIG. 2, all transit vehicles are able to communicate directly to WAN 250 and, in some embodiments, may be able to communicate across mesh network communication links 254, to convey fleet data and/or fleet status data amongst themselves and/or to and from management system 240.

[42] In FIG. 2, user device 130a may receive an input with a request for transportation with one or more transit vehicles HOa-d and/or public transportation vehicles 210a-b. For example, the transportation request may be a request to use (e.g., hire or rent) one of transit vehicles 1 lOa-d. The transportation request may be transmitted to management system 240 over WAN 250, allowing management system 240 to poll status of transit vehicles HOa-d and to select one of transit vehicles 1 lOa-d to fulfill the transportation request. Upon or after one of the transit vehicles HOa-d is selected to fulfill the transportation request, a fulfillment notice from management system 240 and/or from the selected transit vehicle HOa-d may be transmitted to the user device 130a. In some embodiments, navigation instructions to proceed to or otherwise meet with the selected transit vehicle 1 lOa-d may be sent to the user device 130a. A similar process may occur using user device 130b, but where the transportation request enables a transit vehicle over a local communication link 256, as shown.

[43] Management system 240 may be implemented as a server with controllers, user interfaces, communications modules, and/or other elements similar to those described with respect to system 100 of FIG. 1, but with sufficient processing and storage resources to manage operation of dynamic transportation matching system 200, including monitoring statuses of transit vehicles 1 lOa-d, as described herein. In some embodiments, management system 240 may be implemented in a distributed fashion and include multiple separate server embodiments linked communicatively to each other direction and/or through WAN 250. WAN 250 may include one or more of the Internet, a cellular network, and/or other wired or wireless WANs. WAN communication links 252 may be wired or wireless WAN communication links, and mesh network communication links 254 may be wireless communication links between and among transit vehicles HOa-d, as described herein.

[44] User device 130a in FIG. 2 includes a display of user interface 132 that shows a planned route for a user attempting to travel from an origination point 260 to a destination 272 using different transportation modalities (e.g., a planned multimodal route), as depicted in a route/street map 286 rendered by user interface 132. For example, management system 240 may be configured to monitor statuses of all available transportation modalities (e.g., including transit vehicles and public transportation vehicles) and provide a planned multimodal route from origination point 260 to destination 272. Such a planned multimodal route may include, for example, a walking route 262 from origination point 260 to a bus stop 264, a bus route 266 from bus stop 264 to a bus stop 268 (e.g., using one or more of transit vehicles 210a or 210b), and a mobility route 270 (e.g., using one or more of mobility transit vehicles 110b, 110c, or 1 lOd) from bus stop 268 to destination 272. Also shown rendered by user interface 132 are a present location indicator 280 (indicating a present absolute position of user device 130a on street map 286), a navigation destination selector/indicator 282 (e.g., configured to allow a user to input a desired navigation destination), and a notice window 284 (e.g., used to render vehicle status data or other information, including user notices and/or alerts, as described herein). For example, a user may use navigation destination selector/indicator 282 to provide and/or change destination 272, as well as change any portion (e.g., leg, route, etc.) or modality of the multimodal route from origination point 260 to destination 272. In some embodiments, notice window 284 may display instructions for traveling to a next waypoint along the determined multimodal route (e.g., directions to walk to a bus stop, directions to ride a mobility transit vehicle to a next stop along the route, etc.).

[45] In various embodiments, management system 240 may be configured to provide or suggest an optimal multimodal route to a user (e.g., initially and/or while traversing a particular planned route), and a user may select or make changes to such a route through manipulation of user device 130a, as shown. For example, management system 240 may be configured to suggest a quickest route, a least expensive route, a most convenient route (to minimize modality changes or physical actions a user must take along the route), an inclement weather route (e.g., that keeps the user protected from inclement weather a maximum amount of time during route traversal), or some combination of those that is determined as best suited to the user, such as based on various user preferences. Such preferences may be based on prior use of system 200, prior user trips, a desired arrival time and/or departure time (e.g., based on user input or obtained through a user calendar or other data source), available system resources (e.g., availability of one or more transmit modality options), or specifically input or set by a user for the specific route, for example, or in general. In one example, origination point 260 may be extremely congested or otherwise hard to access by a ride-share transit vehicle, which could prevent or significantly increase a wait time for the user and a total trip time to arrive at destination 272. In such circumstances, a planned multimodal route may include directing the user to walk and/or take a scooter/bike to an intermediate and less congested location to meet a reserved ride- share vehicle, which would allow the user to arrive at destination 272 quicker than if the ride-share vehicle was forced to meet the user at origination point 260. It will be appreciated that numerous different transportation-relevant conditions may exist or dynamically appear or disappear along a planned route that may make it beneficial to use different modes of transportation to arrive at destination 272 efficiently, including changes in traffic congestion and/or other transportation-relevant conditions that occur mid-route, such as an accident along the planned route. Under such circumstances, management system 240 may be configured to adjust a modality or portion of the planned route dynamically in order to avoid or otherwise compensate for the changed conditions while the route is being traversed.

[46] FIGS. 3A-3C illustrate respective diagrams of mobility transit vehicles 110b, 110c, and HOd for use in a dynamic transportation matching system. For example, transit vehicle 110b of FIG. 3 A may correspond to a motorized bicycle integrated with the various elements of system 100 and may be configured to participate in dynamic transportation matching system 200 of FIG. 2. As shown, transit vehicle 110b includes controller/user interface/wireless communications module 112/113/120 (e.g., integrated with a rear fender of transit vehicle 110b), propulsion system 122 configured to provide motive power to at least one of the wheels (e.g., a rear wheel 322) of transit vehicle 110b, battery 124 for powering propulsion system 122 and/or other elements of transit vehicle 110b, docking mechanism 140 (e.g., a spade lock assembly) for docking transit vehicle 110b at a docking station, user storage 146 implemented as a handlebar basket, and vehicle security device (e.g., an embodiment of vehicle security device 144 of FIG. 1), which may incorporate one or more of a locking cable 144a, a pin 144b coupled to a free end of locking cable 144a, a pin latch/insertion point 144c, a frame mount 144d, and a cable/pin holster 144e, as shown (collectively, vehicle security device 144). In some embodiments, controller/user interface/wireless communications module 112/113/120 may alternatively be integrated on and/or within a handlebar enclosure 313, as shown.

[47] In some embodiments, vehicle security device 144 may be implemented as a wheel lock configured to immobilize rear wheel 322 of transit vehicle 110b, such as by engaging pin 144b with spokes of rear wheel 322. In the embodiment shown in FIG. 3A, vehicle security device 144 may be implemented as a cable lock configured to engage with a pin latch on a docking station, for example, or to wrap around and/or through a secure pole, fence, or bicycle rack and engage with pin latch 144c. In various embodiments, vehicle security device 144 may be configured to immobilize transit vehicle 110b by default, thereby requiring a user to transmit a request to management system 240 (e.g., via user device 130) to reserve transit vehicle 110b before attempting to use transit vehicle 110b. The request may identify transit vehicle 110b based on an identifier (e.g., a QR code, a barcode, a serial number, etc.) presented on transit vehicle 110b (e.g., such as by user interface 113 on a rear fender of transit vehicle 110b). Once the request is approved, management system 240 may transmit an unlock signal to transit vehicle 110b (e.g., via network 250). Upon receiving the unlock signal, transit vehicle 110b (e.g., controller 112 of transit vehicle 110b) may release vehicle security device 144 and unlock rear wheel 322 of transit vehicle 110b.

[48] Transit vehicle 110c of FIG. 3B may correspond to a motorized sit-scooter integrated with the various elements of system 100 and may be configured to participate in dynamic transportation matching system 200 of FIG. 2. As shown in FIG. 3B, transit vehicle 110c includes many of the same elements as those discussed with respect to transit vehicle 110b of FIG. 3A. For example, transit vehicle 110c may include user interface 113, propulsion system 122, battery 124, controller/wireless communications module/cockpit enclosure 112/120/312, user storage 146 (e.g., implemented as a storage recess), and operator safety measures 142a and 142b, which may be implemented as various types of headlights, programmable light strips, and/or reflective strips.

[49] Transit vehicle HOd of FIG. 3C may correspond to a motorized stand or kick scooter integrated with the various elements of system 100 and may be configured to participate in dynamic transportation matching system 200 of FIG. 2. As shown in FIG. 3C, transit vehicle HOd includes many of the same elements as those discussed with respect to transit vehicle 110b of FIG. 3A. For example, transit vehicle 1 lOd may include user interface 113, propulsion system 122, battery 124, controller/wireless communications module/cockpit enclosure 112/120/312, and operator safety measures 140, which may be implemented as various types programmable light strips and/or reflective strips, as shown.

[50] FIG. 3D illustrates a diagram of a group of docking stations 300 for docking one or more mobility transit vehicles. As shown, the group of docking stations 300 may include multiple bicycle docks, such as docking stations 302a-e. In this example, a single transit vehicle (e.g., any one of electric bicycles 304a-d) may dock in each of the docking stations 302a-e of the group of docking stations 300. Each of the docking stations 302a-e may include a lock mechanism for receiving and locking docking mechanism 140 of the electric bicycles 304a-d. In some embodiments, once a transit vehicle is docked in a bicycle dock, the dock may be electronically coupled to the transit vehicle (e.g., controllers 312a-d of the transit vehicle) via a link such that the transit vehicle and the dock may communicate with each other via the link.

[51] A user may use a user device (e.g., user device 130) to use a mobility transit vehicle HOb-d that is docked in one of the bicycle docking stations 302a-e by transmitting a request to management system 240. Once the request is processed, management system 240 may transmit an unlock signal to a mobility transit vehicle 1 lOb-d docked in the docking station and/or the docking station via network 250. The docking station 300 may automatically unlock the lock mechanism to release the mobility transit vehicle 1 lOb-d based on the unlock signal. In some embodiments, each of the docking stations 302a-e may also be configured to charge batteries (e.g., batteries 324a- c) of the electric bicycle 304a-d, respectively, when the electric bicycle 304a-d are docked at the docking stations 302a-e. In some embodiments, each docking station of the group of docking stations 300 may also be configured to transmit information associated with the respective docking station 300 (e.g., a number of transit vehicles docked at the docking station 300, charge statuses of the docked transit vehicles, a time when a transit vehicle is docked or undocked from the docking station 300, detected nearby but undocked transit vehicles, etc.) to the management system 240.

[52] In particular embodiments, the management system 240 may provide riders with approximate waiting times for available docks at the group of docking stations 300 at a particular location and/or route riders to other nearby group of docking stations 300 at another location based on the demand for use of the group of docking stations 300 at the particular location to terminate a rider’s rental of a mobility vehicle. In the mobility vehicle (e.g., bikes, scooters, etc.) sharing context, one problem riders encounter may be arriving at a destination station but finding that all of the docking stations at the group of docking stations 300 at the destination are full (e.g., unavailable). For certain mobility vehicles, the vehicle must be docked with an appropriate docking station 300 to terminate the rider’s rental of the mobility vehicle and avoid extraneous charges and free up the mobility vehicle for use by another rider. When no docks are available at a rider’s preferred destination or the group of docking stations 300, a rider may scramble to find other available docking stations nearby or wait at the current docking station not knowing when the next dock will be available. The management system 240 may solve this problem by obtaining and determining historical data and/or real-time data regarding the outflow of mobility vehicles (e.g., mobility vehicles rented from a particular docking station or a particular group of docking stations 300) and inflow of mobility vehicle (e.g., mobility vehicles received at a particular docking station or a particular group of docking stations 300 to terminate a ride) monitored over time in the geographic region. The management system 240 may also obtain and determine historical data and/or real-time data regarding the inflow and outflow of mobility vehicles at other docking stations in the geographic region. The management system 240 may also obtain and determine historical data and real-time data of other variables (e.g., schedule of special events, weather data, traffic data, number of people coming into and out of the vicinity of the particular docking station, etc.) and the inflow and outflow of other vehicles within the vicinity of the particular docking station. For example, if the particular docking station is located within a subway station, the management system 240 may utilize information related to the number of passengers exiting a subway car into a subway station to determine inflow within the vicinity of the particular docking station so as to forecast a flow rate. In particular embodiments, the management system 240 may also use the historical data and real-time data of other variables to improve a machine-learning model trained to estimate waiting time of next available or open dock. Together, in some embodiments, the inflow and/or outflow of a docking station 300 may be referred to as the docking station’s 300 “flow rate.” Based on the flow rate, the management system 240 may forecast the flow rate of a docking station 300 at a particular, future time of interest (e.g., Sunday afternoon; expected arrival time of a rider), determine current ridership data (e.g., number of ride requests around the region), and use the forecasted flow rate and/or the current ridership data to enable a variety of features for riders. These features may include estimated waiting time of next available dock at the docking station 300 or nearby docking stations 300, a station “busy-ness” indicator which estimates how busy a station 300 is or will be at a selected time, pre-trip routing for which predicted dock availability is used by a route planner as an additional factor to select an optimal route for a rider, or pre- or mid-trip full dock warning to warn a rider about the likelihood of the destination docking station 300 filling up before or during the rider’s departure or arrival. In some embodiments, the inflow and outflow of a geographic region including multiple docking stations may be referred to as the “flow rate” for the particular geographic region.

[53] In particular embodiments, a table maintained by the management system 240 in a database may capture and determine historical data about how many mobility vehicles are entering and leaving a docking station during selected time intervals (e.g., at given 30-minute windows). Table 1 is an example capturing historical data. Table 1 indicates that for this station “11010”, from Tuesday 10/19 10AM - 10:30AM, there were 3 bikes that left this docking station and 5 bikes that docked at this docking station.

Table 1. Historical data at docking station 11010.

[54] Although not illustrated here, a table may also be maintained by the management system 240 in a database to capture and determine historical data about the number of mobility vehicles entering and leaving a geographic region including multiple docking stations during selected time intervals.

[55] FIG. 4 illustrates an example flow diagram 400 for generating rider experience features based on docking station 300 flow rates. In particular embodiments, the management system 240 may access historical flow rates 410 for each individual docking station (e.g., 302a-e). According to one calculation, the historical flow rates 410 may measure the average number of mobility vehicles (e.g., bikes) arriving or leaving a docking station (e.g., 302a-e) divided by the number of minutes where a dock or mobility vehicle was available over a period of time (e.g., 30 minutes). For example, say we observed the following at Station A between 9:00am - 9:30am: Four rides leave and at least one bike was available for 20 minutes. Accordingly, the outflow rate is 4 bikes / 20 min = 0.20 bikes / min. As another example, eight rides arrive and at least one dock was available for 15 minutes. Accordingly, inflow rate = 8 bikes / 15 min = 0.53 bikes / min. Table 2 illustrates example flow rates for a station. Flow rate calculations can be segmented and filtered according to observed natural demarcations. For example, a docking station 300 may be near a large number of offices. The flow rate is expected to differ based on whether a given date is a weekday (e.g., when riders use the docking station 300 as a destination to arrive at their office and a start point when leaving their office) or a weekend day (e.g., when few riders use the docking station 300 as they do not need to go into their office). The management system 240 can also store separate inflow and outflow values to provide added granularity to the data and provide opportunity for further analysis. In particular embodiments, the historical flow rates 410 may also comprise flow rates for mobility vehicles at a group of docking stations, which may be calculated in similar manners as described above.

Table 2. Flow rates at station 11010.

[56] Next, historical flow rates and/or real-time flow rates over a historically significant period of time (e.g., previous week, 3 weeks, 3 months, etc.) may be used to determine future flow rate forecast 420. In particular embodiments, the future flow rate forecast 420 may be for both the dock stations and the mobility vehicles. The future flow rate forecast can be based on estimations of inflow and outflow rates for a given docking station (e.g., 302a-e), a group of docking stations 300 and/or a geographic region during a select time interval (e.g., 30-minute time interval) by using a weighted average. As defined herein, the geographic region may be an area greater than the group of docking stations, such as, a geographic region may include a plurality of groups of docking stations. In particular embodiments, the weighted average may account for system internal factors (e.g., supply availability, redistribution efforts, charging time requirements, routing decisions) and external factors (e.g., weather, recency, public events). For each docking station (e.g., 302a-e) and each time interval, we may have 4 separate estimates for inflow and outflow rates over the weekend and weekday. For example, for station A from 4:00pm - 4:30pm we may have weekend inflow rate = 0.40 bikes / min, weekend outflow rate = 0.20 bikes / min, weekday inflow rate =1.2 bikes / min, and weekday outflow rate = 0.3 bikes / min. In particular embodiments, to determine the future flow rate forecast of a first docking station at a first location, the management system 240 may use a historical flow rate and/or a real-time flow rate of a second docking station in the first location or a second location for the determination.

[57] In particular embodiments, the future flow rate forecast may be used to determine dock availability forecast 430, mobility vehicle availability forecast 440, and rider experience features 450. As an example and not by way of limitation, the management system 240 may process the future flow rate forecast 420 to calculate probabilities that docking stations (e.g., 302a- e) will be full or empty a short time into the future (e.g., to predict if a rider should wait for an available dock at a current docking location or ride to a nearby docking location to reach a currently available dock) or a longer time into the future (e.g., to recommend a rider to prepare the next morning to use a motor vehicle instead of a mobility vehicle). As another example and not by way of limitation, the management system 240 may process the future flow rate forecast 420 to calculate probabilities that a group of docking stations 300 at a particular location will have one or more mobility vehicles available when the rider arrives at the group of docking stations. In particular embodiments, the management system 240 may use the historical flow rates to determine whether or how to expand the capacity for a given docking location. For example, the management system 240 may determine that valet parking may be provided to riders. As another example, the management system 240 may determine that more docks are needed for a given docking location. As yet another example, the manage system 240 may determine types of docks that are needed for the docking location, e.g., 10 more docks for classic bikes (e.g., 110b), 2 more docks for electric bikes or sitting scooters (e.g., 110c), 5 more docks for kick scooters (e.g., 1 lOd), etc.

[58] In particular embodiments, the management system 240 may determine that a rider of a personal mobility vehicle (e.g., a bike or a scooter) needs to dock the personal mobility vehicle at a first docking station for the personal mobility vehicle based on historical ridership data and/or real-time ridership data associated with the rider, contextual data associated with the rider, or historical and real-time ridership data and contextual data for other riders (not the rider) in the geographic region. For example, the management system 240 may determine that a rider is approaching their stated destination or a destination commonly used by the rider. As another example, the management system 240 may receive a request from a client device of the rider or integrated into the mobility vehicle indicating that the rider desires to dock the mobility vehicle and terminate a ride. The management system 240 may identify a nearby docking location with an available dock compatible with the mobility vehicle and direct the rider to that docking location. In particular embodiments, the management system 240 may determine that the nearest docking location has no docks currently available.

[59] In particular embodiments, the management system 240 may receive, from a client device associated with a rider, a request to dock a personal mobility vehicle associated with the rider at a docking station in a particular location of a geographic region. The management system 240 may then calculate a predicted flow rate associated with at least one docking station in the particular location of the geographic region. The predicted flow rate may be based on a flow rate associated with the at least one docking station. In particular embodiments, the predicted flow rate may be based at least in part on an inflow rate associated with the at least one docking station or an outflow rate associated with the at least one docking station. The management system 240 may then determine a waiting time for an available docking station at the particular location based on the predicted flow rate and/or other real-time/historical variables. As an example and not by way of limitation, other real-time/historical variables may comprise traffic patterns, weather, specific events nearby, nearby usage of applications for requesting mobility vehicles, etc. The management system 240 may further send, to a client device (e.g., a smart phone or a device integrated with the mobility vehicle) associated with the rider, instructions for presenting the waiting time to the rider.

[60] In particular embodiments, the flow rate may be further based on at least one of (i) a historical flow rate associated with the at least one docking station, (ii) one or more additional docking stations at the particular location, (iii) a historical flow rate associated with one or more additional docking stations at another location of the geographic region, or (iv) a historical flow rate associated with mobility vehicles to and from the at least one docking station.

[61] In particular embodiments, the management system 240 may determine the rider needs to dock the personal mobility vehicle at the first docking station (e.g., 302a-e) based on one or more of historical ridership data associated with the rider, real-time ridership data associated with the rider, contextual data associated with the rider, or historical and/or real-time ridership data and contextual data for other riders (not the rider) in the geographic region. For example, the historical ridership data may comprise the last five to ten trips of the rider, which may indicate the rider’s routes, commonly used docking station, etc. As another example, the contextual data may comprise time of day, the starting location of the ride, current location of the rider, destination provided by the rider, current weather, GPS signals associated with the client device (e.g., smart phone), GPS signals associated with the mobility vehicle (e.g., a scooter or an electric bike may have GPS), etc. In particular embodiments, determining the waiting time may be further based on contextual data associated with the rider. In some examples, historical ridership data for other riders in the geographic region may be used where there is insufficient historical ridership data for the rider. [62] In particular embodiments, the management system 240 may use different methods to calculate the estimated waiting time for the next available/open dock. The calculation may be based on the estimated flow rates for a given docking station, time of day, and weekday or weekend, etc. In one embodiment, the management system 240 may use a statistical approach to calculate the estimated waiting time. For example, the management system 240 may use the Poisson point process based on the following formula: Next_open_dock_waiting_time = 1 / outflow rate +/- 2 min. When using such statistical approach, the management system 240 may follow certain rules. In particular embodiments, the management system 240 may account for negative lower bounds. For example, if the waiting time resulting from this formula is -1 min to 3 mins, the management system 240 may push this waiting time to be 0 - 4 mins. This time may be displayed as less than 4 mins for the rider. Another rule may be having an upper bound (e.g., 10 mins). For example, the management system 240 may present the estimated waiting time as 10+ mins if the waiting time is more than 10 minutes. In particular embodiments, when the flow rate of a docking station 300 is 0, the management system 240 may modify the aforementioned formula to be 1/0.0001, which may result in the 10+ mins waiting time.

[63] In particular embodiments, the management system 240 may use a machinelearning model trained to estimate waiting time of next available or open dock. For example, the machine-learning model may be trained to account for real-time signals based on the current environment of the management system 240. Example real-time signals may include real-time demand at a given docking station, the real-time demand at one or more docking stations near a given docking station, the number of users within certain radius requesting mobility vehicles, the rider’s destination, current weather, time of day, nearby events, etc.

[64] In particular embodiments, the management system 240 may measure the efficacy of waiting time estimation. Measuring efficacy can allow the management system 240 to improve the estimation of waiting times based on real- world observations and feedback. Certain metrics for measuring efficacy can be observed, including business-orientated metrics such as ride retention and total rides. Other metrics can include, as example and not limitation, secondary metrics such as average dock intent resulting in successful dock time, accuracy of estimated waiting time, (e.g., measuring how often the dock became available within a predicted threshold), or waiting time retention (e.g., how often a rider waits for the next available dock versus looks for a nearby available dock). [65] FIGS. 5A-5B illustrate example user interface for showing estimated waiting time for the next available dock. FIG. 5A show a message 505 provided on a pin 510 corresponding to a destination docking station 510 that says 0 docks available or open right now and provided the estimated waiting time, which is given as 6-9 mins. FIG. 5A also shows the number of available/open docks 515a-i at nearby docking stations 520a-i. FIG. 5A shows docking stations 520a, 520e, 520f, 520g, and 520i with available/open docks in a first color and those 520b, 520c, 520d, and 520h with no available/open docks in a second color. To show multiple pins corresponding to multiple docking stations with estimated waiting time for available/open docks, the management system 240 may access flow rates for all the docking stations to be considered. For example, when a client device of a user (which is configured to disclose the user interface illustrated in FIG. 5A) requests an estimated wait time for a particular dock, the management system 240 can identify and determine an estimated wait time for nearby docks within a predetermined proximity, distance, or time to travel. Additionally or alternatively, the management system 240 can identity or determine an estimated wait time for nearby docks that are shown with the map interface displayed on the user interface.

[66] FIG. 5B shows a message in an information panel 525 corresponding to the docking station 530 that explains the estimated waiting time. The explanation of waiting time can further include status information for the docking station, including available docks for mobility vehicles of various types. In particular embodiments, the management system 240 may display both the message indicating available docks and the estimated waiting time and the message in the station panel explaining the estimated waiting time when the user is in ride. In particular embodiments, the management system 240 may further display whether valet docking is available at one or more of the docking stations near the user.

[67] While the rider is approaching the destination docking location or if the rider arrives at the destination docking location that is full, the management system 240 may redirect the rider to the closest docking location where they can dock the mobility vehicle. The management system 240 may determine to redirect the rider based on considering not just the current dock capacity of nearby docking location but also the forecasted availability of docks nearby. In particular, the forecasted availability can be based on the estimated time to travel to that docking location. In particular embodiments, the management system 240 may select one or more second docking stations 300 within a threshold distance of the at least one docking station based on predicted availabilities of the second docking stations. The predicted availabilities may be determined based on predicted flow rates associated with the second docking stations. The management system 240 may further send, to the client device, instructions for presenting the predicted availabilities of one or more of the second docking stations and a route to the one or more of the second docking stations.

[68] In particular embodiments, the management system 240 may receive an indication that a rider associated with a personal mobility vehicle is traveling to a destination. For example, the management system 240 may receive a request from a client device of the rider or integrated into the mobility vehicle indicating that the rider desires to dock the mobility vehicle near the destination and terminate a ride. As another example, the management system 240 may know the rider is going to the destination using the previously rented mobility vehicle based historical ridership data (e.g., the rider always went to the destination at a certain time using a mobility vehicle) and determine the rider needs to dock the mobility vehicle at the destination. The management system 240 may then determine one or more docking stations within a predetermined threshold distance of the destination for docking the personal mobility vehicle. For example, the threshold distance may be based on a radius from the destination. As another example, the threshold distance may be determined based on riding or walking time or other calculations for distance besides Euclidean distance. As yet another example, the threshold distance may be determined based on different weights for elevation, weather, or any other suitable factor. In particular embodiments, the management system 240 may access historical flow rates associated with each of the docking stations (e.g., from the database of the management system 240). Accordingly, the predicted flow rate associated with each of the docking stations may be calculated based on the historical flow rates associated with the docking station. In particular embodiments, each of the predicted flow rates may be based at least in part on an inflow rate associated with the docking station (e.g., rate of mobility vehicles being rented from this docking station) or an outflow rate associated with the docking station (e.g., rate of mobility vehicles being docked at this docking station to terminate a ride). The management system 240 may forecast the flow rate of a docking station at a particular time of interest (e.g., Sunday afternoon; expected arrival time of a rider), determine current ridership data (e.g., number of ride requests around the region), and use the forecasted flow rate and the current ridership data to enable a variety of features for riders. Based on a flow rate associated with the one or more docking stations at the destination, the management system 240 may calculate one or more probabilities of the one or more docking stations having an available docking station for the personal mobility vehicle upon the arrival of the rider at the destination, respectively. The management system 240 may select, based on the probabilities, a first docking station from the one or more docking stations (e.g., selecting the docking station with the best dock availability) for docking the personal mobility vehicle. The management system 240 may further send, to a client device (e.g., a smart phone or a device integrated with the mobility vehicle) associated with the rider, instructions for routing the rider to the first docking station.

[69] In particular embodiments, the management system 240 may determine the rider needs to dock the personal mobility vehicle at the destination based on one or more of real-time ridership data associated with the rider, contextual data associated with the rider, or historical and real-time ridership data and contextual data for other riders (not the rider) in the geographic region. For example, the historical ridership data may comprise the last five to ten trips of the rider, which may indicate the rider’s routes, usually used docking station, etc. As another example, the contextual data may comprise time of day, the starting location of the ride, current location of the rider, current weather, GPS signals associated with the client device (e.g., smart phone), GPS signals associated with the mobility vehicle (e.g., a scooter or an electric bike may have GPS), etc. In particular embodiments, calculating the one or more probabilities of the one or more docking locations having an available dock for the personal mobility vehicle at the time of the rider’s arrival, respectively, may be further based on contextual data associated with the rider.

[70] In particular embodiments, the management system 240 may determine a level of activity associated with the particular location of the geographic region. The management system 240 may further send, to the client device, instructions for presenting a user interface element corresponding to the level of activity. For example, the level of activity may be presented as a “busy-ness” indicator. With the “busy-ness” indicator, the management system 240 may surface station- specific flow rate forecasts for each docking station directly for users along with current capacity to let riders make an informed decision about where they want to dock their mobility vehicles. The “busy-ness” indicator can provide an easy-to-read indicator to provide riders an at- a-glance understanding of the level of activity at or near a given docking station.

[71] In particular embodiments, the management system 240 may surface to riders the probability of successfully renting a mobility vehicle or finding an available/open dock at a particular docking location during certain time intervals. The management system 240 may also surface to the estimated number of available mobility vehicles during such time intervals. Such time intervals can include, by way of example and not limitation, if they started their journey now, if they started their journey at a specified time, at a particular arrival time, etc. The management system 240 can also surface the probability during their journey at the rider’s request or as a proactive alert (e.g., indicating that there is a low probability of a rider being able to dock their bike at a docking location and suggesting re-routing to a nearby docking location). Alternatively, the management system 240 may present a confidence rating instead of the probability (e.g., “high confidence you will get a bike”). In addition to probabilities, the management system 240 may additionally show the estimated waiting time for next available/open dock. In particular embodiments, the management system 240 may add these estimates to information panels with detailed station information while riders are in-ride to help them make a decision about whether to stay or find docks elsewhere. The management system 240 may determine the aforementioned probabilities based on one or more of real-time ridership data associated with the rider, contextual data associated with the rider, or historical and real-time ridership data and contextual data for other riders (not the rider) in the geographic region. FIG. 6 illustrates an example user interface for showing probabilities of station availability. The information panel 610 corresponding to the docking station 620 shows there are 10 open docks right now and that there is high likelihood of getting parking spot here (i.e., the docking station 620 at Wacker Dr & Washington St) at the rider’s arrival. The rider may set this docking station 620 as a destination and the management system 240 may then direct the rider to the docking station 620.

[72] In particular embodiments, the management system 240 may generate pre-trip or mid-trip warning of a full docking location (i.e., without any available docks) or a low probability of an available dock. If riders are on a trip or planning to start a guided trip, the management system 240 may, based on their destination, warn riders in real-time when the management system 240 determines that they may likely encounter a docking location without open docking stations when they arrive. In particular embodiments, the management system 240 may generate these warnings based on calculated probabilities compared to threshold values (e.g., if probability that dock will be full is greater than 90% then show warning). In alternative embodiments, the management system 240 may generate the warnings using heuristics based on flow rates (e.g., if inflow rate > 2 bikes / min and capacity < 2 dock; then show warning). In particular embodiments, the management system 240 may show pre-trip warnings as intervention panels and badges, e.g., via the user interface on the user’s client device such as smart phones, smart glasses, smart tablets, computer, etc. The mid-trip warnings may be served by push notifications. For example, the mobility vehicle may have a heads-up display where the warnings may be shown. The heads-up display may additionally show a list of options with other docking stations 300 having available/open docks. As another example, the mobility vehicle may play chimes or audio signals when warning the riders. As yet another example, the warnings may be presented via the rider’s smart phones via the user interface or audio signals (there may be phone holders on the mobility vehicles). In particular embodiments, if the management system 240 determines there isn’t any available dock near the rider’s destination before the rider’s trip, the management system 240 may suggest the rider take buses or use rideshare services. In particular embodiments, the management system 240 may determine the pre-trip or mid-trip warning based on one or more of real-time ridership data associated with the rider, contextual data associated with the rider, or historical and real-time ridership data and contextual data for other riders (not the rider) in the geographic region.

[73] In particular embodiments, the management system 240 may determine and present availability of a rider’s favorite docking location. The management system 240 may determine the rider’s favorite docking location (e.g., the one the rider regularly rides to) based on the historical ridership data associated with the rider. The management system 240 may proactively surface messages comprising dock availability of this docking location to the rider via the user interface. For example, the message may be “your home station is likely to have dock spots available if you leave now.” Alternatively, the management system 240 may just surface flow rate for that docking location. In particular embodiments, the management system 240 may determine the aforementioned availability based on one or more of real-time ridership data associated with the rider, contextual data associated with the rider, or historical and real-time ridership data and contextual data for other riders (not the rider) in the geographic region.

[74] In particular embodiments, the management system 240 may determine pre-trip routing based on station availability. The management system 240 may incorporate the forecasted flow rates into a routing system. Besides other variables, the routing system may use the forecasted flow rates holistically when selecting start or end docking stations for riders who are planning a trip. That is, what is the closest docking station to the rider’s destination which is currently available. In particular embodiments, the routing system may determine the routing based on station flow rates or the probability of availability to ensure the best route for the rider. For example, the routing system may automatically filter out docking stations as destinations for the route planning if they are forecasted to be unavailable at the time of arrival. In particular embodiments, the inflow rate and/or outflow rate associated with a docking location may be estimated from monitoring other modes of transportation nearby. For example, a number of passengers arriving on a train into a train station nearby may lead to a higher outflow rate as these passengers may rent mobility vehicles to continue their commute. As another example, a number of parking spots in a parking garage nearby that have been filled may also lead to a higher outflow rate as the drivers may rent mobility vehicles to continue their commute. In particular embodiment, the routing system may adapt the routing to include multiple transportation modes if needed. For example, the routing may include docking locations that are one bus stop away from the rider’s target destination. The routing instructions provided to the rider can include directing the rider to initiate a first segment of the route using a first transportation mode (e.g., bus) and completing the route using a second segment with a second transportation mode (e.g., bike).

[75] In particular embodiments, the management system 240 may allow riders to reserve docks at particular docking locations. In particular embodiments, the management system 240 may use the forecasted station availability or estimated waiting time for next available/open dock to determine when and how many docks may be reserved at a given time. For example, if a given docking location is full right now or the ratio between the inflow rate and outflow rate is high for the given docking location, the management system 240 may allow eligible riders to reserve docks in advance. The management system 240 may receive, at the client device, a request from the rider to reserve a dock at the first docking location. The management system 240 may then determine, based on a user profile associated with the rider, the rider is eligible for reserving the dock at the first docking location. The management system 240 may then determine that the predicted flow rate for the first docking location satisfies a criteria. The management system 240 may further reserve, responsive to the request, a dock at the first docking location for the rider.

[76] The embodiments disclosed herein may be additionally used for availability forecasts of mobility vehicles. The management system 240 may use the demand forecasts of a docking location and/or forecasts of mobility vehicles to generate information on availability of mobility vehicles for riders as they travel towards the docking location. In particular embodiments, the management system 240 may determine whether there will be a mobility vehicle available when a rider arrives. As an example and not by way of limitation, the management system 240 may process the future flow rate forecast 420 to calculate probabilities that a mobility vehicle will be available a short time into the future (e.g., to predict if a rider should wait for an available mobility vehicle at a current docking location or go to a nearby docking location for a currently available mobility vehicle) or a longer time into the future (e.g., to recommend a rider to prepare the next morning to use a motor vehicle instead of a mobility vehicle). In particular embodiments, the management system 240 may provide riders with approximate waiting times for available mobility vehicles at a first docking location and/or route riders to other nearby docking locations based on the demand for use of mobility vehicles at the first docking location.

[77] While the rider is approaching the destination docking location or if the rider arrives at the destination docking location that does not have any mobility vehicle available, the management system 240 may redirect the rider to the closest docking location where there are one or more available mobility transit vehicles. The management system 240 may determine to redirect the rider based on considering not just the current availability of mobility vehicles of nearby docking location but also the forecasted availability of mobility vehicles nearby. In particular, the forecasted availability can be based on the estimated time to travel to that docking location.

[78] In particular embodiments, the management system 240 may generate information on availability of different types of mobility transit vehicles for riders as they travel towards a docking location. The management system 240 may also calculate the probability of the availability of different types of mobility vehicles. As an example and not by way of limitation, the management system 240 may determine the types of mobility vehicles that are available at the docking location, e.g., more than 10 classic bikes (e.g., 110b) available with a probability of 0.8, more than 2 electric bikes or sitting scooters (e.g., 110c) available with a probability of 0.7, fewer than 5 kick scooters (e.g., 1 lOd) available with a probability of 0.9, etc.

[79] In particular embodiments, the management system 240 may generate pre-trip or mid-trip warning of a docking location without any available mobility vehicle or a low probability of an available mobility vehicle. If riders are on a trip or planning to start a guided trip, the management system 240 may, based on their destination, warn riders in real-time when the management system 240 determines that they may likely encounter an empty docking station when they arrive at the docking station. In particular embodiments, the management system 240 may generate these warnings based on calculated probabilities compared to threshold values (e.g., if probability that the docking location will be empty is greater than 90% then show warning). In alternative embodiments, the management system 240 may generate the warnings using heuristics based on flow rates (e.g., if outflow rate > 5 bikes / min and availability < 5 bikes; then show warning). The riders may be additionally provided with a list of options with other docking locations having available mobility vehicles.

[80] In particular embodiments, the management system 240 may determine and present availability of mobility vehicles at a rider’s favorite docking location and/or preferred location(s). The management system 240 may determine the rider’s favorite docking location (e.g., where the rider regularly rents mobility vehicles from) based on the historical ridership data associated with the rider. The management system 240 may proactively surface messages comprising vehicle availability of this docking location to the rider via the user interface. For example, the message may be “your home station is likely to have mobility vehicles available if you leave now.” Alternatively, the management system 240 may just surface flow rate for that docking location.

[81] In particular embodiments, the management system 240 may determine pre-trip routing based on vehicle availability. The management system 240 may incorporate the forecasted flow rates into a routing system. Besides other variables, the routing system may use the forecasted flow rates holistically when selecting start docking stations for riders who are planning a trip. That is, what is the closest docking location to the rider’s destination which currently has available mobility vehicles. In particular embodiments, the routing system may determine the routing based on station flow rates or the probability of vehicle availability to ensure the best route for the rider. For example, the routing system may automatically filter out docking stations as destinations for the route planning if they are forecasted to have no available mobility vehicles at the time of arrival.

[82] In particular embodiments, the management system 240 may allow riders to reserve mobility vehicles at particular docking locations. In particular embodiments, the management system 240 may use the forecasted station availability or estimated waiting time for next available mobility vehicle to determine when and how many mobility vehicles may be reserved at a given time. For example, if a given docking location only has five available mobility vehicles right now or the ratio between the outflow rate and inflow rate is high for the given docking location, the management system 240 may allow eligible riders to reserve mobility vehicles in advance.

[83] The embodiments disclosed may improve user experience with using mobility vehicles for their commute. When combining the waiting time estimation feature, the availability forecasting feature, or dock reservations, the rider experience may be improved to a greater extent. For example, a rider may be late for a meeting. When the rider sees a docking location the rider is biking to right outside the rider’s office is predicted to be full by the time the rider gets there, the rider may proactively reserve a dock. This may allow riders to more judiciously choose when to use reservations, improving their experience, and the availability of the system at large.

[84] In some embodiments, any combination of the historical data, the real-time data, contextual data, and/or other data described herein may be utilized to determine where to prioritize building new docking stations (e.g., new locations). In some embodiments, any combination of the historical data, the real-time data, contextual data, and/or other data described herein may be utilized to lock out (i.e., render unavailable) particular docking stations from use and unlock (i.e., render available) particular docking stations. For example, the transportation management system may be configured to utilize any of the monitored data described herein to determine there is a high inflow rate at a particular location (relative to average) and determine to unlock a larger number of docking stations at the particular location than on average to accommodate for the high inflow rate so that more bikes are available for use. Thereafter, the transportation management system may be configured to send instructions causing one or more docking stations at the particular location to lock bikes to the docking stations using their respective locking mechanism to accommodate for increased demand for bikes so as to provide a guarantee of a minimum number of bikes at the particular location. In another example, the transportation management system may be configured to utilize any of the monitored data described herein to determine there is a high outflow rate at a particular location (relative to average) and determine to unlock a larger number of docking stations at the particular location than on average to facilitate riders to unlock bikes at the docking stations by sending instructions to one or more docking stations.

[85] FIG. 7 illustrates an example method 700 for estimating waiting time for next available docking station. The method may begin at step 710, where the management system 240 may receive, from a client device associated with a rider, a request to dock a personal mobility vehicle associated with the rider at a docking station in a particular location of a geographic region. At step 720, the management system 240 may calculate a predicted flow rate associated with at least one docking station in the particular location of the geographic region, wherein the predicted flow rate is based on a flow rate associated with the at least one docking station. At step 730, the management system 240 may determine a waiting time for an available docking station at the particular location based on the predicted flow rate. At step 740, the management system 240 may send, to the client device associated with the rider, instructions for presenting the waiting time to the rider. Particular embodiments may repeat one or more steps of the method of FIG. 7, where appropriate. Although this disclosure describes and illustrates particular steps of the method of FIG. 7 as occurring in a particular order, this disclosure contemplates any suitable steps of the method of FIG. 7 occurring in any suitable order. Moreover, although this disclosure describes and illustrates an example method for estimating waiting time for next available docking station including the particular steps of the method of FIG. 7, this disclosure contemplates any suitable method for estimating waiting time for next available docking station including any suitable steps, which may include all, some, or none of the steps of the method of FIG. 7, where appropriate. Furthermore, although this disclosure describes and illustrates particular components, devices, or systems carrying out particular steps of the method of FIG. 7, this disclosure contemplates any suitable combination of any suitable components, devices, or systems carrying out any suitable steps of the method of FIG. 7.

[86] FIG. 8 illustrates an example method 800 for pre-trip routing based on station availability. The method may begin at step 810, where the management system 240 may receive an indication that a rider associated with a personal mobility vehicle is traveling to a destination. At step 820, the management system 240 may determine one or more docking stations within a predetermined threshold distance of the destination for docking the personal mobility vehicle. At step 830, the management system 240 may, based on a flow rate associated with the one or more docking stations, calculating one or more respective probabilities that the one or more docking stations are available for docking the personal mobility vehicle upon the arrival of the rider at the destination. At step 840, the management system 240 may select, based on the one or more probabilities, a first docking station from the one or more docking stations for docking the personal mobility vehicle. At step 850, the management system 240 may send, to a client device associated with the rider, instructions for routing the rider to the first docking station. Particular embodiments may repeat one or more steps of the method of FIG. 8, where appropriate. Although this disclosure describes and illustrates particular steps of the method of FIG. 8 as occurring in a particular order, this disclosure contemplates any suitable steps of the method of FIG. 8 occurring in any suitable order. Moreover, although this disclosure describes and illustrates an example method for pre-trip routing based on station availability including the particular steps of the method of FIG. 8, this disclosure contemplates any suitable method for pre-trip routing based on station availability including any suitable steps, which may include all, some, or none of the steps of the method of FIG. 8, where appropriate. Furthermore, although this disclosure describes and illustrates particular components, devices, or systems carrying out particular steps of the method of FIG. 8, this disclosure contemplates any suitable combination of any suitable components, devices, or systems carrying out any suitable steps of the method of FIG. 8.

[87] FIG. 9 illustrates an example method 900 for reserving an available docking station. The method may begin at step 910, where the management system 240 may receive an indication that a rider associated with a personal mobility vehicle is traveling to a destination. At step 920, the management system 240 may estimate an arrival time of the rider to the destination. At step 930, the management system 240 may, based upon predicted probabilities using a flow rate associated with at least one docking station associated with the destination, determine that one or more docking stations within a threshold distance of the destination and during the estimated arrival time will be available for docking the personal mobility vehicle. At step 940, the management system 240 may select a first docking station from the determined one or more docking stations that is to be reserved for the rider. At step 950, the management system 240 may reserve the first docking station for the rider upon the estimated arrival time of the rider. Particular embodiments may repeat one or more steps of the method of FIG. 9, where appropriate. Although this disclosure describes and illustrates particular steps of the method of FIG. 9 as occurring in a particular order, this disclosure contemplates any suitable steps of the method of FIG. 9 occurring in any suitable order. Moreover, although this disclosure describes and illustrates an example method for reserving an available docking station including the particular steps of the method of FIG. 9, this disclosure contemplates any suitable method for reserving an available docking station including any suitable steps, which may include all, some, or none of the steps of the method of FIG. 9, where appropriate. Furthermore, although this disclosure describes and illustrates particular components, devices, or systems carrying out particular steps of the method of FIG. 9, this disclosure contemplates any suitable combination of any suitable components, devices, or systems carrying out any suitable steps of the method of FIG. 9.

[88] FIG. 10 illustrates an example method 1000 for forecasting availabilities of mobility vehicles. The method may begin at step 1010, where the management system 240 may receive an indication that a rider is traveling to a destination. At step 1020, the management system 240 may determine one or more docking locations within a predetermined threshold distance of the destination for renting a mobility vehicle from. At step 1030, the management system 240 may, based on one or more of a respective flow rate associated with each of the one or more docking locations at the destination or a respective flow rate of mobility vehicles to or from the destination, calculate one or more probabilities of the one or more docking locations having an available mobility vehicle upon the arrival of the rider at the destination, respectively. At step 1040, the management system 240 may select, based on the one or more probabilities, a first docking location from the one or more docking locations for renting the mobility vehicle from. At step 1050, the management system 240 may send, to a client device associated with the rider, instructions for routing the rider to the first docking location. Particular embodiments may repeat one or more steps of the method of FIG. 10, where appropriate. Although this disclosure describes and illustrates particular steps of the method of FIG. 10 as occurring in a particular order, this disclosure contemplates any suitable steps of the method of FIG. 10 occurring in any suitable order. Moreover, although this disclosure describes and illustrates an example method for forecasting availabilities of mobility vehicles including the particular steps of the method of FIG. 10, this disclosure contemplates any suitable method for forecasting availabilities of mobility vehicles including any suitable steps, which may include all, some, or none of the steps of the method of FIG. 10, where appropriate. Furthermore, although this disclosure describes and illustrates particular components, devices, or systems carrying out particular steps of the method of FIG. 10, this disclosure contemplates any suitable combination of any suitable components, devices, or systems carrying out any suitable steps of the method of FIG. 10.

[89] FIG. 11 illustrates an example computer system 1100. In particular embodiments, one or more computer systems 1100 perform one or more steps of one or more methods described or illustrated herein. In particular embodiments, one or more computer systems 1100 provide the functionalities described or illustrated herein. In particular embodiments, software running on one or more computer systems 1100 performs one or more steps of one or more methods described or illustrated herein or provides the functionalities described or illustrated herein. Particular embodiments include one or more portions of one or more computer systems 1100. Herein, a reference to a computer system may encompass a computing device, and vice versa, where appropriate. Moreover, a reference to a computer system may encompass one or more computer systems, where appropriate. [90] This disclosure contemplates any suitable number of computer systems 1100. This disclosure contemplates computer system 1100 taking any suitable physical form. As example and not by way of limitation, computer system 1100 may be an embedded computer system, a system- on-chip (SOC), a single-board computer system (SBC) (such as, for example, a computer-on- module (COM) or system-on-module (SOM)), a desktop computer system, a laptop or notebook computer system, an interactive kiosk, a mainframe, a mesh of computer systems, a mobile telephone, a personal digital assistant (PDA), a server, a tablet computer system, an augmented/virtual reality device, or a combination of two or more of these. Where appropriate, computer system 1100 may include one or more computer systems 1100; be unitary or distributed; span multiple locations; span multiple machines; span multiple data centers; or reside in a cloud, which may include one or more cloud components in one or more networks. Where appropriate, one or more computer systems 1100 may perform without substantial spatial or temporal limitation one or more steps of one or more methods described or illustrated herein. As an example and not by way of limitation, one or more computer systems 1100 may perform in real time or in batch mode one or more steps of one or more methods described or illustrated herein. One or more computer systems 1100 may perform at different times or at different locations one or more steps of one or more methods described or illustrated herein, where appropriate.

[91] In particular embodiments, computer system 1100 includes a processor 1102, memory 1104, storage 1106, an input/output (I/O) interface 1108, a communication interface 1110, and a bus 1112. Although this disclosure describes and illustrates a particular computer system having a particular number of particular components in a particular arrangement, this disclosure contemplates any suitable computer system having any suitable number of any suitable components in any suitable arrangement.

[92] In particular embodiments, processor 1102 includes hardware for executing instructions, such as those making up a computer program. As an example and not by way of limitation, to execute instructions, processor 1102 may retrieve (or fetch) the instructions from an internal register, an internal cache, memory 1104, or storage 1106; decode and execute them; and then write one or more results to an internal register, an internal cache, memory 1104, or storage 1106. In particular embodiments, processor 1102 may include one or more internal caches for data, instructions, or addresses. This disclosure contemplates processor 1102 including any suitable number of any suitable internal caches, where appropriate. As an example and not by way of limitation, processor 1102 may include one or more instruction caches, one or more data caches, and one or more translation lookaside buffers (TLBs). Instructions in the instruction caches may be copies of instructions in memory 1104 or storage 1106, and the instruction caches may speed up retrieval of those instructions by processor 1102. Data in the data caches may be copies of data in memory 1104 or storage 1106 that are to be operated on by computer instructions; the results of previous instructions executed by processor 1102 that are accessible to subsequent instructions or for writing to memory 1104 or storage 1106; or any other suitable data. The data caches may speed up read or write operations by processor 1102. The TLBs may speed up virtual-address translation for processor 1102. In particular embodiments, processor 1102 may include one or more internal registers for data, instructions, or addresses. This disclosure contemplates processor 1102 including any suitable number of any suitable internal registers, where appropriate. Where appropriate, processor 1102 may include one or more arithmetic logic units (ALUs), be a multicore processor, or include one or more processors 1102. Although this disclosure describes and illustrates a particular processor, this disclosure contemplates any suitable processor.

[93] In particular embodiments, memory 1104 includes main memory for storing instructions for processor 1102 to execute or data for processor 1102 to operate on. As an example and not by way of limitation, computer system 1100 may load instructions from storage 1106 or another source (such as another computer system 1100) to memory 1104. Processor 1102 may then load the instructions from memory 1104 to an internal register or internal cache. To execute the instructions, processor 1102 may retrieve the instructions from the internal register or internal cache and decode them. During or after execution of the instructions, processor 1102 may write one or more results (which may be intermediate or final results) to the internal register or internal cache. Processor 1102 may then write one or more of those results to memory 1104. In particular embodiments, processor 1102 executes only instructions in one or more internal registers or internal caches or in memory 1104 (as opposed to storage 1106 or elsewhere) and operates only on data in one or more internal registers or internal caches or in memory 1104 (as opposed to storage 1106 or elsewhere). One or more memory buses (which may each include an address bus and a data bus) may couple processor 1102 to memory 1104. Bus 1112 may include one or more memory buses, as described in further detail below. In particular embodiments, one or more memory management units (MMUs) reside between processor 1102 and memory 1104 and facilitate accesses to memory 1104 requested by processor 1102. In particular embodiments, memory 1104 includes random access memory (RAM). This RAM may be volatile memory, where appropriate. Where appropriate, this RAM may be dynamic RAM (DRAM) or static RAM (SRAM). Moreover, where appropriate, this RAM may be single-ported or multi-ported RAM. This disclosure contemplates any suitable RAM. Memory 1104 may include one or more memories 1104, where appropriate. Although this disclosure describes and illustrates particular memory, this disclosure contemplates any suitable memory.

[94] In particular embodiments, storage 1106 includes mass storage for data or instructions. As an example and not by way of limitation, storage 1106 may include a hard disk drive (HDD), a floppy disk drive, flash memory, an optical disc, a magneto-optical disc, magnetic tape, or a Universal Serial Bus (USB) drive or a combination of two or more of these. Storage 1106 may include removable or non-removable (or fixed) media, where appropriate. Storage 1106 may be internal or external to computer system 1100, where appropriate. In particular embodiments, storage 1106 is non-volatile, solid-state memory. In particular embodiments, storage 1106 includes read-only memory (ROM). Where appropriate, this ROM may be maskprogrammed ROM, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), electrically alterable ROM (EAROM), or flash memory or a combination of two or more of these. This disclosure contemplates mass storage 1106 taking any suitable physical form. Storage 1106 may include one or more storage control units facilitating communication between processor 1102 and storage 1106, where appropriate. Where appropriate, storage 1106 may include one or more storages 1106. Although this disclosure describes and illustrates particular storage, this disclosure contemplates any suitable storage.

[95] In particular embodiments, RO interface 1108 includes hardware, software, or both, providing one or more interfaces for communication between computer system 1100 and one or more RO devices. Computer system 1100 may include one or more of these RO devices, where appropriate. One or more of these RO devices may enable communication between a person and computer system 1100. As an example and not by way of limitation, an RO device may include a keyboard, keypad, microphone, monitor, mouse, printer, scanner, speaker, still camera, stylus, tablet, touch screen, trackball, video camera, another suitable RO device or a combination of two or more of these. An RO device may include one or more sensors. This disclosure contemplates any suitable RO devices and any suitable RO interfaces 1108 for them. Where appropriate, RO interface 1108 may include one or more device or software drivers enabling processor 1102 to drive one or more of these I/O devices. I/O interface 1108 may include one or more I/O interfaces 1108, where appropriate. Although this disclosure describes and illustrates a particular I/O interface, this disclosure contemplates any suitable I/O interface.

[96] In particular embodiments, communication interface 1110 includes hardware, software, or both providing one or more interfaces for communication (such as, for example, packet-based communication) between computer system 1100 and one or more other computer systems 1100 or one or more networks. As an example and not by way of limitation, communication interface 1110 may include a network interface controller (NIC) or network adapter for communicating with an Ethernet or any other wire-based network or a wireless NIC (WNIC) or wireless adapter for communicating with a wireless network, such as a WI-FI network. This disclosure contemplates any suitable network and any suitable communication interface 1110 for it. As an example and not by way of limitation, computer system 1100 may communicate with an ad hoc network, a personal area network (PAN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), or one or more portions of the Internet or a combination of two or more of these. One or more portions of one or more of these networks may be wired or wireless. As an example, computer system 1100 may communicate with a wireless PAN (WPAN) (such as, for example, a Bluetooth WPAN), a WI-FI network, a WLMAX network, a cellular telephone network (such as, for example, a Global System for Mobile Communications (GSM) network), or any other suitable wireless network or a combination of two or more of these. Computer system 1100 may include any suitable communication interface 1110 for any of these networks, where appropriate. Communication interface 1110 may include one or more communication interfaces 1110, where appropriate. Although this disclosure describes and illustrates a particular communication interface, this disclosure contemplates any suitable communication interface.

[97] In particular embodiments, bus 1112 includes hardware, software, or both coupling components of computer system 1100 to each other. As an example and not by way of limitation, bus 1112 may include an Accelerated Graphics Port (AGP) or any other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a front- side bus (FSB), a HYPERTRANSPORT (HT) interconnect, an Industry Standard Architecture (ISA) bus, an INFINIBAND interconnect, a low- pin-count (LPC) bus, a memory bus, a Micro Channel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCIe) bus, a serial advanced technology attachment (SATA) bus, a Video Electronics Standards Association local (VLB) bus, or another suitable bus or a combination of two or more of these. Bus 1112 may include one or more buses 1112, where appropriate. Although this disclosure describes and illustrates a particular bus, this disclosure contemplates any suitable bus or interconnect.

[98] Herein, a computer-readable non-transitory storage medium or media may include one or more semiconductor-based or other types of integrated circuits (ICs) (such, as for example, field-programmable gate arrays (FPGAs) or application-specific ICs (ASICs)), hard disk drives (HDDs), hybrid hard drives (HHDs), optical discs, optical disc drives (ODDs), magneto-optical discs, magneto-optical drives, floppy diskettes, floppy disk drives (FDDs), magnetic tapes, solid- state drives (SSDs), RAM-drives, SECURE DIGITAL cards or drives, any other suitable computer-readable non-transitory storage media, or any suitable combination of two or more of these, where appropriate. A computer-readable non-transitory storage medium may be volatile, non-volatile, or a combination of volatile and non-volatile, where appropriate.

[99] Herein, “or” is inclusive and not exclusive, unless expressly indicated otherwise or indicated otherwise by context. Therefore, herein, “A or B” means “A, B, or both,” unless expressly indicated otherwise or indicated otherwise by context. Moreover, “and” is both joint and several, unless expressly indicated otherwise or indicated otherwise by context. Therefore, herein, “A and B” means “A and B, jointly or severally,” unless expressly indicated otherwise or indicated otherwise by context.

[100] The scope of this disclosure encompasses all changes, substitutions, variations, alterations, and modifications to the example embodiments described or illustrated herein that a person having ordinary skill in the art would comprehend. The scope of this disclosure is not limited to the example embodiments described or illustrated herein. Moreover, although this disclosure describes and illustrates respective embodiments herein as including particular components, elements, feature, functions, operations, or steps, any of these embodiments may include any combination or permutation of any of the components, elements, features, functions, operations, or steps described or illustrated anywhere herein that a person having ordinary skill in the art would comprehend. Furthermore, reference in the appended claims to an apparatus or system or a component of an apparatus or system being adapted to, arranged to, capable of, configured to, enabled to, operable to, or operative to perform a particular function encompasses that apparatus, system, component, whether or not it or that particular function is activated, turned on, or unlocked, as long as that apparatus, system, or component is so adapted, arranged, capable, configured, enabled, operable, or operative. Additionally, although this disclosure describes or illustrates particular embodiments as providing particular advantages, particular embodiments may provide none, some, or all of these advantages.