`
`.WI LEY
`
`Professional Developer’s Guide Series
`
`
`Creating’
`---------------locationSETVICES
`
`forthe
`Wireless Web
`
`
`
`
`
`Unified Patents
`
`Unified Patents
`Exhibit 1020
`Page 1 of 16
`Page 1 of 16
`
`Exhibit 1020
`
`Johan Hjelm
`
`

`

`it}:‘v#51331‘3‘r23}.
`
`.,x;
`
`1
`l
`i
`1
`
`,
`i
`
`Publisher: Robert Ipsen
`Editor: Carol A. Long
`Developmental Editor: Adaobi Obi
`Managing Editor: Angela Smith
`New Media Editor: Brian Snapp
`Text Design & Composition: D&G Limited, LLC
`
`Designations used by companies to distinguish their products are often claimed as
`trademarks. In all instances where John Wiley & Sons, Inc., is aware of a claim, the product
`names appear in initial capital or ALL CAPITAL LETTERS. "Readers, however, should contact
`the appropriate companies for more complete information regarding trademarks and
`registration.
`
`This book is printed on acid—free paper.
`
`Copyright © 2002 by Johan Hjelm. All rights reserved.
`
`Published by John Wlley & Sons, Inc., New York
`
`Published simultaneously in Canada.
`
`No part of this publication may be reproduced, stored in a retrieval system or transmitted
`in any form or by any means, electronic, mechanical, photocopying, recording, scanning
`or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States
`Copyright Act, without either the prior written permission of the Publisher, or authoriza—
`tion through payment of the appropriate per—copy fee to the Copyright Clearance Center,
`222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 750-4744. Requests to
`the Publisher for permission should be addressed to the Permissions Department, John
`Wiley & Sons, Inc., 605 Third Avenue, New York, NY 10158-0012, (212) 850—6011, fax (212)
`850-6008, E—Mail: PERMREQ @ WILEYCOM.
`
`This publication is designed to provide accurate and authoritative information in regard
`to the subject matter covered. It is sold with the understanding that the publisher is not
`engaged in professional services. prrofessional advice or other expert assistance is
`required, the services of a competent professional person should be sought.
`
`Library of Congress Cataloging-in—Publication Data:
`
`I-Ijelm, Johan.
`Creating location services for the wireless web : professional
`developer’s guide / Johan I-Ijelm.
`p. cm.
`ISBN 0—471-40261—3
`
`1. Wireless Applicaiion Protocol (Computer network protocol) 2. Web
`site development. 3. Geographic information systems. 4. Cellular
`telephone systems.
`I. Title.
`TK5105.5865.H554 2002
`005.2'76——dc21
`
`2001006512
`
`Printed in the United States of America.
`
`10987654321
`
`é
`é
`
`
`
`
`
`
`Unified Patents
`Exhibit 1020
`Page 2 of 16
`
`

`

