WO2018026807A1

WO2018026807A1 - Managing automotive vehicle premium lane access

Info

Publication number: WO2018026807A1
Application number: PCT/US2017/044887
Authority: WO
Inventors: Niranjan Suri; Rita LENZI; Enrico Casini; Samian Kaur; Patrick Thomas IGOE
Original assignee: Pcms Holdings, Inc.
Priority date: 2016-08-02
Filing date: 2017-08-01
Publication date: 2018-02-08

Abstract

Methods, apparatus, and systems for managing premium traffic lane usage with autonomous and non-autonomous vehicles using capabilities and/or blockchains.

Description

MANAGING AUTOMOTIVE VEHICLE PREMIUM LANE ACCESS

FIELD

[0001] The present invention relates to the field of wireless communications and, more particularly, to methods, apparatus, and systems for realizing secure communications for managing access to and use of premium lanes on roadways.

BACKGROUND

[0002] As the number of vehicles on the roads today continues to increase, traffic congestion is becoming more common.

[0003] Consequently, some government entities and other road management entities have designated special lanes or even entire roadways (hereinafter express lanes) that are reserved for use by only certain drivers, e.g., drivers that have paid for the privilege of driving on a particular roadway or lane. Such express lanes thus require some form of gating and management to assure that only those drivers authorized to use such express lanes are, in fact, using those lanes. Current solutions include additional infrastructure to separate express lanes from free lanes, such as toll gates with workers or automated systems that allow only authorized drivers and/or vehicles onto such express lanes and collect any necessary fees for the use thereof. In theory, certain drivers (e.g., those willing to pay an extra fee) may be granted additional privileges in connection with express lanes, such as the right to drive at a higher rate of speed or to preempt other drivers (e.g., cause another vehicle to pull over into another lane to allow the driver to pass).

[004] There are no efficient ways to delegate (or grant) additional abilities to a certain vehicle from a supervising authority in a transparent way to the drivers.

[0005] Dedicated short range communications (DSRC) already includes the concepts of priority and preemption of drivers on a road in order for them to let an emergency vehicle pass. This approach operates only at the network level and does not include an authentication scheme, i.e., they do not provide a mechanism by which a priority vehicle establishes to the network or to the other vehicles on the roadway that it, in fact, has the authority to preempt the other drivers/vehicles. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] A more detailed understanding may be had from the Detailed Description below, given by way of example in conjunction with drawings appended hereto. Figures in such drawings, like the detailed description, are examples. As such, the Figures and the detailed description are not to be considered limiting, and other equally effective examples are possible and likely.

[0007] Furthermore, like reference numerals in the figures indicate like elements, and wherein:

[0008] FIG. 1A is a system diagram illustrating an example communications system in which one or more disclosed embodiments may be implemented;

[0009] FIG. 1 B is a system diagram illustrating an example wireless transmit/receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A according to an embodiment;

[0010] FIG. 1 C is a system diagram illustrating an example radio access network and another example core network that may be used within the communications system illustrated in FIG. 1A according to an embodiment;

[0011] FIG. 1 D is a system diagram illustrating another example radio access network and another example core network that may be used within the communications system illustrated in FIG. 1A according to an embodiment;

[0012] FIG. 1 E is a system diagram illustrating a further example radio access network and a further example core network that may be used within the communications system illustrated in FIG. 1A according to an embodiment;

[0013] FIG. 2 is a system level signal diagram showing a procedure in accordance with a service provider mode of operation in accordance with an exemplary embodiment;

[0014] FIG. 3 is a flow diagram showing additional processing in accordance with an embodiment for handling situations in which a target vehicle cannot or does not yield to a client vehicle;

[0015] FIG. 4 shows the structure of a capability created by the service

owner/provider in accordance with an exemplary embodiment;

[0016] FIG. 5 shows the structure of a capability when it is presented by a client device to the target device in accordance with an exemplary embodiment; [0017] FIG. 6 illustrates a signal flow diagram relating to key exchange using Butterfly keys according to an exemplary embodiment;

[0018] FIG. 7 is a diagram showing signal flow in accordance with an exemplary embodiment using third party witness vehicle verification of transactions;

[0019] FIG. 8 is a diagram showing the structure of various token messages sent between nodes of the network in the embodiment of FIG. 7 in accordance with an exemplary embodiment;

[0020] FIG. 9 is a diagram showing signal flow performed with respect to each witness vehicle in the embodiment of FIG. 7 in accordance with an exemplary embodiment;

[0021] FIG. 10 is a flow chart illustrating signal flow in association with transaction verification by witness vehicles in accordance with an exemplary embodiment;

[0022] FIG. 1 1 is a signal flow diagram illustrating exemplary signal flow in accordance with an exemplary embodiment that does not rely on the use of witness vehicles;

[0023] FIG. 12 is a diagram showing the structure of various token messages sent between nodes of the network in the embodiment of FIG. 12 in accordance with an exemplary embodiment;

[0024] FIG. 13 is a flow diagram illustrating process flow for a vehicle asserting a capability against another vehicle to determine if the other vehicle responded

appropriately; and

[0025] FIG. 14 is a flow diagram illustrating process flow for a vehicle receiving a capability assertion from another vehicle to verify whether it responded appropriately.

DETAILED DESCRIPTION

[0026] A detailed description of illustrative embodiments may now be described with reference to the figures. However, while the present invention may be described in connection with representative embodiments, it is not limited thereto and it is to be understood that other embodiments may be used or modifications and additions may be made to the described embodiments for performing the same function of the present invention without deviating therefrom.

[0027] Although the representative embodiments are generally shown hereafter using wireless network architectures, any number of different network architectures may be used including networks with wired components and/or wireless components, for example.

EXAMPLE NETWORKS FOR IMPLEMENTATION OF THE INVENTION

[0028] FIG. 1A is a diagram illustrating an example communications system 100 which may form part of an overall communication system in connection with which one or more aspects of the present invention may be implemented. The communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The

communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), and the like.

[0029] As shown in FIG. 1A, the communications system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 103/104/105, a core network 106/107/109, a public switched telephone network (PSTN) 108, the Internet 1 10, and other networks 1 12, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a "station" and/or a "STA", may be configured to transmit and/or receive wireless signals and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, consumer electronics, and the like. Any of the WTRUs 102a, 102b, 102c and 102d may be interchangeably referred to as a UE.

[0030] The communications systems 100 may also include a base station 1 14a and/or a base station 1 14b. Each of the base stations 1 14a, 1 14b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the core network 106/107/109, the Internet 1 10, and/or the other networks 1 12. By way of example, the base stations 1 14a, 1 14b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a site controller, an access point (AP), a wireless router, and the like. While the base stations 1 14a, 1 14b are each depicted as a single element, it will be appreciated that the base stations 1 14a, 1 14b may include any number of interconnected base stations and/or network elements.

[0031] The base station 1 14a may be part of the RAN 103/104/105, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 1 14a and/or the base station 1 14b may be configured to transmit and/or receive wireless signals within a particular geographic region, which may be referred to as a cell (not shown). The cell may further be divided into cell sectors. For example, the cell associated with the base station 1 14a may be divided into three sectors. Thus, in one embodiment, the base station 1 14a may include three transceivers, i.e., one for each sector of the cell. In another embodiment, the base station 1 14a may employ multiple- input multiple output (MIMO) technology and may utilize multiple transceivers for each sector of the cell.

[0032] The base stations 1 14a, 1 14b may communicate with one or more of the

WTRUs 102a, 102b, 102c, 102d over an air interface 1 15/1 16/1 17, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 1 15/1 16/1 17 may be

established using any suitable radio access technology (RAT).

[0033] More specifically, as noted above, the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 1 14a in the RAN 103/104/105 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 1 15/1 16/1 17 using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink (DL) Packet Access (HSDPA) and/or High-Speed UL Packet Access (HSUPA).

[0034] In another embodiment, the base station 1 14a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 1 15/1 16/1 17 using Long Term Evolution (LTE) and/or LTE-Advanced (LTE-A).

[0035] In other embodiments, the base station 1 14a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.1 1 (i.e., Wireless Fidelity (WiFi), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)),

CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

[0036] The base station 1 14b in FIG. 1A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, and the like. In one embodiment, the base station 1 14b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.1 1 to establish a wireless local area network (WLAN). In another embodiment, the base station 1 14b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 1 14b and the WTRUs 102c, 102d may utilize a cellular- based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or femtocell. As shown in FIG. 1A, the base station 1 14b may have a direct connection to the Internet 1 10. Thus, the base station 1 14b may not be required to access the Internet 1 10 via the core network 106/107/109.

[0037] The RAN 103/104/105 may be in communication with the core network

106/107/109, which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. For example, the core network 106/107/109 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and/or perform high-level security functions, such as user authentication. Although not shown in FIG. 1 A, it will be appreciated that the RAN 103/104/105 and/or the core network 106/107/109 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 103/104/105 or a different RAT. For example, in addition to being connected to the RAN 103/104/105, which may be utilizing an E-UTRA radio technology, the core network 106/107/109 may also be in communication with another RAN (not shown) employing a GSM, UMTS, CDMA 2000, WiMAX, or WiFi radio technology.

[0038] The core network 106/107/109 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 1 10, and/or the other networks 1 12. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 1 10 may include a global system of interconnected computer networks and devices that use common

communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and/or the internet protocol (IP) in the TCP/IP internet protocol suite. The networks 1 12 may include wired and/or wireless communications networks owned and/or operated by other service providers. For example, the networks 1 12 may include another core network connected to one or more RANs, which may employ the same RAT as the RAN 103/104/105 or a different RAT.

[0039] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links). For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with the base station 1 14a, which may employ a cellular-based radio technology, and with the base station 1 14b, which may employ an IEEE 802 radio technology.

[0040] FIG. 1 B is a system diagram illustrating an example WTRU 102. As shown in FIG. 1 B, the WTRU 102 may include a processor 1 18, a transceiver 120, a

transmit/receive element 122, a speaker/microphone 124, a keypad 126, a

display/touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and/or other peripherals 138, among others. It will be appreciated that the WTRU 102 may include any subcombination of the foregoing elements while remaining consistent with an embodiment.

[0041] The processor 1 18 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 1 18 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 1 18 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122. While FIG. 1 B depicts the processor 1 18 and the transceiver 120 as separate components, it will be appreciated that the processor 1 18 and the transceiver 120 may be integrated together in an electronic package or chip.

[0042] The transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 1 14a) over the air interface 1 15/1 16/1 17. For example, in one embodiment, the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals. In another

embodiment, the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit/receive element 122 may be configured to transmit and/or receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.

[0043] Although the transmit/receive element 122 is depicted in FIG. 1 B as a single element, the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 1 15/1 16/1 17. [0044] The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 122 and to demodulate the signals that are received by the transmit/receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.1 1 , for example.

[0045] The processor 1 18 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the

