throbber
Joint sOc-EUSAI conference
`
`Grenoble, october 2005
`
`Applying the RFID technology for Field Force Solution
`
`Petri Vuorinen
`
`Nokia, P.O. Box 307, FIN-00045 Nokia Group, Finland
`petrI.k.vuorinen@nokia.com
`Fax: +358 71803685
`
`Abstract
`
`The RFID technology has been applied for a long time in
`different areas: In logistics to identify the goods in transit, in
`security business for creating the check points for guarding
`tours.
`
`However RFID technology has merely been applied in such
`way that the content of the RFID tag has been read with the
`dedicated reader device that has no real time connectivity to
`the back end systems where the data of the RFID TAGs is
`collected to. Or there has not been possibility to combine the
`mobile phone’s
`functionalities with
`the RFID reader
`(integrated device) that would also have an intuitive User
`Interface based on simple ‘Touch’ [4].
`
`This paper introduces, as an example, the reporting and
`communication tool called Field Force Solution. It is intended
`for people working in the field and who are by nature mobile
`and blue collar.
`
`It uniquely combines the use of RFID technology with tags
`and readers, client - server middleware software, mobile
`phone and real time communication.
`
`Keywords:
`RFID Tag, integrated RFID reader, Functional shell, real time
`communication, field reporting, client – server middleware
`Software, Push over Cellular, J2EE
`
`1.
`
`Introduction
`
`•
`
`•
`
`Currently the enterprises that have mobile workers have
`following problems or limitations:
`Limited access to information and data collection
`applications in the field
`The use of pen and paper in the field generates a lot
`of paperwork when back at the office
`• Manual re-entry of the collected data enhances the
`risk of making errors
`• Out of date Client Information / Service History
`• Out of date site/product/service instructions
`
`In order to resolve those problems RFID technology can be
`applied: RFID tags, an RFID reader integrated to a mobile
`phone, middleware SW in the mobile phone as a mobile client
`and server middleware SW can be successfully combined.
`RFID Tags can uniquely identify objects (= like meter readers,
`machines) or certain locations (= like check points in the
`guarding tour) in the field.
`
`The user only needs to touch an RFID tag with the mobile
`phone in order to receive information related to it or to send
`predefined reports to the back end system using existing
`network infrastructure. The communication is based on
`proprietary protocol with HTTPS over GPRS.
`
`The RFID reader integrated in the mobile phone will read the
`content of the RFID TAG and the middleware in the mobile
`
`sOc-EUSAI 2005, October 12-14, 2005, Grenoble, France
`© 2005 ACM. ISBN 1-59593-304-2/05/10…$15.00
`
`p. 3 9
`
`phone will act as customer specific application and control
`SW between the reader, mobile phone and the server
`middleware.
`
`The actual association between the objects or locations and
`the unique serial number of an RFID Tag is done in the server
`middleware. Again the middleware server can be integrated to
`back end systems.
`
`When this solution is in use the end users no longer need to
`carry paper with them and they do not have to do the manual
`reporting in the office after the work in the field. All the
`reporting will be done real time and in the field. This
`improves reporting efficiency thus reduces costs.
`In addition the maintenance history, task lists or other related
`information can be downloaded to the end user.
`
`The guards will report their visits at the certain locations by
`touching the tags (check points in the guard tour) in real time.
`This provides better visibility to guarding processes and
`provides the proof of time and attendance.
`
`2. Field force solution and its components
`
`2.1. RFID tags
`
`Tags are non battery-powered (passive) tags that are compliant
`with the MIFARE UltraLight RFID protocol, which is based
`on the ISO 14443A standard [1] Mifare Ultralight protocol
`that uses 13.56 MHz. The reading distance is few centimeters
`depending on
`the Tags physical characteristics and
`dimensions.
`
`The RFID tag is a microchip attached to an antenna. Each tag
`contains a serial number (a unique ID), and additional data can
`be added related to the specific service tasks. When the RFID
`reader is brought into close proximity of the tag, it induces a
`current in the tag that “wakes up” the tag and transmits the
`contents of the tag’s memory to the RFID reader [3].
`
`Different kinds of RFID tag formats can be suit to different
`kinds of environments and usage. For example a printable
`indoor tag with an adhesive surface or for outdoor conditions,
`a more durable tag format can be used that can also be placed
`on metal surfaces.
`
`The Field Force Solution uses two types of RFID tags:
`identification tags and operative tags. Identification tags are
`used for identifying end users, and operative tags are used for
`identifying end users’ work sites or the objects of their work
`tasks [3].
`
`2.2. Mobile phone and used bearers
`
`Basically any S40 Mobile phone having support for Midp2.0
`[2] and GPRS and SMS capabilities would be sufficient.
`However the limitations exist and only selected phone models
`can be used. This is due to the fact that manufacturing the
`functional shells for different phone models will be costly due
`to the different mechanics for every phone model.
`
`GOOG-1035
`Google LLC v. RFCyber Corp. / Page 1 of 3
`
`PGR2022-00003
`Apple EX1035 Page 1
`
`

`

`Joint sOc-EUSAI conference
`
`Grenoble, october 2005
`
`One Phone model selected for Field Force Solution also
`supports PoC, Push over Cellular, also referred as Push to
`Talk feature that is based on Voice over IP implementation. It
`enables efficient group communication between field workers.
`
`GPRS connection is the preferred and primary bearer and
`SMS will only be used as a back up bearer and for starting up
`the end user session. GPRS connection is faster way to
`communicate and send data than SMS. Also reducing the
`sending of the SMSs will reduce bearer costs. However the
`actual bearer costs depend on the agreement with operator.
`
`2.3. RFID reader/writer device
`
`The RFID reader is located in the functional shell of the
`mobile phone. The shell is fitted to the dimensions of the
`selected mobile phone model. The RFID reader communicates
`with Client application over the FCI (= Functional Cover
`Interface) and over multiple protocol layers.
`
`The RFID reader has the functionality that enables the reading
`of passive RFID tags at close distance. This can be optimized
`for outdoors-related professional use, providing ease-of-use
`and real-time data collection.
`
`The RFID reader of the Field Force Solution can read tags that
`are compliant with the MIFARE© UltraLight protocol, which
`is based on the ISO 14443A standard [1].
`
`When the user touches an RFID tag with the RFID reader, the
`RFID reader receives the information stored in the tag and
`passes it to the Client in the mobile phone.
`
`The Client processes the received information and delivers the
`information to the Server Middleware using either GPRS data
`transfer or SMS messaging.
`
`2.4. Middleware Client
`
`The Field Force Solution supports Client SW that follow the
`Mobile Information Device Profile (MIDP) 2.0 Specification
`[2]. The Client SW
`is used
`for
`reading
`tags and
`communicating with the Server Middleware.
`
`The middleware client can be easily customized thus to meet
`the needs of each customer (customer specific application)
`For example, customized Client SW can be used for the
`following:
`• Meter reading. Display data about previous readings, as
`well as ask the end user for input such as the current
`meter reading. The new meter reading data is then sent to
`the Server Middleware.
`Providing service information. For field personnel doing
`maintenance work, the end user can, for example, touch
`the tag in an elevator and the customized LI Client can
`display the service instructions for it. [3]
`• Requesting information from the customer’s back-end
`information system through the Server Middleware. [3]
`
`•
`
`2.5. Middleware Server
`
`The middleware Server can send and receive data from the
`Clients using either SSL-secured Hypertext Transfer Protocol
`(HTTPS) over General Packet Radio
`
`Service (GPRS) connections, or Short Message Service (SMS)
`messaging. All the tag reading events coming from the field
`will be stored to the database of the server.
`
`Middleware server is J2EE compliant which makes the
`middleware software easily scalable. The relational database
`
`contains all the RFID tag and Tag event related information as
`well as user register and client register.
`The communication between the client – server is session
`oriented and is based on proprietary protocol. This offers
`secure communication.
`
`The Server also manages different kind of clients and their
`versions. Clients can be downloaded to the end users over
`HTTPS/GPRS. The initiation of downloading the clients is
`based on sending an SMS to the server and it returns WAP
`Push (binary) SMS to the mobile phone.
`
`Currently the customization of the Middleware server User
`Interface is not easily done so it is to be done on client side.
`However there is some pressure to let the customers customize
`also the server UI.
`
`The Server is provided to customers as a hosted service. There
`is a Graphical User Interface for both the service provider’s
`and the customers’ administrators.
`
`2.6. Back End Integration
`
`Integration to back end systems is a necessity because in many
`cases the most of the data that is important for the customers is
`located in their ERP systems. In these cases the Server will act
`as gateway connecting the data from the field to customers IT
`systems.
`
`The Server can send tag event data either with periodical batch
`file transfer or by sending events in real-time. The batch file
`transfer uses SSH/SCP, and the real-time transfer uses
`SOAP/HTTP(S). The Server can also send and receive two-
`way communication messages from Back End systems [3].
`
`
`
`BEBE
`
`ServerServer
`
`
`
`InternetInternet
`
`Interface
`6
`
`SOAP /SCP
`
`HTTP(S)
`over GPRS
`
`
`OperatorOperator
`
`NetworkNetwork
`
`
`
`RFID TagRFID Tag
`
`1
`
`2 & 3 & 4
`
`5
`
`
`
`Figure 1: Field Force Solution and its components.
`
`3. Field force solution and comparison to
`other existing systems
`
`There are several advantages and clear need for this type of
`Field Force solution. Currently in the market there are PDA
`devices that are RFID reader enabled and have real time
`connectivity by using HTTPS over GPRS but they lack some
`of the mobile phones features such as push to talk (Voice over
`IP).
`
`Or alternatively the RFID reader is not integrated into the
`actual PDA device so this clearly indicates that the field
`personnel would need to carry two devices which is costly,
`pretty cumbersome and in some cases impractical.
`
`p. 4 0
`
`GOOG-1035
`Google LLC v. RFCyber Corp. / Page 2 of 3
`
`PGR2022-00003
`Apple EX1035 Page 2
`
`

`

`Joint sOc-EUSAI conference
`
`Grenoble, october 2005
`
`When the RFID reader is integrated to the mobile phone in a
`way two devices can be combined.
`
`Some solutions are based on using PDA devices and real time
`connectivity but the actual end user’s device is far too
`sophisticated and not rugged enough for the blue collar type of
`work. Thus it does not meet the needs of the blue collar
`market.
`
`Some providers in the market do have solutions that are based
`on using real time PDA devices and standalone server with
`back end system connectivity.
`
`In Field Force solution the actual server middleware can be
`provided as hosted application (SW as a service). That reduces
`the initial (business) start up costs that could be an obstacle for
`the small or medium sized companies. In case of hosted
`application only the time and the amount of users using the
`system will be charged.
`
`4. Future considerations
`
`In the future there will be support for different types of tags
`that are based on different tag standards. Series 60 phone will
`provide more functionality on the phone such as improved
`multimedia capabilities.
`
`Enhanced functionality in the server middleware will add
`value in the mobile field processes and work flows. Letting the
`customers customize the server UI provides them better
`usability and branding capabilities.
`
`
`Introducing the GPS receiver into a mobile phone along with
`the RFID reader would benefit the companies who need to
`know where their equipment or employees are and what tasks
`they have completed by touching a tag.
`
`5. Conclusion
`
`The proposed Field Force Solution truly provides an efficient
`communication and reporting solution for the blue collar field
`force users by combining the RFID technology, mobile phones
`and middleware software and an intuitive User Interface that is
`based on
`touching with the mobile phone. The main
`advantages are in the automated reporting from the field thus
`reducing costs, improved visibility to field processes and
`easier access to the information systems in the field.
`
`6. References
`
`(MIDP) v2.0
`
`[1] ISO 14443A standard
`[2] Mobile
`Information Device Profile
`Specification
`[3] Field Force Solution description
`[4] Advance 2004 no. 2 “A touch is all it takes”
`[5] Combination of mobile phones with object identification
`technology and remote service access e.g. in Brody &
`Gottsman, PocketBargainFinder, HUC'99
`[6] Integration of object identification with backend enterprise
`software: 'Enabling Implicit Human Computer Interaction:
`A Wearable RFID-Tag Reader', Schmidt et al
`
`p. 4 1
`
`GOOG-1035
`Google LLC v. RFCyber Corp. / Page 3 of 3
`
`PGR2022-00003
`Apple EX1035 Page 3
`
`

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket