阅读说明：本技术 会话唯一访问令牌 (Session unique access token ) 是由 丹尼尔·亚伦·扎亚克 阿尔迪·乔希 于 2020-10-13 设计创作，主要内容包括：本公开提供了“会话唯一访问令牌”。一种系统包括第一计算机,所述第一计算机包括处理器,所述处理器被编程为从远程装置接收第一数字文档,所述第一数字文档包括来自服务器的数字签名并且指定用户对一个或多个车辆系统的访问。所述处理器还被编程为从所述服务器接收授权对所述一个或多个车辆系统的所述指定访问的第二数字文档；以及基于所述第一数字文档和所述第二数字文档向所述远程装置提供对所述一个或多个车辆系统的所述指定访问。(The present disclosure provides a "session unique access token". A system includes a first computer including a processor programmed to receive a first digital document from a remote device, the first digital document including a digital signature from a server and specifying a user's access to one or more vehicle systems. The processor is further programmed to receive a second digital document from the server authorizing the designated access to the one or more vehicle systems; and providing the designated access to the one or more vehicle systems to the remote device based on the first digital document and the second digital document.)

1. A method, comprising:

receiving, by a first computing device, a first digital document from a remote device, the first digital document including a digital signature from a server and specifying access of the remote device to one or more vehicle systems;

receiving, from the server, a second digital document authorizing the designated access to the one or more vehicle systems; and

providing the designated access to the one or more vehicle systems to the remote device based on the first digital document and the second digital document.

2. The method of claim 1, wherein the second digital document comprises one or more third digital documents authorizing the designated access to a vehicle system of the one or more vehicle systems.

3. The method of claim 2, further comprising:

installing each of the one or more third digital documents in a respective vehicle system to which the respective third digital document authorizes the designated access.

4. The method of claim 3, wherein the second digital document includes a script for installing at least one of the one or more third digital documents in the respective vehicle system, the method further comprising:

and executing the script.

5. The method of claim 1, wherein the designated access to the one or more vehicle systems is based on a user identifier.

6. The method of claim 1, wherein the second digital document is encrypted based on a server private key, the method further comprising:

decrypting the second digital document based on a server public key.

7. The method of claim 1, further comprising:

transmitting a request to the server before receiving the second digital document from the server, the request including an identifier of the one or more vehicle systems and data from the first digital document.

8. The method of claim 7, further comprising:

authenticating the second digital document based in part on the second digital document including data from the request to the server.

9. The method of claim 1, further comprising:

receiving, by a second computing device, a message from the remote device requesting access to the one or more vehicle systems;

generating, by the second computing device, the first digital document specifying the access of the remote device to the one or more vehicle systems and including the digital signature from the server; and

transmitting, by the second computing device, the first digital document to the remote device.

10. The method of claim 9, further comprising:

designating, by the second computing device, the access to the one or more vehicle systems based on at least one of a user identifier and a remote device identifier included in the message.

11. The method of claim 9, further comprising:

generating, by the second computing device, the first digital document based on determining that the user identifier in the message is included in a list of authorized user identifiers.

12. The method of claim 9, further comprising:

generating the first digital document based on determining that a remote device identifier in the message is included in a list of authorized remote devices.

13. A computer programmed to perform the method of any one of claims 1 to 12.

14. A vehicle comprising a computer programmed to perform the method of any one of claims 1 to 12.

15. A computer program product comprising a computer readable medium storing instructions executable by a computer processor to perform the method of any one of claims 1 to 12.

Technical Field

The present disclosure relates generally to vehicle safety systems.

Background

Safety protocols are commonly applied to various vehicle systems to provide access to diagnostic, development, and safety-related functions. The respective systems may require separate authentication procedures, for example, employing separate security tokens generated by separate servers.

Disclosure of Invention

A system includes a first computer including a first processor and a first memory including instructions such that the first processor is programmed to receive a first digital document from a remote device, the first digital document including a digital signature from a server and specifying a user's access to one or more vehicle systems. The processor is further programmed to receive a second digital document from the server authorizing designated access to the one or more vehicle systems; and providing the user's designated access to the one or more vehicle systems to the remote device based on the first digital document and the second digital document.

In other features, the second digital document includes one or more third digital documents authorizing specified access to a vehicle system of the one or more vehicle systems.

In other features, the first processor can be further programmed to install each of the one or more third digital documents in a respective vehicle system to which the respective third digital document authorizes the designated access.

In other features, the second digital document may include a script for installing at least one of the one or more third digital documents in a respective vehicle system; and the first processor may also be programmed to execute the script.

In other features, the designated access to the one or more vehicle systems may be based on a user identifier.

In other features, the second digital document may be encrypted based on a server private key; and the first processor may be further programmed to decrypt the second digital document based on the server public key.

In other features, the first processor may be further programmed to transmit a request to the server including an identifier of one or more vehicle systems and data from the first digital document prior to receiving the second digital document from the server.

In other features, the first processor may be further programmed to authenticate the second digital document based in part on the second digital document including data from the request to the server.

In other features, the server may include a second processor and a second memory including instructions such that the second processor may be programmed to receive a message from a remote device requesting access to one or more vehicle systems. The second processor may be further programmed to generate a first digital document specifying access of the remote device to one or more vehicle systems and including the digital signature from the server; and transmitting the first digital document to a remote device.

In other features, the second processor can be further programmed to designate access to one or more vehicle systems based on at least one of the user identifier and the remote device identifier included in the message.

In other features, the second processor may be further programmed to generate the first digital document based on determining that the user identifier in the message is included in the list of authorized user identifiers.

In other features, the second processor can be further programmed to generate the first digital document based on determining that the remote device identifier in the message is included in the list of authorized remote devices.

In other features, the second processor can be further programmed to confirm that the message includes the first digital document upon receiving the message from the first processor; and generating a second digital document based on the confirmation.

In other features, the second processor may be further programmed to generate a challenge response for a challenge number in the message from one of the one or more vehicle systems; and including the challenge response in a second digital document.

A method is also disclosed that includes receiving a first digital document from a remote device, the first digital document including a digital signature from a server and specifying access by the remote device to one or more vehicle systems. The method further includes receiving, from the server, a second digital document authorizing designated access to the one or more vehicle systems; and providing the designated access to the one or more vehicle systems to the remote device based on the first digital document and the second digital document.

In other features, the second digital document may include one or more third digital documents authorizing specified access to a vehicle system of the one or more vehicle systems.

In other features, the method may include installing each of the one or more third digital documents in a respective vehicle system to which the respective third digital document authorizes designated access.

In other features, the second digital document may include a script for installing at least one of the one or more third digital documents in a respective vehicle system, and the method may further include executing the script.

In other features, the designated access to the one or more vehicle systems may be based on a user identifier.

In other features, the second digital document may be encrypted based on a server private key; and the method may further include decrypting the second digital document based on the server public key.

Also disclosed herein is a computing device programmed to perform any of the above method steps.

Also disclosed herein is a computer program product comprising a computer readable medium storing instructions executable by a computer processor to perform any of the above-described method steps.

Drawings

FIG. 1 is a block diagram illustrating an example system for providing conversational access to a plurality of vehicle systems.

Fig. 2A and 2B are flow diagrams of an example process for providing conversational access to a plurality of vehicle systems.

Detailed Description

FIG. 1 is a block diagram of an example system 100 for providing conversational access of a remote device 140 to a plurality of vehicle systems 106 in a vehicle 105. The system 100 includes a vehicle 105, one or more remote devices 140, and a server 150 communicatively coupled by a network 135. For ease of illustration, the system 100 is described below as including one vehicle 105. However, the system 100 and the session access granted by the system 100 may include one or more vehicles 105.

The user may send a message requesting a session access token from the server 150 via the remote device 140. The session access token is a digital document that specifies access of the remote device 140 to one or more vehicle systems 106 and includes a digital signature from the server 150. The access of the remote device 140 may be based on a user identifier included in the digital document. The message identifies the vehicle system 106 in the vehicle 105 requesting access during the session. As used herein, the term "vehicle system 106" refers to vehicle electronic/electromechanical systems, subsystems, components 118, actuators 116, sensors 112, interfaces, modules, etc., that perform functions in the vehicle 105 and include a processor programmed to transmit and/or receive messages via the vehicle communication network 122. As used herein, the term "token" is a digital document that includes authorization to participate in one or more specified activities. As used herein, the term "access to the vehicle system 106" refers to authorized communication with the vehicle system 106. Access to the vehicle system 106 may be complete or limited. Full access means that the user is authorized to receive all data transmitted by the vehicle system 106 via the remote device 140 and can send messages, such as commands, that control all features of the vehicle system 106. The limited access limits the user to control some features of the vehicle system 106 without controlling other features of the vehicle system 106, or to control only certain features within specified limits.

The server 150 may receive the request and generate a session access token. The session access token specifies the vehicle systems 106 that the remote device 140 has access to, as well as the level of access for each vehicle system 106. The session access token may also specify the remote devices 140 through which the user may access each of the vehicle systems 106. The server 150 may send the session access token to the remote device 140.

Typically upon receiving user input requesting a session, the remote device 140 may send a session access token to the gateway component 118_ GW on the vehicle 105. For ease of discussion, the request for session access for the vehicle 105 will be described herein as being received, processed, and distributed by the gateway 118_ GW in the vehicle 105. One or more other vehicle systems 106, such as another component 118, may alternatively or additionally be programmed to perform these functions.

As described below, the gateway 118_ GW may negotiate with the server 150 and the vehicle system 106 to establish authorized access to the vehicle system 106 for a session. A "session" in this context means a period of time during which a user may access the vehicle system 106 via the remote device 140. The time period may be specified as a fixed amount of time (e.g., four hours), as a start time and an end time, or, for example, until an event occurs, such as a user terminating the session or the server 150 terminating the session.

Each vehicle 105 includes a vehicle computer 110, sensors 112, Human Machine Interface (HMI)114, actuators 116, vehicle components 118, and a vehicle communication module 120 communicatively coupled by a vehicle communication network 122. The vehicle component 118 includes a gateway component 118_ GW.

The vehicle computer 110 includes, for example, a known processor and memory. The memory includes one or more forms of computer-readable media and stores instructions executable by the vehicle computer 110 for performing various operations, including as disclosed herein.

The vehicle computer 110 may operate the vehicle 105 in an autonomous mode, a semi-autonomous mode, or a non-autonomous (or manual) mode. For purposes of this disclosure, an autonomous mode is defined as a mode in which each of the vehicle 105 propulsion, braking, and steering are controlled by the vehicle computer 110; in semi-autonomous mode, the vehicle computer 110 controls one or both of propulsion, braking, and steering of the vehicle 105; in the non-autonomous mode, the human operator controls each of propulsion, braking, and steering of the vehicle 105.

The vehicle computer 110 may include programming for operating one or more of vehicle braking, propulsion (e.g., controlling acceleration of the vehicle 105 by controlling one or more of an internal combustion engine, an electric motor, a hybrid engine, etc.), steering, a transmission, climate control, interior and/or exterior lights, etc., and for determining whether and when the vehicle computer 110 (rather than a human operator) is controlling such operations. Additionally, the vehicle computer 110 may be programmed to determine if and when a human operator controls such operations.

The vehicle computer 110 may include or be communicatively coupled, such as via a vehicle communication network 122, to more than one processor, such as included in an Electronic Controller Unit (ECU) or the like included in the vehicle 105, such as a transmission controller, a brake controller, a steering controller, or the like, for monitoring and/or controlling various vehicle components 118. The vehicle computer 110 is typically arranged for communication over a vehicle communication network 122, which may include one or more buses (e.g., Controller Area Network (CAN), etc.) and/or other wired and/or wireless mechanisms in the vehicle 105.

Via the vehicle communication network 122, the vehicle computer 110 may transmit messages to and/or receive messages (e.g., CAN messages) from various devices in the vehicle 105 (e.g., sensors 112, Human Machine Interface (HMI)114, actuators 116, vehicle components 118, etc.). Alternatively or additionally, where the vehicle computer 110 actually includes multiple devices, the vehicle communication network 122 may be used for communication between the devices, represented in this disclosure as the vehicle computer 110. Further, as mentioned below, various controllers and/or sensors 112 may provide data to the vehicle computer 110 via a vehicle communication network 122.

Additionally, the vehicle computer 110 may be configured to communicate with devices external to the vehicle 105 via the vehicle communication module 120, e.g., with another vehicle 105 through vehicle-to-vehicle (V2V) or vehicle-to-infrastructure (V2X) wireless communication, or with computing devices such as the remote device 140 and the server 150 via the network 135.

The sensors 112 may include, for example, various devices known for providing data to the vehicle computer 110. For example, the sensors 112 may include one or more light detection and ranging (LIDAR) sensors 112 disposed on the top of the vehicle 105, behind a front windshield of the vehicle 105, around the vehicle 105, or the like, that provide relative position, size, and shape of objects around the vehicle 105. As another example, one or more radar sensors 112 fixed to a bumper of the vehicle 105 may provide data to provide a location of an object, the second vehicle 105, or the like relative to a location of the vehicle 105. The sensors 112 may also alternatively or additionally include one or more camera sensors 112 and/or other image sensors 112 (e.g., front view, side view, etc.) to provide images from the area surrounding the vehicle 105.

The sensors 112 may also include a temperature sensor 112, a pressure sensor 112, a rotation sensor 112, an angle sensor 112, a position sensor 112, a torque sensor 112, and the like to detect vehicle operating conditions such as cabin temperature, vehicle engine temperature, vehicle speed, vehicle acceleration, vehicle steering angle, engine speed, brake pressure, and the like. The sensors 112 may be stand-alone units, include a processor, and are programmed for communication over the vehicle communication network 122. Alternatively, the sensors 112 may be included in the respective vehicle systems 106 and communicatively coupled to a processor included in those vehicle systems 106.

The vehicle 105 also includes a Human Machine Interface (HMI) 114. The human-machine interface (HMI)114 includes input devices, such as knobs, buttons, switches, pedals, joysticks, touch screens, microphones, and the like, that can receive input from a user. For example, the HMI 114 may include a brake pedal, an accelerator pedal, and a steering wheel for receiving input from a user to control the vehicle 105. The input devices may include sensors 112 to detect user inputs and provide user input data to the vehicle computer 110. For example, the steering wheel may include a sensor 112 to detect the angle of rotation of the steering wheel and provide data to the vehicle computer 110.

The HMI 114 also includes output devices, such as displays (including touch screen displays), speakers, lights, etc., that output signals or data to a user. The HMI 114 is coupled to the vehicle communication network 122 and can send and/or receive messages to/from the vehicle computer 110 and other vehicle systems 106.

The actuator 116 is implemented via circuitry, chips, or other electronic and/or mechanical components that can actuate various vehicle subsystems in accordance with appropriate control signals as is known. The actuators 116 may be used to control vehicle components 118, including braking, acceleration, and steering of the vehicle 105.

In the context of the present disclosure, the vehicle components 118 are one or more hardware assemblies including an Electronic Control Unit (ECU) including one or more processors and memory including instructions for programming the processors, adapted to perform mechanical or electromechanical functions or operations, such as moving the vehicle 105, decelerating or stopping the vehicle 105, steering the vehicle 105, and the like. Non-limiting examples of vehicle components 118 include a propulsion component 118 (which includes, for example, an internal combustion engine and/or an electric motor, etc.), a transmission component 118, a steering component 118 (which may include, for example, one or more of a steering wheel, a steering rack, etc.), a braking component 118, a parking assist component 118, an adaptive cruise control component 118, an adaptive steering component 118, a movable seat 118, a gateway 118_ GW, etc.

The vehicle component 118 includes a gateway 118_ GW. As used herein, the gateway 118_ GW is an electronic control module that routes communication traffic within the vehicle 105. The gateway 118_ GW is programmed to communicate with the remote device 140 and the server 150 via the vehicle communication module 120. The gateway 118_ GW is also programmed to communicate with the vehicle systems 106, such as the vehicle computer 110, sensors 112, HMI 114, actuators 116, vehicle components 118, and the like, via the vehicle network 122.

The gateway 118_ GW may receive the session access token, e.g., from the remote device 140, and transmit the session access token to the server 150. The gateway 118_ GW may also receive access tokens for one or more vehicle systems 106 from the server 150 and instructions for installing the access tokens in the respective vehicle systems 106. Based on the instructions, the gateway 118_ GW may also install an access token in the respective vehicle system 106 such that the user may access the respective vehicle system 106 via the remote device 140.

The gateway 118_ GW may further manage the expiration/revocation of session access. For example, the gateway 118_ GW may determine that the user's request has expired and execute a script to close the connection. The gateway 118_ GW may also check to see if communication between the requester and the vehicle system 106 is ongoing before closing the connection. In the case where communication is ongoing, the gateway 118_ GW may, for example, send a notification to the requester that access has expired.

The vehicle communication module 120 includes one or more mechanisms by which the vehicle systems 106, e.g., the vehicle computer 110, the vehicle gateway 118_ GW, etc., can communicate with computing devices external to the vehicle 105, e.g., remote devices 140, servers 150, other vehicles 105, traffic infrastructure devices, etc. The vehicle communication module 120 includes any desired combination of wireless (e.g., cellular, wireless, satellite, microwave, and radio frequency) communication mechanisms, as well as any desired network topology (or topologies when multiple communication mechanisms are utilized). Exemplary communications provided via the vehicle communication module 120 include cellular, bluetooth, IEEE802.11, Dedicated Short Range Communication (DSRC), and/or Wide Area Networks (WANs) including the internet, which provide data communication services.

As used herein, the vehicle communication network 122 is defined as one or more mechanisms for wired or wireless communication between the vehicle systems 106 of the vehicle 105. The vehicle communication network 122 may include, for example, one or more vehicle communication buses and one or more wireless communication networks. Non-limiting examples of vehicle communication buses include a Controller Area Network (CAN) bus, a Local Interconnect Network (LIN) bus, and an ethernet network. Non-limiting examples of wireless communication networks include bluetooth, Bluetooth Low Energy (BLE), and Wi-Fi direct.

The network 135 represents one or more mechanisms by which the vehicle computer 110, gateway 118_ GW, and other vehicle systems 106 may communicate with remote devices, such as remote device 140, and server 150. Thus, the network 135 may be one or more of a variety of wired or wireless communication mechanisms, including any desired combination of wired (e.g., cable and fiber) and/or wireless (e.g., cellular, wireless, satellite, microwave, and radio frequency) communication mechanisms, as well as any desired network topology (or topologies when multiple communication mechanisms are utilized). Exemplary communication networks include wireless communication networks providing data communication services (e.g., usingLow power consumption(BLE), IEEE802.11, vehicle-to-vehicle (V2V), such as Dedicated Short Range Communication (DSRC) or the like, Local Area Network (LAN), and/or Wide Area Network (WAN) including the Internet.

The remote device 140 is a computing device that includes, for example, a known processor and memory. The remote device 140 is programmed to communicate with the vehicle system 106 via the vehicle communication network 122 and may include a human machine interface to support user development, testing, or diagnostics of the vehicle system 106. Remote device 140 may include programming, digital keys, etc. to establish or confirm trust with server 150. In this context, trustworthiness means that the remote device 140 can establish a trust level such that the server 150 is authorized to provide the session access token to the remote device 140. For example, the remote device 140 may include a digital key that matches or pairs with a digital key on the server 150 so that the remote device 140 and the server 150 can exchange encrypted communications. As another example, the remote device 140 may have an identifier listed on the server 150 as an authorized device.

Based on receiving the session access token, the remote device 140 is further programmed to request access to the vehicle system 106, such as one of the components 118. The remote device 140 may transmit the request to the gateway 118_ GW, which manages access to the vehicle systems 106 as described herein.

In an example, a user may download an application from server 150 to remote device 140. The application may cooperate with the gateway 118_ GW to establish access to the vehicle systems 106 identified in the session access token during the time period specified by the session access token.

The server 150 may be a conventional computing device programmed to provide operations such as those disclosed herein, i.e., including one or more processors and one or more memories. Further, the server 150 may be accessed via a network 135, such as the internet or some other wide area network.

The server 150 is programmed to receive a request from the remote device 140 to access one or more vehicle systems 106 in the vehicle 105, determine an access level of the remote device 140, and provide a session access token to the remote device 140 to specify the access level of the remote device 140 to the one or more vehicle systems 106. The specified access may be to a specified user (a user with a specified identifier), to a specified remote device 140, or to a specified user via a specified remote device 140. The server 150 may also be programmed to sign the session access token with a digital signature specific to the server 150. In some cases, the user may receive the session access token via the first remote device 140 and use the session access token via the second remote device 140. In this case, for example, the user may transfer the session access token from the first remote device 140 to the second remote device 140 before utilizing the session token.

The server 150 is also programmed to receive a request to authenticate the session access token from the gateway 118_ GW of the vehicle 105 and provide the gateway 118_ GW with the necessary tokens, scripts, and programs to provide access to the vehicle systems 106 by the remote device 140. A script in this context is a set of instructions that can be executed by a processor, typically after being interpreted by an interpreter as is known.

The server 150 may include (i.e., maintain in non-volatile memory) public keys for a plurality of vehicles 105 (or, for example, a gateway 118_ GW for a respective vehicle) to provide secure communications with the vehicles 105. The server 150 may also maintain in memory a private key of the server 150 that the server 150 may use to digitally sign session access tokens and other digital documents.

The server 150 may also include in memory security data related to one or more vehicle systems 106. The term "secure data" in this context means data, algorithms, scripts, etc. that the server 150 may use to determine and provide access to the vehicle systems 106. For example, the security data may include a security token or programming to generate a security token for the vehicle system 106. The security data may also include criteria for granting access to the vehicle systems 106. For example, the security data may include a list of authorized users and/or authorized remote devices 140 for each vehicle system. As another example, the security data may include a mechanism for receiving and responding to a challenge number from the vehicle system 106 requesting access.

Fig. 2A and 2B are flow diagrams of an example process 200 for providing remote device 140 with conversational access to a plurality of vehicle systems 106. The process 200 begins in block 202.

In block 202, the remote device 140 sends a message to the server 150 requesting conversational access to one or more vehicle systems 106 in the vehicle 105. The message may include:

1) the time range of the requested session,

2) the identifier of the vehicle 105 that the user requested access to,

3) the identifier of the one or more vehicle systems 106 for which access is requested,

4) the level of access requested for each vehicle system 106 individually,

5) an identifier of the user requesting access, an

6) An identifier of the remote device 140 requesting access.

As used herein, a time range is a description of a period of time, such as a date, a time of day to begin and end, a number of ignition cycles, a number of uses of a session access token, a number of transactions, and the like. An "identifier" is a substantially unique set of data, typically a string of alphanumeric data, corresponding to a particular user, remote device 140, vehicle 105, vehicle system 106, and the like. For example, the identifier of the vehicle 105 may be a Vehicle Identification Number (VIN). The user identifier may be, for example, an alphanumeric data string corresponding to a particular user or group of users. The identifier of the vehicle system 106 may be, for example, a serial number of a module in the vehicle system 106, an identifier of a processor communicating with the vehicle system 106, and so on. The process continues in block 204.

In block 204, the server 150 determines whether the user is authorized. For example, the server 150 may maintain a list of user identifiers of authorized users. Server 150 may determine whether the user identifier provided in the request is included in the list of authorized users. As another example, the server 150 may request and receive authorization for the user from a third party. In an example, a third party may purchase points that may be used by the server 150 to provide session access to the user.

In the event that server 150 determines that the user is authorized, process 200 continues in block 206. Otherwise, the user is not authorized, and process 200 ends. Before ending process 200, server 150 may send a message to remote device 140 indicating that the requested access has been denied, for example.

