Federated automated interoperation between venues and autonomous resources

Abstract

In some embodiments, the disclosed subject matter relates to communication and negotiation between autonomous entities or vehicles and a network of communication resources within a smart venue. Communication resources may include entry beacons, landing beacons, or navigation beacons, as well as building infrastructure services. Instead of having negotiation of guidance, entry, and other authorization tasks or services scheduled by a centralized server, negotiation of guidance, entry, and other authorization tasks or services can be performed in a distributed manner while on the road or near communication resources. Other embodiments are described and claimed.

Description

[0001] Priority claim

[0002] This patent application claims the benefit of priority to U.S. patent application No. 15 / 694,250, filed September 1, 2017, which is incorporated herein by reference in its entirety. Technical Field

[0003] Embodiments of the present subject matter relate generally to autonomous traversal of locations, and more particularly, but not limited to, interoperation between autonomous and robotic resources and places. Background Art

[0004] There are various mechanisms for navigating public spaces by autonomous devices, vehicles, drones, or robots (also referred to herein as automatons, autonomous devices, and autonomous vehicles). Navigation typically relies on the use of machine vision, light detection and ranging (LiDAR), and mapping technology, as well as identification of locations by sending echo messages (pings) or identification of visual landmarks to nearby access points. In current systems, routes to locations can be pre-marked by autonomous devices with limited adaptability to changing conditions. A large amount of care and supervision, usually performed by personnel, is necessary for autonomous devices to complete tasks. For example, package delivery by drones is being extensively researched, and Amazon is developing a prototype. Marble Robotics and Yelp Eat24 are developing a system for food delivery by semi-autonomous vehicles in San Francisco. However, in current systems, throughout the delivery, personnel must monitor or guide the drone or robot. Furthermore, delivery is typically to an external location, and autonomous vehicles cannot enter buildings and cannot navigate to the final delivery.

[0005] In existing systems, autonomous devices are controlled from a centralized server or management and control device. Consequently, autonomous devices typically receive instructions for their entire route or mission from the centralized server and rely on the server for up-to-date information for scheduling. Centralized management of autonomous devices reduces adaptability to changing conditions and relies on the centralized server for complete information at startup (e.g., at the start of an activity or mission). If conditions change while on the road and the link between the autonomous device and the centralized server is lost, the autonomous device may fail in its mission. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] In the drawings (which are not necessarily drawn to scale), like numerals may describe similar components in different views. Like numerals with different letter suffixes may represent different instances of similar components. Some embodiments are illustrated by way of example and not limitation in the figures of the accompanying drawings, in which:

[0007] Figure 1 is a diagram illustrating a system for joint automated interoperation between a site and robotic and autonomous resources according to an embodiment;

[0008] Figure 2 is a diagram showing a method according to an embodiment of the present invention. Figure 1 A diagram of the automaton flow performed by the example system shown in ;

[0009] Figure 3 shows entity state transitions throughout a delivery task according to an embodiment;

[0010] Figure 4 is a flow chart illustrating a method for federated automated interoperation between venues and autonomic resources according to an embodiment; and

[0011] Figure 5 is a block diagram illustrating an example of a machine upon which one or more embodiments may be implemented. DETAILED DESCRIPTION

[0012] In the following description, for the purpose of explanation, various details are set forth in order to provide a thorough understanding of some example embodiments. However, it will be apparent to one skilled in the art that the present subject matter can be practiced without these specific details or with slight modifications.

[0013] An embodiment of the present subject matter is a system and method for joint automated interoperation between a venue and robotic entities / autonomous resources. In an embodiment, a robot can coordinate and interact with one or more cloud services and services provided by a smart venue to enable distributed interoperation and control of the robot or the robot's mission. The mission or purpose may be the pickup or delivery of a package; an intermediate purpose such as recharging or receiving maintenance; or a completed purpose such as returning to base or billing a customer. Successful completion of a mission may require several intermediate tasks and be affected by localized events. However, as opposed to having all intermediate tasks controlled in advance by a centralized server, an embodiment interoperates with venues, beacons, and cloud servers and can react to localized events at each point in the mission to enable localized control and management at various points along the way. Furthermore, management of the robot may be more predictive in nature than merely reactive.

[0014] References throughout this specification to "one embodiment" or "an embodiment" mean that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present subject matter. Thus, the appearances of the phrases "in one embodiment" or "in an embodiment" in various places throughout this specification are not necessarily all referring to the same embodiment, nor are they necessarily referring to different or mutually exclusive embodiments. Features of various embodiments may be combined in other embodiments.

[0015] For purposes of explanation, specific configurations and details are set forth to provide a thorough understanding of the subject matter. However, it will be apparent to one of ordinary skill in the art that the embodiments of the subject matter can be practiced without the specific details presented herein, or in various combinations as described herein. Furthermore, well-known features may be omitted or simplified to avoid obscuring the embodiments. Various examples may be given throughout this specification. These are merely descriptions of specific embodiments. The scope or meaning of the claims is not limited to the examples given.

[0016] Since autonomous vehicles and drones have mastered navigation in public outdoor spaces, a significant limitation is the lack of ability to autonomously navigate to destinations within buildings or spaces that are less than public (e.g., no public mapping is available). The embodiments described herein extend autonomous traversal to smart places. If the goal is to deliver or pick up a commission or perform other automated destination services by visiting a robotic entity, simply reaching a specific location by road may not be enough. An autonomous robotic vehicle may have to enter a building, find an elevator, an entry door, etc., and return. A drone-based delivery service may need to find a specific location to drop a package off at the porch of a specific apartment, and may need to recharge to fly or navigate back to the main base. Existing technology is based on maps. However, most maps lack details such as internal building structures, landing zones for drones, consumer delivery preferences, etc. In addition, static maps may not have the latest details such as construction work, access restrictions, temporary obstacles, weather conditions, etc.

[0017] Autonomous trucks can alleviate much of the tedium and inefficiencies of driving for human drivers. However, after the vehicle has arrived at its destination, the tedious task of delivering or picking up the item still remains, negating much of the benefit of autonomous driving. A human agent will do more than just reach the destination. For example, the agent will enter the building, find the elevator, select the office entrance door from a possible number of doors, obtain / deliver different forms of confirmation, and then return to the main base. The agent can also perform pre-directed actions (such as ringing a bell) to alert the target. In at least one embodiment, the autonomous device can navigate from the main base to the final destination within the building or venue for delivery or pickup. In embodiments, a drone can navigate to a landing point within or above the building or venue.

[0018] Previous solutions might consider automating the pickup / delivery task by pre-programming a route from a vehicle to a curbside parking location at a business. This solution presents some obvious difficulties, such as: (a) the interior layout of a building or campus may be obscured for privacy or security reasons; (b) the delivery endpoint itself is variable due to maintenance or reallocation; (c) there may be multiple endpoints that share a delivery address, but each endpoint is designed to handle different consignments; and (d) different routes and modes need to be used for different types of shipments.

[0019] Another possible solution could include using sophisticated tag reading devices and human natural language processing entities to enable autonomous robotic vehicles to perform to a similar level of versatility, but this would likely be a very expensive and complex proposition and insufficient to avoid training and navigation errors upon mass adoption. Furthermore, that possible solution would not cover use cases for devices with extended capabilities (can fly) or limited capabilities (e.g., “can’t use stairs”).

[0020] Figure 1 is a diagram illustrating a system 100 for joint automated interoperation between a venue and robots and autonomous resources, according to an embodiment. In an embodiment, various services may be available via a cloud network 110. In an embodiment, a building discovery cloud service (BDCS) 111 may be available on cloud network 110. BDCS 111 may communicate with autonomous devices 180, such as a robot 180A with a cart or an autonomous cart 180B. Drones 170 may also be used for scheduling and communicate with BDCS 111. BDCS 111 may have mapping information to assist in routing autonomous machines 170 or 180 to smart venues 120. Customer delivery / pickup preferences and building infrastructure information may be stored in a database coupled to a building infrastructure cloud service (BICS) 112. For example, robot 180A may need to charge sooner than cart 180B. Therefore, knowing whether a venue 120 has a charging station 190 or not may be useful for appropriate scheduling. In an example, a schedule for a venue 120 may include two deliveries to two customers. Each customer may have a different level of SLA (Service Level Agreement).The initial scheduling may be predictive so that delivery to both customers will meet their various SLAs.

[0021] BICS 112 can be accessed on the cloud to provide information about building infrastructure or customer preferences. BICS 112 can provide specific information about access locations and travel times between two points in a building based on the type of delivery device / vehicle, customer or building management preferences for delivery times and locations, availability of signing authorities, and the like. In embodiments, BICS 112 can also include information about transient events, such as elevator failures. Information from BICS 112 can assist autonomous vehicles or initiators in planning. For example, BICS 112 provides operating hours for various entrances or drone landing pads, service elevators, and the like. Plans to meet goals can incorporate this information in scheduling service devices and when to initiate service. When BICS 112 is unavailable, service devices (e.g., drones, robots, or autonomous vehicles) may need to rely on stored or cached information and default assumptions until the devices are closer to the smart venue 120.

[0022] A cross-section of a smart site 120 is shown to illustrate various features of the site or building. It will be understood that many variations in the architecture and location of resources can be implemented in practice. For example, in an embodiment, a landing platform 130 for a drone 170 is shown, which has a landing beacon 160. In an embodiment, the smart site 120 may have multiple platforms or landing spots for drones (such as on a rooftop, an intermediate balcony, a terrace), or none at all. Each landing spot may have its own beacon. An entry beacon 140 may be used to negotiate entry into the site 120 by an automated machine. Additional beacons 150 may be located on each floor, or more than one additional beacon 150 may be located on each floor to assist in internal site navigation or authentication / authorization to secure locations on the site.

[0023] In an embodiment, once an automaton has arrived at or entered a smart site 120, a building infrastructure local service (BILS) 122 may be available to coordinate with the automaton. The BILS 122 may provide the same functionality as that provided by the BICS 112 as discussed above, or may provide reduced functionality. In the event that cloud services are unavailable, the BILS 122 may provide full or limited capabilities.

[0024] Figure 2 is a diagram showing the embodiment of the Figure 1A diagram of the automaton flow performed by the example system 100 is shown. Notations [1] and [2] illustrate two different use cases for the automaton's tasks, each discussed separately. For example, use case [1] illustrates a device originating from a base of operations when a BDCS 111 is available. Use case [2] illustrates a device originating from a base of operations when no DBCS 111 is available for coordination. Other differences in the use cases will be described below.

[0025] In an embodiment, an automaton interacts with resources in a smart building or smart place 120 to expose discoverable services that support bidirectional exchange of information and use by autonomous entities. In both use cases ([1] and [2]), the autonomous entity 170, 180 begins its interaction with the smart place 120 through a discovery process. This discovery may be referred to as the "point of origin (PofO)". When an autonomous entity enters a building or initiates services for these autonomous entities from different locations, the PofO may be different based on the initial connection acquisition. For example, in use case [1], the automaton may receive guidance and customer SLA or other task information from the BDCS 111. Once the automaton receives the building and location information, it may determine the travel or mid-trip task and the selection of the delivery method. Once the automaton arrives near the smart place 120, it may negotiate or communicate with the BILS 122 to determine the next steps to complete the task. In an embodiment, the BICS 112 may be used for high-level coordination during the journey. In another embodiment, the automaton may communicate with the entry beacon 140 instead of the BILS 122. For example, for a ground vehicle 180, the robot can negotiate with an entry beacon 140 or directly with the BILS 122 for entry and instructions on how to navigate to the final destination. In another example, a drone vehicle 170 with a package 171 can negotiate or communicate with a landing beacon 160 to navigate to a designated landing site 130. In various examples, the BILS 122, entry beacon 140, landing beacon 160, interior beacon 150, or a combination of one or more of these resources (collectively referred to as venue communication resources) can provide authorization and authentication for entry and exit of the robot 170, 180 to interior locations or landing pads within the smart venue 120. The venue communication resources 122, 140, 150, 160 can provide information or events to the robot regarding unexpected changes or updates to route information (e.g., due to an elevator outage or high wind conditions prohibiting the drone 170 from landing on a rooftop). Thus, the required route travel and intermediate tasks required to complete the mission can be dynamically changed and adapted. In embodiments, authentication can be transmitted via a wireless link, such as a radio operating in accordance with the IEEE 802.xx series of standards (e.g., 802.11 or 802.15.1, etc.), near field communication (NFC), RFID link, or other wireless communication link. In embodiments, a physical communication link may be required, for example, for higher security areas. In such cases, the autonomous device can be temporarily physically connected to the communication link, or a token, cable, or other temporary physical connection can be inserted to initiate authentication or authorization of access.

[0026] In use case [2], BICS 112 may be available so that the robot can plan intermediate missions and perform predictive analysis before getting close to the smart place location. For example, BICS 112 may alert the robot base that there are localized strong winds and all drone landing locations 130 are closed. Even if typical deliveries to these places 120 are by drone 170, the base may change the delivery method to ground operations. In another example, the delivery provider may have another operating base closer to the place 120. In this case, the first leg of the trip may be performed by drone 170 to the second operating base, and then the delivery item may be handed over to the autonomous ground vehicle 180 for the next leg of the trip. Once the delivery robot is closer to the place 120, further instructions may be conveyed by BILS 122.

[0027] The beacons 140, 150, 160 may be connected via a local area network (LAN) within the premises 120. Cloud services (111, 112, 122), beacons (140, 150, 160), robots (170, 180), and servers for base operations (not shown) may be communicatively coupled in various combinations via a wide area network (WAN). It will be understood that in embodiments, not all cloud services or beacons are required to provide the functionality described herein, and implementations may provide various optional services or features. During a discovery process for identifying parameters related to delivery or pickup targets, endpoint communications with building infrastructure services 112 or 122 and communication methods (e.g., LAN or WAN) through beacons 140, 150, or 160 may be identified for further invocation of various services (such as charging 190).

[0028] In embodiments, an autonomous vehicle may receive only partial information / guidance from one stage to the next (e.g., starting with directions to the entrance door, then providing directions to the elevator, etc.). Communication devices or services (e.g., cloud or local services, beacons, etc.) at each stage of the journey can provide the entity and building infrastructure with the opportunity to dynamically adjust the route, or revisit and optimize what the vehicle can do based on conditions / events in the public space and the building. Service requirements can be broken down into the building's intelligent infrastructure 120 and organized so that only a portion of the route and requirements are delivered to the autonomous entity at any given moment. This means that the entire service contract can be managed and orchestrated by the intelligent infrastructure 120, allowing it to modify subsequent operations to remedy or adjust if incremental service goals are missed. Furthermore, this allows for efficient management of autonomous entities, minimizing power consumption based on the minimal pre-programming / training required to handle a portion of the overall service outline. In other words, autonomous vehicles can gain just-in-time and just-enough knowledge to advance incrementally.

[0029] The embodiments herein describe how to deliver goods and services quickly, securely, and adaptively to endpoint constraints and requirements with minimal or no human intervention, and allow for scalable linking into other services at the endpoint. Embodiments may be designed for versatility, low cost, and complexity, and for intelligent, scalable, and standardized interoperation between intelligent autonomous access entities (e.g., robots, robotic carts, drones, etc.) at destination locations and interactive Internet of Things (IoT) infrastructure. Embodiments may rely on trusted machine-to-machine (M2M) or peer-to-peer (P2P) communications for such interoperation to achieve dynamic adaptability and secure operation.

[0030] The described protocol layer on top of existing beacon technology is used to facilitate IoT / robotics, but embodiments may also beneficially target assistive technologies for people with disabilities.

[0031] Embodiments may use radio frequency identification (RFID) tags and devices and beacons as a base mechanism, but may also provide higher level services on top. Embodiments may be extended with smart beacons that can relay updates to site policies and manage the status of service level agreements (SLAs) for service delivery. Building infrastructure services 112, 122 may capture the current status for traceability and tracking, and receive information about changes in the delivery mechanism, such as speed-ups, slow-downs, delays, pauses, rerouting, etc. If the SLA is missed or changed by the principal (e.g., if the recipient is late arriving at the delivery location), embodiments may interact with the SLA information and delay the delivery by a certain time factor.

[0032] Distributing (e.g., syndicating) control and instructions at different stages of a journey to cloud and localized devices that are more likely to have the latest information (e.g., just-enough knowledge and just-in-time principles) about a particular stage in the journey can save power used to deliver the vehicle and customize and improve access security. Operational syndication enables new credentials, logging, and route evaluation / replanning at each intermediate stage. Beacons can be used for self-direction.

[0033] Figure 3 1 shows the entity state transitions throughout the entire service goal or task according to an embodiment. Figure 2 The component description shown in Figure 3301. Once a service task has been requested (e.g., pickup, delivery, special service, etc.), the robot can be placed into the discovery state 301. The module or logic for discovery 301 can allow for interaction between the robotic system and a building discovery service to discover information about the building or service location that will assist in the dispatch service. A combination of public navigation sources, building discovery cloud services, and building infrastructure cloud services can be used in the dispatch process.

[0034] A known address can be provided to the BDCS 111 via an application programming interface (API), where it can be converted into geographic (or spatial with 3D) coordinates or street addresses for access to the smart venue's API endpoint. Interaction with the BDCS 111 can occur at base headquarters when planning services and is used to select the appropriate type of autonomous platform. The BDCS 111 can also provide details to the BICS 112 or BILS 122 by providing a known endpoint accessible via the network 110 and a defined API that supports lookups of geographic coordinates or street addresses. The BDCS 111 can serve multiple buildings and provide functionality similar to a Domain Name System (DNS) server. Similar to DNS, the BDCS 111 can be a distributed and federated service. For example, in the case of "certified mail," requiring a specific person to accept delivery, rather than just delivery to an address, additional negotiations may occur to plan the delivery, including agreement on time and location. BICS / BILS (112 / 122) may provide the locations of different entrances, depending on the delivery method, capabilities of the autonomous vehicle, and type of service, as well as instructions for finding the entrance beacon 140 to obtain further details. Discovery 301 may also include additional telemetry, real-time changes, events, hazards, etc., as reported by autonomous vehicles as they progress on their respective transactions and paths.

