Patent Description:
Law enforcement agencies provide officers and agents with an assortment of devices - electronic and otherwise - to carry out duties required of a law enforcement officer. Such devices include radios (in-vehicle and portable), body-worn cameras, weapons (guns, Tasers, clubs, etc.), portable computers, and the like. In addition, vehicles such as cars, motorcycles, bicycles, and Segways, are typically equipped with electronic devices associated with the vehicle, such as vehicle cameras, sirens, beacon lights, spotlights, personal computers, etc..

It is increasingly common for law enforcement agencies to require officers to activate cameras (body-worn and vehicle-mounted) that enable officers to capture audio and/or video of incidents in which an officer is involved. This provides a way to preserve evidence, that would otherwise be unavailable, for subsequent legal proceedings. This evidence greatly aids in the investigation of criminal activities, identification of perpetrators of crimes, and examination of allegations of police misconduct, to name a few advantages.

<CIT> discloses a computer-implemented method comprising: receiving a communication socket associated with a new device; instantiating a driver for the new device; creating a name for the new device and associating the name with the driver; transforming data of the new device to a standardized format; and performing telemetry using the new device, wherein telemetry data is stored in a standardized schema. Further a machine to machine data aggregator is known from <CIT>.

The detailed description is described with reference to the accompanying figures, in which the left-most digit(s) of a reference number identifies the figure in which the reference number first appears.

The present invention provides one or more computer-readable storage media storing computer-executable instructions that upon execution cause one or more processors to perform acts as defined by independent claim <NUM>. Further, the present invention provides a device according to independent claim <NUM>. The dependent claims show further preferred embodiments of the respective subject-matters of the independent claims. This disclosure is directed to techniques for creating a universal schema with default fields that support sensor formats of heterogenous devices. Fields are broken down to smallest fields that support all the sensor formats. In one example, such as when new devices are to be deployed in a network environment to replace older devices, a network operation center (NOC) server may configure new sensor formats for the new devices. A sensor format may include a configuration of the device for collecting telemetry data that can be processed in the NOC server. The sensor format is mapped in the universal schema that observes substantial equivalents (also called substantive equivalents) on its data structure. The new sensor format includes data fields that support inheritance and aggregation of other fields in sensor formats of prior devices such as the devices to be replaced. Because the new sensor format can be a superset or specializations (i.e., subclass of existing class) of the sensor formats from the prior or other devices, the mapping of the new sensor format in the universal schema may provide a coding that avoids copying of all the fields in the prior device (i.e., parent class). In addition, the mapping of the new sensor format in the universal schema may capture a mapping of substantive equivalents between the fields in the universal schema, and avoid running a risk of making different mappings of substantive equivalents in a universal schema structure, and changes in a parent class - sensor format can be easily propagated to child class - sensor format.

As defined herein, the substantive equivalents may include sufficient similarities in attributes between a child class-field (first device sensor format) and a parent class-field (second device sensor format) although the child class-field may utilize a field name, field type, bit alignment, and/or size that is different from the field name, field type, bit alignment, and/or size, respectively, of the parent class-field. Attributes that are sufficiently similar may be declared to be substantive equivalents through a use of flag or tag during creation of the universal schema. When the child class-field is detected to be a substantive equivalent of the parent class-field, a value in the child class-field may require initial transformation before it is stored in the universal schema. Alternatively, the value in the child class-field is not transformed but is directly stored to a mapped field in the universal schema that is a substantive equivalent of the child class-field. For example, the child class-field is recording timestamps in <NUM>-hour clock (military time) time format while the substantively equivalent parent class-field is recording the timestamps based on <NUM>-hour time format. In this example, a value in the child class-field time format (<NUM>-hour clock) is first transformed into a <NUM>-hour time format before it is stored in the universal schema. In another example, the child class-field is using "<NUM>st_Name" as a field name while the substantively equivalent parent class-field is using "First_Name. " In this example, a value under the "<NUM>st_Name" is directly stored (no transformation) into the field in the universal schema that is mapped to be a substantial equivalent of the child class-field "<NUM>st_NameThe universal schema is defined or created to observe substantial equivalents on its data field structure.

In one example, the NOC server may provision a driver for each one of the devices to be deployed in the network environment in order to establish communication with the NOC server. The NOC server may further create the new sensor format or select a sensor format to be associated with each one of the drivers to be provisioned. For the newly created sensor format, the NOC server may configure the created new sensor format to include fields that can inherit or aggregate the sensor formats from the prior or other devices. For the selected sensor format, the NOC server may select an existing sensor format from the other devices and optionally add fields that can also inherit or aggregate the other fields in the sensor formats of other devices. With the provisioned drivers and the created or selected associated sensor formats, the NOC server may deploy the devices to perform telemetry. For example, the devices may now perform periodic geolocation readings to capture locations of law enforcement officers who are using the devices, send names of the law enforcement officers who are using the devices, and the like.

In an example embodiment, the NOC server may receive telemetry data from a deployed device and transform the received telemetry data to conform with a structure of the universal schema. The structure of the universal schema include fields that support single/multiple inheritance and aggregation of other fields in other prior device sensor formats that were previously created, configured, and/or updated. Further, the fields in the universal schema support substantial equivalents between fields. In this regard, the NOC server may first verify whether the received telemetry data is substantially equivalent to another field in the parent class before storing the telemetry data in the universal schema.

As used herein, the terms "device," "portable device," "electronic device," and "portable electronic device" are used to indicate similar items and may be used interchangeably without affecting the meaning of the context in which they are used. Further, although the terms are used herein in relation to devices associated with law enforcement, it is noted that the subject matter described herein may be applied in other contexts as well, such as in a security system that utilizes multiple cameras and other devices.

The implementation and operations described above are ascribed to the use of the server; however, alternative implementations may execute certain operations in conjunction with or wholly within a different element or component of the system(s). Further, the techniques described herein may be implemented in a number of contexts, and several example implementations and context are provided with reference to the following figures. The term "techniques," as used herein, may refer to system(s), method(s), computer-readable instruction(s), module(s)m algorithms, hardware logic, and/or operation(s) as permitted by the context described above and throughout the document.

