■1 Ubiquitous ID Architecture

Ubiquitous ID Center aims to realize the next generation information distribution infrastructure based on ubiquitous ID architecture. Ubiquitous ID architecture is a wide-area distributed information service architecture for identifying objects and places in the real world by ucodes (ubiquitous codes) and then retrieving information related to them.

 

 

●1.1 Ubiquitous Computing

 

The background of ubiquitous ID is "Ubiquitous Computing" that is a new paradigm of information communication technology. In ubiquitous computing environment, small computers and sensors are embedded in various objects and places in our surroundings, and they communicate with each other and process information in a coordinated manner to offer useful services to humans such as performing environment control and offering information (Figure 1).

 

Figure 1: Ubiquitous Computing Image

 

In realizing ubiquitous computing as described above, the most important concept is context awareness. This means that many computers and sensors embedded in our surroundings recognize the real world situations so that they use the understanding to offer advanced information services and to perform environment control.
Here, the easiest-to-understand "context" of the situation in the real world is what the object in front of us is and what our current location is, for example. If computers can automatically recognize such context, more convenient services can be offered to users.
In order to realize such context-awareness, it is necessary to recognize objects and places reliably. With current technology, the surest and easiest method of recognizing objects and places is to assign a number (ID: Identifier) to the target which you want to automatically recognize, store the ID in a medium from which the ID can be easily and automatically recognized by a computer, and attach the medium to the object or place. For example, the practical methods are to print the ID as a bar code so it can be read automatically with a scanner, or to store the ID in an electronic tag typified by RFID (Radio Frequency Identification) tags so it can automatically be read via radio wave.

 

 

●1.2 Ubiquitous ID Architecture Function Configuration

 

Ubiquitous ID architecture is a wide-area distributed architecture for retrieving information and services from objects and places in the real world that are identified by ucodes.
Ubiquitous ID architecture has two assumptions. The first assumption is that various objects and places in the real world can be identified by numbers called ucode. To recognize this ucode automatically, bar codes, electronic tags, sensors, etc. (these are called ucode tags) where this ucode is stored are embedded in objects and places to which ucodes are assigned.
The second assumption is that of always available network environment, i.e., ubiquitous networks of the 21st century. Of course, since there are places where an excellent digital communication environment cannot be established in the real world, the option to operate in such an environment has also been prepared.
Figure 2 illustrates the ubiquitous ID architecture components. Ubiquitous ID architecture has five components of (1) ucode, (2) ucode tag, (3) ubiquitous communicator, (4) ucode resolution server and (5) ucode information server.

 

Figure 2: Ubiquitous ID Architecture Components

 

(1) ucode: Number which can be issued by anyone, anytime, and for anything
A ucode is a number to identify objects and places in the real world. ucodes simply function only as identification numbers in ubiquitous ID architecture. In other words, attributes of objects and places to be identified are not guaranteed to be described in the ucode number itself. Since some users may want to encode the attributes of the identification target in the ucode itself, it is not prohibited to do so.

(2) ucode Tag: Tag Agnostic
ucodes tags are media to store ucodes. Ubiquitous ID architecture is tag agnostic. Many types of tags can be used as ucode tags such as print tags including bar codes and two dimensional bar codes, passive RFID electronic tags without battery, and tags with batteries which actively send ID to readers including radio wave beacons (markers) and infrared ray beacons (markers), and active RFID, etc.

 

(3) Ubiquitous Communicator: A bridge between ucode and the associated information
Ubiquitous Communicator is a terminal for obtaining ucodes from ucode tags. It retrieves information related to the obtained ucodes and provides services to the user.

 

(4) ucode Resolution Server: Wide-area distributed database to retrieve the information from ucodes
The ucode resolution server is a wide-area distributed database server that manages the corresponding relationship between ucodes and the servers (ucode information servers) that provide information, content and services related to the ucodes. When a ubiquitous communicator makes an inquiry to the ucode resolution server about a ucode, the ucode resolution server returns the address of the server providing information and services related to the ucode. The ucode resolution server manages the association of the ucode with its content. In other words, it is one of the key components of the ubiquitous ID architecture which is the bridge between the "real world" consisting of objects and places to which ucodes are assigned and the "virtual world" consisting of information and services.
With a search engine, you need keywords to retrieve information about the objects and places in front of you. With the ucode resolution server, retrieving information on objects and places is possible if their ucodes alone can be obtained even when you don't know anything (clues) about the object or place you would like to inquire about.

 

(5) ucode Information Server: Provider of content and service
The ucode information server provides the information and services on a ucode, and can be reached via the ucode resolution server.

 

 

