Method and apparatus for sharing common data objects among multiple applications in a client device

Abstract

Disclosed is software architecture and method for sharing data objects among multiple applications in a client device. The architecture includes a server process in the client device for processing a template, such as a SHTML template for the Extended Markup Language (XML), based on a template identifier value received from a user application. Each of multiple applications has a template. Each template identifies a series of objects identified by tag values, such as XML entities, that are to be incorporated into a display page. A database of objects, such as a database of XML entities identified by tag values, is maintained that contains data objects for the applications. An update process periodically establishes a communication link with a remote server and requests download of a data document containing content data corresponding to at least a portion of several of the templates. The data document is parsed into the database of objects based on the structure of the data document, which generally conforms to a data type definition. When the server process processes different templates that reference the same data object, it will retrieve the data object from the database. Each template may then be rendered into a page of output data for display to a user. The architecture and method according to the present invention thus permit data objects to be shared by multiple applications and to be automatically updated. Each time a data object is updated, the data will be current for each user application that references the data object.

Claims

1. A software architecture for a client device, the architecture comprising:

a data store for storing a predefined data structure having a first data object and a predefined first template having a first identifier value and a first field, where the first field of the first template is tagged as corresponding to the first data object of the data structure;

a first application process configured to output information to a user of the client device in a format defined by the first template, where the first application process, responsive to a user command, is configured to format and send a template population request message that includes an identifier field having the first identifier value for the first template, and is further configured to render the first template, when populated with data, for display to a user of the client device;

a server process within the client device, the server process being configured to receive the template population request message from an application and, responsive thereto, use the value from the template identifier value from the template population request message to retrieve a corresponding template from the data store, use the tag from the first field of the corresponding template to retrieve a value from a corresponding data object of the data structure corresponding to the tag value from the corresponding template, and return the corresponding template populated with the value from the data object to the application that sent the template population request message.

2. The architecture of claim 1, where:

the data store includes a predefined second template having a second identifier value and a first field, where the first field of the second template is tagged as corresponding to the first data object of the data structure;

the architecture further includes a second application process configured to output information to the user of the client device in a format defined by the second template, where the second application process, responsive to a user command, is configured to format and send the template population request message having the second identifier value for the second template in the identifier field of the message, and is further configured to render the first template, when populated with data, for display to the user of the client device.

3. The architecture of claim 2, where:

the data structure further comprises an XML data structure; and

the server process is configured to obtain data from the XML data structure in the data store using a Server Side Include (SSI) command.

4. The architecture of claim 2, where an automatic update process for communicating with a remote server is further configured to automatically download and store the data value in the first data object of the data structure in the data store at a predetermined periodic time interval.

5. The architecture of claim 4, where the periodic time intervals include times of low use by the user of the client device.

6. The architecture of claim 4, where the periodic time intervals includes times of low use by the user of the communication link.

7. The architecture of claim 4, where:

the data structure further comprises an XML data structure;

the server process is configured to obtain data from the XML data structure in the data store using a Server Side Include (SSI) command; and

the automatic update process is configured to receive an XML data document containing the value for the first data object, which the automatic update process is configured to parse the value for the first data object from the XML data document and insert the value for the first data object into the data structure.

8. The architecture of claim 2, where a remote server defines the data value in the first data object of the data structure in the data store according to a first predetermined data type definition and the first application process accesses the first data object of the data structure in the data store according to the first predetermined data type definition.

Description

FIELD OF INVENTION

The present invention relates to software architecture and, more particularly, to a software architecture for data use in multiple user applications in a client device.

BACKGROUND OF THE INVENTION

The present invention is concerned with application programs running on a client device that display information obtained from a wide area network to a user through a user interface.

Users of computer systems use their computers to perform a variety of tasks, such as word processing, spread sheets, games, and email. Each of these tasks typically involves activating a user application program that interacts with the user to perform the task. An application is a software program that carries out a task, i.e. a database manager, a spreadsheet, a communications package, a graphics program or a word processor. User input is received from the user via user input devices, such as a mouse and keyboard, and information is output to the user by outputting information to the user via a display, such as a monitor.

Each user application typically has its own user interface. In other words, each application accesses data that is typically specific to the application, processes the data, and assembles and formats textual and graphical data for display to the user. The data for each application is typically formatted and structured specifically for the application, so, unless multiple applications are designed to share data, it is often difficult for one application program to access and utilize the data from another application program. Furthermore, the task of assembling and formatting data for output to the user can be complex. Each user application typically uses the interface drivers provided by the operating system of the computer system to output information to the display of the computer system. However, the user interface software for each program is often substantially custom for that program and can represent a significant amount of the code for each application.

Another type of user application is a browser application, which provides users of computer systems access to a vast amount of information through their network connections to the Internet. The Internet is a wide area network that interconnects computer networks around the world and provides a user client device connected to the Internet with access to a broad array of resources connected to the Internet, i.e. access to servers that are also connected to the Internet. In order for information to be accessible to a wide number of client devices and servers, a body of software, a set of protocols and a set of defined conventions are generally needed that permit intercommunication. The World Wide Web is one example of such a body of software, set of protocols and set of defined conventions.

