©ACM 2008. This is the author's version of the work. It is posted here for your personal use. Not

for redistribution. The definitive Version of Record was published in Proceedings of the 7th

International Conference on Mobile and Ubiquitous Multimedia,

http://dx.doi.org/10.1145/1543137.1543148.

Touch & Share: RFID Based Ubiquitous File Containers Iván Sánchez1, Jukka Riekki1, Jarkko Rousu2, Susanna Pirttikangas1

1 Dept. of Electrical and Information Engineering P.O. Box 4500, University of Oulu, 90014, Oulu,

Finland. Tel: +358-08-553-2544

{ivan.milara, jukka.riekki, susanna.pirttikangas}@ee.oulu.fi

2 Nokia Oyj, Devices.Yrttipellontie 6, 90230 Oulu, Finland

jarkko.rousu@nokia.com

ABSTRACT

Here, we present Touch & Share, an application for sharing

multimedia content in our everyday environment. Our main

design criterion is ease of use. Visual icons placed in the

environment act as data storage (file containers). Users can drop

multimedia files into the containers and pick files from them by

touching the icons with their mobile terminals. The icons are

placed on, or near, the physical objects the files are related to.

RFID tags are placed behind the icons and they store metadata

information about the files available in the corresponding

containers. When users bring their terminals near the icons, the

terminals’ RFID readers communicate with the tags, read the

contents of a container from the tag and possibly write

information about new files. The actual files are stored in a server,

but the user experiences the files to be in the containers. The main

contributions of this work are a general application for storing

multimedia content in nearly any place or everyday object and a

fully functional prototype built using only commercial off-the-self

technology.

Categories and Subject Descriptors

H.5.2 [Information interfaces and presentations]: User

Interfaces– input devices and strategies, user-centered design,

prototyping.

H.3.4 [Information storage and retrieval]: Systems and

software– Distributed systems, Information Networks

General Terms

Design, Human Factors.

Keywords

HCI, File Container, RFID, NFC, Ubiquitous System.

1. INTRODUCTION Mark Weiser’s vision of ubiquitous computing [17] describes how

the digital world is embedded in the real world. Users interact

with surrounding objects in a natural way while the computation

aspects are hidden. One requirement set by this vision is that

information access is easy and does not disrupt users’ everyday

activities.

How can such easy access be achieved? The information is stored

in files located at a user’s terminal device or at some other

computer accessible through a network connection. Furthermore,

the files are usually stored in a tree structure. Hence, when a user

desires to access a file, first she needs to know the computer (i.e.

the computer’s name in the network) and then the exact node in

the tree (i.e. the folder) where the file is located. This approach,

network location based addressing (in short, the old addressing),

is clearly not feasible in ubiquitous computing environments. To

allow easy access to the digital content, files should rather be

accessible from the objects around the user, that is, users should

be able to access files by selecting objects the files are related to.

This addressing can be further improved by minimizing the usage

of the traditional user interfaces and by letting the users select

objects by the physical action of touching them. We call this

addressing as the physical object based addressing (in short, the

new addressing).

We can compare these two approaches by considering a mapping

between them. A computer name in the old addressing can be

mapped onto a region in the environment, for example, onto our

university premises. We do not suggest that the files in a single

computer would be accessible only inside some region. Regions

could rather form a hierarchy level helping the user to structure

the great amount of content available nowadays. A folder in the

tree structure of the old addressing can be mapped onto a local

place (e.g. onto the Zoological Museum of our university) and

Local Containers onto objects in that place (e.g. onto a stuffed

wolf on display at the museum). Each local container may contain

several files associated to the object. For example, a container for

a wolf could contain some images of wolves, a sound file of

wolves howling and a video where a pack of wolves is hunting.

Even though users select files by touching objects, the files are

still stored in hard disks and other storage media and the

applications serving the user access the files using the old

addressing. The mapping between the new and the old addressing

can be implemented using RFID technology. This technology is

