Patent Description:
The growth of data networks such as the internet, and the spread of cellular communications technologies such as UMTS and LTE have led to an ever increasing importance of client-server model based solutions. Vast repositories of data are available in remote databases, which can be accessed by means of a suitable index value. However, the scope of modern data platforms is such that such indices themselves have a tendency to become increasingly unwieldy.

<FIG> presents a typical use case scenario for an index of this kind.

The terrestrial globe <NUM> is represented digitally in a database <NUM>. A user may use a browser <NUM> to interrogate this database <NUM> over the internet <NUM> via a website server <NUM> interfacing the database <NUM>. As shown, the user of the browser <NUM> browses the representation of the globe to select a specific point <NUM>, defined in terms of a latitude and a longitude represented by communications <NUM>. The European Patent Office Pschorrhöfe buildings, Bayerstr. <NUM>, <NUM> Munich, Germany, are located at latitude <NUM>, longitude <NUM>. A URL leading to a presentation of a map centred on these offices is provided for instance by the following string:
https://www. com/maps/@<NUM>,<NUM>,17z.

This basic URL comprises a domain https://www. com/maps/, followed by the latitude, the longitude and a zoom level.

The website server <NUM> may return this string via communications <NUM> to the user browser <NUM>. The user of browser <NUM> may then forward the string to the user of another browser <NUM> via communication <NUM>. The user of browser <NUM> may submit this string in communication <NUM> to the server <NUM>, which may then retrieve the corresponding representation from the database <NUM> and present this to the user browser <NUM> via communication <NUM>.

If instead of sharing the index via internet communication <NUM>, the user of browser <NUM> wishes to share the index via some other means, such as verbal or written communication, he may be obliged to memorise the index, or parts thereof, to read it out, or to copy it onto some other medium. Although only providing only basic functionality, the URL is already sufficiently long that any of these operations is likely to be problematic.

As a partial solution to this problem, Google provide a "share" option, whereby a link to a particular view may be more conveniently transmitted. This link takes the following form: https://goo. gl/maps/Q9HKJvZmG8N2.

This link in fact constitutes a token corresponding to a database entry in link database <NUM> containing the full URL string as presented above, e.g. https://www. com/maps/@<NUM>,<NUM>,17z. As such, the link does not contain the actual location data, and is only useable if the back-end database <NUM> capable of retrieving the real reference ("on-line lookup") is available. Similar approaches using an off-line look up, or a distributed database are also known in certain contexts.

<CIT> discloses methods for encoding latitude/longitude coordinates within a URL in a relatively compact form. The method includes converting latitude and longitude coordinates from floating-point numbers to non-negative integers. A set of base-N string representations are generated for the integers (N represents the number of characters in an implementation-defined character set being utilized). The latitude string and longitude string are then concatenated to yield a single output string. The output string is utilized as a geographic indicator with a URL.

<CIT> describes a method and system allowing two or more different coordinates for a geographic location to be expressed as a single string of characters. The single string of characters may include numerical digits or numbers, alphabetic characters or letters, punctuation or other typographical marks, other symbols, or a combination of two or more of these. A geographic location may refer to a physical place, the location of an object, or some other location.

In many contexts, these limitations may be unacceptable. According, it is desirable to provide mechanisms for encoding and decoding data in a compact manner without recourse to external databases and the like.

In accordance with the present invention in a first aspect there is provided a computer implemented method of forming a URI comprising the steps of.

In a further development of the first aspect the first common data type is a binary format.

In a further development of the first aspect, at the step of converting each value into a converted value, each converted value complies with a data structure corresponding to the semantic content of the value.

In a further development of the first aspect the data structure corresponds to an amplitude of the semantic content of the value.

In a further development of the first aspect the datastructure specifies one or more padding bits at specified positions therein, whereby the total length of the data structure is equal to an integral multiple of the number of bits required to encode each alphanumeric character.

