SE526532C2 - Procedure, server and computer software product for remote management of Web service workflows - Google Patents

Abstract

A Remote Controlling Manager server, RCM server, positioned in a network and adapted to enable client devices (1) being in asynchronous, wireless communication contact with the RCM server to remotely control and activate workflow based applications in the RCM server, said applications requesting Web service actions from Web services (13) being in synchronous communication contact with the RCM server.

Description

526 532 2 In general, a web service's processing model may be year object (function or procedure) centered or it may be document centered. The object-centered model involves interaction with the client in a dialogue, while the document-centered model is usually used when the client only needs access to dome documents or information. The business object-centered approach is driven by a series of procedural calls. These procedure calls apply the service logic of the service to the data provided in the request. A Web service interaction model expects a client application to call and interact with the Web service. A client's application interaction with a Web service can be synchronous or asynchronous or a combination of both types of communication. When following a synchronous model, the client application typically uses an RPC-oriented interaction. The RPC-oriented (synchronous) and document-oriented (asynchronous) Web services form two ends of a spectrum.

At one end, a Web service can use a fully RPC-oriented interaction model and object-centered processing, in which case the model is an RPC-oriented Web service. At the other end, a service can be completely document-oriented and communicate with asynchronous messages. However, most Web services handle somewhere between these two cases with a mix of models. Although even a fully RFC-oriented Web service uses Simple Object Access Protocol (SOAP), it keeps the use of XML transparent between the client and the server.

The client and server use procedure calls and objects as parameters to those calls. The underlying platform handles XML. An application client can call RFC-oriented Web service (s) in various ways, for example using SOAP, MIME or other http-based protocols. Each call consists mainly of a request and a reply message. This means that the client device must be given a local processing capability that handles application workloads, application dialogs, and Internet protocols that support the synchronous interaction model as described above.

To enable interaction from, for example, a mobile phone with a Web service, the mobile phone can today be charged with software. This can be done directly to the CPU motherboard or in some cases also into the SIM (Subscriber Identification Module) card. There are several solutions on the market today that enable such use. 526 532 Messaging services such as EMS / MMS / SMS are all of an asynchronous nature, which means that the sending party's programs / services continue with their own processing without waiting for a response to a message, i.e. from the other party. In contrast to synchronous messages where the sending program waits for a response to its message before retrieving its own processing.

