Patent Description:
Given supply chains that extend across borders and different internet service providers, there is growing need to track shipments in ports, warehouses, supply chains and other segments where location data must be accessible both to Asset Owners (AOs) and to the operators that handle the shipments, either in transit or at their final destinations. To track the shipments or parcels, the AO may attach wireless devices that can communicate with wireless networks such as Wi-Fi networks, LoRa networks, or cellular networks. The AO, however, may not operate wireless networks and instead rely on third-party providers to manage the identity, authentication, and life-cycle of its wireless devices used to track shipments. The AO must rely on a visited network (e.g., a wireless network provided by a seaport, airport, or cellular network) to communicate with the wireless devices, identify their locations, and push those locations to the AO.

Currently, there is no way to securely provide location data to the AO, unless the visited network and the AO have an already established agreement, or use a common application. The visited network can use hyper-location in Wi-Fi, multilateration in cellular, TDOA/RSSI in LoRa, mechanisms based on UWB or combinations of them to identify the location of the AO's devices; however, these data are not accessible to third parties, such as AOs. Building ad hoc solutions to share location data between visited networks and AOs suffer both from scalability and trust issues, since the number and diversity of AOs whose devices (e.g., tags) could potentially connect to and transit (e.g., roam) through networks in many different ports, warehouses, and countries might be very large. In addition, privacy requirements dictate that identity and location data should be shared exclusively between entities that have agreed upon specific terms and conditions, thereby restricting the scope and limits of such data exchange. Without a solution, AOs often lose track of their devices (and corresponding shipments) when they move from outdoors to indoor (e.g., inside a warehouse) or when roaming costs become prohibitive.

<CIT> relates to an asset tracking system for tracking an asset in an industrial process involving the asset passing between a plurality of realms with limited mutual trust between the realms comprises: a distributed blockchain-based database system; a plurality of asset tracking devices each configured to acquire one or more asset attribute values of the asset, wherein each of the realms includes at least one of the plurality of asset tracking devices; and an asset lifetime handler device configured to maintain, in a ledger of the distributed database system, based on the asset attribute values respectively acquired over time by a respective one of the plurality of asset tracking devices, an asset lifetime passport, ALP, the ALP constituting a digital representation of a history of the acquired asset attribute values of the asset.

<CIT> is directed to systems, methods, and computer-readable media are provided for a geo-location based selection of an identity for a mobile device to attach to a nearby network of an access provider. In one example, a method includes determining, by one or more processors, a location of a mobile device; identifying, by the one or more processors, an access provider having a network for the mobile device to connect to; selecting, by the one or more processors, one of a plurality of identities associated with the mobile device for authorizing connection to the network of the access provider, the selection being based on the location of the mobile device and connection parameters specified by the access provider; and establishing, by the one or more processors, the connection of the mobile device to the network of the access provider using the one of the plurality of identities.

<CIT> is directed to a multi-provider management system for location-based service zones. The multi-provider management system can receive data associated with location-based service zones from multiple providers. A unique identifier can be assigned to each provider. The multi-provider management system can send location-based service zones from multiple providers to a client device, and can receive trigger event notifications associated with the location-based service zones. The unique identifier can be used to identify which provider to notify when receiving a trigger event notification.

It is to be noted, however, that the appended drawings illustrate typical embodiments and are therefore not to be considered limiting, other equally effective embodiments are contemplated.

One embodiment presented in this disclosure is a method that includes registering a plurality of identity providers (IDPs) with a location, aggregation, and insights (LAI) service, where the LAI service, the plurality of IDPs, and an asset owner (AO) are part of an identity federation. The method also includes registering the AO with the LAI service where registering the AO comprises selecting one of more of the IDPs already registered with the LAI service and binding, in the LAI service, the selected IDPs to an AO application of the AO where the selected IDPs and the AO application have respective realms in common. After detecting a device has roamed to a visited network (VN) in the identity federation, the method includes receiving a realm associated with the device at the LAI service from the VN. The method also includes identifying, at the LAI service, the AO application by matching the received realm to one of the respective realms and enabling the VN to push location information corresponding to the device to the AO application.