display/touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light- emitting diode (OLED) display unit). The processor 1 18 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128. In addition, the processor 1 18 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132. The non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 1 18 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0046] The processor 1 18 may receive power from the power source 134, and may be configured to distribute and/or control the power to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li- ion), etc.), solar cells, fuel cells, and the like.

[0047] The processor 1 18 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 1 15/1 16/1 17 from a base station (e.g., base stations 1 14a, 1 14b) and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location

information by way of any suitable location-determination method while remaining consistent with an embodiment.

[0048] The processor 1 18 may further be coupled to other peripherals 138, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs and/or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like. In a case where the peripherals 138 includes one or more sensors, the sensors may be one or more of a gyroscope, an

accelerometer; an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geolocation sensor; an altimeter, a light sensor, a touch sensor, a

magnetometer, a barometer, a gesture sensor, and/or a humidity sensor.

[0049] The WTRU 102 may include a full duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for both the UL (e.g., for transmission) and downlink (e.g., for reception) may be concurrent and/or simultaneous. The full duplex radio may include an interference management unit 139 to reduce and or substantially eliminate self-interference via either hardware (e.g., a choke) or signal processing via a processor (e.g., a separate processor (not shown) or via processor 1 18).

[0050] FIG. 1 C is a system diagram illustrating the RAN 103 and the core network 106 according to another exemplary network that may form part of an overall communication system in in connection with which one or more aspects of the present invention may be implemented. As noted above, the RAN 103 may employ a UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 1 15. The RAN 103 may also be in communication with the core network 106. As shown in FIG. 1 C, the RAN 103 may include Node-Bs 140a, 140b, 140c, which may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 1 15. The Node-Bs 140a, 140b, 140c may each be associated with a particular cell (not shown) within the RAN 103. The RAN 103 may also include RNCs 142a, 142b. It will be appreciated that the RAN 103 may include any number of Node-Bs and RNCs while remaining consistent with an embodiment.

[0051] As shown in FIG. 1 C, the Node-Bs 140a, 140b may be in communication with the RNC 142a. Additionally, the Node-B 140c may be in communication with the RNC 142b. The Node-Bs 140a, 140b, 140c may communicate with the respective RNCs 142a, 142b via an lub interface. The RNCs 142a, 142b may be in communication with one another via an lur interface. Each of the RNCs 142a, 142b may be configured to control the respective Node-Bs 140a, 140b, 140c to which it is connected. In addition, each of the RNCs 142a, 142b may be configured to carry out or support other functionality, such as outer loop power control, load control, admission control, packet scheduling, handover control, macrodiversity, security functions, data encryption, and the like.

[0052] The core network 106 shown in FIG. 1 C may include a media gateway (MGW) 144, a mobile switching center (MSC) 146, a serving GPRS support node (SGSN) 148, and/or a gateway GPRS support node (GGSN) 150. While each of the foregoing elements are depicted as part of the core network 106, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

[0053] The RNC 142a in the RAN 103 may be connected to the MSC 146 in the core network 106 via an luCS interface. The MSC 146 may be connected to the MGW 144. The MSC 146 and the MGW 144 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate

communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices.

[0054] The RNC 142a in the RAN 103 may also be connected to the SGSN 148 in the core network 106 via an luPS interface. The SGSN 148 may be connected to the GGSN 150. The SGSN 148 and the GGSN 150 may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 1 10, to facilitate communications between and the WTRUs 102a, 102b, 102c and IP-enabled devices. [0055] As noted above, the core network 106 may also be connected to the other networks 1 12, which may include other wired and/or wireless networks that are owned and/or operated by other service providers.

[0056] FIG. 1 D is a system diagram illustrating the RAN 104 and the core network 107 according to another exemplary network that may form part of an overall communication system in in connection with which one or more aspects of the present invention may be implemented. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 1 16. The RAN 104 may also be in communication with the core network 107.

[0057] The RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 1 16. In one embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and/or receive wireless signals from, the WTRU 102a.

[0058] Each of the eNode-Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and/or DL, and the like. As shown in FIG. 1 D, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface.

[0059] The core network 107 shown in FIG. 1 D may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. While each of the foregoing elements are depicted as part of the core network 107, it will be appreciated that any of these elements may be owned and/or operated by an entity other than the core network operator.

[0060] The MME 162 may be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation/deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and/or WCDMA.

[0061] The serving gateway 164 may be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via the S1 interface. The serving gateway 164 may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102c. The serving gateway 164 may perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.

[0062] The serving gateway 164 may be connected to the PDN gateway 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 1 10, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0063] The core network 107 may facilitate communications with other networks. For example, the core network 107 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the core network 107 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the core network 107 and the PSTN 108. In addition, the core network 107 may provide the WTRUs 102a, 102b, 102c with access to the other networks 1 12, which may include other wired and/or wireless networks that are owned and/or operated by other service providers.

[0064] FIG. 1 E is a system diagram illustrating the RAN 105 and the core network 109 according to another exemplary network that may form part of an overall communication system in in connection with which one or more aspects of the present invention may be implemented. The RAN 105 may be an access service network (ASN) that employs IEEE 802.16 radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 1 17. As will be further discussed below, the communication links between the different functional entities of the WTRUs 102a, 102b, 102c, the RAN 105, and the core network 109 may be defined as reference points. [0065] As shown in FIG. 1 E, the RAN 105 may include base stations 180a, 180b, 180c, and an ASN gateway 182, though it will be appreciated that the RAN 105 may include any number of base stations and ASN gateways while remaining consistent with an embodiment. The base stations 180a, 180b, 180c may each be associated with a particular cell (not shown) in the RAN 105 and may each include one or more

transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 1 17. In one embodiment, the base stations 180a, 180b, 180c may implement MIMO technology. The base station 180a, for example, may use multiple antennas to transmit wireless signals to, and/or receive wireless signals from, the WTRU 102a. The base stations 180a, 180b, 180c may also provide mobility management functions, such as handoff triggering, tunnel establishment, radio resource management, traffic

classification, quality of service (QoS) policy enforcement, and the like. The ASN gateway 182 may serve as a traffic aggregation point and may be responsible for paging, caching of subscriber profiles, routing to the core network 109, and the like.

[0066] The air interface 1 17 between the WTRUs 102a, 102b, 102c and the RAN 105 may be defined as an R1 reference point that implements the IEEE 802.16

specification. In addition, each of the WTRUs 102a, 102b, 102c may establish a logical interface (not shown) with the core network 109. The logical interface between the WTRUs 102a, 102b, 102c and the core network 109 may be defined as an R2 reference point, which may be used for authentication, authorization, IP host configuration management, and/or mobility management.

[0067] The communication link between each of the base stations 180a, 180b, 180c may be defined as an R8 reference point that includes protocols for facilitating WTRU handovers and the transfer of data between base stations. The communication link between the base stations 180a, 180b, 180c and the ASN gateway 182 may be defined as an R6 reference point. The R6 reference point may include protocols for facilitating mobility management based on mobility events associated with each of the WTRUs 102a, 102b, 100c.

[0068] As shown in FIG. 1 E, the RAN 105 may be connected to the core network 109. The communication link between the RAN 105 and the core network 109 may be defined as an R3 reference point that includes protocols for facilitating data transfer and mobility management capabilities, for example. The core network 109 may include a mobile IP home agent (MIP-HA) 184, an authentication, authorization, accounting (AAA) server 186, and a gateway 188. While each of the foregoing elements are depicted as part of the core network 109, it will be appreciated that any of these elements may be owned and/or operated by an entity other than the core network operator.

[0069] The MIP-HA 184 may be responsible for IP address management, and may enable the WTRUs 102a, 102b, 102c to roam between different ASNs and/or different core networks. The MIP-HA 184 may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 1 10, to facilitate

communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The AAA server 186 may be responsible for user authentication and for supporting user services. The gateway 188 may facilitate interworking with other networks. For example, the gateway 188 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. The gateway 188 may provide the WTRUs 102a, 102b, 102c with access to the other networks 1 12, which may include other wired and/or wireless networks that are owned and/or operated by other service providers.

[0070] Although not shown in FIG. 1 E, it will be appreciated that the RAN 105 may be connected to other ASNs, other RANS (e.g., RANs 103 and/or 104) and/or the core network 109 may be connected to other core networks (e.g., core network 106 and/or 107. The communication link between the RAN 105 and the other ASNs may be defined as an R4 reference point, which may include protocols for coordinating the mobility of the WTRUs 102a, 102b, 102c between the RAN 105 and the other ASNs. The communication link between the core network 109 and the other core networks may be defined as an R5 reference, which may include protocols for facilitating interworking between home core networks and visited core networks.

[0071] Although the WTRU is described in FIGS. 1A-1 E as a wireless terminal, it is contemplated that in certain representative embodiments that such a terminal may use (e.g., temporarily or permanently) wired communication interfaces with the

communication network. [0072] In representative embodiments, the other network 1 12 may be a WLAN.

[0073] A WLAN in Infrastructure Basic Service Set (BSS) mode may have an Access Point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have an access or an interface to a Distribution System (DS) or another type of wired/wireless network that carries traffic in to and/or out of the BSS. Traffic to STAs that originates from outside the BSS may arrive through the AP and may be delivered to the STAs. Traffic originating from STAs to destinations outside the BSS may be sent to the AP to be delivered to respective destinations. Traffic between STAs within the BSS may be sent through the AP, for example, where the source STA may send traffic to the AP and the AP may deliver the traffic to the destination STA. The traffic between STAs within a BSS may be considered and/or referred to as peer-to-peer traffic. The peer-to- peer traffic may be sent between (e.g., directly between) the source and destination STAs with a direct link setup (DLS). In certain representative embodiments, the DLS may use an 802.1 1 e DLS or an 802.1 1 z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and the STAs (e.g., all of the STAs) within or using the IBSS may communicate directly with each other. The IBSS mode of communication may sometimes be referred to herein as an "ad-hoc" mode of communication.

[0074] When using the 802.1 1 ac infrastructure mode of operation or a similar mode of operations, the AP may transmit a beacon on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., 20 MHz wide bandwidth) or a dynamically set width via signaling. The primary channel may be the operating channel of the BSS and may be used by the STAs to establish a connection with the AP. In certain representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) may be implemented, for example in in 802.1 1 systems. For CSMA/CA, the STAs (e.g., every STA), including the AP, may sense the primary channel. If the primary channel is sensed/detected and/or determined to be busy by a particular STA, the particular STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS. [0075] High Throughput (HT) STAs may use a 40 MHz wide channel for communication, for example, via a combination of the primary 20 MHz channel with an adjacent 20 MHz channel to form a 40 MHz wide contiguous channel.

[0076]Very High Throughput (VHT) STAs may support 20MHz, 40 MHz, 80 MHz, and/or 160 MHz wide channels. The 40 MHz, and/or 80 MHz, channels may be formed by combining contiguous 20 MHz channels. A 160 MHz channel may be formed by combining 8 contiguous 20 MHz channels, or by combining two non-contiguous 80 MHz channels, which may be referred to as an 80+80 configuration. For the 80+80 configuration, the data, after channel encoding, may be passed through a segment parser that may divide the data into two streams. Inverse Fast Fourier Transform (IFFT) processing, and time domain processing, may be done on each stream separately. The streams may be mapped on to the two 80 MHz channels, and the data may be transmitted by a transmitting STA. At the receiver of the receiving STA, the above described operation for the 80+80 configuration may be reversed, and the combined data may be sent to the Medium Access Control (MAC).

[0077] Sub 1 GHz modes of operation are supported by 802.1 1 af and 802.1 1 ah. The channel operating bandwidths, and carriers, are reduced in 802.1 1 af and 802.1 1 ah relative to those used in 802.1 1 η, and 802.1 1 ac. 802.1 1 af supports 5 MHz, 10 MHz and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.1 1 ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.1 1 ah may support Meter Type Control/Machine-Type Communications, such as MTC devices in a macro coverage area. MTC devices may have certain capabilities, for example, limited capabilities including support for (e.g., only support for) certain and/or limited

bandwidths. The MTC devices may include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).

[0078] WLAN systems, which may support multiple channels, and channel bandwidths, such as 802.1 1 n, 802.1 1 ac, 802.1 1 af, and 802.1 1 ah, include a channel which may be designated as the primary channel. The primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and/or limited by a STA, from among all STAs in operating in a BSS, which supports the smallest bandwidth operating mode. In the example of 802.1 1 ah, the primary channel may be 1 MHz wide for STAs (e.g., MTC type devices) that support (e.g. , only support) a 1 MHz mode, even if the AP, and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and/or other channel bandwidth operating modes. Carrier sensing and/or Network Allocation Vector (NAV) settings may depend on the status of the primary channel. If the primary channel is busy, for example, due to a STA (which supports only a 1 MHz operating mode), transmitting to the AP, the entire available frequency bands may be considered busy even though a majority of the frequency bands remains idle and may be available.

[0079] In the United States, the available frequency bands, which may be used by 802.1 1 ah, are from 902 MHz to 928 MHz. In Korea, the available frequency bands are from 917.5 MHz to 923.5 MHz. In Japan, the available frequency bands are from 916.5 MHz to 927.5 MHz. The total bandwidth available for 802.1 1 ah is 6 MHz to 26 MHz depending on the country code.

EXPRESS LANE MANAGEMENT METHODS AND APPARATUS

Computer Capabilities

[0080] The notion of capabilities for purposes of access control in computing has been around since the early days of computer systems such as the IBM System 38.

"Capabilities" in the context of computer access control generally refers to the right of a computer program to access a resource (e.g., a file), and may also include the type of access (e.g., read only or read/write). Early work on capabilities centered on evaluating their security guarantees, especially in the context of the Department of Defense.

Reviews of the early work relating to capabilities is presented in [1 ] and [2], which provide a taxonomy of different capability-based security models that can be created by choosing various alternatives for creation, propagation, and checking of capabilities.

[0081] The Amoeba distributed operating system [3] represents a recent application of capabilities. In Amoeba, network-based servers provide all the traditional functionalities of an operating system, including memory, file, and directory services. Amoeba uses capabilities exclusively as the naming and security mechanism. When a process creates or is otherwise provided access to a resource, Amoeba returns a capability to the process. When accessing the resources, the process simply presents its capability, which includes the server and resource identifiers. Each capability also includes a set of rights granted by the capability. One process may transfer a capability to another process. A process can also create a new capability with reduced access rights before transferring the capability to another process.

[0082] Also important is the notion of delegation certificates and their use in managing rights in distributed settings [4]. Delegation certificates do not have any notion of user identity, but are strictly key-based. They allow the owner of a key to create and sign a certificate that can be distributed to the holder of another key. The certificate can include explicit rights that are granted to the owner (which must be a subset of the rights owned by the original entity) as well as a validity period. A delegated certificate can be further delegated to a third party and this process can be repeated to form a chain of delegation certificates. The authors of [4] have applied delegation certificates in the context of a distributed service architecture where owners of services can offer access to service providers who, in-turn, can offer those services to other service providers or service users.

[0083] Akenti [5] is another certificate-based approach for controlling access to distributed resources. That system is focused on creating attribute certificates that specify policies on how resources may be used, and is targeted to environments where the resource owners are distinct from the service provider (or administrative domain). Central to this approach is the Akenti policy engine, which is responsible for determining the access rights of a user based on the certificates in place.

[0084] As previously alluded to, capabilities may be cryptographically secure tokens that allow a user holding a capability to access the corresponding information or service. Presenting the capability to a service or resource provider allows the user (or, rather, the device or process acting on behalf of the user) to request a service. Capabilities may be transferred from one user to another, and may entail specific access privileges Different capabilities can be created to grant different levels of access. They may also be revoked in order to deny access in the future. Finally, they allow the address or identity of the target entity being accessed to be encoded, thereby increasing privacy and security. [0085] In the premium lanes scenario, capabilities may be applied according to the following exemplary procedure.

1 . Driver A (driving vehicle A) selects a priority level, which determines the toll for the vehicle;

2. The toll road owner or operator (infrastructure) generates a capability for

driver A;

3. When vehicle A approaches another vehicle (vehicle B), the following protocol will be performed;

a. A presents its capability to B;

b. B validates the capability via an infrastructure node, as will be discussed in further detail below;

c. If the priority level of A is higher than that of B, vehicle B should move

over, allowing vehicle A to pass.

[0086] In alternative embodiments (e.g., the embodiment of FIG. 7, as will be discussed in more detail below), the procedure may be modified to be a peer-to-peer protocol that does not require validation capability within the infrastructure (e.g., eliminating step 3b above).

[0087] These schemes allow for important additional features in premium lane

management. For instance, they allow for automatic expiration of specific capabilities assigned to a certain vehicle. Expiration allows the creation of a capability that is only valid for a specific duration (e.g., time, miles etc.). It also improves accuracy by explicitly providing a system that identifies, at any given time, those who are granted the capability to drive in a certain premium lane and those who are not. Furthermore, it reduced infrastructure costs by removing the necessity of building toll gates and hiring workers to operate them.

[0088]A capability may be cryptographically secure so that it cannot be tampered with. Furthermore, when a capability holder (client device) presents its capability credential for a service, the service provider should be able to verify its integrity in addition to identifying the rights granted by the capability itself.

[0089] Capabilities are created by a service owner/provider and may be used in at least two configurations, namely, a peer-to-peer mode and a service provider mode. [0090] FIG. 2 is a system level signal diagram showing a procedure in accordance with an exemplary service provider mode of operation. Specifically, when a driver 200 wants to join a premium lane service, the driver 200 selects a desired priority level (as represented by signal 21 1 ), which determines the toll for the vehicle. The vehicle (202) contacts a Service Access Infrastructure node (as represented by signal 213), which can be the toll infrastructure 204, that generates the capability. The infrastructure node 204 creates and sends the capability credential to vehicle A 202 (as shown by signal 215).

[0091] Then, when vehicle A 202 approaches another vehicle that it wishes to pass, e.g., vehicle B 206, vehicle A 202 presents its capability to vehicle B (as shown by signal 217), e.g., over the DSRC wireless infrastructure, in order to allow a comparison of their priorities so that a determination may be made as to who has the right of way.

[0092]Vehicle B 206 then validates A's capability with the Infrastructure node 204. More specifically, in a typical case, this would involve vehicle B first decrypting the signed certificate received from vehicle A using its private key to extract the certificate (as signed by the toll infrastructure 204). Then, vehicle B verifies the toll infrastructure's signature using the toll infrastructure's public key (typically a signature is a hash of the original data, e.g., the capability certificate, which hash has then been encrypted using the private key of the data originator, i.e., the toll infrastructure). This allows vehicle B to ensure that the capability certificate was issued by the toll infrastructure. However, the fact that the certificate originated at the toll infrastructure does not necessarily mean that it is still valid. Accordingly, vehicle B may then send a message (message 219) to the toll infrastructure asking the toll infrastructure node to confirm whether that capability is valid (e.g., has not expired, has not been used previously, or is not otherwise invalid).

[0093] The infrastructure returns a result (as shown by message 221 ). Assuming that the infrastructure validates A's capability credential to B, B compare its priority with A's priority and, if A has higher priority, B notifies its driver that he or she needs to yield to A (as represented by signal 223). Otherwise, vehicle B ignores the request. Note that, if B is an autonomous vehicle, the driver notification 223 may be omitted. [0094] The flow of FIG. 2 represents a simple case in which we assume that (1 ) traffic conditions allow B to safely yield to A and (2) B's driver actually does move to a different lane in order to let A pass.

[0095] FIG. 3 is a flow diagram showing additional processing for handling situations in which either or both of conditions (1 ) and (2) above may not be true. In such

embodiments, vehicles are equipped with sensors and can exploit V2V technologies in order to evaluate whether a given maneuver is dangerous or complied with. Such technology is essentially inherent in autonomous drive vehicles.

[0096] In this exemplary embodiment, in order to avoid A's driver paying for a service that s/he cannot use, each capability may be assigned with a given number of tokens. Each token may represent a right that can be exercised in connection with a single target device, e.g., the right of A to pass one single vehicle. In one embodiment, every time a vehicle asserts and uses a capability, its number of tokens is decremented.

When this number reaches 0, the capability expires.

[0097] As shown at 31 1 , B evaluates whether it is safe to move to the right to allow A to pass. If B evaluates that moving to the right lane is not possible, it will simply ignore the request from A by not moving or by not notifying its driver and the process ends (327). A may be free to attempt to assert the privilege again at a later time.

[0098] If B can safely move to the right, flow instead proceeds to step 313, where it is determined if B is an autonomous vehicle. If so, flow proceeds to step 315, in which vehicle B is controlled to cause it to move over. If, on the other hand, vehicle B is not an autonomous vehicle, flow instead proceeds to step 317, in which vehicle B notifies its driver of the need to move over (such as through an audible and/or visual cue to the driver). Next, at step 319, vehicle A determines whether vehicle B has, in fact, moved over (using, e.g., cameras and/or other autonomous vehicle apparatus and functionality in the vehicle). If the vehicle has moved over, whether autonomously (step 315) or by action of the driver (step 317), flow proceeds to step 321 , in which vehicle A decrements its token count to indicate that it has used the capability (the right to pass another vehicle with lower priority). Next, at step 323, vehicle A determines if all of its tokens have been used. If so, flow proceeds to step 325, wherein A's capability is marked as expired or otherwise revoked. If, on the other hand, A still has at least one token, no further action needs to be taken, and the process ends at 327.

[0099] Returning to decision step 319, if, on the other hand, it is determined that the driver has not moved over, flow instead proceeds to step 329, in which vehicle B notifies the toll infrastructure accordingly and the toll infrastructure may assign B a penalty. Next, in step 333, the toll infrastructure determines if the number of penalties assigned to B exceeds a maximum value. If so, flow proceeds to step 335, in which B's capability is revoked (or B is otherwise reprimanded) and the process ends at 327.