<FIG> illustrates a schematic view of an example base architecture <NUM> for implementing an object-oriented universal schema that supports mixing and matching of heterogenous sensor formats of media recording devices. The architecture <NUM> may include media recording devices <NUM>(<NUM>)-<NUM>(N) of different types. Each of the media recording devices <NUM>(<NUM>)-<NUM>(N) may be a video recording device, an audio recording device, or a multimedia recording device that records both video and audio data. The media recording devices <NUM>(<NUM>)-<NUM>(N) may include recording devices that are worn on the bodies of law enforcement officers, recording devices that are attached to the equipment, e.g., motor vehicles, personal transporters, bicycles, etc., used by the law enforcement officers. For example, a law enforcement officer (not shown) that is on foot patrol may be wearing the media recording device <NUM>(<NUM>). In the same example, another law enforcement officer that is on a vehicle patrol (not shown) may be wearing a media recording device <NUM>(<NUM>), and so on. Further, the patrol vehicle of the law enforcement officer may be equipped with the media recording device <NUM>(N).

Each of the media recording devices <NUM>(<NUM>)-<NUM>(N) may include a configured sensor format for its telemetry function. The sensor format includes a set of data fields that support inheritance and aggregation of existing sensor formats. The existing sensor formats may include the sensor formats of replaced media recording devices or other media recording devices that are referenced as a base class for the configured sensor format. For example, the second media recording device <NUM>(<NUM>) inherits from the first media recording device <NUM>(<NUM>), the fifth media recording device <NUM>(<NUM>) inherits (multiple inheritance) from the media recording devices <NUM>(<NUM>) and <NUM>(<NUM>), the tenth media recording device <NUM>(<NUM>) aggregates the sensor formats in media recording devices <NUM>(<NUM>) and <NUM>(<NUM>), and so on. In this example, a remote management unit such as a network operating center (NOC) server <NUM> may configure the sensor formats of the media recording devices <NUM>(<NUM>)-<NUM>(N) using inheritance or aggregation of the existing or selected sensor formats.

Given a situation where the media recording devices <NUM>(<NUM>)-<NUM>(N) are deployed for the first time to replace old/prior media recording devices (not shown), the NOC server <NUM> may create new sensor formats or use existing/stored sensor formats as the configured sensor formats of the media recording devices <NUM>(<NUM>)-<NUM>(N). In another situation, some of the deployed media recording devices <NUM>(<NUM>)-<NUM>(N) may require reconfiguration to update their corresponding sensor formats. In this case, the NOC server <NUM> may use the existing/stored sensor formats to update the sensor formats of the media recording devices that require reconfiguration. The NOC server <NUM> stores each sensor format of replaced devices, updated devices, and newly deployed devices. The NOC server <NUM> may communicate with the media recording devices <NUM>(<NUM>)-<NUM>(N) through a network <NUM> to configure the sensor format or in some instances, remove the sensor format of inactive media recording devices. The network <NUM> may be, without limitation, a local area network ("LAN"), a larger network such as a wide area network ("WAN"), a carrier network, or a collection of networks, such as the Internet. Protocols for network communication, such as TCP/IP, may be used to implement the network <NUM>. The network <NUM> may provide telecommunication and data communication in accordance with one or more technical standards.

In some embodiments, a media recording device may be equipped with telemetry software and hardware that provide the device with the ability to generate telemetry data for periodic transmission to the NOC server <NUM> via the network <NUM>. The telemetry hardware may include a global positioning system (GPS) chip, an assisted GPS (A-GPS) chip, or another equivalent geo-positioning sensor. The telemetry data generated by the media recording device may include an identification (ID) information of the media recording device, periodic geolocation readings of the media recording device, as well as time and date stamp information for each geolocation reading. In some instances, the media recording device may be capable of taking the geolocation reading at predetermined intervals (e.g., every <NUM> sec). In other cases, the media recording device may be reliant upon another device to provide telemetry data to the NOC server <NUM>. For example, a computing device attached to the media recording device <NUM>(<NUM>) may have geo-positioning capabilities. As such, the media recording device may rely on the attached computing device to provide the telemetry data to the NOC server <NUM> via the network <NUM>.

The NOC server <NUM> may be part of a facility that is operated by a law enforcement agency or a facility that is operated by a third-party that is offering services to the law enforcement agency. The NOC server <NUM> may include web-sockets <NUM>(<NUM>)-<NUM>(N), a queue <NUM>, data transformation component <NUM>, a telemetry data storage <NUM> with universal schema, configuration database <NUM>, reporting tool <NUM>, configuration deployment module <NUM>, configuration editor module <NUM>, a tag component <NUM>, and an admin too1 <NUM>. Each component or module of the NOC server <NUM> can be realized in hardware, software, or a combination thereof. For example, the web-sockets <NUM>(<NUM>)-<NUM>(N) may be implemented by a software module designed to establish communications with the media recording devices <NUM>(<NUM>)-<NUM>(N), respectively.

Each one of the web-sockets <NUM>(<NUM>)-<NUM>(N) may include an endpoint of a two-way communication link between two programs running on the network <NUM>. The endpoint includes an Internet Protocol (IP) address and a port number that can function as a destination address of the web-socket. Each one of the web-sockets <NUM>(<NUM>)-<NUM>(N) is bound to the IP address and the port number to enable entities such as the corresponding media recording device(s) to communicate with the web socket. In one example, the web-sockets <NUM>(<NUM>)-<NUM>(N) may be set up to receive telemetry data from the media recording devices <NUM>(<NUM>)-<NUM>(N). The received telemetry data is stored in the telemetry data <NUM> universal schema after a transformation of the telemetry data, for example, to conform with a defined universal schema structure in the universal schema. The defined universal schema structure includes fields that support inheritance and aggregation of other fields in the sensor format of other media recording devices.

The queue <NUM> may include management software that processes data streams to or from the web-sockets. The queue <NUM> may be implemented by an event streaming platform such as an Apache Kafka™ platform. In this case, the telemetry data streams from the web sockets <NUM> are pushed into the queue <NUM> as topics and the telemetry data storage <NUM> may subscribe to these topics in order to decouple the telemetry data streams from event streaming platform (queue <NUM>). A topic in the queue <NUM> includes an ordered collection of events that is stored in a durable manner. The topics in the queue <NUM> are divided into a number of partitions that store these events (records or messages) in an unchangeable sequence. The messages or records may be associated with media recording device identification, timestamps, header, and other information that relate to a transmission of data streams.

The topic may be similar to a table in a database but without the table constraints that may limit a type of data that can go into the table. For example, the telemetry data from the media recording device <NUM>(<NUM>) includes continuous streams of telemetry data that are received through the web socket <NUM>(<NUM>). In this example, the queue <NUM> may form and identify a topic for the received data streams, and the telemetry data storage <NUM> may decouple the data streams from the created topic in the queue <NUM>. The decoupled data streams may be used to gather metrics from different locations, track activity of the media recording devices <NUM>(<NUM>)-<NUM>(N), gather application logs, etc. Decoupling of data streams includes independently retrieving and processing the data streams without affecting the configuration of the source such as the queue <NUM>.

