GB2554696A

GB2554696A - Methods of interacting between two devices and corresponding devices and system

Info

Publication number: GB2554696A
Application number: GB1616855.1A
Authority: GB
Inventors: Bellessort Romain; Ouedraogo Naël
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2016-10-04
Filing date: 2016-10-04
Publication date: 2018-04-11
Also published as: GB201616855D0

Abstract

A method of securely interacting between two devices via a unidirectional communications connection is disclosed. A first device 510 such as a printer, scanner, camera or projector indicates an action (such as maintenance) to be performed for modifying its current state. When it is detected that this state has changed, the advertising device generates a URL based on its new current state. Preferably, this URL indicates at least one action to be performed to reach a target state from the new current state. It is then transmitted to a user device such as a mobile or laptop 520 in a message. It is also proposed that upon reception of the message, the user device determines whether the received URL is suitable for execution. If so, it determines an eligible web runtime environment of the user device, in which the received URL can be loaded. Finally, the received URL is loaded without need of user intervention.

Description

(54) Title of the Invention: Methods of interacting between two devices and corresponding devices and system Abstract Title: Methods of interacting between two electronic devices (57) A method of securely interacting between two devices via a unidirectional communications connection is disclosed. A first device 510 such as a printer, scanner, camera or projector indicates an action (such as maintenance) to be performed for modifying its current state. When it is detected that this state has changed, the advertising device generates a URL based on its new current state. Preferably, this URL indicates at least one action to be performed to reach a target state from the new current state. It is then transmitted to a user device such as a mobile or laptop 520 in a message. It is also proposed that upon reception of the message, the user device determines whether the received URL is suitable for execution. If so, it determines an eligible web runtime environment of the user device, in which the received URL can be loaded. Finally, the received URL is loaded without need of user intervention.

1/6

100

110

120

130

190

Fig. 1

2/6

Fig. 2

3/6

Fig. 3

4/6

430

Fig. 4

5/6

500

Fig. 5

6/6

Fig. 6

METHODS OF INTERACTING BETWEEN TWO DEVICES AND CORRESPONDING DEVICES AND SYSTEM

FIELD OF THE INVENTION

The present invention relates to methods of interacting between two devices, as well as corresponding devices and a system comprising these devices.

BACKGROUND OF THE INVENTION

As usage of electronic devices for accessing web services is always increasing, there may be an interest for a user of a device to be suggested a web resource, for instance a web page or another web application.

For these purposes, nowadays technologies allow a device to advertise a URL (Uniform Resource Locator), i.e. the web address of a resource, in order to enable another device to obtain the resource. Thus, when a URL is loaded on a device, this device can access the resource, i.e. for instance load the web page.

Usually, after the URL is loaded, a bidirectional connection is established in order to allow interaction between the advertising device and the receiving device. For instance, this interaction may consist in remotely controlling the advertising device (e.g. for remotely configuring its settings or for remotely triggering picture-taking) or in dynamically providing information about the advertising device (e.g. displaying a stepby-step user guide on the receiving device).

For these purposes, the URL may comprise an identifier of the advertising device so that the associated web application can send data to it. In this case, data are typically sent with help of a web server acting as a proxy between the advertising device and the receiving device executing the web application.

However, depending on the capabilities of each device, it may be necessary to use a specific API/protocol to enable the connection. In addition, such a connection may increase security risks since the advertising device may be compromised and may access to personal data or sensitive/secured functions of the receiving device.

Consequently, there is a need for allowing the advertising device and the receiving device to interact without establishing such a bidirectional connection.

SUMMARY OF THE INVENTION

The present invention has been devised to address one or more of the foregoing concerns.

According to a first aspect of the invention, there is provided a method of interacting between two devices, the method comprising, at a first device:

determining a first state of the first device; and indicating at least one action to be performed on the first device for changing its first state;

determining a second state reached by the first device; generating a URL based on the second state ; and transmitting an advertisement message comprising the generated URL to a second device.

Therefore, the method according to the first aspect of the invention makes it possible for the first device to interact with the second device, notably by providing the second device with a specific URL which loading will allow an action function of the state of the first device to be performed.

Also, the management of states of the first device is improved, without need of establishing a bidirectional connection between the advertising device (first device) and the user device (second device).

