HANDS-FREE DEPLOYMENT OF GEOGRAPHICALLY LINKED APPLICATIONS

System and techniques for hands-free deployment of geographically linked applications are described herein. A radio transceiver of a vehicle may detect a beacon. Here, the beacon includes an indication that an application linked to a geographical area covered by the beacon is available. The vehicle may establish a secure communications link with an application server corresponding to the beacon and receive, through the secure communications link, an application. Then, the vehicle may execute the application in a protected execution environment without intervention by a user of the vehicle.

TECHNICAL FIELD

Embodiments described herein generally relate to automated vehicle application distribution and more specifically to hands-free deployment of geographically linked applications.

BACKGROUND

Geographically linked or contextual services generally involve the use of an application on a user device to provide context specific functionality. For example, upon entering a museum, a user may download an application to a mobile phone, the application providing a tour or explanations of the museum's exhibits. These geographically linked or contextual services may be considered Smart City services in a variety of contexts.

Automated vehicles include systems to assist drivers or to fully control the vehicle without driver intervention. Automated vehicles may be used in mobility-as-a-service (MaaS) applications, in which a passenger may call a vehicle and the vehicles autonomously delivers the passenger to a destination. While the hardware to sense the environment or control the vehicle generally inhabits the automated vehicle. MaaS may employ external hardware to provide services that interact with the passenger (e.g., through a MaaS cloud service, a passenger application, etc.).

DETAILED DESCRIPTION

With respect to Smart City services and the like, a general use case involves user interaction. This interaction may include searching and downloading an app to a mobile device of the user. For example, before going to the MET in NYC, you should download the Metropolitan Museum of Art (the MET) app for using tickets or getting maps. Further, once the user leaves the MET, the user should remove the app because it may not be useful outside the geographical context of the MET. A problem that may arise with the user interaction includes informing users that the service is even available. That is, the user must be aware of the existence of Smart City services that are relevant to a given location before seeking the application out to download and run. Several of these services or the mobile applications to consume them may be unknown to the target users, if users don't use the service due to lack of knowledge, investment on developing or deploying those services are wasted.

The problems with Smart City services and the like expand as more devices become available to consume those services. An example of one such device, with different user interaction characteristics than a mobile phone, are automated vehicles (AV), whether privately owned or in a MaaS system. In either case, the ability of a geographic venue to post placards or the like to inform users about the presence of services, or instructions how to obtain a service, is more limited than an individual walking into the venue. Moreover, when a user's attention is focused on controlling a vehicle in a safe manner, additional user interactions to identify, download, and run an application may be inconvenient or dangerous.

Some attempts to bring geographical linked services to vehicles include factory installation of application, manual deployment of applications to the vehicle, or manual deployment to a user device connected to the vehicle. Factory installed applications are installed by default in the vehicle (e.g., in an infotainment system of the vehicle) and are always available to the current user of the vehicle. Factory installation may include several issues. For example, applications are installed without regard to whether they are useful of desirable to a user, consuming resources (e.g., processing, storage, etc.) in the vehicle. Generally, these applications cannot be removed from the vehicle and are embedded (e.g., integrated) in several built-in functionalities. Some of these applications are subscriptions in which a user wanting to use the application needs to provide personal credentials to access the service even if the vehicle is not theirs, as is the case in rental vehicles or MaaS vehicles. In this case, the user must remember to remove the credentials or user data to avoid abuse by others.

Manual deployment in the vehicle involves the user manually (e.g., proactively) searching, downloading and installing the application in the vehicle (e.g., in an infotainment device of the vehicle). Manual deployment in a vehicle may also involve several issues, such as requiring user interaction for discovering, installing, or removing the applications. Also, several versions of the same application may need to be available for the different automotive operating systems. This may create silos (e.g., each target platform has its own application ecosystem), increasing the cost for developing and deploying applications.

Manual deployment in a user device, such as a mobile phone, operates like traditional Smart City applications with the exception that the mobile device interfaces with the vehicle. Again, the manual nature of the deployment involves a burden on users to identify and manage the application. Further, there is a question of integration between the mobile device and the vehicle system, possibly leading to less functional applications, or the silo effect noted above.

To address these issues, a combination of contextual information, discovery, and deployment technologies may be used to implement a hands-free (e.g., hands-off or automatic) lifecycle—e.g., discovery, deployment, removal—of geographically linked applications in a vehicle. For example, using edge or cloud providers and trusted execution environments (TEE)—such as Software Guard Extensions (SGX). Trust Domain Extensions (TDE)—to provide isolated or secure access to the system resources, an automated vehicle may provide an enhanced and secure user experience to discover, deploy, or retire geographically linked applications.

