Mobile Networks and Applications 5 (2000) 243–258
`
`243
`
`The Satchel system architecture:
`Mobile access to documents and services
`
`Mike Flynn a, David Pendlebury b, Chris Jones c, Marge Eldridge d and Mik Lamming d
`a Internet Designers Limited, Compass House, Vision Park, Chivers Way, Histon, Cambridge CB4 9AD, UK
`b Aspect Capital Limited, 9 Mandeville Place, London W1M 5LB, UK
`c Apama, 17-18 Miller’s Yard, Mill Lane, Cambridge CB2 1RQ, UK
`d Xerox Research Centre Europe, 61 Regent Street, Cambridge CB2 1AB, UK
`
`Mobile professionals require access to documents and document-related services, such as printing, wherever they may be. They may
`also wish to give documents to colleagues electronically, as easily as with paper, face-to-face, and with similar security characteristics.
`The Satchel system provides such capabilities in the form of a mobile browser, implemented on a device that professional people would
`be likely to carry anyway, such as a pager or mobile phone. Printing may be performed on any Satchel-enabled printer, or any fax
`machine. Scanning, too, may be accomplished at any Satchel-enabled scanner. Access rights to individual documents may be safely
`distributed, without regard to document formats. Access to document services is greatly simplified by the use of context sensitivity. The
`system has been extensively tested and evaluated. This paper describes the architecture of the Satchel system.
`
`1. Introduction
`
`In this paper, we describe the architecture of a system
`called “Satchel”. Satchel supports mobile document work
`by providing streamlined access to remote documents, via
`a mobile browser running on a Nokia 9000 Communicator.
`In addition, Satchel provides a set of specialised document
`services that are required to support mobile document work
`such as printing, faxing, and scanning. The current mobile
`browser uses both infrared and GSM radio to communicate
`wirelessly with the rest of the Satchel system.
`In a companion paper [16], we review the distinctive
`features of mobile document work, and explain how they
`motivated us to formulate five design goals for any system
`seeking to provide effective support. To summarise, these
`goals are:
`(a) Easy access to document services, providing a simple
`way to locate and use document services such as print-
`ing, faxing or scanning. A document service might be
`associated with a physical device (e.g., a print service),
`or it might not (e.g., an e-mail service).
`(b) Timely document access for any document when and
`where it is required.
`(c) A streamlined user interface that achieves high usability
`through specialisation for a limited set of activities.
`(d) Ubiquity, since mobile document work occurs in many
`different contexts.
`(e) Compliance with security policies, providing a level
`of security for documents and document services that
`meets or exceeds policies set by the individual or the
`organisation.
`Our companion paper discusses how Satchel addresses
`these design goals in general. In this paper, we describe the
`
`(cid:211) Baltzer Science Publishers BV
`
`architecture of the Satchel system in more detail, referring
`to how specific aspects of the design address these goals.
`The next section (section 2) describes the background
`and some early Satchel prototypes. The overall design of
`the current Satchel architecture is described in section 3,
`then in more detail in the following four sections. The pro-
`prietary format used in transmission to the browser is de-
`scribed in section 8, while security measures are described
`in section 9, and a deployed system is described in sec-
`tion 10. Some remaining challenges and possible future
`developments are described in section 11.
`
`2. Background and prototypes
`
`2.1. The seed: Forget-Me-Not (1993)
`
`Forget-Me-Not [17] was a context-sensitive retrieval
`system based on principles of episodic memory and ubiqui-
`tous computing [29]; it used the Xerox PARC Tab [27] as
`the mobile client. In Forget-Me-Not, information was auto-
`matically collected about a person’s activities: for example,
`telephone calls made, e-mail messages received, and rooms
`visited. This information was logged in a central database,
`and presented as a personal biography on the PARC Tab
`screen, with activities presented in chronological order. The
`biography could be browsed and filtered to show only a par-
`ticular type of entity or activity. So, for example, a user
`could manipulate icons on the PARC Tab screen to answer
`questions such as: “Which document did I print just before
`the meeting with Bob last month?”
`Included in the logged information were document-
`related events, such as passing documents to one another
`or printing them. Because Forget-Me-Not could determine
`information about the user’s context, such as the people
`
`Oracle Exhibit 1005, pg 1
`
`

