Patent Description:
Internet of Things (IoT) clients communicate in a one-to-many fashion using topic-based publish and subscribe messages exchanged via an intermediate Broker. For example, a first IoT client subscribes to a particular topic. When a second IoT client publishes a message regarding the particular topic, an IoT Broker fans-out the published message to IoT clients that have subscribed to the particular topic such as the first IoT client. If the first IoT client unsubscribes to the particular topic, the IoT Broker no longer fans-out a message regarding the particular topic to the first IoT client.

A plethora of disparate communications resources exist including resources using private wireless communications (e.g., public safety and first responder communications networks), public switched network communications resources, public wireless networks, networks of video surveillance devices, private security networks, and the like. Additionally, millions of consumers and public officials are now equipped with smartphone devices that include multiple communications abilities including both voice and video communications.

Often these communications resources cannot communicate with each other. For example, private wireless communication networks, such as those used by public safety or commercial users, are typically isolated from one another and utilize different and often incompatible technologies. While interoperability products are available to interconnect such diverse systems, cooperation among the entities involved is often a barrier to full and scalable implementation. Thus, first responder siloed communication systems exist where control of the resources of each organization coupled to the system is controlled by a central administrator or controller, and each organization providing resources to the system must relinquish control of its resources to the central administrator. The organization responsible for the operation of its radio system(s) may be unable or unwilling to grant control of its resources either to peer organizations or to a higher-level organization.

<CIT>, and <CIT>, both of which are incorporated by reference in their entirety, describe systems and methods for providing an interoperable communications system ("interop system," also referred to as an Incident Communications Network) including a plurality of otherwise disjunct or disparate communications systems that addressed the deficiencies of prior art systems. The `<NUM> and `<NUM> patents specifically describe methods for establishing an incident communications network that enables interoperable communications among communications resources controlled by multiple organizations during an incident involving emergency or pre-planned multi-organization communications where a communications resource is controlled by an administrator within an organization.

Additionally, <CIT>, ("Mobile IWC Patent") which is also incorporated herein by reference in its entirety, extends the concepts of the `<NUM> and `<NUM> patents. Namely, the Mobile IWC Patent includes enhanced video capture and streaming capabilities that are integrated with incident information and events to facilitate improved management and analysis of incidents or events in which an incident communications network is employed.

<CIT>, ("Marshalling Patent") which is also incorporated herein by reference in its entirety, extends the concepts of the '<NUM> and `<NUM> patents. Namely, the Marshalling Patent provides systems and methods that marshal resources into an incident communications network based on a variety of factors, such as the type of incident and the type of resource being marshaled.

<CIT>, which is incorporated herein by reference in its entirety, extends the concepts of the `<NUM> and `<NUM> patents, Marshalling Patent, and the Mobile IWC Patent.

<CIT> relates to a publish-subscribe broker network using certificates to identify endpoints and allow them to participate in specific channels. An emergency ad-hoc network is disclosed as a use case for this system.

Some embodiments include a system, method, and computer program product for Internet of Things (IoT) dynamic policy management during an incident. For example, IoT client devices can create or join an incident communications network and during the incident, some embodiments enable dynamic IoT subscribe/publish policy changes associated with the corresponding certificates of the IoT client devices. The dynamic IoT policy changes can assist agencies during an incident (e.g., a national crisis, emergency, or pre-planned multi-organization communications) to resolve the incident.

Some embodiments include a system for a broker policy manager (BPM) according to claim <NUM>.

To determine that the first IoT client is a participant of the incident communications network, the processor can receive an indication via the transceiver, directly or indirectly from the first IoT client, that the first IoT client has created the incident, or that the first IoT client has been invited to join the incident communications network. To indirectly receive an indication that the first IoT client is a participant of the incident communications network, the processor can subscribe to a topic that includes the BPM (e.g., the BPM as an IoT client subscribes to Topic-BPM. ) The first IoT client can communicate the incident name and the first IoT client identifier as information on the topic, to the certificate-based IoT broker associated with the topic (e.g., publish a message including the Topic-BPM/incident name/first IoT client identifier). The certificate-based IoT broker receives and distributes the published message including Topic-BPM/incident name/first IoT client identifier to subscribers of Topic-BPM which includes the BPM. Thus, the processor indirectly receives the indication that the first IoT client is a participant of the incident, from the certificate-based IoT broker. The BPM in turn adjusts the publish/subscribe certificate permissions for the first IoT client.