`
`
`
`Location-Based
`SerVIces In Termmals
`
`he handset—the mobile telephone, PDA, or special-purpose receiver—is not a
`very good place to deploy services. The Internet end-to-end model did not take
`into account that you might want to present a highly interactive, vividly graph-
`ical service in a device that has a smaller processor than a Furby and less mem—
`ory than the average technical calculator.
`‘
`
`As of this writing, the mobile terminals on the market do not have any imple-
`mentations of hardware or software to support any of the terminal-based posi—
`tioning solutions, for example, GPS or E—OTD. However, in order to fulfill the
`accuracy requirements defined by FCC, if UL-TOA is not to be implemented,
`software and hardware to support one of the terminal-based solutions (or
`both) have to be added to the mobile terminals.
`
`The better acCuracy of the position information 'obtainable, the more applica—
`tions for location-dependent services are conceivable, and the more useful they
`get. Therefore, some users may not find E-OTD sufficient with respect to obtain—
`able accuracy for the services they are interested in. For these users, support for
`Assisted GPS in the terminal should satisfy their need for accuracy, which is the
`most accurate positioning solution for mobile terminal application. A terminal
`with a GPS receiver will, however, cost a bit more, and some users may not want
`to pay that extra amount for the accuracy enhancement compared to E-OTD.
`
`Nor is the software required for the more interesting applications imple-
`mented. Web phones—at least, in the foreseeable future—will receive a ready-
`made presentation from the server. While they will probably have some limited
`capability to execute Java code, 128KB of memory is not something that
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Unified Patents
`Exhibit 1020
`Page 3 of 16
`
`

`

`
`
`
`
`296
`
`CHAPTER 11
`
`
`
`enables you to build particularly impressive services, although SVG viewers are
`available that will work in a mobile phone. Still, there is a programming envi-
`ronment for them that executes on their even punier companion processor, the
`SIM card. There is also one pioneering device that has more programmability:
`The Benefon Esc.
`‘
`
`
`bined Mobile Phones and GPS Receivers
`
`
`
`Many GPS receivers have map services built in, but very few can communicate
`fire—posifibfi'tha’t—flTéy—rec‘eive" t6"5n6ti1§r'§e‘rfiéé“t6 receive a response that1s
`adapted to the request. An example of a device that can perform this task is the
`Benefon ESC, which is a combined GSM mobile telephone and GPS receiver. This
`device has a large enough window to present a position-dependent application—
`for instance, with a map interface. That is an exception, however, and will most
`likely remain that way for as long as the price of mobile phones is a primary buy—
`ing argument.
`
`GPS receivers can be made small enough to be integrated into a handset, and
`several manufacturers have demonstrated prototypes. Just having the GPS
`receiver in the handset, however, means that you have to perform a cold start
`every time you want to retrieve a position. You need a way of getting additional
`data about the satellites to the GPS receiver. From a cold start with the almanac,
`
`it typically takes two minutes to determine its position. A warm start takes
`about oneminute; a hot start (with the last fix less than one minute old) takes
`about 15 seconds. Wlthout the almanac, however, the time it takes to acquire the
`
`satellites is approximately 12 minutes.
`
`There is also another concern. When you are using a protocol like the WAP
`Application Framework of LIF API, you send the position request along with
`the identity for the terminal that is to be positioned to the application server or
`MP0. All of the traffic concerning the positioning, including the execution of
`triggered requests, can be done in the fixed network connecting the base sta-
`tions to the MP0 (because you are asking for information that the network has
`collected anyway). But when you have the positioning in the handset, you have
`to transmit the position over the radio channel.
`
`That might not seem so problematic, but consider the numbers. If 720 users in
`a cell on a GSM network are sending position information messages of 256KB
`every three seconds, that means they are using 400 kbit/s. The capacity of the
`cell is 2160 kbit/s. So, they will be using some 18 percent of the capacity of the
`
`
`
`, illll\
`
`cell for signaling.
`
`Traffic modeling is more complicated, of course. Because the traffic tends to be
`bursty, there are fixed allocations of capacity that are required for certain traf—
`fic types and so on. But that simple calculation shows that just signaling would
`
`Unified Patents
`Exhibit 1020
`Page 4 of 16
`
`