In a further development of the first aspect a value comprises a validation key component, the method comprising the further step of removing the validation key component from the value before proceeding to the step of concatenation.

In a further development of the first aspect the method comprises the further step of defining a network resource corresponding to the URI.

According to the present invention in a second aspect there is provided a computer implemented method of resolving a URI, the method comprising the steps of:.

In a development of the second aspect the method comprises the further step of accessing a network resource defined by the URI.

According to the present invention in a third aspect there is provided program for a computer comprising instructions adapted to implement the steps of the methods described above when executed in the computer.

According to the present invention in a fourth aspect there is provided a system for forming a URI, the system comprising:.

According to the present invention in a fifth aspect there is provided a system for resolving a URI, the system comprising:.

The above and other advantages of the present invention will now be described with reference to the accompanying drawings, in which:.

<FIG> shows steps of a method of forming a URI. As shown in <FIG>, the method starts at step <NUM> before proceeding to step <NUM> of receiving a one or more values, each value having a respective format corresponding to the semantic content of that value.

Each of these values may be viewed as a variable, relating to a particular characteristic of, for example, a product, place, person or any other entity which may be described partially or wholly in terms of such variables. The URI may be one instance of a series of such URIs, where each URI defines corresponding values, although the numbers assigned to each value in a particular instance may vary from one to the next, as they relate to different entities, or the entities to which they relate evolve over time. As such, these URIs may constitute, or reflect, a digital twin of an entity. Some example of values include identity, date, period of time, 2D coordinates, areas, 3D coordinates, volumes,2D coordinates + period of Time (RDV data), health stamp, allergens and so on. Some of these possibilities, and possible combinations thereof are explored in the following examples. Many other possibilities of values, and combinations of values, will occur to the skilled person.

In the context of a map as described above, such values might comprise one or more of a Latitude, a Longitude, a zoom level, or a time stamp for example. It will be appreciated that each of these values has a semantic content that conditions how it should be interpreted- for example, a Latitude describes the North-South position on the globe, and as such is conventionally defined as an angle between <NUM> and <NUM> degrees. While many data formats may be used to represent a Latitude value, in particular varying in terms of precision, units and the like, they will all be constrained to some extent by the inherent requirements associated with this particular semantic context. By way of example, two values may be received- a Latitude value of <NUM> degrees and a longitude value of <NUM> degrees. These may conveniently be handles as hundredths of a degree, i.e. a latitude value of <NUM> and a longitude value of <NUM>.

On this basis, each value may have a respective format corresponding to the semantic content of the value.

The method next proceeds to step <NUM> at which each value is converted into a converted value in a first common data type.

This first common data type may be a binary representation, or any other convenient representation. On this basis the Latitude value of <NUM> degrees may be converted to the binary value <NUM>, and the longitude value of <NUM> degrees may be converted to the binary value <NUM>.

It will be appreciated that the maximum possible latitude value in the current example is <NUM>. Since <NUM><NUM>=<NUM>, <NUM> bits are needed to encode all possible values. On the other hand, any value less than <NUM> will require only <NUM> bits (or less). In order for all encoded values to have the same length in the present example, it is desirable to zero pad the value from the left so that regardless of the modulus of the value, it is encoded over <NUM> bits. On this basis the converted values would be <NUM>.

Similarly, it will be appreciated that the maximum possible longitude value in the current example is <NUM>. Since <NUM><NUM>=<NUM>, <NUM> bits are needed to encode all possible values. On the other hand, any value less than <NUM> will require only <NUM> bits (or less). In order for all encoded values to have the same length in the present example, it is desirable to zero pad the value from the left so that regardless of the modulus of the value, it is encoded over <NUM> bits. On this basis the converted values would be <NUM>.

Optionally, the, or each resulting binary value may be subjected to additional compression. For example, a lossless compression algorithm such as Run Length Encoding, Huffman coding, Prediction by partial mapping, Lempel-ziv compression and so on may be used.