`
`244
`
`M. Flynn et al. / The Satchel system architecture
`
`it became natural to think
`and equipment in the room,
`about transferring documents to others, or printing them,
`merely by dragging and dropping the appropriate icons on
`the PARC Tab screen. This was the seed of the Satchel
`idea: to take advantage of the user’s context to streamline
`the user interface for printing and transferring documents.
`
`2.2. Early Satchel prototypes
`
`During the lifetime of the Satchel project, we have de-
`veloped several prototypes of the system on various mobile
`and desktop computing platforms. These prototypes are
`described below.
`The first Satchel prototype was implemented using the
`PARC Tab as the mobile client and an Apple Macintosh
`computer. The PARC Tab screen showed the contents of
`a Satchel folder on the user’s Macintosh desktop. As the
`PARC Tab was carried around, people (other Satchel users)
`or equipment encountered also appeared on the Tab screen
`as small icons. To transfer a document to a person, the user
`simply dragged and dropped the document’s icon over the
`person’s icon; the document would immediately appear in
`the other person’s Satchel folder, and hence on their screen.
`Similarly, to print a document on a nearby printer, the user
`simply dragged the document icon over the printer icon.
`Although this crude prototype was flawed (e.g., dragging
`a person to a printer printed the contents of that person’s
`Satchel folder on the Macintosh), had no security, and re-
`lied on local PARC Tab infrastructure, it was sufficient to
`stimulate further work on the Satchel project.
`The next series of prototypes was implemented on the
`Apple Newton PDA [18]. At this time, the Newton was
`widely available, relatively cheap, and easy to program.
`Communication was via infrared, serial cable or an Ap-
`pleTalk network, and local radio communications cards be-
`came available later.
`In early 1994, a very basic Satchel browser allowed
`the user to navigate around his or her UNIX directories.
`The user could carry out one of three simple operations on
`files and directories: BLOW, SUCK or SYNC. These com-
`mands were formulated in the mobile “roaming” Newton
`and passed over infrared to one of many static “tethered”
`Newtons, placed by printers, monitors or scanners. BLOW
`indicated that the selected document should be passed to
`the receiver (e.g., a printer) or passed to another Satchel
`user. SUCK indicated that a new entry should be made
`in the current directory, and that the device should place
`a document into that location, by scanning, for example.
`SYNC caused the browser information to be updated from
`the UNIX system (see section 11.4 for detail). Note that
`the Newton never contained the documents, but merely is-
`sued commands referring to them. The wired infrastructure
`carried the actual documents for printing, and so on.
`By mid-1994, the World Wide Web was becoming preva-
`lent, and the Newton Satchel system was modified to use
`generic Web requests rather than the custom UNIX com-
`mand repertoire. The benefits of basing Satchel on Web
`
`protocols included the large and growing infrastructure,
`ready availability of many components, such as web servers
`and scripting libraries, and the ability to test most sys-
`tem functionality using a standard Web browser such as
`Netscape Navigator. The rapid growth of the World Wide
`Web also meant that the problems of scaling Web-based
`services to improve capacity, reliability and security were
`being addressed by many people.
`infrastructure was
`By the end of 1995,
`the Satchel
`re-implemented under Microsoft Windows NT, and the
`browser’s user interface was greatly simplified. The re-
`placement of SUCK, BLOW and SYNC, with an all-purpose
`DO-IT command, completely eliminated the need for the
`user to know which operation was appropriate in which
`physical circumstance. DO-IT was interpreted by the re-
`ceiver, invoking the most appropriate action for the given
`context. For example, in front of a printer, the selected
`document was printed; in front of a display screen, it was
`displayed; in front of a person, the document (or rather a
`reference to it) was transferred. In front of a scanner, a di-
`rectory was selected, and the document in the scanner was
`scanned and stored under a default name, based on the lo-
`cation, date and time. Also, familiar Web-browser buttons,
`such as HOME, BACK and RELOAD were introduced.
`An additional ROOM SERVICE button asked the local in-
`frastructure what services were available at that place. Of-
`ten, the page returned would be a form for invoking a spe-
`cific service, such as printing, with various options. In the
`case of multifunction machines, a directory of such service
`forms could be returned.
`By July 1996, to help us achieve our security goal, extra
`mechanisms were added. Each document reference now
`incorporated a digital signature [22], which proved that the
`reference had indeed been generated by the Satchel claim-
`ing to have done so (section 9). In addition, a local radio
`system covering our entire laboratory was added to increase
`the ubiquity of the Satchel system.
`Although the Newton-based prototype was effective, the
`local radio system was only of use within our laboratory.
`Outside the building, a mobile phone, modem card and ca-
`ble were required to communicate. Around that time, the
`Nokia 9000 Communicator, a mobile phone with built-in
`programmable PDA, infrared and GSM data communica-
`tions, became available. Subsequent browser development
`used this device.
`
`3. Architectural overview
`
`The current Satchel system architecture, illustrated in
`figure 1, draws upon our experience with the prototypes
`discussed in section 2. The Satchel system consists of a
`set of browsers, gateways, servers and services, which treat
`the local Intranet and the Internet as a file system. Initially,
`we will discuss use with the Intranet, and later extend to
`the Internet.
`A Satchel browser (section 4) provides a user interface
`on the mobile client for navigating to documents and in-
`
`Oracle Exhibit 1005, pg 2
`
`

`
`M. Flynn et al. / The Satchel system architecture
`
`245
`
`Figure 1. The Satchel system architecture.
`
`voking services on them. While a cache mechanism min-
`imises the amount of communication required between the
`browser and the rest of the system, a browser may com-
`municate to explore new directories, invoke services, or re-
`fresh the cache. To minimise transmissions over relatively
`low-bandwidth connections, Satchel browsers do not deal
`directly with documents, but with secure document refer-
`ences, or tokens. A token may be passed directly to another
`browser over infrared, or beamed, in order to convey ac-
`cess permission to a specific document. Similarly, tokens
`may be passed to document services, to grant them permis-
`sion, say, to fetch the document for printing. Thus, wireless
`traffic usually consists of service invocations, tokens, or di-
`rectory listings, whereas services use the wide-band wired
`network for transferring the documents themselves.
`From a user’s perspective, services are provided by
`Satchel-enabled devices, such as printers or scanners.
`In
`fact, each device has attached an infrared transceiver, con-
`nected to some nearby PC running a simple Gateway (sec-
`tion 5) process. The Gateway injects contextual informa-
`tion into passing requests, such that services appropriate to
`that situation may be offered. This helps to streamline the
`user interface. In the absence of infrared facilities, a stan-
`dard connection using Point-to-Point Protocol (PPP) may
`be made via the GSM cellular radio network to a Satchel
`server back at base.
`While Satchel users need neither know nor care about
`the implementation, the protocols used in the Satchel sys-
`tem are entirely compatible with the World Wide Web. The
`extensible nature of the Web’s HTTP protocol lends itself
`to the construction of new systems such as Satchel without
`sacrificing interoperability with existing infrastructure. For
`example, normal Web servers may be used to access pub-
`
`lic or company documents and directories. Existing tech-
`niques for load sharing between multiple Web servers, such
`as those commonly employed at large Web sites, can be
`used to increase the capacity and availability of the Satchel
`system.
`For more private documents, the Satchel Personal Web
`Server (section 6) behaves just as a normal Web server, but
`restricts access, such that only the owner, or other legiti-
`mate token holder, will gain access to the document, thus
`enhancing security (section 9). Personal Web Servers may
`also act as hosts for a range of document services, as may
`any standard World Wide Web server.
`The Satchel services instigate document transactions,
`such as printing or scanning, and report on their success.
`Actually, mobile directory and document access is also per-
`formed indirectly through such a service – the fetch ser-
`vice (section 7.1) – capable of translating HTML [2] con-
`tent into a proprietary condensed format, known as Halibut
`(section 8), for efficient transmission and display on the
`browser.
`
`4. The browser
`
`A Satchel browser must provide the ability to browse di-
`rectories for documents, and to invoke services upon them,
`once found. Browsers may be unable to display documents
`themselves, for reasons of transmission bandwidth, storage
`requirements, screen size and resolution. For example, one
`experimental browser is implemented on the PARC Min-
`der, a tiny pager-sized device with only a two-line screen
`and infrared communications, illustrated in figure 2. Omis-
`sion of unnecessary features helps to streamline the user
`interface, one of our design goals.
`
`Oracle Exhibit 1005, pg 3
`
`

`
`246
`
`M. Flynn et al. / The Satchel system architecture
`
`Figure 2. The PARC Minder Satchel browser.
`
`These differences concern browsing, security, services and
`beaming, and are discussed below.
`
`4.1. Browsing
`
`When browsing Web pages with the Satchel browser, the
`user selects a link with the cursor, and presses the OPEN
`button (see figure 4). If the page is not already cached, then
`an HTTP [3] request must be made, over a communications
`link, to a Web server hosting Satchel services. Communi-
`cation is normally attempted first over infrared and then
`over radio (subject to user preferences). If infrared contact
`is made, the receiving infrared gateway forwards requests
`to its nominated server – after all, this might be unfamiliar
`territory, well away from home, where the local services are
`not known to the user. With radio, however, the browser
`must nominate a known server, since the connection is typ-
`ically via a general PPP connection to an ISP, or directly
`into a company Intranet.
`
`Figure 3. The Nokia 9000 Communicator.
`
`The current Satchel browser is essentially a mobile
`World Wide Web browser, implemented on the Nokia 9000
`Communicator, a mobile phone incorporating a sophisti-
`cated PDA (see figure 3). Like any normal Web browser,
`the Satchel browser provides:
`(cid:15) selection and following of hyperlinks, to other HTML
`pages or directories;
`(cid:15) HOME, BACK and RELOAD buttons, operating in the
`usual manner;
`(cid:15) nomination of a “home” page, typically an HTML page
`on a user’s workstation, with links to useful places
`within the user’s private filing system, or the Internet;
`(cid:15) nomination of a home server and proxy server for ra-
`dio connections (infrared connections use a server nom-
`inated by the Gateway);
`(cid:15) fully featured form handling (but currently not multiple
`forms per page);
`(cid:15) considerable caching of pages (around 1000 pages in
`Halibut), purged on a least-recently-used basis, which is
`especially useful given the latency and expense of radio
`network connections.
`
`These features impart familiarity to the technically aware
`user. There are, however, several significant differences
`between a Satchel browser and a conventional Web browser.
`
`Figure 4. The Satchel browser on the Nokia 9000 Communicator.
`
`All requests for a document, or a directory listing, issued
`by the browser are made indirectly through the fetch service
`(section 7.1). Whenever the browser makes any request, it
`inserts an HTTP “Accept” header to inform this service that
`the browser only accepts Halibut replies, and it arranges for
`translation of replies into Halibut. Without this header, no
`translation to Halibut occurs, allowing the services to be
`tested from a regular Web browser by means of a regular
`HTML form, expecting HTML in reply. In any case, future
`browsers might use other formats or even HTML itself,
`which will be indicated by this header.
`The browser expects to receive Halibut, in which there
`is no provision for images or sound. If the retrieved docu-
`ment was not in HTML, and, therefore, cannot be translated
`to Halibut, the fetch service replies with details of the file
`in question (still in Halibut, so that the browser always re-
`ceives the correct format). This prevents potentially large
`images, movies or other non-HTML files, from being trans-
`mitted over the low-bandwidth link, only to be rejected
`at the far end by the browser. Fortunately, Web servers
`commonly serve up directory listings in HTML, which are
`translated to Halibut, just like any other document.
`
`4.2. Service invocation
`
`A SERVICES button (see figure 4) provides easy access
`to document services, appropriate to the context, another
`of our design goals. Typically, a user browses to a docu-
`ment of interest, and wishes to invoke some service on that
`
`Oracle Exhibit 1005, pg 4
`
`