●1.3 ucode system

 

ucode is an identification number which can be issued by anyone anytime for anything. ucodes can be issued for content and information which do not exist in the real world and for more abstract concepts as well as tangible objects and places in the real world. The ucode system is a 128 bit fixed length (2¹²⁸ = 340,282,366,920,938,463,463,374,607,431,768,211,456 ≒ 3.4×10³⁸) identifier system. A mechanism to extend the code length in units of 128 bits has been prepared to meet the future demands so codes longer than 128 bits can be defined.
When a ucode is assigned to an object or place in the real world, the ucode is stored in a ucode tag such as a bar code, a two dimensional optical code, or an RFID tag.
ucode is simply an identification number. There is no relationship between the number and the attribute and the meaning of the target to which the ucode was assigned. ubiquitous ID architecture stores such information as attributes and meaning in databases. The attribute and the meaning can be retrieved from the databases by using the ucode as a key.
Since ucode is an identification number, it is guaranteed that the uniqueness of issued ucodes is maintained systematically. In other words, multiple targets with the same ucodes assigned shall never exist. Moreover, when the target of an issued ucode vanishes, the ucode is also destructed. The same ucode shall never be reused later. ucodes attached to vanished subjects are no longer used identification numbers. Therefore, the uniqueness of a ucode is guaranteed both in space and over time.

 

1.3.1 ucode Management Structure
In order to make the management (including issue) of ucode easy, a structure consisting of management fields and allocation units illustrated in Figure 3 and 4 are defined. However, these are simply a structure for management. The ucode structure does not have a relationship with the attributes and the meaning of the target to which ucode is assigned.

 

Figure 3: ucode (128-bit basic length) Structure

 

Figure 4: Defined CC Value and Bit Boundary Between the SLDC and IC

 

ucode consists of five fields called Version, Top Level Domain Code (TLDC), Class Code (CC), Domain Code (DC), and Identification Code (IC).

● Version
The version is the version number of the ucode standard. The current version is "0000" (four bits in binary representation).

 

● Top Level Domain Code (TLDC)
ucode space is managed by dividing it into subspaces called "Domains." In other words, a domain is a subspace, and is the management unit of ucode space. A domain consists of two levels. The upper level domain is called Top Level Domain (TLD). TLD has a fixed length of 108 bits. Top level domain code (TLDC) is the identification number for TLD.

 

● Class Code
ucodes where the first bit of the class code (CC) is 1 are 128 bits in length. In this case, the low 3 bits of the CC indicate the boundary for the second level domain code and the identification code. A ucode whose first bit of CC is 0 is an extended code that consists of 256 bits or more.

 

● Second Level Domain Code
The second level domain is one level below TLD and is simply called a domain usually. The domain space has 6 different sizes ranging from 16 bits to 96 bits (multiple of 16 bits), and these are called Class A to Class F domains according to the size of the space. Second level domain code (SLDC) identifies each domain. When the bit length of SLDC is added to the bit length of the IC, it is always 104 bits (fixed).

 

● Identification Code
Identification code is an identification number itself in each domain.

 

1.3.2 Features of ucode
Compared to existing various code systems assigned to objects, ucode has the following advantages.

1. ucode is a code to identify individual objects, not to display product types like existing product code.
   Product codes such as EAN, UCC, and JAN identity the type of product from each vendor. Therefore, the same product code can be assigned to two packages of the same products. However, for ucode, different numbers are assigned to individual packages even if they are the same product.
2. ucode can be allocated to places, contents, and concepts as well as tangible objects.
   ucode is the only code system that can identify objects, places, and content universally.
3. ucode does not depend on application fields and business types.
   ucode is not a code system to be used only in specific industries, for example, logistics. ucode is a code system that can be used for various targets such as electric products, food, places, and music content irrespective of applications and the business types. This is because ucode aims only to identify individual items as objects and places only, and it is a simple numbering system without any meaning on the target in itself at all. Therefore, ucode is very effective especially for services and item management across industries and applications as well as for services that manage places and objects in the same system.
4. ucodes do not contain meaning and are simple numbers.
   The basic architecture stores information on the attribute and meaning of objects and places on a server in a network. This approach is effective especially for applications where the attribute and meaning of the objects and places to which ucodes are assigned change from moment to moment.
   Take a guardrail on a road, for example. Guardrails are products produced in a factory until they are delivered to a construction site. When they are installed at the side of a road, they can become parts of the place, components of a scene. After years of use, they are removed. Until they are destroyed, they are industrial waste. In this manner, even when the meaning (product/place/waste) changes from moment to moment according to the life cycle of a product, the ucode can continue to identify the item.