Other embodiments include a computing system and a non-transitory computer readable medium having program instructions for performing an operation which includes registering a plurality of IDPs with a LAI service where the LAI service, the plurality of IDPs, and an AO are part of an identity federation and registering the AO with the LAI service where registering the AO comprises selecting one of more of the IDPs already registered with the LAI service. The operation also includes binding, in the LAI service, the selected IDPs to an AO application of the AO, wherein the selected IDPs and the AO application have respective realms in common and, after detecting a device has roamed to a VN in the identity federation, receiving a realm associated with the device at the LAI service from the VN. The operation includes identifying, at the LAI service, the AO application by matching the received realm to one of the respective realms and enabling the VN to push location information corresponding to the device to the AO application.

Embodiments herein registers AOs and an AO application to a location, aggregation, and insight (LAI) service that are both part of the same open roaming federation (or more generally, an identity federation). It is in the interest of both AOs and the enterprises that own visited networks (VN) to get access to positioning data. Hence, there is a need for new techniques that allow VN owners to dynamically discover AOs and share location data with the AOs in a controlled, trustful and consented way, irrespective of the access technology used. This is particularly relevant in open roaming scenarios, where VNs rely on dynamically establishing trust not only with Identity Providers (IDPs) during the authentication phase but also with AOs.

A plurality of IDPs (which can be an AO, or a separate third-party service) is registered to the LAI service. When registering the AO with the LAI service, the AO selects which of the plurality of IDPs it uses (e.g., has a contractual relationship with), and the LAI service can then bind those IDPs to the AO using digital certificates. This binding associates respective realms (e.g., domains) corresponding to the selected IDPs to the AO application. This binding is stored in the LAI service as a table that links the realms owned by the selected IDPs to an ID of the AO application. Later, when a device owned by the AO roams to a VN (e.g., a network not controlled by the AO or its IDPs), the LAI service can use the table to match a realm associated with the device to one of the realms of the registered IDPs. The LAI service can then use the matched realm to identify the ID of the AO application. The LAI service then enables the VN to begin transmitting location data associated with the device to the AO application using its ID. In this manner, an AO's devices can roam to any VN which is part of the same identity federation as the AO, and the VN can dynamically (e.g., on-the-fly) establish a secure and trusted relationship with the AO so that location data can be pushed to the AO application. As such, the embodiments herein do not have to rely on establishing pre-existing relationships between AOs and potential VNs before these networks can share location data of roaming devices to the AOs.

<FIG> illustrates a location sharing system <NUM> using an identity federation, according to one embodiment described herein. The system <NUM> permits a VN <NUM> (also referred to as an access network (AN)) to dynamically discover the ID of an AO application <NUM> for a roaming device <NUM> that has roamed to the VN <NUM>. The embodiments herein apply when the AO and an IDP <NUM> are different entities, though it is not restricted to that case. Further, the embodiments herein can be used in a multi-RAN scenario where the AO application <NUM> is the target for sharing location data for the devices <NUM> owned by the AO. Location data can be fed to the AO application <NUM> both when the devices <NUM> are connected to their home networks (e.g., the home network <NUM>) as well as when they roam to the VN <NUM> as shown in <FIG>.

The embodiments below also describe techniques for automatically binding a set of device IDs to the corresponding AO. In one embodiment, the device IDs are supplied directly by the IDPs <NUM> on behalf of the AO. Also, the owner/operator of the VN <NUM> can dynamically manage its policy and get explicit consent to share location data with the AO applications <NUM>. This ensures that data disclosures are only sent to the AO, subject to the AO's explicit consent and policy defined by the owner of the VN <NUM> (e.g., the owner for the VN <NUM> may choose not to disclose any location data). In other examples, an AO might be able to provide explicit consent to the VN <NUM> to share location data with a third-party (e.g., for data analysis purposes, for logistics, for subcontractors, etc.).

