Patent Description:
In network communications (e.g., Internet communications), it is often beneficial to use a communication standard that uses human-readable text. Such communication standards are often easier for programmers to understand and may be more flexible than application specific binary formats. One example communication standard that uses human-readable text is JavaScript Object Notation (JSON). JSON is well-suited for Internet communications because of its close ties to JavaScript, which is supported out-of-the-box by many Internet browsers and other applications. <CIT> relates to a method and system for encrypting Javascript Object Notation (JSON) messages. XP055388377 relates to JSON entryption.

In described examples, a data handler has a first input to receive object data and a first output to output an object notation key-value pair for the object data. A string processor has a second input coupled to the first output and a second output to convey the object notation key-value pair without string literals. A hashing and encryption handler has a third input coupled to the second output and a third output to convey the key-value pair signed with a private key, to convey the key-value pair encrypted with a public key, and to convey an indication that the encrypted key-value pair is encrypted in a key of the encrypted key-value pair.

The Internet of Things (IoT) refers to the concept of joining a wide range of devices to the Internet. The "things" may be any type of device or system, which often includes many devices that have previously not included circuitry capable of communicating on a network such as the Internet (e.g., consumer appliances, automobiles, biomedical devices, power outlets, thermostats and/or other environmental sensors). For example, a coffee maker may include an embedded computing device that allows the coffee maker to be uniquely identified on the Internet and allows remote control and monitoring of the example coffee maker via other Internet connected devices. Many IoT devices include low-cost and/or low-power computing devices to reduce the cost and physical space needed to add IoT functionality.

While JSON and other standards using human-readable text for storing and transmitting data objects (e.g., Extensible Markup Language (XML), Yet Another Markup Language (YAML)) (collectively object notation data) are well-suited for use with devices communicating on the Internet, example methods and apparatus disclosed in this application provide extensions to such human-readable formats to facilitate the use of the human-readable protocols with limited-resource devices such as IoT devices. This is advantageous because the disclosed methods and apparatus facilitate use of the desirable object notation data formats with IoT devices and/or any other device that has limited computing resources and/or communicates with many diverse devices.

While the extensions disclosed herein are well-suited for use with IoT devices, the extensions are not limited to use with and/or by IoT devices. Examples disclosed herein are described with reference to an extended JSON, which is referred to herein as xJSON for consistency. Alternatively, the extended JSON may be used with any other content type name and/or the extensions may be used with an extended version of any other protocol or standard. The methods and apparatus disclosed herein at not limited to extending JSON. Rather, the extensions may be used with any type of human-readable based protocol for storing and transmitting objects.

In JSON, objects are denoted by an array of key-value pairs delimited with opening and closing curly brackets. A key denotes a property of the object and the value identifies the value for that property. Keys and values are separated by a colon. For example, a person object in JSON may be stored in a file as:
{
"firstName": "John",
"lastName":"Smith",
"email":"john. smith@example. com",
"password":"secretPassword123)"
}
In the above example, firstName, lastName, email, and password are keys and John, Smith, john. smith@example. com, and secretPassword123 are values. The keys in the object may be referred to as names and may correlate with variables that store the values when the object is stored in an application (e.g., a person object in a JavaScript application). Thus, the JSON object provides a way to represent an object stored in binary or any other format in a human readable format.

The example extensions described herein include data packing, object serialization, and hashing/security.

As used herein, data packing refers to applying a compression algorithm to keys and/or values (e.g., compressing the keys and/or value using GNU Zip (gzip)). When a xJSON file is received, packed data in the xJSON file may be identified and decompressed.

As used herein, object serialization refers to converting keys and/or values to a binary value(s). In some examples, the binary value(s) are then converted to a text format (e.g., using Base64 binary-to-text encoding). When a xJSON file is received, serialized data in the xJSON file may be detected and deserialized/unmarshalled.

In some examples, hashing/security operations are performed by generating a hash for a value of a key-value pair and inserting the hash into the key. The hash can be used for validating the contents of the value by comparing the hash stored in the key with a hash generated for the value of the key-value pair. The hash may additionally or alternatively be used for searching for data contained in values. For example, a search parameter can be hashed and the hash for the search parameter can be compared with the hashes stored in keys to identify a match and, therefore, a value of a key-value pair that matches the search parameter. Additionally or alternatively, hashing/security may also include encrypting keys and/or values and replacing the unencrypted keys and/or values with the encrypted data. When a xJSON file is received, encrypted data in the xJSON file may be detected and decrypted.

In example methods and apparatus disclosed herein, in applying the disclosed extensions to JSON, xJSON capable devices insert a qualifier in a key and/or value when the key and/or the value have been generated and/or modified based on xJSON extensions. The qualifier indicates to other xJSON capable devices that the xJSON extension has been applied. For example, a key may be modified by adding brackets to the end of the key and inserting a qualifier (e.g., a qualifier indicating a particular extension that has been applied) in the brackets. For example, if an extension associated with the character "x" is applied to key-value pairs in the person object shown in the previous paragraph, the xJSON representation may be:
{
"firstName[x]":"John",
"lastName[x]":"Smith",
"email[x] ":"john. smith@example. com"
"password[x]":"secretPassword123)"
}
The qualifier may alternatively be inserted between brackets added to the value of the key-value pair (e.g., "firstName":"John[x]") and/or qualifier(s) may be added to both the key and the value (e.g., "firstName[x]":"John[y]", "firstName[x]": {x; "v" : "John"}). Alternatively, delimiters other than brackets may be used for separating the identifier from the key and/or value (e.g., curly braces, single quotation marks, quotation marks, asterisks).

For consistency the example disclosed herein are described with reference to xJSON identifiers inserted between brackets in the key of key-value pairs. However, this disclosure is not limited to a particular format for the insertion of the identifiers and any other format, including those described above, may be used.

The insertion of the identifier in the key name and/or value ensures that the xJSON representation can still be processed by a device that supports JSON but does not support xJSON (e.g., in some examples, using the xJSON techniques will not prevent devices that use JSON but do not support xJSON from parsing the xJSON file because the xJSON identifiers are inserted in a manner that is consistent with the JSON grammar). Accordingly, the use of xJSON will not cause devices that support JSON, but not xJSON, to fail during parsing of an xJSON file. Rather, these non-xJSON devices will continue to operate, but without an understanding of the extensions. Such an approach enhances the ability for xJSON capable devices to operate in an environment in which some devices do not support xJSON.

An additional advantage of inserting the identifier in the key as disclosed herein allows xJSON extensions to be applied on a selective basis. For example, an xJSON extension may be applied to an entire file, may be selectively applied to one or more objects in a file, or may be selectively applied to one or more keys-value pairs in a file. Thus, when the xJSON file is being processed, key-value pairs that include an xJSON identifier in the key can be processed according to the extension and key-value pairs that do not include an xJSON identifier in the key can be processed using standard JSON processing. Furthermore, different ones of the extensions can be applied to subsets of the key-value pairs in a file. For example, in the foregoing example: (a) "person" object, the firstName, lastName, and email key-value pairs may be processed to insert a hash value and an xJSON identifier for hashing in the corresponding keys; (b) the password key-value pair may be encrypted and hashed; and (c) an encryption identifier, a hash identifier, and a hash value may be inserted in the corresponding key. The invention is defined in the independent claims <NUM> and <NUM>.

<FIG> is a block diagram of an example environment <NUM> in which example methods and apparatus disclosed herein may be implemented to generate and/or parse xJSON and/or any other human-readable object notation data files. The example environment includes an example web service <NUM> to convey an example xJSON data <NUM> via an example network <NUM> to an example first device <NUM> and an example second device <NUM>. As used herein, the phrase "in communication," including variances thereof, encompasses direct communication and/or indirect communication through one or more intermediary components and does not require direct physical (e.g., wired) communication and/or constant communication, but rather additionally includes selective communication at periodic or aperiodic intervals, as well as one-time events.

In the illustrated example, the example web service <NUM>, the example first device <NUM>, and the example second device <NUM> exchange data using JSON data files. According to the illustrated example, the example web service <NUM> and the example first device <NUM> are xJSON capable in that they include an xJSON handler <NUM> to parse and/or generate files that are based on at least one of the extensions associated with xJSON disclosed herein. According to the illustrated example, the example second device <NUM> is not xJSON capable in that the example second device <NUM> may parse and/or generate JSON files but does not include the xJSON handler <NUM> for parsing and/or generating xJSON files with the extensions associated with xJSON disclosed herein. As disclosed herein, while the example second device <NUM> is not capable of using the extensions related to xJSON, the example xJSON data <NUM> of the illustrated example that is output by the example web service <NUM> and/or the example first device <NUM> may be successfully parsed (e.g., parsed without causing a parsing error).

In the illustrated example, the web service <NUM> is a server computer for serving information on the Internet. Alternatively, the web service <NUM> may be any type of device with which a device connected to the example network <NUM> may communicate. The example web service <NUM> sends the example xJSON data <NUM> to the example first device <NUM> and/or the example second device <NUM>. The example web service <NUM> may also receive xJSON data from the example first device <NUM> and/or JSON data from the example second device <NUM>. Alternatively, the example web service <NUM> may only be capable of receiving data (e.g., xJSON data and/or JSON data) or may only be able of sending data (e.g., the xJSON data <NUM> and/or JSON data).

The network <NUM> of the illustrated example of <FIG> is the Internet. Alternatively, the network <NUM> may be any type of and/or combination of a local area network, a wide area network, a wired network, a wireless network, a private network, and/or a public network. The example network <NUM> communicatively couples the example web service <NUM> with the example first device <NUM> and the example second device <NUM>.

The first device <NUM> of the illustrated example of <FIG> is an IoT device that includes the example xJSON handler <NUM> to parse and/or generate the example xJSON data <NUM>. For example, the first device <NUM> may be a network-enabled microprocessor controller. For example, the first device <NUM> may be the CC3100 SimpleLink™ Wi-Fi® and Internet-of-Things Solution for MCU Applications or the CC3200 SimpleLink™ Wi-Fi® and Internet-of-Things Solution, a Single-Chip Wireless MCU from Texas Instruments® and/or a device that includes the CC3100 or the CC3200. Alternatively, the first device <NUM> may be any other device in which it is desirable to use JSON data.

The second device <NUM> of the illustrated example of <FIG> may be any device in which it is desirable to use JSON data. The second device <NUM> is included in the example of <FIG> to illustrate that devices that support xJSON extensions (e.g., the example web service <NUM> and the example first device <NUM>) and devices that do not support xJSON extensions may be connected to the same network and may communicate with each other. For example, when xJSON extensions are implemented in a manner that does not run afoul of the JSON grammar, JSON files (e.g., the example xJSON data <NUM>) that include at least some key-value pairs that include xJSON extensions (e.g., xJSON files) can be parsed by devices that do not support xJSON without causing parsing errors. Likewise, devices that support xJSON extensions are able to process JSON files.

The example xJSON handler <NUM> parses and/or generates xJSON files (e.g., files that are generated according to the JSON protocol and include at least one key-value pair that includes one of the xJSON extensions disclosed herein such as the example xJSON data <NUM>). An example implementation of the xJSON handler <NUM> is described in further detail in conjunction with <FIG>. While <FIG> illustrates that the example web service <NUM> and the example first device <NUM> include the same xJSON handler <NUM>, in other examples, devices may include different xJSON handlers (e.g., the xJSON handler <NUM> of the example web service <NUM> may be implemented differently than the xJSON handler <NUM> of the example first device <NUM>).

Using the xJSON handler <NUM> enables a device to generate xJSON data and parse xJSON data (e.g., object notation data that includes the extensions disclosed herein). The xJSON handler <NUM> of the illustrated example facilitates the use of data representations that are not supported by existing object notation protocols. For example, the xJSON handler <NUM> may support the use of customized primitives (e.g., primitives that are well-suited for use with embedded devices such as IoT devices). For example, a binary typed literal may be input as "0bAAAA" or "0BAAAA" where "b" and "B" indicate that the value is a binary literal. In another example, a hexadecimal typed literal may be input as "0xAAAA" or 0XAAAA" where "x" and "X" indicate that the value is a hexadecimal literal. Hardware based literals may also be supported by the xJSON handler <NUM>. For example, an identifier may be added to a key and/or a value to indicate a literal of a volatile type, a literal for a hardware signal type (input, output, both), and a tri-state value for a signal object. In other words, the flexibility of using identifiers appended to, inserted in, replacing portions of keys and/or values, allows the xJSON handler <NUM> to indicate information about keys and/or values including indicating the state (e.g., encrypted, compressed, serialized) and/or the purpose of the value (e.g., a literal for a hardware signal type).

While the example environment <NUM> of <FIG> includes the example web service <NUM>, the example first device <NUM>, and the example second device <NUM>, any number and/or types of devices may be used. For example, an environment might include any combination of two devices and/or web services, three devices and/or web services, four devices and/or web services, hundreds of devices and/or web services.

<FIG> is a block diagram of an example implementation of the example xJSON handler <NUM> of <FIG>. The example xJSON handler <NUM> of <FIG> includes an example interface <NUM> to send and/or receive example object notation data <NUM> (e.g., the example xJSON data <NUM>), an example parser <NUM> to parse the example object notation data <NUM> to output example object data <NUM>, an example generator <NUM> to generate example object notation data <NUM> from example object data <NUM>, and an example JavaScript Interpreter <NUM>. While the xJSON handler <NUM> of <FIG> is described with reference to the example first device <NUM>, the xJSON handler <NUM> of <FIG> may be implemented in another device (e.g., the example web service <NUM>).

The example interface <NUM> of the illustrated example is a network interface <NUM> that sends and/or receives the object notation data <NUM> (e.g., the example xJSON data <NUM>) to and/or from the network <NUM> and/or from one or more other components of the device that includes a xJSON handler <NUM> (e.g., components of the example web service <NUM> and/or components of the example first device <NUM>). For example, the xJSON handler <NUM> of the example first device <NUM> may receive the example xJSON data <NUM> retrieved from the example web service <NUM>. The example interface <NUM> transmits the object notation data <NUM> received from the network <NUM> to the example parser <NUM>. The example interface <NUM> transmits the object notation data <NUM> received from the example generator <NUM> to a desired destination for the object notation data <NUM>. For example, the interface <NUM> for the xJSON handler <NUM> of the example first device <NUM> may transmit the example object notation data <NUM> generated by the example generator <NUM> to the example web service <NUM>.