SIM toolkit and WAP browser application based phones are based on the common request / response paradigm also called message transaction: - A client sends a request (URD message to a server - The server responds with a reply message and - The client blocks (interrupts execution) while it is waiting for the answer.

A programmable mobile phone, such as a Java based phone, on the other hand, will enable more advanced client applications because the client application can act as a run-time component that provides access to queuing services on a server.

A problem with the techniques described above used today is that thin client devices are not given the local application processing capability that enables local management of application workloads, application dialogs and Internet protocols that support the synchronous interaction model as described above. A thin client is a device with limited capacity for local data storage, stand-alone operation and recovery capability for network outages such as standard cellular mobile phones equipped with SMS / EMS / MMS, SIM toolkit or WAP.

An additional problem that exists in these currently available technologies for wireless clients is that application sessions are lost during wireless loan failures or interruptions.

This loses the application state and related input data (ie synchronous connection). Re-entering a service means that the application must be found again and restarted and that all data provided until the lost state occurred must be re-entered. 526 532 An additional problem is that message-oriented clients, such as SMS / EMS / MMS, SIM toolkit, and WAP-enabled types, cannot support a connection to Web services that require a synchronously connected client application.

One problem with today's wireless network client-based application solutions is to write and develop a workflow application that requires many issues to be explicitly addressed individually for each application, such as errors and exception handling and details for Web service calls. Therefore, the developer must spend a lot of time improving the network reliability of each individual application.

An additional problem with today's solutions is that they can be device dependent. It is preferable to be able to run a program that is useful for a large number of client device types.

A problem with a device-dependent application developed for a number of similar but not identical devices is that the devices may differ slightly and therefore a program that works as expected for one type does not work for another similar type. This means that testing, updating and development must be done separately for each device type.

Another limitation for today's client-based solutions is that it is not possible to change the device on the road. A wireless device with running software cannot stop the current application and allow another device to take control of the application.

Thick clients can suffer from long start-up times, which is something that thin clients are generally good at. Because of this, thick clients may not always provide the same real-time experience of connected services.

A device requesting a web service may also suffer from a large amount of data being transmitted over the network. This is because the XML format used for communication is quite complex but also because data to be transferred can be raw data at a low application level. A further problem is also that applications that provide interactive media capability to thin mobile devices today cannot provide parallel media management that enhances the user experience of each dialogue.

SUMMARY An object of the invention is to provide a method and system in which thin, wireless client devices such as simple mobile phones can act as wireless remote controllers which are easy to use to control work-based applications requesting Web services. It is also an object of the invention that the communication from the client device should be asynchronous.

A further object is to provide a remote controller which does not suffer from the problems described above for related technology.

These objects are achieved in a method according to claim 1 and in a server according to claim 8.

This results in a procedure and a server that uses the wireless network bandwidth of clients efficiently because Web services are not dialed from the client itself but rather indirectly through a server. Bandwidth will be saved because client device communication is done at high semantic levels in the system. Furthermore, a user can use asynchronous communication to control a synchronous Web service because the RCM server is an intermediate server that communicates asynchronously with the client device and synchronously with the Web service.

The asynchronous communication between the client device and the RCM server allows the user to interrupt a work fate application session at any time to pick up the latter where it was interrupted, launch other applications or perform other activities without losing the session states.

Furthermore, the work fate application in the RCM server does not depend on any specific client device or type of network that connects the client. Instead, the work fate applications will be possible to use for all client device types that use a specific media gateway connected to the RCM system. This means that device- and network-dependent issues are handled only 526 532 6 times in the media gateways. The work fate applications as they are initiated in the RCM server need not be aware of different device types.

A further object is to provide a method and system where thin client devices such as standard mobile phones have the ability to serve users with navigation dialogs that are common in all client-based workflow-based applications enabling easy navigation in application sessions and among different application sessions and enabling application menus and navigation. This object and preferred embodiments of the invention are achieved by a method and a server according to one or more of the dependent claims.

BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 is a schematic view of a network with a remote control manager according to the invention.

Figure 2 shows a display of a mobile telephone as an example of an embodiment of the invention.

Figure 3 is a schematic view of a remote control server according to the invention.

Figure 4 is a schematic sequence diagram of the process for logging in to a work fate application according to the invention.

Figure 5 is a schematic sequence diagram of the process for a typical transaction of a service according to the invention.

Figure 6 is a schematic sequence diagram for a complete interaction from user to a Web service.

DETAILED DESCRIPTION OF EMBODIMENTS According to the invention, a Remote Control Manager (RCM) server is provided as a communication link between Web services and media gateways supporting client devices registered for the service provided by the RCM service. Using this invention, the Web service client application has been removed from the client device to be accessed and executed in a server environment, the RCM server. In addition, according to the invention, the interaction dialogs against the client device are controlled by the RCM server through a control interface that handles one or more parallel and simultaneously operating media gateways. The user is presented (promptly) with various options and / or instructions and must respond with a data entry or a choice.

This allows the RCM server to perform work fate interactions, supported by various media options in the work fate application dialogs. Thin client devices can connect to the RMC server to use one or more of the Web services that the RCM server can connect to. 'hinna client devices are devices with limited access to local data storage, stand-alone operation and resilience to network outages such as standard mobile phones, equipped with a numeric keypad that supports voice, SMS / EMS / MMS and / or WAP services.

There are two main interfaces from the RCM server to the outside world: towards users and towards Web services. Communication with users is asynchronous while communication with Web services is synluon. This means that the RCM server handles synchronous Web services but allows the user to access them asynchronously. This means that the user does not have to wait for a Web service to be completed before doing anything else. It is always possible for the user to interrupt the ongoing task and do something else.

The RCM server includes work fate applications that request Web service documents. From the client device, the user can control these work fate applications and thereby indirectly request Web service documents.

Input media to the client device to control the work fate applications can be, for example: voice, telephone keypad or a bar code reader. Media to present the options to the user can be, for example: voice, text and Greek in different forms. The only factor that limits the possibility of media interaction will be the types of media gateways that are involved and the possibility of transformation that is made possible in any specific dialogue-supporting media gateway that covers the dialogue presentation or dialogue entry for work fate dialogues. To set up and configure the capacity of each media gateway adjacent to the RCM requires other tools that are not part of the invention. This invention merely demonstrates that a protocol is required between the RMC and the various interaction media gateways. This can be solved in different ways but preferably this connection will be based on common formats that use XML over HTTP. The RCM server communicates with the Web service theme using ote Remote Procedure Calls (RPC).

Figure 1 is a schematic view of a network with a ladder control manager according to the invention. A client device 1, in this example a mobile telephone 1, is shown connected to a network 7, in this case a mobile network. The client device can, for example, instead be a personal computer, a PDA or a laptop. The network 7 can be audience-based networks (covering public areas), such as PLMNs, Public Land Mobile Networks, based on GSM, GPRS or 2G, 2.5G, 3G cellular technologies or WLAN (Wireless LAN) technology types. Network 7 can also be private networks (covering private areas) that use Bluetooth or WLAN based technologies. The networks can be both circuit-switched or TCP / IP-based types. The network 7 is connected to a number of media gateways 5. The media gateways 5 are according to the invention connected to a remote control manager (RCM) server 9. The media gateways 5 are needed for the translation of the communication between the client device and the RCM server.

The purpose of the media gateways is to translate workflow dialogs between the RCM XML based protocol and certain external protocols that may interact with any presentation format or input format supported in the various device types connected to the RCM server. Due to this, the media gateways are device and / or wireless network dependent. The handling capacity of the combination: device, gateway and network must be able to support RCM in real time to ensure a real-time experience for the end user. The RCM concept itself can only involve a minimal adapter function to interact with the various media gateway protocols and / or interfaces. Through this, RCM can support many different device types with the use of the same code. This architecture makes the system easy to adapt to technological changes and the introduction of new mobile devices and protocols.

The RCM extreme media gateways 5, which are not part of this invention, adapt various extreme protocols to a generally and commercially available XML format understood by the RCM server. 526 532 9 For example, voice provided by the client device needs to be translated into a data format in an ASR (Autornatic Speech Recognition) voice media gateway before being forwarded to the RCM server.

Other examples of media gateways that may be needed are: a WAP gateway that communicates with WAP telephones, a MMS (Multimedia Message Service) gateway that communicates with MMS telephones, a SIM toolkit gateway that communicates with telephones that have SIM applications or PDAs, an IM (Instant Messaging) - gateway that communicates with a phone that can IM, a Java gateway that is intended to translate data content into J ava objects or device equipment gateways that handle device claps, pointers, vibrators, alarm signals or other client device accessories . The gateways 5 are connected to the RCM server 9 using an XML-based connection.

In another embodiment of the invention, the gateways can be placed near the RCM server in the network 7 or even in the client devices.

The RCM server 9 is further connected to various Web services 13. The RCM server 9 communicates via RPC, or other http-based protocols that support synchronous communication with the Web services 13. Work fate applications are initiated in the RCM server to perform a dialogue using Web services and client devices. The work fate application dialogs are adapted to the specific media types supported in the client devices 1 by the different gateways.

The client devices can interrupt all functions at any time because they operate asynchronously and the client devices are never locked just to wait for the next work step.

A Web service 13 can, for example, be to remotely control various settings in a house or industrial facility such as heating, alarm, ventilation, etc. It can also be to perform bank transactions, order movie tickets, make phone call settings, make a change of staff profile in a server, or direct a print job to a place to visit. The work fate application is the chain of dialogs needed for the user to be able to control the settings. Usually the user is provided with a list of choices in the client device 1 when the client logs in to the service. Depending on the user input related to these choices, various additional options are provided by the RCM server. 526 532 10 Figure 2 is given as an example of how the dialogue can appear on the client device. In this example, the client device 1 is a mobile telephone 1 with a display 2 1. Figure 2 shows three consecutive display views of the mobile telephone 1. The display changes depending on the inputs from the user as will be described below. The screen 21 is displayed on a larger scale next to the telephone 1. Here the screen 2 1 is divided into a first, a second and a third section 23, 25 and 27, respectively. In the first section 23, various RCM-specific system commands are presented. System commands are commands that can be made from the client device that are not directly related to the Web service but rather related to the navigation in the activated work fate application, between activated or non-activated work fate applications and to manage and navigate in work fate application menus. This can be, for example, interrupting the work cycle and logging out of the application. It can also be to interrupt the work fate application for a while but with the option to take up the latter with retained settings and previous entries or back up the dialog one step to make a different choice. The available system commands are provided from the RCM server associated with the current work fate dialog in the work fate application.

In the first screen view in Figure 2, the system commands presented to the user are "Logout" and "Cancel". The commands are followed here by a number that indicates which number on the client's keypad is to be pressed to give the command. It would also be possible to give the commands through voice commands or a barcode lock. The option to interrupt the session may be desirable if the user wants to change application or is disturbed or needs to do something else and wants to interrupt the workflow and address it later. The second section 25 shows System Messages. In this case, a system message is displayed: "select house number". System messages are mainly used by the RCM server to confirm system commands executed in the RCM server, but can also be used to simplify the workload dialog. The third section 27 shows the different workload menus and workflow processing options.

The user needs to make some kind of input to the client device by typing a parameter or selecting one of the options and thus proceed to the next dialog. The first screen in fi gur 2 presents three different houses, Gräsö, Sälen and Uppsala together with the number of the button to be pressed by the user to select one of the alternatives. So in this example, the client is connected to a service to control different settings in the client's three different houses.

The first step for the client to perform after logging in to the service is thus to choose one of the houses. This selection is then forwarded to the current workload application in the RCM server. The RCM server determines whether a local treatment should be performed by the RCM server where no Web service is involved, or whether it should call the Web service to perform the current operation selected by the user. Additional options can also be provided from the Web service, for example if an invalid choice was given to the Web service. Such scenarios must be anticipated by the work fate application in RCM. So in this case, the Web service initiates the work fate application to display a new dialog for the client, with the same option but with a new system message requesting a re-entry of the selection. When the operation is completed and a session manager in the RCM server has been notified, the work fate application is advanced. Now the next command option forwards the fi initiated in the work fate application as a dialogue to the client device 1 together with some added system commands and system messages. Since all dialogs in the RCM, including the system commands and the system messages, are adapted to the specific media used in the client device in the media gateways 5 located between the ROM server and the client device. Data that may have been received from the Web service is included in the dialogs and is also adapted for the specific media used in the client device in the gateway. This allows the work fate dialog to be displayed in the client device without the need for any specific application in the client device.

After the user of the client device has selected one of the houses, he / she will be shown the second monitor in Figure 2. In this example, the client has selected his / her house in Gräsö by pressing button number four. In the second screen displayed to the user, the system commands are the same with a new possible command added as year "back". This makes it possible for the client to go back to work and choose another house. In the second section 25, information is now simply the chosen house, Grâsö. The third section 27 shows the new options together with the key number to be pressed before selecting one of the options. In this example, the client can choose to turn off the heat, set the indoor temperature, turn off the alarm or unlock the door. When the user selects the indoor temperature by pressing button number 5, the third 526 532 12 screen is displayed in Figure 2. The system message section is used to present a work application message "enter indoor temperature" and the client can use the keypad to set a new indoor temperature. The new temperature input from the client device is forwarded to the RCM server.

The RCM server realizes that this year an operation is to be performed by the Web service and the new temperature is passed on to the Web service performing the operation, ie. sets the new temperature. The RCM server is then informed that the operation has been performed and a new work fate dialog with a system message that says "done" is sent to the client device.

This example was just one of many possible examples. As stated above, there are many possible implementations of this system. The presentation of the dialogues can of course be designed differently and there can be many different media options to present to the user, such as text, voice, graph, vibration or alarm signaling depending on which output media gateways are used and which client interfaces the media gateway can control. In the same way, the input commands from the client device can also be realized with different media options depending on which supporting input media gateways are used, such as voice, keypad, pointer, barcode reader or other pointer-sensitive pen (such as Armoto Pen). In the example in Figure 2 above, only one media was used in each direction, text for dialogue presentation and keypad for dialogue entry. However, the RCM server allows fl your media types to be used at the same time because fl your media gateways can be connected and operate in parallel and manage the client device.

The user can thus be presented with a dialogue with text as shown in Figure 2 and given a voice at the same time and answer with a voice or keypad alternately in relation to what is preferred in each dialogue step.

However, the invention is not limited to any particular service but rather to the composition and function of the RCM server as an intermediate link between any type of Web service and media gateways that support client devices.

Figure 3 is a schematic view of an RCM server according to the invention. It comprises a communication manager 31 which is connected to and uses different media gateway adapters 32 which support the connection to different media gateways which in turn support the client devices. The media gateway adapters are included in the RCM server for 32 years, but the media gateways are located between the RCM server and the client devices. The media gateways shall support media translation and connection to each individual client device. Examples of different media gateways were mentioned above in relation to ñgur 1. The communication manager 31 communicates with the respective media gateway adapters 32, i.e. an adapter for communicating with a voice gateway, an adapter for communicating with a WAP gateway, an adapter for communicating with a browser proxy. or Java gateway, an adapter for communicating with an MMS gateway, an adapter for communicating with an IM gateway, and so on. With this, the communication manager 31 is capable of communicating with different types of client devices and client device accessories that support different user interfaces and input and output media. For example, in an exhaust mode, the communication manager 31 may be designed to receive both voice input and keystrokes from the same client device at the same time.

The communication manager 31 is responsible for user authentication. For this purpose, it is connected to a user information database 41.

Communication manager 31 years further connected to session manager 35.

The session manager 35 is in turn connected to a Web service manager 39 and an authorization manager 33. The web service manager 39 can connect to various Web services when needed.

Session Manager 35 is the heart of the ROM server. The work fate applications are run here as application sessions. Other parts of the system can be seen as helping session managers perform their work. The RCM server is designed to run work-based applications. A work fate application is described as a sequence of alternate dialog steps for each dialog step can perform one or more alternate functional operations put together to support a user case.

The work fate application definitions are described as functions to be performed in each fate dialogue dialog and are stored in a work fate definition database 38.

All the applications that can be run in the RCM server, including the related dialog settings, are stored in the work fate database 38. In session management 35, stacks are built up and kept updated, which represent the latest session status and session history. Session Manager 35 maintains the 526 532 14 work session status for each individual user and each work application application session. This is done for all work fate applications, initiated and not completed. The RCM server can also keep track of all initiated and interrupted work sessions for an extended period of days or weeks for each user. To do this, the active workload session stacks handled by the session manager are moved from the real-time memory to the long-term storage memory each time the system interrupts a particular user. The long-term storage memory in the RCM server is defined by the session database 37. This allows the client to interrupt an ongoing session and retrieve it later. The session manager 35 keeps track of where the work session session was interrupted and all previous entries from the client device. Even if the interruption in the dialogue was unintentional, such as in the case of poor radio coverage, the dialogue can continue later where it left off. Furthermore, the stored sessions allow the client to back up the dialog one or more steps to change a previous selection. Session Manager 35 also enables the user to save executed workloads as templates including default actions for dialogs. The templates for the different workloads are stored in the session database 37 which is connected to the session manager 35.

For example, a user may want to save a money transfer session if he often transfers the same amount of money to the same account. However, all values in the template are only suggestions when the template is used. The user can change all entries when the template is used or just accept the preset suggestions.

The session manager 35 also controls the timeout logic of the different operating modes separately for each individual user. This means that RCM can use different modes of operation against different client devices. For example, if a client device has not entered any inputs for a predetermined time, the processes used in a particular user session in the RCM server and the related gateways may step by step go back to their operation on the client and thus save resources for other clients. However, since all sessions and previous entries are stored so that the session manager 35 can use them, the user can enter the session whenever he / she wants without having to start again from the beginning. However, for security reasons, the RCM may request a new login from the client device when it re-enters after a predetermined period of inactivity.

Web Services Manager 39 is the interface to Web Services. It retrieves data from the Web services and it forwards the choices made by the user when they involve the Web service. The communication between session manager 35 and the Web services via Web service manager 39 is synchronous. The session manager 35 is further connected to a work fate database 38 which defines the total base of work fate applications available to the users. If the RCM server itself is implemented in J ava code, the applications may also be Java-based. The Java-based workflow applications will then be represented as Java classes in the workflow extension database 38. Furthermore, the session manager can add system commands and system messages as discussed above in relation to Figure 2. These system commands and system messages are associated with respective application work's step steps and transmitted the client device.

Session manager 35 is also connected to authorization manager 33 to authorize and verify that a certain user is allowed to enter and execute a requested workload application.

The authorization manager 33 is connected to a user information database 41 which includes user information such as user ID, related authentication parameters, which application the user is authorized to use and various personal user settings regarding selection and behavior of media gateways. Although the RCM server needs all of these parts as described above, the different parts can of course be separated and placed in different servers. This is only an architectural issue and does not affect the acquisition. From now on, the term "ROM server" used will also include the possibility that the functional parts are located in different physical servers.

Figure 4 is a schematic sequence diagram showing the process of logging into an RCM server from a client device according to the invention. The events are represented by arrows starting from above: 526 532 16 l. A login request is sent from the client via the media gateways 5 and the gateway adapters 32 to the communication manager 3 l in the RCM server.

Login request can be a request to go back into an existing interrupted session or start a new session. Communication manager 3 1 takes care of authentication of the user if necessary, whereby the user authentication parameter entry is controlled by checking in the user information database 41. The authentication can be done in a number of ways, for example by using a PIN code together with telephone ID number or subscription number. 2. The communication manager 3 1 sends an object representing the iriloggriirrig request to session manager 35. 3. Session manager 35 responds with an object representing the last ongoing dialog for an interrupted work fate or the top level in the work fate menu if the request is to start a new session. 4. The communication manager 3 1 responds to the client that the login was successful or failed.

Session Manager 35 is now responsible for presenting all new work fate dialogues to the client. The client is now in service mode for the RCM server. A new dialog can now be retrieved by the session manager from the work fate database 38. Usually, the session manager 35 will present a new work fate dialog immediately when a user has entered some data or selected one of the options. For some work fate applications, special system messages or application messages may be de- nated to support navigation in the work fate application.

Figure 5 is a schematic sequence diagram of the process for a typical transaction of a service according to an embodiment of the invention. The events are illustrated with arrows starting from above. The events are described in order: 1. First, an incoming message is sent from the client device via the media gateway and the gateway adapter, to the communication manager. This message includes information about which input the end user has given, more specifically which command or data entry has been given. 526 532 17 2. After the communication manager has received and verified the user, the message given as an object in XML format is forwarded to session manager 35. 3. Session manager needs to know if the user is authorized to use the requested work application and therefore the authorization manager 33 is called for to determine this. 4. The authorization manager returns a response to the session manager which tells whether the user is allowed to use the work arbets application application or not. 5. If it is so defined in the work fate database 38 for the current work fate a Web service 13 is called and for this task the Web service manager 39 is used. Web service manager is given an object from session manager which tells which Web service to called and with which parameters. 6. A result is returned from the Web service through the Web service manager to the session manager. The result can be a message that a certain action has been performed by the Web service and / or a response that triggers the current work step in the session manager. The work fate application as they are generated in the work destiny database 38 must be designed to handle all possible Web service response options. 7. A new dialog that may include the result retrieved from the Web service and / or new options and messages as defined in the work fate database 38 is sent from the session manager to the communication manager. An XML message representing the new dialog is sent from the communication manager to the client device through said media gateway (s) using the corresponding gateway adapters).