In an example, the vehicle autonomously (automatically) discovers geographically-linked applications based on contextual aspects-such as geolocation or the presence of a beacon-attests the identity of the vehicle or a current user, provides capabilities present and currently available in the vehicle, and automatically deploys (e.g., downloads, installs, and runs) the geographically-linked application in an isolated and secure environment. Once the application is no longer needed-such as when the vehicle leaves the geographical area covered by the geographically-linked application—the application may be proactively retired (e.g., removed) from the vehicle. In most scenarios, the entire process is performed hands-free, without user intervention or even attention. The trust and confidentiality provided by the TEE enable the noninteractive aspect by enabling users to be sure that the integrity of the vehicle driving system or the user's personal data will not be compromised. Further, because isolation may be bidirectional—the host cannot inspect the application running in the isolated environment, which protects the data of the application vendor and sensitive data of the user—and the application cannot inspect the part of the host for which access was not granted, which protects the host assets and user information from disclosure to an unauthorized party, the automatic execution causes few issues. Additional details and examples are described below.

FIG. 1is a block diagram of an example of an environment including a system for hands-free deployment of geographically linked applications, according to an embodiment. As illustrated, the vehicle105moves through five stages during the hands-free deployment of a geographically linked application. The stages start with discovery120, attestation125, deployment130, usage135, and removal140. Here, the application is geographically linked to the building115, and a transmitter110that provides the beacon, the geographically linked application, or both.

While the examples below discuss geographical context for the applications, some other contexts may also be combined with the geographical context, or used on their own. These other contexts may include time of the day (e.g., at noon, and depending on the location an application is delivered for a restaurant), vehicle state (e.g., when a battery level is low and application to reserve a spot to charge the vehicle105is deployed), an emergency (e.g., an application is deployed to help avoid wild fires in the area), among others.

The vehicle105includes computer hardware, such as processing circuitry in an infotainment device, and a transceiver to communicate with the transmitter110when in operation. The processing circuitry is configured (e.g., at the time of manufacturing, at any time by software, or a combination thereof) to detect a beacon transmitted from the transmitter110and received at the transceiver of the vehicle105.

The processing circuitry is configured to detect beacon that is received by the vehicle's transceiver from the transmitter110. The same transceiver may be used to receive the beacon as wells as other communications (e.g., with a cellular network), or different transceivers may be used. The beacon is a signal that includes an indication that an application linked to a geographical area covered by the beacon is available. Thus, generally, the transmitter110provides the beacon within a limited range covering the geographical area. In an example, the method600is extended to include activating the radio transceiver to detect the beacon in response to entering the geographical area. Here, a geofencing technique may be used to search for the beacon when the vehicle enters the geographical area. In an example, the beacon does not identify the application, but merely indicates that some application is available. In any case, the beacon is used to notify the vehicle105that a geographically linked application is available for the current area in which the vehicle105finds itself.

Once the vehicle105is aware that an application is available, the vehicle may start the process by which to acquire and run the application. For example, the processing circuitry may be configured to establish a secure communications link with an application server corresponding to the beacon. Here, the transmitter110may provide a physical link to an application server (e.g., collocated with the transmitter110), or the beacon may include connectivity information to an application server on a different physical link. Generally, the secure link will include exchanging credentials and encrypting communications. In an example, establishing the secure communications link includes providing an identity of the vehicle and attestation data to confirm the identity. The identity and attestation may provide additional assurance to an application provider that the application will function and that the proprietary aspects of the application are not compromised by making it available to the vehicle105. In an example, the identity of the vehicle is linked to an identity of a user. The linking may be embedded in the identity attestation information, enabling the application provider to separately confirm the user's identity. In an example, the identity of the user corresponds to a set of user preferences for geographically linked applications. Here, the user identity is less important from a security perspective, but rather user customization is available to improve the user experience of the geographically linked application.

In an example, a set of capabilities is provided as part of establishing the secure communications link. The capabilities may include available types of hardware on the vehicle105, such as which video, audio, or artificial intelligence accelerators, or TEE environments are available. The capabilities may include other resources of the vehicle105, such as processing power, storage, or working memory. The capabilities may include a current workload or other variable factors that impact the ability of the vehicle105to perform a given workload. In general, the capabilities are used by the application provider to determine whether to provide the application, or what version of the application to provide. Thus, if the application will not run, or will likely result in a poor user experience, the provider may withhold the application. Also, there may be several versions of the application to use different accelerators, or provide different functionality, from which to select one to provide the best user experience based on the capabilities.