`

`
`
`Location-Based Services in Terminals 291
`
`use up a significant portion of the traffic, assuming that the return messages
`with the personalized information are the same, independent of the technology
`used. Another matter is pricing. Nobody knows how the tariffs will be set in the
`end, but given the charges of some European operators for the GPRS traffic
`(the packet data traffic on the GSM network), it would become extremely
`expensive to keep sending your position.
`
`
`
`Benefon Esc
`
` ------
`Esc, built by the other Firmish mobile phone company, whichin a sense corn-
`bines the best of th0 worlds (BenefonIS actually basedin Finland the same as
`market leader Nokia, but it has never reached their market volumes and remains
`specialized in niche applications). It is shown in Figure 11.1. While it uses GPS
`and has all the mobile communications possibilities of a mobile phone, it actu-
`’ ally loses out because the GPS function cannot handle assisted GPS.
`
`Strictly speaking, with the Benefon Esc you are not developing for the mobile
`phone; instead, you are developing for the system. The adaptation of the data
`is done in the service center (in other words, the application server), and the
`phone is providing coordinates that are used to adapt the data. The service
`center is a specialized application server (although it should not be too hard
`for application server developers to provide this kind of functionality if it
`becomes popular). The phone has a built-in GPS receiver, but it can also
`
`
`
`Figure 11.] The Benefon Esc,
`
`
`
`Unified Patents
`Exhibit 1020
`Page 5 of 16
`
`

`

` 1;
`
`CHAPTER II
`
`293
`
`,
`
`receive position information from the GSM network (or, strictly speaking, the
`service center can).
`
`
`
`To enable development by others and to allow service providers to supply
`information, Benefon has released the protocol, the Mobile Phone Telematics
`Protocol, which is used between a service center and a terminal. It uses the
`Short Message System (SMS) of GSM as a carrier format, but that is not an
`absolute binding—other carrier formats could be used if required. The format
`has two parts, text andxbinary, so the conversion should be simple. The com—
`munication between the service center and the mobile terminal is binary, but
`g
`1
`— —~ ~—~~—~—-————~— ————---— wheneemrmmieatlngrwitharegularGSMphone, muses textiommns— —-—--——-—
`enabled1n the protocol are primarily intended to handle emergency calls and
`security and safety applications.
`
`
`
`
`
`
` .§§
`
`§ ..
`
`
`
`rmomma;
`
`‘
`
`
`
`«\gv;«,\~;.nwrkmk\wwA..,.ruzmrmWMWWu‘A/z’fl
`
`
`
`,
`1
`5
`
`‘
`
`
`
`,
`
`j,
`‘1
`
`‘1
`,_ .‘1
`Y
`.
`
`‘
`‘
`
`,
`1
`
`9
`
`1
`
`-
`
`~
`
`1
`:
`5 91131
`
`,
`‘
`‘
`
`1:1
`
`In addition to the message part of the protocol, it also has a numbering for a
`series of images that can be used as icons. They include circles, squares,
`arrows (relative to the compass directions), and a lethal danger symbol in
`addition to icons for buildings such as banks, hospitals, kiosks, camping
`sites, and photo shops. It also includes religious buildings such as syna-
`gogues, mosques, churches, and temples. There are icons to represent differ-
`ent modes of transportation (possibly only Finnish developers would have
`imagined a snowmobile as a standard mode of transportation) and travel
`symbols such as electric outlets, sight, shower, toilet (and again, betraying its
`Finnish roots with symbols for lean-to shelter and orienteering contrOl point).
`Sports symbols include golf, riding,
`ice hockey, and swimming (but not
`handy).
`
`The commands are based on characters already implemented in GSM and use
`ASCII text as the base format. Messages in the protocol have a header that is
`always constant. All field lengths except the header and CMD include one field
`separator character; in other words, the preceding underscore. The field sepa-
`rator is the underscore (__) character. All messages from the service center or
`normal to a GSM phone start with a question mark (‘3), and all messages from a
`terminal using the protocol terminal start with an exclamation point G). If
`information is not, available, the corresponding field is filled with “-” characters.
`
`The basic commands of the protocol are listed in Table 10.1. They are what are
`supported by the Esc telephone, but Benefon also has several other models
`that can provide functions that are more complicated.
`
`The idea is that the service center sends one of these commands to the mobile
`terminal, which then responds with a message reporting its status and position.
`It looks like Table 10.2. The second—row figures are the length of the fields, the
`third row is an explanation, and the fourth is an example.
`
`The Benefon protocol does not use HTTP but SMS for data transfer, which
`makes it somewhat different from Web-based applications. The terminal can
`
`Unified Patents
`Exhibit 1020
`Page 6 of 16
`
`

`

