WO2005076152A2

WO2005076152A2 - Method, arrangement and system for outputting data

Info

Publication number: WO2005076152A2
Application number: PCT/EP2005/000993
Authority: WO
Inventors: Hyun Kyung Shin; Pushkar Singh
Original assignee: Fujitsu Siemens Computers, Inc.
Priority date: 2004-02-05
Filing date: 2005-02-01
Publication date: 2005-08-18
Also published as: WO2005076152A3

Abstract

The invention relates to a method for outputting data comprising the following steps: provision (A) of a description language (9), comprising symbols (11) for the description of abstract output elements (8) for the output of data, provision (B) of a sending arrangement (2), provision (C) of data to be output, mapping (D) of output data to abstract output elements (8), coding (E) of abstract output elements (8) to an output specification (100) using symbols (11) from description language (9), provision (F) of a receiving arrangement (3) with output components (15) specific to the receiving arrangement (3), transmission (G) of the output specification (100) from the sending arrangement (2) to the receiving arrangement (3), decoding (H) of the output specification (100) into the abstract output elements (8) of the description language (9) through the receiving arrangement (3), mapping (I) of abstract output elements (8) to the output components (15) specific to the receiving arrangement (3), output (J) of the mapped output components (15). The invention also relates to a sending arrangement (2) and a receiving arrangement (3) and a system for outputting data.

Description

METHOD, ARRANGEMENT AND SYSTEM FOR OUTPUTTING DATA

The invention relates to a method for outputting data available to a sending arrangement on a receiving arrangement us- ing a common description language. In particular it is aimed at a client/server system, in which the server acting as the sending arrangement defines a user interface to be output on a number of clients acting as the receiving arrangements, whereby each client may have different output capabilities, specific to the client.

Up to now the most common way of outputting data on a number of clients with specific output capabilities was simply to create on the server side different formats for the output for each specialized type of client. For example, a server provides a hypertext mark-up language (HTML) document describing a page to be output on a PC . On the PC a web browser only displays the received HTML document. If another client is to be used, for example a mobile device with a smaller screens like a personal digital assistant (PDA) , which employs for example the wireless application protocol (WAP) for displaying information, the server has to provide a different description of the same information, which takes account of the smaller screen size and follows the encoding rules of the used standard, i.e. the WAP specification. For devices using a messaging service, such as the short message service (SMS) of mobile phone networks, the server has to provide yet another description of the same information to be displayed.

Recent programming techniques like Java servlets have helped to make the production of different output formats easier by providing standard methods for the creation of output according to the format of common client types. Nevertheless the fact remains that multiple output formats, i.e. instructions on how to present the output data, have to be developed, maintained and provided by the server. Especially the maintenance of the specified output formats is a burden for the programmer as the introduction of new or revised client types might require to change the source code of the application program. In addition, the programmer has to code the output data in a format specific to the used client or protocol, i.e. he or she needs additional knowledge about these client types and protocols in addition to the required knowledge of the application domain and programming environment, which is another burden on the programmer providing the application.

Other methods exchange only the data to be output between the client and the server, e.g. text to be presented to the user, but no output format information, i.e. information on how to present the data to a user. This is often done using the extensible mark-up language (XML) as standard for the data exchange .

In this case, the client itself must be aware of how to present the received output data. For example, a client that only receives a list of values, needs to know that and how they form the available options of a particular choice and also how to present such a choice to a user. E.g. it must be aware if they are independent of each other, i.e. if they form the entries of a list, of which none, one or many entries can be chosen, or if they are exclusive, i.e. if they form the entries of a list, of which exactly one must be chosen at any one time. Since in this approach such information is not provided in the data sent out by the server, large parts of the output format must be provided by the client. However, this output format is both dependant on the application which provides the data to be output an the client itself. Thus each time a new application is developed, a new output format must be developed for each client. Using this approach it will be necessary to implement and install new output formats on the client, whenever new or revised applications become available on the server. This is ineffective and may be infeasible, if the clients are not part of a managed environment, i.e. if they are owned by individual users.

In summary, both previously-described methods lack the flexibility to output data of an arbitrary application on a variety of clients, each of which may have different output capabilities, specific to the client.

Therefore, it is one object of the invention to provide a flexible method for outputting data available to a sending arrangement on a variety of receiving arrangements with different means of outputting data, specific to the receiving arrangement .

