Its content is organized following a loosely structured scheme, its size small enough for swift transport and synchronization. Yet its content may also contain pointers to bulky media content for close inspection when needed. Its creation is done through analyses of data stream that originate from one or multiple Example devices; The process is mainly guided by the service context as defined by the chosen DeviceMode, but other types of DeviceMarks may also be created by entities acting independent of any specific service.

Computationally, a DeviceMark refers to a persistent object instantiated from the DeviceMark and its derived classes; the class specification would define basic methods for management of the DeviceMark objects. The DeviceMark spec also defines the DeviceMark protocol that may be adopted by computational entities to generate, use and manage their archival and transport.

The spec also defines its portable data representation so that computational entities on disparate platforms may exchange them through related API calls, based on the REST/JSON style for example. This abstraction separates the function of the DeviceMark from its form, keeping the mechanics of their use immune from the prevailing transport data format (JSON vs XML) and API styles (SOAP vs REST, for example).

The primary functionality of a DeviceMark is as the container of high-value, interpretative information about the chunk of data streamed from the Example device(s) in the set context; It facilitates the standardized mechanism to pass data among disparate computing nodes. The DeviceMarks are to be created by several agents (i.e., Example device itself, a NSS module or even an end-user App may act as a creator agent) and updated asynchronously by agents other than the respective creator.

It also contains in its data structure a flag that designates its persistency characteristics depending on whether its content is ephemeral (for temporary use) or to remain as persistent record in the account. In the latter case, it may be directed to a monitored cloud database so that its entry may automatically trigger action(s) or notifications to subscribing entities further down the service network.

In the spirit of the modular approach, DeviceMark provides the standardized way to pass data of various nature, thereby opening the expansive service network to a vibrant app ecosystem that operates not only at the end-user level but also in the Service and Example Device layers. This is possible because the DeviceMark acts as an efficient data courier object within the stack and just as easily cross the boundaries of the compute layers as JSON object, for example.

The following defines how and when a DeviceMark is created and updated, how it moves through the computational nodes within a typical service network, what the associated methods are, and how it is presented, archived, synchronized and consumed at multiple software layers that constitute the entire Example service workflow.

It is beyond the scope of this document to specify details of implementation at each SW layer and most of the functions discussed below, especially the ones with their scope limited within the given layer, are meant to be guidelines unless specified otherwise. On the other hand, it is expected that the implementation adheres faithfully to the inter-layer API formats and portable data structure output formats to ensure interoperability among distinct vendors and developers.

Before discussing the DeviceMark class itself, we begin with how to manage the provenance of each DeviceMark created in the typical usage environment where multiple software layers and nodes operate.