`
`
`Location-Based Services in Terminals 299
`
`Table 10.1 The Basic Commands of the MPTP Protocol
`
`5cm"
`‘MPTPterminaItoSC'
`
`H
`
`.
`
`C‘fé 'MPTP,,t‘.erm.na!vt95¢‘ . 3
`MPTP terminal ‘tghs‘cfl .
`
`Ex LAN "0N
`
`'
`
`e'r'id
`
`:
`
`send back a position in response to a request from the service center. The
`request from the service center is sent as a response to a request from the user.
`
`The TRC command is intended to set up a tracking service based on the num-
`ber of tracking messages and the interval between them (the tracking messages
`here go from the phone to the service center).
`
`The system can also transmit a route to the terminal by using the RSE com-
`mand. The route points can have names (instead of numbers) in addition to
`coordinates. Up to four route points canbe sent in one message, but by using
`the “part” field, messages can be chained so that up to 99 messages can be sent
`(because the field length is six and has to contain the number of the current
`message, a slash, and the number of total messages). The last point of the route
`has a name and an icon (one of the encoded icons that are part of the protocol).
`The terminal can also request a route and a waypoint from the service center.
`
`The terminal can also be used to send network measurements to the service
`center (and it is likely that this market will be big for it in the short run, because
`there are many network operators who want to measure where their competi—
`tors’ cells are located). The network measurement includes the country and
`network codes, the cell identification number, the time advance, the transmis-
`sion power, and other related data.
`
`
`
`Toolkit
`
`-
`
`Traffic is one factor to consider, because it might make GPS receivers in termi-
`nals unsustainable. Another factor is the processing capacity. The mobile station
`
`
`
`Unified Patents
`Exhibit 1020
`Page 7 of 16
`
`

`

`
`
`ZOE—.50.“.
`
`
`
`
`
`22:3;Eat:
`
`
`mumaow,w.,,K._,.EEnzSanu53$:
`
`
`
`
`<._.<nZO_hUu~—_nZOF—mcn—_._.<_>_~_Ou_l_
`
`
`
`
`
`
`
`
`
`wwmmmws.9.anmemEEmvcm:oEmomNA...035...
`
`Unified Patents
`Exhibit 1020
`Page 8 of 16
`
`

`

`
`
`Location-Based Services in Terminals 301
`
`in a mobile telephony system might contain pretty powerful signal processors,
`but as a computer it has a long way to come close to the current PDAs. Process-
`ing power, and memory even more so, costs money. All manufacturers of mobile
`equipment do everything they can to shave off as many cents as possible off the
`price, which of course is good for the consumer because the mobile phone
`becomes cheaper. But on the other hand, the consumer does not get a device that
`is capable of doing very much. Even the smart phones, like the Nokia Communi—
`cator and the Ericsson r380, do not have much processing power available when
`compared to devices like the Compaq iPac or the HP Journada. The operating
`system might be better, but there is still a ways to go until you can do the same
`""""_"_‘_'Wpf6(fi§1fi§mePCT_‘—_'_——_‘—_'_'m___—W
`
`
`
`"""""""""
`
`Even in the most humble cell phone, however, there is a computer that can be
`used by applications developers. It is the SIM card, which is a smart card used
`to process calls and manage the traffic from and to the telephone (and to make
`sure it is logged into the billing system with the correct identity in GSM and
`IMT-2000, that is). Systems like TDMA, CDMA, and PDC do not have a smart
`card built in.
`
`Compared to the processor in the telephone, the processor on a smart card is
`laughable. But performance is not the issue when developing handset applica—
`tions; the main presentation format is text, after all. The main issue is access to
`information, and in GSM and IMT—ZOOO, that is provided through a standardized
`set of APIs, the SIM Toolkit (there is also a Java virtual machine available for
`smart cards, but it does not have the interfaces to system functions on the
`smart card that the SIM Toolkit has). SIM is an abbreviation for Subscriber
`Identity Module, and the telephony part of the handset interacts with the SIM
`to receive the identification of the user. Other information, like the telephone
`number of the user and the calling party, is also stored on the SIM (and trans-
`ferred from there to the telephone book when requested). It is the fact that the
`SIM is the point of interaction for data services with the telephone that makes
`it interesting as an application platform. The SIM card is the receiver and trans-
`mitter of all SMS messages, and it also has access to all other information that
`pertains to the users of the telephone system (including the cell information).
`
`The original SIM cards had fewer than 10 kbytes of memory, but the cards will
`soon have more than 100 kbytes of memory. They have also been given more
`functionality than when first released in the 1980s. The standard is set through;
`the European Telecommunications Standardization Institute (ETSI), which
`sets the standards for GSM. It is the ETSI SMG9 that defines the box of pro—
`gramming tools and protocols that comprise the SIM Application Toolkit (the
`number is GSM 11.14).
`
`The SIM card controls the mobile telephone, and it receives all the information
`that comes to the mobile phone. This information includes the network and cell
`
`
`
`Unified Patents
`Exhibit 1020
`Page 9 of 16
`
`

`