The parser <NUM> of the illustrated example receives the object notation data <NUM> and parses the data to extract the objects represented by the object notation data <NUM>. The parser <NUM> transmits extracted object data <NUM> to the example JavaScript interpreter <NUM>. For example, returning to the example person object discussed above, the parser <NUM> retrieves the elements of the person object from the key-value pairs included in the xJSON data (e.g., the firstName, the lastName, the email, and the password) and builds a JavaScript person object that is transmitted to the JavaScript interpreter <NUM>. The example parser <NUM> includes functionality for parsing xJSON data that includes one or more of data packing, object serialization, and/or hashing/security extensions. An example implementation of the parser <NUM> is described in further detail in conjunction with the block diagram of <FIG>.

The example generator <NUM> of the illustrated example builds object notation data <NUM> (e.g., an xJSON file) file to represent object data <NUM> received from the JavaScript interpreter <NUM>. For example, the example generator <NUM> may build the example person object in xJSON based on a person object stored in the JavaScript interpreter. The object notation data <NUM> generated by the generator <NUM> is transmitted to the interface <NUM> for transmission to another device (e.g., the web service <NUM>). Alternatively, the xJSON handler <NUM> and/or a device that includes the xJSON handler <NUM> may store the object notation data <NUM> (e.g., for later transmission and/or processing). The example generator <NUM> is described in further detail in conjunction with the block diagram of <FIG>.

The JavaScript interpreter <NUM> of the illustrated example is a software run-time environment that operates according to the JavaScript programming language to execute JavaScript applications or any other JavaScript instructions. The example JavaScript interpreter <NUM> of the illustrated example stores object data <NUM> and/or <NUM> (e.g., the above-described person object). While the JavaScript interpreter <NUM> of the illustrated example uses JavaScript, the JavaScript interpreter <NUM> may alternatively be any other run-time environment that can receive objects output by the example parser <NUM> and/or transmit objects to the example generator <NUM>.

<FIG> is a block diagram of an example implementation of the example generator <NUM> of <FIG>. The example generator <NUM> of <FIG> includes an example data handler <NUM>, an example string processor <NUM>, an example hashing and encryption handler <NUM>, an example compression handler <NUM>, and an example serialization processor <NUM>.

The example data handler <NUM> receives object data <NUM> (e.g., the example object data <NUM> received from the example JavaScript interpreter <NUM>) and generates an object notation data <NUM> populated with xJSON key-value pairs representative of the object data <NUM>. For example, the example data handler <NUM> may provide an interface (e.g., an Application Programming Interface (API)) through which a request for generation of an xJSON file may be received. The example data handler <NUM> determines if the request indicates that an xJSON file is to be generated or if a JSON file that includes xJSON extensions is to be generated. For example, as described in detail herein, if the object notation data <NUM> does not need to be compatible with devices that do not support xJSON, the object notation data <NUM> output by the generator <NUM> may be formatted to be processed by an xJSON capable device (e.g., the quotation marks that surround keys and values according to standard JSON grammar can be excluded when the example parser <NUM> will parse the file and implicitly evaluate the data without the presence of the quotation marks). The example data handler <NUM> of the illustrated example records the content type for the xJSON file, creates a key-value pair <NUM> (a single key-value pair is discussed, but multiple key-value pairs may be used) for the object data <NUM> (e.g., by creating a key named for the variable of the object data <NUM> and creating a corresponding value for the value of the variable), and sends and the key-value pair <NUM> to the example string processor <NUM>.

The example string processor <NUM> of <FIG> determines if the content type for the object notation data <NUM> is to be xJSON or standard JSON. If the object notation data <NUM> is intended to be parsed by xJSON capable devices and non-xJSON capable devices, the string processor <NUM> inserts quotation marks around the keys and the values in the key-value pair <NUM>. If compatibility with non-xJSON capable devices was not desired, the string processor <NUM> does not insert the quotation marks as the strings of the example key-value pair <NUM> will be implicitly recognized by xJSON capable parsers (e.g., the example parser <NUM> of <FIG>). For example, the following example person object may be generated when non-xJSON compatibility is desired:
{
"firstName": "John",
"lastName": "Smith",
"email": "john. smith@example. com",
"password": "secretPassword123)"
}. Alternatively, the following example person object may be generated when non-xJSON compatibility is not desired and/or needed:
{
firstName: John,
lastName: Smith,
email: john. smith@example. com,
password: secretPassword123)
}.

The example string processor <NUM> outputs a processed key-value pair <NUM> to the hashing and example encryption handler <NUM>.

The example hashing and encryption handler <NUM> of <FIG> receives the processed key-value pair <NUM> and determines if hashing and/or encryption of the processed key-value pair <NUM> is requested. For example, the request to generate the object notation data <NUM> may identify one or more key-value pairs and/or objects for which hashing and/or encryption is requested. For example, if an object includes a username field and a password field, hashing may be requested for all fields but encryption may be requested for only the password field. Alternatively, the hashing and encryption handler <NUM> may automatically determine that hashing and/or encryption is desired (e.g., when a key-value pair is identified as sensitive data such as a password field).

When hashing and/or encryption are requested, the hashing and encryption handler <NUM> determines a desired cipher (e.g., an encryption cipher, a hashing cipher, a combination of an encryption cipher and a hashing cipher) to be used. For example, the request to perform hashing and/or encryption may identify a cipher and/or the example hashing and encryption handler <NUM> may use a default cipher.

To certify the authenticity of the processed key-value pair <NUM> to other devices, the hashing and encryption handler <NUM> of this example signs the processed key-value pair <NUM> using a private key of the content-owner (e.g., the owner of the data for which the xJSON file is being generated) to generate an encrypted and/or hashed key-value pair <NUM>. In such examples, the encrypted and/or hashed key-value pair <NUM> can be verified by others with access to the public key corresponding to the private key.

When the cipher includes encryption (e.g., as opposed to only including data signing), the example hashing and encryption handler <NUM> of <FIG> encrypts the encrypted and/or hashed key-value pair <NUM> for any key-value pairs for which encryption was requested. The example hashing and encryption handler <NUM> encrypts the encrypted and/or hashed key-value pair <NUM> using a public key corresponding to a private key that may be used for decrypting the encrypted and/or hashed key-value pair <NUM>. For example, the parser <NUM> of <FIG> and/or <NUM> may store a private key that may be used for decrypting data encrypted using a corresponding public key.

The example hashing and encryption handler <NUM> then hashes the encrypted and/or hashed key-value pair <NUM> (e.g., key-value pairs are hashed when hashing was requested). The example hashing and encryption handler <NUM> hashes the encrypted value for any encrypted data (as opposed to the original data prior to encryption).

The hashing and encryption handler <NUM> of the illustrated example inserts cipher keys data into the encrypted and/or hashed key-value pair <NUM> (e.g., inserts the data in an xJSON file) that is being generated. The cipher keys data identifies one or more keys that were used in encrypting the encrypted and/or hashed key-value pair <NUM>. For example, the cipher keys data may include an identifier for a certificate for which a public key was used for encrypting the encrypted and/or hashed key-value pair <NUM> to enable the example parser <NUM> to locate the corresponding private key for use in decrypting the encrypted and/or hashed key-value pair <NUM>. The cipher keys may additionally include an identifier for a certificate for which a private key was used for signing the data. Where multiple keys are used in a single xJSON file, each key may be identified with a sequential number in the cipher keys data. In addition to the identifier for the encryption key, the cipher keys data of the illustrated example also identifies the particular cipher algorithm used for the hashing and/or encryption and any parameters corresponding to the cipher algorithm.