In an example, the application provider may communicate an application catalog based on the set of capabilities and the identity to the vehicle. Here, the application provider communicates that different applications, or versions of an application, are available. In an example, the application catalog provides metrics for the applications in the catalog to enable the processing circuitry to judge which of the several applications to use. Thus, in an example, the processing circuitry is configured to retrieve performance data for the application from the application catalog and evaluate a current state of the processing circuitry with respect to the performance data to determine that the application passes a threshold. Thus, the processing circuitry establishes that current workloads leave enough computing resources available to run the application without undue impact. In an example, the application is executed in the TEE of the processing circuitry in response to passing the threshold. In an example, the performance data includes expected hardware usage (e.g., profiling numbers about working memory use, storage use, processing power consumption, etc.). In an example, evaluating the current state of the processing circuitry includes determining hardware usage of an already running application, combining the expected hardware usage of the application, and determining that available hardware is greater than the combination of the expected hardware usage and the hardware usage of the already running application.

In an example, the attestation service may provide an application programming interface (API) that may be invoked by a MaaS service once a trip is finished (e.g. end of trip communicated by an Uber like app). This uses the trust chain created to deploy the app. In an example, the API may be used by vendors to protect their work, such as by removing or upgrading an application because of a detected security flaw.

Once attestation has passed, the application provider makes the geographically linked application available to the vehicle105. This may include starting a transmission of the application (or the application catalog) to the vehicle105, or it may include providing the vehicle105with retrieval information (e.g., address, keys, etc.) to enable the vehicle105to retrieve the application. In either case, the processing circuitry is configured to receive the application through the secure communications link.

Once the vehicle105has received the application (e.g., an executable or script for the application), the processing circuitry is configured to execute the application in a protected execution environment of the vehicle without intervention by a user of the vehicle. Thus, up until this point, and perhaps beyond, the user (e.g., driver, pilot, or passenger) is unaware of the existence of the application. The protected execution environment provides security for the vehicle105, and may be implemented in several ways. For example, a virtual machine may be used to isolate the application. In an example, the protected execution environment is bidirectionally secure with other hardware of the vehicle. In an example, the protected execution environment is a hardware implemented trusted execution environment (TEE). This example demonstrates the use of specific hardware in the processing circuitry to provide isolation and security for the application.

In an example, the processing circuitry is configured to detect a removal trigger and remove the application. In an example, the removal trigger is at least one of expiration of a time period, movement beyond the geographical area, or passing beyond a resource use threshold. Thus, the application may only be run for a specific period of time, such as a day. Movement beyond the geographical area may be managed by a satellite positioning system or simply passing beyond the range of the transmitter110. These examples demonstrate a convenient technique to ensure that many applications may be enjoyed by a user without active maintenance to identify and purge applications that are no longer useful. In contrast, removing the application when a resource threshold is surpassed ensures that the vehicle operations are not impacted by, for example, a misbehaving application, or when circumstances change, and more processing power is needed for other aspects of the vehicle's control.

FIG. 2-FIG. 5illustrate a prototypical use case for the autonomous service discovery and deployment (e.g., hands-free deployment of geographically linked applications). In broad strokes, a vehicle205approaches a geographical area that has a radio-based beacon230. An edge server235is collocated with the beacon230and provides edge compute capabilities. The edge server235is connected to a cloud250that provides cloud services running on one or more datacenters.

FIG. 2illustrates an example of the hands-free deployment system as it approaches an application provider (e.g., edge server235), according to an embodiment. In an example, the vehicle205includes a compute device210, such as part of an advanced driver-assistance system (ADAS), infotainment system, etc. In an example, the compute device210includes hardware to execute workloads in a TEE215. Here, the workloads running on the TEE215are isolated from the operating system (OS). This ensures that the OS cannot inspect the contents of the workload running on the TEE215, nor can the workload access services or data (e.g., from peripherals225of the compute device210) of the OS unless the application is granted access by the OS. Examples of TEE215implementations may include SGX or Trust Domain Extensions (TDX).

In an example, the compute device includes an embedded subsystem to execute a discovery service220as trusted application. The discovery service220, like an application running in the TEE215, is executed independently of the OS. Examples of embedded subsystems to implement the discovery service220include a Intel® Converged Security and Manageability Engine (CSME) Intel® Management Engine (ME).

The user may be the owner of the vehicle205who is currently driving and paying complete attention to the road. However, in an autonomously driven vehicle, the user may be a person currently renting the vehicle205or using it in a MaaS. No matter the user situation, when the vehicle205passes the beacon230in the given scenario, an application will start running on the compute device210. Examples of the application may include:1. An application that provides localized and up to date information to the user of the given geographical areas, such as listing the best parking spots available in the city downtown, or alerts about emergency information.2. An application that reports the vehicle's position or statistics to a centralized service, such as reporting the battery level in an electric car. The centralized service then uses this information to allocate a charging bay for the vehicle.3. An application that uses a visualization technology present in the vehicle205to provide the user with, for example, road hazard labeling for the current geographical areas, a machine learning output that identifies an exotic animal species only present on that geographical area and warns the user to be careful to not harm the exotic animal, etc.