Figure 6 is a sequence diagram showing the complete interaction of the entire wave of users to the Web service. This example uses a voice media gateway.

The chain of systems from user to Web service is: client device 1, voice XML browser that acts as media gateway 5, RCM gateway adapter 32, RCM server excluding adapter function, Web service 13. The work fate application used in this specific example enables adjustment of a specific temperature. l. First, the user gives a command using voice. This can be, for example, the word "twenty" if the user wants to set a temperature to 20 degrees. 526 532 18 2. The media gateway (voice XML browser) will interpret the audio input to the integer 20. 3. The value is sent using voice XML to the gateway adapter. 4. The gateway adapter adapts the voice XML format to the internal XML format used in the RCM server. 5. The internal XML format is sent to the communication manager in the RCM server. 6. The RCM server receives the dialog entry from the user and then executes the work fate application used by the user. In this case, the input from the user requires an action from a Web service, namely to set the temperature. Therefore, the relevant Web service is called. 7. The Web service is dialed using Web service manager to forward the temperature value received from the user formatted as an RPC / SOAP request. 8. A result is returned from the Web service. In this case, "OK" is transferred as a receipt that the action has been performed. 9. Some finishing will be done by the work fate application in the RCM server.

This will result in another dialog to be displayed to the user telling them that the operation was successful. 10. A message in the internal XML format is sent to the gateway adapter, which represents the dialog to be displayed to the user. 11. The internal XML format is translated into voice XML in the gateway adapter. 12. The voice XML message is sent to the media gateway. 13. The media gateway (voice XML browser) will generate artificial speech to present the dialog to the user. 14. The speech is transmitted as a voice over the mobile telephone network. 15. The voice is played to the user of the client device.