The data transformation component <NUM> may be configured to transform the telemetry data from the queue <NUM> prior to storing the telemetry data at the telemetry data storage <NUM>. The transformation may include changing the structure of the telemetry data to conform with the structure of the telemetry data as defined in the universal schema (telemetry data storage <NUM>). In one example, upon receiving of the telemetry data from the queue <NUM>, the data transformation component <NUM> may query the configuration database <NUM> to verify whether the fields in the received telemetry data are flagged or tagged. The tagging or flagging of the field in the configuration database <NUM> may indicate the telemetry data field to be substantively equivalent to another field.

Upon verification that the fields of the received telemetry data are tagged or flagged as substantial equivalents, then the data transformation component <NUM> may transform the fields of the received telemetry data in accordance with the flags or tags to conform with the defined universal schema structure in the telemetry data storage <NUM>. The defined universal schema structure may include fields that support substantive equivalents, and inheritance or aggregation of fields. The kinds of substantive equivalents may include change in name, size, type, and bit alignment. An example application of the defined universal schema structure and transformation of telemetry data fields based on substantive equivalents is further described in <FIG>.

The telemetry data storage <NUM> may include a universal schema that uses object-oriented data that supports a hierarchical data model. The telemetry data storage <NUM> may store telemetry data fields, mapped sensor formats that support the master-detail relationship structure (i.e., parent-child relationship), and annotations that may indicate a relationship between the mapped sensor format and the sensor format from the parent class. In one example, the fields in the universal schema of the telemetry data storage <NUM> support inheritance and aggregation of other fields. Further, each one of the fields in the universal schema may include a flag that indicates a capability of the field to be mapped with another field on the basis of substantive equivalents. In this regard, any changes in the parent class may be automatically propagated in the universal schema.

In one example, NOC server <NUM> may utilize the admin tool <NUM>, reporting tool <NUM>, configuration deployment module <NUM>, configuration editor <NUM>, and tag component <NUM> to create new sensor formats, update existing sensor formats, or remove sensor formats. The admin tool <NUM> may be utilized by a user (not shown) as a control panel to perform the creation of a new sensor format, and to update or remove an existing sensor format. The admin tool <NUM> may use the reporting tool <NUM>, configuration deployment module <NUM>, configuration editor <NUM>, and the tag component <NUM> to implement the functions of creating a new sensor format, placing a flag on each one of the fields that will be stored in the universal schema, updating a sensor format, entering annotations, and the like.

For example, the media recording devices <NUM>(<NUM>)-<NUM>(<NUM>) are to be deployed for the first time to replace a previous set of old model media recording devices (not shown). In this example, the NOC server <NUM> may utilize the admin tool <NUM>, reporting tool <NUM>, configuration deployment module <NUM>, configuration editor <NUM>, and tag component <NUM> to create a new sensor format (not shown) for each one of the media recording devices <NUM>(<NUM>)-<NUM>(<NUM>).

Referring to the deployment of the first media recording device <NUM>(<NUM>), the admin tool <NUM> may first establish a connection with the media recording device <NUM>(<NUM>) through the web-socket <NUM>(<NUM>) that can detect a connection status of the media recording device <NUM>(<NUM>). Upon detection of a connection status of the media recording device <NUM>(<NUM>), the configuration editor <NUM> may instantiate a new driver for the media recording device <NUM>(<NUM>). The new driver may be used by an operating system of the NOC server <NUM> to communicate with the connected media recording device <NUM>(<NUM>).

The configuration editor <NUM> may then create a name (e.g., video recording device ID) for the media recording device <NUM>(<NUM>), and associate the created name with the instantiated new driver. Further, the configuration editor <NUM> may create a new sensor format by inheriting or aggregating existing sensor formats in the configuration database <NUM>. The existing sensor formats in the configuration database <NUM> may include the sensor formats of the previously deployed media recording devices and/or other currently deployed media recording devices such the media recording device <NUM>(<NUM>)-<NUM>(N). In one example, the created new sensor format may include fields that support inheritance and aggregation of fields in the sensor formats of prior devices.

With the created new field, the configuration editor <NUM> associates the created new sensor format with the new driver of the media recording device <NUM>(<NUM>), and the configuration deployment module <NUM> may deploy the media recording device <NUM>(<NUM>) to perform telemetry. For example, configuration deployment module <NUM> sends the created new sensor format, new driver, and other information to the media recording device <NUM>(<NUM>) through the queue <NUM> and the web-socket <NUM>(<NUM>). In this example, the web-socket <NUM>(<NUM>) may be used to facilitate the receiving of the telemetry data that can be transformed and stored in the universal schema.

Referring to the deployment of the media recording devices <NUM>(<NUM>)-<NUM>(<NUM>) in the above example, the process as described above for the media recording device <NUM>(<NUM>) may be similarly applied. That is, the configuration editor <NUM> may instantiate a new driver for each one of the media recording devices <NUM>(<NUM>)-<NUM>(<NUM>), create individual names, associate the created names with the corresponding instantiated driver, create the new sensor formats, and so on.

In some cases, instead of creating the new sensor formats as described in the example above, the NOC server <NUM> may select existing sensor formats to be associated with the new drivers of the media recording devices <NUM>(<NUM>)-<NUM>(<NUM>). In this regard, the configuration editor <NUM> may select the existing sensor formats in the configuration database <NUM>, add additional field as may be necessary, and associate the selected sensor formats plus the additional field to the corresponding media recording device. Different versions of these modified formats are stored in a database by the NOC server <NUM>. Thereafter, the configuration deployment module <NUM> may deploy the media recording devices <NUM>(<NUM>)-<NUM>(<NUM>) to perform telemetry.

<FIG> is a block diagram of the telemetry data storage <NUM> including an example universal schema <NUM>. The illustrated universal schema <NUM> includes a simplified set of fields with corresponding mapped sensor formats to illustrate the implementations described herein. In the following discussion, reference is made to elements and reference numerals shown and described with respect to the NOC server <NUM> of <FIG>.