`
`M. Flynn et al. / The Satchel system architecture
`
`247
`
`currently implemented, due to difficulties with the Nokia
`9000’s operating system (GEOS).
`
`4. The CLOSE button now takes the browser back directly
`to the condition in which the SERVICES button was origi-
`nally pressed, rather than via any previous service page,
`in contrast to behaviour during browsing.
`
`Pressing the form’s operation button packages up the
`form contents as an HTTP POST request, and transmits it
`as the argument to a Fetch Service request. Typically, one
`of the (hidden) fields of the form contains the document
`token of interest. When the relevant service is invoked, it
`unpacks its arguments to find the token, and uses that to
`fetch the actual document. Each document service replies
`with a page describing success or failure, possibly with a
`SHOW LOG button for further detailed service information.
`(Since this page is still derived from the original SERVICES
`button press, this SHOW LOG button is now in place of the
`browser’s SERVICES button.)
`
`4.3. Beaming tokens
`
`The browser can “beam” a token to another browser,
`over infrared. This is used in casual encounters or in meet-
`ings to distribute documents quickly, or, more precisely, to
`distribute references with access rights.
`Each browser offers a service, the Beam Service (sec-
`tion 7.7), that receives beamed tokens. The browser must
`maintain a page of such tokens, called the Inbox. This page
`is accessed through a special Inbox URL, so that, for exam-
`ple, the user’s home page can contain a link to it, despite
`the fact that it really resides in the browser. We consider
`this preferable to using a dedicated hardware button, since
`these are in short supply on small devices.
`Tokens received by the beam service are in a somewhat
`vulnerable state, in that they might exist only within the mo-
`bile device. In order to secure them, they should either be
`sent to the workstation desktop with the View Service (sec-
`tion 7.4), sent home using the E-mail Service (section 7.9),
`or the documents they represent should be printed. In the
`future, we envisage there will be a mechanism for automati-
`cally synchronising the Inbox with a workstation folder, and
`informing the user of the status of each Inbox token.
`
`5. Gateways
`
`A Gateway is a simple process, which links the infrared
`medium to that of the local area network.
`It listens to
`the infrared transceiver associated with a Satchel-enabled
`device, waiting for requests from browsers, and forwards
`them on to a Web server hosting Satchel services, over
`TCP/IP. However, the infrared Gateway also inserts context
`information into the request as it passes through, as extra
`HTTP headers. Data returned by a service is transmitted
`straight back through to the waiting browser.
`Each Gateway process has a simple user interface for
`specifying which infrared transceiver to listen to, which
`
`Figure 5. A typical Print Service form.
`
`document – to print it on a nearby printer, for example.
`When in front of a Satchel-enabled device, the user presses
`the SERVICES button, which makes an infrared request for
`services (section 7.2) available at that location, and expects
`back an appropriate service form or a directory of such
`forms, where multiple services are possible. Once again,
`the request uses standard HTTP, with a header indicating
`that only Halibut is accepted in reply, just as with fetch
`requests.
`In the case of a radio request for services, no contextual
`information is known. Exactly the same service request
`is sent to the nominated home server, devoid of location
`information. The reply is typically a directory of services
`available at the home site, such as printing or faxing.
`The service forms are just normal HTML Web pages and
`forms, arranged by local system administrators, which, once
`again, are translated to Halibut on the fly, and sent to the
`browser. The browser supports menus, fields, checkboxes
`and other form elements. Typically, they contain fields to be
`filled in with the document’s title, user’s name and other
`options, such as number of copies. They can be visited
`and used with a regular Web browser for testing purposes,
`although hidden fields (discussed below) may need to be
`made visible.
`The browser treats such forms, such as that in figure 5,
`just like any other form found on the Web, but, knowing
`that the SERVICES button was pressed on an ancestor, en-
`ables a few extra features:
`
`1. Fields with well-known names may be filled in auto-
`matically by the browser; for example, the SATCHEL
`USER field is filled in with the user’s name, and the
`SATCHEL TOKEN field is filled in with the token of the
`document originally selected. Such fields might be hid-
`den from the user to avoid clutter and accidental change,
`if specified in the form’s original HTML.
`
`2. The first button occurring on the form is promoted out of
`the form itself, to replace the (disabled) SERVICES button.
`This syntactic convenience allows common operations,
`such as printing with default options, to involve simply
`pressing the same physical button twice. The effect is
`similar to that of the DO IT command in the Newton
`Satchel browser (section 2.2), but with greater flexibility,
`as the user can select service options, if required.
`
`3. The visual appearance of the forms obtained through the
`SERVICES button may be changed, to appear as dialog
`boxes rather than conventional pages, keeping the se-
`lected document in view in the background. This is not
`
`Oracle Exhibit 1005, pg 5
`
`

`
`248
`
`M. Flynn et al. / The Satchel system architecture
`
`Web server to forward to, and what context information to
`insert. Many Gateways may use the same Web server, the
`context information being used to determine the originator.
`This information is flexible, and may be managed according
`to local requirements. Typically, it identifies the location,
`the name of the device, and the service to offer. Whilst the
`Fetch Service ignores this information, service enquiries use
`it to determine which service form to reply. Although the
`device and service could be determined from the location
`information alone, this would require some central database
`to perform that mapping.
`Infrared communications take place using a simple pro-
`prietary protocol, originally developed for the PARC Tab
`and Minder, rather than IrDA [14]. This was due in part to
`the desire for compatibility between prototypes, but mainly
`due to lack of a suitable IrDA protocol stack for Windows
`NT at that time.
`Radio connections over dial-in lines, possibly through an
`outside ISP, use PPP to obtain Internet connectivity. With
`infrared, the Gateway nominated a Web server to use on
`the browser’s behalf, whereas with generic PPP connec-
`tions the browser itself must make that nomination. Typ-
`ically, a well-known server is used, since in this situation
`the network environment is known. In the case where an
`outside ISP is being used, a special proxy server on the
`firewall must also be nominated in order to cross it. This
`proxy authenticates passing requests (see section 9), possi-
`bly denying access.
`Other communication methods may have their own
`Gateways. For example, our Newton-based prototype used
`a radio card to make AppleTalk connections to our local
`network. A bridging process relayed messages to a Web
`server over IP and back again, just as the current infrared
`Gateway does. We envisage other Gateways to paging net-
`works and the e-mail server infrastructure, too.
`
`6. Servers
`
`The native filing system for Satchel is the World Wide
`Web – our file servers are just Web servers. The security
`design goal required that a user should not need to publish
`their private documents on the World Wide Web in order to
`access them when away from the desk. Also, we believed
`it to be important to present users with the same familiar
`organization of documents available from their workstation.
`Unfortunately, a typical Web server works at the level of
`directories and files, with a fixed set of “document roots”,
`and is incapable of providing access to other machines,
`directories or files expected by the user (such as “Network
`Neighbourhood” or “My Computer” in Windows NT).
`To overcome these problems, at least in the Windows
`NT environment, we developed the Satchel Personal Web
`Server. Satchel users are given access to the directory list-
`ings and files that they have permission to access from their
`desktop PCs – no more, and no less. Access is controlled
`by means of the Satchel security mechanisms (section 9).
`
`An obvious benefit of using Web servers as file systems
`is the potential to access documents residing on any regular
`Web server (on a corporate intranet or the Internet) or any
`electronic file system or document repository that has a web
`front-end (e.g., Xerox DocuShare, Lotus Notes, etc.).
`
`7. Services
`
`Satchel services are invoked directly and indirectly by
`Satchel browsers. In fact, a browser’s only contact with the
`world is through these services.
`Services are implemented as a set of CGI scripts [7],
`hosted by a regular Web server, or a Satchel personal Web
`server.
`Invocation is by HTTP request to the server, so
`that any Web browser can invoke these services for testing
`purposes, in principle, given an appropriate form.
`A CGI script qualifies as a Satchel service by adhering
`to a number of simple conventions. These include defined
`input parameter names, error reporting and logging mech-
`anisms, and output formats. Given details of these con-
`ventions, a Satchel service can be implemented using any
`Web server development tools (such as shell scripts, Python
`scripts and Java servlets). To ease the implementation of
`new services, a Python class hierarchy and library were
`developed which essentially provided skeletal Satchel ser-
`vices, with methods that may be overridden to customise
`functionality. Making such a new service available to users
`simply requires writing an HTML form, following the nam-
`ing conventions, representing the service’s user interface,
`and adding this form to the directory of services.
`If this
`service is associated with a specific device, this association
`is made through the device’s Gateway interface. Otherwise,
`generic services are linked into the Web page for radio ser-
`vice requests.
`Two fundamental services, the Fetch Service and Service
`Enquiries described below, reply in HTML – or Halibut if
`the request includes an HTTP “Accept” header indicating
`that only Halibut is accepted in reply. The HTML to Hal-
`ibut converter (section 8) is used to do this on the fly, and
`the much-reduced result is transmitted back to the browser.
`All other services are invoked via the Fetch Service, and
`so reply HTML for possible translation.
`The Web server logs each service invocation, and ser-
`vices create their own logs in addition, providing a link or
`button to access them in their replies. This not only aids
`debugging, but also allows the user to monitor the progress
`of long-running service requests.
`The following subsections describe those services avail-
`able in the current Satchel system. Note that some of these
`services are not directly visible to the user.
`
`7.1. The Fetch Service
`
`While transparent to the end user, the Fetch Service un-
`derpins browsing and service invocation (section 4.1). This
`service is used to retrieve HTML pages, including directory
`
`Oracle Exhibit 1005, pg 6
`
`

`
`M. Flynn et al. / The Satchel system architecture
`
`249
`
`listings and service forms, from the World Wide Web and
`translate them to Halibut. It takes a token for the required
`page as argument – lexically just an HTTP request – and
`contacts the appropriate Web server or proxy, if necessary,
`to obtain it.
`It is also used to retrieve documents by the
`other services, in which case no translation occurs.
`
`7.2. Service Enquiries
`
`This enquiry service yields a form for the service pro-
`vided at the given location. Where more that one service is
`available, a directory of such services might be provided.
`The location information is supplied by the infrared Gate-
`way (section 5). In the case of radio communication, no
`location information is available, and so a full directory of
`available services is returned. This might include the Fax,
`Print and E-mail Services described below.
`A service directory might be organised by function, lo-
`cation, or indeed any other appropriate organisation, at the
`discretion of the local system manager. The list of avail-
`able services might even be dynamically determined from
`all available information. This Service Enquiry mechanism
`makes simple, effective use of the locality of infrared com-
`munications. More complex systems, such as that of Bag-
`gio and Piumarta [1], use a relatively sophisticated distrib-
`uted object and remote procedure call mechanism to achieve
`little more.
`
`7.3. The Print Service
`
`The Print Service fetches and prints documents, virtu-
`ally regardless of their type. The service takes as argument
`the printer to use, various printing options and a token for
`the document to be printed. The service fetches the docu-
`ment, noting its MIME type. Then, Windows information
`regarding the indicated printer is examined to determine
`what formats the printer accepts. To convert between these
`types, the Conversion Service (section 7.6) is invoked, and
`the result is sent to the printer.
`As with many services,
`this whole process may be
`lengthy, and so fetching conversion and printing are per-
`formed asynchronously – that is, the Print Service actually
`returns an immediate acknowledgement, but which contains
`a link to the Log of the on-going print process.
`
`7.4. The View Service
`
`The View Service presents a document on a Satchel-
`enabled monitor or display screen. As with the Print Ser-
`vice, the document represented by the token argument is
`fetched and the MIME type noted. Then, Windows infor-
`mation regarding the locally available display applications
`is gathered.1 The Conversion Service (section 7.6) is in-
`voked, if necessary, and the resultant file is opened on the
`
`1 Under Windows NT, applications cannot easily be started on remote
`machines. Therefore, a Web server and the View Service must run
`on the PC hosting the display, invoked from the Gateway’s nominated
`Satchel server.
`
`display. Note that this is a local copy of the document,
`possibly in a different format to the original.
`Tokens can be held in a PC file, rather like Windows
`Internet Shortcuts. An extra argument to the View Service
`chooses whether to just put the token on the desktop like
`this, and defer the fetching, conversion and display. Such
`token files have a type and appl