Patent Description:
Machine learning is a method of data analysis that automates the creation of a model (e.g., function), which can be represented in the form of a computational graph. Machine learning is a branch of artificial intelligence that is based on the idea that systems can learn from data, identify patterns, and make decisions with reduced human intervention.

Through machine learning, a computational graph designed to perform particular task(s) (e.g., image recognition) may be obtained. The computational graph defines a set of one or more operations (a. , "compute functions") and, for each operation, a set of one or more inputs to the operation. Accordingly, a computational graph can be represented by a directed graph comprising a set of nodes, where each node corresponds to either an operation or an input to an operation. <FIG> illustrates an exemplary computational graph <NUM>, which represents the function: y= S(B), where B = mx + b and S() is a sigmoid function. As shown in <FIG>, computational graph <NUM> comprises a set of nodes, where each rectangular node (e.g., <NUM>, <NUM>, and/or <NUM>) represents an operation (e.g., multiplication, addition, sigmoid, etc.) and each circular node (e.g., <NUM>, <NUM>, and/or <NUM>) represents an input to an operation. As also shown in <FIG>, the output of an operation can be an input to another operation. One of popular computational graph formats is the Open Neural Network Exchange (ONNX). ONNX provides the advantage of allowing computational graphs to be shared among different frameworks and platforms for interoperability.

<CIT> discloses a method, system, and apparatus for receiving a request to process a computational graph. Processing comprises obtaining data representing the computational graph, wherein each node represents a respective operation and wherein each directed edge connects a respective first node to a respective second node that receives, as input, an output of an operation represented by the respective first node. Further, the method comprises identifying a plurality of available devices for performing the requested operation, partitioning the computational graph into a plurality of subgraphs where each subgraph comprises one or more nodes in the computational graph, and assigning, for each subgraph, the operations represented by the one or more nodes in the subgraph to a respective available device in the plurality of available devices.

<CIT> discloses a CoAP communication method and a system for performing the method, wherein the method includes receiving a POST message for a registration request, verifying whether the registration request is valid in response to the POST message, extracting a unit identifier of at least one resource associated with a node for a message payload of the POST message, and returning a response message.

Certain challenges presently exist. For example, in some use cases, a computational graph can be too resource consuming for a single device (e.g., an Internet-of-Things (IoT) device) to execute (i.e., perform all of the operations defined by the computational graph). To solve this problem, according to some embodiments, the set of operations defined by the computational graph are processed in a distributed manner (especially in a constrained environment) such that a group of devices (e.g., resource constrained devices) cooperate to perform the set of operations.

Accordingly, in one aspect a method for generating output data based on a computational graph (i.e., a method for executing the computational graph) is provided, where the computational graph defines a set of operations, wherein the set of operations includes a first subset of one or more operations and a second subset of one or more operations. The method includes a representational state transfer (REST) server storing information related to the computational graph. The information related to the computational graph may include information representing the first subset of operations. The method may further include the REST server receiving input data and the REST server performing the first subset of operations using the received input data, thereby producing first output data corresponding to the first subset of operations. The method further includes the REST server exposing the first output data as a discoverable resource by generating a link and storing the link in a resource directory, so that the first output data is discoverable using RESTful operations by other devices.

In another aspect, a method is provided that includes obtaining a representation of a computational graph that defines a set of two or more operations. The method may include selecting a first subset of one or more operations from the set of two or more operations and selecting a second subset of one or more operations from the set of two or more operations. The method may further include assigning the first subset of operations to at least a first device of the REST based distributed IoT network, assigning the second subset of operations to at least a second device of the REST based distributed IoT network, and configuring the first device to expose as a first discoverable resource first output data generated by the first device as a result of the first device performing the first subset of operations. The method may further include configuring the second device to expose as a second discoverable resource second output data generated by the second device as a result of the second device performing the second subset of operations.

In another aspect, a computer program is provided. The computer program includes instructions which when executed by processing circuitry cause the processing to perform a method for generating output data based on a computational graph (i.e., a method for executing the computational graph). The computational graph defines a set of operations, wherein the set of operations includes a first subset of one or more operations and a second subset of one or more operations. The method includes a REST server storing information related to the computational graph. The information related to the computational graph may include information representing the first subset of operations. The method may further include the first device receiving input data and the first device performing the first subset of operations using the received input data, thereby producing first output data corresponding to the first subset of operations. The method further includes the REST server exposing the first output data as a discoverable resource by generating a link and storing the link in a resource directory, so that the first output data is discoverable using RESTful operations by other devices.

