Patent Description:
In some cases, the manufacturer of the vehicle may suggest services to be performed on the vehicle. The suggested services can be part of a recall campaign, a regularly scheduled maintenance, or any other type of service that the manufacturer deems should be performed on the vehicle.

When the vehicle's operator takes the vehicle to the repair facility, the vehicle's operator and the repair facility will discuss the services to be performed on the vehicle, and after the vehicle operator has given a verbal approval or approval by signing a physical document, the repair facility proceeds to perform the services on the vehicle.

Accordingly there is provided a method, a computer program, and a system as detailed in the claims that follow.

Examples of vehicles include motor vehicles (e.g., automobiles, cars, trucks, buses, motorcycles, etc.), aircraft (e.g., airplanes, unmanned aerial vehicles, unmanned aircraft systems, drones, helicopters, etc.), spacecraft (e.g., space planes, space shuttles, space capsules, space stations, satellites, etc.), watercraft (e.g., ships, boats, hovercraft, submarines, etc.), railed vehicles (e.g., trains and trams, etc.), bicycles and other types of vehicles including any combinations of any of the foregoing, whether currently existing or after arising.

After a vehicle's operator has given authorization (either verbally or in written form) to a repair facility to perform an automotive service on a vehicle, the operator has no way to determine or verify that the automotive service performed by the repair facility was an automotive service authorized or was an automotive service that is approved by a manufacturer of the vehicle. An "operator" of a vehicle can refer to an owner of the vehicle or a driver of the vehicle or any other person that is to make a decision regarding an automotive service to be performed on the vehicle.

A "repair facility" can refer to any facility that can perform an automotive service on a vehicle, where the automotive service can include a repair or replacement of a malfunctioning part of the vehicle, or a maintenance of the vehicle to keep the vehicle in good working condition. A repair facility can be a facility at a vehicle dealer, or a facility that is separate from the vehicle dealer.

Traditionally, techniques or mechanisms are not provided to allow both an operator of the vehicle and a manufacturer of the vehicle to authorize, in an automated way, an automotive service performed on the vehicle. Moreover, there is no easy way to verify that the automotive service performed was an automotive service that was authorized by both the vehicle's operator and the manufacturer.

In accordance with some implementations of the present disclosure, techniques or mechanisms are provided to allow for verification that authorization for an automotive service to be performed on the vehicle has been obtained from both an operator of the vehicle and from the manufacturer of the vehicle.

<FIG> is a block diagram of an example arrangement in which a vehicle <NUM> has been brought into a repair facility <NUM>. The vehicle <NUM> includes a vehicle controller <NUM> that can control various electronic components (an electronic component <NUM> shown in <FIG>) of the vehicle <NUM>, and that has external connectivity (e.g., a Telematics Control Unit and/or a gateway). As used here, a "controller" can refer to a hardware processing circuit, which can include any or some combination of a microprocessor, a core of a multi-core microprocessor, a microcontroller, a programmable integrated circuit, a programmable gate array, a digital signal processor, or another hardware processing circuit. Alternatively, a "controller" can refer to a combination of a hardware processing circuit and machine-readable instructions (software and/or firmware) executable on the hardware processing circuit.

The electronic component <NUM> may include any of various different types of electronic components. Examples of electronic components include Electronic Control Units (ECUs) or other types of electronic components. For example, the electronic component <NUM> can include a port that can be used by an external entity, such as a mechanic's handheld device <NUM> under the control of a mechanic <NUM> at the repair facility <NUM>, to access data and further electronic components of the vehicle <NUM>. As an example, the port can include an on-board diagnostics (OBD-II) port, which the mechanic <NUM> can use to access the data and/or further electronic components of the vehicle <NUM>, via their device <NUM>. For example, the mechanic <NUM> can use the handheld device <NUM>, such as an OBD handheld scanner or other type of handheld electronic device (e.g., a smart phone, etc.) to connect to the OBD port (<NUM>) to communicate with the vehicle <NUM>. In some examples, the OBD port can include an OBD-II port. In other examples, other types of ports can be employed.

The data that can be accessed by the mechanic <NUM> through an OBD port (<NUM>) can include diagnostic data that can indicate which component(s) of the vehicle <NUM> is (are) malfunctioning or has (have) to be serviced as part of regular maintenance. The OBD port can also be used by the mechanic <NUM> to initiate diagnostics at the vehicle <NUM>, such as to run tests at the vehicle <NUM> for determining which component(s) may be malfunctioning. The OBD port can also be used by the mechanic <NUM> to communicate or interact with further electronic components of the vehicle, such as ECUs for various subsystems (e.g., an engine, a transmission, a brake, etc.) of the vehicle <NUM>.

In further examples, instead of or in addition to using the handheld electronic device <NUM> to access the electronic component <NUM> (e.g., a port), the mechanic <NUM> can use a repair facility computer <NUM> to connect to the electronic component <NUM> to establish communications with the vehicle <NUM>.

<FIG> further depicts an operator <NUM> of the vehicle <NUM>. The operator <NUM> has a handheld electronic device <NUM>, such as a smart phone or other type of handheld electronic device. In some cases, the operator <NUM> can include the owner of the vehicle <NUM>. In other examples, the operator <NUM> can include a different person (e.g., a driver or another person). In the latter examples, the owner can be remotely located from the repair facility <NUM>, but the vehicle controller <NUM> may be able to communicate with the remote owner (or more specifically, an electronic device associated with the remote owner) over a network, such as a wireless network.

<FIG> further shows a vehicle manufacturer system <NUM>, which can include a computer (or an arrangement of computers). The vehicle manufacturer system <NUM> is able to communicate over a wireless network with the vehicle controller <NUM>. In some examples, the vehicle manufacturer system <NUM> can be part of a cloud, a web server, and so forth. For example, if the vehicle controller <NUM> includes a Telematics Control Unit, then the Telematics Control Unit can communicate with the cloud (e.g., the Telematics Control Unit can receive information from the cloud to cause opening of an OBD-II port that may be part of the electornic component <NUM>). Also, in some examples, the Telematics Control Unit can communicate with the electronic component <NUM> through a central gateway (not shown).

<FIG> is a flow diagram of a process of the vehicle controller <NUM> according to some examples. The vehicle controller <NUM> receives (at <NUM>) authorization information that identifies an automotive service to be performed on the vehicle <NUM>, where the authorization information further indicates approval of performance of the automotive service on the vehicle <NUM> (e.g., an automotive service to be performed with respect to one or more ECUs or other components) by the operator <NUM> of the vehicle <NUM> and by the vehicle manufacturer (sometimes referred to as an original equipment manufacturer or OEM) that is associated with the vehicle manufacturer system <NUM>. The authorization information that indicates approval of performance of the automotive service by the operator <NUM> can be received from the handheld electronic device <NUM> associated with the operator <NUM>, or by a different computing device. Note that the operator <NUM> that provided authorization of the authorization of the automotive service may be the driver of the vehicle <NUM> or an owner that is remotely located from the repair facility <NUM>. The authorization information indicating approval of performance of the automotive service by the vehicle manufacturer can be received from the vehicle manufacturer system <NUM>.