The World-Wide-Web and similar private architectures, such as internal corporate LANs, provide a "web" of interconnected document entities. On the World-Wide-Web, these document entities are located on various sites on the global Internet. The World-Wide-Web is also described in "The World-Wide Web," by T. Berners-Lee, R. Cailliau, A. Luotonen, H. F. Nielsen, and A. Secret, Communications of the ACM, 37 (8), pp. 76-82, August 1994, and in "World Wide Web: The Information Universe," by Berners-Lee, T., et al., in Electronic Networking: Research, Applications and Policy, Vol. 1, No. 2, Meckler, Westport, Conn., Spring 1992. On the Internet, the World-Wide-Web is a collection of documents (i.e., content), client software (i.e., browsers) and server software (i.e., servers) which cooperate to present and receive information from users. The World-Wide-Web is also used to connect users through the content to a variety of databases and services from which information may be obtained.

The World-Wide-Web is based on a conventional client-server model. Content is held in documents accessible to servers. Clients can request, through an interconnect system, documents which are then served to the clients through the interconnect system. The client software is responsible for interpreting the contents of the document served, if necessary.

Among the types of document entities in a "web" are documents and scripts. Documents in the World-Wide-Web may contain text, images, video, sound or other information sought to be presented, in undetermined formats known to browsers or extensions used with browsers. The presentation obtained or other actions performed when a browser requests a document from a server is usually determined by text contained in a document which is written in Hypertext Markup Language (HTML). HTML is described in HyperText Markup Language Specification-2.0, by T. Berners-Lee and D. Connolly, RFC 1866, proposed standard, November 1995, and in "World Wide Web & HTML," by Douglas C. McArthur, in Dr. Dobbs Journal, December 1994, pp. 18-20, 22, 24, 26 and 86. HTML documents stored as such are generally static, that is, the contents do not change over time except when the document is manually modified. Scripts are programs that can generate HTML documents when executed.

HTML is one of a family of computer languages referred to as mark-up languages. Mark-up languages are computer languages which describe how to display, print, etc., a text document in a device-independent way. The description takes the form of textual tags indicating a format to be applied or other action to be taken relative to document text. The tags are usually unique character strings having defined meanings in the mark-up language. Tags are described in greater detail, below.

HTML is used in the World-Wide-Web because it is designed for writing hypertext documents. The formal definition is that HTML documents are Standard Generalized Markup Language (SGML) documents that conform to a particular Document Type Definition (DTD). An HTML document includes a hierarchical set of markup elements, where most elements have start tag, followed by content, followed by an end tag. The content is a combination of text and nested markup elements. Tags are enclosed in angle brackets ('<' and '>') and indicate how the document is structured and how to display the document, as well as destinations and labels for hypertext links. There are tags for markup elements such as titles, headers, text attributes such as bold and italic, lists, paragraph boundaries, links to other documents or other parts of the same document, in-line graphic images, and many other features.

A site, i.e. an organization having a computer connected to a network, that wishes to make documents available to network users is called a "Web site" and must run a "Web server" program to provide access to the documents. A Web server program is a computer program that allows a computer on the network to make documents available to the rest of the World-Wide-Web or a private web. The documents are often hypertext documents in the HTML language, but may be other types of document entities as well, as well as images, audio and video information.

The information that is managed by the Web server includes hypertext documents that are stored on the server or are dynamically generated by scripts on the Web server. Several Web server software packages exist, such as the Conseil Europeen pour la Recherche Nucleaire (CERN, the European Laboratory for Particle Physics) server or the National Center for Supercomputing Applications (NCSA) server. Web servers have been implemented for several different platforms, including the Sun Sparc 11 workstation running the Unix operating system, and personal computers with the Intel Pentium processor running the Microsoft.RTM. MS-DOS operating system and the Microsoft.RTM. Windows.TM. operating environment.

A user typically accesses the resources of the World Wide Web through the use of a browser application program. The browser program allows the user to retrieve and display documents from Web servers. Some of the popular Web browser programs are: the Navigator browser from NetScape Communications Corp., of Mountain View, Calif.; the Mosaic browser from the National Center for Supercomputing Applications (NCSA); the WinWeb browser, from Microelectronics and Computer Technology Corp. of Austin, Tex.; and the Internet Explorer, from Microsoft Corporation of Redmond, Wash. Browsers exist for many platforms, including personal computers with the Intel Pentium processor running the Microsoft.RTM. MS-DOS operating system and the Microsoft.RTM. Windows.TM. environment, and Apple Macintosh personal computers.

A browser typically executes on a client device connected to Internet. The Web server and the Web browser communicate using the Hypertext Transfer Protocol (HTTP) message protocol and the underlying transmission control protocol/internet protocol (TCP/IP) data transport protocol of the Internet. HTTP is described in Hypertext Transfer Protocol-HTTP/1.0, by T. Berners-Lee, R. T. Fielding, H. Frystyk Nielsen, Internet Draft Document, Oct. 14, 1995, and is currently in the standardization process. At this writing, the latest version is found in RFC 2068 which is a draft definition of HTTP/1.1. In HTTP, the Web browser establishes a connection to a Web server and sends an HTTP request message to the server.

