©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
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.
Top Related