HK1172470B - A method and arrangement for managing persistent rich internet applications - Google Patents

Description

Method and apparatus for managing persistent rich internet applications

Technical Field

The present invention relates to a method for managing and supporting persistent rich internet applications and to a device adapted to enable a background process to gain access to such applications.

Background

Today, many applications are largely entirely Web-based and, therefore, accessible from any user device provided with Web browser and internet access functionality. This type of application is commonly referred to as a Rich Internet Application (RIA) and provides its users with several important benefits over what is expected to be available from traditional native applications.

Users using RIA no longer have to be concerned with installing applications or manually keeping software up to date, because the RIA is loaded from a Web server every time it is started, rather than installed locally. From the developer's perspective, the development costs associated with RIA can be cut down dramatically, as the development and deployment of RIA is typically less complex than the corresponding native applications. Furthermore, RIAs are important from a commercial perspective, as they enable companies to quickly acquire a large number of users.

Development from native applications to RIA can also be seen as a paradigm (paradigm) migration from "software as artifact" to "software as a service". Due to this paradigm shift, the internet will become a globally distributed operating system. The RIA process may be fully distributed, rather than having native applications run locally in the user device, where some applications are running on the user device and others may instead run in the network. Users may access services from a number of different types of user devices, where mobile user devices become one of many possible network entry points.

The mobile user device industry is experiencing a migration towards a paradigm of open user devices, i.e., user devices that have many commonalities with traditional desktop computers, which enables users to install new application versions and customize their user devices entirely according to their personal preferences. Most user devices will also be provided with desktop-like Web browsers in the near future, i.e. Web browsers that enable users to browse the Web and obtain almost the same user experience as if using a classical desktop computer. A very likely result would likely be that RIA running on such user devices would become an even more attractive alternative for many developers, as many users can be reached at reduced development costs.

Clearly, Web browsers are a key component of Web evolution. Recent developments in Web browser technology, commonly referred to as JavaScript interpreters and JavaScript frameworks, allow applications to run much faster, or even without a fully functional internet connection. However, the Web browsers available today cannot be viewed as constituting a fully mature runtime environment because it places several constraints on the applications. For example, once a Web browser or tab/window has closed, the RIA cannot continue to run in the background of another application.

Another problem with Web browsers available today is that they are not fully integrated on the desktop, which means that even if it is possible to set an icon associated with a particular Web service, defining a RIA on the desktop, such as a mail service, this service will not be able to notify the user when receiving new mail, since only the RIA will run when it is opened in the Web browser.

Disclosure of Invention

The object of the present invention is to solve the problems outlined above. In particular, it is an object of the present invention to provide a mechanism that enables initiation and resumption of communication between a background process residing on an application execution server and a rich internet application residing on an internet enabled user device.

According to an aspect, an application execution server is provided, adapted to manage a background process associated with a rich internet application executable on an internet enabled user device. The application execution server comprises a background process manager adapted to create a background process in response to receiving a request for such a process from the rich internet application. The background process residing on the background process manager is adapted to recognize a triggered event associated with the associated rich internet application and to invoke the rich internet application regardless of whether the Web browser and/or the rich internet application are in an open or closed state, i.e. whether they are running or not. Thus, whenever a triggered event causes a need to communicate with a rich internet application, the rich internet application may be accessed from an associated background process.

The background process manager is generally adapted to create a background process by obtaining executable code, e.g. from a service, according to a received request, and to execute such code accordingly. The background process manager may be adapted to identify a server, such as a third party server, for example by extracting a URL indicating the required server location from the received request.

A background process manager, which is generally adapted to enable interaction between a background process and an associated rich internet application, may be provided with a dedicated server network functionality adapted to enable communication between the background process and the associated rich internet application by supporting a persistent communication channel.

The proposed application execution server may be configured as an integrated part of the internet enabled user device or as a separate network entity accessible to the internet enabled user device. The former alternative may be preferred even when access to the network is not possible, for example if access to an application is required, whereas the latter alternative may be preferred in case battery consumption is a critical issue.

According to another aspect, an internet enabled user device adapted to enable communication between a background process and an associated rich internet application residing on an application execution server is provided. Such internet enabled user devices comprise a functional entity and a user interface which may be referred to as a persistent rich internet application manager. The persistent rich internet application manager is adapted to request creation of a background process at the application execution server and setting of an associated persistent artifact on the user interface. The persistent rich internet application manager is further adapted to support communication between the running background process and the associated persistent artifact, regardless of whether the Web browser and/or the rich internet application is running.

The persistent rich internet application manager is generally adapted to receive a request to initiate a background process from a rich internet application and/or from a Web browser.

Furthermore, the persistent rich internet application manager may be provided with a dedicated client network function adapted to enable persistent communication between the rich internet application and the associated background process by providing a persistent communication channel between the persistent rich internet application manager and the application execution server. Such a persistent communication channel may be based on, for example, a remote procedure call mechanism or a representational state transfer mechanism.

The persistent rich internet application manager generally comprises logic adapted to perform one or more functions in accordance with instructions associated with the rich internet application. Such instructions may be provided from the associated background process to the persistent rich internet application manager via the persistent communication channel and may include instructions on how to obtain executable code associated with the particular background process.

In addition to being adapted to interact with the background process and the associated rich internet application, the persistent rich internet application manager may be adapted to interact with one or more device interfaces of the internet enabled user device in accordance with instructions provided from the background process. The persistent rich internet application manager and the background process may access one or more internal functions of the internet enabled user device via the device interface.

