A Fixed NFC Payment Terminal for the Event-Wallet on an Android Tablet

Tags: system, transaction, payment system, payment systems, Marc Ceulemans, Karel Renckens, Frederik Schrooyen, Rud Beyers, technology, eWallet, Field Communication technology, Luc Wante, NFC reader, Android tablets, electronic wallet, JSON file, terminal, open source project, open-source project, Android OS, serial communication, NFC Payment Terminal, User Interface, tablet computers, passive tag, comparison, mobile terminal, Field Communication, mobile terminals, NFC technology, Event-Wallet, Glenn Ergeerts, shared library, authentication mechanism, default event, configuration files, M. Ceulemans, nfc payment, Paul Butterworth, available products, DESFire, event organizers, Android Tablet, stationary terminal, electronic payment terminal, payment terminal, Koray Sels
Content: A Fixed NFC Payment Terminal for the Event-Wallet on an Android Tablet. Koray Sels, Frederik Schrooyen, Glenn Ergeerts, Rud Beyers, Karel Renckens, Marc Ceulemans and Luc Wante Abstract--Research was conducted on how to implement an electronic payment terminal, by assuming a stationary terminal located at predetermined places on the event terrain. The Event-Wallet (eWallet) will use Near Field Communication technology that allows the user to purchase items or services by using a passive DESFire card or a smartphone. This paper proposes a way for a low-cost fixed terminal solution and validates the advantages and trade-offs of a fixed terminal as opposed to other solutions. The result will be an integrated device with an easy to use graphical user interface (GUI), using low cost hardware i.e. an Android tablet in combination with a wired NFC reader/writer that will provide LCD screen feedback to the customer. Index Terms--Near Field Communication, RF-ID, Event Wallet, Android, ViVOtech R !
1 INTRODUCTION In recent years, there has been a dramatic increase in technological integration and automation. Progress in this field is stimulated by support from outside, young people using smartphones and tablets. The way they behave and interact with each other are affected by new technologies. One example is virtual payment. A significant number of people now prefer to shop on-line using a credit card or safe payment system such as Paypal or iDeal, rather than shopping locally in stores. Consumers who are familiar with virtual payments may find it inconvenient and time-consuming to make purchases at social events using more traditional forms of payment, such as cash, drink/food tickets and tokens. Most of the time, event organizers will offer their customers drink and food tickets at fixed checkout points spread across the event's perimeter. This system can become congested when a lot of visitors wanting to buy tokens all at once, they become frustrated and will make less purchases because they feel like they are wasting their time not having fun. Visitors have difficulties finding the cabins where they can buy tokens and the waiting lines are often too long. However, there are some other drawbacks regarding management and control. The current system is not secure and vulnerable for fraud. Tickets are lost, bartenders forget to deposit the received tickets in safe boxes or worse. This is not only a safety problem, but also a quantification problem when at the end everything has to be counted or weighted. Surveys conducted at large and small events point Koray Sels,Glenn Ergeerts, Rud Beyers, Frederik Schrooyen, Marc Ceulemans and Luc Wante are with the University College of Antwerp, dept. IWT­ Electronics-ICT, Paardenmarkt 92, 2000 Antwerp, Belgium E-mail: see http://www.e-lab.be/ Karel Renckens is founder and owner at 1OK Solutions, Project manager at ITS Belgium and Smart Grid Flanders. E-mail: see http://www.1oksolutions.com/
out that organizers and customers are keen to explore new territories. NFC technology [1] appears to offer a safe payment experience. The main purpose of NFC is to address all the problems mentioned above and enhance event environments with easier and more reliable payment systems. NFC technology (Near Field Communication technology) is a short range secure wireless communication system between two devices, where one device can be a passive tag. This technology is already widely used in the form of RFiD (Radio Frequency Identification) smart-cards and readers [2], [3]. NFC may improve the paying experience [4], but still imposes decisions between a static payment terminal and mobile terminals. A terminal is needed off course to interact with the NFC device. This research focuses on the fixed terminal approach, using low-cost hardware like Android tablets in combination with a wired NFC reader. A fixed terminal is a payment system that will not be portable but mounted at fixed points spread across the terrain. 1.1 Main goal The goal is to achieve less queuing and faster order processing, to make visiting an event more enjoyable for the customers and to make a barkeeper's job more productive whilst keeping the quality of service. A single object of value will replace the physical wallet in the form of an electronic wallet, or eWallet, embedded in the secure element of a smartphone. This valuable object will serve as a host for different events with dedicated offline funds actually stored on a passive tag or mobile phone/smartphone [2], that people can use to pay at events without exchanging physical items of value. This system has the possibility to function properly without requiring a network connection, the values are stored
in the eWallet itself. Less or even no connection with the unsafe internet means greater stability and security which are both requirements to ensure the system's integrity. While this thesis's result will be an electronic terminal system that can easily be operated to decrement and increment money or credits from customers' eWallets at large events, it will also accommodate secure data synchronization with the back-end server. This data will be used to generate status updates and will provide the fine grained control that an organisation needs. In the short term, inexpensive passive tags can be used in the form of cards or wristbands, but the future lies in the assumption that eventually everybody will be equipped with a smartphone with at least a secure element that can be accessed through NFC. A list of existing systems and alternatives can be found in [3].
is happening with their credit. Feedback is supplied via the embedded LCD display present in the ViVOtech R ViVOPay5000 (Figure 1). Using the on-board LCD display the client can verify the amount to be paid and the eWallet's remaining balance on the screen. The aim is to provide a trust-able environment where visitors can remain in control of their funds.
2 NEAR FIELD COMMUNICATION This technology is becoming increasingly important with big events and organizations already offering NFC capabilities to their customers [5], [6]. Comparing NFC to other wireless protocols like Wi-Fi or Bluetooth, its data rate is slow, with a maximum data transfer speed of 848 Kbit/s , less than a quarter than that of Bluetooth. However there are several advantages which makes this technology the perfect candidate for electronic payment. Apart from its great security possibilities, it does not need any 'pairing' procedure and is nearly effort-free, requiring nothing more than a tap. The NFC chip can read out information, emulate a smart card so that a reader can access its data or communicate directly with another NFC device. 2.1 The eWallet The electronic wallet consists of several different applications, one for each event, with specific ID's and it's own personal security settings, integrated in a MiFare DESFire card or any other card that can emulate a DESFire card, e.g. Java Card or a secure element in a smartphone. Within an application, different types of files may exist, like a data file, or value file. The wallet can contain the users' information and credit amount and/or tokens. This means the values are actually stored on the card itself and no internet connection is required to perform operations. Further development is ongoing but remains out of scope for this research.
Fig. 1: A finished transaction with user feedback on the terminal 3.1.2 Terminal concept Bartenders at events like to have a simple and intuitive till system on which they can rely to process individual orders. Therefore the choice has been made to use a touch-based interface with a large screen. The price tags of recent tablet devices keeps getting smaller, the market is flooded with under low-cost tablet computers running on the open-source Android OS. For this research we chose for the Acer Iconia A200 tablet. This choice is based on the basic requirements to communicate with the reader over USB and because of the 10inch display. In Figure 2 we can see the set-up that was used to achieve this.
3 DEVELOPING A FIXED TERMINAL 3.1 Hardware 3.1.1 NFC reader with client-user feedback The RFiD reader/writer used in this research is the ViVOtech R ViVOPay5000. The advantages and disadvantages of a separate reader are discussed in section 6.1. User feedback is important, clients who are paying with next-generation NFC systems want to know what
Fig. 2: The proposed set-up with a tablet running the terminal software and the ViVOPay5000
3.2 Software In terms of software many implementations come to mind , like Windows CE R or one of many Linux distributions. The choice was made to base the entire terminal on the Android OS, which is an open source project and one of the fastest growing mobile operating systems for tablets as well as smartphones. Programming on an Android device requires the use of the Android SDK, which is based on the Java programming language. This project will be using Eclipse IDE to write and debug the code. The advantage that set this approach apart from an embedded system is the autonomy of the Android OS. It is a fully incorporated device that has all the tools at hand and already has a wide user/Developer community. The tablet has to be reliable, because it will be the core of the system, meaning it will take care of calculation, code-frame wrapping, serial communication and terminal visualisation. It will control the ViVOtech R to display messages, manage the on-board buzzer and LEDs and transceive contact-less data. 3.3 Tablet and NFC reader interfacing One of the challenges was to achieve a solid communication between the Android-driven tablet and the serial controlled RFiD reader. To achieve this, the tablet has to be equipped with a USB host feature and must have a compatible kernel driver (or the kernel source available) to interface with a PL-2303 USB to serial chip (Figure 3). For the application to write to the serial port, root access to the file-system is needed. When all of the above requirements were met, we started to implement an open-source project which supplied decent API hooks for usb-to-serial communication [7].
3.4 Multi threading Communicating with the ViVOPay5000 requires a set of command frames to be transceived according to the ViVOtech R Serial Interface Developers Guide [8]. Currently there is no library available for Android, so all the commands and protocols to use the device as a external RF-ID reader/writer were ported to work with the Java for Android programming language. A common mistake is to execute all code in one thread, namely the UI thread (User Interface thread). In this case all the command frames have to be sent to the serial bus and there will always be a slight delay before an answer is received, during this delay the UI thread will be blocked and become unresponsive. Especially when more than one command needs to be sent and received. Multiple threads are used to prevent these blocking function calls. This will be accomplished using AsyncTasks [9]. 3.5 Designing a graphical user interface One of the bottlenecks observed at food or drink stands is the lack of a decent and fluent terminal system for the barkeepers. A complicated user interface can cause critical queue lengths. Therefore design decisions must be taken and applied to form a speedy alternative compared today's solutions. The user interface (GUI) will be designed to work on Android tablets with touch based controls and consists of four pages and a Quit button: Sales, Charge, History and a Home page if the logo is pressed.
Fig. 4: The Sales view on the terminal screen with the insufficient funds notification
Fig. 3: Android to ViVOPay5000 connection scheme
3.5.1 Sales On the Sales screen, there are three distinctive zones. The shopping cart, the button hierarchy and the main controls are displayed as in (Figure 4). The controls are self-explanatory with the names Consult, Empty Cart, Undo and Checkout The button hierarchy and its dynamic capabilities are explained in more detail in section 5.1. This is the main operating screen. When a customer
wants to order drinks or food, the bartender presses the right buttons and the shopping cart is automatically updated to represent the customer's order. When the order is complete, the bartender presses Checkout and waits for the customer to tap their eWallet against the reader. Feedback whether or not the payment succeeded will be given on both the tablet and the reader (Figure 1). 3.5.2 Charge This page will allow the terminal to be used as a simple 'Point Of Sale' (POS) system, meaning customers can pay with cash in exchange for credit on the eWallet they own. All charging activities that were made are logged and displayed here. More about logging in section 5.3. 3.5.3 History When debit transactions are made (i.e. the bartender sold a product), they are logged and displayed here. A typical log for one transaction will contain a time and date fr the transaction that has been made, completed with the respective item ID, current event ID and a 7 byte string value which uniquely identifies every eWalet. If one order contains more than one item that are not the same item, multiple records with the same timestamp and wallet ID are made, each for one specific item in the order. The exact functionality of the logging will be explained in section 5.3 . 3.5.4 Home The Home page contains a message notifying the user when the last configuration file was downloaded, together with a button that will start the preferences activity. The preferences activity is a special activity where all preferences are stored and where the configuration file can be downloaded, it also supplies a simple button that activates the transaction logging synchronization described in section 5.3. It will maintain its stored data, even when rebooting the tablet. When setting up the terminal a configuration file has to be downloaded. 3.6 Communication with the e-wallet In order for all the components in our set-up to communicate with each other, the APDU frame format is used. APDU stands for Application Protocol Data Unit, and is defined by ISO/IEC 7816-4. 3.6.1 APDU exchange When communicating with a secure element or a tag, APDU messages have to be exchanged. To perform a payment action on a DESFire card, an APDU frame containing the event specific application and the location of the value file, where credits are stored, is wrapped together with a decrement command [10] in an ExchangeContactlessData command [8] and sent to the ViVOPay5000 device, which in his turn unwraps the latter and sends the APDU frame to the card. The card will then decrease the value stored in the corresponding value file and returns a response.
3.6.2 Authentication All transaction steps, including the above (3.6) transactions need to be as secure as possible. To avoid counterfeiting, fraud and the risk of compromising the system, an authentication mechanism must be in place before any file located on the DESFire card can be accessed. To authenticate, a 16-byte key is used and also depends on the chosen security settings. The process uses a handshaking protocol with unique keys for each side of the transaction. More information can be found in [10] 4 SHARED LIBRARY As the research went along it became clear that a lot of logic can be made generally available to other terminal implementations [11]. Some features worth mentioning include the complete backend synchronization logic together with the local database mechanism. Also the JSON parser and object classes used to decode the configuration files were included in this library together with a set of command that can be generated to communicate with the DESFire tags. All shared functionality could be updated and implemented on both mobile and fixed terminals which saved a lot of time. 5 BACK-END SERVER Accompanying the application, a back-end solution is proposed [12] for the monitoring and setting up the complete event. Each user can have multiple events and/or configurations. When the user logs in, he is presented with all events (past and future) and can freely modify and create events. Every user can have its own array of products which he can choose from the standard set or create his own. All events have their own start and end date or can be chosen as the default event to switch to when no other events are active (needed for example in a club environment). Each event will have multiple terminals available, spread across the perimeter. For easy set-up, a configuration file can be downloaded from the back-end server. A user can create as many configurations as he likes for each event. 5.1 Configuration file architecture Each configuration consists of 5 critical base elements, name, menus, keys, timestamp and event-id. For convenience this information is stored in a JavaScript Simple Object Notation file (JSON) and parsed on the device itself. 5.1.1 Parsing JSON data for an adaptive menu layout When an event is created on the back-end, the configuration file is automatically generated on the server. If a terminal connects to the back-end with its unique personal ID and the login details of the event owner, the server will search for an active event associated with that terminal and return the configuration file. The project's library has all the tools needed to download this file to
the SD-card and extract all necessary data. Storing this file locally on the SD-card enables the use of the same configuration file, for example if the event is running for a longer period of time, without requiring to download the file every time the application is restarted. For each product that the parser finds in the JSON file, an instance of the Product object is created and initialized. A custom button adapter will then list all available products in large buttons and will dynamically add different views in the Menu zone for every sub-menu that was defined. 5.1.2 Other attributes The keys attribute contains two values, a debit and a credit/debit key. If only the debit key is given, then the terminal will only function as a debit machine. When both keys are found, the terminal automatically enables the POS features. The menus item is a JSONArray with n elements, where n is the number of hierarchical menus that were chosen by the user. Each menu inside menus contains an array of the products with all their properties.
that is stored in the database will be treated as a new record that still has to be synced. When the syncing process starts in a separate asynchronous background thread, the terminal will check if there are any such new records and will parse them into a JSON string together with the unique android ID, which in his turn is posted over HTTPS to the back-end. The records will then be updated to 'already synchronized'. In real life, the syncing process will automatically try to connect every 15 minutes. This time interval is chosen by the user in the preferences menu. The main reason not to erase the database after a successful syncing task is to maintain an overview of sold items on each device separately. 6 FIXED VERSUS MOBILE The fixed terminal was developed alongside a similar system based on an NFC enabled smartphone that shares almost the same functionality. Section 6.1 will explain differences and similarities found between the two systems.
One of the reasons the JSON file structure was chosen instead of XML or some other structural language, is the amount of data overhead. JSON is a very simple notation format with great flexibility regarding to nesting objects and arrays. JSON has the ability to add objects in an array without having to know how many elements it will contain, which is harder to achieve in XML. This flexibility to get data structured and organized in a fast and reliable manner and the Android SDK providing native support for encoding and decoding JSON were all factors in this decision. If the JSON string is modified or incompletely received, the parser which is included in the shared library can not use the data, which ensures authenticity of the system. 5.2 A secure communication channel Valuable data is being sent over the increasingly insecure internet. Steps had to be taken to ensure the safety of the connection. Interaction between user and back-end as well as all syncing threads on the terminals which deal with communication with the back-end, be it sending data or requesting data is secured with a Hypertext Transfer Protocol Secure (HTTPS) implementing a Secure Sockets Layer (SSL) handshaking system using asymmetric cryptography for key exchange, symmetric encryption for privacy, and message authentication codes for message integrity. These specifications have to be met or all synchronization attempts will fail. 5.3 Transaction logging and synchronization Section 3.5.3 listed the elements that where necessary to conduct transaction logging, however it does not explain the logic behind it. All loggings are stored locally in an SQLite 3 database system. Every sales or credit record
6.1 A comparison One of the key features that set the fixed approach apart from the mobile implementation is user feedback. It is important to let visitors know how much credit they have left at all times. After testing in section 6.2, the visitors responded positively, but did have a comment regarding the balance or their eWallet. When a payment system like this is implemented, the visitors like to know how much credit they have left on the eWallet, this is especially important if the eWallet is implemented on a card which does not have the functionality to display the contents on its own. There was one consult-point present, but still this was not enough for all these customers. Therefore, an independent consultation feature is added to the fixed terminal in a way that no user interaction is required. The system will automatically keep polling for tags and if a valid eWallet is found, it will display the current values stored on the eWallet. Another feature specific to the fixed terminal is the Undo button which allows to remove the last chosen product from the list with a memory that will go all the way back to the first chosen product. This will come in handy if a mistake is made entering a large order, without this feature the bartender would have to clear the entire shopping list and start over. Bartenders can enjoy a beautiful user interface which let them operate the system with ease. Paying for drinks at the mobile terminal, the customer and the bartender have to conduct a rather personal movement to tap the eWallet against the smartphone, as opposed to the fixed terminal where the customer has its own screen and tap point. From the bartender's point of view, the hierarchical structure proves to be very useful when a lot of products are for sale. An event could
sell food, drinks and even merchandise using the same system with different configurations and multiple menu views or hierarchies. A simple comparison between the mobile and fixed is presented in Table 1. As mentioned in section 4, some functionality is shared between the two projects.
TABLE 1: Mobile VS Fixed, a comparison
Architecture GUI
Dynamic Layout Hierarchic structure Shopping cart list Customer feedback
Mobile V X V +
Fixed V V V +++
Backend V V X X
Functionaly Debit Credits
(normal
V
operation)
POS mode
X
3DES Authenti-
V
cation
Cryptography
SSL
Logging
V
Independent
X
Consultation
V
X
V
X
(user/
password/
V
ID
authentication)
SSL
SSL
V
V
V
X
Customization Automatic Configurable
V
V
V
Layout
Parsing JSON at Runtime
V
V
V
A comparison of functionality between the fixed and mobile terminal approach. (Including back-end specifications where applicable)
6.2 Both systems put to the test One of the greatest challenges concerning NFC payment systems is mass consumer adoption. To help the greater mass become familiar with next generation payment systems, events can incorporate the technology now. When deployed at an event both terminals appeared to be stable in operation. The systems were thoroughly put to the test at a festival and a local party. Over 200 visitors spread across both events paid using an NFC card that was handed at the entrance. It is worth noting that not all visitors were young people. No mayor flaws were uncovered and the bartenders easily adopted this new way of doing business. After interrogating 70 visitors who actively used the system, the results were promising: · 92.00 % said all payments went fast and easy · 86.20 % trusts this system · 40.00 % admitted they spend more with this system If the personnel was asked which terminal solution they preferred, opinions were divided but leaned to the fixed
terminal. After analysing sales data it became clear that for the party only 26.41 percent of all sales were made with the fixed terminal. This figure can be explained due to the fact that only one fixed terminal was used together with three mobile terminals. At the second event all visitors who applied for the trial had to register their data to get a card so that the consult points could display their current balance together with a personal greeting. Two mobile and one fixed terminal was used and at the end of the day 34.40 percent of all purchases were done using the fixed terminal. This time the fixed terminal was deliberately placed close to the food side of the counter which enabled the merchant to keep his hands free at all times without having to reach for his pockets. The automatic consult mode on the fixed terminal proved useful to customers wanting to order but didn't remember how much was left on their wallet. They could check their credit independently without bothering a bartender so only effective sales were made. These numbers prove that both mobile and fixed terminals were used equally. 7 FUTURE WORK The Terminal should also be aware of event start and end dates. If the configuration file was to contain both the default configuration and the configuration for the first oncoming event, it could automatically detect when to use the default configuration and when to switch to the new event. Also the syncing could automatically be initiated when an internet connection is available. Possibilities are endless, for example a link with an ERP system could be created and vending machines could be equipped with this technology. Future enhancements regarding the hardware have to be made, like building a casing that can easily attach to the counter and can withstand tough environments. It is unacceptable to leave electronic equipment vulnerable to liquids and smudges. 8 CONCLUSION Organizers find NFC attractive to implement, not only because it has a certain gadget factor, but also because 40 percent of the users admitted they would spend more on the festival using this system. When the data analysis tools and stock control are added to this equation, event managers and organizers will definitely invest in this technology. The proposed solution will maintain the easiness of paying for drinks with tickets or vouchers but will enhance the system with better oversight for management. A fully integrated system can be deployed at any event where food, drinks and other items are sold to visitors. A recent survey [13] filled in by over 200 NFC professionals blames the lack of consumer adoption on the slow progression of handset manufacturers, which means that merchants are less interested in investing in NFC enabled systems, which in return means there is not
much for consumers to buy via this technology. When NFC phones will eventually become increasingly available and eWallet deployment will become universally available for different platforms, this will be a perfectly suited terminal system to enhance all on-site payments, with the advantage of being off-line and secure.
9 ACKNOWLEDGEMENTS I would like to thank my promoters, who have aided and supported me during this research. I would also like to thank Paul Butterworth from ViVOtech R for his support regarding the ViVOPay5000 and Jens Luz for the fun weeks we spent together developing and testing our terminals.
REFERENCES
[1] NFC-Forum, "What is nfc?" June 2011. [Online]. Available:
http://www.nfc-forum.org/aboutnfc/
[2] O. Falke, E. Rukzio, U. Dietz, P. Holleis, and A. Schmidt, "Mo-
bile services for near field communication," Ludwig-Maximilians-
UniversitaЁt (LMU), Munich, Germany, Technical Report LMUMI-
2007-1, p. 13, 2007.
[3] J. Ondrus and Y. Pigneur, "Near field communication:
an assessment for future payment systems," Information
Systems and E-Business Management, vol. 7, pp. 347­361,
2009, 10.1007/s10257-008-0093-1. [Online]. Available: http:
//dx.doi.org/10.1007/s10257-008-0093-1
[4] J. Bravo, R. Hervaґs, G. Chavira, S. Nava, and V. Villarreal, "From
implicit to touching interaction: Rfid and nfc approaches," in
Human System Interactions, 2008 Conference on. IEEE, 2008.
[5] N. F. C. World, "Nfc will catch on
"like wildfire"," March 2011. [Online]. Avail-
able:
http://www.nfcworld.com/2011/03/20/36516/
nfc-will-catch-on-like-wildfire-says-sundance-festival-game-creator/
[6] N. Times, "Germany: Transit officials enable users to tap or scan
in new trial," February 2011.
[7] [Online].
Available:
http://code.google.com/p/
android-serialport-api/
[8] V. Inc., ViVOpay Serial Interface Developers Guide, ViVOtech Inc.,
2010,.
[9] V. Matos, "Android multi-threading." Cleveland State University,
2010.
[10] N. Semiconductors, MIFARE DESFire Functional specification, rev.
3.5 ed., NXP Semiconductors, november 2008.
[11] J. Luz, G. Ergeerts, F. Schrooyen, R. Beyers, K. Renckens, L. Wante,
and M. Ceulemans, "A mobile nfc payment terminal for the
event-wallet on an android smartphone," Master's thesis, Artesis
University College of Antwerp, 2011-2012.
[12] J. Stevens, G. Ergeerts, F. Schrooyen, R. Beyers, L. Wante, and
M. Ceulemans, "Ruby on rails back-end for the event payment
terminal," May 2011-2012.
[13] N. I. E. 2012, "Expert analysis from over 200 nfc payment profes-
sionals," NFC Payments insight Survey, 2012.
If you wish to cite this paper, please use the following code: Koray Sels, Frederik Schrooyen, Glenn Ergeerts, Rud Beyers, Karel Renckens, Marc Ceulemans and Luc Wante, A Fixed NFC Payment Terminal for the Event-Wallet on an Android Tablet, Master's Thesis, Department of Applied Engineering, University College Antwerp, Belgium, June 2012.

File: a-fixed-nfc-payment-terminal-for-the-event-wallet-on-an-android.pdf
Published: Tue Jun 19 13:11:52 2012
Pages: 7
File size: 0.43 Mb


RE in Secondary Schools, 2 pages, 0.76 Mb

e-Book Collection Title List, 117 pages, 0.54 Mb

, pages, 0 Mb

Maxims for revolutionists, 6 pages, 0.06 Mb

The Courier, 1 pages, 0.38 Mb
Copyright © 2018 doc.uments.com