emerging as a bridge between the physical and digital worlds [12,

1]. RFID is suitable to implement this bridge, as it enables

hyperlinks to the digital world to be placed in the physical

environment. Specifically the introduction of the NFC technology

has boosted research on this topic. NFC allows mobile devices to

MUM’08, December 3–5 2008, Umeå, Sweden.. Copyright 2008 ACM 1-58113-000-0/00/0004…$5.00.

Permission to make digital or hard copies of all or part of this work for

personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that

copies bear this notice and the full citation on the first page. To copy

otherwise, or republish, to post on servers or to redistribute to lists,

requires prior specific permission and/or a fee.

read and write data on RFID tags just by bringing a device near

the tag. The reading distance is less than 5 cm, so this technology

is advertised as the Touch technology. In recent years, researchers

have used RFID technology in combination with mobile devices

to identify and start remote services [12, 14], to control services

remotely [15], to store and share object metadata [7], to interact

with dynamic displays [6], to store graffiti [5], and as physical

hyperlinks [16].

In this paper, we propose using RFID tags as local file containers.

This idea has been proposed earlier by Arnall [2] and Ailisto et al.

[1], but they did not present any design or implementation. We

store in RFID tags a set of IDs identifying the files that are stored

in the corresponding container. For example, the wolf container

discussed above contains the ids for image, sound, and video files.

As the files are accessed by touching RFID tags in the local

environment, it is essential that users recognize the tags. We have

proposed in our previous work that services are advertised by

attaching icons on the tags [13]. We use this approach to advertise

the local containers.

Users interact with the local containers using the Pick&Drop

paradigm proposed by Hosio et al. [7]. A user has a Personal

Container, only accessible by her. This Personal Container is a

repository for user files. When a user touches a local container

using an NFC enabled mobile device, she can perform two basic

actions: Pick and Drop. The first action, Pick, can be used to

transfer files from a Local Container in the environment to the

user’s Personal Container, whereas the Drop action transfers files

into the opposite direction.

The rest of the paper is structured as follows: in section 2, we

propose a design for ubiquitous file containers. We also present

our first prototype implementation. In section 3, we describe

briefly a real application installed in our university’s Zoological

Museum. We comment the first results from a wide usability test.

In section 4, we discuss our contribution and future improvements

and compare our solution with related work. Finally, section 5

concludes the paper.

2. TOUCH & SHARE The Touch & Share system uses local containers to embed files in

the environment. Its users can share content at physical locations

by utilizing NFC enabled mobile phones and RFID tags. Content

is shared by transferring files from local containers to personal

containers and vice versa. NFC enabled mobile phones act as the

link between both file containers. An act of touching creates a

temporary link between one personal container and one local

container, and hence enables file transfer between them. Although

the users experience the local containers to be at the locations of

the RFID tags, the actual content is stored in a server. Personal

and local containers have references to those files.

The main use cases of the system are distributing content and

accessing content (Figure 1). Distributing content starts by

uploading content to the system. This is done by storing the

content in the user’s personal container through a Web page or

another HTTP based client. Once the content is stored in the

system, it can be dropped to any of the local containers. Accessing

content starts by picking files from local containers. Picked files

are stored in the personal container. Files in the personal container

can be accessed from any device with a network access which

supports the particular file type. User authentication and

permission policy is applied for accessing and distributing content

from/to the system.

Figure 1. Distributing and accessing content.

The limited storage capacity of RFID tags prevents storing the

files into the tags. According to NFC Forum’s definition [18], the

largest tag capacity is 1 MB for NFC Type 3 tags (FeliCa).

However, the tags used at the moment have much smaller

capacities (in the order of several kilobytes). Hence, we need to

store file references in the tags.

We use RFID tags as containers for file references. Each file

reference is formed by a URI and file metadata. File metadata can

help a user, for example, in deciding whether to pick a file into the

Personal Container when a Local Container is accessed.

A URI identifies one file at the server. URIs can be seen as