In block 206, where the user is authorized, and based on the user's identity, the server 150 generates a session access token. The session access token includes one or more of:

1) the time period of the session,

2) the identifier of the vehicle 105 to which access is granted,

3) the identifier of the one or more vehicle systems 106 to which access is granted,

4) an identifier of a user to which access rights are granted;

5) identifiers of one or more remote devices 140 to which access is granted;

6) a level of user access to each of the one or more vehicle systems 106, respectively, an

7) A digital signature from the server 150.

For example, as described above, the server 150 may maintain a user table including approved accesses by the user. The table may include user identifiers and may identify the systems and levels of access that server 150 may authorize for each user. Table 1 is an exemplary partial user approval access table.

In some cases, the server 150 may also specify remote devices 140 that the user may use to access the vehicle system 106. For example, the server 150 may maintain a list of authorized remote device identifiers.

For example, unless the user's approved access is restricted based on the user approved access table, the server 150 may generate a session access token to include all accesses requested by the user. In this case, the server 150 may generate the session access token to include the user access until the user approves the restrictions specified in the access table.

The session access token may include a digital signature from the server 150. A digital signature is a set of data that can be interpreted by one or more algorithms for verifying the authenticity of a document. The digital signature may be based on asymmetric cryptography that enables the creator of the message (in this case, the server 150) to attach code that acts as a signature and private key, where the code is based on the message to which the signature is attached. The message may be authenticated based on a public key associated with a private key. The Digital Signature Algorithm (DSA) developed by the national institute of standards and technology is an example of a digital signature mechanism. In this case, the server 150 may digitally sign the session access token with the server private key. Other computing devices, such as the remote device 140 or the gateway 118_ GW, may utilize the server public key to validate the digital signature.