In another aspect, a computer program is provided. The computer program includes instructions which when executed by processing circuitry cause the processing to perform a method including obtaining a representation of a computational graph. The computational graph may define a set of two or more operations. The method may further include selecting a first subset of one or more operations from the set of two or more operations and selecting a second subset of one or more operations from the set of two or more operations. The method may further include assigning the first subset of operations to at least a first device of the REST based distributed IoT network, assigning the second subset of operations to at least a second device of the REST based distributed IoT network, and configuring the first device to expose as a first discoverable resource first output data generated by the first device as a result of the first device performing the first subset of operations. The method may further include configuring the second device to expose as a second discoverable resource second output data generated by the second device as a result of the second device performing the second subset of operations.

In another aspect, a REST server for generating output data based on a computational graph is provided. The REST server is adapted to store information related to the computational graph, the computational graph defining a set of operations. The set of operations includes a first subset of one or more operations and a second subset of one or more operations, and further the information related to the computational graph includes information representing the first subset of operations. The REST server is further adopted to receive input data, perform the first subset of operations using the received input data, thereby producing first output data corresponding to the first subset of operations, and expose the first output data as a discoverable resource by generating a link and storing the link in a resource directory, so that the first output data is discoverable using RESTful operations by other devices.

In another aspect, a REST server of a REST based distributed IoT network is provided. The REST server is adapted to obtain a representation of a computational graph, the computational graph defining a set of two or more operations. The REST server is further adapted to select a first subset of one or more operations from the set of two or more operations, select a second subset of one or more operations from the set of two or more operations, assign the first subset of operations to at least a first device of the REST based distributed IoT network, and the second subset of operations to at least a second device of the REST based distributed IoT network. The REST server is further adapted to configure the first device to expose as a first discoverable resource first output data generated by the first device as a result of the first device performing the first subset of operations and configure the second device to expose as a second discoverable resource second output data generated by the second device as a result of the second device performing the second subset of operations.

<FIG> illustrates a system <NUM> for executing a computational graph (i.e., performing the operations defined by the computational graph) that defines a set of operations and the inputs for each defined operation. The system <NUM> may be a representational state transfer (REST) based distributed IoT network. As shown in <FIG>, the system <NUM> may comprise a client <NUM>, a first device <NUM> that stores first information identifying a first subset of the operations and the inputs for these operations (denoted in <FIG> as Layer <NUM> and Layer <NUM>), a second device <NUM> that stores second information identifying a second subset of the operations and the inputs for these operations (denoted in <FIG> as Layer <NUM> and Layer <NUM>), and a third device <NUM> that stores third information identifying a third subset of the operations and the inputs for these operations (denoted in <FIG> as Layer <NUM>). In the system <NUM>, upon first device <NUM> receiving a request from the client <NUM>, first device <NUM> begins to execute the computational graph (i.e., performs the Layer <NUM> and Layer <NUM> operations).

<FIG> illustrates a process <NUM> for executing a computational graph. The process <NUM> may begin with step s802.

Step s802 comprises splitting a computational graph (e.g., ONNX graph) into multiple operations (e.g., batch normalization or linear classifier) that can be deployed on devices to perform inference and/or learning. Each device that is a part of a distributed system may execute one or more of the operations. For example, in the system <NUM>, the first device <NUM> may be configured to perform layer <NUM> and <NUM> calculations of the computational graph (e.g., ONNX graph), the second device <NUM> may be configured to perform layer <NUM> and <NUM> calculations of the computational graph, and the third device <NUM> may be configured to perform layer <NUM> calculation of the computational graph.

From (e.g., ONNX) operator description, each device may know what type of input data each device should consume and what type of output data each device should generate.

Input interface of each device may be described using a resource identifier (e.g., a Uniform Resource Locator (URL)) (a. , "link") format (e.g., CoRE link format or Constrained Resource Identifier) to enable dynamic discovery of the input interface. The link corresponding to an input interface of each device may be discovered from a host or may be stored in a CoRE Resource Directory (RD) for robust discovery (especially when nodes are not always available or are not easily discoverable). The link may be annotated based on how much or how frequently data needs to be exchanged to run a distributed algorithm. This information may be used in later steps of the process <NUM> to choose which node and which communication link should be used for a particular part of the computational graph.

Step s804 comprises performing computations. More specifically, when input data is available to a device, the device computes a subset of the graph (i.e., performs at least one operation defined by the graph, thereby producing output data). After the device finishes a computation corresponding to the subset of operation(s), the device may store the generated output data in the device. The generated output data may be treated as a RESTful resource.

