Method and system for secure access of operation data

Abstract

Systems, methods, computer-readable media, and apparatuses for accessing onboard operational data in a vehicle. The systems, methods, computer-readable media, and devices may include hardware and / or software for performing operations including: obtaining user information and vehicle information; obtaining authentication information, for example from an authentication source; verifying that the particular user is associated with the vehicle based on the verification information; communicatively connecting to the vehicle based on the vehicle information; obtaining vehicle-mounted data from the vehicle; and providing the in-vehicle data to the user. In embodiments, the user may be an owner of the vehicle, a registrant of the vehicle, or a serviceman who is servicing the vehicle and needs to access on-board data other than the OBD fault code.

Description

[0001] Cross - Reference to Related Applications

[0002] This application claims the benefit and priority of U.S. Provisional Application No. 63 / 370,544, filed on Aug. 5, 2022, the entire content of which is incorporated herein by reference. Technical Field

[0003] The present invention relates to systems, devices, manufactures, and methods for securely accessing in - vehicle operation data such as in - vehicle data of a vehicle. Background Art

[0004] Modern vehicles, including cars, trucks, sports utility vehicles (SUVs), recreation vehicles (RVs), boats, snowmobiles, drones, etc., include several computerized subsystems such as brake control, steering control, electronic circuits, environmental control, engine control, rear - view cameras, suspension control, telemetry, door locks, and / or transmission control subsystems, to name just a few. The subsystems of a vehicle create, collect, track, and / or store data related to its operation (such as operation information regarding its settings, functions, surrounding environment, communications to / from the subsystems, movement of the vehicle, inputs from the vehicle operator, etc.). One type of operation data generated, collected, stored, and used by modern vehicles is called telematics data, which can include information about vehicle use (e.g., location, speed, etc. from a GPS subsystem), maintenance requirements (e.g., mileage, warning lights, repair codes, etc. from subsystems on - board the vehicle), and servicing (e.g., connection to a scan device at a vehicle repair shop, etc.).

[0005] Although various parts of the in - vehicle operation data of a vehicle can be read, transmitted, or otherwise accessed by the original equipment manufacturer (OEM) of the vehicle (e.g., Ford, Honda, Chevrolet, etc.), or the OEM of the subsystem (e.g., Bosch, Continental, Denso, etc.), or a representative of the manufacturer (e.g., a repair shop of an OEM vehicle dealership (e.g., Ford dealership, Honda dealership, Chevrolet dealership, etc.)), the person who owns, leases, and / or uses the vehicle currently cannot access the in - vehicle data of the vehicle, which is a significant drawback for the owner because the lack of such data can lead to problems, costs, and malfunctions related to maintenance, safety, etc. If the owner could access the operation data of the vehicle, the owner could have avoided or mitigated such problems, costs, and malfunctions. Similarly, independent repair shops without access sponsored by the OEM currently cannot access most of the in - vehicle data of the vehicle (except for fault codes), which results in similar drawbacks as described above. Summary of the Invention

[0006] Disclosed are systems, methods, computer-readable media, and devices for accessing in-vehicle operation data from a vehicle. The systems, methods, computer-readable media, and devices may include hardware and / or software for performing operations including: obtaining vehicle information that specifies a vehicle; obtaining user information that identifies a particular user; obtaining authentication information (e.g., obtaining authentication information from an authentication source), where the authentication information describes the vehicle and the particular user; verifying that the particular user is associated with the vehicle based on the authentication information; communicatively connecting to the vehicle based on the vehicle information; requesting in-vehicle operation data from the vehicle; receiving in-vehicle operation data from the vehicle; and providing the in-vehicle operation data to the particular user.

[0007] In some variations, obtaining vehicle information that specifies a vehicle includes receiving a vehicle identification number (VIN).

[0008] In some variations, obtaining user information that identifies a particular user includes receiving the name and date of birth of the particular user.

[0009] In some variations, obtaining authentication information from an authentication source includes receiving vehicle ownership information from a department of motor vehicles. In certain variations, e.g., obtaining authentication information from an authentication source, includes obtaining vehicle registration information from a department of motor vehicles.

[0010] In some variations, verifying that the particular user is associated with the vehicle includes comparing the user information that identifies the particular user with the authentication information that describes the particular user.

[0011] In some variations, the operations further include storing the in-vehicle operation data received from the vehicle. In some such variations, providing the in-vehicle operation data to the user includes providing the stored in-vehicle operation data.

[0012] In some variations, the particular user is the vehicle's registrant or a service technician.

[0013] In some variations, communicatively connecting to the vehicle based on the vehicle information includes communicatively connecting to the vehicle using the vehicle identification number.

[0014] Also disclosed are systems, methods, computer-readable media, and devices for accessing in-vehicle operation data in a vehicle. The systems, methods, computer-readable media, and devices may include hardware and / or software for performing operations including: obtaining user information and vehicle information from a user; determining, based on the user information and the vehicle information, that the user is the owner or registrant of the vehicle; communicatively connecting to the vehicle based on the vehicle information; obtaining in-vehicle operation data from the vehicle; and providing the in-vehicle operation data to the user. Variations of this implementation include all of the above variations and some additional variations.

[0015] Unless otherwise contradictory, the above elements may be combined with the elements in the specification. Description of the Drawings

[0016] The drawings incorporated in and forming a part of this specification illustrate examples and embodiments of the invention and, together with the specification, are used to explain the principles of the invention.

[0017] Figure 1 is a block diagram showing an example of a system for securely accessing in-vehicle operation data stored in a vehicle that is consistent with an embodiment of the invention;

[0018] Figure 2 is a flowchart showing an example of a process for securely accessing in-vehicle operation data stored in a vehicle that is consistent with an embodiment of the invention;

[0019] Figure 3 is a flowchart showing an example of a process for securely allowing access to in-vehicle operation data stored in a vehicle that is consistent with an embodiment of the invention; and

[0020] Figure 4 is a block diagram showing an example of a computing system that can be used to host and implement a system, functions, operations, and methods consistent with the implementation of the invention. Detailed Description

[0021] Reference will now be made in detail to embodiments of the invention, examples of which are illustrated in the drawings.

[0022] Various embodiments and implementations consistent with the present invention provide systems, devices, methods, and computer program products for securely accessing in-vehicle operational data (also referred to as in-vehicle data) stored in a vehicle, including access by an owner, lessee, vehicle registrant, police agency, or devices of other entities not associated with an OEM (such as computers, tablets, smartphones, etc.). As described herein, various embodiments provide new technical capabilities and facilities for ordinary (e.g., non-OEM-sponsored or non-affiliated with an OEM) owners, lessees, persons registering vehicles, repair shop workers, etc. to access in-vehicle data of a vehicle (including non-fault code data that is currently only accessible by companies affiliated with an OEM), such as telematics data or telemetry data (as opposed to vehicle fault code data, which can be accessed by non-OEM on-board-diagnostics (OBD) scanners). Various embodiments verify that a user requesting in-vehicle data is actually associated with the vehicle in a prescribed manner, such as being associated with the vehicle as an owner, lessee, registrant, repair shop authorized by the owner, etc., before providing access to some or all of the vehicle's in-vehicle data. In some embodiments, a vehicle-related user may, for example, set up an account for each owned / leased / registered / maintained vehicle based on the vehicle identification number (VIN) of each vehicle or include each owned / leased / registered / maintained vehicle in the account. Through this account, the vehicle-related user can access (e.g., read or copy) at least a portion of the in-vehicle data of each vehicle, which in current conventional systems can only be accessed by the OEM.