According to the invention, the RCM server can adopt different modes of operation depending on the status of the sessions. "On state" for the server is when a client connected to the service has logged on and a session has started against the client. "Off-state" is when the client has logged out, the session is over and no settings and inputs to the service are stored in the server. Furthermore, the server may assume an "interrupted state".

This occurs, for example, when the client becomes disturbed or needs to do something armed and wants to interrupt the service action and take up the latter. It can also be a server-initiated interruption, initiated by, for example, time-out, which enables the server 526 532 19 to allocate system resources to other clients. Furthermore, there may be a temporary interruption in the connection between the client and the server, for example if the client moves outside the coverage area. There are two main reasons why the RCM system times out. The time-out parameters are set to minimize a maximum period of inactivity in specific processes. One is to save limited system resources that other users may want to use when they are free. The second reason is that some clients are given higher priority than others and should be given resources In this "interrupted state", session manager 33 in the RCM server retains all session data as previous entries from the client in a memory or in the session database 37. When the session is resumed, for example when the client enters the coverage area again, the session can continue where it left off.In one embodiment of the recovery, there are two different types of interrupted states.An interrupted state where all login data is retained and the client does not have to log in again, preferably only if the client resumes the session within a predetermined Another type of interrupted session is when the client needs to log in again when he / she resumes the session. After an interruption, the user may be presented with an option presented as a speed dial in a menu for the user to use to resume where the actions were interrupted displayed with a speed dial indication in the menu provided as a dialog to the client device.

