GB2521210A

GB2521210A - Method, device, and computer program for processing service requests in a web runtime environment

Info

Publication number: GB2521210A
Application number: GB1322101.5A
Authority: GB
Inventors: Romain Bellessort; Youenn Fablet; Herv Ruellan
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2013-12-13
Filing date: 2013-12-13
Publication date: 2015-06-17
Also published as: GB201322101D0

Abstract

After having received (400), in a module of the web runtime environment, a service request from a service requester application, a service provider application enabling processing of the service request is loaded into the web runtime environment (405) and the service request is transmitted to the loaded service provider application. Next, the service provider application is executed in the web runtime environment, executing the service provider application causing display of a first user interface associated with the service provider application for obtaining user inputs. After having detected that user inputs required for processing the service request have been received (415), a second user interface, independent from the service provider application, is displayed.

Description

METHOD, DEVICE, AND COMPUTER PROGRAM FOR PROCESSING SERVICE

REQUESTS IN AWEB RUNTIME ENVIRONMENT

FIELD OF THE INVENTION

The invention generally relates to the field of processing service requests in a web runtime environment. More particularly, the invention concerns a method for improving the execution of web intents or similar requested services that require a significant amount of time to be processed, by detecting that a service provider application has started processing a service request and by automatically executing the service provider application as a background task to process the service request, so that a user may interact with other applications.

BACKGROUND OF THE INVENTION

Sharing of content on the World Wide Web is now frequently made available through the use of share" buttons. For instance, a person enjoying an article on a given website can generally use Facebook, Twitter or Google÷ buttons in order to share this article on the corresponding social network (Facebook, Twitter, and Google+ are trademarks).

However, since these buttons do not result from any standardization process, they are all defined differently using proprietary solutions and thus, developers have to integrate each button separately into websites. Therefore, if a reader uses a sharing service that has not been integrated by a website developer, he/she cannot share content from this website. Furthermore, a multiplicity of buttons leads to unfriendly user interfaces.

To handle such a problem, a solution consists in using a dedicated service that may be reached using a single button and that defines a communication model between a requester and a provider of that dedicated service.

For the sake of illustration, such a dedicated service can be a "sham" service which defines a communication model for sharing data between a website publishing content ("share" service requester) and a service of a social network ("sham" service provider such as Facebook, Twitter or, Goog/e+). If a website declares itself as a "share" service requester (e.g. to enable its readers to share its articles on their favorite social network), a single "share" button is displayed along with shareable content. Accordingly, when a reader clicks on the "share" button, a list of "share" service providers (or advantageously a list of user's favorite "share" service providers) is displayed so that the reader selects one of them and the corresponding content is shared based on the communication model defined.

Such a solution makes it possible to avoid integrating different proprietary buttons into websites in order to enable requesting services. Moreover, only favorite service providers can be presented to a user thereby improving the user interface.

Such a model is defined by elements known as web intents.

Web intents result from a standardization proposal submitted to W3C (World Wide Web Consortium) whose purpose is to enable a better cooperation between web applications by defining standard actions (web intents) such as share, pick, view or edit (share action allows sharing content on a social network, pick action is used for picking content such as an image from an online image gallery, view action is typically an application adapted for viewing specific kinds of files, and edit action is generally an application for editing content, for example editing an image).

Web intents proposal defines a generic model for interactions between web applications. Each defined action is described in a specification that explains how parameters of the generic model should be specifically used to handle that action.

The main components of web intents comprise an intent tag, an intent object, and a startActivity() method.

The intent tag (<intent>) is defined so that a website can declare itself as a provider for a given kind of action. For instance, the tag <intent action="http://webintents.org/share" 7> may be included in an HTML source code of a webpage (that is considered to be a web application) to indicate that the webpage supports the "share" action.

When a user-agent (i.e. typically a web browser) detects the presence of such a tag in the HTML code of a website, it preferably checks whether the current user has already registered this website as a provider for the corresponding action. If not, the possibility of adding this website to his/her list of registered providers for this action is offered to the user.

Additional attributes of intent tag are available. They can be used to indicate, for example, the type of data a given website can handle (e.g. a website can define itself as able to handle the edit action but only for images) or to specify the URL of the page on the website that supports the action described in the intent tag (i.e. the URL of the page that the user-agent should load when the provider is selected by a user). Another attribute enables to specify whether a web intent provider should be loaded in a new window or directly inside the requesting web page.

It is noted that intent tags are key components for registration of providers, even though other mechanisms may be used to register providers (as an example, web application developers may be able to publish their applications in specific repositories designed to gather applications providing a given service).

A web intent object is typically a JavaScript object representing a request made by a client web application (Java is a trademark). When created, a web intent object contains the parameters of the request, which may include a kind of action (e.g. "sham", "pick', "vieW' or "ed/fl, a data type information (e.g. image or sound), and data to be provided to the application selected by the user to process the request (e.g. the title and the URL of an article to be shared or image data to be edited). A web intent object also comprises two methods known as postResult() and postFailure() that can be called only when the web intent object has been delivered to a service provider application.

After a web intent object has been created, a web page can actually propose to a user, through a user-agent, to select a provider to process the request corresponding to the web intent object. To do so, it calls a startActiv/ty() method that typically comprises up to three parameters among which a web intent object previously created.

Optionally, the startActiv/ty() method may comprise a call-back reference to be associated to an event known as onSuccess, in order to identify a method that should be called in case the provider returns a success event. Similarly, startActiv/ty() method may optionally comprise a call-back reference to be associated with an event known as onFallure, in order to identify a method that should be called in case the provider returns a failure event.

When executing the startActivity() method, the user-agent displays a list of identifiers of possible providers based on intent object properties. For instance, if the web intent object corresponds to "ed/f' action, a list comprising only identifiers of providers supporting "ed/f' action would be displayed. Moreover, if the "ed/f' action concerns an image, then a list comprising only identifiers of providers supporting "ed/f' action for processing images would be preferably displayed. The identifiers of the displayed list typically correspond to providers previously registered by the user.

However, other identifiers may also be displayed within the list, e.g. identifiers of providers suggested by the web page or by the user-agent.

When the user selects one of the displayed identifiers, the corresponding provider is loaded. While processed by the user-agent, provider's web page is provided access to the web intent object. In the case of an image to be edited, the image is therefore accessible to the provider.

After completion of the request, for example after an image is edited and the user clicks on a "complete" button, the provider typically calls postResult() or postFailure() method of the web intent object. As mentioned above, these methods are associated with the call-back references defined for "onsuccess" and "onFailure" events. Depending on the kind of web intents, the result may be a simple string value such as a successful processing indication or an object such as an image if the web intent object corresponds to edit" action for processing an image (the result then being the edited image).

Web intents provide several advantages among which is to allow a web application to request a given kind of services without knowledge of a provider to be selected for performing the request. Accordingly, web developers can easily rely on other web applications and users can select their favorite providers.

Moreover, given that only the user and the user-agent know which client and which provider are considered, the user's privacy can be ensured (with prior ad solution, e.g. for a share" button, the provider knows which client is requesting an action to be performed).

Similarly, security is also improved in that exchanges of data through web intent objects happen between two web pages loaded in a user-agent, i.e. exchange of data happens only in the browser. Therefore, there is no need for a client web application to communicate with a web server distinct from its own web server.

It is noted that web intents is not the only technology enabling cooperation between web applications. For the sake of illustration, Mozilla has developed a very similar technology called web activities (Mozilla is a trademark). This technology is in particular used in Mozilla's Firefox OS operating system (Firefox is a trademark).

Web intents and web activities can be considered as specific implementation of a generic model handled by a web runtime environment (WRE), for example Mozilla's Firefox OS or a web browser, enabling web applications loaded and run in the web runtime environment to cooperate.

Figure 1, comprising Figures la and ib, illustrates two examples of web runtime environments.

As illustrated in Figure la, a web runtime environment can be a software component 100 relying on an operating system 105 to run web applications 110. A web runtime environment typically consists atone or several software modules, for example generic modules and specific modules, among which a web runtime controller, that may comprise sub-modules. Web browsers like Mozilla Firefox, Google Chrome and Microsoft Internet Explorer, are examples of such a web runtime environment (Google, Chrome, Microsoft, and Internet Explorer are trademarks).

Alternatively, as illustrated in Figure ib, a web runtime environment 100' can be integrated in an operating system 105' to run web applications 110'. In such a case, the whole operating system is based on web technologies. Examples of such a web runtime environment are Google Chrome OS and MoziI/a Firefox OS.

Figure 2 illustrates an example of the cooperation between two applications executed in a web runtime environment 200.

As illustrated, a service requester application (SRA), referenced 205, transmits a service request to aweb runtime controller 210. Such a service request has various characteristics and comprises a type, for example "share", "edit', pick" or save".

In response, web runtime controller 210 selects a service provider application (SPA), referenced 215, that is able to handle at least the service request corresponding to the type of the requested service. Once selected for processing a service request, a service provider application is loaded and provided with said service request. Upon completion of the service request, the service provider application can return a result to web runtime controller 210 which in turn returns it to the service requester application 205 that originated the service request.

As it can be understood from Figure 2, a web runtime controller of a web runtime environment is responsible for receiving a service request from a service requester application, transmitting it to a service provider application, receiving a result from the service provider application, and transmitting the result to the service requester application.

It is noted that in practice, a web runtime controller may correspond to various components of a web runtime environment that may also be responsible for performing other tasks handled by the web runtime environment.

It has been observed that processing certain service requests by a service provider application may require a significant amount of time. For the sake of example, processing services requests directed to printing documents or uploading files requires a significant amount of time. However, even if service provider applications typically display an indication of current progress, for example a message like "12 pages printed out of 4?' or File upload: 80%", no specific behavior of the web runtime environment used or of service provider applications is defined for such kinds of services.

It is noted that, at any time during processing of service requests by a service provider application, a user can switch to another application, for example to the service requester application. However, this requires the user to take the initiative for switching from one application to another, which may not be obvious for all users, especially in a mobile environment where the whole screen space is used by each application. Furthermore, some users may think that switching from one application to another may stop processing of the service request.

As a consequence, there is a need for improving the execution of persistent web intents, web activities, and similar requested services in a web runtime environment.

SUMMARY OF THE INVENTION

Faced with these constraints, the inventors provide a method, a device and a computer program for processing service requests in a web runtime environment allowing a service request to be automatically processed as a background task so that a user may interact with other applications.

It is a broad object of the invention to remedy the shortcomings of the prior art as described above.

According to a first aspect of the invention there is provided a method for processing a service request in a web runtime environment, the method comprising: -receiving, in a module of the web runtime environment, a service request from a service requester application; -loading, into the web runtime environment, a service provider application enabling processing of the service request and transmitting the service request to the loaded service provider application; -executing the service provider application in the web runtime environment, executing the service provider application causing display of a first user interface associated with the service provider application for obtaining user inputs; -detecting that user inputs required for processing the service request have been received; and -in response to detecting that user inputs have been received, displaying a second user interface independent from the service provider application.

The method of the invention allows automatically switching from one application to another once a displayed service provider application is no longer needed. This avoids a user having to manually switch to another application and this makes clear for users that switching from one application to another does not stop the processing of the service request. At the same time, the service provider application remains accessible and status updates can be displayed This method achieves such an effect by enabling the web runtime environment to detect a specific kind of step, this step being determined based on web application execution.

In an embodiment, the first user interface associated with the service provider application is displayed until it is detected that the user inputs required for processing the service request have been received.

In an embodiment, the service provider application is executed as a background task after displaying the second user interface.

In an embodiment, the step of detecting that user inputs required for processing the service request have been received comprises a step of receiving a notification from the service provider application that the service request is being processed or is ready to be processed.

In an embodiment, the received notification comprises a status or a completion level of processing the service request.

In an embodiment, the step of detecting that user inputs required for processing the service request have been received comprises a step of detecting that an identified step leading to processing the service request or resulting from processing the service request has been carried out.

In an embodiment, the method further comprises a step of identifying the step leading to processing the service request or resulting from processing the service request.

In an embodiment, the step of identifying the step leading to processing the service request or resulting from processing the service request comprises a step of recognizing a predetermined message or predetermined data transmitted or received by the web runtime environment over a network.

In an embodiment, the step of identifying the step leading to processing the seivice request or resulting from processing the seivice request comprises a step of determining the type of the requested service, of analyzing instructions of the service provider application, or of analyzing a user inteiface element of the seivice provider application.

In an embodiment, the method further comprises a step of detecting the end of processing the service request.

In an embodiment, the step of detecting the end of processing the service request comprises a step of receiving a notification from the service provider application, the notification comprising a status or a completion level of processing the seivice request, or of recognizing a predetermined message or predetermined data transmitted or received by the web runtime environment over a network.

In an embodiment, the method further comprises a step of displaying an indication relative to a status or a completion level of processing the service request, the indication being displayed in the second user interface.

In an embodiment, the method further comprises a step of displaying a description of the displayed indication, the description to be displayed being received along with the status or the completion level of processing the service request.

In an embodiment, the method further comprises a preliminary step of analyzing characteristics of the service request, the step of displaying the second user interface in response to detecting that user inputs have been received being carried out in response to the preliminary analyzing step.

In an embodiment, the step of analyzing characteristics of the service request comprises a step of determining the type of the service request.

In an embodiment, the step of analyzing characteristics of the service request comprises a step of estimating the amount of time required fol processing the seivice request.

In an embodiment, the second user interface is associated with the service requester application.

A second aspect of the invention provides a computer program product for a programmable apparatus, the computer program product comprising instructions for carrying out each step of the method described above when the program is loaded and executed by a programmable apparatus.

The computer program product of the invention allows automatically switching from one application to another once a displayed service provider application is no longer needed. This avoids a user having to manually switch to another application and this makes clear for users that switching from one application to another does not stop the processing of the service request. At the same time, the service provider application remains accessible and status updates can be displayed This computer program product achieves such an effect by enabling the web runtime environment to detect a specific kind of step, this step being determined based on web application execution.

A third aspect of the invention provides a computer-readable storage medium storing instructions of a computer program for implementing the method described above.

The computer-readable storage medium of the invention allows automatically switching from one application to another once a displayed service provider application is no longer needed. This avoids a user having to manually switch to another application and this makes clear for users that switching from one application to another does not stop the processing of the service request. At the same time, the service provider application remains accessible and status updates can be displayed This computer-readable storage medium achieves such an effect by enabling the web runtime environment to detect a specific kind of step, this step being determined based on web application execution.

A fourth aspect of the invention provides a device for processing a service request in a web runtime environment, the device comprising at least one microprocessor configured for carrying out the steps of: -receiving, in a module of the web runtime environment, a service request from a service requester application; -loading, into the web runtime environment, a service provider application enabling processing of the service request and transmitting the service request to the loaded service provider application; -executing the service provider application in the web runtime environment, executing the service provider application causing display of a first user interface associated with the service provider application for obtaining user inputs; -detecting that user inputs required for processing the service request have been received; and -in response to detecting that user inputs have been received, displaying a second user interface independent from the service provider application.

The device of the invention allows automatically switching from one application to another once a displayed service provider application is no longer needed. This avoids a user having to manually switch to another application and this makes clear for users that switching from one application to another does not stop the processing of the service request. At the same time, the service provider application remains accessible and status updates can be displayed This device achieves such an effect by enabling the web runtime environment to detect a specific kind of step, this step being determined based on web application execution.

In an embodiment, the at least one microprocessor is further configured so that the first user interface associated with the service provider application is displayed until it is detected that the user inputs required for processing the service request have been received.

In an embodiment, the at least one microprocessor is further configured so that the service provider application is executed as a background task after displaying the second user interface.

In an embodiment, the at least one microprocessor is further configured so that the step of detecting that user inputs required for processing the service request have been received comprises a step of receiving a notification from the service provider application that the service request is being processed or is ready to be processed.

In an embodiment, the at least one microprocessor is further configured so that the step of detecting that user inputs required for processing the service request have been received comprises a step of detecting that an identified step leading to processing the service request or resulting from processing the service request has been carried out.

In an embodiment, the at least one microprocessor is further configured for carrying out a step of identifying the step leading to processing the service request or resulting from processing the service request.

In an embodiment, the at least one microprocessor is further configured so that the step of identifying the step leading to processing the service request or resulting from processing the service request comprises a step of recognizing a predetermined message or predetermined data transmitted or received by the web runtime environment over a network.

In an embodiment, the at least one microprocessor is further configured so that the step of identifying the step leading to processing the service request or resulting from processing the service request comprises a step of determining the type of the requested service, of analyzing instructions of the service provider application, or of analyzing a user interface element of the service provider application.

In an embodiment, the at least one microprocessor is further configured for carrying out a step of detecting the end of processing the service request.

In an embodiment, the at least one microprocessor is further configured so that the step of detecting the end of processing the service request comprises a step of receiving a notification from the service provider application, the notification comprising a status or a completion level of processing the service request, or of recognizing a predetermined message or predetermined data transmitted or received by the web runtime environment over a network.

In an embodiment, the at least one microprocessor is further configured for carrying out a step of displaying an indication relative to a status or a completion level of processing the service request, the indication being displayed in the second user interface.

In an embodiment, the at least one microprocessor is further configured for carrying out a step of displaying a description of the displayed indication, the description to be displayed being received along with the status or the completion level of processing the service request.

In an embodiment, the at least one microprocessor is further configured for carrying out a preliminary step of analyzing characteristics of the service request, the step of displaying the second user interface in response to detecting that user inputs have been received being carried out in response to the preliminary analyzing step.

In an embodiment, the at least one microprocessor is further configured so that the step of analyzing characteristics of the service request comprises a step of determining the type of the service request.

In an embodiment, the at least one microprocessor is further configured so that the step of analyzing characteristics of the service request comprises a step of estimating the amount of time required for processing the service request.

Since the present invention can be implemented in software, the present invention can be embodied as computer readable code for provision to a programmable apparatus on any suitable carrier medium. A tangible carrier medium may comprise a storage medium such as a floppy disk, a CD-ROM, a hard disk drive, a magnetic tape device or a solid state memory device and the like. A transient carrier medium may include a signal such as an electrical signal, an electronic signal, an optical signal, an acoustic signal, a magnetic signal or an electromagnetic signal, e.g. a microwave or RF signal.

BRIEF DESCRIPTION OF THE DRAWINGS

Further advantages of the present invention will become apparent to those skilled in the art upon examination of the drawings and detailed description. It is intended that any additional advantages be incorporated herein.

Embodiments of the invention will now be described, by way of example only, and with reference to the following drawings in which: Figure 1, comprising Figures la and ib, illustrates two examples of web runtime environments; Figure 2 illustrates an example of the cooperation between two applications executed in a web runtime environment; Figure 3 illustrates an example of processing a service request according to an embodiment of the invention; Figure 4 illustrates an example of processing a service request by a service provider application executed in a web runtime environment according to a particular embodiment; Figure 5 illustrates an example of the process enabling a web runtime module of a web runtime environment to detect that no more users' inputs are needed to process a service request; Figure 6 illustrates an example of an algorithm for identifying a step directly leading to processing a service request or directly resulting from processing a service request; Figure 7 illustrates an example of an algorithm for handling notifications received by a web runtime module from a service provider application; Figure 8 illustrates switching the focus back to a service provider application upon detection of the end of processing of a service request; and Figure 9 represents a block diagram of a computer device in which steps of one or more embodiments may be implemented.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

A particular embodiment of the invention aims at enabling a web runtime module of a web runtime environment, for example a web runtime controller, to detect that a service provider application has started processing a service request and that presumably no more user inputs are required to complete the processing. Such detection is advantageously performed only for service requests that may require a significant processing time.

According to a first embodiment, service provider applications are provided with means for signaling to a web runtime module of a web runtime environment that service request processing has started. For the sake of example, a specific method such as startProcessing() method is defined for the object corresponding to the service request so that the method is called by a service provider application on beginning the service request processing.

According to a second embodiment, specific steps that can be detected in a web runtinie environment are identified as leading to service request processing or as resulting from service request processing. In other words, the detection of these steps in the web runtime environment is to be interpreted as an indication that the service request is processed or as an indication that the service request processing is to be started. For the sake of illustration, the reception of a message of the print job accepted' type from a remote device, when a "print' service request is to be processed, can be considered as a step resulting from the service request processing (since such a message is received after a print job has been sent to a printer and has been accepted by said printer).

Once a web runtime module determines that a service request is processed or that processing of the service request is to be started, the web runtime module selects another application, typically the service requester application, and displays its graphical interface. Preferably, consent of the user is obtained prior to displaying the graphical interface of another application so that the user understands that the service request is being processed as a background task. Even though the service provider application is no longer displayed, it is still executed and accessible to user, for example via a specific user interface.

Advantageously, the service provider application sends status updates, for example a completion level such as the indication "10% of sew/ce request processed' to the web runtime module. Such status updates are typically displayed in the web runtime environment so as to inform the user.

Figure 3 illustrates an example of processing a service request according to an embodiment of the invention.

For the sake of illustration, it is assumed that a photo album web application 300 is loaded in a web browser 305 (i.e. a web runtime environment) and that a user selects photos corresponding to photo album 310 named "Holidays" and clicks the "print' button 315.

After the "print' button has been clicked, the photo album web application acting as a service requester application creates a service request corresponding to a request for printing the selected set of photos. This service request is transmitted to a web runtirne controller of the web runtirrie environment that determines a list of one or more possible service provider applications for processing the service request. The user is prompted with this list to select one of the service provider applications.

After being selected, the service provider application, denoted "print app", is loaded and its user interface is displayed by the web browser 305, as illustrated with reference 320. Next, a user can enter various parameters such as the number of copies and/or the printing mode, for example "black and white" or "colot', as illustrated with reference 325. Once the parameters have been entered, the user clicks "start printing" button 330.

At this stage and according to a first embodiment, the "print app" service provider application can call a specific method that makes it possible to indicate to the web runtime module of the web runtime environment that the processing of the service request has started. For the sake of illustration, a method associated with the object representing the service request, for example, as mentioned above, a method denoted startProcessing, can be called. Alternatively, a method enabling the service provider application to indicate its current status, for example a method denoted "updatestatus(currentStatus)" (where currentstatus is a value corresponding to the current status of the service provider application), can be used. Still for the sake of illustration, such a status can take values representing "no started', "started', and "ended' information.

According to a second embodiment, if the "print app" service provider application does not rely on such a type of method, the web runtime module identifies specific steps that either lead to service request processing or result from service request processing. Next, the web runtime module monitors the execution of the service provider application so as to detect the execution of the identified steps and thus, determine that the processing of the service request has started or is going to start without need for additional user input.

As mentioned above, such steps can correspond to the reception of a "print job accepted' message that is returned by a remote printer to which has been previously sent a "print job" message in relation with selected data to be printed (such a "print job accepted' message indicates that the selected data is being printed). Hence, the reception of a "print job accepted' message by a "print service provider application (via a web runtime module) can be considered to be a step resulting from the service request processing.

After having detected the processing of the service request, it is assumed that no user input is needed to complete the processing. Accordingly, the web browser can display the user interface of another application (preferably after obtaining user consent for doing so), for example the service requester application (i.e. the photo album application in the example illustrated in Figure 3), which was displayed prior to starting the processing of the service request. By doing so, a user is able, for example, to select other photos and build another album to be printed as illustrated with reference 335.

If the "print app" service provider application provides status updates, such updates may be displayed in the web browser user interface. For example, a progress bar reflecting the progress of printing can be displayed as illustrated in Figure 3 with reference 340.

For the sake of clarity, it is assumed in the following that the processing of a service request can start when no more users' inputs are needed. Particular cases according to which users interact with service provider applications during processing service requests have to be handled on an exception basis. Regarding users' inputs required at the end of service request processing, for example when results have to be validated before being transmitted to a service requester application (e.g. by clicking on a "OK' button), it is assumed that these interactions arise after processing the service request and that it can be detected by a web runtime module as described by reference to Figure 8.

Figure 4 illustrates an example of processing a service request by a service provider application executed in a web runtime environment according to a particular embodiment.

According to a first step (step 400), a service request (SR) is obtained by a web runtime controller of a web runtime environment (WRE) from a service requester application (SRA) executed in this web runtime environment.

In a following step, a list of service provider applications that can be used to handle the obtained service request is determined and identifiers of these service provider applications are provided to a user (the identifiers are typically displayed) so that the user can select a service provider application (step 405). Alternatively, the service requester application at the origin of the service request specifies a service provider application to be used. In such a case, there is no need for the user to select a service provider application.

Next, the selected service provider application is loaded in the web runtime environment and the web runtime module gives the focus to the loaded service provider application (step 410). In addition, the web runtime controller provides the service request to the loaded service provider application.

It is noted that generally, in particular in a mobile environment, a single application is displayed at a given time. As a consequence, giving the focus to an application in such a context generally implies that only the graphical interface of this application is displayed (other applications executed in the web runtime environment are therefore no longer visible even though they are still executed).

Next, a test is carried out to determine whether or not the users' inputs required for processing the service request have been obtained (step 415), that is to say whether processing of the service request is to be started. This step is further described by reference to Figure 5.

When the users' inputs required for processing the service request have been obtained, the focus is given to the service requester application or to another application (step 430).

Indeed, when users' inputs required for processing the service request have been obtained, there is no need to maintain the focus on the service provider application. Giving the focus to the service requester application generally results in displaying a graphical interface of the service requester application, in particular in the context of a mobile device. As a result, a graphical interface of the service provider application is no longer displayed, even though the service provider application keeps being executed in background. However, the service provider application remains preferably accessible through a different window to the one used for displaying a graphical interface of the service requester application (or of another application) or through a particular tab. Alternatively, the service provider application may no longer be accessible through a different window or via a different tab but a specific component of the user interface of the web runtime environment enables the user to display and give focus to a window or a tab giving access to the service provider application.

As illustrated in Figure 4, an optional step 425 can be performed prior to performing step 430 to ensure consent of the user before giving focus to the service requester application or to another application. This can be done thanks to a dialog box explaining that the processing of the service request does not require additional users' inputs, hence enabling the user to switch to another application. Such a dialog box may also indicate that the user will be notified of status updates thanks to a specific user interface in the web runtime environment and that service provider application will remain accessible through another specific component of the user interface. A user may be able to define that his/her consent should be provided by default (e.g. by checking a box displayed in the dialog box).

As mentioned above, the application to which focus is given is not necessarily the service requester application. For instance, the dialog box displayed to ensure consent of the user at optional step 425 may also enable the user to select an application among the ones being executed in the web runtime environment or by the operating system. By doing so, once it has been detected that no additional users' input is needed for processing the service request, a single click enables the user to select the application to which focus should be given.

Optionally, a web runtime module may perform a process similar to the one described above in order to determine the moment at which the processing of the service request is completed. In this case, the web runtime module automatically gives focus to the service provider application upon such a detection (optionally, consent of the user may be requested after detection and before giving focus to the service provider application). Such a process is described by reference to Figure 8.

Figure 5 illustrates an example of the process enabling a web runtime module of the web runtime environment to detect that no more users' inputs are needed to process a service request.

As illustrated, a first step (step 500) aims at checking whether or not processing the service request (SR) is to be indicated by the service provider application (SRA). This can be done by different ways.

According to a particular embodiment, service provider applications comprise means for indicating to a web runtime module that they have started processing a service request, typically through a dedicated method of the object corresponding to the service request.

The code of a given service provider application can be inspected to determine whether such a method is called. Alternatively, if different versions of a cooperation model between a service requester application and a service provider application are defined (e.g. Web Intents 1.0 and Web Intents 2.0), the version of a given service provider application may allow determining whether or not this service provider application can indicate processing a service request to the web runtime module. For the sake of illustration, a low version number may correspond to a first version of the model that does not comprise means for indicating processing a service request whereas a higher version number may correspond to another version according to which such means are provided to the service provider application. In some cases, the use of such version numbers can be mandatory.

It is noted that the web runtime environment can store the result of the test performed at step 500 in order to avoid repeating the same determination process each time the service provider application is used. However, such a determination process must be performed at least when the service provider application is updated.

If processing the service request is to be indicated by the service provider application, the latter is executed (step 505) and a test is performed at step 510 to determine whether or not the execution of the service provider application has indicated to the web runtime module that the service request is being piocessed.

If the service provider application has not indicated to the web runtime module that the service request is being processed, the process returns to step 505.

On the contrary, if the service provider application has indicated to the web runtime module that the service request is being processed, this means that it has been detected that there is no need for more users' inputs (step 515). Consequently, the process ends.

If the processing of the service request is not to be indicated by the service provider application (step 500), steps directly leading to processing the service request and/or steps resulting from processing the service request are identified (step 520).

Such an identifying step is further described by reference to Figure 6.

Next, at step 525, the service provider application is executed.

In a following step (step 530), it is determined whether or not a previously identified step leading to processing the service request has been detected.

If a previously identified step leading to processing the service request has not been detected, it is determined at step 535 whether or not a previously identified step resulting from processing the service request has been detected.

If a previously identified step resulting from processing the service request has not been detected, the process returns to step 525.

On the contrary, if a previously identified step leading to processing the service request has been detected or if a previously identified step resulting from processing the service request has been detected, this means that it has been detected that there is no need for more users' inputs (step 515). Consequently, the process ends.

As mentioned above, there exist several ways for a service provider application to indicate to a web runtime module that a service request is being processed and that no more users' input are needed.

According to a particular embodiment, a method is associated with the object representing the service request to indicate that processing the service request has started (such a method is automatically called when the service request starts). It can be called with a command such as serviceRequeststartProcessing.

According to another embodiment, a method is associated with the object representing the service request to indicate a current status, the current status preferably belonging to a list of possible statuses. The current status may comprise one of the following indications: "not started', "started' and "completed (the indication "started' indicates that processing the service request has started). It can be called with a command such as serviceRequestupdateStatus(currentstatus) where currentstatus represents the current status.

Still according to another embodiment, a method is associated with the object representing the service request to indicate current progress, such a current progress being, for instance, a percentage. It can be called with the command such as serviceRe quest. updateProgress (percentage) where percentage indicates the percentage. A percentage greater than zero indicates that the processing has started.

Still according to another embodiment, a method is associated to the object representing the service request to indicate that no more user inputs are needed for processing the service request. It can be called with a command such as serviceRequest.parametersObtained.

Alternatively, methods not associated with the object corresponding to the service request may also be defined, for instance a method enabling a web application to indicate that it does not require focus and that another application may be displayed (typically while a process is being performed).

It is noted that one of the advantages of using the service provider application to determine that a service request is being processed and no more users' inputs are needed is directed to the reliability of the response (since the determination is done by the application in charge of processing the request, the risk of error is very low). However, such a solution can be unavailable, especially if the model used for defining cooperation between the service requester application and the service provider application does not define such means.

Conversely, using a web runtime module to determine that a service request is processed and no more users' inputs are needed may lead to errors since the determination does not rely on an explicit declaration of the service provider application.

However, by correctly choosing the criteria used to determine that a service request is being processed and no more users' inputs are needed, such a risk can be greatly minimized, as described by reference to Figure 6. An advantage of this solution is that there is no need for the service provider application to explicitly indicate processing a service request and thus, this solution is more flexible and does not require specific support from the model used for defining the cooperation between the service requester application and the service provider application.

As mentioned above, embodiments of the invention are particularly useful to process service requests that require a significant amount of time to be processed.

Accordingly, the detection process illustrated in Figure 5 can be applied as a function of the types of the service requests, such as printing or saving. In addition, the process may be applied only if the processing time is assumed to be greater than a predefined amount of time, for example greater than 20 seconds. For the sake of illustration, if a small file is to be saved in a distributed remote storage system (cloud) or if a small number of pages of a document is to be printed, the detection process might not be performed.

Figure 6 illustrates an example of an algorithm for identifying a step directly leading to processing a service request or directly resulting from processing a service request.

The service type (SI) of the service request is obtained in a first step (step 600). Next, a test is performed to determine whether or not the obtained service type is related to data or message transmission over a network (step 605).

For the sake of illustration, in the case of a printing service, processing the printing request typically involves sending a "print job" message to a remote printer, the latter returning a "print job accepted' message if it accepts the print job. In such a case, if the web runtime module detects the "print job" message, it can consider that processing the service request is going to start. Similarly, if the web runtime module detects the "print job accepted' message, it can consider that processing the service request has started.

If the obtained service type is related to data or message transmission over a network, the corresponding transmission step is identified as a step leading to or resulting from the service request processing (step 610) and the process ends.

On the contrary, if the obtained service type is not related to data or message transmission over a network, the code of the service provider application enabling processing of the service request is analyzed in order to determine whether or not the code of the service provider application comprises a step linked to processing the service request (step 615). Since such a code relies on the use of the service request, tracking the usage of the service request in the code of the service provider application may enable determining a step leading to or resulting from processing the service request.

For the sake of illustration, in the case of a service request for saving data in a distributed remote storage system, the code includes a step of uploading data in a remote server.

If the analysis of the code of the service provider application enables determining a step leading to processing the service request (such as a call to a function responsible for uploading data to save) or resulting from the service request processing (e.g. start uploading data to save), such a step is identified as a leading step or as a resulting step (step 620) and the process ends.

On the contrary, if the analysis of the code of the service provider application does not allow to identify a step leading to processing the service request or resulting from the service request processing, the user interface (UI) of the service provider application is analyzed in order to identify the control elements enabling to start processing the service request (step 625). Such an analysis can be done by examining the different control elements of the user interface (e.g. HTML buttons), in particular their labels.

For the sake of illustration, a button enabling to start printing data typically comprises a label including the word print' or "printing" and possibly the word "start', "confir,'r/' or "validate".

After this analysis has been carried out, the step of clicking on the identified control element is identified as a step leading to service request processing (step 630) and the process ends.

The identified step should be selected so that no more users' inputs are needed after reaching this step to complete processing said service request.

Consequently, it is generally safer to rely on the identification of a step resulting from service request processing than to rely on the identification of a step leading to service request processing. However, if a step resulting from the service request processing cannot be determined, the determination of a step leading to service request processing is useful.

It is also to be noted that identifying a step of clicking on a control element (e.g. "print' button) may not be sufficient as such a control element may perform a check of parameters input by the user (e.g. checking the number of copies). If invalid parameters have been input, clicking on such a control element may not start processing the service request but indicate to the user that invalid parameter values should be fixed.

It is also to be noted that a given service type may be provided in different ways by different service provider applications or even by a single service provider application. For instance, a print service provider application may implement different protocols in order to be in a position to communicate with different remote printers.

Consequently, multiple steps are preferably identified as leading or resulting steps (at step 610), typically one step per printing protocol handled in the web runtime environment.

Additionally, a print service provider application may also rely on a distributed printing solution (also known as a cloud printing solution). Such a solution consists in sending a document to be printed to a server, the latter being responsible for sending the document to a selected printer. Therefore, in such cases, no printing protocol is used by the service provider application. Consequently, it can be understood that even if the service type of the service request is associated with data or message transmission, not all service provider applications will necessarily transmit messages that can be used as leading or resulting steps.

Accordingly, even if the service type is associated with data or message transmission, it may be useful to identify additional leading and/or resulting steps in order to increase the likeliness of detecting processing of the service request.

Practically, it means that even in case of a positive result at step 605 in Figure 6, alternative strategies such as the ones described by reference to steps 615 to 630 may be executed in order to define complementary leading and/or resulting steps.

It is noted that multiple leading and/or resulting steps may also be identified at steps 620 and/or 630.

It is to be recalled that prior art service provider applications typically display the progress of the processing of service requests in their user interface. As long as these service provider applications are displayed, this is likely to be sufficient.

However, when a service provider application is not displayed, while a service request is processed according to embodiments of the invention, there is a need for the service provider application to notify a web runtime module with the status of processing the current service request so as to allow the web runtime environment to display such a status in its interface.

Figure 7 illustrates an example of an algorithm for handling notifications, in particular status or progress notifications, received by a web runtime module from a service provider application.

As illustrated, a first step aims at obtaining, by a web runtime module, a notification from a service provider application (step 700).

Such a notification can be obtained, for example, by calling a method associated with the object corresponding to the service request, for example a method called by the command serviceRequest.updateStatus(..) or the command serviceRequestsetProgress(..).

The called method may rely on a predefined set of statuses (e.g. not started', "started', completed', and error") or on a value such as a percentage of completion of processing the service request. Both a predefined status and a value may be provided through the called method. A text message providing explanations about the current status may even be provided, especially in case of error.

Complementary data may also be provided. For the sake of illustration, in the context of a service implying image processing, a service provider application may provide a thumbnail corresponding to the currently processed image, which is progressively being refined up to completion.

In a following step, it is determined whether or not the service requester application that created the service request has subscribed to notifications (step 705).

Subscribing may be decided by the service requester application (e.g. through a specific parameter defined when creating a service request) or may be based on a default setting (e.g. always subscribe I never subscribe). This may be useful if the service requester application needs to obtain the processing result of the service request for another processing.

For example, an image editor acting as a service requester application may rely on a service provider application in order to apply specific filtering to an image.

While the filtering is being performed, the user may edit other images. If the image editor has subscribed to notifications, a specific component of its user interface may display the filtered image and the percentage of completion of the filtering process.

If the service requester application has subscribed to notifications, the received notification is forwarded to the service requester application by the web runtime module (step 710).

If the service requester application has not subscribed to notifications or after the received notification is forwarded to the service requester application, the notification is displayed in the web runtime environment through its user interface (step 715).

The notification can be displayed in different ways. For example, a progress bar can be used, possibly along with text if textual information is provided in the notification. Alternatively, if a percentage of completion is provided, such a percentage can be displayed. If several service requests are being performed at the same time, the web runtime environment can also provide a visual indication regarding the service request associated with the displayed notification (e.g. by displaying the name of the service requester application, of the service provider application, or by displaying data associated with the service request, for instance the name of a file to print or a thumbnail of a picture associated with said service request). The display of the notification does not need to remain visible for a long time. It can be decided, for example, to display each notification for only a few seconds.

It is noted that when processing a service request involves network exchanges (e.g. remotely printing a document), a web runtime module can determine the status of processing the service request by monitoring the network exchanges.

For instance, the web runtime module may detect the total amount of pages to be printed based on a first message sent to the printer. Based on this number and on number of pages already printed contained in progress notifications sent by the printer to the service provider application, the web runtime module can determine and display the current status of the processing, even if the service provider application does not provide it with notifications.

It is also noted that notifications can be displayed elsewhere than in the web runtime environment interface. In particular, the notifications can be displayed by the underlying operating system using a specific component dedicated to the display of notifications. An example of such a specific component is a top bar comprising various indicators (e.g. time, battery and connectivity) as well as notifications (e.g. SMS and emails). In particular, a specific icon may be used for each type of service, such as a printer icon for a notification related to a "print' service request.

Figure 8 illustrates switching the focus back to a service provider application upon detection of the end of processing a service request. Such a process is optionally performed after initial switching of the focus from the service provider application to another application.

The end of processing a service request is detected in a first step (step 800). Such detection can be done in several ways.

According to a particular embodiment, such a detection can be based on the completion of processing as determined from notifications regarding the status of processing the service request, received by a web runtime module from the service provider application.

Similarly, it can be considered that if a service provider application returns a result to the service requester application, processing the service request has ended.

Since such an exchange between a service provider application and a service requester application involves a web runtime module, the latter can therefore detect the end of processing the service request.

Nevertheless, it is noted that a service provider application may require a user input prior to returning a result and closing itself (e.g. clicking a "finish" button). In such a case, the step of returning a result cannot be used as a step indicating the end of processing the service request.

Consequently, another way of detecting the end of processing a service request consists in identifying a step implying the end of processing and in detecting such a step. Identifying such a step is typically based on the principles described by reference to Figure 6. In particular, such a step can be detected when a specific message is received from the network (e.g. "end of print job" message received by a print service provider) or when the execution or the end of execution of a specific function is detected, based on the analysis of the service provider application (e.g. detecting the end of sending data to be saved on a cloud server and/or displaying a finish" button enabling the user to validate a result returned by processing the service request to the service requester application).

Once detected, the end of processing a service request can be indicated in the web runtime environment user interface (step 805). This is typically achieved using similar means to the ones described by reference to step 715 in Figure 7. Focus is then given to the corresponding service provider application (step 810) and the process ends.

As explained above by reference to step 425 in Figure 4, giving the focus to the provider application may be dependent upon obtaining the consent of the user so as to avoid any confusion of the user. The user may also be able to define a default rule indicating whether or not his/her consent is required.

Figure 9 represents a block diagram of a computer device 900 in which steps of one or more embodiments may be implemented.

Preferably, the device 900 comprises a communication bus 902, a central processing unit (CPU) 904 capable of executing instructions from program ROM 906 on powering up of the device, and instructions relating to a software application from main memory 908 after the powering up. The main memory 908 is for example of Random Access Memory (RAM) type which functions as a working area of CPU 904 via the communication bus 902, and the memory capacity thereof can be expanded by an optional RAM connected to an expansion port (not illustrated). Instructions relating to the software application may be loaded to the main memory 908 from a hard-disc (HD) 910 or the program ROM 906 for example. Such software application, when executed by the CPU 904, causes the steps described with reference to Figures 2 and 4 to 8 to be performed in the computer device.

Reference numeral 912 is a network interface that allows the connection of the device 900 to the communication network 914. The software application when executed by the CPU 904 is adapted to react to requests received through the network interface and to provide data and requests via the network to other devices.

Reference numeral 916 represents user interfaces to display information to, and/or receive inputs from, a user.

It should be pointed out here that, as a variant, the device 900 for processing data can consist of one or more dedicated integrated circuits (ASICs) that are capable of implementing the method as described with reference to Figures 2 and 4 to 8.

Naturally, in order to satisfy local and specific requirements, a person skilled in the art may apply to the solution described above many modifications and alterations all of which, however, are included within the scope of protection of the invention as defined by the following claims.

Claims

CLAIMS1. A method for processing a service request in a web runtime environment, the method comprising: -receiving, in a module of the web runtime environment, a service request from a service requester application; -loading, into the web runtime environment, a service provider application enabling processing of the service request and transmitting the service request to the loaded service provider application; -executing the service provider application in the web runtime environment, executing the service provider application causing display of a first user interface associated with the service provider application for obtaining user inputs; -detecting that user inputs required for processing the service request have been received; and -in response to detecting that user inputs have been received, displaying a second user interface independent from the service provider application.
2. The method of claim 1 wherein the first user interface associated with the service provider application is displayed until it is detected that the user inputs required for processing the service request have been received.
3. The method of claim 1 or of claim 2 wherein the service provider application is executed as a background task after displaying the second user interface.
4. The method of any one of claims ito 3 wherein the step of detecting that user inputs required for processing the service request have been received comprises a step of receiving a notification from the service provider application that the service request is being processed or is ready to be processed.
5. The method of claim 4 wherein the received notification comprises a status or a completion level of processing the service request.
6. The method of any one of claims ito 5 wherein the step of detecting that user inputs required for processing the service request have been received comprises a step of detecting that an identified step leading to processing the service request or resulting from processing the service request has been carried out.
7. The method of claim 6 further comprising a step of identifying the step leading to processing the service request or resulting from processing the service request.
8. The method of claim 7 wherein the step of identifying the step leading to processing the service request or resulting from processing the service request comprises a step of recognizing a predetermined message or predetermined data transmitted or received by the web runtime environment over a network.
9. The method of claim 7 wherein the step of identifying the step leading to processing the service request or resulting from processing the service request comprises a step of determining the type of the requested service, of analyzing instructions of the service provider application, or of analyzing a user interface element of the service provider application.
10. The method of any one of claims ito 9 further comprising a step of detecting the end of processing the service request.
11. The method according to claim 10 wherein the step of detecting the end of processing the service request comprises a step of receiving a notification from the service provider application, the notification comprising a status or a completion level of processing the service request, or of recognizing a predetermined message or predetermined data transmitted or received by the web runtime environment over a network.
12. The method of any one of claims 1 to 11 further comprising a step of displaying an indication relative to a status or a completion level of processing the service request, the indication being displayed in the second user interface.
13. The method according to claim 12 further comprising a step of displaying a description of the displayed indication, the description to be displayed being received along with the status or the completion level of processing the service request.
14. The method of any one of claims ito 13 further comprising a preliminary step of analyzing characteristics of the service request, the step of displaying the second user interface in response to detecting that user inputs have been received being carried out in response to the preliminary analyzing step.
15. The method of claim 14 wherein the step of analyzing characteristics of the service request comprises a step of determining the type of the service request.
16. The method of claim 14 or claim 15 wherein the step of analyzing characteristics of the service request comprises a step of estimating the amount of time required for processing the service request.
17. The method of any one of claims 1 to 16 wherein the second user interface is associated with the service requester application.
18. A computer program product for a programmable apparatus, the computer program product comprising instructions for carrying out each step of the method according to any one of claims 1 to 17 when the program is loaded and executed by a programmable apparatus.
19. A computer-readable storage medium storing instructions of a computer program for implementing the method according to any one of claims ito 17.
20. A device for processing a service request in a web runtime environment, the device comprising at least one microprocessor configured for carrying out the steps of: -receiving, in a module of the web runtime environment, a service request from a service requester application; -loading, into the web runtime environment, a service provider application enabling processing of the service request and transmitting the service request to the loaded service provider application; -executing the service provider application in the web runtime environment, executing the service provider application causing display of a first user interface associated with the service provider application for obtaining user inputs; -detecting that user inputs required for processing the service request have been received; and -in response to detecting that user inputs have been received, displaying a second user interface independent from the service provider application.
21. The device of claim 20 wherein the at least one microprocessor is further configured so that the first user interface associated with the service provider application is displayed until it is detected that the user inputs required for processing the service request have been received.
22. The device of claim 20 or of claim 21 wherein the at least one microprocessor is further configured so that the service provider application is executed as a background task after displaying the second user interface.
23. The device of any one of claims 20 to 22 wherein the at least one microprocessor is further configured so that the step of detecting that user inputs required for processing the service request have been received comprises a step of receiving a notification from the service provider application that the service request is being processed or is ready to be processed.
24. The device of any one of claims 20 to 23 wherein the at least one microprocessor is further configured so that the step of detecting that user inputs required for processing the service request have been received comprises a step of detecting that an identified step leading to processing the service request or resulting from processing the service request has been carried out.
25. The device of claim 24 wherein the at least one microprocessor is further configured for carrying out a step of identifying the step leading to processing the service request or resulting from processing the service request.
26. The device of claim 25 wherein the at least one microprocessor is further configured so that the step of identifying the step leading to processing the service request or resulting from processing the service request comprises a step of recognizing a predetermined message or predetermined data transmitted or received by the web runtime environment over a network.
27. The device of claim 25 wherein the at least one microprocessor is further configured so that the step of identifying the step leading to processing the service request or resulting from processing the service request comprises a step of determining the type of the requested service, of analyzing instructions of the service provider application, or of analyzing a user interface element of the service provider application.
28. The device of any one of claims 20 to 27 wherein the at least one microprocessor is further configured for carrying out a step of detecting the end of processing the service request.
29. The device according to claim 28 wherein the at least one microprocessor is further configured so that the step of detecting the end of processing the service request comprises a step of receiving a notification from the service provider application, the notification comprising a status or a completion level of processing the service request, or of recognizing a predetermined message or predetermined data transmitted or received by the web runtime environment over a network.
30. The device of any one of claims 20 to 29 wherein the at least one microprocessor is further configured for carrying out a step of displaying an indication relative to a status or a completion level of processing the service request, the indication being displayed in the second user interface.
31. The device according to claim 30 wherein the at least one microprocessor is further configured for carrying out a step of displaying a description of the displayed indication, the description to be displayed being received along with the status or the completion level of processing the service request.
32. The device of any one of claims 20 to 31 wherein the at least one microprocessor is further configured for carrying out a preliminary step of analyzing characteristics of the service request, the step of displaying the second user interface in response to detecting that user inputs have been received being carried out in response to the preliminary analyzing step.
33. The device of claim 32 wherein the at least one microprocessor is further configured so that the step of analyzing characteristics of the service request comprises a step of determining the type of the service request.
34. The device of claim 32 or claim 33 wherein the at least one microprocessor is further configured so that the step of analyzing characteristics of the service request comprises a step of estimating the amount of time required for processing the service request.
35. A method for processing service requests in a web runtime environment substantially as hereinbefore described with reference to, and as shown in Figures 2 and 4 to 8.
36. A device for processing service requests in a web runtime environment substantially as hereinbefore described with reference to, and as shown in Figure 9.