Home > ucode Allocation Procedure2

ucode Allocation Procedure2

Welcome to Ubiquitous ID Center

A-, e-members, and academic members of TRON Forum are eligible to use 48-bit (248 = 281,474,976,710,656/approximately 281 trillion) ucodes.

Please fill out the necessary items in the Allocation Application Form below and send it to the TRON Forum Secretariat. You will receive an allocation notification from TRON Forum after an examination period of one to two months.
ucode Allocation Application Form (General/Provider) PDF format
To apply for ucode allocation of 64 bit space or more, consult with the TRON Forum Secretariat in advance.

Difference between Application Types: General and Provider

The procedure to re-distribute (or sub-allocate) a part of allocated ucode to other organization and individual, and allow them to issue ucode freely is called “Sub-allocation.” If this type of operation is required, apply for “ucode provider.

The organizations and individuals to which ucode is sub-allocated are affected by the operation policy of the ucode provider. They will be affected considerably, especially if the ucode provider withdraw from the Forum or stops the sub-allocation operation. For this reason, those who apply for ucode provider need to be the Executive Committee member, A-member, or e-member that pays three share or more of TRON Forum.

Table 1 shows the application types depending on ucode operation types. Please check this table to decide whether you apply for General or uocde Provider.

Table 1. Application Types depending on ucode Operation Types

ucode Operation Type Application Type
Use the allocated ucode space only in house General
Issue ucode from the allocated ucode space in house and outsource the operation to attach it to a product or place. (The ucode number can be determined only in house.) General
The organization to which ucode space is sub-allocated sets aside a certain subspace, and other(s) issue the ucode from there and attaches it to a product or place. (The ucode number can be determined by other(s).) Provider
Collect customers and associates, sub-allocate sub-space from the allocated ucode space to them, and transfer the authority to issue it freely. Provider

Allocation with specified space

A ucode tag is the media for storing ucodes. Sometimes ID has already been written into ucode tags as factory defaults, and allocated ucodes may not be written into such tags. To perform ucode resolution (the service to retrieve the information related a given ucode such as URL) using this type of ucode tags, apply for “ucode allocation with the specified space” shown below.
ucode Allocation Application Form with specified space PDF format

Mechanism of ucode Management and Operation

The mechanism of ucode management and operation stated in a rule book “ucode Management Implementing Procedures”is outlined below.

Distributed Management of ucodes

The number of objects and places that can be identified with ucodes is huge,
2128 = 340,282,366,920,938,463,463,374,607,431,768,211,456 ≒ 3.4×1038. To guarantee the uniqueness of numbers used as ucode identifiers, the ucode space is managed by subdividing it into smaller spaces called domains.

There are two levels in a domain. The upper level is called Top Level Domain (TLD) and the lower level is called Second Level Domain (SLD). Organizations that manage TLD are called the “TLD Management Organizations” and organizations that manage SLD are called the “SLD Management Organizations.”

Figure 1 illustrates the method for dividing ucode space. Ubiquitous ID Center at the root manages the entire 128-bit code space and allocates TLDC to TLD management organizations. In this manner, the ucode version and TLDC field (upper 20 bits) managed by a TLD management organization are fixed. TLD management organizations can freely manage the following 108 bits.

TLD management organizations allocate CC and SLDC to SLD management organizations. Therefore, the ucode version, TLDC, CC, and SLDC fields of ucodes managed by an SLD management organization are fixed. SLD management organizations can freely manage the following IC fields (either 16, 32, 48, 64, 80 or 96 bits).

ucode Space Division
Figure 1. ucode Space Division

Lifecycle of the ucode

Retrieving “information related to a ucode” by using the ucode as a key is called ucode resolution. For example, retrieving the URL (Unique Resource Locator) on the Internet where the information related to a food product is published from the ucode identifying the food package is an example of ucode resolution.

A server that provides the ucode resolution function is called a “ucode resolution server” while the pair consisting of a ucode and “information related to that ucode” maintained on the server is called a ucode resolution entry.

