Patent Application
20070089048
Extensible mark-up language (XML) 1.0 (Third Edittion) is a World Wide Web Consortium (W3C) Recommendation of Feb. 4, 2004 available at www.w3.org, the contents of which are incorporated herein by reference. XML wraps information in XML tags in order to impart structure to the information so that the information may be more easily used across different programs and different computers. Scalable Vector Graphics (SVG) version 1.1 is a W3C Recommendation of Jan. 14, 2003 available at www.w3.org, the contents of which are also incorporated herein by reference. SVG is a language that describes (static and animated) two-dimensional graphics in XML. Because SVG permits fine grained control of graphics, SVG is becoming increasingly popular as a language for delivering Web content.
A drawback with SVG is that it is not adapted to support Web pages with user inputs. Thus, for example, it does not define a drop-down menu. While a programmer could create a Web page with a drop-down menu from the graphics primitives available in SVG, this would involve considerable programming. Further, even if a drop-down menu were created in SVG, SVG does not support the capture and submission of any information a user of the Web page may input using the menu. Since SVG is an open standard, the SVG language could be modified so as to support user inputs to Web pages, but this would require considerable effort.
This invention seeks to provide a more economical manner of providing SVG functionality and user inputs in a Web page. More generally, the invention has applicaton to extending the functionality of a graphics language.
A set of instructions include instructions written in a graphics display language and instructions written in a Web form creation language. Graphics are rendered on a display of a device in accordance with the instructions which accord to the graphics display language. Parameters are extracted from the instructions according to the Web form creation language and these parameters are utilized to create native user interface objects. The Web form creation language may be modified to include parameters which indicate the size and position of a user input area such that these parameters will also be used in creating the native user interface objects. The native user interface objects may be used to allow a user to input information via the user controls of the device. A graphic element of the graphic display language may be bound to a submit operation of the Web form creation language to allow submission of information which is input. Another graphic element may be bound to a reset operation of the Web form creation language.
According to this invention, there is provided a method for operating a device comprising: receiving a set of instructions; rendering graphics on a display of said device in accordance with graphics instructions of said set of instructions, said graphics instructions according to a graphics display language; extracting parameters from other instructions of said set of instructions, said other instructions including instructions according to a Web form creation language; and utilizing said parameters to create native user interface objects.
According to another aspect of the invention, there is provided a device comprising: a display; at least one user input control; a memory holding a set of instructions, said set of instructions including graphics instructions for rendering graphics on said display, said graphics instructions according to a graphics display language, and other instructions including instructions according to a Web form creation language, said other instructions including parameters; a controller for operating in accordance with said set of instructions to (i) render graphics on said display, (II) extract parameters from said other instructions of said set of instructions, and (III) utilize said parameters to create native user interface objects.
Other features and advantages of the present invention will become apparent from the following description in conjunction with the drawings.
In the figures which illustrate an example embodiment of the invention,
The housing may be elongated vertically, or may take on other sizes and shapes (including clamshell housing structures). The keyboard may include a mode selection key, or other hardware or software for switching between text entry and telephony entry.
In addition to the microprocessor 98, other parts of the mobile communication device 90 are shown schematically in
Operating system software executed by the microprocessor 98 is preferably stored in a persistent store, such as the flash memory 116, but may be stored in other types of memory devices, such as a read only memory (ROM) or similar storage element. In addition, system software, specific device applications, or parts thereof, may be temporarily loaded into a volatile store, such as the RAM 118. Communication signals received by the mobile communication device may also be stored in the RAM 118.
The microprocessor 98, in addition to its operating system functions, enables operation of a JAVA virtual machine 128 and, through the JAVA virtual machine, software applications 130A-130N, all of which may be stored in flash memory 116 on the device 90. As will be understood by those skilled in the art, JAVA is a platform independent language and a JAVA virtual machine is created to allow JAVA programs to run on a specific device. The specific JAVA virtual machine that may be used with handheld 90 is that which is part of JAVA 2 Platform, Micro Edition (J2ME) available from Sun Microsystems, Inc. through www.sun.com. Details about JAVA are available from many sources including http://Java.sun.com. the contents of which are incorporated by reference herein. A predetermined set of applications that control basic device operations, such as data and voice communications 130A and 130B, may be installed on the device 90 during manufacture. In addition, a personal information manager (PIM) application 130C may be installed during manufacture. The PIM is preferably capable of organizing and managing data items, such as e-mail, calendar events, voice mails, appointments, and task items. The PIM application is also preferably capable of sending and receiving data items via wireless network 88. Preferably, the PIM data items are seamlessly integrated, synchronized and updated via the wireless network 88 with the device user's corresponding data items stored or associated with a host computer system. Other factory installed applications may include a media engine 130D and JAVA user interface (UI) objects 130E, both of which are discussed further hereinafter.
Communication functions, including data and voice communications, are performed through the communications subsystem 100, and possibly through the short-range communications subsystem 102. The communications subsystem 100 includes a receiver 150, a transmitter 152, and one or more antennae 154 and 156. In addition, the communications subsystem 100 also includes a processing module, such as a digital signal processor (DSP) 158, and local oscillators (LOs) 160. The specific design and implementation of the communications subsystem 100 is dependent upon the communication network in which the mobile communication device 90 is intended to operate. For example, the communications subsystem 100 of the mobile communication device 90 may be designed to operate with the Mobitex™, DataTAC™ or General Packet Radio Service (GPRS) mobile data communication networks and may also be designed to operate with any of a variety of voice communication networks, such as AMPS, TDAMA, CDMA, PCS, GSM, etc. Other types of data and voice networks, both separate and integrated, may also be utilized with the mobile communication device 90.
Network access requirements vary depending upon the type of communication system. For example, in the Mobitex™ and DataTAC™ networks, mobile communication devices are registered on the network using a unique personal identification number or PIN associated with each device. In GPRS networks, however, network access is associated with a subscriber or user of a device. A GPRS device therefore requires a subscriber identity module, commonly referred to as a SIM card, in order to operate on a GPRS network.
When required network registration or activation procedures have been completed, the mobile communication device 90 may send and receive communication signals over the communication network 88. Signals received from the communication network 88 by the antenna 154 are routed to the receiver 150, which provides for signal amplification, frequency down conversion, filtering, channel selection, etc., and may also provide analog to digital conversion. Analog to digital conversion of the received signal allows the DSP 158 to perform more complex communication functions, such as demodulation and decoding. In a similar manner, signals to be transmitted to the network 88 are processed (e.g. modulated and encoded) by the DSP 158 and are then provided to the transmitter 152 for digital to analog conversion, frequency up conversion, filtering, amplification and transmission to the communication network 88 (or networks) via the antenna 156.
In addition to processing communication signals, the DSP 158 provides for control of the receiver 150 and the transmitter 152. For example, gains applied to communication signals in the receiver 150 and transmitter 152 may be adaptively controlled through automatic gain control algorithms implemented in the DSP 158.
In a data communication mode, a received signal, such as a text message or Web page download, is processed by the communications subsystem 100 and is input to the microprocessor 98. The received signal is then further processed by the microprocessor 98 for an output to the display 96. or alternatively to some other auxiliary I/O devices 106. A device user may also compose data items, such as e-mall messages, using one or more of the keyboard 92, the thumb wheel 94 and some other auxiliary I/O device 106, such as a touchpad, rocker switch, or some other type of input device. The composed data items may then be transmitted over the wireless communication network 88 via the communications subsystem 100.
In a voice communication mode, overall operation of the device is substantially similar to the data communication mode, except that received signals are output to a speaker 111, and signals for transmission are generated by a microphone 112. Alternative voice or audio I/O subsystems, such as a voice message recording subsystem, may also be implemented on the device 90. In addition, the display 96 may also be utilized in voice communication mode, for example to display the identity of a calling party, the duration of a voice call, or other voice call related information.
The short-range communications subsystem 102 enables communication between the mobile communication device 90 and other proximate systems or devices, which need not necessarily be similar devices. For example, the short-range communications subsystem may include an infrared device and associated circuits and components, or a Bluetoothm™ communication module to provide for communication with similarly-enabled systems and devices.
The device 90 may have a battery 121 to power the active elements of the device.
The compiler 86 may comprise a processor operating under software control to receive and parse an input source code file into an output machine readable object file. As will be further explained hereinafter, the compiler is specifically adapted to parse source code which comprises a graphics display language, such as SVG, and a modified Web form creation language. The Web form creation language may be XForms: XForms version 1.0 is a World Wide Web Consortium (W3C) Recommendation of Oct. 14, 2003 available at www.w3.org, the contents of which are incorporated herein by reference. Like SVG, XForms is an extension of XML
In operational overview, a content provider may develop Web content using both a graphics display language and a Web form creation language. Statements in each language are separately identified in the source code. The Web form creation language may be modified to include a specification of the position and size of a user input defined by the Web form creation language. The source code may include a statement in the graphics display language that binds a graphical element to a submit operation of the Web form creation language. Another statement may bind a graphical element to a reset operation of the Web form creation language. The source code may be loaded to Web content server 84. Device 90 may request this content from Web content server 84 via wireless communications network 88, relay server 87, and Internet 82, When the content is returned, at relay 87 it is intercepted and re-directed to compiler 86. The compiler compiles the content source code into an object (binary) file and returns this to relay 87 which then passes it on to device 90 via wireless communications network 88. The microprocessor 98 of device 90 uses media engine 130D running on JAVA virtual machine 128 to render graphical elements found in the object file on display 96. Web form creation statements are parsed to extract parameters needed to create native UI objects from UI classes. These parameters are then used to create the native UI objects. The native UI objects then allow a user to enter and display data in the various specified UI areas. When a user selects a graphic bound to a submit operation, the user input data may be submitted a specified (local or remote) application, such as an application on the Web content server 84 (via network 88, relay 87, and Internet 82).
The operation may be more fully understood by way of the example source code of
Line 25 is an SVG statement that establishes an empty rectangle with a blue border. The upper left corner of the rectangle is set at display position (80, 0) and the rectangle has a width of 100 (pixels) and a height of 20 (pixels). Lines 26 to 30 define a free-form XForms input for the “form1” form with the reference “CustomerName” and a descriptive label, namely, “Enter your name”. In a standard XForms input statement, it is left to the Web Browser to establish a display position for the label and to create and position an associated text entry box. However, the standard form free-form input statement is modified by line 27 which contains four “pz” parameters. These pz parameters define a rectangle at a display position and it may be noted that this rectangle mirrors that defined by the SVG statement at line 25.
Line 31 uses an SVG statement to place the word “Description” on the display and line 32 uses a further SVG statement to place a rectangle beside this word. Lines 33 to 35 define an XForms user input text area for the “form1” form with the reference “Description”. The standard text area statement in Xforms is modified by the inclusion of the four “pz” parameters in line 33 and these parameters mirror those for the rectangle created in SVG at line 32.
Lines 36 and 37 establish the display of the words “Favourite Ice Cream Flavour:” and a rectangle beside this text. Lines 38 to 55 define an XForms selection menu to allow a user to choose one of four items. The value attribute of each choice establishes the value which is stored when an item is selected. Again, the “pz” parameters mirror the parameters for the rectangle created in SVG at line 37.
Lines 56 to 61 bind the “form1Submit” XForms operation of lines 17 and 18 to an SVG graphic, namely a borderless coloured rectangle containing the word “Submit1”. Similarly, lines 62 to 67 bind the “form1Submit2” XForms operation of lines 19 and 20 to an SVG graphic, namely a borderless coloured rectangle containing the word “Submit2”. Also similarly, lines 68 to 73 bind the “form1 Reset” XForms operation of lines 21 to 23 to an SVG graphic, namely a borderless coloured rectangle containing the word “Reset”.
With reference to
By binding an SVG graphic to an XForms submit operation, a user may effect a submit operation by selection of (e.g., clicking on) the SVG “submit” graphic. Similarly, by binding an SVG graphic to an XForms reset operation, a user may effect a reset by selection of the SVG “reset” graphic. Therefore, the engine does not need to establish a native UI object to provide this functionality,
As will be understood by those skilled in the art, the media engine creates a tree structure from the object code and then traverses the tree to perform the instructions established by the object code. The engine traverses the tree as required to refresh the display in response to active animations and user actions.
Microprocessor 98 could be replaced by any suitable controller, such as a field programmable gate array (FPGA).
While the software applications 130A to 130N—including the media engine 130D and the native UI objects instantiated from classes 130E—are described as running on a JAVA virtual machine 128, with suitable adaptation, these software applications may run on another platform, such as Microsoft Windowst™, Alternatively, the media engine could be part of the operating system of a device. While the graphics display language has been described as SVG, equally another graphics display language could be used. While the Web form creation language has been described as XForms, it may be possible to use another Web form creation language such as Hypertext Markup Language (HTML) forms, which is part of the HT
The native UI objects of the handheld device 90 are objects that are developed to Interact with the specific user interface controls (e.g., thumb wheel) of the handheld. These objects have been described as JAVA objects in the exemplary embodiment where the handheld runs a JAVA virtual machine. However, in a device operating on a different platform, these native UI objects will also be different so that they are adapted to run on the different platform.
It will be apparent that the teachings of this invention could be applied to a wireline device rather than a wireless device, as described in the exemplary embodiment. Further, the device could be. for example, a Personal Computer or laptop computer, rather than a handheld device. Dependent upon the capabilities of the device, it may be possible for the device to accept (and run) the source code itself from Web content server 84 rather than a compiled form of the source code, in such instance, compiler 86 would be unnecessary.
Other modifications will be apparent to those skilled in the art and, therefore, the invention is defined in the claims.