A VN Connector <NUM> coupled to the VN <NUM> interoperates with IDP Connectors <NUM> associated with the home network <NUM>. These connectors <NUM>, <NUM> provide means for dynamic discovery of peers, dynamic establishment of secure tunnels, and carrying identity and authentication packets requiring neither previous knowledge nor pre-established peering agreements between the IDPs <NUM> and the VNs <NUM>. Each VN <NUM> may have associated one or more VN Connectors <NUM> (e.g., one for Wi-Fi, one for LoRa, one for PLTE, one for <NUM>, and so on, or they might all be integrated as a single entity).

The system <NUM> includes an open roaming federation <NUM> that establishes trust between the IDPs <NUM> and VNs <NUM> so that roaming devices <NUM> can be authenticated using credentials stored in the IDP <NUM>. However, the embodiments herein can be applied to any identity federation that establishes trust between VNs and IDPs <NUM> so that roaming devices <NUM> can be identified. Generally, the open roaming federation <NUM> permits the VN <NUM> to authenticate the roaming device <NUM> so that the device <NUM> can attach to the VN <NUM>. However, the embodiments herein leverage the open roaming federation <NUM> to further enable a VN <NUM> to establish trust with the AO applications <NUM> so that location data (or other metadata) regarding the roaming devices <NUM> can be shared with the AO applications <NUM> or a third-party entity.

Once a roaming device is authenticated, the VN <NUM> can track the roaming device (e.g., using Wi-Fi, cellular, or LoRa location techniques) and determine whether the location of the device <NUM> should be shared with the AO application <NUM> (or some other third-party entity). To do so, the VN <NUM> communicates with a LAI service <NUM> which can provide the VN <NUM> with the ID of the AO application <NUM>. The LAI service <NUM>, which is a trusted service to the perspective of the VN <NUM>, can establish trust between the VN <NUM> and the AO application <NUM> when these entities may not have had a previous relationship of trust. Once trust is established, the VN <NUM> can begin pushing location data regarding the device <NUM> to the AO application <NUM> or a third-party entity indicated by the AO application <NUM>.

In one embodiment, the LAI service <NUM> includes one or more computing systems that include one or more processor and memory. In one embodiment, the LAI service <NUM> is a software application executing on one or more computing systems.

<FIG> is a flowchart of a method <NUM> for binding an AO application to an IDP in a LAI service, according to one embodiment described herein. In one embodiment, the method <NUM> is performed before a device (e.g., the roaming device <NUM>) roams to a VN (e.g., the VN <NUM>). Specifically, the method <NUM> can be performed to establish a relationship of trust between the AO, IDPs, and the LAI service. That way, later when a device owned by the AO roams to a VN in the same identity federation as the LAI service, the LAI service can establish a relationship of trust between the VN and the AO (or more specifically, between the VN and the AO application) so the VN can push location data associated with the device to the AO.

At block <NUM>, the IDPs register with the LAI service. For example, Each IDP may or may not require a IDP connector to interface with the LAI service. For example, a Wi-Fi IDP might push data directly to the LAI service using native automation rules (i.e., without requiring a connector between the IDP and the LAI service). However, other IDPs, such as LoRa networks servers, mobile manufacturers, enterprises, etc., might use a IDP connector to feed data to the LAI service. In either case, IDPs may interface with the LAI service once registered. Further, the IDPs may, or may not, operate their own VNs in the open roaming federation.

Registering an IDP with the LAI service may include a certificate to establish a trusted connection to the LAI service. The certificates might be issued by a public key infrastructure (PKI) supported by the LAI service itself, by an open roaming federation (which is the case when the IDP is on-boarded in OpenRoaming) or by a trusted third-party infrastructure. In the case where an open roaming federation issues certificates for mutual authentication between the IDP and the VNs during roaming processes, the certificates might be reused to authenticate to the LAI service or new certificates might be issued for the purpose of exchanging identity information.