[0035] The entry beacon 140 may use a The API endpoints are broadcast to a certain range using common radio frequency (RF) protocols such as the RFID standard. It is expected that autonomous vehicles will use street addresses or coordinates to arrive in the vicinity of the entry beacon 140, where the approximate geographic location can be retrieved from easily accessible mapping services. The entry beacon 140 can allow any device to authenticate at the protocol level (or "open") via a predefined or broadcasted connection point for authentication before using any other services. The beacons 140, 150, 160; the BDCS 111, and the BICS / BILS (112 / 122) may follow various standards (e.g., OCF, OpenFog, etc.) that declare specific protocols at various levels and define APIs, data models, and request ontologies.

[0036] In an embodiment, the method of discovering phase 301 may result in an API endpoint and may use a communication method that can be used by autonomous entities (e.g., Data Distribution Service (DSS) with control, Pub / Sub with control, etc.) for further activities. The API endpoint that implements the build service may:

[0037] Hosted in the cloud network 110 (e.g., BICS 112);

[0038] Is local and available through common RF protocols (e.g., BILS 122) and can operate independently of the network 110 and provide security by limiting access using proximity, geographic, or geo-fencing restrictions;

[0039] provided by a local / edge cloud (such as Fog provided by the OpenFog Consortium); or

[0040] A combination of cloud services and local services.

[0041] The communication method between an autonomous entity and one or more beacons or service resources can be one of the following:

[0042] Locally "here" (via an established connection to a beacon, no network 110 connection is required, but a LAN may be used);

[0043] locally "in situ" (e.g., via another beacon at a different location); or

[0044] The cloud (e.g., over the public internet or a private network, and may require authentication on each request).

[0045] In embodiments, for security, convenience, and high availability, some services may be better suited to being available only from a local connection. This eliminates reliance on public network 110 connectivity. For security reasons, services such as opening a door or calling an elevator may prefer to use a local interface. Using local communication methods can also serve the "just enough knowledge" principle. For example, in embodiments, only robots within the beacon's RF signal area will be able to obtain details of BICS / BILS 112 / 122 information. BDCS 111 may also require authentication before sharing details, providing an additional level of security.

[0046] In an embodiment, BDCS 111 can solve the inverse task by converting the actual location into a set of BICS 112 / BILS 122. This can be useful in failure scenarios (e.g., finding an exit from a site when BILS 122 is inaccessible) and for handovers between sites and smart city infrastructure. Location-based federation enables extension of a site to any location, thus providing smooth handovers between locations.

[0047] The automaton can interact using the API and enter the authenticated state 303. The API endpoint can provide access to the service and implement authentication, authorization and accounting, traceability / tracking, and service status registration. The authentication policy may require:

[0048] Mutual authentication, similar to mutual Transport Layer Security (TLS), when the IoT / robotic authentication robot is connecting to a valid building endpoint and the building authentication service request is a valid / authorized service;

[0049] Authentication for IoT / robot connections;

[0050] Connecting IoT / Robot identification for applications where security is not required (e.g. for public spaces); or

[0051] Just-in-time operation (e.g., opening a door only when the robot is near it, not before). Authentication may include geofencing operations, with light authentication when the robot is far away, and stronger authentication when the entity is nearby. For example, authentication may be required to be performed at a specific point using a local method via a beacon 140, 150, 160 with a limited range, and authentication may be performed by providing a token. In embodiments, full authentication may be performed in advance to avoid waiting times. Authentication component 303 may be aware of impending authentication events.

[0052] Mutual authentication can be used to ensure that devices are legitimate. For example, an autonomous vehicle can provide forward authentication that the autonomous vehicle is actually the identity it is presenting (e.g., such as a specific delivery service) by providing authentication from the autonomous vehicle to (multiple) venue communication resources (e.g., beacons and infrastructure services). Reverse authentication from the venue communication resources to the autonomous vehicle can be used to ensure that the autonomous vehicle is actually communicating with the appropriate building infrastructure and not a false service that may mislead the vehicle. Another use of mutual authentication is as a basis for billing. Some of the building services may be free (e.g., no additional monetary cost), but other building services may require a payment agreement (such as for use of charging stations, use of fast / priority elevators for shortened delivery times, use of special package lockers, such as those with refrigeration or heating capabilities, delivery to specific areas of the building, or use of specific delivery methods (such as drones, etc.)).

[0053] During authentication, credentials may be exchanged and the autonomous vehicle may be given a token, providing the autonomous vehicle with the ability to locate other APIs, providing the autonomous vehicle with instructions to follow the entry beacon, etc. In an embodiment, the entry beacon 140 may consolidate the credential exchange and forward the issued token, etc., rather than communicating with the BICS / BILS 112 / 122.

[0054] Once authenticated, the autonomous vehicle may proceed to the Negotiation and Service Target state 305. At this point, the autonomous vehicle has been authenticated and authorized, and is linked to the entry beacon 140, 150 "origin." The service target may be received by the BICS / BILS 112 / 22, which may optimize deployment parameters, establish negotiation protocols with other existing services and transactions, and resolve events and sequence brokers. When the autonomous vehicle arrives at the entry portal, a first instruction directs the autonomous vehicle to the first broker in a sequence of brokers (such as beacons), with which the autonomous vehicle may communicate as it proceeds through the premises toward its final destination. The brokers may serve as a communication path to the building infrastructure services (BICS / BILS 112 / 122) locally or via the cloud. In an embodiment, the brokers may utilize wireless coverage in the premises (e.g., LTE / 5G, etc.) to maintain continuous contact. In another embodiment, the intermediary can be a limited-range beacon that provides access to the BICS / BILS 112 / 122 only when the vehicle is in close proximity. The intermediary can maintain continuous contact with the service goal management system, which actively manages the service level agreement associated with the transaction and modifies / updates the next intermediary with new or additional instructions if modifications are required.

[0055] Using bidirectional transmission of information between autonomous vehicles and various portals within the venue 120 (e.g., venue communication resources), autonomous vehicles can also request and receive enhanced building services, such as recharging, access to internet or broadband communication hotspots, and use of amenities for an additional fee. The venue 120 can be viewed as a collection of collaborative domains, each of which can coordinate navigation within itself and also collaborate with common services during the autonomous vehicle's use of common amenities (elevators, conduits, etc.). Other beacons can guide autonomous vehicles to building venues, parking lots, recharging points, etc.

[0056] In an embodiment, the BICS / BILS 112 / 122 may negotiate with a semi-autonomous device, such as a semi-automated wheelchair for a disabled person, who interacts with the venue 120 to open doors, call elevators, plan routes within a building, and the like.

[0057] Once the autonomous vehicle has negotiated steps to satisfy the service goals, the navigation and service expansion component 309 may be used to assist in satisfying the intermediate goals. For example, the service provided by the venue 120 may be a navigation service (e.g., providing directions to a specific room, unit, or location in a building) to implement the earlier negotiated service.

[0058] In an example, there may be multiple delivery / pickup points for the same target person / office, depending on security, confidentiality, or physical content. The protocol for communication may include a communication method that allows the autonomous vehicle to interact with the building services 112 / 122 to (a) provide information; (b) receive questions that the autonomous vehicle may not have answers to, in which case, contact the sender to obtain more information not included in the shipping information so that those questions can be answered; or (c) receive directions that can be calculated in real time by the building services 112 / 122 to guide the autonomous vehicle to the optimal drop-off point.

[0059] There may be multiple paths to the same delivery or pickup point, and the path taken is similarly dependent on the above. For example, if a service elevator at the rear of the facility is in normal travel mode to another floor but is temporarily out of service, the building infrastructure services 112 / 122 can provide this information to the autonomous vehicle during negotiation 305 or during navigation 309 if the information has changed since entering the facility 120.

[0060] In an embodiment, in addition to the confirmation of delivery as already described, additional signatures may be required. These additional signatures can be used to provide end-to-end confirmation and time stamping to ensure the chain of custody of important items.

[0061] Depending on the nature of the goods being delivered, specific locations may be suggested, such as a fixed parcel locker, a post office box or a parcel refrigerator / cold room or heated location (e.g. food or medicine deliveries).

[0062] During navigation to the next destination in the facility 120, other localized beacons 140, 150, 160 can be used to achieve precision in internal navigation. In another embodiment, the autonomous vehicle can be given local point-to-point directions / maps and other navigation aids as it proceeds. By providing just-in-time navigation to the autonomous vehicle, it is unnecessary to store long and complex instructions locally in the autonomous vehicle, thereby allowing for reduced memory in the autonomous vehicle and thus saving costs.