These and other objectives are achieved by the inventive method that makes use of a description language, which contains symbols for the description of abstract output elements for the output of data. This language is known to the sending and to the receiving arrangement . The sending arrangement maps output data provided to it to abstract output elements. These elements are encoded to form an output specification using symbols from the abstract language. Said output speci- fication is transmitted to a receiving arrangement. The receiving arrangement decodes the transmitted output specification into the abstract output elements. In addition, the receiving arrangement has access to output components which are specific to the output capabilities of the receiving arrangement . The receiving arrangement maps the decoded abstract output elements to said output components . In a last step the mapped output components are output by the receiving arrange- ment .

According to the invention, there are the two mapping processes, which map the output data to abstract output elements at the sending arrangement and map the abstract output ele- ments to output components at the receiving arrangement respectively. The first mapping provides the independence of the sending arrangement from the used receiving arrangement . The latter mapping provides the independence of the receiving arrangement from the sending arrangement providing the output data. Thus the two mappings into and from a common abstract language achieve a higher degree of flexibility of the inventive method.

In a preferred embodiment the description language also pro- vides abstract elements, which contain at least one input parameter. In order to enable a feedback from the receiving arrangement, the inventive method also includes the following steps. Input parameters of the abstract output elements are mapped to input components provided by the receiving arrange- ment, which are specific to the input capabilities of that receiving arrangement. Values acquired by the input components of the receiving arrangement are used to update the input parameters of the abstract output elements. Through a pre-defined event, such as pressing a confirmation button, a feedback mechanism is triggered. The abstract output elements containing the updated input parameters are coded using the symbols of the description languages to form an updated output specification. The coded output specification is trans- mitted from the receiving arrangement to the sending arrangement . The sending arrangement decodes the received output specification into the abstract output elements containing the updated input parameter. At this stage the updated input parameters are available for processing at the sending arrangement .

Such embodiments are useful to allow a server computer to define the elements of a user interface in an abstract way, such that said user interface can be output on a variety of clients using client-specific output and input components. Examples of such clients comprise, but are not limited to, simple text terminals, HTML or web browsers, mobile devices using WAP browsers or short messaging services, audio de- vices, which are capable of synthesizing a voice, and devices having a graphical user interface.

The methods described can be used in a variety of different configurations of sending arrangements and receiving arrange- ments, typically connected using a common data network. The used data network only needs to provide means for transmitting output specifications in the provided description language. Thus any network protocol for example the transmission control protocol of the internet protocol (TCP/IP) , the hy- pertext transfer protocol (HTTP) , the remote method invocation (RMI) protocol, the simple object access protocol (SOAP) or the common object request broker architecture (CORBA) can be used for the transmission of the output specification.

The used description language can be based on open standards such as the extensible mark-up language (XML) , whose symbols can be generated easily from a variety of programming languages, such as Java, C++, C#, Visual Basic, Perl or PHP, and tools. Thus the coding and the decoding of the output specification can be achieved using standard application programming interfaces (APIs) like the Document Object Model (DOM) , the Simple API for XML (SAX) or the Java API for XML Process- ing (JAXP) or Binding (JAXB) .

In cases, where the output specification is provided according to the XML standard, freely available software tools can be used to implement the mapping of abstract output elements to output components. Such tools are often based on other

XML-related standards, for example the extensible stylesheet language for transformations (XSLT) .

In another embodiment of the invention, a grammar describing the description language is used to verify the correctness of the coded output specification. In this way a client receiving a output specification can confirm that all symbols of the output specification are known to it, i.e. that a successful completion of the task of outputting the contained data is possible. If the received output specification does not comply with the grammar known to the receiving arrangement, for example because the sending arrangement and the receiving arrangement use different variants or versions of the description language, or because the sending arrangement is malfunctioning, the receiving arrangement can reject the request to output the transmitted data. In this way, instead of starting to present it and terminating with an error once the incorrect or unknown parts of the output specification are reached, a malfunctioning of the receiver is prevented. Such a grammar can be specified for example using an XML Schema document or a Document Type Definition (DTD) . Additional aspects of the invention will now be described using the following figures of exemplary and non limiting embodiments of the invention.

Figure 1 shows a system comprising an application, a sending arrangement and a receiving arrangement,

Figure 2 shows an exemplary output specification,

Figure 3 shows a block diagram of a first method for outputting data,

Figure 4 shows a block diagram of a second method for outputting data,

Figure 5 shows a first embodiment of a receiving arrangement,

Figure 6 shows a second embodiment of a receiving arrange- ment,

Figure 7 shows a HTML page generated from an abstract output specification,