Step s806 comprises exposing the output data as a resource. The device is a REST server (e.g. CoAP server or HTTP server) and it exposes the output data as a resource and generates a link for that purpose (e.g., <coap://device1/nn>;rt="data" where "nn" identifies the output data on device <NUM>). Once the resource is exposed it can be discovered, it can be observed, it can be followed, it can be traced, using standard RESTful operations. To enable discovery, the links are stored in a directory service, such as a Resource Directory (RD). As illustrated above, the device may expose the output data using the standard "rt" ("resource type") description, or it may use a new attribute defined for this purpose (e.g., "onnxid"). The device may also assign a specific link target attribute that characterizes the result of a computation (e.g., 'voice data' or 'graph-<NUM>-node-<NUM>').

Example of a link using ONNX endpoint (layer) IDs:
<coap://device1/nn/>;onnxid=layer3.

Example of a link using CoAP resource type (rt): <coap://device1/nn>;rt="voice data" or <coap://device1/nn>;rt="graph-<NUM>-node-<NUM>".

Both types of link enable a client to query for resources from servers that match the "resource type" or "ONNX ID. " An example of the query message is: GET /. well-known/core?onnxid=layer3.

Step s808 comprises discovering a resource. For example, the device may occasionally -- e.g., periodically (e.g., ever few minutes/hours/etc.) or based on a trigger or external interruption -- perform discovery of resource(s) of the right resource type 'rt' (or any similar attribute). For instance, when each device awakes, the device may perform discovery of resource(s) of the right resource type 'rt' (or any similar attribute). This way, each device can dynamically discover computational graph neighbors every time it wakes up or periodically or in response to a trigger. This discovery process is especially useful for battery-based sleepy devices. The discovery may be used to find intermediate states in the computation that the device could task itself to do. There are two types of discoveries: (<NUM>) discovering from where data should be retrieved ("pull mode") and (<NUM>) discovering to where data should be sent next ("push mode").

In the discovery step, the devices that are aware of network capabilities (e.g., bandwidth, cost, latency) may take into account data size/frequency annotations from the step s802 to optimize which devices and links should be used based on discovery.

Instead of performing discovery every time a device wakes up, the discovery may be performed only at the beginning (e.g., after multiple operations of a computational graph are divided among nodes - i.e., after performing the step s802) if the arrangement of computational devices and flow of data is static.

An example of link that contains metadata about network capabilities:
<coap://device1/nn/>;onnxid=layer3;bwlimit=100bps.

Step s810 comprises performing further computations. For example, once a resource is found and fetched, the computation step in the step s804 and the exposing step in the step s806 may be repeatedly performed.

Step s812 (which may be optional) comprises sending a message to mark a resource as processed. More specifically, for example, once the computation of an operation ends, a message may be sent to mark the resource as processed. Depending on the configuration of the system <NUM>, the consumed intermediate results may be removed or stored for later inspection (e.g., tracing using the links). In other embodiments, instead of sending the message to mark the resource as processed, the resource may be given a lifetime after which the resource is automatically removed or stored.

The data exchanged among the devices <NUM>, <NUM>, and/or <NUM> may have a format defined by a new media type (e.g., 'application/ml-data+json' or 'application/ml-data+cbor'). The new media type may have the following structure:.

By using a basic format common for existing REST based IoT systems for the input and output data, the overhead for constrained devices may be reduced and existing tools and code may be used more efficiently. The provenance mechanism may enable securing a distributed computing in a way that is not currently possible with conventional systems.

<FIG> illustrates a message flow <NUM> according to an embodiment. The message flow <NUM> involves devices <NUM>, <NUM>, and <NUM>.

The devices <NUM>, <NUM>, and/or <NUM> may store information related to a computational graph. In some embodiments, the computational graph defines a set of operations including a first subset of one or more operations, a second subset of one or more operations, and a third subset of one or more operations. The information related to the computational graph stored in first device <NUM> may correspond to the first subset of operations. Similarly, the information related to the computational graph stored in the devices <NUM> and <NUM> may correspond to the second subset of operations and the third subset of operations, respectively.

In the message flow <NUM>, first device <NUM> may receive input data <NUM>. The input data <NUM> may originate form client <NUM>. After receiving the input data <NUM>, first device <NUM> may perform a computing operation <NUM> to compute first output data <NUM>. In some embodiments, computing the first output data <NUM> comprises performing the first subset of operations using the received input data <NUM>, thereby producing the first output data <NUM>. For example, the first output data <NUM> may be equal to a function of the input data <NUM> (i.e., y = f(x) where y corresponds to the first output data <NUM>, x corresponds to the input data <NUM>, and f corresponds to the first subset of operations). The computed first output data <NUM> may be stored in first device <NUM>.

After or before first device <NUM> computes the first output data <NUM>, second device <NUM> may transmit a resource discovery message (RDM) <NUM> (e.g., GET /. well-known/core?rt=output_data1) toward a plurality of devices (e.g., the devices <NUM> and <NUM>) included in the network. For example, second device <NUM> multicasts or broadcasts the RDM <NUM>. The RDM <NUM> corresponds to a query message asking other devices (e.g., the devices <NUM> and <NUM>) in the same network as second device <NUM> if any of them has the output data that second device <NUM> needs for its computation (e.g., the first output data <NUM>). The RDM <NUM> may comprise a resource type value associated with the first output data <NUM> (e.g., "rt=output_data1" or "onnxid=layer1"). In some embodiments, the RDM <NUM> may be received at first device <NUM> by receiving an Internet Protocol (IP) packet comprising (i) a header comprising an IP destination address and (ii) a payload comprising the RDM <NUM>. The IP destination address may be an IP multicast group address.

If the first output data <NUM> is stored in first device <NUM> at the time first device <NUM> receives the RDM <NUM>, then first device <NUM> may transmit toward second device <NUM> a resource discovery response message (RDRM) <NUM> indicating that first device <NUM> has the first output data <NUM>. The RDRM <NUM> may include a resource identifier (e.g., "coap://device1. com/output_data1") for retrieving the first output data <NUM>.

In case the first output data <NUM> is not stored in first device <NUM> at the time first device <NUM> receives the RDM <NUM>, first device <NUM> may not transmit any message or alternatively may transmit toward second device <NUM> a message indicating that first device <NUM> does not have the first output data.

After second device <NUM> receives the RDRM <NUM>, second device <NUM> may transmit to first device <NUM> a request message <NUM> (e.g., GET /output_data1) requesting the first output data <NUM>. The request message <NUM> may include the resource identifier included in the RDRM <NUM>. In response to receiving the request message <NUM>, first device <NUM> may transmit the first output data <NUM> toward second device <NUM>. After receiving the first output data <NUM>, second device <NUM> may optionally transmit toward first device <NUM> an acknowledgement message <NUM> acknowledging the receipt of the first output data <NUM>.

<FIG> illustrates a message flow <NUM> according to an embodiment. Message flow <NUM> involves devices <NUM>, <NUM>, and <NUM>.

Like the message flow <NUM> shown in <FIG>, in the message flow <NUM>, first device <NUM> may receive the input data <NUM> and compute the first output data <NUM> using the received input data <NUM>.

After computing the first output data <NUM>, first device <NUM> may transmit toward a resource directory (RD) <NUM> a resource registration message (RRM) <NUM>. The resource registration message <NUM> may comprise a resource type value (e.g., "rt=output_data1" or "onnxid=layer1") of the first output data <NUM> and a resource identifier (e.g., coap://device1. com/output_data1) for identifying the first output data <NUM>. In this way, the RD can associate the resource identifier with the resource type and return the resource identifier to any device that queries the RD using the resource type value.

RD <NUM> may receive a resource discovery message (RDM) <NUM> transmitted by second device <NUM>. The RDM <NUM> corresponds to a query message asking RD <NUM> if it has information about the output data that second device <NUM> needs for its computation (e.g., the first output data <NUM>). That is, the RDM <NUM> may comprise a resource type value associated with the first output data <NUM> (e.g., output_data1). The RDM <NUM> may further comprise a request to "observe" the resource identified by the resource type value (e.g., the RDM <NUM> includes an "Observe Option" value that requests RD <NUM> to add second device <NUM> to a list of observers of the resource).

If RD <NUM> receives the RDM <NUM> before it receives the RRM <NUM> and RDM <NUM> does not include the request to observe the resource, then RD <NUM> may reply with "resource not found" message which may then cause second device to retransmit RDM <NUM> at some later time (this is a polling option). If RD <NUM> receives RDM <NUM> before it receives RRM <NUM> and RDM <NUM> comprises a request to observe the resource, then RD <NUM> may not transmit any response to RDM <NUM> (or may simply transmit some type of acknowledgement or other message)toward second device <NUM> and then after RD <NUM> receives the RRM <NUM> RD <NUM> transmits a notification message <NUM> toward second device <NUM> (this is a subscription option). In the event that RD <NUM> receives the RDM <NUM> after it receives the RRM <NUM> (i.e., once the information regarding the first output data <NUM> becomes available to RD <NUM>), RD <NUM> may immediately transmit toward second device <NUM> the notification message <NUM>. The notification message <NUM> may comprise the resource identifier (e.g., coap://device1. com/output_data1) identifying the first output data <NUM> and a device identifier allocated to the first device <NUM> (e.g., the first device <NUM>'s IP address or hostname).

After second device <NUM> receives the notification message <NUM>, second device <NUM> may transmit to first device <NUM> a request message <NUM> (e.g., GET /output_data1) requesting the first output data <NUM>. In response to receiving the request message <NUM>, first device <NUM> may transmit the first output data <NUM> toward second device <NUM>. After receiving the first output data <NUM>, second device <NUM> may optionally transmit toward first device <NUM> an acknowledgement message <NUM> acknowledging the receipt of the first output data <NUM>.

Like the message flow <NUM>, in the message flow <NUM>, first device <NUM> may receive the input data <NUM> and compute the first output data <NUM> using the received input data <NUM>.

After computing the first output data <NUM>, first device <NUM> may transmit toward the devices in the same network as first device <NUM> (e.g., the devices <NUM> and <NUM>) a resource discovery message (RDM) <NUM> asking the devices in the same network if any of them needs the first output data <NUM>. Transmitting the RDM <NUM> may comprise multicasting the RDM <NUM>. The RDM <NUM> may comprise a resource type value (e.g., rt=consumer_output_data1) associated with the first output data <NUM>.

In the message flow <NUM>, because second device <NUM> needs the first output data <NUM> for its computation, second device <NUM> may transmit toward first device <NUM> a resource discovery response message (RDRM) <NUM> indicating that first device <NUM> should transmit the first output data <NUM> toward second device <NUM>.

In response to receiving the RDRM <NUM>, first device <NUM> may transmit toward second device <NUM> the first output data <NUM> or a link to the first output data (e.g., a Uniform Resource Locator (URL) that points to the first output data). If first device <NUM> transmits to second device <NUM> a link to the output data rather than the first output data itself, then second device <NUM> uses the link to retrieve the output data (step <NUM>). For example, if the link is in the form of an HTTP URL, then second device <NUM> retrieves the first data <NUM> by transmitting to the host identified in the URL an HTTP GET message that includes the path portion and query string, if any, of the URL.

After second device <NUM> receives the first output data <NUM>, second device <NUM> may perform a computing operation <NUM> to compute second output data <NUM>.

In some embodiments, computing the second output data <NUM> (i.e., performing step <NUM>) comprises performing the second subset of operations using the received first output data <NUM>, thereby producing the second output data <NUM>. For example, the second output data <NUM> may be equal to a function of the first output data <NUM> (i.e., y = f(x) where y corresponds to the second output data <NUM>, x corresponds to the first output data <NUM>, and f corresponds to the second subset of operations). The computed second output data <NUM> may be stored in second device <NUM>.

After computing the second output data <NUM>, second device <NUM> may transmit a resource discovery message (RDM) <NUM> asking the devices in the same network (e.g., the devices <NUM> and <NUM>) if any of them needs the second output data <NUM>. The RDM <NUM> may comprise a resource type value (e.g., rt=consumer_output_data2) associated with the second output data <NUM>.

After receiving the RDM <NUM>, third device <NUM> may transmit toward second device <NUM> a resource discovery response message (RDRM) <NUM> indicating that second device <NUM> should transmit the second output data <NUM> toward third device <NUM>.

In response to receiving the RDRM <NUM>, second device <NUM> may transmit toward third device <NUM> the second output data <NUM> (or a link to the second output data). After third device <NUM> receives the second output data <NUM> (or a link to the second output data), third device <NUM> may optionally transmit toward second device <NUM> an acknowledgement message <NUM> acknowledging the receipt of the second output data <NUM> (or a link to the second output data).

In the message flow <NUM>, second device <NUM> may transmit toward the plurality of devices in the same network as second device <NUM> (e.g., the devices <NUM> and <NUM>) a resource notification message (RNM) <NUM> indicating that a device that has the first output data <NUM> should transmit the first output data <NUM> (or a resource identifier for the first output data) toward second device <NUM>. The devices <NUM> and <NUM> may receive the RNM <NUM> by receiving an IP packet. The IP packet may include (i) a header comprising an IP destination address and (ii) a payload comprising the RNM <NUM>. The IP destination address may be an IP multicast group address.

Because first device <NUM> is configured to compute the first output data <NUM>, after receiving the RNM <NUM>, first device <NUM> may optionally transmit toward second device <NUM> an acknowledgement message <NUM> acknowledging the receipt of the RNM <NUM>.

In the message flow <NUM>, third device <NUM> may also transmit toward the plurality of devices in the same network as third device <NUM> (e.g., the devices <NUM> and <NUM>) an RNM <NUM> indicating that a device that has the second output data <NUM> should transmit the second output data <NUM> (or a link to the second output data) toward third device <NUM>. The devices <NUM> and <NUM> may receive the RNM <NUM> by receiving an IP packet. The IP packet may include (i) a header comprising an IP destination address and (ii) a payload comprising the RNM <NUM>. The IP destination address may be an IP multicast group address.

Because second device <NUM> is configured to compute the second output data <NUM>, after receiving the RNM <NUM>, second device <NUM> may optionally transmit toward third device <NUM> an acknowledgement message <NUM> acknowledging the receipt of the RNM <NUM>.

In the message flow <NUM>, first device <NUM> may receive the input data <NUM>. Upon receiving the input data <NUM>, first device <NUM> may compute the first output data <NUM> using the input data <NUM>, as discussed with respect to the message flow <NUM> shown in <FIG>. Even though <FIG> shows that the receipt of the input data <NUM> and the computation of the first output data <NUM> occur after first device <NUM> receives the RNM <NUM>, any of receiving the input data <NUM> and computing the first output data <NUM> may occur at any time. For example, first device <NUM> may receive the input data <NUM> and compute the first output data <NUM> before it receives the RNM <NUM>.

After first device <NUM> computes the first output data <NUM> and receives the RNM <NUM> indicating that the first output data <NUM> (or a link to the first output data) should be sent to second device <NUM>, first device <NUM> may transmit toward second device <NUM> the first output data <NUM> (or a link to the first output data).

If first device <NUM> transmits to second device <NUM> a link to the output data rather than the first output data itself, then second device <NUM> uses the link to retrieve the output data (step <NUM>).

As shown in <FIG>, after second device <NUM> receives the first output data <NUM>, second device <NUM> may perform step <NUM> as described above (i.e., compute the second output data <NUM> using the received first output data <NUM>).

After computing the second output data <NUM>, second device <NUM> may transmit toward third device <NUM> the second output data <NUM> (or a link to the second output data).

After receiving the second output data <NUM> (or a link to the second output data), third device <NUM> may optionally transmit toward second device <NUM> an acknowledgement message <NUM> indicating the receipt of the second output data (or a link to the second output data).

<FIG> illustrates a message flow <NUM> according to an embodiment. The message flow <NUM> involves devices <NUM>, <NUM>, and RD <NUM>.

As shown in <FIG>, second device <NUM> may transmit toward RD <NUM> a resource registration message (RRM) <NUM> indicating that second device <NUM> is the entity that should receive the first output data <NUM>. The RRM <NUM> may include a resource identifier that identifies the first output data <NUM> and that identifies second device <NUM> as a consumer of the data (e.g., consumer_output_data1) and a device identifier identifying second device <NUM> (e.g., second device <NUM>'s IP address or hostname).

After RD <NUM> receives the RRM <NUM>, RD <NUM> may also receive a resource discovery message (RDM) <NUM> transmitted by first device <NUM>. The RDM <NUM> may correspond to a query message asking RD <NUM> the identity of a device to which first device <NUM> should transmit the first output data <NUM> (or a link to the first output data). In other words, the query asks RD <NUM> to return a query result that identifies a consumer of the first output data. In some embodiments, the RDM <NUM> may include a particular resource type value (e.g., rt=consumer_output_data1) associated with the first output data <NUM>.

As a result of receiving the RRM <NUM> and the RDM <NUM>, RD <NUM> may transmit toward first device <NUM> a resource discovery response message (RDRM) <NUM> indicating that the first output data <NUM> should be sent to second device <NUM>. The RDRM <NUM> may include the device identifier identifying second device <NUM>. In some cases, RD <NUM> may receive the RDM <NUM> before it receives the RRM <NUM> but the RDM <NUM> includes a request to observe the resource identified by the resource type value. In such cases, RD <NUM> transmits the RDRM <NUM> in response to RD <NUM> receiving the RRM <NUM> and RD <NUM> determining that device <NUM> is included in the list of observers for this resource. In some cases, RD <NUM> may receive the RDM <NUM> before it receives the RRM <NUM> and the RDM <NUM> does not include the request to observe the resource. In this case, first device <NUM> may periodically retransmit the RDM <NUM> until it obtains the requested resource (i.e., this is the polling option).

In the message flow <NUM>, first device <NUM> may receive the input data <NUM>. Upon receiving the input data <NUM>, first device <NUM> may compute the first output data <NUM> using the input data <NUM>, as discussed with respect to the message flow <NUM> shown in <FIG>. Even though <FIG> shows that the receipt of the input data <NUM> and the computation of the first output data <NUM> occur after first device <NUM> receives the RDRM <NUM>, any of receiving the input data <NUM> and computing the first output data <NUM> may occur at any time. For example, first device <NUM> may receive the input data <NUM> and compute the first output data <NUM> before it receives the RDRM <NUM>.

After first device <NUM> computes the first output data <NUM> and receives the RDRM <NUM> indicating that the first output data <NUM> (or a link to the first output data) should be sent to second device <NUM>, first device <NUM> may transmit toward second device <NUM> the first output data <NUM> (or a link to the first output data).

If first device <NUM> transmits to second device <NUM> a link to the output data rather than the first output data itself, then second device <NUM> uses the link to retrieve the output data (step <NUM>). After second device <NUM> receives the first output data <NUM>, second device <NUM> may perform step <NUM> as described above.

<FIG> is a flow chart illustrating a process <NUM> for generating output data in accordance with a computational graph. Process <NUM> may begin in step s902.

Step s902 comprises a first device storing information related to the computational graph. The computational graph may define a set of operations including a first subset of one or more operations and a second subset of one or more operations. The information related to the computational graph may comprise information representing the first subset of operations.

Step s904 comprises the first device receiving input data.

Step s906 comprises the first device performing the first subset of operations using the received input data, thereby producing first output data corresponding to the first subset of operations.

Step s908 comprises the first device exposing the first output data as a discoverable resource so that the first output data is discoverable by other devices.

In some embodiments, the process <NUM> comprises the first device receiving a request message (e.g., a message comprising the request "GET /output_data1") transmitted by a second device, wherein the request message requests the first output data. The process <NUM> may further comprise the first device transmitting the first output data toward the second device in response to receiving the request message.

In some embodiments, the process <NUM> comprises receiving a resource discovery message (e.g., GET /. well-known/core?rt=output_data1) transmitted by a second device. Exposing the first output data as a discoverable resource may comprise, in response to receiving the resource discovery message, transmitting toward the second device a resource discovery response message comprising a resource identifier (e.g., "coap://device1. com/output_data1" or "/output_data1") for retrieving the first output data. The process <NUM> may further comprise after transmitting the resource discovery response message, the first device receiving a request message (e.g., GET /output_data1) transmitted by the second device, wherein the request message comprises the resource identifier. The process <NUM> may further comprise the first device transmitting the first output data toward the second device in response to receiving the request message comprising the resource identifier.

In some embodiments, exposing the first output data as a discoverable resource comprises associating the first output data with a first resource type value identifying a first resource type (e.g., "rt= output_data1" or "onnxid=layer3"). The resource discovery message may comprise the first resource type value.

In some embodiments, receiving the resource discovery message comprises receiving an Internet Protocol, IP, packet comprising: i) a header comprising an IP destination address and ii) a payload comprising the resource discovery message, wherein the IP destination address is an IP multicast group address.

In some embodiments, exposing the first output data as a discoverable resource comprises associating the first output data with a first resource type value (e.g., "rt= output_data1"). The process <NUM> may further comprise the first device transmitting toward a resource directory a resource registration message comprising: i) the first resource type value (e.g., "rt=output_data1") and ii) a resource identifier (e.g., /output_data1) for identifying the first output data. The process <NUM> may further comprise the first device receiving a request message (<NUM>) (e.g., GET /output_data1) transmitted by a second device, wherein the request message requests the first output data; and the first device transmitting the first output data toward the second device in response to receiving the request message.

In some embodiments, the process <NUM> further comprises the second device transmitting a resource discovery message towards the resource directory, the resource discovery message comprising the first resource type value (e.g., output_data1). The process <NUM> may further comprise the second device receiving a notification message transmitted by the resource directory, the notification message comprising the resource identifier (e.g., /output_data1) and a device identifier allocated to the first device (e.g., the first device's IP address or hostname). The second device may transmit the request message after receiving the notification message.

In some embodiments, the process <NUM> further comprises the first device receiving a resource message that indicates that the first device should transmit the first output data to a second device and after receiving the resource message, the first device transmitting the first output data toward the second device.

In some embodiments, the process <NUM> further comprises prior to receiving the resource message, the first device transmitting a resource discovery message comprising a particular resource type value (e.g., rt=consumer_output_data1).

In some embodiments, transmitting the resource discovery message comprises multicasting the resource discovery message (i.e., transmitting an IP packet comprising the resource discovery message wherein the IP packet is addressed to a multicast group). The resource message may be transmitted by the second device in response to the resource discovery message.

In some embodiments, transmitting the resource discovery message comprises transmitting the resource discovery message after producing the first output data corresponding to the first subset of operations.

In some embodiments, receiving the resource message comprises receiving an IP packet transmitted by the second device. The IP packet may comprise: i) a header comprising an IP destination address and ii) a payload comprising the resource message. The IP destination address may be an IP multicast group address.

