ACTIVITY LEVEL-BASED MANAGEMENT AND DATA LOADING FOR MONITORING THE ROUTES OF A MOBILITY SERVICE PROVIDER

Abstract

A system and method for monitoring vehicle trips is disclosed, in which a driver picks up a customer at a pickup location and drives the customer to a drop-off destination. The system includes at least one sensor installed in the vehicle and configured to capture sensor data during trips, a transceiver configured to communicate with a driver's personal electronic device, non-volatile memory configured to store data, and a processor. The system captures sensor data during a trip, determines an activity index indicating the level of activity within the vehicle during the trip, and stores the captured sensor data with the activity index as metadata. In response to an upload request, the system uploads sensor data based on the activity level.

Description

The device and method disclosed in this document refer to in-vehicle monitoring and, more specifically, to the management based on activity level and data load of route monitoring of the routes of a mobility service provider. BACKGROUND OF THE INVENTION Unless otherwise stated herein, the materials described in this section are not admitted as prior art by inclusion in this section. Mobility service providers will play an increasingly important role in transportation as fewer people own their own vehicles and rely more on on-demand mobility services for their transportation needs. Some mobility service providers, such as taxi and ride-sharing services, facilitate transactions between strangers where a customer requests a ride using a smartphone app or other means, and a driver picks up the customer and transports them to a desired destination in exchange for a fare. Naturally, there are times when disputes arise between the customer and the driver, or between customers during the ride, or when some other unusual event occurs. Therefore, it would be beneficial to provide a system for monitoring rides provided by such mobility service providers.Additionally, it would be desirable if the monitoring maintained the privacy of drivers and customers as much as possible, particularly for most trips where no dispute or other anomalous event occurs. BRIEF DESCRIPTION OF THE INVENTION A system for monitoring vehicle trips is disclosed. The system comprises at least one sensor installed in the vehicle and configured to capture sensor data during trips. The system also comprises non-volatile memory configured to store data. The system further comprises a processor operatively connected to at least one sensor and the memory. The processor is configured to receive sensor data from at least one sensor captured during a trip in which the driver picks up a customer at a pickup location and drives the customer to a drop-off destination. The processor is further configured to determine an activity index indicating a level of activity within the vehicle during the trip based on the sensor data captured during the trip.The processor is also configured to store, in non-volatile memory, the sensor data captured during the journey, with the activity index being stored in metadata of the sensor data captured during the journey. A method for monitoring vehicle journeys is disclosed. The method comprises capturing, with at least one sensor installed in the vehicle, sensor data during a journey in which a vehicle driver picks up a customer at a pickup location and drives the customer to a drop-off destination. The method further comprises determining an activity index that indicates the level of activity within the vehicle during the journey based on the sensor data captured during the journey. The method further comprises storing the sensor data captured during the journey in non-volatile memory, with the activity index being stored in the metadata of the sensor data captured during the journey. BRIEF DESCRIPTION OF THE FIGURES The above aspects and other features of the system and methods are explained in the following description, taken in connection with the accompanying drawings. FIGURE 1 shows a system for monitoring journeys provided by a mobility service provider using a vehicle. FIGURE 2 shows exemplary hardware components of the monitoring device. FIGURE 3A shows exemplary hardware components of the cloud storage backend server. FIGURE 3B shows exemplary hardware components of the personal electronic device. FIGURE 4 shows a method for operating the monitoring device to monitor a journey in which a vehicle driver picks up a customer at a pickup location and drives the customer to a drop-off destination. FIGURE 5 shows a data structure for each piece of route data stored by the monitoring device. FIGURE 6 shows a timeline including activity indices for an exemplary tour. FIGURE 7 shows a method for operating the monitoring device to upload one or more journey data fragments in response to a review request by the mobility service provider. DETAILED DESCRIPTION OF THE INVENTION For the purpose of promoting an understanding of the disclosure principles, reference will now be made to the embodiments illustrated in the drawings and described in the following written specification. It is understood that no limitation is intended to be placed on the scope of this disclosure. Furthermore, it is understood that this disclosure includes any alterations and modifications to the illustrated embodiments and includes additional applications of the disclosure principles as would normally occur to a person skilled in the art to whom this invention belongs. System overview Figure 1 shows an exemplary embodiment of a system 100 for monitoring trips provided by a mobility service provider using a vehicle 102. Non-limiting examples of such mobility service providers include Lyft™ and Uber™. The system 100 comprises a monitoring device 110 and a cloud storage backend server 120. The monitoring device 110 includes a plurality of sensors, including, for example, an exterior front-facing camera 112, an interior cabin-facing camera 114, and at least one interior microphone 116. The monitoring device 110 is configured to record sensor data during trips in the vehicle 102 and store the recorded data on a local storage device.In the event of a dispute or other anomalous event, the recorded data may be uploaded to the cloud storage backend server 120 for further review by an operator or administrator of the mobility service provider. In the illustrated embodiment of FIGURE 1, vehicle 102 is in the form of a car having a cabin 104, which is typically an enclosed room for accommodating passengers. In the illustrated embodiment, the cabin 104 includes four seats 106, including a driver's seat and multiple passenger seats. However, the cabin 104 may include a greater or lesser number of seats depending on the configuration and type of vehicle 102. Vehicle 102 also includes one or more doors (not shown) allowing passengers access to the cabin 104 and seats 106. Additionally, vehicle 102 may include a rear door (not shown) allowing a user access to a cargo storage area of ​​vehicle 102, such as a trunk or storage space behind the rear seats. The monitoring device 110 is accommodated within the cab 104 such that the interior camera 114 has a view of all or most of the seats 106 within the cab 104 and such that the exterior camera 112 has a view of the road ahead of the vehicle 102. In at least one embodiment, the monitoring device 110 is in the form of a conditioned device attached to a dashboard or windshield of the vehicle, and in which all or most of its components are contained within an integrated package. However, in alternative embodiments, the monitoring device 110 may be natively or otherwise integrated with the vehicle 102, and its components, for example, the sensors, may be distributed throughout the vehicle 102. System 100 is configured to operate in conjunction with a mobility service provider application running on a personal electronic device 130, such as a smartphone, in the possession of the vehicle driver 102. Non-limiting examples of similar mobility service provider applications include the “Lyft Driver” application by Lyft™ and the “Uber Driver” application by Uber™, which are available on many tablet and smartphone computing platforms. Such mobility service provider applications, for example, may allow the driver to receive ride requests initiated by prospective customers using a corresponding mobility service provider application 10 on a customer’s personal electronic device. Upon receiving a ride request, the driver may choose to perform the requested ride in exchange for a fare.Generally, each trip involves driving vehicle 102 to a pickup location where the customer is located, accepting the customer into vehicle 102, driving vehicle 102 to a desired drop-off destination, and stopping at the drop-off destination to allow the customer to disembark. Upon completion of the trip, the mobility service provider typically charges the customer a fare, a portion of which is given to the driver. During each trip, the monitoring device 110 is configured to record sensor data, including at least exterior video from the front-facing exterior camera 112, interior video from the interior camera facing the cab 114, and interior audio from the interior microphone 116. The monitoring device 110 is conveniently configured to annotate the recorded sensor data with useful metadata pertaining to each particular trip. As an example, the recorded sensor data can be stored with metadata that identifies the particular trip, the driver, and the customer, and with timestamps that identify a service request time, pickup time, and drop-off time.For this purpose, the monitoring device 110 is configured to communicate with the personal electronic device 130, in particular with the mobility service provider application on the personal electronic device 130, to obtain information regarding each particular journey provided by the driver using the mobility service provider application 30. Sensor data for each journey is stored in a local memory of the monitoring device 110. The sensor data is stored in one or more loop memories so that, as new sensor data corresponding to the latest journeys are recorded, the sensor data corresponding to the oldest journeys are deleted. In at least one mode, sensor data corresponding to a particular journey or a particular portion of a journey may be tagged for longer-term storage in a separate secure storage table if the data is expected to be of greater relevance for resolving disputes by the operator or administrator of the mobility service provider.Such data, for example, can be tagged for longer time storage by the monitoring device 110 with the help of an algorithm that processes the sensor data to determine an activity level within the cabin 104. Particular routes or particular portions of a route that have a high level of activity within the cabin 104 can be automatically tagged for longer time storage by the monitoring device 110. In limited circumstances, recorded sensor data is uploaded to the cloud storage backend server 120 for further review by a mobility service provider operator or administrator. Specifically, sensor data for a particular trip or a portion of a trip will only be uploaded to the cloud storage backend server 120 in response to a trigger event. Examples of trigger events include vehicle 102 being involved in an accident during the trip, a customer or driver requesting that sensor data be uploaded for the trip, a customer or driver submitting proof of the trip to the mobility service provider, and a request from the mobility service provider's backend server.In this way, most of the recorded sensor data is never uploaded to the cloud storage backend server 120 or made available for viewing by any party, thus improving the privacy of the monitoring device system 100. With reference to FIGURE 2, exemplary components of the monitoring device 110 are described. In the illustrated embodiment, the monitoring device 110 comprises at least one processor 200 and associated memories 202, 204. Additionally, the processor 200 is operatively connected to a plurality of sensors, a plurality of transceivers, a plurality of output devices, and a power supply. Those skilled in the art will recognize that a processor includes any hardware system, hardware mechanism, or hardware component that processes data, signals, or other information. Accordingly, the processor 200 may include a system with a central processing unit, graphics processing unit, multiple processing units, dedicated circuitry for achieving functionality, programmable logic, or other processing systems. In at least one configuration, the 200 processor takes the form of a system-on-a-chip (SoC) 200 that has at least one central processing unit (CPU), such as a quad-core ARM Cortex-A53 operating, for example, at 1 GHz. The SoC 200 may comprise dedicated processors or circuitry for video encoding, for example, h.264 and h.265, and for multiple resolution streams. Additionally, the SoC bCLfrnn / eznz / e / Yi The system-on-a-chip 200 may include processors or dedicated circuits for data encryption, such as Advanced Encryption Standard (AES), Triple DES (3DES or TDES) or Triple Data Encryption Algorithm (TDEA or Triple DEA), Secure Hash Algorithm 1 (SHA-1), and / or MD5 message digest algorithm. The system-on-a-chip 200 may include a variety of data and peripheral interfaces, such as Mobile Industry Processor Interface (MIPI), Serial Peripheral Interface (SPI), Inter-Integrated Circuit (I2C or I2C), Inter-IC Audio (I2S or I2S), Secure Digital Input / Output (SDIO), Dynamic Random Access Memory (DRAM), Universal Serial Bus (USB), and Universal Asynchronous Transmitter-Receiver (UART). Finally, the system-on-a-chip 200 may comprise a real-time clock (RTC) and a system clock (CLK), 10 generated, for example, by a 32.768 kHz crystal oscillator 206 and a 24 MHz crystal oscillator 208, respectively. Memories 202, 204 may be of any type of device capable of storing information accessible by the processor 200, such as a flash memory card, ROM, RAM, hard disks, disks, or any other various computer-readable media 15 serving as volatile or non-volatile data storage devices, as will be recognized by those skilled in the art. In particular, memories 202, 204 comprise at least one volatile memory 202 and one non-volatile memory 204. The volatile memory 202, for example, may comprise Low Power Double Data Rate Synchronous Dynamic Random Access Memory (LPDDR SDRAM), in particular LPDDR4, which connects to the processor 200 (for example, via a DRAM interface) and has a capacity of, for example, 512 MB.Non-volatile memory 204, for example, may comprise embedded Media Multimedia Card (eMMC) memory that connects to the processor 200 (for example, via SDIO) and has a capacity of, for example, 16 GB. The monitoring device 110 includes the previously discussed exterior camera 112 and interior camera 114, which are connected to the processor 200 (e.g., via MIPI). The exterior camera 112 and interior camera 114 are configured to capture video of the environment toward which they are oriented, namely the road in front of vehicle 102 and the interior of the cabin 104, respectively. Cameras 112 and 114 comprise image sensors 30 configured to capture video, for example, at a resolution of 1080p at 30 frames per second, at a resolution of 720p at 60 frames per second, or both. The captured video takes the form of a sequence of image frames, each of which comprises a two-dimensional array of pixels. Each pixel contains corresponding photometric information (i.e., intensity, color, and / or brightness). In one mode, the image sensor of the 35 outdoor 112 camera is an image sensor with an IR cut filter.In one configuration, the indoor camera's image sensor is an RGB image sensor with an IR bandpass filter bCLfrnn / eznz / e / Yi configured, for example, to pass infrared light having a wavelength corresponding to associated IR LEDs 210 and IR LED actuator 212 (for example, 850 nm). In one configuration, the outdoor camera 112 and the indoor camera 114 have, for example, image sensor sizes of 24.5 / 68.58 mm (1 / 2.7”) and 24.5 / 73.66 mm (1 / 2.9”), respectively. In one configuration, the outdoor camera 112 and the indoor camera 114 have, for example, lens fields of view of -140° and -150°, respectively. The monitoring device 110 includes at least the microphone 116, discussed earlier, which is connected to the processor 200 (for example, via I2S). The microphone 116 comprises any type of acoustic sensor configured to record sounds within the cabin 104. In at least one embodiment, the monitoring device 110 comprises at least two microphones 116 separated from each other for recording stereo audio from the cabin 104. In one embodiment, the microphones 116 take the form of Micro-Electro-Mechanical Systems (MEMS) microphones mounted directly on a printed circuit board of the processor and / or system-on-a-chip 200. In some configurations, the monitoring device 110 includes an inertial measurement unit (IMU) 214 that is connected to the processor 200 (for example, via SPI). The IMU 214 operates as an accelerometer and a gyroscope and may include a discrete accelerometer and a discrete gyroscope, or a single combined sensor that provides acceleration and gyroscopic measurements. The accelerometer, for example, may be a 16-bit digital triaxial accelerometer with ±16g and a data rate up to 1.6 kHz. The gyroscope, for example, may be a 16-bit digital triaxial gyroscope with up to ±2000 dps and a data rate up to 6.4 kHz. In one configuration, the IMU 214 also includes a built-in temperature sensor that is leveraged for thermal protection features. In some embodiments, the monitoring device 110 includes a cellular and Global Navigation Satellite System (GNSS) module 216 that is connected to the processor 200 (for example, via USB). The cellular and GNSS module 216 provides cellular connectivity and global position measurement for the monitoring device 110. However, separate modules for cellular and GNSS can be used similarly. The cellular and GNSS module 216 comprises a cellular transceiver including a cellular modem (for example, LTE Category 4), a main antenna 218, a diversity antenna 220, and a subscriber identification module (SIM) card 222, as well as any other processors, memories, oscillators, or other hardware conventionally included in a cellular module. In one embodiment, the cellular modem is configured to provide echo cancellation and noise reduction.The cellular and GNSS module 216 further comprises a GNSS receiver, a Low Noise Amplifier (LNA) & Surface Acoustic Wave (SAW) filter module 224, and a flexible antenna 226, as well as any other processors, memories, oscillators, or other hardware conventionally included in a GNSS module. In one mode, the GNSS receiver supports the GPS, GLONASS, BeiDou, and Galileo systems and provides location data with an accuracy of ±5 m. In one mode, the monitoring device 110 is configured to use sensor fusion (dead reckoning) of GNSS data with IMU data to improve location measurement quality in challenging GNSS reception scenarios and bridge GNSS reception gaps. In another mode, the monitoring device 110 provides dead reckoning GNSS location data to the personal electronic device 130 via Bluetooth, along with the measured vehicle speed and heading, and a device ID for the monitoring device 110. In some embodiments, the monitoring device 110 includes the Bluetooth module 228, which is connected to the processor 200 (for example, via UART). The Bluetooth module 228 comprises a Bluetooth transceiver and a Bluetooth antenna 230, as well as any other processors, memories, oscillators, or other hardware conventionally included in a Bluetooth module 15. In at least one embodiment, the Bluetooth module 228 uses the Bluetooth Low Energy (BLE) specification (for example, Bluetooth version 4.0 or later). In one embodiment, the Bluetooth antenna 230 is a PCB-mounted antenna. In some embodiments, the monitoring device 110 includes an LED actuator 232, which is connected to the processor 200 (for example, via I2C), which drives one or more lighting devices 234. The lighting devices 234 may include a plurality of LED status indicators configured to indicate a status, mode, or operation of the monitoring device 110, including a power indicator, a coupling indicator, and a logging indicator. Additionally, the lighting devices 234 may include an array of RGB LEDs and / or white LEDs configured to backlight a brand sign configured to display a trademark or logo of the mobility service provider (for example, in the form of a plastic lens). Alternatively, an LCD screen or equivalent display screen may be included to display any trademark, logo, or other information to customers or external pedestrians. In some embodiments, the monitoring device 110 includes a speaker driver 236, which is connected to the processor 200 (for example, via I2S), and which drives a corresponding speaker 238. In some embodiments, the monitoring device 110 includes a plurality of temperature sensors to ensure the safety of internal components. In particular, the monitoring device 110 monitors the temperature at multiple locations within the device and will safely shut down if its internal temperature 35 becomes too high. In at least one embodiment, the monitoring device 110 is provided with a protective outer housing or enclosure (not shown) designed to retain and protect the various sensors and other electronic components within the housing. The housing comprises any number of shapes, configurations, and / or materials. In one embodiment, the housing is configured to mate with a mount that is semi-permanently attached to a surface such as a dashboard or windshield of vehicle 102 to allow for retrofit installations. Alternatively, the housing itself may include some other mechanism, such as a suction cup or adhesive, for semi-permanent attachment. However, as noted above, in some embodiments, the monitoring device 110 may be natively or otherwise integrated with vehicle 102, and its components may be distributed throughout vehicle 102. Finally, the monitoring device 110 includes a power supply 240 that has convenient power electronics configured to provide the required output voltages for the various components of the monitoring device 110 (e.g., 4.2 Volts, 4.0 Volts, 3.3 Volts, 2.8 Volts, 1.8 Volts, 1.2 Volts, 1.1 Volts, 0.75 Volts, and 0.6 Volts). The power supply 240 is operatively connected to a battery 242 that has, for example, a capacity of 1000mAh, and includes convenient power electronics configured to draw power from the battery 242 as well as to charge the battery 242. Therefore, the power supply 240 is also configured to receive input power from a power source 244, such as a 12V vehicle accessory voltage. For this purpose, the 240 power supply can be connected directly to a vehicle cigarette lighter 102.However, in alternative configurations, the power supply 240 can be connected to a vehicle USB socket 102 or directly to a vehicle accessory voltage line. In one configuration, a vehicle power connection 102 is integrated with the mounting for the monitoring device 110, so that the monitoring device 110 only receives power from the vehicle 102 when attached to the mounting. The power supply 240 is operationally connected to a power switch 246 on the monitoring device and is configured to turn the monitoring device 110 on and off according to an activation or status of the power switch 246. The monitoring device 110 is configured to operate in a variety of different modes. In Normal Mode, the monitoring device 110 is connected for power via the mounting bracket and is paired with the mobility service provider's application on the personal electronic device 130. In some modes within Normal Mode, the sensors are active and recording data to the loop data memories, as discussed in more detail below. When the monitoring device 110 is not connected for power via the mounting bracket, it operates in one or more of the bCLfrnn / eznz / e / Yi modes. Battery Operation. Specifically, the 110 monitoring device does not operate in Normal Mode while using battery power. Battery operation modes are included to ensure data protection in the event of a power loss during an active trip. In some modes, in a Network Query Mode, the monitoring device The 110 operates using battery power and stands in an ultra-low power mode. In ultra-low power mode, the 110 monitoring device wakes up once per hour, checks the network for messages, and then powers down. The 110 monitoring device queries for a minimum amount of time (for example, 2 weeks) or until the battery drops below a specified charge level. In one mode, a staggered query period is used to balance battery life with cost and data availability. For example, the 110 monitoring device wakes up once per hour for a period of one week and then wakes up once per day for a period of one month. Network query periods can be adjusted to balance battery life with cost. In some modes, in Remote Wake-Up Mode, if the 110 monitoring device detects a network message indicating that it should wake up while in Network Query Mode, the 110 monitoring device powers on, performs the commanded action (for example, uploads requested trip data fragments, 20 with a maximum of 30 minutes of trip data fragments), and then powers off again. In this mode, the 110 monitoring device does not activate any sensors or LEDs and operates silently. In some modes, in a Last Breath Mode, if the power cable is unplugged during an active trip, the monitoring device 110 transitions to battery power, ends recording the current trip data fragment 25 (discussed in more detail below), stops recording from all sensors, notifies the cloud storage backend server 120, notifies the mobility service provider, uploads the last three trip data fragments, and safely shuts down. In some modes, in a Safe Shutdown Mode, if the power cable is unplugged while not on an active trip, the monitoring device transitions to battery power, ends recording the current trip data fragment, stops recording from all sensors, notifies the cloud storage backend server, and safely shuts down. In some configurations, in Installation Support Mode, the 35 monitoring device 110 facilitates driver installation with the appropriate camera fields of view, assisted by the mobility service provider's application. The bCLfrnn / cznz / e / Yi Installation Support Mode can be triggered via a cloud storage backend server 120 or the mobility service provider's application. The monitoring device 110 captures images from both the interior and exterior cameras and provides these images to the mobility service provider's application for viewing during the installation process. The mobility service provider's application or the monitoring device 110 provides installation feedback to assist the user in properly aligning the cameras. In some configurations, the 110 monitoring device is set up to receive over-the-air (OTA) updates. These updates come in two forms: Software Over-the-Air (SOTA), which targets the application layer of the 110 monitoring device to ensure operational features can be updated, and Firmware Over-the-Air (FOTA), which targets the lower-level software of the 110 monitoring device. The focus of these updates may be to address more critical software updates, such as those related to security measures within the software itself. The frequency and timing of these updates can vary throughout the device's lifecycle. SOTA / FOTA updates are protected to ensure their security and validity.In addition to being transmitted over a secure communication channel, updates are encrypted and signed, and the device will reject any unauthorized updates. Furthermore, rollback protection will prevent any older software versions that may lack patches or critical fixes from being loaded onto the device. In some configurations, the 110 monitoring device is designed to prevent local access to or removal of data from its path and includes security hardware and tamper detection features. Specifically, the 110 monitoring device is configured to support multiple layers of security to ensure that sensor data cannot leave the device locally, using a combination of hardware, software, and hardware-assisted software features. In one mode, the 110 monitoring device supports Secure Boot (also known as High Security Boot (HAB)) to ensure that only authorized software can run on the device, and establish a root-of-trust for the system. In one mode, the 110 monitoring device supports a Time-Programmable (OTP) key capability for secure boot key authentication, and the ability to backtrack and change even the most critical, lowest-level keys within the system. An OTP memory is used for a device serial number and some bCLfrnn / eznz / e / Yi keys that do not change during the device's lifetime. In one mode, the 110 monitoring device supports an OS integrity check to protect against any system search mirroring in the event of an intrusion. As part of a health diagnostic check, a device integrity check is performed to report the software version and device integrity on a routine basis, ensuring that the device is also reliable and operating as intended. In one mode, the 110 monitoring device supports secure storage via a Secure Execution Environment (TEE) file system for all certificates, and for the temporary storage of encryption keys and related material. The TEE protected operation is also used during system boot and for certain security-critical operations. TEE provides hardware-assisted protection and isolation from the rest of the operating system to make any penetration extremely difficult. In one mode, the 110 monitoring device supports hardware features such as Cryptographic Acceleration, which provides hardware-assisted acceleration for AES symmetric encryption of audio and video data. Similarly, the hardware provides support for RSA asymmetric encryption and SHA record lookup for Public Key Infrastructure (PKI) and related signature / certificate operations. Hardware-assisted encryption combined with specialized kernels enables high-performance audio and video capture and encryption as a tightly coupled operation, which can be protected at a process and policy level within the operating system. With sensitive private data encrypted as close to acquisition as possible, this dramatically reduces the opportunities for hacking attempts or software failures that could compromise data. In one mode, the 110 monitoring device uses a True Random Number Generator (TRNG) because a hardware feature provides the entropy that helps ensure that cryptographic keys are secure and resistant to any brute-force attacks. In one mode, the 110 monitoring device supports disabling debug interfaces (e.g., JTAG, USB, etc.) at a low level in the system to ensure that any attempt to dismantle a device will not reveal an interface that can be used to attack the system. In one mode, the 110 monitoring device supports DRAM encryption, protects system memory, and fortifies the system while in operation against attempts to eavesdrop and steal data, or as a method of side-channel attacks. The communication modules of the 110 monitoring device utilize similar security features (secure boot, programmable one-time keys) to ensure secure communication. In addition, Transport Layer Security (TLS) protocols, firewalls, and operating system policies are used to ensure that the modem communicates exclusively with the 120 cloud storage backend server and is resistant to any attempt by cybercriminals to use the network connection as an attack channel to penetrate the system. An internal Key Management System (KMS) closely controls key generation and injection during the manufacturing assembly. A high level of coordination between the cloud storage backend server 120 and the monitoring device manufacturing site 110 ensures that no keys are compromised on any of the devices. Similarly, access to the signing keys required to sign the software for uploading and execution on devices is rigorously controlled through smart cards and internal registration procedures. Cloud Storage Backend System With reference now to FIGURES 3A and 3B, exemplary components of the cloud storage backend server 120 and the personal electronic device 130 are described. It will be appreciated that the components of the cloud storage backend server 120 and the personal electronic device 130 shown and described here are merely exemplary and that the cloud storage backend server 120 and the personal electronic device 130 may comprise any alternative configuration. As shown in FIGURE 3A, the exemplary form of the cloud storage backend server 120 comprises one or more cloud servers 300 and one or more cloud storage devices 320. The cloud servers 300 may include servers configured to serve a variety of functions for the cloud storage backend server, including web servers or application servers, depending on the features provided by the cloud storage backend server 120, but at least include one or more database servers configured to manage journey data received from the monitoring device 110 and stored on the cloud storage devices 320. Each of the cloud servers 300 includes, for example, a processor 302, memory 304, a user interface 306, and a network communications module 308.It will be appreciated that the illustrated mode of the 300 cloud servers is only an exemplary mode of a 300 cloud server and is merely representative of any of the various ways or configurations of a personal computer, server, or any other data processing systems that are operative in the manner set forth herein. bCLfrnn / eznz / e / Yi The 302 processor is configured to execute instructions for operating the 300 cloud servers in order to enable the features, functionality, characteristics, and / or the like as described herein. To this end, the 302 processor is operatively connected to the 304 memory, the 306 user interface, and the 308 network communications module. The 302 processor generally comprises one or more processors that can operate in parallel or otherwise in conjunction with each other. Those skilled in the art will recognize that a “processor” includes any hardware system, hardware mechanism, or hardware component that processes data, signals, or other information. Accordingly, the 302 processor may include a system with a central processing unit, a graphics processing unit, multiple processing units, dedicated circuitry for achieving functionality, programmable logic, or other processing systems. The cloud storage devices 320 are configured to store route data received from the monitoring device 110. The cloud storage devices 320 can be any type of long-term, non-volatile storage device 15 capable of storing information accessible by the processor 302, such as hard disk drives or any other computer-readable storage media recognized by those skilled in the art. Similarly, memory 304 is configured to store program instructions which, when executed by the processor 302, enable cloud servers 300 to perform various operations described herein, including the management of route data stored on the cloud storage devices 320.Memory 304 can be any type of device or combination of devices capable of storing information accessible by the processor 302, such as memory cards, ROM, RAM, hard drives, disks, flash memory, or any of the various computer-readable media recognized by those 25 experts in the art. The 308 network communications module of the 300 cloud servers provides an interface that enables communication with any of the various devices, including at least the 110 monitoring device. Specifically, the 308 network communications module may include a local area network (LAN) port that allows communication with any of several local computers located in the same or a nearby facility. Typically, the 300 cloud servers communicate with remote computers over the internet via a separate LAN modem and / or router. Alternatively, the 308 network communications module may also include a wide area network (WAN) port that enables communication over the internet. In one configuration, the 308 network communications module is equipped with a Wi-Fi transceiver or other wireless communications device.Therefore, it will be appreciated that communications with the cloud servers bCLfrnn / eznz / e / Yi. 300 can occur through wired or wireless communications. Communications can be achieved using any of several known communication protocols. The 300 cloud servers can be operated locally or remotely by an administrator. To facilitate local operation, the 300 cloud servers may include a 306 user interface. In at least one configuration, the 306 user interface may conveniently include an LCD or similar display, a mouse or other pointing device, a keyboard or other numeric keypad, speakers, and a microphone, as will be recognized by those skilled in the art. Alternatively, in some configurations, an administrator may operate the 300 cloud servers remotely from another computing device that is in communication with it via the 308 network communications module and has a similar user interface. The cloud storage backend server 120 is configured to securely store and manage trip data on cloud storage devices 320 and provide access to trip data to the mobility service provider, as well as authorized third parties, via a web interface or API that includes controlled access and identity management. To this end, in at least some configurations, the cloud storage backend server 120 is in bidirectional communication with a backend server of the mobility service provider. Driver's Personal Electronic Device As shown in FIGURE 3B, the exemplary embodiment of the personal electronic device 130 comprises a processor 330, a memory 332, a display screen 334, and at least one network communications module 336. The processor 330 is configured to execute instructions for operating the personal electronic device 130 to enable the features, functionality, characteristics, and / or likenesses as described herein. To this end, the processor 330 is operatively connected to the memory 332, the display screen 334, and the network communications module 336. The processor 330 generally comprises one or more processors that can operate in parallel or otherwise in conjunction with each other. Those skilled in the art will recognize that a “processor” includes any hardware system, hardware mechanism, or hardware component that processes data, signals, or other information.Therefore, the 330 processor may include a system with a central processing unit, graphics processing unit, multiple processing units, dedicated circuitry to achieve functionality, programmable logic, or other processing systems. Memory 332 is configured to store data and program instructions which, when executed by the processor 330, enable the electronic device bCLfrnn / eznz / e / Yi personal 130 to perform the various operations described herein. Memory 332 may be any type of device capable of storing information accessible by the processor 330, such as a memory card, ROM, RAM, hard disks, disks, flash memory, or any of the various other computer-readable media that serve as data storage devices, as those skilled in the art will recognize. The display screen 334 may comprise any of several known types of displays, such as LCD or OLED displays. In some embodiments, the display screen 334 may comprise touchscreens configured to receive touch input from a user. Alternatively or additionally, the personal electronic device 130 may include additional user interfaces, such as buttons, switches, a keyboard or other numeric keypad, speakers, and a microphone. The 336 network communications module may comprise one or more transceivers, modems, processors, memories, oscillators, antennas, or other hardware conventionally included in a communications module to enable communication with various other devices, including at least the 110 monitoring device. Specifically, the 336 network communications module typically includes a Bluetooth® module (not shown) configured to enable communication with the 110 monitoring device. Additionally, the 336 network communications module typically includes a Wi-Fi module configured to enable communication with a Wi-Fi network and / or Wi-Fi router (not shown), as well as one or more cellular modems configured to communicate with wireless telephone networks. The Personal Electronic Device 130 may also include a respective battery or other power source (not shown) configured to power the various components within the Personal Electronic Device 130. In one mode, the battery of the Personal Electronic Device 130 is a rechargeable battery configured to be charged when the Personal Electronic Device 130 is connected to a battery charger configured for use with the Personal Electronic Device 130. In at least one mode, memory 332 stores a mobility service provider application 338. As noted earlier, non-limiting examples of similar mobility service provider applications include the “Lyft Driver” application by Lyft™ and the “Uber Driver” application by Uber™, which are available on many smartphone and tablet computing platforms. However, it should be appreciated that the versions of these applications existing at the time of this disclosure do not necessarily operate in the manner described herein, and descriptions of mobility service provider application 338 should not be construed as descriptions of these exemplary similar mobility service provider applications. bCLfrnn / eznz / e / Yi As discussed in more detail below, the processor 330 is configured to execute instructions from the mobility service provider application 338 to provide mobility services, specifically to provide routes to customers. Additionally, in some modes, the processor 330 is configured to execute program instructions from the mobility service provider application 338 to communicate useful metadata regarding each particular route to the monitoring device 110.Alternatively, memory 332 can store an additional intermediary application that is executed by processor 330 to receive useful metadata regarding each particular journey from the mobility service provider application 338 or from a 10 mobility service provider cloud backend server service, and then communicate the useful metadata regarding each particular journey to the monitoring device 110. Methods for Monitoring Routes of a Mobile Service Provider A variety of methods and processes are described below for operating the 15 monitoring device 110, the cloud storage backend server 120, and the personal electronic device 130.In these descriptions, statements that a method, processor, and / or system is performing a certain task or function refer to a controller or processor (for example, the processor 200 of monitoring device 110, the processor 302 of cloud storage backend server 120, or the processor 330 of personal electronic device 130) executing programmed instructions stored on non-transient, computer-readable storage media (for example, memories 202, 204 of monitoring device 110, memory 304 of cloud storage backend server 120, or memory 332 of personal electronic device 130) operatively connected to the controller or processor to manipulate data or to operate one or more components in the system 100 to perform the task or function.Additionally, the steps of the methods can be executed in any chronologically feasible order, without regard to the order shown in the figures or the order in which the steps are described. Figure 4 shows a method 400 for operating the monitoring device 110 to monitor a trip in which a vehicle driver picks up a customer at a pickup location 30 and drives the customer to a drop-off destination. The method conveniently captures and stores in non-volatile memory sensor data during a particular trip and annotates the sensor data with useful metadata pertaining to that particular trip. For example, sensor data captured during a trip can be stored with metadata that identifies the trip, driver, and particular customer, and with timestamps that identify a trip request / start time, a customer pickup time, and a customer drop-off time. bCLfrnn / eznz / e / Yi Method 400 begins with a step that involves communicatively pairing the monitoring device with a driver's personal electronic device (block 410). Specifically, in at least one mode, the processor 200 of the monitoring device 110 operates the Bluetooth module 228 to communicatively pair with the Bluetooth module of the personal electronic device 130. This pairing process can be achieved using a variety of known methods with one or more buttons or other user interfaces on the monitoring device 110 and the personal electronic device 130. Furthermore, those skilled in the art will appreciate that the monitoring device 110 and the personal electronic device 130 can be communicatively paired using other communication methods besides Bluetooth, such as Wi-Fi, ZigBee, Z-Wave, and conventional radio.Additionally, in some modalities, the 110 monitoring device may be physically wired to the 110 personal electronic device, for example via a USB connection or similar. Through communicative pairing, the monitoring device 110 can exchange messages and other data with the personal electronic device 130. In particular, the monitoring device 110 exchanges messages and other data with the mobility service provider application 338 or another intermediary application on the personal electronic device 130 to obtain information regarding each particular journey provided by the driver using the mobility service provider application. In one mode, in response to the personal electronic device 130 being paired with the monitoring device 110, the processor 200 operates a status indicator of the lighting devices 234 to indicate that the personal electronic device 130 is paired with the monitoring device 110. After the personal electronic device 130 is paired with the monitoring device 110, the driver can begin operating the mobility service provider's application 338 on the personal electronic device 130 to receive ride requests initiated by potential customers using the corresponding mobility service provider's application on their personal electronic device. This phase, in which the driver is ready and waiting for a ride request, is referred to as Phase 1 (P1). In other words, the driver is logged into the mobility service provider's application 338 but is waiting for a ride request. Upon receiving a ride request, the driver can accept the requested ride, thereby agreeing to complete the requested trip in exchange for a fare. Method 400 continues with a step involving receiving, from the personal electronic device, a trip start message indicating that a trip has been requested and accepted (block 420). Specifically, when the driver accepts a trip request, the processor 330 of the personal electronic device 130 operates its Bluetooth module to transmit a trip start message to the monitoring device 110, and the processor 200 similarly operates the Bluetooth module 228 to receive the trip start message. In at least one mode, the trip start message is transmitted by the personal electronic device 130 to the monitoring device 110 immediately upon the driver accepting the trip request and / or the driver otherwise being assigned the trip by the mobility service provider. The trip start message indicates that a trip has been initiated by the driver and preferably includes a timestamp indicating when the trip began. The trip start message may also include additional metadata such as a trip identifier that identifies the specific trip (e.g., an ID number), a driver identifier that identifies the specific driver (e.g., a username, ID number, email address, driver's license number, or similar identifying information), and a customer identifier that identifies the specific customer (e.g., a username, account number, email address, or similar identifying information). The phase in which the driver has been assigned a route and is driving to pick up the customer is referred to here as Phase 2 (P2). Therefore, the trip start message notifies the monitoring device 110 of the transition from Phase 1 to Phase 2. Method 400 continues with a step that involves initiating sensor data recording for the trip from at least one sensor located on the vehicle (block 430). Specifically, in response to receiving the trip start message, processor 25 200 begins recording / writing sensor data from the plurality of sensors to non-volatile memory 204 in association with the trip. In some modes, processor 200 can continuously record / write sensor data from the plurality of sensors to volatile memory 202 or to non-volatile memory 204 in a short-term buffer memory, including during Phase 1 (i.e., while no trip is being executed).However, in response to receiving the trip start message, the processor 200 begins generating and storing trip data fragments in non-volatile memory 204, which includes sensor data that has timestamps after the trip start time. These trip data fragments will be described in more detail elsewhere in this document. As described earlier, the plurality of sensors of the monitoring device 110 may comprise a variety of different sensor types, including the outdoor camera bCLfrnn / eznz / e / Yi 112, the interior camera 114, at least one interior microphone 116, the GNSS module 216, and the IMU 214. Therefore, the sensor data that are included in the journey data fragments may include video data, audio data, global positioning data, acceleration data, and orientation data. In one mode, as the processor 200 begins recording / writing sensor data from the plurality of sensors in the non-volatile memory 204, the processor 200 operates a status indicator of the lighting devices 234 to indicate that the monitoring device 110 is recording travel data. Method 400 continues with a step involving the driver receiving a "pick up customer" message from the personal electronic device, indicating that the customer has been picked up at a designated pickup location (block 440). Specifically, after accepting a ride request, the driver drives to a pickup location where the customer boards vehicle 102 to be transported to their final destination. When the driver arrives at the pickup location and accepts the customer into vehicle 102, the processor 330 of the personal electronic device 130 operates its Bluetooth module to transmit a "pick up customer" message to the monitoring device 110. Similarly, processor 200 operates Bluetooth module 228 to receive the "pick up customer" message.In at least one modality, the message to pick up the customer is transmitted by the personal electronic device 130 to the monitoring device 110 immediately in response to the driver picking up the customer at the pickup location or, more particularly, in response to the customer or driver indicating, via the application of the respective mobility service provider, that the pickup has occurred. The customer pickup message indicates that the customer has been picked up by the driver and preferably includes a timestamp of the pickup time. The customer pickup message may also include additional metadata such as a trip identifier that identifies the specific trip (e.g., an ID number), a driver identifier that identifies the specific driver (e.g., a username, ID number, email address, driver's license number, or similar identifying information), and a customer identifier that identifies the specific customer (e.g., a username, account number, email address, or similar identifying information). The phase in which the driver has a customer in vehicle 102 and is en route to the final destination is referred to here as Phase 3 (P3). Therefore, the "Pick up customer" message notifies monitoring device 110 of the transition from Phase 2 to Phase 3. Method 400 continues with a step that involves receiving, from the personal electronic device, a customer drop-off message indicating that the customer has been dropped off at a designated drop-off destination (block 450). Specifically, after picking up the customer, the driver drives to an agreed-upon drop-off destination where the customer will exit vehicle 102. When the driver arrives at the drop-off destination and the customer exits vehicle 102, the processor 330 of the personal electronic device 130 operates its Bluetooth module to transmit a customer drop-off message to the monitoring device 110, and the processor 200 similarly operates the Bluetooth module 228 to receive the customer drop-off message.In at least one modality, the customer drop-off message is transmitted by the personal electronic device 130 to the monitoring device 110 10 immediately in response to the customer being dropped off at the drop-off destination or, more particularly, in response to the customer or driver indicating, via the respective mobility service provider's application, that the drop-off has occurred. The customer drop-off message indicates that the customer has been dropped off by the driver and preferably includes a timestamp indicating when the customer was dropped off. The customer drop-off message may also include additional metadata such as a trip identifier that identifies the particular unique trip (e.g., an ID number), a driver identifier that identifies the particular driver (e.g., a username, ID number, email address, driver's license number, or similar identifying information), and a customer identifier that identifies the particular customer (e.g., a username, account number, email address, or similar identifying information). After the customer is dropped off, the driver can again operate the mobility service provider's application 338 on the personal electronic device 130 to receive ride requests initiated by other customers. Therefore, the pickup message 25 to the customer notifies the monitoring device 110 of the transition from Phase 3 back to Phase 1. Method 400 continues with a step that involves stopping the recording of sensor data for the trip from at least one sensor (block 460). Specifically, in response to receiving the client's descent message, processor 200 stops recording / writing sensor data from the plurality of sensors to non-volatile memory 204 associated with the trip. As noted earlier, in some modes, processor 200 may continue recording / writing sensor data from the plurality of sensors to volatile memory 202 or non-volatile memory 204 in a short-term buffer. However, in response to receiving the client's descent message, processor 200 stops generating and storing trip data fragments for the particular trip in non-volatile memory 204 for sensor data that have timestamps after the descent time. Method 400 continues with a step that involves storing, in local memory, the sensor data captured during the traverse along with traverse metadata, including a traverse identifier (block 470). Specifically, when a particular traverse has been completed, processor 200 stores the traverse data fragments generated for that traverse in a loop within non-volatile memory 204 for long-term storage. It should be noted that the traverse data fragments can, of course, be written directly to the loop within non-volatile memory 204 during the course of the traverse and are not necessarily placed in the loop only after the traverse is completed. The details of the traverse data fragments and the loop are described in more detail below. Local data management The monitoring device 110 is configured to store route data as route data fragments, each storing sensor data for a predetermined or variable period of time (e.g., 30 seconds). Each route data fragment is individually encrypted to ensure data integrity. Each route data fragment can be uploaded to the cloud storage backend server 120 independently, reducing cellular data usage and improving data availability in low-connectivity situations. The route data fragments for a particular route can then be decrypted and recombined by the cloud storage backend server 120. FIGURE 5 shows an exemplary data structure 500 for each route data fragment stored by the monitoring device 110. The route data fragment includes fragment metadata 510, encrypted metadata 520, and encrypted sensor data 530 (encrypted video and audio, as illustrated). Those skilled in the art will appreciate that the term “metadata” refers to any data that describes or provides information about other data (e.g., the sensor data included in the route data fragment). The 510 fragment metadata includes the unencrypted metadata of the trip data fragment. In the illustrated mode, the 510 fragment metadata includes a 512 Trip ID, which identifies the particular unique trip (for example, an ID number) with which the trip data fragment is associated; 514 timestamps, which identify the start and end timestamps for the sensor data contained within the trip data fragment; and a 515 activity index, which estimates the level of activity within the 104 cab of the 102 vehicle during the time period represented by the trip data fragment. The activity index is determined locally by the bCLfrnn / pznz / e / Yi processor 200 and will be described in more detail elsewhere in this document.The metadata in 510 fragments can also include the file size of the journey data fragment, a file pointer to the journey data fragment, and a universally unique identifier (UUID) for the journey data fragment. Finally, the five 510 fragment metadata for each journey data fragment can also include additional header information, including any additional information necessary to decrypt the journey data fragments and reassemble the journey data from a set of sequential journey data fragments, for example, by the cloud storage backend server 120. Encrypted metadata 520 includes the encrypted metadata of the trip data fragment, such as personally identifiable information or other more sensitive metadata. In the illustrated mode, encrypted metadata 520 includes at least global positioning data 522 recorded by the GNSS module 216 during the trip (for example, a time series of latitude / longitude positions). Encrypted metadata 15 520 may also include additional trip metadata such as a driver identifier that identifies the particular driver (for example, a username, ID number, email address, driver's license number, or similar identifying information) and a customer identifier that identifies the particular customer (for example, a username, account number, email address 20, or similar identifying information).It should be appreciated that any of the metadata described here may be included in either the 510 fragment metadata or the 520 encrypted metadata, depending on privacy and searchability concerns. Finally, the encrypted sensor data 530 includes the sensor data from the 25 journey data fragment. In the illustrated mode, the encrypted sensor data 530 includes audio data 532 recorded by the microphones 116 during the time period represented by the journey data fragment and video data 534 recorded by the front-facing exterior camera 112 and the cabin-facing interior camera 114 during the time period represented by the journey data fragment. In some 30 modes, the encrypted sensor data 530 further includes sensor data recorded by other sensors during the time period represented by the journey data fragment, such as acceleration and gyroscopic data recorded by the IMU 214. Individual journey data fragments may include multiple types of sensor data or, in some modes, only one type of sensor data. As mentioned earlier, to provide enhanced security, the processor 200 is configured to encrypt at least part of the data in each data fragment of the be i πηη / ρζηζ / Β / γι path, i.e., the encrypted metadata 520 and the encrypted sensor data 530. Thus, the data structure 500 conveniently ensures data integrity by encrypting personally identifiable information. In at least one mode, the processor 200 includes hardware for cryptographic acceleration. In one mode, encryption keys are unique to each particular monitoring device 110, so that the exposure of one key does not involve data from another device. For similar reasons, in one mode, encryption keys are changed on a periodic basis. The monitoring device 110 manages route data fragments stored in local non-volatile memory 204 at various levels to ensure that collected sensor data is available upon request within defined timeframes. Additionally, route data fragments are managed between local non-volatile memory 204 in the monitoring device 110 and cloud storage devices 320 on the cloud storage backend server 120 to ensure data integrity and the highest possible data availability. The 200 processor implements one or more cyclic memories (which may also be referred to as circular memories, circular queues, or cyclic buffer memories) in local non-volatile memory 204 to manage the storage of newly generated traverse data fragments and the disposal of old traverse data fragments. Each cyclic memory is a data structure comprising a predetermined number of elements that are written to and replaced on a first-in, first-out (FIFO) basis. Each element in the cyclic memory comprises a particular traverse data fragment and / or an index / pointer reference to a particular traverse data fragment stored in non-volatile memory 204.As new traverse data fragments are generated and written to memory 204, the cyclic memory 25 is modified to remove the oldest traverse data fragment and add the new traverse data fragment. Therefore, each cyclic memory stores and / or references traverse data fragments corresponding to a time period that has a predetermined duration (i.e., the number of items multiplied by the duration of an individual traverse data fragment). In one mode, the 200 processor implements different cyclic memories of varying lengths for different data types. This allows more important data types to be stored for longer periods, while less important data types can be stored for shorter periods. For example, in one mode, a first cyclic memory might be implemented to store video data from the front-facing exterior camera 112, with a predetermined first length (e.g., 2 hours). A second cyclic memory might be implemented to store video data from the cabin-facing interior camera 114, with a predetermined second length (e.g., 48 hours). A third cyclic memory might be implemented to store audio data from microphones 116, with a predetermined third length (e.g., 48 hours).A fourth cyclic memory is implemented to store metadata (e.g., any of the 510 fragment metadata or 520 encrypted metadata discussed earlier) that has a predetermined fourth length (e.g., 48 hours). In one mode, if the 110 monitoring device is offline for a predetermined amount of time, the 110 monitoring device is configured to wake up and erase any expired data from the cyclic memories. In some configurations, in addition to cyclic memories, the 200 processor implements a safe storage table or other data structure configured to identify traverse data fragments or portions thereof that will not be deleted for at least a predetermined amount of time. In response to particular conditions or trigger events, the 200 processor moves some traverse data fragments and / or the index / pointer references to certain traverse data fragments from the cyclic memories to a separate safe storage table, which is separate from the cyclic memories. As a result, these traverse data fragments will be deleted by the cyclic memories and instead fed into the safe storage table according to its rules. The safe storage table is a data structure comprising an arbitrary number of elements stored for a predetermined amount of time, typically much longer than that of cyclic memory (e.g., 30 days). Much like cyclic memory, each element in the safe storage table comprises a traversal data fragment and / or a reference to a particular index / pointer to a specific traversal data fragment stored in non-volatile memory 204. After the predetermined time for the safe storage table expires (e.g., 30 days), the processor 200 removes the traversal data fragments from the safe storage table, thus allowing those traversal data fragments to be removed from non-volatile memory 204.The various conditions and triggering events that will cause a piece of route data or some data from a certain piece of route data to be moved from loop memory to the secure storage table will be described in more detail elsewhere in this document. bCLfrnn / eznz / e / Yi Selective loading of route sensor data to a cloud storage backend server As mentioned earlier, the 110 monitoring device is conveniently configured to upload trip data to the 5 cloud storage backend server 120 in response to a limited set of trigger events. Otherwise, trip data is only stored locally and is eventually deleted as an ongoing issue. In this way, the 110 monitoring device maximizes the privacy of drivers and customers because trip data is never uploaded to the 120 cloud storage backend server 120 for most trips where no dispute or other anomalous event occurs. In response to one of the limited set of trigger events occurring with respect to a particular route, the monitoring device's processor 200 operates the cellular transceiver of the cellular module and GNSS module 216 to begin uploading route data fragments associated with that particular route to the cloud storage backend server 15 120. Similarly, the cloud storage backend server's processor 302 operates the network communication modules 308 to receive the route data fragments associated with that particular route. In one mode, each route data fragment is uploaded individually by the monitoring device 110, and the cloud storage backend server's processor 302 is configured to decrypt each route data fragment and recombine the sensor data from the route data fragments. In one mode, the limited set of triggering events includes a crash occurring during a particular trip. Specifically, the processor 200 monitors the sensor data stream from the IMU 214 and detects that a crash has occurred during a trip 25 in response to acceleration data exceeding an acceleration threshold and / or a deceleration threshold (e.g., ±2G). Other factors may be taken into consideration to ensure high-confidence crash detection. In response to detecting the crash, the monitoring device 110 uploads some or all of the trip data fragments associated with the particular trip 30 during which the crash occurred to the cloud storage backend server 120.In one mode, the monitoring device 110 immediately loads only a subset of the trip data fragments or only a portion of some trip data fragments corresponding to a predetermined time period (for example, 30 seconds) around which the accident occurred. In another mode, the monitoring device 110 immediately loads only some types of sensor data (for example, only video data). In yet another mode, the monitoring device 110 moves the remaining trip data fragments or the remaining portions of the trip data fragments that are not yet loaded from the loop memories to the secure storage table, so that these trip data fragments will remain available for a longer period of time should they be subsequently requested by the mobility service provider for review.In one mode, the 110 monitoring device moves only some types of sensor data (e.g., only video data) to the secure storage table. In one mode, the limited set of triggering events includes the driver or customer requesting that trip data be uploaded for a particular trip 10. Specifically, in some cases, the driver or customer may request that trip data for a particular trip be uploaded to the cloud storage backend server 120, for example, by interacting with the mobility service provider's applications. If such a request is made, an upload request message is received by the monitoring device 110 from the mobility service provider via the cloud storage backend server 120 through the cellular transceiver of the cellular and GNSS module 216 or via the mobility service provider's application 338 on the personal electronic device 130 through the Bluetooth module 228. In one mode, the limited set of triggering events includes a receipt submitted to the mobility service provider by the driver or customer regarding a particular trip. Specifically, in some cases, the driver or customer submits a receipt indicating a dispute of some kind concerning a particular trip, for example, by interacting with the mobility service provider's application. If such a request is made, a payload request message is received by the monitoring device from the mobility service provider via the cloud storage backend server through the cellular transceiver of the cellular and GNSS module, or via the mobility service provider's application on the personal electronic device via the Bluetooth module. In one mode, the limited set of triggering events includes a backend server request received from the mobility service provider. Specifically, in some cases, the mobility service provider may request that trip data for a particular trip be uploaded for some other reason (for example, a driver deviates from the route). If such a request is made, a upload request message is received by the monitoring device from the mobility service provider via the cloud storage backend server through the cellular transceiver of the cellular and GNSS module, or via the mobility service provider's application on the personal electronic device via the Bluetooth module. bCLfrnn / eznz / e / Yi In response to receiving any of the upload request messages described above, monitoring device 110 uploads some or all of the route data fragments associated with the particular route to the cloud storage backend server 120. In one mode, monitoring device 110 immediately uploads only a subset of the route data fragments or only certain types of sensor data (for example, only video data). In another mode, monitoring device 110 moves the remaining route data fragments or the remaining portions of the route data fragments that are not yet uploaded from loops to the secure storage table. In yet another mode, monitoring device 110 moves only certain types of sensor data (for example, only video data) to the secure storage table. In some cases, one of the limited set of trigger events may occur at a time when the monitoring device 110 cannot upload trip data fragments to the cloud storage backend server 120, such as when the monitoring device 110 has weak cellular connectivity with the cloud storage backend server 120, no cellular connectivity at all, a critically low battery, or some other circumstance that prevents the trip data fragments from being uploaded. In response to such a situation, the monitoring device 110 moves the trip data fragments for the particular trip during which the trigger event occurred from the cyclic memories 20 to the secure storage table, thus ensuring that the trip data fragments remain available for later upload.Once the ability to load trip data fragments has been restored, the monitoring device 110 loads the trip data fragments as described above. Once the trip data fragments are successfully loaded, the monitoring device 110 removes them from the secure storage table and deletes them from non-volatile memory. In some cases, after the occurrence of one of the limited set of trigger events, the 110 monitoring device may be unable to successfully upload some of the trip data fragments due to a loss of cellular connectivity during the upload process. In response to this situation, the 110 monitoring device moves the trip data fragments for the specific trip during which the trigger event occurred from the loop memories to the secure storage table, thus ensuring that the trip data fragments remain available for later upload. Once cellular connectivity is restored, the 110 monitoring device uploads the trip data fragments as described above.Once the 35 travel data fragments are successfully loaded, the monitoring device 110 removes them from the secure storage table and deletes them from non-volatile memory 204. bCLbnn / eznz / B / Yi In some cases, if a large amount of data is moved to the secure storage table, local non-volatile memory 204 may run low on storage space. In some modes, in response to a storage space threshold being exceeded in non-volatile memory 204, monitoring appliance 110 is configured to upload some of the route data fragments from the secure storage table to cloud storage backend server 120 for storage on cloud storage appliance 320. Upon successful upload to cloud storage backend server 120, monitoring appliance 110 removes the uploaded route data fragments from local non-volatile memory 204.After the predetermined amount of time for the secure storage table expires (for example, 30 days), the processor 302 of the cloud storage backend server 120 removes the traverse data fragments from the cloud storage device 320. In this way, the availability of any traverse data fragments that are moved to the secure storage table is maintained even if the local non-volatile memory 204 runs out of storage space. Algorithmic activity level As discussed earlier, in at least some modalities, the metadata in 510 fragments of trip data fragments includes an activity index. The activity index provides an estimate of the level or amount of activity within the vehicle's cab during the time period represented by the trip data fragment. The activity index can be used by the system to identify trip data fragments that may pertain to events related to undesirable or inappropriate behavior, which can be leveraged to support data load reduction and operational review time reduction. The activity index is determined locally by the processor 200, preferably using a lightweight algorithm that does not require heavy processing or memory usage. Specifically, because the processor 200 receives sensor data from the multiple sensors of the monitoring device 110, it evaluates the incoming sensor data for particular characteristics that may be associated with violence or other negative behaviors. In some modes, the processor 200 determines the activity index based on audio data captured by microphones 116 and video data captured by the interior camera facing the cabin 114. In some modes, the processor 200 determines separate activity indices for the audio data from microphones 116 and for the video data from the interior camera facing the cabin 114.In some modes, each activity index comprises a time series of numerical values ​​representing the activity level at each point in time during the time period represented by the travel data fragment. In most modes, the processor 200 does not label or identify particular types of activity. Therefore, the monitoring device 110 generally does not know what has occurred inside cabin 104. In one mode, the 200 processor determines a video activity index that indicates the amount of activity in the video from cabin 104, based on video data from the interior camera facing cabin 114. The 200 processor determines the video activity index, for example, based on the amount of motion in the detected video data, such as the amount or rate of change in the visual information. More specifically, the 200 processor can determine the video activity index based on the amount of motion in a mid-frame region (i.e., a region between two customers or between the driver and the customer), which can be correlated with physical violence. A variety of other video data characteristics can be taken into consideration when determining the video activity index. In one mode, the 200 processor determines an audio activity index that indicates the amount of activity in the audio from booth 104, based on the audio data from microphones 116. The 200 processor determines the audio activity index, for example, based on the volume of the audio data. More specifically, the 200 processor can determine the audio activity index based on the volume of the audio data in a predetermined range of frequencies associated with human dialogue, which can be correlated with verbal arguments. A variety of other characteristics of the audio data can be taken into consideration when determining the audio activity index. Figure 6 shows a timeline 600 including activity indices for a sample trip. The timeline 600 includes several trip data fragments 610 that store sensor data for the trip. The timeline 600 also includes a graph 620, which plots the numerical activity level values ​​of a video activity index 630 over time and the numerical activity level values ​​of an audio activity index 640 over time. During the sample trip, an incident occurred midway through Phase 3 (i.e., between pickup and drop-off). Specifically, an argument occurred between a customer and the driver or between two customers. As can be seen, the audio activity index 640 increased significantly during the incident. In one mode, in response to a traverse data fragment that has a higher activity index (e.g., 20% higher) for the traverse or that has an activity index greater than a threshold, the 200 processor moves those traverse bCLfrnn / eznz / e / Yi data fragments and / or index / pointer references to those traverse data fragments from the cyclic memories to the separate secure storage table. In at least one mode, the cloud storage backend server 120 is configured to provide more advanced processing of trip data fragments that are uploaded to and stored on the cloud storage appliance 320. Specifically, upon receiving a trip data fragment from the monitoring appliance 110, the processor 302 can process the sensor data from that appliance to determine additional metadata, such as identifying and labeling particular types of activities that occurred during the time period represented by the trip data fragment. This metadata can further help pinpoint specific moments within a trip that should be reviewed by the mobility service provider, reducing their need to view the entire video footage. Review Request Process Figure 7 illustrates a method for operating the monitoring device to upload one or more trip data fragments in response to a review request from the mobility service provider. This method conveniently leverages locally determined activity indices to identify only the most relevant trip data fragments for uploading to the mobility service provider for review. Simultaneously, remaining trip data fragments are moved to the secure storage table for preservation should more data be required. In this way, the monitoring device reduces cellular data usage while maximizing data availability. Method 700 begins with a step that involves receiving a payload request message from the cloud storage backend server. This payload request message includes at least one trip ID and optionally an incident type and incident time (block 710). Specifically, when a review request is received by the cloud storage backend server 120 from the mobility service provider, the cloud storage backend server's processor 302 operates the network communications module 308 to transmit a payload request message to the monitoring device 110. Similarly, processor 200 operates the cellular transceiver of the cellular and GNSS module 216 to receive the payload request message. A review request can be sent to the cloud storage backend server 120 by the mobility service provider for a variety of reasons. For example, as discussed earlier, the driver or customer can request that trip data be uploaded for a particular trip, such as through the mobility service provider's application. As another example, as discussed earlier, the driver or customer can submit proof to the mobility service provider regarding a particular trip. Finally, as discussed earlier, the mobility service provider can request the upload of trip data for a particular trip for some other reason (for example, a driver deviates from the route). In any case, the review request received on the cloud storage backend server 120 from the mobility service provider includes at least one route identifier that identifies the specific unique route (for example, an ID number). Similarly, the upload request message received by the monitoring device 110 includes at least the route identifier. Additionally, if available, the review request may also include an incident type that identifies the type of incident that occurred during the trip and is selected from a defined set of known incident types. This defined set of known incident types may include, for example, argument between customers, physical violence between customers, argument between customer and driver, physical violence between customer and driver, vehicle accident, and damage to the customer's vehicle. Similarly, the upload request message received by the 110 monitoring device includes the incident type if the review request included one. Finally, if available, the review request can also include an incident time that identifies approximately when the incident occurred during the 20-trip. The incident time, for example, can be selected from a defined set of options, such as the start, middle, or end of the trip. Alternatively, the incident time can include a specific time during the trip. The upload request message received by the monitoring device 110 also includes the incident time if the review request included it. Method 700 continues with a step that involves identifying one or more route data fragments for upload based on their activity indices and the route ID, incident type, and / or incident time (block 720). Specifically, the monitoring device 110's processor 200 identifies the route data fragments associated with the route identified by the route ID in the upload request message. Processor 200 then identifies one or more of these route data fragments—preferably a subset of all route data fragments associated with the route—to be uploaded in response to the upload request message. Processor 200 identifies the route data fragment(s) to be uploaded based on the activity indices of the route data fragments associated with the route.In one mode, the 200 processor identifies those route data fragments associated with the route that have an activity index exceeding a predetermined threshold and selects them for loading. In another mode, the 200 processor identifies those route data fragments associated with the route that have the highest activity indexes for the route and selects a predetermined number or percentage (for example, the top 20%) of the five route data fragments with the highest activity indexes for loading. If the upload request message includes an incident type that identifies the type of incident that occurred during the trip, then the 200 processor identifies the trip data fragment(s) to be uploaded based on the activity indices of the trip data fragments associated with the trip and based on the incident type. Specifically, for some incident types, the 200 processor identifies the trip data fragment(s) to be uploaded by assigning the highest weight to the activity indices for some sensor data types and less weight or no weight to the activity indices for some other sensor data types.For example, if the incident type indicates that an argument occurred, then Processor 200 identifies the path data fragment(s) to be loaded based solely on audio activity indices, ignoring video activity indices. As another example, if the incident type indicates that physical violence occurred, then Processor 200 identifies the path data fragment(s) to be loaded by giving greater weight to video activity indices and less weight or no weight to audio activity indices. Those skilled in the technique will appreciate that a wide variety of techniques can be applied to leverage knowledge of the incident type to better identify the path data fragment(s) to be loaded. If the upload request message includes an incident time that roughly identifies when the incident occurred during the journey, the 200 processor then identifies the journey data fragment(s) to be uploaded based on the activity indices of the journey data fragments associated with the journey and the incident time. Specifically, the 200 processor identifies the journey data fragment(s) to be uploaded as those that correspond to the incident time (for example, start, mid, end, or a specific time) and have the highest activity indices (for example, the top 20%) or activity indices greater than a threshold. Method 700 continues with a step that involves uploading the identified 35 route data fragments to the cloud storage backend server for review (block 730). Specifically, the monitoring device's processor 200 operates the cellular transceiver of the cellular and GNSS module 216 to upload the identified route data fragments to the cloud storage backend server 120. Similarly, the cloud storage backend server's processor 302 operates the network communication modules 308 to receive the route data fragments associated with the particular route. The cloud storage backend server's processor 302 stores the received route data fragments on the cloud storage devices 320, through which the route data fragments become available for review by the mobility service provider. Method 700 continues with a step that involves moving the remaining trip data fragments associated with the trip ID to the secure storage table (block 740). Specifically, the monitoring device 110's processor 200 moves the remaining trip data fragments for the trip that are not identified for upload in response to the upload request message from the loop memories to the secure storage table. This ensures that these trip data fragments remain available for a longer period should the mobility service provider subsequently request them for review. If an additional upload request message is received that identifies the same trip, the monitoring device 110 can then upload all the remaining trip data fragments. Although the invention has been illustrated and described in detail in the drawings and description above, these should be considered illustrative and not restrictive in character. It is understood that only preferred embodiments have been presented and that it is intended to protect all changes, modifications, and additional applications arising in the spirit of disclosure.

Claims

1. A system for monitoring journeys in a vehicle, characterized in that it comprises: at least one sensor accommodated in the vehicle and configured to capture sensor data during journeys; a non-volatile memory configured to store data; and a processor operatively connected to at least one sensor and the memory, the processor being configured to: receive sensor data from at least one sensor captured during a journey in which the driver picks up a customer at a pickup location and drives the customer to a drop-off destination; determine an activity index indicating a level of activity within the vehicle during the journey based on the sensor data captured during the journey; and store, in the non-volatile memory, the sensor data captured during the journey, the activity index being stored in metadata of the sensor data captured during the journey.

2. The system according to claim 1, characterized in that the activity index is a time series of numerical values ​​indicating a level of activity within the vehicle at respective times during the journey. 20 3. The system according to claim 1, characterized in that the processor is further configured to: implement, in non-volatile memory, a data structure configured to store sensor data that will not be deleted for at least a predetermined amount of time; identify a first portion of the sensor data captured during the journey to be moved to the data structure based on the activity index; and move the first portion of the sensor data to the data structure.

4. The system according to claim 1, characterized in that it further comprises: 30 a first transceiver configured to communicate with a remote server, wherein the processor is operatively connected to the first transceiver and is further configured to: receive, through the first transceiver, a request message from the remote server, the request message identifying the route; 35 identify a first portion of the sensor data captured during the route to be uploaded based on the activity index, in response to receiving the request message identifying the route; and upload, through the first transceiver, the first portion of the sensor data captured during the route to the remote server.

5. The system according to claim 4, characterized in that the processor 5 is further configured to: implement, in non-volatile memory, a data structure configured to store sensor data that will not be deleted for at least a predetermined amount of time; and move a second portion of the sensor data that is not identified to be loaded on the remote server to the data structure.

6. The system according to claim 4, characterized in that: the request message received from the remote server further identifies a type of incident that occurred during the journey; and the processor is further configured to identify the first portion of the sensor data captured during the journey to be uploaded based on the activity index and the type of incident.

7. The system according to claim 6, characterized in that the processor is further configured to: determine a first activity index indicating a first level of activity within the vehicle during the journey based on first sensor data captured during the journey by a first sensor of at least one sensor; determine a second activity index indicating a second level of activity within the vehicle during the journey based on second sensor data captured during the journey by a second sensor of at least one sensor; and identify the first portion of the sensor data captured during the journey to be loaded based on the first activity index and the second activity index, the first activity index and the second activity index being weighted differently depending on the type of incident.

8. The system according to claim 7, characterized in that: 30 the first sensor is a first camera accommodated in the vehicle and configured to capture video of an interior of the vehicle, the first sensor data including the video of the interior of the vehicle; the second sensor is a microphone accommodated in the vehicle and configured to capture audio from the interior of the vehicle, the second sensor data including the audio from the 35 interior of the vehicle.

9. The system according to claim 8, characterized in that at least the sensor further includes: a second camera accommodated in the vehicle and configured to capture video of an exterior of the vehicle in a direction of vehicle driving.

10. The system according to claim 4, characterized in that: 5 the request message received from the remote server further identifies a time of an incident that occurred during the journey; and the processor is further configured to identify the first portion of the sensor data captured during the journey to be uploaded based on the activity index and the time of the incident. 10 11. A method for monitoring journeys in a vehicle, characterized in that it comprises: capturing, with at least one sensor accommodated in the vehicle, sensor data during a journey in which a vehicle driver picks up a customer at a pickup location and drives the customer to a drop-off destination; 15 determining an activity index that indicates a level of activity within the vehicle during the journey based on the sensor data captured during the journey; and storing the sensor data captured during the journey in non-volatile memory, the activity index being stored in metadata of the sensor data captured during the journey. 20 12. The method according to claim 11, characterized in that the activity index is a time series of numerical values ​​indicating a level of activity within the vehicle at respective times during the journey.

13. The method according to claim 11 characterized in that it further comprises: 25 implementing, in non-volatile memory, a data structure configured to store sensor data that will not be deleted for at least a predetermined amount of time; identifying a first portion of the sensor data captured during the journey to be moved to the data structure based on the activity index; and 30 moving the first portion of the sensor data to the data structure.

14. The method according to claim 11 characterized in that it further comprises: receiving, through a first transceiver, a request message from a remote server, the request message identifying the route; identifying a first portion of the sensor data captured during the route to be uploaded based on the activity index, in response to receiving the request message identifying the route; and uploading, through the first transceiver, the first portion of the sensor data captured during the route to the remote server.

15. The method according to claim 14, characterized in that it further comprises implementing, in non-volatile memory, a data structure configured to store sensor data that will not be deleted for at least a predetermined amount of time; and moving a second portion of the sensor data that is not identified to be uploaded to the remote server within the data structure.

16. The method according to claim 14, characterized in that the request message received from the remote server further identifies a type of incident that occurred during the journey, the identification of the first portion of the sensor data further comprises: identifying the first portion of the sensor data captured during the journey to be uploaded based on the activity index and the type of incident.

17. The method according to claim 16, characterized in that: the determination of the activity index further comprises: determining a first activity index indicating a first level of activity within the vehicle during the journey based on first sensor data captured during the journey by a first sensor of at least the sensor; and determining a second activity index indicating a second level of activity within the vehicle during the journey based on second sensor data captured during the journey by a second sensor of at least the sensor;and the Identification of the first portion of the sensor data also comprises: identifying the first portion of the sensor data captured during the journey to be uploaded based on the first activity index and the second activity index; the first activity index and the second activity index are weighted differently depending on the type of incident.

18. The method according to claim 17, characterized in that: the first sensor is a first camera accommodated in the vehicle and configured to capture video of the vehicle interior, the first sensor data including the video of the vehicle interior; the second sensor is a microphone accommodated in the vehicle and configured to capture audio from the vehicle interior, the second sensor data including the audio from the vehicle interior.

19. The method according to claim 18, characterized in that at least the sensor further includes: a second camera accommodated in the vehicle and configured to capture video of an exterior of the vehicle in a direction of vehicle driving.

20. The method according to claim 14, characterized in that the request message received from the remote server further identifies a time of an incident that occurred during the journey, the identification of the first portion of the sensor data further comprises: identifying the first portion of the sensor data captured during the journey to be uploaded based on the activity index and the time of the incident.

Images