Authorization indicating approval of performance of an automotive service can include a specific unique identifier of the automotive service, a description of the automotive service, a list of affected electronic components, or any other information that is useable to make a determination of what automotive service is being referred to. For example, the authorization information can be in the form of one or more authorization tokens. An authorization token or more generally a security token, sometimes also referred to as an access token, can be a digital data element associated with any of the following protocols: OAuth <NUM>, OpenID, Secure Token Service (STS) based on SAML (Secure Assertion Markup Language), other security tokens as in Amazon web services Secure Token Service (STS), and so forth. Information associated with an automotive service may contain an identifier of the software or firmware code and/or an identifier of a regulation, law or standard with which this automotive service aims to achieve compliance for that vehicle. For example, an automotive service may apply a software or firmware patch to comply with a regulation, law or standard. A software or firmware patch refers to machine-readable instructions that can be used to repair or replace software or firmware code in the vehicle. The regulation may be for all vehicles by a regulatory agency, or it may be just for that vehicle and a particular operator, by law enforcement agency (e.g., a breathalyzer installed per court order).

The vehicle controller <NUM> enables (at <NUM>), based on the authorization information, access to an electronic component (e.g., the electronic component <NUM>) of the vehicle <NUM> by an authorized repair entity to perform the automotive service. The authorized repair entity can be the repair facility <NUM> or can be a specific mechanic <NUM>. The authorization information can further identify the authorized repair entity approved to perform the automotive service, where the enabling of the access of the electronic component is responsive to verifying that a repair entity attempting to perform the automotive service is the authorized repair entity identified by the authorization information. Additionally, the authorization information indicates a time interval during which the approval of the performance of the automotive service is valid.

In some examples, the enabling of the access of the electronic component of the vehicle to perform the automotive service by the repair entity is further based on detecting, by the vehicle, that the vehicle is within a specified proximity (using a short-range communication as discussed further below) of at least one of the operator of the vehicle and the repair entity.

Prior to enabling access to the electronic component <NUM> of the vehicle, the electronic component <NUM> (e.g., a diagnostic port) may be in a state that does not accept or respond to requests from an electronic device (e.g., <NUM> or <NUM> in <FIG>) associated with the authorized repair entity. For example, the electronic component may ignore or discard requests for data or requests for access of further electronic components received from the electronic device associated with the authorized repair entity. Alternatively, to be able to access the electronic component <NUM>, the electronic device associated with the authorized repair entity would have to provide a credential (e.g., a password, a passcode, etc.), a key, or any other information that the electronic component <NUM> uses to allow access of the electronic component <NUM>. Enabling access of the electronic component <NUM> can refer to configuring the electronic component <NUM> to a state that accepts requests (from the electronic device associated with the authorized repair entity) to access data or further electronic components through the electronic component <NUM>. Alternatively, enabling access of the electronic component <NUM> can refer to providing the electronic device associated with the authorized repair entity with information (e.g., a credential, a key, etc.) that can be submitted by the electronic device associated with the authorized repair entity to access the electronic component <NUM>.

In some examples, the diagnostic port can be closed when the vehicle <NUM> is initially brought into the repair facility <NUM>. The diagnostic port being "closed" refers to the diagnostic port not allowing the vehicle by an external entity, such as by the handheld electronic device <NUM> of the mechanic <NUM> or by the repair facility computer <NUM>. When the diagnostic port is closed, no diagnostics or repairs on the vehicle <NUM> are allowed.

Generally, in some implementations of the present disclosure, the authorization of an automotive service may involve four entities: the vehicle manufacturer, the operator <NUM> (via the operator's device <NUM>), the authorized repair entity (either the repair facility <NUM> or the mechanic <NUM> via the mechanic's device <NUM>), and the vehicle <NUM>. In some examples, authorization of the automotive service can be performed using a series of grants and checks. The vehicle manufacturer and the operator <NUM> are the providers of authorization, and the vehicle <NUM>, and possibly the repair entity, are the authorization checkers.

In some examples, before an automotive service is allowed to commence on a vehicle, any or all of the following grants and checks may be performed:.

The above series of grants and checks can employ signaling that involves all <NUM> entities, and the sets of bilateral authorization grants and checks. The operator <NUM> is brought into diagnostic signaling (including via cloud). In some examples, the signaling can be according to any or some combination of the following protocols: OAuth <NUM>, which is a web based authorization protocol; International Organization for Standardization (ISO) <NUM> (<NUM>) Unified Gateway Protocol (UGP), which is a protocol between a diagnostic tool and the gateway ECU in a vehicle; and so forth.

In further examples, instead of or in addition to the vehicle manufacturer, other parties can be brought into the authorization process, such as an insurance company, a legal entity (public safety entity or entity in charge of assessing compliance with a law, regulation, or standard, e.g., a rule specifying that breathalyzers have to be installed). In these cases, additional signaling can involve messages to/from the insurance company server (or other server).

In some examples, in addition to the authorization process based on <FIG> or based on the grants and checks discussed above, proximity of the operator <NUM> and of the mechanic <NUM> is also confirmed before an automotive service can be performed on the vehicle.

In further examples, authorization of an automotive service can further be based on proximity of the vehicle operator <NUM> and/or the mechanic <NUM> to the vehicle <NUM> at the repair facility <NUM>. The proximity can be detected based on use of short-range communications between the vehicle <NUM> and the handheld device <NUM> and/or <NUM> associated with the vehicle operator <NUM> and/or the mechanic <NUM>.

The short-range communications can include Bluetooth communications, Near-Field Communication (NFC) communications, Radio-Frequency Identification (RFID) communications, optical communications (e.g., infrared or IR communications), or any other type of wireless communications in which the effective range between electronic devices is less than a specified short distance (e.g., less than <NUM> meters, less than <NUM> meters, less than <NUM> meters, etc.). For short-range communications, if electronic devices are physically separated by the specified short distance, then the electronic devices would be out of range of one another and thus would not be able to successfully communicate with one another.

In other examples, proximity can be detected based on using a camera to capture an image. For example, the operator's handheld device <NUM> and/or the mechanic's handheld device <NUM> can be used to capture a barcode, a quick response (QR) code, or another identifier that may be physically on the vehicle <NUM>, for example displayed in an Automotive Head Unit.

In some examples, using short-range communications, the vehicle controller <NUM> (<FIG>) can receive information from the operator's handheld device <NUM> regarding what type of automotive service the operator <NUM> is authorizing. Additionally, using short-range communications, the vehicle controller <NUM> (<FIG>) can receive information from the mechanic's handheld device <NUM> information relating to the vehicle <NUM> and/or the automotive service to be performed, such as any of the following: the vehicle model, the vehicle serial number, another identifier of the vehicle (e.g., vehicle identification information or VIN), information of a requested access type, information relating to the automotive service to be performed by the mechanic <NUM>, information on the affected electronic components, and so forth.