`
`
`identifiers, which are the base for location-dependent services based on the SIM
`Toolkit. It also controls what is displayed to the user and can communicate with
`the network by using the SMS, which was introduced for this type of communi-
`cation even if it is now mostly used for messaging between teenagers.
`
`Today, there are a large number of applications based on the SIM Toolkit
`deployed. Among the applications developed using the SIM Toolkit, Internet
`access, mobile banking, and location-dependent services seem to be among the
`most popular. The SIM card can also download new applications (if they are
`encoded as SMS messages).
`
`
`Internet applicatiohmhe—SIM Mdfimw—sefiifitm
`on the card. It is, in turn, based on the WAP standards. The most popular appli—
`cations are those that are dependent on security, however, such as banking,
`online brokerages, and payments. The card is more secure than the rest of the
`phone because it not only manages things like telephone numbers and the like,
`but it also contains the encryption key for the communication (all GSM com-
`munication is encrypted, including the voice calls).
`
`Location-dependent information based on the SIM Toolkit means that the card
`requests the area information based on the cell ID to the operator and then
`receives messages containing the information.
`
`There is also a standard Java Card API for SIM cards. The Java—compatible SIMS
`can run a number of programs independently. The standard is also used in the
`credit card world. Wlth Java, the card can also be reprogrammed in the field. A
`Java card runs a Java Virtual Machine (JVM). The card handles applications
`
`accordingtothestandardbehaviorforVirtualmachines,butitisalsopossibleto
`
`upgrade the software in a SIM via over-the—air data communications technology
`or other techniques, such as downloading software Via point—ofsale (POS) ter-
`rninals in the network operator’s retail outlets. The operator can also remotely
`update the cards without the user requesting it (because the assumption is that
`the user does not own the phone; the operator does). Only changes to the appli—
`cations need to be transmitted.
`
`Smart cards are also integrated with WAP 1.2 (and 2.0, where it is replaced with
`TLS, the same standard as is used on the Internet) standards. There is a smart
`card—based application known as a WAP Identity Module, or WIM. The WIM
`handles the Wireless Transport Layer security between the WAP gateway and
`the mobile terminal. Several different cryptography algorithms are available.
`The card can also be used for application-layer security, using a digital signa-
`ture and non-repudiation techniques.
`‘
`
`‘
`
`.57,
`
`j
`j
`
`_
`
`1
`
`J
`{
`
`
`
` CHAPTER I I
`
`
`:
`
`j
`
`.
`1
`
`‘1
`
`‘
`
`,
`
`i
`‘
`
`E.
`i‘.‘1.
`1,.
`ifJ,.
`i'l
`
`The SIM card is a GSM standard, but there is a similar standard for CDMA
`called the Removable User Identity Module (RUIM). In IMT-ZOOO, there is a
`similar function: the Universal Subscriber Identity Module (USIM).
`
`
`
`
`.
`-,
`,
`:3
`1,
`
`’1
`
` \
`
`,,
`‘2;
`
`'
`
`..
`i
`‘
`
`::
`
`Unified Patents
`Exhibit 1020
`Page 10 of 16
`
`

`

`
`
`Location-Based Services in Terminals 303
`
`Programming with the SIM Toolkit is not simple, and you need to access the
`Operator’s network, not just the SIM. The assumption in the system is that the
`operator owns the application, the network, and the SIM card. So, instead of
`going deeper into it here, I will include the specifications on the CD—ROM that
`comes with this book.
`
`,
`
`ava in the Mobile Phone
`
`WMenJaxabecameavaflableinAUebbrowsersritwashaflaiasthelfiggestthing——--~~—-w~--~~}
`since shaved ice. It was supposed to change the user interface of the computer
`‘
`forever. Well, a lot of water has run under the bridges since then, and Java has
`established itself thoroughly as a server programming language. It turns out
`that what you can do as a developer is very limited—far more limited than was
`originally thought. The standard MIDP and CLDC implementations do not actu—
`ally enable more than very simple animations and games. It is when you get
`additional functionality, such as sprites for games (which the Japanese com—
`pany Jphone has in its Java phones), that you can start doing really interesting
`things.
`
`The first company to manufacture a mobile phone using Java was Nortel, but
`that phone hardly sold at all—being released before the standard was ready.
`The first network operator to release a phone with Java was Nextel in the
`United States, which released a phone based on the MIDP profile. Next came
`NTT DoCoMo, which released a phone based on K—Java—but it has a very spe-
`cial operating environment that does not allow the Java applet to interact with
`the network other than through the browser. Jphone in Japan came next, and it
`released a mobile telephone with the full MIDP profile (and some additional
`goodies, such as three-dimensional sprites for games programming) in 2001.
`
`The Java libraries in the mobile telephones consist of the Connected Limited
`Device Configuration (CLDC), which is based on the K Virtual Machine (KVM)
`and is implemented on top of device operating systems and provides the inter—
`face between specific phone operating systems and higher—level Java technology-
`based applications. The JZME Mobile Information Device Profile (MIDP) is
`layered on top of the CLDC and includes APIs for the application life cycle, HTTP
`networking, persistent data storage, and graphical user interfaces (GUIs), as
`shoWn in Figure 11.2.
`
`CLDC is a basic set of libraries and Java virtual machine features. It must be pre—
`sent in each implementation of aJZME environment on highly constrained devices,
`such as cell phones and pagers. CLDC takes care of the telecommunications-
`related aspects of the system, such as pausing applications when the connec-
`tion drops, switching over to the telephony application when a call comes in,
`
`
`
`Unified Patents
`Exhibit 1020
`Page 11 of 16
`
`

`

`304
`
`CHAPTER II
`
`MIDP
`
`
`
`applications
`
`2 OEM APISV
`
`
`
`Figure 11.2 How the Java libraries in the mobile phone belong together.
`
`and so on. MIDP adds supplementary libraries that provide APIs not handled
`by the low-level CLDC, such as the user interface, database, and device-specific
`networking. It also contains HTTP so you do not have to develop your own
`browser or your own protocol stack. It also contains TLS security over TCP,
`which enables end-to—end security
`
`When you use Java technology phone applications, you’ll be able to either
`leverage an existing WAP infrastructure or, by using the next-generation WAP,
`use TCP/IP and other native Internet protocols. Once you have TCP/IP access,
`of course, you will be able to bypass any kind of gateway that exists between
`the phone and the server, although for performance reasons you might want to
`retain it when you do not need end-to—end security. This is because it contains
`a mobile profile of TCP, which is optimized for the narrowband network.
`
`The MIDP APIs are logically composed of high—level and low—level APIs.
`
`l
`
`‘
`‘l r
`
`;.
`
`
`
`lx
`
`
`
`i
`l
`
`‘
`
`
`
`l
`z
`
`l
`.
`.
`
`,
`};
`" 5.
`
`
`
`
`
`
`The high-level APIs are designed for applications where software portability
`across a range of handsets is desired. These APIs use a high level of abstrac-
`tion. The tradeoff is that the high-level APls limit the amount of control the
`developer has over the look and feel of the user interface. The underlying
`implementation of the user interface APIs, which is accomplished by the hand-
`set manufacturer, is responsible for adapting the human interface to the hard—
`ware and native user interface style of the device.
`
`The low—level API provides very little abstraction and requires a bit more
`design work to remain portable. It is designed for applications that need pre-
`cise placement and control of graphic elements as well as access to low—level
`inputevents. The low—level API enables the application to access special,
`device-specific features. Games are a typical application of this API.
`
`The high-level portion of the user interface API is screen-based. That is, the API
`is designed so that interaction with the user is based around a succession of
`
`.
`
`T
`
`t '1‘
`
`l
`
`‘
`
`
`§
`
`3
`él
`
`Unified Patents
`Exhibit 1020
`Page 12 of 16
`
`

`

