MANAGEMENT AND LOADING OF TRAVEL MONITORING DATA FROM A MOBILITY SERVICE PROVIDER.

Abstract

A system and method for monitoring vehicle trips are disclosed, in which a vehicle driver picks up a passenger at a pickup location and drives the passenger 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 remote server, non-volatile memory configured to store data, and a processor. The system captures sensor data during each trip, stores the captured sensor data, receives a trip identifier from the personal electronic device that uniquely identifies the trip, and uploads the sensor data for a particular trip to the remote server in response to one of a limited set of trigger events.

Description

MANAGEMENT AND LOADING OF TRAVEL MONITORING DATA FROM A MOBILITY SERVICE PROVIDER pc i trnn / eznz / e / YiAi FIELD OF INVENTION The device and method disclosed in this document refer to in-vehicle monitoring and, more specifically, to the management and uploading of trip monitoring data from a mobility service provider. BACKGROUND OF THE INVENTION Unless otherwise stated herein, the materials described in this section are not admitted to be 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 ride-sharing and taxi services, facilitate transactions between strangers in which a passenger requests a ride using a smartphone app or other means, and a driver picks up and transports the passenger to a desired destination in exchange for a fare. Naturally, there are times when disputes arise between the passenger and the driver, or between passengers during the trip, or when some other unusual event occurs. Therefore, it would be beneficial to provide a system for monitoring trips provided by these mobility service providers.Additionally, it would be advantageous if the monitoring maintained the privacy of drivers and passengers as much as possible, particularly for the majority of trips in which 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 further comprises a first transceiver configured to communicate with a remote server. The system further comprises non-volatile memory configured to store data. The system further comprises a processor operatively connected to the at least one sensor, the first transceiver, and the memory. The processor is configured to receive sensor data from the at least one sensor captured during each of a plurality of trips in which a vehicle driver picks up a passenger at a pickup location and drives the passenger to a drop-off destination. The processor is configured to store, in the non-volatile memory, the sensor data captured during each of the plurality of trips.The processor is configured to upload, via the first transceiver, a portion of the sensor data captured during a respective trip of the plurality of trips to the remote server in response to one of a defined set of triggering events that occur. A method for monitoring vehicle trips is disclosed. The method comprises capturing, with at least one sensor installed in the vehicle, sensor data during each of a plurality of trips in which a vehicle driver picks up a passenger at a pickup location and drives the passenger to a drop-off destination. The method further comprises storing the sensor data captured during each of the plurality of trips in non-volatile memory. The method further comprises uploading, via the first transceiver, a portion of the sensor data captured during a respective trip of the plurality of trips to a remote server in response to one of a defined set of trigger events. BRIEF DESCRIPTION OF THE FIGURES The above aspects and other features of the system and method are explained in the following description, taken in connection with the attached drawings. FIGURE 1 shows a system for monitoring trips provided by a mobility service provider using a vehicle. FIGURE 2 shows example hardware components of the monitoring device. FIGURE 3A shows example hardware components of the cloud storage backend. FIGURE 3B shows example hardware components of the personal electronic device. FIGURE 4 shows a method for operating the monitoring device to monitor a trip in which a vehicle driver picks up a passenger at a pickup location and drives the passenger to a drop-off destination. FIGURE 5 shows a data structure for each travel data fragment stored by the monitoring device. FIGURE 6 shows a timeline that includes activity indices for a sample trip. FIGURE 7 shows a method for operating the monitoring device to upload one or more travel data fragments in response to a review request by the mobility service provider. DETAILED DESCRIPTION OF THE INVENTION pc i trnn / eznz / e / YiAi For the purpose of promoting an understanding of the disclosure principles, reference will now be made to the modalities illustrated in the drawings and described in the following written specification. It is understood that this is not intended to limit the scope of the disclosure. It is further understood that this disclosure includes any alterations and modifications to the illustrated modalities and includes additional applications of the disclosure principles as would normally occur to a person skilled in the art to which this disclosure pertains. System overview Figure 1 shows an example 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 LyftMR and UberMR. The system 100 comprises a monitoring device 110 and a cloud storage backend 120. The monitoring device 110 includes a plurality of sensors, including, for example, a forward-facing exterior camera 112, an interior camera facing the cabin 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 to 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 back end of cloud storage 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 a typically enclosed room for accommodating passengers. In the illustrated embodiment, the cabin 104 includes four seats 106, comprising a driver's seat and multiple passenger seats. However, the cabin 104 may include more or fewer seats depending on the configuration and type of vehicle 102. Vehicle 102 also includes one or more doors (not shown) that allow passengers access to the cabin 104 and the seats 106. In addition, vehicle 102 may include a rear door (not shown) that allows a user access to a cargo storage area of ​​vehicle 102, for example, a trunk or storage space behind the rear seats. The monitoring device 110 is arranged 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 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 retrofit device that attaches 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 LyftMR’s “Lyft Driver” application and UberMR’s “Uber Driver” application, which are available on many smartphone and tablet computing platforms. These mobility service provider applications may, for example, allow the driver to receive trip requests initiated by potential passengers using a corresponding mobility service provider application on a passenger’s personal electronic device. Upon receiving a trip request, the driver may choose to perform the requested trip in exchange for a fare.In general, each trip involves driving vehicle 102 to a pickup location where the passenger is waiting, accepting the passenger into vehicle 102, driving vehicle 102 to a desired drop-off destination, and stopping at the drop-off destination to allow the passenger to disembark. At the end of the trip, the passenger is generally charged a fare by the mobility service provider, a portion of which is given to the driver. During each trip, the monitoring device 110 is configured to record sensor data, which includes at least external video from the forward-facing exterior camera 112, internal video from the in-cabin-facing interior camera 114, and internal audio from the interior microphone 116. The monitoring device 110 is advantageously configured to annotate the recorded sensor data with useful metadata about each particular trip. As an example, the recorded sensor data can be stored with metadata that identifies the particular trip, driver, and passenger, and with timestamps that identify a trip call time, a pick-up time, and a drop-off time.To this end, 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, in order to obtain information about each particular trip provided by the driver using the mobility service provider application. Sensor data for each trip is stored in a local memory of the monitoring device 110. The sensor data is stored in one or more ring buffers so that as new sensor data corresponding to the latest trips is recorded, the sensor data corresponding to older trips is deleted. In at least one mode, sensor data corresponding to a particular trip or a particular portion of a trip can be tagged for longer-term storage in a separate secure storage table (pc i trnn / eznz / e / YiAi) if the data is expected to be more relevant for resolving disputes by the operator or the mobility service provider administrator. This data can be tagged, for example, for longer-term storage by the monitoring device 110 with the help of an algorithm that processes the sensor data to determine an activity level within cabin 104.Particular trips or particular portions of a trip that have a high level of activity within cabin 104 can be automatically tagged for longer-term storage by the monitoring device 110. In limited circumstances, recorded sensor data is uploaded to the back-end cloud storage 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 back-end cloud storage 120 in response to a trigger event. Examples of trigger events include the vehicle 102 being involved in an accident during the trip, a passenger or driver requesting that the sensor data be uploaded for the trip, a passenger or driver submitting a support ticket to the mobility service provider regarding the trip, and a back-end request from the mobility service provider.In this way, most of the recorded sensor data is never uploaded to the back end of cloud storage 120 or made available for viewing by any party, thereby improving the privacy of the monitoring device system 100. With reference to FIGURE 2, example 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 operationally connected to a plurality of sensors, a plurality of transceivers, a plurality of output devices, and a power supply. It will be recognized by those skilled in the art 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 units, 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) that has at least one central processing unit (CPU), such as a quad-core ARM Cortex-A53 running at, for example, 1 GHz. The SoC may include dedicated processors or circuitry for video encoding, for example, pc i trnn / eznz / e / YiAi h.264 and h.265 and for multiple resolution streams. Additionally, the system-on-a-chip 200 may comprise dedicated processors or circuits for data encryption, for example, 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 comprise a variety of data and peripheral interfaces, for example, 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 Receiver / Transmitter (UART). Finally, the system-on-a-chip 200 may comprise a real-time clock (RTC) and a system clock (CLK), generated by, for example, a 32-bit crystal oscillator 206.768 kHz and a 24 MHz crystal oscillator 208, respectively. Memories 202 and 204 can be any type of device capable of storing information accessible by the processor 200, such as a flash memory card, ROM, RAM, hard drives, disks, or any other different computer-readable media that serve as volatile or non-volatile data storage devices, as will be recognized by those skilled in the art. In particular, memories 202 and 204 comprise at least one volatile memory 202 and one non-volatile memory 204. The volatile memory 202 can, for example, comprise a 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 may, for example, comprise embedded MultiMediaCard (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 exterior camera 112 and the interior camera 114, discussed earlier, which connect to the processor 200 (e.g., via MIPI). The exterior camera 112 and interior camera 114 are configured to capture video of their surroundings, namely the road ahead of vehicle 102 and the interior of the cabin 104, respectively. Cameras 112 and 114 comprise image sensors configured to capture video at, for example, a resolution of 1080p at 30 frames per second, 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 configuration, the image sensor of the exterior camera 112 is an RGB 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 configured, for example, to pass infrared light with a wavelength corresponding to the associated IR LEDs 210 and IR LED driver 212 (e.g., 850 nm). In one configuration, the outdoor camera 112 and indoor camera 114 have, for example, image sensor sizes of 0.9407 cm (1 / 2.7 in) and 0.8758 cm (1 / 2.9 in), respectively. In one configuration, the outdoor camera 112 and indoor camera 114 have, for example, lens fields of view of -140° and -150°, respectively. The monitoring device 110 includes at least one microphone 116, discussed above, which connects to the processor 200 (for example, via I2S). The microphone 116 comprises any type of acoustic sensor configured to record sounds within the booth 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 booth 104. In one embodiment, the microphone(s) 116 take the form of micro-electromechanical system (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 connects to the processor 200 (for example, via SPI). The IMU 214 functions as an accelerometer and a gyroscope and may include a discrete accelerometer and a discrete gyroscope, or a single combined sensor that provides both acceleration and gyroscopic measurements. The accelerometer may, for example, be a 16-bit digital triaxial accelerometer with ±16 g and a data rate of up to 1.6 kHz. The gyroscope may, for example, be a 16-bit digital triaxial gyroscope with up to ±2000 dps and a data rate of up to 6.4 kHz. In one configuration, the IMU 214 also includes a built-in temperature sensor that is used for thermal protection features. In some embodiments, the monitoring device 110 includes a cellular and global navigation satellite system (GNSS) module 216 that connects to the processor 200 (for example, via USB). The cellular and GNSS module 216 provides both 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 that includes a cellular modem (for example, Category 4 LTE), a main antenna 218, a diversity antenna 220, and a subscriber identification module (SIM) card 222, as well as any other processor, memory, oscillator, 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) and surface acoustic wave (SAW) filter module 224, and a flexible antenna 226, as well as any other processor, memory, oscillator, 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 to 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 mode, along with measured vehicle speed, vehicle heading, and a device ID for the monitoring device 110. In some embodiments, the monitoring device 110 includes a Bluetooth module 228 that connects 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 processor, memory, oscillator, or other hardware conventionally included in a Bluetooth module. 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 an RGB-mounted antenna. In some embodiments, the monitoring device 110 includes an LED driver 232, which connects to the processor 200 (for example, via I2C), and 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 pairing indicator, and a recording indicator. Additionally, the lighting devices 234 may include an RGB LED array 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 show any trademark, logo, or other information to passengers or external pedestrians. In some embodiments, the monitoring device 110 includes a speaker driver 236, which connects to the processor 200 (for example, via I2S) and drives a corresponding speaker 238. In some embodiments, the monitoring device 110 includes multiple 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 becomes too high. In at least one embodiment, the monitoring device 110 is provided with a protective outer housing or casing (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 attach to a mount that semi-permanently affixes to a surface such as a vehicle dashboard or windshield 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 modalities, the monitoring device 110 can be natively or otherwise integrated with the vehicle 102 and its components can be distributed throughout the vehicle 102. Finally, the 110 monitoring device includes a 240 power supply that has suitable power electronic components configured to provide the required output voltages for the different components of the 110 monitoring device (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 operationally connected to a battery 242 having, for example, a capacity of 1000 mAh, and includes suitable power electronics configured to draw power from the battery 242 as well as to charge it. The power supply 240 is therefore also configured to receive input power from a power source 244, such as a 12 V vehicle accessory voltage. To this end, the power supply 240 can be connected directly to a vehicle cigarette lighter socket 102.However, in alternative configurations, the power supply 240 can be connected to a vehicle USB port 102 or directly to a vehicle accessory voltage line. In one configuration, a vehicle power connection 102 is integrated with the mount for the monitoring device 110, so that the monitoring device 110 only receives power from the vehicle 102 when it is attached to the mount. 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 a trigger or status of the power switch 246. The 110 monitoring device is configured to operate in a variety of different modes. In normal mode, the 110 monitoring device is connected to power via the mount and paired with the mobility service provider application on the 130 personal electronic device. In some modes, even in normal mode, the sensors are active and record data to the data ring buffers, as discussed in more detail later. When the 110 monitoring device is not connected to power via the mount, it operates in one or more battery-powered operating modes. Notably, the 110 monitoring device does not operate in normal mode while using battery power. These battery-powered operating modes are included to ensure data protection in the event of a power loss during an active trip. In some modes, in network polling mode, the 110 monitoring device operates using battery power and stands in ultra-low power mode. In ultra-low power mode, the 110 monitoring device activates once per hour, checks the network for messages, and then powers down. The 110 monitoring device polls for a minimum time (for example, 2 weeks) or until the battery drops below a specified state of charge. In one mode, a staggered polling period is used to balance battery life with cost and data availability. For example, the 110 monitoring device activates once per hour for a period of one week and then once per day for a period of one month. Network polling periods can be adjusted to balance battery life with cost. In some modes, in remote activation mode, if the 110 monitoring device receives a network message indicating that it should be activated while in network polling mode, the 110 monitoring device powers on, performs the instructed action (for example, uploads the requested trip data fragments, up to a maximum of 30 minutes of data), and then powers off again. In this mode, the 110 monitoring device does not activate any sensors or LEDs and remains silent. In some modes, in a last-gasp mode, if the power cable is unplugged during an active trip, the monitoring device 110 switches to battery power, finishes recording the current trip data fragment (discussed in more detail later), stops recording from all sensors, notifies the cloud storage backend 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 cord is unplugged while not on an active trip, the monitoring device 110 switches to battery power, finishes recording the current trip data fragment, stops recording from all sensors, notifies the cloud storage backend 120, and safely shuts down. In some configurations, in an installation support mode, the 110 monitoring device facilitates driver installation with the appropriate fields of view for the cameras, assisted by the mobility service provider application. Installation support mode can be activated via the 120 cloud storage backend or the mobility service provider application. The 110 monitoring device captures images from both the indoor and outdoor cameras and provides these images to the mobility service provider application for viewing during the 110 monitoring device installation. The mobility service provider application or the 110 monitoring device provides installation feedback to help the user properly align 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 its operational features can be updated, and Firmware Over-the-Air (FOTA), which targets lower-level software. 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 of updates and when these updates occur within the device's lifecycle can vary. SOTA / FOTA updates are protected to ensure their security and validity. In addition to being transmitted over a secure communication channel, the updates are encrypted and signed, and the device will reject any unauthorized updates.In addition, the anti-rollback feature will prevent any older software versions that may lack critical patches or fixes from being loaded onto the device. In some configurations, the 110 monitoring device is configured to prevent local access to or removal of trip data from the device and includes device tamper detection and hardware fail-safe 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-assisted software, software, and hardware features. In one mode, the 110 monitoring device supports secure boot (also known as high-security boot (H AB)) 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 one-time programmable key (OTP) capability for secure boot key authenticity verification, and the ability to revert and change even the most critical, lowest-level keys within the system. An OTP memory is used for a device serial number and certain keys that do not change throughout the device's lifespan. In one mode, the 110 monitoring device supports OS integrity verification to protect against any attempt at privileged access to the system root in the event of an intrusion. As part of a diagnostic health check, a device integrity check is routinely performed to report the software version and device integrity, ensuring that the device is still trustworthy and functioning as intended. In one mode, the 110 monitoring device supports secure storage using a Trusted Execution Environment (TEE) file system for all certificates and for the transient storage of encryption keys and related material. TEE protected operation is also used during system boot and for certain critical security operations. TEE provides hardware-assisted protection and isolation from the rest of the operating system to make any intrusion 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 hashing for public key infrastructure (PKI) and related signature / certificate operations. Hardware-assisted encryption combined with specialized cores enables high-performance audio and video capture and encryption as a tightly coupled operation, which can be protected at the 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 glitches to compromise any data. In one mode, the 110 monitoring device uses a true random number generator (TRNG) as a hardware feature that provides the entropy that helps ensure cryptographic keys are secure and resistant to any brute-force attack. In one mode, the 110 monitoring device supports the debug interface deactivation (e.g., JTAG, USB, etc.) performed 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 that protects system memory and strengthens the system while it is running against attempts to eavesdrop and steal data, or as a method of side-channel attacks. The communication modules of the monitoring device 110 utilize similar security features (secure boot, one-time programmable keys) to ensure secure communication. Furthermore, Transport Layer Security (TLS) protocols, firewalls, and operating system policies are used to ensure that the modem communicates exclusively with the cloud storage backend 120 and is resistant to any attempt by hackers to use the network connection as an attack channel to penetrate the system. pc i trnn / eznz / e / YiAi An internal Key Management System (KMS) closely controls key generation and injection at the manufacturing assembly. A high level of coordination between the cloud storage back-end 120 and the monitoring device manufacturing site 110 ensures that no key is compromised on any device. Similarly, access to the signing keys required to sign the software for uploading and execution on the devices is rigorously controlled through smart cards and internal logging procedures. back end of cloud storage With reference now to Figures 3A-3B, example components of the cloud storage back end 120 and personal electronic device 130 are described. It will be appreciated that the components of the cloud storage back end 120 and personal electronic device 130 shown and described herein are merely illustrative and that the cloud storage back end 120 and personal electronic device 130 may comprise any alternative configuration. As shown in FIGURE 3A, the example cloud storage backend 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, including web servers or application servers depending on the features provided by the cloud storage backend 120, but at least include one or more database servers configured to manage the trip 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 example mode of a 300 cloud server and is merely representative of any of the different ways or configurations of a personal computer, server, or any other data processing system that is operational in the manner set forth herein. Processor 302 is configured to execute instructions for operating cloud servers 300 to enable the features, functionality, characteristics, and / or the like as described herein. To this end, processor 302 is operationally connected to memory 304, user interface 306, and network communications module 308. Processor 302 generally comprises one or more processors that can operate in parallel or otherwise in concert with each other. It shall be recognized by those skilled in the art that a “processor” includes any hardware system, hardware mechanism, or hardware component that processes data, signals, or other information. Accordingly, processor 302 may include a system with a central processing unit, graphics processing units, multiple processing units, dedicated circuitry for achieving functionality, programmable logic, or other processing systems.The cloud storage devices 320 are configured to store travel data received from the monitoring device 110. The cloud storage devices 320 can be any type of long-term, non-volatile storage device capable of storing information accessible by the processor 302, such as hard 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 the cloud servers 300 to perform various operations described herein, including the management of travel 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 other different computer-readable media recognized by those skilled in the art. The 308 network communications module of the 300 cloud servers provides an interface that enables communication with 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 the various local computers located in the same or a nearby facility. Generally, the 300 cloud servers communicate with remote computers over the internet using a modem and / or router separate from the LAN. 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 noted that communication with the 300 cloud servers can occur via wired or wireless connections. Communication can be achieved using any of the various 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 suitably 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 120 is configured to securely store and manage travel data on cloud storage devices 320 and provide access to the travel 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 120 is in bidirectional communication with a mobility service provider backend. Driver's personal electronic device As shown in FIGURE 3B, the example 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 the like as described herein. To this end, the processor 330 is operationally 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 concert with each other. It shall be recognized by those skilled in the art 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 units, 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 personal electronic device 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 other computer-readable media that serve as data storage devices, as will be recognized by those skilled in the art. The display screen 334 may comprise any of the various known types of displays, such as LCD or OLED screens. 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 devices, including at least the 110 monitoring device. Specifically, the 336 network communications module generally includes a BluetoothMR module (not shown) configured to enable communication with the 110 monitoring device. Additionally, the 336 network communications module generally includes a Wi-Fi module configured to enable communication with a Wi-Fi network and / or a 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 charge 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 configuration, memory 332 stores a mobility service provider application 338. As noted above, non-limiting examples of similar mobility service provider applications include LyftMR’s “Lyft Driver” application and UberMR’s “Uber Driver” application, 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 function in the manner described herein, and the descriptions of mobility service provider application 338 should not be construed as descriptions of these example similar mobility service provider applications. As discussed in more detail later, the processor 330 is configured to execute program instructions from the mobility service provider application 338 to provide mobility services, specifically passenger rides. Additionally, in some modes, the processor 330 is configured to execute program instructions from the mobility service provider application 338 to communicate useful metadata about each individual ride to the monitoring device 110.Alternatively, memory 332 can store an additional intermediate application that is run by processor 330 to receive useful metadata about each particular trip from the mobility service provider application 338 or from an associated cloud-based pc i trnn / eznz / e / YiAi endpoint service from the mobility service provider, and then communicate the useful metadata about each particular trip to the monitoring device 110. Methods for monitoring trips by a mobile service provider A variety of methods and processes for operating the monitoring device 110, the cloud storage back end 120, and the personal electronic device 130 are described below.In these descriptions, statements that a method, processor, and / or system is performing some task or function refer to a controller or processor (for example, the processor 200 of monitoring device 110, the processor 302 of cloud storage back-end 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 back-end 120, or memory 332 of personal electronic device 130) operatively connected to the controller or processor to manipulate data or operate one or more components in system 100 to perform the task or function.Additionally, the steps of the methods can be performed in any feasible chronological order, regardless of 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 passenger at a pickup location and drives the passenger to a drop-off destination. The method advantageously captures and stores in non-volatile memory sensor data during a particular trip and annotates the sensor data with useful metadata about the particular trip. For example, the sensor data captured during a trip can be stored with metadata that identifies the particular trip, driver, and passenger, and with timestamps that identify a call / trip start time, a passenger pickup time, and a passenger drop-off time. Method 400 begins with a step of 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 accomplished 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, it will be appreciated by those skilled in the art 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 modes, the monitoring device 110 se pc i trnn / eznz / e / YiAi can be physically wired to the personal electronic device 110, for example, via a USB connection or similar. Through communicative pairing, the monitoring device 110 is able to 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 in order to obtain information about each particular trip provided by the driver using the mobility service provider application. In one mode, in response to the personal electronic device 130 pairing 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 application 338 on the personal electronic device 130 to receive trip requests initiated by potential passengers using a corresponding mobility service provider application on their personal electronic device. This phase, in which the driver is ready and waiting for a trip request, is referred to herein as phase 1 (P1). In other words, the driver logs into the mobility service provider application 338 but is waiting for a trip request. Upon receiving a trip request, the driver can accept the requested trip, thereby agreeing to perform the requested trip in exchange for a fare. Method 400 continues with a step of 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 after the driver accepts the trip request and / or the driver is otherwise 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 license number, or similar identifying information), and a passenger identifier that identifies the specific passenger (e.g., a username, account number, email address, or similar identifying information). The phase in which the driver has been assigned a trip and is driving to pick up the passenger is referred to herein as phase 2 (P2). Therefore, the trip start message notifies the 110 monitoring device of the transition from phase 1 to phase 2. Method 400 continues with a step of beginning to record sensor data for the trip from at least one sensor located on the vehicle (block 430). Specifically, in response to receiving the trip start message, processor 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 may 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, including during phase 1 (i.e., while no trip is in progress). However, in response to receiving the trip start message, processor 200 begins generating and storing trip data fragments in non-volatile memory 204, which include sensor data timestamped after the trip start time.These travel data fragments will be described in more detail elsewhere in this document. As described above, the plurality of sensors of the monitoring device 110 may comprise a variety of different types of sensors, including the exterior camera 112, the interior camera 114, the at least one interior microphone 116, the GNSS module 216, and the IMU 214. Therefore, the sensor data included in the travel data fragments may include video data, audio data, global positioning data, acceleration data, and orientation data. In one mode, as the processor 200 begins to record / write 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 trip data. Method 400 continues with a step of receiving, from the personal electronic device, a passenger pickup message indicating that the passenger has been picked up at a pickup location (block 440). Specifically, after accepting a ride request, the driver drives to a pickup location where the passenger will board vehicle 102 to be transported to their final drop-off destination. When the driver arrives at the pickup location and accepts the passenger into vehicle 102, the processor 330 of the personal electronic device pc i trnn / eznz / e / YiAi 130 operates its Bluetooth module to transmit a passenger pickup message to the monitoring device 110, and the processor 200 similarly operates Bluetooth module 228 to receive the passenger pickup message.In at least one modality, the passenger pickup message is transmitted by the personal electronic device 130 to the monitoring device 110 immediately in response to the driver picking up the passenger at the pickup location or, more particularly, in response to the passenger or driver indicating via the respective mobility service provider application that the pickup has occurred. The passenger pickup message indicates that the passenger has been picked up by the driver and preferably includes a timestamp of the pickup time. The passenger 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 license number, or similar identifying information), and a passenger identifier that identifies the specific passenger (e.g., a username, account number, email address, or similar identifying information). The phase in which the driver has a passenger in vehicle 102 and is traveling to the destination drop-off is referred to herein as phase 3 (P3). Therefore, the passenger pickup message notifies monitoring device 110 of the transition from phase 2 to phase 3. Method 400 continues with a step of receiving, from the personal electronic device, a passenger disembarkation message indicating that the passenger has been dropped off at a designated drop-off destination (block 450). Specifically, after picking up the passenger, the driver drives to an agreed-upon drop-off destination where the passenger will disembark from vehicle 102. When the driver arrives at the drop-off destination and the passenger exits vehicle 102, the processor 330 of the personal electronic device 130 operates its Bluetooth module to transmit a passenger disembarkation message to the monitoring device 110, and the processor 200 similarly operates the Bluetooth module 228 to receive the passenger disembarkation message.In at least one modality, the passenger drop-off message is transmitted by the personal electronic device 130 to the monitoring device 110 immediately in response to the passenger being dropped off at the drop-off destination or, more particularly, in response to the passenger or driver indicating via the respective mobility service provider application that the drop-off has occurred. The passenger drop-off message indicates that the passenger has been dropped off by the driver and preferably includes a timestamp of when the passenger was dropped off. The passenger 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 license number, or similar identifying information), and a passenger identifier that identifies the particular passenger (e.g., a username, account number, email address, or similar identifying information). After dropping off the passenger, the driver can again operate the mobility service provider application 338 on the personal electronic device 130 to receive ride requests initiated by other passengers. Therefore, the passenger pickup message notifies the monitoring device 110 of the transition from phase 3 to phase 1. Method 400 continues with a step of stopping the recording of sensor data for the trip from at least one sensor (block 460). Specifically, in response to receiving the passenger descent message, processor 200 stops recording / writing sensor data from the plurality of sensors to non-volatile memory 204 in association 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 passenger 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 of storing, in local memory, the sensor data captured during the trip in association with trip metadata that includes a trip identifier (block 470). Specifically, when a particular trip has been completed, processor 200 stores the trip data fragments generated for that particular trip in a ring buffer of non-volatile memory 204 for long-term storage. It will be appreciated that the trip data fragments can, of course, be written directly to the ring buffer of non-volatile memory 204 during the course of the particular trip and are not necessarily placed in the ring buffer only after the trip has ended. The details of the trip data fragments and the ring buffer are described in more detail later. Local data management The monitoring device 110 is configured to store trip data as trip data fragments, each storing sensor data for a predetermined or variable period of time (e.g., 30 seconds). Each trip data fragment is individually encrypted to ensure data integrity. Each trip data fragment can be uploaded to the cloud storage backend 120 independently, reducing cellular data usage and improving data availability in low-connectivity situations. The trip data fragments for a particular trip can then be decrypted and recombined by the cloud storage backend 120. Figure 5 shows an example data structure 500 for each trip data fragment stored by the monitoring device 110. The trip data fragment includes fragment metadata 510, encrypted metadata 520, and encrypted sensor data 530 (encrypted video and audio, as illustrated). It will be appreciated by those skilled in the art that the term “metadata” refers to any data that describes or provides information about other data (e.g., the sensor data included in the trip 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 that identifies the particular unique trip (for example, an ID number) with which the trip data fragment is associated, 514 timestamps that identify start and end timestamps for the sensor data contained within the trip data fragment, and a 515 activity index that estimates an activity level 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 200 processor and will be described in more detail elsewhere herein.The 510 fragment metadata may also include the file size of the travel data fragment, a file pointer to the travel data fragment, and a universally unique identifier (UUID) for the travel data fragment. Finally, the 510 fragment metadata for each travel data fragment may also include additional header information, such as any additional information needed to decrypt the travel data fragments and reassemble the travel data from a set of sequential travel data fragments, for example, by the back end of cloud storage 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 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 passenger identifier that identifies the particular passenger (for example, a username, account number, email address, or similar identifying information).It should be noted that any of the metadata described herein may be included in either the 510 fragment metadata or the 520 encrypted metadata, depending on privacy and searchability concerns. Finally, encrypted sensor data 530 includes the sensor data from the trip data fragment. In the illustrated mode, encrypted sensor data 530 includes audio data 532 recorded by the microphone(s) 116 during the time period represented by the trip data fragment and video data 534 recorded by the forward-facing exterior camera 112 and the cabin-facing interior camera 114 during the time period represented by the trip data fragment. In some modes, encrypted sensor data 530 also includes sensor data recorded by other sensors during the time period represented by the trip data fragment, such as acceleration and gyroscopic data recorded by the IMU 214. Individual trip 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 200 processor is configured to encrypt at least some of the data in each data fragment, namely the encrypted metadata 520 and the encrypted sensor data 530. Therefore, the 500 data structure advantageously ensures data integrity by encrypting personally identifiable information. In at least one mode, the 200 processor includes hardware for cryptographic acceleration. In one mode, the encryption keys are unique to each specific monitoring device 110, so that the exposure of one key does not compromise the data of another device. For similar reasons, in one mode, the encryption keys are changed periodically. The monitoring device 110 manages trip 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, trip data fragments are managed between local non-volatile memory 204 in the monitoring device 110 and cloud storage devices 320 at the cloud storage backend 120 to ensure the highest possible data integrity and availability. The 200 processor implements one or more ring buffers (also referred to as circular buffers, circular queues, or cyclic buffers) in local non-volatile memory 204 to manage the storage of newly generated travel data fragments and the disposal of old travel data fragments. Each ring buffer 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 ring buffer comprises a particular travel data fragment and / or an index / pointer reference to a particular travel data fragment stored in non-volatile memory 204.As new travel data fragments are generated and written to memory 204, the ring buffer is modified to remove the oldest travel data fragment and add the new travel data fragment. Therefore, each ring buffer stores and / or references travel data fragments that correspond to a time period with a predetermined duration (i.e., the number of items multiplied by the duration of an individual travel data fragment). In one mode, the 200 processor implements different ring buffers 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 ring buffer can be implemented to store video data from the forward-facing exterior camera 112, with a predetermined first buffer length (e.g., 2 hours). A second ring buffer can be implemented to store video data from the cabin-facing interior camera 114, with a predetermined second buffer length (e.g., 48 hours).A third ring buffer can be implemented to store audio data from microphone(s) 116, which has a third default length (e.g., 48 hours). A fourth ring buffer is implemented to store metadata (e.g., any of the fragment metadata 510 or encrypted metadata 520 discussed earlier), which also has a fourth default length (e.g., 48 hours). In one mode, if the 110 monitoring device is disconnected for a predetermined amount of time, the 110 monitoring device is configured to power on and clear any expired data from the ring buffers. In some configurations, in addition to ring buffers, the 200 processor implements a safe storage table or other data structure configured to identify travel 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 certain travel data fragments and / or the index / pointer references to certain travel data fragments from the ring buffers to a separate safe storage table, which is separate from the ring buffers. As a result, these travel data fragments will be deleted by the ring buffers and instead stored according to the rules of the safe storage table. The safe storage table is a data structure comprising an arbitrary number of items stored for a predetermined amount of time, generally much longer than that of ring buffers (for example, 30 days). Like ring buffers, each item in the safe storage table comprises a particular travel data fragment and / or an index / pointer reference to a particular travel data fragment stored in non-volatile memory 204. After the predetermined amount of time for the safe storage table expires (for example, 30 days), processor 200 removes the travel data fragments from the safe storage table, thereby allowing those travel data fragments to be removed from non-volatile memory 204.The different conditions and triggering events that will cause a travel data fragment or certain data from a certain travel data fragment to be moved from the ring buffer to the secure storage table will be described in more detail elsewhere herein. Selective uploading of trip sensor data to the back-end cloud storage As mentioned previously, the 110 monitoring device is advantageously configured to upload trip data to the 120 cloud storage backend in response to a limited set of trigger events. Otherwise, trip data is stored locally and eventually deleted as a matter of routine. In this way, the 110 monitoring device maximizes the privacy of drivers and passengers because trip data is never uploaded to the 120 cloud storage backend for most trips where no dispute or other anomalous event occurs. In response to one of the limited set of trigger events that occur with respect to a particular trip, the monitoring device's processor 200 operates the cellular transceiver of the cellular and GNSS module 216 to begin uploading trip data fragments associated with that particular trip to the cloud storage backend 120. Similarly, the cloud storage backend's processor 302 operates the network communication module(s) 308 to receive the trip data fragments associated with that particular trip. In one mode, each trip data fragment is uploaded individually by the monitoring device 110, and the cloud storage backend's processor 302 is configured to decrypt each trip data fragment and recombine the sensor data from the trip data fragments. In one mode, the limited set of triggering events includes a PC i trnn / eznz / e / YiAi crash that occurs 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 in response to acceleration data exceeding an acceleration threshold and / or a deceleration threshold (e.g., ±2G). Other factors may be considered to ensure high-confidence crash detection. In response to crash detection, the monitoring device 110 uploads some or all of the trip data fragments associated with the particular trip during which the crash occurred to the back-end cloud storage 120.In one mode, the 110 monitoring device immediately loads only a subset of the trip data fragments or only a portion of certain trip data fragments corresponding to a predetermined time period (for example, 30 seconds) around which the accident occurred. In another mode, the 110 monitoring device immediately loads only certain types of sensor data (for example, only video data). In yet another mode, the 110 monitoring device moves the remaining trip data fragments or the remaining portions of the trip data fragments that have not yet been loaded from the ring buffers to the secure storage table, so that these trip data fragments will remain available for a longer period should the mobility service provider subsequently request them for review.In one mode, the 110 monitoring device moves only certain types of sensor data (e.g., video data only) to the secure storage table. In one mode, the limited set of activation events includes a request from the driver or passenger to upload trip data for a particular trip. Specifically, in some cases, the driver or passenger may request that trip data for a particular trip be uploaded to the cloud storage backend 120, for example, by interacting with the mobility service provider's application(s). If this request is made, the monitoring device 110 receives an upload request message from the mobility service provider via the cloud storage backend 120 through the cellular transceiver of the cellular and GNSS module 216 or through the mobility service provider application 338 of the personal electronic device 130 via the Bluetooth module 228. In one mode, the limited set of activation events includes a support ticket submitted to the mobility service provider by the driver or passenger regarding the particular trip. Specifically, in some cases, the driver or passenger submits a support ticket indicating a dispute of some kind concerning a particular trip, for example, by interacting with the mobility service provider's application(s). If this request is made, a upload request message is received by the PC device i trnn / eznz / e / YiAi monitoring 110 from the mobility service provider via the cloud storage backend 120 using the cellular transceiver of the cellular and GNSS module 216 or via the mobility service provider application 338 of the personal electronic device 130 using the Bluetooth module 228. In one mode, the limited set of activation events includes a back-end request received from the mobility service provider. Specifically, in some cases, the mobility service provider may request the upload of trip data for a particular trip for some other reason (for example, a driver deviates from the route). If this request is made, a upload request message is received by the monitoring device 110 from the mobility service provider via the cloud storage back-end 120 using the cellular transceiver of the cellular and GNSS module 216 or via the mobility service provider application 338 of the personal electronic device 130 using the Bluetooth module 228. In response to receiving any of the upload request messages described above, monitoring device 110 uploads some or all of the trip data fragments associated with the particular trip to the back end of cloud storage 120. In one mode, monitoring device 110 immediately uploads only a subset of the trip data fragments or only certain types of sensor data (for example, only video data). In another mode, monitoring device 110 moves the remaining trip data fragments or the remaining portions of the trip data fragments that have not yet been uploaded from the ring buffers 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 120, such as when the monitoring device 110 has weak cellular connectivity with the cloud storage backend 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 this situation, the monitoring device 110 moves the trip data fragments for the particular trip during which the trigger event occurred from the ring buffers to the secure storage table, thereby 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 pc i trnn / eznz / e / YiAi trip data fragments are successfully loaded, the monitoring device 110 removes them from the secure storage table and deletes them from non-volatile memory 204. 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 particular trip during which the trigger event occurred from the ring buffers 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 trip data fragments are successfully loaded, the monitoring device 110 removes them from the secure storage table and deletes them from non-volatile memory 204. In some cases, if too much 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 exceeding a storage space threshold in non-volatile memory 204, monitoring device 110 is configured to upload some of the data fragments in the secure storage table to the cloud storage backend 120 for storage on cloud storage device 320. Upon successful upload to cloud storage 120, monitoring device 110 removes the uploaded data fragments from local non-volatile memory 204.After the predetermined time limit for the secure storage table expires (for example, 30 days), the back-end processor 302 of cloud storage 120 removes the travel data fragments from the cloud storage device 320. This ensures the availability of any travel data fragments moved to the secure storage table, even if local non-volatile memory 204 runs out of storage space. Algorithmic activity level. As discussed earlier, in at least some modalities, the 510 fragment metadata 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 104 during the time period represented by the trip data fragment. The activity index can be used by the system 100 to identify trip data fragments that may pertain to events related to undesirable or inappropriate behavior, which can then be leveraged to support data load reduction and operational review time reduction. pc i trnn / eznz / e / YiAi The activity index is determined locally by the processor 200, preferably using a lightweight algorithm that does not require intensive processing or memory usage. In particular, as the processor 200 receives sensor data from the plurality of sensors of the monitoring device 110, the processor 200 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 the audio data captured by the microphone(s) 116 and on the 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 the microphone(s) 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 level of activity 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 processor 200 determines a video activity index indicating the amount of activity in the video from cabin 104, based on video data from the interior camera facing cabin 114. The processor 200 determines the video activity index, for example, based on the amount of movement in the detected video data, such as the amount or rate of change in visual information. More specifically, the processor 200 can determine the video activity index based on the amount of movement in a mid-frame region (i.e., a region between two passengers or between the driver and a passenger), which can be correlated with physical violence. A variety of other video data characteristics can be considered when determining the video activity index. In one mode, the processor 200 determines an audio activity index that indicates the amount of activity in the audio from booth 104, based on audio data from microphone(s) 116. The processor 200 determines the audio activity index, for example, based on the volume of the audio data. More specifically, the processor 200 can determine the audio activity index based on the volume of the audio data within a predetermined range of frequencies associated with human speech, which can be correlated with verbal arguments. A variety of other characteristics of the audio data can be taken into account when determining the audio activity index. pc i trnn / eznz / e / YiAi Figure 6 shows a timeline 600 that includes activity indices for a sample trip. The timeline 600 includes a plurality of trip data fragments. 610 stores sensor data for the trip. 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 example trip, an incident occurred midway through phase 3 (i.e., between pickup and drop-off). Specifically, an argument broke out between the passenger and the driver, or between two passengers. As can be seen, the audio activity index 640 increased significantly during the incident. In one mode, in response to a travel data fragment that has a higher activity index (e.g., 20% higher) for the travel or that has an activity index greater than a threshold, the 200 processor moves those travel data fragments and / or the index / pointer references to those travel data fragments from the ring buffers to the separate secure storage table. In at least one configuration, the cloud storage backend 120 is configured to provide more advanced processing of trip data fragments uploaded to and stored on the cloud storage device 320. Specifically, upon receiving a trip data fragment from the monitoring device 110, the processor 302 can process the sensor data from that fragment 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 additional metadata can help pinpoint specific moments within a trip that the mobility service provider should review, reducing their need to view entire videos. Review request process Figure 7 shows a method 700 for operating the monitoring device 110 to upload one or more trip data fragments in response to a review request from the mobility service provider. The method takes advantage of locally determined activity indices to identify only the most relevant trip data fragments to upload for review by the mobility service provider, while also moving the remaining trip data fragments to the secure storage table for retention should more data be needed. In this way, the monitoring device 110 reduces cellular data usage while maximizing data availability. Method 700 begins with a step of receiving a payload request message from the cloud storage back end. 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 back end 120 from the mobility service provider, the cloud storage back end processor 302 operates the network communications module 308 to transmit a payload request message to the monitoring device 110. Similarly, the 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 120 by the mobility service provider for a variety of reasons. For example, as discussed earlier, the driver or passenger can request that trip data be uploaded for a particular trip, such as through the mobility service provider's app. As another example, also discussed earlier, the driver or passenger can submit a support ticket 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 at the cloud storage backend 120 from the mobility service provider includes at least one trip identifier that identifies the specific trip (e.g., an ID number). Similarly, the upload request message received by the monitoring device 110 also includes at least the trip 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 passengers, physical violence between passengers, argument between passenger and driver, physical violence between passenger and driver, vehicle accident, and passenger injuries inside the 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 trip. The incident time can be selected from a defined set of options, such as the beginning, middle, or end of the trip. Alternatively, the incident time can include a specific time during the trip. Similarly, the load request message received by the 110 monitoring device includes the incident time if the review request included it. Method 700 continues with a step of identifying one or more trip data fragments to upload based on their activity indices and the trip ID, incident type, and / or incident time (block 720). Specifically, the monitoring device's processor 200 identifies the trip data fragments associated with the trip identified by the trip ID in the upload request message. Then, processor 200 identifies one or more of these trip data fragments—preferably a subset of all trip data fragments associated with the trip—to be uploaded in response to the upload request message. Processor 200 identifies the one or more trip data fragments to be uploaded based on the activity indices of the trip data fragments associated with the trip.In one mode, the 200 processor identifies those travel data fragments associated with the trip that have an activity index exceeding a predetermined threshold and selects those to be loaded. In another mode, the 200 processor identifies those travel data fragments associated with the trip that have the highest activity indexes for the trip and selects a predetermined number or percentage (for example, the top 20%) of the travel data fragments with the highest activity indexes to be loaded. 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 one or more trip data fragments 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 one or more trip data fragments to be uploaded, giving greater weight to the activity indices for certain sensor data types and lesser or no weight to the activity indices for other sensor data types. For example, if the incident type indicates that an argument occurred, then the 200 processor identifies the one or more trip data fragments to be uploaded based only on the audio activity indices, ignoring the video activity indices.As another example, if the incident type indicates that physical violence occurred, then the 200 processor identifies the one or more travel data fragments to be loaded, giving greater weight to video activity indices and lesser 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 one or more travel data fragments to be loaded. If the upload request message includes an incident time that roughly identifies when the incident occurred during the trip, then Processor 200 identifies the one or more trip data fragments to be uploaded based on the activity indices of the trip data fragments associated with the trip and the incident time (pc i trnn / eznz / e / YiAi). Specifically, Processor 200 identifies the one or more trip data fragments to be uploaded as those that correspond to the incident time (for example, start, middle, end, or a specific time) and have higher activity indices (for example, the top 20%) or activity indices greater than a threshold. Method 700 continues with a step of uploading the identified trip data fragments to the cloud storage backend 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 trip data fragments to the cloud storage backend 120. Similarly, the cloud storage backend's processor 302 operates the network communication module(s) 308 to receive the trip data fragments associated with the particular trip. The cloud storage backend's processor 302 stores the received trip data fragments on the cloud storage devices 320, thereby making the trip data fragments available to the mobility service provider for review. Method 700 continues with a step of moving the remaining trip data fragments associated with the trip ID to the secure storage table (block 740). Specifically, the monitoring appliance 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 ring buffers 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 appliance 110 can upload all the remaining trip data fragments. While the disclosure has been illustrated and described in detail in the drawings and the preceding description, it should be considered illustrative and not restrictive. It is understood that only preferred embodiments have been presented and that it is desired that all changes, modifications, and additional applications within the spirit of the disclosure be protected.

Claims

1. A system for monitoring journeys in a vehicle, the system characterized in that it comprises: at least one sensor disposed in the vehicle and configured to capture sensor data during journeys; a first transceiver configured to communicate with a remote server; a non-volatile memory configured to store data; and a processor operatively connected to the at least one sensor, the first transceiver, and the memory, the processor being configured to: receive sensor data from the at least one sensor captured during each of a plurality of journeys in which a driver of the vehicle picks up a passenger at a pickup location and drives the passenger to a drop-off destination; store, in the non-volatile memory, the sensor data captured during each of the plurality of journeys;and upload, via the first transceiver, a portion of the sensor data captured during a respective trip of the plurality of trips to the remote server in response to one of a defined set of triggering events that occur.; 2. The system according to claim 1, the processor characterized in that it is further configured to: implement, in the non-volatile memory, at least one ring buffer configured to manage the storage and deletion of sensor data captured by the at least one sensor, each of the at least one ring buffer being configured to store a respective amount of sensor data corresponding to the respective duration of time; and store, as new sensor data is captured by the at least one sensor, the new sensor data in the at least one ring buffer and delete the sensor data stored in the oldest at least one ring buffer.

3. The system according to claim 2, the processor characterized in that it is further configured to: implement, in the non-volatile memory, a first ring buffer of the at least one ring buffer configured to manage the storage and deletion of sensor data captured by a first sensor of the at least one sensor, the first ring buffer being configured to store a first amount of sensor data corresponding to a first duration of time;and implement, in non-volatile memory, a second ring buffer of at least one ring buffer configured to manage the storage and deletion of sensor data captured by a second sensor of at least one sensor, the second ring buffer being configured to store a second amount of sensor data corresponding to a second duration of time that is different from the first duration of time.; 4. The system according to claim 2, the processor being 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, in response to one of the defined set of trigger events that occur, the portion of the sensor data captured during the respective trip from the at least one ring buffer to the data structure.

5. The system according to claim 4, the processor being further configured to: in response to the successful loading of the portion of the sensor data captured during the respective trip to the remote server, remove the portion of the sensor data from the data structure.

6. The system according to claim 2, the processor being 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, in response to one of the defined set of activation events that occur while the sensor data cannot be uploaded to the remote server, the portion of the sensor data captured during the respective journey from the at least one ring buffer to the data structure.

7. The system according to claim 1, the processor characterized in that it is further configured to: detect that an accident has occurred during the respective trip; and upload, by means of the first transceiver, the portion of the sensor data captured during the respective trip to the remote server in response to the detection that the accident has occurred during the respective trip, wherein the accident that occurs during the respective trip is one of the defined set of activation events.

8. The system according to claim 1, characterized in that it further comprises: pc i trnn / eznz / e / YiAi an acceleration sensor disposed in the vehicle and configured to measure vehicle accelerations during the plurality of journeys, wherein the processor is configured to detect the accident based on the vehicle accelerations.

9. The system according to claim 1, the processor being further configured to: receive, by means of the first transceiver, a request message from the remote server, the request message identifying the respective trip; and upload, by means of the first transceiver, the portion of the sensor data captured during the respective trip to the remote server in response to the receipt of the request message identifying the respective trip, wherein receiving the request message identifying the respective trip is one of the defined set of activation events.

10. The system according to claim 1, characterized in that the at least one sensor includes at least one of: a first camera disposed in the vehicle and configured to capture video of an interior of the vehicle; a second camera disposed in the vehicle and configured to capture video of an exterior of the vehicle in a driving direction of the vehicle; and at least one microphone disposed in the vehicle and configured to capture audio from the interior of the vehicle, wherein the sensor data includes video of the interior of the vehicle, video of the exterior of the vehicle, and audio from the interior of the vehicle.

11. A method for monitoring trips in a vehicle, the method characterized in that it comprises: capturing, with at least one sensor disposed in the vehicle, sensor data during each of a plurality of trips in which a driver of the vehicle picks up a passenger at a pickup location and drives the passenger to a drop-off destination; storing the sensor data captured during each of the plurality of trips in non-volatile memory; and uploading, by means of a first transceiver, a portion of the sensor data captured during a respective trip of the plurality of trips to the remote server in response to one of a defined set of triggering events that occur.

12. The method according to claim 11, the storage characterized in that it further comprises: implementing, in the non-volatile memory, at least one ring buffer pc i trnn / eznz / e / YiAi configured to manage the storage and deletion of sensor data captured by the at least one sensor, each of the at least one ring buffer being configured to store a respective amount of sensor data corresponding to the respective time duration; and storing, as new sensor data is captured by the at least one sensor, the new sensor data in the at least one ring buffer and deleting the sensor data stored in the at least one ring buffer that is the oldest.

13. The method according to claim 12, the storage characterized in that it further comprises: implementing, in the non-volatile memory, a first ring buffer of the at least one ring buffer configured to manage the storage and deletion of sensor data captured by a first sensor of the at least one sensor, the first ring buffer being configured to store a first amount of sensor data corresponding to a first duration of time;and implement, in non-volatile memory, a second ring buffer of the at least one ring buffer configured to manage the storage and deletion of sensor data captured by a second sensor of the at least one sensor, the second ring buffer being configured to store a second amount of sensor data corresponding to a second duration of time that is different from the first duration of time.; 14. The method according to claim 12, characterized in that it further comprises: implementing, in the 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, in response to one of the defined set of triggering events that occur, the portion of the sensor data captured during the respective trip from the at least one ring buffer to the data structure.

15. The method according to claim 14, characterized in that it further comprises: removing, in response to the successful upload of the portion of the sensor data captured during the respective trip to the remote server, the portion of the sensor data from the data structure.

16. The method according to claim 12, characterized in that it further comprises: implementing, in non-volatile memory, a data structure configured to store sensor data that is not to be deleted for at least a predetermined amount of time; and moving, in response to one of the defined set of activation events that occur while the sensor data cannot be uploaded to the remote server, the portion of the sensor data captured during the respective journey from the at least one ring buffer to the data structure.

17. The method according to claim 11, characterized in that it further comprises: detecting that an accident has occurred during the respective trip; and uploading, by means of the first transceiver, the portion of the sensor data captured during the respective trip to the remote server in response to the detection that the accident has occurred during the respective trip, wherein the accident that occurs during the respective trip is one of the defined set of activation events.

18. The method according to claim 11, characterized in that it further comprises: receiving vehicle accelerations during travel from an acceleration sensor arranged in the vehicle, detecting the accident based on the vehicle acceleration.

19. The method according to claim 11, characterized in that it further comprises receiving, by means of the first transceiver, a request message from the remote server, the request message identifying the respective trip; and uploading, by means of the first transceiver, the portion of the sensor data captured during the respective trip to the remote server in response to the receipt of the request message identifying the respective trip, wherein receiving the request message identifying the respective trip is one of the defined set of activation events.

20. The method according to claim 11, characterized in that the at least one sensor includes at least one of: a first camera disposed in the vehicle and configured to capture video of an interior of the vehicle; a second camera disposed in the vehicle and configured to capture video of an exterior of the vehicle in a driving direction of the vehicle; and at least one microphone disposed in the vehicle and configured to capture audio from the interior of the vehicle, wherein the sensor data includes video of the interior of the vehicle, video of the exterior of the vehicle, and audio from the interior of the vehicle.

Images