Patent Description:
A "vehicle" can refer to any or some combination of a truck, a trailer, a tractor, a car, a railed vehicle (e.g., a train), a watercraft (e.g., a ship), an aircraft, a spacecraft, or any other moveable structure that can carry cargo or people.

A vehicle can include one or more services that are accessible by users in a proximity of the vehicle. For example, the service(s) of the vehicle can be accessible by the occupants (driver and/or passenger) of the vehicle. Alternatively, the service(s) of the vehicle can be accessible to a user that is outside but near the vehicle. Such a user can be a technician that is servicing the vehicle, a valet parker, or any other user that is near the vehicle (i.e., within a communication range of the vehicle).

Examples of services that can be provided by vehicles include wireless network connectivity (to allow for connection to a cellular network or a wireless local area network or WLAN, for example) so that a user is able to establish a communication session, playback of media content (e.g., music, video, etc.), a telephony service to allow a user to make a telephone call, access to an online music station, and so forth. Services can be accessed both internally and externally of the vehicle.

To gain access to a service of a vehicle, a security credential and profile information can be used. A security credential (or more generally a "credential") can refer to information that allows or disallows for a secured access of a service. Examples of security credentials include encryption keys, passwords, certificates and so forth. Profile information can refer to information relating to an identification of the service or an access point (AP) of a wireless network, information describing a service, wireless pairing information (e.g., Bluetooth pairing information, Near Field Communication (NFC) pairing information, etc.) for remote access to the vehicle or access to applications (e.g., Waze, Spotify, etc.), and so forth. In a wireless local area network (WLAN) that operates according to the Institute of Electrical and Electronics Engineers (IEEE) <NUM> standards, an identifier of an AP can include a service set identifier (SSID).

In some contexts, the access of a service of a vehicle can be temporary. For example, the vehicle may be a rental vehicle, a taxi, a shared vehicle, and so forth. A user can access a service so long as the user occupies or has possession of the vehicle. However, at the same or a later time, a second user can access a service of the vehicle. Thus, in some cases, even though access of a service of a vehicle is temporary, a security credential and other information associated with the access of the service by the first user may persist even after the service access is complete (or terminated). As a result, one user may be able to access personal information of another user who has accessed or is accessing a service of the vehicle.

In accordance with some implementations of the present disclosure, information used by a user to access a service of a vehicle is revoked after completion (or equivalently, termination) of access of the service by the user. Revoking the information can refer to either deleting the information or otherwise rendering the information invalid. An example of information that can be revoked includes a credential used by the user to access the service. In other examples, other information can also be revoked. For example, service access information that relates to at least one service accessible by the user can be revoked after completion of the service access. The service access information is used to access an application (on the vehicle) that provides the service.

<FIG> is a block diagram of an example arrangement that includes a vehicle <NUM>, a user device <NUM>, and an operator system <NUM> that is associated with an operator of the vehicle <NUM>. An "operator" can refer to an entity that manages the vehicle <NUM>, such as for vehicle sharing, vehicle rental, taxi ride service, and so forth. The operator can be an enterprise, such as a business organization (e.g., a rental company, a taxi company, a vehicle sharing management company, etc.). In other examples, the operator can be an individual that owns or otherwise manages the vehicle <NUM>.

The operator system <NUM> can be implemented as a computer or an arrangement of multiple computers. The operator system <NUM> can be a server system such as a web server system, a cloud server system, and so forth. In further examples, the operator system <NUM> can be implemented as a mobile computing device (or an arrangement of multiple mobile computing devices).

A "user device" can refer to any electronic device that can be used by a user. Examples of user devices include any or some combination of the following: a desktop computer, a notebook computer, a tablet computer, a smartphone, a wearable device (e.g., a smart watch, smart eyeglasses, a head-mounted device), a game appliance, a computer of a vehicle, and so forth.

The vehicle <NUM>, the user device <NUM>, and the operator system <NUM> are able to communicate over a network <NUM>. For example, the network <NUM> can include a public network such as the Internet. Alternatively, the network <NUM> can include a private network such as a local area network (LAN), a wide area network (WAN), and so forth.

The user device <NUM> and the vehicle <NUM> can establish communications using a wireless link <NUM>. In some examples, the wireless link <NUM> can include a short-range wireless link, such as a Bluetooth wireless link, an NFC link, or other types of short-range wireless links. Alternatively, the wireless link <NUM> can include a WI-FI wireless link according to the IEEE <NUM> and Wi-Fi Alliance standards, in which case the vehicle <NUM> includes a WLAN AP to communicate over the WI-FI wireless link with the user device <NUM>.

The user device <NUM> includes a secure connection establishment module <NUM> that is able to obtain information that can be used to establish a secure connection over the wireless link <NUM> with a secure connection establishment module <NUM> of the vehicle <NUM>.

As used here, the term "module" can refer to a hardware processing circuit, such as any or some combination of the following: a microprocessor, a core of a multi-core microprocessor, a microcontroller, a programmable integrated circuit device, a programmable gate array, or another hardware processing circuit. In other examples, a "module" can refer to a combination of a hardware processing circuit and machine-readable instructions executable on the hardware processing circuit.

The information that can be obtained to establish the secure connection between the user device <NUM> and the vehicle <NUM> includes bootstrapping information and configuration information.

Bootstrapping information can be obtained by the user device <NUM> to perform authentication of the user device <NUM> with respect to the vehicle <NUM>. Once authentication is performed, configuration can be performed to allow the user device <NUM> to obtain configuration information (including a credential and other information) that is used by the user device <NUM> to establish the secure connection over the wireless link <NUM> with the vehicle <NUM>.

Once the secure connection is established between the user device <NUM> and the vehicle <NUM>, a service access module <NUM> of the user device <NUM> is able to access an application <NUM> in the vehicle <NUM>. The application <NUM> includes a program executable in the vehicle <NUM> to provide a service that is to be accessed by the service access module <NUM>. The service access module <NUM> can be in the form of an application, a web browser, and so forth, that is executable in the user device <NUM>.

The user device <NUM> additionally includes an information revoking module <NUM> that is able to revoke information used by the user device <NUM> to access the service of the vehicle <NUM> once the service access is complete. Service access is complete if the user device <NUM> performs an action (or fails to perform an action) that indicates that access of the service is no longer being performed or is terminated. For example, a user of the user device <NUM> may close the service access module <NUM> that is used to access the vehicle service. As another example, the user at the user device <NUM> may log out from an account that is used to access the vehicle service. As yet another example, the user at the user device <NUM> may activate a control item (such as in a user interface) indicating termination of access of the service. In further examples, the user may be idle for some specified time duration, which indicates that access of the vehicle service should time out.

The vehicle <NUM> similarly includes an information revoking module <NUM> that revokes information used by the user device <NUM> to access the vehicle service, in response to completion of the service access.

In accordance with some examples of the present disclosure, authentication and configuration (collectively referred to as "provisioning") of the user device <NUM> to allow for access of a service of the vehicle <NUM> can be according to the Wi-Fi Alliance Device Provisioning Protocol (DPP). DPP provides a provisioning scheme in which a dedicated network infrastructure for use in provisioning of wireless devices does not have to be implemented. By using DPP, use of certain servers, such as an Authentication, Authorization, and Accounting (AAA) server, a policy database, a web server, and/or other network infrastructure entities can be avoided.

DPP uses a configurator device to provision other devices (enrollee devices) within a network, where the enrollee devices can include stations (STAs) such as mobile devices or other user devices, access points (APs), peer-to-peer (P2P) client devices, P2P Group Owners (GO)s, P2P services client devices, Neighbor Awareness Networking (NAN) devices, or other types of devices. Any of a station, AP, or other device can also operate as a configurator device (referred to as a "DPP Configurator"). Devices that have yet to be configured by the DPP Configurator are called enrollee devices, and devices that have been configured by the DPP Configurator are called peers.

Generally, a "configurator device" can refer to any wireless device (e.g., a mobile device or an AP) in which an application or service is executed that is able to perform provisioning functionality. DPP operates between a pair of devices, where a first device takes on the role of configurator and the second device takes on the role of enrollee. The configurator device first authenticates the enrollee device, and then may provision the enrollee device. Provisioning includes the setup of new devices and the capability to provide a third party introduction for connectivity to other devices managed by the configurator device.

Both the configurator device and enrollee device generate public/private key pairs that are used to authenticate and establish a secure configuration channel. The secure configuration channel is then used to pass configuration information between the devices.

The enrollee device sends a set of attributions (e.g., requirements and associated parameters), and in response, the configurator device sends configuration information to the enrollee device. The configuration information can include credentials to obtain network access, and/or a configurator signing key. The configuration information can also include a list of configurator identities, a list of enrollees (in the case of a configurator), and so forth.