From the user's point of view, this process is automatic and secure. Automatic in the sense that it does not require any user interaction to get the benefits of the application running, and secure in the sense that the user knows that the application will not misbehave and cause harm due to the isolation of the application with the other subsystems guaranteed by the TEE215.

In an example, applications may be created following a standard software development process and published into a marketplace of applications. In an example. Software Development Kit (SDK) may be provided to third party application developers to increase the number and quality of available MaaS applications. In an example, the marketplace may be centralized in a cloud-based deployment (e.g., through application provider240or application provider245), or a portion relevant to a given geographical area may be deployed at the geographical area hosted in an edge server235. The edge deployment may present additional benefits by using a Near-me Area Network (NAN) infrastructure to deploy the application that may improve deployment times by avoiding communicating with the cloud application marketplace through an internet connection, for example.

Although the examples herein discuss a beacon, alternative embodiments may be used in much the same manner as the beacon230. For example, a virtual-beacon—e.g., an application running in an edge device (such as application server235inFIG. 2) using a transmitter—may be employed. Thus, once the vehicle205is close and in range of the transmitter, the same functionality as the physical beacon230. In an example, the range of the transmitter may be too far to be considered “near area” (e.g., a 5G cellular tower). To make it operate as “near-area,” the location shared by the vehicle205, and the location of the virtual-beacon (previously defined) are compared to determine if they are close enough (e.g., within a threshold distance). If they are close enough, then the virtual beacon is treated as detected, and ignored otherwise.

FIG. 3illustrates an example of the hands-free deployment system performing discovery, according to an embodiment. Discovery305is the initial phase of the deployment process. In this phase, an environmental parameter is used to publish available services. This environmental parameter may be the current geographical location of the vehicle205by a GPS, or the presence of a radio signal in the near geographical location. The environmental parameter is discovered by the discovery service220of the compute device210.

In an example, the environmental parameter is the presence of a beacon in the area. The discovery service220detect the radio signals produced by the beacon transmitter and is notified that there are MaaS applications available for execution that will provide value to the user.

Attestation is a phase after discovery305. Initially, the discovery service220will interact with an attestation service running on the cloud250or deployed in the near geographical area at an edge location. The purpose of this process is to prove the identity of the compute device210using a unique identifier and a secure process to prove that this compute device210is the sole owner of that unique identifier. After the identity attestation process is complete, an initial trusted and secure communication channel may be established between the attestation service and the discovery service220. The secure communication channel will be used for the duration of the process to communicate sensitive information between the actors.

In an example, the compute device210unique identifier may be associated with the actual identity of the user. This may be implemented through an out-of-band process to stablish the association, such as the owner of the vehicle205associating a personal identity to the unique identifier of the vehicle205using a private infrastructure (e.g., an insurance company) or a public service (e.g., the Department of Motor Vehicles (DMV)). In an example, the current user of the vehicle205could temporarily link his personal identity to the unique identifier of the compute device210using biometric information or a mobile application to establish the physical presence of the person in the vehicle205. The personal identity may improve the user experience of the applications deployed in the vehicle205compute device210by, for example fetching user preferences from a cloud service

In an example, after the identity attestation process is complete, a capability attestation may be triggered. The capability attestation may include the discovery service220publishing the capabilities present or currently available in the vehicle205. Such capabilities may include any combination of processing power, available memory, the availability of a smart display or a smart windshield technology, accelerators, etc.

As with discovery, the discovery service220interacts with the edge server235to perform the attestation process or processes. In an example, the processes are performed through a NAN that connects the vehicle205with the edge server235.

FIG. 4illustrates an example of the hands-free deployment system deploying an application, according to an embodiment. Deployment follows discovery305and attestation. With the capabilities reported by the discovery service220, the attestation service now decides which applications it is going to offer405to the vehicle205compute device210for deployment. A set of examples on criteria for selecting an application catalog may include:1. Based on a user profile (if available). In this case, the application catalog430may be populated with applications that the user may prefer or has already been using.2. Based on the current capabilities reported by the discovery service220. In this case, the information received in the capabilities attestation process is used to decide the application catalog420contents. For example, applications that requires a Smart Windshield are not offered because of the lack of necessary capability on the vehicle205.3. Based on localization policies. In this case, the geographical area may require all vehicles, including the vehicle205, to run an application to satisfy a law enforcement of governmental policy. For example, an application reporting a maximum velocity or greenhouse gas emission statistics to a central service for monitoring, or in a catastrophic or emergency situation, the geographical area will deploy specific applications that may help to overcome the emergency situation.4. Based on a bidding process. This may operate similar to advertisement auctions (e.g., bidding) occur on web pages. In this case, third party application providers bid for the opportunity to be deployed in the vehicle205compute device210. For example, three different parking companies may bid for the opportunity to offer their services to the user.