`
`
`Location-Based Services in Terminals 305
`
`1
`
`‘
`
`1
`1
`1
`
`screens, each of which presents a reasonable amount of data to the user. Com—
`mands are presented to the user on a per-screen basis. They enable the applica—
`tion to determine which screen to display next, What computation to perform,
`what request to make of a network service, and so on.
`
`A screen is an object that encapsulates device-specific graphics rendering user
`input. Screens can only scroll vertically; there is no horizontal scrolling. The
`screen handles all events that occur as the user navigates the screen. Only high-
`level events are passed on to the application. Only one screen can be Visible at
`a time, and the user can only interact with the items on that screen.
`
`For'flfis reason,iyou cannot make—screens too—"comphcalfilst? as few user
`interface components as possible, and make sure they are related. It makes it
`easier for the user if he or she only has to perform one task per screen.
`
`Applications are composed of a set of screens through which the user steps as
`he or she completes the tasks (which the application consists of). The screens
`need not be organized linearly; they can branch out, and it is possible to jump
`between them (and make conditional jumps, as well).
`
`The MID Profile has four types of screens: List, Alert, Text Box, and Form. The
`List screen provides three variations: an implicit (menu) list; a single—choice
`list; and a multiple—choice list. The implicit list can be used to display a list of
`menu commands inside the application.
`
`The Alert and Text Box screens contain alert and text, but alerts are simpler
`than in other environments and will use the entire screen. Text boxes generally
`will not support fancy text formatting or font styles and enable only basic text-
`editing capabilities. Form screens contain an arbitrary mix of items including
`images, read-only text, editable text,._ date and time fields, gauges, and choice
`groups.
`
`The form screen is Where you can actually develop something. There are theoret—
`ically no limits on what a form can include. The implementation, not the applica—
`tion, handles layout, traversal, and scrolling. There are quite a few primitives that
`you can use for development, such as text boxes, multiple-choice menus, and so
`on. There are many good books about Java, so I do not need to list them here.
`
`None of the components contained on the form screen are able to scroll inde-
`pendently. The entire contents scroll together vertically (there is no horizontal
`scrolling). When a form is presented on the display, the user can interact With it
`and with its items indefinitely
`
`Interaction can be made by using the pointer on the screen or using editable data.
`Devices following the MIDP profile are assumed to have either a one—handed
`ITU-T phone keypad or a two-handed QWERTY—style keyboard. Beyond that,
`devices can have any number ofprogrammable (soft) buttons or no programmable
`buttons at all. The manufacturer ultimately maps these commands onto the device.
`
`
`
`Unified Patents
`Exhibit 1020
`Page 13 of 16
`
`

`

`
`
`il
`
`l l l
`
`ll
`l
`
`306
`
`CHAPTER 11
`
`Developers can create portable applications, but they lose control over where each
`specific command will map on the device.
`
`l
`
`,
`
`.
`
`
`
`
`
`1
`1‘
`ill
`
`.
`3
`
`.
`
`MIDP also contains a database in the device that can be controlled with three
`primitives in the API. The RecordStore primitive consists of a collection of
`records that remain persistent across multiple invocations of the MIDlet. Record—
`Comparator defines a comparator that compares two records in a RecordStore to
`see whether they match or what their relative sort order is. RecordFilter defines
`a filter that is used to extract sets of records that match a criterion.
`l
`Java is available for mobile phones, and NTT DoCoMo in Japan (as well as its
`"7i _‘_""_____—‘W,W fimneWoMones“(albeit infifim ——"“i-—
`‘
`versions). In terms of location—based applications, though, there are basically
`’
`two ways where Java comes in handy: as an animation system for the display of
`l
`maps (where you can add an animated line to a downloaded map, for instance),
`j
`and as a system to program a dedicated client, which is independent of the
`3
`browser and does more than change the map when the position changes. The
`.
`challenge in developing applications of this ldnd lies in two different areas: you
`have to create applications that work in the minimal environment of the mobile
`phone, and it is a user interface challenge. When you move beyond the static
`display, you get an entirely new set of problems—as we saw in Chapter 9,
`“Maps as User Interfaces.”
`
`l ,
`
`‘
`
`‘V‘
`
`H
`‘
`
`1
`
`The other type of application is an active application that runs in the back-
`ground of your PDA (mobile phones are hardly up to this point yet) and that
`conducts an action based on the position, such as checking your gasoline level
`and beeping you when you are coming within 500 meters of a filling station run
`by the company where you have a discount. It could actually run in the applica-
`tion server as well and be triggered when you pass a boundary, but then it
`would be harder for it to communicate with the gasoline meter, of course. This
`type of application belongs to the future (although it is not science fiction; sim-
`ilar applications have been demonstrated, although not dependent on position).
`
`It is still not entirely clear how Java in the mobile phone will play out (although
`play is just what it is being used for). More and more manufacturers are imple-
`menting it in theirgphones, though, and just as it has developed into a comple-
`ment to the Web browser on the fixed Internet, it is likely that it will become a
`very important execution environment in the mobile phone. But there is still
`room for developers—and new applications.
`
`l3
`i
`
`
`
`Navigation and ln-Car Telematics
`
`In Japan, car navigation devices are extremely popular. Because there are no
`street names, roads are almost never straight for more than 50 meters and
`
`
`
`
`
`
`
`Unified Patents
`Exhibit 1020
`Page 14 of 16
`
`

`

`
`
`Location-Based Services in Terminals 301
`
`because drivers are rarely familiar with the layout of cities other than their
`own, car navigation systems have become a hot seller.
`
`Car navigation systems are often standalone systems with the map database on
`a CD—ROM or DVD, and the in—car GPS receiver is used to center the map
`around the car’s position. Car navigation systems also usually have functions to
`calculate routes and sometimes contain databases of points of interest.
`
`What they do not have, however, is communication with the world outside. If
`you want to update the information in a car navigation system, you have to
`
`change the stored maps (for instance, by changing the CD—ROM). Most car nav—
`W _ W““““~m0n SflemomM'E—mmrmimEEfiWW-Mu_
`
`Given the popularity of car navigation systems in Japan, however, NTT
`DoCoMo has formed an alliance with car navigation companies to connect car
`navigation systems with its mobile phones to update them with traffic informa-
`tion and other information that is dynamic.
`
`In the United States, General Motors has been successful with the OnStar sys-
`