Request messages in HTTP contain a "method name" indicating the type of action to be performed by the server, a URL indicating a target object (either document or script) on the Web server, and other control information. Response messages contain a status line, server information, and possible data content. The Multipurpose Internet Mail Extensions (MIME) are a standardized way for describing the content of messages that are passed over a network. HTTP request and response messages use MIME header lines to indicate the format of the message. MIME is described in more detail in MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies, Internet RFC 1341, June 1992.

The user enters a resource identifier value that identifies a desired web resource through a command input line of the user interface of the browser. The resource identifier value is typically a Uniform Resource Identifier (URI) or a Uniform Resource Locator (URL) that is resolved into an address for a server device having the desired object. See Request for Comment (RFC) 1630 available through the Internet Engineering Task Force at URL www.ietf.org.

When a URL value has been input to the browser, the browser transmits a command containing the URL value. The command is typically formatted according to a Hypertext Transfer Protocol (HTTP) that provides a convention for commands and replies over the web. The URL value in the command is typically resolved to an address for a server connected to the web and to a resource on the server, such as a document. See RFC 1945. The server that receives the command will typically respond with an HTTP reply message containing information. This information is typically in the form of a document that uses the Hypertext Mark-up Language (HTML).

In response to an HTTP request message, the server performs any requested action and returns an HTTP response message containing an HTML document resulting from the requested action, or an error message. The returned HTML document may simply be a file stored on the Web server, or it may be created dynamically using a script called in response to the HTTP request message. For instance, to retrieve a document, a Web browser residing in a client device sends an HTTP request message to the indicated Web server, requesting a document by its URL. The Web server then retrieves the document and returns it in an HTTP response message to the Web browser. If the document has hypertext links, then the user may again select a link to request that a new document be retrieved and displayed.

The server constructs the HTML reply message by retrieving an HTML document corresponding to the URL value. The HTML document typically includes markup data that encodes a description of the HTML document's graphical layout and logical structure and includes a set of tags that identify data entities that are to be retrieved and inserted into the HTML document as indicated by the tag. The server typically obtains the data for the HTML document by performing a Server Side Include (SSI) request for each tag value. The SSI request is sent to a database manager that may be internal to the server itself or may be connected to the server via a backend network. The database manager uses the tag value to search aid retrieve the data object corresponding to the tag value. The data object is returned to the server for incorporation into the HTML document. When the server has completed the population of the HTML document with the data entities for each tag of the HTML document, the server will transmit the HTML document in the reply to the client device.

As another example, a user may fill in a form requesting a database search, the Web browser will send an HTTP request message to the Web server including the name of the database to be searched and the search parameters and the URL of the search script. The Web server calls a program or script, passing in the search parameters. The program examines the parameters and attempts to answer the query, perhaps by sending a query to a database interface. When the program receives the results of the query, it constructs an HTML document that is returned to the Web server, which then sends it to the Web browser in an HTTP response message.

When the client device receives the response from the server containing the HTML document, the browser will process the document according to the HTML standard and display the resulting page to the user via the display of the user's computer system.

U.S. Pat. Nos. 5,973,696; 6,006,242; 5,983,228; and 5,737,739 provide additional examples of web architectures and applications and are herein incorporated by reference.

FIG. 1 is a functional block diagram illustrating an example of an architecture 10 involving a client device 20, e.g. a user's computer system, and a server device 60 that can communicate via a network, such as the Internet. Client device 20 includes a keyboard 24 and a mouse 26 as user input devices and a display 28 for user output. Client 20 has a communications port, such as a network interface card, through which it is connected to a local area network (LAN) 30 via communication link 22. LAN 30 is connected to a public Internet Protocol (IP) network 50, i.e. a wide area network, that provides access to a broad range of network resources including those of server 60, which is connected to public IP network 50 via communication link 62. Client device 20 is controlled by a user through a combination of command inputs via mouse 26 in concert with keyboard 24 to execute application programs in client device 20 that display output to the user via display 28.

FIG. 2 is a functional block diagram illustrating an example of another architecture 15 involving a client device 20, e.g. a user's computer system, and a server device 60 that can communicate via a network, such as the Internet. In architecture 15, client device 20 includes a communications device, such as a modem, capable of communicating through public switched telephone network (PSTN) 35 to a network access server (NAS) 40. NAS 40 is connected to IP network 50 and enables client device 20 to communicate with server 60.

FIG. 3 is a simplified functional block diagram illustrating an embodiment of an architecture 100 for a central processing unit (CPU) for client device 20. The CPU includes a processor 110 connected to a system bus 120. Processor 110 accesses several subsystems via bus 120 including a memory subsystem 130 for storage of data and code. A network interface subsystem 140 is connected to bus 120 and is used to communicate with the network via connection 22. The network interface may, for example, be a network interface card or a modem device that communicates with a network access server connected to public IP network 50.

The CPU outputs information to the user via a display interface 150 connected to bus 120 that sends video information to display monitor 28. The CPU receives user input via user interface 160 that receives user input via keyboard 24 and mouse 26 and forwards the user input to processor 110 via bus 120.

