A system and method for tracking historical driver data at the edge.

Abstract

Driver insurance and risk management scores are calculated for each driver based on vehicle and driver behavior data collected during driving sessions. Often, a single vehicle is shared by multiple drivers, or one driver operates multiple vehicles. This disclosure securely tracks individual drivers, stores and retrieves relevant driver data, and analyzes it in near real-time at the edge (vehicle). The collected data is analyzed at various time intervals (each trip, daily, monthly) to generate scores. The goal of the proposed solution is to minimize costs associated with data transmission and cloud storage, track drivers' long-term driving history at the edge for near real-time analysis of driver behavior, minimize driver distraction by user devices while driving, securely store and retrieve driver driving data on edge devices associated with the driver, restrict driver access to driving data, and restrict user devices' access to servers and telematics units.

Description

Technical Field

[0001] Priority Claim This patent application claims the priority of U.S. Provisional Application No. 63 / 515,272 entitled "Systems and Methods for Tracking Historical Driver Data on the Edge" filed on July 24, 2023, which is expressly incorporated herein by reference.

[0002] The present disclosure generally relates to systems, apparatuses, and methods for tracking historical driver data of vehicles. Background Art

[0003] Currently, vehicle management companies rely on complex processes involving duplicate systems and paperwork that are heavily dependent on human effort to associate fleet vehicle drivers with specific vehicles. In "fleet use cases", out-of-band communication is used to associate drivers with vehicles using cloud infrastructure (backend systems). Vehicle management companies manually update the backend system to reflect the association between drivers and vehicles. An edge telematics device periodically transmits vehicle and driver data to the backend system during a driving session. The backend system calculates driver scores using the received data and the out-of-band association mapping between drivers and vehicles. In "personal line use cases", attempts are made to identify drivers using the driver's smartphone, but when there are multiple drivers in the vehicle, such systems cannot correctly identify the actual driver among the persons in the vehicle. Since out-of-band communication is required for driver identification, vehicle and driver data are stored in the cloud for analysis.

[0004] The above process requires a lot of manual processing and review. Accordingly, there is a need for an automated system and method that reduces manual processing and review and tracks historical driver data of vehicles. [Overview of the project]

[0005] Below are simplified overviews of one or more implementation examples to provide a basic understanding of several implementations. These overviews are not intended to be a comprehensive overview of all possible implementations, nor are they intended to identify the main or important elements of all implementations, nor to define the scope of some or all implementations. Their sole purpose is to present some concepts from one or more implementations in a simplified form as a preliminary step to the more detailed explanations provided later.

[0006] According to one embodiment, one or more non-temporary computer-readable media are provided that store computer-executable instructions that cause one or more processors on a telematics unit to perform an operation at runtime. The telematics unit performs the following steps: acquiring vehicle speed using an on-board sensor system mounted in the vehicle; calculating a first difference between vehicle speed and a predetermined speed stored in non-volatile memory using one or more processors coupled to the on-board sensor system; acquiring trip duration using the on-board sensor system; calculating a second difference between trip duration and initial start duration using one or more processors coupled to the on-board sensor system; capturing an image of the driver using an image capture device coupled to the one or more processors, wherein the image is captured when the vehicle speed is greater than the initial start speed; measuring one or more head position angles of the driver using one or more processors coupled to the on-board sensor system; sending a driver authentication request to a user device when the one or more processors indicate one or more head position angles that indicate the driver is facing forward inside the vehicle; receiving a driver authentication status from the user device; and sending the driver authentication status to a server that communicates with the one or more processors.

[0007] 1. The image capture device is selected from a digital camera, a video camera, and a mobile phone, and is one or more non-temporary computer-readable media according to claim 1. 2. The driver authentication request comprises a user ID and an image of the driver, in one or more non-temporary computer-readable media according to claim 1.

[0008] 3. The user device performs facial image recognition of the driver's image in one or more non-temporary computer-readable media according to claim 3.

[0009] 4. One or more non-temporary computer-readable media according to claim 4, wherein the user history is activated when the driver authentication status is successful.

[0010] 5. One or more non-temporary computer-readable media according to claim 4, wherein the user history is invalidated if the driver authentication status fails.

[0011] 6. The above operation further, The steps include receiving a driver authentication success message from the user device when the driver's image verification is successful, The one or more non-temporary computer-readable media according to claim 6, comprising the step of sending a driver authentication success message along with a timestamp to a storage server when the driver's image has been verified.

[0012] 7. The above operation further, The steps include receiving a driver authentication failure message from the user device when the verification of the driver's image fails, One or more non-temporary computer-readable media according to claim 7, comprising the step of sending a driver authentication failure message to a server. [Brief explanation of the drawing]

[0013] [Figure 1]Figure 1 shows an exemplary architecture for generating and calculating a driver's driver insurance and risk management score based on vehicle data and driver behavior data collected during a driving session, according to various aspects of this disclosure. [Figure 2] Figure 2 is a flowchart showing the user device login verification sequence for verifying user device and driver login authentication information using a telematics unit and a remote server. [Figure 3] Figure 3 is a flowchart illustrating the login verification process for user devices. [Figure 4] Figure 4 is a flowchart illustrating the user device login verification process for the telematics unit (TU). [Figure 5] Figure 5 is a flowchart illustrating the login verification of user devices on the server. [Figure 6] Figure 6 is a flowchart showing the system pairing sequence. [Figure 7] Figures 7A-7B are flowcharts showing the flow of the telematics unit (TU) in system pairing. [Figure 8] Figure 8 is a flowchart showing the flow of user devices in system pairing. [Figure 9] Figure 9 is a flowchart showing the flow of the remote server in system pairing. [Figure 10] Figure 10 is a flowchart showing the driver authentication sequence. [Figure 11] Figure 11 is a flowchart showing the flow of the TU (User Unit) for driver authentication. [Figure 12] Figure 12 is a flowchart showing the flow of user equipment for driver authentication. [Figure 13] Figure 13 is a flowchart showing the flow of the remote server for driver authentication. [Figure 14] Figure 14 shows the historical driver data formatted as the data structure for each user ID. [Figure 15]15A to 15B are flow diagrams illustrating a historical driver data search sequence. [Figure 16] Figure 16 is a flow diagram illustrating the flow of user equipment for historical driver data search. [Figure 17] 17A to 17B are flow diagrams illustrating the flow of a TU for historical driver data search. [Figure 18] Figure 18 is a flow diagram illustrating the flow of a server for historical driver data search. [Figure 19] Figure 19 is a block diagram of an exemplary hardware implementation of a server module / apparatus configured to communicate in accordance with one or more aspects of the present disclosure. [Figure 20] Figure 20 is a block diagram of an exemplary hardware implementation of a telematics unit configured to communicate in accordance with one or more aspects of the present disclosure. [Figure 21] Figure 21 is a block diagram of an exemplary hardware implementation of user equipment configured to communicate in accordance with one or more aspects of the present disclosure. [Figure 22] Figure 22 is a flow diagram illustrating an alternative system pairing sequence. [Figure 23] Figure 23 is a flow diagram illustrating the flow of a telematics unit (TU) for alternative system pairing. [Figure 24] Figure 24 is a flow diagram illustrating the flow of user equipment for alternative system pairing. [Figure 25] Figure 25A and Figure 25B are flow diagrams illustrating the flow of a remote server for alternative system pairing. MODE FOR CARRYING OUT THE INVENTION

[0014] In the following description, specific details are set forth to provide a thorough understanding of the embodiments. However, it will be understood by those skilled in the art that the embodiments may be practiced without these specific details.

[0015] Terms The term "sensor" can refer to various types of known sensors used to detect the dynamic state of a vehicle. Sensors may be standard equipment or aftermarket. Sensors may include, but are not limited to, mass airflow sensors, engine speed sensors, oxygen sensors, spark knock sensors, coolant sensors, manifold absolute pressure sensors, fuel temperature sensors, voltage sensors, camshaft position sensors, throttle position sensors, vehicle speed sensors or speedometers, proximity sensors, accelerometers, global positioning systems, odometers, steering angle sensors, safety system data, radio detection rangefinding (RADAR), light detection rangefinding (LIDAR), and diagnostic trouble codes.

[0016] The terms "sensor data" and "vehicle sensor data" may refer to data received from any sensor in a vehicle, whether it is standard equipment or an aftermarket addition. An "in-vehicle sensor system" refers to sensors installed in a vehicle that sense the vehicle's dynamic state.

[0017] The terms "server" and "remote server" can be used interchangeably.

[0018] The term "vehicle" refers to, but is not limited to, any type of machine used to transport people or goods, including automobiles, trucks, buses, motorcycles, airplanes, and helicopters.

[0019] The terms "driver" and "user" can be used interchangeably.

[0020] "Telematics devices" and "telematics units" refer to combinations of telecommunications and information technology for sending and receiving data over long distances.

[0021] As used herein, the term “edge” refers to a device, unit, or module located at the edge of a network that collects data and transmits it to a central system or server. Processing data locally at edge devices, such as telematics units, before transmission improves the efficiency of data transmission and analysis and reduces latency.

[0022] A "risk event" refers to any event or incident that occurs while driving and negatively impacts the driver's performance, and is not limited to such events, but may include: braking at a specific speed, accelerating at a specific speed, tailgate time before a collision, cornering at a specific speed, trip time, trip distance, failure to stop at a stop sign, slow stopping, complete stop, speeding in miles, trip cost, trip start time, trip stop time, trip status, and trip score.

[0023] Some of the methods described in this book can be implemented in hardware such as servers, user devices, and telematics units. Each of these devices determines whether a risk event has occurred, generates a driver score, and transmits accident data to emergency response vehicles via mobile phones or other network communications.

[0024] As used herein, the term “computer-readable medium” refers to any tangible storage involved in providing execution instructions to a processor. Such mediums include, but are not limited to, various forms such as non-volatile media, volatile media, and transmission media. Non-volatile media include NVRAM, magnetic disks, optical disks, etc. Volatile media include dynamic memory such as main memory. Common forms of computer-readable media include, for example, floppy disks, flexible disks, hard disks, magnetic tapes, other magnetic media, magneto-optical media, CD-ROMs, other optical media, punch cards, paper tapes, other physical media with hole patterns, RAM, PROMs, EPROMs, FLASH-EPROMs, solid-state media such as memory cards, other memory chips or cartridges, or other computer-readable media. If the computer-readable medium is configured as a database, it should be understood that the database can be any type of database, such as relational, hierarchical, or object-oriented. Accordingly, this disclosure is considered to include tangible storage media on which software implementations of this disclosure are stored, and their equivalents and successor media recognized in the prior art.