In some examples, the hashing and encryption handler <NUM> also inserts the public key certificate(s) that were used for encrypting the encrypted and/or hashed key-value pair <NUM> and/or that may be used for validating the signing data in the encrypted and/or hashed key-value pair <NUM>.

The example hashing and encryption handler <NUM> of the example of <FIG> inserts in the corresponding keys of the encrypted and/or hashed key-value pair <NUM> an indication of the hashing and/or an indication of the encryption. For example, for a key that has its value hashed, the example hashing and encryption handler <NUM> inserts '[#HHHH]' in the key, where '#' is a hash identifier and `HHHH' is the value resulting from the hashing. The example hashing and encryption handler <NUM> inserts '[sX#HHHH]' in the key for the encrypted and/or hashed key-value pair <NUM>, where the 's' is a hash identifier, the 'X' is an index value of the key used for the signing and/or encryption where there are multiple keys, the '#' is a hash identifier, and `HHHH' is the value resulting from the hashing.

For example, the following is a person object before hashing and encryption:
{
"name": "John Smith",
"email": "john. smith@example. com",
"passwords": ["<NUM>", "my-most-secret-passphrase", "abcdefg"]
}
A hashed and encrypted person object that may be generated by the example hashing and encryption handler <NUM> of <FIG> for the person object above is:
<IMG>
<IMG>.

The example hashing and encryption handler <NUM> outputs the encrypted and/or hashed key-value pair <NUM> to the example compression handler <NUM>.

The compression handler <NUM> of the illustrated example determines if compression of the encrypted and/or hashed key-value pair <NUM> is requested. For example, the request to generate the xJSON file may identify one or more key-value pairs and/or objects for which compression is requested. Alternatively, the compression handler <NUM> may automatically determine that compression is desired when a key-value pair and/or an object exceeds a threshold size. When compression is requested, the compression handler <NUM> compresses (e.g., zips) the encrypted and/or hashed key-value pair <NUM> (e.g., the requested key-value pair and/or the requested object) to generate the example compressed key-value pair <NUM>. The example compression handler <NUM> of the illustrated example inserts a key for the compressed data in the example compressed key-value pair <NUM>. For example, the compression handler <NUM> may insert a generated key for the compressed data (e.g., a key such as _oX, where X is a number that increments for each set of generated data inserted in the generated xJSON file) to ensure that the key for each set of generated data is unique. The example compression handler <NUM> of <FIG> also inserts a compression identifier (e.g., [z]) in the example compressed key-value pair <NUM> to indicate to the example parser <NUM> that the compressed key-value pair <NUM> is compressed. In the illustrated example, the example compression handler <NUM> inserts a value for the key that identifies metadata for the compression and includes the compressed data. For example, the compression handler <NUM> may use gzip for compressing the encrypted and/or hashed key-value pair <NUM> and may insert metadata identifying the algorithm and the look-up table for the compression algorithm. For example, the result of compressing the person object may be:
{
"_o1[z]": {
'alg': `gzip',
'lut': '+srRõ'ós',
'o': xœËKÌMµÊÊÏÈS(ÎÍ,É°NÍMÌÌ
}
}.

The example compression handler <NUM> outputs the compressed key-value pair <NUM> to the example serialization processor <NUM>.

The example serialization processor <NUM> of the illustrated example determines if serialization of the example compressed key-value pair <NUM> is requested. For example, the request to generate an xJSON file may identify one or more key-value pairs and/or objects for which serialization is requested. When serialization is requested, the example serialization processor <NUM> serializes the requested compressed key-value pair (e.g., the requested key-value pair and/or the requested object) to generate an example serialized key-value pair <NUM>. The serialization processor <NUM> of the illustrated example inserts a key for the serialized key-value pair <NUM>. For example, the serialization processor <NUM> may insert a generated key for the serialized key-value pair <NUM> (e.g., _oX, where X is a number that increments for each set of generated data in the generated xJSON object notation data <NUM>) to ensure that the key for each set of generated data is unique. The example serialization processor <NUM> also inserts a serialization identifier (e.g., [b]) in the key to indicate to the example parser <NUM> that the serialized key-value pair is serialized. The example serialization processor <NUM> of <FIG> inserts the serialized data as the value for the key of the serialized key-value pair <NUM>. In the illustrated example, the example serialization processor <NUM> converts the binary data resulting from the serializing to ASCII text using Base64 conversion. For example, the result of serializing the person object may be:
{
"_o1[b]":"NjTigJxuYW114oCdOiDigJxKb2huIFNtaXRo4oCdLAOK4oCcZW1
haWzigJ06IOKAnGpvaG4uc21pdGhAZXhtYXBsZS5jb23igJ0NCg==
"
}.

The example serialization processor <NUM> of the illustrated example transmits the resulting serialized key-value pair <NUM> to the example data handler <NUM> for transmission to the destination for the object notation data <NUM> (e.g., to the example web server <NUM> via the example interface <NUM> and the example network <NUM>). For example, the object notation data 314ile may be transmitted via the example interface <NUM> to the example web service <NUM> for parsing by the example parser <NUM> in the xJSON handler <NUM> implemented in the example web service <NUM>. The example web service <NUM> may then process the data objects in accordance with the operation of the example web service <NUM>. Alternatively, the object notation data <NUM> may be transmitted to any other desired location. In some examples, the data handler <NUM> includes references to invoke functions in the object notation data <NUM>. For example, a function referenced as "func1(arg1,. argN)" will cause a parser (e.g., the example parser <NUM> to invoke the function identified as "func1" when parsing the object notation data. Alternatively, a function referenced as "@uri#func1(arg1,. argN)" will cause the parser (e.g., the example parser <NUM>) to cause "func1" to be invoked by the server listening at the location "uri.

<FIG> is a block diagram of an example implementation of the parser <NUM> of <FIG>. The example parser <NUM> of <FIG> includes a data handler <NUM>, a string processor <NUM>, a decryption handler <NUM>, a deserialization processor <NUM>, and a decompression handler <NUM>.

The data handler <NUM> of the example of <FIG> receives an example object notation data <NUM> (e.g., an xJSON file) file to be processed. The example data handler <NUM> extracts the key-value pairs and/or objects from the object notation data <NUM> and transmits them to the example string processor <NUM>. For example, the data handler <NUM> may extract one key-value pair at a time and transmit the key-value pair as the example key-value pair <NUM> for processing by the example string processor <NUM>, the example deserialization processor <NUM>, the example decompression handler <NUM>, and/or the example decryption handler <NUM>. Alternatively, the data handler <NUM> may extract multiple key-value pairs for processing by the example string processor <NUM>, the example deserialization processor <NUM>, and the example decompression handler <NUM>, and the example decryption handler <NUM>.

Following processing by one or more of the example string processor <NUM>, the example deserialization processor <NUM>, and the example decompression handler <NUM>, and the example decryption handler <NUM>, the example data handler <NUM> receives the data object(s) (e.g., the example decrypted pair <NUM>) and transmits example object data <NUM> containing the objects extracted from the example object notation data <NUM> to the example JavaScript interpreter <NUM>.

The example string processor <NUM> of <FIG> receives the example key-value pair(s) <NUM> extracted from the object notation data <NUM> (e.g., a xJSON file) by the data handler <NUM> and automatically determines if the example key-value pair <NUM> is an xJSON file or a JSON file based on the presence or lack of string literals (e.g., quotation marks surrounding the keys and values). According to the illustrated example, the string processor <NUM> determines that the example key-value pair <NUM> is associated with file is a JSON file when the string literals are present and determines that the example key-value pair <NUM> is an xJSON file when the string literals are not present. The example string processor <NUM> additionally removes the string literals (e.g., the quotation marks) when they are present to reduce the data size. The example string processor <NUM> transmits processed key-value pair(s) <NUM> to the example deserialization processor <NUM>.

The example deserialization processor <NUM> of <FIG> determines if the processed key-value pair(s) <NUM> include a serialization identifier (e.g., a key that has been modified to include an indication that serialization has been performed such as the letter "b" in brackets). When the example deserialization processor <NUM> determines that the serialization identifier is included in the example processed key-value pair <NUM>, the example deserialization processor <NUM> deserializes the example processed key-value pair <NUM>. For example, serialized data may be encoded in Base64 and the example serialization processor <NUM> will decode the Base64 representation to retrieve the original key-value pair(s). After performing any needed deserialization, the example deserialization handler <NUM> of the illustrated example transmits a deserialized key-value pair(s) <NUM> to the example decompression handler <NUM>.

The example decompression handler <NUM> determines if the example deserialized key-value pair(s) <NUM> include a compression identifier (e.g., a key that has been modified to include an indication that compression has been performed such as the letter "z" in brackets). When the example decompression handler <NUM> of this example determines that the compression identifier is included in a key of the example deserialized key-value pair <NUM>, the example decompression handler <NUM> decompresses the example deserialized key-value pair <NUM>. The example decompression handler <NUM> of the illustrated example retrieves the identity of the compression algorithm from metadata inserted into the value(s) of the example deserialized key-value pair <NUM> during compression by the example compression handler <NUM>. For example, the metadata may include an identity of the compression algorithm (e.g., gzip), parameters for use during the compression and/or decompression (e.g., a look up table). After performing any needed decompression, the example decompression handler <NUM> transmits a decompressed key-value pair(s) <NUM> to the example decryption handler <NUM>.

The decryption handler <NUM> of this example determines if the decompressed key-value pair(s) <NUM> includes an encryption identifier (e.g., a key that has been modified to include an indication that encryption has been performed such as the letter "s" in brackets). When the decryption handler <NUM> of the illustrated example determines that the encryption identifier is included in a key of the example decompressed key-value pair <NUM>, the decryption handler <NUM> decrypts the key-value pair. For example, the decryption handler <NUM> may have access to private keys installed on the device on which the xJSON handler <NUM> is implemented (e.g., the example first device <NUM>). The decryption handler <NUM> of the illustrated example may retrieve the private key corresponding to decompressed key-value pair <NUM> and use the private key for decrypting the decompressed key-value pair <NUM>. Alternatively, the decryption handler <NUM> may prompt a user to input a private key for performing the decryption.

The example decryption handler <NUM> of <FIG> determines the appropriate private key for the decryption by analyzing the keys field inserted into the decompressed key-value pair <NUM> and/or the example object notation data <NUM>. Alternatively, information identifying the keys used for encrypting and/or decrypting the decompressed key-value pair(s) <NUM> may be stored in any other location (e.g., information about keys used for encryption may be inserted in the key of an encrypted key-value pair). In some examples where multiple keys are used in the example object notation data <NUM>, the encryption identifier may include an identifier for the particular one of the keys used for encrypting (and similarly for decrypting) the decompressed key-value pair <NUM>. For example, as described above in conjunction with the hashing and encryption handler <NUM>, the encryption identifier may be "[sX#HHHH]" where X is an index value identifying one of the keys in the keys field inserted in the object notation data <NUM>.

After performing any needed decryption, the example decryption handler <NUM> of the illustrated example transmits an example decrypted key-value pair(s) <NUM> to the data handler <NUM> for transmission of the example object data <NUM> to the example JavaScript interpreter <NUM>.

While an example manner of implementing the generator <NUM> of <FIG> is illustrated in <FIG>, one or more of the elements, processes and/or devices illustrated in <FIG> may be combined, divided, re-arranged, omitted, eliminated and/or implemented in any other way. Further, the example data handler <NUM>, the example string processor <NUM>, the example hashing and encryption handler <NUM>, the example compression handler <NUM>, the example serialization processor <NUM>, and/or, more generally, the generator <NUM> of <FIG> and <FIG> may be implemented by hardware, software, firmware and/or any combination of hardware, software and/or firmware. Thus, for example, any of the example data handler <NUM>, the example string processor <NUM>, the example hashing and encryption handler <NUM>, the example compression handler <NUM>, and/or the example serialization processor <NUM> could be implemented by one or more analog or digital circuit(s), logic circuits, programmable processor(s), application specific integrated circuit(s) (ASIC(s)), programmable logic device(s) (PLD(s)) and/or field programmable logic device(s) (FPLD(s)). When reading any of the apparatus or system claims of this patent to cover a purely software and/or firmware implementation, at least one of the example data handler <NUM>, the example string processor <NUM>, the example hashing and encryption handler <NUM>, the example compression handler <NUM>, and/or the example serialization processor <NUM> is/are hereby expressly defined to include a tangible computer readable storage device or storage disk such as a memory, a digital versatile disk (DVD), a compact disk (CD), or a Blu-ray disk storing the software and/or firmware. Further still, the xJSON handler <NUM> of <FIG> and/or the generator <NUM> of <FIG> and/or <NUM> may include one or more elements, processes and/or devices in addition to, or instead of, those illustrated in <FIG>, and/or may include more than one of any or all of the illustrated elements, processes and devices.

Flowcharts representative of example machine readable instructions for implementing the example generator <NUM> are shown in <FIG>. In these examples, the machine readable instructions include program(s) for execution by a processor such as the processor <NUM> shown in the example processor platform(s) <NUM> discussed below in connection with <FIG>. The program(s) may be embodied in software stored on a tangible computer readable storage medium such as a CD-ROM, a floppy disk, a hard drive, a digital versatile disk (DVD), a Blu-ray disk, or a memory associated with the processor(s) <NUM>, but the entire program(s) and/or parts thereof could alternatively be executed by a device other than the processor(s) <NUM> and/or embodied in firmware or dedicated hardware. Further, although the example program(s) are described with reference to the flowcharts illustrated in <FIG>, many other methods of implementing the example generator <NUM> may alternatively be used. For example, the order of execution of the blocks may be changed, and/or some of the blocks described may be changed, eliminated, or combined.

As mentioned above, the example processes of <FIG> may be implemented using coded instructions (e.g., computer and/or machine readable instructions) stored on a tangible computer readable storage medium such as a hard disk drive, a flash memory, a read-only memory (ROM), a compact disk (CD), a digital versatile disk (DVD), a cache, a random-access memory (RAM) and/or any other storage device or storage disk in which information is stored for any duration (e.g., for extended time periods, permanently, for brief instances, for temporarily buffering, and/or for caching of the information). As used herein, the term tangible computer readable storage medium is expressly defined to include any type of computer readable storage device and/or storage disk and to exclude propagating signals and transmission media. As used herein, "tangible computer readable storage medium" and "tangible machine readable storage medium" are used interchangeably. Additionally or alternatively, the example processes of <FIG> may be implemented using coded instructions (e.g., computer and/or machine readable instructions) stored on a non-transitory computer and/or machine readable medium such as a hard disk drive, a flash memory, a read-only memory, a compact disk, a digital versatile disk, a cache, a random-access memory and/or any other storage device or storage disk in which information is stored for any duration (e.g., for extended time periods, permanently, for brief instances, for temporarily buffering, and/or for caching of the information). As used herein, the term non-transitory computer readable medium is expressly defined to include any type of computer readable storage device and/or storage disk and to exclude propagating signals and transmission media.

The example computer readable instructions of <FIG> begins when the example data handler <NUM> receives data and a request to generate object notation data (e.g., an xJSON file) (block <NUM>). For example, the example data handler <NUM> may receive a JavaScript object from the example JavaScript interpreter <NUM>. The example data handler <NUM> determines if xJSON output is requested (block <NUM>). For example, the request to generate the xJSON file may include an indication that an xJSON specific file is requested. An xJSON specific file is a file that does not need to support parsing by devices that do not support xJSON. For example, for files that support parsing by JSON the keys and values are surrounded by quotation marks and for xJSON files that do not need to support JSON the keys and values do not need to be surrounded by quotation marks to reduce the file size. When the request indicates that the output file is to be an xJSON file type, the example data handler <NUM> inserts a content type identifier indicating that the file is an xJSON file type (e.g., "Content-Type: application/xjson") (block <NUM>). When the request indicates that the output file is to be a JSON file type, the example data handler <NUM> inserts a content type identifier indicating that the file is a JSON file type (e.g., "Content-Type: application/json") (block <NUM>).

After the content type is set in block <NUM> or block <NUM>, the example data handler <NUM> selects a data object (e.g., selects a first data object, a first element of a data object, a next data object) (block <NUM>). For example, the example data handler <NUM> may select the firstName element of the example person object described above. The example data handler <NUM> then generates a key-value pair for the selected element (block <NUM>). For example, the example data handler <NUM> may create a key named "firstName" and a value containing the value for the firstName element to generate the JSON key-value pair: "firstName: John.

The example string processor <NUM> then determines if the content type was set to xJSON for the file (block <NUM>). If the content type was not set to xJSON (e.g., the output file is to support parsing by JSON parsers that do not support xJSON), the example string processor <NUM> inserts quotation marks around the key and the value in the generated key-value pair (block <NUM>).

After the string processor <NUM> inserts the quotation marks in block <NUM> or after the string processor <NUM> determines that the content type for the file is set to xJSON (block <NUM>), the example hashing and encryption handler <NUM> determines if the key-value pair is to be hashed and/or encrypted (block <NUM>). The example hashing and encryption handler <NUM> may determine that the key-value pair is to be hashed and/or encrypted when the request to generate the xJSON file indicates that the key-value pair is to be hashed and/or encrypted. Alternatively, the hashing and encryption handler <NUM> may automatically determine that data is to be encrypted when detecting that the key-value pair contains sensitive data (e.g., when the key-value pair is a password field). When the hashing and encryption handler <NUM> determines that the key-value pair is to be hashed and/or encrypted, the example hashing and encryption handler <NUM> hashes and/or encrypts the key-value value pair (block <NUM>). Example computer readable instructions for hashing and/or encrypting the key-value pair are described in conjunction with <FIG>.

After the example hashing and encryption handler <NUM> determines that hashing and encryption are not requested (block <NUM>) or the hashing and encryption handler hashes and/or encrypts the key-value pair (block <NUM>), the example compression handler <NUM> determines if the key-value pair is to be compressed (block <NUM>). The compression handler <NUM> may determine that the key-value pair is to be compressed when the request to generate the object notation data indicates that the key-value pair is to be compressed. Alternatively, the example compression handler <NUM> may determine that the key-value pair is to be compressed when the size of the value exceeds a threshold level. When the compression handler <NUM> determines that the key-value pair is to be compressed, the example compression handler <NUM> compresses the key-value value pair (block <NUM>). Example computer readable instructions for compressing the key-value pair are described in conjunction with <FIG>.

After the example compression handler <NUM> determines compression is not requested (block <NUM>) or the compression handler <NUM> compresses the key-value pair (block <NUM>), the example serialization processor <NUM> determines if the key-value pair is to be serialized (block <NUM>). The example serialization processor <NUM> may determine that the key-value pair is to be serialized when the request to generate the object notation data indicates that the key-value pair is to be serialized. When the serialization processor <NUM> determines that the key-value pair is to be serialized, the example serialization processor <NUM> serializes the key-value value pair (block <NUM>). An example process for serializing the key-value pair is described in conjunction with <FIG>.

After performing any requested hashing and/or encrypting (block <NUM>), compressing (block <NUM>), and serializing (block <NUM>), the example data handler <NUM> inserts the generated key-value pair in the object notation data (e.g., an xJSON file) (block <NUM>). The example data handler <NUM> determines if there are additional data objects and/or elements for which key-value pairs are to be generated (block <NUM>). When there are additional objects and/or elements for key-value pair generation, control returns to block <NUM> to process the next object and/or element. When there are no additional objects and/or elements for key-value pair generation the example computer readable instructions of <FIG> end.

<FIG> is a flowchart of example computer readable instructions to compress a key-value pair. The example computer readable instructions of <FIG> may be used for implementing block <NUM> of <FIG>. The example computer readable instructions of <FIG> begins when the example compression handler <NUM> determines a compression algorithm (block <NUM>). For example, a request to compress a key-value pair may specify a compression algorithm to be used. Alternatively, the example compression handler <NUM> may include a default compression algorithm (e.g., the gzip compression algorithm). The example compression handler <NUM> then compresses the key-value pair using the determined compression algorithm (block <NUM>). The example compression handler <NUM> then inserts a compression identifier in the key for the key-value pair (block <NUM>). For example, the compression identifier may be any indication that may indicate that the key-value pair is compressed (e.g., "[z]"). For example, a compressed key-value pair may include a key placeholder and the compression identifier (e.g., "_o1[z]" where the value following the "o" is an index that is incremented for each compressed value to ensure that each key remains unique). The example compression handler <NUM> then inserts metadata regarding the compression in the value for the key-value pair (block <NUM>). For example, the compression handler <NUM> may insert an identification of the algorithm used for compression (e.g., "alg: gzip") and parameters for the compression (e.g., a lookup table "lut: +srRõ'ós"). The example computer readable instructions of <FIG> then end. For example, control may return to block <NUM> of <FIG>.

<FIG> is a flowchart of example computer readable instructions that may be executed to serialize a key-value pair. The example computer readable instructions of <FIG> may be used for implementing block <NUM> of <FIG>. The example computer readable instructions of <FIG> begins when the example serialization processor <NUM> determines a serialized value for the value in the key-value pair (block <NUM>). For example, the serialization processor <NUM> may serialize the value of the key-value pair and perform a binary to text conversion (e.g., using Base64) to store the serialized data in the object notation data. The example serialization processor <NUM> then modifies the key of the key-value pair to insert a serialization identifier in the key (e.g., the example serialization processor <NUM> may insert "[b]" in the key). The example computer readable instructions of <FIG> then end. For example, control may return to block <NUM> of <FIG>.

<FIG> is a flowchart of example computer readable instructions to hash and/or encrypt a key-value pair. The example computer readable instructions of <FIG> may be used for implementing block <NUM> of <FIG>. The process of <FIG> begins when the example hashing and encryption handler <NUM> of the illustrated example determines a cipher and a key to be used (block <NUM>). For example a request to hash and/or encrypt may include an identification of a cipher and/or a key (e.g., a private key) that is to be used. Alternatively, the hashing and encryption handler <NUM> may use a default cipher and/or private key. The example hashing and encryption handler <NUM> then packs the string to be encrypted (block <NUM>). For example, the example hashing and encryption handler <NUM> packs the key-value pair by removing any quotation marks. The hashing and encryption handler <NUM> may perform any other packing to remove any other characters. The example hashing and encryption handler <NUM> then signs the key-value pair using the identified key (block <NUM>).

The example hashing and encryption handler <NUM> then determines if the cipher includes encryption (block <NUM>). For example, the cipher may be a cipher that only includes hashing or may be a cipher that includes hashing and encryption. When the cipher does not include encryption, control proceeds to block <NUM> for hashing of the key-value pair. When the cipher includes encryption, the hashing and encryption handler <NUM> encrypts the signed key-value pair (block <NUM>). The example hashing and encryption handler <NUM> then converts the encrypted value to a string for insertion in the xJSON file (block <NUM>). The example hashing and encryption handler <NUM> transfers the encrypted value to a string using Base64 encoding.

After encrypting the key-value pair (block <NUM>), the hashing and encryption handler <NUM> inserts an encryption identifier (e.g., "[s]") in the key of the key-value pair (block <NUM>). The example hashing and encryption handler <NUM> then inserts the metadata identifying the cipher in the xJSON file (block <NUM>). For example, the cipher metadata may be inserted in a key-value pair with key name "keys. " The example hashing and encryption handler <NUM> then determines if there are multiple ciphers in the keys metadata (block <NUM>). If there are multiple ciphers in the keys metadata, the example hashing and encryption handler <NUM> inserts a cipher identifier in the key of the encrypted key-value pair (block <NUM>). For example, the hashing and encryption handler <NUM> may insert an index corresponding to the cipher in the keys metadata (e.g., "[s2]" where the cipher is the second cipher in the keys metadata).

After the hashing and encryption handler <NUM> has determined that the cipher does not include encryption (block <NUM>), has determined that there are not multiple ciphers (block <NUM>), or has inserted the identifier of the cipher in the key (block <NUM>), the example hashing and encryption handler <NUM> determines a hash for the value of the key-value pair (block <NUM>). For example, the hash may be determined using a double Pearson hashing. The example hashing and encryption handler <NUM> inserts the value of the hash into the key for the key-value pair (block <NUM>). For example, the hash value may be inserted following a hashing identifier (e.g., the hashing identifier may be the hash symbol (#)). For example, the hash may be inserted as ("[#XXXX]" where XXXX is the hash value). A key for a value that is encrypted and hashed may be "[s#XXXX]" where a single cipher is present and "[s1#XXXX]" where there are multiple ciphers and the first cipher was used for the encryption.

The example computer readable instructions of <FIG> then end. For example, control may return to block <NUM> of <FIG>.

While an example manner of implementing the parser <NUM> of <FIG> is illustrated in <FIG>, one or more of the elements, processes and/or devices illustrated in <FIG> may be combined, divided, re-arranged, omitted, eliminated and/or implemented in any other way. Further, the example data handler <NUM>, the example string processor <NUM>, the example deserialization processor <NUM>, the example decompression handler <NUM>, the example decryption handler <NUM>, and/or, more generally, the parser <NUM> of <FIG> and <FIG> may be implemented by hardware, software, firmware and/or any combination of hardware, software and/or firmware. Thus, for example, any of the example data handler <NUM>, the example string processor <NUM>, the example deserialization processor <NUM>, the example decompression handler <NUM>, and/or the example decryption handler <NUM> could be implemented by one or more analog or digital circuit(s), logic circuits, programmable processor(s), application specific integrated circuit(s) (ASIC(s)), programmable logic device(s) (PLD(s)) and/or field programmable logic device(s) (FPLD(s)). When reading any of the apparatus or system claims of this patent to cover a purely software and/or firmware implementation, at least one of the example data handler <NUM>, the example string processor <NUM>, the example deserialization processor <NUM>, the example decompression handler <NUM>, and/or the example decryption handler <NUM> is/are hereby expressly defined to include a tangible computer readable storage device or storage disk such as a memory, a digital versatile disk (DVD), a compact disk (CD), or a Blu-ray disk storing the software and/or firmware. Further still, the xJSON handler <NUM> of <FIG> and/or the parser <NUM> of <FIG> and/or <NUM> may include one or more elements, processes and/or devices in addition to, or instead of, those illustrated in <FIG>, and/or may include more than one of any or all of the illustrated elements, processes and devices.

Flowcharts representative of example machine readable instructions for implementing the example parser <NUM> are shown in <FIG>. In these examples, the machine readable instructions include program(s) for execution by a processor such as the processor <NUM> shown in the example processor platform(s) <NUM> discussed below in connection with <FIG>. The program(s) may be embodied in software stored on a tangible computer readable storage medium such as a CD-ROM, a floppy disk, a hard drive, a digital versatile disk (DVD), a Blu-ray disk, or a memory associated with the processor(s) <NUM>, but the entire program(s) and/or parts thereof could alternatively be executed by a device other than the processor(s) <NUM> and/or embodied in firmware or dedicated hardware. Further, although the example program(s) are described with reference to the flowcharts illustrated in <FIG>, many other methods of implementing the example parser <NUM> may alternatively be used. For example, the order of execution of the blocks may be changed, and/or some of the blocks described may be changed, eliminated, or combined.

<FIG> is a flowchart of example computer readable instructions for the example parser <NUM> to parse object notation data (e.g., an xJSON file). The example computer readable instructions of <FIG> begin when the example data handler <NUM> receives object notation data (block <NUM>). For example the data handler <NUM> or another component of a device including the xJSON handler <NUM> may request data from another device that transmits data as xJSON data.

In some examples, the data handler <NUM> of the illustrated example requests only a portion of an available object notation data. For example, an example xJSON file might include <NUM>,<NUM> key value pairs, which would exhaust the memory of a low power device (e.g., and IoT device) attempting to parse the xJSON file. Accordingly, the example data handler <NUM> requests a desired portion (e.g., based on a request for retrieving data). For example, the data handler <NUM> may reference a particular portion of the object notation data using dot notation (e.g., "@exmaple. value1" would retrieve the key identified as value1 in the object id in the myobj. xjson file served by example. Thus, the example data handler <NUM> may retrieve a desired key(s) and/or object(s) of interest without the need to retrieve the entire object notation data. In an example implementation, an object may be referenced as "#object" where "object" is the name of the object, "@uri" where "uri" is the location from which the object notation data may be retrieved, and @uri#object. subobject where "subobject" identifies an object and/or key within the object "object" in the object notation data location at "uri.

The example data handler <NUM> selects the first key-value pair in the object notation data (block <NUM>). The example string processor <NUM> determines if the key-value pair includes string literals (e.g., quotation marks) (block <NUM>). When the key-value pair does not include string literals, the example string processor <NUM> determines that the received file is of the xJSON type and stores an indication that the file is an xJSON file (e.g., because JSON files include the quotation marks but xJSON files not need to include the quotation marks) (block <NUM>). Control then proceeds to block <NUM>.

When the string processor <NUM> determines that the key-value pair includes string literals, the string processor <NUM> stores the type as JSON (block <NUM>). For example, the file may be a JSON compatible file because it includes the string literals, but the file may include xJSON extensions. The example string processor <NUM> then removes the quotation marks from the key-value pair to reduce the size of the xJSON file (block <NUM>).

After the string processor <NUM> sets the type as xJSON (block <NUM>) or after the string processor <NUM> removes the quotation marks (block <NUM>), the example deserialization processor <NUM> determines if the key includes a serialization identifier (block <NUM>). When the key includes a serialization identifier, the example deserialization processor <NUM> deserializes/demarshalls the serialized data (block <NUM>).

When the key-value pair does not include a serialization identifier (block <NUM>) or after deserialization of the key-value pair (block <NUM>), the example decompression handler <NUM> determines if the key includes a compression identifier (block <NUM>). When the key includes a compression identifier, the example decompression handler <NUM> decompresses the key-value pair (block <NUM>). Example computer readable instructions that may be executed to decompress a key-value pair is described in conjunction with <FIG>.

When the key-value pair does not include a compression identifier identifier (block <NUM>) or after decompression of the key-value pair (block <NUM>), the example decryption handler <NUM> determines if the key of the key-value pair includes an encryption identifier (block <NUM>). When the key includes the encryption identifier, the decryption handler <NUM> decrypts the key-value pair (block <NUM>). Example computer readable instructions to decrypt the key-value pair are described in conjunction with <FIG>.

<FIG> is a flowchart of example computer readable instructions to decrypt and encrypted key-value pair. The example computer readable instructions may be used for implementing block <NUM> of <FIG>. The example computer readable instructions begin when the decryption handler <NUM> determines the cipher and key used during encryption of the key-value pair (block <NUM>). The example decryption handler <NUM> determines the cipher and public key from the keys metadata included in object notation data. In some examples, the decryption handler <NUM> selects the cipher and key from a list of keys using an index identified in the encryption handler.

The example decryption handler <NUM> then obtains the private key corresponding to the public key used during encryption (block <NUM>). For example, the private key may be stored in a set of private keys stored in the parser <NUM>. Alternatively, the decryption handler <NUM> may display a prompt requesting that a user provide a private key corresponding to an identified public key. The decryption handler <NUM> then decrypts the encrypted data using the private key and the identified cipher (block <NUM>). The example computer readable instructions of <FIG> then end. For example, control may return to block <NUM> of <FIG>.

<FIG> is a flowchart of example computer readable instructions to decompress a key-value pair. The example computer readable instructions of <FIG> may be used for implementing block <NUM> of <FIG>. The example computer readable instructions of <FIG> begin when the example decompression handler <NUM> determines a compression algorithm that was used for compressing the key-value pair (block <NUM>). For example, the decompression handler <NUM> determines the compression algorithm from the metadata inserted in value of the compressed key-value pair. The example decompression handler <NUM> then determines parameters for the compression (block <NUM>). For example, the decompression handler <NUM> may extract the parameters from metadata inserted in the value of the key-value pair. For example, the parameters may include a look-up table used by the compression algorithm. The example decompression handler <NUM> then decrypts the key-value pair using the identified compression algorithm and the parameters (block <NUM>). The example computer readable instructions of <FIG> then end. For example, control may return to block <NUM> of <FIG>.

<FIG> is a block diagram of an example processor platform <NUM> structured to execute the instructions of <FIG>, <FIG>, <FIG>, <FIG>, and/or <NUM> to implement the example first device <NUM> and/or the example web service <NUM> including the example interface <NUM>, the example parser <NUM> (e.g., including the example data handler <NUM>, the example string processor <NUM>, the example deserialization processor <NUM>, the example decompression handler <NUM>, and/or the example decryption handler <NUM>), the example generator <NUM> (e.g., including the example data handler <NUM>, the example string processor <NUM>, the example hashing and encryption handler <NUM>, the example compression handler <NUM>, and/or the example serialization processor <NUM>), and/or the example JavaScript interpreter <NUM>. The processor platform <NUM> can be, for example, a personal computer, a mobile device (e.g., a cell phone, a smart phone, a tablet such as an iPad™), a personal digital assistant (PDA), or any other type of computing device capable of processing images.

The example processor <NUM> of <FIG> may implement the components of the example xJSON handler <NUM> including the example parser <NUM>, the example generator <NUM>, and the example JavaScript interpreter <NUM> to parse and generate xJSON files and data.

The example interface circuit may implement the example interface <NUM> of the xJSON handler <NUM> of <FIG> and/or <NUM> to interface the processor platform <NUM> with the example network <NUM> of <FIG>.

The input device(s) <NUM> permit(s) a user to enter data and commands into the processor <NUM>.

The output devices <NUM> can be implemented, for example, by display devices (e.g., a light emitting diode (LED), an organic light emitting diode (OLED), a liquid crystal display, a cathode ray tube display (CRT), a touchscreen, a tactile output device, a light emitting diode (LED), a printer and/or speakers). The interface circuit <NUM> of the illustrated example, thus, typically includes a graphics driver card, a graphics driver chip or a graphics driver processor.

The interface circuit <NUM> of the illustrated example also includes a communication device such as a transmitter, a receiver, a transceiver, a modem and/or network interface card to facilitate exchange of data with external machines (e.g., computing devices of any kind) via a network <NUM> (e.g., an Ethernet connection, a digital subscriber line (DSL), a telephone line, coaxial cable, a cellular telephone system).

The coded instructions <NUM> of <FIG>, <FIG>, <FIG>, <FIG> and/or <NUM> may be stored in the mass storage device <NUM>, in the volatile memory <NUM>, in the non-volatile memory <NUM>, and/or on a removable tangible computer readable storage medium such as a CD or DVD.

Examples disclosed herein provide extensions to object notation data (e.g., human-readable object notation data such as JSON). In some examples, usage of data storage and communication bandwidth are reduced used by packing and/or compressing portions of the object notation data. In some examples, computer processing resource usage is reduced by allowing portions of object notation data to be packed/compressed, serialized, and/or compressed while allowing other portions of the object notation data not to be extended. For example, in a JSON file, using examples disclosed herein, a single key-value pair can be encrypted without requiring the entire JSON file to be encrypted, which reduces the amount of processing required to encrypt and decrypt the elements of the JSON file. In some examples, backward compatibility with devices that do not support the extension is provided by generating output (e.g., extended JSON files) that follow grammar rules set by prior object notation protocols. Accordingly, such extended files that meet the grammar rules of the prior protocol will not trigger errors when parsing the extended files with a device that does not support the extensions.

Claim 1:
Apparatus adapted to generate an object notation file comprising:
a data handler having a first input configured to receive object data and a first output configured to output an object notation key-value pair for the object data;
a string processor with a second input coupled to the first output and a second output configured to convey the object notation key-value pair without string literals; and
a hashing and encryption handler with a third input coupled to the second output and a third output configured to convey:
the key-value pair signed with a private key,
the key-value pair encrypted with a public key,
an indication that the encrypted key-value pair is encrypted in the key of the key-value pair,
the encrypted key-value pair with a hash value of the encrypted key-value pair inserted in the key, and
in the key an indication that the encrypted key-value pair is hashed.