FIG. 4 is a simplified software architecture diagram illustrating an embodiment of a software architecture 200 for a typical client device 20. At the center of architecture 200 is an operating system (OS) 210 that controls access to the resources of the client device, including memory, display and communications, and activation of application programs 260 and 270. Output to display monitor 28 of client 20 is accomplished using the display driver primitives 230 provided through OS 210. User input from keyboard 24 and mouse 26 is detected by user interface drivers 240, which receive, interpret, and forward the user input signals to OS 210 for further action. Communications with the network connection 22 are handled through communications drivers 250.

A user of client device 20 selects one of user application programs 260 and 270 through a combination of user inputs. For example, the user may double click an icon displayed on monitor 28 with mouse 26 to activate user application 260. OS 210, upon receiving the user's selection, spawns a process for the selected application.

The application 260 will typically operate with a data store 262, which is a portion of memory subsystem 130 allocated to the application. For example, application 260 may be a word processor that retrieves a document from long term storage, such as a disk drive that is part of memory subsystem 130, and buffers the document in a random access memory (RAM) that is also part of the memory subsystem. The data in data store 262 is typically formatted for use only by the application. For another application to share data, it must be designed to read the data. For example, a word processor application may be configured so that it can read data from a spreadsheet application or import a graphic created by a graphics application.

As an application processes data, it also formats the data for display to the user and outputs the display data using display drivers 230. Above the display driver level, each application essentially includes its own graphical display capability. When, for example, application 260 is a word processor, it formats the ASCII codes and control characters from a document along with the menu and control bars for display via monitor 28 and outputs the formatted document to the user using display drivers 230. When, for example, application 270 is a browser application, it communicates through communication drivers 250 to send a HTTP request containing a URL over the network and receive an HTML document in response. The browser application then renders the graphics and text of the HTML document into a page and outputs the page to the display monitor 28 using display drivers 230.

The separate graphics capability required for each of the applications residing on a client device can become a significant limitation in a client device having limited resources. Likewise, the inability to efficiently share data across multiple applications can also pose a problem. Therefore, the need remains for a software architecture that efficiently uses the resources available in a client device.

SUMMARY OF THE INVENTION

In accordance with preferred embodiments of the present invention, some of the problems associated with selecting a network resource in the prior art are overcome.

An embodiment of a software architecture for a client device, according to the present invention, includes a data store for storing a predefined data structure having a first data object and a predefined first template having a first identifier value and a first field, where the first field of the first template is tagged as corresponding to the first data object of the data structure. A first application process is configured to output information to a user of the client device in a format defined by the first template, where the first application process, responsive to a user command, is configured to format and send a template population request message that includes an identifier field having the first identifier value for the first template, and is further configured to render the first template, when populated with data, for display to a user of the client device. The architecture also includes a server process within the client device, the server process being configured to receive the template population request message from an application and, responsive thereto, use the value from the template identifier value from the template population request message to retrieve a corresponding template from the data store, use the tag from the first field of the corresponding template to retrieve a value from a corresponding data object of the data structure corresponding to the tag value from the corresponding template, and return the corresponding template populated with the value from the data object to the application that sent the template population request message. In a further refinement of the architecture, the data store includes a predefined second template having a second identifier value and a first field, where the first field of the second template is tagged as corresponding to the first data object of the data structure and the architecture further includes a second application process configured to output information to the user of the client device in a format defined by the second template, where the second application process, responsive to a user command, is configured to format and send the template population request message having the second identifier value for the second template in the identifier field of the message, and is further configured to render the first template, when populated with data, for display to the user of the client device

An embodiment of a method for sharing data between multiple applications in a client device, according to the present invention, calls for defining a first predetermined data type definition, creating a first data structure for storing data, where the first data structure is structured in accordance with the first data type definition, and storing a first data object from a first application in the first data structure, where the first data object of the first application is structured according to the first data type definition. The method further sets forth retrieving the first data object in a second application by accessing the first data structure according to the first: predetermined data type definition and outputting the first data object from the second application to a user of the client device.

An embodiment of a data display device, according to the present invention, includes a communication interface adapted for connection to a network of computing devices and a memory device containing a first display template corresponding to a first application and a second display template corresponding to a second application, where each of the first and second display template includes an index to a first data object, where the index is defined by a data type definition. The device also includes a microprocessor programmed to execute the first and second applications and a database manager for providing access to a database, where the microprocessor is configured to execute each of the first and second applications by retrieving the first and second display templates, respectively, and using the index to the first data object to access the database in order to retrieve a value for the first data object, where the microprocessor is further configured to execute an update routine for receiving periodic data updates to the first data object via the communication interface and storing the data updates to the first data object in the database. The device also has a display generator for generating display data from the first and second templates and the first data object data and a display device for receiving said display data and displaying images.

The foregoing and other features and advantages of the present invention will be more readily apparent from the following detailed description of an embodiment of the present invention, which proceeds with references to the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

Particular embodiments of the present invention are described below with reference to the following drawings, wherein:

FIG. 1 is a functional block diagram illustrating an example of a conventional architecture for communication of a client device with a server connected to a public IP wide area network, where the client communicates through a LAN also connected to the IP network;

FIG. 2 is a functional block diagram illustrating another example of a conventional architecture for communication of a client device with a server connected to a public IP wide area network, where the client communicates through a public switched telephone network to a network access server also connected to the IP network;