[0063] The venue 120 can provide customized navigation / assistance that may be needed (e.g., if the autonomous vehicle is transporting confidential content, the autonomous vehicle may require a special route). The guidance provided to the autonomous vehicle may include scripts for communicating with other beacons / APIs and may provide a sequence of operations based on known building maps and policies.

[0064] For certain types of deliveries, it may be necessary for the vehicle to navigate to resources nearby that further provide events to services that rely on the completion of the delivery. This may be referred to as event chaining 315. For example, someone may initiate a completion event that indicates the start of a delivery service, especially at a remote, unmanned office. An example of this might be the activation of a process such as placing the delivered vial into a cryogenic chamber and starting the cryogenic operation (if not already started). The autonomous vehicle may be appropriately instructed by the local service to deliver such a completion event for activation. Similarly, the autonomous vehicle that receives the package may be instructed by the local service to both generate an event and consume another event; for example, the consumed event may be the receipt and action in accordance with specific instructions to proceed with the pickup transport.

[0065] While providing guidance, some pre-authorization can be performed to allow other beacons to accept requests from the autonomous vehicle. For example, an elevator control can have a policy that allows the elevator to only move to predetermined floors of the site 120 for autonomous vehicles, thereby improving security. This security can be further enhanced by requiring the use of a token, etc.

[0066] In embodiments, additional special service bootstrapping 307 may be available. Traceback and tracking operations can be used to trace and track the autonomous vehicle's progress through the service while it is on the road. This ensures that the SLA will be met based on the contractual agreement. Traceback and tracking can also be used to dynamically modify the SLA if the initiator / client so chooses. Furthermore, if necessary, the traceback and tracking operations can facilitate changes / remediation to ensure the SLA is met. This can be a data point or an input to the system.

[0067] In this example, an autonomous vehicle is required to deliver a package to a recipient, R. Therefore, tracking recipient R within a building can facilitate proper delivery. The autonomous vehicle can ask the building service, "Please tell me if recipient R is currently at the venue 120, and if not, please tell me when recipient R will be there." The building service within the venue can use various sources to ascertain information (such as parking data and a software agent running on the recipient's device (such as a smartphone)) to obtain the actual location of recipient R, notify the recipient, forward the actual location to the autonomous vehicle, and use the venue as a broker to negotiate the delivery with the recipient.

[0068] Another special service that can be provided is charging. Autonomous vehicles can enter buildings for charging purposes, either in conjunction with pickup or delivery, or independently. In an example, an autonomous vehicle can be dispatched to deliver a package to a location 120, with the prediction that recharging will be necessary after completion. However, the location 120 may not have a charging station, but an adjacent smart building (not shown) may have this capability. In this case, two goals can be dispatched at the main base headquarters, such as (1) delivery of the package and (2) recharging. Instructions to complete the recharging can be dynamically provided by the cloud service after the delivery is completed. When the location 120 has the capability to provide recharging services, the BILS 122 can direct the vehicle to the recharging point if requested.

[0069] In embodiments, billing and accounting services may be provided as special services. To support potential revenue sharing, usage of specific services within venue 120 may be billed. For example, a charging station for autonomous vehicles or use of a cold room for food storage may require a service fee. In this example, the initiator may be billed for charging, while the recipient may be billed for use of the cold room or package locker. Some services may be charged separately, free for a limited time, etc.

[0070] The delegation state 311 may require negotiation between the building and the delivery resource. For example, drone 170 may have been assigned a package 171 for delivery at landing pad 130. Once drone 170 arrives at site 120, it may learn that landing pad 130 is no longer operational for the day. In this case, drone 170 may need to delegate the delivery to ground vehicle 180 or provide an alternative delivery location. Delegation module 311 can communicate with navigation service 309 to be directed to an alternative landing point or to hand over package 171 to ground vehicle 180. In some cases, this may require landing at a nearby location to perform the handover. Delegation 311 can coordinate directly with other entities at 313 or communicate via navigation service extension 309. During the delegation process, the environmental conditions of site 120, SLA requirements for on-time delivery, and other factors may be taken into consideration. In this example, delegation may result in delayed delivery. Depending on the SLA, this delayed delivery may trigger a refund to the recipient or anyone who scheduled the service target (and paid for the service target). In this case, a billing will be made in special service 307 for prompt refund.

[0071] Coordination with other entities 313 may include negotiations with other delivery agents or vehicles to ensure on-time and safe delivery. For example, the originating party may realize that its in-use vehicle is overscheduled or scheduled to capacity. In this case, negotiations may be conducted with another provider's autonomous vehicle to transfer delivery to another agent. In some cases, delivery may even be transferred to a semi-autonomous vehicle or a human agent. Communication with other delivery agents may be peer-to-peer or via a cloud service. Accounting for changes in agents or vehicles may be performed through accounting functions such as special services 307.

[0072] It will be understood that the server may be provided by a single service or computing module on the server device. Figure 3 The process shown may be provided by distributed services / modules Figure 3 The processes shown can be provided locally by one or more server devices or remotely via one or more cloud services. Figure 3 The process shown. It will also be understood that although the embodiments described herein do not utilize a centralized server for command and control of autonomous devices, the provider or initiator of the service target may have a central server or distributed server maintained at an operations base or located remotely and accessible via a network to provide management functions and robot inventory, maintenance, and initial scheduling. The provider may directly utilize the BDCS 111 and use it in conjunction with various business functions, or provide business and management functions on separate servers.

[0073] Embodiments can provide various services as described herein in various combinations. For example, if BDCS 111 is unavailable, a public map can be used to guide the autonomous vehicle to the vicinity of the approach location 120 before communicating with the entry beacon 140 or BILS 122. If BICS 112 is available, the autonomous vehicle can communicate with BICS 112 before leaving the base of operations or while en route to obtain more specific delivery information. In an example, and consistent with the just-in-time aspect of the system, BICS 112 can provide instructions regarding which entryway to use, and further instructions can be provided at that entryway by the entry beacon 140 or BILS 122.

[0074] Although alternative embodiments may operate with all or only a subset of the components and resources discussed herein, some common elements may apply to multiple embodiments. For example, the identification and enumeration of available services may be performed by Figure 1-Figure 2 Access control to locations and entryways in the venue 120 (including special items such as package lockers or charging station areas) can be provided using various techniques for authentication, authorization, recording and accounting. Billing details for the services can be provided to the accounting module. Dynamic navigation and routing can be adaptive to the requirements of the vehicle or venue, or defined in an SLA. After the autonomous vehicle has connected to communication resources within the venue 120, path optimization can be adaptive and provided or suggested by localized resources. Entry beacons, landing beacons and interior beacons can be used for precise indoor navigation and can provide navigation information directly or provide precise location information that can be used for navigation in conjunction with the BILS 122.

[0075] With appropriate authentication and authorization, programmable access to site infrastructure (e.g., entryways, elevators, rooftop corridors, doors, etc.) can be available. Authorization can be temporary in nature and valid only for a limited time when delivery is expected. In addition, additional security measures can be standard policies and procedures at some locations. For example, if a package must be X-rayed or otherwise inspected before final delivery, the entry beacon 140 or BICS 112 / BILS 122 can first direct the autonomous vehicle to an X-ray room or inspection room. For example, enhanced services such as charging stations, lockers, dedicated elevators, or lifts can be provided, or for an additional fee, secure corridors can be used for faster route travel. Billing and accounting details can be forwarded to an accounting module or device with access to customer information, SLA details, billing rules, etc. SLA status, traceability and tracking, and estimated time to complete service goals can be monitored and stored for later use and analysis.

[0076] In an embodiment, delegation from one delivery mode to another is available. For example, drone 170 can hand over package 171 to ground vehicle 180 waiting on landing pad 130. Ground vehicle 180 can then complete the final delivery or hand over package 171 to another autonomous entity (such as another vehicle or conveyor belt (not shown)) for delivery. When the delivery location within site 120 is dynamic or inherently changing, delivery to other non-stationary objects can be performed through negotiation with the recipient.

[0077] As discussed above, autonomous entities do not need to be pre-trained with pre-learned training, expensive cognition, or pre-programmed with entire decision trees for every possible but unpredictable event. Instead, autonomous entities acquire new information at various stages while executing service objectives and can learn and adapt. Adaptation can come from just-in-time, customized knowledge received by the autonomous entity from cloud or localized resources. Consequently, power consumption, safety / security risks, and errors can be minimized.

[0078] In general, embodiments can address the coordination problem for interactions between autonomous entities and venue infrastructure. Embodiments can provide a means for setting service objectives, where those objectives can be applied to actions that meet the service objectives. Success can be measured against negotiated SLAs and remediation in the event of failure.

[0079] Figure 4 4 is a flow chart illustrating a method for federated automated interoperation between a venue and autonomous resources, according to an embodiment. As discussed above, in block 401, a provider or initiator of a service receives a request or instruction for a service objective. Service objectives may include, but are not limited to, pickup or delivery of a package, recharging, obtaining a signature on a document, performing maintenance on a specific device, and the like. Service objectives may include information regarding location, customer / client identifiers, required signatures, specific building information, timely completion SLA requirements, customer preferences, passcodes, and the like.

[0080] Once the service parameters are identified, the optimal resource usage and path(s) for achieving the destination can be determined in block 403. In an example, the building may be too far away for efficient battery operation of some autonomous vehicles. The stored information about the location may indicate that the drone landing pad can be used with and transferred to a ground vehicle operated by the site. Other information may include temperature or environmental requirements for food or medicine delivery, thereby requiring a special environmentally controlled (e.g., heated or refrigerated) vehicle. The dispatch service at the initiator's base can aggregate information about the destination and select the appropriate service equipment (e.g., autonomous vehicle) based on availability, operating parameters, etc. Once a serving autonomous vehicle is selected, the initial path to the destination can be identified. As discussed above, the initial path can be selected using information from one or a combination of the following: (a) an address given by a public navigation and mapping service; (b) a building discovery cloud service; and (c) a building infrastructure cloud service. Once the initial path is provided to the autonomous vehicle and, if necessary, loaded with delivery packaging, the vehicle can begin traveling on the initial path to the destination.

[0081] During the initial journey to the destination, unforeseen events may require adapting the route. For example, a road or sidewalk may unexpectedly close or become impassable. A drone landing pad may become unusable due to high winds, etc. The autonomous vehicle can query the cloud service for the next instruction or receive pushed instructions on the fly directing the autonomous vehicle to change course.

[0082] In block 405, once the autonomous vehicle has arrived in the vicinity of the smart venue, authentication and authorization techniques can be initiated to gain entry to the venue. An entry beacon on the building infrastructure (local or cloud) service can provide an additional passcode or token for entry, as well as next-step instructions for meeting service objectives. While traversing the venue, additional authentication and authorization handshakes may be required at various points along the journey.

[0083] Depending on the intermediate and final goals, various communications between the autonomous vehicle and communication nodes in the venue can be performed in blocks 407, 409, 411, 413, and 415. In block 407, ongoing negotiations between the vehicle and various beacons, entry or access points, and transportation equipment (e.g., elevators, conveyors) can be performed in advance or when in the vicinity. In block 409, continuous and adaptable navigation information can be provided by beacons or building infrastructure services to guide the vehicle to the next stage in the journey to achieve the goal. In block 413, special services as discussed above can be requested or provided and negotiated.

[0084] If it is determined that the autonomous vehicle is unable to complete the goal due to, for example, low battery, a malfunction, an inappropriate form factor for the path, an uncertified safety mode, etc., delegation to another device or vehicle may be assigned or negotiated in block 411. In some cases, and as described above, additional coordination with other parties may be necessary in block 415.

[0085] Figure 5 A block diagram of an example machine 500 is shown on which any one or more of the techniques (e.g., methods) discussed herein can be performed. In alternative embodiments, the machine 500 can operate as a standalone device or can be connected (e.g., networked) to other machines. In a networked deployment, the machine 500 can operate as a server, a client, or both in a server-client network environment. In an example, the machine 500 can act as a peer machine in a peer-to-peer (P2P) (or other distributed) network environment. The machine 500 can be a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a mobile phone, a web appliance, a network router, a switch or a bridge, or any machine capable of executing instructions (sequential or otherwise) specifying actions to be taken by the machine. Further, although only a single machine is shown, the term "machine" should also be considered to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methods discussed herein, such as cloud computing, software as a service (SaaS), or other computer cluster configurations.

[0086] Examples as described herein may include, or be operated by, logic or multiple components or mechanisms. A circuit system is a collection of circuits implemented in a tangible entity including hardware (e.g., simple circuits, gates, logic, etc.). The components of the circuit system can be flexible over time and with the variability of the underlying hardware. The circuit system includes components that can perform specified operations individually or in combination when in operation. In an example, the hardware of the circuit system can be designed to perform specific operations in an unchangeable manner (e.g., hard-wired). In an example, the hardware of the circuit system can include variably connected physical components (e.g., execution units, transistors, simple circuits, etc.), including computer-readable media that are physically modified (e.g., magnetically, electrically, or removably arranged to invariant aggregate particles) to encode instructions for specific operations. When the physical components are connected, the underlying electrical properties of the hardware components change, for example, from an insulator to a conductor, or vice versa. These instructions enable embedded hardware (e.g., execution units or loading mechanisms) to create components of the circuit system in hardware via variable connections to perform multiple parts of a specific operation when in operation. Accordingly, when the device is operating, the computer-readable medium is communicatively coupled to other components of the circuit system. In an example, any one of the physical components can be used in more than one member of more than one circuit system. For example, during operation, an execution unit can be used in a first circuit in a first circuit system at one time, and reused by a second circuit in the first circuit system at a different time, or reused by a third circuit in the second circuit system.

[0087] The machine (e.g., a computer system) 500 may include a hardware processor 502 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), a hardware processor core, or any combination thereof), a main memory 504, and a static memory 506, some or all of which may communicate with each other via an interconnection link (e.g., a bus) 508. The machine 500 may further include a display unit 510, an alphanumeric input device 512 (e.g., a keyboard), and a user interface (UI) navigation device 514 (e.g., a mouse). In an example, the display unit 510, the input device 512, and the UI navigation device 514 may be a touch screen display. The machine 500 may additionally include a storage device (e.g., a drive unit) 516, a signal generating device 518 (e.g., a speaker), a network interface device 520, and one or more sensors 521 (e.g., a global positioning system (GPS) sensor, a compass, an accelerometer, or other sensors). The machine 500 may include an output controller 528 for connecting to or controlling one or more peripheral devices (e.g., a printer, a card reader, etc.), 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.