If communication with the client device is interrupted for a short period of time, for example if the client device moves through a tunnel, the application should keep a session in progress and will not ask for a re-entry of the application. The perceived functionality of the application will then be that the contact has never been interrupted or disturbed.

With a system according to the invention, it is possible to design the server so that it guarantees a certain QoS (Quality of Service = service quality) to the clients. The server is then designed to take care of a distributed set of clients. These clients will always be served, but when other clients are also served and the server is running out of resources, these other clients' sessions are interrupted so that the original clients always receive their service. By providing different timeout settings for the operating conditions to different clients in the RCM server, the activity of the different media gateways can be controlled. Through this, a QoS 526 552 functionality can be provided that involves both the media gateways and the RCM-SCIVCITI.

For some services, it would be beneficial to keep templates in the server. This means that given entries are stored for later use. This means that the client does not have to enter all the data every time the same type of session is started. The templates are stored in the session database 37 accessible by the session manager 35. Examples of workload applications where templates are useful are banking services where different account numbers can be saved or pro-sets in a server that handles redirection of letters or telephone calls.

An advantage of the invention is further that the client is not occupied or blocked during the work fate application execution, i.e. asynchronous communication. This enables the user to continue with whatever he / she wants to do in the meantime, eg navigate in a work fate application (backwards, forwards, cancel etc), navigate between the work fate applications (select and enter a new application, change between background / forward application operation ) or manipulate and navigate the application menu using the system commands. Furthermore, as mentioned above, the client has the option to interrupt the current session and return to the latter with all inputs and settings saved. This is possible because Session Manager retains all information about ongoing and interrupted Sessions.