symbolic links in a UNIX system or as a shortcut in Windows OS.

This characteristic has the advantage of avoiding unnecessary

replications if several users have the same file in their Personal

Container. Copying the URI which identifies the file is enough.

2.1 Design Figure 2 shows a general view of the system. The Local

Containers are implemented as collections of file references. Each

file reference has a URI which is linked to one file in the File

Repository.

We use the NDEF format [20] to store data in RFID tags. An

NDEF message may contain a variable number of records. The

structure of a record is given by its type. A record may be

structured as a set of smaller records. URI NDEF type is

recommended by the NFC Forum to store URIs in a NDEF

message.

As a file reference is structured as an URI and a set of metadata

(size, keywords, description, date of creation, author name, etc.),

we need a special type of record. One possibility is to use the

Smart Poster record [21] that is structured as a set of subrecords:

Title, URI, Action, Icon, Size, and Type. If it is not enough, a

specific NDEF type must be implemented.

Local Containers may have a permission policy which allows only

a particular user to pick/drop files from/to it. For example, in a

Figure 2. Touch & Share Architecture.

museum, only the staff can drop files in the Local Containers.

Museum visitors can only pick files. In addition, the museum

might offer some premium service, in which some premium

material is available only to users who have paid some extra fee.

In this case, users who did not pay cannot pick any files from the

premium Local Containers. There is not yet any standard for

providing authentication in RFID tags. However, many RFID tag

chips allow encryption. For example, Mifare 1K, Mifare 4k, and

DesFire tags allows including secret keys in the tags when they

are programmed. Only RFID readers who have the key(s) are able

to read or write such tags. Using those keys we can establish a

permission policy. As in a UNIX system, tags may have read or

write permissions for all users in the system, a group of users, or a

particular user. A user may have one private key for reading and

one private key for writing files in a local container. All members

of a group have the same group key. The possession of a key

depends on the user rights and the implementation. For example, a

premium user needs the premium-group read key to access

premium files from the containers. Keys are stored in a key store.

Access to the key store must be safe, and the user can get a set of

keys only after the authentication. Information about user name

and group are obtained from the User Profile (stored in a Personal

Container).

RFID tags are attached to the local environment, on objects, or on

their representations (photos, for example). Tags are located

behind icons identifying the services the tags offer. The icon

advertising a service depends on the concrete application that uses

the containers and the permissions of the file. In Figure 3, we

propose three different icons: The first one is used for local

containers with read and write permissions and the second one for

containers allowing only reading. The third icon can be used when

the possibility to write is emphasized.

Figure 3. Icons for Local Containers.

The Personal Container stores all user-related information. It is

composed of the User Profile and the Reference Container. The

first one stores general information like name, password

(encrypted), group, permissions, and personal data. The User

Profile can access the personal keys of the user located at the Key

Store (using a secure connection). The Reference Container is a

set of references (i.e. URIs and metadata) to files that the user can

access. The structure of the Reference Container is the same as the

that of the Local Container, or in other words, a set of file

references. A user has access to her own Personal Container only,

so an authentication mechanism is used to retrieve Personal

Container information.

The System Administrator module offers the possibility to modify

users’ profiles and delete references from Personal Containers.

The administrator may also create new users, modify any user

information, and manage files.

The Pick&Drop client is the interface between a Local Container

and a Personal Container. The Pick&Drop client has several

responsibilities. Firstly, it authenticates the user into the system by

means of a login name and password. Secondly, it maintains a

local copy of the Personal Container. The cache for the Personal

Container is obtained from the system once the user has been

authenticated. This cache is created to make the system faster and

more reliable. The user does not need to establish a network

connection to the server every time she desires to pick or drop a

file. Besides, the user can check file information without the

necessity of accessing the network. For example, she can check

how many files she has stored during her museum visit. The user

can also delete undesired references. As the same entity is

maintained at two different places, at a terminal and at the server,

a synchronization operation is needed. This operation is ordered