As such, the step of converting each value into a converted value may be performed such that the converted value complies with a data structure corresponding to the semantic content of the value. In the present example a data structure has been defined where the received values are encoded in 31bits.

Furthermore, the range of possible values (amplitude) that must be encodable for a particular received value type may be considered in defining the data structure with regard to which encoding is performed. Accordingly, the data structure may be defined to correspond to amplitude of the semantic content of the value.

It will be appreciated that depending on the nature of the original values, the addition of padding in this manner may or may not be required.

The method next proceeds to step <NUM> at which the converted values are concatenated to obtain a concatenated value0010010110011100000010010000011.

It will be appreciated that in embodiments where only a single value is received, this step of concatenating need not be explicitly performed, since a single value is inherently concatenated with itself.

Where a plurality of values are received, the step of concatenating the converted values may be performed such that the concatenated value complies with a data structure corresponding to the semantic content of the value. In the present example a data structure has been defined where the latitude is succeeded by the longitude.

Optionally, the resulting binary value may be subjected to additional compression. For example, a lossless compression algorithm such as Run Length Encoding, Huffman coding, Prediction by partial mapping, Lempel-ziv compression and so on may be used.

The method next proceeds to step <NUM> at which the concatenated value is converted to an alphanumeric datatype.

The alphanumeric datatype may be any convenient alphanumeric datatype. By way of example, the following table represents the concatenated value converted to Hexadecimal format.

The method next proceeds to step <NUM> at which a root value is added at the beginning of the concatenated value.

