GB2506369A

GB2506369A - Control of service requests communication in a web runtime environment

Info

Publication number: GB2506369A
Application number: GB1217214.4A
Authority: GB
Inventors: Romain Bellessort; Youenn Fablet; Herva Ruellan
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2012-09-26
Filing date: 2012-09-26
Publication date: 2014-04-02
Also published as: GB201217214D0

Abstract

The invention relates to a method of controlling communication in a web runtime environment of a device between a service requester application adapted to generate service requests and a service provider application adapted to process the service requests. The method comprising the following steps performed by a controller of the web runtime environment: obtaining (S420) parameters defined by the service provider application for the processing of a service request, enabling value setting (S430) for the obtained parameters; and transmitting (S440) to the service provider application a service request received from the service requester application with the set parameters. The service provider application is preferably selected from a list presented on a graphical user interface (GUI).

Description

TITLE OF THE INVENTION

Control of service requests communication in a web runtime environment

BACKGROUND OF THE INVENTION

The invention relates to the field of web services. The invention concerns particularly the enabling of the setting of parameters associated with a service request generated by a service requester application run by a web runtime environment and intended to be piocessed by a service provider application.

Providing services over the web such as sharing of contents is becoming widespread as the number of web enabled devices is increasing significantly. Although services available over the web rely mostly on the client/server model where a client web application exchanges data with a web server, increasingly client web applications need to pass data between each othei when running on a same client device. This is aimed to enhance the provided service and user experience.

In this context, ii is known to have a service requester web application run by a web browsei making a service request towaids anothei web application hosted by the same web browser, the service requester application possibly providing parameters along with the service request to the web browser. For instance, a photo album application may request photos (pick" service) from another application adapted to provide photos, and the photo album may specify a specific parameter defining a type of photo requested.

This type of request doesn't apply however properly in the current communication model (which is aimed to maintain web applications dissociated) because compatibility issues may arise between the service requester application and the application providing the service.

It is therefore sought to improve the way web applications can exchange data while maintaining a loose coupling between them and keeping an open architecture that makes it possible to plug-in applications form different developers.

SUMMARY OF THE INVENTION

To this end, the present invention provides according to a first aspect a method of controlling communication in a web runtime environment of a device between a service requester application adapted to generate service requests and a service provider application adapted to process the service requests, the method comprising the following steps performed by a controller of the web runtime environment: obtaining parameters defined by the service provider application for the processing of a service request; enabling value selling for the obtained parameters; and transmitting to the service provider application a service request received from the service requester application with the set parameters.

The parameters that are used for processing the request are those defined by the service provider application, which provides better results and user experience.

Indeed, the parameters defined by the service requester application, if any, may differ from those provided by the service requester application. Thus, best benefit is taken from what the service provider application has to offer in terms of features. Better compatibility is also ensured.

In one implementation, the method further comprises a step of receiving a service request generated by the service requester application, said service request being then transmitted at the transmitting step to the service provider application with the set parameters.

Preferably, the service provider application is selected among a list of service provider application candidates adapted to process the service request generated by the service requester application.

In one variant, the selection of the service provider application is performed based on user input obtained via a graphical user interface. In this variant, the service provider application candidates are displayed along with their associated parameters in the graphical user interface so that to provide the user with information prior performing the selection.

Preferably, the method comprises a step of obtaining parameters defined by each service provider application candidate and wherein the selecting of the service provider application is performed based on the parameters defined by the service provider application candidates.

In a variant, the method comprises a step of obtaining parameters defined by each service provider application candidate and parameters defined by the service requester application and/or the web runtime environment, and wherein the selecting of the service provider application is performed based on the matching between the parameters defined by the service requester application and/or the web runtime environment and the parameters defined by each service provider application candidate.

In one implementation, the selection of the service provider application is performed by the controller based on pre-defined rules.

Preferably, the controller causes the display of graphical user interface (GUI) components enabling the user to set values for the obtained parameters, defined by the service provider application.

In one implementation, the controller causes the display via the GUI components of defaults values for one or more of the obtained parameters, the default values can be validated or changed by the user with other values to set values for the one or more parameters.

Advantageously, the above defaults values are obtained from a list of possible values containing at least one of the following: values obtained by applying user-defined rules; values defined by the service requester application and/or the web runtime environment; values defined and/or refined by a service provider application; values set in previously transmitted service requests; and relevant values defined by the web runtime environment.

In one implementation, the list of possible values is stored in a web storage unit, the web runtime environment controller having access to the web storage unit for retrieving values to be used as default values.

In a variant implementation, the controller performs an automatic setting of parameters values based on obtained default values. These default values may be obtained from a list of possible values containing at least one of the following: values obtained by applying user-defined rules; values defined by the service requester application and/or the web runtime environment; values defined and/or refined by a service provider application; values set in previously transmitted service requests; and relevant values defined by the web runtime environment.

In a preferred implementation, the step of obtaining the parameters defined by the service provider application is based on parsing a code portion of said service provider application containing a description of said parameters. The code is not necessarily parsed each time parameters need to be obtained. The obtaining of the parameters involves the parsing of the code the first time the service provider application is loaded for example. Obtained parameters are then saved in a storage unit and obtained again form the storage unit when the parameters are to be displayed for example.

In one implementation, the description of said parameters is written in one of the following formats: as attributes of an XML element defining the parameters; as XML elements, each element defining one parameter; and as a JSON object.

According to a second aspect of the present invention there is provided a device for controlling communication in a web runtime environment between a service requester application adapted to generate service requests and a service provider application adapted to process the service requests, the device comprising: obtaining means for obtaining parameters defined by the service provider application for the processing of a service request; enabling means for enabling value selling for the obtained parameters; and transmitting means for transmitting to the service provider application a service request received from the service requester application with the set parameters.

The present invention also extends to programs which, when run on a computer or processor, cause the computer or processor to carry out the method described above or which, when loaded into a programmable device, cause that device to become the device described above. The program may be provided by itself, or carried by a carrier medium. The carrier medium may be a storage or recording medium, or it may be a transmission medium such as a signal. A program embodying the present invention may be transitory or non-transitory.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the invention will now be described, by way of example only, with reference to the drawings in which; figure IA illustrates a web runtime environment run by the operating system of a processing device; figure lB illustrates a variant web runtime environment consisting of an operating system enabled to run directly web applications; figure 2 schematically illustrates a processing device configured to implement a web runtime environment according to at least one embodiment of the present invention; figure 3 schematically illustrates an architecture model of the web runtime environment according to embodiments of the invention; figure 4 is a flowchart that describes the process of handling service requests generated by a service requester application according to an embodiment of the invention; figure 5 is a flowchart that describes the process of handling service requests by the Web runtime environment according to an embodiment of the invention in which the WRE requests the user to select a service provider application; figures 6A, 6B and 6C illustrate various solutions that can be used by a service provider application to define its supported parameters; figure 7 is a flowchart that describes the possibility for a service provider application to provide the WRE with feedback information on used parameters values; figure 8 is a flowchart that describes the process of determining possible values that can be taken by a given parameter according to a particular implementation of the invention; figure 9 illustrates a communication scenario between a service requester application and a service provider application controlled by the web runtime environment controller according to an embodiment of the invention; and figures 1OA and lOB provide an illustration of the scenario of Figure 9 in a web browser.

DETAILED DESCRIPTION OF THE INVENTION

Figures lA and lB illustrate a web runtime environment (WRE) in accordance with embodiments of the present invention. A web runtime environment is an environment able to run the code of web applications, by parsing and executing the instructions contained therein. Code instructions are typically written in HTML (Hypertext Markup Language) and JavaScript.

Figure 1A illustrates a web runtime environment (WRE) 120 which is run by the operating system 110 of a processing device such as a computer device. The WRE retrieves the code of web applications 115, for instance by loading the applications from URLs (Uniform Resource Locators), and runs the corresponding code instructions. Web applications 115 may represent distinct applications or several instances of an application, i.e. the same code loaded and executed several times. Unless otherwise stated, when reference is made in the following to different applications, these applications may be distinct applications, several instances of one application or several instances of distinct applications.

An end-user web browser is an example of a web runtime environment according to figure 1A which enables running web applications by inputting URLs.

Figure lB illustrates a variant web runtime environment 130 consisting of an operating system enabled to run directly web applications. In this case, instead of being loaded in a web browser, the application is run by the operating system, using for example a specific command and rendered in a dedicated window. An example of such operating system is Firefox OS.

In either implementation of the WRE, it is to be noted that web applications loaded by the WRE may be retrieved from a server or a storage unit located in the same Is processing device as the device hosting the WRE, or located in a remote device connected to the processing device through a communication network. The remote device can be located in the same local area network as the processing device or in a distant network.

Alternatively, web applications retrieved by the WRE may be natively installed on the processing device. This is for example the case for Firefox OS, whose applications are written for example in HTML version 5.

Thus, the web runtirne environment should be understood as a software application adapted to run web applications obtainable from different sources such as Intranet, Internet or as a standalone software application running web applications natively installed. In either case, the WRE is purely a client-side application, distinct from the web servers it may interact with for downloading applications.

Embodiments of the invention described here below are considered to be implemented by a web runtime environment as illustrated by any one of the figures 1A and lB.

Figure 2 schematically illustrates a processing device 200 configured to implement a web runtime environment according to at least one embodiment of the present invention. The processing device 200 may be a device such as a computer, a micro-computer, a workstation or a light portable device, e.g. a smartphone. The device 200 comprises a communication bus 213 to which there are preferably connected: a central processing unit 211, such as a microprocessor, denoted CPU; a read only memory 207, denoted ROM, for storing computer programs for running the operating system of the processing device and the WRE; a random access memory 212, denoted RAM, for storing the executable code of the methods of embodiments of the invention; and a screen 209 for rendering loaded web applications (web pages) and/or serving as a graphical user interface for inputting data from the user, by means of a keyboard 210 or any other means (e.g. mouse or touchscreen).

Optionally, the apparatus 200 may also include the following components: a communication interface 202 connected to a communication network 203 over which digital data is exchanged with other processing devices, e.g. a remote web server or a storage unit.

a non-volatile data storage means 204 such as a hard disk, for storing computer programs or applications code for implementing methods of one or more embodiments of the invention and data used or produced during the implementation of one or more embodiments of the invention; and a disk drive 205 for a disk 206, the disk drive being adapted to read data from the disk 206 or to write data onto said disk; The apparatus 200 can be connected to various peripherals, such as for example a digital camera 200 or a microphone 208, each being connected to an input/output card (not shown) so as to supply multimedia data to the apparatus 200.

The communication bus provides communication and interoperability between the various elements included in the apparatus 200 or connected to it. The representation of the bus is not limiting and in particular the central processing unit is operable to communicate instructions to any element of the apparatus 200 directly or by means of another element of the apparatus 200.

The disk 206 can be replaced by any information storage medium such as for example a compact disk (CD-ROM), rewritable or not, a ZIP disk or a memory card and, more generally, by an information storage means that can be read by a microcomputer or by a microprocessor, integrated or not into the apparatus, possibly removable and adapted to store one or more programs whose execution enables the methods according to the invention to be implemented.

The executable code may be stored either in read only memory 207, on the hard disk 204 or on a removable digital medium such as for example a disk 206 as described previously. According to a variant, the executable code of the programs can be received by means of the communication network 203, via the interface 202, in order to be stored in one of the storage means of the apparatus 200, such as the hard disk 204, before being executed.

The central processing unit 211 is adapted to control and direct the execution of the instructions or portions of software code of the program or programs according to embodiments of the invention, which instructions are stored in one of the aforementioned storage means. On powering up, the program or programs that are stored in a non-volatile memory, for example on the hard disk 204 or in the read only memory 207, are transferred into the random access memory 212. which then contains the executable code of the program or programs, as well as registers for storing the variables and parameters necessary for implementing the invention.

Figure 3 schematically illustrates an architecture model of the WRE according to embodiments of the invention. As illustrated, the WRE enables different applications, or instances thereof, to communicate with each other within the device hosting the WRE (without the involvement of a web server) under the control of a web runtime controller (WRE controller) 340.

According to the model, the WRE controller 340, which is part of the web runtime environment 310, is in charge of controlling the communication between a service requester application (SRA) 320 and a service provider application (SPA) 330. Although one SPA and one SPA are represented, the model does not limit the number of applications involved in the communication and the WRE controller may for example control the communication between a service requester application and a plurality of service provider applications.

The service requester application 320 is a web application loaded and run in the web runtime environment 310 according to the model ot web applications 115 ot figure 1A or 1 B. The service requester application is for example a web page (client web application) containing HTML and JavaScript code that can be loaded, parsed and rendered by a web browser representing the WRE. Of course, the service requester application is not necessarily a web application and in an alternate implementation the application 320 may be run outside the WRE by another runtime environment such as the operating system of device 200.

The service requester application 320 is an application adapted to generate service requests towards one or more service provider applications that are capable of rendering (executing) services such as application 330. The provided service can be for example of type Share", "Edit", "Pick" for sharing, editing and picking a digital content respectively. Also, the service requester application typically implements an interface for receiving a (result) data object provided by the service provider application in response to the generated service request.

Practically, the service requester application generates a service request in the form of a request object and passes it to the controller, or in the form of arguments passed to the controller which would then be in charge of generating the request object.

The request object represents thus from an implementation point of view the means by which a service is requested by a service requester application. The request object may contain payload data needed by the provider application to provide the service. For example, "Edit" and "Share" services need payload data (e.g. images, text, etc.) that is to be edited and shared respectively. The request object may also contain the necessary information (methods) on how to interface to the service requester application as well as parameters in the form of (key, value) pairs representing the mandatory/optional arguments to be used by the service provider application when processing the request object. As it will be discussed in more details in the different embodiments of the invention, parameters and their values may be provided by the SPA in the generated service request (referred to as SPA-defined parameters), or provided by the WRE (WRE-defined parameters). In this latter case, the WRE may prompt user to input values for the parameters via an appropriate GUI (Graphical User Interface). The SPA may also define parameters (SPA-defined parameters) which correspond to the parameters that are expected by the service provider application to provide a requested service (cf. figures 6A to 6C for examples of SPA-defined parameters).

A request object is for example a JavaScript object created by a web client application acting as a service requester application. When the object is created, the client web application adds attributes for defining the request, such as for example the requested service (e.g. "Share", "View", Edit'...), the payload data associated with the service (e.g. title and URL of an article to be shared, image to be edited, ...) and the type of payload data (e.g. "text", "image", "audio",...).

Any other type of request object may alternatively be used. As an example, the request object can be a Web Intent object as defined by the World Wide Web Consortium (W3C) for modeling a particular task which can be requested to be handled by a web page or a web application.

The client web application may add also methods to the JavaScript object, referred to as call-back methods, defining the API of the web application. The methods can be called to provide the service requester application with returned data objects in case of success or failure of the execution of the requested service.

One role of the controller is to keep the service provider and service requester applications independent while maintaining the communication between them. This makes it possible to develop applications independently without rising compatibility issues and by increasing security. For that, call-back methods defined by the requester application are not made directly accessible to the service provider application for providing its resulting data object (i.e. the service requester application does not expose an API to the service provider application), but generic methods are added or linked to the request object to be communicated to the service provider application. On the WRE side, the controller maintains a correspondence between the generic methods and the call-back methods defined by the requester application and which are associated with the service request. For example, postResult() and postFailure() define generic methods to be used in case of, respectively, successful or unsuccessful processing of a request object. In operation, the provider application calls a generic method to give a data object to the controller, and the controller calls in turn the corresponding call-back function to deliver the data object to the service requester application.

In response to a service request generated by the service requester application 320, Web runtime environment typically displays a list of possible service provider applications that can provide the requested service. The Web runtime environment then loads one service provider application 330 from the list, after a selection by a user for example. According to embodiments of the invention, possibility is given to the user to perform the selection based on the parameters defined by each SPA, and to set (e.g. input or validate) values of the parameters associated with the request prior their communication to the selected SPA. It should be noted here that the parameters relied upon for the selecting of an SPA or for the setting of values are SPA-defined defined parameters instead of being SRA-defined parameters. This makes the proposed model more accurate and enhances the synergy of communication between applications of the WRE while keeping user operations smooth.

If several service requests are generated, the above operations of displaying a list of SPAs, selecting and loading the selected SPA(s) are repeated. Several service provider applications may be loaded by the WRE if different service provider applications have been selected to serve the several service requests (not illustrated in figure 3).

The service provider application 330 is a web application loaded and run in the web runtime environment 310 according to the model ot web applications 115 ot figure 1A or 1 B. The service provider application 330 is preferably coded using a combination of JavaScript and HTML.

The execution of the service provider application enables to provide different services (we can say also perform actions) on payload data (contents) such as "Share", "View", "Edit" and "Pick" services. Typically, the service provider application provides its service in response to the reception of a service request (request object) with associated parameters, via the controller, from the service requester application 320. As it will be discussed later, the parameters can be communicated to the SPA in the service request, or separately from the service request. Also, the communicated parameters are not necessarily SRA-defined parameters, but can be WRE-defined parameters to better match the SPA-defined ones.

In addition to the performed actions, the service provider application may be adapted to provide, during its execution by the WRE, data objects resulting from the execution of the service, intended for the service requester application. For example, if the provided service is editing an image ("Edit" service), the provided data object would contain the edited image. It is to be noted that applications providing different services may still return a same type of data object; for example applications providing "Edit" and "Pick" services applied to an image payload would both return a same data object type containing the edited image and the picked image respectively. A provided data object can also be void or containing only status information on the execution of the associated service. For example, if the provided service is sharing an image ("Share" service), a void data object may be returned.

A data object provided by the provider application is passed to the controller for delivery to the service requester application 320.

Optionally, a web storage unit 350 controlled by the WRE and used by this latter to store various types of information, such as browsing history and parameters, is provided. In a preferred embodiment of the invention, the WRE implements an API that makes it possible for web applications to access the web storage unit 350 if they are given the appropriate access rights by the WRE controller. In fact, for security reasons, the WRE has to control the access to the information stored in the web storage unit 350, and typically a web application is granted access only to the information it has previously stored in the storage unit.

Giving access to web applications to the web storage unit is particularly advantageous for example for the SPA to have the possibility to store a history of its defined parameters and their corresponding values in the form of (key, value) pairs as it will be discussed later. This information can then be retrieved by the WRE controller 340 and used to make suggestions (default values proposal) to the user via the GUI when setting parameter values associated with a new service request to be communicated to SPA 330.

The web storage unit 350 is preferably implemented locally in device 200 for example by dedicating storage space in hard disk 204. Alternatively, the storage unit 350 is external to device 200. The API provided by the WRE for accessing the web storage unit 350 may be compliant with W30 web storage specifications (cf. http://wwww3.org/TR/webstoraQe/).

It is to be noted that the destination application is not necessarily a web application and can be, in an alternate implementation, an application run outside the WRE by another runtime environment such as the operating system of device 200. In this implementation, the WRE provides an interface reachable by the destination application to enable said destination application to send service requests to the WRE controller; additionally, destination application has to declare to WRE an interface to receive data objects from said controller, this interface being possibly communicated by the destination application along with a service request. Once the service requester application has provided its service request to the WRE, WRE handles this request as it would handle one submitted from a web application run by the WRE. Also, the service provider application communicates a data object to the WRE directed to a destination application as if the destination application is a web application loaded and run by the WRE.

As an example, a requester application running outside the WRE is a photo editing application run by the operating system in the case of embodiment of figure 1A (i.e. the WRE distinct from the operating system). This application may have a Pick from Web" button to pick a photo from a social network. The WRE provides an interface accessible to applications run by the operating system enabling them to transmit a request object. By using the interface, the photo editing application can transmit a service request for a photo. The WRE would then serve this service request as a request coming from a web application, typically by displaying a list of possible service provider application for "Pick" and then forwarding request to the selected service provider application.

According to an embodiment of the invention, the request object is made available to the service provider application by a Web runtime controller 340 through a request object queue. The implementation of request object queue advantageously makes it possible to select a same service provider application for serving several service requests. There is thus no need to create several instances of the service provider application if this latter has been selected for serving several service requests. Also, the queue gives the possibility to implement service provider applications capable of providing complex services taking several request objects as input.

Figure 4 is a flowchart that describes the process of handling service requests generated by the service requester application 320 according to an embodiment of the invention. The process is run in the web runtime environment.

First, at step 5400, WRE controller 340 receives a service request from the service requester application 320. At the next step S410, a service provider application that is capable of serving the requested service is determined. The determination of the SPA can be done in several ways: from the service request if the SRA has explicitly defined a SPA to be used for handling the service request; or from a user input, for instance: -by the display of a list of SPA candidates by the WRE and then the selecting of one of them by the user (more details about this scenario are provided in figure 5), or -by means of a specific graphical user interface (GUI) like a button that displays a pre-selected SPA, obtained by applying some user-defined rules or by relying on history information of previously selected service provider applications; the user can then confirm the pre-selected SPA by clicking on the corresponding button. The GUI may be either managed by the SRA or the WRE.

Once a SPA has been determined for serving the request, parameters defined by this SPA for processing the service request are then obtained at step S420. When the determined SPA is loaded by the WRE, WRE parses the code of the SPA and identifies the parameters supported by the SPA.

Various solutions can be used by a SPA to define its supported parameters, some of them being illustrated on figures 6A, 6B and 60.

First, it should be noted that a possible way for a SPA to advertise its ability to provide a service consists in including a specific element in its source code, e.g. a "service" element in its HTML code. Then, this "service" element is typically characterized by attributes describing the action performed by the service (e.g. action="pick") and possibly other properties of the service, such as the type of the data supported (e.g. type="image"). Such element is then a natural and appropriate place where to insert the definition of the supported parameters. Figure 6A and 6B illustrate two possible ways of doing so, with two different kinds of service.

Figure 6A relies on an attribute named "parameters" to describe the different parameters supported. The value of this attribute is a semi-colon-separated list of (parameter name, parameter type) items. In this example, SPA defines a parameter "keywords" whose value is a string (such value could also be a list of strings), a parameter "width" whose value is an integer, a parameter "height" whose value is an integer, and parameters "start" and "end" representing date and time. These parameters are defined for a "pick" service provider, which provides contents ot type "image". As a consequence, a user may for instance be able to filter images associated to given keywords, having a resolution of "width" x "height" pixels and having been taken in the timeframe comprised between "start" and "end".

As an alternative, figure 6B illustrates the use of dedicated elements to describe supported parameters. Each parameter is described by a "parameter" element, "parameter" elements being comprised in the "service" element (this makes sense as the parameters are defined for this service particularly). Each "parameter" element has two main attributes: "name", to define the parameter name, and "type", to define the parameter type. Optionally, a "value" attribute may be added in order to define possible values for a given parameter. In this example, two parameters are defined: a "name" parameter, whose value is a string, and a "filter" parameter, whose value is a string, said string possibly being "sepia", "vintage" or "blur" (such list of values may or may not exclude other values; to avoid ambiguity, another attribute may be defined, such as a "strict" attribute whose value would be a Boolean indicating whether other values are allowed or not). As it can be understood from figure 6B, this service is an "edit" service, applicable to "image" content types; "name" represents the name of the image to be edited, and "filter" represents the name of an image filter to be applied to the edited image.

Finally, figure 6C provides the same kind of information as what is illustrated in figures 6A and 6B, but using JSON format instead of XML mark-up. JSON format may for instance be used in a web application manifest, a file which describes various characteristics of a web application. In this case, the service described is a "view" service meant to display images. The parameters defined to handle corresponding service requests are "name", which is a string corresponding to the name of the image to display, and "mode", which is a string corresponding to a display mode selected among "thumbnail", "normal" and "full-screen".

Even though not illustrated in these figures, other properties may be defined for each parameter. As an example, defining whether each parameter is mandatory or optional may be useful so that WRE knows which parameters require a value. As another example, a property may define whether the setting of a value of one parameter depends or not on the value of another parameter. For instance, a service providing images and videos may define a "media-type" parameter whose value is "image" or "video"; if the value is "video", then a parameter "duration" may be enabled, whereas this parameter would not be enabled if the value of "media-type" parameter were "image".

Preferably, the identified parameters are stored in association with the corresponding SPA by the WRE for later re-use. This avoids parsing again the code of the application if it is selected again for serving another service request. When a given SPA is loaded by WRE, WRE parses parameters definitions as discussed above and typically stores the parameters and their values, if any, for example in web storage unit 350. As a consequence, because the parameters are not supposed to change frequently for a given SPA, WRE can display the parameters defined by said SPA without having to load it first.

If the history of parameters is empty in the storage unit 350 for a given SPA, the SPA is loaded and parsed for identifying its corresponding parameters. In the context of the handling of a service request, if the parameters displayed by the WRE happen to be different from the actual parameters for a given SPA (this can be checked while WRE finally loads the SPA), WRE can notify user and enable her/him to set values for the updated (newly defined) parameters. The WRE may also enable user to cancel the transmission of service request to the SPA (indeed, user may no more want to select said SPA if defined parameters are not the same, e.g. if the parameter the user relied on when selecting the SPA is no more available, such as the absence of parameter "keyword" for the selected service provider application).

SRA-defined parameters may also exist, for instance because they are generally supported by SPA or because they are defined in a specification related to the kind of service requested by SRA. However, this does not imply that the determined SPA (S410) has support for such parameters. Various solutions can be used in order to handle these parameters: * removal: WRE may remove such parameters from the service request if they are not supported by the determined SPA in order to avoid transmitting useless information; * preservation: WRE may preserve such parameters in the service request even if they are not explicitly defined as supported parameters by SPA; indeed, SPA may for instance check for the presence of this parameter and use it under another name (e.g. SPA defines "tag" as one of its parameters, but knows that SRA often use "keyword"; then, SPA may check for the presence of a "keyword" parameter and use its value in lieu of/in addition to "tag" parameter's value); * In case of preservation, WRE may even enable value setting for such parameters at step 5430.

If SRA defines a value for a given parameter and the determined SPA supports that parameter, WRE would advantageously use SRA's value as default value for said parameter (this is described with more details in figure 8).

Back to the description of figure 4, and following the obtaining of the parameters that can be handled by the SPA at step S420, the setting of values for these obtained parameters is enabled at step 5430. This is typically achieved by displaying the determined parameters along with text fields or other user interface components enabling a user to set values for said parameters; such user interface components may for instance include a drop-down list to restrict the possible values to a limited set or a calendar to set a date.

It should be noted that optionally, a step of determining default values for the obtained parameters may be run by the WRE controller. By doing so, user may benefit from having the values already pre-set without having to enter them manually. User can also edit the default values if he/she is not happy with them. Similarly, the editing may be eased by the determination of suggested values by WRE (figure 8 describes a possible implementation for this optional step).

At step 3440, the service request is transmitted to the determined SPA with the set parameters, which means parameters associated with their values. The parameters themselves may be identified by their names or keys; set parameters forming thus pairs of names or keys and values.

The transmission is typically performed by associating the parameters and the values to the service request. For instance, if the service request is represented as an object having a "parameters" dictionary, each parameter name and its associated value can be added to this dictionary as a (key, value) pair.

Alternatively, parameters may also be transmitted through URLs. For instance, a given SPA available at a given URL may support the passing of parameters by appending them at the end of that URL. For example, if a given SPA is available at http:t/example.comtSPA, a parameter "keyword" having the value "sky" may be passed as http://example.com/SPA?keyword=sky or as http://example.com/SPA#keyword=sky.

These two variants are slightly different; as it is known to the person skilled in the art, in the first case (use of a question-mark after SPA's URL, known as query string), the parameters have to be provided while the URL is being requested (HTTP GET request), whereas in the second case (use of hash tag after SPA's URL). the parameters can be passed independently from the loading of said URL. Therefore, if SPA is already loaded, the second solution may be more advantageous (i.e. use of hash tag instead of question-mark).

Figure 5 is a flowchart that describes the process of handling service requests by the Web runtime environment according to an embodiment of the invention in which the WRE requests the user to select a service provider application.

At step 5500 a service request is received from a SRA. Then at step S510, SPA candidates representing possible SPAs capable of handling the received request are determined. For this, the WRE typically examines a list of SPAs previously registered by the WRE to select those capable of processing the type of service request received.

Alternatively or in addition, particularly if no suitable service provider application has been found in the list of registered applications maintained by the WRE, other external registries may be consulted by the WRE, for instance online registries of SPAs.

The determination of SPA candidates is followed by the obtaining of parameters defined by each SPA candidate for the processing of the service request (step 5520).

This step is similar to step S420 repeated for each SPA candidate.

At step 5530, the list of SPA candidates with their associated parameters are displayed via a GUI to enable the user to select among these SPAs and to input the corresponding parameter values if necessary. Different solutions may exist for constructing that GUI, a few examples are presented below: * display of each SPA candidate along with its associated parameters names and a GUI component (e.g. text field) for inputting a value for each associated parameter; this solution is especially suitable when there are few parameters and few SPAs, otherwise this may take too much space in the user interface (cf. example of figure lOB); * display of each SPA candidate along with its associated parameters names only; a common GUI component (e.g. text fields) is displayed for inputting values of the parameters of a current pre-selected SPA (a pre-selection can be performed using a tick-box for example), values can be entered for parameters of different SPAs by changing the pre-selected SPA (for instance, by default one SPA is pre-selected and its parameters names are displayed next to text fields for entering values, but if user clicks on another SPA to perform the pre-selection, the list of displayed parameters is updated); note that even if the GUI component for setting values is not displayed for non-pre-selected SPAs, displaying their associated parameters names is still important as it enables the user to have an idea about the features of each SPA prior to performing the selection; alternatively, all possible parameters of all SPAs are displayed in the common GUI component, but only those of the pre-selected SPA are active, i.e. their values can be edited; furthermore, it is possible to display default values (determined based on the algorithm of figure 8 for example) in the text fields next to the parameters names, the user can then validate these default values or change them; display of each SPA candidate along with its associated parameters names only; a dedicated GUI component (e.g. text fields) is displayed only for the current pie-selected SPA, next to the parameters' names, to input values for these parameters; thus GUI components are hidden for non-pie-selected SPAs to save space.

It should be noted that a pre-selection of a SPA may be performed by default by the WRE based on a set of user-defined rules. As an example of such rules, if SRA has already provided a value (e.g. sky") for one parameter (e.g. keyword') in the service request, then a SPA supporting this parameter ("keyword") would advantageously be pre-selected. Indeed, if user has set a value for this parameter, it is a strong indication that the user prefers SPAs capable of handling this parameter.

Value setting is then enabled at step S540, as well as the selection of one of the listed SPA. Alternatively, WRE may enable user to select multiple SPAs in order to transmit the same service request to multiple SPAs. As it can be understood from the above descnption about the different possible solutions for constructing the GUI, the selection of a SPA and the setting of values for parameters may occur in different orders which is partly related to the adopted GUI solution. As a matter of fact, if the parameters are always visible, user does not have to pre-select a SPA to know which parameters are associated with that SPA. Also, if the parameters are always visible and a GUI component is systematically provided for each parameter to set its value, user does not have to pre-select a SPA prior to setting values for the parameters. On the other hand, if parameters are hidden, then user has to select a SPA prior to setting values for the parameters, except if the SPA the user wants to select is the one pre-selected by the WRE for which a GUI for setting parameters values is already present.

Finally, the service request and the set parameters are transmitted to the selected SPA at step S550. Similar transmission means as step S440 can be used.

It should be noted that one or both of the selecting of the service provider application and the setting of parameters values for the selected SPA may be automated (i.e. without intervention of the user). In a variant implementation, the selection of the service provider application (step S540) may be performed by the controller based on user pre-defined rules. For example, the selecting of the service provider application is performed based on the parameters defined by the service provider application candidates, e.g. the SPA candidate defining the greater number of parameters is selected to provide the user with the richer SPA in terms of features. In another example, the selecting of the service provider application is performed based on the matching between the parameters defined by the service requester application and/or the web runtime environment and the parameters defined by each service provider application candidate; e.g. the SPA candidate which defines the most of identical or equivalent parameters with the SRA is selected to increase compatibility between the two applications. Regarding the automation of parameters values setting, a default value (e.g. first in a list of possible values as described with regards to figure 8) can be automatically selected by the WRE controller.

Figure 7 is a flowchart that describes the possibility for the SPA to provide the WRE with feedback information regarding which parameter values have been finally used to process the service request. Indeed, after receiving the service request with associated parameters values from the WRE, the SPA may provide a further opportunity to the user to add or modify those values through a dedicated GUI managed by the SPA.

Consequently, if parameters values have been updated (referred to as refined parameter values), it is advantageous to feedback these refined values to the WRE for later re-use, such as default values for example. For instance, if we consider a parameter "keyword" and an initial value "sky" set via a GUI of the WRE in the context of a pick service for digital contents of type photos, a refined value could be "sky cloudy" that would have been input by the user via SPA GUI after the results obtained with value "sky" were found unsatisfactory (because returning too many photos for example).

The flowchart of figure 7 is executed by a service provider application that has been selected for processing a service request. The processing of the service request as such is represented by step S700. After completion of the request processing, which can be detected for example after user clicks on a completion button, the SPA determines the values of the parameters used for the request processing at step S710. These values may include all the different variations used for each parameter or only the last updated versions if any. The values are then saved using WRE's application storage (step S720).

The application storage of WRE is a specific memory area within for example web storage unit 350 intended to save (key! value) pairs provided by a given application executed by WRE. A standard describing a possible solution for providing application storage functionality is "Web Storage" (http://www.w3.org/TRlwebstorage/). This standard describes two kinds of application storage, one called "session storage", meant to store data only for the duration of a session, and another one called "local storage", meant to store data that persists between sessions. Each application (each web site in the case of "Web Storage") benefits from its own application storage area in a given WRE (indeed, an application/a web site should generally not access data from another application/another web site). In the context of the invention, "local storage" is preferably used as parameters -20 -and related data should be persistent between sessions in order to provide a better user experience.

In the case of step S720, each parameter can be stored in the application storage as a (key, value) pair, the key being, for instance, the name of the parameter suffixed by a specific indication (e.g. "parameter name-latestValue" to refer to the latest value of the parameter), and the value being the value of said parameter.

The data object resulting from the processing of the service request is then transmitted to WRE controller (step 5730). In a preferred implementation, the refined parameters are communicated to the WRE solely via the web storage unit 350, the WRE controller retrieving that information when needed directly from the web storage unit. Note here that transmitting the result after having saved parameters values (step S720) ensures that the values are available in the web storage unit when WRE receives the result data object.

The advantage of relying on application storage is that data is immediately available to WRE; however, the amount of storage is limited, and this mechanism is less dynamic given that the values stored are the ones defined the last time SPA was loaded and executed by WRE.

More generally, application storage can be used by a SPA to store values that may be useful when setting values for parameters. Depending on the usage of the values, appropriate keys should be defined (typically by adding a suffix to each parameter name) as described in the following examples.

If SPA handles tags, frequent tags may be added to a list of possible values so that WRE can help user select a tag value; for instance, "tag-parameter-possibleValues" may be chosen as a key.

In the same context, tags specific to user may also be stored by SPA, for instance using the key "tag-parameter-user-possibleValues".

If SPA provides a sharing service, different groups of people with who a user might share a content may be stored, for instance using the key "group-parameter-possibleValues" (simple values for this may for instance be "public" and "private").

If SPA is a photo editing application, said SPA may allow users to detine set of filters/operations that can be applied to photos; in this case, SPA advantageously defines a "processing" parameter and stores the names of these sets of filters/operations in application storage, allowing a user to easily select one of his/her defined processing from WRE interface.

Alternatively, instead of relying on application storage, a given SPA may define an interface accessible to a WRE so that said WRE can obtain a list of values for a given -21 -parameters. Such interface may for instance be an URL, possibly along with parameters, defined in SPA source code or in a manifest.

Alternatively or in addition to the saving of parameter values in the application storage (step S720), the parameter-value pairs can be communicated back to the WRE in the data object resulting from the execution of the service request that is passed to the WRE controller. This can be implemented for example by defining a parameter" property in the data object that would comprise the (parameter name, parameter value) pairs.

Additionally, the SPA may be able to define another property, such as "privacy" representing a Boolean variable to indicate whether or not parameters should be communicated to the requesting SPA. The possibility of communicating the refined parameter values back until the SRA can be further controlled at the WRE level through user settings. Indeed, user may not want the refined parameters to be provided to the requesting SPA although it has been authorized by the SPA.

Figure 8 is a flowchart that describes the process of determining possible values that can be taken by a given parameter according to a particular implementation of the invention. The possible values are typically used for proposing default values to the user when setting the corresponding parameter.

From a general point of view, the flowchart considers different sources for obtaining values for the given parameter and establishes a priority order between these different sources. The chosen order is provided for illustration purposes and alternate orders may also be considered.

First, at step S800, an empty list meant to contain possible values for the given parameter is created. It is then checked at step S805 whether user-defined rules exist for this parameter. Means to create such rules might be provided by the WRE. As an example, a user-defined rule may specify a default value for a given parameter provided no other value was defined by SPA. If a rule is defined, it is applied at step S810 and the value resulting from the application of the rule is added to the list.

At step S815 it is checked whether a value has been defined by SRA or by WRE for this parameter. The SPA can define a value if it provides a user interface enabling user to set that value for the given parameter. Similarly, WRE can define a value if user selects a different SPA after having already set values for a previous SPA (the different SPA and the previous SPA are assumed to define a same parameter so that a value set for one SPA can be reused for the other SPA). If the test of step S815 is positive, the value is added to the list at step S820. If not, or after step S820, it is checked at step S825 whether a refined parameter value has been set by SPA after processing a previous service request (previous service request is not necessarily of the same type as the one -22 -of current service request). If so, this value is added to the list at step 5830. It should be noted that if several refined parameters values have been provided by SPA (or possibly by different SPAs) for the given parameter, WRE may add all these values to the list, and not only the last value. Alternatively or in addition to step 5825, it may be checked whether parameters values have been defined by the SPA, i.e. these values are not necessarily refined values. In fact, the SPA may store possible values for the parameters it defines, particularly if these parameters can only take specific values known to the SPA.

After step S830, or if there is no refined parameter value set by SPA at step 5825, the values set for the given parameter in previous requests, if any, are considered at step S835. If these values have been set they are added to the list at step S840.

After step 5840, or if there are no values set for the given parameter in previous requests at step S835, it is checked at step 5845 whether other values stored in the WRE might be relevant for the given parameter. For instance, if the considered parameter is known to be an e-mail address, then e-mail addresses previously input in web pages executed by the WRE may be considered as relevant. Similarly, if a phone number is needed, previously input phone numbers may be considered as relevant. If such values are available, they are added to the list at step S850.

After step S850, or if no relevant value appears to be defined in WRE at step 3845, the first value in the list is selected as the default value. The process then ends (step 5890).

In the above described algorithm, values added first appear in the top of the list.

For example, a value added at step S810 would be in the first position. If several values are added in a single step, these values are ordered so that the first value added is the most likely to be used. The way to determine the value the most likely to be used can for instance be to order values by date of last usage, so that the value the most recently used would be in the first position. Another way of ordering values may be to associate an occurrence number with each value and to set the most frequent value in first position.

The user-defined rules can be easily extended making it possible for the user to customize the algorithm described in this figure, for instance by changing the priority of each kind of value (e.g. moving step 5825 right after step 5800 in order to assign highest priority to refined parameters set by SPA). As another alternative, user-defined rules may also enable a user to prevent WRE from setting a default value for a given parameter.

Additionally, another improvement to the setting of values consists in making it easy for a user to reuse a set of previously set values for a considered group of parameters. For instance, the user may have set values for a first group of parameters intended to a first SPA after a first service request has been made. Then, a second -23 -service request is made to that same first SPA; as discussed before, the values set for this second request can be based on the refined values obtained from the first SPA after its completion of processing the first service request. Now assume that the user decides to do a third service request to a second SPA which has at least part of the group of parameters in common with the first SPA. Two options are available for setting the values of these common parameters, either considering the initial values or the refined values.

The user interface should allow the user to easily select between these two options. For instance, refined values are proposed by default, but user may be able to click on a "Previous" button in order to replace these values by the initial values. Similarly, a "Next" button may be displayed in order to go back to the refined values. User may also be provided with means to save parameters and values in WRE; and conversely, the WRE would then provide user with the possibility to select among these saved parameters and values.

Figure 9 illustrates a communication scenario between a service requester application 910 and a service provider application 920 controlled by the web runtime environment controller 920 according to an embodiment of the invention. Figures WA and lOB provide an illustration of the scenario in a web browser 1000.

In this scenario, the service requester application 910 is for example a web image editor 1005 that generates a request 911 for a service "Pick" with payload of type "image". The request is for example generated when the user clicks on a button 1010 in the GUI of the image editor 1005.

After reception of the request 911, the WRE controller 920 determines the SPAs able to process this service request (here SPA#0, SPA#1 SPA#N) as well as the parameters each SPA defines for such service request, then prompts the user to select a service provider application and to set the corresponding parameters' values by means of a GUI component 1020 represented by a new window. In this window, SPAs are listed along with their associated parameters and a text field for setting the corresponding value.

In the illustrated example, only SPA#0 defines a parameter "keyword" and thus provides an input text field 1034 for setting a value for this parameter (for example "sky" value has either been input by the user or displayed as a default value by the WRE controller for validation). One selection button 1031, 1032, ... 1033 is provided in correspondence with each SPA. It is assumed that the user selects SPA#0 by clicking on button 1031. This triggers the generation of a service request 921 from the WRE controller 920 towards SPA#0 930. As it can be noticed, the service request contains the service "Pick", the type of payload "image" and a pair of (key, value) equal to ("keyword", "sky").

-24 -When SPA#0 receives the service request 921, it typically displays photos based on their relevance to the keyword "sky", user selects one of these photos using a GUI of the SPA#0 (not illustrated), and the selected photo is returned to SRA 910 in a resulting data object.

The above example shows clearly the advantages of embodiments of the invention. First, taking into account which parameters can be handled by the different SPAs, it is possible to select the most appropriate service provider application for executing the requested service and a better user experience can thus be achieved. For example, without information on the SPA-defined parameters, the user could have selected SPA#1 which would have returned photos of arbitrary subjects, that wouldn't satisfy user's expectations. Second, relying solely on the parameters provided by the service requester application makes it unlikely to be able to provide values for all parameters defined by the selected SPA as the parameters defined by the requester application and the selected provider application do not necessarily match. In the illustrated example, SRA 910 didn't provide a "keyword" parameter, and thus without the invention, the advantage of filtering by keyword wouldn't have been used even if SPA#0

Claims

-25 -CLAIMS1. A method of controlling communication in a web runtime environment of a device between a service requester application adapted to generate service requests and a service provider application adapted to process the service requests, the method comprising the following steps performed by a controller of the web runtime environment: obtaining parameters defined by the service provider application for the processing of a service request; enabling value setting for the obtained parameters; and transmitting to the service provider application a service request received from the service requester application with the set parameters.
2. The method according to claim 1, further comprising a step of receiving a service request generated by the service requester application, said service request being then transmitted at the transmitting step to the service provider application with the set parameters.
3. The method according to claim 2, wherein the service provider application is selected among a list of service provider application candidates adapted to process the service request generated by the service requester application.
4. The method according to claim 3, wherein the selection of the service provider application is performed based on user input obtained via a graphical user interface.
5. The method according to claim 4, wherein the service provider application candidates are displayed along with their associated parameters in the graphical user interface so that to provide the user with information prior performing the selection.
6. The method according to claim 3, comprising a step of obtaining parameters defined by each service provider application candidate and wherein the selecting of the service provider application is performed based on the parameters defined by the service provider application candidates.

-26 -
7. The method according to claim 3, comprising a step of obtaining parameters defined by each service provider application candidate and parameters defined by the service requester application and/or the web runtime environment, and wherein the selecting of the service provider application is performed based on the matching between the parameters defined by the service requester application and/or the web runtime environment and the parameters defined by each service provider application candidate.
8. The method according to claim 3, 6 or 7, wherein the selection of the service provider application is performed by the controller based on pre-defined rules.
9. The method according to any preceding claim, wherein the controller causes the display of graphical user interface (GUI) components enabling the user to set values for the obtained parameters, defined by the service provider application.
10. The method according to claim 9, wherein the controller causes the display via the GUI components of defaults values for one or more of the obtained parameters, the default values can be validated or changed by the user with other values to set values for the one or more parameters.
11. The method according to claim 10, wherein the defaults values are obtained from a list of possible values containing at least one of the following: values obtained by applying user-defined rules; values defined by the service requester application and/or the web runtime environment; values defined and/or refined by a service provider application; values set in previously transmifted service requests; and relevant values defined by the web runtime environment.
12. The method according to claim 11, wherein the list of possible values is stored in a web storage unit, the web runtime environment controller having access to the web storage unit for retrieving values to be used as default values.
13. The method according to any one of claims 1 to 8, wherein the controller performs an automatic setting of parameters values based on obtained default values.
14. The method according to claim 13, wherein the defaults values are obtained from a list of possible values containing at least one of the following: -27 -values obtained by applying user-defined rules; values defined by the service requester application and/or the web runtime environment; values defined and/or refined by a service provider application; values set in previously transmitted service requests; and relevant values defined by the web runtime environment.
15. The method according to any preceding claim, wherein the set parameters representing (key, value) pairs are communicated to the service provider application in the transmitted service request and/or in the URL used for loading the service provider application.
16. The method according to any preceding claim, wherein the step of obtaining the parameters defined by the service provider application is based on parsing a code portion of said service provider application containing a description of said parameters.
17. The method according to claim 16, wherein the description of said parameters is written in one of the following formats: as attributes of an XML element defining the parameters; as XML elements, each element defining one parameter; and as a JSON object.
18. A device for controlling communication in a web runtime environment between a service requester application adapted to generate service requests and a service provider application adapted to process the service requests, the device comprising: obtaining means for obtaining parameters defined by the service provider application for the processing of a service request; enabling means for enabling value selling for the obtained parameters; and transmitting means for transmitting to the service provider application a service request received from the service requester application with the set parameters.
19. A device, substantially as hereinbefore described with reference to and as shown in figures 1A, 1B, 2 and 3.
20. A method, substantially as hereinbefore described with reference to and as shown in figures 4, 5, 7 and 8.

-28 -
21. A program which, when executed by a computer, causes the computer to carry out the method according to any one of claims 1 to 17.
22. A program which, when loaded into a computer, causes the computer to function as the device of claim 18.
23. A storage medium storing the program according to claim 21 or claim 22.