[00100] On the other hand, if vehicle B has not exceeded its limit of penalties, flow instead proceeds directly from decision step 331 to the end 327.

[00101] It should be noted that, in some embodiments, vehicle A also may perform substantially the same steps as described above for vehicle B in terms of verifying that vehicle B performed as required (e.g., steps like 319 and 329). In fact, either or both vehicles may perform the verification and report the results to the infrastructure node.

[00102] FIG. 4 shows an exemplary data structure of a capability created by the service owner/provider. As shown at 401 , in a simple embodiment, the capability may comprise four basic pieces of information: (1 ) a client device ID that uniquely identifies the client device that is being granted the capability (e.g., vehicle A in the example of FIG. 2), (2) the rights that the capability is granting to the holder (e.g., the right to cause another vehicle of lower priority to move over to allow passing and possibly a number of tokens for exercising the right), (3) any restrictions applicable to the capability (e.g., a priority level, a number of times it may be used per hour, etc.), and (4) any expiration time of the capability. Referring now to 403 in FIG. 4, this information is signed with the private key of the service owner/provider, creating a signed capability 403.

[00103] In order to protect the data in the capability from being examined by third party interceptors, the signed capability may also be encrypted with the public key of the client device (Vehicle A), which results in an encrypted capability 405.

[00104] Finally, the encrypted capability may also be annotated with a description or other meta information for use by the service application in the client device, as shown at 407, before being transmitted to vehicle A. For example, a client application may be an app provided by a pharmacy that allows the user to pick up a prescription for medication at a drug store. In such an application, the metadata may comprise, a time window for picking up the medication, the name of the medication, the location of the pharmacy, etc.

[00105] Vehicle A can decrypt the capability using its private key corresponding to its public key with which the infrastructure encrypted the capability. Vehicle A also can authenticate that the capability came from the proper infrastructure provider by combining the received capability and signature (signed using the private key of the infrastructure provider) with the infrastructure provider's public key (previously obtained by Vehicle A).

[00106] Referring now to FIG. 5, before vehicle A presents the capability 403 to the target device (vehicle B in the example of FIG. 2), vehicle A signs the capability 403 using its own private key to generate a signed capability 503. After it has identified the target vehicle (e.g., vehicle B) and requested and obtained a copy of the target vehicle's public key from the target vehicle (not shown), vehicle A may encrypt its signed capability 503 using the public key of the target device (vehicle B) to create an encrypted and signed capability 505 to transmit to vehicle B. This encryption helps avoid a scenario where a rogue person sniffs the message and pretends to have the same capability.

[00107] As noted above in connection with FIG. 4, vehicle A also may annotate the encrypted and signed capability with a description or other meta information for use by the service application in the target device (Vehicle B) to produce an annotated, encrypted, and signed capability 507, before being transmitted to vehicle B. Again, merely as an example, the service application in the target vehicle may be Android Auto or Apple CarPlay, either of which may allow the car to drive the user to the drug store and/or inform the user that the drug store is currently closed.

[00108] Private keys and public keys for all of the infrastructure owner/provider, the target device (vehicle B) and the client device (vehicle A) may be obtained exploiting the concept of Butterfly Keys presented by the Crash Avoidance Metrics Partnership (CAMP) [6]. FIG. 6 is a signal flow diagram illustrating exemplary signal flow for obtaining Butterfly keys in accordance with an embodiment. [00109] This authentication system provides for the devices (including the service owner/provider) to generate a seed (also called "caterpillar" key pair) and an expansion function. The device, e.g., the toll infrastructure node 601 , sends a message 610 containing the caterpillar seed key pair to a Registration Authority (RA) 603. Then, the (RA) runs the expansion function on the caterpillar public key to generate a plurality of "cocoon" public keys. These cocoon public keys are not correlated, and the expansion function allows for the creation of an arbitrary number of as many cocoon keys as the system needs.

[00110] Subsequently to the generation phase, the RA 603 sends a message 612 to a Certification Authority (CA) 605 submitting the cocoon keys to the CA for

certification.

[00111] The CA randomizes each cocoon public key so that the RA is unable to recognize them, thereby creating a certificate. The certificate contains the resulting "butterfly" keys. The CA 605 then returns the certificate (Cert) and the private randomization values (c) to the devices. In the illustrated exemplary embodiment, the CA sends the data to the RA as shown at 614, and the RA forwards the data on to the device, as shown at 616. In other embodiments, the CA may have direct connectivity to the other nodes of the network and can send the data directly to the devices.

[00112] Each device 601 is the only one that knows its private key, while the public key cannot be correlated by any entity. Also, the whole process guarantees low computational burden on the devices. CAMP allows also for efficient revocation of a certificate after it has been issued.

[00113] One of the key advantages of capabilities is the ability for the creator to limit their duration of validity in terms of any one or more of geographical area, time, and number of tokens granted.

[00114] This allows a capability to be disseminated with the prior knowledge that the client device is limited as to the duration of use. Expiration can be disabled by not specifying a duration. Granting a capability for a limited duration is a very effective mechanism to model any interaction that requires temporary access to a resource. For the service owner (e.g., the toll road operator), this is a powerful mechanism to enforce security. The capability renewal mechanism allows the client device (e.g., vehicle A) to obtain a (new) capability that is similar to the original, but with a new expiration.

Obtaining a renewal requires an interaction with the service owner, thereby bringing the Service Owner back into the loop in making the decision to provide an extension.

[00115] Consider, for example, the chance for the client device (e.g., vehicle A) to request a daily or monthly fast pass for a given segment of road. The capability will be created with a flag restricting its use only to that specific road segment and with the specific expiration date.

[00116] Revocation is the notion of canceling a capability before the capability expires normally (based on the expiration field or the geographical restriction in the capability). Revocation may be desirable if the circumstances under which a capability was granted change and the service owner needs to cancel the capability. Revocation can be handled by maintaining a list of revoked capabilities. When a capability needs to be revoked, the service owner may add the capability to the revocation list. When a capability is presented for access, the revocation list is checked before access is granted. Note that the capability should be maintained on the revocation list until the capability expires. Therefore, having capabilities that have an expiration is preferable since, otherwise, the revocation list would have to be maintained indefinitely.

Blockchain

[00117] An alternative embodiment for providing preemption to drivers on premium lanes is by transferring coins or tokens from a client device to a target device on a decentralized peer-to-peer network through a blockchain approach. This embodiment works on a decentralized peer-to-peer network and allowed entities (e.g., drivers or vehicles) to transfer coins or tokens in exchange for services. Reference may be had to https://en.wikipedia.org/wiki/Blockchain_(database) or "Blockchain Revolution: How the Technology Behind Bitcoin Is Changing Money, Business, and the World", D. Tapscott, A. Tapscott, Penguin, Canada (2016) for an explanation of blockchain theory and operation, and the following discussion will assume familiarity with the basics of blockchain theory and operation.

[00118] In such an approach, transactions of tokens may be maintained in a distributed database, also known as a blockchain. The transactions created by client devices are the content that is stored in the blockchain. In this embodiment, a transaction is created any time a client device with a certain number of tokens (e.g., the ability to drive a specific number of miles in the premium lane, the number of available preemption bonuses, etc.) wants to use one or more of the tokens relative to a target device. This may be for the purpose of taking advantage of a right of preemption to pass, as in the examples described above. However, it could also be for the purpose of transferring its premium miles (or other privilege) to another driver or vehicle. In either case, the service owner implementing the blockchain is responsible for defining a valid transaction. During the transfer of tokens between the client device and the target device, the transaction may be digitally signed with SHA-256 encryption using a private key or seed, which prevents third parties from tampering with it. All confirmed transactions are embedded in the blockchain, and specific records called blocks are the ultimate confirmation of when and in what sequence the transactions entered the system.

[00119] According to one embodiment, the transfer of tokens through the blockchain occurs in three phases:

[00120] Transaction: The software on the client device (vehicle A) checks whether the driver of vehicle A has a sufficient balance and then creates a payment order, which we call a transaction. This transaction is composed of three pieces of information: (1 ) the amount of tokens to spend, (2) the recipient, and (3) a signature. The client device is connected to other participants in the network, that we shall simply call network members. The client device passes the transaction to all of them to which it has connectivity, which, in turn, pass it on to all other network members to which they have connectivity. Hence, within a few seconds, every member of the network has received notification of the client device's "payment" order. Each and every participant checks whether the listed "tokens" exist, and whether the signatory is the owner (as may be determined from reviewing the preexisting state of the blockchain that is maintained at every node of the network).

[00121] Block Creation: The transaction implies that it is clear and verifiable that the client device has the necessary tokens. The client device cannot pay the target device if it is not acknowledged by all the members of the network that the client device has the sum of tokens necessary for the transaction (e.g., to purchase the miles or the preemption attempts). At this stage, the client device payment is only a promise because it is still unconfirmed. In order to change that unconfirmed status, some network nodes, which are known as miners, work on confirming these transactions. Miners typically are dedicated nodes of the network for performing the miner functions within the network (e.g., a miner server farm). The miners grab all the unconfirmed transactions in the network and try to pack them into a set, called a block. The miners attempt to organize the block to meet the requirements of a proper blockchain. When a miner's set does not fit the requirements, the miner reshuffles the transactions into a new ordered block and tries again. Eventually, one of the miners creates a set having the required properties: the resultant block. Generally, transactions can refer only to tokens that have already been created. Thus, each block has a fixed position, that is, each block references its direct predecessor, e.g., block 42 says that block 41 preceded it. In turn, block 41 names block 40 as his predecessor, and so forth, until block 2 points at the first block, the genesis block.

[00122] Confirmation: Once the correct block is created, just as with the transactions before, the members of the network send this block to all their connections, who, in turn, forward it to their connections. Every node checks the work (to confirm that the block follows the rules) and, when satisfied, applies the included transactions to their own ledger. Then the transactions get executed and the tokens that were used by the client device get invalidated. As noted above, in other embodiments, tokens may be treated more like a currency. That is, vehicle A may "pay" vehicle B for the right to pass it. In such embodiments, then, rather than invalidating vehicle A's tokens, those tokens may be transferred from vehicle A's ledger to vehicle B's ledger (like currency).

[00123] In either type of embodiment, the client device's transaction (and all the others) are now confirmed.

[00124] A classic blockchain approach such as just described (e.g., Bitcoin) has two potential shortcomings, namely, the time needed to build a block (commonly more than 10 minutes) and (2) the number of nodes needed to acknowledge the creation of a block. [00125] Both of these issues may be problematic in a scenario with many cars driving at different speeds, at variable distances between each other, and most likely taking different forks in the road, creating therefore a partition in the peer-to-peer network. Most of these issues are potentially solved by Ethereum [7], which is one of the most promising "Bitcoin 2.0" projects, a decentralized platform that runs "smart contracts" and enables developers to program their version of blockchain, enabling developers to program and automate transactions, trigger sophisticated commercial exchanges, and eliminate the potential for disputes. Smart contracts are a set of programs and protocols to automate the enforcement of a transaction. Ethereum has a current creation block time of 12 seconds and its blockchain can be programmed to reduce the number of members of the network that have to acknowledge the creation of the block.