In one example, a first defined universal schema structure <NUM> and a second defined universal schema structure <NUM> may store data that are received from the media recording devices <NUM>(<NUM>)-<NUM>(N) as described in <FIG>. The data may include telemetry data such as periodic geolocation readings of the media recording devices, time and date timestamp for each geolocation reading, identifications (IDs) of the media recording devices, names of law enforcement officers associated with the media recording devices, etc. In this example, the data transformation component <NUM> receives the data and stores the received data in the universal schema <NUM>.

The first defined universal schema structure <NUM> includes data fields that supports substantial equivalents and inheritance and aggregation of other data fields in a hierarchical relational database. In one example, the first defined universal schema structure <NUM> of the universal schema <NUM> may include a <NUM>-hour clock <NUM> for a clock measurement field <NUM>, a resolution in megapixels <NUM> for a camera resolution setting field <NUM>, an optical zoom <NUM> for a camera viewing capability field <NUM>, a sensor format <NUM> for sensor format fields <NUM>, flags <NUM> for flag fields <NUM>, and a note <NUM> for annotations <NUM>. The annotations <NUM> may indicate the fields in the universal schema <NUM> that support substantial equivalents. The second defined universal schema structure <NUM> similarly includes data fields that support substantial equivalents and inheritance and aggregation of other data fields in the hierarchical relational database. In one example the second defined universal schema structure <NUM> of the universal schema <NUM> may include a "First_Name" <NUM> for a person's first name field <NUM>, "Middle_Name" <NUM> for a person's middle name field <NUM>, "Last_Name" <NUM> for a person's last name field <NUM>, suffix <NUM> for a person's suffix name field <NUM>, a sensor format <NUM> for sensor format fields <NUM>, flags <NUM> for flag fields <NUM>, and a note <NUM> for annotations <NUM>. The annotations <NUM> may indicate the fields in the universal schema <NUM> that support substantial equivalents. The manner in which the present universal schema <NUM> is provided is not intended to limit the scope of the claims presented herewith but is intended merely to provide an example of what kinds of data may be used with the present techniques and how a data item may be associated with other data items and the significance thereof.

In an example embodiment, the defined universal schema structures <NUM>/<NUM> support the use of substantive equivalents its data fields. For the example universal schema structure <NUM>, a substantive equivalent based on types is illustrated. That is, a unit of measurement (first type) in a received data field is first transformed into another unit of measurement (second type) before it is stored in the universal schema <NUM>. That is, a <NUM>-hour clock can be transformed into <NUM>-hour clock time format, a resolution in megapixels can be transformed into pixels per square inches, an optical zoom measured in variables "2X, 3X, 4X. " may be changed to numerical percentage "<NUM>%, <NUM>%, <NUM>%,. " and so on, before they are stored in the universal schema structure <NUM>. For the example universal schema structure <NUM>, a substantive equivalent based on a change of name is illustrated. That is, the incoming data fields may have a different field name representation and they are mapped to substantially equivalent fields in the universal schema without transforming the values of the incoming data fields. That is, the values under the substantively equivalent field name may be direct stored into the mapped field in the universal schema <NUM>.

Referencing the universal schema structure <NUM>, the data transformation component <NUM> receives, for example, from the media recording device <NUM>(<NUM>) a clock measurement field that is in <NUM>-hour clock type (e.g., 1300Hours) instead of the <NUM>-hour clock type (<NUM>-hour clock <NUM>). In this example, the data transformation component <NUM> may initially verify via the configuration database <NUM> if there is a flag for the clock measurement field <NUM> that indicates support of substantial equivalence. If the <NUM>-hour clock <NUM> is flagged or supports substantial equivalents (annotation <NUM> includes "<NUM>-hour clock = <NUM>-hour clock"), then the data transformation component <NUM> may transform the unit of measurement in the value of the received clock measurement field from the <NUM>-hour clock type into <NUM>-hour clock type (i.e., "<NUM> Hours" to "<NUM>:<NUM> PM") before storing the received clock measurement field in the clock measurement field <NUM> of the first universal schema structure <NUM>.

In another example, the data transformation component <NUM> receives from the media recording device <NUM>(<NUM>) an optical zoom capability (e.g., a magnification of "3X" instead of <NUM>%, or "2X" instead of <NUM>%, etc.) for the camera viewing capability field <NUM>. In this example, the data transformation component <NUM> may again verify via the configuration database <NUM> if there is a flag for the camera viewing capability field to indicate support of substantial equivalents. If the camera viewing capability field is not flagged (i.e., does not indicate that there are one or more substantial equivalents in the universal schema to which this field is mapped), then the data transformation component <NUM> may directly store the indication of optical zoom capability in the camera viewing capability field <NUM> of the universal schema <NUM> without first transforming the indication of optical zoom to a different format or value (e.g., "3X" to <NUM>%, "2X" to <NUM>%), and then storing the transformed indication. In other words, the match is direct and exact, and not a substantially equivalent mapping.

In one example, the sensor format <NUM> may be a superset or specializations of the sensor format in the prior devices. In this case, the sensor format <NUM> may be defined to include a set of fields that support inheritance or aggregation of other fields in other existing sensor formats.

For the second universal schema structure <NUM>, the storing process of the received person's first name, middle name, last name, and suffix is similar to the process as described above for the first universal schema structure <NUM>. That is, the data transformation component <NUM> may receive data fields that include, for example, "<NUM>st_Name," "Mid_Init," "L_Name," and "Suffix. " In this example, the data transformation component <NUM> may query the configuration database <NUM> to verify whether each one of the received data fields is flagged or tagged. For the flagged data fields, the data transformation component <NUM> may store the received data fields to corresponding fields in the universal schema <NUM> that are mapped as substantial equivalents of the received data fields. For example, the values of the received data fields "<NUM>st_Name," "Mid_Init," and "L_Name" are stored in substantively equivalent "first name field <NUM>," "middle name field <NUM>," and "last name field <NUM>," respectively. In this kind of substantive equivalents, there is no transformation in the value of the received data field before storing of the value in the defined universal schema <NUM>.

In some cases, the substantial equivalence between fields is based upon a user-entered parameter. That is, two distinct fields may still be declared to be substantively equivalent, and a transformation may be set up by the user to eventually correlate the two fields. For example, an American Standard Code for Information Interchange (ASCII) code "<NUM>" that is equivalent to letter "A" is assigned to a phrase "Alpha. " In this example, the transformation may be set up to interpret the ASCII code "<NUM>" to "Alpha" instead of letter "A.

<FIG> is a diagram <NUM> showing a concept of transforming a received set of fields that are substantially equivalent in type with the structure of the fields in the defined universal schema. In the following discussion, reference is made to elements and reference numerals shown and described with respect to the first universal schema structure <NUM> of <FIG> and the NOC server <NUM> of <FIG>. For example, diagram <NUM> shows the data transformation component <NUM> that receives telemetry data, the configuration database <NUM> that is used by the data transformation component <NUM> to verify the fields that support substantial equivalents, and the telemetry data storage <NUM> that stores the telemetry data from the data transformation component <NUM>. Diagram <NUM> further shows a parent class <NUM> that refers to a base class object (e.g., prior or other media recording device) and corresponding fields, and a child class <NUM> that refers to the received telemetry data in the data transformation component <NUM>.

In one example, the data transformation component <NUM> receives a set of data fields from the queue <NUM> and queries the configuration database <NUM> to verify whether each one of the received data fields is substantively equivalent with the fields in the defined universal schema <NUM>. Given a situation where the data fields are flagged to indicate substantive equivalents, then the data transformation component <NUM> may transform the received data fields in accordance with the flags to conform with the structure of the defined universal schema structure <NUM> before storing the received data fields from the queue <NUM>.

For example, the data transformation component <NUM> receives telemetry data that include "<NUM>" <NUM> as camera or media recording device identification (ID), "<NUM> Hours" <NUM> as the clock measurement field, "<NUM> x <NUM> pixels per square inches" <NUM> as the camera resolution setting field, "3X" <NUM> as the camera viewing capability field, and "new sensor format" <NUM> as the sensor format field. In this example, the data transformation component <NUM> may send queries to the configuration database <NUM> to verify whether each one of the received "<NUM> Hours" <NUM>, "<NUM> x <NUM> pixels per square inches" <NUM>, and the "3X" <NUM> is substantially equivalent with the field structure (e.g., field-type) that is used in the defined universal schema structure <NUM>. The universal schema structure <NUM> may be a superset or specialization of the parent class <NUM> that includes a <NUM>-hour clock <NUM> for the clock measurement field, a resolution in megapixels <NUM> for the camera resolution setting field, flags <NUM> for flag fields, an existing sensor format <NUM> for the sensor format field, and a note <NUM> for the annotation field.

In an example embodiment, the configuration database <NUM> receives a query <NUM> from the data transformation component <NUM> with regard to verification of the received clock measurement field ("<NUM> Hours" <NUM>), camera resolution setting field ("<NUM> x <NUM> pixels per inch square" <NUM>), and the viewing capability field ("3X" <NUM>), respectively. In response to the received query <NUM>, the configuration database <NUM> may send a response (not shown) indicating, for example, that the clock measurement field ("<NUM> Hours" <NUM>) and the camera resolution setting field ("<NUM> x <NUM> pixels per inch square" <NUM>) are flagged as requiring transformation while the viewing capability field ("3X" <NUM>) is not tagged/flagged. In this case, the data transformation component <NUM> may transform the "<NUM> Hours" <NUM> into "<NUM>:<NUM> PM" <NUM> (<NUM>-hour clock) and the "<NUM> x <NUM> pixels per inch square" <NUM> into "<NUM> Megs" <NUM> before storing these fields in the defined universal schema structure <NUM>. It is to be noted that the viewing capability field ("3X" <NUM>) is not flagged in the configuration database <NUM> and, as such, the "3X" <NUM> may be directly stored as "3X" <NUM> in the defined universal schema structure <NUM>.

The sensor format <NUM> of the defined universal schema structure <NUM> is configured to inherit from the existing sensor format <NUM> of the parent class <NUM> (prior or other devices). For example, a coding of the defined universal schema structure <NUM> may inherit the clock and the resolution from the parent class <NUM> and add the viewing capability field in the child class <NUM>. In this example, the sensor format <NUM> is considered to be a superset of the existing sensor format <NUM> in the parent class <NUM>. By using the sensor format <NUM> in the first universal schema structure <NUM>, multiple advantages may be obtained. For example, the coding in the first universal schema structure <NUM> may be implemented without copying all the fields in the parent class <NUM>. Further, the first universal schema structure <NUM> captures the mapping of substantive equivalents. Further still, changes in the parent class <NUM> can be propagated automatically to the universal schema structure <NUM>.

<FIG> is a diagram <NUM> showing a concept of mapping a received set of fields that are substantially equivalent - based on a change of name - with the structure of the fields in the defined universal schema. Diagram <NUM> shows no transformations in actual values of received data fields but illustrates the direct storing of the actual values to corresponding fields that are mapped as substantial equivalents of the received data fields. In the following discussion, reference is made to elements and reference numerals shown and described with respect to the second universal schema structure <NUM> of <FIG> and the NOC server <NUM> of <FIG>. For example, diagram <NUM> shows the data transformation component <NUM> that receives telemetry data, the configuration database <NUM> that is used by the data transformation component <NUM> to verify the fields that support substantial equivalents, and the telemetry data storage <NUM> that stores the telemetry data from the data transformation component <NUM>. Diagram <NUM> further shows a parent class <NUM> that refers to a base class object (prior device) and corresponding fields, and a child class <NUM> that refers to the received telemetry data in the data transformation component <NUM>.

In one example, the data transformation component <NUM> receives a set of data fields from the queue <NUM> and queries the configuration database <NUM> to verify whether each one of the received data fields is substantively equivalent (based on a change of name) with the fields in the defined universal schema <NUM>. Given a situation where the received data fields are flagged, then the data transformation component <NUM> may transform the received data fields to conform with the field structure of the defined universal schema structure <NUM> before storing the received data fields. In the case of substantive equivalents that is based upon a change of name, the data transformation component <NUM> may directly store the values of the received data fields to mapped fields in the universal schema that are substantial equivalents of the received data fields.