The vehicle controller <NUM> verifies that the operator <NUM> and the mechanic <NUM> are in close proximity to the vehicle <NUM>, based on use of short-range communications, or based on use of a camera to capture an identifier on the vehicle <NUM>.

In some examples, the vehicle controller <NUM> can send the information received from the operator's handheld device <NUM> and/or the mechanic's handheld device <NUM> to the vehicle manufacturer system <NUM> (<FIG>) for verification.

If the vehicle manufacturer system <NUM> sends back an indication that the information has been verified, then the vehicle controller <NUM> can enable the diagnostic port. For example, the vehicle manufacturer system <NUM> can send a "OBD-II firewall setting" for temporarily opening the diagnostic port. An example of specifying this firewall setting is a list of approved OBD-II Parameter IDs (PIDs), which are codes used to request certain data from a vehicle. In another example, a list of ECU identifiers identifying the components with which access is allowed (such as to replace software or firmware) to take place can be used in constructing firewall settings to allow access to the diagnostic port.

In some examples, the vehicle manufacturer system <NUM> can send back to the vehicle controller <NUM> a granular configuration (e.g., contained in configuration information that allows selective access of portions of the vehicle <NUM> by the mechanic <NUM>. For example, the granular configuration may allow access to only to the parts of the vehicle <NUM> that are required to complete the automotive service.

As noted above in Section <NUM>, the authorization of an automotive service involves four entities: the vehicle manufacture, the operator <NUM>, the mechanic <NUM>, and the vehicle <NUM>, which can involve a series of grants and checks (including Grant <NUM>, Grant <NUM>, Check <NUM>, and Check <NUM> listed in Section <NUM>).

Grant <NUM>: The operator <NUM> authorizes a particular mechanic to perform the automotive service, within a certain period of time ("authorization time window"), and possibly within a certain cost estimate. Grant <NUM> can be instantiated as a process via the cloud (e.g., the vehicle manufacturer system <NUM> of <FIG>), where the operator <NUM> uses an application or website to authorize a mechanic. The authorization can result in an authorization token provided by the vehicle manufacturer system <NUM> to the vehicle <NUM>. Alternatively, the vehicle manufacturer system <NUM> can direct the operator <NUM> and the mechanic <NUM> to exchange application-level information (e.g., QR codes) directly via their devices <NUM> and respectively <NUM>, and/or via the vehicle's system, still using their devices.

By authorizing the particular mechanic, another mechanic not approved by the operator <NUM> will not be able to perform the authorized service.

Also, by authorizing the particular mechanic to perform a specific automotive service, the particular mechanic would not be able to perform another automotive service that was not authorized by the operator <NUM>, or the particular mechanic would not be able to perform the authorized service outside the authorization time window (either before or after the authorization time window). For example, this may prevent the particular mechanic from updating an ECU of the vehicle <NUM> after the update may no longer be valid or before the update is valid.

The authorization of grant <NUM> can be provided directly, indirectly and/or implicitly by the operator <NUM> to both the vehicle <NUM> and the mechanic <NUM>.

For example, the operator <NUM> (or the electronic device, e.g., <NUM>, associated with the operator <NUM>) provides, directly to the vehicle <NUM> (more specifically, the vehicle controller <NUM>), authorization information (e.g., a digital authorization token), so that vehicle controller <NUM> can verify authorization information (e.g., an authorization token) that the mechanic <NUM> presents to the vehicle controller <NUM>. As a more specific example, the operator <NUM> can access the vehicle's infotainment graphical user interface (GUI) (e.g., an Automotive Head Unit), and can enter, through this GUI, an identifier of the mechanic <NUM>). Alternatively, the operator's handheld device <NUM> and vehicle's infotainment system can exchange information pertaining to the repair entity, e.g., a human user selects the mechanic from a drop-down list. Once this information is entered, the vehicle controller <NUM> knows that the identified mechanic <NUM> has been authorized (i.e., the vehicle controller <NUM> can authorize an automotive service to be performed by the mechanic <NUM> that presents the vehicle controller <NUM> with the mechanic's identity, such as in a digital certificate sent by an electronic device associated with the mechanic <NUM>). The foregoing solution does not involve a cloud (e.g., the vehicle manufacturer system <NUM>).

In another example, the operator <NUM> can indirectly (e.g., via the vehicle manufacturer cloud such as implemented with the vehicle manufacturer system <NUM>) provide authorization to the mechanic <NUM>.

In a further example, the operator <NUM> can indirectly (e.g., via the vehicle manufacturer cloud) provide authorization information to the vehicle controller <NUM> regarding the mechanic <NUM> so that the vehicle controller <NUM> can verify the authorization information, e.g., a digital authorization or other type of token, that the mechanic <NUM> presents to the vehicle controller <NUM>.

In another example, the operator <NUM> can implicitly authorize the mechanic <NUM>, such as based on use of a specified signaling sequence in which the vehicle manufacturer does not issue an authorization token until the vehicle manufacturer has first received authorization from the operator <NUM>, and this practice is known by all system participants to be accurate.

Grant <NUM>: The vehicle manufacturer grants authorization for the particular mechanic to perform the automotive service within a certain period of time ("authorization time window"). This authorization should (but does not have to) be granted based on the operator's authorization.

The authorization granted by the vehicle manufacturer can be instantiated as a security token (e.g., a digital authorization token) sent by cloud (e.g., the vehicle manufacturer system <NUM>) to the mechanic's device (e.g., the handheld device <NUM> or the repair facility computer <NUM>).

By authorizing the particular mechanic, another mechanic, not approved by the vehicle manufacturer, or approved by the vehicle manufacturer but not approved by the operator <NUM>, may perform the automotive service.

Moreover, the particular mechanic is prevented from performing a non-authorized automotive service, and is prevented from performing the authorized automotive service outside the authorization time window.

The authorization of grant <NUM> is provided directly, indirectly or implicitly to both the vehicle <NUM> and the mechanic <NUM>.

The authorization can be performed at the vehicle manufacturer cloud (e.g., implemented with the vehicle manufacturer system <NUM>). For example, the vehicle manufacturer system <NUM> can send to each of the mechanic <NUM> and the vehicle <NUM> a respective different authorization token or the same authorization token. The authorization token can be sent over separate secure channels between the vehicle manufacturer system <NUM> and the respective vehicle <NUM> and the electronic device (e.g., <NUM> or <NUM>) associated with the mechanic <NUM>.

The authorization token sent to each of the vehicle <NUM> and the mechanic <NUM> may be in response to a request sent from the operator <NUM> or the mechanic <NUM> to the vehicle manufacturer system <NUM>.

Check <NUM>: The vehicle <NUM> authenticates the mechanic and verifies the mechanic's authorization given by the vehicle manufacturer (part <NUM>), and also by the operator <NUM> (part <NUM>), or both together (implicit).