[00126] While these contracts can be implemented in various languages, they are ultimately compiled into bytecode for the Ethereum Virtual Machine (EVM) before being deployed to the blockchain. The authors of the Ethereum project claim that the EVM provides state updates that can be written in a Turing complete scripting language. Like many other Bitcoin projects, the platform provides a cryptocurrency (called "ether") used to pay for computational services on the Ethereum network. Ether is currently mined by proof-of-work, while the average creation time for a block is around 12 seconds, which is a great improvement over the 10 minutes wait of classic Bitcoin.

[00127] The availability of the ether cryptocurrency is useful because Ethereum uses a mechanism called gas to limit contracts that might take a long time to run, charging a certain amount of ether per computation. Generic computation on the EVM is expensive because every contract is run on every node, resulting in the consensus of the output. The usage of the ether currency to pay for runs discourages developers to keep the Ethereum network busy for unnecessary computations, helping to maintain a natural equilibrium on the blockchain. While the creation time for a block is much shorter than Bitcoin, the main requirement of having a global network of nodes acknowledging the creation of the block remains a major issue.

[00128] When a block is created and confirmed, all members of the peer-to-peer network need to be notified and the record of all the transactions is held inside the longest blockchain. Therefore, if the number of members is relatively small, it is impossible to protect the peer-to-peer network from attacks coming from a larger and more powerful group of nodes.

[00129] In the premium lane scenario, a solution may be applied as follows. The driver of vehicle A buys a given amount of tokens from the toll infrastructure that will allow him to preempt other drivers on the premium lane. When vehicle A approaches another vehicle, vehicle B, the following protocol will be realized:

A creates a transaction;

A requests the transaction to be signed by N witnesses;

A presents the transaction to B;

B creates a transaction receipt;

B requests the transaction receipt to be signed by P witnesses (wherein P is an integer);

B presents the transaction receipt to A;

B moves over to let A pass.

[00130] In order to verify that both vehicles behaved properly per the transaction, a further group of witnesses may detect whether A and B behaved correctly, and may release a receipt after a given amount of time. This receipt can be shown to the toll infrastructure in case of a dispute between A and B to solve the conflict.

[00131] The peer-to-peer nature of this embodiment allows improvement in the costs for premium lanes by removing the necessity of building toll gates and hiring workers. The mechanism of witnesses for the transactions exchange overcomes the security issues that a pure Blockchain implementation would bring to a vehicular network.

[00132] FIG. 7 is a diagram showing exemplary signal flow in accordance with such an embodiment.

[00133] Let us assume vehicle A (the client device) 703 has requested (714) and received (716) a given number of tokens (or coins) from the toll infrastructure 701 that allow preemption of other drivers on the premium lane. Let us also assume that A wants to use one of them to pass vehicle B (the target device) 705. [00134] The structure of the message 716 from the toll infrastructure containing the tokens is shown in the top line 801 of FIG. 8. The token IDs may be originally encrypted with A's public key to avoid malicious vehicles from intercepting them and claiming them as theirs. They also may be signed by the toll infrastructure to allow vehicle A to know that they came from the proper source.

[00135] Vehicle A decrypts the tokens (and authenticates the source) and creates a transaction message 718, the structure of which is shown at 803 of FIG. 8.

Transaction message 803 contains: (1 ) an ID composed of the token(s) to spend encrypted with B's public key, (2) the target device's ID, (3) the client device's ID, and (4) a timestamp. Collectively, these four pieces of information are herein termed a transaction ID. The message 718 further comprises (5) the message type, which, in this case, corresponds to "Transaction Creation"; (6) the segment of the road where this transaction will apply; (7) a transaction state (discussed later and which is left blank at this point); (8) the toll infrastructure's signature (which vehicle A received in message 716 as part of data structure 801 ); and (9) vehicle A's signature.

[00136] In this exemplary embodiment, there is only one type of token, namely, one that grants the right to pass another vehicle. However, if there are multiple types of privileges or capabilities that can be represented by tokens, then another field of data (not shown) may be added to 803 specifying the capability that is granted by the token.

[00137] Referring back to FIG. 7, vehicle A broadcasts this transaction message 718 to the surrounding vehicles (including vehicle B). In a blockchain type embodiment, this message would correspond to the "transaction" mentioned above, and would be broadcast and rebroadcast throughout the network as described above until all network nodes received a copy.

[00138] Vehicle B waits to receive at least P (wherein P is an integer) signed transaction receipts 720 from the surrounding vehicles (collectively shown at 707 in FIG. 7), which represents the witnesses for the transaction. After that, B considers the transaction valid and moves to the right to let vehicle A overtake him, such as described in connection with any of the previous embodiments.

[00139] The message 720 that each witness sends is shown in the bottom line 805 of FIG. 8. It substantially contains a copy of the original transaction 803 (message 718) signed with the witness's signature. The Transaction State field is still left blank.

However, the message type field is changed to "Transaction Receipt".

[00140] Subsequently, when it is convenient for them, each witness 707 sends a message 722 to the Central Authority (CA), represented by the toll infrastructure 701 , registering the transaction. Message 722 may be similar in structure to message 720.

[00141] In a blockchain embodiment, this message would correspond to the "confirmation" mentioned above and, as noted above, would be broadcast and rebroadcast until all nodes of the network (not just the P witness vehicles), including the toll infrastructure, received a copy of the blockchain.

[00142] The witnesses in this type of blockchain embodiment are the equivalents of miners, and they should be authenticated with the CA.

[00143] In a preferred embodiment, witness vehicles 707 are pre-authenticated by the Central Authority, and the CA considers any transaction registrations received by unauthenticated vehicles to be invalid. Accordingly, as shown near the top of FIG. 7, witness vehicles may request authentication from the toll infrastructure (message 710) and receive authentication credentials (message 712) from the toll infrastructure 701 . Similarly to miners, vehicles serve as witnesses to a transaction may receive a reward (message 724) for their service, e.g., a token (or portion of a token) that they can use on the premium lane. Thus, if the CA verifies the identities of the client and target devices, the identity of the witness, and the correctness of the token identifiers, a reward 724 can be sent in the form of a token (or portion of one).

[00144] When vehicle B moves to the right lane (or does not move to the right for legitimate reasons, such as the maneuver is not possible for safety reasons), vehicle B requests an additional receipt signed by another group of witnesses by sending a broadcast message to the surrounding vehicles. This may be done in accordance with the exemplary embodiment shown in the signal flow diagram of FIG. 9, for instance.

[00145] FIG. 9 is a diagram showing an exemplary signal flow for this process of having witness vehicles verify whether vehicle B reacted properly. First, vehicle B 905 sends a message 910 to each witness vehicle 907 requesting a receipt from each witness verifying that it moved over for vehicle A 903. Since this message does not contain tokens or other particularly sensitive information, it may or may not be encrypted and/or signed by vehicle B.

[00146] Each witness vehicle sends a transaction receipt message 912 to vehicle B reporting what it has determined with regard to the transaction (e.g., vehicle B properly moved over, vehicle B did not move over because of a safety hazard, or vehicle B did not move over without proper excuse). Each witness vehicle also creates and sends a message 914 to the CA 901 with message type equal to "Transaction State" and the Transaction State field indicating that it is a final report. Again, these messages 912 and 914 may or may not be encrypted or signed by vehicle B. The toll infrastructure and/or vehicle B may wish to verify that witness reports are coming from registered witness vehicles. Therefore, it may be desirable for the witness vehicles to at least sign these messages.

[00147] As discussed in connection with FIG. 7, the CA 901 may send a reward (message 916) to each witness. The reward may be encrypted and/or signed to protect it from being stolen and/or to allow the recipient to verify its authenticity, such as previously described in connection with the transmission of tokens or capabilities from the toll infrastructure to a vehicle in connection with previously described embodiments.

[00148] Furthermore, vehicle B also may forward a copy of its receipt for the transaction (message 918) to the CA 901 .

[00149] In case of a dispute between A and B (or even if B could not safely move), the CA has all the necessary information to solve the conflict, decide whether and who behaved improperly, and, if necessary, restore the tokens used by A in an incomplete transaction.

[00150] FIG. 10 is a flow chart illustrating an exemplary process that a witness vehicle may perform with regard to verifying a transaction as described in connection with FIG. 9. Every N/M seconds (see step 1001 ) up to a maximum on N seconds (see step 1002), the witness tries to determine the state of the transaction, where N is the maximum amount of time permitted to confirm the transaction and M is a number.

Specifically, the witness detects whether vehicle B is able to safely move to the right lane (step 1003). If the maneuver is not possible, the witness records it in a temporary report of the situation (step 1005) and returns to step 1001 to wait for N/M seconds to pass since the last loop through the repetitive flow. If the maneuver is possible, then the witness checks whether B actually did move to the right (step 1007). If B did not move over, the witness records that fact in its temporary report (step 1009) and returns to step 1001. If, on the other hand, B moved to the right, the witness checks whether B is also keeping its position in order to allow A to safely pass (step 101 1 ), and, if B does not keep its position, the witness records it in its temporary report (step 1013) and returns to step 1001 . If, on the other hand, B keeps its position sufficiently long for vehicle A to pass, the witness checks whether A overtakes B (step 1015). If A does not overtake B, the witness records that fact in its temporary report (step 1021 ) and returns to step 1001. If, on the other hand, A overtakes B, the witness records that fact (step 1017) in its temporary report. At that point, the transaction is complete (nothing further can happen in connection with the transaction). So the witness creates a final receipt (step 1019) and the process ends (step 1021 ).

[00151] If, on the other hand, it is determined in step 1002 that the maximum allowed time for confirming the transaction (N) is reached before the witness verifies the entire transaction, flow instead proceeds from step 1002 to step 1019 to create the final receipt with whatever information it has been able to verify. This receipt (whether it confirms the complete transaction or otherwise) is the receipt that the witness sends to vehicle B in message 912 in FIG. 9.

Further Alternate Embodiments

[00152] In other embodiments, a transaction may be verified using only assets in the two vehicles involved in the transaction. The features of this embodiment, however, also may be used in conjunction with those witness vehicle features discussed above in connection with FIGS. 9 and 10, for example, for additional verification of transactions.

[00153] Briefly, in this type of embodiment, when vehicle A approaches vehicle B, vehicle A creates a transaction to inform B about its right of preemption and presents the transaction to vehicle B. Vehicle B signs the transaction receipt and sends it to vehicle A. Then both vehicle A and vehicle B start an algorithm that periodically collects information from cameras, sensors, and GPS to determine/prove whether B responded correctly to the transaction request and that vehicle A overtook vehicle B. Whenever it is convenient, A and B each register a transaction receipt with the toll infrastructure specifying whether it was successful or not, and, if not successful, why it was not successful (e.g., B did not have room to move over safely or B improperly failed to move over). The toll infrastructure may take adequate punitive measures towards B if B did not behave correctly.