At block <NUM>, an AO registers with the LAI service and selects IDPs it uses. That is, the AO selects which of the registered IDPs it has a contractual relationship with. In one embodiment, the AO may be an IDP, in which case, it selects itself. Prior to registering with the LAI service, the AO should already have a unique ID and credentials to access its data within each IDP. Thus, the AO will have an ID and credentials to log into its associated IDPs and manage its devices. The AO can have a different set of ID and credentials for each of the IDPs to which it subscribes.

At block <NUM>, the LAI service assigns a tenant ID to the registered AO, unique tokens to the registered IDPs, and an ID to an AO application. If an AO wishes to register more than one category of identities for the same IDP in the LAI service, then the AO selects the IDP as many times as needed and different tokens are assigned to the IDPs by the LAI service. For instance, this might occur when the same entity can act as an IDP for two or more realms on behalf of the AO. In this way, each realm would be associated with only one (token, tenant ID) pair, while multiple tokens could be potentially assigned to the same IDP.

In one embodiment, the AO application is registered with the LAI service at block <NUM>. As mentioned above, the AO application is the destination of data streams originating both from the selected IDPs (e.g., for populating IDs for the devices owned by the AO) and from the VN (e.g., for receiving location updates for the devices owned by the same AO). The AO application has a unique ID within the LAI service (e.g., embodied as an AO application uniform resource identifier (URI)). To this end, the AO application might also have a certificate issued by a PKI trusted by the identity federation.

<FIG> is a table <NUM> in a LAI service storing the tenant ID for a registered ID, tokens to the registered IDPs, and AO application ID, according to one embodiment described herein. As shown, the table <NUM> includes three columns: a home/realm column, an authorized tenant ID column, and an AO application ID column. Upon registering the IDPs, AO, and AO application, the realms are not yet linked to the AO application ID, which happens in the next block of the method <NUM>. However, the remaining two columns indicate that there are individual tokens (i.e., Token <NUM>-n) assigned to the IDPs and a corresponding tenant ID assigned to the AO (i.e., tenantID = X). That is, the table <NUM> records each IDP that was selected by the AO having the tenantID X. The third column records the ID of the AO application (i.e., URI_X) corresponding to the AO X. In this manner, the LAI service records which IDPs were selected by the AO, and the ID for its corresponding AO application.

In one embodiment, the LAI service has a different table <NUM> for each AO. Alternatively, the LAI service has a single table for all the registered AOs, which includes their corresponding selected IDPs and AO applications.

At block <NUM>, the LAI service binds the IDPs selected at block <NUM> to the AO application. In one embodiment, each IDP may manage a pool of device IDs on behalf of the AO (e.g., one IDP manages a pool of LoRa devices, another IDP manages a pool for cellular devices, another IDP manages a pool of LTE devices, etc. which is illustrated in <FIG>). The devices may move freely within their home networks as well as roam across other VNs leveraging the open roaming federation. The open roaming federation can use dynamic discovery (DNS resolution) of the IDP based on a realm (e.g., a domain). A PKI used by the open roaming federation issues certificates to attest to the trustworthiness of the realm - i.e., establish an association between the previously registered IDP and the realm. Certificates issued to the IDPs by the PKI may be used to prove ownership of a given realm to the LAI service. The LAI service may also gather such information proactively from other subsystems within an open roaming federation (e.g., directly from the PKI).

When an IDP sends data to the LAI service, it uses a unique (token, tenantID) pair (e.g., the pairs illustrated in the second column of the table <NUM> in <FIG>) issued by the LAI service. For instance, in <FIG>, IDP <NUM> might use (Token <NUM>, tenantID = X) and may also send to the LAI service the realm used by the AO in the context of that IDP.