Figure 8 shows a graphical user interface generated from an abstract output specification.

Figure 1 shows a system comprising an application 1, a sending arrangement 2 and a receiving arrangement 3. Said sending arrangement 2 and receiving arrangement 3 are connected by a network 4, for example the Internet, a company internal data network, a public switched telephone network (PSTN) or a dedicated communication line. The sending arrangement 2 com- prises a data input 5, for example an API accessible to the application 1, a physical device receiving data, like a modem, or a mechanism reading data from a storage medium like a hard-disk drive, and a data processing unit 6a, for example the CPU of a server computer or a programmable logic unit like an FPGA or an ASIC. Said data processing unit 6a comprises a mapping arrangement 7, for example as a software process running in a CPU of a PC or a hardware device, which is part of the data processing unit 6. The processing unit 6 further comprises a coding arrangement 10, like an API of a standard library for the encoding of XML messages or a dedicated signal processor.

The receiving arrangement 3 comprises a data processing unit 6b, which in turn comprises a decoding arrangement 12 and a mapping arrangement 13. Again the decoding arrangement 12 or the mapping arrangement 13 can be implemented in either hard- or software. The receiving arrangement 3 also contains a library 14 of output components 15, for example text boxes, check boxes, radio buttons, menu elements, push buttons and so on. Said output components 15 can be composed to form a user interface 16, like a graphical representation of a screen or read-out instruction for a user, on an output device 17 of the receiving arrangement 3, for example a built- in screen or a loudspeaker.

Both the sending arrangement 2 and the receiving arrangement 3 have access to a common description language 9, which comprises symbols 11 for the description of abstract output ele- ments 8.

Figure 2 shows an exemplary output specification 100. The associated description language 9 provides three abstract out- put elements 8, one called "abstract text" 8a used for outputting textual information, one called "abstract choice" 8b used to output a selection of exclusive options and return a user choice, and a last one called "abstract action" 8c used to specify a potential action, which can be activated using the user interface 16. Practical implementation of description languages 9 will of course offer more abstract output elements 8, such as menu items, input fields or hierarchical structures. Each abstract output element 8 is represented by a different symbol 11. In the example these symbols are

"<text>", "<choice>" and "<action>". The elements also contain output data 101 and input parameters 102. For example the abstract output element "abstract text" contains the text to be output. The abstract output element "abstract choice" specifies both output data 101, i.e. the options to be presented, and an input parameter 102, which specifies the option currently chosen, for example represented by a currently pressed radio-button in a graphical representation of the user interface 16.

In an exemplary embodiment of the invention the sending arrangement 2 is a server computer which runs the application 1, which provides data to be output on the user interface 16 of the receiving arrangement 3. In this example the applica- tion 1 wants to prompt a user of the application 1 to make a choice between two different options, namely the payment by credit card or cheque. To this end a text is to be output on the output device 17 of the receiving arrangement 3. The user interface 16 should also present the choice between the two options and allow a user to choose one of them. Finally, the user interface 16 needs to provide means which confirms the user's choice. Whether said receiving arrangement 3 is an web browser or an automatic phone messaging service is not known to the sending arrangement 2 or the application 1.

Figure 3 shows individual steps A - J of the inventive method. The arrows between the steps indicate their logical dependency, but not necessarily a temporal order. The steps will be described in detail using the example set out above.

The steps A, B and C provide the description language 9, the sending arrangement 2 and the output data received from the data input 5 respectively. In this example we will use an XML notation for the description language 9, whereby tag names denote the abstract output elements 8, their contained data is used to specify the output data 101 and attributes are used to specify the input parameters 102. An exemplary output specification 100 of the example language 9 is presented in Figure 2. As sending arrangement 2, for example, a web-server can be used, which responds to requests from the client ac- cording to the hypertext transport protocol (HTTP) by providing a response message, in this example an output specification 100 like the one presented in Figure 2. For the example it is assumed that the application 1 runs on the same computer which acts as the web-server, i.e. that the application 1 can provide output data by the means of a software interface like an API . Of course this does not need to be the case in general, i.e. application and web-server can run on different machines and communicate in another way, e.g. by exchanging files over a data network.