Check <NUM> can be instantiated as a check at the vehicle <NUM> on the authorization token from the vehicle manufacturer (if the authorization token includes an authorization from the operator <NUM>), or separately check the authorization token from the vehicle manufacturer and the authorization token from the operator <NUM>.

Check <NUM> prevents another mechanic, not approved by the vehicle manufacturer, or approved by the vehicle manufacturer but not chosen by the operator <NUM>, from performing an automotive service. Moreover, the particular mechanic is prevented from performing a non-authorized automotive service, and is prevented from performing the authorized automotive service outside the authorization time window.

For check <NUM>, part <NUM>, the mechanic <NUM> can present the vehicle <NUM> with an authorization token. The vehicle controller <NUM> can validate the authorization token if either of the options is satisfied. With a first option, a digital signature verification is performed. The vehicle stores a pre-stored public key of the vehicle manufacturer system <NUM>, and the vehicle controller <NUM> can check that the authorization token has been signed by the vehicle manufacturer. The authorization token includes an identifier (e.g., a VIN) of the vehicle <NUM> in addition to information of the automotive service.

With a second option, a token data comparison is performed. The vehicle <NUM> is provided with a copy of the authorization token directly from the vehicle manufacturer system <NUM>, so that the vehicle controller <NUM> can perform a comparison of the authorization token from the mechanic <NUM> with the authorization token from the vehicle manufacturer system <NUM>.

Alternatively, to perform check <NUM>, part <NUM>, the vehicle <NUM> can directly seek authorization from the vehicle manufacturer system <NUM>.

For check <NUM>, part <NUM>, the mechanic <NUM> presents the vehicle <NUM> with an authorization token. To validate the authorization token, the vehicle <NUM> can use a pre-stored digital public key infrastructure (PKI) key of the operator <NUM>, so that the vehicle controller <NUM> can check that the operator <NUM> has indeed signed the authorization token.

Alternatively, the operator <NUM> can directly present the vehicle <NUM> with an authorization token. The operator <NUM> may, for example, use a GUI in the vehicle's infotainment system (such as to enter a username and password in an application so that the operator <NUM> can type in the identity of the mechanic <NUM>, and other information such as scope of allowed service.

Check <NUM>, implicit, can check both grant <NUM> and grant <NUM> in one operation. For example, the mechanic <NUM> presents the vehicle <NUM> with an authorization token. The authorization from both the operator <NUM> and the mechanic <NUM> can be implicit in the signalling flow. In this example, the vehicle manufacturer system <NUM> will only issue to the mechanic <NUM> an authorization token after the vehicle manufacturer system <NUM> has received an authorization from the operator <NUM> for the automotive service to commence. In this case, the vehicle controller <NUM> only has to be presented with the authorization token from the mechanic <NUM>, and the vehicle <NUM> hears nothing from the vehicle manufacturer system <NUM>, but trusts that the authorization token presented to the vehicle <NUM> by the mechanic <NUM>, e.g., by verifying the vehicle manufacturer's digital signature (whom the vehicle <NUM> trusts intrinsically) included in that token.

In some examples, to validate the authorization token, the vehicle <NUM> can store a signing (i.e., public) key of the vehicle manufacturer. The vehicle manufacturer may have one or more public keys. Alternatively, instead of an authorization token, the vehicle manufacturer system <NUM> can directly inform the vehicle <NUM> that the operator authorization has been granted (e.g., via a secure signalling procedure between vehicle <NUM> and vehicle manufacturer system <NUM>).

Check <NUM> (optional): The mechanic may authenticate the vehicle <NUM>. Check <NUM> may be performed using the mechanic's electronic device, such as the handheld device <NUM> or the repair facility computer <NUM>. In some examples, check <NUM> may be based on a cryptographic authorization token sent by the vehicle controller <NUM> to the mechanic's electronic device. The cryptographic authorization token may be used to verify an authorization provided by the vehicle manufacturer to the mechanic for a specific vehicle, such as identified by a VIN.

Check <NUM> prevents a vehicle from receiving an automotive service unless authorized (such as based on payment for the automotive service by the operator <NUM>).

For check <NUM>, the vehicle <NUM> presents the mechanic <NUM> with an authorization token. The mechanic <NUM> (or more specifically, an electronic device associated with the mechanic <NUM>) can validate the authorization token, which can be performed in any of the following manners.

With a first option, the mechanic's electronic device has a pre-stored public key of the vehicle manufacturer system <NUM>, or that public key can be looked up on the fly, and can check that the authorization token has been signed by the vehicle manufacturer. In the first option, the vehicle <NUM> would have had to a priori received the authorization token from the vehicle manufacturer.

With a second option, the mechanic's electronic device is provided with a copy of the authorization token directly from the vehicle manufacturer upon authorization, so that the mechanic's electronic device to compare the authorization tokens. As with the first option, the vehicle controller <NUM> would have had to a priori received the authorization token from the vehicle manufacturer.

After the authorized service is completed, the vehicle controller <NUM> can notify the vehicle manufacturer system <NUM> of the completion, and the vehicle manufacturer system <NUM> can notify the operator <NUM> about the results of the automotive service.

The vehicle manufacturer system <NUM> can use diagnostics information retrieved from the vehicle <NUM> (such as using a diagnostic port of the vehicle <NUM>, e.g. on the electronic component <NUM>) to determine whether the automotive service was successfully completed. For example, the vehicle manufacturer system <NUM> can confirm that a new ECU has been installed (replaced) in the vehicle <NUM>, and that the new ECU is an authentic part (the cryptographic signature of the new ECU is validated). In case an ECU has been upgraded with new firmware or software, that change can also be validated by the vehicle manufacturer. The vehicle manufacturer system <NUM> can also check that oil level has changed (e.g., if an oil change is being charged for).

The post-automotive service check can help catch unauthorized repairs of the vehicle <NUM>, such as requested by a driver of the vehicle <NUM> who brought the vehicle <NUM> to the repair facility <NUM> but who is not also the owner (in other words, bringing the car to a mechanic does not equate owner consent). The post-automotive service check can also indicate whether the mechanic <NUM> performed an automotive service that was not pre-authorized, and if so, what were the changes that were done, e.g., what electronic components were changed.

In some cases, a further automotive service can be requested after an original automotive service is authorized. The mechanic <NUM> initiates this process by requesting the vehicle manufacturer system <NUM> for authorization, and the authorization is granted from both the vehicle manufacturer and the operator <NUM>. The same grants and checks discussed above can be used for the further automotive service, with a possible difference that the trigger is signaling from the mechanic to the vehicle manufacturer system <NUM>. The operator <NUM> has to be notified in order to authorize, e.g., via an application at the operator's handheld device <NUM>.

The different ways in which the checks are performed could result in a large number of different signaling flows. There are many possible approaches, some examples are given below.

<FIG> shows a first example signaling flow. The tasks of <FIG> can be performed in an order different from that depicted.