For example, the data transformation component <NUM> receives the telemetry data that include "Alex" <NUM> under "<NUM>st_Name" <NUM> (i.e., field format name), "B. " <NUM> under "Mid_Init" <NUM>, "Carter" <NUM> under "L_Name" <NUM>, "Jr. " <NUM> under "Suffice" <NUM>, and "new sensor format" <NUM> as a sensor format field <NUM>. In this example, the data transformation component <NUM> may send a query <NUM> to the configuration database <NUM> to verify whether each one of the received fields includes a flag indicating a substantial equivalent with the field structure that is used in the defined universal schema structure <NUM>. In this example, the configuration database <NUM> may indicate that the received data fields "<NUM>st_Name" <NUM>, "Mid_Init" <NUM>, "L_Name" <NUM> are substantial equivalents of a "First Name" <NUM>, "Middle Name" <NUM>, and "Last Name <NUM>," respectively, in the universal schema <NUM>. Accordingly, the data transformation component <NUM> may directly store the values "Alex" <NUM>, "B. " <NUM>, and "Carter" <NUM> in the "First Name" <NUM>, "Middle Name" <NUM>, and "Last Name <NUM>," respectively. In one example, a data field "Suffix" <NUM> is added to the universal schema <NUM> that is a superset of the parent class <NUM>. It is to be noted that the suffix field for the parent class <NUM> can be left as blank in the universal schema. The universal schema <NUM> further includes a sensor format <NUM>, flags <NUM>, and annotations <NUM>. The sensor format <NUM> may store the new sensor format <NUM> that can inherit from the sensor format in the parent class <NUM>. The flags <NUM> may store the flags <NUM> for each one of the fields in the universal schema. And the annotations <NUM> may indicate the substantial equivalents in the fields of the universal schema.

The new sensor format <NUM> of the defined universal schema structure <NUM> is configured to inherit from an existing sensor format <NUM> of the parent class <NUM>. For example, coding of the defined universal schema structure <NUM> may inherit the first name, middle name, and last name from the parent class <NUM> and adds the suffix field in the child class <NUM>. In this example, the new sensor format <NUM> is considered as a superset of the existing sensor format <NUM> in the parent class <NUM>. By using the new sensor format <NUM> in the universal schema structure <NUM>, multiple advantages may be obtained. For example, the coding in the universal schema structure <NUM> may be implemented without copying all the fields in the parent class <NUM>. Further, the universal schema structure <NUM> captures the mapping of substantive equivalents. Further still, changes in the parent class <NUM> can be propagated automatically to the universal schema structure <NUM>.

<FIG> is a diagram <NUM> showing a concept of transforming a received set of data fields that are substantially equivalent to the structure of the fields in the defined universal schema. Particularly, a sensor format that is mapped to the received set of fields inherits from multiple sensor formats from different base classes that support substantial equivalents. In the following discussion, reference is made to elements and reference numerals shown and described with respect to the first universal schema structure <NUM> of <FIG> and the NOC server <NUM> of <FIG>. For example, diagram <NUM> shows the data transformation component <NUM> that receives telemetry data, the configuration database <NUM> that is used by the data transformation component <NUM> to verify the fields that support substantial equivalents, and the telemetry data storage <NUM> that stores the telemetry data from the data transformation component <NUM>. Diagram <NUM> further shows a first parent class <NUM> that refers to a first object (e.g., first device to be replaced) and corresponding fields, a second parent class <NUM> that refers to a second object (e.g., second device to be replaced) and corresponding fields, and a child class <NUM> that refers to the received telemetry data in the data transformation component <NUM>.

In one example, the data transformation component <NUM> receives a set of data fields from the queue <NUM> and queries the configuration database <NUM> to verify whether each one of the received data fields is substantively equivalent to the fields in the defined universal schema <NUM>. Given a situation where the data fields are flagged, then the data transformation component <NUM> may transform the received data fields to conform with the structure of the defined universal schema structure <NUM> before storing the received data fields.

For example, the data transformation component <NUM> receives the telemetry data that include "<NUM>" <NUM> as a camera or media recording device ID, "<NUM> Hours" <NUM> as the clock measurement field, "<NUM> x <NUM> pixels per square inches" <NUM> as the camera resolution setting field, "3X" <NUM> as the camera viewing capability field, "<NUM>rd sensor format" <NUM> as the sensor format field, and a note <NUM> for the annotations. In this example, the data transformation component <NUM> may send queries <NUM> to the configuration database <NUM> to verify whether each one of the received "<NUM> Hours" <NUM>, "<NUM> x <NUM> pixels per square inches" <NUM>, and the "3X" <NUM> is substantially equivalent with the field structure that is used in the defined universal schema structure <NUM>.

The universal schema structure <NUM> may be a superset of the parent classes <NUM> and <NUM>. As depicted, the first parent class <NUM> may be associated with fields that include a <NUM>-hour clock <NUM> for the clock measurement field, flags <NUM> for flag fields, a first sensor format <NUM> for the sensor format field, and a note <NUM> for the annotation field. The second parent class <NUM> may be associated with a resolution in megapixels <NUM> for the camera resolution setting field, flags <NUM> for flag fields, a second sensor format <NUM> for the sensor format field, and a note <NUM> for the annotation field.

In an example embodiment, the configuration database <NUM> receives a query <NUM> from the data transformation component <NUM> to verify the received clock measurement field ("<NUM> Hours" <NUM>), camera resolution setting field ("<NUM> x <NUM> pixels per inch square" <NUM>), and the viewing capability field ("3X" <NUM>). In response to the received query <NUM>, the configuration database <NUM> may send the response <NUM> indicating, for example, that the clock measurement field ("<NUM> Hours" <NUM>) is flagged based upon the first parent class <NUM>, the camera resolution setting field ("<NUM> x <NUM> pixels per inch square" <NUM>) is flagged based upon the second parent class <NUM>, while the viewing capability field ("3X" <NUM>) is not tagged/flagged. In this case, the data transformation component <NUM> may transform the "<NUM> Hours" <NUM> (<NUM>-hour clock) into "<NUM>:<NUM> PM" <NUM> (<NUM>-hour clock) and the "<NUM> x <NUM> pixels per inch square" <NUM> into "<NUM> Megs" <NUM> before storing these fields in the defined universal schema structure <NUM>. It is to be noted that the viewing capability field having the value "3X" <NUM>) is not flagged in the configuration database <NUM> and as such, the "3X" <NUM> may be directly stored as "3X" <NUM> in the defined universal schema structure <NUM>.

In an embodiment, the sensor format <NUM> may include the <NUM>rd sensor format <NUM> that inherits from the first sensor format <NUM> of the first parent class <NUM> and the second sensor format <NUM> of the second parent class <NUM>. For example, a coding of the defined universal schema structure <NUM> may inherit the clock measurement and the camera resolution from the parent classes <NUM> and <NUM>, respectively, and adds the viewing capability field in the child class <NUM>. In this example, the sensor format <NUM> is considered to be a superset of the first sensor format <NUM> and the second sensor format <NUM>.

