GB2531611B

GB2531611B - Method, device, and computer program for improving access to services carried out in remote web runtime environments

Info

Publication number: GB2531611B
Application number: GB1419003.7A
Authority: GB
Inventors: Bellessort Romain; Fablet Youenn; Ruellan Hervé
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2014-10-24
Filing date: 2014-10-24
Publication date: 2019-08-07
Anticipated expiration: 2034-10-24
Also published as: GB2531611A; GB201419003D0

Description

METHOD, DEVICE, AND COMPUTER PROGRAM FOR IMPROVING ACCESS TO SERVICES CARRIED OUT IN REMOTE WEB RUNTIME ENVIRONMENTS

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, a device, and a computer program for improving access to services carried out in remote web runtime environments, in particular web runtime environments supporting the API known as Presentation API. The invention enables a requesting device to access a service carried out in a remote web runtime environment by providing the web runtime environment hosting the service to be used with a web driver application, the latter being provided by the requesting device when accessing the service.

BACKGROUND OF THE INVENTION A web application, also called a web app, is an application relying on web technologies. Typically, such an application is developed in the HyperText Markup Language (HTML), the Cascading Style Sheets (CSS) language, or the JavaScript language. A web application is generally designated through a Uniform Resource Locator (URL) which indicates a resource, for example an application. Therefore, what is sometimes referred to as a “web page” can also be seen as a web application. A web application can also be a packaged application that may be installed on a device. In such a case, the application is stored persistently on the device.

In the context of the invention, it is considered that a web application is typically executed by a Web Runtime Environment (WRE), for example Mozilla’s Firefox OS (Mozilla and Firefox are trademarks) or a web browser, enabling web applications loaded and run in the web runtime environment to cooperate.

Figure 1, comprising Figures 1a and 1b, illustrates two examples of web runtime environments.

As illustrated in Figure 1a, 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 of one or several software modules, for example generic modules and specific modules, among which a web runtime controller, which 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 1b, a web runtime environment 100’ can be integrated into 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 Mozilla Firefox OS. A network service is a service made accessible through a network. Examples of such services are remote media displaying services which provide the service of displaying media on a remote display.

For the sake of illustration, a web application can request display, on a remote display, of the data pointed to by a URL, for example using the Presentation API which is an API currently standardized by the World Wide Web Consortium (W3C).

The Presentation API is an API which has been discussed by the W3C Second Screen Presentation Community Group from 2013. It is currently under a standardization process. It basically enables a web application to request the display of data (typically indicated with a URL) on a remote display.

After a web runtime environment has discovered available remote displays, it presents a list of these available remote displays to a user so that the latter can select one. Once the user has selected one remote display, the web runtime environment can display previously obtained data on the selected remote display. To that end, the web runtime environment can load data, render them in a separate context (for example as if the rendered data were to be displayed in the same web runtime environment), produce a video stream from the rendered data, and send this video stream to the selected remote display (e.g. through a video streaming technology such as Miracast (RTM)). According to that solution, a single web runtime environment is used in the device controlled by a user.

Alternatively, if the selected remote display comprises a web runtime environment (second web runtime environment), the first web runtime environment can transmit the previously obtained data to be displayed to the remote display which loads and renders the transmitted data through its own web runtime environment. According to that solution, two different web runtime environments are used, when being located in the device controlled by a user and the other in the remote display.

It is to be noted that according to the Presentation API, both the requesting web application (i.e. the web application which requests the remote display of data) and the remote web application (i.e. the web application which is displayed in response to a request) should be able to exchange messages through similar APIs. If messages can be easily exchanged when both web applications are executed by the same web runtime environment, interoperability conditions are required when the requesting web application and the remote web application are executed in two different web runtime environments.

In the case according to which the selected remote display comprises a web runtime environment, if both the web runtime environment used in the device controlled by a user and the web runtime environment of the selected remote display are compatible (e.g. designed by the same entity), for example if both web runtime environments are Mozilla Firefox browsers, exchanging messages between the two web runtime environments is not an issue.

However, if both the web runtime environment used in the device controlled by a user and the web runtime environment of the selected remote display are not compatible (e.g. not designed by the same entity), for example if one of the web runtime environments is Mozilla Firefox browser and the other is Google Chrome browser, exchanging messages between the two web runtime environments can be an issue. A solution to that problem mainly consists in defining a common discovery protocol and a common communication protocol. Such a discovery protocol would allow discovering a remote service provided by a web runtime environment of a remote device, for example a service that can be used for remote displaying of data. A common communication protocol would typically enable a requesting device provided with a web runtime environment to request the display of data and to transmit messages to and receive messages from a web runtime environment implemented in a remote device so that the messages can be forwarded to an appropriate web application.

The Presentation API allows a web application executed by a web runtime environment of a requesting device to request the display of data (typically defined by a URL) on a remote display. The requesting web application does not know how the web runtime environment is connected to the remote display.

According to a particular implementation, the selected remote display is a device comprising its own web runtime environment. The latter is made available as a network service so that it can launch URLs provided by web applications executed by other web runtime environments through the Presentation API.

In this case, the web runtime environment executing the requesting web application establishes a communication link with the remote web runtime environment so that a web application identified by a URL can be launched and messages can be exchanged between the requesting web application and the web application launched on the remote web runtime environment.

To enable exchange of Presentation API related messages, a protocol to be implemented by both web runtime environments has been proposed.

However, the use of such a protocol means that that all the web runtime environments which are capable of exchanging Presentation API related messages must implement that protocol.

Furthermore, it is to be noted that there exist devices not implementing a web runtime environment and that would benefit to rely on a remote web runtime environment for remotely launching URLs. Implementing a protocol allowing exchange of Presentation API related messages in that devices would be a real issue. This applies, in particular, to constrained devices that rely on specific proprietary protocols particularly adapted to their constraints. DIAL (Discovery And Launch) is a protocol that second-screen devices can use to discover and launch applications on first-screen devices. Accordingly, DIAL offers an access to services carried out in remote web runtime environments. Communications between a DIAL client and a DIAL server are made through a REST API, that is to say through specific HTTP requests and responses. For the sake of illustration, a specific request allows requesting the loading of a given web application. DIAL does not establish a communication channel between a requesting web application and a remotely loaded web application. If a communication channel is needed between a requesting web application and a remotely loaded web application, the remotely loaded web application establishes a connection of the WebSocket type with the DIAL client.

Therefore, there is a need for a solution allowing a device implementing a web runtime environment or not to rely on a remote web runtime environment for remotely launching URLs, without requiring implementation of a specific predetermined protocol.

SUMMARY OF THE INVENTION

Faced with these constraints, the inventors provide a method, a device and a computer program for improving access to services carried out in remote web runtime environments.

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 implemented by a requesting device for processing a service request from a service requester application of the requesting device, the service to be carried out in a remote web runtime environment, the method comprising: - determining a service provider comprising said web runtime environment and being capable of providing the requested service through a submitted web driver application; - submitting the web driver application to the determined service provider; and - interacting with the web driver application executed by the web runtime environment, causing the service provider to provide the requested service; wherein the web driver application interacts with the web runtime environment through a standard API.