[0088] The storage device 516 may include a machine-readable medium 522 on which is stored one or more sets of data structures or instructions 524 (e.g., software) that embody or are utilized by any one or more of the techniques or functionality described herein. The instructions 524 may also reside, completely or at least partially, within the main memory 506, within the static memory 502, or within the hardware processor 500 during execution thereof by the machine 504. In an example, one or any combination of the hardware processor 502, the main memory 504, the static memory 506, or the storage device 516 may constitute a machine-readable medium.

[0089] Although machine-readable medium 522 is illustrated as a single medium, the term “machine-readable medium” may include a single medium or multiple media (eg, a centralized or distributed database, or associated caches and servers) configured to store one or more instructions 524 .

[0090] The term "machine-readable medium" may include any medium that can store, encode, or carry instructions for execution by the machine 500 and causes the machine 500 to perform any one or more of the techniques of the present disclosure, or that can store, encode, or carry data structures used by or associated with such instructions. Non-limiting examples of machine-readable media may include solid-state memory and optical and magnetic media. In an example, a large-capacity machine-readable medium includes a machine-readable medium having a plurality of particles that have a constant (e.g., stationary) mass. Accordingly, a large-capacity machine-readable medium is not a transient propagating signal. Specific examples of large-capacity machine-readable media may include: non-volatile memory, such as semiconductor memory devices (e.g., electrically programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM)) and flash memory devices; magnetic disks, such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks.

[0091] The instructions 524 may be further transmitted or received over a communication network 526 using a transmission medium via the network interface device 520 using any of a variety of transmission protocols (e.g., Frame Relay, Internet Protocol (IP), Transmission Control Protocol (TCP), User Datagram Protocol (UDP), Hypertext Transfer Protocol (HTTP), etc.). Example communication networks may include a local area network (LAN), a wide area network (WAN), a packet data network (e.g., the Internet), a mobile telephone network (e.g., a cellular network), a plain old telephone (POTS) network, and a wireless data network (e.g., a wireless network known as a Wi-Fi network). The Institute of Electrical and Electronics Engineers (IEEE) 802.11 family of standards, known as .16 family of standards), IEEE 802.15.4 family of standards, peer-to-peer (P2P) networks, and the like. In an example, the network interface device 520 may include one or more physical jacks (e.g., Ethernet jacks, coaxial jacks, or telephone jacks) or one or more antennas for connecting to the communication network 526. In an example, the network interface device 520 may include multiple antennas for communicating wirelessly using at least one of single-input multiple-output (SIMO), multiple-input multiple-output (MIMO), or multiple-input single-output (MISO) technology. The term "transmission medium" shall be deemed to include any intangible medium capable of storing, encoding, or carrying instructions for execution by the machine 500, and "transmission medium" includes digital or analog communication signals or other intangible media for facilitating the communication of such software.

[0092] Additional Notes and Examples

