|
|
|
Structured document (e.g., HTML, SGML, ODA, CDA) |
Wireless communication device with markup language based man-machine interface6317781
Abstract
A system, method, and software product provide a wireless communications device with a markup language based man-machine interface. The man-machine interface provides a user interface for the various telecommunications functionality of the wireless communication device, including dialing telephone numbers, answering telephone calls, creating messages, sending messages, receiving messages, establishing configuration settings, which are defined in markup language, such as HTML, and accessed through a browser program executed by the wireless communication device. This feature enables direct access to Internet and World Wide Web content, such as Web pages, to be directly integrated with telecommunication functions of the device, and allows Web content to be seamlessly integrated with other types of data, since all data presented to the user via the user interface is presented via markup language-based pages. The browser processes an extended form of HTML that provides new tags and attributes that enhance the navigational, logical, and display capabilities of conventional HTML, and particularly adapt HTML to be displayed and used on wireless communication devices with small screen displays. The wireless communication device includes the browser, a set of portable components, and portability layer. The browser includes protocol handlers, which implement different protocols for accessing various functions of the wireless communication device, and content handlers, which implement various content display mechanisms for fetching and outputting content on a screen display.
Claims
We claim:
1. A new wireless communication device comprising:
a screen display;
a memory;
a processor coupled to the screen display and the memory;
a plurality of user interface pages stored in the memory and encoded in a markup language, the user interface pages providing substantially all access to the functions of the wireless communication device, and including user interface pages providing access to telecommunication functions of the wireless communication device; and
a markup language browser, executed by the processor, and communicatively coupled to the memory and the screen display, that:
accesses either the stored user interface pages from the memory or remotely stored pages encoded in the markup language via a telecommunications network;
decodes accessed pages to display user interface elements on the screen display; and
effects a telecommunication function in response to a user input to a displayed user interface element.
2. A computer implemented method processing a page of data encoded in a markup language, the page including a reference to an embedded object, the method comprising:
a receiving a user selection of a displayed user interface element in the page, the element associated with a URL encoded within the page, the URL having a protocol component and a data component;
invoking the embedded object, and providing the URL to the embedded object for processing; and
responsive to the embedded object not processing the URL, either fetching content specified by the data component, or executing a command specified by the data component.
3. A computer implemented method of processing a page of data encoded in a markup language, the page including a reference to an embedded object, the method comprising:
receiving a user selection of a displayed user interface element in the page, the element associated with a command encoded within the page, the command having a protocol component and a data component; and
invoking the embedded object, and providing the command to the embedded object for processing, the embedded object processing the command using an internally defined function.
4. A wireless communication device comprising:
a screen display;
a memory;
a processor coupled to the screen display and the memory;
a plurality of user interface pages stored in the memory and encoded in a markup language, the user interface pages providing substantially all access to the functions of the wireless communication device, and including user interface pages providing access to telecommunication functions of the wireless communication device; and browser means excuted by the processor, and communicatively coupled to the memory and the screen display, and including:
to the memory and the screen display, and including:
means for accessing either the stored user interface pages from the memory or remotely stored pages encoded in the markup language via a telecommunications network;
means for decoding accessed pages to display user interface elements on the screen display; and
means for effecting a telecommunication function in response to a user input to a displayed user interface element.
5. A computer implemented method for automatically displaying help data to a user, comprising:
displaying a window having a title in a title bar area;
incrementing a coutner of an amount of time elapsed since a last user input; and
responsive to the counter equaling or exceeding a threshold amount of time, replacing the title by scrolling first help data in the title bar area.
6. The method of claim 5, further comprising:
responsive to a completion of scrolling the first help data;
redisplaying the title in the title bar;
resetting the counter;
incrementing the counter; and
responsive to the counter equaling or exceeding the threshold amount, replacing the title bar by scrolling second help data in the title bar.
7. The method of claim 5, further comprising the initial steps of:
receiving markup language page including a title tag defining the title and a help tag defining the first help data;
storing the first help data; and
displaying the markup language page in the window, including displaying the title in the title bar.
8. A browser program conduct for controlling the operation of a wireless communication device by execution of the browser by a processor of the wireless communication device, the browser executing the operations of:
decoding a markup language page, the page including a title tag defining a title of the page, and a help tag specifying help data;
storing the help;
displaying the page in a window;
displaying the title in a title bar area of the window;
determining an elapsed amount of time since a last user input;
responsive to the elapsed amount exceeding a threshold, replacing the title in the title bar area by scrolling the stored help data in the title bar; and
responsive to completion of the scrolling of the stored hep data, redisplaying the title in the title bar area.
9. A computer implemented method for automatically displaying data to a user, comprising:
receiving a markup language page containing a tag including displayable text in a header portion of the page, and a title;
displaying the markup language page in a window having the title in a title bar area;
incrememnting a counter of an elapsed amount of time; and
responsive to the counter equaling or exceeding a threshold amount of time, replacing the title by scrolling the dispayable text included in the tag in the title bar area.
10. The computer implemented method of claim 9, wherein the tag contained in the markup language page is <MARQUEE> tag.
11. The computer implemented method of claim 9, wherein the data displayed to the user is advertising data.
12. A browser program product for controlling the operation of a wireless communication device by execution of the browser by a processor of the wireless communication device and displaying a page of markup language data, the browser executing the operations of:
receiving a markup language page containing a tag including displayable text in a header portion of the page, and a title;
displaying the markup language page in a window having the title in a title bar area;
incrementing a counter of an elapsed amount of time; and
responsive to the counter equaling or exceeding a threshold amount of time, replacing the title by scrolling the displayable text included in the tag in the title bar area.
13. A computer implemented method of navigating a page of data including at least one selectable hyperlink, in a computer system including a screen display but not including an independent cursor controlled by a peripheral pointing device, the method comprising:
scrolling the page in a direction on the screen display in response to a user input to display only a portion of the page; and
automatically and iteratively assigning a next visible hyperlink in the direction of the scrolling and in the displayed portion of the page to a user selectable key.
14. A computer implemented method of navigating a page of data including a plurality of form fields, each form field having a type, in a computer system including a screen display and a keypad having a plurality of keys, but not including an independent cursor controlled by a peripheral pointing device, the method comprising:
scrolling the page in a direction on the screen display in response to a user input to display only a portion of the data file;
determining whether a next form field in the drection of scrolling is visible;
responsive to the next form field in the direction of scrolling being visible, making next form field a current form field for receiving a user input; and
assigning an action for manipulating the current form field to a key of the key pad according to the type of the current form field.
Description
BACKGROUND
1. Field of Invention
This invention relates to man-machine interfaces for wireless communication devices, and more particularly, to man-machine interfaces constructed from markup languages.
2. Background of the Invention
Wireless communication devices are becoming an increasingly prevalent for personal communication needs. These devices include, for example, cellular telephones, alphanumeric pagers, "palmtop" computers and personal information managers (PIMS), and other small, primarily handheld communication and computing devices. Wireless communication devices have matured considerably in their features, and now support not only basic point-to-point communication functions like telephone calling, but more advanced communications functions, such as electronic mail, facsimile receipt and transmission, Internet access and browsing of the World Wide Web, and the like.
Generally, wireless communication devices have software that manage various handset functions and the telecommunications connection to the base station. The software that manages all the telephony functions is typically referred to as the telephone stack, and the software that manages the screen display and processes user inputs of key presses is referred to as the Man-Machine-Interface or "MMI." The MMI is the topmost, and most visible layer of the wireless communication device's software.
Because wireless communication devices have generally reached a very desirable and small form factor, the primary determinant of a successful device will likely be in its feature set and its ease of use. Thus, the ability to quickly design, test, and deliver wireless communication devices that are both easy to use, and have a rich set of features--attributes that are often opposed to one another--will be essential to successful product performance.
However, wireless communication devices present a variety of more challenging design and implementation issues that do not arise with larger processor-based systems, such as notebook and desktop computers, which may also have similar telecommunication features. These design challenges include the design of the user interface, the customization of the devices for particular service operators, the integration of Internet and World Wide Web access with other communication functionality, and the software development process.
User Interface Design Constraints
Unlike desktop and notebook computers, wireless communication devices have a form factor which requires a very small screen display size. Desktop computers typically have displays with at least 14" screen size, and resolution typically between 640.times.480 and 1024.times.768 pixels. In contrast, wireless communication devices typically have a screen size between 25.times.25 mm and 80.times.120 mm, and resolutions between 90.times.60 to 120.times.120 pixels, or about 3-8% of the size of the desktop or notebook screen. As a direct result, the user interface design of the wireless communication device must provide access to essentially the same features as desktop computers, such as electronic mail, facsimiles, and Web browsing, yet with only a fraction of the screen area for displaying text, images, icons, and the like. This problem of constructing the user interface to provide these features is particularly significant when handling Web based content, since conventional Web content, such as forms, assume the larger screen size of conventional desktop computers. Displaying such forms on the small screen of a wireless communication device results in jumbled and difficult to use content.
Another user interface limitation of wireless communication devices is the severely restricted set of inputs available to the user. Conventional desktop or notebook computers have cursor based pointing devices, such as computer mouse, trackballs, joysticks, and the like, and full keyboard. This enables navigation of Web content by clicking and dragging of scroll bars, clicking of hypertext links, and keyboard tabbing between fields of forms, such as HTML forms. Wireless communication devices have a very limited number of inputs, typically up and down keys, and one to three softkeys.
Accordingly, it is desirable to provide a software architecture for the MMI of a wireless communication device that enables the customization and use of user interface with Web content accounting for the limited screen resolution and input functionality of the wireless communication device.
Integration of Internet/Web Functional with Telephony
With the advent of the Internet and the World Wide Web, the highest performance wireless communication devices provide complete Internet access and the ability to directly browse the World Wide Web. Current devices provide Internet and World Wide Web access through a strictly modal interface, in which the user must select between using the wireless communication device in a browser mode, or in its native telecommunications mode for making telephone calls, accessing a stored telephone book, sending facsimiles, and the like. In the "browser mode" the user cannot dial a telephone number to make a telephone call; likewise in the telephony mode, the user cannot access a Web site. Thus, the user is unable to operate the wireless communication device in a seamless fashion that allows Web content to be downloaded and manipulated in context of the telephone functions, such as embedding an item of Web content that is obtained while browsing into the user's telephone book, or into an email message.
Accordingly, it is desirable to provide an MMI in which Internet and World Wide Web access features are seamlessly integrated with the telephony and other controls of the wireless communication device so that user can access any feature of the wireless communication device at any time.
Software Engineering of the MMI
Typically, an MMI is implemented as a module in a larger piece of code that manages the telephone control functions. The MMI is coded in the same computer language as the rest of the telephone control software. This makes the MMI difficult to modify without using the same programming skills and tools used to create the entire telephone control software. In other words, changing anything in the MMI requires the services of a skilled programmer familiar with the underlying telephony programming details and computer language. In addition, since the MMI is an integral part of the code for the telephone control software, implementing new changes in the MMI means compiling a new image of all the telephone control software, and testing the result to ensure that the new MMI features are compatible with all other code modules. In short, problems introduced by modifying the MMI software can potentially cause the handset to malfunction, disrupting service on the network to other users. Depending on the extent of the modifications, the change of any portion of the telephone control software can result in bugs, and/or the need for new type approval of the entire wireless communication device. Thus, it is desirable to provide a software architecture which separates the design and implementation of the MMI functionality from the implementation of the telephone control software, allowing the manufacturer to quickly and safely customize the MMI design to suit the needs of a particular customer
Customizing of the MMI for Service Operators: "Branding"
In the wireless communication device industry, the services operators, such as cellular service providers, are interested in attracting and retaining their customers by aggressively branding their wireless communication device products, and offering new telephony features and network services to the user. Important among these are services that add value to the user, such as voice mail, electronic messaging, Internet access, and the like as mentioned above. "Branding" is the embedding of insignia, logos, or other indicia into the MMI of the wireless communication device and its features that identifies it to the consumer as originating from the service operator.
The manufacturers of the wireless communication device, who typically provide only the basic hardware components, must therefore provide a way for the service operator to integrate these features and services into the wireless communication device by software programming, and provide a mechanism for branding the features. A key problem is that these services are necessarily different in their functionality and requirements, and the task of providing users with a current array of services and features is a difficult one.
Wireless communication device manufacturers have traditionally attacked this problem by making a special version of the wireless communication device control software for each service operator selling that wireless communication device in conjunction with its own communication services. Each specific version of the wireless communication device contains the device manufacturer's branding, the operator's branding, and support for whatever features and services the service operator supports. Each of these versions becomes a different piece of software to be tested, maintained, and modified as new features or services are provided to the consumer. This significantly increases the software development expense and maintenance issues. Further, unless the wireless communication device manufacturer provides the service operator with the source code of the MMI and telephone control software, it requires the wireless communication device manufacturer to be directly involved in the branding and MMI design requirements of the service operator. Thus, it desirable to provide a software architecture for an MMI that allows the wireless communication device manufacturer to provide a single body of telephone control software to each service operator, and allows each service operator to independently, and without the assistance of the wireless communication device manufacturer, design, implement, and brand the MMI for the wireless communication device.
SUMMARY OF THE INVENTION
The present invention overcomes the various limitations of conventional wireless communication devices by providing a wireless communication device with an MMI that is based on a markup language. A markup language is a computer programming language that allows the content of a page or a screen display to be defined by the inclusion of predefined symbols in the content itself indicating the logical components of the content, instructions for the layout of the content on the page or screen, or other data which can be interpreted by some automatic system responsible for displaying, manipulating or modifying the content.
In one aspect the present invention provides a wireless communication device including a user interface defined in a markup language. To effect this, the present invention includes a markup language browser that it uses to provide both telephony control of the wireless communication device, in response to user selection of telephony functions in the user interface, and Internet access via the HyperText Transport Protocol (HTTP), in response to user selection of data items associated with content located on the Internet.
In one embodiment, the telecommunication control and other functions of the wireless communication device are defined in various user interface pages written in a markup language. Each control function is associated with, or activated by a Uniform Resource Locator (URL). A URL is a data item specifying a protocol for obtaining a data item, and which data item should be fetched or manipulated. The user interface pages are stored in a local memory of the wireless communication device, and fetched by the browser, which decodes them and displays the appropriate user interface elements. The browser can also modelessly fetch markup language pages or other content that is stored remotely, by accessing such pages via a telecommunications network such as the World Wide Web, and likewise decode and display these remotely accessed pages. When a user interface page is displayed, user selection of a control function passes a URL or command data to the browser. The browser effects a telecommunication function in response the received URL or command.
The browser preferably includes a number of protocol handlers, including a telephony protocol handler, a local file protocol handler, and an remote file protocol handler, and a number of content handlers, including a markup language handler. The telephony protocol handler decodes URLs for telephony control features such as telephone dialing and answering, and activates underlying functions of telephony control software controlling the hardware of the wireless communication device. Any content of the URL that is needed to display the telephony controls is provided to the markup language content handler, which parses the content and displays it on a screen display. The markup language content handler is generally responsible for displaying any fetched markup language pages, including all user interface pages, and for receiving user inputs to these pages via forms and other input means.
The markup language handler generally receives content from two sources, the local file protocol handler and the remote file protocol handler. The remote file protocol handler decodes URLs for accessing content on the World Wide Web, and provides the fetched content, such as a Web page, form, applet, or the like to the markup language content handler for outputting the content to the screen display of the wireless communication device. One suitable remote file protocol handler implements HTTP. The local file protocol handler decodes URLs for accessing local user interface files and provides such content to the markup language content handler. In a preferred embodiment of the MMI, the user interface is defined in HyperText Markup Language, or "HTML," and the browser includes a HTML content handler that displays both Web content and user interface featured defined in HTML.
The use of a markup language to define the MMI of a wireless communication device provides numerous advantages over conventional MMI software architectures. First, the use of a markup language allows for complete and seamless integration of Internet and World Wide Web access into the telephony and other features of the wireless communication device. Since the MMI uses a markup language such as HTML to display all the functional screens, the World Wide Web content (which is also written in HTML) has the same appearance as other features of the wireless communication device. More particularly, the pages of the MMI are accessed using URLs, just as Web content is similarly accessed. When displaying a functional page the wireless communication device accesses a local URL; when displaying Web content, the wireless communication device automatically initiates a connection with a Web server to obtain the Web content. The markup language based MMI thus allows for a modeless user interface that enables the user to access the Internet and the World Wide Web at any time, without having to switch the wireless communication device between telephony and "browser" modes, as in conventional devices.
As a further benefit of the markup language based MMI, Web content such as Web pages, forms, and the like, from the World Wide Web can be accessed and incorporated directly into telephony, messaging, and other non-Internet based features of the wireless communication device. For example, in a preferred embodiment, a wireless communication device has a telephone book of stored telephone numbers and names. Conventionally, the user would have to manually key these entries in using the keypad of the wireless communication device. In a wireless communication device using an MMI in accordance with the present invention, the user could add an entry to the telephone book simply by accessing a telephone directory on the World Wide Web, which can contain HTML that allows the user to easily store the information directly into the telephone book.
The use of a markup language also reduces the complexity of the software engineering process for creating the MMI for a particular wireless communication device. First, since the MMI of the present invention is based on a markup language, only a very limited amount of programming skill is needed to design a fully featured user interface, unlike a conventional MMI which requires a programmer skilled in C or other low level language programming. Editing and modifying the user interface requires only simple markup language and image editing tools, not a complete application programming environment. Second, using the markup language based MMI of the present invention enables any of the features the MMI to be modified, without having to re-compile the entire telephone control software, and re-test and certify the entire package. Because the MMI is separate from the underlying telephone control and air interface stack, only user interface pages that are individually changed or added need to be tested. This reduces the time to market, and increases the ease of designing, maintaining, and modifying the MMI as new features and services become available. Reduction of the time to create and test changes in the user interfaces also means that more different versions can be prototyped in less time than with a conventional MMI, thereby facilitating design exploration for the best user interface design for a given set of user requirements and features.
The ease with which the user interface of a MMI can be created and modified, and the reduction of time to market further enables the service operator to quickly generate wireless communication devices targeted at specific customer segments, without requiring the device manufacturer to create specific product software images for each and every target customer segment. For example, the service operator may use the same wireless communication device hardware and telephony control software with different user interfaces designed for executives, teenagers and seniors, each of whom may have different needs and abilities to use the features of the wireless communication device.
For example, using a markup language to define the pages of the user interface allows any of the following items to be changed on any page: title bar presence and text; all informational text; option list text; links to all subsequent screens; soft key assignments; permanent scrolling banner messages; banner advertising; and help text.
The use of markup language based MMI also provides advantages in the branding of the wireless communication device for different service operators. Since the user interface is defined in markup language pages, service operator-specific logos, artwork, and text can be easily added and changed by individual service operators. Thus, the wireless communication device can provide the same wireless communication device hardware and telephone control software to a number of service operators, each of whom can quickly and easily brand the wireless communication device with their own distinctive user interfaces, without requiring the wireless communication device manufacturer to implement, test, and ship different user interfaces to each operator, as is conventional.
In providing a wireless communication device with a markup language based MMI, the present invention enhances the standard HTML with a number of extensions that make it particularly useful for working with wireless communication devices. Standard HTML assumes the presence of a conventional computer with keyboard, pointing device, and full size display screen, features which are not present in most wireless communication devices. The most notable deficiencies of HTML include:
Form elements (e.g., checkboxes, radio buttons) are awkward to navigate without a mouse.
Forms as they exist in content today tend to be too large for the user to maintain some context as she is filling them in on a small screen. If the form is divided into n forms, then the user's input is sent between the client and the server and back to the client n-1 times, wasting bandwidth. In addition, with a series of smaller forms, terminating the transaction could be tortuous as the user hits the back key for each form in the series.
Hyperlinks are awkward to follow without a mouse to select them and a separate scrollbar for scrolling the content of a page. On a device with only an Up key and a Down key to both select which hyperlink to follow and to scroll the display, fixed assignment of either scrolling or selecting to the Up and Down keys is insufficient to provide the needed navigational abilities.
As a user interface definition language, HTML lacks a number of key features:
The ability to specify actions for the soft function keys, or indeed for any key on the device.
The ability to define a pop-up menu of choices.
The ability to display or alter the data one would like to store on the device, such as names and phone numbers.
The ability to design a screen as a template without writing C code to fill in the blanks.
The ability to allow content arriving over the air to extend or customize the interface the device presents to the user.
The present invention provides extensions to the HTML language which facilitate the design of multi-part forms, the use of a limited number of keys to both navigate Web pages and select hypertext links, define actions for any key (keypad or softkey) of the wireless communication device using URLs, create menus of options for softkeys, and conditional inclusion of text, formatting, and user interface gadgets.
More particularly, the present invention provides a "key" tag that allows the assignment of specific functions or actions to any key of a key-pad, including binding a menu to a key. A "keymenu" tag allows specification of the menu items to be included in a menu bound to a key. A "template" tag and an "include" tag allow for the substitution or insertion of external HTML or other data directly into the HTML of a page. A "help" tag allows for the definition of help strings that are automatically scrolled across the title bar of page after a set time period. A conditional tag allows for the testing of expressions to conditionally display HTML data within a page, for example based on variables or configuration settings of the device. A "next" method for forms allows for maintaining state of a multi-part form without having to repeatedly transmit hidden data between a client and server to maintain the state. Improved navigational methods allow for the Up and Down keys of a wireless communication device to control both scrolling of a page, and selection of user interface gadgets and hyperlinks, in the absence of separate Tab and Enter keys and scroll bars.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is an illustration of the top level software and system architecture of a wireless communication device in accordance with the present invention.
FIG. 2 is an illustration of a sample user interface page for a wireless communication device is accordance with the present invention.
FIG. 3 is an illustration of the detailed software architecture of a man-machine interface of a wireless communication device in accordance with the present invention.
FIG. 4 is an illustration of the URL history stack.
FIG. 5 is a flowchart of the operation of the shell in handling received URLs.
FIGS. 6a and 6b are a flowchart of the operation of the HTMLp content handler in processing a string input associated with a user interface gadget
FIG. 7 is an example HTMLp file and page showing a key menu using the <KEY> and <KEYMENU> tags.
FIG. 8 is an example HTMLp file and page showing a help text scrolling banner with the <HELP> tag.
FIG. 9 is an example HTMLp file and page showing the use of the <TEMPLATE> tag for template files.
FIG. 10 is an example HTMLp file and page for editing a phone book.
FIG. 11 is another example HTMLp file and page for editing a phone book.
FIG. 12 is an example HTMLp file and page showing the use of expressions for evaluating the CHECKED and SELECTED attributes.
FIG. 13 is an example HTMLp file and page showing included HTML with the <INC> tag.
FIG. 14 is an example HTMLp file and page using the PHONENUM and PHONENAME attributes for the <INPUT> tag.
FIG. 15 is a flowchart of the process for handling an input key by the HTMLp content handler.
FIG. 16 is an example conventional HTML file and page for a complex form.
FIGS. 17a.1-17b.2 are example HTML files and pages showing a conventional multiple form approach using HIDDEN input data.
FIGS. 18a.1-18b.2 are example HTMLp files and pages showing a multi-part form used with the NEXT method.
FIG. 19 is an example HTMLp file and page showing the default creation of a menu of hyperlinks without the use of the <LINKMENU> tag.
FIG. 20 is an example HTMLp file and page showing the use of the <LINKMENU> tag.
FIGS. 21a-21e illustrate various user interface pages for dialing a telephone number.
FIGS. 22a-22c illustrate various user interface pages for handling active calls.
FIG. 23 is an example HTMLp file and page showing the use of the "extra" protocol.
FIG. 24 is a table of icons and images used with the builtin protocol.
FIG. 25 is an example HTMLp file and page showing the use of the <DIAL> tag.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
A. System and Software Architecture
Referring now to FIG. 1, there is shown an illustration of the system and software architecture of a wireless communication device 100 using the markup language based MMI 102 in accordance with the present invention. The hardware of the wireless communication device 100 includes a processor 124, memory 126, screen display 136, and keypad 128. Memory 126 includes ROM, RAM, and a flash memory for long term storage of data. A suitable wireless communication device 100 for providing the hardware features is a Nokia 6100.TM. manufactured by Nokia Telecommunications, Inc.
The wireless communication device 100 stores in the memory 126 and executes a conventional real time operating system 122, which includes modules for managing power, memory, threads (communication connections), keypad inputs, and timer activities. The real time operating system 122 provides a standard application programming interface to allow higher level components of the MMI 102 to request functionality of the wireless communication device 100, and to send and receive data.
Also stored in the memory 126 and in communication with the real time operating system 122 is telephony control module 120 that provides the primary telephone controls, including making and receiving telephone calls, managing multiple telephone lines (if appropriate), management of text messaging (if appropriate), monitoring of telephone signals, and other basic telephony functions. The telephony control module 120 includes a conventional telephone protocol stack that implements an air-interface protocol. The telephony control module 120 provides an application programming interface to the MMI 102 to access these features. The telephony control module 120 and the real time operating system 122 are typically provided by the manufacturer of the wireless communication device 100, and their particular implementation is not material to the invention.
The screen display 136 is a bitmapped LCD or similar display device. The screen display 136 is typically of very limited resolution, for example about 90.times.60 to 120.times.120 pixels (at about 0.28 mm dot pitch) as would be appropriate for a compact, portable, hand-held electronic device. It is anticipated that advances in display technology will result in screen displays 136 of significantly higher resolution, but even so, the ergonomic and form factor requirements of wireless communication devices will result in screen displays that are relatively small (e.g., between 25.times.25 mm and 80.times.120 mm) as compared to the screen displays of notebook and desktop computers, and as a result will not display content designed for such larger screen displays in the exactly the same manner. The present invention is adapted to increase the ease of use of such screen displays when displaying Web content.
The wireless communication device 100 has a keypad 128 that includes a number of fixed function keys 132 for accessing defined functions of the wireless communication device 100 (e.g., "Send," "End," and "Power"), number keys 134 for entering digits (and if suitably encoded, for entering other characters), and programmable softkeys 130 which have variable functionality that changes depending on the particular screen display of the user interface 104 being shown.
The wireless communication device 100 stores in its memory 126 and executes an instance of an MMI 102 made in accordance with the present invention. This MMI 102 includes a set of user interface definition files 104, a browser 107, a set of portable components 116, and a portability layer 118. The browser 107 provides the primary user interface mechanism to the user, allowing access to both telecommunication functions, and Internet/World Wide Web access. The portable components 116 provide a set of graphics primitives, file store functions, and localization features that allow the browser to be used on a variety of wireless communication devices 100. The portability layer 118 provides an interface for the browser 107 and portable components 116 to the real time operating system 122 and the telephone control module 120.
The MMI 102 executes as a single-threaded application, and is generally designed to run on any real time operating system 122, telephone control module 120, and wireless communication device 100 that provides sufficient ROM, RAM, and flash memory, a screen display 136, and basic services.
B. The Browser
The browser 107 provides the basic user interface of the wireless communication device 100 and is responsible for displaying content on the screen display 136, as defined by the user interface definition files 104, and as may be retrieved from remote sites, such as Web content accessed via a communication link to a remote Web site. The user interface definition files 104 are a set of content and code files written in a markup language such as HTML, or the preferred variant described below, HTMLp, and may include executable embedded code objects. The present invention is not limited to HTML, but also operates with, and may extend any other markup language, such as SGML, or XML, or other extended non-standard versions of HTML, such as the Netscape Communications' set of HTML extensions.
Since each service operator providing a wireless communication device using the MMI 102 of the present invention will design their own specific user interface, typically modifying some portion of the user interface definition files 104 provided by the device manufacturer, the particular content of the user interface definition files 104 is variable, and expected to be different from any of the illustrative user interface screens described herein. In addition, it is expected that the MMI 102 may be provided to a service operator without any user interface definition files 104 at all, leaving the service operator to create these files as desired; thus the user interface definition files 104, while used by the MMI 102 of the present invention, themselves are not an essential part of the invention. As the user interface definition files 104 define the user interface presented to the user, they allow the service operator to easily and quickly `brand` the wireless communication device 100, by simple editing of the user interface definition files 104. This branding requires no recompilation of the underlying browser 107, portability layer 118, or portable components 116, and thereby makes customization very easy and cost effective. It also means that the service operator can customize and brand the user interface using simple markup language editing tools, without necessitating the programming skill and environment of conventional code development.
Following the terminology of the World Wide Web, an individual user interface screen is herein called a "page." Referring now to FIG. 2, there is shown a basic layout of a page 135 displayed on the screen display 136 by the browser 107. Each page 135 generally has four basic areas. A status bar 200 that is preferably always present and displays items such as signal strength 202 and battery strength 204, message-waiting indicator 206. A title bar 210 displays the name for a particular screen, if so defined. A status message area 212 may be used to present status messages particular to the current content, such as a telephone number being called or answered. A content area 214 is used to display the particular content of a user interface page, for example, text of a message, phone book entries, and the like. Along the bottom (though other locations may be used) are softkey labels 216, which are dynamically updated according to key definitions provided in the user interface definition files 104. A scroll arrow 215 indicates the current direction in which the user is scrolling (either up or down). In the content area 214, a focus and selection icon 220 may optionally be used to indicate the particular item or line of content that has the focus, i.e. is the current user interface gadget or input field. A mode indicator 218 indicates the mode for text entry, whether alpha, numeric, or a combined alphanumeric mode.
Any of the pages or content displayed on the screen display 136 may be obtained locally from the user interface definition files 104 or remotely from the Internet or World Wide Web. Examples of local content include a telephone book, received text messages, or messages being created for sending, configuration settings for the wireless communication device, and the like. One of the features of the present invention is that whether the content is locally or remotely fetched is largely hidden from the user, except for the delay (if any) in obtaining it. This feature enhances the presentation of seamlessly integrated Internet and World Wide Web access with telecommunication functions.
Most of the features of the user interface are activated by means of a URL (Universal Resource Locator). Nominally, a URL is a means of identifying a piece of data, which data may be predefined, or may be generated on demand based on arguments that are encoded in the URL. A URL is a string that takes the following form:
protocol:data-identifier[?arguments]
The protocol component specifies a communication protocol that should be used to retrieve the data. For content located on the World Wide Web, the protocol is usually "http" for the HyperText Transport Protocol; local content of the user interface definition files 104 is retrieved with the "file" protocol to obtain data in a local file system stored in the memory 126. The present invention provides a number of additional new protocols that control the operation and configuration of the wireless communication device 100.
The data-identifier component is a specification of the desired content to be fetched. Currently, for content on the World Wide Web, the data-identifier normally takes the form of two `/` characters, followed by a machine name, another `/` character, and a path of some sort.
The arguments, if present, are separated from the data-identifier by a "?" and take the form of pairs made of an argument name and its value. An `=` character separates an argument name from its value. Multiple arguments are separated by an `&` character between the value of one and the name of the next.
Architecturally, the browser 107 includes three major pieces: shell 106, protocol handlers 112, and content handlers 114. FIG. 3 illustrates the detailed software architecture of the MMI 102, including browser 107.
The shell 106 is responsible for maintaining the universal parts of the screen display 136, for processing URLs by passing portions of a URL to the correct protocol 112 and content handler 114 for the URL, for maintaining a history stack 108 of URLs, and for routing user input. User input routing involves passing user input keystrokes to the appropriate content handler 114 or other target entity for processing, such as entering input numbers and letters into a form, or dialing a telephone number.
Protocol handlers 112 receive a URL from the shell 106, and are responsible for fetching the data corresponding to the URL, and instructing the shell 106 which content handler 114 should receive the data. In some cases, the URL is a command to control features of the wireless communication device 100, which the protocol handler 112 is responsible for executing.
Content handlers 114 are responsible for displaying fetched URL data and interacting with the user. At least one content handler 114 is always the current content handler 114. It is from the current content handler that any new URL is provided back to the shell 106, and that receives by default any keystrokes that are not delivered to any other input target. The shell 106 is further described below with respect to FIGS. 4-5.
1. Overview of the Protocol Handlers
The protocol handlers 112 serve two functions in the MMI 102: First, they fetch data and determine its type; the determination of type in turn determines which content handler is used to display the data. Second, they perform a command in the wireless communication device 100, by accessing an embedded object or the appropriate API of the real time operating system 122, or telephone control module 120. A protocol handler 112 may return the results of that command, causing a different screen to display, or may return no results. The protocol handlers 112 of a preferred embodiment include the following.
Builtin protocol handler 112a provides access to icons that are built in to the wireless communication device 100.
Config protocol handler 112b gets and sets configuration settings of the wireless communication device 100.
Extra protocol handler 112c provides access to arguments and form data that are passed from an embedded object in a page, or from previously accessed pages. This protocol allows data to be passed directly into a page, without requiring the page to be dynamically generated.
File protocol handler 112d provides access to local content in ROM and in the flash file systems. Generally, this content is user interface definition files 104 that define the pages of the user interface. The file protocol handler 112d may be implemented by those of skill in the art according to a suitable specification for file system access, such as the POSIX specification.
HTTP hander 112e is a remote file protocol handler that provides accesses to remote content stored on the World-Wide Web, using the standard HyperText Transfer Protocol. The HTTP handler 112e may be implemented by those of skill in the art according to the specification defined in RFC 2068: Hypertext Transport Protocol--HTTP/1.1. Other remote file access specifications may also be used to implement a remote file protocol handier.
Message protocol handler 112f activates various messaging functions, including sending a message, deleting a stored message, reading new or stored messages, or locking a stored message.
Telephone protocol handler 112g activates various telephone functions, including making a call, answering an incoming call, displaying the phone book, editing a phone book entry, and creating a new phone book entry.
Config protocol handler 112b (shown as part of the portability layer 118) retrieves and sets various configuration settings for the wireless communication device 100.
a) Basic Protocol Handler API
Generally, a protocol handler 112 is similar to a device driver, in that it has a well-defined set of functions it can perform, and each protocol handler 112, though supporting the same functions, supports those functions in its own manner. Each protocol handler 112 implements three functions:
GetURL: Given a URL and a security level of the page containing the URL to be fetched, returns the data associated with the URL, and the privilege level of that data. If the URL is actually a command, rather than a reference to data, no data need be returned.
BuildURL: Given a full URL and a partial URL (without the protocol: element), returns a full URL. This is used primarily for references inside HTML pages.
PutURL: Given a URL, a stream of data to be stored under the URL, and the security level of the page containing a "put" method, stores the data if the security level is high enough to allow it.
The various embedded object and command URLs supported by the protocol handlers 112 are described below.
2. Overview of the Content Handlers
Content handlers 114 are responsible for decoding the content data of a page corresponding to a fetched URL and displaying the content, or otherwise manipulating the content. A content handler 114 typically decodes content it receives and presents a page in the screen display 136, or portion thereof. Some content handlers 114 construct the page from data they receive from the memory 126 or over a communications link, while others display the state of the wireless communication device 100 or serve some other administrative function. In a preferred embodiment of the browser 107, the content handlers 114 include the following:
CallManager content handler 114b manages an incoming call screen defined in the user interface definition files 104 to enable the user to receive incoming calls. The CallManager content handler 114b provides other functionality through embedded objects.
HTMLp content handler 114c displays the bulk of the user interface by accessing the appropriate user interface definition files 104 in memory 126. The HTMLp content handler 114c includes a HTML 3.2 compatible parser, and is capable of decoding HTML and creating the necessary data structures and objects to display text and graphics according to HTML tags. In addition, the HTMLp content handler 114c accepts a modified form of HTML 3.2, herein called "HTMLp" as described below, which provides a number of beneficial extensions to the features and functionality of HTML 3.2.
To better serve as a user interface, and provide added flexibility in designing the user interface, the HTMLp content handler 114c allows objects, written in C or other programming language, to be embedded in an HTML or HTMLp page to display different types of data that are in the wireless communication device 100. However, the HTMLp content handler 114c, unlike a standard HTML parser, first passes user selected URLs in a current page to any embedded object, allowing the URL to be modified by what the user has selected or entered or fully processed before they are given to the shell 106 to process.
In the preferred embodiment, the available embedded objects include the following:
A phone book object stores records of names, associated telephone numbers, addresses, email addresses, speed dial key selection, ring tone, and other definable fields of data. The phone book object includes methods to get and set the fields of records. A phone book object may be embedded in a page and activated by the appropriate URL of the phone protocol.
A recent and missed phone call list object stores a continually updated list of telephone numbers that were recently called, received, or not answered. The call list object includes methods to delete and dial a telephone number on the list. The call list may be embedded in a page and activated by the appropriate URL of the phone protocol.
A speed dial number list object stores a set of telephone numbers and associations to keys of the keypad 128, such that the selection of the key provides for speed dialing functionality. This list object include methods to set, get, and dial a speed dial number.
A phone number lookup object accesses the phone book object to return a telephone number(s) associated with an input or selected name or name fragment.
A phone book name lookup object accesses the phone book object to return a name(s) associated with an input or selected telephone number of number fragment.
A list object of text messages/alpha-numeric pages that have been received or sent. The message list object stores a list of messages, including email or Short Message Service messages, and includes methods to view, store, edit, delete, and send messages. The message list may be embedded in a page and activated by the appropriate URL of the message protocol.
The main content handler 114d is primarily a front-end for the HTMLp content handler 114c in that it uses HTMLp to display a main screen for the wireless communication device 100.
The advert content handler 114a is a front-end for the HTMLp content handler 114c that chooses which advertising page to display when the wireless communication device 100 is idle and instructs the HTMLp content handler 114c to display it. In addition, it intercepts keystrokes and user interface gadget activation to optionally delete an advertisement that has been responded to or expired.
a) Basic Content Handler API
Like protocol handlers 112, content handlers 114 have a well-defined interface the shell 106 uses to communicate with them. The interface is tailored around the screen display 135 in the sense that there the content area is defined within the screen displayand interaction needs of content handlers 114. The four functions each content handler 114 supports are:
ContentOpen: This is the call that gives a content handler 114 control of the content area 214 of the screen display 136, the softkeys 130 and softkey labels 216, title bar 210, and status message area 212. Each content handler 114 receives the following four pieces of information when its ContentOpen function is invoked:
1. A stream of data returned by the protocol handler 112 that fetched the data; this is data to be displayed.
2. A handle to the content area 214, indicating where the data is to be displayed.
3. A flag indicating whether the content handler 114 has previously displayed this data.
4. A pointer to extra data that was passed by whatever entity asked the shell 106 to fetch the URL, allowing the extra data to be entered into the page being displayed. The use of the extra data is further described below with respect to the <TEMPLATE> tag of HTMLp, and the "extra" protocol.
ContentClose: When the user asks to close a page, or asks to open a different page, the current content handler 114 is closed. It receives a flag that indicates whether the page is maintained in the URL history stack 108, or if it has been removed from the stack permanently.
ContentProcessKey: In the absence of anything else to process a keystroke, the shell 106 delivers the keystroke to the current content handler 114 by default. The current content handler 114 is the one displaying the content whose URL is at the top of the URL stack.
ContentActivate: When the user presses a softkey 130 or selects an item from a menu, the string that is bound to the key or menu item is passed to the current content handler 114 via this function. In some cases, the string will be a URL that can be passed straight to the shell 106 to be fetched. In other cases, the string is an indication of what the user wishes to do, and the content handler 114 may perform the action itself, or it may use an item the user has selected on the screen display 136 to generate a URL it can give to the shell 106. For example, if the user selects an entry in the phone book and presses a softkey 130 labeled "Edit", the HTMLp content handler 114c will take the string associated with that softkey 130 and pass it to the embedded phone book object, which will use the string as a template for generating the actual URL to pass to the shell 106, based on which phone book entry the user has selected in the embedded object.
The specific functionality of the content handlers 114 is further described below.
3. Control Flow
A preferred implementation of the browser 107 is organized around a single callback queue 110, which takes the place of the event loop used in other environments. Any part of the MMI 102, can request that a function be called at a later time by adding a function request to the callback queue 110.
The callback queue 110 has a number of elements, each of which has a pointer to a function to call, and two 32 bit arguments to pass to the routine. The function pointer can be to any module in the system.
Essentially, the overall system executes a top most control loop:
1. Call the next item on the callback queue 110.
2. Update the screen display 136 with any changes that call made. This step includes drawing graphical elements to the screen (e.g. scrolling, updating status messages and icons) displaying keystrokes, and displaying new pages in response to user activation of functions or features associated with URLs.
3. Go to step 1.
Items for the callback queue 110 are added primarily by asynchronous events such as keystroke (up or down), change in an active call, timer expiration, and incoming text messages.
Certain protracted operations also will use the callback queue 110 to continue the operation, while still allowing other actions (such as user input) to be handled. For example, reading the frames of an animated GIF image is broken into two conceptual phases:
1. Read the first frame and queue a call to read the next frame.
2. Attempt to read the next frame. If successful, queue a call to read the next frame.
In this way, a page containing the animation can be displayed as soon as possible while the rest of the animation is effectively loaded in the background.
4. The Shell
The shell 106 provides handling of input keystrokes and other inputs from the lower layers, and passing of such inputs to the appropriate protocol handlers 112 and content handlers 114. A list of shell 106 functions is provided in Appendix A.
a) Keypad Input
Keypad input arrives spontaneously at the shell 106 from the portability layer 118. The shell 106 maintains a keystroke target list which is a list of entities, particularly user interface objects of the currently displayed page, that can process the keystroke. When a keystroke arrives, the shell 106 passes the keystroke to the first entity in the keystroke target list, via ShellProcessKey. If that entity decides not to process the keystroke, it calls the shell 106 to give the keystroke to the next entity in the list (ShellPreviousInput). The final entity in the list, placed there by the shell 106 when the list is initialized, disperses the keystroke to the current content handler 114, which can choose to pass to a default processing routine in the shell 106 that implements system-wide keystroke defaults, or the current content handler 114 can handle the keystroke as desired.
The shell 106 includes functions to register an entity (usually a user interface object) into the keystroke target list (ShellGrabInput) and release an entity from the list (ShellReleaseInput).
b) Softkeys
One type of key that has a special function is a softkey 130, which is a key whose label is displayed on a page in the screen display 136, and whose purpose changes from page to page, according to defined parameters in the user interface definition files 104. The shell 106 manages a number of softkeys 130, typically between one and three, but variable depending on the wireless communication device 100. Each softkey 130 may be bound to a string, or to a menu whose menu items specify a string, or the softkey 130 can be set to pop one or more entries from the URL stack, or to do nothing.
When a softkey 130 or a menu item that is bound to a string is activated, the string is passed to the current content handler 114 via its ContentActivate function. In some cases, the string that is bound to a softkey 130 is a URL to be fetched. In this instance, the URL is passed by the content handler 114 to the shell 106 for processing (ShellGetURL) and fetching by the appropriate protocol handler 112 and content handler 114. In other cases, the bound string is a command that the content handler 114 handles itself without changing pages. Finally, the bound string may be a mixture of the two: a template URL (see below) that is modified by the content handler 114, based on some input from the user, before being fetched.
As noted above, as part of its ContentActivate function, the HTMLp content handler 114c passes a string bound to a user selected user interface entity to any embedded object in the current page before it examines the string itself. Some embedded objects simply take commands to operate on what data they are displaying in this way, while others look for special escapes in the string to substitute some portion of the data the user has selected, yielding a URL that they then pass to the shell 106. The HTMLp content handler 114c also has certain special commands it accepts, rather than just accepting URLs from hyperlinks.
c) URL Processing
The step of updating the screen display 136 in the above described control flow, when done in the context of obtaining a new page for display, is accomplished by passing a URL to the shell 106 via the ShellGetURL function. FIG. 4 illustrates the URL history stack 108 used by the shell 106 to support URL processing. The URL history stack 108 is a LIFO stack. Each entry 402 includes a URL 404, a pointer 406 to a function table 412 for functions for the particular content handler 114 that handles the URL, extra data 408 (if any) that was passed in with the URL to be retrieved by the "extra" protocol or to be used by the content handler for the URL, a pointer 410 to the next URL, a privilege level 414 at which the page is operating, the priority 416 of the URL, and a pointer to the state block 418 the shell 106 maintains on behalf of the content handler 114.
Referring to FIG. 5 there is shown a flowchart of the operation of the shell 106 in handling a URL. The shell 106 extracts 500 the first part of the URL string, before the first `:` character, and compares 502 it to the list of known protocol handlers 112 to identify the appropriate handler for fetching the URL data. If no protocol handler 112 is found, then the shell 106 creates 508 a complete URL by calling the BuildURL function of the protocol for the URL currently at the top of the URL stack, passing it the current top URL and the URL that is being fetched. The protocol handler 112 returns the absolute URL that should be used in place of the relative one that was passed in.
If a protocol handler 112 is found, the shell 106 calls 504 the GetURL function of this protocol handler 112, passing the remainder of the URL. The protocol handler 112 is expected to fetch the URL, and return a pointer to a ContentStream structure that includes a string indicating the type of data returned, the privilege level at which the data should be interpreted, and a pointer to a Stream, which contains the actual data (the data need not be present yet, but reading from the stream must return the data as it arrives). If no stream is returned 506, the shell 106 returns 510 an error.
The shell 106 matches 512 the data-type string against the list of known content handlers 112. If there is no match, the shell 106 returns 520 an error. If there is a match 514, this content handler 114 becomes the current content handler. The shell 106 resets 516 the softkeys 130, content area 214 size, title bar 210, and status message area 212 to their default state. The shell 106 invokes the ContentOpen function of the current content handler 114, passing both the ContentStream and control of the content display area 214 to the current content handler 114 for the content to be displayed.
If the open call is successful 522, the shell 106 updates the URL history stack 108, placing the URL, the pointer to the current content handler 114 functions, any extra data, on the stack, and returns 524 success to the entity requesting the URL, otherwise, the shell 106 reopens 526 the previous URL from the URL history stack 108, and returns an error.
5. Security
Because content that is received over the air is allowed to activate telephone features and access telephone data, such as telephone book entries, the present invention provides mechanisms for security to prevent unauthorized access to functions or data.
When a URL is fetched by a protocol handler 112 as part of its GetURL function, its data are assigned a privilege level by the protocol handler. If content comes from a privileged source, the protocol handler 112 assigns the highest privilege level. For example, all pages from the user interface definition files 104 which are stored in the ROM 126 of the wireless communication device 100 are assigned the highest privilege level. Formatted text messages, whether received or created by the user, are assigned a lowest privilege level. Content that does not have an assigned privilege level is automatically given the lowest privilege level by the shell 106. For example, content from the World Wide Web (unless otherwise pre-assigned) is given the lowest privilege level. The privilege level of an item of content is stored with its URL in the URL history stack 108.
Selected functions of the wireless communication device 100 are configured to be privilege-sensitive by either the manufacturer of the wireless communication device 100 or the service operator. When such a function is called it determines the privilege level of the page requesting the content from the page's URL in the URL history stack 108. If the privilege level of the requesting page is higher than the privilege level of the requested content, then the content is accessed. If the privilege level of the requesting page is lower than the privilege level of the requested content, then the function can either deny the access out of hand, or confirm the operation with the user. For example, if a lower privilege page requests to make a telephone call via the CallManager, the user is alerted to the actual number being dialed and must confirm the request before the phone is dialed.
6. The Content Handlers
The following sections outline how the individual content handlers 114 implement the four functions in the API to each content handler 114.
a) The HTML.sub.p Content Handler
(1) HTMLp API
The HTMLp content handler 114c provides a fully HTML compliant parser, using the HTML 3.2 specification. This parser is activated as needed by the HTMLp content handler 114c during parsing of a page of content to create user interface entities for display of the screen display 136, and for storing respective data associated with such entities, such as labels, and associated data, including URLs to be fetched when the user interface entity is selected.
As noted above, each content handler 114 provides an external interface of four functions, HTMLpOpen, HTMLpClose, HTMLpActivate, and HTMLpProcessKey. HTMLpOpen and HTMLpClose are described here. For ease of understanding, HTMLpActivate, and HTMLpProcessKey are described below, after a description of the new tags of HTMLp.
(a) HTMLpOpen
This function, called by the shell 106, gives control of the content area 214 of the screen display 136 to the HTMLp content handler 114c for displaying a page of content. As noted, the HTMLp content handler 114c receives from the shell 106 a stream of data to display, a handle to the content area 214, a display flag indicating whether the content data (the page) has been previously displayed, and a pointer to any extra data to be associated with the page.
The function determines from the display flag whether the page has been previously displayed, and if so, whether any embedded object in the page was cached. In this case, the page is redisplayed and any embedded object has a RestoreState function called to reestablish its previous state.
If the embedded objects for a page were not cached, or this is the first time the page is being displayed, the content stream for the page is passed to the underlying HTML parser to be interpreted as HTMLp code. The parser will create windows, and user interface entities as needed, and wrap text and update and assign softkeys 130 as necessary. When the page has been completely parsed, it is displayed to the user. In creating the user interface entities, the HTML parser establishes a table of associations between the user interface elements (including keys 132, softkeys 130, menu items, and the like) and URLs (whether local or remote) bound to these entities. The association identifies each particular user interface entity, and a URL that is to be fetched if the entity is selected or otherwise activated by the user. These associations are used when subsequently processing key strokes received by the page by the HTMLpProcessKey function. A handle to the main window that holds all the other pieces of the page is set as a state block 418 for the page via a call to ShellSetState.
(b) HTMLpClose
This function is called when the user closes the current page or switches to a different page. The shell 106 passes in a flag indicating whether the page is to be removed from the URL history stack 108, or if it may remain on the URL history stack 108. If the page is not to be removed, and the page has not been marked as non-cacheable, then the main page is set not visible, effectively hiding it from the user, but maintaining it as an active page.
If the page is non-cacheable or the page is to be removed from the URL history stack 108, the page window and its associated data structures are destroyed. A page is deemed non-cacheable when it refers to data outside itself that could potentially change while the page is not displayed. For example, if the page contains an <INC> ("include") tag or uses the configuration mechanisms described below to display a configuration setting, it is considered non-cacheable. The use of the conditional <IF> tag, and the <TEMPLATE> tag may or may not cause a page to be non-cacheable, depending on whether the DYNAMIC attribute for these tags is set, and whether a %[url] escape is encountered inside a <TEMPLATE> </TEMPLATE> block. These features are further explained below.
(2) Extensions to HTML: HTMLP
The present invention provides an MMI 102 that is fully HTML compatible. However, in addition to merely displaying content, it is desirable to provide a set of HTML extensions for further refining the user interface of a wireless communication device 100, making it more functional for telecommunication functions and the small screen display 136, and allowing the wireless communication device to be easily and quickly customized by both the device manufacturer and the service operator.
The extensions which make up HTMLp are as follows:
(a) A. User Interface Extensions
In this section, the extensions of HTMLp which enrich the user interface are described. These various tags are decoded by the HTMLp content handler 114c when it receives a page of content from the shell 106.
(i) Binding Keys to Functions: <KEY> Tag
A typical wireless communication device 100 possesses one to three softkeys 130, the standard number keys 134, and a number of special-purpose keys 132. A new extension of HTMLp allows any key of the keypad 128 to be bound by an HTML page using the <KEY> tag. The syntax is:
<KEY KEY=key LABEL=string ACTION=url.vertline.POP.vertline.DONE.vertline.CLEAR.vertline.MENU.vertlin e.GO.vertline.NONE>
The value of the KEY attribute is one of the following:
1, . . . m Specifies a softkey to be bound. Keys are numbered from left to right, or from top to bottom (depending on where they are on the phone). Typically (m<=3), but this may be varied per device.
send Specifies the "Send" or "Talk" key.
back Specifies the "Back" key. Not all devices have this key. A page must be privileged to bind this key.
#n Specifies one of the dialing keys, where n is the label on the key (0-9, *, or #). To bind all dialing keys to the same action, specify #x.
end Specifies the "End" key. A page must be privileged to bind this key.
mode Specifies the "Mode" or "ABC" key.
clear Specifies the "Clear" or "Del" key.
up Specifies the up-arrow key or down action.
down Specifies the down-arrow key or down action.
left Specifies the left-arrow key.
right Specifies the right-arrow key.
select Specifies the select key or action.
power Specifies the power key. A page must be privileged to bind this key.
default Specifies an action for any key for which no other action has been specified, with the exception of the back, end, and power keys, for which actions must always be explicitly specified, if any other than the standard actions are to be taken.
If the key is a softkey 130, the value of the LABEL attribute is the string that appears in the on-screen label for the key. If the string is too long to fit in the space allotted, it is truncated. The LABEL attribute is valid only for softkeys 130.
The value of the ACTION attribute specifies what should happen when the bound key is pressed. The possible values are:
URL Specifies a URL to be fetched, or some other command for an embedded object in the page. The URL is passed to the HTMLp content handler's HTMLpActivate function for processing.
POP Requests that the previous page be displayed.
DONE Requests that the page before the most-recent <TOP> page be displayed.
CLEAR Requests that all pages be cleared from the URL history stack 108 and the main screen be displayed.
MENU Specifies that the softkey 130 should bring up a menu. The items in the menu are specified by <KEYMENU> tags in the <HEAD> section. This is valid only for softkeys 130.
GO Asks that the currently selected link be fetched. This is valid only for pages with the <LINKMENU> attribute.
NONE Asks that no action be taken when the key is pressed. This allows the default action for the key to be overridden.
When the HTMLp content handler 114c loads a page with the <KEY> tag, it creates a key binding table that stores the association between the key, label (if any) and action.
The string bound to the ACTION attribute is processed by the HTMLpActivate function, as follows.
(ii) HTMLpActivate
The HTMLpActivate function is used to determine the appropriate response to the string that is bound to a user interface entity, such as a key, softkey, menu item, hyperlink, or the like. The input is a string from the shell 106, and more particularly, a string that is bound to the ACTION attribute of a KEY or KEYMENU tag, or the HREF attribute of an A tag. The new HTMLp tags generally allow any key or menu item of the wireless communication device 100 to be associated with a specific action or URL.
Referring to FIGS. 6a-6b, there is shown a flowchart of one embodiment of the HTMLpActivate function. The HTMLp content handler 114c maintains a list of embedded objects in the current page. If there is an embedded object in the page (602), the function passes the string to the embedded object for processing 604. The embedded object returns a Boolean indicating whether the string was processed, and that no further processing of the string is necessary. If the string was processed by the embedded object (606), then the function returns 608 control to the shell 106. The processing 604 of a string to an embedded object is further described below.
If the string was not processed, the HTMLpActivate function proceeds to process 610 the string according to its value as an ACTION attribute.
If the string is "POP," (612) then the shell's ShellGoBack(POP) function is called 614. This function pops the top URL of the URL history stack 108, and cause the previous URL to be loaded.
Similarly, if the string is "DONE," (616) the ShellGoBack(DONE) function is called 618, which is similar, but displays the page before the most recent <TOP> tag; the <TOP> tag identifies the first part of a multi-part form, as further described below.
The HTMLp content handler 114c maintains a pointer to a current object in the page, which can be an input field in a form or a hyperlink. This current object is where the input focus is located.
If the string is "GO," (620) and the current object is not a hyperlink (622), then nothing happens. If the current object is a hyperlink, the content handler 114 gets 624 the URL string associated with the hyperlink, and passes that URL string to ShellGetURL, which then fetches the actual content.
If the string is "CLEAR," (626) then the ShellGoBack(CLEAR) of the shell 106 is called 628. This function clears the URL history stack 108 and causes a default main page to be displayed.
If the string has the form "resetformid," (630) then the function returns 632 the input elements of form number formid to their original state. This action is bound to any softkey 130 or softkey menu for an <INPUT TYPE=reset> gadget.
If the string has the form "submitformid,label," (634) then the function submits 636 form number formid according to the METHOD and ACTION attributes of the FORM tag that defined form numberformid. If present, label indicates which <INPUT TYPE=submit> gadget the user activated, so its name-value pair can be submitted along with the values from the rest of the gadgets in the form.
If the string is "SELECT", (638) then the function activates 640 the user interface gadget the user has selected, according to the gadget type as follows:
<INPUT TYPE=radio> Selects that radio button and unselects other
radio buttons with the same name.
<INPUT TYPE=checkbox> Checks or unchecks the checkbox.
<SELECT> If the options are displayed, it chooses the
option the user has selected. If the SELECT
list is a pop-down list, the pop-down is
closed.
hyperlink Follows the link.
If the string is "NONE" (642), then no action is taken.
After all these conditionals are passed, if the string is any other value (644), such as a URL, then it is passed 646 to ShellGetURL to be processed. If the URL has no arguments (there is no `?` in it), any parameters that were passed to this page as extra data are also passed in the call to ShellGetURL.
An example of the HTMLpActivate function and its particular benefits for embedded objects is further described below.
An example of processing by the Activate function using the <KEY> tag is as follows. Assume that a page contains the following KEY tag:
<KEY KEY="send" ACTION=phone:dial>
When this page is loaded, the HTMLp content handler 114c stores the association between the Send key and the URL "phone:dial" in its key binding table. This stored data will be used to activate the telephone dialing function of the telephone protocol handler 112g when the user presses the Send key. The HTMLp content handler 114c is the current content handler 114.
Assume that at some later point the user presses the Send key. The portability layer 118 calls the shell's ShellProcessKey function indicating that a key has been pressed, and passes in a key number for the Send key, and a flag indicating that it has been pressed. As noted above, the shell 106 maintains the keystroke target list. The ShellProcessKey sends the received key to the first target on the stack. If this target does not have a purpose for the key, then the target calls the Previouslnput function of the shell 106, passing the Send key index. The shell 106 finds the next item on its keystroke target list. This process repeats until the key is passed to the HTMLp content handler 114c. This happens when the shell 106 calls the ProcessKey function of the current content handler 114, since the URL at the top of the URL history stack 108 contains the pointer 406 to the HTMLp content handler 114c.
The shell 106 then calls the HTMLpProcessKey("Send"). This function looks at the key binding table, which includes the association between the Send key and the URL "phone:dial." The HTMLp content handler 114c calls ShellActivate(phone:dial), which calls the HTMLp content handler's 114c HTMLpActivate function.
Here, it is assumed that there is no embedded object in the page. The function then tests the input string against the various other actions, such as POP, DONE, GO, CLEAR, and NONE. Since the string "phone:dial" does not match any of these, the HTMLpActivate function calls the shell's ShellGetURL(phone:dial) function.
The shell 106 processes this function, as shown in the flowchart of FIG. 5. Continuing the example, the shell determines that the URL is for the telephone protocol handler 112g, and passes the "dial" portion to it for processing. This protocol handler 112g returns a content stream of type "CallManager" (destined for the call manager content handler 114b) that contains the number to be dialed. The shell 106 closes the HTMLp content handler 114c, but does not remove the URL from the URL history stack 108. The shell 106 places the URL "phone:dial" on the top of the URL history stack 108. The shell 106 gets from the content stream returned by the telephone protocol handler 112g the string name of the content handler 114 to handle the stream. The shell 106 looks up the string in its table, and updates the CONTENT field of the top entry of the URL history stack 108. Finally, the shell 106 invokes the Open function of the new current content handler 114, passing in the content stream data. In the Open routine of the call manager content handler 114b, it retrieves the phone number from the stream and invokes the necessary function in the telephone control module 120 to establish the phone call.
(iii) Building Menus
If a softkey 130 is bound to a menu using the <KEY> tag, and ACTION="menu", then the entries for the menu are specified using a <KEYMENU> tag in the HEAD section of the page. The <KEYMENU> tag has the following syntax:
<KEYMENU KEY=n LABEL=string ACTION=url.vertline.POP.vertline.DONE.vertline.CLEAR.vertline.GO>
Entries are displayed in the menu in the order in which they are encountered. However, menu entries do not all have to be together in the header.
The value of the KEY attribute specifies to which menu the entry should be added. This is the same value as given for the <KEY> tag that specified a menu should exist.
The value of the LABEL attribute is the string that appears in the menu entry. The menu will be as wide as necessary to hold all the entries. However, the label will be truncated if it is wider than the screen.
The value of the ACTION attribute specifies what should happen when the entry is selected. The possible values are:
URL Specifies a URL to be fetched, or some other command for an embedded object in the page.
POP Requests that the previous page be displayed.
DONE Requests that the page before the most-recent <TOP> page be displayed.
CLEAR Requests that all pages be popped from the URL stack and the main screen be displayed.
GO Requests that the currently selected link be fetched. This is valid only for pages with the <LINKMENU> attribute.
These ACTION attributes are processed in the same manner as the attributes of the <KEY> tag in the HTMLpActivate function, as described above.
FIG. 7 illustrates example of the HTMLp source code for page with a key menu defined, and the screen display 136 when the menu is selected to be displayed. The HTMLp code is shown on the left, and the resulting page on the right. Line 4 defines a menu for the first softkey (KEY=1). Note that when the menu is open, the softkey label 216 for the menu changes to "Select," indicating that if the user presses the softkey 130 again, the selected entry will be activated; this label 216 may change to instead close the menu, leaving the Send key to activate the selection. Lines 5-7 define the menu items for this menu, each of which has its ACTION attribute specifying one of the user interface definition files 104 for the appropriate page to display to retrieve messages, recent calls, or phone settings. Selecting one of the entries in the menu, either by pressing the softkey marked "Select" or pressing the numbered key matching the icon to the left of the entry, causes the ACTION specified in the KEYMENU to be executed. In this example, the appropriate HTML.sub.P user interface definition file 104 is fetched from ROM.
(iv) Delayed Help
Many user interfaces for computers provide some form of online context-specific help text. Conventionally, these help screens are displayed in their own window overlaying the portion of the user interface where the user is expected to enter data. In addition, help screens are typically passive, and appear only in response to a direct action of the user to request help. However, in a wireless communication device with a very small screen display, overlaying a help screen over the content area would hinder the user. In addition, since the user may not know that help is available, passively waiting for the user to request help may be insufficient to assist some users.
To assist users who might be uncertain of what to do next when viewing a page, and to provide such help without obscuring the content area 214 of a page where the user is expected to input data, the present invention enables help text to automatically scroll across the screen in place of the title 210 of a page after a certain amount of time has elapsed without a user input keystroke. More than one help text string may be specified, in which case the strings are displayed in succession, with a suitable interval between each one. The help text strings are displayed only once each, each time the page is viewed.
To allow pages to specify one or more help strings a new <HELP> tag is specified in the <HEAD> section of the document. The syntax of the <HELP> tag is:
<HELP>help string</HELP>
where help string is the help text to be displayed.
When a page containing the <HELP> tag is loaded, the HTMLp content handler 114c builds a structure, such as a table, that includes the help text strings. This table is passed to the shell 106, which stores the table for later use. The functionality of <HELP> tag is then handled primarily by the shell 106 during idle time processing.
The shell 106 maintain a counter of the number of seconds since the last keystroke. The counter is normally cleared on each ShellProcessKey. The real time operating system 122 has a timer that runs in the background, and calls a routine in the shell 106 that increments the counter. If counter reaches a threshold number of seconds, the shell 106 creates a scrolling banner object, and instructs it to display the first help text string in the table. The scrolling banner object internally determines when the help text string is fully scrolled off of the screen display 136, and notifies the shell 106, which redisplays the title 210. A second threshold is set for displaying the next help string. The thresholds are predetermined by the shell 106 based on a desired length of time for displaying the help text strings.
FIG. 8 shows an example of the HTMLp source for a page including two HELP tags, and the resulting sequence through which the screen display 136 passes when the page is loaded. Lines 7-8 of the HTMLp code define the help text to be displayed. The second and third screen images show the first help text string being scrolled in place of the title.
(v) Pages as Templates
There are a number of extensions of HTML in the present invention that allow pages to be designed using a standard HTML editor, using arguments passed by C code to complete form entry fields, or specifying data to be fetched on the fly from the device to determine the initial state of a form in a page. These extensions include templates, conditional HTML, configuration setting capabilities, and "included" HTML.
Generally, the C code for an embedded object has parameters to be displayed, but it is desirable that the format of the display be defined in the HTML for the page. For example, a page displaying a form of data for an incoming call preferably displays a telephone number and its associated name. Accordingly, the HTML page for displaying the incoming call should be able to take the parameters (telephone number and caller name) and format them as necessary.
However, conventional HTML 3.2 provides no mechanism to pass data directly into a page for this desired application, but rather at best allows the HTML for the page to be created on demand. The generation of HTML is both slow and compute-intensive, and the executable scripts for generating a page typically require more storage than the page being generated, thereby making it less efficient than storing the page itself. By allowing indirect passing of arguments, the present invention eliminates the need to generate HTML at run time. This enables the pages to be stored in the ROM 126, and requires less memory than the code for generating the HTML on demand.
(a) Using Pages as Templates
The first extension which enables data to be passed into a page is the <TEMPLATE> tag. The <TEMPLATE> tag may appear anywhere in page. It must be matched by a corresponding </TEMPLATE> tag at the appropriate place in the structure of the document.
All text between the <TEMPLATE> and </TEMPLATE> tags is examined for escapes of the form %(url), %[url] or %<url>. This includes text within tags, even within quoted attribute values. When such an escape is seen, the data for the URL are fetched and, if they are plain text or HTML, they are inserted into the HTML document in place of the escape exactly as if they had been there all along. To include a % character in the text between <TEMPLATE> and </TEMPLATE>, it must be preceded by another %, as in "%%".
The form %<url> causes the text returned as the data for url to be encoded for use as an argument for another URL. URL arguments have a restricted character set, with anything outside that character set being encoded as % followed by two hexadecimal digits.
The distinction between %(url) and %[url] lies in the caching behavior of the HTML.sub.P content handler 114c. Normally, the data for a page are parsed and the information needed to render the page is saved so long as the URL remains on the URL history stack 108. This allows for quick redisplay of a page that has already been fetched. If, however, a %[url] escape is seen in a template section, it indicates that the data for the URL are dynamic enough to warrant the reparsing the page when it needs to be redisplayed, to catch any changes in the URL data since the user last saw the page.
FIG. 9 illustrates an example of the TEMPLATE tag. In this example, the text between the <TEMPLATE> tags on lines 19-25 defines the template text; the escape on line 20 results in the URL "extra:name" being fetched, which replaces the text with whatever data is stored under the variable "name". The screen display shows this as the text "Adam M."
The HTML 4.0 specification provides for the use of embedded objects in pages. Generally, an embedded object is an item of code positioned at a location on the page that is responsible for constructing and displaying its own content. An embedded object is specified in the URL for the OBJECT tag, located in the desired position in the HTML source. Normally, the URL specifies a code entity such as an ActiveX control, a Java applet, C code, and the like. In the HTML 4.0 specification, the URL is merely passed to a server which return the desired entity. However, in HTML 4.0 once a page with an embedded object is loaded, no further processing or passing of arguments to the embedded object can occur. In particular, when a user selects a hyperlink (a user interface gadget associated with a URL) on a page containing the embedded object, the embedded object does not have any opportunity to process the URL, and instead, the URL is merely followed to the linked page.
However, the present invention extends the functionality of embedded objects by providing URL associated with a hyperlink or user interface gadget first to embedded objects for processing. This lets an embedded object respond directly to arguments provided in HTML forms, without having to have the server update the page. The implementation of this embedded object functionality is provided in the HTMLpActivate function of the HTMLp content handler 114c, as described above with respect to FIG. 6.
As described, when the HTMLp content handler 114c processes a string that is a URL, if there is an embedded object in the page, the HTMLp content handler 114c passes the URL to the embedded object. In accordance with the present invention, an embedded object does one of three actions in processing a URL:
Process the URL as a command;
Look for escape sequences in the URL and substitute for those sequences information from the data the user selected, before passing the URL to the shell 106 to be fetched; or
Return the URL to the HTML.sub.P content handler 114c without processing, to be processed according to the remainder of HTMLpActivate.
As an example of the second type of processing, an instance of the phone book embedded object in an HTMLp page may look for escape sequences such as "@n" or "@I" to replace with the name or record ID of the phone book record the user has selected. The phone book object includes an edit method that can edit either the name of a record, or any of the fields. Passing the URL "phone:edit?Name=@n" to the phone book object will begin the process of adding another number to the selected phone book record by entering the phone book entry creation process with the name already set from the selected phone book record;, passing the URL "phone:edit?id=@i" to the phone book object will edit all the fields of the record.
The advantage of this extended functionality is that instead of having pages hardcoded in C, they can have those elements that require the data access and dynamic behavior of C be coded in C, while the specification of functions the user can perform is done in HTML. This is not possible in HTML 4.0 because the only way for an embedded object to interact with the user is by putting up its own user interface, which again will be hardcoded in the language in which the embedded object is implemented, and thus not easily modified or branded by the service operator.
FIGS. 10 and 11 provide two examples of possible phone book pages, and illustrate the flexibility embedded objects can provide with the extended processing of the present invention.
In FIG. 10, the user can create a new entry, or modify one of the fields of an existing phone book entry to change its speed dial key, ring tone, or number. Line 5 defines a key menu, which is shown displayed, activated by the user pressing the first softkey 130. The menu entries (lines 6-12) are bound to URLs that have escape placeholders for data from the current selection. In particular, line 6 defines the ACTION for the menu item to be a URL for the embedded phone book object that will change to the first page of the phone book entry creation process with the name already specified to be that of the current selection in the embedded phone book object. Generally, other URLs in the present invention can be activated using pieces of the selected phone book record to fill in their arguments; any of these URLs can be bound to menu entries, softkeys, or other keys on the keypad. The specific escape sequences are described below, with respect to the phone:list URL of the phone protocol.
In FIG. 11, the user can create a new entry, or go to a separate page to display all the parameters for a particular entry, and change them if she wishes (this is done via a separate screen, pbedit.html; the `@` escapes in the editurl argument to the phone:list embedded object extract all the relevant pieces of the entry for passing to pbedit.html). In addition, the a graphical title bar is used here, along with a tiled background of the wireless communication device manufacturer's logo as a border. The object to embed is specified in line 10 with a URL to the phone list object.
When the HTMLp content handler 114c encounters an <OBJECT> tag, it requests the shell 106 to fetch the data associated with the URL given as the CODE attribute to the OBJECT tag. The shell 106 returns this data as a content stream, which must be of type "Object". In the stream is a structure that contains:
A pointer to the object (a window to be made a child of the HTMLp page window)
A pointer to a function HTMLpActivate can call with the string it has been given.
A pointer to a function that will fetch the current state of the object. This is called by HTMLpClose.
A pointer to a function that accepts the state that was fetched and restores the object to that state. This is called by HTMLpOpen when it is told the page has been displayed before.
A pointer to a function that returns the "value" of the object as a string. This is called when the object is part of a form that is being submitted.
A pointer to a function that accepts the "value" to which the object should set itself. The value is a string. The function is called when the object is part of a form and extra data that have the same name as the object (as given by the NAME attribute to the OBJECT tag) were passed.
(b) Accessing Device Settings
The various configurable parameters of the wireless communication device 100 are accessible via the config protocol, further dcscribed below. It is desirable to provide pages that can adjust these settings using form gadgets to specify the possible values for each setting. However, to do this, it must be possible to set the initial state of these form gadgets to match the current value of the setting they're supposed to affect.
The form gadgets most preferably used to set the value of a device setting arc the radio button, the checkbox, and the scrolling list. The radio button and checkbox are both accessed via the INPUT tag, with a TYPE attribute of either RADIO or CHECKBOX. For these input elements, it is possible in HTML 3.2 to specify a selection attribution which defines whether the input element is selected on the form. The selection attributes include CHECKED and SELECTED. The CHECKED attribute indicates that a radio button or checkbox is to be initially selected. Similarly, a scrolling list is specified by a <SELECT> tag, with <OPTION> tags inside it, any of which may have the SELECTED attribute to indicate that that option of the selection list should be initially selected.
Normally these attributes are Boolean; if the CHECKED or SELECTED attributes exist in the source, the radio button, checkbox, or option is selected, while if they do not, it is not selected. In the present invention, however, these attributes have been extended to accept a value. The value takes the form of an expression, which, if it evaluates true, causes the item to be selected initially.
The expression fetches data from a URL and either treats it as a Boolean value, to be checked for truth or falseness, or compares it to a string for equality or inequality.
The syntax is:
ATTRIBUTE=[!]url
or
ATTRIBUTE=url[!]=string
ATTRIBUTE is either CHECKED or SELECTED. The URL here is to a config protocol, and takes the form "config:setting" where setting is the particular setting of interest which the config protocol handler 112b will access.
The first syntax form treats the fetched URL data as a Boolean value, converting the text to an integer and seeing if it is 0 or non-zero. If the leading "!" is present and the value is 0, the item is selected, while if the leading "!" is absent and the value is non-zero, the item is selected. If the url itself contains an equal sign, it must be enclosed in parentheses.
The second syntax form performs a string comparison between the string and the data retrieved for the URL. If "!=" is given, the item is selected if the strings are not equal, while if just= is given, the item is selected if the strings are equal.
If the data returned by the URL is neither plain text nor HTML, the expression always evaluates false and the item remains unchecked.
FIG. 12 provides an example of the use of this extension, showing both the HTMLp source, and the resulting page. Lines 9-14 specify the various configuration settings, showing the CHECKED attribute being set by an expression which is a URL to the config protocol hander. The illustrated page shows the resulting user interface for configuring these settings. In this example, the user will be presented with three radio buttons and a text input field. The user will be able to specify whether the backlight for the screen display 136 should be on only when the device is in-use, or when it's in-use or is plugged in, or not at all. In addition, the user can set the number of seconds without input after which the wireless communication device is consider to no longer be in use. These settings may be stored in the "backlight" and "backlight delay" settings, respectively. When the screen first appears, the radio button that corresponds to the current setting will be checked, and the text input field will contain the current delay.
Generally, when an <INPUT> tag with this extended selection attribute is loaded, the HTMLp content handler 114c passes the URL to the shell 106 to be fetched. The HTMLp content handler 114c evaluates the fetched data according to its syntax form, as described above, and establishes the value of the selection attribute according to the evaluation of the URL data. "Including" HTML
"Including" is an extension to HTML that allows blocks of HTML or HTMLp code to be referenced in a page. Any included HTML is recursively resolved, so that included HTML may itself include other HTML. At present, the HTML 4.0 provides no mechanism to include blocks of HTML from one page into another. A benefit of included HTML is that common HTML components, such a page headers or footers, navigation toolbars, and the like, which are desired to appear in a number of pages, may be easily incorporated by a single reference to the included pages.
The present invention provides a mechanism for including HTML (which also includes plain text) from any source, by giving its URL. This is used primarily to display device settings via template pages, but can also be used to reduce content size by placing elements common to multiple pages in a separate part of the content archive and including it in the other pages. The mechanism is provided by the <INC> tag, which has the following syntax:
<INC SRC=url DYNAMIC>
The SRC (source) attribute must be present, and specifies the URL whose data are to be included in the document at that point. When the <INC> tag is resolved by the HTMLp content handler 114c, the data associated with the URL is fetched inserted at the location of the <INC> tag.
An <INC> tag may be used anywhere in a page, except from within another tag. For example, "<A HREF=<INC SRC=file:commonurl.txt>>" is not allowed.
FIG. 13 illustrates an example of the <INC> tag. In this example, the first page infor.html has an <INC> tag on line 2 referencing the second file bbody.html, which itself has an <INC> tag on line 8 referencing a third file stdlogo.html. When the first page is loaded, the HTMLp content handler 114c fully resolves all <INC> tags, and produces the resulting page, as shown. File info.html has an <INC> tag on line 13 which references the file endbody.html, and this latter file includes the </BODY> tag properly closing the <BODY> tag that appeared in a completely different file, bbody.html.
Generally, when parsing a page, as the HTMLp content handler 114c identifies an <INC> tag, it fetches the reference URL and directly inserts the data from the file into the source of the present file, and resolves it as needed for displaying the page.
If the DYNAMIC attribute is specified for the <INC> tag, it causes the page to be rebuilt when the user returns to it, rather than using display instructions that were cached when the page was temporarily closed. In general, the DYNAMIC attribute indicates that the url used as the SRC refers to data that may change while the page is temporarily closed, so it must be reread and the page rebuilt to accommodate any such change.
(d) Conditional HTML
The display of pieces of a template HTMLp page can be controlled by parameters passed with the URL for the template page, either directly as arguments following a `?` in a URL for the file protocol 112d (arguments specified in a URL for the file protocol 112d are available as values within the file using the extra:protocol), as form data from a METHOD=NEXT form in the referring URL, or as parameters from C code in the present invention.
Conventional HTML does not allow for conditional expressions to be encoded directly in the HTML source of a page to control which elements of the page are displayed. The present invention overcomes this deficiency with the new <IF> tag. The <IF> tag allows for testing of expressions, such parameters or device settings, to control the display of a page. The syntax is as follows:
<IF TEST=expression DYNAMIC>html<ELSE
TEST=expression>html<ELSE>html</IF>
The expression in the TEST attribute is evaluated exactly like that described for the CHECKED and SELECTED attributes, above.
For example, consider the HTMLp source:
<IF TEST=extra:conf>
<KEY KEY=1 LABEL=Conference ACTION=phone:conference>
<ELSE>
<KEY KEY=1 LABEL="Pick Up" ACTION=phone:answer>
</IF>
<KEY KEY=send ACTION=phone:answer>
<IF TEST=config:anykey>
<KEY KEY=default ACTION=phone:answer>
<KEY KEY=back ACTION=phone:answer>
<ELSE>
<KEY KEY=default ACTION=none>
<KEY KEY=back ACTION=phone:ignore>
</IF>
In the first <IF> tag, TEST is evaluated with respect to extra data "conf" being passed into the page by the C code that loaded the page. This data is stored in a variable available to the HTMLp content handler 114c. When the page is loaded, if "conf" evaluates to TRUE, then the first softkey 130 (KEY=1) is labeled "Conference" and is bound in the key binding table to the URL "phone:conference", to allow the user to activate the conference feature of the telephone. If "conf" evaluates to FALSE, then the softkey is labeled "Pick Up" instead and the key is bound to a different URL.
In the second <IF> tag, the tested data is a configuration setting of the wireless communication device, accessed by the "config:anykey" URL. Depending on the device configuration for this setting, either all keys, including the Back key, will be bound to the "phone:answer" function, or all keys but the Back key (and any other key that has a specific binding) will do nothing, while the Back key will be bound to the "phone:ignore" function.
The <IF> tag has a DYNAMIC attribute that tells the parser that the URL it uses generates dynamic data and the page should be reparsed, similar to the %[url] form used in template mode to signal that url refers to data dynamic enough to require the page to be rebuilt when it is again made visible.
(vi) Phone Number Entry Field
HTML 4.0 is designed as a general purpose language, and does not include any features that make it particularly adapted for use in a wireless communication device, particularly one capable of making telephone calls, and storing telephone numbers and associated names.
To make HTML more adapted for such a wireless communication device 100, the present invention specifies "phonenum" and "phonename" as new values for the TYPE attribute of the <INPUT> tag. Generally, <INPUT> tag allows specification of a data input type, such as a checkbox, radio button, text, or image.
The new input type of the present invention allows the user to enter a phone number or a person's name. As the user types, the input field uses the input data to look up a matching record in a phone book data structure. Matching records are then displayed in a list below the input field in exactly the same format as is used in the phone book display.Once the matching records are displayed, the user is able to select an item in the list, and have that item be used to complete the form.
More particularly, when the input type is "phonenum," the input digits are compared against all telephone numbers in the phone book; matching telephone are displayed in a list. When the user selects one of the matching telephone numbers in the list, this causes the input field to be replaced by the full selected telephone number, with the portion that matched the input underlined. In matching, single digits (0-9) or double digits (00-99) are matched only against the speed dial list, and display matching speed dial numbers.
When the input type is "phonename", the input characters are compared against the names in the phone book, and those entries that match are displayed, with the characters that matched drawn underlined. Matches in the first word of the name take precedence over matches in subsequent words and the list is sorted accordingly. When the user selects one of the matching names, this causes the input field to be replaced by the full matching name.
FIG. 14 illustrates an example of the HTMLp source and the resulting page. Here, line 7 specifies the phone protocol for dialing a telephone number; the input type is "phonenum". The user has first typed in "2" which is matched against the speed dial list and displays a matching name. In the next image, the user has typed in "995" which is matched against the phone book list, and displays a single matching name. In the third image, the user has selected the name, which causes the entire telephone number that matches including prepending and remaining digits to be inserted into to the input field for use in dialing.
(b) Multi-part Forms
As mentioned earlier, in typical HTML pages destined for the desktop and its large screen, a conventional form will use many input fields. If such a form were displayed on the small screen display 136 of a typical wireless communication device 100, it would be very easy for the user to become lost in the form, because she loses the context of the form, most of which will be scrolled off the screen display 136 at any given time, or she cannot see much of the data being entered. FIG. 16 illustrates an example of a conventional HTML form which would be cumbersome to use on a screen display 136 of a wireless communication device 100.
One solution is to break the single form into a series of forms that each gather one or two of the items required. In this case, however, conventional HTML requires the data from each form to be transmitted to the server as part of the URL that fetches the next form. The server then takes the data passed in the URL and returns a page that must be generated on-the-fly with the passed-in data from the previous forms included as "hidden" type input elements in the form in the returned page. In this manner, the data the user enters get sent up and back multiple times until the entire form has been filled in. This process is very bandwidth intensive, and time consuming, and costly.
The other drawback to breaking a form into multiple forms is what the user has to go through if she decides in the middle that she does not want to complete the form after all. In such a case, the user has to hit the "End" or "Back" key once for each of the subforms that have been filled in, since each is a separate page. If the user is in a hurry, she could easily overshoot and end up dropping out of a place she actually wanted to be in when canceling the form.
FIGS. 17a.1, 17a.2, 17b.1 and 17b.2 illustrate a conventional multiple form method, as described above, where parameters received from a client computer in one HTML page are inserted by the server computer as HIDDEN type inputs in a next HTML page before being uploaded to the client computer. As seen in the figures, multiple pages have to be dynamically created to continually pass this data back and forth between the client and server.
This protocol for sending data back and forth between a server and a client results from a fundamental assumption of standard HTML that each transaction between a client and server is stateless, and thus, no data from previous states may be implicitly relied on to complete a current state.
The present invention overcomes these deficiencies of HTML with a new "NEXT" method for forms, and a new <TOP> tag, which are designed to take advantage of the fact that client is fully able to save its own state and use this information in determining subsequent states.
(i) The "NEXT" Form Method
A form in an HTML page consists of one or more input elements for gathering data from the user. The data, each piece tagged with the name of the input element from which it came, is submitted to a server according to two parameters in the FORM tag: the METHOD and the ACTION. The ACTION is a URL to which the data are usually appended, while the METHOD is either GET or POST. GET is used to fetch another page based on the data, while POST is usually used to send data to finalize a transaction.
To these two methods, the present invention adds a new NEXT method. Generally, the NEXT method allows a form to be specified in multiple parts, with each part including a subset of all of the input fields of the overall form, and the data for the entire form stored in an external data structure.
The NEXT method has the following effects:
1. The method used on the ACTION URL is "GET" without any modification of the URL,; the page is simply fetched from the server. GetURL is the function called for the protocol handler 112.
2. Any form in the fetched page begins with the name/value data-set active in the form on the current page. This includes any name/value data that was passed from a previous page. This replaces the use of "hidden" input fields, avoiding the bandwidth penalty of having to transfer the data up to the server and have it transfer the data and the page back again. Instead, the page can reside on the server without an associated CGI script, or it can reside on the device, having been downloaded with the other pages that make up the transaction when the user subscribed to the service.
FIGS. 18a.1, 18a.2, 18a.3, 18b.1 and 18b.2 illustrate the HTMLp source and pages for a multi-part form that captures the same information as the illustrated conventional HTML pages, but presents in a significantly more useful and easy to use format for a screen display 136. The first three pages, "purchaseform.html," "addr.html," and "credit.html" all use the NEXT method in the <FORM> tag to specify the next page to be loaded to obtain additional inputs. The last page "confirm.html," uses a conventional ACTION value to specify the CGI script for processing all of the data accumulated on the multi-part form. In this manner, much lower degree of bandwidth is needed between the server and the client to obtain all of the inputs to the form and transmit them back to the server, since the client (the wireless communication device 100) maintains the state data of the previous input pages. This state data of the name, address, credit card number, and so forth is maintained in an internal data structure of the wireless communication device 100 in its memory 126, and thus need not be embedded in HIDDEN type input elements as in conventional HTML. This internal data structure is created as the first page is parsed by the HTMLp content handler 114c , and updated as each new page in the multi-page form is loaded.
The <TOP> tag and "DONE" action used in the "confirm.html" page are explained in the following section.
(ii) Complex Interactions
Given that what would be a multi-element form in standard HTML displayed in a desktop browser can now be transformed into multiple pages in HTMLp, each of which contains a one- or two-element form (in order to fit on the screen display 136 comfortably), a user might easily find herself in the middle of providing data for each of the fields and decide she wishes to terminate the whole process. If all she can do is go back to the previous page, this could be a slow and tedious process to terminate the transaction.
To make termination of a multi-page form easier, the present invention allows a page to be marked as the beginning of a complex interaction a user might want to exit completely. It does this by providing the <TOP> tag:
<TOP>
at the desired location of the "top" of the interaction. Such an interaction may be a multi-part form, or any other complex group of pages.
To access the top of an interaction, a softkey 130 is defined using the <KEY> tag with an ACTION attribute of "DONE". When this softkey 130 is selected by the user, the user will return to the page that referred the user to the most recent page marked with <TOP>. This processing of the DONE value for ACTION takes place during the HTMLpActivate function, as described above.
(c) Navigation
The display of HTML on a conventional wireless communication device 100 is further hampered by the heavily-restricted keyboard and the absence of any pointing device. In a typical HTML environment, there is a scrollbar that can be clicked or dragged, a tab key to shift between fields in a form, and a mouse that can select hyperlinks included in the content should the user wish to follow them.
In a wireless communication device 100 in which the present invention advantageously operates, however, there is only the up key, down key, and possibly one of the softkeys 130 that may be relied upon to provide navigational controls. To provide a rich set of navigational abilities, the present invention provides the following features to HTMLp.
(i) Form Entries
When a page contains form elements, the Up and Down arrows are overloaded to allow moving between the form fields in the following fashion:
If the next (for the Down arrow) or previous (for the Up arrow) field in the form is visible, then it is made the active form field. This is denoted by a graphical selection indicator; a text input element will also get a blinking text cursor.
If the next (or previous) field in the form is not visible on-screen, the screen is scrolled so that the next (or previous) line of the page is brought on-screen. If the next (or previous) field is in the line that was brought on-screen, then it will be made the active form field. Otherwise, the current form field remains active.
As the screen display is scrolled, the current form field, is continually updated without requiring the user to directly select the field. In this manner, the user can easily switch among fields merely by scrolling, while being able to predictably read explanatory text leading up to the next field to be filled in.
In addition to this, if the first softkey 130 is not bound by the page to some other purpose, it will change its action in the key binding table as the current form field changes, as follows:
TABLE 1
Softkey Navigation Defaults
SOFTKEY
GADGET WITH FOCUS LABEL ACTION
Text field no label --
Scrolling List (single OK Selects and generates
selectable) Submit
Scrolling List (multi-selectable) Select Selects/de-selects item.
Popdown (closed) Open Opens popdown
Popdown (open) Select Closes popdown and
makes selection
Checkbox (selected) Clear De-selects
Checkbox (unselected) Select Selects
Radio button (unselected) Select Selects button
Radio button (selected) no label --
Standard link Select Activates Link
Phone: Dial link Call Goes to Dial screen
displaying the number
(can also be activated
with Send button).
The various actions defined in Table 1 provide for appropriate and dynamically variable behavior of the softkey 130 depending on the type of user interface gadget that is the current form field. These actions are dynamically assigned as the user scrolls a page and changes the focus between gadgets, thereby changing the current form field. For example, if the current form field is a hyperlink, then the softkey is automatically assigned to the URL for the link, and selection of the softkey automatically fetches the hyperlink. If the form field is some type of selection device, such as a list, popdown, checkbox, or radio button, then the softkey will either select, deselect, or submit an item from the selection device, as appropriate. For example, if a scrolling list has an item preselected using the SELECTED attribute (with or without the expression evaluation feature of the present invention) then the softkey 130 is defined to deselect the item.
This functionality for page navigation is implemented in the HTMLpProcessKey function. This function is called by the shell 106 when no other entity of the current page elects to receive an input keystroke. The input to the function is a key number indicating the key of keypad 128, and a Boolean indicating whether the key is pressed or released. Referring to FIG. 15 there is shown a flowchart of one embodiment of the HTMLpProcessKey function.
If there is a URL associated with the key, then the ProcessKey function 606 invokes 1502 the GetURL function of the shell 106, passing the associated URL. The shell 106 will process this URL as illustrated in FIG. 5, to determine the appropriate protocol handler 112 and content handler 114 for handling the URL.
The function determines 1502 from the key number whether or not the key has been bound to some action using the <KEY> tag, or the KEY attribute of the <A> or <INPUT> tags. If so, and the key is not a softkey 130 (which is handled by the shell 106), then that action is passed 1504 to ShellActivate when the key is released.
Otherwise, only the Up and Down keys are handled specially (1506); all others are passed 1508 to ShellDefaultProccssKey to receive their default handling.
The behavior of the Up and Down keys depends on whether there are selectable user interface gadgets on the page. A selectable gadget is either a form input field (from the INPUT, SELECT, TEXTAREA or OBJECT tags), or a hyperlink (if the LINKMENU tag is present). If there are no selectable gadgets on the page (1509), then the function makes 1514 the next line in the given direction visible.
If there are selectable gadgets on the page (1509), the reaction to an UP or DOWN key i |