FIG. 3 is a functional block diagram illustrating an example of a client system architecture for the client device of FIGS. 2 and 3;

FIG. 4 is a software architecture diagram illustrating an example of an operating system for the client system architecture of FIGS. 1-3;

FIG. 5 is a functional block diagram illustrating an example of an architecture for communication of a client device according to the present invention with a server connected to a public IP wide area network, where the client communicates through a LAN also connected to the IP network;

FIG. 6 is a functional block diagram illustrating another example of an architecture for communication of a client device according to the present invention with a server connected to a public IP wide area network, where the client communicates through a public switched telephone network to a network access server also connected to the IP network;

FIG. 7 is a diagram illustrating a front view of an embodiment of the client device, according to the present invention, shown in FIGS. 5, 6 and 7;

FIG. 8 is a functional block diagram illustrating an example of a client system architecture for the client device of the present invention;

FIG. 9 is a data diagram illustrating a channel ID value table for the client device of the present invention;

FIG. 10 is a functional block diagram illustrating another example of a client system architecture for the client device of the present invention; and

FIG. 11 is a software architecture diagram illustrating an example of an operating system for the client device of the present invention;

FIG. 12 illustrates an example of an exchange of messages involved in a user channel selection.

FIG. 13 illustrates an exemplary display page of a SHTML document after processing.

FIG. 14 is a diagram illustrating a PID device connected to a personal computer for the purpose of synchronizing data;

FIG. 15 is a functional block diagram illustrating an embodiment of a software architecture for synchronizing data between the PC and the PID of FIG. 14;

FIG. 16 is a diagram illustrating two PID devices that may be connected to an embodiment of the client device of the present invention for the purpose of synchronizing data;

FIG. 17 is a functional block diagram illustrating an embodiment of a software architecture for synchronizing and displaying data in the client device according to the present invention;

FIG. 18 is a diagram illustrating an embodiment of a graphical user interface for the calendar application of FIG. 17 on the display of the client device according to the present invention;

FIG. 19 is a diagram illustrating an embodiment of a graphical user interface for copying an entry using the calendar application of FIG. 17;

FIG. 20 is a diagram illustrating an embodiment of the graphical user interface for the calendar application of FIG. 17 after the operation of FIG. 19 is performed;

FIG. 21 is a functional block diagram illustrating an embodiment of a software architecture during a subsequent synchronization operation between the client device and a PID device;

FIG. 22 is a control flow diagram illustrating an embodiment of a process in the calendar application of FIG. 17 for copying an event from one database to another database responsive to the user actions taken with respect to FIG. 19;

FIG. 23 is a control flow diagram illustrating an embodiment of a synchronization process performed subsequent to the process of FIG. 22;

FIG. 24 is a control flow diagram illustrating an embodiment of a display process in the calendar application of FIG. 17 for displaying events from multiple calendar databases;

FIG. 25 is a control flow diagram illustrating an embodiment of an application knitting process in the calendar application of FIG. 17 for displaying data from the XML database of FIG. 11 on the graphical user interface of FIG. 18; and

FIG. 26 is a diagram illustrating another embodiment of a graphical user interface of calendar application 940 of FIG. 17, where the user interface has different columns for different databases and a user may drag and drop an event from one database to another.

Note that elements that are related to one another in the drawings are identified using the same or similar reference numbers.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

The present invention is directed toward a software architecture for a client device and method for accessing and displaying data FIG. 5 is a functional block diagram illustrating an embodiment of an architecture 300 that includes an embodiment of a client device 320 according to the present invention. The client device 320 includes a communications port, such as a network interface card, that is connected to LAN 30 via communication connection 22. Client device 320 includes a user input knob 322 for selecting network resources accessible through public IP network 50, such as those residing on server 60. FIG. 6 is a functional block diagram illustrating another embodiment of an architecture 315 that includes an embodiment of the client device 320 according to the present invention. In architecture 315, client 320 includes a communication port, such as a modem, for establishing a communication session with network access server 40 connected to IP network 50 that enables the client device to communicate with a server on the IP network, such as server 60.

FIG. 7 is a frontal view of a preferred embodiment of client device 320. Client device 320 includes a housing 330 that houses the user input knob 322, input buttons 332 and 334, which are optional, and a display 340. Display 340 is a graphical display device, such as a digital liquid crystal display (LCD), that includes a viewing area 342 in which is displayed an output page for a currently selected channel or, at initialization, a default page. Certain inventive aspects described herein may be embodied in a client device that utilizes a separate display device, such as a television. In still further embodiments, such as that shown in FIG. XX,

Display 340 also includes a previewing area 350 that includes previewing frames 352A-D and selection frame 354. Previewing frames 352A-D and selection frame 354 display graphical images representing channels accessible using the client device 320 within a predetermined previewing window. In the embodiment shown in FIG. 7, the previewing window consists of five frames. Selection frame 354 corresponds to a channel at the center of previewing window. Previewing frames 352A and 352B represent channels preceding the channel at the center of the previewing window in a predefined hierarchy of channels that may be selected. Similarly, previewing frames 352C and 352D represent channels following the channel at the center of the previewing window in the predefined hierarchy of channels that may be selected. The previewing frames 352A-D and selection frame 354 may be removed from the display 340 once a channel has been selected and re-displayed, for example, when the user rotates knob 322.