[0093] Examples may include subject matter such as: a method; an apparatus for performing the actions of the method; at least one machine-readable medium comprising instructions that, when executed by a machine, cause the machine to perform the actions of the method; or an apparatus or system for joint automated interoperability between smart places and autonomous resources according to the embodiments and examples described herein.

[0094] Example 1 is an autonomous entity comprising: a processor that, when in operation, is coupled to at least one communication link to communicate with services and other entities; a mobile component that is configured to enable the autonomous entity to independently travel without human intervention to achieve a service goal; a guidance system operable by the processor, configured to send navigation instructions to the mobile component to guide the autonomous entity to a specified location and communicate with an external navigation service via at least one communication link, wherein the guidance system is configured to receive updated position or path information from the external navigation service at an intermediate location, and wherein the external navigation service is one of a cloud service or a local service provided by a smart venue; and A two-way authenticator operated by a processor, the two-way authenticator being configured to provide two-way authentication, authorization, and security information between an autonomous entity and a second entity via at least one communication link, wherein the at least one communication link is one of wired or wireless; negotiation logic operable by the processor, the negotiation logic being configured to communicate with any one or more of a local building service, a cloud building service, and a location beacon coupled to a smart venue to negotiate intermediate tasks and final tasks in completing a service objective, wherein the negotiation logic is configured to aggregate guidance information, service level agreement information, building infrastructure information, and operability information to determine a next intermediate task or final task to complete the task objective.

[0095] In Example 2, the subject matter of Example 1 optionally includes delegation logic operable by a processor and coupled to at least one communication link, the delegation logic configured to identify a second entity to complete the service objective in response to an indication that the autonomous entity cannot independently complete the service objective, and further configured to relocate to a position to hand over the service objective to the second entity.

[0096] In Example 3, the subject matter of Example 2 optionally includes: wherein the autonomous entity includes a drone, and wherein the delegation logic is configured to enable the drone to automatically hand over the service objective to a ground vehicle to complete the service objective after arriving at a landing point at the smart venue.

[0097] In Example 4, the subject matter of any one or more of Examples 1-3 optionally includes: wherein the negotiation logic is configured to receive environmental information about building infrastructure, environmental event information, and alternative intermediate tasks while on the road to modify a previously planned schedule for a service target and create a modified schedule, wherein the modified schedule includes at least one of: a route to a location, a speed, a direction vector, a handover location for delegation, a waiting indication, a billing event, or an instruction to initiate a special service.

[0098] In Example 5, the subject matter of any one or more of Examples 1-4 may optionally include wherein the negotiation logic is configured to negotiate a special service provided by the smart venue, wherein the special service is a service fee, and using the special service triggers payment to a provider of the special service.

[0099] In Example 6, the subject matter of Example 5 optionally includes: wherein the special service is selected from the group of services consisting of: charging of an autonomous entity, authorization to traverse a secure passage, rental of a parcel locker, rental of an environmentally controlled storage area, and delegation to a second entity.

[0100] Example 7 is a smart place for providing federated automated interoperability with autonomous resources, comprising: a network of place communication resources, including at least one of the following: an entry beacon, an internal navigation beacon, or a landing beacon; and a building infrastructure service, the building infrastructure service being configured to provide current information about the building infrastructure, localized event information, place environment information, special service information, or consumer information, the current information about the building infrastructure including mapping and location information, wherein the building infrastructure service is one of a local service available upon approaching the smart place or a cloud service available via a network connection, wherein the network of place communication resources is configured to authenticate and negotiate entry authorization for authorized autonomous entities at a localized point in the smart place, and provide guidance to the next location.

[0101] In Example 8, the subject matter of Example 7 can optionally include one or more special services, wherein the autonomous entity negotiates with a network of venue communication resources to obtain use of the special services.

[0102] In Example 9, the subject matter of Example 8 optionally includes: wherein the special service is a service fee, and use of the special service triggers payment to a provider of the special service, and wherein the special service is selected from a group of services consisting of: charging of an autonomous entity, authorization to traverse a secure passage, rental of a package locker, rental of an environmentally controlled storage area, or delegation to a second entity.

[0103] In Example 10, the subject matter of any one or more of Examples 7-9 optionally includes: wherein the building infrastructure service is configured to send environmental information about the building infrastructure, environmental event information, and alternative intermediate tasks to the autonomous entity when the autonomous entity is on the road to modify a previously planned schedule for the service target and generate a modified schedule, wherein the modified schedule includes at least one of the following: a route to a location, a speed, a direction vector, a handover location for delegation, a waiting indication, a billing event, or an instruction to initiate a special service.

[0104] In Example 11, the subject matter of one or more of Examples 7-10 optionally includes: wherein the entry beacon is configured to negotiate a route portion in the smart venue to enable the autonomous entity to complete a service objective within the parameters of a service level agreement between a provider and a consumer of the autonomous transportation in the smart venue, wherein the route portion is one of a route that completes the service objective or an intermediate route to an intermediate location.

[0105] Example 12 is a computer-implemented method for providing federated automated interoperability between autonomous resources and a smart venue, comprising: receiving instructions for a service goal; performing discovery of initial tasks for completing the service goal; identifying an optimal autonomous resource for completing the service goal while maintaining the requirements of a predefined service level agreement; determining a path to the service goal for the optimal autonomous resource; navigating the optimal autonomous resource through initial tasks, wherein each initial task includes an intermediate destination toward completing the service goal; and negotiating with a network of venue communication resources, the network of venue communication resources including at least one of: an entry beacon, an internal navigation beacon, a landing beacon, or a building infrastructure service, wherein the negotiation includes: authenticating the autonomous resource with the network of venue communication resources; and receiving a new task at the autonomous resource toward completing the service goal.

[0106] In Example 13, the subject matter of Example 12 can optionally include wherein the negotiation further comprises authorizing the autonomous resource for a path or service within the smart venue.

[0107] In Example 14, the subject matter of any one or more of Examples 12-13 optionally includes: automatically delegating completion of a service objective by the optimal autonomous resource to a second resource, wherein the second resource is one of the following: located within the smart venue; or located at a secondary intermediate location; and in response to the delegation to the second resource owned by a third party, triggering a billing event to pay for use of the second resource.

[0108] In Example 15, the subject matter of any one or more of Examples 12-14 optionally includes negotiating use of a special service in a smart place, wherein the special service is a service fee, and use of the special service triggers payment to a provider of the special service, and wherein the special service is selected from a group of services comprising: charging of an autonomous entity, authorization to traverse a secure passage, rental of a package locker, rental of an environmentally controlled storage area, or delegation to a second entity.

[0109] In Example 16, the subject matter of any one or more of Examples 12-15 optionally includes: wherein the negotiation includes negotiating with a building infrastructure service to receive environmental information about the building infrastructure, environmental event information, and alternative intermediate tasks while on the way to modify a previously planned schedule for the service target, wherein the modified schedule includes at least one of: a route to a location, a speed, a direction vector, a handover location for delegation, a waiting indication, a billing event, or an instruction to initiate a special service.

[0110] Example 17 is at least one computer-readable storage medium having instructions stored thereon, which instructions, when executed by a processing circuit system, cause the processing circuit system to: receive instructions for a service goal; perform discovery of initial tasks for completing the service goal; identify optimal autonomous resources for completing the service goal while maintaining the requirements of a predefined service level agreement; determine a path to the service goal for the optimal resources; navigate the autonomous resources through the initial tasks, wherein each initial task includes an intermediate destination toward completing the service goal; and negotiate with a network of venue communication resources, the network of venue communication resources including at least one of the following: an entry beacon, an internal navigation beacon, a landing beacon, or a building infrastructure service, wherein the negotiation includes: instructions for authenticating the autonomous resource using the network of venue communication resources; and receiving a new task at the autonomous resource toward completing the service goal.

[0111] In Example 18, the subject matter of Example 17 may optionally include wherein the instructions for negotiating further include instructions for authorizing the autonomous resource for a path or service within the smart venue.

[0112] In Example 19, the subject matter of any one or more of Examples 17-18 optionally includes instructions for automatically delegating, by the optimal autonomous resource, completion of a service objective to a second resource, wherein the second resource is one of: located within the smart venue; or located at a secondary intermediate location; and in response to the delegation to the second resource owned by a third party, triggering a billing event to pay for use of the second resource.

[0113] In Example 20, the subject matter of any one or more of Examples 17-19 optionally includes instructions for negotiating use of a special service in a smart place, wherein the special service is a service fee and use of the special service triggers payment to a provider of the special service, and wherein the special service is selected from a group of services comprising: charging of an autonomous entity, authorization to traverse a secure passage, rental of a package locker, rental of an environmentally controlled storage area, and delegation to a second entity.

[0114] In Example 21, the subject matter of any one or more of Examples 17-20 optionally includes: wherein the instructions for negotiating include instructions for the following operations: negotiating with a building infrastructure service to receive environmental information, environmental event information, and alternative intermediate tasks about the building infrastructure while on the road to modify a previously planned schedule for a service target, wherein the modified schedule includes at least one of the following: a route to a location, a speed, a direction vector, a handover location for delegation, a waiting indication, a billing event, or instructions for initiating a special service.