Advantageously, the energy consumption is reduced since fewer data are exchanged compared to an interaction through a bidirectional connection, and the interaction is more secure.

Optional features of the invention are further defined in the dependent appended claims.

According to embodiments, the transmission of the advertisement message may be performed according to the Eddystone specification.

According to embodiments, the generated URL enables loading of a resource indicating at least one action to be performed to reach a target state from the second state.

According to embodiments, the method comprises determining a list of actions to be performed to reach the target state from the second state.

According to embodiments, generating a URL comprises adding a complementary part to a base URL, said complementary part comprising an identifier of each action to be performed or an encoded version of it.

According to embodiments, generating comprises adding an error indication in the complementary part when it is determined that the first device is in an unexpected state that does not correspond to the target state or to an intermediary state caused by said at least one action to be performed.

According to embodiments, the error indication is an identifier of an action of undoing an unexpected action, or an encoded version of it.

According to embodiments, the complementary part indicates the current step in a step-by-step process.

According to embodiments, the step of indicating is performed by a component of the first device.

For instance, this component may cause the display of a notification on a display of the first device. In a variant, it may cause the flashing of a LED indicating that there is a problem with the first device.

According to embodiments, the step of indicating comprises advertising a URL indicating the at least one action to be performed on the first device for changing its first state.

According to embodiments, the advertisement message comprises a continuation indication indicating that the generated URL may be loaded in the same execution context as another URL previously loaded by the second device.

According to embodiments, the continuation indication is a flag.

According to embodiments, the continuation indication is a part of the generated URL.

According to embodiments, the continuation indication is a fragment of the URL or a string of at least one character appended to the end of the generated URL.

According to a second aspect of the invention, there is provided a method of interacting between two devices, the method comprising, at a second device:

receiving an advertisement message comprising a URL from the first device generated as aforementioned;

determining, based on the received advertisement message, whether the generated URL is suitable for execution in an existing execution context;

upon positive determination, determining an eligible existing execution context running in a web runtime environment of the second device, in which the generated URL can be loaded; and loading the received URL in said eligible existing execution context.

Therefore, the method according to the second aspect of the invention makes it possible for the second device to interact with the first device.

This is notably thanks to the specific URL provided by the first device and enabling the loading of a resource indicating an action to be performed in function of the state of the first device.

Advantageously, an existing execution context of the second device can be reused for loading the generated URL and the user experience is improved since the user is not solicited for authorizing the loading of the URL, i.e. for opening a new execution context.

Hence, the handling of advertised URLs is improved, without need of establishing a bidirectional connection between the advertising device (first device) and the user device (second device). For instance, even though no connection has been established between the advertising device and the user device, a web page can be seamlessly updated in order to indicate a second action to be performed after a first action has been performed on the first device.

Typically, there are two cases explicating the presence of existing execution contexts in the second device. First, a user of this device may have voluntarily loaded a URL. For instance, this may be the URL of a help web page loaded by the user after seeing a flashing LED indicating a problem on the first device. Thus, there may be an existing context even if no URL has been received in an advertisement message. Second, the URL may have been advertised to the second device in an advertisement message and the user may have authorized the loading by selecting this advertised URL.

According to embodiments, determining an eligible existing execution context comprises determining a URL that has been loaded in an existing execution context running in a web runtime environment of the second device.

According to embodiments, the existing execution context is determined as being eligible only if said determined URL is associated with the same domain name and/or the same origin as the generated URL.

According to embodiments, the existing execution context is determined as being eligible only if said determined URL is the same as the generated URL except for the fragment part.

According to embodiments, the received advertisement message comprises a continuation indication indicating that the generated URL may be loaded in the same execution context as another URL previously loaded by the second device and the determination steps are based on this continuation indication.

According to embodiments, the existing execution context is determined as being eligible only if said determined URL has been obtained through another advertisement message.

According to embodiments, the existing execution context is determined as being eligible only if said other advertisement message was also from the first device.

According to embodiments, a plurality of eligible existing execution contexts is determined, and the method further comprises selecting one of them, the received URL being loaded in the selected eligible existing execution context.