In step D said output data is mapped to abstract output elements 8. In the example, one "abstract text" output element 8a for the output of the text "Please specify the form of payment" and one "abstract action" output element 8c for the confirmation of the choice are mapped to the output data provided. In addition, one "abstract choice" output element 8b comprising the options "Creditcard" and "Cheque" and an input parameter, which specifies that the "Creditcard" option is the currently chosen option, is mapped. In step E the sending arrangement 2 codes the output specification 100 of the desired user interface by replacing the abstract output elements 8 with their respective symbols 11 from the description language 9 and including the provided output data 101 and input parameters 102. In this example, this step results in the output specification shown 100 in figure 2, though this specification 100 is exemplary and neither the used symbols 11, their format or their order is limiting or prescriptive.

In step F a receiving arrangement 3 with a library 14 of specific output components 15 is provided. In the example chosen, the receiving arrangement 3 is a web browser, which is capable of displaying text documents complying with the HTML standard. Among others the HTML 4.0 specification provides output components 15 for displaying text, ^"e.g. using the <p>- tag, an output component 15 to specify a form for user input, indicated by the <form>-tag and different output components 15 of said form, e.g. those specified using the <input>-tag. The output components 15 specified by the <input>-tag are parameterized using a "type" attribute with values like "submit" or "radio" to specify a special submit button, which triggers a special feedback mechanism, and a radio-button respectively. All of these language elements can be parameter- ized to further specify the exact properties and the format of these output components 15. In step G the output specification 100 coded in step E is transmitted from the sending arrangement 2 to the receiving arrangement 3 using the network 4. In the example this transmission uses the HTTP protocol and is thus initiated by the receiving arrangement 3, i.e. by the web browser requesting a document from a predetermined web address. However, in general such a process could also be initiated by the sending arrangement 2, e.g. by broadcasting a coded output specification 100 to a group of receiving arrangements 3 using the user datagram protocol (UDP) . The receiving arrangement 3 decodes the received output specification 100 into the corresponding abstract output elements 8 in step G. In the following step I the abstract output elements 8 are mapped to output components 15 which are specific to the used receiving arrangement 3 and the capabilities of its output device 17.

For the web browser of this example, the output components 15 correspond to the tags provided by the HTML standard and described above. Thus, in step I, abstract output elements 8 are mapped to the output components 15, which are the aforementioned HTML-tags in the given example. In this particular case, the steps G and I can be combined.

In the example the decoding and mapping process can be af- fected by the use of a transformation language, as described for example by the extensible style sheet language (XSL) and its accompanying transformation language (XSLT) specifications, and corresponding transformation engines, which are capable of executing these transformation. A resulting HTML document might look as follows: <HTML>

<HEAD>

<TITLE>Please specify the form of payment</TITLE>

</HEAD> <B0DY>

<P> Please specify the form of payment</P>

<INPUT type="radio" value="Creditcard" name= "choicel " >Creditcard<BR> <INPUT type="radio" value="Cheque" name=" choicel">Cheque<BR> <INPUT type="submit" value="0.K. "> </FORM> </BODY> </HTML>

In the example provided, the "abstract text" output element 8a, prompting the user to make a choice, is mapped to output components 15 both as paragraph displayed on the generated page and as the title for that page. The "abstract choice" output element 8b for choosing between the two different options of payment is mapped to a collection of radio-buttons. They belong to a common group, because they both specify the same name ("choicel" in the example) . As a consequence, only one of these radio-buttons can be pressed at any one time as required by the semantic of the abstract output element 8b. The same information could have been mapped to a drop-down menu, which is also an available component of the HTML specification. The choice, which output component 15 to use for the abstract output element 8b, rests with the receiving ar- rangement 3. The "abstract action" output element 8c of the example, which is used to confirm the choice, is mapped to the special type of button provided by the HTML specification for this purpose . Together these HTML components specify the user interface 16. In a last step J, the user interface 16 is output using the output device 17 of the receiving arrangement 3. In the exam- pie provided, this step includes rendering of the HTML page shown above and displaying it in a window of the web browser. An exemplary result of this step is shown in Figure 7.

Figure 4 shows another embodiment of the inventive method. The variant shown adds further steps K - R in order to allow a feedback from the receiving arrangement 3 back to the sending equipment 2. In the example above, it is desirable to sent back the option chosen for the "abstract choice" output element 8b by a user after he or she has confirmed the choice by triggering the "abstract action" output element 8c, e.g. by pressing the "O.K." button shown in Figure 7.

The description language 9 provided in step A needs to comprise at least some abstract output elements 8, which contain at least one input parameter 102. The exemplary language used in the previous embodiment and the output specification of this language already provide such an abstract output element 8, namely the "abstract choice" output element 8b. It contains a single input parameter 102, which is represented by the attribute with the name "value".

