Browse Prior Art Database

Multi-modal Data Access

IP.com Disclosure Number: IPCOM000013617D
Original Publication Date: 1999-Oct-01
Included in the Prior Art Database: 2003-Jun-18
Document File: 6 page(s) / 55K

Publishing Venue

IBM

Related People

David Kaminsky: AUTHOR [+4]

Abstract

With the proliferation of pervasive devices such as cellular phones, smart phones, Palm Pilots (WorkPads) and other PDAs, it is becoming necessary to provide multi-modal access to personal data such as e-mail, calendar and address book. And, as one would expect, such solutions are emerging.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 15% of the total text.

Page 1 of 6

Multi-modal Data Access

With the proliferation of pervasive devices such as cellular phones, smart phones, Palm Pilots (WorkPads) and other PDAs, it is becoming necessary to provide multi-modal access to personal data such as e-mail, calendar and address book. And, as one would expect, such solutions are emerging.

However, most (or all) of these solutions tightly integrate the user devices to the back-end. For example, one company might provide access to e-mail through voice. Another might offer calendar through browsers and PalmPilots.

In this paper, we describe an open, standards-based approach to this problem. Rather than specifying which back-ends are accessible, we define an open method for adding back-ends. Similarly, we describe an easily extensible mechanism for producing clients implementing various modalities.

In designing our solution, we assumed that we were not permitted to alter either the data sources or the devices. Thus, we must access the sources using whatever protocols they currently export, and we must deliver the content to the devices in whatever format(s) they can render.

Our resulting infrastructure consists of three layers: interfaces to back-end data sources, which we call facades; an input processor, which we call a request multiplexer, or ReqMux; and a set of output formatters. Below, we describe each of these components. As shown in Figure 1, each request flows from a client into the ReqMux, which passes the request to a facade, which passes the results to an output formatter. A request contains a request type, such as get today's calendar entries or get message N, and a client-device indicator, which is used to determine the output format, as described further below.

Facades are the liaisons between our infrastructure and the data sources. Each facade has three basic responsibilities: extract data from a source; convert the dat a from the source-dependent format to our canonical representation; and export the sources's commands to the remainder of our infrastructure.

The first two points above relate to converting back-end data from its server-dependent format to the infrastructure's canonical representation. When pulling data items from back-end sources, the facade is we assume that the sources are fixed -- that is, they will not be modified to accomodate our infrastructure -- so any changes in data format required by the infrastructure must be made by the facade. Since the source is fixed, each facade must use the protocol exported from the source. For example, we've implemented POP3 and IMAP4 facades for mail retrieval.

Once the facade has extracted data from a source, it transforms the data into a canonical internal format. This representation allows the system to normalize differences among sources. We use XML for our representations. For example, the mail facade can produce an XML document representing an inbox, such as:

<?xml version="1.0" encoding="US-ASCII" standalone="no"?>

<!DOCTYPE Mail S...