An embodiment of user input knob 322 includes a rotary encoder device that outputs a clock signal and a data signal that indicate rotational motion of the knob. The rotary encoder device may include a selection switch for generating a selection signal in response to a user depressing a shaft of the rotary encoder. As selection knob 322 is rotated, the channel at the center of the previewing window changes, with the center of the previewing window moving up or down the hierarchy of channels depending upon the direction of rotation. As the center of the previewing window is changed, graphical images, such as gif files, corresponding to the channels are scrolled through the previewing frames 352A-D and the selection frame 354. Thus, as the knob is rotated and the channels within the previewing window change, the graphical images displayed within previewing area 350 change correspondingly so as to scroll the graphical images through the previewing frames 352A-D and the selection frame 354. The user rotates the user input knob in order to preview graphical representations of the channel options in the hierarchy. The resulting effect is somewhat like a filmstrip projection.

In order to select a channel, the user rotates selection knob 322 to scroll graphical images until the graphical image corresponding to a desired channel is displayed in selection frame 354. Then, the user depresses knob 322 in order to select the desired channel. A channel identifier corresponding to the channel at the center of the previewing window is sent to an operating system executing within client device 320.

Alternatively, the user may make a selection by rotating the selection knob 322 until the desired channel is displayed in selection frame 354 and then wait for a predetermined time period to expire, e.g. a time-out event. When the time-out event occurs, e.g. through the expiration of a timer, then the channel identifier corresponding to the channel in selection frame 354 is sent to the operating system for further processing. As a further alternative, depressing the selection knob 322 when client device 320 is displaying an application program, such as a calendar or datebook application, may result in the channel application being activated with the most recently selected channel displayed.

FIG. 8 is a functional block diagram illustrating one embodiment of a processor system of the client device 320 shown in FIGS. 5-7, where the processor system is configured to receive user input via the user input knob 322 and display information to the user via display 340. The embodiment of a processor system shown in FIG. 8 includes a processor 400 that is coupled to various peripheral devices through processor bus 404. The peripheral devices coupled to processor 400 include a programmable timer 410, a memory subsystem 420, a display controller 430, a network interface circuit 440, and a knob interface circuit 450.

One of ordinary skill in the art will readily recognize that a variety of computer systems may be adapted provide the hardware platform for the client device 320. In one embodiment of the present invention, a Geode GX1 processor from National Semiconductor Corporation (Santa Clara, Calif.: www.national.com) may be used as processor 400. The GX1 processor may communicate through a Peripheral Component Interconnect (PCI) bus to a CS5530 Geode I/O Companion Multifunction South Bridge device to drive display and communications subsystems. For example, a CS9211 Graphics Companion Flat Panel Display Controller may be used as display controller 230 to drive display 140. A Universal Serial Bus (USB) interface of the CS5530 may be attached to an ethernet adapter in order to provide an interconnection to a broadband communication interface device for highspeed communication with the Internet. Examples of broadband communication interface devices are digital subscriber line (DSL) gateways and cable modems. For PSTN access, a modem device may be connected to the PCI bus. One example of a modem that may be connected to the PCI bus is composed of the Analog Devices (Norwood, Mass.: www.analogdevices) Model 1807 modem processor and Model 1804 data access arrangement (DAA).

Programmable timer 410 is programmed with a time-out value by processor 400 and, when the time-out value is reached, generates an interrupt signal 412 that is input to the processor. Memory subsystem 420 stores data and executable code for processes running on processor 400, such as channel application 402. Display controller 430 drives a display device, such as the display 340 of client device 420 shown in FIG. 7, and receives display updates under the control of processor 400. A network interface circuit 440, such as a network interface card (NIC) or a modem, sends and receives data packets, such as HTTP commands and responses, over network connection 22. Knob interface circuit 450 receives and decodes the user selection information that is input via knob circuit 322, as illustrated in FIGS. 5-7.

In the embodiment of FIG. 8, knob circuit 322 outputs three signals, a clock signal 452, and a data signal 454, and a selection signal 456. When the user rotates the knob, the clock signal 452 will transition between logic states, such as a logical "1" and logical "0". When knob interface circuit 450 detects a transition in the clock signal, such as a falling edge, then it checks the value of the data signal 454. If the data signal is a logic 1, then the knob has been rotated in one direction, and when the data signal is a logic 0, then the knob has been rotated in the opposite direction. By counting the number of clock pulses and sensing the data signal value, a count representing the position of the knob is maintained by knob interface circuit 450.

The user input from knob 322 is received and processed by a channel selection application 402. An example of a design approach for channel selection application 402 to detect the changes in the position of knob 322 is an interrupt routine based upon a polling approach. This approach assumes that the system of client 320 has been initialized at power-up such that a data index, e.g. a data pointer, indexes or points to a default start value for the center of the selection window discussed above and the data index points to a portion of a data structure containing the predetermined hierarchy of channels. This approach further assumes that the knob 322 is an incremental device, e.g. there is not an absolute relationship between the knob position and an output value of the knob circuit, and that a previous count value is initialized at start-up to the same value present in the counter within knob interface circuit 450.