Therefore, the method of the invention makes it possible for a requesting device, in particular for a constrained device, to interact with a remote device implementing a remote web runtime environment providing a remote service using its own communication features.

It allows, in particular, to provide data from a constrained device to an advanced device, for example for using a smartphone or a tablet as a user interface for displaying data received from a camera or a printer. Similarly, it allows to provide input from an advanced device to a constrained device, for example for using a smartphone or a tablet as a user interface for enabling a user to set parameters of a camera or a printer.

According to the method of the invention, interaction between a requesting application and a remote service is possible by providing a specific web driver application, which is able to interact with a web runtime environment and with a requesting application.

In an embodiment, the step of determining a service provider comprises a step of receiving an indication for determining that the service provider supports web driver application submission.

In an embodiment, the method further comprises a step of determining a URL defining a location at which the web driver application is to be submitted.

In an embodiment, the URL is received from the service provider or being determined as a function of an item of information received from the service provider.

In an embodiment, the method further comprises a step of transmitting the web driver application to the service provider as a URL defining a source from which the web driver application can be loaded or as source code.

In an embodiment, the method further comprises a step of determining a communication configuration for submitting the web driver application to the determined service provider.

In an embodiment, the method further comprises a step of selecting one web driver application to be submitted to the determined service provider from among a plurality of web driver applications.

In an embodiment, the method further comprises a step of transmitting data or references to data to the service provider.

In an embodiment, the data or the referenced data comprises data to be processed by the requested service.

In an embodiment, the data or the referenced data are representative of a web application type.

In an embodiment, the step of submitting the web driver application to the determined service provider comprises the step of transmitting the data or the references to data.

In an embodiment, the step of interacting comprises a step of receiving data from the requested service through the web driver application.

In an embodiment, the received data are data entered by a user via an interface of the service provider, the interface being associated with a web application of which the launch is part of the requested service. A second aspect of the invention provides a method for a service provider to provide a service, the method comprising: - receiving a submission for a web driver application enabling communication with a web application and a component of a remote requesting device; - loading the web driver application in the service provider; - launching the web application in the service provider for providing the service; and - interacting with the component of the remote requesting device and the web application through the web driver application, causing the service provider to provide the service; wherein the service provider comprises a web runtime environment and a server, the web runtime environment enabling execution of the web driver application and of the web application and the server enabling execution of the steps of receiving a submission and of loading the web driver application; and wherein the web driver application interacts with the web runtime environment through a standard API.

In an embodiment, the server is a component of the web runtime environment.

In an embodiment, the server is independent from the web runtime environment, the web runtime environment and the server being connected to each other through a standard interface.

In an embodiment, the method further comprises a preliminary step of transmitting an indication that the service provider supports web driver application submission.

In an embodiment, the indication comprises a URL defining a location at which the web driver application is to be submitted.

In an embodiment, the method further comprises a step of receiving the web driver application from the remote requesting device as a URL defining a source from which the web driver application can be loaded or as source code.

In an embodiment, the method further comprises a preliminary step of verifying that the version of the web driver application in the received submission is the latest version of the web driver application, prior to loading the web driver application.

In an embodiment, the method further comprises a preliminary step of verifying that the web driver application is not already installed within the service provider, prior to loading the web driver application.

In an embodiment, the method further comprises a step of receiving data or references to data.

In an embodiment, the received data or referenced data comprise data to be processed by the service.

In an embodiment, the received data or referenced data enable the steps of loading the web driver application and of launching the web application to be carried out simultaneously.

In an embodiment, the method further comprises a step of the received data or referenced data represents a web application type, the web application being determined as a function of the web application type.

In an embodiment, the step of interacting comprises a step of transmitting data to the remote requesting device through the web driver application.

In an embodiment, the transmitted data are data entered by a user via an interface of the service provider, the interface being associated with the web application. A third aspect of the invention provides a requesting device for processing a service request from a service requester application of the requesting device, the service to be carried out in a remote web runtime environment, the device comprising at least one microprocessor configured for carrying out the steps of: - determining a service provider comprising said web runtime environment and being capable of providing the requested service through a submitted web driver application; - submitting the web driver application to the determined service provider; and - interacting with the web driver application executed by the web runtime environment, causing the service provider to provide the requested service; wherein the web driver application interacts with the web runtime environment through a standard API.

Therefore, the device of the invention makes it possible to interact with a remote device implementing a remote web runtime environment providing a remote service using its own communication features.

According to the device of the invention, interaction between a requesting application and a remote service is possible by providing a specific web driver application, which is able to interact with a web runtime environment and with a requesting application.

In an embodiment, the at least one microprocessor is further configured so that the step of determining a service provider comprises a step of receiving an indication for determining that the service provider supports web driver application submission.

In an embodiment, the at least one microprocessor is further configured for carrying out a step of determining a URL defining a location at which the web driver application is to be submitted.

In an embodiment, the at least one microprocessor is further configured so that the URL is received from the service provider or is determined as a function of an item of information received from the service provider.

In an embodiment, the at least one microprocessor is further configured for carrying out a step of transmitting the web driver application to the service provider as a URL defining a source from which the web driver application can be loaded or as source code.

In an embodiment, the at least one microprocessor is further configured for carrying out a step of determining a communication configuration for submitting the web driver application to the determined service provider.

In an embodiment, the at least one microprocessor is further configured for carrying out a step of selecting one web driver application to be submitted to the determined service provider from among a plurality of web driver applications.

In an embodiment, the at least one microprocessor is further configured for carrying out a step of transmitting data or references to data to the service provider.

In an embodiment, the data or the referenced data are data to be processed by the requested service, the at least one microprocessor being further configured so that the step of submitting the web driver application to the determined service provider comprises the step of transmitting the data or the references to data.

In an embodiment, the at least one microprocessor is further configured so that the step of interacting comprises a step of receiving data from the requested service through the web driver application. A third aspect of the invention provides a device for a service provider to provide a service, the device comprising at least one microprocessor configured for carrying out the steps of: - receiving a submission for a web driver application enabling communication with a web application and a component of a remote requesting device; - loading the web driver application in the service provider; - launching the web application in the service provider for providing the service; and - interacting with the component of the remote requesting device and the web application through the web driver application, causing the service provider to provide the service; wherein the service provider comprises a web runtime environment and a server, the web runtime environment enabling execution of the web driver application and of the web application and the server enabling execution of the steps of receiving a submission and of loading the web driver application; and wherein the web driver application interacts with the web runtime environment through a standard API.

Therefore, the device of the invention makes it possible to interact with a requesting device from a remote device implementing a remote web runtime environment providing a remote service using its own communication features.

In an embodiment, the device comprises the web runtime environment and wherein the server is a component of the web runtime environment.

In an embodiment, the device comprises the web runtime environment and a standard interface for communicating with the server, the server being independent from the web runtime environment.