The operator <NUM> (or more specifically, an electronic device <NUM> associated with the operator <NUM>), authorizes (at <NUM>) a particular mechanic to perform an automotive service, by sending authorization information (e.g., an authorization token) to the vehicle manufacturer system <NUM>. This authorization is part of grant <NUM> discussed above. The electronic device <NUM> can be the handheld electronic device <NUM> of <FIG>, or another electronic device.

For the vehicle <NUM> to accept changes from the mechanic <NUM>, at least two things have to happen. First, the mechanic <NUM> (using an electronic device <NUM> associated with the mechanic <NUM>) has to be authenticated and authorized by the vehicle manufacturer system <NUM>. The electronic device <NUM> can be the handheld electronic device <NUM> of <FIG>, or another electronic device. This authentication and authorization is based on the mechanic's electronic device <NUM> sending (at <NUM>) a request for an authentication token from the vehicle manufacturer system <NUM>, and in response, the vehicle manufacturer system <NUM> sending (at <NUM>) the authentication token to the mechanic's electronic device <NUM> (grant <NUM>).

In the signaling flow of <FIG>, the vehicle manufacturer system <NUM> can optionally send (at <NUM>) information to the vehicle <NUM> that would enable the vehicle <NUM> to check the mechanic's authentication token. Task <NUM> can occur before or after task <NUM>.

Second, the vehicle <NUM> authenticates the mechanic <NUM>, based on the mechanic's electronic device <NUM> sending (at <NUM>) the authorization token (which was received by the mechanic's electronic device <NUM> from the vehicle manufacturer system <NUM>) to the vehicle <NUM>. Task <NUM> is check <NUM>, implicit, discussed above. The check is implicit because the authorization of the operator <NUM> is implicit.

In examples where the task <NUM> is not performed, the vehicle <NUM> may not have enough information to validate the authorization token (<NUM>) from the mechanic's electronic device. As a result, tasks <NUM> and <NUM> are performed, in which the vehicle <NUM> sends (at <NUM>) the authorization token received from the mechanic's electronic device <NUM> to the vehicle manufacturer system <NUM>. In response, the vehicle manufacturer system <NUM> sends (at <NUM>) an indication that the authorization token is valid, based on the vehicle manufacturer system <NUM> confirming that the authorization token is valid.

Once the validity of the authorization token received from the mechanic's electronic device <NUM> is confirmed (based on the information of task <NUM> or the indication of task <NUM>), the vehicle <NUM> authenticates and authorizes (at <NUM>) the mechanic <NUM> to perform the authorized service.

In some examples, the content of the authorization token from the vehicle manufacturer system <NUM> (task <NUM>) can include any or some combination of the following: an identifier of the mechanic <NUM>, an identifier of the vehicle <NUM>, an identifier of the automotive service (plus parameters such as a time limit, a list of affected components, a cost estimate, etc.), and a cryptographic signature of the vehicle manufacturer.

<FIG> shows a second example signaling flow. In <FIG>, the mechanic <NUM> (instead of the operator <NUM> as in <FIG>) initiates the process. The tasks of <FIG> can be performed in an order different from that depicted.

The mechanic's electronic device <NUM> sends (at <NUM>) a request for an authorization token to the vehicle manufacturer system <NUM>. In response to the request, the vehicle manufacturer system <NUM> checks (at <NUM>) with the operator's electronic device <NUM> regarding whether the mechanic <NUM> is authorized for the automotive service. In response to the checking, the operator's electronic device <NUM> sends (at <NUM>) an authorization grant (possibly including a cryptographic token) to the vehicle manufacturer system <NUM>.

The operator's electronic device <NUM> can be the operator's smart phone which has an appropriate application installed, or can be the vehicle's telematics control unit, by which the operator <NUM> can provide authorization via, e.g., username/password access on the infotainment GUI.

In response to receiving the authorization grant, the vehicle manufacturer system <NUM> sends (at <NUM>) an authorization token to the mechanic's electronic device <NUM>. Optionally, the vehicle manufacturer system <NUM> can send (at <NUM>) information to the vehicle <NUM> that enables the vehicle <NUM> to check the mechanic's authorization token. Tasks <NUM> and <NUM> can occur in any order.

The remaining tasks of <FIG> are the same as the corresponding tasks of <FIG>, and are assigned the same reference numerals.

The content of the authorization token sent to the mechanic <NUM> can be the same as the content of <FIG>.

<FIG> shows a third example signaling flow. The tasks of <FIG> can be performed in an order different from that depicted.

In <FIG>, the operator <NUM> uses the vehicle <NUM> as a device and the mechanic <NUM> uses the mechanic's electronic device. The vehicle and the mechanic's electronic device can communicate directly via Bluetooth, WI-FI, OBD-II, etc., or via the cloud (implemented the vehicle manufacturer system <NUM>).

The operator <NUM> (using the operator's electronic device <NUM> or a device of the vehicle <NUM>) can authorize (at <NUM>) the mechanic <NUM> to perform the automotive service, by sending authorization information to the vehicle <NUM>.

In response to the authorization information from the operator <NUM>, the vehicle <NUM> sends (at <NUM>) to the mechanic's electronic device <NUM> a first authorization token (Token A).

The mechanic's electronic device <NUM> passes (at <NUM>) Token A to the vehicle manufacturer system <NUM>. The vehicle manufacturer system <NUM> checks (at <NUM>) Token A and performs other checks too. Optionally, the vehicle manufacturer system <NUM> can provide (at <NUM>) information to the vehicle <NUM> to enable the vehicle <NUM> to check the mechanic's Token B at a later time.

In response to the check (at <NUM>) passing, the vehicle manufacturer system <NUM> sends (at <NUM>) a new authorization token (Token B) to the mechanic's electronic device <NUM>. The mechanic's electronic device <NUM> then sends (at <NUM>) Token B to the vehicle <NUM>.

The vehicle <NUM> verifies (at <NUM>) Token B, which means that the mechanic <NUM> was authorized by the vehicle manufacturer system <NUM> as well. The authorization parameters of the vehicle manufacturer system <NUM> match authorization parameters received from the operator's electronic device <NUM> as received in task <NUM>.

The content of Token A that the vehicle <NUM> can provide to the mechanic <NUM> (task <NUM>) can include any or some combination of the following: an identifier of the mechanic <NUM>, an identifier of the operator <NUM>, an identifier of the vehicle <NUM>, an identifier of the automotive service (plus parameters like time limit, affected components, cost estimate, etc.), and a cryptographic signature of the vehicle <NUM>.

The content of Token B is the same as the authorization token of <FIG>.

<FIG> shows a fourth example signaling flow. The tasks of <FIG> can be performed in an order different from that depicted.

The operator's electronic device <NUM> authorizes (at <NUM>) a particular mechanic to perform an automotive service, by sending authorization information to the vehicle manufacturer system <NUM>.

The mechanic's electronic device <NUM> sends (at <NUM>) a request for an authentication token (Token B) from the vehicle manufacturer system <NUM>. In response, the vehicle manufacturer system <NUM> sends (at <NUM>) Token B to the mechanic's electronic device <NUM>.

The vehicle <NUM> authenticates the mechanic <NUM>, based on the mechanic's electronic device <NUM> sending (at <NUM>) Token B (which was received by the mechanic's electronic device <NUM> from the vehicle manufacturer system <NUM>) to the vehicle <NUM>.