Next, in block 208, the server 150 sends the session access token to the remote device 140. The process 200 continues in block 210.

In block 210 (which may be omitted in some implementations), the remote device 140 may transmit the session access token to one or more other remote devices 140 to which the session access token is applicable. For example, the other remote devices 140 may include one or more items of test equipment that the user may use during the access session and may need to access the vehicle systems 106 in the vehicle 105. The remote device 140 may transmit the session access token to each of the other remote devices 140 via the network 135. The process 200 continues in block 212.

In block 212, the remote device 140 submits the session access token to the gateway 118_ GW in the vehicle 105. For example, the remote device 140 may be connected to a CAN bus included in the vehicle communication network 122 and transmit the session access token to the gateway 118_ GW via the CAN bus. The process 200 continues in block 214.

In block 214, the gateway 118_ GW generates a request packet for the server 150. The request packet is a digital document generated by the gateway 118_ GW based on the session access token received from the remote device 140 and may include:

1) the identifier of each of the vehicle systems 106 for which access is requested,

2) challenge numbers from one or more vehicle systems 106 respectively,

3) metadata of the vehicle system 106 for which access is requested, an

4) A session access token.

The gateway 118_ GW used to generate the request packet may request the corresponding challenge number from one or more of the vehicle systems 106 for which access is requested. The respective challenge numbers may be generated, for example, by [ [ a ] ] pseudo-random number generators included in the one or more vehicle systems 106. The gateway 118_ GW may include the corresponding challenge numbers for one or more vehicle systems 106 in the request packet.