In an embodiment, the at least one microprocessor is further configured for carrying out a preliminary step of transmitting an indication that the service provider supports web driver application submission.

In an embodiment, the at least one microprocessor is further configured for carrying out a step of receiving the web driver application from the remote requesting device as a URL defining a source from which the web driver application can be loaded or as source code.

In an embodiment, the at least one microprocessor is further configured for carrying out a preliminary step of verifying that the version of the web driver application in the received submission is the latest version of the web driver application, prior to loading the web driver application.

In an embodiment, the at least one microprocessor is further configured for carrying out a preliminary step of verifying that the web driver application is not already installed within the service provider, prior to loading the web driver application.

In an embodiment, the at least one microprocessor is further configured for carrying out a step of receiving data or references to data.

In an embodiment, the received data or referenced data comprise data to be processed by the service, the at least one microprocessor being further configured for carrying out so that the received data or referenced data enable the steps of loading the web driver application and of launching the web application are carried out simultaneously.

In an embodiment, the at least one microprocessor is further configured so that the step of interacting comprises a step of transmitting data to the remote requesting device through the web driver application.

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, and in particular a suitable tangible carrier medium or suitable transient 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 1a and 1b, illustrates two examples of web runtime environments;

Figure 2 illustrates an example of the logical architecture of an embodiment of the invention;

Figure 3 illustrates an example of steps carried out in a device enabling an application executed by that device to execute a service in a remote web runtime environment while providing a communication channel between the device and the service executed in the remote web runtime environment;

Figure 4 illustrates an example of steps for identifying a service of a remote web runtime environment supporting submission of web driver applications;

Figure 5 illustrates an example of steps for providing a web driver application to a service of a remote web runtime environment;

Figure 6 illustrates an example of steps enabling a requesting device to interact with a web driver application implemented in a remote device so that a service of a remote web runtime environment can be carried out;

Figure 7 illustrates an example of steps carried out in a service of a remote web runtime environment;

Figure 8 illustrates an example of implementing an embodiment of the invention to access a service of a remote web runtime environment, that uses a web driver application provided by a requesting device; 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

According to particular embodiments, the invention mainly consists in enabling requesting devices to provide web driver applications to remote web runtime environments to access services of those web runtime environments. Each of the web driver applications knows how to interact with the corresponding requesting device since it has been developed specifically with that purpose. In addition, a remote web runtime environment and a web driver application know how to interact with each other since the model of a web driver application is designed with that purpose.

To that end, the description of services of a remote web runtime environment is configured so as to enable providing such a web driver application to that web runtime environment when it is discovered by a requesting device searching for a service of a remote web runtime environment. Accordingly, requesting devices can have their web driver applications loaded by remote web runtime environments. After being loaded in a remote web runtime environment, a web driver application acts as a proxy between the remote web runtime environment and the requesting device, enabling that requesting device to rely on this remote web runtime environment as a Presentation API provider.

It is to be noted that the following description is mainly based on the Presentation API for the sake of illustration. However, the invention applies to any API that allows remote launching of web content (especially URLs) and establishing a communication channel between a requesting application and a remote application.

Figure 2 illustrates an example of the logical architecture of an embodiment of the invention.

As illustrated, requesting device 200 is configured to launch a service in remote device 205.

Requesting device 200 comprises operating system 210, application 215, and standard API 220 allowing application 215 to interact with operating system 210. Application 215 can be a native application and API 220 can be a native API.

Alternatively, requesting device 200 may implement a web runtime environment, application 215 may be a web application and API 220 may conform to the JavaScript API.

Operating system 210 may interact with web runtime environment 215 of remote device 205 via a standard communication link 225.

Remote device 205 is configured for providing services, for example display of web content. Accordingly, remote device 205 can execute web application 230 that may interact with web runtime environment 215 through standard API 235.

According to embodiments of the invention, requesting device 200 is configured for providing web driver application 240 to remote device 205. As illustrated, web driver application 240 may interact with web runtime environment 215 through standard API 245. As a consequence, web driver application 240 enables interaction between operating system 210, web runtime environment 215 and web application 230 as described herein after.

Figure 3 illustrates an example of steps carried out in a device enabling an application executed by that device to execute a service such as data display in a remote web runtime environment while providing a communication channel between the device and the service executed in the remote web runtime environment.

It is to be noted that a web runtime environment can be implemented in the device executing the application that launches the execution of a remote service, or not.

For the sake of clarity, the device executing the application that launches the execution of a remote service is referred to as the requesting device while the device implementing the remote web runtime environment wherein the service is carried out is referred to as the remote device.

As illustrated, a first step (step 300) aims at receiving a service request for a remote service, for example remote displaying of data in a web runtime environment. A reference to the data to be displayed is preferably received along with the service request. Data are typically HTML data or web data defined by a URL. They typically represent a web application. This service request is received from a requesting application executed by the requesting device.

It is to be noted that a service request for displaying data may also be directed to data such as images or video streams that may be embedded in HTML and provided as web data. In such a case, the remote web runtime environment would typically display such content by wrapping them in an HTML container, that is to say a HTML document specifically designed to embed such data. As another example described herein below, the data to be displayed are identified as a function of their type, for example of type of web application.

According to a particular embodiment, the service request is received by a specific component of an operating system of the requesting device through a native API which is called by a native application (i.e. an application written for a specific platform). This is typically the case for constrained devices.

According to another embodiment, the service request is received from a web application by a web runtime environment implemented in the requesting device, for example through a JavaScript API.

Next, at step 305, a service of a remote web runtime environment allowing submission of a web driver application is identified. The identified service is typically a service for displaying data. According to a particular embodiment, the service of the remote web runtime environment is not only configured for reaching a main objective such as displaying data (by launching a web application in the remote web runtime environment) but is also configured to enable communication between the launched web application, the web runtime environment, and the requesting device (i.e. the requesting application).

Step 305 is further described by reference to Figure 4.

After having identified a service of a remote web runtime environment allowing submission of a web driver application, the web driver application is provided to the identified service (step 310). Step 310 is further described by reference to Figure 5.

Next, after the web driver application has been loaded into the remote web runtime environment, the requesting device may interact with the web driver application (step 315) until the process ends. The interaction process of step 315 is further described by reference to Figure 6.

According to a particular embodiment, the steps described by reference to Figure 3 are carried out in a particular component of an operating system of the requesting device or in a web runtime environment implemented by the requesting device.

It is to be noted that instead of providing the data to be displayed as a URL or HTML data, a web content abstract may be provided, for example as a given type of web content or of a web application. For the sake of illustration, a particular type of web application may be provided, this type being chosen among different types, the latter being determined, for example, as a function of a type of input to be returned to the requesting device.

An example of such web application types are a text input web application, an image input web application, a video input web application, and an audio input web application. When a web content is provided to a service of a remote web runtime environment, the latter typically allows a user to select a given web application associated with the corresponding type of web content. Such a web application expects to be launched through a service of a remote web runtime environment, hence rely on a corresponding API (e.g. W3C Presentation API).