In some embodiments, transmitting the resource discovery message comprises transmitting the resource discovery message toward a resource directory. The resource message originated from the resource directory.

In some embodiments, the first device generates the first output data after receiving the resource message. The first device may transmit the first output data toward the second device immediately after the first device generates the first output data.

<FIG> is a flow chart illustrating a process <NUM>. Process <NUM> may begin in step s1002.

Step s1002 comprises obtaining a representation of a computational graph. The computational graph defines a set of two or more operations.

Step s1004 comprises selecting a first subset of one or more operations from the set of two or more operations.

Step s1006 comprises selecting a second subset of one or more operations from the set of two or more operations.

Step s1008 comprises assigning the first subset of operations to at least a first device.

Step s1010 comprises assigning the second subset of operations to at least a second device.

Step s1012 comprises configuring the first device to expose as a first discoverable resource first output data generated by the first device as a result of the first device performing the first subset of operations.

Step s1014 comprises configuring the second device to expose as a second discoverable resource second output data generated by the second device as a result of the second device performing the second subset of operations.

<FIG> is a block diagram of an apparatus <NUM>, according to some embodiments, for implementing any of the devices <NUM>, <NUM>, and <NUM>. As shown in <FIG>, apparatus <NUM> may comprise: processing circuitry (PC) <NUM>, which may include one or more processors (P) <NUM> (e.g., a general purpose microprocessor and/or one or more other processors, such as an application specific integrated circuit (ASIC), field-programmable gate arrays (FPGAs), and the like), which processors may be co-located in a single housing or in a single data center or may be geographically distributed (i.e., apparatus <NUM> may be a distributed computing apparatus); one or more network interfaces <NUM> (which may be co-located or geographically distributed) where each network interface includes a transmitter (Tx) <NUM> and a receiver (Rx) <NUM> for enabling apparatus <NUM> to transmit data to and receive data from other nodes connected to network <NUM> (e.g., an Internet Protocol (IP) network) to which network interface <NUM> is connected; and one or more storage units (a. , "data storage systems") <NUM> which may be co-located or geographically distributed and which may include one or more nonvolatile storage devices and/or one or more volatile storage devices. In embodiments where PC <NUM> includes a programmable processor, a computer program product (CPP) <NUM> may be provided. CPP <NUM> includes a computer readable medium (CRM) <NUM> storing a computer program (CP) <NUM> comprising computer readable instructions (CRI) <NUM>. CRM <NUM> may be a non-transitory computer readable medium, such as, magnetic media (e.g., a hard disk), optical media, memory devices (e.g., random access memory, flash memory), and the like. In some embodiments, the CRI <NUM> of computer program <NUM> is configured such that when executed by PC <NUM>, the CRI causes apparatus <NUM> to perform steps described herein (e.g., steps described herein with reference to the flow charts). In other embodiments, apparatus <NUM> may be configured to perform steps described herein without the need for code. That is, for example, PC <NUM> may consist merely of one or more ASICs. Hence, the features of the embodiments described herein may be implemented in hardware and/or software.

While various embodiments are described herein, it should be understood that they have been presented by way of example only, and not limitation.

Claim 1:
A method (<NUM>) for generating output data based on a computational graph, the method performed by a representational state transfer, REST, server of a REST based distributed IoT network, the method comprising:
the REST server storing (s902) information related to the computational graph, the computational graph defining a set of operations, wherein the set of operations comprises a first subset of one or more operations and a second subset of one or more operations, and further wherein the information related to the computational graph comprises information representing the first subset of operations;
the REST server receiving (s904) input data (<NUM>);
the REST server performing (s906) the first subset of operations using the received input data, thereby producing first output data (<NUM>) corresponding to the first subset of operations; and
the REST server exposing (s908) the first output data (<NUM>) as a discoverable resource by generating a link and storing the link in a resource directory, so that the first output data is discoverable using RESTful operations by other devices.