5. ucode is tag agnostic for storage purposes.
   ucodes can be stored in every type of tag such as bar codes, two dimensional bar codes, RFID and active tags. Therefore, the optimal tag according to the application and usage environment can be selected to store a ucode.
6. ucode is secure.
   Ubiquitous ID architecture, the application framework for handling ucodes, has incorporated eTRON architecture which is the ubiquitous security framework. Therefore, strong security and privacy information protection can be achieved.

 

●1.4 ucode Tag

 

A ucode tag is the media for storing ucodes.
The ubiquitous ID architecture is tag agnostic. A wide variety of tags can be used as ucode tags such as print tags including bar codes and two dimensional codes as well as electronic tags typified by RFID and smart cards. This results from the fact that the optimal tag for storing a ucode differs depending on the application and usage environment.

 

● Price / Cost consideration
● Readability near metal surface
● Readability near water-rich objects
● Readability over over long (or short) distance
● Required security level

 

1.4.1 ucode Tag Certification System
Ubiquitous ID Center classifies various ucode tags from two viewpoints. One is the communication method to retrieve ucode from tags and the other is security levels for the storage method of ucodes and ucode retrieval method. The former classification is called "Interface Category" (Table 1) and the latter is called "Security Class" (Table 2).

 

Table 1: Classification of ucode tags by interface category

 

Table 2: Classification of ucode tags by security class

 

Ubiquitous ID Center certifies ucode tags in order to establish the infrastructure for using ucodes. The certification of ucode tags is a procedure to confirm there are no problems with using a certain tag as a ucode tag. A tag certified by this procedure is called a "Certified ucode Tag." As of December 2009, there are 37 kinds of certified tags.
Certification criteria have been established for each interface category of ucode tags to certify ucode tags. The criteria are released as a set of specification. The respective criteria are derived from the following seven basic policies.

 

1. Tag type
A tag must fit in one of the categories in Table 1.

 

2. To guarantee the uniqueness of ucodes
The ucode values assigned to targets must be unique. Therefore, ucode tags must guarantee the uniqueness of the ucode.

 

3. Distinction from non-ucode tags
ucode tags should be distinguishable from non-ucode tags based on the same same standard. If this is not possible, tag readers will misidentify and obtain IDs of non-ucode tags as ucodes IDs. This is not good for the applications in general.

 

4. Principle of no response
In an environment where many tags of different protocols and methods exist together, it is preferable that a tag should produce no response to reading attempts in non-compatible methods. If we assume a ubiquitous computing environment where various tags exist as ucode tags and where tags are embedded everywhere, this point is important.

 

5. Guarantee of the ucode acquisition function
The ability to read ucodes from tags correctly must be guaranteed.

 

6. Guarantee for the interoperability of the interface
This means that Ubiquitous ID Center can disclose information if interface information is necessary for the development of multi protocol readers that can read different ucode tags to assure interoperability .

 

7. To clearly display the existence of ucode tags
Clearly displaying the ucode mark is one of the conditions for certification so the existence of the ucode tag can be visibly identified easily.

 

 

 

■2 uID 2.0 -- Realization of Richer Ubiquitous Computing World Based on ucR

Ubiquitous ID Architecture 2.0 is an extended version of ubiquitous ID architecture by incorporating meta information processing technology called ucR (ucode Relation) in the ucode resolution step. As a result, richer description of the real world and context-aware ucode resolution based on it can be realized.

 

 

●2.1 ucR Basic Theory

 

The model which describes the situation (context) of the real world, in other words, the relationship between objects and places as a relationship between the ucodes assigned to objects and places is called "ucode Relation model" (ucR model). ucR model represents the concept of "relationships between ucodes" as well as objects and places with ucodes. A ucode which identifies such relationships is called a relation ucode. Information which can become the attribute value of objects and places to which ucode is assigned such as strings, web page URLs, numerical values, etc. is called an atom in the ucR model.
The triplet of (ucode, relation ucode, ucode) or (ucode, relation ucode, atom) is called ucR unit. This is the basic unit used in ucR model. (Figure 5) In addition, if a triplet is compared to a sentence where the relation ucode is the predicate, the ucode that corresponds to the subject of the sentence is called a subject ucode, and the ucode that corresponds to the object or the complement of the verb is called an object ucode. The structure of triplet is quite simple. Yet it has a high representation power for situations in the real world.

 

Figure 5: ucR unit

 