The metadata may include a serial number, firmware or software version, manufacturer, part number, trim level, feature content, etc. of the respective vehicle system 106.

After assembling the request packet, the gateway 118_ GW may further encrypt the request packet, for example, by using the gateway 118_ GW private key. The process 200 continues in block 216.

In block 216, the gateway 118_ GW transmits the request packet to the server 150 via the network 135. The process 200 continues in block 218.

In block 218, where the gateway 118_ GW encrypts the request packet, the server 150 decrypts the request packet. For example, in the case where the gateway 118_ GW encrypts the request packet using the gateway 118_ GW private key, the server 150 decrypts the request packet using the gateway 118_ GW public key. The process 200 continues in block 220.

In block 220, the server 150 determines whether the request packet is authorized. In the case where the request packet is encrypted, the server 150 confirms that the decryption by the gateway 118_ GW public key is successful, thereby confirming that the encryption is performed using the gateway 118_ GW private key.

The server 150 may also generate a challenge response to the challenge number from the vehicle system 106 included in the request packet. The challenge response may be a number (or string of alphanumeric characters) generated by a response generator algorithm associated with the respective vehicle system 106. For example, upon receiving the challenge number included in the request packet, the server 150 may submit the challenge number to a response generator algorithm associated with the vehicle system 106 that generated the challenge number. In some cases, the server 150 may include, i.e., store in memory, response generator algorithms for one or more vehicle systems 106, respectively. In other cases, one or more of the response generator algorithms may be maintained on another server with which server 150 may communicate via network 135.