In some cases, the substantial equivalents may include a difference in bit alignments (not shown) in the received telemetry data fields. For example, the data transformation component <NUM> receives the value "<NUM> Hours" <NUM> of the clock measurement field that includes extra bits when compared with the number of bits utilized in the "<NUM>-hour clock <NUM>" of the parent class <NUM>. In this example, the data transformation component <NUM> verifies from the configuration database <NUM> the presence of substantial equivalents in the bit alignment. If so, then the data transformation component <NUM> may accordingly adjust the bit alignment before storing the received telemetry data in the universal schema <NUM>.

<FIG> is a flow diagram <NUM> that depicts a methodological implementation of at least one aspect of the techniques for configuring a media recording device that is to be deployed for the first time to perform telemetry. In the following discussion of <FIG>, continuing reference is made to the elements and reference numerals shown in and described with respect to the NOC server <NUM> of <FIG>. Further, certain operations may be ascribed to particular system elements shown in previous figures. However, alternative implementations may execute certain operations in conjunction with or wholly within a different element or component of the system(s). Furthermore, to the extent that certain operations are described in a particular order, it is noted that some operations may be implemented in a different order to produce similar results.

At block <NUM>, the admin tool <NUM> receives a communication socket that is associated with a new video recording device to be deployed. For example, the media recording device <NUM>(<NUM>) is deployed to replace an old media recording device. In this example, the NOC server <NUM> may create a corresponding web-socket (e.g., web-socket <NUM>(<NUM>)) with an IP address and a port number for the media recording device <NUM>(<NUM>). The IP address and the port number are communicated to the admin tool <NUM> as a reference for establishing a communication link with the media recording device <NUM>(<NUM>).

At block <NUM>, the configuration editor <NUM> instantiates a driver for the new media recording device. For example, the driver may be used by the operating system of the NOC server <NUM> to communicate with the media recording device <NUM>(<NUM>).

At block <NUM>, the configuration editor <NUM> creates a name for the new media recording device and associates the name with the instantiated driver.

At block <NUM>, the configuration editor <NUM> provisions the driver with a telemetry speed. For example, the telemetry speed may include or indicate an amount of data that is buffered before it is processed in the data transformation component <NUM>. The telemetry speed may also refer to an amount of data collected by the media recording device before the collected data are transmitted to the NOC server <NUM>. In one example, masking of received telemetry data in the queue <NUM> may be based upon the provisioned telemetry speed.

At block <NUM>, the configuration editor <NUM> creates a sensor format for the driver. For example, the sensor format includes the new sensor format <NUM>, new sensor format <NUM>, or the <NUM>rd sensor format <NUM> in <FIG>, respectively. In this example, each one of the new sensor formats <NUM> and <NUM>, and the <NUM>rd sensor format <NUM> are configured to inherit from a parent class such as the parent class <NUM>, parent class <NUM>, parent class <NUM>, etc. In some cases, the new sensor format such as the <NUM>rd sensor format <NUM> are configured to aggregate the sensor formats from the parent classes such as the parent classes <NUM> and <NUM>. Further, the new sensor format may support multiple inheritances from different parent classes. In these cases, the new sensor format captures the mappings of substantial equivalents.

At block <NUM>, the configuration editor <NUM> associates the created sensor format to the driver. In one example, the created sensor format is communicated to the media recording device <NUM>(<NUM>) via the web-socket <NUM>(<NUM>).

At block <NUM>, the NOC server <NUM> receives telemetry from the media recording device.

At block <NUM>, the NOC server <NUM> and particularly the data transformation component <NUM>, verifies substantial equivalent (flags) before storing the telemetry data in the universal schema. The data transformation component <NUM> queries the configuration database <NUM> whether a field in the received telemetry data is substantially equivalent to a field in the universal schema. Differences between substantial equivalents may include a change in name, type, size, and bit alignment. Upon verification, the data transformation component <NUM> may transform data from the received field to conform with the structure of the defined universal schema.

<FIG> is a flow diagram <NUM> that depicts a methodological implementation of at least one aspect of the techniques for transforming a received telemetry data to conform with a structure of the defined universal schema. In the following discussion of <FIG>, continuing reference is made to the elements and reference numerals shown in and described with respect to the NOC server <NUM> of <FIG>. Further, certain operations may be ascribed to particular system elements shown in previous figures. However, alternative implementations may execute certain operations in conjunction with or wholly within a different element or component of the system(s). Furthermore, to the extent that certain operations are described in a particular order, it is noted that some operations may be implemented in a different order to produce similar results.

At block <NUM>, the data transformation component <NUM> receives telemetry data that includes at least one field from a media recording device. In one example, the NOC server <NUM> may use the corresponding web-socket and the queue <NUM> to receive the telemetry data that can include a plurality of fields.

At block <NUM>, the data transformation component <NUM> verifies from the configuration database <NUM> substantial equivalents of the at least one field. In one example, relationships between the substantial equivalents may include or indicate kinds of differences between substantial equivalents such as a change in name, size, type, and bit alignment. In this example, the data transformation component <NUM> may send a query to the configuration database <NUM> to determine the presence of substantial equivalents for each one of the received telemetry data fields.

At decision block <NUM>, the data transformation component <NUM> receives a response from the configuration database <NUM> that indicates the presence or absence of a flag for each one of the queried fields. In a case where one or more flags indicate substantial equivalents ("Yes" at block <NUM>), then at block <NUM>, the data transformation component <NUM> may store the received field to conform with the structure of the defined universal schema.

In one case, the data transformation component <NUM> may transform the "<NUM> Hours" to "<NUM>:<NUM> PM" <NUM>-hour clock before storing the value into corresponding field in the universal schema. In another case, however, the data transformation component <NUM> may directly store a value (e.g., "Alex") under a field name to a field in the universal schema that maps to the field name as described in <FIG>. This type of substantial equivalent that is based upon a change in name does not require transformation before storing of values in the universal schema.

After transformation, at block <NUM>, the data transformation component <NUM> stores the transformed telemetry data into the universal schema. For the change of name kind of substantial equivalents, the data transformation component <NUM> directly stores the value of data field to the corresponding field in the universal schema that is mapped to be a substantial equivalent of the received data field. In one example, the data transformation component <NUM> stores all versions, identifications, attributes, and other information for each updated sensor format.

Referring again to the decision block <NUM>, in a case where the at least one field is not indicated to have substantial equivalence to the field in the parent class ("No" at block <NUM>), then the data transformation component <NUM> may directly store the received field in the universal schema. For example, the value "3X" <NUM> of the viewing capability field is not substantially equivalent to another field in the prior devices, and is directly stored in the universal schema.