At sub-block <NUM>, as part of binding the IDPs to the AO application, the LAI service generates a table linking realms of the selected IDPs to the AO application. <FIG> illustrates updating the table in <FIG> to include the realms bound to the IDPs and the AO application. For instance, the IDP <NUM> may send the realm "NS1. lora-alliance. org" to the LAI service which is then stored in the left column. The same process applies to the other IDPs selected by the AO. That is, IDP n can send the realm "enterprise_X. com" which is also stored in the appropriate entry in the left column. Based on this, the LAI service may verify the ownership of the realms (as per the contents of the certificates issued by the federation) and update its state as shown in table <NUM>. Put differently, the LAI service can use the certificates provided by the PKI to the IDPs to establish a relationship of trust with the IDPs. Because of this relationship, the LAI service trusts the IDPs when they indicate which realm the "own" for a particular AO. In the example shown in table <NUM>, the same AO application is bound to two different realms which are each associated with a different IDP, i.e., IDP <NUM> and IDP n.

Assigning the realms to an IDP also binds the IDPs to the AO applications. In one embodiment, the realms are in, or derived from, the device ID provided by the devices. For instance, in LoRa, the device IDs do not explicitly include the realms. The realms might be built dynamically based on the ID or they could be inferred based on the ID. For instance, the part "netids. lora-alliance. org" is common to any ID. In sum, the realms might be included/provided by the device explicitly, inferred, or built dynamically from the device ID itself. In another example, a device may have an ID of DevAddr_x@NS1. lora-alliance. As discussed below, the LAI service can use the realm in the device ID (i.e., "NS1. lora-alliance. org") to map to a unique (token, tenant ID) pair in the table <NUM>. In turn, that (token, tenant ID) pair maps to a unique entry (e.g., row) in the table <NUM> in which there is only one AO Application ID authorized by the AO. Thus, any devices in that realm map to the same AO application. In this manner, because the realm is owned by the IDP (which has a relationship of trust with the LAI service), the LAI service uses table <NUM> to bind that realm (and thus, the IDP) to the AO application.

<FIG> illustrates the LAI service <NUM> communicating with IDPs <NUM> and the AO application <NUM>, according to one embodiment described herein. As already mentioned, the AO application <NUM> is the consumer of location data that is sent by the VNs and brokered and streamed by the LAI service <NUM> (where streaming occurs exclusively for the devices owned by the AO). The process below describes a potential embodiment to ensure trusted ID ownership and data flows across the LAI service <NUM>, which can be used in certain portions of the method <NUM>.

Device ID ownership might be handled in the following way within the LAI service. As shown in <FIG>, the device IDs might be fed directly by the sources, i.e., by the IDPs. In this way, the LAI service <NUM> does not broker messages for identities and/or data claimed or entered by the AO. More specifically, device IDs can be fed automatically by the IDPs <NUM> themselves, since IDPs <NUM> are the source of truth for the device IDs they manage. Hence, AOs do not have to manually enter a device ID or claim any device ID in the LAI service <NUM> since this is handled by the IDPs <NUM>. This also applies to device IDs supplied by the entities that act as IDPs on behalf of the AO.

In one embodiment, based on a root of trust (e.g., by using a PKI), and mutually authenticated interfaces, the LAI service <NUM> enables the binding of device IDs managed by the IDPs <NUM> to a specific AO application <NUM>. This binding is captured in the table <NUM> in <FIG>. The data flows used to populate the table <NUM> in <FIG> and feed the AO Application <NUM> with device IDs from the IDPs <NUM> might be based on the schema shown in <FIG>. For instance, each IDP <NUM> uses its own token (assigned by the LAI service <NUM>) and data are populated using the same tenant ID (i.e., the tenant ID assigned by the LAI service to the AO application <NUM>). In this way, the AO application <NUM> is a passive listener (consumer) of identity data produced by the IDPs <NUM> and brokered by the LAI service <NUM>.