always by the Pick&Drop client. Synchronization may be

performed periodically, triggered by an event (for example when a

new user has logged in), or commanded by the user. Finally, the

Pick&Drop client performs pick and drop operations, that is, it

reads and writes NDEF records from/to the tag. To pick and drop

files from protected containers, the client must access the key

store and get the user’s keys.

The Authentication and Key Store system stores the keys

associated to a user. A user only has access to her own keys. It

also identifies users in the system and keeps session ids. When a

user needs to access protected resources like Personal Containers

or private keys, the corresponding client must first authenticate in

the system. A secure connection might be needed to collect some

critical data such as keys.

The File Repository stores the media files. Either the file or an

URL identifying the file’s location in the Internet can be stored.

Every media file has one owner and one group owner. File

repository offers two different interfaces to interact with files in

the system.

The File Retrieval Interface is utilized to access and open files.

Users can retrieve/open the files for which they have read

permissions. Furthermore, this interface adapts the file to the

physical constraints of the calling device (using the CC/PP). A

request to retrieve a file contains a file id and a device profile as

parameters. The File Retrieval Interface authenticates the user and

checks if the requested URI is in this user’s Personal Container. If

this process is successful, the system retrieves the physical file,

adapts it according to device constraints and serves the file to the

device.

The second interface is the File Upload Interface. This interface

allows users to upload and modify files in the system. Only the

owner, users belonging to the group owning the file, and a system

administrator can remove or modify uploaded files. Only

authorized users can upload files to the system, so authentication

is needed. When a file is uploaded, this interface stores the file

(including metadata like owner and group) to the File Repository.

If a group is specified, the file is stored automatically in the

Personal Container of all group members.

Note that the mobile phone terminal in this application can act as

a Pick&Drop client, as a File Retrieval client, and as File Upload

Client.

2.2 TiPo Application

2.2.1 Implementation We have implemented a Touch & Share system prototype. It

contains almost all entities described in the previous section but

some of them are simplified. The goal of the implementation was

to verify the feasibility of the system. More detailed description of

prototype implementation and application functional behavior can

be obtained from [22].

Our first prototype is called TiPo. This application has been

installed in the Zoological Museum located at our premises and

tested by more than 300 pupils from different schools of the city.

More details about testing are given in section 3.

The clients communicate with the server using the HTTP

protocol. TiPo application accepts four kinds of files: html pages,

audio (mp3), video (3gp), and images (jpg, gif, png). It has three

kinds of users: administrators, registered users, and anonymous

users. Administrators are the only ones who can upload files to the

system and drop content to Local Containers. Registered users can

pick files and retrieve them from their Personal Containers.

Finally, anonymous users can pick files, but the Personal

Container is not in the network, only in the Pick&Drop client

(they only have a local copy). A basic authentication mechanism

was used to identify the user and associate the user to a HTTP

session. No encryption was utilized.

Local containers are Mifare 1K tags. We use our own Record

Type to store data information in the tag. The record consists of a

NDEF message which contains six different records: file URI

(unique id which identifies the file in the system), type (mime

type for this file), size, creation date, owner, and description. All

the records use ASCII text codified in UTF-8. Figure 4 shows the

NDEF message encapsulation.

Main NDEF message

NDEF record

(File Reference 1)

NDEF record

(File Reference 2) … NDEF record

(File Reference n)

NDEF record

(URI)

NDEF record

(type)

NDEF record

(size)

NDEF record

(date created)

NDEF record (author) NDEF record (description)

Figure 4. NDEF message encapsulation.

We did not use any kind of key or encryption in the tags. To avoid

users from dropping material, we created two different

Pick&Drop clients. The administrator client is able to write data

in the tag, while the other can only read data from the tag.

Pick&Drop Client was implemented as a J2ME application in

Nokia 6131 NFC mobile phone. This mobile phone provides an

RFID reader and a programmable API based on JSR-257 standard

to interact with NFC compatible RFID tags. It uses GPRS data

bearer to connect with the main server. The user must authenticate

herself by inserting login and password before starting the

application. Cache for the Personal Container is stored in the

RMS registry as well as basic user information. RMS offers

persistent data storage for J2ME applications. Hence, a local copy

of the Personal Container is always kept in the mobile phone,

even when the application is closed. The local copy is deleted

only when a different user logs in. By default, users synchronize

their Personal Containers manually, choosing the corresponding

option in the application menu. Users can choose from the

Personal Profile, if automatic synchronization is done when the

application starts or when a new file is picked. During

synchronization, the local copy of the Personal Container is sent

to the server. The server compares the local copy with the server

copy, and sends back a list of references that must be deleted or

added in the local copy.

All server side has been implemented using Java Servlet

Technology using Tomcat as servlet repository. File repository is

a folder in our server machine. The system has for each user a

separate text file, containing User Profile and Personal Container

references. Each reference contains the same fields as the records

at the local container.

The system offers a web based interface for users to access their

Personal Containers: to retrieve stored files and to delete

undesired files. The administrator has also a web based interface

to upload files into the system. Those files can be dropped into the

Local Containers. The administrator can also create and modify

user data. Both File Retrieval Interface and File Upload interface

are implemented using JSP technology.

Users can open files from the Pick&Drop client. When a user

requests a file, the Pick & Drop client is closed and the phone’s

browser is used to present the file. The client needs to be closed

due to the 6131 terminal’s software limitations. Simple content

adaptation is used. Small files (maximum 100KB) are presented

straight to the user in the web browser. The user can optionally

download the file to the mobile phone memory. For bigger files or

files that cannot be seen directly on the mobile phone browser, file

information is presented on a web page. A link to download the

file is provided on that page. Files are stored in the phone’s

memory and can be opened using external phone applications.

2.2.2 Pick&Drop client functional behavior User may start the Pick&Drop client either manually or by

touching any of the museum’s RFID tags. Authentication is

required, but the authentication data might be stored in the RMS if

the user has used the application before. After that, a menu with

possible commands is shown.

The Pick command allows the user to read file references from an

RFID tag. When this command is activated, the RFID reader waits

to read a tag. When the user touches a tag and its contents have

been read, the display shows the list of the references read from

the tag. The user can choose the files to be stored in the Personal

Container.

The Drop command is only available for the administrator. It

opens a multiple choice selection list with all the references

contained in the local copy of the Personal Container. When a tag

is touched, all selected references are written to the tag and all

previous references are deleted from the tag.

The My documents command presents on the UI a list the files in

the Personal Container. When a file is selected, information about

the file and a button to retrieve this file to the mobile phone is

presented on the UI. The Synchronize command performs

synchronization between the local copy of the Personal Container

and the one stored in the system server.

3. USABILITY TESTING

3.1 Museum installation The museum has a big collection of stuffed animals. We located

22 Local Containers at the museum. Each container was

associated to one animal. The containers store images, sounds,

and web pages related to the target animal. Every tag was

advertised by an icon otherwise similar to the one shown in Figure

3 in the middle, but the name of the animal was added in each tag.

Figure 5 shows some pictures of the system installed at the

museum. On the top-left, a user is picking some files related to

hawks. On the top-right, a user watching an image of a lynx on

the mobile phone’s screen, and at the bottom, a user is interacting

with a moose.

3.2 Test procedure The system was tested by three user groups: (a) 7 our city’s

representatives interested in the application, (b) 29 people with

very diverse background who tested the application during the

Science Days of our university, and (c) more than 300 pupils from

local schools. Ages of the pupils vary between 9 and 13 years. We

lent phones to the users for the tests.

Users came to the test event in groups. If the number of users was

bigger than 16, we created groups of 2-3 users (we only had 16

phones available). Each group had one hour to perform the given

tasks. We started by introducing the application, then provided the

material and gave each group a set of tasks to perform. To