[00154] FIG. 1 1 is a signal flow diagram illustrating exemplary signal flow in accordance with such an embodiment. This embodiment assumes that all the vehicles are equipped with trusted sensors (e.g., camera or LiDAR, accelerometer, GPS, etc.) and that they can exploit V2V technologies to understand whether a given maneuver is dangerous. This, of course, would be true for autonomous vehicles.

[00155] As in the previously described embodiments, vehicle A 1 103 requests tokens from the toll infrastructure 1 101 (message 1 1 10) and receives tokens from the toll infrastructure (message 1 1 12). The structure of message 1 1 12 containing the tokens is shown at 1201 in FIG. 12. It is essentially the same as described above in connection with reference numeral 801 in FIG. 8.

[00156] When vehicle A wants to pass another vehicle (vehicle B), it creates a transaction and sends it to vehicle B (message 1 1 14). The structure of the transaction is shown in at 1203 in FIG. 12, and contains: (1 ) an ID composed of the amount of tokens to spend encrypted with B's public key, (2) the target device's ID, (3) the client device's ID, and (4) a timestamp. The message 1 1 14 may further comprise any one or more of (5) the message type, which corresponds, in this case, to "Transaction

Creation", (6) the segment of the road where this transaction will apply, (7) the toll infrastructure signature (i.e., it is signed by the toll infrastructure), and (8) vehicle A's signature (i.e., it is also signed by vehicle A). Note that this structure is similar to that illustrated in FIG. 8 at 803, but lacking a transaction state field.

[00157] Vehicle B verifies whether the transaction is valid and, if so, signs it and sends it back to A (message 1 1 16). Afterwards, if it is safe to do so, it moves to the right to let vehicle A overtake it. The message 1 1 16 that vehicle B sends as a receipt is shown in FIG. 12 at 1205. It contains the original transaction (1203), but with the message type field set to "Transaction Receipt", and B's signature. When A receives the receipt, it starts an algorithm to verify whether vehicle B responded appropriately, and, if that is not the case, to have evidence of it.

[00158] FIG. 13 is a flow diagram illustrating an exemplary embodiment for performing such verification. First, vehicle A creates a recorded state in step 1301 . An exemplary structure of such a recorded state is illustrated in FIG. 12 at index 0 within data structure 1207. It contains: (1 ) the current timestamp, (2) an algorithm step field set to 0; and (3) a proof field containing a geo-localized picture of the front of the vehicle to show the initial position of vehicle B.

[00159] Then, as represented by steps 1303 and 1305, every N/M seconds, vehicle A detects whether vehicle B is able to safely move to the right lane (step 1307). If the maneuver is not possible, flow proceeds to step 1309, in which A creates a recorded state containing: (1 ) the current timestamp, (2) the algorithm step field set to 1 ; (3) the proof field, which may, for example, contain an image or a LiDAR report showing the vehicles and the lanes on the right side of vehicle A, and flow returns to step 1303. The structure of this record is shown at index 1 within data structure 1207 in FIG. 12.

[00160] If, on the other hand, it is determined in step 1307 that the maneuver is possible, flow instead proceeds to step 131 1 , in which vehicle A uses its accelerometer to detect whether A changed its speed to overtake B. If not, flow proceeds to step 1313, in which vehicle A creates a recorded state containing: (1 ) the current timestamp; (2) the algorithm step field set to 2; and (3) the proof field containing an image or a LiDAR report showing the front and right side of A. If, alternately, it is determined in step 131 1 that A does detect that B was passed, vehicle A creates a recorded state similar to that discussed immediately above, except that the proof would indicate that vehicle A has passed vehicle B. Since detecting that vehicle A passed vehicle B would comprise the end of the transaction, vehicle A also produces the final reported states list (step 1317) and the process ends at 1319.

[00161] If time limit N is reached before vehicle A detects that it has passed vehicle B, then flow proceeds from step 1305 to 1317 to produce a final report indicating whatever state of affairs existed at the end of period N.

[00162] This final report constitutes the report that vehicle B sends to the toll infrastructure in message 1 1 18 of FIG. 1 1. [00163] FIG. 14 is a flow diagram illustrating a corresponding exemplary process performed by vehicle B to verify whether vehicle B has responded appropriately to the capability presented to it by vehicle A.

[00164] Specifically, at step 1401 , vehicle B creates a recorded state containing: (1 ) a current timestamp; (2) an algorithm step field set to 0; and (3) a proof field containing its GPS coordinates.

[00165] Then, as represented by steps 1403 and 1405, every N/M seconds, vehicle B detects whether it is able to safely move to the right lane (step 1407). If the maneuver is not possible, flow [proceeds to step 1409, in which vehicle B creates a recorded state containing: (1 ) the current timestamp; (2) the algorithm step field set to 1 (a 1 in this field essentially being indicative of the fact that vehicle B has been asked to allow vehicle A to pass); and (3) the proof field containing an image or a LiDAR report showing the vehicles and the lanes on the right side of B. Then flow returns to step 1403.

[00166] If, on the other hand, the maneuver is possible, flow proceeds to step 141 1 , in which the GPS system of vehicle B checks whether B has moved to the right. If not, flow proceeds to step 1413, in which vehicle B creates a recorded state containing: (1 ) the current timestamp; (2) the algorithm step field set to 2 (a 2 in this field essentially being indicative of the fact that vehicle B has failed to properly yield to vehicle A); and (3) the proof field containing the current GPS position of B. If, on the other hand, it is determined in step 141 1 that vehicle B moved to the right, flow proceeds to step 1415, in which the GPS in vehicle B checks whether vehicle B is keeping its position in order to allow A to safely pass. If it is determined in step 1415 that vehicle B did not keep its position, vehicle B creates a recorded state containing: (1 ) the current timestamp; (2) the algorithm step field set to 3 (a 3 in this field essentially being indicative of the fact that vehicle B has properly yielded to vehicle A); and (3) the proof field containing the current GPS position of B, and flow returns to step 1403.

[00167] If, instead it is determined in step 1415 that vehicle B kept its position, flow proceeds from step 1415 to step 1419, in which, vehicle B determines if vehicle A has overtaken it. If not, flow proceeds to step 1421 , in which vehicle B creates a recorded state containing: (1 ) the current timestamp; (2) the algorithm step field set to 4 (a 4 in this field essentially being indicative of the fact that vehicle B has yielded to vehicle A, but vehicle A has not overtaken vehicle B); and (3) the proof field containing an image or LiDAR report showing the left side of B to prove whether A overtook B. Then flow returns to step 1403.

[00168] If, on the other hand, it is determined in step 1419 that vehicle A overtook vehicle B, flow instead proceeds to step 1423, in which vehicle B creates a recorded state similar to that discussed immediately above, except that the proof would indicate that vehicle A has passed vehicle B and the algorithm step field is set to 5 (a 5 in this field essentially being indicative of the fact that vehicle B has yielded to vehicle A, and vehicle A has overtaken vehicle B). Since detecting that vehicle A passed vehicle B would comprise the end of the transaction, flow proceeds from step 1423 to step 1425, in which vehicle B produces the final reported states list, and the process ends at 1427.

[00169] If time limit N is reached before vehicle B detects that it has been passed by vehicle A, then flow proceeds from step 1403 to 1425 to produce a final report that indicates whatever state of affairs existed at the end of period N.

[00170] This final report constitutes the report that vehicle B sends to the toll infrastructure in message 1 120 of FIG. 1 1. The final reported states lists produced by vehicles A and B may be used by the toll infrastructure together with the transaction receipt (see data structure 1307 in FIG. 13) to solve any possible conflict.

Real World Examples

[00171] The following are some examples of real world scenarios in which the technology disclosed herein may be applied.

[00172] One scenario is a subscription-based scenario. Subscriptions may be defined in terms of time, space, or a combination of both. For example, a driver could purchase 100 miles of premium lane usage (space), two months of premium lane usage (time), or 500 miles per month of premium lane usage (a combination of time and space).

[00173] In one embodiment, the capabilities are granted to the target device (as opposed to an individual). The target device can be a smartphone or the smart vehicle control center (Android, iOS etc.). When mileage expires, the target device could force the driver to exit the premium lane by gradually slowing the maximum speed of the vehicle to a speed unfit for the premium lane (e.g., 40 mph). This would guarantee a natural regulation of the premium lanes in which only drivers with enough "premium miles" would be able to take advantage of it.

[00174] In yet another embodiment, in instances of increased demand of usage of the premium lanes and proximity of congestion, the system could dynamically create a second premium lane and distribute the vehicles equally among the two. Each target device will indicate to the driver whether the driver should move to the newly created premium lane or staying in the original one.

[00175] Although the invention has been described herein using the right to overtake another vehicle as the capability bestowed upon its bearer, this is merely exemplary, and other capabilities may be bestowed, such as parking priority (e.g., the right to park in a parking spot) or the ability to cause a traffic light or other signal or sign to change (e.g., turning a red light to a green light).

Conclusion

[00176] Although features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer readable medium for execution by a computer or processor. Examples of non-transitory computer-readable storage media include, but are not limited to, a read only memory (ROM), random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU 102, UE, terminal, base station, RNC, or any host computer.

[00177] Moreover, in the embodiments described above, processing platforms, computing systems, controllers, and other devices containing processors are noted. These devices may contain at least one Central Processing Unit ("CPU") and memory. In accordance with the practices of persons skilled in the art of computer programming, reference to acts and symbolic representations of operations or instructions may be performed by the various CPUs and memories. Such acts and operations or

instructions may be referred to as being "executed," "computer executed" or "CPU executed."

[00178] One of ordinary skill in the art will appreciate that the acts and symbolically represented operations or instructions include the manipulation of electrical signals by the CPU. An electrical system represents data bits that can cause a resulting transformation or reduction of the electrical signals and the maintenance of data bits at memory locations in a memory system to thereby reconfigure or otherwise alter the CPU's operation, as well as other processing of signals. The memory locations where data bits are maintained are physical locations that have particular electrical, magnetic, optical, or organic properties corresponding to or representative of the data bits. It should be understood that the exemplary embodiments are not limited to the above- mentioned platforms or CPUs and that other platforms and CPUs may support the provided methods.

[00179] The data bits may also be maintained on a computer readable medium including magnetic disks, optical disks, and any other volatile (e.g., Random Access Memory ("RAM")) or non-volatile (e.g., Read-Only Memory ("ROM")) mass storage system readable by the CPU. The computer readable medium may include cooperating or interconnected computer readable medium, which exist exclusively on the processing system or are distributed among multiple interconnected processing systems that may be local or remote to the processing system. It is understood that the representative embodiments are not limited to the above-mentioned memories and that other platforms and memories may support the described methods.

[00180] In an illustrative embodiment, any of the operations, processes, etc.

described herein may be implemented as computer-readable instructions stored on a computer-readable medium. The computer-readable instructions may be executed by a processor of a mobile unit, a network element, and/or any other computing device.

[00181] There is little distinction left between hardware and software

implementations of aspects of systems. The use of hardware or software is generally (but not always, in that in certain contexts the choice between hardware and software may become significant) a design choice representing cost vs. efficiency tradeoffs. There may be various vehicles by which processes and/or systems and/or other technologies described herein may be effected (e.g., hardware, software, and/or firmware), and the preferred vehicle may vary with the context in which the processes and/or systems and/or other technologies are deployed. For example, if an

implementer determines that speed and accuracy are paramount, the implementer may opt for a mainly hardware and/or firmware vehicle. If flexibility is paramount, the implementer may opt for a mainly software implementation. Alternatively, the implementer may opt for some combination of hardware, software, and/or firmware.

[00182] The foregoing detailed description has set forth various embodiments of the devices and/or processes via the use of block diagrams, flowcharts, and/or examples. Insofar as such block diagrams, flowcharts, and/or examples contain one or more functions and/or operations, it will be understood by those within the art that each function and/or operation within such block diagrams, flowcharts, or examples may be implemented, individually and/or collectively, by a wide range of hardware, software, firmware, or virtually any combination thereof. Suitable processors include, by way of example, a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller,

Application Specific Integrated Circuits (ASICs), Application Specific Standard Products (ASSPs); Field Programmable Gate Arrays (FPGAs) circuits, any other type of integrated circuit (IC), and/or a state machine.

[00183] Although features and elements are provided above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. The present disclosure is not to be limited in terms of the particular embodiments described in this application, which are intended as illustrations of various aspects. Many modifications and variations may be made without departing from its spirit and scope, as will be apparent to those skilled in the art. No element, act, or instruction used in the description of the present application should be construed as critical or essential to the invention unless explicitly provided as such. Functionally equivalent methods and apparatuses within the scope of the disclosure, in addition to those enumerated herein, will be apparent to those skilled in the art from the foregoing descriptions. Such modifications and variations are intended to fall within the scope of the appended claims. The present disclosure is to be limited only by the terms of the appended claims, along with the full scope of equivalents to which such claims are entitled. It is to be understood that this disclosure is not limited to particular methods or systems.

[00184] It is also to be understood that the terminology used herein is for the purpose of describing particular embodiments only, and is not intended to be limiting. As used herein, when referred to herein, the terms "station" and its abbreviation "STA", "user equipment" and its abbreviation "UE" may mean (i) a wireless transmit and/or receive unit (WTRU), such as described infra; (ii) any of a number of embodiments of a WTRU, such as described infra; (iii) a wireless-capable and/or wired-capable (e.g., tetherable) device configured with, inter alia, some or all structures and functionality of a WTRU, such as described infra; (iii) a wireless-capable and/or wired-capable device configured with less than all structures and functionality of a WTRU, such as described infra; or (iv) the like. Details of an example WTRU, which may be representative of any UE recited herein, were provided above with respect to FIGS. 1A-1 E.

[00185] In certain representative embodiments, several portions of the subject matter described herein may be implemented via Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), digital signal processors (DSPs), and/or other integrated formats. However, those skilled in the art will recognize that some aspects of the embodiments disclosed herein, in whole or in part, may be equivalently implemented in integrated circuits, as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., as one or more programs running on one or more microprocessors), as firmware, or as virtually any combination thereof, and that designing the circuitry and/or writing the code for the software and or firmware would be well within the skill of one of skill in the art in light of this disclosure. In addition, those skilled in the art will appreciate that the mechanisms of the subject matter described herein may be distributed as a program product in a variety of forms, and that an illustrative embodiment of the subject matter described herein applies regardless of the particular type of signal bearing medium used to actually carry out the distribution. Examples of a signal bearing medium include, but are not limited to, the following: a recordable type medium such as a floppy disk, a hard disk drive, a CD, a DVD, a digital tape, a computer memory, etc., and a transmission type medium such as a digital and/or an analog communication medium (e.g., a fiber optic cable, a waveguide, a wired communications link, a wireless communication link, etc.).