In some embodiments, the subscribe and published messages are based on a real time publication-subscription, data-sync, or request-response protocol including but not limited to, HyperText Transfer Protocol (HTTP), Message Queueing Telemetry Transport (MQTT) protocol, Extensible Messaging and Presence Protocol (XMPP), Streaming Text Oriented Messaging Protocol (STOMP), Advanced Message Queuing Protocol (AMQP), Web Application Messaging Protocol (WAMP), Java Message Service (JMS), ZeroMQ Message Transport Protocol (ZMTP), or proprietary messaging protocols, where the subscription includes subscribing to the topic relating to the incident.

In some embodiments, the first IoT client includes: a software routine; a web browser; a map or a region of a map; a graphical user interface (GUI); an actuator; an artificial intelligence or analytics based object, event, or condition; a state change state detection module that interprets video data, either alone or in concert with other real time, historical or predictive data from other sensors, systems, databases, analytical functions, or information sources; a sensor; a sensor coupled to another device or module that causes an alarm, event notification, or warning signal to be transmitted to a rules-based or pre-designated recipient agent; a gas sensor; a smoke/fire detector; or a contact closure of a switch or panic button.

In some embodiments, the first IoT client comprises a GUI of an interoperability work station (IWS) coupled to the incident communications network, and the processor can determine that a third IoT client shares the first certificate with the first IoT client, where the first certificate enables the third IoT client to publish and/or subscribe to the topic that includes the incident.

In some embodiments, to determine that the first IoT client is a participant of the incident communications network, the processor can receive via the transceiver, an indication on a multicast channel of a multicast-based communication system, that the first IoT client has created the incident, or that the first IoT client has been invited to join the incident communications network.

Further embodiments, features, and advantages, as well as the structure and operation of the various embodiments, are described in detail below with reference to accompanying drawings. It is noted that the embodiments are presented herein for illustrative purpose only. Additional embodiments will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein.

In an Internet of Things (IoT) system, IoT clients communicate in a one-to-many fashion using topic-based publish and subscribe messages exchanged via an IoT Broker over the Internet. For example, IoT client A can subscribe to a topic and inform the IoT Broker. When IoT client B publishes information to that topic and informs the IoT Broker, the IoT Broker fans the published information of that topic to IoT client A and other IoT clients that have subscribed to that topic. Some IoT Brokers can include certificates to establish the confirmed identities of IoT clients to prevent an unauthorized IoT client from eavesdropping or receiving published information. The certificates can also include policies that include permissions for an IoT client to publish and/or subscribe to messages on certain topics. For example, a policy of certificate A may allow IoT client A to perform the following: publish messages on Topics <NUM> and <NUM>, but not other topics; or subscribe to messages on Topic-<NUM>, but not publish messages on Topic-<NUM>.

The policies associated with certificates are communicated to the IoT Broker via a network-based application programming interface (API) and a graphical user interface (GUI). For example, an operator uses the GUI to set up the system certificates and policies in a static manner at system design time. The static arrangements identify the IoT clients that are allowed to publish and subscribe to certain topics. For example, an IoT client A can be a controller for a security video camera that streams video of a business' premises. The associated policy and certificate may indicate that the video from IoT client A can only be published to the business owner's devices to maintain privacy. While the static certificates and policies maintain privacy, there are incidents (e.g., emergencies) in which owners of the IoT clients may want the certificates and policies to be dynamically changed to allow others to have access to the published information related to the incidents. For example, in the event of a fire, the business owner of IoT Client A may allow the security video camera (IoT client A) to stream video and/or images to the fire department, or even yield control of the security video camera to the fire department. But, static certificates and policies do not permit this flexibility. Some embodiments enable dynamic IoT policy management during an incident.