[0023] Figure 1FIG. 0 is a block diagram showing an example of a system 100 for securely accessing operational data stored in-vehicle in a vehicle, consistent with an embodiment of the present invention. As shown in this example, a vehicle 150 (e.g., an automobile in this figure) is communicatively connected to one or more networks, such as a wireless network 122 and a general network 120, which may include wired and wireless capabilities. Also, through networks 120, 122, the vehicle 150 may also be communicatively connected to one or more remote devices, such as an authorization controller 105 and / or an OEM data device 125. As shown, any other remote devices connected to networks 120, 122 may be communicatively connected to each other. For example, the authorization controller 105 may also be connected to a vehicle user device 110, a repair shop device 130, a verification source device 115, and / or an OEM data device 125. As shown in this example, one or more remote devices may be associated with a person (e.g., operated by a person), such as a user 112 (e.g., a vehicle owner) associated with the vehicle user device 110 and a repair person 132 associated with the shop device 130. Also as shown in this example, the vehicle 150 may also be directly communicatively connected to a remote device, such as an OBD scanner 140, without using networks 120, 122.

[0024] As Figure 1 shown in the example, the vehicle 150 includes a plurality of electronic control units (ECUs) 156, 157, 158, etc.; although only three ECUs 156 - 158 are explicitly depicted, there are typically more ECUs in a vehicle 150 (e.g., an automobile or a truck), as indicated by the ellipsis. An ECU may also be referred to as an electronic control module (ECM). In various implementations, an ECU may be part of an embedded subsystem in the vehicle 150, and each ECU may control one or more functions, features, or subsystems in an automobile or other vehicle (e.g., a fuel subsystem, a chassis control subsystem, a generator subsystem, a multimedia electronics subsystem, a braking subsystem, a navigation subsystem, a safety subsystem, an adaptive cruise control subsystem, an engine control subsystem, and a security (door lock) subsystem, etc.), or be part of one or more functions, features, or subsystems in an automobile or other vehicle. In some uses, as is known in the art, an ECU may be an on-board unit (OBU), or may be part of an on-board unit, or may be connected to an on-board unit. An ECU is generally a computerized device, where the computerized device creates, collects, and / or stores data related to itself and to the vehicle and the operation of the vehicle. The data may include telematics data and other non-fault code data. Generally, Figure 1The ECUs 156 - 158 shown and described herein represent any and all data sources and data storage devices in a vehicle. The present disclosure is not limited to data only from the ECUs, but includes all in - vehicle data from any source in vehicle 150.

[0025] In Figure 1 the example, the ECUs 156 - 158 are communicatively coupled to a gateway 154, which has novel operations and functions as described herein. The gateway 154 can be considered another type of ECU. In various embodiments, the gateway 154 can be a computer, digital logic module, or computerized device (e.g., similar to a router device or a firewall device) that controls communication with and access to the ECUs 156 - 158 and their data. In such embodiments, the gateway 154 can be used to block access to the ECUs 156 - 158 and their data from unauthorized requesters (e.g., deny read requests), and to grant access or partial access to the ECUs 156 - 158 and their data to authorized requesters. Again, note that although the term ECU is used herein for clarity, the present disclosure includes any data source on vehicle 150 that is in - vehicle and includes ECUs.

[0026] As shown, the gateway 154 is communicatively coupled to a communication port 152, which, as is known in the art, can be or include an on - board diagnostic (OBD) port for an automobile, etc. In some embodiments, the communication port 152 can be or include a hardware connection point, such as an OBD - II 16 - pin diagnostic connector, etc. In other embodiments, the communication port 152 can be or include a device that includes one or more wireless connection points (e.g., Bluetooth, local area network (LAN), cellular, etc.), and may also be or include a hardware connection point.

[0027] In various embodiments, a remote device may be communicatively coupled (e.g., via a wire or wirelessly) to communication port 152 and interact with gateway 154. In one example shown, the remote device may be an OBD scanner 140 (also known as an automotive diagnostic code reader); in another example, the remote device may be an authorization controller 105, which is a new device having novel operations and functions as described herein. OBD scanners are known in the art and they only read fault codes from vehicle 150, e.g., for use by a mechanic. In this example, OBD scanner 140 may be connected to communication port 152 using a cable that a mechanic inserts into communication port 152. In various embodiments, authorization controller 105 may be wirelessly connected (e.g., via a cellular connection provided by wireless network 122) to communication port 152 and enable entities not affiliated with the OEM, such as user 112 or repair person 132, to indirectly or directly obtain access to in-vehicle operation data of vehicle 150.

[0028] Gateway 154 may receive and process requests for in-vehicle data from remote devices, where each request may specify the requester, the in-vehicle data the requester desires, and / or the ECU 156 - 158 that will provide the data.

[0029] In various implementations, gateway 154 may initially process the received data requests to identify and authenticate the requester (e.g., the requesting device), as is known in the art (e.g., using digital certificates, etc.). Using Figure 1 as an example, gateway 154 may identify one requester as OBD scanner 140 and determine that OBD scanner 140 is authorized to communicate with gateway 154 based on the scanner's digital certificate. Similarly, gateway 154 may identify another requester as authorization controller 105 and determine that it is authorized to communicate with gateway 154 based on its digital certificate.

[0030] Based on the identity of each authenticated requester and / or the data requested from the ECU, gateway 154 may reject (e.g., block) or accept the request, where accepting the request allows the authenticated requester access to the requested data. For example, gateway 154 may grant a request from OBD scanner 140 to read fault code data from the vehicle (as is known in the art) and may reject a request from OBD scanner 140 to read telematics data from the vehicle.

[0031] In some embodiments, the gateway 154 may use previously stored access rights to determine whether an authenticated requester is authorized to access (e.g., read, copy, receive, etc.) data from a specific ECU, where the ECU may be associated with a specific type of data. In various embodiments, the access rights stored by the gateway 154 may be updated or changed periodically or as needed, e.g., to add new authenticated requesters, which are typically remote devices (e.g., new authorization controllers 105), that are arranged to access some or all of the vehicle's on-board data, or, e.g., to delete or update the access rights of previously authenticated requesters that have had a change to their access rights.

[0032] In some embodiments, the access rights may be in the form of a lookup table, as shown in Table 1 below. As shown, Table 1 may indicate that the OBD scanner 140 is able to obtain data from the ECU 156 (in this example, the ECU 156 is the ECU that generates and maintains vehicle fault code data), but is not able to access data from the ECU 157 or ECU 158. Similarly, according to Table 1, if the requester is a repair shop affiliated with the OEM, the gateway 154 will allow access to on-board data associated with the ECUs 156, 157, or 158; if the requester is an independent repair shop, the gateway 154 will allow access to on-board data associated with the ECUs 156 or 157; if the requester is a user of the vehicle (e.g., the registrant, etc.), the gateway 154 will allow access to on-board data associated with the ECUs 156 or 158; and the authorization controller requester may access all on-board data.

[0033]

[0034] Table 1

[0035] If the request is denied (e.g., according to the permissions stored in Table 1), the authenticated requester is denied access to the requested data. If the gateway 154 grants the request, the requester is able to access the requested data from the ECU; e.g., the requester may be able to upload, copy, receive, or otherwise obtain the requested data from the ECU.

[0036] In some embodiments, the authorization controller 105 may set or configure the access rights used by the gateway 154 to determine whether a requester is authorized to access specified on-board data. For example, the authorization controller 105 may create and / or modify a lookup table, such as Table 1, to grant or delete permissions for specific requesters, specific types of requesters, and / or specific roles. The ability of the authorization controller 105 to set access rights is represented in Table 1 by listing the gateway "gateway 154" as a component to which the authorization controller 105 has access rights.

[0037] As described above, system 100 includes a network 120 and a wireless network 122 that are communicatively connected. Network 120 can be any type of network or part of any type of network, such as the Internet, a private network, a virtual private network, a cellular network, a wireless local area network, or any combination of these networks. Wireless network 122 can be any type of wireless network or part of any type of wireless network, such as a cellular network, a wireless local area network, a wireless wide area network, or a combination of these networks. Although network 120 and wireless network 122 are shown as separate for clarity of explanation, in various embodiments, network 120 and radio network 122 can be combined into a network capable of both wired and wireless communication. As described above, networks 120, 122 can be connected to various systems and computerized devices, such as servers, portal computers, laptops, client devices, smartphones, etc. Generally, networks 120, 122 are capable of digital communication between the computerized devices connected to them, including the computerized devices included in vehicle 150, such as ECUs 156 - 158 and gateway 154. Figure 1 As described above, system 100 includes a novel authorization controller 105. Authorization controller 105 can be implemented as a server computer (e.g., having at least one processor and an associated data storage device, such as a memory). In various implementations, authorization controller 105 can be used to: authenticate and communicate securely with users of system 100 (e.g., user 112 / vehicle user device 110 or repair person 132 / shop device 130); communicate securely with and manage gateway devices in the vehicle (e.g., gateway device 154); communicate securely with one or more verification sources 115 (e.g., verification sources 115 maintained by a department of motor vehicles (DMV) or including copies of records maintained by the DMV) and collect verification information from them; communicate securely with an original equipment manufacturer (OEM, e.g., OEM data storage 125 of the manufacturer of vehicle 150, etc.) and collect information from it; create and store account records for user 112, repair person 132, etc.; create and securely distribute access rights to vehicle 150 (e.g., as described in Table 1 above); and / or obtain, copy, distribute, and / or store (e.g., in data storage 107, which can be a database hosted on the same or a different computer as controller 105, etc.) on - vehicle data from vehicle 150.

[0038] As described above, system 100 includes a novel authorization controller 105. Authorization controller 105 can be implemented as a server computer (e.g., having at least one processor and an associated data storage device, such as a memory). In various implementations, authorization controller 105 can be used to: authenticate and communicate securely with users of system 100 (e.g., user 112 / vehicle user device 110 or repair person 132 / shop device 130); communicate securely with and manage gateway devices in the vehicle (e.g., gateway device 154); communicate securely with one or more verification sources 115 (e.g., verification sources 115 maintained by a department of motor vehicles (DMV) or including copies of records maintained by the DMV) and collect verification information from them; communicate securely with an original equipment manufacturer (OEM, e.g., OEM data storage 125 of the manufacturer of vehicle 150, etc.) and collect information from it; create and store account records for user 112, repair person 132, etc.; create and securely distribute access rights to vehicle 150 (e.g., as described in Table 1 above); and / or obtain, copy, distribute, and / or store (e.g., in data storage 107, which can be a database hosted on the same or a different computer as controller 105, etc.) on - vehicle data from vehicle 150.

[0039] As Figure 1As shown in the example of, the authorization controller 105 is communicatively connected to the OEM data store 125 via the network 120 (e.g., which may be implemented as a server hosting a database containing OEM data, etc.). The OEM data store 125 may store data, information, and digital assets related to an individual vehicle produced by the OEM (e.g., a copy of the in-vehicle data collected and stored by the OEM from the vehicle 150) and / or data, information, and digital assets related to a group of vehicles or vehicle types to which the vehicle 150 belongs (e.g., data about the 2019 Nissan Murano, such as maintenance bulletins or recalls). Although Figure 1 using the "OEM" data store 125 as a convenient label, various other embodiments may include any data collected or stored by other entities (e.g., in-vehicle data from the vehicle 150). Embodiments of the system 100 are not limited to data from only OEM sources.

[0040] The authorization controller 105 may also be communicatively connected to the shop device 130, which in various embodiments may be implemented as, for example, a stand-alone computerized device (e.g., a server, smartphone, tablet, or other computer) connected to a portal, an application programming interface (API), or other interface controlled by the authorization controller 105, or other implementations such as a stand-alone computerized device running an application for interacting with the authorization controller 105. In various implementations, a repair person 132 among the vehicle repair shop employees may use the shop device 130 to engage with the authorization controller 105 and manage their access to the in-vehicle data, devices, and subsystems (e.g., ECUs 156 - 158) of the vehicle 150 and / or other vehicles relevant or of interest to the vehicle repair shop services. As used herein, "repair person" does not mean limited to those performing repairs, but rather refers to any person or entity providing any type of service for a vehicle, including technical and maintenance services, which include but are not limited to locksmith services, transmission mechanic services, brake mechanic services, engine mechanic services, tire services, refueling or charging services, etc. Similarly, the terms "shop" and "repair shop" do not mean limited to a shop or limited to a shop performing repairs on vehicles, but rather refer to any business or organization providing any type of service for a vehicle.

[0041] In various implementations, the repair person 132 may use the shop device 130 to perform a variety of functions within the system 100. Although Figure 1Using "repair person" 132 as a convenient example, but in embodiments, person 132 can be another person associated with the repair shop, such as an owner, manager, employee, etc. In various embodiments, the functions of the shop device 130 include, but are not limited to, engaging with the authorization controller 105, verifying the authenticity of the shop device 130 and / or the repair person 132, establishing a repair shop account, and managing access to in-vehicle data of a vehicle (such as vehicle 150). In such an implementation, for example, the authorization controller 105 can verify that a repair shop with a shop device 130 and a repair person 132 is a legitimate vehicle repair shop by confirming that the repair shop is properly registered in the state and / or has the appropriate business permits and business licenses associated therewith (which can be done using business records of the state and / or local municipalities or similar verification information from the verification source 115). Similarly, the authorization controller 105 can verify that the repair person 132 of the shop is a legitimate automotive repair person by confirming that person 132 has a professional license or mechanic's certificate or other verification information (which can be done using state or city licensing records or professional training organization records from the verification source 115 (e.g., records of the National Institute for Automotive Service Excellence (ASE))). In some implementations, the repair shop can pay a fee (e.g., a subscription fee) for the in-vehicle operation data access service provided by the authorization controller 105, and the fee can vary based on the amount and / or which in-vehicle data is accessed and the number of vehicles covered.

[0042] In some implementations, the shop device 130 (e.g., by running an application or connecting to a portal or API provided by the authorization controller 105) can collect identification information such as a username, password, two-factor identification data, facial recognition image, fingerprint, etc. from a user (e.g., the repair person 132) located at the repair shop and provide the identification information to the authorization controller 105. The authorization controller 105 can store the identification information in an account of the repair shop device 132 and authenticate person 132 before allowing person 132 to access data from vehicle 150. For example, the authorization controller 105 can look up the identification information (e.g., username and password) associated with a particular user 132 that has been previously verified and stored and compare the stored identification information with the identification information collected by the shop device 130.

[0043] As Figure 1As shown in the example of, the authorization controller 105 is also communicatively coupled to a vehicle user device 110, which in various embodiments may be implemented as, for example, a stand-alone computerized device (e.g., a server, a smart phone, a tablet computer, or other computer) connected to a portal or other interface controlled by the authorization controller 105 in other implementations, or a stand-alone computerized device running an application for interacting with the authorization controller 105. In various implementations, a user 112 associated with the vehicle 150 (e.g., the owner, lessee, registrant, and / or operator of the vehicle 150) may employ the vehicle user device 110 to interact with the authorization controller 105 without limitation, verify their identity and relationship to the vehicle 150 (e.g., owner, lessee, registrant, etc.), set up a personal account, and manage their access to data of their vehicle 150 and / or other vehicles that they own, operate, or have other relationships with.

[0044] In view of the vehicle user device 110 and the shop device 130, the system 100 can be considered to provide new role-based access control (RBAC) capabilities for in-vehicle data in the vehicle 150. Other implementations of the system 100 may include additional interfaces and / or additional ports that support access for other roles in addition to the vehicle user role and the maintenance personnel / shop role.

[0045] In various embodiments, the authorization controller 105 may authenticate or verify that the user 112 using the vehicle user device 110 has a specific relationship with the vehicle 150 (e.g., is the actual owner, lessee, and / or registrant of the vehicle 150) before allowing the user 112 to access in-vehicle data from the vehicle 150 (e.g., operation data associated with the ECUs 156-158, etc.). In some such embodiments, the authorization controller 105 and / or the vehicle user device 110 may collect information from the user 112 for verifying that the user 112 has a relationship with the vehicle that the user 112 claims, e.g., claiming to be the owner, lessee, and / or registrant of the vehicle 150. The information collected from the user 112 should include information that can be independently obtained from a verification source 115 (e.g., from the DMV). Two examples of information collected from the user 112 are information from the registration document of the vehicle 150 issued by the DMV (e.g., name of the registrant, address of the registrant, vehicle ownership number, vehicle identification number (VIN), registration state, registration issue date, license plate number, vehicle make, model, and year, vehicle purchase date, etc.) and / or information from the ownership document of the vehicle 150 issued by the DMV (e.g., name of the owner, address of the owner, ownership number, ownership status, vehicle identification number, ownership issue date, vehicle make, model, and year, ownership odometer reading, previous ownership number, etc.).

[0046] In some embodiments, the information collected from user 112 may include information that the authorization controller 105 uses to set up an account for the user, such as name, address, phone number, email address, biometric information, password, etc. In some such embodiments, this information can be used to set up two-factor authentication for the account so that the system can verify the identity of user 112 when logging in through the vehicle user device 110 at a later time.

[0047] In various embodiments, the authorization controller 105 may not allow user 112 to access data from vehicle 150 unless the authorization controller 105 can confirm that user 112 does in fact have the claimed relationship with vehicle 150 (e.g., is actually the owner, lessee, and / or registrant of vehicle 150). For example, to verify that user 112 is the actual registrant of vehicle 150, the authorization controller 105 may access and analyze data (e.g., verification information) from a verification source 115, which in this example is the DMV of the state in which vehicle 150 is registered. For example, the authorization controller 105 may verify whether the registration information (e.g., name of the registrant, address of the registrant, vehicle ownership number, vehicle identification number, registration issue date, license plate number, vehicle make, model, and year, and vehicle purchase date) entered by user 112 matches the registration information of vehicle 150 from the DMV 115. In such an embodiment, user 112 without all of the registration information cannot access data from vehicle 150 because the system 100 will detect that they are not the person who registered vehicle 150 with the DMV.

[0048] In some cases, the vehicle may be legally owned by a financial institution or lessor, and user 112 may be a loan borrower or lessee who is registered, owns, and drives vehicle 150. Even though user 112 may not legally own vehicle 150 and thus may not have the title documents, the system 100 can enable such a user 112 to access data from vehicle 150 because the vehicle is registered to user 112 either individually or jointly. Similarly, the vehicle may be owned by an organization, such as a company, and user 112 may be an employee (or similar person) of the organization, and embodiments of the system 100 can allow the employee / user 112 to access data from vehicle 150 when the employee / user 112 can provide the vehicle registration information of the organization to the authorization controller 105, and the authorization controller 105 will verify whether the information matches the registration records from a verification source (e.g., DMV) 115.

[0049] In some embodiments, if the authorization controller 105 can confirm that the user 112 is actually a law enforcement officer or agent, the authorization controller 105 may allow the user 112, who is a law enforcement officer or agent, to access data from the vehicle 150. To verify that the user 112 is a law enforcement officer or agent, the authorization controller 105 may access and analyze data or verification information from a verification source 115 (e.g., a state or federal law enforcement database that stores identity information of law enforcement officers and agents in the jurisdiction, such as name, social security code, date of birth, officer badge code or identification code, biometric data, etc.). In some such embodiments, the system 100 may also require and verify that the law enforcement officer or agent holds a search warrant for the vehicle 150 before allowing access to the vehicle's on-board data.

[0050] As a simple, non-limiting use case of the system 100 (among many other use cases), consider the example where the user 112 is the owner of the vehicle 150, and the vehicle is registered to the user 112 at the state DMV. The user 112 may use the vehicle user device 110 to engage with the authorization controller 105. In some embodiments, the vehicle user device 110 may be a laptop computer that engages with an internet website (e.g., a portal website) controlled by the authorization controller 105. The user 112 may input information from the vehicle registration document issued by the DMV of their state for the vehicle 150, such as their name, their address, the vehicle ownership number, the vehicle identification number, the vehicle license plate number, and the make, model, and year of the vehicle, and the user 112 may request access to all or part of the on-board data of their vehicle 150 (e.g., request data from all ECUs, request telematics data, or request data from a specific subsystem, such as only request data from ECUs 156 and 158). In some embodiments, the user 112 may pay a fee for the data access service provided by the authorization controller 105, and the fee may vary according to how much on-board data is accessed and / or which on-board data is accessed.

[0051] After receiving the vehicle registration information input by the user 112, the authorization controller 105 may request, obtain, or otherwise access the corresponding verification information data from the verification source 115. In this example, the authorization controller 105 may obtain the vehicle registration DMV data of the vehicle 150 with the VIN input by the user 112 from the DMV 115. The authorization controller 105 may then compare and analyze the vehicle registration information input by the user 112 with the corresponding data from the DMV.

[0052] If two data sets match, then in this example, it can be considered that the authorization controller 105 has verified that the user 112 is indeed the registrant of the vehicle 150. After verification, the authorization controller 105 can connect to the vehicle 150 via the networks 120 and 122 and request or otherwise obtain the in-vehicle data specified by the user 112. The authorization controller 105 can then provide the requested in-vehicle data to the user 112, for example, by displaying it or providing a downloadable file via the vehicle user device 110. Thus, the system 100 provides new technical capabilities and a novel technical infrastructure to allow the verified user 112 of the registered vehicle 150 in this example to access the in-vehicle data from the vehicle 150, thereby providing a novel and secure data retrieval capability not present in current traditional systems.

[0053] Those of ordinary skill in the art will recognize that Figure 1 the components, processes, data, operations, and implementation details shown in Figure 1 are examples presented for the sake of concise and clear explanation. Other components, processes, implementation details, and variations may be used without departing from the principles of the present invention, as the example is not intended to be limiting and many variations are possible. For example, for clarity of explanation, Figure 1 a single instance of the vehicle 150 is shown in

[0054] but the present invention is not limited thereto, and in other embodiments, there may be multiple vehicles 150. Similarly, for clarity of explanation,

[0055] As another example, system 100 can include a charger / refueler device and an application and / or a corresponding portal or API managed by authorization controller 105, through which charging stations, charging point operators, e-Mobility service providers, gas stations, etc. can access the in-vehicle data of the vehicles they are charging / refueling, similar to those described herein. As yet another example, system 100 can include an application portal or API managed by authorization controller 105, through which software applications, etc. (e.g., a mobile navigation application that wishes to use the geographical location data of vehicle 150) can access the in-vehicle data as described herein. In other embodiments, there can be a single type of multi-purpose API or portal (e.g., similar to the combination of web portals that devices 110 and 130 can use), which enables multiple different types of entities (e.g., 110 / 112, 130 / 132) to access the in-vehicle data. Other variations are possible.

[0056] As yet another example, some embodiments may not include or may not utilize the authentication source 115. In such embodiments, authorization controller 105 can use the information provided by user 112 (e.g., a copy of the user's driver's license and a copy of the user's vehicle ownership and / or registration) to verify whether the user is associated with the vehicle. Using these documents, authorization controller 105 can verify whether the user information in the driver's license, such as name, date of birth, and address, matches the corresponding verification information in the vehicle ownership document and / or vehicle registration document.

[0057] As yet another example, those of ordinary skill in the art will recognize that other embodiments can replace the permission authorization data structure represented by Table 1 with other means and / or data structures to determine which in-vehicle data is allowed for a requester to access.

[0058] Those of ordinary skill in the art further recognize that although an automobile is used as an example of vehicle 150 herein Figure 1 and elsewhere in this document, vehicle 150 can be any type of vehicle, such as a truck, SUV, RV, boat, airplane, snow vehicle, drone, etc. The inventors also note that although the communication port 152 is described for clarity in connection with Figure 1 the exact hardware and technology used to connect gateway 154 to the requester are not important to the present invention.

[0059] Figure 2 is a flowchart showing an example of a process 200 for securely accessing in-vehicle operation data stored in a vehicle, which is consistent with an embodiment of the present invention. In various implementations, some or all of the operations of process 200 can be performed by authorization controller 105 or a similar computing system.

[0060] AsFigure 2 As shown in the example of Figure 2 , process 200 begins at block 205 by obtaining user information and vehicle information. In various implementations, the vehicle information may include information that uniquely identifies a particular vehicle (e.g., VIN in the case where the vehicle is an automobile), and may also include a description (e.g., name, category, etc.) of the operational data (e.g., "location data, speed data, idle time data, acceleration data, braking data, fuel consumption data, and tire pressure data") that the user requests to obtain from vehicle 150. In various implementations, the user information may include information that uniquely identifies a particular user, such as a driver's license number, social security number, registration number, or ownership code.

[0061] In some implementations, process 200 may obtain user information and vehicle information from user 112, such as by prompting user 112 to enter appropriate information via a device 110 connected to a vehicle user web portal associated with authorization controller 110. For example, user 112 may be prompted to enter information that identifies user 112, such as name, date of birth, social security number, driver's license number, etc., or, in the case where user 112 has previously established an account with authorization controller 110, to enter, for example, a username and password or biometric information. User 112 may also be prompted to enter information that specifically identifies vehicle 150 from which data is to be obtained, such as VIN information, make, model, and year information, etc. User 112 may also be prompted to enter information that identifies the data that the user wishes to obtain from vehicle 150, such as a particular type of operational data stored in vehicle 150. In some implementations, process 200 may present a list or menu of in-vehicle data, etc., to user 112, and user 112 may select the desired in-vehicle data (e.g., by clicking on an item displayed in a screen menu).

[0062] In some implementations of block 205, process 200 may prompt user 112 to enter information from a vehicle ownership document and / or vehicle registration document, or information typically found on a vehicle ownership document. In some such implementations, process 200 may also prompt and / or require the user to enter information about themselves (e.g., from a driver's license or other government-issued identification information) and / or information corresponding to the vehicle (e.g., 150) associated with the user (e.g., owned, leased, registered, driven, maintained, fueled, etc.), such as information from an ownership document, such as the owner's name, owner's address, ownership number, ownership status, vehicle identification number, ownership issue date, vehicle make, model, and year, etc. Additionally or alternatively, process 200 may prompt and / or require the user to upload a copy of the vehicle 150's ownership and / or registration document and / or a copy of user 112's driver's license or mechanic's license (e.g., PDF scan, JPG digital photo, etc.).

[0063] At block 210, process 200 determines or verifies whether the user is associated with the vehicle in a prescribed manner. Non-limiting examples of acceptable associations include being the owner of the vehicle, being the registrant of the vehicle, being the lessee of the vehicle, being the lienholder of the vehicle, being a service person who repairs or refuels the vehicle, etc. In various implementations, the authorization controller 105 may use data from the verification source 115 to make this determination. For example, in the case where vehicle 150 is an automobile and user 112 is the owner, the verification source 115 may be a DMV website or database, new car sales and lease records of an automobile dealership, etc. In this case, the authorization controller 105 may use the ownership number (and / or other information) obtained from user 112 at block 205 to request, download, access, or otherwise obtain verification information such as an electronic copy of the vehicle ownership. After obtaining the electronic copy of the vehicle ownership from the DMV 115, the authorization controller 105 may compare the verification information in one or more fields of the vehicle ownership with the corresponding information provided by the owner / user.

[0064] Continuing with the vehicle owner example, if the verification information in one (or in some implementations, more than one) field of the vehicle ownership does not match the corresponding information provided by user 112 (e.g., if the owner name, owner address, vehicle identification number, and / or ownership issue date from the DMV ownership information do not match the owner name, owner address, vehicle identification number, and ownership issue date obtained from user 112 at block 205), then user 112 is not verified as being associated with vehicle 150, and process 200 exits (block 212). In some embodiments, when process 200 exits, process 200 may communicate to user 112 that the user will not be authorized to access in-vehicle data because user 112 cannot be confirmed or verified as being associated with the vehicle; in this case, not being verified as the owner.

[0065] On the other hand, if the information in all fields of the verification information (or in certain implementations, in specially selected important fields) (e.g., DMV vehicle ownership) does in fact match the corresponding information provided by user 112 (e.g., if the owner name, owner address, vehicle identification number, and ownership issue date from the DMV ownership information are substantially the same as the owner name, owner address, vehicle identification number, and ownership issue date obtained from user 112 at block 205), then the user is verified as being associated with the vehicle, and process 200 continues at block 215 to connect to the vehicle. In various embodiments, process 200 (e.g., implemented by the authorization controller 105) may connect to vehicle 150 based on the VIN of vehicle 150 and / or based on other information identifying vehicle 150, as is well known in the vehicle-to-anything (V2X) technical field.

[0066] In Figure 2 In the example shown, at block 220, a process 200 implemented, for example, by an authorization controller 105 as a requester provides login credentials to a vehicle (e.g., 150) to which it is connected. In various implementations, the vehicle 150 may include a gateway 154, and the login credentials (which may include digital certificates) may be provided to the gateway 154 for processing, as is known in the art, e.g., to authenticate a connected device (e.g., the authorization controller 105) as authorized to connect to and interact with the vehicle, according to a security authentication protocol. Based on the login credentials and / or other information, the gateway 154 may: deny all access to in-vehicle data of the vehicle 150 (e.g., if the gateway 154 is unable to authenticate the requester); allow access to a part or subset of the in-vehicle data (e.g., only allow access to the data of ECUs 156 and 158, e.g., according to the authorization scheme for each requester as described above with respect to Table 1), or allow access to all in-vehicle data (e.g., allow access to the data of any and all ECUs 156 - 158, again e.g., according to the authorization scheme as described above with respect to Table 1).

[0067] In some implementations, for example, the process 200 implemented by the authorization controller 105 will utilize requester login credentials that allow access to all in-vehicle data. In some embodiments, the access rights of an entity identified by the login credentials of the entity may be stored in a data structure such as Table 1 above, and the gateway 154 may consult the table to determine the access rights or authorization. For example, in the case where the login credentials identify the requester as an "authorization controller" (e.g., as opposed to a "user" or "repair shop / person"), then as shown in the last row of Table 1, the authorization controller 105 may access all in-vehicle data of the vehicle 150.

[0068] At block 225, a process 200 implemented, for example, by an authorization controller 105 obtains the requested in-vehicle data from the vehicle (e.g., from one or more of the ECUs 156 - 158 of the vehicle 150). As described above, the gateway 154 may restrict access to data of a particular part of the in-vehicle data (e.g., limited to data from a particular ECU, as per Table 1); however, some implementations may allow the process 200 to obtain any and / or all in-vehicle data (e.g., according to the permissions of each authorization controller in Table 1).

[0069] In some variations, the on-vehicle data obtained from the vehicle in block 225 can be copied to a data store (such as 107), etc., which is part of or accessible by the authorized controller 105. In such an implementation, when a copy of the data requested by the relevant user exists in the data store 107, the authorization control can forego operations 215 - 225 and instead obtain the data from the data store 107. In another variation, if the requested data was previously stored by the OEM in the OEM data store 125, it can be obtained additionally or alternatively from the OEM data store 125. For example, when the vehicle 150 is unable to connect to the wireless network 122, this can reduce significant time delays, as well as other technical advantages.

[0070] In block 230, process 200 provides data to the owner of the vehicle. In some implementations, process 200 provides the requested on-vehicle data to the user 112 by displaying the data (e.g., on the graphical user interface of the vehicle user device 110) or by providing a downloadable file via a portal or API, etc., accessed via the vehicle user device 110. After receiving the data, the user 112 can use it for various purposes, including diagnosis, scheduling, and performing repairs and maintenance on the vehicle 150. For example, the user 112 can provide the data to a mechanic at a repair shop or an application that analyzes the data to recommend maintenance, repairs, etc. for the vehicle 150.

[0071] In some use cases, the user 112 can utilize the on-vehicle data obtained by using the system 100 to detect problems in the vehicle 150 that are not obvious, such as a misaligned or damaged camera or other sensors after the vehicle has been hit in a parking lot without the user 112's knowledge. Non-obvious sensor misalignment or damage can be very dangerous as it can have a negative impact on the performance of the vehicle's autonomous driving system, intelligent cruise control system, etc. In another use case, the user 112 can show the on-vehicle data (such as mileage data, airbag data, etc.) to a potential purchaser of the vehicle 150 as evidence that the vehicle 150 is as advertised, e.g., in good working condition, has not been in an accident, etc., similar to a CARFAX TM report.

[0072] In yet another use case, a service technician 132 at an automotive dealership or locksmith shop can use the authorization controller 105 of the system 100 to obtain a security code and / or other vehicle security data from the vehicle 150 and use the vehicle data to create a replacement vehicle key for a customer who owns the vehicle 150 but has lost their electronic key. In various embodiments, the shop personnel 132 can use the shop equipment 130 and the authorization controller 105 to provide relevant user and vehicle information to the system 100 to verify that the customer has the required association with the vehicle 150 (e.g., is the owner, registrant, etc. of the vehicle) and obtain the vehicle data needed to re-encrypt the vehicle for the customer.

[0073] One of ordinary skill in the art will recognize that the operations, functions, blocks, sequences, and orders described in the examples can be changed, deleted, added, or altered without departing from the scope of the present invention. For example, the operations and functions of blocks 215 and 220 can be combined. Figure 2 As another example, although the example described uses the ownership document of the vehicle 150 and verifies whether the user 112 is the owner of the vehicle based on the ownership document information, the process 200 can be changed to use the registration document of the vehicle and verify whether the user 112 is the registrant of the vehicle based on the registration document information. Similarly, before allowing the user 112 to access the vehicle data, the process 200 can be modified to verify that the user 112 is an employee of an organization (e.g., a company) that owns and / or registers the vehicle 150. Also similarly, before allowing the user 112 to access the vehicle data, the process 200 can be modified to verify that the user 112 is a law enforcement officer or agent, and / or that the law enforcement officer or agent has a valid search warrant. Also similarly, before allowing the service technician 132 to access the vehicle data, the process 200 can be modified to verify that the service technician 132 is a bona fide service technician, and / or that the service technician 132 is affiliated with a service shop.

[0074] As another example, although Figure 2 the example described uses the ownership document of the vehicle 150 and verifies whether the user 112 is the owner of the vehicle based on the ownership document information, the process 200 can be changed to use the registration document of the vehicle and verify whether the user 112 is the registrant of the vehicle based on the registration document information. Similarly, before allowing the user 112 to access the vehicle data, the process 200 can be modified to verify that the user 112 is an employee of an organization (e.g., a company) that owns and / or registers the vehicle 150. Also similarly, before allowing the user 112 to access the vehicle data, the process 200 can be modified to verify that the user 112 is a law enforcement officer or agent, and / or that the law enforcement officer or agent has a valid search warrant. Also similarly, before allowing the service technician 132 to access the vehicle data, the process 200 can be modified to verify that the service technician 132 is a bona fide service technician, and / or that the service technician 132 is affiliated with a service shop.

[0075] In yet another example, before performing operations 215 - 225, the authorization controller 105 can determine whether it has a recently uploaded copy of the vehicle data requested by the user in its local storage device (e.g., 107), and if so, the authorization agent 105 can skip operations 215 - 255 and provide the requested data from the copy in operation 230.

[0076] In yet another example, instead of performing operations 215 - 225, the authorization agent 105 can obtain a copy of the requested data from another source. For example, the data of the requested vehicle 150 may have been periodically copied by the OEM of the vehicle 150 to a storage location such as the OEM data storage 125, and the authorization agent 105 can determine that the data is available in the OEM data storage 125 and obtain the data from there.

[0077] Other variations are possible. For example, repair shop 132 may use a process similar to process 200 to access in-vehicle data of a group of vehicles (e.g., a group of vehicles that repair shop 132 has worked on (e.g., the cars of its customers)). Repair shop 132 may provide the VIN of the vehicle recorded in the files of repair shop 132 to process 200 (e.g., at block 205). In this variant, block 210 may be modified, for example, by using business records of state and / or local municipalities, etc. as verification source 115, to confirm that the repair shop has the appropriate state registration, business license, and / or business license associated therewith, to verify that repair shop 132 is a legitimate vehicle repair shop.

[0078] Figure 3 is a flowchart showing an example of process 300 for securely allowing access to in-vehicle operation data stored in a vehicle, consistent with an embodiment of the present invention. In various implementations, some or all of the operations of process 300 may be performed by gateway 154 or a similar component of vehicle 150.

[0079] As Figure 3 shown in the example of, process 300 begins at block 305 by receiving a request for in-vehicle data from a requester. In various implementations, the request may come from an authorized controller 105 acting as the requester. In some implementations, the request may come from a vehicle user device 110 or a shop device 130 acting as the requester. In various implementations, the request may include information authenticating the requester, such as a digital certificate, and information specifying the in-vehicle data being requested.

[0080] At block 305, process 300 authenticates the requester. In various implementations, as is known in the art, block 305 may use a digital certificate and a security authentication protocol to authenticate the requester. If the requester cannot be authenticated (block 305, no), then process 300 ends at block 310 and the interaction with the requester stops. On the other hand, if the requester is authenticated (block 305, yes), then process 300 continues to block 315.

[0081] At block 315, process 300 determines which vehicle data to access based on the identity of the requester. In some embodiments, process 300 may query access rights associated with the identity of the requester to determine which vehicle data to access. For example, referring to Table 1 above, if the requester is an authorized controller (e.g., 105), the rights may indicate that the requester can access all vehicle data, regardless of the ECU that generated or stores the data. As another example, referring to Table 1 above, if the requester is a user (e.g., 112), the rights may indicate that the requester can only access vehicle data related to ECUs 156 and 158. As previously mentioned, in addition to the rights table, other means may be considered to determine which vehicle data to access based on the identity of the requester.

[0082] At block 320, process 300 obtains the appropriate vehicle data. Continuing the example using the table, if the requester is a user (e.g., 112), gateway 154 may obtain the data stored in ECUs 156 and 158 (e.g., copy, or request and receive a copy thereof).

[0083] At block 325, process 300 provides the obtained data to the requester. For example, gateway 154 may package the obtained data into an appropriate digital message and then send the digital message to the requester, e.g., as a response to the request received at block 302. After providing the obtained / requested data to the requester, process 300 ends.

[0084] In addition to those already described, other variations are possible. For example, authorized controller 105 may connect to vehicle 150 periodically or according to the needs of a user (e.g., user 112 or maintenance personnel 132) of system 100 and simply upload copies of some or all of the data from ECUs 156 - 158 of vehicle 150 according to the rights in the fourth row of Table 1. After obtaining copies of the data that can be stored in data memory 107, authorized controller 105 may enforce the data access rights limitations shown in Table 1 for user 112 and maintenance shop 132 on its own. In this variant, the second and third rows of Table 1 may not exist or gateway 154 may not be required.

[0085] In yet another variant, user 112 may provide information (e.g., information from a vehicle registration document) to maintenance shop 132 and authorize maintenance shop 132 to use that information and system 100 to obtain vehicle information from user 112's vehicle 150 on behalf of user 112.

[0086] As described above, in some implementations, users of system 100 (e.g., user 112 and repair shop 132) may pay one or more fees to access in-vehicle data of vehicle 150 and / or other vehicles, and the fees may vary based on how much in-vehicle data is accessed per vehicle and / or which in-vehicle data is accessed and / or how many vehicles are included. For example, referring again to Table 1 above, user 112 may have subscribed to access two types of in-vehicle data from their vehicle 150, such as fault code data (corresponding to or from ECU 156 in this example) and a certain type of telematics data (corresponding to or from ECU 158 in this example), and user 112 may have paid two fees (e.g., two-year subscription fees) to access these two types of data. According to Table 1, system 100 does not allow user 112 to access in-vehicle data other than the data subscribed to by user 112.

[0087] Although the examples described herein use ECUs to describe, type, partition, or classify different types and sources of in-vehicle data available for vehicle 150, this convention is for illustrative clarity and is not meant to be restrictive. In other implementations, in-vehicle data may be described, typed, partitioned, or classified in other ways, such as using categories such as telematics data, fault code data, location data, tire pressure data, etc., which may or may not correspond to ECUs, or may or may not correspond to a particular group of ECUs.

[0088] Figure 4 is a block diagram of an example of a computing environment that includes a computing system 400 that can be used to implement systems, devices, and methods consistent with implementations of the present invention. Other components and / or devices may also be used. In some implementations, one or more computing systems 400 may be used to partially or fully implement various components, processes, operations, and data records related to Figures 1 - 3 such as authorization controller 105, vehicle user device 110, shop device 130, verification source 115, OEM data store 125, and / or gateway 154, etc. In some implementations, a series of computing systems similar to computing system 400 may each be customized with dedicated hardware and / or programmed as dedicated servers to implement one or more Figures 1 - 3 features related thereto, which may communicate with each other via network 435, and network 435 may be the same as, connected to, or a part of networks 120, 122, 112.

[0089] In Figure 4In the example shown, computing system 400 includes multiple components, such as CPU 405, memory 410, input / output (I / O) device 425, hardware security module (HSM) 440, and storage device 420. System 400 can be implemented in various ways. For example, implementation as an integrated platform (such as a server, workstation, personal computer, laptop, etc.) can include CPU 405, memory 410, non-volatile storage device 420, and I / O device 425. In this configuration, components 405, 410, 420, and 425 can be connected and communicate via a local data bus, and can access data repositories 430 (such as data store 107 and / or OEM data store 125) via an external I / O connection. I / O component 425 can be connected to external devices via a direct communication link (such as a wired or local Wi-Fi connection), via network 435 (such as a local area network (LAN) or a wide area network (WAN), such as a cellular phone network or the Internet), and / or via other suitable connections. System 400 can be standalone or a subsystem of a larger system.

[0090] CPU 405 can be one or more known processors or processing devices, such as Core TM series microprocessors manufactured by Intel TM Corporation of Santa Clara, California or Athlon TM series microprocessors manufactured by AMD TM Corporation of Sunnyvale, California. Memory 410 can be one or more fast storage devices configured to store instructions and information executed or used by CPU 405 to perform certain functions, methods, and processes related to the implementation of the present invention. Storage device 420 can be volatile or non-volatile, magnetic, semiconductor, tape, optical, or other types of storage devices or computer-readable media, including devices such as compact discs (CDs) and digital video discs (DVDs) for long-term storage, as well as solid-state devices.

[0091] In the implementation shown, memory 410 contains one or more instructions, programs, or applications 415 that can be loaded from storage device 420 or a remote system (not shown) and, when executed by CPU 405, perform various operations, steps, processes, functions, or methods consistent with the present invention. For example, as described in connection with Figures 1 - 3Alternatively, the CPU 405 may execute one or more programs located away from the system 400. For example, the system 400 may access one or more remote programs via the network 435, which, when executed, perform functions, operations, and processes related to the implementation of the present invention.

[0092] In one implementation, the memory 410 may include a program 415 for performing the dedicated functions and operations described herein with respect to the system 100 to securely access in-vehicle data. In some implementations, the memory 410 may also include other instructions, programs, or applications that implement Figure 2 and Figure 3 the methods, as well as other methods and processes that provide auxiliary functions for the present invention.

[0093] The memory 410 may also be configured with other programs (not shown) unrelated to the present invention and / or an operating system (not shown) that performs several functions known in the art when executed by the CPU 405. For example, the operating system may be Microsoft Windows TM , Unix TM , Linux TM , Apple Computers TM operating system or other operating systems. The choice of operating system, or even the use of an operating system, is not important for the present invention.

[0094] The HSM 440 may be a device with its own processor that securely generates and stores digital security assets and / or securely performs various cryptographic and sensitive computations. The HSM 440 protects digital security assets such as cryptographic keys and other sensitive data from possible access by attackers. In some implementations, the HSM may be a plug-in card or board directly connected to the computing system 400.

[0095] The I / O device 425 may include one or more input / output devices that allow the system 400 to receive and / or transmit data. For example, the I / O device 425 may include one or more input devices capable of receiving input data from a user, such as a keyboard, touch screen, mouse, etc. In addition, the I / O device 425 may include one or more output devices capable of outputting or presenting data to the user, such as a display screen, CRT monitor, LCD monitor, plasma display, printer, speaker device, etc. The I / O device 425 may also include one or more digital and / or analog communication input / output devices that allow the computing system 400 to communicate with other machines and devices, such as digital communication. Other configurations and / or other numbers of input and / or output devices may be incorporated into the I / O device 425.

[0096] In the illustrated implementation, system 400 is connected to a network 435 (e.g., the Internet, a private network, a virtual private network, a cellular network, or other network or combination thereof), which in turn can be connected to various systems and computing machines such as servers, personal computers, laptops, client devices, etc. Generally, system 400 can input data from external machines and devices and output data to external machines and devices via network 435. In some implementations, network 435 can be network 120, 122, or a part of networks 120, 122.

[0097] In Figure 4 the illustrated exemplary implementation, data repository 430 is an independent database external to system 400, such as database 125. In other implementations, data source 430 can be hosted by system 400. In various implementations, data source 430 can manage and store data for implementing systems and methods consistent with the present invention. For example, data source 430 can manage and store data used by operational data access system 100 (e.g., in-vehicle data previously read from vehicle 150).

[0098] Data source 430 can include one or more databases that store information and are accessed and / or managed via system 400. For example, database 430 can be an Oracle TM database, a Sybase TM database, or other relational database. However, the systems and methods consistent with the present invention are not limited to a particular data structure or database, or even to the use of a database or data structure.

[0099] Those of ordinary skill in the art will recognize that Figure 4 the components and implementation details of the systems herein are presented as examples for the sake of concise and clear explanation. Other components and implementation details can be used.

[0100] Although the examples described herein describe the vehicle as a source of in-vehicle operational data, the vehicle is merely an example for clarity of explanation, and the present invention is not meant to be limited to vehicles. The principles of the present invention can be applied to many different types of computerized devices that create, collect, and / or store operational data, such as Internet-of-Things (IoT) devices, V2X roadside units, etc.

[0101] Throughout the specification, including the claims, unless the context requires otherwise, the term "comprising one" shall be understood to be synonymous with "comprising at least one". Further, unless the context requires otherwise, any range set forth in the specification, including the claims, shall be understood to include its end values. Specific values used to describe components shall be understood to be within acceptable manufacturing or industry tolerances known to those of ordinary skill in the art, and any use of the terms "substantially" and / or "about" and / or "generally" shall be understood to fall within those acceptable tolerances. As used herein, the terms "and" and "or" shall be interpreted as "and / or".

[0102] Other embodiments of the invention will be apparent to those of ordinary skill in the art from consideration of the specification and practice of the invention disclosed herein. This specification and the description herein are only by way of example.

Claims

1. A system for accessing in-vehicle operation data from a vehicle, the system comprises: A memory device that contains instructions; A processor operably connected to the memory device and executing the instructions to perform operations, the operations including: Obtaining vehicle information that specifies the vehicle; Obtaining user information that identifies a specific user; Obtaining verification information from a verification source, wherein the verification information describes the vehicle and the specific user; Verifying that the specific user is associated with the vehicle based on the verification information; Communicatively connecting to the vehicle based on the vehicle information; Requesting the in-vehicle operation data from the vehicle; Receiving the in-vehicle operation data from the vehicle; and Providing the in-vehicle operation data to the specific user.

2. The system according to claim 1, wherein Obtaining vehicle information that specifies the vehicle includes: Receiving a Vehicle Identification Number (VIN).

3. The system according to claim 1, wherein Obtaining user information that identifies a specific user includes: Receiving the name and date of birth of the specific user.

4. The system according to claim 1, wherein Obtaining verification information from a verification source includes: Receiving vehicle ownership information from a Department of Motor Vehicles.

5. The system according to claim 1, wherein Obtaining verification information from a verification source includes: Receiving vehicle registration information from a Department of Motor Vehicles.

6. The system according to claim 1, wherein Verifying that the specific user is associated with the vehicle includes: Comparing the user information that identifies the specific user with the verification information that describes the specific user.

7. The system according to claim 1, wherein The operations further include: Storing the in-vehicle operation data received from the vehicle.

8. The system according to claim 7, wherein Providing the in-vehicle operation data to the specific user includes: Providing the stored in-vehicle operation data.

9. The system according to claim 1, wherein The specific user is the vehicle registrant or a maintenance technician.

10. The system according to claim 1, wherein Communicatively connecting to the vehicle based on the vehicle information includes: Communicatively connecting to the vehicle using the Vehicle Identification Number (VIN).

11. A computer-implemented method for accessing in-vehicle operation data in a vehicle, the method comprises: Obtaining vehicle information that specifies the vehicle; Obtaining user information that identifies a specific user; Obtaining verification information from a verification source, wherein the verification information describes the vehicle and the specific user; Verifying that the specific user is associated with the vehicle based on the verification information; Communicatively connecting to the vehicle based on the vehicle information; Requesting the in-vehicle operation data from the vehicle; Receiving the in-vehicle operation data from the vehicle; and Providing the in-vehicle operation data to the specific user.

12. The computer-implemented method according to claim 11, wherein Obtaining vehicle information that specifies the vehicle includes: Receiving a Vehicle Identification Number (VIN).

13. The computer-implemented method according to claim 11, wherein Obtaining user information identifying a specific user includes: Receiving the name and date of birth of the specific user.

14. The computer-implemented method according to claim 11, wherein, Obtaining verification information from a verification source includes: Receiving vehicle ownership information from a department of motor vehicles.

15. The computer-implemented method according to claim 11, wherein, Obtaining verification information from a verification source includes: Receiving vehicle registration information from a department of motor vehicles.

16. The computer-implemented method according to claim 11, wherein, Verifying that the specific user is associated with the vehicle includes: Comparing the user information identifying the specific user with the verification information describing the specific user.

17. The computer-implemented method according to claim 11, wherein, The operation further includes: Storing the in-vehicle operation data received from the vehicle.

18. The computer-implemented method according to claim 17, wherein, Providing the in-vehicle operation data to the specific user includes: Providing the stored in-vehicle operation data.

19. The computer-implemented method according to claim 11, wherein, The specific user is the registrant or maintenance personnel of the vehicle.

20. The computer-implemented method according to claim 11, wherein, Communicatively connecting to the vehicle based on the vehicle information includes: Communicatively connecting to the vehicle using a vehicle identification number VIN.

21. A non-transitory computer-readable medium including instructions that, when executed by a processor, perform a method, the method including: Obtaining vehicle information specifying a vehicle; Obtaining user information identifying a specific user; Obtaining verification information from a verification source, wherein the verification information describes the vehicle and the specific user; Verifying that the specific user is associated with the vehicle based on the verification information; Communicatively connecting to the vehicle based on the vehicle information; Requesting in-vehicle operation data from the vehicle; Receiving the in-vehicle operation data from the vehicle; and Providing the in-vehicle operation data to the specific user.

22. The non-transitory computer-readable medium according to claim 21, wherein, Obtaining vehicle information specifying a vehicle includes: Receiving a vehicle identification number VIN.

23. The non-transitory computer-readable medium according to claim 21, wherein, Obtaining user information identifying a specific user includes: Receiving the name and date of birth of the specific user.

24. The non-transitory computer-readable medium according to claim 21, wherein, Obtaining verification information from a verification source includes: Receiving vehicle ownership information from a department of motor vehicles.

25. The non-transitory computer-readable medium according to claim 21, wherein, Obtaining verification information from a verification source includes: Receiving vehicle registration information from a department of motor vehicles.

26. The non-transitory computer-readable medium according to claim 21, wherein, Verifying that the specific user is associated with the vehicle includes: Comparing the user information identifying the specific user with the verification information describing the specific user.

27. The non-transitory computer-readable medium according to claim 21, wherein, the operations further include: storing the in-vehicle operation data received from the vehicle.

28. The non-transitory computer-readable medium according to claim 27, wherein, providing the in-vehicle operation data to the specific user includes: providing the stored in-vehicle operation data.

29. The non-transitory computer-readable medium according to claim 21, wherein, the specific user is the registrant or maintenance personnel of the vehicle.

30. The non-transitory computer-readable medium according to claim 21, wherein, communicatively connecting to the vehicle based on the vehicle information includes: communicatively connecting to the vehicle using a vehicle identification number VIN.

Images