The server 150 may also confirm the authenticity of the user by comparing the session access token with a session access token previously signed and provided to the user. The server 150 may also reconfirm that the user is authorized by, for example, confirming receipt of the request packet within the time frame of the session. Server 150 may also reconfirm that the user's identifier is included in the list of approved users. In the event that the server 150 confirms that the request packet is authorized, the process 200 continues in block 222. Otherwise, the server 150 rejects the request packet and the process 200 ends. The server 150 may, for example, send a message to the gateway 118_ GW informing the gateway 118_ GW that the request packet is rejected.

In block 222, the server 150 generates a response package. The response packet is a digital document generated by the server 150 based on the request packet received from the gateway 118_ GW. The response packet may also be based on a request for a session access token previously received from the remote device 140. The response packet includes:

1) a request packet is sent to the mobile station,

2) a session unique token for the vehicle system 106,

3) a challenge response, and

4) the vehicle system 106 submits a script that is specific.

The session unique token for the vehicle system 106 is a digital representation of the rights to interact with the specified vehicle system 106 during the specified session. The submission script specific to the vehicle system 106 is a set of instructions (digital code) that may be executed, for example, by the gateway 118_ GW to provide the remote device 140 access to the specified vehicle system 106.

After generating the response packet, the server 150 may then encrypt the response packet using the server 150 private key. The process 200 continues in block 224.

In block 224, the server 150 transmits the response packet to the gateway 118_ GW. The process continues in block 226.

In block 226, the gateway 118_ GW decrypts the response packet, if necessary. For example, in the case where the server 150 encrypts the response packet using the server 150 private key, the gateway 118_ GW may decrypt the response packet using the server 150 public key.

Next, in block 228, the gateway 118_ GW authenticates the response packet. Initially, the gateway 118_ GW determines whether the gateway 118_ GW is capable of decrypting the response packet, i.e., whether it received the expected result from decrypting the response packet. In addition, the gateway 118_ GW determines whether the request packet included in the response packet matches the request packet previously provided to the server 150. In the event that the gateway 118_ GW authenticates the response packet, i.e., the request packet capable of decrypting and/or returning the response packet matches the previously sent request packet, the process 200 continues in block 230. Otherwise, process 200 ends. Before ending the process 200, the gateway 118_ GW may notify the user and/or the server 150 (via the remote device 140) that the access request was denied.

