Embedded web server - Patent Review 5973696

Description Submit all comments and votes

COPYRIGHT NOTICE

The appendices attached to the disclosure of this patent contain material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

APPENDIX

This application includes a microfiche appendix containing a source code listing in the C programming language of header files defining data structures representing an archive of content as used by the EmWeb.TM. product. This appendix shows an example of a particular embodiment of the invention incorporating features thereof which are described in detail below.

FIELD OF THE INVENTION

The present invention relates generally to graphical user interfaces (GUIs), i.e. user interfaces in which information can be presented in both textual form and graphical form. More particularly, the invention relates to GUIs used to control, manage, configure, monitor and diagnose software and hardware applications, devices and equipment using a World-Wide-Web client/server communications model. Yet more particularly, the invention relates to methods and apparatus for developing and using such GUIs based on a World-Wide-Web client/server communications model.

RELATED ART

Many modern communications, entertainment and other electronic devices require or could benefit from improved local or remote control, management, configuration, monitoring and diagnosing. It is common for such devices to be controlled by a software application program specifically written for each device. The design of such a device includes any hardware and operating environment software needed to support the application, which is then referred to as an embedded application, because it is embedded within the device. Embedded application programs are generally written in a high-level programming language such as C, C++, etc., referred to herein as a native application programming language. Other languages suitable to particular uses may also be employed. The application program communicates with users through a user interface, generally written in the same high-level language as the application.

The representation of an application in a native application programming language is referred to as the application program source code. A corresponding representation which can be executed on a processor is referred to as an executable image.

Before an application written in a high-level language can be executed it must be compiled and linked to transform the application source code into an executable image. A compiler receives as an input a file containing the application source code and produces as an output a file in a format referred to as object code. Finally, one or more object code files are linked to form the executable image. Linking resolves references an object module may make outside of that object module, such as addresses, symbols or functions defined elsewhere.

Source code may also define arrangements by which data can be stored in memory and conveniently referred to symbolically. Such defined arrangements are referred to as data structures because they represent the physical arrangement of data within memory, i.e., the structure into which the data is organized.

Most commonly, remote control, management, configuration, monitoring and diagnosing applications employ unique proprietary user interfaces integrated with the application software and embedded into the device. Frequently these user interfaces present and receive information in text form only. Moreover, they are not portable, generally being designed to operate on a specific platform, i.e., combination of hardware and software. The devices for which control, management, configuration and diagnosing are desired have only limited run-time resources available, such as memory and long-term storage space. Proprietary interfaces are frequently designed with such limitations to data presentation, data acquisition and portability because of the development costs incurred in providing such features and in order to keep the size and run-time resource requirements of the user interface to a minimum. Since each user interface tends to be unique to the particular remote control, management, configuration, monitoring or diagnosing function desired, as well as unique to the operating system, application and hardware platform upon which these operations are performed, significant time and/or other resources may be expended in development. Graphics handling and portability have therefore been considered luxuries too expensive for most applications.

However, as the range of products available requiring control, management, configuration, monitoring or diagnosing increase, such former luxuries as graphical presentation and portability of the interface from platform to platform have migrated from the category of luxuries to that of necessities. It is well known that information presented graphically is more quickly and easily assimilated than the same information presented as text. It is also well known that a consistent user interface presented by a variety of platforms is more likely to be understood and properly used than unique proprietary user interfaces presented by each individual platform. Therefore, portable GUIs with low run-time resource requirements are highly desirable.

With the growing popularity and expansion of the Internet, one extremely popular public network for communications between computer systems, and development of the World-Wide-Web communication and presentation model, a new paradigm for communication of information has emerged.

The World-Wide-Web and similar private architectures such as internal corporate LANs, provide a "web" of interconnected document objects. On the World-Wide-Web, these document objects 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. However, except as explained below, the World-Wide-Web is based principally on static information contained in the content documents available to the browsers through the servers. Such a limitation would make the World-Wide-Web paradigm useless as a GUI which must present dynamic information generated by a device or application.

The World-Wide-Web communications paradigm 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 objects 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. Bemers-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 a 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.

For example, here are several lines of HTML:

______________________________________ Some words are bold, others are italic. Here we start a new paragraph.Here's a link to the <A HREF="http://www.agranat.com">Agranat Systems, Inc.</A> home page. ______________________________________

This sample document is a hypertext document because it contains a "link" to another document, as provided by the "HREF=." The format of this link will be described below. A hypertext document may also have a link to other parts of the same document. Linked documents may generally be located anywhere on the Internet. When a user is viewing the document using a client program called a Web browser (described below), the links are displayed as highlighted words or phrases. For example, using a Web browser, the sample document above would be displayed on the user's screen as follows:

Some words are bold, others are italic. Here we start a new paragraph.

Here's a link to Agranat Systems. Inc. home page.

In the Web browser, the link may be selected, for example by clicking on the highlighted area with a mouse. Selecting a link will cause the associated document to be displayed. Thus, clicking on the highlighted text "Agranat Systems, Inc." would display that home page.

Although a browser can be used to directly request images, video, sound, etc. from a server, more usually an HTML document which controls the presentation of information served to the browser by the server is requested. However, except as noted below, the contents of an HTML file are static, i.e., the browser can only present a passive snapshot of the contents at the time the document is served. In order to present dynamic information, i.e., generated by an application or device, or obtain from the user data which has been inserted into an HTML-generated form, conventional World-Wide-Web servers use a "raw" interface, such as the common gateway interface (CGI), explained below. HTML provides no mechanism for presenting dynamic information generated by an application or device, except through a raw interface, such as the CGI. Regarding obtaining data from the user for use by the application or device, although standard HTML provides a set of tags which implement a convenient mechanism for serving interactive forms to the browser, complete with text fields, check boxes and pull-down menus, the CGI must be used to process submitted forms. Form processing is important to remote control, management, configuration, monitoring and diagnosing applications because forms processing is a convenient way to configure an application according to user input using the World-Wide-Web communications model. But, form processing using a CGI is extremely complex, as will be seen below, requiring an application designer to learn and implement an unfamiliar interface. A CGI is therefore not a suitable interface for rapid development and prototyping of new GUI capabilities. Moreover, a developer must then master a native application source code language (e.g., C, C++, etc.), HTML and the CGI, in order to develop a complete application along with its user interface.

Models of the World-Wide-Web communications paradigm for static content and dynamic content are shown in FIGS. 14 and 15, respectively. As shown in FIG. 14, a browser 1401 makes a connection 1402 with a server 1403, which serves static content 1405 from a storage device 1407 to the browser 1401. In the case of dynamic content, shown in FIG. 15, the server 1403 passes control of the connection 1402 with the browser 1401 to an application 1501, through the CGI 1503. The application 1501 must maintain the connection 1402 with the browser 1401 and must pass control back to the server 1403 when service of the request which included dynamic content is complete. Furthermore, during service of a request which includes dynamic content, the application 1501 is responsible for functions normally performed by the server 1403, including maintaining the connection 1402 with the browser 1401, generating headers in the server/browser transport protocol, generating all of the static and dynamic content elements, and parsing any form data returned by the user. Since use of the CGI 1503 or other raw interface forces the application designer to do all of this work, applications 1501 to which forms are submitted are necessarily complex.

In order to provide dynamic content to a browser, the World-Wide-Web has also evolved to include Java and other client side scripting languages, as well as some server side scripting languages. However, these