Next, the vehicle <NUM> sends (at <NUM>) an authorization token (Token C) to the mechanic's electronic device <NUM>, to enable the mechanic's electronic device <NUM> to authenticate the vehicle <NUM>. Optionally, in response, the mechanic's electronic device sends (at <NUM>-A) Token C to the operator's electronic device <NUM> (directly or via the cloud), or alternatively, the mechanic's electronic device sends (at <NUM>-B) Token C to the vehicle manufacturer system <NUM>.

Responsive to the operator's electronic device <NUM> or the vehicle manufacturer system <NUM> validating Token C, the operator's electronic device <NUM> or the vehicle manufacturer system <NUM> sends (at <NUM>-A or <NUM>-B, respectively) an indication of the validation of Token C back to the mechanic's electronic device <NUM>.

At this point, the vehicle <NUM> and the mechanic <NUM> are mutually authenticated (at <NUM>). Note that the operator <NUM> and the vehicle manufacturer may have implicitly provided the authentication.

The content of Token C can include any or some combination of the following: an identifier of the vehicle <NUM>, information of a type of automotive service, a list of affected vehicle components, a time limit, an estimated cost, and a cryptographic signature of the vehicle <NUM>.

Table <NUM> below provides a mapping of entities shown in <FIG> and <FIG> and entities of OAuth <NUM>.

<FIG> shows an example signaling flow in which OAuth <NUM> messages are used. The tasks of <FIG> can be performed in an order different from that depicted.

A message flow <NUM> including an authorization request and authorization grant allows an operator <NUM> to authorize the mechanic <NUM> directly.

A message flow <NUM> can be used by the mechanic <NUM> to request a token from the vehicle manufacturer system <NUM>, and for the vehicle manufacturer system <NUM> to send the token to the mechanic <NUM>.

The vehicle manufacturer system <NUM> can provide (at <NUM>) an access token (including an authorization token) to the vehicle <NUM>. The mechanic's electronic device can send (at <NUM>) an access token (including an authorization token) to the vehicle <NUM>. The vehicle <NUM> can send (at <NUM>) an access token to the mechanic's electronic device to access a protected resource.

OAuth <NUM> can be modified to include the following features.

An Authorization grant (as a JSON Web token (TBC)) can be expanded to include vehicle service parameters: a diagnostic code, a service code, an expiration time, a list of affected vehicle components, an identifier of a mechanic, an identifier of a vehicle.

A transaction from an Authorization server (vehicle manufacturer cloud) to a resource server (vehicle) can be added to enable the checking of the token (by the vehicle). An issue may be that the vehicle is the resource server, but the vehicle may not have any prior ability to check authorization tokens like in OAuth <NUM>. This transaction (between authorization server and resource) is present in another, separate token system: STS (Security Token Service).

As noted above, Unified Gateway Protocol (UGP) is a protocol between a diagnostic tool and the gateway ECU in a vehicle.

The security signaling part of UGP can be modified to accommodate the authorization of the operator <NUM>. In the current UGP standard there is an authenticationcall UGP message containing a string called authenticationKey. This message is sent from the diagnostic tool device to the gateway (VSG) of the car. In response, the VSG responds with an authenticationReply UGP message containing a binary "authorization" token value where each bit corresponds to a certain privilege, e.g., bit <NUM> means get-value-extended-access, bit <NUM> means file-download-access, and these bits could be set but other bits could be set to <NUM>. If the authenticationKey is found not suitable, then the VSG sends a negative authenticationReply granting no access.

To enhance UGP, the authenticationCall message is modified to include in addition to or in lieu of the authenticationKey at least one security token, as in the example flows that show a token being sent to the vehicle <NUM>. In some examples, this token is cryptographically signed by the vehicle manufacturer. The data in the token can contain any or some combination of the following:.

The VSG can take this security token into account (e.g., at least verifying the signature of the vehicle manufacturer and the identifier of the mechanic in the authenticationKey original part, assuming token contains the identifier of the mechanic) when determining an authorization value.

Constraints on a requested or granted authorization can be provided by the operator <NUM> or the mechanic <NUM> as part of the authorization process.

In some examples, the operator <NUM> may only grant authorization for certain specific automotive service(s) to be performed on the vehicle <NUM>, whereas the list of recommended services by the vehicle manufacturer may contain several services, as superset of those selected services.

For example, if the operator <NUM> has authorized that an automotive service can be performed on the brakes, then automotive services on other components of the vehicle <NUM> will not be permitted.

The operator <NUM> can grant authorization for only a period of time, e.g., from the present until <NUM> weeks from now. Then any repairs attempted outside this time window should be rejected by the vehicle <NUM>.

The operator <NUM> can authorize whether repair or replacement of only software, only hardware (ECU), or some combination of hardware and software is allowed, and the vehicle <NUM> could enforce this restriction. In the case of hardware repair or replacement, a technique of enforcement can involve providing a notification to the operator <NUM> that hardware has been changed in the vehicle <NUM> (in violation of an authorization), and/or not allowing the vehicle <NUM> to start when unauthorized new hardware has been inserted. In the case of software repair or replacement, the vehicle <NUM> can ensure that only authorized updates may be made. Additionally, the vehicle <NUM> may provide a notification to the operator <NUM> that software has been changed (in violation of an authorization).

Authorization information specifying constraints may also include an agreed maximum price for the automotive service. In this way, the authorization/authentication signaling also establishes a contract between the mechanic <NUM> and the operator <NUM>, which may be accessed in case of a later dispute between the mechanic <NUM> and the operator <NUM>. Optionally, only the vehicle manufacturer can see this maximum price.

Also, optionally, the process may be repeated if the mechanic <NUM> finds that the repairs are more extensive than anticipated, and so a new authorization has to be granted via a similar mechanism.

The following describes examples of data formats that can be used for specifying an authorization of an automotive service.

The authorization data can be included in a digital file that is cryptographically signed by the operator <NUM> via a device (e.g., a smart phone) or can be provided to the mechanic <NUM> and/or the vehicle manufacturer via a secure communication channel.