The root value is an authority and or the domain of the path, and or prefix, in the sense of an URI definition, as defined for example in Request for Comments (RFC) <NUM>, published in August <NUM>, and finalized in RFC <NUM>. In accordance with the generic URI syntax, a URI complies with the following format:
URI = scheme:[//authority]path[?query][#fragment].

Accordingly, a root element of the URI defines the authority and/or the domain part of the path of the resource. In the following examples, the string http://xt. ag/# will be used as a generic placeholder for the root. The skilled person will appreciate that depending on implementation details any string may be used as appropriate. Where the root comprises a prefix, for example after a domain component, this may indicate additional processing steps, or be used as an indication of the semantic content of the URI, or of the identity of the datastructure used in its encoding.

On this basis, the datastructure might be defined as follows:.

Depending on the format of the values as they are received, it may be necessary to apply a value level padding to ensure that each value fills the indicated number of bits.

Optionally, the resulting alphanumeric value may be subjected to additional compression. For example, a lossless compression algorithm such as Run Length Encoding, Huffman coding, Prediction by partial mapping, Lempel-ziv compression and so on may be used.

It will be appreciated that in addition to adding the root value, other elements may be added to the URL in addition to the concatenated value. For example, one or more indicator values may be added to indicate the nature of the values encoded in the URI, details of the encoding scheme or data structure used, an origin of the URI, and so on.

The method then terminates at step <NUM>.

As discussed above, the range of possible values (amplitude) that must be encodable for a particular received value type may be considered in defining the data structure with regard to which encoding is performed. In accordance with certain embodiments, this may be performed in a further step of defining the data structure in response to the received plurality of values. As such, there may be provided a learning process, whereby a sequence of values are observed with a view to automatically assessing their amplitude.

As discussed above, the number of digits (in the case of a binary representation being used for the converted values, the digits in question will of course be bits) used in the representation of the converted values may be selected on the basis of the amplitude of the range of possible received values. This may be defined in a datastructure as described above, which may also define the manner in which converted values from respective received values should be concatenated, thereby defining the number of digits defining the concatenated value. Optionally, the datastructure may additionally specify one or more padding bits at specified positions in the data structure, so that the final concatenated value is a desired number of digits in length. By this means, the total length of the data structure may be defined for example to be equal to an integral multiple of the number of bits required to encode each alphanumeric character. Accordingly, if a base <NUM> representation is used, <NUM> bits are required to encode a single alphanumeric character. In the example presented above, the concatenated value comprised <NUM> bits, which is insufficient to exactly encode an integral number of alphanumeric characters. By padding the one or more of the converted values to a desired length, it can be ensured that the length of the concatenated value comprises a convenient number of bits. For example, by padding such that the concatenated value comprises <NUM> bits, the concatenated value can be defined to exactly convert into <NUM> alphanumeric characters.

Alternatively or additionally, the precision, units or granularity of each value may be selected so as to obtain values having an amplitude indicating a number of bits close to a convenient number of bits on a similar.

On this basis, encoding at step <NUM> may be performed as follows.

In the preceding example, base64 has been suggested as the basis of the generation of an alphanumeric value. Base64 is a group of similar binary-to-text encoding schemes that represent binary data in an ASCII string format by translating it into a radix-<NUM> representation.

A conventional Base64 conversion table is set out below.

On this basis, applying the example presented above, the alphanumeric coding might be performed as follows:.

While conversion of a binary value to an alphanumeric value may conveniently be achieved by this means, it may be noted that on this basis the final URI may comprise the values "+" and/or "/", corresponding to binary values <NUM> or <NUM>. The skilled person will appreciate that these symbols may have special meanings for example in a case where the URI is resolved as a URL, which may cause errors in the interpretation or processing of the URI.

Accordingly, the alphanumeric data type may be defined to omit the characters having a special meaning in the context corresponding to the root defined in the URI. For example, in a root corresponding to a URL, the symbols "/" and "+" may be replaced.

For example, a modified table along the following lines might be adopted:
The Base64 index table:.

As such, there is provided a modified, URL compatible, Base64 encoding scheme.

Another possibility is a Base62 conversion, for example as set out below, however it will be appreciated that while this avoids the issue of characters with a special meaning, it provides a less efficient conversion of bit values.

A still further possibility is a Base256 conversion, in which a single alphanumeric character encodes an <NUM> bit binary value. This has the advantage of further reducing the length of the final URI, but increases the possible number of special characters which must be managed.

Any of the above encoding schemes or any of the various alternatives that may occur to the skilled person may be adopted in this regard.

In some contexts, it may be conventional for the received values to comprise a validation key component, such as a check digit. In such contexts, this redundant data is provided so that the received values may be validated.

For example, European Patent Applications take the form <CIT>, where the digit following the decimal point is a redundant checkdigit. By applying a mathematical algorithm to any purported European Patent Application number including such a validation value, it can be determined whether the number is valid, or not. In a case where a number is entered manually for example, this mechanism can alert a user to an input error.

In some embodiments, where a received value incorporates such a validation key component, this redundant data may be discarded before proceeding to convert the value at step <NUM>.

In some contexts, part of a received value may comprise an offset, that is to say a value which remains the same in successive instances of a particular value. For example, if all instances of a value are based on the same root, this root may be considered as common to all identifiers in a domain, or to a particular prefix thereto, or all properties in a domain, or of a given prefix thereto. This is a concept similar to that of factorization. This might correspond to a geographical reference point, a group of codes sharing the same rood, a date expressed from a referent point in time.

In some embodiments, where a received value incorporates such an offset, this redundant data may be discarded before proceeding to convert the value at step <NUM>.

As discussed above, the method of <FIG> may be applied to any number of received values, including a single received value. It will be appreciated that the method of <FIG> may be applied either partially or wholly in parallel with additional instances of the method of <FIG>, or with other process flows.

For example, in a case where three data values are defined, corresponding to longitude, latitude, and a time stamp for instance, each of these values may be processed independently according to the method of <FIG>, or some of these values may be processed independently according to the method of <FIG> and other processed by some other means.

For example, the Latitude might be processed in accordance with the method of <FIG> as follows.

And the Longitude data added to the URI without other processing, e.g.
http://xt. ag/#/BLO1155.

Still further, Latitude and Longitude may be processed independently in accordance with the steps of <FIG> as illustrated below:.

and then combined in an additional concatenation step to form the final URI as follows: http://xt. ag/#BLOAsD.

It will be appreciated that many variations combining these approaches may be envisaged, and the degree of reduction of the length of the final URI achieved will depend on amplitude of the value types in question, and how closely these amplitudes correspond to the number of digits used to encode each alphanumeric character. Generally speaking, concatenating all values at step <NUM> before conversion to an alphanumeric form at step <NUM> may be expected to offer the most compact URI, but this need not always be the case.

Embodiments of the invention define a URI. Certain URI implementations, such as URLs, serve to identify a network resource. In some cases, a URI generated in accordance with the method of <FIG> may correspond to an existing network resource. In other cases, for example in the case of the scenario of <FIG>, a network resource may be defined as an additional step of the process of <FIG>. The definition of a network resource might comprise the generation of a database entry reference by the URI, such a map in the case of the example of <FIG>. The definition of a network resource may alternatively or additionally comprise the creation of a virtual machine, network storage space or any other network resource that might be designated by a URI, as well as the population of the resource with any appropriate data.

Embodiments of the invention define a URI. Such URIs may be subject to additional encoding for certain purposes. In particular, URIs may be encoded for graphical representation. Such graphical representation may comprise representation of the URI as a one, two or three dimensional bar code, or other machine readable format. An example of a two dimensional bar code implementation is the QR code.

As a general principle, the shorter the URL, the smaller the QR Code. Similarly, where an URL or URI is stored in a memory for example in an NFC device, the memory size required will be correspondingly smaller.

While <FIG> represents a method of encoding, it will be appreciated that a corresponding method of decoding may be defined.

<FIG> presents a method of resolving a URI. As shown, the method starts at step <NUM> before proceeding to step <NUM> at which a URI composed of a root value and a content part comprising one or more successive concatenated alphanumeric values is received.

The root value is split from the content part at step <NUM> on the basis of a defined data structure corresponding to the semantic content of the URI. Retaining the example described with respect to <FIG>, the received URI may be split as follows:.

The method next proceeds to step <NUM> at which the alphanumeric value comprised in the content part is converted into a converted value in a first data type on the basis of the defined data structure.

The data structure may be shared between the encoding side and the decoding side, for example by means of a transmission from one to the other, or via occasional or on-demand access to a common storage resource or otherwise. Alternatively, the datastructure may be defined independently on both sides, for example on the basis of user input, machine learning, and the like as discussed above.

On this basis, for the present example the alphanumeric value may be converted as follows:.

The method next proceeds to step <NUM> at which the converted value in a first data type is split on the basis of a defined data structure corresponding to the semantic content of the URI.

On this basis, for the present example the converted value may be split as follows:.

The method next proceeds to step <NUM> at which each converted value is further converted to a respective format corresponding to the semantic content of the respective value on the basis of the defined data structure.

On this basis, for the present example the split value may be further converted as follows:.

Accordingly, the original encoded values are recovered.

<FIG> presents a method of defining a data structure. The data structure obtained in accordance with the steps of <FIG> may be suitable for use as datastructure mentioned with reference to <FIG> or <FIG> above.

As shown in <FIG>, the method starts at step <NUM> before proceeding to step <NUM> at which a representation of one or more data values is received, where the datavalues have a sequence and where each represents semantic content. The method next proceeds to step <NUM> at which a respective amplitude of each value is determined. The amplitude of the value is the number of possible discrete forms that value might take. For example, as discussed above, a latitude value will lie between <NUM> and <NUM> degrees, so that if a <NUM>th of a degree precision is specified, there are <NUM> possible values. The amplitude may be determined by calculation from criteria of this kind provided by a user or in configuration files or the like, or may be inferred through a learning process from sample values.

The method then proceeds to step <NUM> at which a datastructure is defined reflecting the sequence and defining a binary space for each data value corresponding to the respective amplitude. As discussed above, the binary space may correspond to the minimum number of bits capable of encoding the amplitude, or may define a large number of bits for some or all values by specifying a padding to a certain number of bits so as to support an optimal encoding using a particular alphanumeric conversion. In particular, the datastructure may specify one or more padding bits at specified positions therein, such that total length of the data structure is equal to an integral multiple of the number of bits required to encode each alphanumeric character.

As a further example, a date may be expressed in seconds since the <NUM> January <NUM>. Coding a date in seconds requires <NUM> digits (for example, <NUM> corresponds to <NUM> September <NUM> at <NUM> :<NUM> : <NUM>). <NUM> decimal places of precision (i.e. thousandths of a second) require <NUM> digits, corresponding to <NUM> bits.

If in a given data structure 16bits are required for a representation of Longitude and <NUM> bits are required for a representation of Latitude in line with the amplitude considerations presented above, the addition of <NUM> Bits for a time stamp brings the total size of the data structure to <NUM> bits. <NUM> is divisible by six, making Base <NUM> a convenient choice, by means of which the final concatenated, converted value will comprise <NUM> characters.

The method may comprise an optional further step of specifying a root for addition to a URI conforming to the data structure.

The foregoing examples have been presented in the context of geographic data, specifically latitude and longitude data. It will be appreciated that the present invention is not restricted to any particular data type. By way of additional illustration, a number of further implementations in other areas of activity will now be presented.

An example of an entity which may be reflected in values processed in accordance with embodiments as described above comprises trade goods. Such goods may be identified by trade item identification numbers (GTINs).

In a further example, values relating to trade item identification numbers (GTINs)in the Food industry on packaging will now be considered.

In the present example, three data values are used in each URI:.

For the purposes of this example, the following numbers may be received for these values respectively at step <NUM> as discussed above.

As a basis for comparison, the conventional URI representation of this data would be as follows : http://xt. ag/#/gtin/<NUM>/lot/<NUM>?exp=<NUM>.

In accordance for example with the method of <FIG>, a data structure for these values may be defined as follows:.

The amplitude of the GTIN value is determined on the basis that the last digit is a validation key that may be discarded without reducing the data content of the value.

In accordance with the method of <FIG>, at step <NUM> the values received at step <NUM> are converted to a common data type (in this instance, binary), as follows:.

In accordance with the data structure presented above, these values are padded to arrive at the following converted values.

At step <NUM> these values are concatenated, as dictated by the data structure as presented above, to obtain the following concatenated value:
<NUM><NUM>.

At step <NUM> this concatenated value is converted to an alphanumeric format. By way of example, a modified Base64 encoding as presented above is used:
BGzk8YdhOMwS1fWB.

Finally, at step <NUM> the root value http://xt. ag/#/g2 is added to obtain the final URI http://xt. ag/#g2BGzk8YdhOMwS1fWB.

This may be compared once more with the conventional coding
http://xt. ag/#gtin/<NUM>/lot/<NUM> ?exp=<NUM>.

For the purposes of this example, the following URI is received for these values respectively at step <NUM> as discussed above. ag/#g2BGzk8YdhOMwS1fWB.

At step <NUM> the root value http://xt. ag/#g2 is split out to leave
BGzk8YdhOMwS1fWB.

In certain embodiments, the recognition of the root value may dictate the data structure (e.g. as presented above) to be used in the remaining steps of the resolution.

At step <NUM> the content part BGzk8YdhOMwS1fWB is converted from its alphanumeric format (in this case Base64) to the common format (in this case binary) to obtain the converted content part
<NUM><NUM>.

At step <NUM> this converted content part is split in accordance with the data structure (as presented above with respect to the encoding phase) to obtain the three content values:.

At step <NUM> these values are then converted to their native (in this case decimal) formats:.

Finally, and optionally, further processing may be performed to improve the usability of the data. For example, the validation key of the GTIN may be calculated and reinstated to give:
GTIN <NUM>.

Similarly, the date format may be converted to a more convenient format for the human user:
Exp: 14th of February <NUM>.

In a further example, values relating to trade item identification numbers (GTINs) in combination with other data in the Cosmetics industry will be considered. In particular, the GTIN may be combined at the cash desk or/and at marketing content delivery with time and location data, to fight against grey market.

In the present example, four data values are used in each URI:.

In accordance with the method of <FIG>, at step <NUM> the values received at step <NUM> are converted to a common data type (in this instance, binary), as follows:
As a preprocessing step, the Latitude and Longitude values may be converted to integers and expressed as offsets with respect to a median value, i.e..

At step <NUM> this concatenated value is converted to an alphanumeric format. By way of example, a modified Base64 encoding as presented above is used:.

This may be compared once more with the conventional coding
http://xt. ag/#gtin/<NUM>?lat=<NUM>&lon=<NUM>&tms=<NUM>-<NUM>-<NUM>+17_08_09.

It will be appreciated that subsets of the original data may be processed separately as discussed above. Furthermore, in some cases it may be desirable to obtain a plurality of separate URIs encoding different subsets of the original values, for example
Subsets, <NUM> parts :.

A Value may encode an indication of the presence of an allergen.

For example, the following are common allergens.

On this basis, a structured code might take the form of a binary sequence, <NUM>, with a <NUM> indicating the presence of a particular allergen, and a <NUM> indicating its absence in a particular foodstuff. 00100111011010may be taken as the received value in certain embodiments. This value may be converted to the common data format at step <NUM>, where in the case the common data format is a binary format, this may mean the value is unchanged, or may nevertheless require padding as discussed above. The value may then be concatenated with other values as required (an in a case where no other data are specified in the relevant data structure, the data may once again be unchanged). The concatenated value may then be converted to an alphanumeric value, for example on the basis of the modified Base64 encoding as presented above, or otherwise, and combined with a root value.

For example, if <NUM> is padded to <NUM> bits, the resulting Base64 representation would be "EwjrMXb"and the final URI http://xt. ag/#p2ABABh".

In a case with <NUM> allergens and <NUM> trace components, which may be represented as a <NUM> bit value. For example, a representation of the presence in a product of Cereals containing gluten, Fish, Mustard, traces of Eggs, might take the form:
<NUM> (padded to <NUM> bits, zeros to the left)
Which converts to ABABh in Base64.

Giving http://xt. aq/qtin/<NUM>/?alq=ABABh as a URI, where the GTIN is included as part of the root. The GTIN may be reduced to327016039899 with the validation key removed.

Alternatively, the GTIN may be taken as a received value to be processed in accordance with an embodiment in parallel with the processing of the allergen representation. On this basis we obtain a converted GTIN value of <NUM> (padded to <NUM> bits, zeros to the left), giving EwjrMXb in Base <NUM>. In accordance with this embodiment, the two resulting alphanumeric values may be concatenated together with the root to obtain the URI as follows: http://xt. ag/#EwjrMXbABABh where A is required. It will be appreciated that any number of values may be compiled in a URI in this manner, of which some or all may have been processed in accordance with steps of <FIG>, and others optionally may have been exposed to only some, or none of the steps of <FIG>.

The densest result is obtained by concatenating both values in the common format, e.g. binary. In other words, both the GTIN and the allergen representation are processed together as received values in the method of <FIG>. On this basis, the data structure defines a total of <NUM>+<NUM> = <NUM> Bits which in Base <NUM> encodes <NUM> characters. Accordingly, in accordance with an embodiment we obtain http://xt. ag/#AAJhHWYu3ABhwhere AA is optional.

A network resource might then be defined so as to be accessible with this URI which might provide a human readable description of the allergens in question, and any other guidance or advice that may be appropriate.

<FIG> shows a system according to an embodiment. As shown, there is provided asystem 600for forming a URI. As shown, the system comprises an interface <NUM> for receiving a one or more of values, e.g. from server <NUM> via the internet <NUM>, and a processor <NUM> adapted to convert each value into a converted value in a first common data type. The processor <NUM> is further adapted to concatenate the converted values to obtain a concatenated value to convert the concatenated value to an alphanumeric datatype, and a processor adapted to adding a root value at the beginning of the concatenated value.

As shown, the system comprises an optional data storage <NUM> containing a data structure corresponding to the semantic content of the value. In accordance with certain embodiments as described above, the sequence in which converted values are concatenated, the number of bits to which each value must be padded, and other necessary information is provided in this data structure. <FIG> shows a system according to an embodiment. As shown, there is provided asystem <NUM> for resolving a URI. As shown, the system comprises an interface <NUM> for receiving an root value and one or more successive concatenated alphanumeric values, e.g. from server <NUM> via the internet <NUM>, and a processor <NUM> to split the root value and each concatenated value on the basis of a defined data structure corresponding to the semantic content of the URI, to convert each alphanumeric value into a converted value in a first common data type on the basis the defined data structure, and to convert each converted value to a respective format corresponding to the semantic content of the value on the basis of the defined data structure.

As shown, the system comprises an optional data storage <NUM> containing the data structure.

The preceding embodiments relate to the generation of a complete URI, but it will be appreciated that in some cases it may be desirable not to proceed as far as the step of adding the root or authority value.

On this basis, there may be provided a method of forming a data string, which may constitute the hierarchical part of a URI, comprising the steps of:.

Each said value may have a respective format corresponding to the semantic content of said value. The first common data type may be a binary format. At the step of converting each value into a converted value, each converted value may comply with a data structure corresponding to the semantic content of the value. The data structure may correspond to an amplitude of the semantic content of the value.

The datastructure may specify one or more padding bits at specified positions, whereby the total length of the data structure is equal to an integral multiple of the number of bits required to encode each said alphanumeric character.

URIs such as URLs often contain data, which may be found in, or otherwise be relevant to the resource to which the URL relates. In order to provide the same information in a compact URI, the individual data components are converted to a common format such as a binary format, concatenated and the resulting value converted to an alphanumeric format, for example using a base64 encoding. These steps may be performed on the basis of a datastructure defining the concatenation sequence and the dataspace to be filled by each value after conversion to the common format. Corresponding methods for decoding URIs and compiling a datastructure are disclosed.

It will be appreciated that the system of <FIG> or <FIG> or any equivalent functional grouping may further be adapted to implement the functions corresponding to any combination of the method steps described above with reference to any of <FIG>.

The disclosed methods can take form of an entirely hardware embodiment (e.g. FPGA), an entirely software embodiment (for example to control a system according to the invention) or an embodiment containing both hardware and software elements. Software embodiments include but are not limited to firmware, resident software, microcode, etc. The invention can take the form of a computer program product accessible from a computer-usable or computer-readable medium providing program code for use by or in connection with a computer or an instruction execution system. A computer-usable or computer-readable can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. The medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium.

These methods and processes may be implemented by means of computer-application programs or services, an application-programming interface (API), a library, and/or other computer-program product, or any combination of such entities.

Claim 1:
A computer implemented method of forming a URI, said method comprising the steps of
receiving (<NUM>) one or more values, each said value having a respective format corresponding to the semantic content of said value,
converting (<NUM>) each said value into a converted value in a first common data type,
concatenating (<NUM>) said converted values to obtain a concatenated value,
converting (<NUM>) said concatenated value to an alphanumeric datatype, and
adding (<NUM>) a root value at the beginning of said converted concatenated value.