The life cycle of a ucode starting from the unused state through the procedure of allocation and issue to actual use and destruction is defined (Figure 2). There are seven states in the ucode life cycle, and the procedures to change the state are stipulated in “ucode Management Implementing Procedures.”

ucode lifecycle
Figure 2. Lifecycle of a ucode


The state of a ucode that has not been used yet is called the “Unused” state. This is the initial state of a ucode.


The ucode state reserved as an allocated area for a specific purpose in the future by Ubiquitous ID Center is called the “Reserved” state. The procedure to change the state of an unused ucode to the reserved state is called “Reservation.”

There are two methods to store ucodes in products (tags) such as RFID and infrared markers. One is storing arbitrary ucode in writable memory area and using it as ucode, and the other is transforming unique IDs provided during shipment from the factory, which is managed by a different system from ucode, into ucode on reading (Figure 3). When ucodes are stored by the second method, the ucode reservation procedure is necessary. The ucode reservation procedure is performed when tag manufacturers apply for ucode tag certification.

tag how to store ucode
Figure 3: Method for storing ucodes in ucode tags


The ucode state in which the authority of allocation is given to a TLD management organization by Ubiquitous ID Center is called “TLD-allocated.” The procedure to change the state of unused ucodes to the TLD allocation state is called “TLD-allocation.”


Ubiquitous ID Center (a TLD management organization) provides SLD management organizations with the authority to manage ucodes in a certain subspace based on an application. When this happens, the ucode state is called “Allocated.” The procedure to move ucodes in the unused or reserved state to the allocated state is called “Allocation.”

When a TLD management organization allocates a ucode to an SLD management organization, the TLD management organization registers the information of the allocated SLD management organization in a ucode resolution server managed by the TLD management organization itself. For example, when TLD Management Organization #1 which manages the space 00001XXXXXXXXXXXXXXXXXXXXXXXXXXX (x are arbitrary) allocates the space 00001e0000000000000000000001XXXX to SLD Management Organization #1, TLD Management Organization #1 adds a ucode resolution entry “information on ucodes in the space 00001e0000000000000000000001XXXX is understood by SLD Management Organization #1″ in the ucode resolution server they manage (Upper part in Figure 4).


Sometimes SLD management organizations may transfer the authority to issue a part of allocated ucode space to other individuals and organizations. This procedure is called “Sub-allocation” and the ucode state in which other individuals and organizations can issue it is called “Sub-allocated.” SLD management organizations which conduct sub-allocation are called “ucode providers.”


SLD management organizations or individuals and organizations to which ucodes are sub-allocated by SLD management organizations change a ucode they have the authority to issue to a readable state [1], associate it with content or service and service, and register the relationship between the ucode and content (or service) to be associated with ucode in a ucode resolution entry. For example, SLD Management Organization #1 registers the ucode resolution entry, “information regarding the 00001e00000000000000000000011234 ucode is available at http://www.example.org/” in the ucode resolution server they manage (bottom part in Figure 4). After this, the terminal which obtained the ucode value, 00001e00000000000000000000011234, will know that the information regarding this ucode is available at http://www.example.org/ by performing ucode resolution. As a result, the terminal can receive the information and service related to the obtained ucode.

The ucode state in which the ucode can be used in this manner is called the “Issued” state and the procedure to change a ucode in the allocated or sub-allocated state to the issued state is called “Issue.”

[1] “Change a ucode to a readable state” refers to the actions of making the ucode into a readable image based on the ucodeQR representation and printing it out, or writing the ucode in an RFID tag and attaching it to objects, places, etc.

ucode Allocation and Issue Procedure
Figure 4. ucode Allocation and Issue Procedure


The ucode state in which a ucode cannot be used is called the “Destructed” state. The procedure to change a ucode in the issued state to the destructed state is called “Destruction.”

In this way, ucodes become usable after three procedures of allocation, sub-allocation, and issue. Figure 5 illustrates how ucode space is divided by each procedure of allocation, sub-allocation, and issue.

ucode allocation
Figure 5. ucode Allocation/Sub-allocation/Issue Procedures and ucode Space Division

Home > ucode Allocation Procedure2


Return to page top