Although reference is made to provisioning techniques according to DPP, it is noted that in further examples, additional or alternative provisioning techniques can also be employed.

In the examples where DPP is used, a DPP Configurator can be included as part of either the operator system <NUM>, the vehicle <NUM>, or the user device <NUM>. For example, if a rental car company wants to provision a new car, then they may use a master DPP Configurator in a user device to initially set it up at the garage. The provisioning performed according to DPP with the DPP Configurator allows for a credential (or multiple credentials) to be created to allow a connection of the user device <NUM> to the vehicle <NUM>.

<FIG> is a message flow diagram in which a DPP Configurator <NUM> is part of the operator system <NUM>. As shown in <FIG>, the user device <NUM> performs a vehicle request interaction (at <NUM>) with the operator system <NUM> to allow a user of the user device <NUM> to obtain access of the vehicle <NUM>. For example, in a rental vehicle context, the interaction (<NUM>) can include an online reservation in which the user uses the user device <NUM> to access a website of the operator system <NUM> to make a reservation for the vehicle <NUM>. In a vehicle ridesharing context, the interaction (<NUM>) can be based on a user requesting a vehicle using an application of the user device <NUM> to hail a ride.

As part of the interaction (<NUM>), the user device <NUM> can be provided with location information of the vehicle <NUM>, such as a street address or other indication of the vehicle's location.

Once the user is granted access to the vehicle <NUM> in response to the interaction (<NUM>), the operator system <NUM> can provide (at <NUM>) service information to the vehicle at <NUM>, where the service information indicates the service(s) that (is) are available to the user device <NUM>. The service information can include any or some combination of the following: Bluetooth pairing information that enables the user device <NUM> to establish a Bluetooth connection with the vehicle <NUM>; information of the vehicle's navigation service; information of a feature of the vehicle <NUM> to access local information; information of the vehicle's multimedia service; information of a toll road access service; information of priority access to special traffic lanes (such as car pool lanes); information relating to electrical charging of the vehicle <NUM>; information enabling multi-device access; and so forth.

The service information <NUM> can also include the bootstrapping information for the user device <NUM>.

The user device <NUM> receives (at <NUM>) bootstrapping information. As explained below, the bootstrapping information can be obtained from any of various different sources. The bootstrapping information can be provided by the operator system <NUM>. Alternatively, the bootstrapping information can be acquired by the user device <NUM> by scanning, using a camera of the user device <NUM>, a specified code that includes the bootstrapping information. As yet another example, the bootstrapping information can be provided in a Bluetooth Low Energy (BLE) beacon transmitted using Bluetooth signals in the vehicle <NUM>, or provided in NFC signals. As a further example, the bootstrapping information can be received over a cable (such as a Universal Serial Bus or USB cable). In other examples, the bootstrapping information can be obtained from another source.

In specific examples, a multimedia service (such as streaming audio), or third party road tolling, may be authenticated via open authentication (OAUTH) or other methods to grant access via cloud services or third party servers. In such examples, the action of obtaining access to the vehicle <NUM> can result in simultaneous provisioning of bootstrapping information for WLAN connectivity, out of band Bluetooth pairing, and OAUTH token provisioning to third party servers.

Once the user enters the vehicle <NUM> or comes within a specified proximity of the vehicle <NUM>, using the bootstrapping information, the user device <NUM> can perform DPP configuration (at <NUM>) with the DPP Configurator <NUM> of the operator system <NUM>. The vehicle <NUM> can also perform DPP provisioning (at <NUM>) with the DPP Configurator <NUM> of the operator system <NUM>.

Within a specified proximity can be one of two things. It can be bounded by the distance the radio can operate and thus be the radius of the particular wireless technology. Or it can be a specifically measured distance using technology such as received signal strength (RSSI) or round trip time (RTT). Examples of proximity protocols include Bluetooth PXP profile, IEEE <NUM> Fine Timing Measurement, Wi-Fi Alliance Location and Wi-Fi Aware Ranging.

The DPP provisioning of the user device <NUM> includes authenticating the user device <NUM> and providing configuration information to the user device <NUM>.