perform the tasks, the users had to use all features of the

application. Finally, we invited the user to fill a questionnaire

about their background information and user experience.

Figure 5. Museum images.

We kept the user accounts active after the tests, so they could

access the picked material from their own computers. Finally, we

plan to send to teachers a questionnaire to find out their

experiences of the visit to the museum. We are interested in

knowing if they have used collected material in their own teaching

activity and how we could improve the system.

The tests performed by groups b and c have not yet been

analyzed. The city representatives graded TiPo with a mark of 4

or more (over 5 points) in the 90% of the cases. The application

worked as expected for all the subjects, and 80% of the users

reported rather to use this system than the classical paper

brochure. [22] Further results will be published in a future paper.

4. DISCUSSION AND RELATED WORK In this paper, we present a design and implementation for a

system sharing media content in everyday environment. Several

authors have proposed systems to retrieve files from the

environment, especially as museum guide applications. D’Souza

et al. [4] present a protocol to download files to mobile devices

with limited capacity using Bluetooth. Servers located at the

museum serve files using this technology. PhoneGuide [3] allows

the visitors of a museum to get information from a particular

object. Targets are selected by taking photos; objects are

identified using image recognition and Bluetooth tracking.

Information is delivered to the terminals via Bluetooth. The

SnapAndGrab [11] system is used by taking a photo of a visual

key shown on a public display. The photo is sent via Bluetooth to

a server which then sends back via MMS the files related to the

key in question. However, none of these solutions offer a

centralized or distributed file repository for storing files. Hence,

users must open the file in the same device they used for

retrieving it. None of the systems allow sharing data between

users either. From the proposals for ubiquitous storage systems

(CriStore [10], UbiData [18] and OmniStore [8]), only CriStore

allows sharing data between several users. Furthermore, none of

these three systems are integrated in the environment, which is the

case with Touch & Share

Want et al. was the first author who sketched in [23] how RFID

tags could be used as physical container of documents linking the

RFID id number with a web link. We have developed a more

complex system beyond this idea, providing a structure which

allows storing several files in the same RFID tag. Furthermore,

the metadata inserted in the tags allows clients to have

information related with the file without the necessity of a

network connection.

DroPicks [7] is the most similar system to Touch & Share.

DroPicks uses RFID readers to augment objects. A client in the

user terminal allows inserting metadata information to that object.

This metadata information can be read by others. Objects are used

just as digital memo boxes. In Touch & Share, objects are

augmented with tags and readers are integrated in the user

terminals. Furthermore, Touch & Share is a more focused system

and stores media files’ information in RFID tags.

Kindberg et al. [9] have suggested a general approach of placing

hyperlinks in the environment. Schwieren et al. comment in [16]

how RFID tags can be transformed in physical hyperlinks for

mobile applications. In Touch & Share, system tags contain a set

of file identifiers (URIs) plus corresponding metadata associated

to that file.

The Touch & Share system enables many different applications,

for example, a file sharing application for an office environment.

A local container might be located near a conference room’s

doorway and speakers could drop their presentations into the

container. Attendants could pick the presentations when coming

in. In other scenario, local containers might be attached near every

office’s doorway plates. The office owner could drop documents

that she wants to share with her colleagues. The colleagues could

also drop files that they want to share with the office’s owner. In

this case, a permission policy is needed: only the owner can pick

files left by others while everybody can pick files dropped by her.

An easy way to implement this is using two different containers:

one to pick files left by the office owner and the other to drop files

to her.

We have shown that the system is feasible by creating a real

implementation for the application (TiPo) and testing it with a

large amount of users. User response was encouraging and many

of the users were excited by the application. However, this first

prototype needs to be improved in many ways. Tags we use allow

storing only 1 KB of information. Each reference contains a file

URI and some metadata. Even with that, we could store only a

maximum of five references per tag. We could reduce the size of

the URI (currently we are using complete URLs) and the amount

of metadata until tags with larger capacity become available.