According to embodiments, the eligible existing execution context is selected only if said determined URL has been obtained through an advertisement message from the first device.

According to embodiments, the eligible existing execution context in which a URL has been loaded the most recently is selected.

According to a third aspect of the invention, there is provided a first device configured for:

According to embodiments, the first device is configured so that the generated URL indicates at least one action to be performed to reach a target state from the second state.

According to a fourth aspect of the invention, there is provided a second device configured for:

receiving an advertisement message comprising a URL generated by a first device aforementioned;

determining an eligible existing execution context running in a web runtime environment ofthe second device, in which the generated URL can be loaded; and loading the received URL in said eligible existing execution context.

According to embodiments, the second device comprises a component specifically developed to identify URLs associated with a given base URL.

According to a fifth aspect of the invention, there is provided a system comprising a first device as aforementioned and a second device as aforementioned, the first and the second device being configured for interacting without establishing a bidirectional connection.

The other aspects of the present invention have optional features and advantages similar to the first and second aspect above-mentioned.

The invention also concerns a method substantially as described herein with reference to, and as shown in Figures 1, 2, 3 and 4, a system substantially as described herein with reference to, and as shown in Figure 5, and a device substantially as described herein with reference to, and as shown in Figure 5 or 6.

Since the present invention may be implemented in software, the present invention may 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 or 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

Embodiments of the invention will now be described, by way of example only, and with reference to the following drawings in which:

Figure 1 is a flowchart illustrating general steps of a method of interacting performed by a first device according to embodiments;

Figure 2 is a flowchart illustrating steps for building dynamically URLs according to embodiments;

Figure 3 is a flowchart illustrating general steps of a method of interacting performed by a second device according to embodiments;

Figure 4 is a flowchart illustrating steps for determining whether there is an eligible existing execution context in which a received URL can be loaded according to embodiments;

Figure 5 illustrates an example of context in which embodiments of the invention may be implemented; and

Figure 6 represents a block diagram of the first and/or second device according to embodiments.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

According to general embodiments, the advertising device (first device) indicates an action to be performed for modifying its current state (initial or first state). When it is detected that this state has changed, the advertising device generates a URL based on its new current state (second state). Preferably, this URL indicates at least one action to be performed to reach a target state from the new current state (second state). It is then transmitted to a user device (second device) in an advertisement message.

Upon reception of the advertisement message, the user device determines whether the received URL is suitable for execution in an existing execution context. If so, it determines an eligible existing execution context running in a web runtime environment of the user device, in which the received URL can be loaded. Finally, the received URL is loaded in this eligible existing execution context, without need of user consent.

Figure 1 shows general steps of a method of interacting between two devices, according to embodiments. These steps aim notably at managing the state of a first device and are for instance performed by the advertising device 510 shown in Figure 5.

First, at step 100, the current state of the first device is determined. This state is defined by a number of parameters, for instance whether or not a given tray is open, the position of a given part of the first device, the state of a button, whether or not a particular interface is displayed, or other physical or logical parameters. In order to minimize the number of states, the possible values for each parameter may be discretized. For instance, a tray may either be open or closed. The first device itself can determine such physical parameters and make them accessible to software components. Consequently, it is assumed that a software component running on the first device can determine the current state of said first device.

Step 100 is followed by step 110 where the first device provides information indicating which action(s) has(have) to be performed on the first device for changing its state. For instance, the information may indicate that there is an issue with said first device (e.g. paper jam or low ink on a printer, no more memory on a camera, lamp to be changed on a projector...). As another example, the information may invite to manipulate said first device in order to achieve a specific target based on a tutorial or user guide (e.g. perform specific settings on a camera).

Such indication may be provided through different means.

A URL may be advertised so that user can load it on his/her own device (second device), and said URL may describe the action to be performed.

Alternatively, a specific component of the first device may be used to provide such indication to the user. This may be a light that may e.g. blink or be turned on (e.g. with a specific color); the light itself may not be sufficient for the user to understand exactly the action to be performed, but a user guide may provide detailed explanations to the user. If the first device has a screen, said screen may also be used to indicate to the user the action to be performed.

In a variant, the URL may be advertised from the first device to the second device and in addition, a specific component of the first device may provide a specific indication on the first device (display, light...).