In some examples, the configuration information can include a DPP configuration object provided to the user device <NUM> by the DPP Configurator <NUM>. For example, the configuration information can include WI-FI credentials, Bluetooth pairing information, an expiration time of a DPP Connector, and so forth. The configuration information can also include the DPP Connector, which includes information identifying service(s) of the vehicle <NUM> accessible by the user device <NUM>. The DPP Connector can also include a credential useable to establish a secure connection for accessing the service(s) of the vehicle <NUM>.

The DPP provisioning of the vehicle <NUM> includes authenticating the vehicle <NUM> and providing configuration information to the vehicle <NUM>.

In examples according to <FIG>, the operator system <NUM> acts as a proxy for interaction between the user device <NUM> and the vehicle <NUM>. Trust in the operator system <NUM> allows the user to establish a secure connection with the vehicle <NUM>.

As a result of the DPP provisioning (<NUM> and <NUM>), the user device <NUM> establishes a secure connection (at <NUM>) with the vehicle <NUM>. Following establishment of the secure connection (at <NUM>), the user device <NUM> is able to access (at <NUM>) a service (or services) of the vehicle <NUM>.

Once the service access is complete (<NUM>), the information revoking module <NUM> of the user device <NUM> revokees (at <NUM>) service access information (e.g., including the configuration information) used by the user device <NUM> to access the service of the vehicle <NUM>. Similarly, the information revoking module <NUM> of the vehicle <NUM> can revoke (at <NUM>) the service access information used by the user device <NUM> to access the service of the vehicle <NUM>. In some examples, the information revoking modules <NUM> and <NUM> can interact over a secure connection to revoke the service access information. In other examples, an information revoking store <NUM> or coordination unit may exist within the operator system <NUM>, for tracking and auditing purposes. The information revoking store <NUM> communicates with the information revoking modules <NUM> and <NUM> through the network <NUM>.

In examples where the configuration information (including the DPP Connector, for example) has an expiry time, the user device <NUM> can be provided with an alert regarding when the service access is about to expire, so that the user should return the vehicle <NUM> or otherwise exit the vehicle <NUM> or stop using the vehicle's service(s). Alternatively, the user can be notified through a display device of the vehicle <NUM>, such as a display device of an infotainment system of the vehicle <NUM>.

Although reference is made to examples where user access of the vehicle <NUM> is temporary (e.g., taxi or ridesharing, vehicle rental, vehicle sharing, etc.), it is noted that techniques according to some implementations can be applied in a more permanent context where the user is intended to have permanent access of the vehicle <NUM>. For example, the user may be the owner of the vehicle <NUM>, and is granted the service access information to access the service(s) of the vehicle <NUM>. However, the vehicle <NUM> may be stolen or borrowed by another driver (e.g., a family member, a friend, etc.), in which case the service access information can be revoked while the user is not in possession of the vehicle <NUM>.

Additionally, in further examples, when the vehicle <NUM> crosses a border between different geographic regions (e.g., different states, provinces, or countries), new service access information can be provided to the user device <NUM> to access the service(s) of the vehicle <NUM>. The new service access information can be provided by a communications backhaul link to the use device <NUM> such as cellular or another technology. Different geographic regions may use different service providers or operators in connection with the service(s) of the vehicle <NUM>. If new service access information is created when the vehicle <NUM> crosses into a given geographic region, the new service access information can be revoked once the vehicle <NUM> leaves the given geographic region.

While <FIG> depicts indirect provisioning of the user device <NUM> by the DPP Configurator <NUM> of the operator system <NUM>, <FIG> shows an alternative example in which a DPP Configurator <NUM> of the vehicle <NUM> can perform direct provisioning of the user device <NUM> that is to access a service of the vehicle <NUM>.

In <FIG>, it is assumed that the vehicle <NUM> has network connectivity with the operator system <NUM> used to manage the service, and the operator system <NUM> has the ability to push provisioning information (such as the bootstrapping information and policy information for the device session to the vehicle).

As shown in <FIG>, the user device <NUM> performs a vehicle request interaction (at <NUM>) with the operator system <NUM> to allow a user of the user device <NUM> to obtain access of the vehicle <NUM> (a process similar to the interaction <NUM> of <FIG>). Once the user is granted access to the vehicle <NUM> in response to the interaction (<NUM>), the operator system <NUM> can provide (at <NUM>) service information to the vehicle at <NUM>, where the service information indicates the service(s) that (is) are available to the user device <NUM>.