An incident communications network enables interoperable communications among communications resources controlled by multiple organizations or individuals during an incident involving emergency or pre-planned multi-organization communications in which a communications resource is controlled by an administrator within an organization, or by an individual. The incident communications network includes interoperability workstation (IWS) controllers to control communications resources and enable a user a means to control and interface with the incident communications network. The incident communications network are described in the `<NUM>, `<NUM>, and `<NUM> patents, Marshalling Patent, and the Mobile IWC Patent that incorporated herein by reference.

Some embodiments enable IoT client devices to join an incident communications network and enable dynamic IoT policy management of the IoT client devices during an incident. <FIG> illustrates a system <NUM> for dynamic Internet of Things (IoT) policy management during an incident, according to an example embodiment. System <NUM> includes IoT Client <NUM>, Broker Policy Manager (BPM) <NUM>, and Certificate-based IoT Broker <NUM>. IoT Client <NUM> can be: a software routine; a web browser; a map or a region of a map; a graphical user interface (GUI); an actuator; an artificial intelligence or analytics based object, event, or condition; a state change state detection module that interprets video data, either alone or in concert with other real time, historical or predictive data from other sensors, systems, databases, analytical functions, or information sources; a sensor; a sensor coupled to another device or module that causes an alarm, event notification, or warning signal to be transmitted to a rules-based or pre-designated recipient agent; a gas sensor; a smoke/fire detector; or a contact closure of a switch or panic button.

Certificate-based IoT Broker <NUM> executes the certificates and policies for corresponding IoT clients such as IoT Client <NUM>. As described above, the policies indicate whether IoT Client <NUM> has permission to subscribe to and/or publish on various topics. BPM <NUM> can dynamically change the policies of the certificate associated with IoT Client <NUM> based on an incident invitational model. In some embodiments, when IoT Client <NUM> is a participant in an incident communications network, IoT Client <NUM> (e.g., a GUI on an interoperability workstation (IWS) or mobile IWS) can publish and/or subscribe to messages associated with that incident-topic. Some exchanges in system <NUM> are described below:.

At <NUM> IoT Client <NUM> can create an incident named 'incident-abc. ' In some embodiments, BPM <NUM> can determine that IoT Client <NUM> has joined incident-abc communications network and/or created incident-abc communications network in a variety of ways. In some embodiments, BPM <NUM> listens to a multicast channel to learn that IoT Client <NUM> has been invited to join incident-abc communications network or has created incident-abc communications network. In some embodiments, BPM <NUM> receives a signal from an Interoperability Workstation (IWS) that IoT Client <NUM> has been invited to join incident-abc communications network. In some embodiments, BPM <NUM> directly or indirectly receives a communication from IoT Client <NUM> via a signaling channel indicating that IoT Client <NUM> has joined or created incident-abc communications network as described above. The signaling channel can include request and receive exchanges based on a real time publication-subscription, data-sync, or request-response protocol, including but not limited to, HyperText Transfer Protocol (HTTP), Message Queueing Telemetry Transport (MQTT) protocol, Extensible Messaging and Presence Protocol (XMPP), Streaming Text Oriented Messaging Protocol (STOMP), Advanced Message Queuing Protocol (AMQP), Web Application Messaging Protocol (WAMP), Java Message Service (JMS), ZeroMQ Message Transport Protocol (ZMTP), or proprietary messaging protocols, where the request includes subscribing to the topic relating to the incident.

At <NUM>, BPM <NUM> can transmit a signal to Certificate-based IoT Broker <NUM> to change the policy of the certificate associated with IoT Client <NUM> to allow IoT Client <NUM> to now publish and subscribe to Topic-abc. Certificate-based IoT Broker <NUM> updates IoT Client <NUM>'s certificate policy accordingly.

At <NUM>, IoT Client <NUM> can transmit a message to Certificate-based IoT Broker <NUM> to publish on Topic-abc. When the message is received, Certificate-based IoT Broker <NUM> verifies that IoT Client <NUM> is permitted to publish on Topic-abc based on the dynamic policy change due to <NUM> above. Since IoT Client <NUM> has permission to publish information regarding Topic-abc, Certificate-based IoT Broker <NUM> distributes the published Topic-abc to IoT clients (not shown) that have subscribed to Topic-abc.

At <NUM>, IoT Client <NUM> can transmit a message to subscribe to Topic-abc. When the message is received, Certificate-based IoT Broker <NUM> verifies that IoT Client <NUM> is permitted to subscribe to Topic-abc based on the dynamic policy change due to <NUM> above. Thereafter, IoT Client <NUM> can receive information regarding Topic-abc published from other IoT clients (not shown) that are authorized to publish on Topic-abc.

In this example IoT Client <NUM> is not authorized to publish or subscribe to Topic-xyz associated with incident xyz, because IoT Client <NUM> is not a member of incident-xyz. Thus messages <NUM> to publish or <NUM> to subscribe to Topic-xyz are not accepted by Certificate-based IoT Broker <NUM>.

<FIG> illustrates a block diagram <NUM> of an example wireless system for dynamic IoT policy management during an incident, according to an example embodiment. As a convenience and not a limitation, system <NUM>, may be described with elements of <FIG>. System <NUM> can be IoT Client <NUM>, BPM <NUM>, and/or Certificate-based IoT Broker <NUM> of <FIG>. System <NUM> may include processor <NUM>, transceiver <NUM>, communication infrastructure <NUM>, memory <NUM>, and antenna <NUM> that together perform operations enabling dynamic IoT policy management during an incident. Transceiver <NUM> transmits and receives wireless communications signals via antenna <NUM>. Communication infrastructure <NUM> may be a bus. Memory <NUM> may include random access memory (RAM) and/or cache, and may include control logic (e.g., computer software), computer instructions, and/or data. Processor <NUM>, upon execution of the computer instructions, can be configured to perform the functionality described herein for dynamic IoT policy management during an incident. Alternatively, processor <NUM> can include its own internal memory (not shown), and/or be "hard-wired" (as in a state-machine) configured to perform the functionality described herein for dynamic IoT policy management during an incident. Antenna <NUM> coupled to transceiver <NUM>, may include one or more antennas and/or panels (not shown) that may be the same or different types to enable wireless communication over a wireless network. In some embodiments transceiver <NUM> may transmit and receive signals via a wired network (not shown.

<FIG> illustrates a system <NUM> for dynamic IoT policy management during an incident with a second IoT client, according to an example embodiment. As a convenience and not a limitation, system <NUM>, may be described with elements of <FIG> and <FIG>. System <NUM> includes IoT Client <NUM>, BPM <NUM>, Certificate-based IoT Broker <NUM>, and IoT Client <NUM>. In this example, IoT Client <NUM> invites IoT Client <NUM> to join incident-abc communications network, and some embodiments enable IoT Client <NUM> to publish and/or subscribe to messages on Topic-abc.

At <NUM>, IoT Client <NUM> can invite IoT Client <NUM> to join incident-abc communications network.

At <NUM>, IoT Client <NUM> accepts the invitation to join incident-abc communications network. BPM <NUM> learns about IoT Client <NUM> joining incident-abc communications network via a signaling channel via IoT Client <NUM> and/or IoT Client <NUM>, or by listening to a multicast channel of the incident communications network. BPM <NUM> dynamically determines whether to adjust the policies of the certificate corresponding to IoT Client <NUM> so that IoT Client <NUM> can publish and/or subscribe to IoT messages on Topic-abc. In this example, BPM <NUM> determines that IoT Client <NUM> can publish and subscribe to Topic-abc.

At <NUM>, IoT Client <NUM> can transmit a message to subscribe to Topic-abc. When the message is received, Certificate-based IoT Broker <NUM> verifies that IoT Client <NUM> is permitted to subscribe to Topic-abc based on the dynamic policy change due to <NUM> above. Thereafter, IoT Client <NUM> can receive information regarding Topic-abc published from other IoT clients (e.g., IoT Client <NUM>) that are authorized to publish on Topic-abc. IoT Clients <NUM> and <NUM> can now exchange IoT messages on Topic-abc via Certificate-based IoT Broker <NUM>. In addition to or alternatively, IoT Clients <NUM> and <NUM> can exchange media using existing means (e.g., via the incident-abc communications network.

At <NUM>, IoT Client <NUM> can transmit a message to Certificate-based IoT Broker <NUM> to publish on Topic-abc. Certificate-based IoT Broker <NUM> verifies that IoT Client <NUM> is permitted to publish on Topic-abc. For example, if incident-abc was a fire and the fire department was a member of the incident-abc communication network, IoT Client <NUM> can publish a message to Topic-abc that causes IoT Client <NUM> to perform an action. If IoT Client <NUM> was a fire sensor, IoT Client <NUM> can publish a message to Topic-abc that causes IoT Client <NUM> to transmit whether any smoke is detected, a temperature reading, and/or a fire alarm.

At <NUM>, Certificate-based IoT Broker <NUM> distributes the published message on Topic-abc to IoT Client <NUM> that subscribed to Topic-abc (e.g., at <NUM> above.

At <NUM>, IoT Client <NUM> transmits a publish message on Topic-abc that is received by Certificate-based IoT Broker <NUM> that verifies that IoT Client <NUM> is permitted to publish on Topic-abc. For example, IoT Client <NUM> can publish a message on Topic-abc in response to the instructions received due to <NUM>, according to the published message on Topic-abc. For example, IoT Client <NUM> may transmit a report or readings of a sensor (e.g., whether any smoke is detected, a temperature reading, and/or a fire alarm.

At <NUM>, Certificate-based IoT Broker <NUM> distributes the published message on Topic-abc to IoT Client <NUM> based at least on <NUM> of <FIG>.

<FIG> illustrates a system <NUM> for dynamic IoT policy management during an incident with multiple IoT clients, according to an example embodiment. As a convenience and not a limitation, system <NUM>, may be described with elements of <FIG>. System <NUM> includes IoT Client <NUM>, BPM <NUM>, Certificate-based IoT Broker <NUM>, IoT Client <NUM>, and IoT Client <NUM>. In this example, IoT Client <NUM> invites IoT Client <NUM> to join incident-abc communications network, and illustrates the fanning out of publishing messages on Topic-abc to authorized IoT client subscribers.

At <NUM>, IoT Client <NUM> accepts the invitation to join incident-abc communications network. BPM <NUM> learns about IoT Client <NUM> joining incident-abc communications network via a signaling channel via IoT Client <NUM> and/or IoT Client <NUM>, or by listening to a multicast channel of the incident-abc communications network. BPM <NUM> dynamically determines whether to adjust the policies of the certificate corresponding to IoT Client <NUM> so that IoT Client <NUM> can publish and/or subscribe to IoT messages on Topic-abc. In this example, BPM <NUM> determines that IoT Client <NUM> can publish and subscribe to Topic-abc.

At <NUM>, IoT Client <NUM> can transmit a message to subscribe to Topic-abc. When the message is received, Certificate-based IoT Broker <NUM> verifies that IoT Client <NUM> is permitted to subscribe to Topic-abc based on the dynamic policy change due to <NUM> above. Thereafter, IoT Client <NUM> can receive information regarding Topic-abc published from other IoT clients (e.g., IoT Client <NUM> and IoT Client <NUM>) that are authorized to publish on Topic-abc. IoT Clients <NUM>, <NUM>, and <NUM> can now exchange IoT messages on Topic-abc via Certificate-based IoT Broker <NUM>. In addition to or alternatively, IoT Clients <NUM>, <NUM>, and <NUM> can continue to exchange media using existing means (e.g., via the incident-abc communications network.

At <NUM>, IoT Client <NUM> can transmit a message to Certificate-based IoT Broker <NUM> to publish on Topic-abc. Certificate-based IoT Broker <NUM> verifies that IoT Client <NUM> is permitted to publish on Topic-abc.

At <NUM>, Certificate-based IoT Broker <NUM> distributes the published message on Topic-abc to IoT Client <NUM> that subscribed to Topic-abc (e.g., at <NUM> of <FIG> above.

At <NUM>, IoT Client <NUM> transmits a publish message on Topic-abc that is received by Certificate-based IoT Broker <NUM> that verifies that IoT Client <NUM> is permitted to publish on Topic-abc.

At <NUM>, Certificate-based IoT Broker <NUM> distributes the published message on Topic-abc to IoT Client <NUM> based at least on <NUM> above.

At <NUM>, Certificate-based IoT Broker <NUM> distributes the published message on Topic-abc to IoT Client <NUM> based at least on <NUM> of <FIG> above.

<FIG> illustrates a system <NUM> for dynamic IoT policy management during an incident when an IoT client leaves an incident, according to an example embodiment. As a convenience and not a limitation, system <NUM>, may be described with elements of <FIG>. System <NUM> includes IoT Client <NUM>, BPM <NUM>, Certificate-based IoT Broker <NUM>, IoT Client <NUM>, and IoT Client <NUM>. In this example, IoT Client <NUM> leaves incident-abc communications network, and system <NUM> illustrates the termination of policies for IoT Client <NUM> that remove permissions for IoT Client <NUM> to publish and subscribe to messages on Topic-abc.

At <NUM>, IoT Client <NUM> leaves incident-abc communications network. BPM <NUM> learns about IoT Client <NUM> leaving incident-abc communications network via a signaling channel via IoT Client <NUM> and/or IoT Client <NUM>, or by listening to a multicast channel of the incident-abc communications network. BPM <NUM> dynamically determines to adjust the policies of the certificate corresponding to IoT Client <NUM> so that IoT Client <NUM> can no longer publish and/or subscribe to Topic-abc.

At <NUM>, BPM <NUM> can transmit a signal to Certificate-based IoT Broker <NUM> to change the policy of the certificate associated with IoT Client <NUM> to remove permissions for IoT Client <NUM> to publish or subscribe to Topic-abc. Certificate-based IoT Broker <NUM> updates IoT Client <NUM>'s certificate policy accordingly.

At <NUM>, IoT Client <NUM> can transmit a message to unsubscribe to Topic-abc. When the message is received, Certificate-based IoT Broker <NUM> verifies that IoT Client <NUM> is not unsubscribed to Topic-abc based on the dynamic policy change due to <NUM> above. Thereafter, IoT Client <NUM> will no longer receive information regarding Topic-abc published from other IoT clients (e.g., IoT Client <NUM> and IoT Client <NUM>) that are authorized to publish on Topic-abc. While IoT Clients <NUM> and <NUM> can continue exchange IoT messages on Topic-abc via Certificate-based IoT Broker <NUM>, and/or via the incident-abc communications network, IoT Client <NUM> will no longer be permitted to publish (e.g., transmit) or subscribe (e.g., receive) messages regarding Topic-abc.

At <NUM>, Certificate-based IoT Broker <NUM> distributes the published message onTopic-abc to IoT Client <NUM> that subscribed to Topic-abc (e.g., at <NUM> of <FIG> above.

<NUM> illustrates that Certificate-based IoT Broker <NUM> does not transmit the published message on Topic-abc to IoT Client <NUM>.

<FIG> illustrates a system <NUM> for dynamic IoT policy management during an incident with associated IoT clients, according to an example embodiment. As a convenience and not a limitation, system <NUM>, may be described with elements of <FIG>. System <NUM> includes IoT Client <NUM> (e.g., a sensor), IoT Client <NUM> (e.g., a GUI), BPM <NUM>, Certificate-based IoT Broker <NUM>, and IoT Client <NUM>. In some embodiments IoT clients with unique identifiers can share the same certificate. In some embodiments, IoT clients with unique identifiers that have separate corresponding certificates that are associated or linked together. For example, IoT Client <NUM> can be a GUI on an IWS and IoT Client <NUM> can be a video camera, or an actuator that controls an access to a facility (e.g., locks and unlocks a door). In some examples, IoT Client <NUM> and IoT Client <NUM> may be owned by the same agency (e.g., fire department, police department, Federal Bureau of Investigation (FBI), etc.) Thus, when IoT Client <NUM> joins an incident, one or more IoT clients like IoT Client <NUM> may also join the incident.

At <NUM>, IoT Client <NUM> can signal a policy change to BPM <NUM> that one or more other IoT clients' certificates in addition to IoT Client <NUM>'s policy may be authorized to publish and/or subscribe on Topic-abc, where the one or more IoT Clients' certificates are unique. The policy change can be the same or different than that of IoT Client <NUM>. As an example, <NUM> can be transmitted in time proximity to <NUM> of <FIG>. In some embodiments when IoT Client <NUM> shares the same certificate with another IoT client, then the abilities to publish and/or subscribe are the same as that of IoT Client <NUM>.

At <NUM>, which can be an extension of <NUM> of <FIG>, BPM <NUM> can determine that IoT Client <NUM> and IoT Client <NUM> have unique identities but share the same certificate and/or policies. In some embodiments, BPM <NUM> can determine that IoT Client <NUM> and IoT Client <NUM> have unique identities, different certificate/policies, and their certificates are associated or linked together. BPM <NUM> can dynamically determine whether IoT Client <NUM> can only-publish, only-subscribe, or publish and subscribe to Topic-abc corresponding to incident-abc, and inform Certificate-based IoT Broker <NUM> accordingly. In some embodiments the dynamic determination is based on instructions received from IoT Client <NUM> at <NUM>. In this example, BPM <NUM> determines that IoT Client <NUM> can only publish to Topic-abc.

At <NUM>, Certificate-based IoT Broker <NUM> distributes the published message on Topic-abc to IoT Client <NUM> that subscribed to Topic-abc (e.g., at <NUM> above. ) Note that Certificate-based IoT Broker <NUM> does not transmit the published message on Topic-abc to IoT Client <NUM> because, according to the instructions of BP <NUM> at <NUM> above, IoT Client <NUM> can only publish to Topic-abc. IoT Client <NUM> cannot subscribe to Topic-abc.

At <NUM>, IoT Client <NUM> can transmit a message to Certificate-based IoT Broker <NUM> to publish on Topic-abc. For example, if IoT Client <NUM> were a video camera, IoT Client <NUM> can stream data, or if IoT Client <NUM> were a sensor, the sensor's readings and/or alarms can be transmitted. Certificate-based IoT Broker <NUM> verifies that IoT Client <NUM> is permitted to publish on Topic-abc.

At <NUM>, Certificate-based IoT Broker <NUM> distributes the published message on Topic-abc to IoT Client <NUM> that subscribed to Topic-abc (e.g., at <NUM> of <FIG> above. ) In some embodiments, IoT Client <NUM> shares a certificate with one or more IoT Clients, or IoT Client <NUM> is associated or linked with one or more IoT Clients and/or their corresponding certificates. When IoT Client <NUM> receives the published information from IoT Client <NUM> (e.g., a temperature gauge reading and/or an alert regarding the value; or a video stream or image), IoT Client <NUM> (e.g., as a GUI) may take control of IoT Client <NUM> (e.g., control pan/tilt/zoom, actuator control to lock or unlock doors.

In some embodiments, when BPM <NUM> determines that IoT Client <NUM> can both publish and subscribe to Topic-abc (not shown), then IoT Client <NUM> can subscribe to and receive published messages on Topic-abc. For example, other members of the incident communications network can access IoT Client <NUM> (e.g., control pan/tilt/zoom, or actuator control lock or unlock doors) via the incident-abc communications network or via IoT Client <NUM> receiving published messages on Topic-abc.

<FIG> illustrates a method <NUM> for a broker policy manager (BPM), according to an example embodiment. As a convenience and not a limitation, method <NUM>, may be described with elements of <FIG>. For example, method <NUM> can be provided by system <NUM> or system <NUM> described below.

An Incident-based system (e.g., IWS, mobile IWS, IoT Client <NUM>) can specify a topic such as Topic-BPM.

At <NUM>, system <NUM> (e.g., BPM <NUM>, as an IoT client), can subscribe to Topic-BPM and receive published messages that include Topic-BPM and other information. For example, system <NUM> can subscribe to Topic-BPM established by the Incident-based system. Subsequently, the Incident-based system can publish to a certificate-based IoT Broker, information on the Topic-BPM, such as the incident name and IoT Client name (e.g., Topic-BPM/incident-abc/IoT Client <NUM>.

At <NUM>, system <NUM> can receive from the certificate-based IoT broker, a published message on the topic including the BPM. For example, BPM <NUM> can receive from Certificate-based IoT Broker <NUM>, a published message on Topic-BPM that includes IoT Client <NUM> joining or creating incident-abc (e.g., the published message including Topic-BPM/incident-abc/IoT Client <NUM>, Topic-BPM/incident-abc/IoT Client <NUM>/creator.

At <NUM>, system <NUM> can dynamically determine that a first IoT client is a participant of an incident communications network corresponding to an incident. For example, BPM <NUM> can make that determination from <NUM> above. In some embodiments, BPM <NUM> listens to a multicast channel to learn that IoT Client <NUM> has been invited to join incident-abc communications network or has created incident-abc communications network. In some embodiments, BPM <NUM> receives a signal from an Interoperability Workstation (IWS) that IoT Client <NUM> has been invited to join or has created incident-abc communications network. In some embodiments, system <NUM> creates Topic-abc or system <NUM> determines that Topic-abc has been created (e.g., by IoT Client <NUM>). System <NUM> also determines whether IoT Client <NUM> is permitted to publish-only, subscribe-only, or publish and subscribe to Topic-abc.

At <NUM>, system <NUM> can transmit first instructions to the certificate-based IoT broker to change a first IoT policy associated with a first certificate of the first IoT client, to enable the first IoT client to publish and/or subscribe to a topic that includes the incident. For example, BPM <NUM> can transmit a signal to Certificate-based IoT Broker <NUM> to change the policy of the certificate associated with IoT Client <NUM> to allow IoT Client <NUM> to now publish and subscribe to Topic-abc. Certificate-based IoT Broker <NUM> updates IoT Client <NUM>'s certificate policy accordingly.

At <NUM>, system <NUM> can receive an indication that a second IoT client accepts an invitation from the first IoT client to join the incident communications network. For example, BPM <NUM> can learn about IoT Client <NUM> joining incident-abc communications network via a signaling channel via IoT Client <NUM> and/or IoT Client <NUM>, or by listening to a multicast channel of the incident-abc communications network. BPM <NUM> dynamically determines whether to adjust the policies of the certificate corresponding to IoT Client <NUM> so that IoT Client <NUM> can publish and/or subscribe to IoT messages on Topic-abc. In this example, BPM <NUM> determines that IoT Client <NUM> can publish and subscribe to Topic-abc.

At <NUM>, system <NUM> can transmit second instructions to the certificate-based IoT broker to change a second IoT policy associated with a second certificate of the second IoT client that enables the second IoT client to publish and subscribe to the topic that includes the incident, where the first and second IoT clients can communicate via the incident communications network and/or via the certificate-based IoT broker. For example, BPM <NUM> can transmit a signal to Certificate-based IoT Broker <NUM> to change the policy of the certificate associated with IoT Client <NUM> to allow IoT Client <NUM> to now publish and subscribe to Topic-abc. Certificate-based IoT Broker <NUM> updates IoT Client <NUM>'s certificate policy accordingly. IoT Clients <NUM> and <NUM> can communicate via the incident-abc communications network and/or via the certificate-based IoT broker.

At <NUM>, system <NUM> can determine that a third IoT client shares the first certificate with the first IoT client, where the first certificate enables the third IoT client to publish and/or subscribe to the topic that comprises the incident (e.g., the first IoT client can be a GUI of an interoperability workstation (IWS) coupled to the incident-abc communications network, and the third IoT client can be an actuator or a sensor. ) For example, BPM <NUM> can determine that IoT Client <NUM> and IoT Client <NUM> have unique identities yet share the same certificate and/or policies. In some embodiments, BPM <NUM> can determine that IoT Client <NUM> and IoT Client <NUM> have unique identities, different certificate, but their certificates are associated. BPM <NUM> can dynamically determine whether IoT Client <NUM> can only-publish, only-subscribe, or publish and subscribe to Topic-abc corresponding to incident-abc, and inform Certificate-based IoT Broker <NUM> accordingly. In some embodiments the dynamic determination is based on instructions received from IoT Client <NUM> at <NUM> of <FIG>.

At <NUM>, system <NUM> can receive an indication that the second IoT client leaves the incident.

At <NUM>, system <NUM> can transmit to the certificate-based IoT broker, a request to remove the Topic-incident from the second IoT policy associated with the second certificate.

Various embodiments can be implemented, by software, firmware, hardware, or a combination thereof. <FIG> illustrates and example computer system <NUM> in which the systems and devices described within various embodiments can be implemented as computer-readable code and/or text-readable code. After reading this description, it will become apparent to a person skilled in the relevant art how to implement the embodiments using other systems and/or processing architectures. For example, an IoT client, Broker Policy Manager (BPM), and/or a Certificate-based IoT Broker may be implemented by computer system <NUM>.

Processor <NUM> is connected to a communication infrastructure <NUM> that can be a bus. One or more processors <NUM> may each be a graphics processing unit (GPU). In an embodiment, a GPU is a processor that is a specialized electronic circuit designed to process mathematically intensive applications. The GPU may have a parallel structure that is efficient for parallel processing of large blocks of data, such as mathematically intensive data common to computer graphics applications, images, videos, etc..

Computer system <NUM> also includes a main or primary memory <NUM>, such as random access memory (RAM). Main memory <NUM> may include one or more levels of cache. Main memory <NUM> has stored therein control logic (i.e., computer software) and/or data.

According to an exemplary embodiment, secondary memory <NUM> may include other means, instrumentalities or other approaches for allowing computer programs and/or other instructions and/or data to be accessed by computer system <NUM>. Such means, instrumentalities or other approaches may include, for example, a removable storage unit <NUM> and an interface <NUM>. Examples of the removable storage unit <NUM> and the interface <NUM> may include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an EPROM or PROM) and associated socket, a memory stick and USB port, a memory card and associated memory card slot, and/or any other removable storage unit and associated interface.

In an embodiment, a tangible, non-transitory apparatus or article of manufacture comprising a tangible, non-transitory computer useable or readable medium having control logic (software) stored thereon is also referred to herein as a computer program product or program storage device. This includes, but is not limited to, computer system <NUM>, main memory <NUM>, secondary memory <NUM>, and removable storage units <NUM> and <NUM>, as well as tangible articles of manufacture embodying any combination of the foregoing. Such control logic, when executed by one or more data processing devices (such as computer system <NUM>), causes such data processing devices to operate as described herein.

Based on the teachings contained in this disclosure, it will be apparent to persons skilled in the relevant art(s) how to make and use embodiments of the invention using data processing devices, computer systems and/or computer architectures. In particular, embodiments may operate with software, hardware, and/or operating system implementations other than those described herein.

It is to be appreciated that the Detailed Description section, and not the Summary and Abstract sections (if any), is intended to be used to interpret the claims. The Summary and Abstract sections (if any) may set forth one or more but not all exemplary embodiments of the invention as contemplated by the inventor(s), and thus, are not intended to limit the invention or the appended claims in any way.

While the invention has been described herein with reference to exemplary embodiments for exemplary fields and applications, it should be understood that the invention is not limited thereto. For example, and without limiting the generality of this paragraph, embodiments are not limited to the software, hardware, firmware, and/or entities illustrated in the figures and/or described herein. Further, embodiments (whether or not explicitly described herein) have significant utility to fields and applications beyond the examples described herein.

Also, alternative embodiments may perform functional blocks, steps, operations, methods, etc. using orderings different than those described herein.

Claim 1:
A system for a broker policy manager (<NUM>), BPM, comprising:
a transceiver; and
one or more processors coupled to the transceiver, configured to:
determine that a first Internet of Things, IoT, client (<NUM>) is a participant of an incident communications network corresponding to an incident;
transmit first instructions to a certificate-based IoT broker (<NUM>) to change a first IoT policy associated with a first certificate of the first IoT client, to enable the first IoT client (<NUM>) to publish or subscribe to a first topic corresponding to the incident:
receive a indication that a second IoT client accepts an invitation from the first IoT client to join the incident communications network;
transmit second instructions to the certificate-based IoT broker (<NUM>) to change a second IoT policy associated with a second certificate of the second IoT client that enables the second IoT client to publish or subscribe to the first topic corresponding to the incident; and
determine that a third IoT client has a third certificate associated with the first certificate of the first IoT client (<NUM>) based on a third indication received from the first IoT client (<NUM>), wherein the first instructions transmitted to the certificate-based IoT broker (<NUM>) change a third IoT policy associated with the third certificate of the third IoT client to enable the third IoT client to publish or subscribe to the first topic.