When timer 410 times-out and interrupts processor 400, the interrupt routine is entered and the processor will read the current count value from the knob interface circuit 450. Processor 400 compares the current count value to the previous count value. If the current count and previous count values are the same, then the knob has not been moved and no further action is required.

If the current count and previous count values are not the same, then knob 322 has been turned and the pointer to the center of the preview window in the predetermined hierarchy of network resources is incremented or decremented according to the change in counter value.

Channel application 402 causes processor 400 to obtain the graphics corresponding to the channels within the preview window and updates the graphics in the preview areas 352A-D and selection frame 354 of display 340, accordingly, which results in the graphics scrolling across the preview area 350. The previous count value is then set to the current count value to prepare for the next polling period and the process continues on to check for additional user input.

The processor 400 then checks whether the selection signal 456 is set. If signal 456 is not set, then processor 400 resets timer 410 and returns from the interrupt routine. However, if signal 456 is set, then process 400 obtains the channel value pointed to by the pointer to the hierarchy of channels for processing by channel application 402, as discussed in further detail below. The register or flip-flop within knob interface circuit 450 that stores the selection signal 456 is then reset.

FIG. 9 is a block diagram of an embodiment of a data structure 460 for the hierarchy of channels used in one embodiment of the present invention. Data structure 460 is shown in FIG. 9 as a table containing multiple channel identifier pairs composed of a channel ID value and a pointer to a graphic. The structure 460 can take on a variety of other forms, such as a linked list, as one of ordinary skill in the art will readily understand. Pointer 462 is the pointer to the center of the preview window and generally points to the channel identifier pair for the network resource shown in the select area 354 of FIG. 7. The channel identifier pairs stored in the data structure 460 for the hierarchy include a channel ID value for the channel and a pointer to a graphic for the channel. The graphic for the channel identifier pair pointed to by pointer 462 is displayed in selection frame 354. The graphics for the other network resource identifier pairs within the preview window, i.e. the network resource identifier pairs that are adjacent to the network resource identifier pair currently indexed by -pointer 462, are displayed in the preview windows 352A-D of FIG. 7. In the embodiment shown in FIG. 7, the preview window is plus and minus two pairs relative to pointer 462 for a total of five graphics displayed in preview area 350.

As selection knob 322 is rotated, the position of pointer 462 moves up or down the hierarchy depending upon the direction and magnitude of the knob rotation. As the preview window is changed by the knob rotation to include channel identifier pairs not previously displayed, the pointer to the graphic in each new channel identifier pair is used to retrieve the graphic for the channel for output to the display 340 by processor 400. As the knob 322 is rotated clockwise or counterclockwise, the graphics for the network resources within the preview window are scrolled forwards or backwards, respectively, through the preview area 350. When the selection signal 456 is activated by depressing the knob 322, then the channel ID value from the channel identifier pair indexed by pointer 462 is retrieved for processing by channel application 402. Data structure 460 resides in memory subsystem 420, which preferably includes persistent memory elements, such as flash memory, for storing the hierarchy. Likewise, the graphics for the channels may also be stored in persistent memory elements within memory subsystem 420.

As noted above, the selection signal 456 may be replaced with a time-out event from a timer, such as time-out signal 412 from timer 410 of FIG. 8. Thus, the user rotates knob 322 until the icon or graphic representing the desired channel is displayed in selection window 354. The user then stops rotating knob 322 and waits for a predetermined time period, which may be user selectable. In this embodiment, processor 400 resets timer 410 with the predetermined time period each time it processes the signals from the knob interface circuit. When the user stops turning knob 322, the timer does not get reset and, when the predetermined time period expires, timer 410 generates timer signal 412. As a result, the channel ID value from the channel identifier pair indexed by pointer 462 is retrieved for processing by channel application 402. When an application other than channel selection application 402, such as a calendar application, is currently running, then processor. 400 may be configured to interpret selection signal 456 activated by knob 322 as a command to activate the channel selection application 402

The channel identifier pairs within data structure 460 may be predetermined by a manufacturer of the client device 320, defined by the user of client device 320, or both. A user interface application may be included that allows a user to update the contents of data structure 460. Alternatively, channel selection application 402 may be used to access a particular channel that provides for the request and download of a new channel identifier pair and associated data, such as in a XML file, as is discussed below, and a graphic representing the new channel in the data structure.

By using an incremental rotary encoder device for user selection knob 322, the number of selections available to the user is not limited by the number of positions of the knob 322. Consequently, the number of selections available to the user is determined by the number of channel identifier pairs provided for by data structure 460. Thus, the amount of available memory substantially determines the number of selections available to the user.

The clock and data signals generated by the rotary encoder of knob 322 may also be referred to as quadrature signals and one embodiment of the knob interface circuit 450 is a quadrature decoder circuit. When knob 322 is rotated forward, e.g. in a clockwise direction, the phase of the clock signal 452 leads the phase of the data signal 454 and the data signal is in a logic zero state at the rising edge of the clock signal. When knob 322 is rotated backwards, e.g. counter-clockwise, then the phase of the data signal 454 leads the phase of the clock signal and the data signal is in a logic one state at the rising edge of the clock signal.