The steps B - J are the same as in the embodiment described above. In step K, input components are provided, e.g. a pointing device like a mouse with an associated mouse pointer on a graphical user interface, a touch-screen or a keyboard, which allows to type in some characters. These input components are mapped to the input parameters 102 of abstract output elements 8 with at least one input parameter 102 in step L. For example, an "abstract action" output element 8c with an associated button on a screen is associated with a mouse- click, or a text input field is associated with the input from a keyboard. In a step M the receiving arrangement 3 gathers input, for example a mouse-click within a predefined distance to a output component 15 displayed on a screen or a key-stroke of a particular key of a keyboard. In step N the gathered information is used to update the state of the mapped input parameters 102 and thus the state of the ab- stract output elements 8 comprising them. For example the selection of an option of the "abstract choice" output element 8b in the example above updates the state of its "value" input parameter 102.

After confirming the changes, e.g. by activation the "abstract action" output element 8c represented by the button, the updated abstract output elements 8 can be encoded using the description language 9 in step 0. This results in an updated version of the output specification 100. For example, if the user has clicked on the radio-button representing a payment by Cheque, the value of the input parameter 102 "value" encoded in the "abstract choice" output element 8b of figure 2, would read "Cheque" instead of "Creditcard" now. In step P this updated output specification 100 is sent back from the receiving arrangement 3 to the sending arrangement 2, which decodes the received output specification 100 in step Q back into the abstract output elements 8. Thus the updated input parameters 102 of the abstract output elements 8 are available to the sending arrangement 2 and can be made available to the application 1 for further processing in step R. There are two possible options regarding the content of the output specification 100 returned in step P. One can either return the complete output specification 100, containing all abstract output elements 8 that were transmitted in step G from the sending arrangement 2. Or one can only transmit those abstract output elements 8 with input parameters 102, whose input parameters 102 have been updated in step N of the inventive method. The former option is easier to implement, as the receiving arrangement 3 does not need to maintain a list of updates performed in step N. It will just serialize, i.e. encode, the state of all abstract output elements 8 into an output specification 100, once this is triggered by a predetermined action. However, the latter option, i.e. the transmission of incremental updates in step P is more effi- cient, as less data has to be transformed. This is particularly important in a system, where the bandwidth available between receiving arrangement 3 and sending arrangement 2 is limited.

Figure 5 shows another embodiment of the receiving arrangement 3 for the output of data. Herein the receiving arrangement 3 comprises an automatic voice system 18 and a telephone 19, which are connected by a telephone network 20. The automatic voice system 18 comprises a decoding arrangement 12, a mapping arrangement 13, a synthesizer 21 and a voice recognition system 22. The telephone 19 comprises a loudspeaker 23 and a microphone 24.

Steps A to E, G and H, i.e. the provision (A, B, C) of the description language 9, the sending arrangement 2 and output data, the mapping D of output data to abstract language elements 8, the coding E of the output specification 100 and the transmission G and decoding H of the output specification 100 remain unchanged. The receiving arrangement 3 provided in step F comprises the automatic voice system 18 and the telephone 19. The automatic voice system 19 comprises the synthesizer 21, which, in combination with the telephone 19, pro- vides the user interface 16 using the loudspeaker 23 as the output device 17. In step I the abstract language elements 8 are mapped to spoken commands, which correspond to the output components 15. Said spoken commands are output on the loudspeaker 23 of the telephone 19 using the synthesizer 21 in step J of the inventive method. The audio signals generated from the synthesizer 21 are transmitted using the telephone network 20 to the telephone 19.

The separation of the receiving arrangement 3 into the auto- matic voice system 18 and the telephone 19 allows to use the inventive method with an arbitrary telephone 19 using the public switch telephone network 20. Consequently the application 1 is accessible from any telephone 19 in the world. The automatic voice system 18 does not need to be located near the sending arrangement 2 or the telephone 19.

In order to implement a feedback path using the receiving arrangement 3 shown in Figure 5, the microphone 24 is used in combination with the voice recognition system 22, which is provided in step K as input component. Here the mapping L of input components to input parameters 102 will be time- dependant, i.e. the voice recognition system 22 will always direct its output to the input parameter 102 of the abstract output element 8 being read out at that moment. For example, after reading a list of available options in step J to a user of the telephone 19, said user can react by speaking a command, e.g. by saying the number of the option he or she wishes to select. This information is gathered in step M us- ing the microphone 24 and transmitted over the telephone network 20 back to the voice recognition system 22. In step N the voice recognition system 22 analysis the received voice pattern and updates the input parameter 102 of the current abstract output element 8 with the corresponding value . Step 0 codes the updates information either immediately or after a confirmation or at the completion of the phone call and transmits it in step P back to the sending arrangement 2. As above the sending arrangement 2 decodes the updates output specification 100 containing the values of the input parameter 102 in step Q. In step R the values of the input parameters 102 are processed, for example by sending them back to the application 1.