[0025] The terms “central processing unit,” “processor,” “processor circuit,” and “processing circuit” and their variations as used herein are interchangeable and include, but are not limited to, general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs) or other programmable logic components, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. General-purpose processors may include, in addition to microprocessors, conventional processors, controllers, microcontrollers, and state machines. Furthermore, processors can be implemented as combinations of computing components, such as combinations of DSPs and microprocessors, multiple microprocessors, one or more microprocessors combined with a DSP core, and ASICs and microprocessors, and many other various configurations are possible. These examples of processors are for illustrative purposes only, and other suitable configurations within the scope of this disclosure are also assumed. In addition, processors may be implemented as one or more processors, one or more controllers, and / or other structures configured to perform executable programming.

[0026] As used herein, the terms “determine,” “calculate,” “generate,” and “operate,” and their variations thereof, are used interchangeably and include any kind of methodology, process, mathematical operation, or technique.

[0027] As used herein, the term “module” refers to known or subsequently developed hardware, software, firmware, artificial intelligence, fuzzy logic, or combination of hardware and software that is capable of performing functions related to its elements.

[0028] The term "user device" may mean a mobile phone, personal computer, smartphone, tablet, portable computer, machine, entertainment device, or other electronic device having a circuit.

[0029] The term "driver" can refer to either a person or a vehicle.

[0030] The term "driver session" can refer to travel in a vehicle by a driver.

[0031] A "trip" can refer to a journey or short trip using a vehicle. A trip begins from a designated starting point, such as home, work, or a specific address, and ends at a destination. The detailed descriptions provided below in relation to the attached drawings are intended to illustrate various configurations and are not intended to show only the configurations in which the concepts described herein can be implemented. The detailed descriptions include specific details to provide a complete understanding of the various concepts. However, it will be apparent to those skilled in the art that these concepts can be implemented without specific details. Sometimes, well-known structures and components are shown in block diagram form to avoid obscuring such concepts. In this specification, a singular reference to an element also implies a reference to a plural element.

[0032] overview Driver insurance and risk management scores are calculated for each individual driver based on vehicle and driver behavior data collected during driving sessions. Often, a single vehicle is shared by multiple drivers, and one driver may operate multiple vehicles. The systems, devices, and methods for tracking historical driver data in vehicles of this disclosure ensure that individual drivers are tracked, and relevant driver data is stored and retrieved in near real-time for analysis at the edge (vehicle). The collected data may be analyzed at various time intervals (e.g., each trip, daily, monthly) to generate scores.

[0033] The systems, devices, and methods for tracking vehicle driving history data described herein minimize costs associated with data transmission and cloud storage, track long-term driving history of drivers at the edge for near real-time analysis of driver behavior, minimize driver distraction by user devices while driving, securely store and retrieve driver driving data on edge devices associated with the driver, restrict access to driver driving data, and restrict user devices' access to remote servers and telematics units.

[0034] In this application, “data at the edge” refers to storing data on telematics units and / or user devices, as opposed to storing data in the cloud.

[0035] Minimizing the costs associated with data transfer and cloud storage. Insurance companies offer vehicle insurance to many customers. Telematics-based premium calculations require access to driver vehicle data. Vehicle data captures various driving risk behaviors acquired through vehicle sensors. Sending all vehicle sensor data to a remote server for analysis, for each customer, each vehicle, and each trip, leads to a significant increase in both transmission and storage costs for insurance companies. In recent years, cars have been equipped with more advanced sensors (advanced driver assistance systems, driver monitoring systems) for safer driving. Because such advanced sensors generate data at a very high frequency, analyzing this data in the cloud can be too costly. The proposed system described below describes a way to store historical driver data at the edge and minimize frequent communication with remote servers.

[0036] Track drivers' long-term driving history at the edge and analyze their behavior in near real-time. Calculating driver scores requires access to past and present driving behavior data for specific drivers and vehicles. As mentioned earlier, drivers may operate multiple vehicles, so it is essential to obtain up-to-date historical driver data in near real-time for the algorithm to analyze. Conventional systems require sending current data to the cloud to analyze the history of all drivers, which requires considerable cloud infrastructure and cost. This disclosure offers the advantage of improved data transmission and analysis efficiency and reduced latency by identifying drivers and securely storing and retrieving their driving data at the edge.

[0037] Minimizing driver distraction caused by user devices while driving. It is well known that distraction is a major cause of accidents. Placing user devices in an in-vehicle docking station, as in this disclosure, makes them easily accessible, visualized, and can act as a deterrent by providing an audible alert to the driver if the user device is removed while the vehicle is in motion.

[0038] Securely store and retrieve driver driving data on edge devices associated with the driver. In the systems, methods, and apparatus of this disclosure, driver history driving data is stored on the user device. The data on the user device is encrypted, and no entity or individual can easily view or edit the data stored on the user device. The encryption / decryption keys for the encrypted data are managed by a remote server. Neither the user device nor the telematics unit (TU) can independently view or edit the driver data. The driver data is only accessible when the following conditions are met: (1) the user is logged into the remote server, (2) the user device is in the vehicle, (3) the user device is paired with and authenticated by the TU in the vehicle, and (4) the driver is identified using biometric authentication such as facial recognition. When these conditions are met, the TU can receive the driver data stored on the user device and decrypt it using the key provided by the remote server. This unique process enhances security and allows for the secure handling of personally identifiable information of the driver.

[0039] Restrictions on access to driver's driving data Driver data can only be retrieved and decrypted if the driver associated with the data is present in the vehicle and identified using biometric authentication such as facial recognition. Driver driving history data is stored on the driver's user device and a remote server. The data is encrypted by the TU before being shared between the user device and the remote server. Security and privacy are further enhanced because the key is managed only on the remote server and can be changed at the end of each driving session.

[0040] Restrictions on user device access to remote servers and telematics units The unique method of this disclosure includes a series of authentication and verification steps. Each step requires the success of the previous step to proceed. These steps include (1) the driver connecting to a remote server for authentication using a user device, (2) a system pairing process authenticating and verifying the user device with the TU and the remote server, and (3) identifying the user at the edge using biometric authentication such as facial recognition. These steps ensure that the driver and user device are authenticated step by step, restricting insecure access to the TU and the remote server. Restricting communication from the user device to the TU to short-range communication limits malicious access to the vehicle network from outside the vehicle. In addition, an audit trail of the user device's access to the TU is also tracked on the remote server.

[0041] Additional novel aspects of this disclosure include (1) three-way system authentication and verification, (2) independent communication paths between user equipment, TU, and remote servers, (3) storage of driver history driver data at the edge, (4) minimization of data transfer and storage on remote servers, (5) unique entity-generated IDs (keys) for session-based authentication, (6) session-based shared driver authentication, and (7) individual protection of each driver's data.

[0042] In three-way system authentication and verification, the system has a three-stage authentication process. First, the user is authenticated by the remote server using an application running on the user's device. Second, there is system-level pairing and authentication between the user's device, the TU, and the remote server. Third, there is driver recognition through biometric authentication such as facial recognition at the edge.

[0043] Through independent communication paths between the user device, the TU, and the remote server, this disclosure provides asynchronous communication of data for authentication. For example, the TU transmits verification data specific to the user device via a short-range communication path and shares the same data with the remote server. The remote server then requests the user device to transmit the same data via a wide-area network (WAN) communication path and uses the data received independently from both devices via different paths to verify and authenticate the user device's access to the TU and the remote server.

[0044] By storing driver history data at the edge, this disclosure provides a way to store driver history data on the driver's user device. When a driving session begins, the TU requests the driver's history data from the user device, then sends a request for a decryption key to a remote server to decrypt the history data and update it based on driving risk events. Once the trip is complete, the TU encrypts the history data using the key provided by the remote server and sends the encrypted history data to the user device and the remote server for storage. This disclosure uses driver authentication with biometric identification, such as facial recognition, to ensure that the correct driver data is retrieved and updated. Separating the symmetric key and data storage further enhances security because both must cooperate for the data to be read correctly.

[0045] In this disclosure, neither the user device nor the TU can decrypt and update the historical driver data unless the driver and the driver's user device are inside the vehicle and have already gone through the three-step authentication process.

[0046] This disclosure provides several approaches to minimize data transfer to a remote server. For example, instead of activating the TU and communicating with the remote server, once the TU recognizes the presence of user equipment in the docking station within the vehicle, the TU waits for the user equipment to indicate that the remote server has successfully authenticated the driver authentication information. If the TU can obtain historical driver data from the driver's user equipment, the TU does not need to request historical driver data from the remote server, significantly reducing data transfer. Furthermore, communication between the TU and the remote server begins only after the vehicle has reached a predefined speed and distance, rather than when the user equipment is placed in the docking station or the vehicle's ignition is turned on.

[0047] Session-based authentication uses a unique entity-generated identifier (ID), such as a single symmetric key, to allow the remote server and the TU to generate a new random ID or key, share it with the other two entities, and send back an acknowledgment. This allows the originating entity to verify that it is communicating with the correct remote end that sent the random ID or key.

[0048] Through session-based shared driver authentication, this disclosure provides session-based shared driver identification responsibility between the edge user device (such as a smartphone) and the TU. The TU takes an image of the cabin (or interior), crops the image to include only the driver's face, and transmits the image to the user device via NFC or a near-field communication-enabled mount. Driver authentication is performed on the user device, and the authentication result is shared with the TU.

[0049] By protecting each driver's data independently, each driver possesses their own single symmetric key, which is stored only on a remote server.

[0050] Figure 1 shows an exemplary architecture 100 for generating and calculating a driver's driver insurance score and risk management score based on vehicle data and driver behavior data collected during a driving session, in which embodiments of the system and method of the present disclosure can be seen. The system includes a user device 104, a device docking station 106, a telematics unit 108, and a communication network 102 connecting a remote file system or server 110. The user device 104, the device docking station 106, the telematics unit 108, and the remote server 110 are described in detail below.

[0051] The user device 104 communicates with the device docking station 106 (hereinafter referred to as the "docking station") via a short-range communication means such as NFC (Near Field Communication) or USB. The docking station 106 is equipped with wireless charging and USB power and is installed inside the vehicle near the driver to facilitate display visibility and interaction with the driver. If the user device 104 is removed from the docking station 106 while the vehicle is in motion, the user device 104 generates an audible alarm and an appropriate driver risk event is generated. The docking station 106 may be connected to the telematics unit (TU) 108 using Wi-Fi, a physical serial interface (USB), or Bluetooth. The user device 104 communicates with the TU 108 via the docking station 106 to ensure that the user device 104 is always on the docking station 106 inside the vehicle. Ensuring that the user device 104 is always on the docking station 106 has at least two advantages. First, distraction by the user device is suppressed, and it is ensured that the user device 104 is located in the same vehicle as the TU 108 to which it is connected. The TU 108 and the user device 104 communicate independently with the remote server 110 via a wide-area network-based communication technology such as LTE (Long-Term Evolution). The communication system 100 may employ at least two different communication paths between the remote server 110, the TU 108, and the user device 104 so that data received from the user device can be independently verified. The communication system 100 may also implement industry-standard communication security measures, such as private / public keys for end-to-end encryption and transport layer security protocols to protect end-to-end communication.

[0052] Communication between some or all of the apparatus, devices, systems, functions, modules, and servers described herein may occur via one or more wired and / or wireless communication networks 102. Examples of communication networks 102 include public switched telephone networks (PSTN), wide area networks (WANs), local area networks (LANs), TCP / IP data networks such as the Internet, and wireless networks such as 3G, 4G, LTE, and 5G networks established by the Third Generation Partnership Project (3GPP). Communication network 102 may be one or more of the aforementioned communication networks, or any combination thereof.

[0053] Figure 2 is a flowchart 200 showing a user device login verification sequence for verifying user device and driver login credentials using a telematics unit and a remote server. The user device login verification sequence establishes the initial connection between the user device, the telematics unit, and the remote server, verifies the user device's login credentials, and determines whether the telematics unit needs to be started.

[0054] First, the user device is placed in the vehicle's mount or docking station and connected to the telematics unit. Upon successful login, the Near Field Communication (SRCC) connection is enabled (202). Next, the user device sends login information (i.e., user ID and user device ID) to the remote server along with the user device's GPS location information (i.e., the user device's location) and a timestamp indicating the country from which the login information was requested. The remote server verifies the login credentials (204). The GPS location information (i.e., the user device's location) and timestamp help to double-check and confirm that the TU and the user device's locations and session time are the same. The remote server then verifies the user login credentials (206) and sends either a login success status message (208) or a login failure status message (210) to the user device. In case of login failure, the user device displays an error and the sequence ends (212).

[0055] If the login is successful, the remote server generates an authentication identifier (ID) and stores the ID along with the login authentication information on the user device (214). Next, the remote server sends an authentication ID to the user device indicating that the login has been authenticated (208). Next, the user device starts the TU and sends the same information (user ID, user device ID, GPS location) to the TU along with the authentication ID (216). Next, the TU sends a ready message to the remote server containing its telematics unit ID, GPS location information, and timestamp (218).

[0056] When the remote server receives this information from the TU, the remote server generates a random key for the session (i.e., a docking station key) to be used to verify the TU's communication (220), and writes or records this key in the remote server's memory or database (222). The key is then sent or transferred from the remote server to the TU (224), and the docking station key is written or recorded in the TU's storage / memory (226). This sequence ensures that the login is successfully authenticated by the remote server and that a key is generated for secure communication between the TU and the remote server.