While the architecture of FIG. 8, and the corresponding interrupt routine, is configured to monitor user manipulation of knob 322 by periodically polling the knob interface circuit 450, an interrupt driven approach may also be employed with respect to channel selection application 402. In FIG. 10, an architecture is shown whereby the processor 400 directly monitors user input via knob 322 through the use of the processor's interrupt scheme. In FIG. 10, clock signal 452 is coupled to a first interrupt input of processor 400, such as a non-maskable interrupt (NMI) input and selection signal 456 is coupled to a second interrupt input of processor 400, such as an interrupt request (IRQ) signal. Data signal 454 may be coupled to an interrupt level input or be read through bus 404 as an interrupt vector or simply as data. One of ordinary skill in the art will appreciate that there are a variety of interrupt based approaches and corresponding designs and that the present embodiment is illustrative of one such approach.

As an example of an interrupt routine for directly monitoring the rotation of knob 322 using processor 400 using clock signal 452 to generate an interrupt. In this approach, the interrupt routine is entered when clock signal 452 transitions to an active state, e.g. a rising edge of clock signal 452. At step 452, the value of data signal 454 is read. As noted above, data signal 454 may be input to processor 400 in various ways, including using a buffer, such as a flip-flop. If the value of data signal 454 is a logic zero, then the pointer to the center of the preview window in the hierarchy of network resources is incremented. If the value of data signal 454 is a logic one, then the pointer is decremented. In either case, the preview area 350 is updated with graphics for the channels within the preview window. Once this processing is completed, the interrupt routine returns and awaits the next transition of clock signal 452.

Another interrupt routine may be used to process an interrupt caused by selection signal 456. This interrupt routine is entered when selection signal 456 transitions to an active state, e.g.. a rising edge of selection signal 456. At this point, any rotation of knob 322 has been handled by the interrupt routines discussed above. As a result, the selection signal interrupt routine only needs to process the selected channel, which is pointed to by the current position of the pointer to the center of the preview window. Therefore, the channel ID value indicated by the pointer is processed by channel application 402 for further processing, as discussed in further detail below, and the channel selected by the user is displayed to the user in the display area. 340. The user selection interrupt routine then returns to normal processing.

FIG. 11 is a software architecture diagram illustrating an embodiment of a software architecture 500 for client device 320. Similar to software architecture 200 of FIG. 4, architecture 500 includes an operating system 510 for controlling the resources of the client device and activating application program 520 and channel application 302. Architecture 500 also includes a display driver 530 for driving the display monitor of client device 530, user interface drivers 540 for receiving and processing user input signals from a user interface, including knob 322, and a communications driver 550 for handling a communications via network interface circuitry for connection 22.

An example of an operating system suitable for use as OS 510 in client device 320, according to the present invention, is the QNX operating system available from QNX, 175 Terence Matthews Crescent, Kanata, Ontario Canada, k2M 1W8. See www.gnx.com for further details regarding the QNX OS.

The QNX OS includes features such as multitasking, threads, priority-driven preemptive scheduling, synchronization, and fast context switching that enhance its real-time performance. Preferably, the OS has a small memory footprint for execution and storage to keep cost and complexity down in the client device.

For networking services, the preferred device also is configured to provide a full implementation of the TCP/IP protocol suite and utilities, including PPP, DHCP, NFS, RPC, and SNMP, that make it possible to run a variety of Internet services over a wide choice of networks. Using Ethernet with a network interface card, or serial lines, with a modem, users can connect to the Internet, the private wide area networks, and log-in to remote systems. The network services may also be scaled back to a small TCP/IP stack.

The device also includes a customized windowing system that permits high-end graphics to be displayed even on small memory-constrained devices. This graphical user interface (GUI) has a small memory footprint.

Architecture 500 also includes a thin server process 560, which is a server process residing in the client device rather than a remote server, that accesses a template store 562 and an Extended Markup Language (XML) database 564. The QNX OS discussed above includes a server that may be modified for use as the thin server process 560. XML and the more familiar Hypertext markup language (HTML) are both restricted forms of the Standard Generalized Markup Language (SGML) defined by the International Standards Organization (ISO) standard 8879 (1986). XML 1.0 (Feb. 10, 1998), herein incorporated by reference, is defined by the World Wide Web Consortium (W3C) and is available at www.w3c.com.

XML describes a class of data entities called XML documents and generally describes the behavior of computer programs that process these documents. XML documents are made up of storage units called entities that contain either parsed or unparsed data. Parsed data is made up of characters, some of which form character data and some of which form markup. Markup encodes a description of the document's storage layout and logical structure. XML provides a mechanism to impose constraints on the storage layout and logical structure. An XML processor is a program configured to read and interpret XML documents according to the XML standard and process them into a viewable format on behalf of an application program.

Each XML document is structured according to a document type definition (DTD) that contains or points to markup declarations that describe a class of documents. The DTD can point to an external subset of entities containing markup declarations or can contain the markup declarations directly in an internal subset, or both. The DTD for a document consists of both subsets taken together. Each XML document also contains one or more elements that are delimited by tags. Each element has a type, identified by a name and sometimes called its generic identifier. Table 1 below is an example of a DTD file used for defining a channel, according to the present invention, for weather information.