©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
2 Nokia
Oyj, Devices.Yrttipellontie 6, 90230 Oulu, Finland
[email protected]
{ivan.milara, jukka.riekki, susanna.pirttikangas}@ee.oulu.fi
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 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.
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
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.
2.2 TiPo Application
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.
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].
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.1 Implementation
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 (URI)
NDEF record (File Reference 2)
NDEF record (type)
NDEF record (author)
…
NDEF record (size)
NDEF record (File Reference n)
NDEF record (date created)
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.
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.
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.
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.nfcforum.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.