An example implementation is as follows. The mechanic <NUM> can present a cost estimate to the operator <NUM>, which states, for example, that brakes are going to be fixed and it will cost $<NUM>. This cost estimate is communicated to the operator <NUM>, which provides an authorization for this work to commence. The cost estimate can be put together using an application, such as based on use of drop down menus and so forth to enable mechanic <NUM> to describe work that is to be performed. A first version of cost estimate and information of the work to be performed may be produced automatically by the vehicle manufacturer system <NUM> (such as based on remote diagnostics monitoring). The mechanic <NUM> can edit the cost estimate and information describing the work, and can pass the information to the operator <NUM>. The operator <NUM> can view the information, which can be presented by an application on an electronic device of the operator <NUM>. The operator <NUM> can agree to the information, such as by clicking on an "agree" button presented by the application. The application then produces a file (e.g., an eXtensible Markup Language (XML) file or other type of file) describing the work that is to be performed, and then cryptographically signs this authorization file using a private key of the operator <NUM>.

The mechanic <NUM> may only request authorization for certain specific work to be performed. In a similar way to that described above for the operator <NUM>, the mechanic <NUM> may encode information of the work that the mechanic <NUM> is planning to perform, and the mechanic <NUM> may include a price for the job, a maximum timeframe that is expected for the job, and so forth. This file is cryptographically signed by the mechanic <NUM> via a device associated with the mechanic <NUM>. The cryptographically signed file can be provided to the operator <NUM> and/or the vehicle manufacturer.

The vehicle manufacturer system <NUM> can perform the role of checking that authorization requests and grants (in authorization files) are consistent with one another, or alternatively the authorization files can be directly shared between the operator <NUM> and the mechanic <NUM>.

In the context of OAuth <NUM>, these permissions are referred to as "scope. " In the Internet context, the scope contains space-delimited permissions that the application seeking authorization requires. In the automotive case as per current disclosure, the scope can contain elements of the service, e.g., service type (oil change, etc.), identifier of the mechanic (optional, can be part of client ID), a time window, and optionally, other parameters like affected vehicle components, cost.

Signaling flows can be organized such that the vehicle manufacturer performs a central role in which the vehicle manufacturer has visibility of the requested and granted authorizations. The vehicle manufacturer also receives diagnostics information directly from the vehicle <NUM> after the work has been completed. The vehicle manufacturer may therefore be able to determine whether the agreed work has actually been done, and if so, whether the work has been done adequately.

For example, if the mechanic <NUM> was authorized to change oil then the vehicle manufacturer may expect to see a change in the oil level being reported by the vehicle <NUM> (if the vehicle <NUM> is able to do a reading at the instance that the oil is drained out; though perhaps this is only possible if oil levels were lower than desirable prior to the visit to the repair facility).

<FIG> shows an example signaling flow after the mechanic <NUM> has performed (at <NUM>) the automotive service. The tasks of <FIG> can be performed in an order different from that depicted.

Note that the authorization for the automotive service may have been confirmed by the vehicle <NUM> using any of the signaling flows of <FIG>, for example.

The mechanic's electronic device, the operator's electronic device, or the vehicle <NUM> can notify (at <NUM>) the vehicle manufacturer system <NUM> that the automotive service has been completed. The vehicle <NUM> sends (at <NUM>) a diagnostic report to the vehicle manufacturer system <NUM>.

The vehicle manufacturer system <NUM> determines (at <NUM>) whether the information in the diagnostic report is consistent with the authorized automotive service. If not, then the vehicle manufacturer system <NUM> can generate (at <NUM>) an indication that unauthorized work may have been performed. For example, the vehicle manufacturer system <NUM> may set a risk factor to a value indicating an elevated level of risk.

The vehicle manufacturer system <NUM> can send (at <NUM>) the indication to the operator's electronic device <NUM>, to alert the operator <NUM> of the possible risk of an unauthorized service.

The operator <NUM> wishes to allow the repair facility <NUM> to perform an automotive service on the vehicle <NUM>. The vehicle <NUM> is designed to ensure that only authorized repairs (as authorized by the vehicle manufacturer and the operator <NUM>) are performed, and optionally, only via certain diagnostic tools (identified by, for example, type/model numbers, or by owner, i.e., ones belonging to certain dealers/shops).

The only entity that the vehicle <NUM> trusts is the vehicle manufacturer. The vehicle manufacturer system <NUM> has secure links to vehicles, and the secure links are used to upload/download vehicle data. It is assumed the vehicle manufacturer knows about all acceptable/recommended repairs at a given time for a given vehicle.

The vehicle <NUM> ensures before granting access (e.g., open the OBD-II port), that the repair entity is authorized by the operator <NUM> for a given automotive service, and/or the repair entity has been authorized by the vehicle manufacturer as well (e.g., the repair entity is an authorized dealer).

One way the vehicle <NUM> can ensure the legitimacy of the repair entity and the authorization granted by the operator <NUM> is by gathering both identifying information from the mechanic's electronic device (implicitly as a request to perform service) and identifying information from the operator's electronic device (as an authorization grant) at substantially the same time and via short-range communication. This ensures that at least both the mechanic's electronic device and the operator's electronic device are in proximity to the vehicle <NUM> at the same time.

There are many options for short-range communications: QR codes, NFC tags/signals, Bluetooth or Bluetooth Low-Energy signals, and WI-FI or WI-FI-Direct signals.

The vehicle <NUM> then sends both the identifying information from the mechanic's electronic device and identifying information from the operator's electronic device up to the vehicle manufacturer system <NUM> to be verified. This is because the vehicle <NUM> may not have all the information to verify the information and make an authorization decision. Alternatively, the vehicle <NUM> is provided by the vehicle manufacturer a list of approved repair entities for given types of service/repairs, so that the vehicle <NUM> can make that decision on its own.

The vehicle manufacturer system <NUM> can send back to the vehicle <NUM> a list of access privileges that the vehicle <NUM> can grant to the mechanic's electronic device for the automotive service. The vehicle manufacturer system <NUM> can send back any or all of the following types of information: information identifying a diagnostic tool (e.g., model/serial number, and/or shop identifier), a list of ECUs that are allowed to be updated (repaired, replaced, or from which data can be obtained), a list of acceptable Parameter IDs (PIDs), which are codes used to request data from a vehicle via a diagnostic tool.

The vehicle <NUM> then opens the diagnostics port for the repair entity to access. A component of the vehicle such as vehicle controller <NUM> or the electronic component <NUM>, can restrict access to only certain components in the vehicle; access restriction can be implemented via a gateway or firewall. The vehicle <NUM> sends a diagnostic report to the vehicle manufacturer system <NUM>.

<FIG> shows an example signaling flow. The tasks of <FIG> can be performed in an order different from that depicted.

The operator's electronic device <NUM> sends (at <NUM>) to the vehicle <NUM> information indicating an authorization grant using a short-range communication, such as by use of a QR code, an NFC tag, a Bluetooth Low Energy beacon, etc..

The mechanic's electronic device <NUM> sends (at <NUM>) to the vehicle <NUM> information indicating an authorization request using a short-range communication (e.g., any of the above short-range communications). The information can also include identifying information of the mechanic's electronic device.

The vehicle <NUM> sends (at <NUM>) both the operator's and mechanic's information (which can be different from each other, e.g. both QR codes or one QR code, one NFC tag) to the vehicle manufacturer system <NUM>.