[0115] Example 22 is a system for providing joint automated interoperability between autonomous resources and smart places, comprising: a device for receiving instructions for a service goal; a device for performing discovery of initial tasks for completing the service goal; a device for identifying the optimal autonomous resource for completing the service goal while maintaining the requirements of a predefined service level agreement; a device for determining a path to the service goal for the optimal resource; a device for navigating the autonomous resource through initial tasks, wherein each initial task includes an intermediate destination toward completing the service goal; and a device for negotiating with a network of place communication resources, the network of place communication resources including at least one of: an entry beacon, an internal navigation beacon, a landing beacon, or a building infrastructure service, wherein the device for negotiating includes a device for authenticating the autonomous resource with the network of place communication resources and receiving a new task toward completing the service goal at the autonomous resource.

[0116] In Example 23, the subject matter of Example 22 may optionally include wherein the means for negotiating with the network of venue communication resources further comprises means for authorizing the autonomous resource for a path or service within the smart venue.

[0117] In Example 24, the subject matter of any one or more of Examples 22-23 optionally includes: an apparatus for automatically delegating completion of a service objective by an autonomous resource to a second resource, wherein the second resource is one of the following: located within a smart venue; or located at a secondary intermediate location; and an apparatus for triggering a billing event to pay for use of the second resource in response to delegation to the second resource owned by a third party.

[0118] In Example 25, the subject matter of any one or more of Examples 22-24 optionally includes: an apparatus for negotiating the use of a special service in a smart place, wherein the special service is a service fee, and use of the special service triggers payment to a provider of the special service, and wherein the special service is selected from a group of services comprising: charging of an autonomous entity, authorization to traverse a secure passage, rental of a package locker, rental of an environmentally controlled storage area, and delegation to a second entity.

[0119] In Example 26, the subject matter of any one or more of Examples 22-25 optionally includes: wherein the apparatus for negotiating includes apparatus for negotiating with a building infrastructure service to receive environmental information about the building infrastructure, environmental event information, and alternative intermediate tasks while on the road to modify a previously planned schedule for a service target, wherein the modified schedule includes at least one of: a route to a location, a speed, a direction vector, a handover location for delegation, a waiting indication, a billing event, or an instruction to initiate a special service.

[0120] Example 27 is a system configured to perform the operations of any one or more of Examples 1-26.

[0121] Example 28 is a method for performing the operations of any one or more of Examples 1-26.

[0122] Example 29 is a machine-readable medium comprising instructions that, when executed by a machine, cause the machine to perform the operations of any one or more of Examples 1-26.

[0123] Example 30 is a system comprising means for performing the operations of any one or more of Examples 1-26.

[0124] The techniques described herein are not limited to any specific hardware or software configuration; they may find applicability in any computing, consumer electronic device, or processing environment. The techniques may be implemented in hardware, software, firmware, or a combination thereof to produce logic or circuitry that supports the execution or performance of the embodiments described herein.

[0125] For simulation purposes, program code may represent hardware using a hardware description language or another functional description language that essentially provides a model of how the designed hardware is expected to perform. Program code may be assembly or machine language, or data that can be compiled or interpreted. Furthermore, it is common in the art to refer to software, in one form or another, as performing an action or producing a result. Such expressions are simply shorthand ways of stating that program code is executed by a processing system that causes a processor to perform an action or produce a result.

[0126] Each program may be implemented in a high-level procedural language, a declarative language, or an object-oriented programming language to communicate with the processing system. However, if desired, the program can be implemented in assembly language or machine language. In either case, the language can be compiled or interpreted.

[0127] Program instructions can be used to cause a general-purpose processing system or a special-purpose processing system programmed with the instructions to perform the operations described herein. Alternatively, the operations can be performed by dedicated hardware components that contain hard-wired logic for performing the operations, or by any combination of programmed computer components and custom hardware components. The methods described herein can be provided as a computer program product (also described as a computer or machine-accessible or readable medium), which can include one or more machine-accessible storage media having instructions stored thereon that can be used to program a processing system or other electronic device to perform the methods.

[0128] Program code or instructions can be stored, for example, in volatile or non-volatile memory, such as a storage device or associated machine-readable or machine-accessible media, including solid-state memory, hard drives, floppy disks, optical storage, magnetic tape, flash memory, memory sticks, digital video disks, digital versatile disks (DVDs), and the like; as well as more unique media, such as machine-accessible biological state preservation storage. Machine-readable media may include any mechanism for storing, transmitting, or receiving information in a machine-readable form, and the medium may include a tangible medium through which an electrical, optical, acoustic, or other form of propagated signal or carrier wave encoding the program code may be transmitted, such as an antenna, optical fiber, a communication interface, and the like. Program code can be transmitted in the form of packets, serial data, parallel data, propagated signals, and the like, and can be used in a compressed or encrypted format.

[0129] The program code can be implemented as a program executed on a programmable machine, such as a mobile or fixed computer, a personal digital assistant, a smartphone, a mobile internet device, a set-top box, a cellular phone and pager, a consumer electronic device (including a DVD player, a personal video recorder, a personal video player, a satellite receiver, a stereo receiver, a cable television receiver), and other electronic devices, each of which includes a processor, a volatile or non-volatile memory readable by the processor, at least one input device, or one or more output devices. The program code can be applied to data entered using the input device to execute the described embodiments and generate output information. The output information can be applied to one or more output devices. It will be appreciated by those skilled in the art that the embodiments of the disclosed subject matter can be implemented using various computer system configurations, including multi-processor or multi-core processor systems, minicomputers, mainframe computers, and universal or microcomputers or processors that can be embedded in virtually any device. The embodiments of the disclosed subject matter can also be implemented in a distributed computing environment, a distributed computing environment, a cloud environment, a peer-to-peer or networked microservice, where tasks or portions of a service can be performed by remote processing devices linked via a communication network.

[0130] The processor subsystem can be used to execute instructions on a machine-readable medium or a machine-accessible medium. The processor subsystem may include one or more processors, each processor having one or more cores. In addition, the processor subsystem may be arranged on one or more physical devices. The processor subsystem may include one or more special-purpose processors, such as a graphics processing unit (GPU), a digital signal processor (DSP), a field programmable gate array (FPGA), or a fixed-function processor.

[0131] Although the operations can be described as sequential processes, in fact, some of these operations can be performed in parallel, simultaneously, or in a distributed environment, and using locally or remotely stored program code for access by single-processor or multi-processor machines. In addition, in some embodiments, the order of operations can be rearranged without departing from the spirit of the disclosed subject matter. The program code can be used by or in conjunction with an embedded controller.

[0132] Examples as described herein may include circuit systems, logic or multiple components, modules or mechanisms, or may operate on circuit systems, logic or multiple components, modules or mechanisms. A module may be hardware, software or firmware that is communicatively coupled to one or more processors to implement the operations described herein. It will be understood that a module or logic can be implemented as a hardware component or device, software or firmware running on one or more processors, or a combination thereof. A module may be a different and independent component integrated by sharing or transferring data, or a module may be a subcomponent of a single module, or a module may be split between several modules. A component may be a process running or implemented on a single computing node, or between multiple computing nodes running in parallel, concurrently, sequentially, or in combination, as more fully described in conjunction with the flowcharts in the accompanying drawings. Thus, a module may be a hardware module, and thus, a module may be considered to be a tangible entity that can perform a specified operation and may be configured or arranged in a certain manner. In an example, a circuit (e.g., internally or relative to an external entity such as other circuits) may be arranged as a module in a specified manner. In an example, all or part of one or more computer systems (e.g., stand-alone client or server computer systems) or one or more hardware processors may be configured by firmware or software (e.g., instructions, application parts, or applications) to operate as a module for performing a specified operation. In an example, the software may reside on a machine-readable medium. In an example, the software, when executed by the underlying hardware of the module, causes the hardware to perform a specified operation. Therefore, the term hardware module is understood to encompass a tangible entity that is physically constructed, specifically configured (e.g., hard-wired), or temporarily (e.g., transiently) configured (e.g., programmed) to operate in a specified manner or to perform part or all of any operation described herein. Considering the example of a temporary configuration module, each of these modules does not need to be instantiated at any one moment. For example, in the case where a module includes a general-purpose hardware processor configured, arranged, or adjusted using software, the general-purpose hardware processor can be configured as corresponding different modules at different times. The software can configure the hardware processor accordingly, for example, so as to construct a specific module at one time instance and to construct different modules at different time instances. The modules may also be software or firmware modules that operate to perform the methods described herein.