An additional feature of the system according to the invention is that it is possible to change the communication state (change of something and / or media gateway) in the middle of a session without having to restart the session and log in again. For example, the user may want to switch from a screen / keypad-based user interface to a voice-based one when entering a car. The user can also change from a voice-based interface to a monitor / keypad interface when sitting down on a train or in an office. This is possible because the RCM server provides different types of adapters that enable dialogue communication with different types of media gateways. Which communication network to handle is entirely a matter between the client and the media gateway and does not involve the RCM server. It must also be possible to use two types of communication media at the same time as well as to use certain types of media for input and other types of media for output. 526 532 21 For example, a weather forecast can be requested by voice and delivered by MMS or so a voice letter can be sent via a keystroke command and delivered to the headphones.

An additional feature of the RCM server is a menu system that enables a hierarchical classification and storage of application names that represent all the different workload applications. The menu structure is a advanced application in RCM management. Its structure provides a hierarchical classification of services where the top level is the basis and the service input level to the RCM server.

The depth of the different branches of the menu structure may vary, but the bottom level, the blade, for each branch is always represented by a work fate application.

The menu application is handled by dialogs like all other work fate applications. In the dialog, each level is displayed as an option of work fate classes to select presented in the same way as work fate treatment options are displayed. A specific level in the menu hierarchy can be reached using successive dialogues that go up, down or horizontally in the menu structure.

