Abstract:
A method of configuring a smart mobile device for remote control of a target process, the device including a tag reader, an interface to a communications network, and an operating system capable of dispatching a URI to be handled by a URI handler selected from among a plurality of URI handlers that are installed on the mobile device, the method including the steps of: reading, with the tag reader, a data tag that is associated with the target process and includes the specific URI to be dispatched by the operating system; installing, on the mobile device, a local configuration service which is a URI handler capable of: parsing a specific URI that is related to the target process, connecting, via the communications network and on the basis of parameters inferred from the parsed URI, to an external configuration service for downloading a mobile client application for controlling the target process, the mobile client application being another URI handler, and returning the specific URI to the operating system, thereby causing the same to call up the mobile client application.

Description:
CROSS REFERENCE TO RELATED APPLICATIONS 
       [0001]    This application is a Continuation of International Application No. PCT/EP2016/057464, filed on Apr. 6, 2016, and for which priority is claimed under 35 U.S.C. §120. PCT/EP2016/057464 claims priority under 35 U.S.C. §119 to application Ser. No. 15/163,146.2, filed in Europe on Apr. 10, 2015. The entirety of each of the above-identified applications is expressly incorporated herein by reference. 
     
    
     BACKGROUND OF THE INVENTION 
     1. Field of the Invention 
       [0002]    The invention relates to a method of configuring a smart mobile device for remote control of a target process, the device comprising a tag reader, an interface to a communications network, and an operating system capable of dispatching a URI to be handled by a URI handler selected from among a plurality of URI handlers that are installed on the mobile device. 
         [0003]    In the meaning of the present invention, a “target process” may be any process that is performed by means of a technical equipment such as a machine or a data processing system. For example, the target process may be the operation of a printer, the operation of a door opening and closing system, a software service offered on the Internet or a corporate network, or the like. 
         [0004]    A “smart mobile device” in the meaning of the invention is a device that is capable of connecting to a communications network via a wireless communication channel such as a mobile telephone network (2G, 3G, Wi-Max, LTE or the like), Wi-Fi, Bluetooth, RFID, infrared or sound communication channels, or the like. The mobile device is considered to be “smart” in the sense that is contains data processing and storing hardware controlled by an operating system, so that it is possible to install and run software applications (APPs) on the mobile device. Examples of smart mobile devices are smartphones and intelligent RFID tags. 
       2. Background of the Invention 
       [0005]    As is generally known in the art, a smart mobile device may include a tag reader that is capable of reading a data tag. The data tag may be any physical medium that stores encoded data in a format that can directly be read by the tag reader. Known data tags comprise image-type data tags such as QR codes, Data Matrix, bar-codes and the like, as well as radio tags such as NFC tags and the like. The data tags may be passive (non-powered) or active (powered) and may be of a read-only type or a read-write type. For example, a smartphone typically has a camera that may be used among others for capturing a photograph of an image-type data tag. Then, suitable software in the smartphone may perform the function of a tag reader. 
         [0006]    As is commonly known, the data tagging technology may be used for example for encoding a URI (Uniform Resource Identifier) or a URL (Uniform Resource Locator) of an Internet page, so that, when the tag has been read, a web browser in the smart mobile device may connect to that Internet page. 
         [0007]    Further, it is known that a smart mobile device may be used for remote control of a printer or any other target process, provided that a suitable control software application is installed on the mobile device. Then, the software application may for example enable a smartphone with its touch-sensitive screen to act as an operating console or user interface of the printer. 
         [0008]    However, in order to be able to use a smart mobile device in this way, a suitable configuration of the device is prerequisite. For example, the mobile device must be configured to use the right communication channel for communication with the target process. Further, an application software must be installed that is specifically adapted to the target process, and different target processes may require different control software applications to be installed. On the other hand, the operating systems of known smart mobile devices are distinguished by their brand (e.g. Android, iOS, or the like), model, and software version. In general, the control software application must be adapted to the specific capabilities and functions of the operating system. 
         [0009]    Thus, when a user wants to configure his mobile device for a given target process, the configuration procedure may turn out to be a relatively complex and cumbersome task. The user has to know which control software application is needed for the given task and which resource has to be contacted for downloading this application. Further, he has to know the model and version of his mobile operating system so as to select the control software application that matches his operating system. Then, the application must be downloaded and installed, and the mobile device must be configured for contacting the target process via the correct communication channel and under the correct address. If the target process and the related control software application are not public, a suitable authentication procedure may also be required. All these complex activities are needed for eventually controlling a process as simple as opening a door or printing a document from the mobile device. 
         [0010]    It is therefore an object of the invention to provide a method that assists the user in configuring his mobile device for a selected target process. 
       SUMMARY OF THE INVENTION 
       [0011]    In order to achieve this object, the method according to the invention comprises the following steps:
       installing, on the mobile device, a local configuration service which is a URI handler capable of:
           parsing a specific URI that is related to the target process,   connecting, via the communications network and on the basis of parameters inferred from the parsed URI, to an external configuration service for downloading a mobile client application for controlling the target process, said mobile client application being another URI handler, and   returning said specific URI to the operating system, thereby causing the same to call up the mobile client application; and   
           reading, with the tag reader, a data tag that is associated with the target process and includes the specific URI to be dispatched by the operating system.       
 
         [0017]    Once the local configuration service has been installed, the necessary information for downloading the mobile client application that will eventually control the target process is available on the mobile device, and the configuration process can largely be automated. In order to specifically configure the mobile device for a given target process, it is then sufficient to read the data tag that is associated with that process. The operating system of the mobile device will then dispatch the URI that has been read from the data tag, and this will trigger the rest of the configuration process. 
         [0018]    When the mobile client application had already been installed earlier, the URI will be handled by this mobile client application which will then control the configuration process. On the other hand, if the mobile client application for this specific target process had not yet been installed on the mobile device, then the URI will be handled by the local configuration service which will attend to the download of the required client application. 
         [0019]    The local configuration service may be generic to a plurality of different target processes and related mobile client applications for controlling them, so that the mobile device may be configured for different target processes in a very convenient and efficient way. 
         [0020]    More specific optional features of the invention are indicated in the dependent claims. 
         [0021]    When the local configuration service has not yet been installed on the mobile device, even the process of downloading and installing this local configuration service may be assisted by reading the data tag. In that case, the URI read from the data tag will be handled by a default URI handler of the mobile device, e.g. a web browser which will connect to the external configuration service for downloading the local configuration service. 
         [0022]    For security reasons, it is preferable that the mobile device is capable of communicating with the external configuration service via at least two different networks one of which is preferably a secure private network which is the only network that allows access to the target process. The user may then first use the less secure network as an initial network for downloading the local configuration service, and then this local configuration service will attend to switching to the secure network, preferably after the user and its mobile device, respectively, has passed an authentication procedure. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0023]    The present invention will become more fully understood from the detailed description given hereinbelow and the accompanying schematic drawings which are given by way of illustration only and thus are not limitative of the present invention, and wherein: 
           [0024]      FIG. 1 . is block diagram of a first system embodiment arranged according to the invention; 
           [0025]      FIG. 2 . is a block diagram of a minimal system embodiment arranged according to the invention; 
           [0026]      FIG. 3 . is an UML activity diagram of a URI handler arranged according to the invention; 
           [0027]      FIG. 4 . is a first part of a flow diagram illustrating the configuration method steps according to the invention; and 
           [0028]      FIG. 5 . is the second part of the flow diagram started in  FIG. 4 . 
       
    
    
       [0029]    It shall be understood that, although the detailed description and drawings are provided by way of example and in the context of a particular embodiment, other embodiments and variations preserving the scope and spirit of the invention are possible and will be apparent to those skilled in the art. 
         [0030]    The present invention will now be described with reference to the accompanying drawings, wherein the same reference numerals have been used to identify the same elements throughout the several views. 
       DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
       [0031]      FIG. 1  shows a block diagram of a complex system embodiment arranged according to the present invention. Said embodiment is specific to private environments such as a corporate intranet where the access from a mobile device  20 , e.g. a smartphone, to a target process  51 , e.g. a process of operating a printer, requires the use of an access network  31  that is private and secured, and also requires the presence of a mobile application  28  that is running on the mobile device  20  and arranged for interacting with said target process  51  via the access network  31  and an access network interface  23 . 
         [0032]    According to  FIG. 1 , a data tag  10  embedding an encoded URI  11  that is specific to the target process  51  is read (step M 1 ) by the mobile device  20  using a data tag reader  21 . Upon reading, said URI  11  is decoded and forwarded (step M 2 ) to a mobile operating system  24  of the mobile device for further processing. 
         [0033]    For clarity, it shall be noted that although in the presented embodiment the data tag  10  is a barcode, other data tag technologies such as RFID, NFC tags, Bluetooth Low Energy Beacons, ANT+ tags, network advertised services using protocols such as SSDP or any other well-known proximity service advertising techniques may be used as data tags in the meaning of this disclosure. 
         [0034]    For clarity, it shall also be noted that, although the URI  11  presented in  FIG. 1  is a HTTP URL, other encoding schemes, protocols and formats exceeding the limitations of the W3C URI specification may be used as a URI within the scope of the present invention as long as they can be embedded within a data tag  10  and can be forwarded to and interpreted by the operating system  24 . By way of example, other embodiments may consider using other tag formats such as an NFC SMS tag comprising a specific message payload and pointing to the telephone service number of a public configuration service  41  that is exposed as an SMS listening server on the mobile data network. 
         [0035]    According to  FIG. 1 , upon receiving said URI lithe operating system  24  auto selects or allows the user for manual selection of a preferred URI handler from a plurality URI handlers  25  installed on the mobile device  20 , and then it activates and dispatches said input URI  11  to the preferred URI handler for further processing (step M 31 , M 32  or M 33 ). In the example shown, the URI handlers  25  comprise a standard web browser  26 , a local configuration service  27 , and a mobile client application  28 . The distinguishing features and functions of the latter two URI handlers which are specifically configured for the purposes of the invention will be explained later in this description. In view of the tasks to be performed in the framework of the invention, the URI handlers have different levels of specialisation, with the web browser  26  at the lowest level and the mobile client application  28  at the highest level. 
         [0036]    It will be noted that the proposed system requires the presence of an operating system capable to select and activate a preferred URI handler and capable to dispatch said URI to said preferred URI handler. Operating systems having these capabilities are state of the art. 
         [0037]    According to  FIG. 1 , the URI handlers  25  are arranged to communicate with a public zone  40  via an initial network  30 , e.g. a mobile telephone network, and an initial network interface  22 . The public zone  40  comprises the above-mentioned public configuration service  41 . As an alternative, the URI handlers  25  may communicate with a private zone  50  comprising the target process  51 , or with a smart proxy  54  and, by means of an intranet network  53 , with a private configuration service  52  storing confidential configuration data about the target process  51 . The smart proxy  54  is a capped portal allowing the mobile device  20  to transparently access part of the internet  42  or intranet  53  when connected to an initial network  30  or to the access network  31 , respectively. 
         [0038]    For clarity, it shall be noted that other embodiments designed with different design constraints may exhibit different topologies wherein components of the public and the private zones (as designated here by reference numerals  41 ,  42 ,  51 ,  52 ,  53 , and  54 ) overlap or are missing. By way of example,  FIG. 2  shows a block diagram of a minimal system embodiment arranged according to the present invention. This system is specific to public environments, with a public coffee dispenser system as the target process  51 , for example, and is built with minimal resources. By way of example, in the embodiment depicted in  FIG. 2  the configuration service  52  and the target service  51  are hosted on the internet cloud. 
         [0039]    According to  FIG. 2 , when compared with the system show in  FIG. 1 , the private zone  50  shown in  FIG. 1  is merged into the public zone  40  and, therefore the initial network  30  is also used as an access network  31  and is linked to the internet  42  using the initial network interface  22 . The public configuration service  41  also comprises the functionality and configuration of the private configuration service  52  shown in  FIG. 1  and the target device or process  51  is directly accessible from the internet  42  although the access itself may be secured and restricted to authenticated users and/or mobile devices  20 . 
         [0040]      FIG. 3  is an UML activity diagram illustrating the behaviour of a URI handler which may be either the local configuration service  27  and or the mobile client application  28  shown in  FIG. 1 . 
         [0041]    According to  FIG. 3 , the URI handler is activated in a start state S 1 . Upon reading an input URI in the step S 2  one or more actions are inferred and executed by a first actions step S 3  considering both the input URI and the local context of the URI handler. For clarity, the local context of the URI handler comprises its state and the environment and may persist over different activations of the same URI handler and/or shared with other URI handlers. By way of example, upon subsequent activations of the same URI handler using a same input URI, the first actions step S 3  may produce a different set of actions having different results considering that the local context is different in the subsequent activations. 
         [0042]    According to one aspect of the present invention, the first actions step S 3  has the technical effect of executing a number of actions without any prior call to the input URI. This behaviour is different from the behaviour of other well-known URI handlers such as web browsers where actions can be inferred and executed only after the input URI has been called at least once and when the response has been received. Further, the technical effect of the step S 3  is different from the effect of a known web browser caching mechanism since both the content of the input URI and the local context determine the actions that need to be executed in the first actions step S 3 . Further, the function of the first actions step S 3  is the execution of configuration and/or workflow actions required on the mobile device  20  for the interaction with the target process  51  shown in  FIG. 1 . This function is different from caching and has a different technical effect. 
         [0043]    According to  FIG. 3 , the URI handler determines in a first decision step S 4  weather a call to an external service is required for receiving further information or for triggering remote commands. For clarity, said external service is one of the configuration services  41 ,  52  and the target process  51  shown in  FIG. 1 . 
         [0044]    According to one aspect of the present invention, said first decision step S 4  shown in  FIG. 3  determines whether a call to said external service is required by considering both the input URI and the local context of the URI handler. Therefore, the technical effect of the first decision step S 4  is that the external service is called only when (a) the input URI is present but comprises insufficient configuration information, when (b) the local context comprises insufficient information for allowing the interaction of the mobile device  20  with the target process  51 , and/or when (c) said external service needs to be triggered. 
         [0045]    For clarity, the behaviour of a conventional URI handler such as a web browser performing a cache decision before actually calling an input URI is different than the decision step S 4  since the first decision step S 4  is applicable to any URI and not restricted to already visited ones and in the sense that the first decision step S 4  considers both the content of the input URI and the local context of the URI handler which is broader than an URI cache lookup. For further clarity and by way of example, compared to a web browser that will always try to call a new input URI, an URI handler arranged according to the present invention may decide not to call said URI considering a parameter encoded in the input URI and/or considering the local context. 
         [0046]    According to  FIG. 3 , a step S 5  of calling an external service, a step S 6  of receiving a response, and a step S 7  of executing a second actions step are the same as in other well-known URI handlers such as web browsers. 
         [0047]    According to  FIG. 3 , a second decision step S 8  determines whether a further configuration round is required to be performed by the same or by a different URI handler using a new input URI determined or received in the current round. 
         [0048]    According to one aspect of the present invention, the new input URI required for starting a further configuration or workflow round using the same or different URI handler can also be determined in the first actions step S 3  considering both the input URI and the URI handler local context and without requiring to call the external service for a response. As will be noticed by a person skilled in the art, the above mentioned behaviour is not implemented within known URI handlers such as Web browsers where the a new URI is received either in the step S 6 , for example as a HTTP 302 redirection request response, or where it is determined in the second actions step S 7 , for example by executing an HTML JavaScript function browsing to a new location that has been embedded in the response. 
         [0049]    According to  FIG. 3 , depending upon the result of the second decision step S 8 , a forwarding step S 9  forwards the new input URI to the operating system  24  ( FIG. 1 ) for further processing. The new input URI is further used in a new configuration or workflow round. 
         [0050]    Finally, according to  FIG. 3 , the state S 10  models the end of the current configuration or workflow round started in the state S 1  and allows the URI handler to close or to perform further specific actions that are out of the scope of this invention. 
         [0051]      FIG. 4  and  FIG. 5  show, in the form of an UML activity diagram, an example of a sequential configuration workflow that is specific to the system shown in  FIG. 1  and that involves the URI handlers  25  shown in  FIG. 1  arranged to perform specific configuration rounds. Each round is triggered by an input URI in step M 31 , M 32 , or M 33 , and said configuration rounds are compliant with the general behaviour illustrated in  FIG. 3 . 
         [0052]    For clarity, although this embodiment is presented as an example using specific choices relating to the data tag technology, the URI encoding format and protocols, it will be understood that the sequence and choice of the workflow steps and other details serve only as an illustrative example these choices do not constitute limitations or indispensable features of the invention. 
         [0053]    The configuration workflow shown in  FIG. 4  and  FIG. 5  will now be detailed hereinbelow using references to numerals shown in  FIG. 1  and  FIG. 3 . 
         [0054]    According to  FIG. 4  and by way of example, in a starting step W 1  a user having the mobile device  20  is positioned in the proximity of a target process  51  which shall be considered to be a printer. The user wants to print a document from his mobile device  20  without knowing how to configure the network access, what mobile application to install and how to configure it for pairing with said target process  51 . 
         [0055]    According to  FIG. 4  and by way of example, in a step W 2  the user uses the tag reader  21  (e.g. a barcode scanner) that is available on the mobile device  20  and scans the data tag  10  that is a QR-Code label attached to the printer. The data tag  10  encodes a URI  11  which may be a so-called tiny URL pointing to the public configuration service  41 . The data tag  10  comprises also the printer&#39;s unique identifier encoded in the URI path as a numeral. For clarity, the printer identifier is not a confidential information since no information is disclosed about the model type, version, location or the authority hosting said printer, and it may therefore be publicly shared without any security risks. Moreover, the printer is not accessible from the internet  42  but only when using the dedicated access network  31  that is a secured proximity Wi-Fi network. 
         [0056]    According to  FIG. 4  and by way of example, in the step W 3  the tag reader  21  forwards the URI  11  to the operating system  24  for further processing. 
         [0057]    According to  FIG. 4  and by way of example, in the step W 4  the mobile operating system  24  auto selects the web browser  26  that is the sole URI handler currently installed and that is arranged for handling URLs. 
         [0058]    According to  FIG. 4  and by way of example, the first configuration round starts with the step W 5  when the web browser  26  is activated in the state S 1  by the operating system  24 . Further, in the step W 6 , corresponding to the step S 2 , the web browser  26  reads the input URI served by the operating system  24  (step M 31  in  FIG. 1 ). 
         [0059]    According to  FIG. 4  and by way of example, in the step W 7  the web browser forcedly decides to access the external service that is the public configuration service  41  exposed on the internet  42  using the network interface  22  and the initial network  30  that is the mobile data network. For clarity, the first decision step S 4  shown in  FIG. 3  does not exist for the web browser  26  that will always access a web resource pointed at by said input URI  11 . 
         [0060]    According to  FIG. 4  and by way of example, in the step W 8  the input URI  11  is requested, corresponding to the step S 5 . 
         [0061]    According to  FIG. 4  and by way of example, in the step W 9  the public configuration service  41  receives the URI  11  request and infers a response. The public configuration service  41  is arranged to serve a response considering the requested input URI  11  and its local context comprising its state and environment. By way of example, the public configuration service  41  receiving the URI  11  request from the web browser  26  looks up the HTTP User-Agent from the request and consequently detects the model and version of the operating system  24  and the fact that the request is initiated by a web browser  26  and not by a specialized URI handler. As a consequence and by way of example, the public configuration service  41  provides a HTTP redirection request response comprising a redirection URI pointing to the download location of the local configuration service  27  specific to the model and version of the operating system  24 . Alternatively and by way of example, the response may comprise a web page with a download link and a message allowing the user to decide whether he wants to continue installing the local configuration service  27  or abort. 
         [0062]    According to  FIG. 4  and by way of example, in the step W 10 , corresponding to the step S 6 , the web browser  26  receives the HTTP redirection request response pointing to the download location of the local configuration service  27  and downloads it according to the step S 7 . 
         [0063]    According to  FIG. 4  and by way of example, in the step W 11  the downloaded local configuration service  27  is auto installed by the operating system  24 . For clarity, the installation procedure depends on the model of the operating system  24 , which may require the user to manually accept and/or install said local configuration service  27 . 
         [0064]    According to  FIG. 4  and by way of example, in the step W 12  the local configuration service  27  is activated automatically by the operating system  24 . Therefore, the step W 12  embodies the starting state S 1  and marks the beginning of a second configuration round using a different URI handler, in this case the local configuration service  27 . 
         [0065]    According to  FIG. 4  and by way of example, in the step W 13  (step M 32  in  FIG. 1 ) the local configuration service  27  reads the input URI that in this particular case is missing since said service is automatically started upon installing. Consequently, the input URI is set to a fallback default value embedded within said local configuration service  27 , said default URI pointing to the public configuration service  41  and not having an identifier of target process  51  encoded in the path. Further, the local configuration service  27  skips the first actions step S 3  since the default URI and initial state do not have specific configuration information and therefore no specific configuration actions can be inferred and performed. 
         [0066]    According to  FIG. 4  and by way of example, in the step W 14  the local configuration service  27  decides according to the step S 4  to call the public configuration service  41  pointed at by the default URI for receiving additional configuration information. The call to the public configuration service  41  is further performed in the step W 15  corresponding to the step S 5 . 
         [0067]    According to  FIG. 4  and by way of example, in the step W 16  the public configuration service  41  receiving the call from the local configuration service  27  determines that request was made from a mobile device by a local configuration service, that the identifier of the target process  51  is unknown since it is not specified in the request, and that a previous request coming from the same mobile device  20  having the same operating system  24  has recently been made (in the step W 8 ). By way of example, the public configuration service  41  determines the model and version of the operating system  24  of the requesting device  20  by looking up the HTTP User-Agent of the request, it determines that the requested URI does not have encoded in the path the identifier of the target process  51  and determines by looking up in the recent requests history that the same mobile device  20 , using the same mobile operating system  24  has requested configuration details about the target process  51  using a web browser  26 . Consequently, the public configuration service considers this request as a continuation of the request in step W 8  and determines that the request is performed using the local configuration service  27  that, contrary to the web browser  26 , is able to configure and access a network that is different from the initial network  30  and is arranged for user authentication. Therefore, the public configuration service  41  provides in the response further configuration details for configuring the access network  31  and a redirection URI to be used as a new input URI for a further configuration round. By way of example, the response comprises information about the access network  31  that in this particular example is a private WIFI network that is secured by using the WPA2 protocol and is protected by a given password. The response also comprises a new input URI that is the same as the input URI  11  shown in  FIG. 1 . 
         [0068]    According to  FIG. 4  and by way of example, in the step W 17  the response is received by the local configuration service  27 , this step corresponding to the step S 6 . The received configuration information is used for configuring the access network interface  23  and for switching the network from the initial network  30  to the access network  31  according to the step S 7 . In addition, in the same step S 7  the new input URI is read from the received response. 
         [0069]    According to  FIG. 4  and by way of example, in the step W 18  the local configuration service  27  determines in accordance with the step S 8  that a further configuration round is required due to the presence of a new input URI received in the previous step W 17 . Therefore, in the step W 19  said new input URI is forwarded to the operating system  24  for further processing (corresponding to step S 9 ). The current configuration round ends in the step W 20  corresponding to the state S 10 . 
         [0070]      FIG. 5  continues the workflow from  FIG. 4 , and the step W 21  is the same as the step W 20 . 
         [0071]    According to  FIG. 5  and by way of example, in the step W 22  the operating system  24  selects a URI handler for handling the new input URI issued in the step W 19 . For clarity, although said new input URI read in step W 17  is the input URI  11 , the selected URI handler is different since the local configuration service  27  has been installed and registered as a more specialized URI handler for handling URIs pointing to the public configuration service  41 . Therefore, the selected URI handler is the local configuration service  27  and no longer the web browser  26  as it was the case in the step W 4 . The local configuration service  27  is further re-activated in the step W 23  that corresponds to the state S 1  of a new configuration round. 
         [0072]    According to  FIG. 5  and by way of example, in the step W 24  the new input URI that is the same as the input URI  11  is read by the local configuration service  27  according to the step S 2  (step M 32  in  FIG. 1 ). The first actions step S 3  is skipped as the new input URI does not comprise additional configuration information other than the address of the public configuration service  41  and the identifier of the target process  51  encoded in the URI as a numeric path. 
         [0073]    According to  FIG. 5  and by way of example, in the step W 25  the local configuration service  27  determines according to the step S 4  to call the public configuration service  41  using the access network  31  for getting further configuration information specific to the target device or service  51 . 
         [0000]    According to  FIG. 5  and by way of example, in the step W 26 , which corresponds to the step S 5 , the local configuration service  27  calls the public configuration service  41  using the access network  31  that has been configured in the previous round. The communication is intercepted by the smart proxy  54  and is transparently redirected towards the private configuration service  52  accessible via the intranet  53 . Therefore, the local configuration service  27  having switched to the private network  31  has the impression of accessing the public configuration service  41  while actually the communication is transparently routed to the private configuration service  52  accessible on the intranet  53 . This arrangement allows for protecting confidential configuration data from the public while preserving the appearance of accessing public resources. 
         [0074]    According to  FIG. 5  and by way of example, in the step W 27  the private configuration service  52  having received the input URI determines that the user is unknown and needs to authenticate against a corporate access directory using a secured channel before receiving any further information related to the printer being the target process  51 . Therefore, the private configuration service  52  responds with a secured authentication web page comprising an authentication form. 
         [0075]    According to  FIG. 5  and by way of example, in the step W 28  the local configuration service  27  receives the authentication page, in accordance with the step S 6 . 
         [0076]    According to  FIG. 5  and by way of example, in the step W 29 , corresponding to the step S 7 , the local configuration service  27  displays the authentication form, and when the user fills the form it sends the authentication data to the private configuration service  52  acting on behalf of the public configuration service  41  for further validation against the corporate access directory. In the same step, the private configuration service  41  having authenticated the user provides a response comprising an authentication token and further details required for accessing said printer. By way of example, the provided configuration information includes the download URI of the mobile client application  28  and a new input URI to be used as an input URI in a further configuration round (step M 33  in  FIG. 1 ) that will be handled by the mobile application  28 . Further in the same step W 29  and in accordance with the step S 7 , the local configuration service  27  downloads the mobile client application  28  using the secured access network  31  and the smart proxy  54  that allows the download of said mobile client application  28  from a store deployed on the internet  42  or on the intranet  53 . Further in the same step, upon download completion the local configuration service  27  triggers the operating system for installing the mobile client application  28 . For clarity, in an alternative embodiment, when design constraints of the mobile operating system  24  allow, the step W 29  would further comprise the installation, configuration and startup of the mobile client application  28 . However, as a person skilled in the art will notice, mobile operating system technical limitations and design usually forbid unauthorized installations and out of the application configuration and therefore the current embodiment is preferred as being less restrictive. For further clarity, the complexity and number of actions performed in the step W 29  according to the step S 7  can vary from zero to any other value and therefore the granularity of a configuration round may be coarse grained or fine grained depending on the operating system  28  design constraints. 
         [0077]    According to  FIG. 5  and by way of example, in the step W 30  corresponding to the step S 8  the local configuration service  27  determines that a new configuration round is required for starting and configuring the mobile client application  28  previously installed. 
         [0078]    According to  FIG. 5  and by way of example, in the step W 31 , corresponding to the step S 9 , the new input URI determined in the step W 29  is forwarded by the local configuration service  27  to the mobile operating system  24  for starting a new configuration round (step M 33  in  FIG. 1 ). Further, in the same step W 31  and in accordance with the step S 10  the local configuration service  27  finishes execution. 
         [0079]    According to  FIG. 5  and by way of example, in the step W 32  the mobile operating system  24  selects the mobile client application  28  as the URI handler that is registered for processing the new input URI. For clarity, the new input URI can be identical to the input URI  11  when the mobile client application  28  is registered upon install as a more preferred URI handler than the local configuration service  27 . For clarity, in a preferred embodiment the local configuration service  27  and the mobile client application  28  will both be registered as URI handlers for different URI formats and content. 
         [0080]    According to  FIG. 5  and by way of example, in the step W 33  the mobile operating system  24  activates the mobile client application  28  that is placed into the state S 1 . 
         [0000]    According to  FIG. 5  and by way of example, in the step W 34 , corresponding to the step S 2 , the mobile client application  28  reads the new input URI (M 33 ) comprising the host name and model of the target process  51  (i.e. the printer). 
         [0081]    According to  FIG. 5  and by way of example, in the step W 35  corresponding to the step S 3  the mobile client application configures the printer model and address, and the user is allowed to use the configured application for controlling the target process  51 , i.e. for printing. 
         [0082]    According to  FIG. 5  and by way of example, in the step W 36  the mobile client application decides in accordance with to the steps S 4  and S 8  that a call to an external service is not required and that no further configuration round is required and, as a consequence the mobile client application  28  is placed in the state  10  that finishes the configuration.