In another embodiment shown in Figure 6, the receiving arrangement 3 comprises a messaging gateway 25, a mobile phone 26 and a mobile phone network 27. The messaging gateway 25 comprises a decoding arrangement 12 and a mapping arrangement 13 and is connected to a sending antenna 28. The mobile tele- phone 26 comprises a messaging arrangement 29, a screen 30 and a keyboard 31. The messaging arrangement 29 is connected to a receiving antenna 32. The messaging gateway 25 is able to transmit messages to the mobile telephone 26 using the mobile phone network 27.

Again the steps A to E, G and H remain unchanged. The receiving arrangement 3 provided in step F comprises the mobile phone 26 and the messaging gateway 25. The screen 30 of the mobile phone 26 can be used as output device 17 of the re- ceiving arrangement 3. In the step I the abstract language elements 8 are mapped to short textual descriptions, which act as output components 15. For example the output data 101 of the "abstract text" output element 8a can be used as its representation. The options of the "abstract choice" output element 8b can be represented, for example, as numbered entries of a list. The "abstract action" output element 8c can be mapped to a predefined function key of the mobile phone 26, e.g. a special "O.K." button of the keyboard 31. The textual descriptions are combined to form a short message which is transmitted over the sending antenna 28 and the network 27 to the receiving antenna 32 of the mobile phone 26. In the step J the received short message comprising the user inter- face 16 is displayed on the screen 30 of the mobile phone 26.

This embodiment of the invention makes the application 1 available to all mobile phones 26 using a short messaging service. Because the mapping arrangement 13 provided by the messaging gateway 25 is separate from the receiving mobile phone 26, the embodiment can be used with existing mobile phones 26. The messaging gateway 25 can be provided as a service directly provided by the sending arrangement 2 or as a independent unit. In the latter case it is possible to use the messaging gateway 25 with several sending arrangements 2 each providing one or more applications 1.

The embodiment of the receiving arrangement 3 presented in Figure 6 can also be used to implement a feedback path. Herein the keyboard 31 is used as an input component, which is provided in step K. In step L individual keys are mapped to the input parameters 102 of the abstract output elements 8. Alternatively a cursor can be used on the screen 30 of the mobile phone 26. Said cursor is controlled by a special group of keys of the keyboard 31 of the mobile phone 26, as they are commonplace. The input from the other keys is then directed to the output component 15 at the current position of the cursor. In step M such input from the keyboard 31 is gathered by the mobile phone 26. For example, a user might select an option from a numbered list on the screen by pressing the number key corresponding to the selected option. In step N this information is used to update the input parameter 102 of the corresponding abstract output element 8 , i.e. the input parameter 102 of the "abstract choice" output element 8b.

Once the changes have been confirmed, for example by pressing a special "O.K." key on the keyboard 31 of the mobile phone 26, the updated abstract output elements 8 are encoded to form an updated output specification in step O. This can be done, for example, by composing a new message containing an updated output specification 100 using the messaging arrangement 29, which is send back to the messaging gateway 25 and passed on to the sending arrangement 2 in step P. Alternatively only the input signals are send back to the messaging gateway 25 and the steps N - P, i.e. the updating of the ab- stract output element 8, the coding of an updated output specification 100 and the transmission of the output specification 100 are performed by the messaging gateway 25. The transmitted message comprising the updated output specification 100 is decoded in step Q and processed in step R by the sending arrangement as in the other embodiments above.

Of course the inventive method can also be used for defining the output of a locally run application 1. In a further exemplary embodiment of the invention a single PC comprises the sending arrangement 2 and the receiving arrangement 3. In this embodiment the inventive method is used in order to separate the code defining the application logic from the code defining its user interface 16, e.g. using a GUI class library. An exemplary library, which can be used as library

14 of output components 15, is the Java Swing class library.

In this case the Swing class library acts as the library 14 of output components 15, which are provided in form of Swing components like JButtons, JMenus and so on.