Once the application catalog is generated, it is sent405to the discovery service220. The discovery service220makes a decision on whether to deploy an application from the received catalog430. The discovery service220may decide to not deploy an application if, for example, the resources of the vehicle205compute device210are being used by some other system or process, or if the user experience will be negatively impacted by deploying another application.

As illustrated, the edge server235communicates405the application catalog430to the discovery service220. The application catalog430contains metadata related to the App1and App2. The App3is discarded on the application catalog generation process, and thus is not in the application catalog430. The discovery service220selects an application410from the proposed catalog430. The application selected is the App1, which can be directly installed from the edge server235without incurring in internet utilization for downloading the App1package like in the App2case. A launch request415is performed by the discovery service220to the TEE215. The application package is then fetched420from the edge server235using the previously created secure communication channel. The application package may then be validated and instantiated425in the TEE215.

Once instantiated, the usage phase begins. When running in the TEE215, the application is effectively isolated from the vehicle205systems, such as an ADAS or In-vehicle Infotainment (IVI) system. Access to the data and peripherals225must be granted by the discovery service220, generally only in a need-to-have basis. Once the necessary access is granted to the application, the application may start executing its logic and provide its value to the User.

In an example, the instantiated application425is allocated necessary CPU time, working memory allocation, or access to the display, sound, or other systems. For example, a sample application may use a guidance system for consuming promoted city services. The application425interacts with the user through the sound subsystem to promote places to visit. Also, once a place is selected, the display is used to show a map with directions to the selected place.

FIG. 5illustrates an example of the hands-free deployment system removing an application, according to an embodiment. As the vehicle205moves beyond the geographical area, the removal phase may be reached. The removal is triggered based on contextual conditions. A list of potentially applicable conditions may include:1. Time. A time condition may be used to trigger the removal of the application. After the configured time (e.g., a day, business hours, etc.), the application may be consider no longer needed and removed.2. Geographical position. A satellite position system (or other localization service) boundary or beacon may be used to notify the discovery service220that the application is no longer needed.3. Resource utilization. The discovery service220may determine to schedule a more relevant application and release needed resources necessary by stopping any of the currently deployed applications. For example, in a catastrophic or emergency situation, an entertainment application may be removed to enable applications that provide guidance in the context of the emergency to execute.4. A combination of contextual conditions. For example, on a self-driving taxi e.g., MaaS), the distance between the geolocation of the vehicle205and the geolocation of the user that hired the service may trigger the removal process of the applications when then user moves away from the vehicle205.

Removal may include destroying the TEE215containing the application and its associated data. Given the hardware base isolation characteristic of the TEE215, removing the instance of the TEE215will ensure that no data or confidential information will be left on the vehicle205compute device210. After removal, the resources allocated to the TEE215will become available so the discovery service220may use them to run additional applications. The third-party application provide is also benefited from the removal process by avoiding disclosure of sensitive intellectual property that may be contained in the application package.

FIG. 6illustrates a flow diagram of an example of a method600for hands-free deployment of geographically linked applications, according to an embodiment. The operations of the method600are performed by computer hardware, such as that described above or below (e.g., processing circuitry).

At operation605, a beacon is detected. The detection may be performed by a radio transceiver of a vehicle. Here, the beacon includes an indication that an application linked to a geographical area covered by the beacon is available. In an example, the method600is extended to include activating the radio transceiver to detect the beacon in response to entering the geographical area.

At operation610, a secure communications link with an application server corresponding to the beacon is established. In an example, establishing the secure communications link includes providing an identity of the vehicle and attestation data to confirm the identity. In an example, the identity of the vehicle is linked to an identity of a user. In an example, the identity of the user corresponds to a set of user preferences for geographically linked applications.

In an example, a set of capabilities is provided as part of establishing the secure communications link. In an example, the indication that the application linked to the geographical area is available does not identify the application. Here, the method600may be extended to include receiving an application catalog based on the set of capabilities and the identity.

In an example, the method60is extended to include retrieving performance data for the application from the application catalog and evaluating a current state of the processing circuitry with respect to the performance data to determine that the application passes a threshold. Here, the application is executed in the protected environment in response to passing the threshold. In an example, the performance data includes expected hardware usage. In an example, evaluating the current state of the processing circuitry includes determining hardware usage of an already running application, combining the expected hardware usage of the application, and determining that available hardware is greater than the combination of the expected hardware usage and the hardware usage of the already running application.

At operation615, an application is received through the secure communications link.

At operation620, the application is executed in a protected execution environment of the vehicle without intervention by a user of the vehicle. In an example, the protected execution environment is bidirectionally secure with other hardware of the vehicle. In an example, the protected execution environment is a hardware implemented trusted execution environment (TEE).