[00186] The herein described subject matter sometimes illustrates different components contained within, or connected with, different other components. It is to be understood that such depicted architectures are merely examples, and that in fact many other architectures may be implemented which achieve the same functionality. In a conceptual sense, any arrangement of components to achieve the same functionality is effectively "associated" such that the desired functionality may be achieved. Hence, any two components herein combined to achieve a particular functionality may be seen as "associated with" each other such that the desired functionality is achieved, irrespective of architectures or intermediate components. Likewise, any two

components so associated may also be viewed as being "operably connected", or "operably coupled", to each other to achieve the desired functionality, and any two components capable of being so associated may also be viewed as being "operably couplable" to each other to achieve the desired functionality. Specific examples of operably couplable include but are not limited to physically mateable and/or physically interacting components and/or wirelessly interactable and/or wirelessly interacting components and/or logically interacting and/or logically interactable components.

[00187] With respect to the use of substantially any plural and/or singular terms herein, those having skill in the art can translate from the plural to the singular and/or from the singular to the plural as is appropriate to the context and/or application. The various singular/plural permutations may be expressly set forth herein for sake of clarity.

[00188] It will be understood by those within the art that, in general, terms used herein, and especially in the appended claims (e.g., bodies of the appended claims) are generally intended as "open" terms (e.g., the term "including" should be interpreted as "including but not limited to," the term "having" should be interpreted as "having at least," the term "includes" should be interpreted as "includes but is not limited to," etc.). It will be further understood by those within the art that if a specific number of an introduced claim recitation is intended, such an intent will be explicitly recited in the claim, and in the absence of such recitation no such intent is present. For example, where only one item is intended, the term "single" or similar language may be used. As an aid to understanding, the following appended claims and/or the descriptions herein may contain usage of the introductory phrases "at least one" and "one or more" to introduce claim recitations. However, the use of such phrases should not be construed to imply that the introduction of a claim recitation by the indefinite articles "a" or "an" limits any particular claim containing such introduced claim recitation to embodiments containing only one such recitation, even when the same claim includes the introductory phrases "one or more" or "at least one" and indefinite articles such as "a" or "an" (e.g., "a" and/or "an" should be interpreted to mean "at least one" or "one or more"). The same holds true for the use of definite articles used to introduce claim recitations. In addition, even if a specific number of an introduced claim recitation is explicitly recited, those skilled in the art will recognize that such recitation should be interpreted to mean at least the recited number (e.g., the bare recitation of "two recitations," without other modifiers, means at least two recitations, or two or more recitations). Furthermore, in those instances where a convention analogous to "at least one of A, B, and C, etc." is used, in general such a construction is intended in the sense one having skill in the art would understand the convention (e.g., "a system having at least one of A, B, and C" would include but not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and/or A, B, and C together, etc.). In those instances where a convention analogous to "at least one of A, B, or C, etc." is used, in general such a construction is intended in the sense one having skill in the art would understand the convention (e.g., "a system having at least one of A, B, or C" would include but not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and/or A, B, and C together, etc.). It will be further understood by those within the art that virtually any disjunctive word and/or phrase presenting two or more alternative terms, whether in the description, claims, or drawings, should be understood to contemplate the possibilities of including one of the terms, either of the terms, or both terms. For example, the phrase "A or B" will be understood to include the possibilities of "A" or "B" or "A and B." Further, the terms "any of" followed by a listing of a plurality of items and/or a plurality of categories of items, as used herein, are intended to include "any of," "any combination of," "any multiple of," and/or "any combination of multiples of" the items and/or the categories of items, individually or in conjunction with other items and/or other categories of items. Moreover, as used herein, the term "set" or "group" is intended to include any number of items, including zero. Additionally, as used herein, the term "number" is intended to include any number, including zero.

[00189] In addition, where features or aspects of the disclosure are described in terms of Markush groups, those skilled in the art will recognize that the disclosure is also thereby described in terms of any individual member or subgroup of members of the Markush group.

[00190] As will be understood by one skilled in the art, for any and all purposes, such as in terms of providing a written description, all ranges disclosed herein also encompass any and all possible subranges and combinations of subranges thereof. Any listed range can be easily recognized as sufficiently describing and enabling the same range being broken down into at least equal halves, thirds, quarters, fifths, tenths, etc. As a non-limiting example, each range discussed herein may be readily broken down into a lower third, middle third and upper third, etc. As will also be understood by one skilled in the art all language such as "up to," "at least," "greater than," "less than," and the like includes the number recited and refers to ranges which can be

subsequently broken down into subranges as discussed above. Finally, as will be understood by one skilled in the art, a range includes each individual member. Thus, for example, a group having 1 -3 cells refers to groups having 1 , 2, or 3 cells. Similarly, a group having 1 -5 cells refers to groups having 1 , 2, 3, 4, or 5 cells, and so forth.

[00191] Moreover, the claims should not be read as limited to the provided order or elements unless stated to that effect. In addition, use of the terms "means for" in any claim is intended to invoke 35 U.S.C. §1 12, U 6 or means-plus-function claim format, and any claim without the terms "means for" is not so intended. [00192] A processor in association with software may be used to implement a radio frequency transceiver for use in a wireless transmit receive unit (WTRU), user equipment (UE), terminal, base station, Mobility Management Entity (MME) or Evolved Packet Core (EPC), or any host computer. The WTRU may be used in conjunction with modules, implemented in hardware and/or software including a Software Defined Radio (SDR), and other components such as a camera, a video camera module, a

videophone, a speakerphone, a vibration device, a speaker, a microphone, a television transceiver, a hands free headset, a keyboard, a Bluetooth® module, a frequency modulated (FM) radio unit, a Near Field Communication (NFC) Module, a liquid crystal display (LCD) display unit, an organic light-emitting diode (OLED) display unit, a digital music player, a media player, a video game player module, an Internet browser, and/or any Wireless Local Area Network (WLAN) or Ultra Wide Band (UWB) module.

[00193] Although the invention has been described in terms of communication systems, it is contemplated that the systems may be implemented in software on microprocessors/general purpose computers (not shown). In certain embodiments, one or more of the functions of the various components may be implemented in software that controls a general-purpose computer.

[00194] In addition, although the invention is illustrated and described herein with reference to specific embodiments, the invention is not intended to be limited to the details shown. Rather, various modifications may be made in the details within the scope and range of equivalents of the claims and without departing from the invention.

REFERENCES

[1] Levy, Henry, M. Capability-Based Computer Systems. Digital Press, Bedford, MA, 1984. Available online at: bttp;^

[2] Kain, Richard Y. and Carl E. Landwehr. On Access Checking in Capability-Based Systems. In IEEE Transactions on Software Engineering. Vol SE-13, No. 2, pp. 202-207.

[3] Tanenbaum, Andrew S., Sape J. Mullender, and Robbert van Renesse. Using Sparse Capabilities in a Distributed Operating System. In Proceedings of the 6th International Conference on Distributed Computing Systems (ICDCS 1986), pp. 558-563.

[4] Aura, Thomas. Distributed Access-Rights Management with Delegation