Figure 8 shows a GUI window 33 generated from the output specification 100 shown in Figure 2. It comprises a title bar 34 comprising system specific elements, such as the applica- tion name (in the example "Payment Application") and button for closing the window 33 or resizing it. In addition, the window 33 comprises a number of output components 15. In the example these are a text pane 35, a drop-down menu 36 and a push button 37. They correspond to the abstract output ele- ments 8a, 8b and 8c of the output specification 100 respectively. In the example given, they could be implemented using a JTextPane, a JMenu with two JMenuItems and a JButton of the Java Swing library. The JMenuItems correspond to the different options of the "abstract choice" output element 8b, with the currently visible menu item 38 being the current value of the associated input parameter 102 of the abstract output element 8b.

Of course other output components 15 of the same class li- brary 14 could have been used for the generation of the user interface 16. The Java Swing library also provides radio- buttons, i.e. JRadioButtons, which could have been used to implement the "abstract choice" output element 8b. In addition, a completely different class library could have been used. Older versions of the Java Class library, predating the

Swing library, use the Abstract Window Toolkit (AWT) to generate GUIs. A mapping of the abstract output elements 8 to output components 15 of this library can be performed in a similar way as described above. Many other programming languages and environments also provide class libraries 14 with output elements 15 for the construction of GUIs, which can be employed in a similar fashion. A not limiting list of such class libraries comprises the .NET class library, the XWindow class library, the Qt class library, the Tcl/Tk class library and the Motif class library.

Using the inventive method the time-consuming task of defin- ing a GUI for outputting data is avoided and replaced by the automatic generation of concrete output components 15, given, for example, by system specific class libraries 14, from a abstract output specification 100.

List of reference numerals:

1. Application

2. Sending arrangement 3. Receiving arrangement

4. Network

5. Data input

6. Data processing unit

7. Mapping arrangement (of the sending arrangement) 8. Abstract output elements

9. Description language

10. Coding arrangement

11. Symbol

12. Decoding arrangement 13. Mapping arrangement (of the receiving arrangement)

14. Library

15. Output components

16. User interface

17. Output device 18. Automatic voice system

19. Telephone

20. Telephone network

21. Synthesizer

22. Voice recognition system 23. Loudspeaker 24. Microphone

25. Messaging gateway

26. Mobile phone

27. Mobile phone network 28. Sending antenna

29. Messaging arrangement 30. Screen 31. Keyboard 32. Receiving antenna

33. Window

34. Title bar

35. Text pane 36. Drop-down menu 37. Push-button 38. Menu item

100. Output specification

101. Output data 102. Input parameter

A - R Steps of the methods for outputting data

Claims

Claims :

1. A method for outputting data comprising the following steps :

provision (A) of a description language (9) , comprising symbols (11) for the description of abstract output elements (8) for the output of data,

provision (B) of a sending arrangement (2) ,

provision (C) of data to be output,

mapping (D) of output data to abstract output elements (8) ,

coding (E) of abstract output elements (8) to an output specification (100) using symbols- (11) from the description language (9) ,

provision (F) of a receiving arrangement (3) with output components (15) specific to the receiving arrangement (3) ,

transmission (G) of the output specification (100) from the sending arrangement (2) to the receiving arrangement (3) ,

decoding (H) of the output specification (100) into the abstract output elements (8) of the description language (9) through the receiving arrangement (3) ,

mapping (I) of abstract output elements (8) to the output components (15) specific to the receiving arrangement (3) , output (J) of the mapped output components (15) .

2. Method according to claim 1, in which in the step of the provision (A) of a description language (9) , the description language (9) also comprises abstract output elements (8) with an input parameter (102) , and which comprises the additional steps:

provision (K) of input components (24, 31) specific to the receiving arrangement (3) ,

mapping (L) of input components (24, 31) specific to the receiving arrangement (3) to the decoded input parameters (102) of the abstract output elements (8) with an input parameter (102) ,

gathering (M) of input values through the input components (24, 31),

updating (N) of the input parameters (102) using the gathered input values ,

coding (O) of the mapped abstract output elements (8) with an updated input parameter (102) into an updated output specification (100) using symbols (11) from the description language (8) through the receiving arrangement (3) ,

transmission (P) of the updated output specification (100) from the receiving arrangement (3) to the sending arrangement (2),

decoding (Q) of the updated output specification (100) into the abstract language elements (8) with updated input parameters (102) of the description language (9) , processing (R) of the abstract output elements (8) with updated input parameters (102) .

3. Method according to either claim 1 or claim 2, in which the abstract output elements (8) describe the components of an user interface (16) .