At step 120, the first device determines that it is no longer in the first state. Next, it determines its new current state called second state as at step 100.

Step 120 is followed by step 130 which consists in advertising a URL associated with said second state. This URL can be determined through different ways. A first solution may consist in defining specific URLs for each state depending on potential previous and next states (e.g. in a step by step explanation). A second solution may consist in building dynamically URLs based on the current state and potential previous and next ones. An example of such solution is described with reference to Figure 2. As explained in the following description, a continuation indication may be associated with the advertised URL so that a receiving device may determine that the advertised URL can be loaded in an existing execution context.

Step 130 is followed by the end of the process (step 190).

Thanks to these embodiments, the management of states of the first device is improved though an interaction between the first and the second device, without need of establishing a bidirectional connection between them.

Figure 2 shows steps for building dynamically URLs according to embodiments. These steps are for instance performed by the advertising device (first device) 510 shown in Figure 5.

First, at step 200, the current state (i.e. the second state of Figure 1) is determined, as well as a target state. The target state is a state that requires one or more actions to be performed on the first device to be reached.

At step 210, the list of actions to be performed to reach the determined target state from the current state is determined.

For instance, for each different scenario each comprising different steps, the list of actions to be performed may have been predefined. In function of the current scenario, it is thus possible to determine the current step and which other action(s) must be performed to reach the target state.

Alternatively, a graph of possible transitions (i.e. set of actions to be performed) between different states may be defined, and in function of the current state and of the target state, the list of states to go through (thus defining the actions to perform) is determined.

Next, at step 220, a URL is built based on the determined list of actions. For instance, a base URL may be used and a complementary part based on the determined list of actions may be appended to the base URL.

For illustrative purposes, the URL http://example.org/actions/ may be used as a base URL and #a1-a2-a3 may be used as a complementary part to indicate that actions a1, a2 and a3 have to be performed to reach the target state. In this example, the resulting URL is thus http://example.Org/actions/#a1-a2-a3.

In practice, specific identifiers may be defined for each action. It should be noted that these identifiers do not have to be understood by the user, but only by the web application executed when the corresponding URL is loaded. When executed, said web application can determine the identifiers and provide appropriate explanations to the user regarding actions to be performed.

At step 230, it is then determined whether the current state is an expected state. A state is considered as expected when it corresponds to the target state or an intermediary state caused by some of the actions of the list of actions in the order indicated in the URL.

For instance, if the actions a1, a2 and a3 were expected to be performed, but that a1 and then a4 were performed instead, the current state is considered as not expected. As a consequence, it may be determined that the next action to be performed is e.g. to undo a4. For instance, this action may be designated by a specific identifier such as b4.

If the current state is an expected state, the URL generated at step 220 can be advertised as such and the process ends at step 290.

On the other hand, if the state is not an expected state, the URL generated at step 220 should be modified to take this into account. For these proposes, an error indication is added to the URL at step 250. Then, the reading of this error indication by the web application may cause the provision of an error message to the user of the second device, e.g. an error message is displayed or read to the user. In practice, this can be achieved by appending the indication “-e” to the built URL. Back to the illustrative example mentioned, the resulting URL may thus be http: //exa m p I e. o rg/acti o ns/#a 1 -a2- a3- e.

Then, the process ends (step 290).

As it may be advantageous to build short URLs, in some embodiments, the complementary part of the URL is made of encoded indications. For instance, instead of adding a chain of characters “a1-a2-a3-e” (8 characters), each action can be encoded on 4 bits. Thus, there may be at most 16 different actions. Then, each action may be associated with a 4-bits value, the 3 actions and the error indication being encoded on 2 bytes (i.e. 16 bits), hence 2 characters. Obviously, the encoding may be performed with a different number of bits.

According to embodiments, other indications may be added to the base URL. For instance, the current step in a process may be added so that user may be made aware of it. An advantage of defining specific URLs for each state of a process beforehand is that such information does not have to be provided through URL. Instead, the URL itself indicates such information.

Figure 3 shows general steps of a method of interacting between two devices, according to embodiments. These steps aim notably at handling an advertised URL and are for instance performed by the user device (second device) 520 shown in Figure 5.