<FIG> is a diagram of an example NOC server <NUM> for implementing an obj ect-oriented universal schema that supports mixing and matching of heterogenous sensor formats of the media recording devices. The NOC server <NUM> is similar to the NOC server <NUM> of <FIG> and may include hardware, software, or a combination thereof, that implements deployment of the media recording devices including the configuring of each one of the media recording devices as described above with respect to <FIG>.

The NOC server <NUM> includes a communication interface <NUM> that facilitates communication with media recording devices such as the media recording devices <NUM>(<NUM>)-<NUM>(N). Communication between the NOC server <NUM> and other electronic devices may utilize any sort of communication protocol known in the art for sending and receiving data and/or voice communications.

The NOC server <NUM> includes a processor <NUM> having electronic circuitry that executes instruction code segments by performing basic arithmetic, logical, control, memory, and input/output (I/O) operations specified by the instruction code. The processor <NUM> can be a product that is commercially available through companies such as Intel® or AMD®, or it can be one that is customized to work with and control a particular system. The processor <NUM> may be coupled to other hardware components used to carry out device operations. The other hardware components may include one or more user interface hardware components not shown individually - such as a keyboard, a mouse, a display, a microphone, a camera, and/or the like - that support user interaction with the NOC server <NUM>.

The NOC server <NUM> also includes memory <NUM> that stores data, executable instructions, modules, components, data structures, etc. The memory <NUM> may be implemented using computer-readable media. Computer-readable media includes, at least, two types of computer-readable media, namely computer-readable storage media and communications media. Computer-readable storage media includes, but is not limited to, Random Access Memory (RAM), Dynamic Random Access Memory (DRAM), Read-Only Memory (ROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), flash memory or other memory technology, Compact Disc - Read-Only Memory (CD-ROM), digital versatile disks (DVD), high-definition multimedia/data storage disks, or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information for access by a computing device. As defined herein, computer-readable storage media do not consist of and are not formed exclusively by, modulated data signals, such as a carrier wave. In contrast, communication media may embody computer-readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave, or other transmission mechanisms.

A memory controller <NUM> is stored in the memory <NUM> of the NOC server <NUM>. The memory controller <NUM> may include hardware, software, or a combination thereof, that enables the memory <NUM> to interact with the communication interface <NUM>, processor <NUM>, and other components of the NOC server <NUM>. For example, the memory controller <NUM> receives data (e.g., audio and video contents) from the communication interface <NUM> and sends the received data to a hierarchical data ingestion app <NUM> for further processing. In another example, the memory controller <NUM> may retrieve data from memory <NUM> where the data will be processed in the processor <NUM>.

The memory <NUM> stores the hierarchical data ingestion app <NUM> that, when executed, implements the object-oriented universal schema that supports mixing and matching of heterogenous sensor formats of the media recording devices as described herein. As shown, the hierarchical data ingestion app <NUM> includes a network or web-sockets <NUM>, a queue loader <NUM>, data transformation component <NUM>, a substantive equivalence tracker <NUM>, and a database <NUM>. The database <NUM> may further include a configuration database <NUM>, a universal schema <NUM>, a driver module <NUM>, and a sensor formats module <NUM>. In one example, each component of the hierarchical data ingestion app <NUM> can be realized in hardware, software, or a combination thereof. For example, the data transformation component <NUM> is a software module designed to transform the received telemetry data before storing the telemetry data to the universal schema <NUM>.

The web-sockets <NUM> are similar to web-sockets <NUM>(<NUM>)-<NUM>(N) of <FIG>. The web-sockets <NUM> may be implemented by a software module designed to establish communications with the media recording devices <NUM>(<NUM>)-<NUM>(N), respectively. In one example, each one of the web-sockets <NUM>(<NUM>)-<NUM>(N) is bound to the IP address and the port number to communicate with the corresponding media recording device. The queue <NUM> may include a loader that facilitates receiving or transferring of data to or from the web-sockets <NUM>.

In one example, the queue loader <NUM> may include an application programming interface (API) to establish a connection with an event streaming platform such as the Apache Kafka™. The event streaming platform may utilize logs to store the telemetry data streams from the media recording devices. The logs are immutable records of things or events. The logs may include topics and partitions to store the telemetry data streams. In one example, the NOC server may subscribe to the topics in the event streaming platform and utilize the queue loader <NUM> to decouple the telemetry data streams.

The data transformation component <NUM> is similar to the data transformation component <NUM> of <FIG>. The data transformation component <NUM> may utilize the substantive equivalence tracker <NUM> to verify whether the received telemetry data that includes at least one field is substantively equivalent to another field as described above in <FIG>. In on example, the substantive equivalence tracker <NUM> may send queries to the configuration database <NUM> to verify whether the received field is substantively equivalent to another field based upon type, change of name, size, or bit alignment. For verified fields (i.e., fields that are substantively equivalent to another field), the data transformation component <NUM> may change the structure of the verified fields to conform with the structure of the defined universal schema in the universal schema <NUM>.

The driver module <NUM> and the sensor formats module may store the instantiated drivers and the configured sensor format, respectively, for each one of the media recording devices <NUM>(<NUM>)-<NUM>(N). The creation of the sensor format or the updating of the sensor format is described above with respect to <FIG>.

Claim 1:
One or more computer-readable storage media storing computer-executable instructions that upon execution cause one or more processors to perform acts comprising:
receiving (<NUM>) a communication socket associated with a new device;
instantiating (<NUM>) a driver for the new device;
creating (<NUM>) a name for the new device and associating (<NUM>) the name with the driver;
creating (<NUM>) a new sensor format for the driver, wherein the new sensor format is mapped to a universal schema (<NUM>, <NUM>, <NUM>) and based at least upon a sensor format of different device;
associating (<NUM>) the created new sensor format with the driver of the new device; and
performing telemetry using the new device, wherein telemetry data is stored in the universal schema (<NUM>, <NUM>, <NUM>);
and further comprising:
querying a configuration database (<NUM>) to determine whether an at least one field in the telemetry data is substantively equivalent to another field in a sensor format of a different device, wherein the different device is replaced by the new device;
wherein the universal schema (<NUM>, <NUM>, <NUM>) is provided with default fields that support sensor formats of heterogenous devices; wherein the fields are broken down to smallest fields that support all the sensor formats; wherein the new sensor format is mapped in the universal schema (<NUM>, <NUM>, <NUM>) that observes substantial equivalents on its data structure, wherein the new sensor format includes data fields that support inheritance and aggregation of other fields in sensor formats of prior devices such as the device that is replaced.