[0133] In this document, as is common in patent documents, the terms "a" or "an" are used to include one or more than one, independent of any other instance or usage of "at least one" or "one or more." In this document, unless otherwise indicated, the term "or" is used to refer to a non-exclusive or, such that "A or B" includes "A but not B," "B but not A," and "A and B." In the appended claims, the terms "including" and "in which" are used as the plain English equivalents of the respective terms "comprising" and "wherein." Furthermore, in the appended claims, the terms "including" and "comprising" are open-ended, that is, a system, apparatus, article, or process that includes elements in a claim in addition to those listed after such terms is still considered to fall within the scope of that claim. Furthermore, in the appended claims, the terms "first," "second," and "third," etc., are used merely as labels and are not intended to indicate a numerical order to their objects.

[0134] Although this theme has been described with reference to illustrative embodiments, this description is not intended to be interpreted in a restrictive or binding sense. For example, the examples described above (or one or more aspects thereof) can be used in conjunction with other embodiments. Other embodiments can be used as will be understood by those of ordinary skill in the art after carefully reading this disclosure. The abstract allows the reader to quickly discover the nature of the present technology disclosure. However, this abstract is submitted, and it is understood that this abstract will not be used to interpret or limit the scope or meaning of the claims.

Claims

1. An autonomous resource, comprising: processor; a boot system coupled to the processor; at least one communication link for communicating with services and other entities; a bidirectional authenticator coupled to the processor; a memory comprising instructions stored thereon that, when executed by the processor, enable the autonomous resource to proceed independently without human intervention to achieve a service goal, wherein, to achieve the service goal, the instructions cause the processor to: sending navigation instructions using the guidance system to guide the autonomous resource to a specified location and communicating with an external navigation service via the at least one communication link, wherein the guidance system is configured to receive updated position or path information from the external navigation service at an intermediate location; providing bidirectional authentication, authorization, and security information between the autonomous resource and a second entity via the at least one communication link using the bidirectional authenticator; Communicate with resources to perform negotiation of intermediate and final tasks in completing the service objectives; aggregating guidance information, service level agreement information, building infrastructure information, and operability information to determine a next intermediate task or final task for completing the service goal and negotiate a second service provided by the smart venue; wherein the second service comprises delegating one or more tasks originally assigned to the autonomous resource to the second entity to complete the tasks, wherein the second entity is an autonomous vehicle, a semi-autonomous vehicle, or a human agent associated with a vehicle, wherein the delegation of the one or more tasks initially assigned to the autonomic resource is communicated to the second entity via the external navigation service, wherein the one or more tasks originally assigned to the autonomous resource are handed over from the autonomous resource to the second entity, wherein the second entity completes the one or more tasks originally assigned to the autonomous resource separately from the autonomous resource, wherein the guidance information is updated based on a change in at least one of the intermediate tasks or the final task, and The change of at least one of the intermediate tasks or the final tasks occurs after the autonomous resource or the second entity arrives at the smart place.

2. The autonomous resource of claim 1, wherein: The instructions further cause the processor to: The second entity is identified to complete the service goal in response to an indication that the autonomous resource cannot independently complete the service goal, and the delegation logic is further configured to relocate to a location for handing over the service goal to the second entity.

3. The autonomous resource of claim 1 , wherein the autonomous resource comprises a drone, and wherein the drone, after arriving at a landing point of the smart site, is capable of automatically handing over the service objective to a ground vehicle to complete the service objective.

4. The autonomous resource of claim 1 , wherein the instructions further cause the autonomous resource to receive environmental information about building infrastructure, environmental event information, and alternative intermediate tasks while on-route to modify a previously planned schedule for the service goal and create a modified schedule, wherein the modified schedule includes at least one of: a route to a location, a speed, a direction vector, a handover location for delegation, a wait indication, a billing event, or an instruction to initiate the second service.

5. A computer-implemented method for providing automated interoperability between autonomous resources and smart places, comprising: Receive instructions for service objectives; Perform discovery of one or more initial tasks for completing the service objective; Identify the autonomous resources used to accomplish the stated service objectives; determining a path to the service target for the autonomous resource; navigating the autonomous resource through the one or more initial tasks, wherein each initial task includes an intermediate goal toward completing the service goal; as well as negotiating with venue communication resources of the smart venue, wherein the negotiation comprises: authenticating the autonomous resource with the venue communication resource; and receiving at the autonomous resource a new task toward completing the service goal, wherein the negotiation comprises: negotiating a second service provided by the smart venue, wherein the second service comprises delegating one or more tasks originally assigned to the autonomic resource to a second entity to complete the one or more tasks originally assigned to the autonomic resource, wherein the second entity is an autonomous vehicle, a semi-autonomous vehicle, or a human agent associated with a vehicle, and wherein the delegation of the one or more tasks initially assigned to the autonomous resource is communicated to the second entity via an external navigation service, wherein the one or more tasks originally assigned to the autonomous resource are handed over from the autonomous resource to the second entity, wherein the second entity completes the one or more tasks originally assigned to the autonomous resource separately from the autonomous resource, and wherein the negotiation comprises updating the path to the service target based on a change of at least one of the intermediate tasks, and wherein the change of at least one of the intermediate tasks occurs after the autonomous resource or the second entity arrives at the smart place.

6. The computer-implemented method of claim 5 , wherein negotiating further comprises: The autonomous resource is authorized for a path or service within the smart venue.

7. The computer-implemented method of claim 5, further comprising: The autonomous resource automatically delegates completion of the service goal to a second resource, wherein the second resource is one of the following: located within the smart venue; or in a secondary intermediate position; and In response to the delegation to the second resource owned by the third party, a billing event is triggered to pay for use of the second resource.

8. The computer-implemented method of claim 5, wherein: The network of venue communication resources includes at least one of: an entry beacon, an interior navigation beacon, a landing beacon, or a building infrastructure service, and wherein automated interoperation of the smart venue and the autonomous resources is combined such that the autonomous resources interact with one or more cloud services or services provided by the smart venue to enable distributed operation or control of the autonomous resources.

9. A computer-implemented method as described in claim 5, wherein negotiation includes negotiating with a building infrastructure service to receive environmental information about the building infrastructure, environmental event information, and alternative intermediate tasks while on the road to modify a previously planned schedule for the service target, wherein the modified schedule includes at least one of the following: a route to a location, a speed, a direction vector, a handover location for delegation, a waiting indication, a billing event, or an instruction to initiate the second service.

10. At least one computer-readable storage medium having stored thereon instructions that, when executed on a processor, cause the machine to perform the operations of any one or more of claims 5-9.

11. A system for providing automated interoperability between autonomous resources and smart places, comprising: means for receiving instructions for a service target; means for performing discovery of one or more initial tasks for completing said service objective; means for identifying autonomous resources for completing said service objective; means for determining, for said autonomous resource, a path to said service target; means for navigating the autonomous resource through the one or more initial tasks, wherein each initial task includes an intermediate goal toward completing the service goal; as well as means for negotiating with venue communication resources of the smart venue, wherein the means for negotiating comprises means for authenticating the autonomous resource with the venue communication resource and receiving at the autonomous resource a new task toward completing the service goal, wherein the means for negotiating comprises means for negotiating a second service provided by the smart venue, wherein the second service comprises delegating one or more tasks originally assigned to the autonomic resource to a second entity to complete the one or more tasks originally assigned to the autonomic resource, wherein the second entity is an autonomous vehicle, a semi-autonomous vehicle, or a human agent associated with a vehicle, and wherein the delegation of the one or more tasks initially assigned to the autonomous resource is communicated to the second entity via an external navigation service, wherein the one or more tasks originally assigned to the autonomous resource are handed over from the autonomous resource to the second entity, wherein the second entity completes the one or more tasks originally assigned to the autonomous resource separately from the autonomous resource, and Wherein, the means for negotiation comprises: means for updating the path to the service target based on a change of at least one of the intermediate tasks, and wherein the change of at least one of the intermediate tasks occurs after the autonomous resource or the second entity arrives at the smart place.

12. The system of claim 11, wherein the means for negotiating with the venue communication resource further comprises means for authorizing the autonomous resource for a path or service within the smart venue.

13. The system of claim 11, further comprising: means for automatically delegating, by the autonomous resource, completion of the service goal to a second resource, wherein the second resource is one of: located within the smart venue; or located at a secondary intermediate location; and In response to the delegation to the second resource owned by the third party, a billing event is triggered to pay for use of the second resource.

14. The system of claim 11, wherein: The network of venue communication resources includes at least one of: an entry beacon, an interior navigation beacon, a landing beacon, or a building infrastructure service, and wherein automated interoperation of the smart venue and the autonomous resources is combined such that the autonomous resources interact with one or more cloud services or services provided by the smart venue to enable distributed operation or control of the autonomous resources.

15. A system as described in claim 11, wherein the means for negotiating includes means for negotiating with a building infrastructure service to receive environmental information, environmental event information, and alternative intermediate tasks about the building infrastructure while on the road to modify a previously planned schedule for the service target, wherein the modified schedule includes at least one of the following: a route to a location, a speed, a direction vector, a handover location for delegation, a waiting indication, a billing event, or an instruction to initiate the second service.

Images