[0057] Figure 3 is a flowchart illustrating user device login verification (300). To initiate the verification process (302), the driver places the user device on an NFC dock (i.e., docking station) that communicates with the telematics unit (304) so ​​that the driver can log in. Next, the user device sends login information, GPS location (i.e., the user device's location), and a timestamp to the TU (306) and waits to receive login authentication from the TU (308). If login fails, the user device receives a failure message from the TU and displays an error message on the user device's display screen (310). If login is successful, the user device receives a success message along with the authentication ID for the driving session (312). Next, the user device displays the login success message (314) and starts the TU (316). Once the TU is started, the user device sends all relevant information to the TU along with the authentication ID (318). The relevant information includes the user ID, user device ID, GPS location information, and authentication ID.

[0058] Figure 4 is a flowchart (400) illustrating the user device login verification process in the telematics unit (TU). The TU starts in an off state (402) and is turned on only upon successful login (404). Next, the user device sends a ready message to the remote server containing the TUID, GPS location (i.e., the user device's location), and a timestamp (406). After sending the ready message, the TU waits until it receives a randomly generated docking station key from the remote server and writes / records / saves the docking station key to storage / memory (408).

[0059] Figure 5 is a flowchart (500) showing the user device login verification process on the remote server. Upon initiation (502), the remote server waits for the user device to send login information (i.e., user ID, user device ID, password, GPS location, and timestamp) (504). Upon receipt, the remote server verifies the user authentication information using the authentication information stored on the remote server (506). Next, it is determined whether this authentication information is valid (508). If the authentication information is not valid, the remote server sends a login failure status message to the user device, and the sequence ends (i.e., login failure) (510). If the authentication information is valid and the login is successful, the remote server generates and stores an authentication ID and sends the authentication ID to the user device along with the login success status (512). Next, the remote server waits for a ready message from the TU containing the TUID, GPS location, and timestamp (514). When the remote server receives a ready message, TUID, GPS location, and timestamp from the TU, the remote server generates a docking station key, stores the key in storage / memory / database, and sends the key to the TU (518).

[0060] Figure 6 is a flowchart illustrating the system pairing sequence 600. System pairing establishes a three-way system identification between the remote server, the telematics unit (TU), and the user equipment. Upon successful completion of system pairing, each device (i.e., the user equipment) recognizes the ID of the other devices it is communicating with. System pairing is achieved by the TU (random pair key) and the remote server (docking station key) each generating their own random key for each session request, and sharing these keys asynchronously over different communication paths based on a request / response scheme.

[0061] This approach is a two-step process in which the user device is physically connected to the TU's docking station in the vehicle via a near-field communication connection, and is verified to be connected to the correct TU when requested. First, the TU verifies that the user device is authenticated by the remote server and connected via near-field communication. Next, the remote server individually verifies the identities of both the TU and the user device, enabling communication not only between the TU and the user device but also with the remote server for that driving session. At the start of each driving session, a new unique key is generated so that old keys are not used for communication between entities / devices.

[0062] When a TU is activated for communication, a random pair key is generated (602). Each TU generates its own random pair key for each session and shares the initial random pair key with user devices connected via near-field communication means (such as NFC) and with remote servers via cloud connectivity. The TU then requests user device details from the connected user device via near-field communication (604). Requesting details via near-field communication ensures that the connected user device is inside a vehicle and docked at the TU's docking station.

[0063] Next, the user device sends the Login Remote Server Authenticated User ID, User Device ID, Authentication ID, and Login Status to the TU (606). The User ID is unique to each user or driver of the user device and is authenticated during the user device's login operation session. The Authentication ID generated by the remote server is unique for each user device's login operation session. The user device also shares the Login Status. The TU then sends the connected user ID, user device ID, authentication ID, and Login Status to the remote server for further verification of the information provided by the user device (608). The remote server then attempts to retrieve the Login Status for the provided User ID, User Device ID, and Authentication ID from the data stored in the remote server's database (610). The remote server then compares the retrieved Login Status with the provided Login Status to verify that the Status is correct and returns the Login Status to the TU (612). If the returned Login Status is successful (True), the TU also notifies the user device that the login has been verified (614).

[0064] If the login status is successful, the TU sends a system pairing request to the remote server, including the user ID, user device ID, TUID, docking station key generated by the remote server, random pair key generated by the TU, GPS location, and pair timestamp 616. When the remote server receives the TU's system pairing request, the remote server sends a system pairing request to the user device via the cloud connection (618) and stores the data in the remote server's database / memory for future comparison.

[0065] When the user device receives a pairing request from the remote server device, it requests pairing information from the TU via the near-field communication connection (620). This keeps the user device connected to the TU via the near-field communication connection. The TU then sends the docking station key, a copy of the random pair key, and the pair timestamp provided by the remote server to the user device via the near-field communication connection (622). After receiving the details / information from the TU, the user device sends a pairing response to the remote server via the cloud connection, including the user ID, user device ID, pair timestamp, a copy of the random pair key, and the docking station key (624). The remote server stores the data received from the user device and then verifies the responses received individually from the TU and the user device by comparing the data sent by the user device and the TU, including the copy of the random pair key sent by the user device and the random pair key generated by the TU (626). In other words, the remote server compares the data from the TU with the data from the user device to verify that all three connected entities / devices are authenticated, can communicate asynchronously and in near real-time, and share a unique random key generated by the TU and the remote server. The random key pair and a copy of the random key pair are sent asynchronously to the remote server.

[0066] If the system pairing request is validated successfully, the remote server may send the device pairing success status, user ID, user device ID, and docking station key to the TU (628). The TU may then send a system pairing success message (or device pairing success message) to the user device via the short-range communication connection (630).

[0067] If the verification of the system pairing request fails, the remote server sends the device pairing failure status, user ID, user device ID, and docking station key to the TU (632). The TU then sends a system pairing failure message to the user device via the short-range communication connection (634). The user device then displays an error message on its display screen (636). If the login status returned from the remote server is failed (False) (638), the TU also sends a login failure status message to the user device (640), and the user device displays an error message on its display screen to inform the user / driver (642).

[0068] Figures 7A and 7B are flowcharts illustrating the flow 700 of the telematics unit (TU) for system pairing. When the TU is activated for communication by the user equipment, the TU initiates the process of the system pairing sequence (702). The TU waits for the user equipment to reach a pre-configured start speed and confirms that a trip or driving session has started (704). Users can place their devices in the docking station long before a trip or driving session begins and can detach their user equipment multiple times before the vehicle starts moving. This approach minimizes unnecessary cloud communication, cloud connectivity data costs, and session management workloads on remote servers.

[0069] Once the vehicle reaches a predetermined speed, the TU further waits for the vehicle to travel a predetermined distance to confirm that the actual trip has begun (706). The predetermined speed and distance may be set by the employer or manager. For example, the predetermined speed is 20 miles per hour and the predetermined distance is 1 mile. The TU then generates a new unique random pair key for the trip session (708), stores the key, and sends the initial random pair key to the user's device (710).

[0070] Next, the TU sends a request for user device details to the user device via the Near Field Communication Connection (SRCC) (712) and waits for a response from the user device. This request is sent via SRCC to confirm that the user device is on the docking station and communicating with the TU while it is physically connected. Once the user device details (user ID, user device ID, login status, and authentication ID) are successfully received from the user device via SRCC (714), the TU sends a login status verification request to the remote server via the cloud connection (716). The login status verification request includes the TU ID, user ID, user device ID, login status, and authentication ID. The login status is then received from the remote server (718). Next, a determination is made regarding the success of the login and / or device pairing (720). If the login and / or device pairing fails, a failure message is sent to and displayed on the user device (722).

[0071] When the TU receives a login status success message from the remote server via the cloud connection, the TU sends a login status success message to the user device via SRCC. Next, the TU sends a system pairing request to the remote server via the cloud connection. The message includes the user ID, user device ID, TUID, docking station key, GPS location (user device location), pair timestamp, and random pair key (724). When the TU receives a pairing information request from the user device (726), it sends the docking station key, its own random pair key, and pair timestamp to the user device (728).

[0072] When the TU receives a pairing status success from the remote server (730), it verifies that the device pairing success message contains the original parameters sent to the remote server (732). If device pairing is successful, the TU receives the user ID, user device ID, and docking station key from the remote server (734). The TU then sends a system (or device) pairing success message to the user device via SRCC (736), and driver authentication is enabled (738).

[0073] Alternatively, if the TU receives a pairing status failure from the remote server, it verifies that the success message contains the original parameters sent to the remote server for verification (740), and sends a system pairing failure message to the user device via SRCC (742). The pairing failure message invalidates driver authentication (744).

[0074] Figure 8 is a flowchart showing the user device flow 800 for system pairing. First, the user device logs on to the remote server (802). Once the user device has successfully logged on to the remote server, it waits for the TU to request user device details (804). Upon receiving the user device details request from the TU via SRCC, the user device sends the user ID, user device ID, login status, and authentication ID back to the TU via SRCC (806). The TU independently verifies with the remote server whether the user device has been authenticated by the remote server in order to restrict unauthorized access by malicious user devices attempting to access the TU.

[0075] Next, the user device waits for a login status verification response from the TU via SRCC (808) and determines whether the login was successful (810). If the TU returns a login status failure message, the user device displays an error message to the user and terminates the pairing process (812). Once the user device receives a login status success message from the TU, it waits for a system pairing request from the server via the cloud connection (814).

[0076] Upon receiving a system pairing request from a remote server, the user device sends a pairing information request to the TU via SRCC (816). Once the pairing information (docking station key, random pair key, pair timestamp) is received from the TU via SRCC (818), the TU responds to the pairing request from the remote server by sending a pairing response message to the server via the cloud connection (820). This message includes the user ID, user device ID, pair timestamp, a copy of the random pair key, and the docking station key. Importantly, the TUID is never shared with the user device; instead, a random pair key generated by the TU and based on the operation session is shared with the user device. The user device does not receive any permanently identifiable information from either the server or the TU.

[0077] Next, the user device waits for a system pairing status message from the TU via SRCC (822) and determines whether the device pairing was successful (824). If a system pairing failure message is received from the TU via SRCC, the user device displays an error message on its display screen (826), the process terminates, driver authentication is not performed, and the user device is disabled (828).

[0078] When the user device receives a system pairing success message from the TU via SRCC, it enables the next step, driver authentication (830).

[0079] Figure 9 is a flowchart showing the remote server flow 900 of system pairing. The remote server not only authenticates the TU and user equipment individually, but also acts as a control unit that verifies whether the TU and user equipment can communicate with each other (902). The remote server does this by synchronously receiving common verification data from the TU and user equipment using request / response, and comparing the data to confirm that it is valid and identical. In the first step of user and user equipment authentication, the remote server authenticates the user equipment and waits for the TU to begin verifying the login status.

[0080] Upon receiving a login verification request from the TU (904) that includes the user ID, user device ID, login status, and authentication ID, the remote server compares the received data with the user ID, user device ID, and authentication ID data stored in the database (906) to determine whether the login was successful (908). If they do not match, the login status check fails, and the remote server sends a login status failure message to the TU via the cloud connection, terminating further processing of the system pairing process (910).

[0081] If a match is found, the login status check is successful, and the remote server sends a login status success message to the TU, enabling the system pairing process (910). The remote server then waits for the TU to initiate a system pairing request. Upon receiving a system pairing request from the TU containing the user ID, user device ID, TUID, docking station ID, GPS location, pair timestamp, and random pair key, the remote server stores the data in its database (912).

[0082] Next, the remote server sends a system pairing request to the corresponding user device via the cloud connection, based on the user ID and user device ID provided by the TU's request (914). The remote server then receives a user device pairing response from the corresponding user device via the cloud connection, which includes the user ID, user device ID, pair timestamp, random pair key, and docking station key (916). The remote server then verifies the data provided by the TU and the corresponding data provided by the user device by comparing each parameter and confirming that the docking station key generated by the remote server belongs to the TU requesting the system pairing response (920).

[0083] If verification fails, the remote server sends a system pairing status failure message to the requesting TU via the cloud connection, along with the user ID, user device ID, docking station key received from the user device, and TUID received from the TU (924). If verification is successful, the remote server sends a system (or device) pairing status success message to the requesting TU via the cloud connection, along with the user ID, user device ID, docking station key received from the user device, and TUID received from that TU (922).

[0084] Figure 10 is a flowchart showing the driver authentication sequence 1000. Once the system pairing process is successfully completed, the TU initiates the driver authentication process. First, the TU captures a front-facing image of the driver (1002) and sends a driver authentication request to the user device connected via SRCC (1004). The request includes the driver's image and user ID.

[0085] When the user device receives the driver image and user ID from the TU via SRCC, it retrieves the driver's facial image associated with the authenticated user ID and compares it with the user ID provided by the TU to confirm that the user IDs are the same. Next, the user device performs facial recognition between the stored driver's facial image and the image provided by the TU. If the driver is authenticated successfully, the user device verifies the image / user ID mapping (1006) and sends a driver authentication success message to the TU via SRCC (1008).

[0086] Upon receiving a driver authentication success message from a user device connected via SRCC (1008), the TU sends a driver authentication success message to the remote server via the cloud connection (1010). This message includes the TUID, user ID, user device ID, docking station ID, and optionally a driver image. Upon receiving the driver authentication success message, the remote server saves the success status to its database (1012).

[0087] If driver authentication fails, the user device displays an error message on its display screen (1014) and sends a driver authentication failure message to the TU connected via SRCC (1016). Upon receiving the driver authentication failure message via SRCC, the TU sends the driver authentication failure message to the remote server via the cloud connection (1018). The message includes the TUID, user ID, user device ID, docking station key, and a captured front-facing driver image. Upon receiving the driver authentication failure message, the remote server saves the failure status to its database (1020) and sends a notification to the system administrator for further investigation.

[0088] Figure 11 is a flowchart showing the driver authentication flow 1100 of the TU. Once the system pairing process is successfully completed (1102), the TU may initiate the driver authentication step with the connected user device via the SRCC. The driver authentication process is initiated when the vehicle speed is greater than the initial start speed (1104) and the trip duration exceeds the initial start duration. The TU waits for the trip duration to become longer than the initial start duration (1106) and captures an in-vehicle image of the driver (1108). In other words, an image of the driver is captured when the vehicle starts moving. Next, a face detection model is applied to measure the head position angle (1110), identify the face image, and select and crop the face image on the driver's side of the vehicle so that the TU has only the driver's seat image.

[0089] Next, the TU applies a frontal face detection model to the driver's face image to check if the image is facing forward (1112). If detection fails, this process is repeated until an image of the driver facing forward is captured (1114). If an image of the driver facing forward is successfully captured, the TU sends a driver authentication message to the user device connected via SRCC (1116). This message includes the image of the driver facing forward and the user ID.

[0090] Next, the TU waits for a driver authentication status message from the user device connected via SRCC (1118) and determines whether authentication was successful (1120). Upon receiving a driver authentication success message from the user device, the TU sends a driver authentication success message to the remote server via the cloud connection (1122). The driver authentication success message to the remote server includes the TUID, user ID, user device ID, docking station key, and optionally a driver image. Upon receiving the driver authentication success message from the user device, the TU enables the user history tracking process (1124).

[0091] Upon receiving a driver authentication failure status message from the user device, the TU sends the driver authentication failure message to the remote server via the cloud connection (1126). The driver authentication failure message sent to the remote server may include the TUID, user ID, user device ID, docking station key, and front face image. Upon receiving the driver authentication failure status message from the user device, the TU disables the user history tracking process (1128).

[0092] Figure 12 is a flowchart showing the user device flow 1200 for driver authentication. Upon successful system pairing, the driver authentication process 1202 is enabled. The user device, connected to the TU within the docking station, awaits a driver authentication request message from the TU via SRCC (1204). The message is sent via SRCC, ensuring that the user device is still on the docking station. The user device is configured with a user ID and a corresponding front image of the driver. Each user device can support multiple users. If the user ID is successfully authenticated by the remote server during the user device login verification process, the corresponding user image is decoded and loaded into memory for ID verification.

[0093] The user device receives a driver recognition request from the connected TU via SRCC, which includes a user image and user ID. The user device then compares the user ID provided by the TU with the currently authenticated user ID. If the user IDs are the same, the user device performs facial recognition on the user image provided by the TU and the user image stored in memory (1206) to determine whether the facial image has been identified (1208). If the comparison of the user ID and facial image is successful, the user device sends a driver authentication success message to the TU via SRCC (1210) and enables the user history tracking process using the relevant data (user ID, user device ID, TUID, optional image, identification status). If the comparison of the user ID and facial image fails, the user device sends a driver authentication failure message to the TU via SRCC and disables the user history tracking process (1212).

[0094] Figure 13 is a flowchart showing the remote server flow 1300 for driver authentication. If the automated driver recognition process fails, the remote server may send a manual review request message to the administrator. The administrator can review the user image and update the user equipment with additional user images to improve image recognition. The remote server also updates the database with the authentication status for logging purposes (1302). The remote server receives a driver authentication status message from the TU via a cloud connection. This message includes the TUID, user ID, user equipment ID, docking station key, verification status, and optionally a user image. If verification fails, the image is required (1304). The remote server then stores the received TUID, user ID, user equipment ID, docking station key, timestamp and authentication status, and optional user image in the database (1306).

[0095] Next, it is determined whether driver authentication was successful (1308). If driver authentication fails, the remote server sends an error message to the administrator for further verification (1310) and stores the TUID, user ID, user device ID, timestamp, and authentication status in the unrecognized user table (1312). If driver authentication is successful, the remote server stores the TUID, user ID, user device ID, timestamp, and authentication status in database 1314.

[0096] Figure 14 shows historical driver data formatted as a data structure for each user ID, indexed by GPS location and time. Each GPS location includes, but is not limited to, a timestamp, driver behavior rate, and driver score.

[0097] Figures 15A and 15B are flowcharts illustrating the historical driver data retrieval sequence 1500. The historical driver data retrieval sequence is executed only after a secure connection has been established between the three devices (user device 104, TU 108, and server 110), ensuring secure data transfer. This sequence minimizes data transfer between the user device / TU and the remote server by storing encrypted historical driver data on the user device and the encryption key on the remote server. Both the user device and the remote server maintain updated copies of the historical driver data, minimizing data transfer between them and reducing the need for cloud-based data transfer, resulting in cost savings and reduced data transfer. This ensures that, unless the data on the user device is incorrect, only the server needs to communicate the key.

[0098] First, the TU requests data from the user device by sending the user ID of the data required (1502). Next, the user device checks whether the data exists on the user device. If the data exists on the user device, the user device sends encrypted historical driver data to the TU (1504). Raw data is never sent. To confirm that the user device has sent the correct and latest data, the TU applies a hash algorithm to the encrypted data (1506) and sends the hash to the remote server (1508). Next, the remote server retrieves the encrypted historical driver data and the user ID key from the database (1510), applies the same hash algorithm to a copy of the encrypted data (1512), and compares the two hashes (1514). The remote server generates a new encryption key and stores it in the database / memory (1516). If the hashes are the same, the data sent by the user device to the TU is up-to-date, and the remote server returns the old and new encryption keys (or the first and second symmetric keys) to the TU (1518). Next, the TU can decompose and store the historical driver data.

[0099] If the hashes are different, the data held by the user device is different, and the remote server returns the encrypted data to the TU along with the old and new encryption keys (or the first and second symmetric keys) (1520). The TU then decrypts and stores the historical driver data (1522) and returns the encrypted data to the user device (1524). The user device can now store the most recently encrypted data.

[0100] If the data does not exist on the user device, the user device sends a message to the TU indicating that the user device does not have historical driver data (1526). The TU then requests the historical driver data and symmetric key from the remote server (1528), which the remote server then needs to check whether historical driver data exists for that user ID.

[0101] If historical driver data exists on the remote server, the remote server sends the encrypted data back to the TU along with the symmetric key (1530). The TU then decrypts and stores the data (1532) and sends the encrypted data back to the user device (1534). The user device then stores the most recent encrypted data.

[0102] If the history driver data does not exist on the remote server, the remote server sends a message to the TU indicating that the history driver data does not exist (i.e., a no history data message) because it is a new user for whom no history driver data exists (1536). The TU then creates a new record in the database (1538) and sends confirmation of the creation of the new record to the user's device (1540).

[0103] Next, the TU waits for the trip to finish (1542), encrypts the updated trip data with the new symmetric key (1544), and sends the updated encrypted trip data to the user's device (1546). Then, the TU sends the updated encrypted trip data, including the user ID, user device ID, TUID, and timestamp, to the remote server (1548).

[0104] Figure 16 is a flowchart showing the user device flow 1600 for historical driver data retrieval. When the user device starts (1602), it waits for a request for historical driver data to be sent based on the received user ID (1604). Communication is via SRCC and it is guaranteed that the user device is on a docking station. Next, it is determined whether historical driver data for that particular user ID exists on the user device (1606). If historical driver data exists on the user device, the user device sends encrypted data to the TU (1608) and waits for a remote server verification message indicating whether the data is up to date (1610). Next, it is determined whether the user data is up to date (1612). If the user data is up to date, the user device receives confirmation that the data is up to date, and the user device does not need to take any further action (1614). If the user device's data is not up to date, the user device receives encrypted up to date data from the remote server via the TU and writes this new data to the TU's storage / memory (1616).

[0105] If the historical driver data does not exist on the user device, the user device sends a message to the TU indicating that there is no encrypted data (1618) and waits for the data retrieval process from the remote server / TU (1620). Next, it is determined whether the historical driver data exists on the remote server (1622). If the historical driver data exists on the remote server, the user device receives the latest encrypted data from the remote server via the TU (1624) and writes this new data to storage / memory. If the historical driver data does not exist on the remote server, the user device receives confirmation that a new record has been created because there is no previous historical driver data (1626).

[0106] Figures 17A-17B are flowcharts showing the TU flow 1700 for historical driver data retrieval. Upon initiation (1702), the TU requests encrypted historical driver data from the user device by sending the driver's user ID to the user device (1704). Next, the user device checks whether the historical driver data for that driver exists on the user device (1706). If the historical driver data exists on the user device, the TU receives the historical driver data from the user device (1708). Next, this data is hashed, the hashed data is sent to the remote server for verification (i.e., to check if the historical driver data is up-to-date), and the server is requested to provide the old and new keys (first and second symmetric keys) (1710).

[0107] Next, it is determined whether the user device data is up-to-date, that is, whether the hashes match (1712). If the hashes match and the user device data is up-to-date, the TU receives the old and new keys (first and second symmetric keys) from the remote server and can use the old key (first symmetric key) to decrypt and store the historical driver data (1714). If the hashes do not match and the user device data is incorrect, the TU receives the old and new keys (or first and second symmetric keys) along with the latest historical driver data from the remote server (1716). The TU then uses the old key (first symmetric key) to decrypt and store the historical driver data (1718) and sends the encrypted data to the user device (1720).

[0108] If the history driver data does not exist on the user's device, the TU receives a message from the user's device indicating that the history driver data does not exist (1722). Next, the TU requests the history driver data and the old and new keys (first and second symmetric keys) from the remote server (1724). Next, the remote server checks whether the history driver data exists on the remote server (1726). If the history driver data exists on the remote server, the TU receives the encrypted data and the old and new keys (first and second symmetric keys) from the remote server (1728). The TU then decrypts the history driver data using the old key (first symmetric key), stores it (1730), and sends the encrypted data to the user's device (1732).

[0109] If the historical driver data does not exist on the remote server, the TU receives a message indicating that the historical driver data does not exist on the remote server either (1734). The TU then creates a new record for the new user in the database and sends a confirmation of the new user to the user's device (1736).

[0110] Figure 18 is a flowchart showing the flow 1800 for the remote server in the historical driver data retrieval process. The remote server waits for a message from the TU. This message may vary depending on other decisions made in the sequence (whether the user device has data) (1802). It is determined whether historical driver data exists on the user device (1804). If historical driver data exists on the user device, the remote server receives a hash of the encrypted historical driver data on the device (i.e., the driver history data on the user device) from the TU (1806). Next, the same hash algorithm is used on the encrypted historical driver data and the two are compared (1808). Next, it is determined whether the historical driver data on the user device is up-to-date, i.e., whether the hashes match (1810). If the hashes are the same, i.e., match, the history data on the user device is up-to-date and correct, and the remote server sends the old and new keys (first and second symmetric keys) to the TU, and the TU decrypts the historical driver data (1812). If the hashes are different, the data on the user's device is inaccurate, and the remote server sends both the old and new keys and the encrypted data to the TU (1814).

[0111] If the history driver data does not exist on the user's device, the remote server waits for a request for the server-side history driver data and key from the TU (1816). Next, it is determined whether the history driver data exists on the remote server (1818). If the history driver data does not exist on the remote server, the remote server sends a message indicating that the history driver data does not exist on the remote server either (1820). Next, the remote server checks whether the history driver data exists for that user ID.

[0112] If historical driver data exists on the remote server, the remote server sends both the old and new keys (first and second symmetric keys) and the encrypted data to the TU (1822). After data retrieval and the trip is complete, the TU encrypts the new data with the new key (second symmetric key) generated by the remote server. The TU sends this new data to the user device and sends the encrypted new data along with relevant information (user ID, user device ID, TUID, timestamp) to the remote server.

[0113] Figure 19 is a block diagram of an exemplary hardware implementation of a remote server module / device 1900 configured to communicate according to one or more aspects of the present disclosure. The remote server 1900 may include, for example, a communication interface 1902. The communication interface 1902 may provide input and output of data and control. The communication interface 1902 may provide communication over one or more communication networks, for example, similar to the communication network 102 in Figure 1. The communication interface 1902 may be communicatively coupled to the communication network 102 directly or indirectly. The server 1900 may include a working memory device 1904 and a processor system / function / module / device (hereinafter, processor 1906). The processor 1906 may use the working memory device 1904 to store data that is to be operated, is being operated, or has recently been operated on. The processor 1906 may store instructions on the working memory device 1904 and / or on one or more other memory structures or devices, such as a non-temporary computer-readable media system / function / module / device (hereinafter referred to as non-temporary computer-readable media 1908). When executed by the processor 1906, the instructions can cause the processor 1906 to perform one or more embodiments of the methods described herein, for example.

[0114] The remote server 1900 may be implemented using a bus architecture generally represented by bus 1910. Bus 1910 may include any number of interconnection buses and bridges, depending on the specific application and overall design constraints of the server 1900. Bus 1910 can communicatively connect various circuits, including one or more processors (generally represented by processor 1906), a working memory device 1904, a communication interface 1902, and a non-temporary computer-readable medium 1908. Bus 1910 may also link various other circuits and devices, such as timing sources, peripherals, voltage regulators, and power management circuits and devices, which are well known in the art and will not be described further.

[0115] The communication interface 1902 provides means for communicating with other devices over a transmission medium. In some implementations, the communication interface 1902 includes circuitry and / or programming adapted to facilitate bidirectional information communication to one or more communication devices in a network. In some implementations, the communication interface 1902 is adapted to facilitate wireless communication of a server 1900. In these implementations, the communication interface 1902 may be coupled to one or more antennas 1912 for wireless communication within a wireless communication system, as shown in Figure 19. In some implementations, the communication interface 1902 may be configured for wired-based communication. For example, the communication interface 1902 may be a bus interface, a transmit / receive interface, or other type of signal interface including drivers, buffers, or other circuitry for outputting and / or acquiring signals (e.g., outputting signals from and / or receiving signals to integrated circuits). The communication interface 1902 may consist of one or more standalone receivers and / or transmitters, as well as one or more transceivers. In the illustrated example, the communication interface 1902 includes a transmitter 1914 and a receiver 1916. The communication interface 1902 functions as an example of a receiving means and / or a transmitting means.

[0116] Processor 1906 may be responsible for general operations, including managing bus 1910 and executing software stored in non-temporary computer-readable medium 1908. When executed by processor 1906, the software may cause processor 1906 to perform various functions described below on any specific device or module. Furthermore, non-temporary computer-readable medium 1908 and working memory device 1904 may be used to store data manipulated by processor 1906 when executing the software.

[0117] One or more processors, such as the processor 1906 of server 1900, can execute the software. Software can be broadly interpreted to mean instructions, instruction sets, code, code segments, program code, programs, subprograms, software modules, applications, software applications, software packages, routines, subroutines, objects, executable files, execution threads, procedures, functions, etc., whether they are called software, firmware, middleware, microcode, or hardware description languages. The software may reside on non-temporary computer-readable media, such as non-temporary computer-readable media 1908. Non-temporary computer-readable media 1908 may include, for example, magnetic storage devices (e.g., hard disks, floppy disks, magnetic tapes, magnetic strips), optical discs (e.g., compact discs (CDs), digital multipurpose discs (DVDs)), smart cards, flash memory devices (e.g., cards, sticks, key drives), random access memory (RAM), read-only memory (ROM), programmable ROM (PROM), erasable PROM (EPROM) including electrically erasable PROM (EEPROM), registers, removable disks, and any other suitable non-temporary media for storing software, date and time, and / or instructions that can be accessed and read by a computer or processor 1906. Computer-readable media may also include, for example, carrier waves, transmission lines, and any other suitable media for transmitting software and / or instructions that can be accessed and read by a computer or processor 1906.

[0118] The processor 1906 is arranged to perform data acquisition, processing, and / or transmission, control of data access and storage, issue commands, and control of other desired operations. In at least one example, the processor 1906 may include circuitry configured to perform desired programming provided by a suitable medium.

[0119] Non-temporary computer-readable media 1908 can be embodied as a computer program product. For example, a computer program product may include computer-readable media within package materials. Those skilled in the art will recognize the best way to implement the functions described throughout this disclosure, depending on the specific application and the overall design constraints imposed on the entire system.

[0120] In some aspects of this disclosure, the processor 1906 may include circuits configured for various functions. For example, the processor 1906 may include circuits / modules 1920 for operation, manage the operation of historical driver data received from user equipment 104 (Figure 1) and telematics unit 108 (Figure 1), perform input / output operations related to accessing the Internet Web, and be configured to perform, for example, the methods described herein. For example, the processor 1906 may include a data storage system / function / module / device 1922 configured to store data including, but not limited to, images, sensor data, event data, threshold levels, video data, driver data, score data, and previously collected datasets. For example, the processor 1906 may include a file system / function / module / device 1924 configured to control how data in local data storage and / or remote data storage is stored and retrieved. For example, the processor 1906 may include a graphics processor system / function / module / device 1926 configured to control video input / output of a camera mounted in a vehicle.

[0121] In some embodiments of this disclosure, the non-transient computer-readable medium 1908 of the remote server 1900 may include instructions causing various systems / functions / modules / devices of the processor 1906 to perform the methods described herein. For example, the non-transient computer-readable medium 1908 may include operation instructions or code 1928 for circuits / modules 1920 for operation. For example, the non-transient computer-readable medium 1908 may include data storage instructions 1930 corresponding to a data storage system / function / module / device 1922. For example, the non-transient computer-readable medium 1908 may include file system instructions 1932 corresponding to a file system / function / module / device 1924. For example, the non-transient computer-readable medium 1908 may include graphics processor instructions 1934 corresponding to a graphics processor system / function / module / device 1926.

[0122] Figure 20 is a block diagram of an exemplary hardware implementation of a telematics unit 2000 configured to communicate in accordance with one or more aspects of this disclosure. The telematics unit 2000 may include, for example, a communication interface 2002. The communication interface 2002 may enable data and control input and output. The communication interface 2002 may enable communication over one or more communication networks, for example, similar to the communication network 102 in Figure 1. The communication interface 2002 may be communicatively coupled to the communication network 102, directly or indirectly. The telematics unit 2000 may include a local working memory device 2004 and a processor system / function / module / device (hereinafter, processor 2006). The processor 2006 may use the working memory device 2004 to store data that is to be operated, is being operated, or has recently been operated. The processor 2006 may store instructions on the working memory device 2004 and / or on one or more other memory structures or devices, such as a non-temporary computer-readable media system / function / module / device (hereinafter referred to as non-temporary computer-readable media 2008). When executed by the processor 2006, the instructions can cause the processor 2006 to perform one or more embodiments of the methods described herein, for example.

[0123] The telematics unit 2000 may be implemented in a bus architecture generally represented by bus 2010. Bus 2010 may include any number of interconnection buses and bridges, depending on the specific application and overall design constraints of the telematics unit 2000. Bus 2010 can communicatively connect various circuits, including one or more processors (generally represented by processor 2006), a working memory device 2004, a communication interface 2002, and a non-temporary computer-readable medium 2008. Bus 2010 may also link various other circuits and devices, such as timing sources, peripherals, voltage regulators, and power management circuits and devices, which are well known in the art and will not be described further.

[0124] The communication interface 2002 provides means for communicating with other devices over a transmission medium. In some implementations, the communication interface 2002 includes circuitry and / or programming adapted to facilitate bidirectional information communication to one or more communication devices in a network. In some implementations, the communication interface 2002 is adapted to facilitate wireless communication of a telematics unit 2000. In these implementations, the communication interface 2002 may be coupled to one or more antennas 2012 for wireless communication in a wireless communication system, as shown in Figure 20. In some implementations, the communication interface 2002 may be configured for wired-based communication. For example, the communication interface 2002 may be a bus interface, a transmit / receive interface, or other type of signal interface including drivers, buffers, or other circuitry for outputting and / or acquiring signals (e.g., outputting signals from and / or receiving signals to integrated circuits). The communication interface 2002 may consist of one or more standalone receivers and / or transmitters, as well as one or more transceivers. In the illustrated example, the communication interface 2002 includes a transmitter 2014 and a receiver 2016. The communication interface 2002 functions as an example of a receiving means and / or a transmitting means.

[0125] Processor 2006 may be responsible for general operations, including managing bus 2010 and executing software stored in non-temporary computer-readable medium 2008. When executed by processor 2006, the software may cause processor 2006 to perform various functions described below on any specific device or module. Furthermore, non-temporary computer-readable medium 2008 and working memory device 2004 may be used to store data manipulated by processor 2006 when executing the software.

[0126] One or more processors, such as the processor 2006 of the telematics unit 2000, can execute the software. Software can be broadly interpreted to mean instructions, instruction sets, code, code segments, program code, programs, subprograms, software modules, applications, software applications, software packages, routines, subroutines, objects, executable files, execution threads, procedures, functions, etc., whether they are called software, firmware, middleware, microcode, or hardware description languages. The software may reside on non-temporary computer-readable media such as non-temporary computer-readable media 2008. Non-transient computer-readable media 2008 may include, for example, magnetic storage devices (e.g., hard disks, floppy disks, magnetic tapes, magnetic strips), optical discs (e.g., compact discs (CDs), digital versatile discs (DVDs)), smart cards, flash memory devices (e.g., cards, sticks, key drives), random access memory (RAM), read-only memory (ROM), programmable ROM (PROM), erasable PROM (EPROM) including electrically erasable PROM (EEPROM), registers, removable disks, and any other suitable non-transient media for storing software, date and time, and / or instructions that can be accessed and read by a computer or processor 2006. Computer-readable media may also include, for example, carrier waves, transmission lines, and any other suitable media for transmitting software and / or instructions that can be accessed and read by a computer or processor 2006.

[0127] The processor 2006 is configured to perform data acquisition, processing, and / or transmission, control data access and storage, issue commands, and control other desired operations. In at least one example, the processor 2006 may include circuitry configured to perform desired programming provided by a suitable medium.

[0128] Non-temporary computer-readable media 2008 can be embodied as a computer program product. For example, a computer program product may include computer-readable media within package materials. Those skilled in the art will recognize the best way to implement the functions described throughout this disclosure, depending on the specific application and the overall design constraints imposed on the entire system.

[0129] In some aspects of this disclosure, the processor 2006 may include circuitry configured for various functions. For example, the processor 2006 may include circuitry / modules 2020 for operation, manage the operation of sensors and displays, perform input / output operations related to accessing the Internet Web, and be configured to perform, for example, the methods described herein. For example, the processor 2006 may include a data storage system / function / module / device 2022 configured to store data including, but not limited to, images, sensor data, event data, threshold levels, video data, driver data, score data, and previously collected datasets. For example, the processor 2006 may include a file system / function / module / device 2024 configured to control how data is stored and retrieved. For example, the processor 2006 may include an in-vehicle sensor system / function / module / device 2026 mounted in a vehicle and configured to control sensor inputs and video inputs. For example, processor 2006 may include a diagnostic system / function / module / device 2026 configured to, for example, service an email account, process email messages, bundle emails for sending, acquire and store vehicle self-report data and recorded video, and perform, for example, the methods described herein. For example, processor 2006 may include an engine control unit system / function / module / device 2030 configured to control one or more electrical systems of subsystems in the vehicle to an external remote server and perform, for example, the methods described herein. For example, processor 2006 may include an artificial intelligence system / function / module / device 2032 configured to build a model of previous usage. For example, processor 2006 may include an autonomous driving system / function / module / device 2032 configured to determine whether the vehicle's autonomous driving system was activated when a risk event occurred, and whether the driver activated the autonomous driving system or the vehicle activated the autonomous driving function.

[0130] In some aspects of this disclosure, the non-transient computer-readable medium 2008 of the telematics unit 2000 may include instructions causing various systems / functions / modules / devices of the processor 2006 to perform the methods described herein. For example, the non-transient computer-readable medium 2008 may include operation instructions or code 2020 for a circuit / module 2020 for operation. For example, the non-transient computer-readable medium 2008 may include data storage instructions 2036 corresponding to a data storage system / function / module / device 2022. For example, the non-transient computer-readable medium 2008 may include file system instructions 2038 corresponding to a file system / function / module / device 2024. For example, the non-transient computer-readable medium 2008 may include sensor instructions 2040 corresponding to an on-board sensor system / function / module / device 2026 mounted in a vehicle. For example, the non-transient computer-readable medium 2008 may include diagnostic instructions 2042 corresponding to an engine control unit system / function / module / device 2030. For example, non-temporary computer-readable medium 2008 may include engine control unit instructions 2044 corresponding to engine control unit system / function / module / device 2030. For example, non-temporary computer-readable medium 2008 may include artificial intelligence instructions 2046 corresponding to artificial intelligence system / function / module / device 2032. For example, non-temporary computer-readable medium 2008 may include autonomous driving instructions 2046 corresponding to autonomous driving system / function / module / device 2033.

[0131] Figure 21 is a block diagram of an exemplary hardware implementation of a user device 2100 configured to communicate according to one or more aspects of the present disclosure. The user device 2100 may include, for example, a communication interface 2102. The communication interface 2102 may provide input and output of data and control. The communication interface 2102 may provide communication over one or more communication networks, for example, similar to the communication network 102 in Figure 1. The communication interface 2102 may be communicatively coupled to the communication network 102 directly or indirectly. The user device 2100 may include a working memory device 2104 and a processor system / function / module / device (hereinafter, processor 2106). The processor 2106 may use the working memory device 2104 to store data that is to be operated, is being operated, or has recently been operated. The processor 2106 may store instructions on the working memory device 2104 and / or on one or more other memory structures or devices, such as a non-temporary computer-readable media system / function / module / device (hereinafter referred to as non-temporary computer-readable media 2108). When executed by the processor 2106, the instructions can cause the processor 2106 to perform one or more embodiments of, for example, the methods described herein.

[0132] The user device 2100 may be implemented in a bus architecture generally represented by bus 2110. Bus 2110 may include any number of interconnection buses and bridges, depending on the specific application and overall design constraints of the user device 2100. Bus 2110 may communicatively connect various circuits, including one or more processors (generally represented by processor 2106), a working memory device 2104, a communication interface 2102, and a non-temporary computer-readable medium 2108. Bus 2110 may also link various other circuits and devices, such as timing sources, peripherals, voltage regulators, and power management circuits and devices, which are well known in the art and will not be described further.

[0133] The communication interface 2102 provides means for communicating with other devices via a transmission medium. In some implementations, the communication interface 2102 includes circuitry and / or programming adapted to facilitate bidirectional information communication to one or more communication devices in a network. In some implementations, the communication interface 2102 is adapted to facilitate wireless communication of user equipment 2100. In these implementations, the communication interface 2102 may be coupled to one or more antennas 2112 for wireless communication in a wireless communication system, as shown in Figure 21. In some implementations, the communication interface 2102 may be configured for wired-based communication. For example, the communication interface 2102 may be a bus interface, a transmit / receive interface, or other type of signal interface including drivers, buffers, or other circuitry for outputting and / or acquiring signals (e.g., outputting signals from and / or receiving signals to integrated circuits). The communication interface 2102 may consist of one or more standalone receivers and / or transmitters, as well as one or more transceivers. In the illustrated example, the communication interface 2102 includes a transmitter 2114 and a receiver 2116. The communication interface 2102 functions as an example of a receiving means and / or a transmitting means.

[0134] The processor 2106 may be responsible for managing the bus 2110 and general processing, including the execution of software stored in the non-temporary computer-readable medium 2108. When executed by the processor 2106, the software may cause the processor 2106 to perform various functions described below on any specific device or module. The non-temporary computer-readable medium 2108 and the working memory device 2104 may also be used to store data manipulated by the processor 2106 when the software is executed.

[0135] One or more processors, such as the processor 2106 of the user device 2100, can execute the software. Software can be broadly interpreted to mean instructions, instruction sets, code, code segments, program code, programs, subprograms, software modules, applications, software applications, software packages, routines, subroutines, objects, executable files, execution threads, procedures, functions, etc., whether they are called software, firmware, middleware, microcode, or hardware description languages. The software may reside on a non-temporary computer-readable medium, such as the non-temporary computer-readable medium 2108. The non-transient computer-readable medium 2108 may include, for example, magnetic storage devices (e.g., hard disks, floppy disks, magnetic tapes, magnetic strips), optical discs (e.g., compact discs (CDs), digital multipurpose discs (DVDs)), smart cards, flash memory devices (e.g., cards, sticks, key drives), random access memory (RAM), read-only memory (ROM), programmable ROM (PROM), erasable PROM (EPROM) including electrically erasable PROM (EEPROM), registers, removable disks, and any other suitable non-transient medium for storing software, date and time, and / or instructions that can be accessed and read by a computer or processor 2106. The computer-readable medium may also include, for example, carrier waves, transmission lines, and any other suitable medium for transmitting software and / or instructions that can be accessed and read by a computer or processor 2106.

[0136] The processor 2106 is arranged to control data acquisition, processing, and / or transmission, data access and storage, command issuance, and other desired operations. In at least one example, the processor 2106 may include circuitry configured to perform desired programming provided by a suitable medium.

[0137] Non-temporary computer-readable media 2108 can be embodied as a computer program product. For example, a computer program product may include computer-readable media within package material. Those skilled in the art will recognize the best way to implement the functions described throughout this disclosure, depending on the specific application and the overall design constraints imposed on the entire system.

[0138] In some aspects of this disclosure, the processor 2106 may include circuitry configured for various functions. For example, the processor 2106 may include circuitry / module 2120 for operation, manage the operation of data received from the telematics unit 108 (Figure 1) and the server 110 (Figure 1), perform input / output operations related to accessing the Internet Web, and be configured to perform, for example, the methods described herein. For example, the processor 2106 may include a data storage 2122 system / function / module / device configured to store data including, but not limited to, sensor data, event data, threshold levels, video data, driver data, score data, and previously collected datasets. For example, the processor 2106 may include a file system / function / module / device 2124 configured to control how data in local data storage and / or remote data storage is stored and retrieved. For example, the processor 2106 may include a vehicle head-up display (HUD) system / function / module / device 2126 configured for video input / output. For example, the processor 2106 may include a vehicle HUD system / function / module / device 2126 configured to control the vehicle's in-vehicle head-up display.

[0139] In some aspects of this disclosure, the non-transient computer-readable medium 2108 of the user device 2100 may include instructions causing various systems / functions / modules / devices of the processor 2106 to perform the methods described herein. For example, the non-transient computer-readable medium 2108 may include operation instructions or code 2120 for circuits / modules 2130 for operation. For example, the non-transient computer-readable medium 2108 may include data storage instructions 2132 corresponding to a data storage system / function / module / device 2122. For example, the non-transient computer-readable medium 2108 may include file system instructions 2134 corresponding to a file system / function / module / device 2124. For example, the non-transient computer-readable medium 2108 may include vehicle HUD instructions 2136 corresponding to a vehicle HUD system / function / module / device 2126. For example, the non-transient computer-readable medium 2108 may include dashboard instructions 2138 corresponding to a vehicle HUD system / function / module / device 2126.

[0140] Alternative device pairing methods Figure 22 is a flowchart showing an alternative system pairing sequence 2200. System pairing establishes three-way system identification between the remote server, the telematics unit (TU), and the user equipment. Once system pairing is successfully completed, each device (i.e., the user equipment) recognizes the ID of the other devices it is communicating with. System pairing is achieved by the TU (random pair key) and the remote server (docking station key) each generating their own random key for each session request, and sharing these keys asynchronously over different communication paths based on a request / response scheme.

[0141] First, the remote server generates a unique random key pair 2202 and sends a request for its information / device details to the user device (2204). Next, the user device sends the user ID, user device ID, authentication ID, and login status request to the remote server in response to the request (2206). Then, the remote server verifies the login status.

[0142] If the login is successful, the remote server sends a login success message to the user device (2210), and the user device sends a login success message to the TU (2212). The TU then sends a device pairing request to the remote server along with the TUID, docking station key, GPS (Global Positioning System) location, and pair timestamp (2214). Upon receipt, the remote server sends a random pair key to the TU (2216) and a pairing request to the user device along with the random pair key (2218).

[0143] Next, the user device sends the requested pairing information to the TU (2220), and the TU sends the docking station key and pair timestamp to the user device in response (2222). The user device then sends a pairing response to the remote server, which includes the user ID, user device ID, pair timestamp, random pair key, and docking station key (2224). The remote server then verifies the TU's device pairing request (2226).

[0144] If the pairing request is successful, the remote server sends a device pairing success message to the TU along with the user ID, user device ID, and docking station key (2228). Furthermore, the remote server sends a device pairing success message to the user device along with the docking station key (2230).

[0145] However, if device pairing fails, the remote server sends a device pairing failure message to the TU along with the user ID, user device ID, docking station key, pair timestamp, and random pair key (2232). Furthermore, the remote server sends a device pairing failure message to the user device (2234), and the user device displays an error message on its screen (2236).

[0146] If login fails, the remote server sends a login status failure message to the user's device (2238). The user's device then sends the login status failure message to the TU, and the user's device displays an error message on its screen (2240).

[0147] Figure 23 is a flowchart illustrating the flow 2300 of the alternative system pairing telematics unit (TU). When the TU is activated for communication by the user equipment, the TU initiates the system pairing sequence process (2302). The TU waits for the user equipment to reach a pre-configured (or predefined) start speed and confirms that a trip or driving session has started (2304). The user can place the user equipment in the docking station long before the trip or driving session begins and can detach the user equipment multiple times before the vehicle starts moving. This approach minimizes unnecessary cloud communication, cloud connectivity data costs, and session management workloads on remote servers.

[0148] Once the vehicle reaches the predetermined speed, the TU further waits for the vehicle to travel the predetermined distance to confirm that the actual trip has begun (2306). The predetermined speed and distance may be set by the administrator / employer or manager. For example, the predetermined speed is 20 miles per hour and the predetermined distance is 1 mile.

[0149] Next, if the login is determined to have failed (2308), a login status failure message is received from the user's device (2310). If the login is determined to have been successful (2308), a login status success message is received from the user's device (2312).

[0150] Next, the TU sends a device pairing request to the remote server along with the TUID, docking station key, GPS location, and pair timestamp (2314). The TU then receives a random pair key from the remote server (2316). Next, the TU receives a pairing information request from the user device (2318) and sends the docking station key and pairing timestamp to the user device (2320).

[0151] Next, the TU determines whether the device pairing was successful (2322). If it fails, the TU receives a device pairing failure message from the remote server along with the user ID, user device ID, docking station key, pair timestamp, and random pair key (2324). The TU then disables the driver identification (2326).

[0152] If device pairing is successful (2322), the TU receives a device pairing success message from the remote server along with the user ID, user device ID, and docking station key (2328). The TU then enables driver identification (2330).

[0153] Figure 24 is a flowchart showing the flow 2400 for a user device in an alternative system pairing. First, the user device logs on to the remote server (2402). If the user device successfully logs in to the remote server, it waits for a device details request from the remote server (2404). Upon receiving the request, the user device sends the user ID, user device ID, authentication ID, and login status to the remote server (2406). The user device then waits for the login status from the remote server (2408) and determines whether the login was successful (2410). If the login fails, the user device displays an error message on the display screen (2412) and sends a login failure status message to the TU (2414).

[0154] If the login is successful, the user device sends a login success message to the TU (2416) and receives a pairing request and a random pair key from the remote server (2418). Next, the user device requests pairing information from the TU (2420). In response to the request, the TU sends the docking station key and pair timestamp to the user device (2422).

[0155] Next, the user device sends the pairing response from the TU to the remote server along with the user ID, user device ID, timestamp, random pair key, and docking station key (2424). The user device then waits to receive a pairing status message from the TU (2426) to determine whether the device pairing was successful (2428). If pairing fails, the user device displays an error message on the display screen (2430) and disables driver identification (2432). If pairing is successful, the user device enables driver identification (2434).

[0156] Figure 25 is a flowchart illustrating the flow 2500 of the remote server for alternative system pairing. The remote server not only authenticates the TU and user equipment individually, but also functions as a control unit that verifies whether the TU and user equipment can communicate with each other (2502). The remote server does this by synchronously receiving common verification data from the TU and user equipment using request / response, and comparing the data to confirm that it is valid and identical.

[0157] First, the remote server generates a random pair key (2504) and requests user device details from the user device (2506). Next, the remote server receives / waits for a login status request from the user device, which includes the user ID, user device ID, authentication ID, and login status (2508). When a status request is received from the user device, the remote server checks the user ID, user device ID, authentication ID, and login status (2510) to determine whether the login was successful (2512). If the login is unsuccessful, the remote server sends a login failure status message to the user device (2514). If the login is successful, the remote server sends a login success message to the user device (2516).

[0158] Next, the remote server awaits a pairing request from the TU, along with the TUID, docking station key, GPS location, and pair timestamp 2518. Upon receiving a pairing request, the remote server sends a random pair key to the TU (2520), requests device pairing with the user device, and sends a random pair key to the user device (2522). Upon receiving a pairing response from the user device along with the user ID, user device ID, pair timestamp, random pair key, and docking key (2524), the remote server verifies the device pairing information from the TU and the user device (2526).

[0159] Next, it is determined whether the device pairing was successful (2528). If the device pairing fails, the remote server sends a device pairing failure message to the TU along with the user ID from the device, the user device ID, and the resolved docking station key (2530). If the device pairing request is successful, the remote server sends a device pairing success message to the TU along with the user ID, the user device ID, and the docking station key (2532). Subsequently, the remote server sends a device pairing success message to the user device along with the docking station key (2534).

[0160] conclusion In this disclosure, the term “exemplary” is used to mean “serving as an example, illustration, or explanatory example.” Embodiments or aspects described “exemplary” in this specification are not necessarily construed to be preferable or advantageous to other embodiments or aspects of this disclosure. Similarly, the term “aspects” does not require that all aspects of this disclosure include the features, advantages, or modes of operation discussed. In this specification, the term “bonded” means a direct or indirect bond between two objects. For example, if object A is in physical contact with object B, and object B is in contact with object C, objects A and C are considered bonded to each other even if they are not in direct physical contact. For example, an object may be bonded to an object second even if it is not in direct physical contact with the object first. The terms “circuit” and “circuit” are used broadly and are intended to include both hardware implementations of electrical devices and conductors that, when connected and configured, enable the performance of the functions described in this disclosure, and software implementations of information and instructions that, when executed by a processor, enable the performance of the functions described in this disclosure, without being limited to types of electronic circuits. In this specification, the terms "at least one" and "one or more" may be used interchangeably.

[0161] In this disclosure, the terms “memory,” “computer-readable medium,” and “storage” may be used interchangeably.

[0162] In this disclosure, the use of the component “A and / or B” means “A or B or A and B,” and may be expressed alternatively as “A, B, or a combination thereof” or “A, B, or both.” In this disclosure, the use of the component “A, B, and / or C” means “A or B or C, or any combination thereof,” and may be expressed alternatively as “A, B, C, or any combination thereof.”

[0163] One or more of the components, steps, features, and / or functions illustrated herein may be rearranged and / or combined into a single component, step, feature, or function, or they may be embodied in multiple components, steps, or functions. Additional elements, components, steps, and / or functions may also be added without departing from the novel features disclosed herein. Apparatus, devices, and / or components illustrated herein may be configured to perform one or more of the methods, features, or steps described herein. Furthermore, novel algorithms described herein can be efficiently implemented in software or incorporated into hardware.

[0164] It should be understood that the specific order or hierarchy of steps in the disclosed method is illustrative of an exemplary process. It should be understood that the specific order or hierarchy of steps in this method may be rearranged based on design preferences. The attached method claims present elements of various steps in a sample order and are not intended to be limited to the specific order or hierarchy presented unless otherwise noted.

[0165] The above description is provided to enable a person skilled in the art to carry out the various embodiments described herein. Various modifications to these embodiments will be obvious to a person skilled in the art, and the general principles set forth herein can be applied to other embodiments. For this reason, the claims are not intended to be limited to the embodiments shown herein, but the entire scope consistent with the language of the claims is recognized, and references to singular elements shall mean "one or more" and not "only" unless otherwise specified. Unless otherwise specified, the term "several" refers to one or more. The phrase "at least one" in a list of items refers to any combination of those items, including a single member. For example, "at least one of a, b, and c" covers a, b, c, a and b, a and c, b and c, a, b, and c. All structural and functional equivalents to elements of the various embodiments described throughout this disclosure, known to a person skilled in the art, or to become known to a person skilled in the art, are expressly incorporated herein by reference and are intended to be included in the claims. Furthermore, nothing disclosed herein is intended to be made available to the public, whether such disclosure is expressly contained in the claims or not. No element of a claim should be construed under 35 U.S. SC § 112(f) unless it is expressly contained in the phrase “means for” or, in the case of a method claim, in the phrase “step for.”

[0166] As used herein, the term “determining” encompasses a wide range of actions. For example, “determining” may include calculation, operation, processing, derivation, investigation, retrieval (e.g., looking up in a table, database, or other data structure), and confirmation. It may also include receiving (e.g., receiving information), accessing (e.g., accessing data in memory), and resolving, selecting, choosing, and establishing.

[0167] While the foregoing disclosures illustrate exemplary embodiments, it should be noted that various changes and modifications can be made herein without departing from the scope of the attached claims. The functions, steps, or operations of the method claims in accordance with the embodiments described herein do not need to be performed in a specific order unless expressly otherwise stated. Furthermore, elements may be described or asserted in the singular form, but plural forms are also assumed unless an limitation to the singular form is expressly stated.

Claims

1. One or more non-temporary computer-readable media storing computer-executable instructions that cause one or more processors on a telematics unit to perform an operation at runtime, wherein the operation is: The vehicle's onboard sensor system acquires the vehicle speed, and The steps include: calculating a first difference between the vehicle speed and a predetermined speed stored in non-volatile memory using one or more processors coupled to the in-vehicle sensor system; The in-vehicle sensor system provides a step of obtaining the trip duration, The steps include: calculating a second difference between the trip duration and the initial start duration using one or more processors coupled to the in-vehicle sensor system; A step of capturing an image of the driver using an image capture device coupled to one or more processors, wherein the image is captured when the vehicle speed is greater than the initial starting speed. The steps include: measuring one or more head position angles of the driver using one or more processors coupled to the in-vehicle sensor system; The steps include: when the one or more processors indicate that the driver is facing forward inside the vehicle, the one or more head position angles transmit a driver authentication request to the user device; The steps include receiving the driver authentication status from the user device, One or more non-temporary computer-readable media, comprising the step of transmitting a driver authentication status to a server communicating with the one or more processors.

2. The image capture device is selected from a digital camera, a video camera, and a mobile phone, one or more non-temporary computer-readable media according to claim 1.

3. The driver authentication request includes a user ID and an image of the driver, in one or more non-temporary computer-readable media according to claim 1.

4. The user device performs facial image recognition of the driver's image in one or more non-temporary computer-readable media according to claim 3.

5. The user history is activated when the driver authentication status is successful, according to one or more non-temporary computer-readable media according to claim 4.

6. If the driver authentication status fails, the user history is invalidated, one or more non-temporary computer-readable media according to claim 4.

7. The aforementioned operation further, The steps include receiving a driver authentication success message from the user device when the driver's image verification is successful, The one or more non-temporary computer-readable media according to claim 6, comprising the step of sending a driver authentication success message along with a timestamp to a storage server when the driver's image has been verified.

8. The aforementioned operation further, The steps include receiving a driver authentication failure message from the user device when the verification of the driver's image fails, One or more non-temporary computer-readable media according to claim 7, comprising the step of sending a driver authentication failure message to a server.

Images