The proposed internet enabled user device may be a fixed user device, such as a PC, or a wireless user device, such as a laptop, PDA or mobile phone. According to yet another aspect, there is also provided a method for managing a background process associated with a rich internet application being executed on an internet enabled user device. According to this method, a background process is created by executing instructions according to a request for the background process received from a rich internet application running on an internet enabled user device. The background process is adapted to recognize a triggered event associated with the associated rich internet application, invoking the rich internet application, irrespective of whether the Web browser and/or the rich internet application is running or not.

The method may comprise the further steps of: receiving a notification request from a background application requesting a notification associated with a rich internet application, wherein the request is triggered by the event; and transmitting a notification request to the internet-enabled user device, thereby enabling notification of the event at the internet-enabled user device.

According to yet another aspect, a method is provided for enabling communication between a rich internet application accessible from an internet enabled user device and an associated background process residing on an application execution server. The method of applying on an internet enabled user device comprising a persistent rich internet application manager and a user interface is initiated upon receiving a request to create a background process from a rich internet application. In response to receiving such a request, an associated perceptible artifact is set on the user interface, and in accordance with the request, the application execution server is requested to create a background process. Once the background process has been created, the internet enabled user device is adapted to manage communication between the background process and the perceptible artifact in response to receiving a notification from the background process, irrespective of whether the Web browser and/or the rich internet application is running.

The mentioned method may comprise further steps: receiving a message including a notification from an application execution server; notify the rich internet application; and supporting communication between the persistent rich internet application manager and the rich internet application according to predefined instructions if the notification is approved via the perceptible artifact. According to yet another method step, the internet enabled user device may process messages communicated between the background process and the device interface of the internet enabled user device, thereby enabling background process access to the device interface and thus also to sensors or functions implemented on the device interface.

Additional features of the invention and its benefits will be understood from the detailed description below.

Drawings

The invention will be described in more detail below by way of exemplary embodiments and with reference to the accompanying drawings, in which:

fig. 1 is an illustration of a block diagram including an internet enabled user device and an application execution server adapted for using persistent rich internet applications, according to an exemplary embodiment.

Fig. 2a is a simplified illustration of a background process and an associated persistent rich internet application.

Fig. 2b is a simplified illustration of a persistent rich internet application.

Fig. 3 is a more detailed illustration of the block diagram of fig. 1 according to an exemplary embodiment.

Fig. 4 is a simplified signaling scheme illustrating a procedure for creating a background process and thus for setting up a persistent rich internet application according to an exemplary embodiment.

Fig. 5 is a simplified signaling scheme illustrating a procedure for terminating a background process and a persistent rich internet application according to an exemplary embodiment.

Figure 6a is a simplified signaling scheme illustrating a procedure for notifying a user of events associated with a background process according to an exemplary embodiment.

Fig. 6b is a simplified signaling scheme illustrating a procedure for enabling interaction between a persistent rich internet application and a background process according to an exemplary embodiment.

Fig. 6c is a simplified signaling scheme illustrating another procedure for enabling interaction between a persistent rich internet application and a background process according to another exemplary embodiment.

Fig. 7a is a simplified flowchart illustrating method steps to be performed at an internet enabled user device for setting a persistent rich internet application, according to an embodiment.

Fig. 7b is a simplified flowchart illustrating method steps to be performed at an internet enabled user device for handling notifications, according to an embodiment.

Fig. 7c is a simplified flowchart illustrating method steps to be performed at an internet enabled user device for terminating a background process, according to an embodiment.

Fig. 8a is a simplified flowchart illustrating method steps to be performed at an application execution server for creating a background process, according to one embodiment.

Fig. 8b is a simplified flowchart illustrating method steps to be performed at the application execution server for handling notifications from the background process, according to one embodiment.

Fig. 8c is a simplified flowchart illustrating method steps for terminating a background process to be performed at an application execution server according to one embodiment.

Detailed Description

The general idea behind the claimed invention is to enhance the user experience for users when browsing Web applications, or more specifically for users using RIA running on internet enabled user devices, by enabling a dedicated background process to run in the background of, but separate from, an associated host Web browser process (i.e. a certain RIA), so that the process can invoke the RIA irrespective of whether the corresponding RIA is running or not. This means that even if the associated RIA has terminated, i.e. the Web browser tab of the RIA has been deleted, and/or the complete Web browser has been closed, the initiated background process will continue to run until it itself also actively terminates, while being able to prompt the user for a triggered event, so that after being prompted for an event, the user can choose to invoke the closed RIA again.

In the context shown, RIA is to be understood in its broadest sense as disclosing any kind of dynamic Web-based application that can run on an internet-enabled user device.

As is well established in the context of executable applications, a process can refer to a computer program product residing on at least one core and may be made up of one or more executable objects, each residing in one or more threads, where each thread is executed in sequence by an entity comprising conventional computer system functionality, capable of running several computer programs simultaneously. In the case of a multi-core system, different threads may execute in parallel.

In the context shown, a background process refers to a process that is launched from a RIA via a host Web browser process, but which once launched can run independently of the host process in a separate runtime environment outside the Web browser, yet from the developer's perspective, still be perceived as a logical process running inside the Web browser. In this context, we can also refer to such background processes as application scope.

The background process will be able to actively monitor the activity associated with the associated RIA and communicate with the RIA, and optionally also other functional entities of the internet enabled user device, e.g. via the device interface.

The background process may have been configured to invoke the associated RIA for a number of reasons. One reason, for example, may be that users who update through them have requested a background process to accomplish such tasks whenever certain changes or events may occur. Another reason for invoking a RIA may be related to invoking a control or service invitation, where, for example, the user is invited to participate in a collaborative Web service, or in response to entering a telephony RIA or entering an instant messaging RIA. Such background processes can remain running regardless of whether the Web browser and/or associated RIA are closed or left open in accordance with the claimed invention.

To illustrate the above concept, two typical use cases will now be given below.

In a first use case, user bill browses the Web from the user device and finally selects the Web application (RIA) he finds interesting. The application is a sports webpage that displays the latest NHL results in real time on the user device. The Web application provides the bill with the option of adding icons of a particular type to the control panel (dashboard) of the user device simply by prompting the user with an appropriate dialog associated with the selectable button. Bill likes the extension of the current application's offering and activates the yes button provided in the dialog, which initiates the installation of the enhanced Web application and the new icon associated with the enhanced application is displayed on the dashboard. Bill then closes the Web application and continues browsing the internet. For a while, the icon just introduced changes appearance, displaying a small star in the upper left corner of the dashboard. Bill notices the modification of the icon and realises excitingly that something related to the enhanced Web application has occurred, he clicks the icon without hesitation and thus starts the closed Web application again in the Web browser. Beer can now see on the dashboard that his favorite team has scored and now leads the opponent.

According to another example use case, which in turn relates to voice over internet protocol (VoIP) applications, a user browsing the Web ends up on a WebVoIP application that he finds interesting. Peter activates the button displayed on the display screen of his user device and thus causes the selected application to persist. An icon in the form of a conventional fixed telephone is displayed on the display screen. Once he has fully entered his credentials, such as username and password, via the dialog displayed on the display screen, peter closes the Web browser and continues his internet browsing. He also knows that his closest friend knows his username that is valid for the VoIP service. Later, peter notices that the phone icon on the display is changing color and the user device's speaker is ringing. Peter's response is to activate the phone icon and the VoIP application starts in the Web browser. Peter noticed that his friend bill called him, his response was to activate the "answer" button displayed in the Web application, and now started talking with his friend.

Typically, the background process will be managed and maintained running until it is actively terminated from the internet-enabled user device that originally created it, or the tasks that have been specified for it have been successfully completed. Alternatively, the background process may be terminated by the background process manager when it finds suspicious or harmful code.

The RIA together with the associated background processes that have been set to operate according to the proposed mechanism constitute a new persistent application concept, which can be referred to as Persistent Rich Internet Applications (PRIA). Each PRIA will consist of two entities, namely a presentation entity located at the internet enabled user device and a background process entity that is performing a specific task associated with the PRIA. This type of representation entity can be realized by applying the perceptual article of manufacture (PA) concept. The PA concept, which enables the user to be prompted, typically via a visual or sound experience, thus constitutes a link between the background process and the associated RIA, which enables the background process to invoke the RIA. A PA is a dynamically represented entity that may generally have been configured such that it is able to alter its appearance, for example by altering size, color, and/or shape.

Each background process will be associated with a PA that will be accessible via the User Interface (UI) of the internet-enabled user device. The PA concept allows a user to easily maintain control of an active background process, terminate the background process whenever required and allow the background process to interact with the user, for example by modifying an associated PA and to interact with processes of an internet enabled user device. In other words, the PA can be seen as an event that is used by the background process to notify or prompt the internet-enabled user device of a triggered activity associated with a particular RIA (now constituting a PRIA) to subsequently determine by the user whether he is to continue processing notifications.

Once the user is prompted, he may choose to continue by activating the PA, thereby instructing the persistent rich internet application manager to continue the initiated process according to the corresponding instructions of the respective background process.

An exemplary system architecture suitable for providing the rich background process concept described above will now be described in more detail with reference to FIG. 1.

It is to be understood that the figures of this document only describe exemplary embodiments, where the defined functional units are to be referred to as logical units, while other units that are generally relevant in the context but are not necessary for understanding the proposed mechanism may have been omitted for the sake of brevity. The internet enabled user device depicted in fig. 1, for example, also typically does include conventional communication components necessary to enable the user device to communicate with the internet and external network servers.

The claimed invention is basically based on a functional entity residing on an internet enabled user device and configured to manage the initiation and termination of PRIA and to handle communication steps associated with PRIA. This entity, referred to as the PRIA manager from below, interacts with another conventional entity adapted to manage one or more background processes. The latter entity will be referred to as an application execution server from below.

For each PRIA, a separate background process is started and managed at the application execution server. To this end, a functional entity, which will be referred to as background process manager from below, is provided on the application execution server. The background process manager is configured to obtain some executable code, such as Flash, JavaScript, Java, Flash or HTML, that has been pre-configured for the associated RIA in response to receiving a request for a new background process from the PRIA manager. To be able to create the correct background process, such a request may typically include an instruction, such as a URL, indicating where to retrieve the appropriate code, i.e. from where the code can be downloaded.

Fig. 1 is a diagram of an internet-enabled user device 100 configured to access a RIA on the internet, i.e. a user device provided with a Web browser 102. The Web browser 102 allows a user to access and browse the RIA in a conventional manner. The internet-enabled user device 100 of fig. 1 also includes a UI101, which may be a graphical UI such as a desktop or dashboard, an audio-based UI, or any other type of UI that enables application of a selected type of PA.

Even though the UI may be generally configured as a visual UI, where the PA is an icon or widget, neither the UI nor the PA is limited to such a solution. The UI may be, for example, an audio-based UI, where the user is prompted by sound, or even the user may be able to respond to such prompts or triggers by interacting with the PA using sound.

Alternatively, the PA may rely on a combination of visual and sound effects.

The user can be prompted from the background process via the notification and access and respond to PRIA via an associated PA (PA1-PAn) that will be displayed on the UI101 of the internet enabled user device 100 when PRIA is installed. In a typical scenario, the UI101 will also display conventional icons (icon 1-icon m), for example, icons associated with native applications when the graphical UI is applied.

The application execution server 150 may be configured as an integrated part of the internet enabled user device 100 or as a separate entity located somewhere in the communication network. If the PRIA is to be run even when access to the communication network is not possible, or for some reason is not desired, an application execution server that is part of the internet enabled user device may be a preferred choice, whereas in many other cases, but especially where battery consumption of the internet enabled user device is a critical issue, an application execution server implemented in a communication network node may be a preferred alternative.

One or more PRIAs may be launched from one or more RIA's, typically by providing the user with the option to create a PA that has been predefined for a particular task. Due to its dynamic nature and its difference from conventional icons, a PA implemented as an icon may also be referred to as a live icon (LiveIcon).

Each PA (PA1-PAn) will map to a respective background process (background process 1-background process n) residing on the application execution server 150, such that, for example, PA1 maps to background process 1.

The user via the PA will be able to easily create, control and terminate the associated background processes. The background process may be created by a user in response to a dialog prompting the user. Such a dialog will typically be initiated by a corresponding RIA, wherein the user is asked whether he wishes to start a certain PRIA. Such dialogs can be executed directly from RIA103 using a Web application API, such as the javascript API, or via a dedicated function provided by Web browser 102, similar to the mechanism applied when adding bookmarks, which is a functionality available today in all conventional Web browsers. Alternatively, the background process may be created automatically in response to some trigger implemented in the processing code of the RIA.

An exemplary scenario describing the background process that may be created if via the Web browser 102 is given in more detail below, with reference now to fig. 2 a.

The activation of the PA1 by a user browsing RIA initiates a certain PRIA, PRIA1, which means that in addition to activating the PA1 on the UI101 of the internet enabled user device 100, a background process 1 is created at the application execution server 150. According to fig. 2a, this may be displayed by the user on the display screen of the UI101, such as "add live icon? When the problem is solved, the method selects 'yes'.

The interaction between the internet enabled user device and the background process can also be described in terms of fig. 2b, where the code that has been configured to run the background process can perform tasks such as computing and can enable communication between the background process and the associated RIA of the internet enabled user device. Such code constituting the background process comprises code, represented in the example by the perceptible artifact object 210, which enables communication between the background process 1 and an associated PA of the internet enabled user device 100, i.e. for providing a prompt to the UI101, and code, represented here by the user interface object 211, which enables communication between the background process 1 and an associated RIA via the UI 101.

Fig. 2b also includes an optional device interface object 212 configured to enable interaction between the background process and a device interface 213 of the internet enabled user device 100. Such objects may be configured to perform certain tasks that may or may not involve the associated RIA, and may include tasks such as checking battery status, radio coverage, or location of the internet-enabled user device 100.

From the developer's perspective, the code running in the background process appears to run locally on the user device, whereas the code may actually run at a remote location in the communication network.

The architecture of the exemplary application server and internet enabled user device described above with reference to figure 1 will now be described in more detail with reference to figure 3. For reasons of simplicity, some of the functionality of fig. 1 has been omitted in fig. 3.

PRIA manager 104 is responsible for creating a PA on UI101 and requesting a background process from application execution server 150. The PRIA manager 104 is also configured to create and maintain a communication channel 108 between the internet enabled user device 100 and the application execution server 150 to be used for enabling reliable communication between the background processes (background processes 1-n) and their respective associated PAs (PAs 1-n). Communication channels supporting Remote Procedure Call (RPC) communication or representational state transfer (REST) mechanisms may be used for this purpose.

The background process is adapted to prompt PRIA manager 104 by generating and transmitting a message to PRIA manager 104, PRIA manager 104 being adapted to process such a message, thereby enabling subsequent interaction between the background process and the associated RIAP to be obtained.

As already mentioned above, the application execution server 150 requires functionality that allows it to interact with the PRIA manager 106. According to fig. 1, such functionality may be implemented as a dedicated functional entity referred to as a background process manager 151.

The background process manager 151 is adapted to create a background process based on a request from the PRIA manager 104 and to manage the already created background process and to enable the background process to communicate with the internet enabled user device 100.

The background process manager 151 is responsible for lifecycle management of each running background process (background processes 1-n) on the application execution server 150. This means that it is adapted to listen for incoming requests, create new background processes that are reachable from PRIA manager 104 via the established communication channel 108, respond to such requests by obtaining associated code from a code source (not shown), e.g. a third party server, and generate new background processes by executing downloaded code. Alternatively, some or all of the relevant code may already be stored at the storage component of the application execution server 150.

The application execution server 150 further comprises a code interpreter 152 or any corresponding functionality connected to the background process manager 151 and configured to interpret executable code.

According to an alternative embodiment, where the JavaScript application is executable code, a full rendering engine (not shown), such as WebKit or Mozilla Gecko (both containing a corresponding JavaScript interpreter), may be embedded in the application execution server 150. According to yet another alternative embodiment, a separate code interpreter (not shown), such as Mozilla rhino, may be embedded in the application execution server 150.

The PRIA manager 104 of the internet enabled user device 100 and the background process manager 151 of the application execution server 150 may each be implemented in a variety of ways. The PRIA manager 104 of fig. 3 also comprises a PA/RIA function 301 connected to the client network function 300 and functionality for enabling interaction with the RIA103 via the Web browser 10, as a Web server 302 and/or a Web browser communication function 303.

The PA/RIA function 301 is a logical function adapted to implement the above PA concept, i.e. the PA/RIA function 301 supports the PA and associated hinting functionality of an application.

According to one exemplary embodiment, the PA/RIA function 301 may be configured to support a graphic adapted icon on a desktop. When the user has been notified of an event from a background process via such a PA/RIA function, he may click on the icon, whereby the RIA/PA function may respond by launching the associated RIA, e.g. by activating a standard platform icon API or any other corresponding standard technique. Alternatively, the user may ignore the notification and the provided PRIA feature. For example, the notification mechanism may be implemented by implementing an UbuntuLinux desktop icon, which may be supported by a D-Bus interface, for example.

According to another exemplary embodiment, the PA/RIA function 301 may instead be configured to support interaction via an audio-based user interface such that the user is notified of the event, for example by playing a sound via a speaker of an internet-enabled user device. In such a case, the user may respond to such a notification, for example, by activating a graphical icon, or by using voice commands via known voice processing techniques.

Further, the PA/RIA function 301 may also be configured to support interaction between a background process and the functionality of an internet-enabled user device via a device interface of the internet-enabled user device.

The PA/RIA function 301 is adapted to receive a request for a new PRIA from the Web browser 102 via the Web server 302 or via the Web browser communication function 303, the Web server 302 may for example be adapted to process requests provided as standard XMLHTTP request objects, the Web browser communication function 303 may be configured as a Web browser plug-in, such as a Netscape plug-in application programming interface (NPAPI) or WebKit plug-in adapted to communicate with the PRIA manager 106 using an interprocess communication protocol using a dependency shared memory, a pipe or a socket.

According to one embodiment, the PA/RIA function 301 may be adapted to support inserting URLs into messages requesting background processes, and providing such messages to the corresponding server network function 310 via the client network function 300 adapted to manage communications with the application execution server 150.

The client network function 300 is adapted to provide a communication channel between the background process manager 151 and the PRIA manager 104 if a communication channel has not been established between these two functions.

The PA/RIA function 301 is also adapted to process notifications received from background processes. The PA/RIA function 300 may be configured to process notification of a request only when the Web browser 102 and/or an associated RIA are in a closed, non-operational state. Such features may be obtained by the PA/RIA function 301, the PA/RIA function 301 being configured to recognize when a user's connection with the Web browser 102 is terminated or when the Web browser is no longer connected to a certain RIA. The D-Bus mechanism may be used for this purpose, for example. If the PA/RIA function identifies that neither the Web browser 102 nor the associated RIA is currently closed, it may instead be configured to begin processing according to the instructions for the corresponding PRIA.

If the notification is to be processed, the user may decide to respond to the notification by activating the activity of the relevant PA approval notification, whereby the PA/RIA function 301 is adapted to recognize such approval from the PRIA specific code and to perform further activities.

The communication functionality may be implemented, for example, by applying a remote procedure call (RRC) mechanism or a representational state transfer (REST) mechanism, such as extensible markup language (XML) -RPC, JavaScript object notation (JSON) -RPC, and the like.

To limit the waiting time for approval of the notification, the PRIA manager 104 may further include a conventional timer that is adapted to terminate the notification-initiated process if the limit has expired without receiving approval for a predefined time. Accordingly, the background process manager 151 may also include corresponding timer functionality.

As already mentioned above, the background process manager 151 may comprise a server network function 310 adapted to interact with a corresponding client network function 300 in order to support communication via a communication channel.

When applicable, the server network function 310 may be adapted to extract the URL from the request for the background process, thereby enabling the relevant executable code necessary for the associated background process to be obtained in a straightforward manner.

A communication channel between the two functions based on a server-initiated push is preferred, since it is generally not feasible to let the client network function 300 poll the corresponding server network function 310 for new information per active background process, which would result in excessive battery consumption at the internet-enabled user device hosting the client network function 300. Thus, when the application execution server 150 is located in a network, a mechanism based on a known technical solution such as SMS, Comet, BOSH, Web socket, or server send event may be applied for this purpose. If the application execution server 150 has instead been configured as part of an internet enabled user device 100, conventional TCP sockets or any other type of suitable interprocess communication protocol may instead be used for this purpose.

To avoid managing separate connections for each background process and thus requiring excessive energy consumption, e.g. due to activating multiple PAs on an internet enabled user device, one communication channel would be sufficient to maintain communication between the internet enabled user device and the application execution server. Such a channel will generally be maintained at least as long as there are any background processes running on the application execution server. Thus, the PRIA manager only needs one communication channel per application execution server, but can have multiple communication channels open to different application execution servers.

The background process manager 151 of fig. 3 also includes a background process function 311 coupled to the server network function 310 and the code interpreter 152. Background process function 311 generally hosts logic adapted to: the creation and termination of new background processes according to predefined instructions, and the code required for creating the background processes is obtained, when necessary, from e.g. an external code source and/or from a memory (not shown) that may reside on the application execution server.

A number of exemplary scenarios based on the background process concept described above will now be described in further detail below with reference to fig. 4-6c, respectively.

Fig. 4 is a general signaling diagram illustrating how an internet enabled user device 100 may interact with an application execution server 150 in order to start or create a background process and thus a PRIA.

In a first step 4:1, a user browsing the RIA103 via the Web browser 102 selects to add a PA, such as a live icon, to the UI101 of the Internet enabled user device 100 by interacting with the PRIA manager 104 via the RIA103 or directly via the Web browser 102. As shown by the following step 4:2, PRIA manager 104 identifies the relevant RIA and sets the PA according to predefined instructions.

In parallel with setting up the PA, the PRIA manager 104 also generates and transmits a message to the background process manager 151 of the application execution server 150, wherein the message comprises a request to set up a new background process, as shown by the further step 4: 3. In the example we assume that a channel has been established between the internet enabled user device 100 and the application execution server 150. If this is not the case, such a communication channel will be set by the PRIA manager at this stage.

Background process manager 151 responds to the request by creating a background process 312 from the request. This is typically achieved by performing predefined functions in the background process manager 151, i.e. by running predefined code explicitly configured for the selected PRIA. To enable the background process manager 151 to identify the relevant PRIA, and thus create the relevant background process, PRIA manager 104 may have added to the message conveyed in step 4:3 a URL or any other information that allows identification of the source hosting the PRIA associated code.

As shown by the next step 4:4, the application execution server 150 extracts the URL or any other corresponding information from the message and uses this information to obtain the relevant background process code from the third party 401 or from any other source from which the relevant code can be downloaded. Alternatively, the relevant code may already reside on the application execution server 150. The background process manager 151 injects PRIA associated code into a new background process which from now on will execute PRIA associated code in the background of the RIA from which the process was originally started.

The PA, together with the associated background process, now constitutes PRIA, which typically remains active until, for example, the user manipulating the PA closes it upon completion of one or more events in the associated background process, or upon detection of an error or suspicious code, regardless of whether the Web browser 102 and/or the RIA103 that originally created the PA are active/open.

FIG. 5 illustrates one possible scenario for actively deleting a background process 312 associated with a RIA 103.

In a first step 5:1, a user having decided to delete the background process 312 first selects an option to delete the associated PA from the UI101 of the Internet enabled user device 100. Subsequently, as shown by another step 5:2, a notification of the PA requesting deletion is transmitted from the UI101 to the PRIA manager 104. PRIA manager 104 responds to such notification by deleting the PA, as shown by the following step 5: 3.

PRIA manager 104 also transmits a message requesting background process manager 151 to delete background process 312, as shown by another step 5: 4. The response of the background process manager 151 is to delete the background process 312, as shown by the final step 5: 5.

Yet another signaling diagram, fig. 6a, shows how the proposed PRIA-enabled mechanism can be applied for the purpose of notifying a user of events that have been triggered in a background process, thereby enabling the user to know that a certain event has occurred, so that the user can decide to approve or ignore the process start initiated by the notification. The suggested notification process is typically only required when the RIA associated with the notification background process and/or the Web browser of the internet enabled user device 100 is closed. After the associated RIA has recovered, multiple backup options for communication to continue between the RIA and the associated background process or between the RIA and the PRIA manager 104 would be possible.

In a first step 6:1, the processing of the background process 312 has reached the point where notification of the associated RIA is required, i.e. the RIA notification trigger has been started due to the occurrence of a specific event. According to one exemplary scenario, the background process 312 may be configured to poll a designated third party server (not shown) for new data, wherein the presence of new data may trigger a RIA notification at the background process 312. In response to identifying the notification trigger, the background process 312 requests the background process manager 151 to start the notification, as shown by the next step 6:2, and in a subsequent step 6:3, PRIA manager 104, which notices that the Web browser and/or associated RIA has closed, transfers the notification to the relevant PRIA manager 104.

Upon receiving the notification, PRIA manager 104 performs a notification procedure, wherein the respective PA is modified accordingly via UI101, as shown in a further step 6: 4. Once PRIA manager 104 has performed the notification process, as shown in another step 6:5, the PRIA process will generally not start until PRIA manager identifies a user approval. Such approval may generally be performed by a user clicking on a modified PA. If RPC is applied, the PA object may run in a background process, where modifications to this object will cause a notification to be triggered and sent to PRIA manager 104. At the PRIA manager 104, the content of the notification will then be interpreted and the PA will be modified accordingly.

According to another alternative embodiment, which also relies on an RPC mechanism, the PA has not been predefined for background processes at the PRIA manager 104. Instead, the predetermined RPC call is communicated to the PRIA manager 104, which includes the corresponding predefined function that is started, so that the required PA modification can be requested from the PRIA manager.

According to yet another embodiment, applicable when applying REST mechanisms, each PA is accessible from an associated background process as a REST resource.

Various types of processes may be initiated once the user has given his approval to continue restoring the respective RIA, such as processes for updating the respective RIA, for enabling the user to interact with the PRIA manager, and/or for enabling the user to interact with the notification background process.

Referring now to the signaling diagram of fig. 6b, an exemplary scenario illustrating a series of steps that may follow a successful notification (such as the notification described above with reference to fig. 6 a) according to one embodiment will be described below.

According to the signaling diagram of fig. 6b, the approval causes the Web browser 102 and/or the RIA103 to be started by the PRIA manager 104, as shown by steps 6:6 and/or 6: 7. Once both Web browser 102 and RIA103 are active, the browsing user may continue the initiated PRIA process by interacting with background process 312. According to FIG. 6b, interaction begins between the RIA/Web browser 103, 102 and the associated background process 312, as shown by the following step 6: 8. Such interaction may, for example, cause background process 312 to instruct PRIA manager 104 to retrieve new data, as shown by further step 6:9, whereby PRIA manager 104 retrieves new data from server 401, as shown by subsequent step 6:10, after which RIA103 may be updated, as shown by step 6: 11. The interaction may then continue, as shown by another step 6:12, according to the instruction associated with the respective PRIA.

As already mentioned above, the background process may also be configured to interact with the device interface of the internet enabled user device. If such communication is to be applied, the background process may perform one or more tasks with or without involving the associated RIA.

According to another alternative embodiment, which will be described below with reference to the signalling diagram of fig. 6c, both the Web browser 102 and the RIA103 are already open/active, but no background process is actively involved in the remaining processes, as shown by steps 6:6 'and 6: 7'. Instead, the RIA manager 104 opens the RIAURL again in the Web browser, thereby enabling the start-up process from the RIA to begin. The upcoming processing step may for example comprise reloading data from the external server 401 to the internet enabled user device 100 under supervision of the PRIA manager 104. The reloaded data may for example comprise a predefined set of instructions that have been specified for the relevant PRIA. The obtained data may then be used by the RIA103 without involving the associated background process. Such a process is illustrated by the subsequent steps 6:8 'and 6: 9'.

Methods of creating, managing and terminating background processes and managing notifications and subsequent interactions using entities such as the entities described above will now be described below with reference to the various flow diagrams of fig. 7a-8c, respectively.

Fig. 7a relates to a method for initiating or creating a new background process at an application execution server, which is executed at a PRIA manager or corresponding functional entity of an internet enabled user device.

In a first step 700, a request to create a PA is received from an internet enabled user device. Such a request is responded to by setting a PA on the UI of the user device according to the content of the request, as shown in the following step 701. In a next step 702, it is determined whether any channels are available for the associated application execution server. If this is not the case, such communication is established in a subsequent step 703. Subsequently, according to a next step 704, a request to set up the associated background process is prepared according to the content of the request, which is then sent to the application execution server.

Fig. 7b relates to exemplary method steps to be performed at an internet enabled user device for enabling communication between a running background process and the internet enabled user device by managing a notification process at the internet enabled user device.

In a first step 705, a request for notification is received from a background process, and in a subsequent step 706, the PRIA manager of the internet enabled user device performs the notification via the relevant PA. The PRIA manager then waits for approval, i.e. a response to the notification, to proceed with the initiated interactive process, as shown by step 707, and once approved, the background process is notified of the approval and the process initiated by the notification can start, as shown by a subsequent step 708, typically by receiving instructions provided in one or more messages from the background process, and by executing such instructions accordingly. If the Web browser and the RIA of the notification are active, step 707 can be omitted and, therefore, the background process is notified by the PRIA manager to immediately start the requested event-initiated process.

Figure 7c relates to another example process described by a series of method steps to be performed at an internet enabled user device when a background process is to be terminated from the internet enabled user device. In a first step 709, a request to delete the PA is received from the RIA, typically in response to the PRIA manager of the internet enabled user device deleting the PA, as shown by a subsequent step 710 and a further subsequent step 711, step 711 indicating that the application execution server is instructed to terminate the associated background process.

Fig. 8a-c show corresponding method steps to be performed at an application execution server when a background process is to be created, terminated or managed, respectively.

In fig. 8a, illustrating the steps of managing a request for a new background process, according to one embodiment, a request for a new background process is first received in a message provided from an internet enabled user device, as shown by step 800.

In a next step 801, relevant background process code is obtained based on the content of the message. Once the relevant code is obtained, the application execution server executes the predefined instructions by executing the relevant code, so that the corresponding background process can be started upon request, as shown by a further step 802.

Fig. 8b shows another set of method steps according to one embodiment, which enables communication between a background process and a RIA to be executed by an application execution server.

In a first step 803, the application execution server receives a trigger for a notification from a background process. In a next step 804, the application execution server prepares a message including a request for notification and transmits the message to an internet enabled user device connected to the RIA. The background process then waits for approval of the notification, which is to be seen as indicating to the background process, according to how the background process' instructions are, the started communication process to continue with the corresponding RIA. This is indicated by the loop denoted as step 805.

Once the application execution server has received the approval, the process may start or even terminate according to the corresponding instructions of the background process, as shown by step 806.

Fig. 8c is another signaling scheme illustrating another set of example method steps that may be performed at an application execution server to perform a required termination of a background process.

According to the example, the running background process may be terminated by first identifying a background process termination request at the application execution server, as shown by step 807. Such requests may be received from internet-enabled user devices connected to the RIA in response to user interaction entered by a user via a corresponding PA, in response to a fault or suspicious code identified by the internet-enabled user device, or by receiving a trigger from a background process, for example, once a required process has been completed. The application execution server responds to such a request by terminating the background process, as shown by step 808.

Throughout this document, terms used to describe logical devices, entities or nodes, such as "application execution server", "background process manager", "PRIA manager", "server network function", and "client network function", are to be understood as merely illustrative expressions, which may be expressed in a variety of alternative ways.

Additionally, while the apparatus and methods have been described with reference to specific exemplary embodiments, the description is generally only intended to illustrate the inventive concepts and should not be taken as limiting the scope of what has been defined by the appended claims.

Acronyms

Claims (21)

1. An application execution server for managing a background process associated with a rich internet application accessible via a Web browser of an internet enabled user device, the application execution server comprising:

-a background process manager adapted to create a background process by obtaining executable code from the content of the request and executing the executable code in response to receiving a request for such process from the rich internet application, such that activity associated with the rich internet application is being monitored;

the background process is further adapted to identify a triggered event in the background process associated with the rich internet application and associated with the monitored activity, and to invoke the rich internet application after the Web browser and/or the rich internet application has changed from open to closed state in response to the identified event.

2. The application execution server of claim 1, wherein the background process manager is adapted to create the background process by obtaining executable code according to the request and by executing the code.

3. The application execution server of claim 2, wherein the code is obtained from a server.

4. The application execution server of claim 3, wherein the background process manager is adapted to identify the server by extracting a URL from the received request.

5. The application execution server of any of claims 1-4, wherein the background process manager is further adapted to enable communication between the background process and the rich Internet application.

6. The application execution server of any of claims 1-4, wherein the background process manager further comprises a server network function adapted to enable communication between a background process and an associated rich Internet application by supporting a persistent communication channel.

7. The application execution server of any of claims 1-4, wherein the application execution server is configured as an integrated part of the Internet enabled user device.

8. The application execution server of any of claims 1-4, wherein the application execution server is configured as a stand-alone network entity adapted to establish communication with the Internet enabled user device.

9. An internet enabled user device for enabling communication between a rich internet application accessible via a Web browser and an associated background process residing on an application execution server, wherein the internet enabled user device comprises:

-a persistent rich internet application manager, and

-a user interface for the user to use,

the persistent rich internet application manager is adapted to request the application execution server to create the background process by obtaining and executing executable code and to set an associated perceptible artifact on the user interface, the persistent rich internet application manager being further adapted to support communication between the background process and the associated perceptible artifact by establishing and/or maintaining a communication channel between the internet enabled user device and the application execution server after the Web browser and/or rich internet application has changed from open to closed state.

10. Internet enabled user device according to claim 9, wherein the persistent rich internet application manager is adapted to receive a request for initiating the background process from the rich internet application or from the Web browser.

11. An internet enabled user device, according to claim 9, wherein the persistent rich internet application manager further comprises a client network function adapted to enable persistent communication between the rich internet application and the background process by providing a persistent communication channel between the persistent rich internet application manager and the application execution server.

12. An internet enabled user device, according to claim 11, wherein the persistent rich internet application manager is adapted to perform one or more functions in accordance with instructions associated with the rich internet application, the instructions being provided to the persistent rich internet application manager from the background process via the persistent communication channel.

13. The internet enabled user device of claim 12, wherein the client network function is adapted to enable persistent communication by applying a remote procedure call mechanism or a representational state transfer mechanism.

14. The internet enabled user device of claim 12, wherein the persistent rich internet application manager is adapted to obtain executable code according to the instructions and execute the code.

15. An internet enabled user device, according to any of claims 9-14, wherein said persistent rich internet application manager is further adapted to interact with at least one device interface of said internet enabled user device according to instructions provided from said background process.

16. An internet enabled user device, according to any of claims 9-14, wherein said internet enabled user device is any device of a fixed or wireless user device.

17. A method for managing a background process associated with a rich internet application accessible via a Web browser of an internet enabled user device, the method being performed at an application execution server, comprising the steps of:

-receiving a request for a background process from the rich Internet application running on the Internet enabled user device,

-in response to receiving the request, creating the background process by obtaining executable code from the content of the request and by executing the code such that activity associated with the rich Internet application is being monitored by the background process,

-identifying, by the background process, a triggered event in the background process associated with the rich internet application and associated with the monitored activity, and invoking, by the background process, the rich internet application after the Web browser and/or rich internet application has changed from an open to a closed state.

18. The method of claim 17, further comprising the steps of:

-receiving a notification request from the background process requesting a notification associated with the rich internet application, the request being triggered by the event, and

-transmitting said notification request to said internet enabled user device, thereby enabling notification of said event at said internet enabled user device.

19. A method for enabling communication between a rich internet application accessible via a Web browser of an internet enabled user device and an associated background process residing on an application execution server, wherein:

the internet enabled user device comprising a persistent rich internet application manager and a user interface, the method being performed at the internet enabled user device, comprising the steps of:

-receiving a request for creating a background process from the rich internet application;

-setting an associated perceptible artifact on the user interface;

-requesting the application execution server to create a background process by obtaining and executing executable code according to the request, and

-in response to receiving a notification from the background process, managing communication between the background process and the perceptible artifact by establishing and/or maintaining a communication channel between the internet enabled user device and the application execution server after the Web browser and/or rich internet application has changed from open to closed state.

20. The method of claim 19, said step of managing comprising the further steps of:

-receiving a message comprising a notification from the application execution server,

-notifying the rich Internet application of the content,

-enabling communication between the persistent rich internet application manager and the rich internet application according to predefined instructions if the notification is approved via the perceptible artifact.

21. The method of claim 19 or 20, further comprising the additional step of:

-processing background process communication messages communicated between the background process and a device interface of the internet enabled user device.