In an example, the method600is extended to include detecting a removal trigger and removing the application. In an example, the removal trigger is at least one of expiration of a time period, movement beyond the geographical area, or passing beyond a resource use threshold.

The machine (e.g., computer system)700may include a hardware processor702(e.g., a central processing unit (CPU), a graphics processing unit (GPU), a hardware processor core, or any combination thereof), a main memory704, a static memory (e.g., memory or storage for firmware, microcode, a basic-input-output (BIOS), unified extensible firmware interface (UEFI), etc.)706, and mass storage708(e.g., hard drives, tape drives, flash storage, or other block devices) some or all of which may communicate with each other via an interlink (e.g., bus)730. The machine700may further include a display unit710, an alphanumeric input device712(e.g., a keyboard), and a user interface (UI) navigation device714(e.g., a mouse). In an example, the display unit710, input device712and UI navigation device714may be a touch screen display. The machine700may additionally include a storage device (e.g., drive unit)708, a signal generation device718(e.g., a speaker), a network interface device720, and one or more sensors716, such as a global positioning system (GPS) sensor, compass, accelerometer, or other sensor. The machine700may include an output controller728, such as a serial (e.g., universal serial bus (USB), parallel, or other wired or wireless (e.g., infrared (IR), near field communication (NFC), etc.) connection to communicate or control one or more peripheral devices (e.g., a printer, card reader, etc.).

Registers of the processor702, the main memory704, the static memory706, or the mass storage708may be, or include, a machine readable medium722on which is stored one or more sets of data structures or instructions724(e.g., software) embodying or utilized by any one or more of the techniques or functions described herein. The instructions724may also reside, completely or at least partially, within any of registers of the processor702, the main memory704, the static memory706, or the mass storage708during execution thereof by the machine700. In an example, one or any combination of the hardware processor702, the main memory704, the static memory706, or the mass storage708may constitute the machine readable media722. While the machine readable medium722is illustrated as a single medium, the term “machine readable medium” may include a single medium or multiple media (e.g., a centralized or distributed database, or associated caches and servers) configured to store the one or more instructions724.

In an example, information stored or otherwise provided on the machine readable medium722may be representative of the instructions724, such as instructions724themselves or a format from which the instructions724may be derived. This format from which the instructions724may be derived may include source code, encoded instructions (e.g., in compressed or encrypted form), packaged instructions (e.g., split into multiple packages), or the like. The information representative of the instructions724in the machine readable medium722may be processed by processing circuitry into the instructions to implement any of the operations discussed herein. For example, deriving the instructions724from the information (e.g., processing by the processing circuitry) may include: compiling (e.g., from source code, object code, etc.), interpreting, loading, organizing (e.g., dynamically or statically linking), encoding, decoding, encrypting, unencrypting, packaging, unpackaging, or otherwise manipulating the information into the instructions724.

In an example, the derivation of the instructions724may include assembly, compilation, or interpretation of the information (e.g., by the processing circuitry) to create the instructions724from some intermediate or preprocessed format provided by the machine readable medium722. The information, when provided in multiple parts, may be combined, unpacked, and modified to create the instructions724. For example, the information may be in multiple compressed source code packages (or object code, or binary executable code, etc.) on one or several remote servers. The source code packages may be encrypted when in transit over a network and decrypted, uncompressed, assembled (e.g., linked) if necessary, and compiled or interpreted (e.g., into a library, stand-alone executable etc.) at a local machine, and executed by the local machine.

ADDITIONAL NOTES & EXAMPLES

Example 1 is an apparatus, in a vehicle, for hands-free deployment of geographically linked applications, the apparatus comprising: a memory including instructions; and processing circuitry that, when in operation, is configured by the instructions to: detect, by a radio transceiver of a vehicle, a beacon, the beacon being a message that includes, an indication that an application linked to a geographical area covered by the beacon is available; establish a secure communications link with an application server corresponding to the beacon; receive, through the secure communications link, an application; and execute, the application in a secured execution environment of the vehicle without intervention by a user of the vehicle.

In Example 2, the subject matter of Example 1 includes, wherein the processing circuitry is configured to activate the radio transceiver to detect the beacon in response to entering the geographical area.

In Example 3, the subject matter of Examples 1-2 includes, wherein, to establish the secure communications link, the processing circuitry is configured to provide: an identity of the vehicle; and attestation data to confirm the identity.

In Example 4, the subject matter of Example 3 includes, wherein the identity of the vehicle is linked to an identity of a user.

In Example 5, the subject matter of Example 4 includes, wherein the identity of the user corresponds to a set of user preferences for geographically linked applications.

In Example 6, the subject matter of Examples 3-5 includes, wherein, to establish the secure communications link, the processing circuitry is configured to provide a set of capabilities.

In Example 7, the subject matter of Example 6 includes, wherein the indication that the application linked to the geographical area is available is independent of identification of the application, and wherein the processing circuitry is configured to receive an application catalog based on the set of capabilities and the identity.

In Example 8, the subject matter of Example 7 includes, wherein the processing circuitry is configured to: retrieve performance data for the application from the application catalog; and evaluate a current state of the processing circuitry with respect to the performance data to determine that the application passes a threshold, wherein the application is executed in the secured environment in response to passing the threshold.

In Example 9, the subject matter of Example 8 includes, wherein the performance data includes expected hardware usage.

In Example 10, the subject matter of Example 9 includes, wherein, to evaluate the current state of the processing circuitry, the processing circuitry is configured to: determine hardware usage of an already running application; combine the expected hardware usage of the application; and determine that available hardware is greater than the combination of the expected hardware usage and the hardware usage of the already running application.

In Example 11, the subject matter of Examples 1-10 includes, wherein the processing circuitry is configured to: detect a removal trigger; and remove the application.

In Example 12, the subject matter of Example 11 includes, wherein the removal trigger is at least one of expiration of a time period, movement beyond the geographical area, or passing beyond a resource use threshold.

In Example 13, the subject matter of Examples 1-12 includes, wherein the secured execution environment is bidirectionally secure with other hardware of the vehicle.

In Example 14, the subject matter of Example 13 includes, wherein the secured execution environment is a hardware implemented trusted execution environment (TEE).

Example 15 is a method for hands-free deployment of geographically linked applications, the method comprising: detecting, by a radio transceiver of a vehicle, a beacon, the beacon being a message that includes, an indication that an application linked to a geographical area covered by the beacon is available; establishing, by processing circuitry of the vehicle, a secure communications link with an application server corresponding to the beacon; receiving, through the secure communications link, an application; and executing, by the processing circuitry, the application in a secured execution environment of the vehicle without intervention by a user of the vehicle.

In Example 16, the subject matter of Example 15 includes, activating the radio transceiver to detect the beacon in response to entering the geographical area.

In Example 17, the subject matter of Examples 15-16 includes, wherein establishing the secure communications link includes providing: an identity of the vehicle; and attestation data to confirm the identity.

In Example 18, the subject matter of Example 17 includes, wherein the identity of the vehicle is linked to an identity of a user.

In Example 19, the subject matter of Example 18 includes, wherein the identity of the user corresponds to a set of user preferences for geographically linked applications.

In Example 20, the subject matter of Examples 17-19 includes, wherein establishing the secure communications link includes providing a set of capabilities.

In Example 21, the subject matter of Example 20 includes, wherein the indication that the application linked to the geographical area is available is independent of identification of the application, and wherein the processing circuitry is configured to receive an application catalog based on the set of capabilities and the identity.

In Example 22, the subject matter of Example 21 includes, retrieving performance data for the application from the application catalog; and evaluating a current state of the processing circuitry with respect to the performance data to determine that the application passes a threshold, wherein the application is executed in the secured environment in response to passing the threshold.

In Example 23, the subject matter of Example 22 includes, wherein the performance data includes expected hardware usage.

In Example 24, the subject matter of Example 23 includes, wherein evaluating the current state of the processing circuitry includes: determining hardware usage of an already running application; combining the expected hardware usage of the application; and determining that available hardware is greater than the combination of the expected hardware usage and the hardware usage of the already running application.

In Example 25, the subject matter of Examples 15-24 includes, detecting a removal trigger; and removing the application.

In Example 26, the subject matter of Example 25 includes, wherein the removal trigger is at least one of expiration of a time period, movement beyond the geographical area, or passing beyond a resource use threshold.

In Example 27, the subject matter of Examples 15-26 includes, wherein the secured execution environment is bidirectionally secure with other hardware of the vehicle.

In Example 28, the subject matter of Example 27 includes, wherein the secured execution environment is a hardware implemented trusted execution environment (TEE).

Example 29 is at least one machine-readable medium including instructions that, when executed by processing circuitry of a vehicle, cause the processing circuitry to perform operations comprising: detecting, by a radio transceiver of a vehicle, a beacon, the beacon being a message that includes, an indication that an application linked to a geographical area covered by the beacon is available; establishing a secure communications link with an application server corresponding to the beacon; receiving, through the secure communications link, an application; and executing, by the processing circuitry, the application in a secured execution environment of the vehicle without intervention by a user of the vehicle.

In Example 30, the subject matter of Example 29 includes, wherein the operations comprise activating the radio transceiver to detect the beacon in response to entering the geographical area.

In Example 31, the subject matter of Examples 29-30 includes, wherein establishing the secure communications link includes providing: an identity of the vehicle; and attestation data to confirm the identity.

In Example 32, the subject matter of Example 31 includes, wherein the identity of the vehicle is linked to an identity of a user.

In Example 33, the subject matter of Example 32 includes, wherein the identity of the user corresponds to a set of user preferences for geographically linked applications.

In Example 34, the subject matter of Examples 31-33 includes, wherein establishing the secure communications link includes providing a set of capabilities.

In Example 35, the subject matter of Example 34 includes, wherein the indication that the application linked to the geographical area is available is independent of identification of the application, and wherein the processing circuitry is configured to receive an application catalog based on the set of capabilities and the identity.

In Example 36, the subject matter of Example 35 includes, wherein the operations comprise: retrieving performance data for the application from the application catalog; and evaluating a current state of the processing circuitry with respect to the performance data to determine that the application passes a threshold, wherein the application is executed in the secured environment in response to passing the threshold.

In Example 37, the subject matter of Example 36 includes, wherein the performance data includes expected hardware usage.

In Example 38, the subject matter of Example 37 includes, wherein evaluating the current state of the processing circuitry includes: determining hardware usage of an already running application; combining the expected hardware usage of the application; and determining that available hardware is greater than the combination of the expected hardware usage and the hardware usage of the already running application.

In Example 39, the subject matter of Examples 29-38 includes, wherein the operations comprise: detecting a removal trigger; and removing the application.

In Example 40, the subject matter of Example 39 includes, wherein the removal trigger is at least one of expiration of a time period, movement beyond the geographical area, or passing beyond a resource use threshold.

In Example 41, the subject matter of Examples 29-40 includes, wherein the secured execution environment is bidirectionally secure with other hardware of the vehicle.

In Example 42, the subject matter of Example 41 includes, wherein the secured execution environment is a hardware implemented trusted execution environment (TEE).

Example 43 is a system for hands-free deployment of geographically linked applications, the system comprising: means for detecting, by a radio transceiver of a vehicle, a beacon, the beacon being a message that includes, an indication that an application linked to a geographical area covered by the beacon is available; means for establishing, by processing circuitry of the vehicle, a secure communications link with an application server corresponding to the beacon; means for receiving, through the secure communications link, an application; and means for executing, by the processing circuitry, the application in a secured execution environment of the vehicle without intervention by a user of the vehicle.

In Example 44, the subject matter of Example 43 includes, means for activating the radio transceiver to detect the beacon in response to entering the geographical area.

In Example 45, the subject matter of Examples 43-44 includes, wherein the means for establishing the secure communications link include means for providing: an identity of the vehicle; and attestation data to confirm the identity.

In Example 46, the subject matter of Example 45 includes, wherein the identity of the vehicle is linked to an identity of a user.

In Example 47, the subject matter of Example 46 includes, wherein the identity of the user corresponds to a set of user preferences for geographically linked applications.

In Example 48, the subject matter of Examples 45-47 includes, wherein the means for establishing the secure communications link include means for providing a set of capabilities.

In Example 49, the subject matter of Example 48 includes, wherein the indication that the application linked to the geographical area is available is independent of identification of the application, and wherein the processing circuitry is configured to receive an application catalog based on the set of capabilities and the identity.

In Example 50, the subject matter of Example 49 includes, means for retrieving performance data for the application from the application catalog; and means for evaluating a current state of the processing circuitry with respect to the performance data to determine that the application passes a threshold, wherein the application is executed in the secured environment in response to passing the threshold.

In Example 51, the subject matter of Example 50 includes, wherein the performance data includes expected hardware usage.

In Example 52, the subject matter of Example 51 includes, wherein the means for evaluating the current state of the processing circuitry include: means for determining hardware usage of an already running application; means for combining the expected hardware usage of the application; and means for determining that available hardware is greater than the combination of the expected hardware usage and the hardware usage of the already running application.

In Example 53, the subject matter of Examples 43-52 includes, means for detecting a removal trigger; and means for removing the application.

In Example 54, the subject matter of Example 53 includes, wherein the removal trigger is at least one of expiration of a time period, movement beyond the geographical area, or passing beyond a resource use threshold.

In Example 55, the subject matter of Examples 43-54 includes, wherein the secured execution environment is bidirectionally secure with other hardware of the vehicle.

In Example 56, the subject matter of Example 55 includes, wherein the secured execution environment is a hardware implemented trusted execution environment (TEE).

Example 57 is at least one machine-readable medium including instructions that, when executed by processing circuitry, cause the processing circuitry to perform operations to implement of any of Examples 1-56.

Example 58 is an apparatus comprising means to implement of any of Examples 1-56.

Example 59 is a system to implement of any of Examples 1-56.

Example 60 is a method to implement of any of Examples 1-56.