Certificates. In Secure Internet Programming. Jan Vitek and Christian D. Jensen, eds., pp. 21 1 -235. Springer Lecture Notes in Computer Science Vol. 1603.

[5] Thompson, Mary, William Johnston, Srilekha Mudumbai, Gary Hoo, and Keith

Jackson. Certificate-based Access Control for Widely Distributed Resources. In

Proceedings of the 8^th U SEN IX Security Symposium, pp. 215-227.

[6] Whyte, Weimerskirch, Kumar, Hehn. A security credential management system for V2V communications. In IEEE Vehicular Networking Conference (VNC), 2013

[7] Ethereum, the blockchain app platform https://www.ethereum.org/

Claims

What is claimed is:

1. A method for a first vehicle to exercise a capability relative to a second vehicle using a communication network, comprising:

the first vehicle receiving from an authority, via the communication network, a first message containing a certificate signifying a capability of the first vehicle; and

the first vehicle transmitting, via the communication network, a second message to the second vehicle, the second message containing the certificate, wherein the certificate is encrypted with a public encryption key of the second vehicle.

2. The method of claim 1 wherein the certificate received from the authority is signed with a private encryption key of the authority and wherein the second message containing the certificate contains the certificate signed by the authority.

3. The method of claim 1 wherein the certificate in the first message is further encrypted with a public key of the first vehicle.

4. The method of claim 1 wherein the first message is further annotated with metadata.

5. The method of claim 1 wherein the certificate in the second message is further signed with a private key of the first vehicle.

6. The method of claim 1 further comprising:

the first vehicle receiving a copy of a public key of the second vehicle.

7. The method of claim 1 wherein the capability includes a duration during which it is valid.

8. The method of claim 1 wherein the capability includes an expiration time.

9. The method of claim 1 wherein the capability includes a priority level.

10. The method of claim 1 wherein the capability comprises at least (1) an identity of a vehicle to which it corresponds and (2) a description of the capability it bestows.

11. The method of claim 1 wherein the capability is a right to overtake another vehicle.

12. The method of claim 1 wherein the capability is the right of a vehicle to perform a maneuver relative to another vehicle.

13. The method of claim 1 further comprising:

responsive to exercising of the capability, decrementing the capability.

14. The method of claim 1 further comprising:

requesting from the second vehicle, a public encryption key of the second vehicle; and receiving from the second vehicle, the public encryption key of the second vehicle.

15. The method of claim 1 further comprising:

receiving from the authority, a public encryption key of the authority;

16. A method for a target vehicle to respond to an assertion of a capability by an asserting vehicle relative to the second vehicle using a communication network, comprising:

the target vehicle receiving a first message from the first vehicle, the first message containing a certificate signifying a capability of the first vehicle relative to the second vehicle, wherein the signed certificate is encrypted with a public encryption key of the second vehicle; the target vehicle decrypting the certificate using a private encryption key of the target vehicle;

the target vehicle transmitting to the authority, via the communication network, a second message requesting the authority to validate the certificate; and

the target vehicle receiving from the authority, via the communication network, a third message indicating whether the certificate is valid.

17. The method of claim 16 wherein the certificate in the first message is signed with a private encryption key of the first vehicle.

18. The method of claim 17 wherein the certificate is further encrypted using a private encryption key of the first vehicle and further comprising the target vehicle decrypting the certificate using the public encryption key of the first vehicle.

19. The method of claim 18 wherein the certificate in the first message is further signed with the private encryption key of an authority other than the first vehicle having authority to issue the certificate.

20. The method of claim 16 further comprising:

responsive to the third message indicating that the certificate is valid, attempting to perform an action responsive to the certificate.

21. The method of claim 20 wherein the action comprises issuing an indication adapted to inform a driver of the target vehicle of an action to take responsive to the capability.

22. The method of claim 20 wherein the target vehicle is at least partially autonomous and wherein the action comprises causing the vehicle to perform a maneuver responsive to the capability.

23. The method of claim 16 wherein the first message is further annotated with metadata.

24. The method of claim 16 wherein the capability includes a duration during which it is valid.

25. The method of claim 16 wherein the capability includes an expiration time.

26. The method of claim 16 wherein the capability includes a priority level.

27. The method of claim 26 further comprising:

the target vehicle comparing the priority level of the capability with a priority level associated with the target vehicle; and

the target vehicle ignoring the capability if the priority level associated with the target vehicle is greater than the priority level in the capability.

28. The method of claim 16 wherein the capability comprises at least (1) an identity of a vehicle to which it corresponds and (2) a description of the capability it bestows.

29. The method of claim 16 wherein the capability is a right to overtake a vehicle.

30. The method of claim 20 further comprising:

transmitting to the authority via the network a fourth message indicating whether or not the action has been performed.

31. The method of claim 20 wherein the attempting to perform the action comprises:

the target vehicle determining if conditions permit the target vehicle to perform a maneuver responsive to the capability;

performing the maneuver if conditions permit; and

transmitting to the authority a fourth message indicating whether or not the maneuver has been performed.

32. The method of claim 31 wherein the attempting to perform the maneuver further comprises:

issuing an indication adapted to inform a driver of vehicle B of an action to take responsive to the capability; and

determining if the driver has performed the action.

33. A method for an authority to permit a first vehicle to exercise a capability relative to a second vehicle using a communication network, comprising:

the authority receiving, via the communication network, a first message from the first vehicle requesting granting of a capability for the first vehicle;

the authority transmitting, via the communication network, a second message containing a certificate signifying a capability of the first vehicle;

the authority receiving from the second vehicle, via the communication network, a third message requesting the authority to validate the certificate; and

the authority transmitting to the second vehicle, via the communication network, a fourth message indicating whether the certificate is valid.

34. The method of claim 33 wherein the certificate is signed with a private encryption key of the authority.

35. The method of claim 34 wherein the certificate in the second message is further encrypted with a public key of the first vehicle.

36. The method of claim 34 wherein the first message is further annotated with metadata.

37. The method of claim 34 wherein the capability includes a duration during which it is valid.

38. The method of claim 34 wherein the capability includes an expiration time.

39. The method of claim 34 wherein the capability includes a priority level.

40. The method of claim 34 wherein the capability comprises at least (1) an identity of a vehicle to which it corresponds and (2) a description of the capability it bestows.

41. The method of claim 34 wherein the capability is a right to overtake another vehicle.

42. The method of claim 34 wherein the capability is the right of a vehicle to perform a maneuver relative to another vehicle.

43. A method for a second vehicle to verify authenticity of a capability being asserted against it by a first vehicle, the method comprising:

receiving a transaction message, the transaction message containing a transaction identifier, the transaction identifier comprising at least one token representing a capability of the first vehicle being asserted relative to the second vehicle;

subsequently receiving transaction receipt messages from a plurality of third vehicles, each transaction receipt comprising the transaction identifier;

determining if a number of transaction receipts received within a predetermined period since receiving the transaction message exceeds a threshold.

44. The method of claim 43 wherein each transaction identifier is signed by a private encryption key of the third vehicle that transmitted the transaction receipt message.

45. The method of claim 44 further comprising: determining the transaction to be valid if the number of transaction receipts received within a predetermined period since receiving the transaction message exceeds a threshold.

46. The method of claim 45 further comprising:

responsive to determining that the transaction is valid, attempting to perform an action responsive to the capability.

47. The method of claim 46 wherein the action comprises issuing an indication adapted to inform a driver of the second vehicle of an action to take responsive to the capability.

48. The method of claim 46 wherein the second vehicle is at least partially autonomous and wherein the action comprises causing the vehicle to perform a maneuver responsive to the capability.

49. The method of claim 45 wherein the first message is further annotated with metadata.

50. The method of claim 45 wherein the capability includes a duration during which it is valid.

51. The method of claim 45 wherein the capability includes an expiration time.

52. The method of claim 45 wherein the capability includes a priority level.

53. The method of claim 43 wherein the capability is a right to overtake a vehicle.

54. The method of claim 46 further comprising:

transmitting a witness request message to at least one fourth vehicle requesting the at least one fourth vehicle to confirm that the second vehicle performed the action responsive to the capability; and

receiving from the at least one fourth vehicle a transaction receipt message indicating whether the second vehicle performed the requested action.

55. The method of claim 54 further comprising:

transmitting the receipt message to the authority.

56. A method of confirming exercise of a capability by a first vehicle relative to a second vehicle using a communication network, comprising:

receiving from the first vehicle via the communication network a transaction message, the transaction message including at least (1) a transaction identifier representing a capability of the first vehicle being asserted relative to the second vehicle, (2) a signature of an authority that granted the capability, and (3) a signature of the first vehicle;

transmitting to the first vehicle via the network a first transaction receipt message acknowledging receipt of the transaction message;

transmitting to the authority via the network a second transaction receipt message acknowledging the transaction.

57. The method of claim 56 further comprising:

receiving from the authority via the network a value responsive to the transmission of the second transaction receipt message.

58. The method of claim 56 wherein the transaction message is a blockchain transaction message.

59. The method of claim 58 wherein the second transaction receipt is a blockchain confirmation message.

60. The method of claim 59 further comprising:

broadcasting a copy of the transaction message and the second transaction receipt message to other nodes of the communication network.

61. The method of claim 56 further comprising:

receiving a value from the authority in response to the second transaction receipt message.

62. The method of claim 56 wherein at least a portion of the transaction identifier in the transaction message is encrypted with a private key of the second vehicle, and further comprising decrypting the portion of the encrypted transaction message.

63. The method of claim 62 wherein the transaction message further comprises a timestamp indicative of a time of the transaction, a message type field indicating a type of the message, and a transaction state field comprising information indicative of a status of the transaction.

64. The method of claim 63 wherein the message type is set to a first state indicative of the transaction having been requested.

65. The method of claim 64 wherein the first transaction receipt message includes a copy of the transaction message signed with a private encryption key of the third vehicle.

66. The method of claim 56 further comprising:

receiving from the second vehicle via the network a request message requesting witnessing of the transaction;

sensing data relating to the first and second vehicles using sensing apparatus of the third vehicle;

creating a record of the sensed data;

transmitting to the authority via the communication network a message including the sensed data.

67. The method of claim wherein the sensing comprises:

determining if the second vehicle is able switch driving lanes safely to allow the first vehicle to pass;

if the second vehicle is able switch driving lanes safely to allow the first vehicle to pass, determining whether the second vehicle switched driving lanes to allow the first vehicle to pass; if the second vehicle switched driving lanes to allow the first vehicle to pass, determining if the second vehicle maintained a position that permitted the first vehicle to pass; and

if the second vehicle maintained a position that permitted the first vehicle to pass, determining if the first vehicle passed the second vehicle.

68. The method of claim 67 wherein the third vehicle performs the determining steps repeatedly until expiration of a timer.

69. The method of claim 68 wherein the third vehicle performs the determining steps at intervals of N/M seconds, where N is a predetermined period of time and M is an integer.

70. The method of claim 69 wherein the third vehicle transmits the sensed data after the expiration of the timer.