Depending on the type of service, the messages provided by the web application to the web driver application (through the web runtime environment) may be of different types. The web driver application may be adapted to the type of web content abstract which is provided to the remote web runtime environment so that it handles these messages properly. Alternatively, a given web driver application may be able to handle different types of messages from different types of web contents.

Figure 4 illustrates an example of steps for identifying a service of a remote web runtime environment supporting submission of web driver applications.

As illustrated, a first step (step 400) aims at identifying remote web runtime environments providing a particular service, typically a remote display service.

It is be noted that the operating system component of the requesting device or the web runtime environment implemented in the requesting device, carrying out the steps of Figure 4, may not be aware of all the possible types of services associated with the remote web runtime environment. Hence, it may ignore some services that could actually be used provided the requesting device is able to discover them.

The determination of available services generally starts by a discovery step that typically involves the use of discovery protocols such as mDNS (multicast Domain Name System), DNS-SD (DNS Service Discovery) and SSDP (Simple Service Discovery Protocol). A proximity-based discovery step may also be performed, for example by using technologies such as NFC (Near Field Communication) or Bluetooth LE (Bluetooth is a trademark). An advantage of such a process is directed to security issues since it requires a user to be physically present nearby the remote device providing the service.

Services may also be discovered thanks to sharing of information with another device (for example a device from another user in the same place) or thanks to a service (for example a synchronization service allowing synchronization of user data between various web runtime environments, previously discovered services being obtained by a newly used web runtime environment).

As another example, a user may also directly input settings of a service in a device (for example by indicating a service type and network parameters), typically the requesting device, so that the latter may be aware of it.

It is also to be noted that a discovery process may also be done, wholly or partially, prior to receiving a service request in an operating system or in a web runtime environment of the requesting device. According to that discovery process, a service can be selected quickly in a list of available services, providing a better user experience. However, an issue of such a discovery process lies in the fact that if the list of available services has not been recently refreshed, services of the list can be no more available. Therefore, checking that services are actually available is important in such a case.

Once the available services have been identified and memorized, for example as a list of available services, the requesting device should determine the ones which support the submission of web driver applications.

To that end, the list of available services is processed. A first test is carried out to determine whether or not the list of available services comprises an available service S not yet processed (step 405).

If the list of available services comprises an available service S not yet processed, the means provided by service S for submitting or providing a web driver application to that service are determined (step 410).

There exist several ways of determining the means provided by a service for submitting or providing a web driver application.

According to a first embodiment, the type of service S is used as an indication for determining whether or not the corresponding service supports web driver application submission and how to submit or provide a web driver application. In other words, a type of service indicates that a corresponding service supports web driver application submission. If a type of service indicates that a corresponding service supports web driver application submission, it preferably further indicates whether submitting a web driver application is compulsory or optional. Similarly, if a type of service indicates that a corresponding service supports web driver application submission, it preferably further indicates the way a web driver application can be provided to the corresponding service.

For the sake of illustration, a given service type may indicate that web driver applications should be submitted at a given URL which can be obtained once network parameters of the service are known (e.g. http://[service ip address:service portj/submit-driver). In the case according to which a web driver application can be optionally provided to a service, the requiring device may determine whether the feature is supported or not by querying this URL. If a success code is associated with the response (e.g. HTTP/200), a driver can be submitted. Alternatively, if an error code is associated with the response (e.g. HTTP/404 or HTTP/500), the requiring device is aware that the web driver application cannot be provided to the service.

According to a second embodiment, discovery information obtained while discovering services indicates whether or not web driver applications can be provided to the services and if so, how to do so. This typically consists in providing dedicated URLs in the discovery information.

According to a third embodiment, information needed to determine whether or not a web driver application can be provided to a service and how to provide a web driver application to a service are defined in an additional service description file. This file may comprise URLs defining the location wherein the web driver applications are to be submitted.

It is to be noted that one service may offer different possibility to a requesting device for the latter to provide a web driver application. For the sake of illustration, a service may provide a HTTPS URL and a HTTP URL so that a requesting device supporting HTTPS can use the HTTPS URL (which is more reliable in terms of security) while a requesting device that does not implement that protocol, for example a constrained device, can provide a web driver application to the service by using the HTTP URL (possibly with a limited access due to the lower level of security).

After having determined the means provided by service S for submitting or providing a web driver application (step 410), a second test is carried out to determine whether or not there exist determined means that can be used by the requesting device for providing a web driver application to service S (step 415).

For the sake of illustration, if the means provided by service S requires a connection of the WebSocket type but that the requiring device does not implement WebSocket protocol, no web driver application can be submitted. As another example, no web driver application can be submitted if the URL to be used for submitting the web driver application is not reachable by the requesting device or if the URL provided to submit the web driver application is an HTTPS URL but that the requesting device does not implement HTTPS protocol.

If there exist determined means that can be used by the requesting device for providing a web driver application to service S, service S is added to a list of services which can be used by the requesting device.

If none of the determined means can be used by the requesting device for providing a web driver application to service S or after having added service S to the list of services which can be used by the requesting device, the process is branched to step 405.

If all the services of the list of available services have been processed (step 405), one service of the list of services which can be used by the requesting device is selected (step 425) and the process ends.

The selection of a service which can be used by the requesting device is typically done by displaying the list of services which can be used by the requesting device and by giving the opportunity to a user to select one service. However, there exist other solutions for selecting one service.

For example, a user may define a default service to be used if it is available. In such a case, there is no need to search for other services if that default service is available. According to another example, the selection step may be implicit when only a single service is available. This may happen, in particular, in the case where the requesting device is a constrained device without any screen.

For the sake of illustration, a constrained sensor may discover a service of a remote web runtime environment when the remote device providing that service is very close to it (for example using a proximity-based discovery process such as a NFC or Bluetooth LE based discovery process). In such a case, the requesting device may decide to request the display of a given web application to the service so that a user can interact with said sensor.

It is to be noted that a given operating system or a given web runtime environment of a requesting device may provide a specific API that makes it possible to discover and to interact with services. In such a case, in addition to network services, local services available on the requesting device may also be discovered. An example of a local service is a web runtime environment that registers itself to the operating system as a service of a remote web runtime environment. To that end, such a service is to be defined by the operating system as a specific type of service, typically along with an API adapted to registering, requesting, and interacting with such a service. Therefore, in such a case, the means available for providing a web driver application would be a specific API provided by the operating system or by the web runtime environment.

It is also to be noted that local services of a requesting device may also be accessible through a network interface. In such a case, they are discovered like any other network services, for example using a discovery protocol.

Figure 5 illustrates an example of steps for providing a web driver application to a service of a remote web runtime environment.

For the sake of illustration, it is assumed that the requesting device has obtained a URL to which it can submit or provide a web driver application and that the web driver application can be submitted either as a URL or as HTML data. Alternatively, the web driver application may also be submitted as a JavaScript document being observed that a web driver application does not require to be displayed.

Still for the sake of illustration, it is assumed that two web driver applications are available for the requesting device, one being an up-to-date driver hosted by a cloud server and the other being a fallback driver hosted by the requesting device. Being hosted in a cloud server, the up-to-date driver can be easily updated, for example to fix bugs, to increase security, or to improve its efficiency.

As illustrated, a first step (step 500) is directed to obtaining means for submitting a web driver application to a selected service (for example the means determined at step 410 in Figure 4 for transmitting a web driver application to service S).

If different means are applicable for the selected service S, one of them is selected. Such a selection can be based, for example, on a security or an efficiency criterion.

Next, a first test is performed to determine whether or not service S may access the cloud (step 505). This test can be based, for example, on an item of information provided by service S in its service description. According to another example, service S may provide an interface allowing to check whether or not it can access a given server.

If service S may access the cloud (more precisely a cloud server comprising the up-to-date web driver application to be provided to the remote device), a URL of the up-to-date web driver application to be loaded in the remote device (defining a location in a cloud server) is provided to the service (step 510).

On the contrary, if service S cannot access the cloud server hosting the web driver application to be loaded in the remote device (step 505), a second test is carried out to determine whether or not the requesting device hosts a local web server (step 515).

If the requesting device hosts a local web server, a URL of the fallback web driver application to be loaded in the remote device, hosted by the requesting device, is provided to the service (step 520).

It is to be noted that the requesting device may not host a web server application, for example because it is too constrained or because it may reduce its security level. In such a case, if the requesting device does not host a local web server (step 515), the fallback web driver application can be directly provided to the service as HTML data (step 530). Those HTML data may be encoded in a specific format, e.g. in EXI (Efficient XML Interchange) format or GZIP format, in order to make it more compact. According to a particular embodiment, web driver application data can be provided as the payload of an HTTP POST request.

Then, the process ends.

The steps described by reference to Figure 5 illustrate an example of a process for providing a web driver application to a service of a remote device. However, there exist other solutions which could prove to be more efficient according to the circumstances. For example, it may happen that only a cloud web driver application or a local web driver application is available. It is also possible that, if both the cloud and the local web driver applications can be chosen, the local version is selected.

In addition, other constraints such as security constraints may be considered. For example, a web driver application hosted in the cloud may be submitted only if it can be ensured that the corresponding cloud server is safe. As a consequence, if such guarantee cannot be obtained, the web driver application hosted locally is selected to be provided to the service of the remote device.

It is to be noted that there exist services which may accept additional data in complement to a provided web driver application. For example, some services may accept web data or web content to be remotely displayed to be received as a complementary parameter. By doing so, a remote web runtime environment may be able to load the corresponding data at the same time as the web driver application. Alternatively, a service of a remote web runtime application may provide the web content to be displayed to the web driver application once the latter has been loaded. This avoids the need for the web driver application to obtain that web content from the requesting device (which is likely to enable a faster display of the provided web content).

As another example, data may be provided along with the web driver application to a service of a remote web runtime environment so that these data can be further transmitted by that service to the web driver application once the latter has been loaded. For sake of illustration, the IP address and the port number to which a web driver application should connect once loaded may be provided along with the web driver application in order to allow the web driver application to connect to the considered device as soon as possible after being loaded.

Such features are further described in reference do Figure 7.

Figure 6 illustrates an example of steps enabling a requesting device to interact with a web driver application implemented in a remote device so that a service of a remote web runtime environment can be carried out.

As illustrated, a first step (step 600) aims at obtaining an input in the requesting device. For the sake of illustration, the input obtained by the requesting device can be a URL defining data to be displayed by a remote device.

Such an input may be obtained along with a service request or independently. For example, the requesting application can provide the operating system of the requesting device with data which are transmitted to the remote displaying application through a web driver application. Typically, these data are transmitted from the requesting application to the operating system of the requesting device through a native API.

According to another example, the input is provided by a web driver application. For the sake of illustration, a message provided by the displayed application of the remote web runtime environment can be forwarded by the remote web runtime environment to the web driver application which, in turn, forwards the message to the operating system of the requesting device.

The operating system of the requesting device may also obtain an input through its own components or through external components. For example, an indication of a network connection failure may be an input obtained by the remote web runtime environment at step 600.

Since there exist cases for which an input has to be modified prior to use, the input obtained at step 600 is processed at step 605 (if needed). For example, a message obtained from a native application may have to be encoded in a different format prior to being transmitted to the remotely executed web driver application.

According to other examples, the obtained input does not have to be modified and can be directly transmitted to the web driver application. However, in such cases, minimal processing may still be performed, for example to check the validity of input data with regard to certain constraints. In the case of a URL defining data to be remotely displayed, the processing of the URL may consist in checking that it is correctly formatted or that it belongs to an authorized domain.

After the inputs have been processed (if needed), a first test is carried out to determine whether or not data are to be transmitted to the web driver application loaded in the remote device (step 610). The data to be transmitted may be the obtained input, a part of the obtained input, the processed obtained input, a part of the processed input data, complementary data related to service execution, or a combination thereof.

If data are to be transmitted to the web driver application loaded in the remote device, they are transmitted at step 615. Such transmission is achieved through one or more interactions involving the operating system of the requesting device (or the web runtime environment implemented in the requesting device) and the web driver application loaded in the remote device.

It is to be noted that the web driver application being designed specifically for the requesting device, these interactions between the requesting device and the web driver application loaded in the remote device are flexible. The technologies used for enabling interaction between the operating system of the requesting device (or the web runtime environment implemented in the requesting device) and the web driver application loaded in the remote device are chosen so as to fit the considered constraints.

According to a particular embodiment, the requesting device may implement a server conforming to the WebSocket protocol so that the requesting device and the web driver application loaded in the remote device can exchange messages through a connection of the WebSocket type. According to another example, the requesting device implements a web server so that the web driver application can interact with the requesting device through request of the XmlHttpRequest type. Still according to a particular example, if the web driver application expects to be granted access to a specific API providing control over UDP or TCP, it may rely on such protocols to exchange data with the requesting device.

If data are not to be transmitted to the web driver application loaded in the remote device or after having transmitted the data to that web driver application, a second test is carried out to determine whether or not data are to be transmitted to the requesting application (step 620).

If data are to be transmitted to the requesting application, they are transmitted to the requesting application at step 625.

For the sake of illustration, if the input obtained at step 600 is an indication that an error occurred in the connection with the remote web runtime environment or if the input obtained at step 600 is a message from a remotely displayed web application intended for the requesting application (through the web driver application executed remotely), the operating system of the requesting device should inform the requesting application of such an event.

According to another example, if a connection has been established with a remote web runtime environment, the requesting device may return a specific object to the requesting application so that the requesting application can provide messages to the remotely displayed application.

If the requesting application is a native application executed by a given operating system, specific APIs of the operating system are used to interact with the requesting application.

Alternatively, if the requesting application is a web application executed by a web runtime environment implemented in the requesting device, the transmission is typically achieved by calling a specific function of a given API or by triggering an event of a given API.

Next, if no data are to be transmitted to the requesting application (step 620) or after having transmitted data to the requesting application (step 625), a third test is carried out to determine whether or not the interaction should end (step 630).

The third test can be based on the type of the obtained input (e.g. the web driver application or the requesting application may explicitly request the end of the interaction) or can be based on the result of processing of the obtained input.

If the interaction should not end, the process is branched to step 600 so as to obtain another input. On the contrary, if the interaction should end, no more input is obtained and the process ends. In such a case, steps 615 and 625 are generally previously carried out in order to notify the web driver application and the requesting application that the interaction is about to end.

Figure 7 illustrates an example of steps carried out in a service of a remote web runtime environment. According to the illustrated example, the service is associated with a web runtime environment and a display, this service enabling a client to request the display of a web content (such as a URL) on that display through that web runtime environment.

As illustrated, the first step (step 700) is directed to receiving a web driver application. As described above, a web driver application is typically provided as a URL or as HTML data, the service that is requested being responsible for providing means to submit the driver.

In a following step (step 705), the web driver application is loaded and its execution environment is defined.

If the web driver application has been provided as a URL, loading the driver involves obtaining the data associated with that URL. Alternatively, as described with reference to Figure 3, if a web content abstract is provided, the remote web runtime environment is in charge of determining an actual web content to be loaded, such as a web application of a given type. In addition, loading data may involve providing data by the web runtime environment to the loaded web driver application. For the sake of illustration, network parameters such as an IP address and a port number of the requesting device or alternative connection means may be provided to the web driver application so that it can connect to it (such parameters may be provided by the client itself or determined by the service).

The execution environment may depend on various parameters, in particular parameters that are related to the security. Further details regarding the execution environment are provided herein below.

Then, a request for loading a web content such as a URL is received by the web driver application (step 710).

Although the step of receiving a request for loading a content is illustrated as an independent step, it is to be noted that the web content to be displayed may be provided along with the web driver application by the requesting device.

According to a particular embodiment, the request for loading a web content may be provided to the web runtime environment by the loaded web driver application which may have obtained it from the requesting device. In such a case, a specific API should be defined for enabling a driver to request the display of web content and to establish a communication channel with that web content once it has been loaded. Such an API would be somehow similar to the request of a remote display through the W3C Presentation API, without any step for displaying selection (since it is known that current web runtime environment has to be used for displaying the considered web content).

Next, the web content is loaded and a communication channel is established by the web runtime environment between the loaded web content and the loaded web driver application (step 715). Once this communication channel has been established, the web runtime environment can act as a proxy between the web driver application and the web content (step 720).

For the sake of illustration, the communication channel can be provided through an object representing the current remote display session. This session object typically enables sending messages (e.g. thanks to a specific method of that object) and receiving messages (e.g. through an event associated with that object, that event being triggered by the web runtime environment when a new message has to be delivered).

In addition, the web driver application may be allowed to indicate other types of events, for example that the connection with the requesting device has failed or that it would like to end the session (i.e. end the display of provided web content).

Displayed web content may also indicate that the session should end. This can be the case if a user can interact with the web content and decides to close the corresponding window.

It is to be noted that the end of the session does not necessarily imply the end of the execution of the service by the remote web runtime environment. For example, a web driver application may request another session for another web content if a specific API allows to do so. In such a case, a specific API may also be defined for enabling the web driver application to explicitly indicate that it can be unloaded from the execution context. A web driver application would typically make such a request based on an input received from the requesting device.

Figure 8 illustrates an example of implementing an embodiment of the invention to access a service of a remote web runtime environment, that uses a web driver application provided by a requesting device.

As illustrated, requesting application 800 executed by requesting device 802 (for example a native application executed by a constrained device) requests the display of a URL. This can be done thanks to a specific native API by using, for example, the remoteDisplay() function (step 804).

The operating system of requesting device 802 processes a call to that function by discovering remote devices providing a service allowing to remotely display web content, this service being implemented through the Presentation API or a similar API (i.e. an API providing the ability to remotely launch URLs and establish a communication channel between a main application and a remote application).

According to a particular embodiment, this discovery process is based on a standard process. However, contrary to standard process, the descriptions of the discovered services provide means for the requesting device to provide a web driver application. As described above, such means typically consist in posting a web driver application or its URL to a given URL hosted by the remote device providing the discovered service.

In the illustrated example, the URL at which a web driver application can be provided to remote device 806 is http://192.168.1.2/load-driver (step 808). This URL (/load-driver) would be defined in the description information of the corresponding service (or accessible through the description information, e.g. in a configuration document whose URL is comprised in service description).

The discovered services are displayed so that a user may select one of them. Upon selection, requesting device 802 submits its web driver application to the selected service. In the illustrated example, this is achieved by posting the URL of the considered device’s driver (http://192.168.1.1/driver) to the http://192.168.1-2/load-driver URL of selected service (step 810).

After the selected service has obtained the URL of the web driver application, it requests the corresponding resource to the requesting device or to another device and loads it in its own web runtime environment 812. Loaded web driver application 814 can then establish a connection with requesting device 802 using their preferred means (step 816), for example the WebSocket protocol or the XmlHttpRequest model. As described previously, requesting device 802 and web driver application 814 are typically provided by the same manufacturer and thus, they can interoperate using their own means.

Once this connection has been established, requesting device 802 can send a message (e.g. LOAD_URL message) indicating to web driver application 814 which URL should be loaded (step 818) (e.g. http://example.com/web-app).

When web driver application 814 receives this message, it requests the web runtime environment to display the received URL (step 820). This is achieved through a dedicated API, for example by using the driver.loadURL() function.

This dedicated API is tightly connected to the Presentation API (or similar API) as it enables requesting the display of a URL according to the means provided by the Presentation API (or a similar API). In other words, the loaded URL can rely on the Presentation API as if it had been launched without the invention (the invention has no impact on the remotely launched URL).

This request for loading a URL is handled by the web runtime environment which loads the corresponding URL and displays it to a user, contrary to the web driver application which is typically not displayed. The loaded URL is typically a web application (requested service or web app 822) that can rely on the Presentation API (or similar API). In particular, it can receive and send messages to the requesting application.

For the web runtime environment, exchanging messages is very similar to the standard Presentation API model, the web driver application acting as the main web application. However, a difference is that the web driver application is not the last step in the communication chain. Indeed, once a message has been received from the launched URL through the web runtime environment, this message is transmitted by the web driver application to the requesting device which forwards it to the requesting application. Similarly, messages can be sent by the requesting application to the remotely displayed URL.

Consequently, it can be seen that according to a particular embodiment, the invention allows a first application to rely on a remote display service provided by a device making its web runtime environment available for such remote display, typically through the Presentation API model.

As an example, the requesting application may be a native application running on a constrained device that has very limited input means. Therefore, when the requesting application needs to obtain an input from a user (e.g. a textual value to be used by the application), it may rely on a service of a remote web runtime environment that may be provided, for example, by a smartphone. If such remote web runtime environment is available, the native application may request the loading of a “remote input” application on the smartphone, which allows the user to input a textual value through the smartphone, for example using a touch keyboard or a voice-to-text feature. Interaction between the native application and the remote input application may continue until all required inputs have been obtained by the native application.

It is to be noted that a web runtime environment can embed a service of a remote web runtime environment. To that end, it should embed a server that waits for service requests and handles discovery and submission of web driver applications. Then, when receiving a web driver application, it should load this web driver application. Since the server belongs to the web runtime environment, the server can easily rely on the web runtime environment to load the web driver application.

However, a server associated with that service may not be directly embedded in a web runtime environment. For example, a server may be run as a distinct process. In this case, interacting with a web runtime environment requires relying on specific APIs made available by the considered web runtime environment so that a web driver application can be loaded. In such a case, the server is not embedded in the web runtime environment but tightly linked to it.

Still for the sake of illustration, a generic API may be defined and implemented by different web runtime environments so that the server associated with the service can be decoupled from the web runtime environment. Such an API would typically allow the server to request the loading of a given URL in a certain context associated with a service of a remote web runtime environment (i.e. with the appropriate execution context and, for example, with an object corresponding to the considered session, as described previously in reference to steps 715 and 720 in Figure 7). In the case of Android (Android is a trademark), a specific Intent could be defined for such feature, which would allow a given server to rely on any web runtime environment to provide a service. The same type of feature may be adapted to other operating systems or environments.

Generally speaking, it can therefore be understood that a service of a remote web runtime environment implies both a server for handling service requests and a web runtime environment for displaying the provided data.

According to a particular embodiment, a web driver application can be installed on the remote device providing the service of the remote web runtime environment. In such a case, upon reception of a URL associated with this web driver application or of another identifier of this web driver application, the web runtime environment indicates that this web driver application is already installed and that there is no need to download it again.

Optionally, a given version number or a timestamp may be associated with the web driver application identifier or the URL so that the web runtime environment can determine whether it has the latest version of the web drive application or not. In addition, since the web driver application may remain loaded even after the end of a session, a web runtime environment may check whether a web driver application to be loaded is already loaded or not prior to loading it.

It is to be noted that under certain circumstances, a web driver application (or more precisely an interface associated with the web driver application) may be displayed by a web runtime environment. This typically allows a user to define some parameters that may impact the behavior of the web driver application, either when communicating with the requesting device or when communicating with the web runtime environment.

For example, a frequency of interaction may be defined by the user. Depending on its value, a user may be able to decrease a processing duration which is more resource-consuming or to increase a processing duration which is less resourceconsuming. After such an input has been obtained from a user, there is no need to keep the interface of the web driver application displayed. Therefore, in such a case, the web runtime environment may advantageously determine that needed input has been obtained and that displaying the interface of the web driver application is no longer useful. The web runtime environment would then switch to displaying another user interface (typically the one associated with the remotely displayed web content), even though the web driver application is still being executed.

The determination by the web runtime environment that the needed input has been obtained may be related to an API used by the web driver application. For instance, once needed parameters have been obtained, the web driver application may call a specific function. The web runtime environment can rely on this call to determine that displaying the interface is no longer needed. Nevertheless, it is to be noted that once the display of the interface of the web driver application has ended, a dedicated user interface component may still be present in order to allow the user to change the values of defined parameters or even to stop the execution of the service.

It is to be noted that a web driver application has a specific role compared to other web applications, which consists in interfacing a web runtime environment and a service. Therefore, a specific execution environment is to be defined for web driver applications, typically by forbidding and/or allowing access to specific features. For example, a web driver application may be allowed to establish a connection only with the associated requesting device and/or with the server hosting the web driver application. According to that example, the web driver application can obtain resources or exchange messages only with this device and/or this server.

Similarly, accessing features of the device wherein the web runtime environment is implemented may not be allowed to the web driver application as it generally does not need to access such features (for example a camera or a compass).

According to another example, if specific security constraints are met, a web driver application may be allowed to access specific APIs provided by the web runtime environment, such as an API providing a low-level access to a remote device. Such a low-level access can be, for example, obtained through a full control over a UDP (User Datagram Protocol) or TCP (Transmission Control Protocol) connection (in contrast to connections based on specific protocols or models such as those known as XmlHttpRequest or WebSocket which are both generally accessible to web applications).

It is to be recalled that W3C Presentation API is an example of an API that may be used to enable a web application to request the remote display of web content. When doing so, the requesting web application and the remotely displayed web content are both provided with a specific object associated with the current session, this object allowing both ends to interact, especially by sending and receiving messages.

The Presentation API may be used between two different devices, the second one providing a “remote Presentation API” service (i.e. a specific type of service of a remote web runtime environment). In such a case, the remotely loaded web content relies on the Presentation API. Implementing an embodiment of the invention is advantageous for the web runtime environment to also rely on the Presentation API to enable interaction between itself and the loaded web driver application. Indeed, the web driver application can be considered as being a requesting web application, except that when it requests the display of web content, the target display is already known and is the one associated with the current web runtime application. Hence, in this case, the step of selecting a remote display can be skipped as it has already been performed on the requesting device (which, as has been described previously, is not necessarily a web runtime environment). By doing so, there are few differences between a “local” requesting web application (i.e. executed by a web runtime environment implemented in the requesting device) and a web driver application locally executed by the web runtime environment implemented in the requesting device but associated with another “main application” executed by the requesting device. Such a model may allow an easy integration of the invention in a web runtime environment.

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-disk (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 3 to 7 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 3 to 7.

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

1. A method implemented by a requesting device for processing a service request from a service requester application of the requesting device, the service to be carried out in a remote web runtime environment, the method comprising: - determining a service provider comprising said web runtime environment and being capable of providing the requested service through a submitted web driver application; - submitting the web driver application to the determined service provider; and - interacting with the web driver application executed by the web runtime environment, causing the service provider to provide the requested service; wherein the web driver application interacts with the web runtime environment through a standard API.

2. The method of claim 1, wherein the step of determining a service provider comprises a step of receiving an indication for determining that the service provider supports web driver application submission.

3. The method of claim 1 or claim 2, further comprising a step of determining a URL defining a location at which the web driver application is to be submitted.

4. The method of claim 3, the URL being received from the service provider or being determined as a function of an item of information received from the service provider.

5. The method of any one of claims 1 to 4, further comprising a step of transmitting the web driver application to the service provider as a URL defining a source from which the web driver application can be loaded or as source code.

6. The method of any one of claims 1 to 5, further comprising a step of determining a communication configuration for submitting the web driver application to the determined service provider.

7. The method of any one of claims 1 to 6, further comprising a step of selecting one web driver application to be submitted to the determined service provider from among a plurality of web driver applications.

8. The method of any one of claims 1 to 7, further comprising a step of transmitting data or references to data to the service provider.

9. The method of claim 8, wherein the data or the referenced data comprise data to be processed by the requested service.

10. The method of claim 8, wherein the data or the referenced data are representative of a web application type.

11. The method of any one of claims 8 to 10, wherein the step of submitting the web driver application to the determined service provider comprises the step of transmitting the data or the references to data.

12. The method of any one of claims 1 to 11, wherein the step of interacting comprises a step of receiving data from the requested service through the web driver application.

13. The method of claim 12, wherein the received data are data entered by a user via an interface of the service provider, the interface being associated with a web application of which the launch is part of the requested service.

14. A method for a service provider to provide a service, the method comprising: - receiving a submission for a web driver application enabling communication with a web application and a component of a remote requesting device; - loading the web driver application in the service provider; - launching the web application in the service provider for providing the service; and - interacting with the component of the remote requesting device and the web application through the web driver application, causing the service provider to provide the service; wherein the service provider comprises a web runtime environment and a server, the web runtime environment enabling execution of the web driver application and of the web application and the server enabling execution of the steps of receiving a submission and of loading the web driver application; and wherein the web driver application interacts with the web runtime environment through a standard API.

15. The method of claim 14, wherein the server is a component of the web runtime environment.

16. The method of claim 14, wherein the server is independent from the web runtime environment, the web runtime environment and the server being connected to each other through a standard interface.

17. The method of any one of claims 14 to 16, further comprising a preliminary step of transmitting an indication that the service provider supports web driver application submission.

18. The method of claim 17, wherein the indication comprises a URL defining a location at which the web driver application is to be submitted.

19. The method of any one of claims 14 to 18, further comprising a step of receiving the web driver application from the remote requesting device as a URL defining a source from which the web driver application can be loaded or as source code.

20. The method of any one of claim 14 to 19, further comprising a preliminary step of verifying that the version of the web driver application in the received submission is the latest version of the web driver application, prior to loading the web driver application.

21. The method of any one of claims 14 to 20, further comprising a preliminary step of verifying that the web driver application is not already installed within the service provider, prior to loading the web driver application.

22. The method of any one of claims 14 to 21, further comprising a step of receiving data or references to data.

23. The method of claim 22, wherein the received data or referenced data comprise data to be processed by the service.

24. The method of claim 23, wherein the received data or referenced data enable the steps of loading the web driver application and of launching the web application to be carried out simultaneously.

25. The method of claim 24, wherein the received data or referenced data represents a web application type, the web application being determined as a function of the web application type.

26. The method of any one of claims 14 to 25, wherein the step of interacting comprises a step of transmitting data to the remote requesting device through the web driver application.

27. The method of claim 26, wherein the transmitted data are data entered by a user via an interface of the service provider, the interface being associated with the web application.

28. 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 27 when the program is loaded and executed by a programmable apparatus.

29. A computer-readable storage medium storing instructions of a computer program for implementing the method according to any one of claims 1 to 27.

30. A requesting device for processing of a service request from a service requester application of the requesting device, the service to be carried out in a remote web runtime environment, the device comprising at least one microprocessor configured for carrying out the steps of: - determining a service provider comprising said web runtime environment and being capable of providing the requested service through a submitted web driver application; - submitting the web driver application to the determined service provider; and - interacting with the web driver application executed by the web runtime environment, causing the service provider to provide the requested service; wherein the web driver application interacts with the web runtime environment through a standard API.

31. The device of claim 30, wherein the at least one microprocessor is further configured so that the step of determining a service provider comprises a step of receiving an indication for determining that the service provider supports web driver application submission.

32. The device of claim 31 or claim 32, wherein the at least one microprocessor is further configured for carrying out a step of determining a URL defining a location at which the web driver application is to be submitted.

33. The device of claim 32, wherein the at least one microprocessor is further configured so that the URL is received from the service provider or is determined as a function of an item of information received from the service provider.

34. The device of any one of claims 30 to 33, wherein the at least one microprocessor is further configured for carrying out a step of transmitting the web driver application to the service provider as a URL defining a source from which the web driver application can be loaded or as source code.

35. The device of any one of claims 30 to 34, wherein the at least one microprocessor is further configured for carrying out a step of determining a communication configuration for submitting the web driver application to the determined service provider.

36. The device of any one of claims 30 to 35, wherein the at least one microprocessor is further configured for carrying out a step of selecting one web driver application to be submitted to the determined service provider from among a plurality of web driver applications.

37. The device of any one of claims 30 to 36, wherein the at least one microprocessor is further configured for carrying out a step of transmitting data or references to data to the service provider.

38. The device of claim 37, wherein the data or the referenced data are data to be processed by the requested service, the at least one microprocessor being further configured so that the step of submitting the web driver application to the determined service provider comprises the step of transmitting the data or the references to data.

39. The device of any one of claims 30 to 38, wherein the at least one microprocessor is further configured so that the step of interacting comprises a step of receiving data from the requested service through the web driver application.

40. A device for a service provider to provide a service, the device comprising at least one microprocessor configured for carrying out the steps of: - receiving a submission for a web driver application enabling communication with a web application and a component of a remote requesting device; - loading the web driver application in the service provider; - launching the web application in the service provider for providing the service; and - interacting with the component of the remote requesting device and the web application through the web driver application, causing the service provider to provide the service; wherein the service provider comprises a web runtime environment and a server, the web runtime environment enabling execution of the web driver application and of the web application and the server enabling execution of the steps of receiving a submission and of loading the web driver application; and wherein the web driver application interacts with the web runtime environment through a standard API.

41. The device of claim 40, wherein the device comprises the web runtime environment and wherein the server is a component of the web runtime environment.

42. The device of claim 40, wherein the device comprises the web runtime environment and a standard interface for communicating with the server, the server being independent from the web runtime environment.

43. The device of any one of claims 40 or claim 42, wherein the at least one microprocessor is further configured for carrying out a preliminary step of transmitting an indication that the service provider supports web driver application submission.

44. The device of any one of claims 40 to 43, wherein the at least one microprocessor is further configured for carrying out a step of receiving the web driver application from the remote requesting device as a URL defining a source from which the web driver application can be loaded or as source code.

45. The device of any one of claim 40 to 44, wherein the at least one microprocessor is further configured for carrying out a preliminary step of verifying that the version of the web driver application in the received submission is the latest version of the web driver application, prior to loading the web driver application.

46. The device of any one of claims 40 to 45, wherein the at least one microprocessor is further configured for carrying out a preliminary step of verifying that the web driver application is not already installed within the service provider, prior to loading the web driver application.

47. The device of any one of claims 40 to 46, wherein the at least one microprocessor is further configured for carrying out a step of receiving data or references to data.

48. The device of claim 47, wherein the received data or referenced data comprise data to be processed by the service, the at least one microprocessor being further configured for carrying out so that the received data or referenced data enable the steps of loading the web driver application and of launching the web application are carried out simultaneously.

49. The device of any one of claims 40 to 48, wherein the at least one microprocessor is further configured so that the step of interacting comprises a step of transmitting data to the remote requesting device through the web driver application.