In block 230, the gateway 118_ GW unlocks the vehicle system 106 specified in the request packet to the specified level of access made by the user via the remote device 140. The gateway 118_ GW executes a submit script to install a session unique token for each respective vehicle system 106 to enable access by the remote device 140. The gateway 118_ GW may also submit the challenge response to the respective vehicle system 106 for verification by the respective vehicle system 106. The process 200 continues in block 232.

In block 232, the gateway 118_ GW monitors the vehicle communication network 122. For example, the gateway 118_ GW may monitor messages on a CAN bus in the vehicle communication network 122 on which the remote device 140 communicates, i.e., transmits messages. The process 200 continues in block 234.

In block 234, the gateway 118_ GW determines whether a session-ending event has occurred. A session end event is a message, an electrical signal, a change in system voltage level, etc. indicating that a session has ended or is about to end. For example, the session end event may be a message from the remote device 140 that the user is logging off. As another example, a message on the vehicle communication network 122 may indicate that the time of day is 19:00, and the session is scheduled to end at 19:00 by the session access token. As another example, a change in the voltage level of the electrical signal or the power supply voltage may indicate that the vehicle 105 has been powered off, or that the power supply has been removed from the vehicle 105. The examples listed above are not limiting. Other messages, signals, changes in voltage levels, etc. may also indicate that the session has ended. In the event that the gateway 118_ GW determines that a session-ending event has occurred, the process 200 ends. Otherwise, process 200 continues in block 232.

In the above description of example process 200, the request for session access to vehicle 105 is described as being received, processed, and distributed by gateway 118_ GW in vehicle 105. This is merely an example and is not intended to be limiting. Operations attributed to the gateway 118_ GW may be performed in whole or in part by one or more other vehicle systems 106, such as another component 118.

As used herein, the adverb "substantially" means that shapes, structures, measurements, quantities, times, etc. may deviate from the precisely described geometries, distances, measurements, quantities, times, etc. due to imperfections in materials, machining, manufacturing, data transmission, computational speed, etc.

As used herein, the term "based on" means based in whole or in part on.

In general, the described computing systems and/or devices may employ any of a number of computer operating systems, including, but in no way limited to, the following versions and/or variations: fordApplication, AppLink/Smart Device Link middleware, Microsoft WindowsOperating System, Microsoft WindowsOperating System, Unix operating System (e.g., distributed by Oracle corporation of the coast of sequoia, Calif.)Operating system), the AIX UNIX operating system distributed by International Business Machines corporation of Armonk, N.Y., the Linux operating system, the Mac OSX and iOS operating Systems distributed by apple Inc. of Cuttino, Calif., the BlackBerry OS distributed by BlackBerry, Inc. of Toyowa, Canada, and the Android operating system developed by Google and the open cell phone alliance, or the QNX Software SystemsCAR infotainment platform. Examples of a computing device include, but are not limited to, an in-vehicle computer, a computer workstation, a server, a desktop computer, a notebook computer, a laptop computer, or a handheld computer, or some other computing system and/or device.

Computers and computing devices generally include computer-executable instructions, where the instructions are executable by, for example, one or more computing devices such as those listed above. Computer-executable instructions may be compiled or interpreted by a computer program created using a variety of programming languages and/or techniques, including but not limited to Java, alone or in combination^TMC, C + +, Matlab, Simulink, Stateflow, Visual Basic, Java Script, Perl, HTML, and the like. Some of these applications may be compiled and executed on a virtual machine, such as a Java virtual machine, a Dalvik virtual machine, or the like. In general, a processor (e.g., a microprocessor) receives instructions, e.g., from a memory, a computer-readable medium, etc., and executes those instructions, thereby performing one or more processes, including one or more of the processes described herein. Various calculations may be usedA machine-readable medium stores and transmits such instructions and other data. A file in a computing device is typically a collection of data stored on a computer readable medium, such as a storage medium, random access memory, or the like.

The memory may include a computer-readable medium (also referred to as a processor-readable medium) including any non-transitory (e.g., tangible) medium that participates in providing data (e.g., instructions) that may be read by a computer (e.g., by a processor of a computer). Such a medium may take many forms, including but not limited to, non-volatile media and volatile media. Non-volatile media may include, for example, optical or magnetic disks and other persistent memory. Volatile media may include, for example, Dynamic Random Access Memory (DRAM), which typically constitutes a main memory. Such instructions may be transmitted by one or more transmission media, including coaxial cables, copper wire and fiber optics, including the wires that comprise a system bus coupled to the processor of the ECU. Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, any other magnetic medium, a CD-ROM, DVD, any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, a RAM, a PROM, an EPROM, a FLASH-EEPROM, any other memory chip or cartridge, or any other medium from which a computer can read.

A database, data store, or other data store described herein may include various mechanisms for storing, accessing, and retrieving various data, including a hierarchical database, a set of files in a file system, an application database in a proprietary format, a relational database management system (RDBMS), and so forth. Each such data store is typically included within a computing device employing a computer operating system (such as one of the operating systems mentioned above) and is accessed via a network in any one or more of a variety of ways. The file system is accessible from the computer operating system and may include files stored in various formats. RDBMS also typically employ the Structured Query Language (SQL) in addition to the language used to create, store, edit, and execute stored programs, such as the PL/SQL language described above.