The user device <NUM> further receives (at <NUM>) bootstrapping information from one of multiple sources (QR code, email, text message, web link etc.).

Once the user is able to access the vehicle <NUM> (such as by entering the vehicle <NUM> or coming within a specified proximity of the vehicle <NUM>), the user device <NUM> can perform, using the bootstrapping information, DPP provisioning (at <NUM>) with the DPP Configurator <NUM> of the vehicle <NUM>. The DPP provisioning includes authenticating the user device <NUM> and providing configuration information to the user device <NUM>.

The remaining tasks <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> are similar to corresponding tasks <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> of <FIG>.

Bootstrapping information (received by the user device <NUM> at <NUM> in <FIG> or <NUM> in <FIG>) can be obtained in any of various different ways in the following different contexts. In examples where the vehicle <NUM> is a taxi or other vehicle that can be requested for transportation of the user, the bootstrapping information is obtained in the following manner.

A specified code, such a QR code or barcode (that includes a unique bootstrapping key) can be provided for each ride. The specified code can be associated with a payment transaction process. A display screen in the vehicle <NUM> (e.g., a taxi or other vehicle) can display the specified code that can be scanned by a camera of the user device <NUM>. For example, an application on the user device <NUM> can control the capture of the displayed specified code.

In other examples, obtaining the bootstrapping information can be performed ahead of the ride, such as by accessing a website or other source (e.g., when the user performs the vehicle request interaction <NUM> or <NUM> to request access of the vehicle <NUM>).

In other examples, an existing authenticated connection between the user device <NUM> and the vehicle <NUM> can be used.

In this example, the service access information can be revoked once the ride is over and payment has been made for the ride.

In examples where the vehicle <NUM> is a rental vehicle or a shared vehicle that can be rented by a user, the bootstrapping information can be obtained in the following ways. The user can be provided with a specified code (e.g., QR code or barcode) including the bootstrapping information with a time expiry set to the end of rental period at booking time or through the vehicle <NUM> directly. The specified code can be provided to the user device <NUM> at the time of making the vehicle reservation, or alternatively, the specified code can be displayed by a display device of the vehicle <NUM>, and can be scanned by a camera of the user device <NUM>.

In some examples, the specified code can include a token that uniquely identifies a rental agreement governing the rental of the vehicle <NUM>.

The specified code can be used to provision multiple user devices, if enabled by the vehicle rental company.

Also, in some examples, at the time of reserving the vehicle <NUM>, the vehicle rental information provided to the user device <NUM> can include Bluetooth pairing information to allow the user device <NUM> to establish a Bluetooth connection with the vehicle <NUM>, or alternatively, the vehicle rental information can include Bluetooth bootstrapping information to establish a WI-FI connection with the vehicle <NUM>.

DPP provisioning of the user device <NUM> can be performed using a vehicle rental application on the user device <NUM>, or based on access of a website by the user device <NUM>.

In this example, the service access information can be revoked at the end of the rental period.

In some examples, bootstrapping involves the user device <NUM> obtaining a public key of a peer device (e.g., the vehicle <NUM>) that will be used for DPP authentication. Bootstrapping information can be encoded as a uniform resource identifier (URI). Bootstrapping mechanisms utilize any or some combination of the following technologies according to the DPP specification to obtain bootstrapping information: scanning a QR code, static or dynamic NFC communication of the bootstrapping information, BLE communication of the bootstrapping information, exchanging a shared secret, and so forth.

A typical example of the Augmented Backus-Naur Form (ABNF) for the bootstrapping information is as follows:
<IMG>
<IMG>.

The bootstrapping information can be enforced in either one-way authentication (the user device <NUM> authenticates the vehicle <NUM>) or mutual authentication (bi-directional authentication between the user device <NUM> and the vehicle <NUM>). If mutual authentication is used, the user device <NUM> can exchange bootstrapping keys over the secure connection with the operator system <NUM>.

If the operator system <NUM> instead of the vehicle <NUM> includes a DPP Configurator (such as in <FIG>), the bootstrapping information can contain a domain name or IP address. The following are examples of bootstrapping information that include the domain name carrental. com:
DPP:I:www. com/config. htm;K:MDkwEwYHKoZIzjOCAQ YIKoZIzj0DAQcDIgADM2206avxHJaHXgLMkq/24e0rsrfMP9K1Tm8gx +ovP0I=;;.