The poor performance of the GPRS network decreased the

usability of the tested application. In some cases, the users had to

wait for 40 seconds to download a photo to a mobile phone.

Furthermore, synchronization process took sometimes more than

30 seconds. One solution would be to use Bluetooth for

communication, but this is against our “infrastructureless”

principle. Wi-Fi could be a solution, but currently there are no

mobile phones in the market with both Wi-Fi and NFC

capabilities in the same phone.

In the future, we need to improve also the access policy and create

an infrastructure for managing keys to limit Local Container

access. Improvements are needed as well in the Personal

Repository’s data storing solution (currently we are using plain

text) and in some of the interfaces. Some of the users commented

that it could be nice to upload their own personal images from a

mobile phone to a Local Container. In other words, an interface to

upload files using a mobile phone is desired.

5. CONCLUSION In this paper, we have proposed a system for sharing files between

users. This system is completely embedded in the environment.

Files can be dropped to the environment and picked from the

environment with a mobile phone that is equipped with an RFID

reader. We have successfully implemented a first prototype a

zoological museum. Although the prototype does not implement

the whole Touch & Share application and there are still some

improvement areas, usability tests with over 300 test users

indicate that Touch & Share has a great potential.

6. ACKNOWLEDGMENTS We would like to acknowledge everybody who has collaborated

in the usability test: Jouni Aspi, Tuula Pudas and the rest of the

staff of the Zoological Museum who prepared the material and

helped in the organization; Hannu Rautio and Jukka Kontinen

who helped us with the equipment and technical issues; Marta

Cortés, Timo Saloranta and Mikko Pyykkönen who were assisting

the pupils during tests; City of Oulu which inform local schools

about our application. We are also very grateful with teachers

who came with their students and of course we thank all pupils

who have tested the application.

7. REFERENCES [1] Ailisto, H., Pohjanheimo, L., Vlkkynen, P., Strmmer, E.,

Tuomisto, T., and Korhonen, I. Bridging the physical and

virtual worlds by local connectivity-based physical selection.

Personal and Ubiquitous Computing 10 (2006), 333-344.

[2] Arnall, T. Spatial memory: marking in urban public space. In

UbiComp in the Urban Frontier, in conjuction with UbiComp

2004 (2004),pp. 34-35.

[3] Bruns, E., Brombach, B., Zeidler, T., and Bimber, O.

Enabling mobile phones to support large-scale museum

guidance. 16-25.

[4] D'Souza, M., Postula, A., Bergmann, N., and Ros, M. A

multimedia guidebook implementation using a bluetooth

wireless information point network. In WMASH '05:

Proceedings of the 3rd ACM international workshop on

Wireless mobile applications and services on WLAN

hotspots (New York, NY, USA, 2005), ACM, pp. 33-38.

[5] Garner, P., Rashid, O., Coulton, P., and Edwards, R. The

mobile phone as a digital spraycan. In ACE '06: Proceedings

of the 2006 ACM SIGCHI international conference on

Advances in computer entertainment technology (New York,

NY, USA, 2006), ACM, p. 12.

[6] Hardy, R., and Rukzio, E. Direct touch-based mobile

interaction with dynamic displays. In CHI08 Workshop

(April 5th 2008). Available at

http://http://eis.comp.lancs.ac.uk/multitag/Publications/Direct

TouchBasedMobileInteractionWithDynamicDisplays.pdf,

last visit 4-06-08.

[7] Hosio, S., Kawsar, F., Riekki, J., and Nakajima, T. Dropicks

a tool for collaborative content sharing exploiting everyday

artefacts. In Proceedings on 4th International Symposium

onUbiquitous Computing Systems UCS07 (Germany, 2007),

vol. 4836/2007, Springer-Link/Heidelberg, pp. 258-265.

[8] Karypidis, A., and Lalis, S. Omnistore: a system for

ubiquitous personal storage management. In Proceedings of