As discussed below, location data might be received both from the home networks and from VNs while the devices are roaming. In the former case, home networks often act as IDPs <NUM> as well. Hence, certain IDPs <NUM> could feed and update the AO application <NUM> with location data when the devices are not roaming. In the latter case, location updates may come from a VN connector, such or from the corresponding IDP <NUM> directly. In case the entities interfacing with the LAI service <NUM> use a connector, the connector ID might also be conveyed in the messages sent from the IDP connectors or the VN connectors. Location data may be received by the LAI service <NUM>, processed, and pushed to the AO application <NUM> irrespective of the type of device and access technology used (e.g., LoRa, Wi-Fi, cellular, etc.). In <FIG>, the AO uses three different IDPs <NUM>, which correspond to three different wireless communication schemas (e.g., LoRa, Wi-Fi, and cellular), to enable the LAI service <NUM> to push location data of the AO's devices to the AO application <NUM>.

In another embodiment, the AO application <NUM> may require explicit approval from the IDPs <NUM> before data can be streamed to the AO application <NUM>. This covers the scenario of initially populating the AO application <NUM> with data coming from the source of truth (i.e., the IDPs). This might require explicit approval from the IDPs themselves (otherwise IDs won't show in the AO application <NUM>). Obtaining explicit approval might use an SSO process supported by two/multi-factor authorization (<NUM>/MFA) or alternative verification means assuming the IDPs <NUM> are already registered with the LAI service <NUM>. An explicit approval process could be instrumented vs. implicit (or inferred) binding, where IDPs <NUM> grant access to an AO application in the LAI service <NUM>, rather than the other way around.

<FIG> is a flowchart of a method <NUM> for enabling a VN to share location data with an AO application, according to one embodiment described herein. In one embodiment, the method <NUM> assumes that the method <NUM> has been performed to populate the table <NUM> in <FIG>.

At block <NUM>, a VN detects a roaming device. This is illustrated in <FIG> where the roaming device <NUM> has disconnected from its home network <NUM> and is now attempting to connect to the VN <NUM>.

At block <NUM>, the IDP authenticates the device through the identity federation and permits the device to attach to the VN. That is, the VN can use an identity federation (e.g., an open roaming federation) to authenticate the device. In one embodiment, as shown in <FIG>, the VN connector <NUM> establishes a secure tunnel to the IDP connector <NUM> which permits the IDP <NUM> and VN <NUM> to exchange data for authenticating the device <NUM>. This secure tunnel may be based on mutual authentication. In the case of Wi-Fi, the connectors could proxy and forward RADIUS messages over a WAN link (using RADSEC). For private cellular networks, the connectors could proxy DIAMETER messages over a WAN link and forward them to the corresponding DRA and HSS. For LoRa, the connectors could proxy and forward the Passive Roaming Start Requests (PRStartReq) and Passive Roaming Start Answers (PRStartAns) over a WAN link. The VN connectors may be standalone entities dealing with each access technology individually or architected as a single multi-access connector.

Once the device has been authenticated using the identity federation, the following blocks in the method <NUM> can be used to dynamically identify the AO application ID through the LAI service.

At block <NUM>, the VN determines that a sharing policy permits the VN to share the location of the device. Based on a device ID, the VN determines whether the device is a roaming device or a local one and apply a predefined policy indicating whether the VN should or should not share location data of the device. This policy may be based on the particular realm provided in the device ID. That is, the VN can identify the realm from the device ID, and use this realm to index into the policy to determine whether the policy forbids or permits the VN to share location data for devices in that realm. That is, it is up to the VN policy to decide whether to check if an AO want to receive location data for its devices. The VN may also decide whether or not to send such data to a third-party entity using the realm in the device ID.

Assuming the policy permits the VN to show the location of the device, at block <NUM>, the VN connector queries the LAI service to determine whether location data for the device (or for the realm) is needed. In one embodiment, the VN connector shares the device ID, the realm associated to that device, and other metadata (subject to privacy regulations) with the LAI service.

<FIG> illustrates a system for enabling the VN <NUM> to share location data with an AO application, according to one embodiment described herein. The arrows <NUM> and <NUM> illustrate the VN <NUM> and VN connector <NUM> querying the LAI service <NUM> to determine whether location data for the device is needed, where the VN connector <NUM> provides the device ID, the realm associated with that device, and other metadata to the LAI service. In scenarios where government regulation (e.g., privacy regulation) restricts querying the LAI service using the device ID as an input, a combination of realm and second order factors might be used, as long as they support automated verification. For instance, a hash of an identifiable accounting log entry, a hash of an identifiable LoRa MAC frame, etc. For example, the VN connector may include all or a subset of the following parameters in the message sent to the LAI service (the first two are directed to the LAI service itself, while the last two are the ones that should be brokered and forwarded to the AO): the VN ID, the home network ID, the realm, or the device ID.

Returning to the method <NUM>, at block <NUM>, the LAI service identifies the AO application using the realm provided by the device and the VN connector. That is, with the realm, the LAI system can resolve the authorized tenant ID and dynamically determine the ID of the corresponding AO application. Using table <NUM> as an example, if the realm in the device ID was "enterprise_X. com", then the LAI service can identify the appropriate row that has the tenantID (X) and the AO application ID (URI_X).

At block <NUM>, the LAI service enables the VN to share the location of the device with the AO application. The LAI service can broker the query sent by the VN connector to the AO application as shown by the arrow <NUM> in <FIG>. In general, the query sent to the AO application <NUM> determines whether location data is needed for specific devices or an entire realm. The AO application then replies (also shown by arrow <NUM>). The reply is brokered by the LAI service <NUM> and forwarded back to the VN connector <NUM> as shown by the arrow <NUM>. If the query was accepted by the AO application <NUM>, the LAI service <NUM> may return the AO Application ID to the VN connector <NUM> so that the VN <NUM> may obtain explicit consent (digitally signed) by the AO application <NUM> before sharing any location data with it, which is discussed in detail in <FIG>. The LAI service <NUM> can also provide to the VN <NUM> the ID of the AO's IDP as per the realm sent in the query. The VN <NUM> can use this ID to verify and bind the AO Application ID to the IDP that authenticated the device during the roaming phase. In this manner, the IDP ID bonded to the just discovered AO application <NUM> is provided to the VN <NUM> by a trusted entity, i.e., the LAI service <NUM>. The VN (or VN connector) can then begin to push location updates corresponding to the roaming device to the AO application <NUM>.

In one embodiment, the VN pushes location data to the LAI service which in turn brokers and shares the updates with the corresponding AO application. In other embodiments, the VN can push the location data to the AO application without using the LAI service as an intermediary or broker. The location data might include the device ID and latitude and longitude coordinates. The update policy might be decided by the VN (e.g., only push location every S sec. , every M min. , every H hours every time the device changes its location, upon changes on the VN attached, etc.). Data sharing can be stopped by the VN, the LAI service or the AO application. For example, when the device leaves the venue, if it misbehaves, if an IDP deletes an ID from the LAI service, if the AO does not want to keep accumulating data sharing costs, etc..

In a further enhancement, the AO application may reply to the request from VN by allowing the VN to share location data with a third-party entity (e.g., for handling purposes, as part of an automated supply chain, for unmanned operations, etc.). Such third-party entities should be trusted within the LAI service. That is, these third-party entities may have already been registered with the LAI service and have a unique Application ID (e.g., a URI) and corresponding entries in the LAI service (e.g., a table like in <FIG>). The corresponding (token, tenant ID) pair could be generated by the LAI service based on delegation from a valid AO tenant.

In another enhancement, incentive models might be used to foster data sharing. For instance, AOs might be willing to pay for such information. Likewise, the LAI service would have incentives to provide and scale out such service. The incentives for VNs might be based on direct monetization or indirect means to generate revenue (e.g., by offering such service, a port might attract more cargo).

Further, the techniques described above applies even for devices that might move within their home networks. That is, considering mobility without necessarily roaming, where both the AO and the service provider might benefit from getting accurate location data.

<FIG> is a flowchart of a method <NUM> for obtaining explicit consent to share location data from the AO application, according to one embodiment described herein. In one embodiment, the method <NUM> is performed after block <NUM> where the LAI service has indicated to the VN which AO application should receive the location information for the roaming device.

At block <NUM>, the VN first determines whether the AO application has already consented to sharing the location of the device. For example, a different device owned by the AO may have previously roamed to the VN where the AO gave its consent to share location data. The VN may have a local policy to authorize, and cache consented exchanges for a period of time before querying the LAI service again.

However, assuming consent was not previously given, the method <NUM> proceeds to block <NUM> where the VN requests that the AO application signs a consent. Using <FIG> as an example, the arrow <NUM> illustrates the VN connector <NUM> transmitting the request for consent to the LAI service <NUM> which, serving as a broker, forwards the request to the AO application <NUM> as shown by arrow <NUM>.

A signed consent is then sent back to the VN connector as shown by the arrow <NUM>. In <FIG>, the exchanges concerning explicit consent are brokered by the LAI service <NUM>, though other models could be applied as well, including direct peer-to-peer exchanges or using another system as the broker.

At block <NUM>, the VN verifies the received consent. The VN could rely on the PKI to verify the AO application's signature as well as the data provided in block <NUM> of the method <NUM>. Doing so allows the VN to verify whether the IDP ID matches the one that authenticated the device. Alternative options may include WC3 verifiable credentials (e.g., the IDP may vouch for a verifiable credential on behalf of the AO application), token-based mechanisms to bond the two, and the like.

If at block <NUM> the VN cannot verify the consent, the method <NUM> proceeds to block <NUM> where the VN does not share or push out location information related to the roaming device to the AO application or other third parties. However, assuming the consent is verified, the method <NUM> proceeds to block <NUM> of the method <NUM> as described above.

In the current disclosure, reference is made to various embodiments. However, the scope of the present disclosure is not limited to specific described embodiments. Instead, any combination of the described features and elements, whether related to different embodiments or not, is contemplated to implement and practice contemplated embodiments. Additionally, when elements of the embodiments are described in the form of "at least one of A and B," it will be understood that embodiments including element A exclusively, including element B exclusively, and including element A and B are each contemplated. Furthermore, although some embodiments disclosed herein may achieve advantages over other possible solutions or over the prior art, whether or not a particular advantage is achieved by a given embodiment is not limiting of the scope of the present disclosure. Thus, the aspects, features, embodiments and advantages disclosed herein are merely illustrative and are not considered elements or limitations of the appended claims except where explicitly recited in a claim(s). Likewise, reference to "the invention" shall not be construed as a generalization of any inventive subject matter disclosed herein and shall not be considered to be an element or limitation of the appended claims except where explicitly recited in a claim(s).

Claim 1:
A method, comprising:
registering(<NUM>) a plurality of identity providers, IDPs, with a location, aggregation, and insights, LAI, service (<NUM>), wherein the LAI service (<NUM>), the plurality of IDPs, and an asset owner, AO, are part of an identity federation;
registering (<NUM>) the AO with the LAI service (<NUM>), wherein registering the AO comprises selecting one of more of the IDPs already registered with the LAI service (<NUM>);
binding (<NUM>), in the LAI service (<NUM>), the selected IDPs to an AO application (<NUM>) of the AO, wherein the selected IDPs and the AO application (<NUM>) have respective realms in common;
after detecting a device has roamed to a visited network (<NUM>), VN, (<NUM>) in the identity federation, receiving a realm associated with the device at the LAI service (<NUM>) from the VN (<NUM>);
identifying (<NUM>), at the LAI service (<NUM>), the AO application (<NUM>) by matching the received realm to one of the respective realms; and
enabling (<NUM>) the VN (<NUM>) to push location information corresponding to the device to the AO application (<NUM>).