The vehicle manufacturer system <NUM> verifies (at <NUM>) the operator's and mechanic's information, and sends (at <NUM>) a result of the verification to the vehicle <NUM>. The result can be a positive result, which means the automotive service is approved to proceed, or a negative result, which means that the vehicle <NUM> should not allow the automotive service at this time, location, and/or from this mechanic.

In response to the result, the vehicle <NUM> controls (at <NUM>) a state of the diagnostic port of the vehicle <NUM>. For example, in response to a positive result, the vehicle <NUM> opens the diagnostic port. In response to a negative result, the vehicle <NUM> maintains diagnostics port closed.

The following discusses how the operator's electronic device operates, such as for task <NUM> in <FIG>. It is assumed that the vehicle <NUM> is ready to receive the information from the operator's electronic device (e.g., the vehicle's camera is ready, or the NFC reader in the vehicle <NUM> is ready, or the Bluetooth or WI-FI connection to the operator's electronic device is ready). The operator <NUM> opens an application on the operator's electronic device. The application may be an application developed by the vehicle manufacturer, or an application developed by a repair facility. The operator <NUM> selects, in a GUI of the application, an automotive service from a drop-down menu or accepts a suggestion (in case of the vehicle manufacturer application, the vehicle manufacturer may have already suggested services and/or repairs). The operator's electronic device then displays a QR code, or notifies that an NFC tag is ready to be read, or that a Bluetooth code is ready to be sent, or that the WI-FI connection to the vehicle <NUM> is ready. The operator <NUM> then points the operator's electronic device toward the vehicle <NUM>, and the vehicle <NUM> reads the QR code, or the NFC tag, or receives a Bluetooth or Bluetooth Low Energy beacon or a WI-FI signal, all via a short range communication.

The mechanic's electronic device can perform similar tasks for task <NUM> of <FIG>.

In another example, the QR code appears in a display (e.g., head up display), and the operator's electronic device reads the QR code. The operator's electronic device can redirect the QR code or a link (e.g., a uniform resource locator (URL) relating to the QR code) to the vehicle manufacturer system <NUM>. The URL relating to the QR code contains a cookie or other authorization information, by which the vehicle manufacturer system <NUM> can deduce that the operator <NUM> is in the proximity of the vehicle, and the vehicle manufacturer system <NUM> can authorize the automotive service to be performed on the vehicle <NUM>.

Similarly, another or the same QR code can appear on the display of the vehicle <NUM>, and the mechanic's electronic device can read the QR code. The mechanic's electronic device can redirect the QR code (or a link in the form of a URL to the QR code) to the vehicle manufacturer system <NUM>. The URL contains a cookie or other authorization information, by which the vehicle manufacturer system <NUM> can deduce that the mechanic <NUM> is also in the proximity of the vehicle <NUM>. In the end, the vehicle manufacturer instructs the vehicle <NUM> to allow limited access to the mechanic's diagnostic tool. In some examples, the vehicle manufacturer sends a list of PIDs that the OBD-II diagnostic port can accept.

<FIG> is a block diagram of an example system <NUM>, which can be any of the vehicle controller <NUM>, the devices <NUM>, <NUM>, <NUM>, and <NUM>, the repair facility computer <NUM>, and the vehicle manufacturer system <NUM>.

The system <NUM> includes one or more hardware processors <NUM>. A hardware processor can include a microprocessor, a core of a multi-core microprocessor, a microcontroller, a programmable integrated circuit, a programmable gate array, a digital signal processor, or another hardware processing circuit.

The system <NUM> includes a communication interface <NUM> to communicate over a network, such as a wireless network or a wired network. The communication interface <NUM> includes a transceiver to transmit and receive signals over the network, and one or more protocol layers that control the transmission and reception of the messages or frames according to corresponding one or more protocols.

The system <NUM> includes a non-transitory machine-readable or computer-readable storage medium <NUM> to store machine-readable instructions that are executable on the one or more hardware processors <NUM> can perform any of various tasks discussed above. The machine-readable instructions can include automotive service authorization instructions <NUM> to perform authorizations for supporting automotive services on vehicles.

The storage medium <NUM> can include any or some combination of the following: a semiconductor memory device such as a dynamic or static random access memory (a DRAM or SRAM), an erasable and programmable read-only memory (EPROM), an electrically erasable and programmable read-only memory (EEPROM) and flash memory; a magnetic disk such as a fixed, floppy and removable disk; another magnetic medium including tape; an optical medium such as a compact disc (CD) or a digital video disc (DVD); or another type of storage device. Note that the instructions discussed above can be provided on one computer-readable or machine-readable storage medium, or alternatively, can be provided on multiple computer-readable or machine-readable storage media distributed in a large system having possibly plural nodes. Such computer-readable or machine-readable storage medium or media is (are) considered to be part of an article (or article of manufacture). The storage medium or media can be located either in the machine running the machine-readable instructions, or located at a remote site from which machine-readable instructions can be downloaded over a network for execution.

Claim 1:
A method comprising:
receiving (<NUM>), by a vehicle (<NUM>) comprising a diagnostic port (<NUM>), authorization information that identifies an automotive service to be performed on the vehicle, the authorization information further indicating approval of performance of the automotive service on the vehicle by an operator (<NUM>) of the vehicle and a vehicle manufacturer, wherein the authorization information received by the vehicle (<NUM>) comprises vehicle manufacturer authorization information sent by a system (<NUM>) of the vehicle manufacturer over a network to the vehicle responsive to the system of the vehicle manufacturer receiving an indication that the vehicle manufacturer authorization information is requested; and
wherein the vehicle manufacturer authorization information received by the vehicle over the network from the system of the vehicle manufacturer identifies an authorized repair entity (<NUM>) approved to perform the automotive service, the authorized repair entity (<NUM>) being different from the operator (<NUM>) of the vehicle;
receiving, by the vehicle, configuration information from the system of the vehicle manufacturer, the configuration information providing selective access to a portion of the vehicle for the automotive service while disabling access to another portion of the vehicle;
based on the authorization information received by the vehicle and the configuration information received by the vehicle from the system of the vehicle manufacturer, changing (<NUM>) by the vehicle, a state of the diagnostic port from a closed state to an open state so as to accept access from an external device (<NUM>, <NUM>) of an authorized repair entity (<NUM>, <NUM>) to perform the automotive service;
wherein the changing of the state of the diagnostic port to an open state to accept access from the external device is responsive to verifying that a repair entity attempting to perform the automotive service is the authorized repair entity identified by the vehicle manufacturer authorization information received by the vehicle over the network from the system of the vehicle manufacturer, and the change of state of the diagnostic port to an open state is responsive to a setting from the system of the vehicle manufacturer; and
on adoption of the open state, the method further comprises performing, at the vehicle, diagnostic tests through the opened diagnostic port and communicating with the external device (<NUM>, <NUM>) through the opened diagnostic port.