First, at step 300, a URL is received through an advertisement message.

At step 305, it is determined that URL is suitable for being loaded in an existing execution context. Such determination may be based on different criteria.

For instance, advertisement messages may be designed so that the advertising device may include a continuation indication into them. Such a continuation indication aims at explicitly indicating to the user device that the advertised URL may be loaded in the same execution context as an already loaded URL. Such a continuation indication may for instance be in the form of a dedicated flag in the advertisement message.

Alternatively, the usage of a specific syntax in the advertised URL itself may allow providing this indication. For instance, URL fragments (parts after a # character in the URL) may be used to indicate that the advertised URL can be loaded in an existing execution context. In this case, the URL would typically be loaded in a context that is executing a URL which is similar to the advertised URL apart from the fragment part. For illustrative purposes, the advertised URL http://example.Org/abc#456 may be loaded in the same execution as the previously loaded URL http://example.Org/abc#123 or http://example.org/abc.

Instead of fragments, other characters/strings or syntaxes may be used. For instance, a specific suffix may be appended to the end of the URL (e.g. “.continuation”) to indicate that it may be loaded in the same execution context as another URL.

According to embodiments, a component of the second device is configured to identify URLs to be handled as continuation URLs. For instance, the component has been specifically developed to handle URLs associated with a given base URL, e.g. the base URL http://www.example.org.

At step 310, it is determined whether there is an execution context running in a web runtime environment of the second device, in which the received URL may be loaded. In the following description, such an execution context is referred to as an “eligible” execution context (i.e. eligible for loading the received URL). Generally speaking, this determination may involve different criteria.

For instance, the determination may comprise a comparison between the advertised URL and a URL already loaded in an execution context to evaluate the “similarity” between these URLs. For example, the execution context may be considered as eligible if these URLs differ only by their fragment parts, or if they have the same domain name and/or the same origin (i.e. same protocol, host and port, e.g. http://www.example.org:80).

In a variant, the determination may be such that an existing execution context is eligible only if the URL already loaded in this execution context has been obtained through an advertisement message.

More specifically, it may be required that the URL already loaded has been obtained through an advertisement message transmitted by the same advertising device as the one that transmitted the URL currently being processed.

This may be determined for instance by reading the value of a parameter called « fromDevice » associated with each executing context. If this parameter is null, it means that the corresponding URL (i.e. the URL executed in this execution context) has not been obtained through an advertisement message. Otherwise, if this parameter is not null, it means that the executing context has executed at least one URL received through an advertisement message. The “fromDevice” parameter allows the device from which this advertisement message is to be identified, for instance by its network address and/or via information/identifiers specific to this device. The value of this parameter for the different executing contexts is attributed by a component in charge of obtaining/handling the advertisement messages and of asking the loading of URLs. For instance, this component is a browser or a specific component capable of interacting with the browser.

An exemplary procedure for this determination step is described with reference to Figure 4.

In the case where there are several eligible execution contexts determined at step 310, one of them is selected at step 320. The received URL will be loaded in the selected execution context.

For instance, the eligible execution context that has been used the most recently (i.e. the eligible execution context in which a URL has been loaded the most recently) among them may be selected.

Alternatively, another criterion may be used to select an eligible execution context. For instance, if there is only one eligible execution context whose current loaded URL has been obtained through an advertisement and from the same advertising device as the received URL, this eligible execution context may be preferably selected, even if it is not the most recent.

Next, at step 330, the received URL is loaded in the selected execution context.

In the case where there is no eligible execution context available in the second device (response NO to test 310), the process usually applied when a new URL is received is performed at step 340. This consists in displaying a notification allowing the user to request the loading of said received URL in a new execution context.

Finally, after steps 330 and 340, the process ends (step 390).

Thanks to these embodiments, the handling of an advertised URL from the first device is improved through an interaction between the first and the second device, without need of establishing a bidirectional connection between them.

It should be noted that contrary to prior art, in these embodiments, the advertised URL may be loaded in an existing execution context of a web runtime environment without the user being notified. This improves greatly the user experience.

Figure 4 describes steps for determining whether there is an eligible existing execution context in which the URL received at step 300 can be loaded. These steps are an exemplary implementation of step 310 and are for instance performed by the user device (second device) 520 shown in Figure 5, typically by a component of this device. For instance, this component is a dedicated component or a component integrated to the web runtime environment (e.g. browser).

At step 400, the user device identifies existing execution contexts running in one of its web runtime environments as well as URLs loaded in these execution contexts.

In practice, web runtime environments provide means for obtaining such information, typically through a dedicated API. This API comprises for instance a function that provides a list of the existing execution contexts. Each context may be associated with further information, for instance a value of the «fromDevice» parameter as mentioned previously.

At step 410, the user device checks whether there is any context not yet processed. Initially, all existing contexts are considered as not yet processed.

If so, the user device determines at step 420 whether the received URL and the URL executed in the considered execution context differ only through their fragment parts. For illustration purposes, the following URLs differ only through their fragment parts: http://example.Org/abc#456, http://example.Org/abc#123 and http://example.org/abc.

In case of positive determination, the considered existing execution context is added to a list of eligible existing execution contexts at step 430. After step 430, the considered existing execution context is marked as processed at step 440 and the process goes back to step 410.

In case of negative determination, the considered existing execution context is also marked as processed at step 440 and the process goes back to step 410.

When all existing execution contexts are processed, the process ends at step 490.

As previously described, these steps are merely an example of a possible procedure and other criteria may be considered for determining eligible execution contexts.

In particular, the web runtime environment may decide to consider as eligible only execution contexts that have been created upon request of the user to load a URL obtained through an advertisement message. More specifically, it may be required that the URL has been obtained through an advertisement message advertised by the same first device as the one that advertised the URL.

In embodiments, the loading of a URL and execution of corresponding resource is performed by a web runtime environment (a web execution engine such as a web browser). Such web runtime environment may fully implement embodiments by supporting the receiving of advertisement message. However, this task may also be handled by a dedicated software component which may be called a discovery agent. This agent is then in charge of interacting with a web runtime environment in order to trigger the loading of the received URL. Generally, this is done upon user authorization so that only a URL the user is interested in is loaded.

Such discovery agent is configured to send requests to the web runtime environment so that a given URL may be loaded in an existing execution context. A dedicated API may therefore be provided so that the discovery agent can determine whether a URL similar to the received one is already associated with an existing context, and if so, to request the loading of said received URL in the same context.

Figure 5 illustrates an example of context in which embodiments of the invention may be implemented.

The represented system 500 comprises a first device 510 (advertising device), a second device 520 (user device).

The first device 510 is for instance a multi-function printer, a scanning device, a camera or a projector.

The second device 520 may be an end-user device such as a mobile device, a smartphone, a micro-computer (laptop), a workstation, a desktop computer or a light portable device. It is configured to execute a web runtime environment in which execution context(s) may run and in which URLs may be loaded.

For illustrative purposes, a printer (first device) running out of ink is considered. It advertises a URL providing explanations regarding how to change cartridges, for instance http://example.org/ink. On the other hand, a user has a smartphone (second device) that is capable of obtaining the advertisement message comprising said URL. The smartphone displays a notification to the user so he/she can request the loading of the corresponding URL. The notification for instance indicates that the printer is running out of ink and describes how to change cartridges. When the user selects the notification, the corresponding URL is loaded in a web runtime environment, for instance a web browser. Thanks to information displayed by the web browser, the user understands that he/she should first open the tray on the top of the printer.

When the user does this action, the printer detects so and determines that the next action to be performed is to press a button so that the cartridges may be made accessible to the user. The printer advertises a new URL which corresponds to the continuation of the previous action. A continuation indication is therefore added to the advertisement message for the new URL. This indication may be a flag or a specific part of the URL, for instance a URL fragment. For example, this new URL may be http://example.Org/ink#2.

Upon receiving the corresponding advertisement message, the smartphone determines that there is a continuation indication and that this new URL should not be handled as other URLs obtained through advertisement. More specifically, instead of displaying a notification to the user for this URL, this URL is loaded in the same execution context as the previous one. Consequently, even though no connection has been established between the printer and the smartphone, the web page can be updated after the first action performed by the user in order to indicate the second action to be performed. This process is seamless for the user.

Still for illustration purposes, instead of advertising a first URL indicating how to change the cartridges, the printer may simply turn on an orange light. This orange light is an indication provided for indicating that cartridges should be changed. If the user is not yet aware of it, he/she may understand it by checking a user guide (which may be a book, a native application or a web application for instance). Based on this, the user may perform the first required action (e.g. open tray). From there, this example is similar to previous example on the printer side: the change of state is determined and a URL to be advertised is determined, e.g. http://example.Org/ink#2.

However, on the smartphone side (client side), it may happen that no similar URL has already been loaded and is being executed. For instance, this may be the case if the user referred to a book or to a native application, or if the user was already aware of the meaning of the orange light. In this case, the smartphone determines that there is no such execution context and processes the URL as if there was no continuation indication in the advertisement (i.e. a notification is displayed, and the URL is loaded in a new context if the user requests to load it). On the other hand, it may also happen that a similar URL (such as http://example.org/ink or http://example.Org/ink#1) is already executed on the smartphone. For instance, this may happen if the user used a web application to determine the meaning of orange light, or if the user reached such URL by searching for explanations regarding said orange light through a web search. In this case, the situation is similar to the previous example, i.e. there is an execution context with a similar URL. Therefore, the considered URL can be loaded in said context.

Figure 6 represents an exemplary architecture 600, for instance for the first device 510 (advertising device) or the second device 520 (e.g. smartphone) shown in Figure 5.

The device 600 comprises a communication bus 602 to which there are preferably connected:

- a central processing unit 604, such as a microprocessor, denoted CPU;

- a read only memory 606, denoted ROM, for storing computer programs for implementing the invention;

- a random access memory 608, denoted RAM, for storing the executable code of methods according to embodiments of the invention as well as the registers adapted to record variables and parameters necessary for implementing methods according to embodiments of the invention;

- a communication interface 612 connected to a communication network 614 over which communications can be implemented, for instance for exchanging HTTP or HTTPS requests/responses, e.g. for the loading of a URL; and

- a data storage means 610 such as a hard disk, for storing computer programs for implementing steps of one or more embodiments of the invention and for storing data, during the implementation of one or more embodiments of the invention.

The device 600 also includes a user interface 616 to display information to, and/or receive inputs from, a user. For instance, it may be a screen for displaying data such as the user interface of a web application and/or serving as a graphical interface with a user, by means of a keyboard or any other pointing means.

The communication bus provides communication and interoperability between the various elements included in the device 600 or connected to it. The representation of the bus is not limiting and in particular the CPU 604 is operable to communicate instructions to any element of the device 600 directly or by means of another element of the device 600.

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

Instructions relating to the software application may be loaded to the main memory 608 from a hard-disk (HD) 610 or the program ROM 606 for example. According to a variant, the executable code of the programs can be received by means of the communication network 614, via the interfaces 612, in order to be stored in one of the storage means of the device 600, such as the hard-disk 610, before being executed. Such software application, when executed by the CPU 604, causes steps described with reference to one of Figures 1 to 4 to be performed in the device 600.

The CPU 604 is adapted to control and direct the execution of the instructions or portions of software code of the program or programs according to 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 610 or in the ROM 606, are transferred into the RAM 608, 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.

In this embodiment, the device is a programmable apparatus which uses software to implement the invention. However, alternatively, the present invention may be implemented in hardware (for example, in the form of an Application Specific Integrated Circuit or ASIC). It can consist of one or more dedicated integrated circuits that are capable of implementing one of the methods described with reference to Figures 1 to 4.

While the invention has been illustrated and described in detail in the drawings and foregoing description, such illustration and description are to be considered illustrative or exemplary and not restrictive, the invention being not restricted to the disclosed embodiment. Other variations to the disclosed embodiment can be understood and effected by those skilled in the art in putting into practice (i.e.

performing) the claimed invention, from a study of the drawings, the disclosure and the appended claims.

In the claims, the word “comprising” does not exclude other elements or steps, and the indefinite article “a” or “an” does not exclude a plurality. A single processor or other unit may fulfil the functions of several items recited in the claims. The mere fact that different features are recited in mutually different dependent claims does not indicate that a combination of these features cannot be advantageously used. Any reference signs in the claims should not be construed as limiting the scope of the invention.

Claims

1. A method of interacting between two devices, the method comprising, at a first device:

2. The method of claim 1, wherein said URL enables loading of a resource indicating at least one action to be performed to reach a target state from the second state.

3. The method of claim 2, comprising determining a list of actions to be performed to reach the target state from the second state.

4. The method of claim 2 or 3, wherein generating a URL comprises adding a complementary part to a base URL, said complementary part comprising an identifier of each action to be performed or an encoded version of it.

5. The method of claim 4, wherein generating comprises adding an error indication in the complementary part when it is determined that the first device is in an unexpected state that does not correspond to the target state or to an intermediary state caused by said at least one action to be performed.

6. The method of claim 5, wherein the error indication is an identifier of an action of undoing an unexpected action, or an encoded version of it.

7. The method of any one of claims 4 to 6, wherein the complementary part indicates the current step in a step-by-step process.

8. The method of any one of claims 1 to 7, wherein the step of indicating is performed by a component of the first device.

9. The method of claim 8, wherein the step of indicating comprises displaying a notification on the first device and/or making a light of the first device flash.

10. The method of any one of claims 1 to 9, wherein the step of indicating comprises advertising a URL indicating the at least one action to be performed on the first device for changing its first state.

11. The method of any one of claims 1 to 10, wherein the advertisement message comprises a continuation indication indicating that the generated URL may be loaded in the same execution context as another URL previously loaded by the second device.

12. The method of claim 11, wherein the continuation indication is a flag.

13. The method of claim 11, wherein the continuation indication is a part of the generated URL.

14. The method of claim 13, wherein the continuation indication is a fragment of the URL or a string of at least one character appended to the end of the generated URL.

15. A method of interacting between two devices, the method comprising, at a second device:

receiving an advertisement message comprising a URL from the first device generated according to any one of claims 1 to 14;

16. The method of claim 15, wherein determining an eligible existing execution context comprises determining a URL that has been loaded in an existing execution context running in a web runtime environment of the second device.

17. The method of claim 16, wherein the existing execution context is determined as being eligible only if said determined URL is associated with the same domain name and/or the same origin as the generated URL.

18. The method of claim 16 or 17, wherein the existing execution context is determined as being eligible only if said determined URL is the same as the generated URL except for the fragment part.

19. The method of claim 16, wherein the received advertisement message comprises a continuation indication indicating that the generated URL may be loaded in the same execution context as another URL previously loaded by the second device and the determination steps are based on this continuation indication.

20. The method of any one of claims 16 to 19, wherein the existing execution context is determined as being eligible only if said determined URL has been obtained through another advertisement message.

21. The method of claim 20, wherein the existing execution context is determined as being eligible only if said other advertisement message was also from the first device.

22. The method of any one of claims 15 to 21, wherein a plurality of eligible existing execution contexts is determined, and the method further comprises selecting one of them, the received URL being loaded in the selected eligible existing execution context.

23. The method of claim 22, wherein the eligible existing execution context is selected only if said determined URL has been obtained through an advertisement message from the first device.

24. The method of claim 22 or 23, wherein the eligible existing execution context in which a URL has been loaded the most recently is selected.

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

26. A first device configured for: determining a first state of the first device; and indicating at least one action to be performed on the first device for changing its first state;

27. The first device of claim 26, configured so that the generated URL indicates at least one action to be performed to reach a target state from the second state.

28. A second device configured for:

receiving an advertisement message comprising a URL generated by a first device according to claim 26 or 27;

determining an eligible existing execution context running in a web runtime environment of the second device, in which the generated URL can be loaded; and loading the received URL in said eligible existing execution context.

29. The second device of claim 28, comprising a component specifically developed to identify URLs associated with a given base URL.

30. A system comprising a first device according to claim 26 or 27 and a second device according to claim 28 or 29, the first and the second device being configured for interacting without establishing a bidirectional connection.

31. A method substantially as described herein with reference to, and as shown in Figures 1,2, 3 and 4.

32. A system substantially as described herein with reference to, and as 5 shown in Figure 5.

33. A device substantially as described herein with reference to, and as shown in Figure 5 or 6.

Intellectual

Property

Office

Application No: Claims searched: