Method and system for securely accessing operational data

Abstract

Systems, methods, computer-readable media, and devices for accessing on-board 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 verification information, e.g., from a verification source, verifying that a particular user is associated with the vehicle based on the verification information, communicatively connecting to the vehicle based on the vehicle information, obtaining on-board data from the vehicle, and providing the on-board data to a user. In various embodiments, the user may be the owner of the vehicle, the registrant of the vehicle, or a repairperson servicing the vehicle and needing access to on-board data in addition to OBD error codes.

Description

[Technical Field]

[0001] FIELD OF THE INVENTION The present invention relates to systems, apparatus, articles of manufacture, and methods for securely accessing on-board operational data, such as on-board data of a vehicle.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of and priority to U.S. Provisional Application No. 63 / 370,544, filed August 5, 2022, which is incorporated herein by reference in its entirety. [Background technology]

[0003] Modern vehicles, including cars, trucks, SUVs, RVs, boats, snow vehicles, drones, etc., include several computerized subsystems, such as brake control, steering control, electronics, climate control, engine control, backup camera, suspension control, telemetry, door lock, and / or transmission control subsystems, to name a few. The vehicle's subsystems create, collect, track, and / or store data related to their operation, such as operational information about their settings, their functions, the surrounding environment, communications between subsystems, vehicle movements, inputs from the vehicle operator, etc. One category of operational data generated, collected, stored, and used by modern vehicles is called telematics data. Telematics data can include, among other things, information about vehicle usage (e.g., location, speed, etc., from a GPS subsystem, etc.), maintenance requirements (e.g., mileage, warning lights, repair codes, etc., from subsystems onboard the vehicle, etc.), and service (e.g., connection to a scanner device at a vehicle repair shop, etc.).

[0004] Various portions of the on-board vehicle operational data may be read, transmitted, or accessed by the vehicle manufacturer (Original Equipment Manufacturer, or OEM, e.g., Ford, Honda, Chevrolet, etc.) or by a subsystem OEM (e.g., Bosch, Continental, Denso, etc.). Alternatively, it may be read by the manufacturer's representative (e.g., a repair shop of an OEM vehicle distributor, such as a Ford dealer, Honda dealer, or Chevrolet dealer). However, persons who own, lease, and / or use a vehicle currently cannot access the vehicle's on-board data. This lack of data is a significant disadvantage to owners because it can lead to problems, expenses, and disruptions related to maintenance, safety, etc., that the owner could have avoided or mitigated if they had access to the vehicle's operational data. Similarly, independent repair shops that do not have the access provided by OEM sponsorship currently cannot access most of the on-board data (typically with the exception of error codes), resulting in the same disadvantages as those described above. Summary of the Invention

[0005] Systems, methods, computer-readable media, and devices for accessing on-board operational data from a vehicle are disclosed that may include hardware and / or software for performing operations including obtaining vehicle information identifying the vehicle, obtaining user information identifying a particular user, obtaining verification information describing the vehicle and the particular user, e.g., from a verification 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, requesting on-board operational data from the vehicle, receiving the on-board operational data from the vehicle, and providing the on-board operational data to the particular user.

[0006] In one variation, obtaining vehicle information identifying the vehicle includes receiving a Vehicle Identification Number (VIN).

[0007] In one variation, obtaining user information identifying the particular user includes receiving the particular user's name and date of birth.

[0008] In some variations, for example, obtaining the verification information from a verification source includes receiving vehicle entitlement information from a motor vehicle authority. In some variations, for example, obtaining the verification information from a verification source includes vehicle registration information from a motor vehicle authority.

[0009] In one variation, verifying that a particular user is associated with the vehicle includes comparing user information identifying the particular user with verification information describing the particular user.

[0010] In some variations, the operations further include storing the on-board operational data received from the vehicle. In some such variations, providing the on-board operational data to the particular user includes providing the stored on-board operational data.

[0011] In one variation, the particular user is the registrant or repairer of the vehicle.

[0012] Also, in one variation, communicatively connecting to the vehicle based on the vehicle information includes communicatively connecting to the vehicle using a vehicle identification number.

[0013] Systems, methods, computer-readable media, and devices for accessing on-board operational data in a vehicle are also disclosed. These 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 that the user is the owner or registrant of the vehicle based on the user information and vehicle information, communicatively connecting to the vehicle based on the vehicle information, obtaining on-board operational data from the vehicle, and providing the on-board operational data to the user. Variations of this implementation include, among others, all of the variations described above.

[0014] It is contemplated that elements described above may be combined with elements herein unless otherwise inconsistent. [Brief explanation of the drawings]

[0015] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate examples and embodiments of the invention and, together with the description, serve to explain the principles of the invention.

[0016] [Figure 1] 1 is a block diagram illustrating an example system for securely accessing on-board operational data stored in a vehicle, consistent with embodiments of the present invention.

[0017] [Figure 2] FIG. 1 is a flow diagram illustrating an example process for securely accessing on-board operational data stored in a vehicle, consistent with embodiments of the present invention.

[0018] [Figure 3] FIG. 2 is a flow diagram illustrating an example process for providing secure access to on-board operational data stored in a vehicle, consistent with embodiments of the present invention.

[0019] [Figure 4]FIG. 1 is a block diagram of an example computing system that can be used to host and implement systems, functions, operations, and methods consistent with implementations of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0020] Detailed Description Reference will now be made in detail to the present embodiments of the present invention, examples of which are illustrated in the accompanying drawings.

[0021] Various embodiments and implementations consistent with the present invention provide systems, apparatus, methods, and computer program products for securely accessing on-board operational data (also referred to as on-board data) stored in a vehicle, including access by devices (e.g., computers, tablets, smartphones, etc.) of owners, lessors, vehicle registrants, law enforcement agencies, or other entities not associated with an OEM. As described herein, various embodiments provide new technical capabilities and infrastructure for, for example, general vehicle owners (not funded by or non-OEM affiliated), lessors, vehicle registrants, repair shop personnel, etc. to access on-board data (including data other than error codes, which are currently accessible only by OEM affiliates), such as telematics or telemetry data (as opposed to vehicle error code data, which can be accessed by non-OEM on-board diagnostics (OBD) scanners). Various embodiments verify that the user requesting the on-board data is actually associated with the vehicle in a prescribed manner, e.g., as the owner, lessee, registrant, owner-authorized repair shop, etc., before providing access to some or all of the on-board data. In some embodiments, a user associated with a vehicle can set up an account for or containing each owned / leased / registered / repaired vehicle, e.g., based on each vehicle's vehicle identification number (VIN). From that account, the user associated with the vehicle can access (e.g., read or copy) at least a portion of each vehicle's on-board data, which in current conventional systems is accessible only by the OEM.

[0022] 1 is a block diagram illustrating an example system 100 for securely accessing operational data stored onboard a vehicle, consistent with embodiments of the present invention. As shown in this example, a vehicle 150 (e.g., a passenger car in this illustration) is communicatively connected to one or more networks, such as a general-purpose network 120 and a wireless network 122, which may include wired and wireless capabilities. Via networks 120, 122, 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, authorization controller 105 may also be connected to vehicle user device 110, repair shop device 130, verification source device 115, and / or OEM data device 125. As shown in this example, one or more of the remote devices may be associated with a person (e.g., an operator), such as a user 112 (e.g., a vehicle owner) associated with vehicle user device 110 and a repairman 132 associated with shop device 130. Also, as shown in this example, vehicle 150 may be communicatively connected directly to a remote device, such as OBD scanner 140, without utilizing networks 120, 122.

[0023] As shown in the embodiment of FIG. 1 , vehicle 150 includes multiple Electronic Control Units (ECUs) 156, 157, 158, etc. While only three ECUs 156-158 are explicitly depicted, as indicated by the ellipsis, vehicle 150 (e.g., a car or truck) typically has many more ECUs. ECUs are sometimes referred to as Electronic Control Modules (ECMs). In various implementations, the ECUs may be part of embedded subsystems in vehicle 150, and each ECU may control or be part of one or more of the functions, features, or subsystems of a car or other vehicle, such as 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, a security (door lock) subsystem, etc. In some applications, the ECUs may be, be part of, or be connected to an on-board unit (OBU), as known in the art. An ECU is typically a computerized device that, among other things, creates, aggregates, and / or stores data related to itself, the vehicle, and its operation. This data can include telematics data and other non-error code data. Generally, the ECUs 156-58 depicted in FIG. 1 and described herein represent any and all data sources and data storage devices within the vehicle, and the present disclosure is not limited to data originating solely from the ECUs, but instead includes all on-board data within the vehicle 150, regardless of source.

[0024] In the example of FIG. 1 , the ECUs 156-158 are communicatively connected to a gateway 154, which has novel operations and functionality 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 or firewall device) that controls communication with and access to the ECUs 156-158 and their data. In such embodiments, the gateway 154 can function to block access to the ECUs 156-158 and their data from unauthorized requestors (e.g., deny read requests) and to grant access, or partial access, to the ECUs 156-158 and their data for authorized requestors. While the term ECU is used herein for clarity, it should be noted that the present disclosure includes any data source onboard the vehicle 150, including an ECU.

[0025] As shown, gateway 154 is communicatively coupled to communication port 152, which may be or include an on-board diagnostic (OBD) port, such as that of a passenger vehicle, as is known in the art. In some embodiments, communication port 152 may be or include hardware connection point(s), such as an OBDII 16-pin diagnostic connector. In other embodiments, communication port 152 may be or include a device that includes one or more wireless connection point(s) (e.g., Bluetooth, LAN, cellular, etc.) and possible hardware connection point(s).

[0026] In various embodiments, a remote device can communicatively connect (e.g., wired or wirelessly) to communication port 152 and interact with gateway 154. In one illustrated example, the remote device can include an OBD scanner 140 (also known as an automotive diagnostic code reader). In another example, the remote device can be authorized controller 105, which is a new device with novel operations and functionality as described herein. OBD scanners are known in the art and are intended for use by, for example, a mechanic to simply read error codes from vehicle 150. In this example, OBD scanner 140 can be connected to communication port 152 using a wire cable that a mechanic plugs into communication port 152. Authorized controller 105 can be wirelessly connected to communication port 152. For example, via a cellular connection provided via wireless network 122, various embodiments allow entities not affiliated with the OEM, such as user 112 or repairman 132, to indirectly or directly access on-board operational data from vehicle 150.

[0027] Gateway 154 can receive and process requests for in-vehicle data from remote devices, each of which can identify the requestor, the in-vehicle data desired by the requestor, and / or the ECU 156-158 that will provide the data.

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

[0029] Based on the identity of each authenticated requestor and / or the data being requested from the ECU, gateway 154 can deny (e.g., block) or accept the request, thereby allowing the authenticated requestor to access the requested data. For example, gateway 154 can grant a request from OBD scanner 140 to read error code data from the vehicle (as known in the art) and can deny a request from OBD scanner 140 to read telematics data from the vehicle.

[0030] In some embodiments, gateway 154 can use pre-stored access permission(s) to determine whether an authenticated requestor is authorized to access (e.g., read, copy, receive, etc.) data from a particular ECU, which can correlate with a particular type of data. In various embodiments, the access permission(s) stored in gateway 154 can be updated or changed periodically or as needed, for example, to add a new authorization requestor, typically a remote device (such as a new authorization controller 105) positioned to access some or all of the on-board data of vehicle 150, or to remove or update the access permissions of a previous authorization requestor, for example, after their access authorization has changed.

[0031] In one embodiment, the access permissions may be in the form of a lookup table, such as Table 1 below. As shown, Table 1 may indicate that OBD scanner 140 can obtain data from ECU 156 (which in this example is the ECU that generates and maintains the vehicle's error code data), but cannot access data from ECU 157 or ECU 158. Similarly, according to Table 1, if the requestor is an OEM-affiliated repair shop, gateway 154 will provide access to on-board data related to ECU 156, 157, or 158. If the requestor is an independent repair shop, gateway 154 will provide access to on-board data related to ECU 156 or 157. If the requestor is a user of the vehicle (e.g., the registrant, among other things), gateway 154 will provide access to on-board data associated with ECU 156 or 158. And, if the requestor is an authorized controller, all of the on-board data may be accessed. [Table 1]

[0032] If the request is denied (e.g., according to the permissions stored in Table 1), the authenticated requestor is denied access to the requested data. If the request is authorized by gateway 154, the requestor can access the data from the requested ECU. For example, the requestor can upload, copy, receive, or retrieve the data from the requested ECU.

[0033] In one embodiment, the authorization controller 105 can set or provide access permissions used by the gateway 154 to determine whether a requestor is authorized to access particular in-vehicle data. For example, the authorization controller 105 can create and / or modify a lookup table, such as Table 1, to grant or remove permissions for particular requestors, types of requestors, and / or roles. The authorization controller 105's ability to set access permissions is represented in Table 1 by listing the gateway "GW154" as a component that the authorization controller 105 can access.

[0034] As described above, system 100 includes communicatively coupled network 120 and wireless network 122. Network 120 can be, or be 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 thereof. Wireless network 122 can be, or be part of, any type of wireless network, such as a cellular network, a wireless local area network, a wireless wide area network, or any combination thereof. While network 120 and wireless network 122 are shown as separate entities in FIG. 1 for clarity of illustration, in various embodiments, network 120 and wireless network 122 can be combined into a single network capable of both wired and wireless communication. As described above, networks 120 and 122 can connect to various systems and computerized devices, such as servers, portal computers, laptop computers, client devices, smartphones, etc. Generally, networks 120 and 122 enable digital communication between computerized devices connected thereto, including computerized devices included in vehicle 150, such as ECUs 156-158 and gateway 154.

[0035] As described above, system 100 includes novel authorization controller 105. Authorization controller 105 may be implemented as a server computer (e.g., having at least one processor and associated data storage device(s), such as memory). In various implementations, authorization controller 105 may function to, among other things, authenticate and securely communicate with users of system 100, e.g., user 112 / vehicle user device 110 or repairer 132 / shop device 130, securely communicate with and manage a vehicle gateway device (e.g., gateway device 154), and verify authorization from one or more verification sources 115 (e.g., a Department of Motor Vehicle Authority, Department of Motor Vehicles, etc.). Vehicles: Functions to securely communicate with and aggregate verification information from verification sources 115, including those maintained by the DMV or copies of records maintained by the DMV, securely communicate with and aggregate information from manufacturers (OEMs, such as OEM data storage 125 for the manufacturer of vehicle 150), create and store account records for users 112, repairers 132, etc., create and securely distribute access permissions to vehicle 150 (e.g., as described with respect to Table 1 above), and / or retrieve, copy, distribute, and / or store on-board data from vehicle 150 (e.g., in data storage 107, which may be a database hosted on the same or a different computer as controller 105, etc.).

[0036] As shown in the example of FIG. 1 , authorization controller 105 is communicatively coupled via network 120 to OEM data storage 125 (which may be implemented, for example, as a server hosting a database containing OEM data). OEM data storage 125 may store data, information, and digital assets related to individual vehicles manufactured by the OEM (e.g., copies of on-board data from vehicle 150 collected and stored by the OEM) and / or related to a group or type of vehicle to which vehicle 150 belongs (e.g., data for a 2019 Nissan Murano, such as maintenance reports and recalls). While FIG. 1 uses “OEM” data storage 125 as a convenient label, various other embodiments may include any data collected or stored by other entities (e.g., on-board data from vehicle 150). Embodiments of system 100 are not limited to only OEM-supplied data.

[0037] The authorization controller 105 is also communicatively connected to store devices 130, which in various embodiments may be implemented as a separate computerized device (e.g., a server, smartphone, tablet, or other computer) that connects to, for example, a web portal, an application programming interface (API), or other interface that launches applications controlled by or interacting with the authorization controller 105, among other implementations. In various implementations, repairers 132, who are staff members of a vehicle repair shop, can use store devices 130 to connect and interact with the authorization controller 105 and manage their access to on-board data, devices, and subsystems (e.g., ECUs 156-158) of the vehicle 150 and / or other vehicles serviced by the repair shop. As used herein, "repairer" is not meant to be limited solely to a person who performs repairs, but instead is used to refer to any person or entity that provides any type of service of or for a vehicle, including technical and maintenance services, including, but not limited to, locksmith services, transmission service services, brake service services, engine service services, tire service, fueling or charging services, etc. Similarly, the terms "shop" and "repair shop" are not meant to be limited to merely a shop or a shop that performs vehicle repairs, but are used to refer to any establishment or organization that provides any type of service of or for vehicles.

[0038] In various implementations, a repairer 132 can employ in-store devices 130 to perform several functions within system 100. While FIG. 1 uses a “repairer” 132 as a convenient example, in some embodiments, this 132 can be another person associated with the repair shop, such as an owner, manager, or employee. In various embodiments, the functionality of the in-store devices 130 includes, but is not limited to, interacting with authorization controller 105, verifying the authenticity of in-store devices 130 and / or repairers 132, establishing accounts for the repair shop, and managing access to on-board vehicle data, such as for vehicles 150. In such implementations, authorization controller 105 can verify that a repair shop with in-store devices 130 and repairers 132 is a legitimate vehicle repair shop, for example, by verifying that the repair shop is properly registered with the state and / or has the proper business permits and licenses associated with it. This can be done using state and / or local business records and similar verification information from verification source 115. Similarly, the authorization controller 105 can verify that the shop's repairperson 132 is a legitimate automotive mechanic by verifying that the person 132 has a professional license, mechanic's license, or other verification information. This can be done using state or local licensing records or professional training organization records (e.g., National Institute for Automotive Service Excellence (ASE) records) from a verification source 115. In some implementations, the repair shop may pay a fee(s) (e.g., a subscription fee) for the in-vehicle operational data access service(s) provided by the authorization controller 105, which fee(s) may vary depending on the amount and / or type of in-vehicle data accessed and the number of vehicles covered.

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

[0040] 1 , the authorization controller 105 is also communicatively connected to a vehicle user device 110, which may be implemented in various embodiments as a separate computerized device (e.g., a server, smartphone, tablet, or other computer) that connects to a web portal or other interface controlled by the authorization controller 105 or launches an application to interact with the authorization controller 105, among other implementations. In various implementations, a user 112 associated with the vehicle 150 (such as the owner, lessor, registrant, and / or operator of the vehicle 150) may employ the vehicle user device 110 to interact with the authorization controller 105, verify their identity and affiliation (e.g., owner, lessor, registrant, etc.) with the vehicle 150, set up personal accounts, and manage their access to data for the vehicle 150 and / or other vehicles they own, operate, or are otherwise associated with.

[0041] In terms of the vehicle user devices 110 and the store devices 130, the system 100 can be thought of as providing a new Role Based Access Control (RBAC) capability for on-board data within the vehicle 150. Other implementations of the system 100 may include additional interfaces and / or additional ports that support access for additional roles in addition to the vehicle user and repairer / store roles.

[0042] In various embodiments, the authorization controller 105 may authenticate or verify that the user 112 using the vehicle user device 110 has a particular relationship to the vehicle 150 (e.g., being the actual owner, lessor, and / or registrant of the vehicle 150, among other things) before allowing the user 112 to access on-board data from the vehicle 150, such as operational data related to the ECUs 156-158. In some such embodiments, the authorization controller 105 and / or the vehicle user device 110 may collect information from the user 112 that is used to verify that the user 112 has a relationship with the vehicle claimed by the user 112, such as claiming to be the owner, lessor, and / or registrant of the vehicle 150. The information collected from the user 112 should include information available independently of the verification source 115, such as the DMV. Two examples of information collected from user 112 are information from a registration document issued by the DMV for vehicle 150 (e.g., registrant's name, registrant's address, vehicle title number, vehicle identification number (VIN), registration status, registration issue date, license plate number, vehicle make, model, year, vehicle purchase date, etc.) and / or information from a DMV-issued entitlement document for vehicle 150 (e.g., owner's name, owner's address, title number, entitlement status, vehicle identification number, entitlement issue date, vehicle make, model, and year, entitlement odometer reading, previous entitlement number, etc.).

[0043] In some embodiments, the information collected from the user 112 may include information used by the authorization controller 105 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 may be used to set up two-factor authentication for the account so that the system can authenticate the identity of the user 112 upon subsequent login via the vehicle user device 110.

[0044] In various embodiments, authorization controller 105 may not allow user 112 to access data from vehicle 150 unless authorization controller 105 can verify that user 112 truly has the claimed relationship to 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, authorization controller 105 may access and analyze data (e.g., verification information) from verification source 115, which in this example is the DMV of the state in which vehicle 150 is registered. For example, authorization controller 105 may verify that the registration information entered by user 112 (e.g., registrant name, registrant address, vehicle title number, vehicle identification number, registration issue date, license plate number, vehicle make, model, year, and vehicle purchase date) matches the registration information from DMV 115 for vehicle 150. In such an embodiment, a user 112 who does not have all the registration information will not be able to access data from the vehicle 150 because the system 100 will detect that they are not the person who registered the vehicle 150 with the DMV.

[0045] In some situations, a vehicle may be legally owned by a financial institution or leasing party, and a user 112 may be a loan borrower or lessee who registers, owns, and drives the vehicle 150 even though they do not legally own the vehicle 150 and therefore do not have any entitlement documents. Because the vehicle is registered to a user 112, either alone or jointly, the system 100 allows such a user 112 to access the vehicle 150's data. Similarly, a vehicle may be owned by an organization, such as a business, and the user 112 may be an employee (or the like) of the organization. An embodiment of the system 100 may allow the employee / user 112 to access the vehicle 150's data when the employee / user 112 can provide the organization's vehicle registration information to the authorization controller 105. The authorization controller 105 verifies that the information matches registration records from a verification source 115 (e.g., the DMV).

[0046] In some embodiments, if the authorization controller 105 can confirm that the user 112 is in fact a law enforcement officer or agent, the authorization controller 105 can 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 can access and analyze data or verification information from a verification source 115, such as a state or federal law enforcement database that holds identifying information (e.g., name, Social Security number, date of birth, officer badge number or identification number, biometric data, etc.) about law enforcement officers and agents within a jurisdiction. In some such embodiments, the system 100 can also require and verify that the law enforcement officer or agent has a search warrant for the vehicle 150 before allowing access to the on-board data.

[0047] As a simple, non-limiting use case for system 100 (among other things), consider an example in which user 112 is the owner of vehicle 150, which is registered to user 112 with a state DMV. User 112 can interact with authorization controller 105 using vehicle user device 110. In one embodiment, vehicle user device 110 can be a laptop computer that interacts with an internet website (e.g., a web portal) controlled by authorization controller 105. User 112 can enter information from a vehicle registration document issued by their state DMV for vehicle 150, such as their name, their address, vehicle title number, vehicle identification number, vehicle license plate number, and vehicle make, model, and year. User 112 can then request access to all or a portion of vehicle 150's on-board data (e.g., request data from all ECUs, request telematics data, or request data from specific subsystems, such as data from only ECUs 156 and 158). In one embodiment, the user 112 may pay a fee for the data access service(s) provided by the authorization controller 105, which may vary depending on the amount and / or type of in-vehicle data accessed.

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

[0049] If the two data sets match, then in this example, it can be assumed that authorization controller 105 has confirmed that user 112 is indeed the registered owner of vehicle 150. Following verification, authorization controller 105 can connect to vehicle 150 via networks 120 and 122 to request or obtain the on-board data identified by user 112. Authorization controller 105 can then provide the requested on-board data to user 112, for example, by displaying it or by providing a downloadable file via vehicle user device 110. Thus, system 100, in this example, provides new technical capabilities and a new technical infrastructure for enabling verified user 112, who has registered vehicle 150, to access on-board data from vehicle 150, providing novel and secure data retrieval capabilities not currently present in conventional systems.

[0050] Those skilled in the art will recognize that the components, processes, data, operations, and implementation details shown in FIG. 1 are examples presented for brevity and clarity of explanation. This example is not intended to be limiting, and many variations are possible; other components, processes, implementation details, and variations can be used without departing from the principles of the invention. For example, while FIG. 1 shows a single instance of vehicle 150 for clarity of explanation, the invention is not so limited, and in other embodiments, multiple vehicles 150 may be present. Similarly, while FIG. 1 shows single instances of components 105, 110, 115, 120, 122, 125, and 130 for clarity of explanation, the invention is not so limited, and in other embodiments, multiple instances of any or all of these may be present.

[0051] For example, an embodiment of the system 100 may include multiple components akin to user devices 110 or store devices 130, as well as multiple entities akin to users 112 or repairers 132, to enable those entities to access on-board data within a vehicle 150(s) in a similar manner.

[0052] As another example, system 100 may include charger / fueling devices and / or applications and / or corresponding web portals or APIs managed by authorization controller 105, through which charging stations, charge point operators, e-mobility service providers, gas stations, etc., can access on-board data for the vehicles they are charging / fueling, similar to that described herein. In yet another example, system 100 may include application portals or APIs managed by authorization controller 105, through which software applications (e.g., mobile navigation apps seeking to use vehicle 150's positioning data) and the like can access on-board data, as described herein. In yet other embodiments, there may be a single type of multi-purpose API or portal (e.g., a combination of web portals that can be used by devices 110 and 130) that allows multiple different types of entities (e.g., 110 / 112, 130 / 132) to access on-board data. Other variations are possible.

[0053] In yet another example, an embodiment may not include or utilize a verification source 115. In such an embodiment, the authorization controller 105 may verify that the user is associated with a vehicle using information provided by the user 112, such as a copy of the user's driver's license and a copy of the user's vehicle entitlement and / or registration. Using these documents, the authorization controller 105 may verify that the user information from the driver's license, such as name, date of birth, and address, matches the corresponding verification information from the vehicle entitlement document and / or vehicle registration document.

[0054] In yet another example, one skilled in the art will recognize that in other embodiments, the permission and authorization data structure represented by Table 1 can be replaced with other means and / or data structures for determining what in-vehicle data a requestor can access.

[0055] Those skilled in the art will further recognize that while a passenger car is used as an example of vehicle 150 in Figure 1 and elsewhere herein, vehicle 150 may be any type of vehicle, such as a truck, SUV, RV, boat, aircraft, snow vehicle, drone, etc. The inventors further note that while communication port 152 is described with reference to Figure 1 for clarity, the exact hardware and technology used to connect gateway 154 to a requestor is not critical to the present invention.

[0056] 2 is a flow diagram illustrating an example process 200 for securely accessing on-board operational data stored in a vehicle consistent with embodiments of the present invention. In various implementations, some or all of the operations of process 200 may be performed by the authorization controller 105 or a similar computing system.

[0057] 2, process 200 begins by obtaining user information and vehicle information at block 205. In various implementations, this vehicle information may include information that uniquely identifies a vehicle (e.g., a VIN if the vehicle is a passenger car) and may also include a description (e.g., name, category, etc.) of the operational data that the user requests to obtain from vehicle 150, such as "location data, speed data, idle time data, acceleration data, braking data, fuel consumption data, and tire pressure data." In various implementations, user information may include information that uniquely identifies a particular user, such as a driver's license number, social security number, registration number, or entitlement number.

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

[0059] In some implementations of block 205, process 200 may prompt user 112 to enter information from a vehicle entitlement document and / or vehicle registration document, or information typically found on a vehicle entitlement document. In some such implementations, process 200 may also prompt and / or require the user to enter information about themselves (e.g., information from a driver's license or other government-issued identification) and / or information corresponding to the vehicle (e.g., 150) associated with the user (e.g., owner, lessor, registrant, operator, repairer, fuel supplier, etc.), such as information from the entitlement document, such as the owner's name, owner's address, entitlement number, entitlement status, vehicle identification number, entitlement issue date, vehicle make, model, and year. Additionally or alternatively, process 200 may prompt and / or request the user to upload a copy (e.g., a PDF scan, a JPG digital photo, etc.) of the vehicle's 150 entitlement and / or registration documents and / or the user's 112 driver's license or mechanic's license.

[0060] In block 210, process 200 determines or verifies whether the user is associated with the vehicle in a predetermined manner. Non-limiting examples of permissible associations include being the owner of the vehicle, being the registrant of the vehicle, being the lessor of the vehicle, being a lien holder on the vehicle, being a service technician who repairs or refuels the vehicle, etc. In various implementations, authorization controller 105 can use data from verification source 115 to make this determination. For example, if vehicle 150 is a passenger car and user 112 is the owner, this verification source 115 can be a DMV website or database, an auto dealer's records for new car sales or leasing, or the like. In such cases, authorization controller 105 can use the entitlement number (and / or other information) obtained from user 112 in block 205 to request, download, access, or obtain verification information, such as an electronic copy of the vehicle entitlement. After obtaining the electronic copy of the vehicle entitlement from DMV 115, authorization controller 105 can compare the verification information in one or more fields of the vehicle entitlement with corresponding information provided by the owner / user.

[0061] Continuing with the vehicle owner example, if the verification information in one (or in some implementations, two or more) fields of the vehicle entitlement does not match the corresponding information provided by user 112 (e.g., if the owner's name, owner's address, vehicle identification number, and / or entitlement issue date from the DMV entitlement information do not match the owner's name, owner's address, vehicle identification number, and entitlement issue date obtained from user 112 in block 205), user 112 is not verified to be associated with vehicle 150, and process 200 ends (block 212). In some embodiments, upon ending process 200, process 200 may communicate to user 112 that it was unable to confirm or verify that user 112 is associated with the vehicle, in which case the user is not authorized to access the vehicle data because they were not verified as the owner.

[0062] On the other hand, if the information in all fields (or, in some implementations, certain selected significant fields) of the verification information, e.g., DMV vehicle entitlement, actually matches the corresponding information provided by user 112 (e.g., if the owner's name, owner's address, vehicle identification number, and entitlement issue date from the DMV entitlement information are essentially the same as the owner's name, owner's address, vehicle identification number, and entitlement issue date obtained from user 112 in block 205), then the user is verified as associated with the vehicle, and process 200 proceeds to connect to the vehicle in block 215. In various embodiments, (e.g., when implemented in authorization controller 105) process 200 can connect to vehicle 150 based on the VIN of vehicle 150 and / or other information identifying vehicle 150, as is known in the vehicle-to-all V2X technology arts.

[0063] 2, for example, process 200 implemented in authorization controller 105 as a requestor provides login credentials to the connected vehicle (e.g., 150) in block 220. In various implementations, vehicle 150 may include gateway 154, and the login credentials (which may include a digital certificate) may be provided to gateway 154 for processing, for example, according to a secure authentication protocol for authenticating the connected device (e.g., authorization controller 105) as authorized to connect to and interact with the vehicle, as known in the art. Based on the login credentials and / or other information, gateway 154 may deny all access to vehicle 150's on-board data (e.g., if gateway 154 is unable to authenticate the requestor), may allow access to some or a subset of the on-board data (e.g., allowing access to data for ECUs 156 and 158 in accordance with an authorization scheme for each requestor, such as described above with respect to Table 1), or may be configured to allow access to all of the on-board data (e.g., allowing access to data for any and all of ECUs 156-158 in accordance with an authorization scheme, also described above with respect to Table 1).

[0064] In one implementation, process 200 (e.g., implemented in authorization controller 105) utilizes requestor login credentials that allow access to all on-board data. In one embodiment, access permissions for an entity identified by its login credentials can be stored in a data structure such as Table 1 above, and gateway 154 can search that table to determine access permissions or authorization. For example, if the login credentials identify the requestor as an "authorization controller" (as opposed to, e.g., a "user" or a "repair shop / repairman"), then authorization controller 105 can access all on-board data for vehicle 150, as shown in the last row of Table 1.

[0065] Process 200, implemented in, for example, authorization controller 105, retrieves the requested in-vehicle data from vehicle 150, for example, from one or more of ECUs 156-58 in block 225. As discussed above, gateway 154 may restrict data access to certain portions of the in-vehicle data (e.g., limited to data from specific ECUs, e.g., data according to Table 1). However, some implementations may allow process 200 to retrieve any and / or all of the in-vehicle data (e.g., as permitted by the authorization controller according to Table 1).

[0066] In one variation, the on-board data retrieved from the vehicle in block 225 may be copied to a data storage (e.g., 107) that is part of or accessible by the authorization controller 105. In such an implementation, if a copy of the relevant user-requested data exists in the data storage 107, the authorization controller may forgo operations 215-225 and instead retrieve the data from the data storage 107. In another variation, the requested data may additionally or alternatively be retrieved from the OEM data storage 125 if it was previously stored there by the OEM. This may, among other technical advantages, reduce significant time delays, for example, if the vehicle 150 is unable to connect to the wireless network 122.

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

[0068] In one use case, user 112 can use on-board data obtained using system 100 to detect non-obvious issues with vehicle 150, such as a camera or other sensor that is misaligned or damaged after the vehicle is hit in a parking lot without the user 112's knowledge. Misalignment or damage to a non-obvious sensor can be very dangerous because it adversely affects the performance of the vehicle's autonomous driving system, intelligent cruise control system, etc. In another use case, user 112 can show on-board data (e.g., mileage data, airbag data, etc.) to a potential buyer of vehicle 150 as proof that the vehicle 150 is as advertised, e.g., in good condition, accident-free, etc., akin to a CARFAX™ report.

[0069] In yet another use case, a repairman 132 at an auto shop or locksmith shop can use the authorization controller 105 of the system 100 to obtain a security code and / or other on-board security data from the vehicle 150 and use the on-board data to create a replacement smart key for a customer who owns the vehicle 150 but has lost the smart key. In various embodiments, a store clerk 132 can use the store device 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., being the owner, registrant, etc.) and obtain the on-board data necessary to change the vehicle key for the customer.

[0070] Those skilled in the art will recognize that the operations, functions, blocks, sequences, and orders described in the embodiment of Figure 2 may be changed, deleted, added, or modified without departing from the scope of the present invention. For example, the operations and functions of blocks 215 and 220 may be combined.

[0071] While the embodiment described in FIG. 2 uses an entitlement document for vehicle 150 to verify whether user 112 is the owner of the vehicle based on information in the entitlement document, in another embodiment, process 200 can be modified to use a registration document for the vehicle to verify whether user 112 is the registered owner of the vehicle based on information in the registration document. Similarly, process 200 can be modified to verify that user 112 is an employee of the organization (e.g., a business) that owns and / or registers vehicle 150 before allowing user 112 to access on-board data. Similarly, process 200 can be modified to verify that user 112 is a law enforcement officer or agent and / or that the law enforcement officer or agent has a valid search warrant before allowing user 112 to access on-board data. Similarly, process 200 can be modified to verify that repairer 132 is a legitimate repairer and / or that repairer 132 is affiliated with a repair shop before allowing repairer 132 to access on-board data.

[0072] In yet another embodiment, before performing operations 215-225, the authorization controller 105 can determine whether there is a copy of the recently uploaded user-requested in-vehicle data in local storage (e.g., 107), and if there is, the authorization agent 105 can omit operations 215-225 and provide the requested data in operation 230 from that copy.

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

[0074] Other variations are possible. For example, a process similar to process 200 may be used by a repair shop 132 to access on-board data for a group of vehicles, such as a group of vehicles (e.g., customer vehicles) that the repair shop 132 has worked on. The repair shop 132 may provide (e.g., in block 205) the vehicle's VIN as recorded on file at the repair shop 132 to process 200. In such a variation, block 210 may be modified to verify that the repair shop 132 is a legitimate vehicle repair shop, for example, by verifying that the repair shop has proper state registration, associated business permits and / or licenses, using state and / or local government business records, etc. as verification source 115.

[0075] 3 is a flow diagram illustrating an example process 300 for providing secure access to on-board operational data stored in a vehicle, consistent with embodiments 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.

[0076] 3 , process 300 begins by receiving a request for in-vehicle data from a requestor at block 305. In various implementations, the request can be from the authorization controller 105 as the requestor. In some implementations, the request can be from the vehicle user device 110 or the store device 130 as the requestor. In various implementations, the request can include information authenticating the requestor, such as a digital certificate, and information identifying the in-vehicle data being requested.

[0077] In block 305, process 300 authenticates the requestor. In various implementations, block 305 may authenticate the requestor using digital certificates and secure authentication protocols, as known in the art. If the requestor cannot be authenticated (No at block 305), process 300 ends at block 310 and discontinues interaction with the requestor. On the other hand, if the requestor is authenticated (Yes at block 305), process 300 proceeds to block 315.

[0078] At block 315, process 300 determines which in-vehicle data to access based on the requestor's identity. In some embodiments, process 300 may look up access permissions associated with the requestor's identity to determine which in-vehicle data to access. For example, referring to Table 1 above, if the requestor is an authorization controller (e.g., 105), the permissions may indicate that the requestor has access to all of the in-vehicle data, regardless of the ECU that generated or stored the data. As another example, referring to Table 1 above, if the requestor is a user (e.g., 112), the permissions may indicate that the requestor has access only to in-vehicle data associated with ECUs 156 and 158. As previously discussed, it is contemplated that the in-vehicle data to access based on the requestor's identity may be determined by other means than just the permission table.

[0079] At block 320, process 300 reads the appropriate on-board data. Continuing with this example using a table, if the requestor is a user (e.g., 112), gateway 154 can read (e.g., copy, or request and receive a copy of) the data stored in ECU 156 and ECU 158.

[0080] At block 325, process 300 provides the read data to the requestor. For example, gateway 154 may package the read data into appropriate digital message(s) and then send the digital message(s) to the requestor, for example, as a response to the request received at block 302. After providing the read / requested data to the requestor, process 300 ends.

[0081] In addition to those already described, other variations are possible. For example, authorization controller 105 could connect with vehicle 150 periodically, or upon request of a user of system 100 (e.g., user 112 or repair shop 132), and simply upload copies of some or all of the data from all (or some) of vehicle 150's ECUs 156-158, in accordance with its permissions in row 4 of Table 1. After obtaining copies of the data, which may be stored in data storage 107, authorization controller 105 could itself implement the data access permission restrictions shown in Table 1 for user 112 and repair shop 132. In such variations, rows 2 and 3 of Table 1 may not be present or needed in gateway 154.

[0082] In yet another variation, the user 112 can provide information (e.g., information from vehicle registration documents) to the repair shop 132 and authorize the repair shop to use that information and the system 100 to retrieve on-board information from the user's 112 vehicle 150 on the user's 112's behalf.

[0083] As previously mentioned, in some implementations, users of system 100 (e.g., user 112 and repair shop 132) may pay one or more fees to access on-board data for vehicle 150 and / or other vehicles. The fee(s) may vary depending on the amount and / or type of on-board data accessed in each vehicle and / or the number of vehicles involved. For example, referring again to Table 1 above, user 112 may subscribe to access two types of on-board data from vehicle 150, e.g., error code data (corresponding to or originating from ECU 156 in this example) and a type of telematics data (corresponding to or originating from ECU 158 in this example), and user 112 may pay two fees (e.g., two annual subscription fees) for access to these two types of data. According to Table 1, system 100 does not allow user 112 to access on-board data other than the data to which user 112 has subscribed.

[0084] Although the examples described herein use ECUs to describe, populate, segment, or categorize the distinct types and sources of in-vehicle data available from vehicle 150, this convention is for clarity of explanation and is not meant to be limiting. In other embodiments, in-vehicle data may be described, populated, segmented, or categorized in other ways, using categories such as, for example, telematics data, error code data, location data, tire pressure data, etc., which do not necessarily correspond to an ECU or a particular set of ECUs.

[0085] FIG. 4 is a block diagram of an example computing environment, including 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 arrangements can also be used. In some implementations, one or more computing systems 400 can be used to partially or fully implement the various components, processes, operations, and data records described in connection with FIGS. 1-3 , such as the authorization controller 105, the vehicle user device 110, the store device 130, the verification source 115, the OEM data storage 125, and / or the gateway 154, among others. In some implementations, a series of computing systems similar to computing system 400 can each be customized with dedicated hardware and / or programmed as a dedicated server to implement one or more of the features described in connection with FIGS. 1-3 . They can communicate with each other via a network 435, which in turn can be connected to or be part of networks 120, 122.

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

[0087] CPU 405 may be one or more known processors or processor devices, such as, for example, the Core™ family of microprocessors manufactured by Intel™ Corporation of Santa Clara, Calif., or the Athlon™ family of microprocessors manufactured by AMD™ Corporation of Sunnyvale, Calif. Memory 410 may be one or more high-speed storage devices configured to store instructions and information executed or used by CPU 405 to perform certain functions, methods, and processes related to implementations of the present invention. Storage 420 may be volatile or non-volatile, magnetic, semiconductor, tape, optical storage, or another type of storage device or computer-readable medium, including devices intended for long-term storage, such as CDs and DVDs and solid-state devices.

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

[0089] In one implementation, memory 410 can include program(s) 415 for performing the dedicated functions and operations described herein with respect to system for securely accessing on-board vehicle data 100. In some implementations, memory 410 can also include other instructions, programs, or applications that implement the methods of Figures 2 and 3, as well as other methods and processes that provide auxiliary functionality to the present invention.

[0090] Memory 410 may also be configured with other programs (not shown) unrelated to the present invention and / or an operating system (not shown) that, when executed by CPU 405, performs certain functions known in the art. By way of example, this operating system may be Microsoft Windows™, Unix™, Linux™, an Apple Computer™ operating system, or other operating system. The choice of operating system, and even the use of an operating system, is not critical to the present invention.

[0091] HSM 440 can be a device with its own processor that securely generates and stores digital security assets and / or securely performs various cryptographic and sensitive calculations. HSM 440 protects digital security assets such as cryptographic keys and other sensitive data from potential access by attackers. In one implementation, HSM can be a plug-in card or board attached directly to computing system 400.

[0092] The I / O device(s) 425 may include one or more input / output devices that allow data to be received and / or transmitted by the system 400. For example, the I / O device(s) 425 may include one or more input devices, such as a keyboard, touch screen, mouse, etc., that allow for input of data from a user. Additionally, the I / O device(s) 425 may include one or more output devices, such as a display screen, CRT monitor, LCD monitor, plasma display, printer, speaker device, etc., that allow for output or presentation of data to a user. The I / O device(s) 425 may also include one or more digital and / or analog communication input / output devices that allow the computing system 400 to communicate, e.g., digitally, with other machines and devices. Other configurations and / or multiple input and / or output devices may be incorporated into the I / O device(s) 425.

[0093] 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 a combination thereof), which may further connect to various systems and computing machines, such as servers, personal computers, laptop computers, client devices, etc. Generally, system 400 can input data from and output data to external machines and devices via network 435. In some implementations, network 435 can be, or be part of, networks 120, 122.

[0094] 4, data repository 430 is a standalone database external to system 400, such as database 125. In other implementations, data source 430 may be hosted by system 400. In various implementations, data source 430 may manage and store data used to implement systems and methods consistent with the present invention. For example, data source 430 may manage and store data used by operational data access system 100 (e.g., on-board data previously read from vehicle 150).

[0095] Data source 430 may include one or more databases that store information and that are accessed and / or managed through system 400. By way of example, database 430 may be an Oracle™ database, a Sybase™ database, or other relational database. However, systems and methods consistent with the present invention are not limited to a separate data structure or database, nor are they limited to the use of a database or data structure.

[0096] Those skilled in the art will recognize that the components and implementation details of the system in Figure 4 are examples presented for simplicity and clarity of explanation, and other components and implementation details may be used.

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

[0098] Throughout this specification, including the claims, the term "comprising" should be understood to be synonymous with "comprising at least one" unless otherwise specified. Furthermore, any range set forth in this specification, including the claims, should be understood to be inclusive of its end value(s) unless otherwise specified. Specific values ​​for recited elements should be understood to be within accepted manufacturing or industry tolerances known to those skilled in the art, and the use of the terms "substantially" and / or "approximately" and / or "generally" should be understood to mean within such accepted tolerances. As used herein, the terms "and" and "or" should be interpreted as "and / or."

[0099] Other embodiments of the invention will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed therein. It is intended that the specification and its description be considered as exemplary only.

Claims

1. A system for accessing in-vehicle operation data from a vehicle, A memory device containing instructions, A processor operably connected to the memory device, which executes the instructions, Steps include obtaining vehicle information to identify the vehicle, Steps include obtaining user information to identify a specific user, A step of obtaining verification information describing the vehicle and the specific user from the verification source, A step of verifying that the specific user is associated with the vehicle based on the verification information, The steps include: connecting to the vehicle in a communicative manner based on the vehicle information; The steps include requesting the in-vehicle operation data from the vehicle, The steps include receiving the in-vehicle operation data from the vehicle, The steps include providing the in-vehicle operation data to the specific user, A processor that performs operations including, A system that includes these features.

2. The step of obtaining vehicle information to identify the aforementioned vehicle is, The system according to claim 1, comprising receiving a vehicle identification number (VIN).

3. The step of obtaining user information that identifies the specific user is, The system according to claim 1, comprising receiving the name and date of birth of the specified user.

4. The step of obtaining verification information from the aforementioned verification source is, The system according to claim 1, comprising receiving vehicle qualification information from the automotive authorities.

5. The step of obtaining verification information from the aforementioned verification source is, The system according to claim 1, comprising receiving vehicle registration information from the automotive authorities.

6. The step of verifying that the aforementioned specific user is associated with the vehicle is, The system according to claim 1, comprising comparing user information that identifies a specific user with verification information that describes the specific user.

7. The aforementioned operation, The system according to claim 1, further comprising the step of storing the in-vehicle operation data received from the vehicle.

8. The step of providing in-vehicle operation data to the aforementioned specific user is The system according to claim 7, comprising providing the stored in-vehicle operation data.

9. The system according to claim 1, wherein the specified user is the registrant or repairer of the vehicle.

10. The step of establishing a communicationable connection to the vehicle based on the vehicle information is: The system according to claim 1, comprising communicating with the vehicle using a vehicle identification number (VIN).

11. A computer implementation method for accessing in-vehicle operation data within a vehicle, Steps include obtaining vehicle information to identify the vehicle, Steps include obtaining user information to identify a specific user, A step of obtaining verification information describing the vehicle and the specific user from the verification source, A step of verifying that the specific user is associated with the vehicle based on the verification information, The steps include: connecting to the vehicle in a communicative manner based on the vehicle information; The steps include requesting the in-vehicle operation data from the vehicle, The steps include receiving the in-vehicle operation data from the vehicle, The steps include providing the in-vehicle operation data to the specific user, Computer implementation methods including

12. A non-temporary computer-readable medium containing instructions, wherein the instructions are executed by a processor. Steps include obtaining vehicle information to identify the vehicle, Steps include obtaining user information to identify a specific user, A step of obtaining verification information describing the vehicle and the specific user from the verification source, A step of verifying that the specific user is associated with the vehicle based on the verification information, The steps include: connecting to the vehicle in a communicative manner based on the vehicle information; The steps include requesting the in-vehicle operation data from the vehicle, The steps include receiving the in-vehicle operation data from the vehicle, The steps include providing the in-vehicle operation data to the specific user, A non-temporary computer-readable medium that implements a method including the following.

Images