Alternatively, the bootstrapping information encoding can be modified to add a domain name:
DPP:D:carrental. com; K:MDkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDIgADM2206avxHJaHXgLMk q/24e0rsrfMP9KlTm8gx+ovP0I=;;.

As a further example, the bootstrapping information can be encoded as a URL:
https://www. com/configurator?proto=dpp&key= MDkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDIgADM2206avxHJaHXgLMkq/ 24e0rsrfMP9K1Tm8gx+ovP0I=;;.

An example of a bootstrapping URI that provides channel information is as follows:
DPP:C:<NUM>/<NUM>,<NUM>/<NUM>;K:MDkwEwYHKoZIzjOCAQYIKoZIzj0DAQcDIgA DM22 <NUM>6avxHJaHXgLMkq/<NUM>4e0rsrfMP9KlTm8gx+ovP0I = ;;.

The following provides further details regarding DPP provisioning (authentication and configuration) according to some examples.

The user device <NUM> and a DPP Configurator (either in the operator system <NUM> or the vehicle <NUM>) can perform DPP authentication using bootstrapping information. Once a secure connection is established by the user device <NUM>, the user device <NUM> sends a DPP Configuration Request frame to the DPP Configurator (<NUM> in <FIG> or <NUM> in <FIG>). If the user device <NUM> obtained a token during the vehicle request interaction (<NUM> in <FIG> or <NUM> in <FIG>), the user device <NUM> would transmit the token to the DPP Configurator in order to obtain the correct configuration. For Bluetooth pairing, the DPP Configuration Request frame can contain a public key that can be used to perform out-of-band Bluetooth pairing.

In some examples, DPP Configuration Request attributes are encoded using JavaScript Object Notation (JSON) and can have the following form:
{
"name": "My Device",
"wi-fi_tech":"infra",
"netRole":"sta",
"myVehicleReservationToken":"AlB2C3D4E5F6G7H8"
"myDeviceBTPairingKey:"HDkwEwYHKoZIzj0CXYYIKoZIzj0DA
QcDIgMSN2206avxHJaHXgLMkq/24e0rsrfMP9K1Tm8gx+ovP0I="
}.

Upon successful reception of the DPP Configuration Request frame, the DPP Configurator can construct a configuration response containing a DPP Configuration Object and a DPP Connector. The DPP Configuration object and DPP Connector are encoded using JSON, for example.

An example DPP Configuration object is set forth below:
{
"wi-fi_tech":"infra",
"discovery":
{
"ssid":"car1138wifi"
},
"cred":
{
"akm":"dpp",
"signedConnector":
"eyJ0eXAiOiJkcHBDb24iLCJraWQiOiJrTWNIZ0RCUG1OWlZha0FzQlpP
ek9vQ3N2UWprcl9uRUFwOXVGLUVEbVZFIiwiYWxnIjoiRVMyNTYifQ. ey
Jncm91cHMiOlt7Imdyb3VwSWQiOiJob211IiwibmV0Um9sZSI6InN0YSJ
9LHsiZ3JvdXBJZCI6ImNvdHRhZ2UiLCJuZXRSb2xlIjoic3RhIn1dLCJk
ZXZpY2VzIjpbeyJkZXZpY2VJZCI6IkcxWWFKWUliQTkwMjlvY1AzQlZDZ
zVrajN5R0hXWWkzTTJoSnF5T21jeFEiLCJuZXRSb2xlIjoic3RhIn0sey
JkZXZpY2VJZCI6IkF6cy1rc2VmaWVuMUNBOEVZSWxpdTZONnZHclRhM3F
vd3FDSEtLOEl1MFkiLCJuZXRSb2xlIjoic3RhIn1dLCJuZXRBY2Nlc3NL
ZXkiOnsia3R5IjoiRUMiLCJjcnYiOiJQLTI1NiIsIngiOiI4QTF0LUVPV
WxMajBZNm5rUU9GMyltNDgxdm9TMlFaLUlaemlSLUtMTHVJIiwieSI6Im
NnYnEzOUJ5SnpWYkZ0WVdUVEVUcE52QnBBUnVuRXRUMlNzaTg0eEFubDA
iLCJraWQiOiJCUkRNX1JOemlfeGtRcTdGTORlbXpoc2VXQkUzM21ybTAz
OHdZUjdZOWE4InOsImV4cGlyeSI6IjIwMTktMDEtMzFUMjI6MDA6MDArM
DI6MDAifQ. ED65oTLhYTFAw9E5mgDESELSIS3AyRapVWfHT2y7r19big8
uY8ge0BiXUSQj0ew5KUuNR3qb9d8kFuMQr6RTfA",
"csign":
{
"kty":"EC",
"crv":"P-<NUM>",
"x":"MKBCTNIcKUSDiillySs3526iDZ8AiTo7Tu6KPAqv7D4",
"y":"4Et16SRW2YiLUrN5vfvVHuhp7x8PxltmWWlbbM4IFyM",
"kid": "kMcegDBPmNZVakAsBZOzOoCsvQjkr_nEAp9uF-EDmVE"
},
},
"bt_pair_key":"ERkeroDFE989FEAk2j0CXYYIKoZIzj0DAQcDI
gMSN2206avxHJaHXgLMkq/24e0rsrfMP9K1Tm8gx+ovP0I=L"
}.