(Example 1) Description of Place
Let's describe a situation where there are chairs in a room using a ucR unit. Suppose ucode:u1 is assigned to one of the chairs and ucode:u2 is assigned to the room respectively as identifiers. Furthermore, suppose ucode:uA is assigned to indicate the relationship of "is in (inside)." In this case, the situation of "a char is in the room" is described by connecting two ucodes, u1 and u2, with the relation ucode:uA (Figure 6).

Figure 6: Example of a ucR unit (1)

 

(Example 2) Product Information
Suppose there is a computer product named "ubiquitous PC" and the operating manual is published on http://www.example.org/.
Here, suppose, u3 is assigned as a ucode to identify the computer product and ucode uB is assigned to the relationship of "name" while ucode uC is assigned to the relationship of "operating manual URL." In this case, the ucR unit describing the situation of "the name of this product is ubiquitous PC and the operating manual is available at http://www.example.org/" is illustrated in Figure 7.

 

Figure 7: Example of a ucR unit (2)

 

Suppose this room is located on the sixth floor of ABC building in the example of Figure 6. Then, this room is said to be `is in' "the sixth floor of the building," and the sixth floor of the building is `is in' "ABC building." These can be described with ucR units respectively. In addition, names of the room and the building and the address of the building can also be associated with the ucR units. Thus, a directed graph associating multiple ucodes and atoms with relation ucodes is called a ucode Relation Graph (ucR graph). Atoms only appear in the leaves of the ucR graph.

 

Figure 8: Example of a ucR Graph

 

In ucR, the data structure does not have to be defined beforehand. Information related to a ucode can be freely updated by adding and deleting the ucR unit. Therefore, cases of frequently changing context can be supported; such as adding a new kind of service to a certain place or conversely halting a certain kind of service, launching the coordination of multiple services or the merger of companies relocating users for a certain service as customers for other services etc.

 

 

●2.2 ucR Databases and ucode Resolution

 

The ucode Relational Database (ucR database) manages ucR graphs. Therefore, in a ucR database, information on the relationships between each ucode are also managed in addition to the server address of information and the content related to individual objects and places to which ucodes are assigned.
ucode resolution for the ucR model means selecting relevant information corresponding to the situation from a given ucode based on the given ucR graph. For example, with the ucR graph such as the one in Figure 8 in a ucR database, latitude and longitude of places, and their inclusion and connectivity relationship can be inquired by ucode resolution.
In the ucode resolution protocol in the ucR model, commands are also provided for pattern matching of graphs in addition to commands to obtain ucR units and ucR graphs from the ucR database. Therefore, when the graph structure is already known, information can also be efficiently obtained from the ucR database.

 

 

●2.3 ucR Schema and ucR SOAP API

 

As previously mentioned, with ucR, rich information description and the retrieval of many patterns related to the rich information representation is possible. Since ucR does not use a predetermined data schema like an ordinary relation database, it is also suitable when each item has different attributes respectively.
However, in practice, all information is not so individualistic in this manner. Rather, we see many applications where a large amount of information with the same structure repeatedly appear. For example, Figure 9 is an example of a ucR graph used by a space information service application. Similar structures appear twice in the enclosed parts in the figure. The repeated ucR unit is one connected by relation ucodes for the names, keywords, price, address, and nearest bus stop from the node that displays the facility, and there is a ucR unit connected by relation ucodes for the tags and names from the ucode for the nearest bus stop. Such structures repeatedly appear in location information service ucR database.

 

Figure 9: ucR graph structure often seen in space information service
Note: In this graph, the ucode part is represented with characters to make it easy to read.

 

ucR schema is an abstraction of such repeatedly appearing structures in this way. ucR schema allocates variables to each node of the abstracted ucR graph (Figure 10). By using the ucR schema, you can make inquiries without being aware of the ucR graph structure, in other words, without knowledge of the graph structure.

 

Figure 10: ucR Schema Example

 

Although this ucR schema is apparently similar to the scheme used in a relational database, there is a significant difference. A relational database schema defines the structure of data to be inserted beforehand. Therefore, the structure of data stored in the database should basically follow the predetermined schema of the database. On the other hand, the ucR schema defines a pattern of an arbitrary ucR graph beforehand. We don't have to use the ucR scheme pattern for the data within an ucR database. Thus, while the flexibility and the universality of the ucR model is maintained, highly abstract and easy-to-use inquires can be described from an application.
ucR SOAP API is a SOAP 1.2 compliant API to access ucR databases using such ucR scheme. With this API, information in the uCR database can be registered, updated, and retrieved by use of variable names defined by the ucR schema. Also, we can use many ucR schemas and switch them using this API, and conduct mashups with other applications.