4. Method according to one of the claims 1 to 3 , in which the provided receiving arrangement (3) is adapted for output- ting text, and in which the step of mapping (I) of abstract output elements (8) to output components (15) specific to the receiving arrangement (3) , character sequences are mapped to the decoded abstract output elements (8) .

5. Method according to one of the claims 1 to 3 , in which the provided receiving arrangement (3) is adapted for outputting of pages according to the HTML specification, and in which the step of mapping (I) of abstract output elements (8) to output components (15) specific to the receiving arrangement (3) , components according to the HTML specification are mapped to the decoded abstract output elements (8) .

6. Method according to one of the claims 1 to 3, in which the provided receiving arrangement (3) is adapted for outputting of audio signals, and in which the step of mapping (I) of abstract output elements (8) to output components (15) specific to the receiving arrangement (3) , audio signals are mapped to the decoded abstract output elements (8) .

7. Method according to one of the claims 1 to 3 , in which the provided receiving arrangement (3) is adapted for displaying a graphical user interface (33) , and in which the step of mapping (I) of abstract output elements (8) to output components (15) specific to the receiving arrangement (3), graphical components (35, 36, 37, 38) for the composition of a graphical user interface (33) are mapped to the decoded abstract output elements (8) .

8. Method according to claim 7, in which the graphical components for the composition of a graphical user interface (33) are provided through a class library (14) of the receiving arrangement (3) ,

9. Method according to claim 8, in which at least one of the following class libraries (14) is used: Java AWT, Java Swing, .net, XWindow, Qt, Tcl/TK, or Motif.

10. Method according to one of the claims 1 to 9, in which the step of transmission (G) of the output specification (100) a data network and a protocol for network communication is used.

11. Method according to claim 10, in which 'at least one of the following protocols is used: TCP/IP, HTTP, RMI, SOAP, or CORBA.

12. Method according to one of the claims 1 to 11, in which the description language (9) provided is described by a gram- mar, such that the correctness of the transmitted output specification (100) can be verified.

13. Method according to claim 12, in which the description language (9) provided complies with the extensible mark-up language (XML) recommendation and the grammar complies with either the Document Type Definition (DTD) or XML Schema recommendation.

14. Method according to one of the claims 1 to 11, in which the mapping (D) of output data to abstract output elements (8) or the mapping (I) of abstract output elements (8) to output components (15) specific to the receiving arrangement (3) is performed using a scripting language.

15. Method according to claim 14, in which the scripting language is at least one of the following: XSLT, ECMA-Script, JScript, PHP, Perl.

16. Method according to one of the claims 1 to 13, in which the mapping (D) of output data to abstract output elements (8) or the mapping (I) of abstract output elements (8) to output components (15) specific to the receiving arrangement (3) is performed using a programmable hardware device (7, 13) .

17. Method according to claim 16, in which the programmable hardware device (7, 13) comprises at least one of the following components: an ASIC, PAL, GAL, or an FPGA device.

18. Sending arrangement (2), which comprises a description language (9) with symbols (11) for the description of abstract output elements (8) for the outputting of data, a data input (5) for receiving data to be output, a mapping arrangement (7) and a coding arrangement (10),

in which

the mapping arrangement (7) is adapted for the mapping of data to be output received from the data input (5) to abstract output elements (8) of the description language (9) ,

the coding arrangement (10) is adapted for the composition of output specifications (100) comprising symbols (11) of the mapped abstract output elements (8) of the description language (9) , and

the sending arrangement (2) is adapted to transmit composed output specifications (100) to a receiving arrangement (3) .

19. Receiving arrangement (3), which comprises a description language (9) with symbols (11) for the description of abstract output elements (8) for the out- putting of data, a library (14) of output components (15) specific to the receiving arrangement (3) , a decoding arrangement (12) and a mapping arrangement (13) , in which

the receiving arrangement (3) is adapted for the reception of an output specifications (100) comprising symbols (11) of the description language (9) , the decoding arrangement (12) is adapted for a decomposition of the output specifications (100) in abstract output elements (8) of the description language (9) ,

the mapping arrangement (13) is adapted for the mapping of the decoded abstract output elements (8) to the output components (15) of the receiving arrangement (3) , and

the receiving arrangement (3) is equipped for outputting of the mapped output components (15) .

20. System, comprising

- the sending arrangement (2) according to claim 18, - the receiving arrangement (3) according to claim 19, and

- a communication network (4) , which connects the sending arrangement (2) with the receiving arrangement (3) .