An additional feature of the RCM server is the system commands that are to support each work ations application dialog. The system commands made available in each dialog are denoted in the work fate (application) denomination database. There are different classes of system commands; session navigation, inter-session navigation, manipulation and menu navigation and some other general types of work. Examples of some system commands are: Intra-session: o Back. Go to previous dialog in workflow 0 Forward. Go to the dialog that has previously been backed from. o End work fate application. This will delete all work objects for the current application.

Inter-session: 526 532 22 0 New session (current session remains inactive) 0 Re-entry. Changes to another existing session (current session remains inactive) 0 End current session. Another session will resume if any. If no work fate application sessions remain, only the menu management session will remain.

Others: 0 Refresh. Request an update of the dialogue presentation or present. 0 Top level. Go to the top level for dialogs o Change menu structures 0 Settings. Go to personal settings 0 Log out The system commands that were defined for each dialogue included during the development of the work fate application can be answered and activated at any time during an ongoing dialogue.

The method according to the invention is implemented by means of a computer program product comprising software code means for performing the steps of the method as described above. The computer program product is implemented in the RCM server according to the invention. The computer program is loaded directly or from a computer usable medium, such as a floppy disk, a CD, Internet, etc.

The present invention is not limited to the preferred embodiments described above. Various alternatives, modifications and equivalents can be used.

Therefore, the embodiments described above should not be construed as limiting the scope of the invention as defined by the appended claims.

Claims (15)

526 532 23 REQUIREMENTS A method for remote control and remote activation of work fate applications from client devices (1) through a wireless communication network (7) wherein said work fate applications request Web service documents, the method comprising the steps of: - providing a server control server, RCM, RCM, , in the network as an intermediate communication link between the Web service themes and the client devices (1), said RCM server running said work application applications; - requesting a work fate application from a client device (1), receiving said request in the RCM server (9) and thereby starting a work fate session for the requested work fate application in the RCM server; - present work fate dialogs de nied in the RCM server (9) for this work fate application for the client device (1) from the RCM server (9) and receive in the RCM server (9) inputs from the client device (1) in response to the presented work fate dialogs, wherein inputs will advance the application work fl session in the ROM server, this communication between the RCM server (9) and the client device (1) being asynchronous; - adapting at least one media gateway (5) provided between the RCM server (9) and the client device (1) the working dialogs presented from the RCM server to the client device and the inputs from the client device to media supported in the client device and the RCM server, respectively; - possibly forwarding said inputs to the Web service in order for the Web service to act according to the inputs, whereby communication between the RCM server and the Web service is synchronous. The method of claim 1 comprising adapting the work fate dialogs presented from the RCM server to the client device and the inputs worded from the client device into more than one media gateway simultaneously so that more than one media can be supported simultaneously in the client device. Method according to claim 1 or 2, characterized in that the client devices (1) can be thin clients that perform little or no data processing themselves. A method according to any one of the preceding claims, comprising storing each step for non-closed and ongoing work fl application sessions and inputs from the client devices (1) in a session manager (35) in the RCM server (9) and thereby providing the client the option to back one or more fl your steps in the session or interrupt a session consciously or unconsciously and re-enter the session in the same state as when it was interrupted. A method according to any one of the preceding claims, comprising interrupting a user session from the RCM server after a predetermined period of time without activity from the client device has expired and thereby releasing resources for other users. Method according to one of the preceding claims, characterized in that the RCM server attaches to the work fate dialogs sent to the client device system commands for the user to use to navigate the work fate session, to interrupt a session and to navigate between different requested applications. A method according to any one of the preceding claims, comprising requesting and managing more than one work-based application from a client device (1) at the same time. A remote control manager server, RCM server, Remote Controlling Manager server, located in a network and intended to enable client devices (1) that are in asynchronous, wireless communication contact with the RCM server to remotely control and activate work-based applications in the RCM server, wherein said applications request Web service documents from Web services (13) which are in synchronous communication with the RCM server comprising: - a communication manager (31) adapted to receive a request from a client device (1) to control a work-based application and thereby starting an application work fate session for the requested application in the RCM server, said communication manager (31) being further adapted to present work fate dialogs denoted in the RCM server (9) for this work fate application for the client device (1) and receive client input (1). response to the presented work fl dialogue dialogues, whereby the said inm applications for the application work session in the RCM server (9) forward, the communication between the RCM server and the client device being asynchronous and performed by at least one media gateway (3) which adapts the work fate dialogs and inputs to media supported in the client device (1) and the RCM server, respectively. ; and - a session manager connected to the communication manager (3 1) and adapted to process said inputs from the client device and present the client a new work d dialog and / or forward said entries to a Web service manager (39) adapted to forward said inputs to the Web service so that the Web service can act according to the inputs, the communication between the RCM server and the Web service being synchronous. Server according to claim 8, wherein the communication manager (3 1) is adapted to communicate with so-called thin client devices (1), i.e. devices that perform little or no data processing themselves. Server according to any one of claims 8-9, characterized in that the communication manager (31) is adapted to receive and forward work fate dialogues and responses from the client to and from more than one media gateway simultaneously so that more than one media can be supported simultaneously in the client device. A server according to any one of claims 8-10, wherein the session manager (35) is adapted to store each step in activated and non-closed work session sessions and inputs from the client devices (1) and thereby provide the client with the ability to back up one or more of your steps. in the session or interrupt a session consciously or unconsciously and re-enter the session in the same state as when it was interrupted. 526 532 26 Server according to any one of claims 8-11, characterized in that the session manager (39) is adapted to attach to the work fl dialogs sent to the client device system commands for the user to use to navigate the work ession session to interrupt a session and also to navigate between different requests. applications. A server according to any one of claims 8 to 12, characterized in that it further comprises an authorization manager (33) adapted to authorize the client in the RCM server before the client has access to the requested workflow-based applications. A computer program product that is directly loadable in the internal memory of a processing means in an RCM server according to any one of claims 8-13 comprising the software code means for performing the method steps performed in the RCM server as described in any one of claims 1-7. A computer program product stored on a data usable medium comprising readable program for causing a process means in a server according to any one of claims 8 to 13 to control an execution of the method steps performed in the RCM server as described in any one of claims 1 to 7.