An example DPP connector object can be as follows:
{
"groups":
[
{"groupId":"preferred","netRole":"sta"},
{"serviceId":"nav"},
{"serviceId":"spotify"},
{"serviceId":"VoWiFi"},
{"serviceId":"netAccess"}
],
"netAccessKey":
{
"kty": "EC",
"crv":"P-<NUM>",
"x":"8A1t-EOUlLj0Y6nkQOF3-m481voS3QZ-IZziR-
KLLuI",
"y":"cgbq39ByJzVbFtYWTTETpNvBpARunEtT2Ssi84xAnl0"
},
"expiry":"<NUM>-<NUM>-31T22:<NUM>:<NUM>+<NUM>:<NUM>"
}.

In the foregoing, the various Serviceld fields of the DPP Connector identify respective services. The netAccessKey is a credential that can be used to set up a secure connection between the user device <NUM> and the vehicle <NUM> to access the service(s) of the vehicle <NUM>.

The user device <NUM> uses the service information (the Serviceld fields) in the DPP Connector to establish service connectivity to applications running on the vehicle <NUM>. The user device <NUM> can exchange personal preference information and application configuration information with the vehicle <NUM>.

In further examples, if the service provided by the application of the vehicle <NUM> uses a credential (such as a credential to access a media content application), then this application credential can be used to proxy connectivity to the vehicle <NUM> to establish the secure connection between the user device <NUM> and the vehicle <NUM>.

