White Paper On Mobile Codes: Candidate - 17 Jun 2008
White Paper On Mobile Codes: Candidate - 17 Jun 2008
White Paper On Mobile Codes: Candidate - 17 Jun 2008
Use of this document is subject to all of the terms and conditions of the Use Agreement located at
http://www.openmobilealliance.org/UseAgreement.html.
Unless this document is clearly designated as an approved specification, this document is a work in process, is not an
approved Open Mobile Alliance™ specification, and is subject to revision or removal without notice.
You may use this document or any part of the document for internal or educational purposes only, provided you do not
modify, edit or take out of context the information in this document in any manner. Information contained in this document
may be used, at your sole risk, for any purposes. You may not use this document in any other manner without the prior
written permission of the Open Mobile Alliance. The Open Mobile Alliance authorizes you to copy this document, provided
that you retain all copyright and other proprietary notices contained in the original materials on any copies of the materials
and that you comply strictly with these terms. This copyright permission does not constitute an endorsement of the products
or services. The Open Mobile Alliance assumes no responsibility for errors or omissions in this document.
Each Open Mobile Alliance member has agreed to use reasonable endeavors to inform the Open Mobile Alliance in a timely
manner of Essential IPR as it becomes aware that the Essential IPR is related to the prepared or published specification.
However, the members do not have an obligation to conduct IPR searches. The declared Essential IPR is publicly available
to members and non-members of the Open Mobile Alliance and may be found on the “OMA IPR Declarations” list at
http://www.openmobilealliance.org/ipr.html. The Open Mobile Alliance has not conducted an independent IPR review of
this document and the information contained herein, and makes no representations or warranties regarding third party IPR,
including without limitation patents, copyrights or trade secret rights. This document may contain inventions for which you
must obtain licenses from third parties before making, using or selling the inventions. Defined terms above are set forth in
the schedule to the Open Mobile Alliance Application Form.
THE OPEN MOBILE ALLIANCE IS NOT LIABLE FOR AND HEREBY DISCLAIMS ANY DIRECT, INDIRECT,
PUNITIVE, SPECIAL, INCIDENTAL, CONSEQUENTIAL, OR EXEMPLARY DAMAGES ARISING OUT OF OR IN
CONNECTION WITH THE USE OF DOCUMENTS AND THE INFORMATION CONTAINED IN THE DOCUMENTS.
Contents
1. SCOPE ................................................................................................................................................................................5
2. REFERENCES ..................................................................................................................................................................6
3. TERMINOLOGY AND CONVENTIONS ......................................................................................................................7
3.1 CONVENTIONS .............................................................................................................................................................7
3.2 DEFINITIONS................................................................................................................................................................7
3.3 ABBREVIATIONS ..........................................................................................................................................................7
4. INTRODUCTION .............................................................................................................................................................8
4.1 USAGE SCENARIOS FOR MOBILE CODES .....................................................................................................................8
4.1.1 Web......................................................................................................................................................................8
4.1.2 SMS .....................................................................................................................................................................9
4.1.3 Dial ......................................................................................................................................................................9
4.1.4 Business card .......................................................................................................................................................9
4.2 BENEFITS FOR CONSUMERS, MARKETING, MOBILE INDUSTRIES ...............................................................................9
4.2.1 Consumers ...........................................................................................................................................................9
4.2.2 Marketing.............................................................................................................................................................9
4.2.3 Mobile industries .................................................................................................................................................9
4.3 THE NEED TO SELECT FROM EXISTING STANDARDS .................................................................................................10
5. SYMBOLOGIES .............................................................................................................................................................11
5.1 REQUIREMENTS AND BASIS FOR COMPARISON.........................................................................................................11
5.2 STANDARD SYMBOLOGIES.........................................................................................................................................11
5.2.1 QR......................................................................................................................................................................11
5.2.2 Data Matrix ........................................................................................................................................................12
5.2.3 EAN/UPC ..........................................................................................................................................................13
5.3 PRINTING AND DISPLAY CONSIDERATIONS ...............................................................................................................13
6. DATA FORMAT .............................................................................................................................................................14
6.1 DATA REQUIREMENTS ...............................................................................................................................................14
6.1.1 Direct vs. Indirect codes ....................................................................................................................................14
6.1.2 User Feedback....................................................................................................................................................14
6.2 SYNTAX ......................................................................................................................................................................14
6.2.1 NDEF .................................................................................................................................................................14
6.2.2 NTT DoCoMo....................................................................................................................................................16
6.2.3 Flashcode data syntax ........................................................................................................................................16
7. CLIENT BEHAVIOURS ................................................................................................................................................18
7.1 SUPPORT FOR DIRECT AND INDIRECT ARCHITECTURES..........................................................................................18
7.1.1 Direct method ....................................................................................................................................................18
7.1.2 Indirect method ..................................................................................................................................................18
7.1.3 Achieving interoperability with the Indirect method .........................................................................................19
7.1.4 Security ..............................................................................................................................................................20
8. EXAMPLES OF DIRECT MODE ENCODING BASED ON EXISTING STANDARDS .......................................22
9. CONCLUSIONS ..............................................................................................................................................................23
APPENDIX A. EXAMPLE ECOSYSTEM ROLES .......................................................................................................24
APPENDIX B. CHANGE HISTORY (INFORMATIVE) ..............................................................................................26
Figures
Figure 1. Three common types of mobile code. .......................................................................................................................8
Figure 2. QR codes encoding alphanumeric data “a123456789a12…” of length (a) 40, (b) 100, (c) 200 characters ......12
Figure 3. Data Matrix codes encoding alphanumeric data “a123456789a12…” of length (a) 40, (b) 100, (c) 200
characters. ........................................................................................................................................................................12
Figure 5. Link to www.openmobilealliance.org encoded as a Smart Poster record (and as Data Matrix and QR)........15
Figure 8. Indirect mobile code decoding conceptual service architecture (possible roles) ................................................25
Tables
Table 1. Four combinations of data format and symbology, and the types of data encoded ............................................22
1. Scope
This white paper aims to stimulate a global market in which barcodes act as enablers for camera-equipped handsets to access
content and services. Some technologies already exist; for example, in Japan, 2D barcode scanning is in widespread use.
However there is fragmentation in the worldwide market currently, due to the variety of approaches to the questions of which
barcode symbologies should be supported, what format of data they should contain, and how reader software should behave
when barcodes are read. The Open Mobile Alliance aims to halt fragmentation by providing guidelines on existing standards
as well as creating specifications to address interoperability needs as they arise. Once enough mobile code readers that follow
those guidelines are deployed on consumer handsets, marketing organisations and publishers will be able to include mobile
codes as links to online content and services with confidence, in advertising and promotional campaigns, and in printed and
displayed media of many kinds.
This white paper does not address barcodes displayed on mobile devices as coupons or tickets (for reading by other devices).
2. References
[DATAMATRIX] “Information technology — International symbology specification — Data Matrix”, ISO/IEC 16022:2000.
[EAN/UPC] “Information technology — Automatic identification and data capture techniques — Bar code symbology
specification — EAN/UPC”, ISO/IEC 15420.
[FLASHCODE] “Flashcode Reader International Specification”, Version 1.0
http://www.mobiletag.com/beta/en/contactspecification.html
[MIME] “Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types”, RFC 2046
http://www.ietf.org/rfc/rfc2046.txt
[NDEF] “NFC Data Exchange Format (NDEF) Technical Specification”, NFC Forum
http://www.nfc-forum.org/specs/
[NFCRTD] “NFC Record Type Definition (RTD) Technical Specification”, NFC Forum
[NTTDOCOMOGUIDE] “Guidelines and criteria for creating QR codes compatible with all terminals”, NTT DoCoMo,
http://www.nttdocomo.co.jp/english/service/imode/make/content/barcode/about/#p02
3.2 Definitions
Code See Mobile Code
Direct Code A mobile code that contains either (1) content for direct consumption for the handset, or (2) the address of
the service to be accessed (typically a URI [URI])
Indirect Code A mobile code that contains an identifier. The identifier has to be resolved (looked up) in order to access the
identified content or service. See Resolution.
Mobile Code A 1D or 2D barcode as read by camera-equipped handsets
Resolution The process of mapping an identifier supplied from an indirect code into either content to be consumed
directly by the handset, or the address of content (or a service) to be consumed by the handset. Typically,
resolution is performed by a network service.
Symbology The algorithm by which data is encoded as visual elements (typically arrangements of lines or squares), and
the resultant “look and feel” for the user.
3.3 Abbreviations
EAN/UPC Barcode symbology family including EAN-8, EAN-13, UPC-A, and UPC-E [EAN/UPC].
JAN Japanese Article Number. A barcode of the EAN symbology, used in Japan.
NDEF NFC Data Exchange Format
NFC Near Field Communications
OMA Open Mobile Alliance
QR Quick Response, a type of barcode symbology [QR].
UPC See EAN/UPC.
URI Uniform Resource Identifier [URI]
4. Introduction
Mobile codes – 2D and 1D barcodes – have emerged as a promising enabler of the mobile Internet in some markets. Camera-
equipped handsets now have good enough optics, image resolution and processing capacity to read mobile codes on printed
materials and electronic displays. These symbols encode information such as URLs, phone numbers, and in-line content such
as business cards.
There is, however, still a lack of interoperability between different markets and players. The majority of consumers are
unlikely to adopt the technology before it comes pre-installed on their devices. Similarly, marketing, publishing and other
industries that are otherwise motivated to provide mobile codes will not adopt them without adequate potential for consumer
take-up. That in turn would entail deployment on a large variety of devices, and interoperability between different service
providers.
Example
When read and decoded by a camera-equipped handset, data from mobile codes can be used to access content and services in
several ways. These include but are not restricted to:
• Dialling a number
• Consuming data such as business card information directly from the code.
4.1.1 Web
Outside, in a café, a mobile handset camera is pointed at an advertisement, poster, leaflet or beer-mat. In just one click, the
user arrives at a webpage designed specifically for that location. No struggle with the navigational systems of mobile
websites; no wait – just the instant fulfilment of the user’s needs. The spontaneity of the response encourages an internet
connection there and then; the internet content is relevant to the precise time and location of the user; the advertiser can track
exactly which piece of paper generated the user response – and the mobile handset has enabled a trouble-free and relevant
experience of the web that is potentially more useful to website provider and user alike. And of course, the mobile industry
benefits from increased usage of the internet over mobile handsets.
4.1.2 SMS
At the breakfast table, Mary finds day 2 of a holiday promotion in her copy of the Times newspaper. To enter, she can either
text ‘Holiday 2’ to ‘55555’, or she can read the mobile code. The latter is much quicker and easier. The response explains that
she needs to do this over three days to complete her entry, and that she can enter for yesterday from the Times web pages.
That lunchtime, she finds yesterday’s entry on the web, and reads the code from the screen. The next day, at 3pm, she still
hasn’t bought a copy of the Times. She receives an SMS reminding her that she needs just one more entry to complete her
entry. She buys the Times and reads the code when she gets home. Mary has been provided with easy ways to enter the
promotion – which might have been too much trouble, otherwise. The newspaper established two-way connections with its
readers. If they consent, there are further ways in which it can reach them.
4.1.3 Dial
Jane is going though the yellow pages for a plumber. It’s an emergency. She goes for the first ad with a mobile code, points
and clicks to dial the number – there’s no time to waste. The plumbing company has found they’re receiving more calls since
they placed this larger ad with the mobile code. The yellow pages company is more than happy to accommodate them.
4.2.1 Consumers
Reading a mobile code is faster and more convenient than transcribing data such as URLs, telephone numbers and SMS
messages into handsets. It’s less error-prone, because the error correction in the codes guarantees against entering incorrect
data.
Consumers do not need to navigate to the appropriate application on their handset. It is implicit in the type of data in the
code. This is especially helpful with respect to web browsers, which many users find difficult to locate and operate on their
handsets.
4.2.2 Marketing
By lowering the effort required for a user to participate in promotional campaigns compared to manual transcription of URLs
etc., mobile codes increase response rates.
Mobile codes also make print advertising measurable. By including unique identifiers in the mobile codes targeted to
different placements of the same advertisement in media formats, markets and physical locations, marketers can measure
which placements were more effective than others.
through more and more rewarding internet connections. Operators can help drive the reach and scale of the mobile code
scanning opportunities by ensuring that scanning clients and applications are pre-installed in the mobile devices. Moreover,
while user triggering of mobile access to content and services can be reduced to “scan the code with the camera-and click”,
operators may – where involved in the transaction – be able to associate such user inquiries with the user’s preferences based
on his/her subscription profile so that advertisers may benefit from target marketing with deeper profile data of prospective
customers. Privacy concerns need to be considered as applicable.
Handset Manufacturers: Feedback from mobile code adoption in Japan suggests that, once established in the market, mobile
code readers become a “must have”. Handset companies will want to provide a compelling reason to upgrade to their mobile
code-enabled terminals.
Application and Service Providers: There is room for innovation in many aspects of user interaction with mobile codes, and
in new mobile code support services. The mobile phone’s code reader is the new web browser in terms of the impact it could
have on mobile content and service provision. The service at the end of the code provides the new internet experience. Both
application and service sectors have the opportunity for significant growth, perhaps enabling different actors in the value
chain, as is discussed in Appendix A.
By using existing standards wherever possible and appropriate – as applied to the usage scenarios in this white paper– work
will be saved and the path to adoption will be accelerated. One of the roles of the OMA is to critically examine the suitability
of existing standards, and to determine whether there is a gap between what they specify and the functionality that is required
for mobile codes.
5. Symbologies
This section describes standard symbologies that are already in widespread use in business processes such as product
identification where dedicated reader hardware and software is used; and, to a greater or lesser extent, as mobile codes, that
is, read by readers on handsets. They are described on the basis that they are fully specified and approved standards, and that
reader technologies for handsets are already mature, with several providers in the marketplace.
In addition to open standard symbologies, support of proprietary symbologies may be important in certain markets. Examples
of such proprietary symbologies include EZCode, Colorzip, BeeTagg and Shotcode. This list is not exhaustive.
When comparing symbologies with respect to those requirements, the following factors are relevant:
Data capacity. Some symbologies, such as the EAN/UPC family [EAN/UPC], have a data capacity in the order of ten bytes.
Such symbologies cannot be used to store in-line content or addresses such as URLs. Instead, their use is restricted to storing
identifiers, which need to be looked up to provide associated content or services. Other symbologies, such as QR [QR] and
Data Matrix [DATAMATRIX], can in principle be used to store thousands of bytes, although in practice such quantities of
data cannot be resolved currently, given the limited imaging capacity of handsets. A typical limit for high-end camera phones
at the time of writing is a few hundred bytes of alphanumeric or binary data.
Error correction. Some degree of error detection and correction is essential, given that users may try to read partially
occluded codes, codes displayed on imperfect surfaces, and codes read in imperfect lighting conditions.
Space efficiency. Symbologies define a smallest visual unit, sometimes called a module, out of which the variable part of a
mobile code is constructed as an encoding of the data to be encoded along with error correction bits. Symbologies also
include visual elements (constructed from modules) for the purposes of registration in the visual field, and supplying certain
metadata needed for decoding. Those include a ‘quiet zone’ at the borders of the code, and certain fixed and variable
elements within it. One can compare symbologies by asking, for a given module dimension (chosen to be resolvable by a
typical handset) and a given amount of data of a given type to be encoded (e.g. numeric vs. alphanumeric vs. binary), and a
given level of error correction, what are the overall dimensions of the corresponding mobile code? Obviously, the better the
space efficiency in both axes of the display plane, the better.
Look and feel. Any barcode symbology, by its nature, consists of a regular arrangement of visually noisy elements. But the
overall appearance of different symbologies to the human eye isn’t necessarily equal.
5.2.1 QR
QR codes [QR] (Figure 2) are already widely used in Japan in industrial processes and as mobile codes, and have been used
in mobile code pilots in the rest of the world. They are an ISO standard. The variant of QR codes in widespread use are
Model 2 (with some minor enhancements in the QR 2005 variant).
Figure 2. QR codes encoding alphanumeric data “a123456789a12…” of length (a) 40, (b) 100, (c) 200 characters
QR codes have native support for the Kanji character set, and efficient support for all-alphanumeric data. QR codes currently
support alphanumeric data capacities of up to about 400 bytes and binary capacities of up to about 270 bytes, in formats that
are readable by handsets that have macro focus and resolutions of several megapixels. Such handsets are typical in Japan but
represent high-end handsets outside Japan. The capacity is closer to 100 bytes of alphanumeric characters or 70 bytes of
binary data when read by a typical camera phone without macro focus, but with resolution of one megapixel or more.
The QR symbology supports error correction using the Reed-Solomon method. There are four levels of error correction,
selectable according to the operating environment. The capability ranges from correcting about 7% of the data in a code, to
about 30%.
Figure 3. Data Matrix codes encoding alphanumeric data “a123456789a12…” of length (a) 40, (b) 100, (c) 200
characters.
Data Matrix, like QR codes, uses the Reed-Solomon algorithm for error correction. Data Matrix codes have a redundancy of
approximately 33%, which ensures a good trade-off between code efficiency and correction capacity.
A quiet zone of at least one module width is generally needed around the 2D barcodes, as shown by the following examples:
5.2.3 EAN/UPC
The EAN/UPC family of 1D symbologies [EAN/UPC] (Figure 4) consists of EAN-13, EAN-8, UPC-A and UPC-E. They are
all ISO standards. They are in widespread use as product tags.
The data capacity of these codes is small and fixed according to the symbology: between 8 and 13 numeric digits. They carry
one error correction digit. The space efficiency of these codes is relatively poor.
Size. A given code may be printed or displayed relatively large or small, by varying the module size. However, relatively
large codes may be aesthetically disruptive. Relatively small codes may be unreadable by many handsets. A relatively small
or large code may also cause the user to adopt a reading position that is respectively too close to or too far from the display
surface.
Rendering fidelity. Mobile codes must be printed with sufficient accuracy, use colours of sufficient contrast, and have a ‘quiet
area’ of suitable dimensions around them, if they are to be robustly readable. Similar considerations apply when presenting
codes on electronic displays. In addition, screen flicker (caused by the lack of synchronisation between the display’s refresh
pulse and the handset’s camera) may interfere with code reading.
Colour. Colour is relevant to aesthetics, and not just readability. With Data Matrix, the possibility to use white on black
provides a convenient way of integrating a code on a layout with black background.
The standards’ specifications [QR, DATAMATRIX, EAN] provide some general guidelines on the above issues, and NTT
DoCoMo also publish guidelines [NTTDOCOMOGUIDE].
6. Data Format
This section first describes the data required in mobile codes, and then describes existing standards that specify a syntax for
representing it. Both the choice of data structure and the way the data is processed are independent of the symbology choice,
except in respect of limited data capacity.
• Direct: the code contains either the address (URI) of the content or service, or the content itself, in-line. The
requirement here is to support a range of URI and content types that correspond to scenarios such as those described
in Section 4.1.
• Indirect: the mobile code contains an identifier, which needs to be resolved to obtain the content or service.
Resolving an identifier means looking it up, typically at a network service, to determine the corresponding content
or service. To avoid ambiguity, any identifier retrieved from a code must be unique. Several URI schemes have
already dealt with those issues, e.g. ‘tag’ URIs [TAGURI]. Note that certain symbologies, such as those in the
EAN/UPC family, contain uniquely allocated identifiers. The combination of the symbology name (e.g. its ISO
identifier) and the identifier read from the code is therefore unique.
6.2 Syntax
Below we consider 3 examples of syntax for mobile codes. Other specifications exist, and the list of examples below is non-
exhaustive.
6.2.1 NDEF
This subsection describes the applicability of NFC Forum’s NDEF standard as an appropriate syntax for data in mobile
codes. It accommodates both Direct and Indirect use cases. It can also accommodate proprietary applications and foreseeable
extensions to standards (for example, for Bluetooth pairing).
Near Field Communications (NFC) is a short range radio technology based on radio frequency identification (RFID). It can
be used for a new kind of human-device interaction, where a user can initiate actions on a mobile device by touching physical
objects.
NFC use cases can be divided into 3 sub categories, based on the role the device plays. In some of the most popular use cases
of NFC, the device is acting as an RFID tag, being read by an external reader. Examples include using the phone as a mass
transit ticket, a credit card, or a key. Another mode of NFC phones is peer-to-peer, where two users can exchange data such
as a business card by touching the devices together. The last mode of an NFC phone is when the device acts as the RFID
reader (/writer), acting on an external, and usually passive, RFID tag. This last mode is most relevant to the discussion that
follows, as these use cases much resemble the typical use of mobile codes.
The NFC Data Exchange Format (NDEF) is a data format agreed by the NFC Forum for achieving interoperability between
different players in the mobile industry. Version 1.0 of the NDEF specification was published by the NFC Forum on the 7th
of March 2006 [NDEF]. The format wraps content transferred over NFC, adding information about the type of the transferred
data (helping the device decide what to do with the data) and the length of the data (useful for separating multiple records, as
explained in the UI section below).
The NDEF format was designed with similar aims and constraints that apply to mobile codes. The format provides a flexible
way of encoding both common industry standard data formats – that can support the most common use cases – as well as
being open for company-specific proprietary data. As the first commercially available NFC tags vary in size from about 50
bytes up to some kilobytes – similar to the data capacity achievable with mobile codes – the NDEF format has been designed
for low overhead.
On top of NDEF, the NFC Forum has published a number of Record Type Definitions [NFCRTD], which provide a well
known way of encoding data for some of the most common use cases. As of November 2007, the NFC Forum has published
RTDs for plain text [TEXTRTD], URIs [URIRTD] and Smart Posters [SPRTD].
Reusing the established NDEF format for mobile codes should help reduce the time to market, Moreover, devices that
implement both NFC and mobile code technologies may be able to benefit by re-using the NDEF format for mobile codes
The URI RTD does not specify how a device should behave when encountering a specific URI. For guidelines on that, please
refer to the OMA URI schemes document [OMAURI].
Figure 5 shows SmartPosters with links to www.openmobilealliance.org with the popup text “Hi!” encoded as Data Matrix
and QR code.
Figure 5. Link to www.openmobilealliance.org encoded as a Smart Poster record (and as Data Matrix and QR)
The NTT DoCoMo standards are based on the QR code symbology, but the data structures described below could equally
well be written on Data Matrix. As of November 2007, these specifications are available on NTT DoMoCo’s web pages
[NTTDOCOMOFUNC].
• A mobile code starting with MEBKM: is a command to the phone to bookmark a URL. A title for the bookmark is
provided in the data, together with the URL. This is similar to an NDEF Smart Poster with the bookmark action.
• A mobile code starting with MECARD: signifies a business card. This is similar to an NDEF record with a vCard as
MIME typed data.
• A mobile code starting with MATMSG: is used for encoding email messages onto a mobile code.
• A mobile code starting with CNTS: encodes images, music or ToruCa messages. This is similar to having the data as
MIME typed content on an NDEF message [MIME].
• A mobile code starting with LAPL: indicates data used for i-appli (DoCoMo’s Java services) synchronization.
On encountering something that looks like a phone number, the device will offer the user the option of initiating a voice or
video phone call, or sending an SMS message to that number. If the device finds a message containing an email address in
the form somebody@example.com, it can suggest that the user sends an email to the address. Lastly, if the device finds a URI
with the prefix http or https, the device can invoke the browser to access the resource designated by the URI. In all the
foregoing cases, the device first obtains user confirmation before the operation can proceed.
• “Details” field
o The format of the “Details” is dependent on whether the service type is direct or indirect:
For direct services, the “Details” field contains formatted data which is specific to the service type and consists of list of
fields separated by a delimiter. Here is an example of a direct phone call initiation in the Details field:
7. Client behaviours
Now that mobile codes themselves have been dealt with, we describe factors concerning the behaviour of the ‘code reader’
client on the handset (downloaded or preinstalled).
Step 1: a software client on a mobile handset acquires, recognises and decodes a mobile code.
Step 2: the decoding is completely performed by the client on the mobile handset. In some cases, the decoded data is content
that is provided for direct consumption on the handset, such as personal contact details.
Step 3 (optional): the result of the decoding (as performed in step 2) is a URI to a 3rd party service.
Step 4 (optional): if step 3 occurs, the 3rd party provides the required services.
Note that clients reading a URI from a mobile code in Step 3 will process it in accordance with [OMAURI].
Step 1: a software client on a mobile handset acquires, recognises and decodes a mobile code.
Step 2: the processing of the data in the mobile code is not fully performed by the client on the mobile handset; the client
reads the identifier embedded in the mobile code and then it connects to a redirection platform.
Step 3: the redirection platform resolves the identifier from the mobile code. The redirection platform may apply rules
governing both access restrictions and the type of service provided to mobile users.
Step 4: the redirection platform sends either content or a service URI to the mobile handset.
Step 5 (optional): the data returned to the client in step 3 is a URI to a 3rd party service.
Step 6 (optional): if step 5 occurs, the 3rd party will provide the required services.
Note that clients receiving a URI from a redirection platform in Step 5 will process it in accordance with [OMAURI].
There are two main problems to solve in order to achieve interoperability: managing the identifier namespace and resolving
the identifiers.
The identifier obtained from an indirect code should be unique; otherwise, the effect of reading a code may be ambiguous.
We first describe two examples for decentralised allocation of identifiers, and then consider centralised allocation.
Example U1: There is an existing standard for the decentralised creation of globally unique identifiers: ‘tag’ URIs
[TAGURI], e.g.:
tag:example.com,2007:832481364312894
Users may place such URIs in NDEF URI records or in the free text of an NTT DoCoMo code.
Example U2: In the special case of EAN/UPC codes, where the symbology is strongly tied to a managed namespace of
identifiers, the identifier extracted from the code is prefixed by a symbology-specific unique string, such as:
tag:openmobilealliance.org,2008:bt:mc:sym:<symbology identifier>:
In this example, the client is pre-configured with the unique names of the UPC/EAN symbologies. It automatically constructs
the resulting globally unique identifier for the mobile code, by appending the identifier it has read from the code to the
symbology’s identifier.
An alternative to decentralised namespace management (as in examples U1 and U2) is to create a centralised authority for
managing the allocation of identifiers. In principle, a centralised authority could allocate shorter identifiers, and thus facilitate
smaller mobile codes. Moreover, the scope of uniqueness maintained by such an authority could be, say, national rather than
global, enabling the identifiers to be shorter still while achieving geographic market interoperability. But then a factor to be
considered is that conflicts might arise for those travelling into or out of the country or region concerned.
A system architecture is required for resolving the identifiers extracted from mobile codes into data that the client can
consume directly or use to access third-party services, such as a URI. We consider two examples that differ markedly. These
are merely taken as the two examples out of a multitude of possibilities.
Example R1: Centralised resolution. This example follows the architecture shown in Figure 7
In this example, every handset is configured with the domain name of a centralised resolution (redirection) service. To access
this service, the client may construct a query URL according to the standard for URN resolution [URNRES], using the ‘N2L’
example. That service then performs the redirection.
Example R2: Code reader applications. In this example, consumers are free to download and install applications that utilise
their code readers by processing the identifiers read from codes, and which respond to identifiers beginning with specific tag
prefixes. For example, an application for product information could take all URIs beginning
tag:openmobilealliance.org,2008:bt:mc:sym:EAN-13: read from the code reader, and send them to an application-specific
service for resolution. In the case of an enterprise application used by staff in the Example corporation, their clients
incorporate an application that sends all tags beginning tag:example.com for in-house resolution.
7.1.4 Security
Mobile codes raise security issues, since they may lead the user to a malicious service or to one with an undesirable side-
effect such as a hidden charge. Such codes may be presented in apparently benign situations, and they may even be placed so
as to cover bona fide codes.
In the case of indirect codes, the redirection platform can place constraints on the possible results when a given user reads a
mobile code. Firstly, only codes containing an identifier sanctioned via that platform will produce any result at all.
Secondly, trusted information about the charge that will be billed to the user can be generated and sent to the user before
completion of the transaction. Thirdly, if the user is registered with the platform, then the platform can apply policies
concerning the types of content that the user can access – based, for example, on the user’s age.
Whether the mobile code is Direct or Indirect, in some markets, user feedback is an important issue in helping the user avoid
inadvertent service or network accesses. For example, an implementation may display the details of the third-party service
address (for example, its URI) and require confirmation from the user before accessing the service. For general consumer
use, in some markets, this is considered to be good practice.
Table 1 shows that two data formats, NDEF and NTT DoCoMo, may be used as independent alternatives, and that each
format may be encoded in either the QR or Data Matrix symbology.
About five years of experience exists with the NTT DoCoMo standard. The NDEF standard has not been applied to mobile
codes hitherto, but there is no reason in principle why it should not be used for this purpose.
Even though the NTT DoCoMo format is normally associated exclusively with QR codes, there is no technical reason why
NTT DoCoMo data should not be represented in Data Matrix encoding. This gives a total of four combinations for
implementing mobile codes based on well established standards.
Data format:
Table 1. Four combinations of data format and symbology, and the types of data encoded
Representation of Direct mobile codes is immediate for any of the four combinations in Table 1. The NDEF standard allows
arbitrary URIs and MIME-typed inline data. The NTT DoCoMo standard includes http(s), tel, sms and mailto URIs, and
inline data.
The OMA has defined terminal behaviours for various types of URI in [OMAURI], and this would apply to code reader
behaviour on reading these types of URI. All such URIs can already be represented in NDEF. In principle, the NTT
DoCoMo standard could be naturally extended so that any types of URI in [OMAREF] could appear in free text.
1
Includes a proprietary URI scheme “tel-av:” to initiate video phone calls.
9. Conclusions
Barcodes have been discussed as enablers for camera-equipped mobile devices to access content and services. In this context,
the barcodes are called mobile codes and include (ordinary) 1D barcodes (e.g. EAN/UPC) as well as 2D matrix code type
symbols (e.g. QR Code or Data Matrix).
The existing landscape around mobile codes has been described with its various aspects, including usage scenarios,
symbologies to produce mobile code symbols, mobile code data formats, client behaviours when a mobile device encounters
a mobile code, and options for the system architecture. Two classes of architectural options have been identified, namely
Direct and Indirect architectures. It has been identified that, in some markets, support of proprietary codes may be desirable.
Assessment of the existing landscape has led to insights about the areas where further agreement needs to be made to achieve
interoperability between all essential parts of a mobile codes infrastructure, including e.g. code symbol generation, client
code reading software, and the mobile network through which services will eventually be provided. Also some standards
from other areas have been identified and discussed which may prove useful as candidates for data formats for both the
Direct and the Indirect architecture, e.g. NDEF, URI, and tag URIs.
Interoperability is achievable within the Direct architecture, where mainly the choice of symbology and data structure need to
be agreed. Proven de facto standards and practices exist for both symbologies and data structures. The NTT DoCoMo system
in Japan is a prominent example.
Interoperability for the Indirect architecture may require some additional agreement, for example with respect to identifier
namespace management and resolution procedures. Standardised interfaces between the functional roles in the Indirect
architecture need further consideration.
It is recommended that the normative specifications to be developed ensure backward compatibility with relevant 2D barcode
systems, so that mobile devices that are compliant to the specifications to be developed shall be able to recognise and process
such existing 2D barcodes.
Based on the analysis in the white paper, the normative specifications should address the following:
• Common components for both Direct and Indirect methods, which consist of:
o Barcode symbology
Support of Data Matrix and QR
Optional support of proprietary codes
o Data structure in the mobile codes (considering namespace issues)
o Code reader functions
o Mobile device code reader – server interface
o Backward compatibility with relevant deployed mobile codes
1) Code Publisher. This is a brand owner (businesses or individual) who chooses to acquire and present mobile codes in
print or electronic media. Code Publishers may wish to execute advertising campaigns by directly acquiring codes themselves
or may do so via a campaign agency that manages their interests. Therefore, they may interact with the Code Sales Agency,
Code Management Platform or Code Registry.
2) Code Sales Agency. The Code Sales Agency acquires the rights to market codes obtained from a Code Management
Platform provider and/or from a Code Registry, and sells them to Code Publishers.
3) Code Management Platform. The Code Management Platform function obtains the rights to distribute codes from the
Code Registry, and adds technical value to the code generation and management process (e.g., code design enhancement,
measurement and reporting of success rates of the advertising campaign). This entity also interacts with the Code Sales
Agency. The Code Management entity may also develop a variety of “Ad Mechanics” that can be fulfilled by the code, such
as “Launch Browser and dereference a URI”, or “Launch SMS client, address it, and populate it with this message”; it could
also design and host wireless web pages on behalf of the code publishers/code sales agency, or arrange for their access to user
demographic data collected based on the campaign.
4) Code Registry and Resolution. This entity is comprised of 2 functional roles: a) the code registry, and b) the resolution
(redirection) server. In the registry role, this entity authorises different actors performing at the same layer (i.e. multiple
players of Code Sales Agencies, or multiple Code Management Platform providers) to activate and distribute codes. Other
key responsibilities of the Code registry may include:
i. Ensuring that common codes work across operator domains and that no duplicates exist across the entire ecosystem.
ii. Providing a mechanism for each operator to approve these common codes for use in their networks.
iii. Synchronising multiple Code Registries, where applicable.
In the resolution role, this entity receives an identifier read from a mobile code and provides the content or URI
corresponding to that identifier. The Code Registry could interact with the Code Publisher, the Code Sales Agency and/or the
Code Management Platform.
5) Code Clearing House. This is an entity that sits between the Operator and the Code Management entity and is equipped
with a database facility to ensure that the identifier from the Code Reader is partially resolved and sent to the appropriate
Code Management Server for full resolution. The Clearing House can be independent of the Operator, can serve one
Operator, or, subject to business agreements, can serve multiple Operators. In addition to routing of scanned codes to the
appropriate Code Management Platform via the Code Registry, the Code Clearing House can also provide value-added
functions (e.g. accounting functions, scanned code traffic monitoring, logging and reporting) to Code Publishers.
6) Operator. The Operator (or an entity performing an equivalent role) supports all required functions toward the End
Users, including requiring Code Readers to support desired symbologies relevant to its markets. Towards Code Publishers,
the Operators are responsible for connectivity to one or more Clearing Houses, or alternatively, connecting directly to one or
more Code Registries.
7) Code Reader. Code Readers extract data from mobile codes and processes it accordingly. Code Readers in mobile
devices are configured according to individual Operator requirements. Economies of scale should motivate the Code Reader
to support symbologies that are both relevant and exclusive to the market.
8) End User. The End User is the consumer of services accessed by mobile codes. The End User device may include a pre-
installed or downloaded Code Reader.
• Code Generation
Code Management & Management CMP-A CMP-B CMP-C
... CMP-X
Platform (CMP) • Full Resolution
of codes
• Triggers Content & Scanned Code routing (any-to-any)
Services “Ad Mechanics”
Code Registry
Synchronise
• Code Resolution Server CRR-A CRR-B CRR-C
& Resolution - maintains Directory
(CRR) of Unique Codes
- updates all CHs Scanned Code routing (any-to-any)
mobile
codes
Code Reader
…
…… … …
…
…… … …
…… … …
……
… …… ……… …
End User
………
Figure 8. Indirect mobile code decoding conceptual service architecture (possible roles)