In some examples, system elements may be implemented as computer-readable instructions (e.g., software) on one or more computing devices (e.g., servers, personal computers, etc.), stored on computer-readable media (e.g., disks, memory, etc.) associated therewith. The computer program product may comprise such instructions stored on a computer-readable medium for performing the functions described herein.

With respect to the media, processes, systems, methods, heuristics, etc. described herein, it should be understood that, although the steps of such processes, etc. have been described as occurring according to a certain ordered sequence, such processes could be practiced with the described steps performed in an order other than the order described herein. It should also be understood that certain steps may be performed simultaneously, that other steps may be added, or that certain steps described herein may be omitted. In other words, the description of processes herein is provided for the purpose of illustrating certain embodiments and should in no way be construed as limiting the claims.

Accordingly, it is to be understood that the above description is intended to be illustrative, and not restrictive. Many embodiments and applications other than the examples provided would be apparent to those of skill in the art upon reading the above description. The scope of the invention should be determined, not with reference to the above description, but should instead be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled. It is anticipated and intended that the technology discussed herein will be developed in the future and that the disclosed systems and methods will be incorporated into such future embodiments. In sum, it should be understood that the invention is capable of modification and variation and is limited only by the following claims.

Unless explicitly indicated to the contrary herein, all terms used in the claims are intended to be given their ordinary and customary meaning as understood by those skilled in the art. In particular, the use of singular articles such as "a," "the," "said," etc. should be read to recite one or more of the indicated elements unless a claim recites an explicit limitation to the contrary.

According to the invention, there is provided a system having a first computer comprising a first processor and a first memory, the first memory comprising instructions such that the first processor is programmed to: receiving a first digital document from a remote device, the first digital document including a digital signature from a server and specifying a user's access to one or more vehicle systems; receiving, from the server, a second digital document authorizing designated access to the one or more vehicle systems; and providing the user's designated access to the one or more vehicle systems to the remote device based on the first digital document and the second digital document.

According to an embodiment, the second digital document includes one or more third digital documents authorizing specified access to a vehicle system of the one or more vehicle systems.

According to an embodiment, the first processor is further programmed to install each of the one or more third digital documents in a respective vehicle system to which the respective third digital document authorizes the designated access.

According to an embodiment, the second digital document comprises a script for installing at least one of the one or more third digital documents in a respective vehicle system; and the first processor is further programmed to execute the script.

According to an embodiment, the designated access to the one or more vehicle systems is based on a user identifier.

According to an embodiment, the second digital document is encrypted based on a server private key; and the first processor is further programmed to: the second digital document is decrypted based on the server public key.

According to an embodiment, the first processor is further programmed to: transmitting a request to the server before receiving the second digital document from the server, the request including identifiers of the one or more vehicle systems and data from the first digital document.

According to an embodiment, the first processor is further programmed to: the second digital document is authenticated based in part on the second digital document including data from the request to the server.

According to an embodiment, the invention is further characterized in that the server comprises a second processor and a second memory, the second memory comprising instructions such that the second processor is programmed to: receiving a message from a remote device requesting access to one or more vehicle systems; generating a first digital document specifying access of a remote device to one or more vehicle systems and including a digital signature from a server; and transmitting the first digital document to a remote device.

According to an embodiment, the second processor is further programmed to: access to one or more vehicle systems is specified based on at least one of the user identifier and the remote device identifier included in the message.

According to an embodiment, the second processor is further programmed to: a first digital document is generated based on determining that the user identifier in the message is included in the list of authorized user identifiers.

According to an embodiment, the second processor is further programmed to: a first digital document is generated based on determining that the remote device identifier in the message is included in a list of authorized remote devices.

According to an embodiment, the second processor is further programmed to: confirming that the message includes the first digital document upon receipt of the message from the first processor; and generating a second digital document based on the confirmation.

According to an embodiment, the second processor is further programmed to: generating a challenge response for a challenge number in the message from one of the one or more vehicle systems; and including the challenge response in the second digital document.

According to the invention, a method comprises: receiving a first digital document from a remote device, the first digital document including a digital signature from a server and specifying access of the remote device to one or more vehicle systems; receiving, from the server, a second digital document authorizing designated access to the one or more vehicle systems; and providing the designated access to the one or more vehicle systems to the remote device based on the first digital document and the second digital document.

In one aspect of the invention, the second digital document includes one or more third digital documents authorizing specified access to a vehicle system of the one or more vehicle systems.

In one aspect of the invention, the method includes installing each of the one or more third digital documents in a respective vehicle system to which the respective third digital document authorizes designated access.

In one aspect of the invention, the method comprises: the second digital document includes a script for installing at least one of the one or more third digital documents in a respective vehicle system, the method further including executing the script.

In one aspect of the invention, the designated access to the one or more vehicle systems is based on a user identifier.

According to an embodiment, the second digital document is encrypted based on a server private key, the method further comprising: the second digital document is decrypted based on the server public key.