the 4th Annual IEEE International Conference on Pervasive

Computing and Communications, 2006. PerCom 2006

(March 13 - 17 2006), IEEE, pp. 136-147

[9] Kindberg, T., Barton, J., Morgan, J., Becker, G., Caswell,D.,

Debaty, P., Gopal, G., Frid, M., Krishnan, V., Morris,H.,

Schettino, J., Serra, B., and Spasojevic, M. People, places,

things: Web presence for the real world. Mobile Networks

and Applications 7 (2004), 365-376.

[10] Lee, H., Song, Y., Kim, K., Kim, D., and Park, D. Cristore:

dynamic storage system for heterogeneous devices in off-site

ubiquitous communities. In SAC '07: Proceedings of the

2007 ACM symposium on Applied computing (New York,

NY, USA, 2007), ACM, pp. 1146-1150.

[11] Maunder, A. J., Marsden, G., and Harper, R.

Snapandgrab:accessing and sharing contextual multi-media

content using Bluetooth enabled camera phones and large

situated displays. In CHI '08: CHI '08 extended abstracts on

Human factors in computing systems (New York, NY, USA,

2008), ACM, pp. 2319-2324.

[12] Riekki, J., Salminen, T., and Alakarppa, I. Requesting

pervasive services by touching RFID tags. Pervasive

Computing, IEEE 5, 1 (Jan.-March 2006), 40-46.

[13] Riekki J., Sánchez I., and Pyykkönen M. Universal remote

control for the smart world. In Proceedings of 5th

International Conference on Ubiquitous Intelligence and

Computing, UIC 2008, pages 563-577, Oslo, Norway, June

23-25 2008.

[14] Sánchez, I., Cortés, M., and Riekki, J. Controlling

multimedia players using nfc enabled mobile phones. In

MUM '07: Proceedings of the 6th international conference on

Mobile and ubiquitous multimedia (New York, NY, USA,

December 12 - 14 2007), ACM, pp. 118-124.

[15] Sánchez, I., Riekki, J., and Pyykknen, M. Touch & control:

Interacting with services by touching RFID tags. In

Proceedings of the 2nd International Workshop on RFID

Technology - Concepts, Applications, Challenges (IWRT 08)

(June 12 - 13 2008).

[16] Schwieren, J., and Vossen, G. Implementing physical

hyperlinks for mobile applications using r_d tags. 11th

International Database Engineering and Applications

Symposium, 2007. IDEAS 2007 (Sept. 2007), 154-162.

[17] Weiser, M. The computer for the 21st century. SIGMOBILE

Mob. Comput. Commun. Rev. 3, 3 (1999), 3-11.

[18] Zhang, J., Helal, A. S., and Hammer, J. Ubidata: ubiquitous

mobile _le service. In SAC '03: Proceedings of the 2003

ACM symposium on Applied computing (New York, NY,

USA, 2003), ACM, pp. 893-900.

[19] NFC Forum. NFC Forum Type 3 Tag Operation

Specification. Accessible from http://www.nfc-

forum.org/specs/. Last access 09-06-08

[20] NFC Forum. NFC Data Exchange Format (NDEF).

Accessible from http://www.nfc-forum.org/specs/. Last

access 09-06-08

[21] NFC Forum. Smart Poster Record Type Definition.

Accessible from http://www.nfc-forum.org/specs/. Last

access 09-06-08

[22] Rousu, J. Virtual File Repository for Mobile Phones. Master

Thesis. Department of Electrical and Information

Engineering. University of Oulu. May 2008. Available at:

http://www.ee.oulu.fi/research/isg/publications/ID/1209. Last

access 07-10-2008.

[23] Want, R. , Fishkin, K., Gujar , F., Harrison, B. Bridging

physical and virtual worlds with electronic tags, Proceedings

of the SIGCHI conference on Human factors in computing

systems: the CHI is the limit, p.370-377, May 15-20, 1999,

Pittsburgh, Pennsylvania, United States.