As explained above, upon service access completion, service access information (including the credential and other information with respect to the access of the vehicle's service) is revoked at both the user device <NUM> and the vehicle <NUM>.

The revocation of the service access information can be triggered in a few ways. For example, the service access information can be revoked in response to expiry of the DPP Connector, based on the expiry time provisioned in the DPP Connector.

As another example, the service access information can be revoked by the operator system <NUM> in response to the user triggering the end of access of the vehicle <NUM> (such as the end of the rental of the vehicle <NUM> based on return of the vehicle <NUM>, end of the ride of the vehicle <NUM> based on payment for the ride, etc.).

As a further example, the service access information can be revoked by the vehicle <NUM> in response to the user triggering the end of access of the vehicle <NUM>.

As yet another example, the service access information can be revoked by the vehicle <NUM> in response to the user moving out of coverage (e.g., WI-FI or Bluetooth coverage) of the vehicle <NUM> after a trigger that the vehicle access is complete. The trigger condition can be a result of the user interacting with an application running on the user device <NUM>, or interacting with the vehicle's user interface.

As another example, the service access information can be revoked by sending a message or information element (e.g., a de-authentication or disassociation message or information element) with a respective reason code. The value of the reason code may cause the user device <NUM> or vehicle <NUM> to delete the service access information from memory and never try connecting again.

The revocation of the service access information can include deleting the service access information or otherwise indicating that the service access information is invalid. Indicating that the service access information is invalid can be accomplished by flagging the service access information stored in memory as inactive (or invalid), such that the service access information cannot be used. This allows the user device <NUM> or vehicle <NUM> to respond to failed authentications with different response codes for credentials or other service access information that do not exist yet versus credentials or other service access information that did exist but are now expired or invalid for some other reason.

The following gives details on how DPP is adapted to perform revocation of service access information.

The following describes revocation of the service access information on the vehicle <NUM> (or more specifically, on the AP of the vehicle <NUM> in examples where the vehicle <NUM> provides a WLAN). In such examples, the operator system <NUM> establishes a secure connection with the vehicle <NUM> to delete the DPP Connector, for example. A configuration key allows the DPP Configurator to re-establish a connection to the vehicle <NUM>. The configuration key can be a new key derived as a result of successful DPP authentication, or existing keys such as the netAccessKey from the enrollee device (the vehicle <NUM>) and the configurator signing key from the DPP Configurator. The DPP Configurator in the operator system <NUM> uses its configuration key to authenticate itself to the vehicle <NUM>. The vehicle uses its configuration key to authenticate itself to the DPP Configurator in the operator system <NUM> (i.e., the DPP Configurator would have to store vehicle's enrollee netAccessKey). The revocation process is as follows. The DPP Configurator establishes a secure connection with the vehicle <NUM>. The DPP Configurator securely sends a Configuration Request frame to the vehicle <NUM> containing revocation information. The revocation information includes information used to revoke the service access information. For example, the revocation information can include: Wi-Fi, Bluetooth, or NFC pairing credentials; application access information including any credential information associated with application access; browser cache or search information; search parameters for navigation or any information associated with navigating a route; and so forth.

The following describes revocation of the service access information on the user device <NUM>. The user device <NUM> establishes a connection to either the DPP Configurator in the operator system <NUM> or the DPP Configurator in the vehicle <NUM> using a configuration key. The revocation process is as follows. The DPP Configurator establishes a secure connection with the user device <NUM>. The DPP Configurator securely sends a Configuration Request frame to the user device <NUM> containing revocation information.

Within the user device <NUM>, an application (such as a ridesharing application or vehicle rental application) may interact with a WLAN manager (running on the user device <NUM>) to remove the service access information that the application had previously created. For security and privacy reasons, the operating system (OS) of the user device <NUM> does not allow the application to change or delete other service access information that was not previously created by the particular application.

The revocation of a service access information causes the user device <NUM> (such as an application or an operating system in the vehicle <NUM>) to query the information revoking store <NUM> in the operator system <NUM> over another connection (e.g., a cellular connection different from the vehicle's wireless network). In response to this query, the user device <NUM> can verify if the revocation was due to the normal completion of access of the vehicle <NUM>, or for some other purpose (e.g., the vehicle <NUM> was reported stolen). This information may be used to determine whether the service access information should be stored and reused later on, or deleted. The information in the query response may also be displayed to the user.

<FIG> is a block diagram of an electronic device or system <NUM> according to some examples. The electronic device or system <NUM> can include any of the user device <NUM>, the vehicle <NUM>, or the operator system <NUM> discussed above.

The electronic device or system <NUM> includes a processor <NUM> (or multiple processors). A processor can include a microprocessor, a core of a multi-core microprocessor, a microcontroller, a programmable integrated circuit, a programmable gate array, or another hardware processing circuit.

The electronic device or system <NUM> further includes a non-transitory machine-readable or computer-readable storage medium <NUM> that stores machine-readable instructions executable on the processor <NUM>. Machine-readable instructions executable on a processor can refer to the instructions executable on a single processor or the instructions executable on multiple processors. The electronic device or system further includes a communication interface <NUM> for communication over a communication medium with external entities.

The machine-readable instructions include service access and information revocation instructions <NUM> that can allow a user device to access a vehicle's service, and to revoke service access information upon completion of the service access.

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 disk (CD) or a digital video disk (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 (e.g., a cloud) from which machine-readable instructions can be downloaded over a network for execution.

Claim 1:
A method comprising:
receiving (<NUM>, <NUM>), by an electronic device (<NUM>), configuration information relating to network connectivity with a network of a vehicle (<NUM>), the configuration information including a credential, the electronic device being an enrollee device, wherein an enrollee device is a device which has not been configured by a configurator device yet;
establishing (<NUM>, <NUM>), by the electronic device (<NUM>) using the configuration information, a connection with the network of the vehicle (<NUM>) to access a service; and
revoking (<NUM>, <NUM>), at the electronic device (<NUM>), the credential in response to a termination of the access of the service, wherein revoking (<NUM>, <NUM>) the credential comprises:
establishing, using a configuration key, another connection between the electronic device (<NUM>) and the configurator device (<NUM>, <NUM>), the another connection different from the network of the vehicle (<NUM>); and
receiving revocation information from the configurator device (<NUM>, <NUM>) via the another connection, the revocation information for revoking the credential.