WO2017109362A1 - Procédés et serveurs de transmission et de réception de documents comprenant des images - Google Patents

Procédés et serveurs de transmission et de réception de documents comprenant des images Download PDF

Info

Publication number
WO2017109362A1
WO2017109362A1 PCT/FR2016/053533 FR2016053533W WO2017109362A1 WO 2017109362 A1 WO2017109362 A1 WO 2017109362A1 FR 2016053533 W FR2016053533 W FR 2016053533W WO 2017109362 A1 WO2017109362 A1 WO 2017109362A1
Authority
WO
WIPO (PCT)
Prior art keywords
document
image
terminal
doc
tiles
Prior art date
Application number
PCT/FR2016/053533
Other languages
English (en)
Inventor
Bruno Girard
Original Assignee
Orange
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange filed Critical Orange
Publication of WO2017109362A1 publication Critical patent/WO2017109362A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/565—Conversion or adaptation of application format or content
    • H04L67/5651—Reducing the amount or size of exchanged application data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/04—Protocols for data compression, e.g. ROHC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers

Definitions

  • the invention relates to the general field of telecommunications.
  • It relates more particularly to the transmission of a document comprising one or more images stored on a server (eg web server, e-mail server, etc.) to a terminal of a user who has requested this document.
  • a server eg web server, e-mail server, etc.
  • terminal eg mobile terminal, computer, tablet, etc.
  • type of document required by the terminal eg web page, digital file, email, etc.
  • the access time to the document is generally limited by the transmission time of the images of this document on the network.
  • images eg multi-resolution images, medical images, high-definition photographs, etc.
  • images are becoming more precise and occupy more and more important sizes (eg 10 MB to 20 GB).
  • the transmission time of the document can be up to more than a minute or even minutes, which has a negative impact on the user experience of the terminal.
  • the server compresses the images included in the document according to a rate fixed image compression.
  • the size of the images transmitted with the document being reduced, the transmission time of the document to the terminal is also reduced.
  • Such compression may degrade the quality of the images received by the terminal when the fixed image compression rate imposed by the server is low.
  • such compression is not necessarily justified when the terminal has a satisfactory bandwidth.
  • the invention aims in particular to improve this situation by proposing, according to a first aspect of the invention, a method of transmitting a document intended to be implemented by an intermediate server placed between a terminal and a document server. process comprising:
  • a step of processing said at least one image to be processed comprising a step of obtaining a set of tiles resulting from the cutting into tiles of said at least one image to be processed according to a tile size adapted to a transmission context of the terminal on a communications network;
  • the invention is an intermediate server placed between a terminal and a document server, able to transmit a document, the intermediate server comprising: a receiving module, from the document server, a document required by the terminal ;
  • modules activated if there is at least one image to be processed in the document, said modules comprising:
  • a processing module of said at least one image to be processed configured to obtain a set of tiles resulting from the cutting into tiles of said at least one image to be processed according to a tile size adapted to a transmission context of the terminal on a network of communications;
  • the invention also provides a method for receiving a document intended to be implemented by a terminal, the method comprising:
  • the invention relates to a terminal capable of receiving a document, the terminal comprising:
  • a receiving module via the network from an intermediate server placed between the terminal and the document server, of the document in which at least one image of the document is replaced by executable code configured to execute during a access by the terminal to the document and to request the tiles of the image replaced by this code;
  • the invention thus proposes to advantageously use an intermediary server located between a terminal and a document server (for example, a proxy server placed at the end of a flow between the terminal and the document server) for processing one or more images of a document. a document required by the terminal, in order to facilitate their transmission to the terminal.
  • a document server for example, a proxy server placed at the end of a flow between the terminal and the document server
  • the use of an intermediate server advantageously provides a simple and transparent solution for the terminal and the document server.
  • the processing applied by the intermediate server consists in cutting the images of the document having a large size (that is to say the images to be treated with respect to a given size criterion) in tiles (that is to say in several elements or pieces) whose size is adapted to the transmission context of the terminal. Then the document without these images but in which executable codes for recovering the tiles of the images when the document accesses the terminal replace these images, is sent to the terminal. The tiles resulting from the cutting of the images are then transmitted to the terminal on request of the executable codes.
  • the executable codes allow asynchronous transmission of the tiles of the images replaced by these codes (that is to say the transmission to the terminal of the document and that of the tiles are not carried out at the same time). This asynchronous transmission implemented by the invention does not advantageously block the overall process of accessing the document (or loading the document).
  • the invention thus makes it possible to improve the experience of the user of the terminal by virtue of quick access via the communications network to the document which no longer contains large images but the executable codes making it possible to retrieve these images later.
  • the invention makes it possible to optimize the transmission of these images to the terminal, in particular without sacrificing the quality of the images, by tiling the images according to a size of tiles adapted to the transmission context of the terminal.
  • the intermediate server is able to perform the cutting of the images itself. In a variant, it subcontracts this division to a third entity and obtains from this entity the tiles to be transmitted to the terminal.
  • the size of the tiles according to which the image to be processed is cut out takes into account the transmission context of the terminal, that is to say in particular (network) conditions (characteristics) of the network (for example, its bandwidth , the transmission protocol of the network used, the existence or not of a congestion control mechanism implemented by the transmission protocol, the latency of the network, etc.), restitution constraints imposed by the terminal (typically the size of the screen of the terminal), and / or characteristics of the image to be processed (for example of a type of image, etc.).
  • network network conditions
  • characteristics of the network for example, its bandwidth , the transmission protocol of the network used, the existence or not of a congestion control mechanism implemented by the transmission protocol, the latency of the network, etc.
  • restitution constraints imposed by the terminal typically the size of the screen of the terminal
  • characteristics of the image to be processed for example of a type of image, etc.
  • this tile size verifies an image quality factor (eg image compression ratio) and / or a maximum transmission time.
  • image quality factor eg image compression ratio
  • the transmission of all the tiles of a processed image according to the invention makes it possible to respect or even exceed at least one parameter among a quality factor of the image and a transmission time of the image. specified, for example, by the terminal.
  • Such parameters are particularly important and representative in terms of user experience and make it possible to privilege via the invention this experience during the transmission of the tiles of the image.
  • the invention proposes to send to the terminal in the first place the document in which this image is replaced by an executable code, this executable code being configured to execute when access to the document (that is to say a loading or display of the document) by the terminal and to request the tiles of the image replaced by this code.
  • this executable code is a script, that is to say a program in interpreted language (for example, in JavaScript language), allowing interactions with the intermediate server and / or with the user of the terminal.
  • Such an executable code having a smaller size compared to the image that it replaces, this allows a fast transmission of the document to the terminal.
  • the intermediate server before processing an image, the intermediate server first checks whether there exists in the document one or more images to be processed taking into account a determined size criterion.
  • the invention thus makes it possible to check "on the fly” (that is to say in real time) if at least one image contained in the document needs to be processed in order to be transmitted via the network to the terminal. . In other words, it is no longer, as in the state of the art, to systematically compress all the images of a document during its transmission to the terminal.
  • the processing carried out by the intermediate server is thus optimized by cutting only the images of the document that need it, which results in a limited complexity of implementation of the invention.
  • an image is considered to satisfy the determined size criterion if its size (ie the number of bytes it occupies) is greater than a predetermined size, for example fixed by the intermediate server, or determined dynamically according to the intermediate server's transmission link with the terminal.
  • an image is considered to satisfy the determined size criterion if a transmission time of this image to the terminal on the network estimated by the intermediate server is greater than a determined transmission time setpoint, for example specified by the terminal.
  • This setpoint corresponds for example to a maximum transmission time acceptable by the terminal.
  • the estimated transmission time of the image can be obtained from the size of the image taking into account network conditions experienced by the terminal. This ensures that the constraints imposed by the user of the terminal are respected.
  • the size of tiles adapted to the transmission context of the terminal is received by the intermediate server in a request for access to the document sent by the terminal.
  • This embodiment makes it possible to preserve the resources of the network by limiting the signaling (ie exchanges of messages between the terminal and the intermediate server) for the implementation of the invention.
  • the tile size adapted to the transmission context of the terminal is received by the intermediate server from a third entity, or calculated by the intermediate server directly.
  • the size of tiles adapted to the transmission context of the terminal is stored by the intermediate server in association with an account of the terminal.
  • the efficiency of the intermediate server is increased because this server is able to use the same size of tiles to cut several documents required by the terminal.
  • the method implemented by the intermediate server comprises a step of receiving a message intended to modify the size of tiles used for cutting the images of the document.
  • this size can be dynamically changed, via a message sent to the intermediate server by the terminal or by a device for determining the size of image tiles, during a change in network conditions experienced by the terminal (ex. bandwidth change, increase / decrease in network latency).
  • This embodiment ensures a flexible cutting of the image to be treated in tiles while taking into account a possible change in the context experienced by the terminal.
  • the tiles resulting from the cutting of at least one image to be processed are transmitted to the terminal via several execution tasks taking place in parallel.
  • the tiles of the image are transmitted via 2 to 5 execution tasks (or son of execution, "threads" in English) running in parallel, each task being intended to transport a portion of the tiles of the image . This allows a faster transmission of the image.
  • At least one executable code replacing in the document a processed image is configured to require the tiles of this image on authorization of a user of the terminal.
  • the executable code may be configured to provide, for example, the user with information about the image he is replacing (eg name, type, size, time of transmission, etc.).
  • This embodiment makes it possible to dynamically decide the transmission of an image to the terminal as a function of a wish of the user of the terminal. This makes it possible to load only images of interest to the user and to reduce the access time to the complete document (including the images required by the user).
  • At least one executable code replacing in the document a processed image is configured to automatically request the tiles of this image, that is to say without requesting authorization from the user of the terminal.
  • an executable code replacing in the document a processed is configured to display the tiles of this image in a display mode chosen from:
  • this executable code is configured to retrieve all the tiles of the processed image corresponding to this code before displaying them on the screen of the terminal. This allows a complete display of all tiles in the image at one time.
  • the executable code is configured to display on a screen of the terminal a tile of the image to be processed as soon as it receives it. This allows a real-time display of the tiles of the image even if all the tiles of this image are not received by the terminal. This gives a quick display of the image although partial.
  • the tiles of the image can be for example displayed sequentially in order of their sequence or spiral numbers, etc. depending on an executable code configuration.
  • the different steps of the transmission method or the reception method are determined by computer program instructions.
  • the invention also relates to a computer program on an information medium, this program being capable of being implemented in a computer, for the implementation of the steps of the transmission method or the steps of the method according to the invention, as briefly described above.
  • This program can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other form desirable shape.
  • the invention also relates to a computer readable information medium, and comprising instructions of the computer program as mentioned above.
  • the information carrier may be any entity or device capable of storing the program.
  • the medium may comprise storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording medium, for example a floppy disk. ), a hard drive, or a USB key.
  • the information medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means.
  • the programs according to the invention may in particular be downloaded on an Internet-type network.
  • the information medium may consist of integrated circuits in which the program is incorporated, the circuits being adapted to execute or to be used in the execution of the method in question.
  • the invention also provides a communication system comprising:
  • a document server storing a document
  • an intermediate server adapted to receive the document from the document server and to transmit this document to the terminal via a communications network.
  • the transmission method, the reception method, the terminal, the intermediate server and the communication system according to the invention present in combination all or some of the aforementioned characteristics. .
  • FIG. 1 represents a communication system comprising an intermediate server, a terminal and a document server according to a particular embodiment of the invention
  • FIG. 2 represents an intermediate server according to a particular embodiment of the invention
  • FIG. 3 represents a terminal according to a particular embodiment of the invention.
  • FIG. 4 represents the various exchanges implemented between the terminal, the intermediate server and the document server of the communication system of FIG. 1 in a particular embodiment of the invention for the transmission of a document between the server intermediate and the terminal.
  • FIG. 1 represents, in its environment, a SYS communication system according to the invention, in a particular embodiment of the invention.
  • This SYS system enables a TM terminal (eg mobile phone, touch pad, personal computer, etc.) to access, via an intermediary server SI (eg proxy or proxy server), a DOC document stored on an S2 document server (eg web server, e-mail management server, etc.) through an NW communications network.
  • SI eg proxy or proxy server
  • S2 document server eg web server, e-mail management server, etc.
  • the terminal TM, the intermediate server S1 and the document server S2 are respectively a mobile telephone, a proxy server and a web server;
  • the DOC document is a web page comprising one or more images
  • the NW communications network is a 3G network whose bandwidth is limited to 1 Mb / s.
  • the DOC document can be any type of document, such as a web page, an email, a digital file, etc.
  • the images contained in this document may be of different natures (eg medical image, high-definition photography, etc.), and / or different resolutions.
  • NW communications network can be indifferently a fixed, mobile, wireless, wired telecommunications network, etc.
  • the terminal TM communicates with the intermediate server S1 and with the document server S2 via the network NW.
  • the intermediate server S1 and the document server S2 communicate with each other preferentially via a high-speed or wired communications network (not shown in FIG. 1).
  • the intermediate server S1 and the terminal TM each have the hardware architecture of a computer, shown schematically in FIG. 2 and FIG. 3 respectively.
  • the intermediate server S 1 notably comprises a processor 10, a rewritable non-volatile memory 11, a ROM type ROM 12, a RAM type random access memory 13 and a communication module 14.
  • the communication module 14 enables the intermediate server to communicate with the terminal TM via the communications network NW as well as with the document server S2.
  • it comprises means known per se, such as a network card, a Subscriber Identity Module (SIM) card, and so on.
  • SIM Subscriber Identity Module
  • the read-only memory 12 of the intermediate server S 1 constitutes a recording medium in accordance with the invention, readable by the processor 10 and on which is recorded a computer program PG1 according to the invention comprising instructions for performing the steps a transmission method according to the invention as implemented by the intermediate server S1 and whose steps are detailed later with reference to FIG.
  • This computer program equivalently defines functional modules of the intermediate server S1 (software modules here). These modules support or control the hardware elements 10-14 described above. They include in particular here a verification module VRF configured to check the existence in the DOC document of at least one IM image to be processed in accordance with the invention, a processing module CT configured to process said IM image, and a module COM transmission / reception.
  • the transmission / reception module COM is configured to send via the network NW to the terminal TM the document DOC according to the invention (that is to say as such or in which at least one image of the document has been replaced by an executable code COD as explained in more detail later), and to transmit via the network NW to the terminal TM the tiles of the cut images of the document DOC.
  • the terminal TM notably comprises a processor 20, a rewritable non-volatile memory 21, a ROM-type read only memory 22, a RAM type random access memory 23, and a communication module 24.
  • the communication module 14 allows the terminal to communicate with the intermediate server SI via the communications network NW, as well as with the document server S2.
  • the communication module 14 comprises means known per se, such as a Subscriber Identity Module (SIM) card, etc.
  • SIM Subscriber Identity Module
  • the read-only memory 22 of the terminal TM constitutes a recording medium in accordance with the invention, readable by the processor 20 and on which is recorded a computer program PG2 according to the invention comprising instructions for executing the steps of FIG. a reception method according to the invention as implemented by the terminal TM and whose steps are further illustrated with reference to FIG. 4.
  • This computer program equivalently defines functional modules of the terminal TM (software modules here). These modules support or control the hardware elements 20-24 described above. They include in particular here a transmitting / receiving module COM ', an access ACC module configured to access from the terminal TM DOC document received from the intermediate server SI and trigger the execution of said at least one executable code COD, and a RCN reconstitution module configured to reconstitute at least one IM document DOC from tiles of this image received from the intermediate server SI.
  • the transmission / reception module COM ' is configured to send to the intermediate server S1 (via the communication module 24 in particular) an access request RQ to the document DOC stored on the document server S2, and to receive the document DOC or a modified version of this DOC document via the NW communications network from the intermediate server SI. It is also configured to receive via the network NW from the intermediate server SI, the tiles resulting from a cutting of at least one IM image of the DOC document according to the invention.
  • the functions of the modules COM ', ACC and RCN are further detailed with reference to the steps of the access method according to the invention.
  • the terminal TM, the intermediate server S1 and the document server S2 are respectively a mobile telephone, a proxy server and a web server.
  • access by the mobile phone TM to a DOC document comprising images, such as a web page, and hosted by the web server S2 is performed via the proxy server SI, and not directly to the S2 server.
  • the proxy server SI obtains the web page required by the mobile phone TM from the web server S2, and performs a processing on the IM images present in the web page in order to limit the transmission time of this web page to the mobile phone TM.
  • This processing consists of tiling the images of the web page that satisfy a predetermined size criterion, according to a predefined size (x, y) of tiles (i.e. vertical and horizontal dimensions of the tiles).
  • This size (x, y) of tiles is advantageously adapted to the transmission context (and in particular to the 3G NW network characteristics) experienced by the mobile phone TM and thus facilitates the transmission of the IM image on the NW network to the terminal TM. How the size (x, y) of tiles is determined will be described in more detail later.
  • the proxy server SI then replaces in the DOC web page each image processed by an executable code and sends the document thus obtained to the mobile phone TM via the network NW.
  • the executable code allows the terminal to later retrieve the tiles of the image that it replaces.
  • the invention allows the mobile phone TM to quickly access a modified version of the initial DOC web page, that is to say the DOC web page without IM image. Moreover, thanks to the executable code inserted by the proxy server SI in this web page, the mobile phone TM can easily recover the IM image that the executable code replaces.
  • This request RQ includes the URL ("Uniform Resource Locator") of the DOC web page as well as one or more optional information.
  • This optional information here includes the size (x, y) of image tiles adapted to the mobile phone transmission context TM, an image quality factor set point specified by the mobile phone TM, as well as other described parameters. subsequently (eg current flow of the network experienced by the mobile phone when accessing the DOC web page and maximum Td transmission time acceptable by the user of the terminal).
  • This setpoint is here a compression ratio for use by the proxy server SI during a possible image compression.
  • the size (x, y) of the image tiles can be expressed in other measurement units known per se.
  • this size (x, y) of tiles is calculated by a third party entity E on request of the mobile phone TM and communicated to this telephone TM by the third party entity E. It is determined by the third party entity E so that the transmission of an image via tiles of this size (x, y) on the 3G network NW between the phone TM and the proxy server SI respects a Qmin quality factor of the image and / or time Tmax transmission of the image on the 3G network NW.
  • This size (x, y) of tiles is for example calculated and obtained by the mobile phone TM as described in a French application FR 15 55701 unpublished to date.
  • the image quality factor Qmin and the transmission time Tmax of the image are specified by the mobile phone TM to the entity Third party E.
  • This entity evaluates a cost function representative of a value of the transmission time of the image to be transmitted on the network NW between the proxy server SI and the mobile phone TM according to a value of the quality factor. image and a tile size of the image.
  • This cost function takes into account the characteristics / conditions (eg maximum bit rate, latency, transport protocol, etc.) of the 3G NW network experienced by the mobile phone TM, image restitution constraints imposed by this telephone TM ( eg the phone screen size TM) and the type of image (for example, medical image, photograph, etc.).
  • the entity E determines from the cost function a size (x, y) of tiles to be used by the proxy server S1 to transmit the image to the mobile phone TM, this size respecting at least one of the quality factor Qmin of the transmission picture and time Tmax specified by the mobile phone TM.
  • the proxy server SI receives (E10), via its COM module, the request RQ from the mobile phone TM. As described above, this RQ request here comprises the size (x, y) of tiles.
  • the proxy server SI receives the size (x, y) of tiles directly from the third entity E.
  • the proxy server SI is able to determine itself the size (x, y ) of tiles to use for the mobile phone TM.
  • the proxy server SI On receipt of the request RQ, the proxy server SI extracts the size (x, y) of tiles from the request RQ and sends (E20) the request RQ thus modified to the web server S2 from the URL specified in the request RQ .
  • the size (x, y) of tiles extracted is stored in the proxy server SI and associated with a telephone account TM.
  • the proxy server SI is thus able to use this size (x, y) of tiles for documents required later by the mobile phone TM.
  • This size (x, y) of tiles can be dynamically modified, in particular via a message sent to the proxy server SI by the telephone TM, for example when the telephone TM experiences a change in network conditions.
  • the proxy server SI receives (E30) then, via its COM module, the DOC web page required by the mobile phone TM of the web server S2. It is recalled that in the example envisaged here this DOC web page comprises one or more images.
  • the SI proxy server checks (E40) via its VRF module if there is at least one image to be processed in this DOC web page. with regard to a given size criterion (that is, one or more images whose size is too large to be transmitted directly into the DOC document without being processed beforehand). This prior check allows the proxy server SI to filter the image (s) present (s) on the DOC web page received from the web server S2, to identify at least one IM image that needs to be processed (cut).
  • a given size criterion that is, one or more images whose size is too large to be transmitted directly into the DOC document without being processed beforehand.
  • the IS proxy server here verifies for this purpose whether, for each image of the DOC web page, an estimated transmission time Te of this image to the mobile telephone TM via the communications network NW is greater than a transmission time Td predetermined.
  • the image is considered by the proxy server SI as satisfying the determined size criterion. It is therefore an image to be processed within the meaning of the invention.
  • the proxy server S 1 checks whether the size (ie the number of bytes) of each image of the DOC web page is greater than a predetermined size, for example fixed by the proxy server S 1 according to the type of communications network. used by the TM mobile phone (eg 500 KB for a 3G mobile network). If yes, this image is considered by the proxy server SI as satisfying the determined size criterion and as an image to be processed.
  • a predetermined size for example fixed by the proxy server S 1 according to the type of communications network. used by the TM mobile phone (eg 500 KB for a 3G mobile network).
  • the proxy server SI estimates the transmission time Te of the image considered via its VRF module from the size of the image and the current flow rate of the network NW 3G experienced by the mobile phone TM.
  • the IS proxy server here obtains the current network speed (eg 1 Mb / s) from the mobile phone TM, for example in the request RQ.
  • the transmission time Td is specified by the telephone TM (eg 10 s). It is sent here to the proxy server SI by the telephone TM in the request RQ, as mentioned previously.
  • the telephone TM may send the transmission time Td to the proxy server SI via a separate message, or the proxy server SI may receive it from the third party entity E determining the size (x, y) of tiles for the telephone TM . If the proxy server SI determines during step E40 that there is no image to be processed, it sends (E50) the DOC web page as received from the web server S2 TM phone.
  • the proxy server SI detects the presence in the DOC web page of two images to be processed IM 1 and IM 2. For each image IM 1 and IM 2, the proxy server SI processes (E60) via its CT module the image considered by cutting it into TU tiles according to the size (x, y) of tiles specified by the telephone TM in its request RQ. It stores the tiles thus obtained for example in its non-volatile memory 11.
  • step E60 the cutting is performed by a third cutting device, which then transmits the thus cut tiles to the proxy server SI.
  • the proxy server SI constructs (E62) an executable code, COD1 and COD2 respectively, which is here a script written according to the JavaScript language.
  • COD1 and COD2 scripts are configured to execute when the mobile phone TM accesses (ie loads or displays) the DOC web page and to request the tiles of the corresponding image.
  • the IS proxy server replaces (E64) the IM 1 and IM2 processed images respectively by the COD1 and COD2 scripts in the DOC web page.
  • the mobile phone TM receives (F30) from the proxy server SI, via its COM 'module, via the network NW, the modified DOC web page, previously requested by the telephone TM and in which the two scripts COD1, COD2 replace IM 1, IM2 images.
  • the scripts COD1 and COD2 run here sequentially (that is, in order of their presence on the DOC web page from top to bottom).
  • COD1 and COD2 scripts are programmed to run simultaneously.
  • a graphical interface appears at the position of the image IM 1 replaced by the COD1 script on the DOC web page.
  • This graphic interface here takes the form of an information window comprising an authorization button and a refusal button.
  • This information window asks the user of the phone TM for permission to retrieve the image IM 1.
  • the information window also specifies here the user the name, the type, the size of the image IM 1 to the TM mobile phone.
  • the script COD1 sends a request to the proxy server SI to obtain the tiles of this image IM 1. If the user refuses the recovery of the image IM1 via the refusal button, the script COD1 stops, and therefore does not require the transmission of the tiles of the image IM1 from the proxy SI.
  • the proxy server SI On receiving the request from the script COD1, the proxy server SI transmits (E80) via the network NW to the terminal TM, the tiles TU resulting from the division of the processed image IM1 and stored in its non-volatile memory 11.
  • the tiles TU of the processed image IM1 are transmitted in the embodiment described here via several execution tasks running in parallel with the mobile phone TM.
  • these tiles can be transmitted via 5 threads, each one intended to transport part of the tiles of the image IM1. This number of 5 threads is of course given for illustrative purposes only.
  • the tiles of the image can be transmitted sequentially or in a hybrid mode depending on the number of threads that can be used in parallel.
  • the mobile phone TM receives (F50) these tiles IM1 image replaced by the COD1 script via the aforementioned execution tasks on the NW network from the SI proxy.
  • the mobile phone TM then renders (F60) via its RCN module the IM1 image initially contained in the DOC web page from the TU tiles received.
  • the COD1 script is configured to display the TU tiles of the IM1 image in a display mode where these TU tiles are displayed as and when they are received by the telephone TM.
  • the COD1 script may be configured to display these TU tiles in a display mode where they are displayed once all the TU tiles of the IM1 image are received by the TM phone, i.e. displayed once.
  • the script COD1 includes information indicating the position (ie the row and the column) and a reference number of each tile to properly assemble the tiles in the IM1 image and display them on the screen.
  • the script COD1 is configured to display the tiles of this IM1 image in order of their sequence numbers.
  • the tiles of the image IM1 are displayed in a spiral pattern.
  • the COD2 script is executed in turn.
  • the execution of the COD2 script and the recovery of the IM2 image are unconditional according to this example, ie no user authorization is required to recover the IM2 image of the proxy server SI.
  • the COD2 script therefore automatically requires the tiles of the processed IM2 image replaced by the COD2 script without asking the user's permission.
  • the TM phone renders IM1 and IM2 images initially contained in the DOC web page on its screen. It is noted that thanks to the size (x, y) of tiles used for the cutting of images IM1 and IM2 which complies with at least one of the set of Qmin picture quality and transmission time Tmax specified by the mobile phone TM , images IM1 and IM2 restored on the phone TM thus have a desired quality and / or transmission time (s) (s) by the user of the mobile phone TM. The experience of the user is thus improved compared to the state of the art.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

L'invention concerne un procédé de transmission d'un document (DOC) par un serveur intermédiaire (SI) placé entre un terminal (TM) et un serveur de documents (S2), comportant : - la réception, en provenance du serveur de documents, d'un document (DOC) requis par le terminal; - la vérification de l'existence dans le document d'au moins une image à traiter au regard d'un critère de taille déterminé; - si une telle image existe : le traitement de cette image comprenant l'obtention d'un ensemble de tuiles résultant du découpage de cette image en tuiles selon une taille de tuiles adaptée à un contexte de transmission du terminal sur un réseau de communications; l'envoi, via le réseau au terminal, du document dans lequel chaque image traitée est remplacée par un code exécutable configuré pour s'exécuter lors d'un accès par le terminal au document et pour requérir les tuiles de l'image traitée remplacée par ce code; la transmission, via le réseau au terminal, des tuiles d'au moins une image traitée sur requête du code exécutable remplaçant cette image. - sinon l'envoi du document au terminal.

Description

Procédés et serveurs de transmission et de réception de documents comprenant des images
Arrière-plan de l'invention
L'invention se rapporte au domaine général des télécommunications.
Elle concerne plus particulièrement la transmission d'un document comprenant une ou plusieurs images stocké sur un serveur (ex. serveur web, serveur de courriels, etc.) vers un terminal d'un utilisateur ayant requis ce document.
Aucune limitation n'est attachée ici à la nature du terminal considéré (ex. terminal mobile, ordinateur, tablette, etc.), ni au type de document requis par le terminal (ex. page web, fichier numérique, courriel, etc.).
Lorsqu'un terminal requiert l'accès via un réseau de communications à un document contenant une ou plusieurs images, le temps d'accès au document est en général limité par le temps de transmission des images de ce document sur le réseau.
Or aujourd'hui, du fait de l'évolution des technologies numériques, les images (ex. images multi résolution, images médicales, photographies haute définition, etc.) sont de plus en plus précises et occupent des tailles de plus en plus importantes (ex. 10 Mo à 20 Go).
Ainsi, lorsque le débit du réseau entre un serveur hébergeant un document comprenant une ou plusieurs telles images et un terminal souhaitant accéder à ce document est limité à quelques mégabits/s voire quelques centaines de kilobits/s (ex. entre 750 Kb/s et 5 Mb/s), par exemple lorsque le terminal utilise un accès nomade 3G (« Third Génération » en anglais) ou 3G+, le temps de transmission du document peut s'élever à plus d'une minute voire plusieurs minutes, ce qui a une incidence négative sur l'expérience de l'utilisateur du terminal.
Dans l'état actuel de la technique, pour réduire le temps de transmission d'un tel document vers un terminal se trouvant dans une situation telle que mentionnée ci-dessus, le serveur compresse les images comprises dans le document en fonction d'un taux de compression d'image fixe. La taille des images transmises avec le document étant réduite, le temps de transmission du document vers le terminal est également réduit.
Une telle stratégie, si elle est simple à réaliser du point de vue du serveur, présente plusieurs inconvénients du point de vue de l'utilisateur.
Tout d'abord, une telle compression peut dégrader la qualité des images reçues par le terminal lorsque que le taux de compression d'image fixe imposé par le serveur est bas. En outre une telle compression ne se justifie pas nécessairement lorsque le terminal bénéficie d'une bande passante satisfaisante.
Par ailleurs, lorsque que le taux de compression d'image fixe imposé par le serveur n'est pas suffisamment bas par rapport au contexte de transmission du terminal (ex. le terminal se trouve dans de mauvaises conditions du réseau), l'utilisateur du terminal subit un temps de transmission important. Objet et résumé de l'invention
L'invention vise notamment à améliorer cette situation en proposant, selon un premier aspect de l'invention, un procédé de transmission d'un document destiné à être mis en œuvre par un serveur intermédiaire placé entre un terminal et un serveur de documents, le procédé comportant :
une étape de réception, en provenance du serveur de documents, d'un document requis par le terminal ;
une étape de vérification de l'existence dans le document d'au moins une image à traiter au regard d'un critère de taille déterminé ;
s'il n'existe pas d'image à traiter dans le document, une étape d'envoi du document au terminal ;
s'il existe au moins une image à traiter dans le document :
o une étape de traitement de ladite au moins une image à traiter comprenant une étape d'obtention d'un ensemble de tuiles résultant du découpage en tuiles de ladite au moins une image à traiter selon une taille de tuiles adaptée à un contexte de transmission du terminal sur un réseau de communications ;
o une étape d'envoi, via ledit réseau au terminal, du document dans lequel chaque image traitée est remplacée par un code exécutable configuré pour s'exécuter lors d'un accès par le terminal au document et pour requérir les tuiles de l'image traitée remplacée par ce code ; et
o une étape de transmission, via ledit réseau au terminal, des tuiles d'au moins une image traitée du document sur requête du code exécutable remplaçant cette image.
Corrélativement, l'invention vise un serveur intermédiaire placé entre un terminal et un serveur de documents, apte à transmettre un document, le serveur intermédiaire comportant : un module de réception, en provenance du serveur de documents, d'un document requis par le terminal ;
un module de vérification de l'existence dans le document d'au moins une image à traiter au regard d'un critère de taille déterminé ;
un module d'envoi du document au terminal, activé s'il n'existe pas d'image à traiter dans le document ;
des modules, activés s'il existe au moins une image à traiter dans le document, lesdits modules comprenant :
o un module de traitement de ladite au moins une image à traiter configuré pour obtenir un ensemble de tuiles résultant du découpage en tuiles de ladite au moins une image à traiter selon une taille de tuiles adaptée à un contexte de transmission du terminal sur un réseau de communications ;
o un module d'envoi, via ledit réseau au terminal, du document dans lequel chaque image traitée est remplacée par un code exécutable configuré pour s'exécuter lors d'un accès par le terminal au document et pour requérir les tuiles de l'image traitée remplacée par ce code ;
o un module de transmission, via ledit réseau au terminal, des tuiles d'au moins une image traitée du document activé sur requête du code exécutable remplaçant cette image.
Selon un deuxième aspect, l'invention vise aussi un procédé de réception d'un document destiné à être mis en œuvre par un terminal, le procédé comportant :
une étape d'envoi, via un réseau de communications, d'une requête d'accès à un document stocké sur un serveur de documents ;
une étape de réception, via le réseau en provenance d'un serveur intermédiaire placé entre le terminal et le serveur de documents, du document dans lequel au moins une image du document est remplacée par un code exécutable configuré pour s'exécuter lors d'un accès par le terminal au document et pour requérir les tuiles de l'image remplacée par ce code ;
une étape d'accès au document reçu du serveur intermédiaire déclenchant l'exécution dudit au moins un code exécutable ;
- une étape de reconstitution d'au moins une image remplacée dans le document par un code exécutable sur réception de tuiles de cette image en provenance du serveur intermédiaire.
Corrélativement, l'invention vise un terminal apte à recevoir un document, le terminal comportant :
un module d'envoi, via un réseau de communications, d'une requête d'accès à un document stocké sur un serveur de documents;
un module de réception, via le réseau en provenance d'un serveur intermédiaire placé entre le terminal et le serveur de documents, du document dans lequel au moins une image du document est remplacée par un code exécutable configuré pour s'exécuter lors d'un accès par le terminal au document et pour requérir les tuiles de l'image remplacée par ce code;
- un module d'accès au document reçu du serveur intermédiaire déclenchant l'exécution dudit au moins un code exécutable;
un module de reconstitution d'au moins une image remplacée dans le document par un code exécutable activé sur réception de tuiles de cette image en provenance du serveur intermédiaire.
L'invention propose ainsi d'utiliser avantageusement un serveur intermédiaire se situant entre un terminal et un serveur de documents (par exemple, un serveur proxy placé en coupure du flux entre le terminal et le serveur de documents) pour traiter une ou plusieurs images d'un document requis par le terminal, en vue de faciliter leur transmission vers le terminal. Le recours à un serveur intermédiaire permet avantageusement de proposer une solution simple et transparente pour le terminal et le serveur de documents.
Le traitement appliqué par le serveur intermédiaire consiste à découper les images du document ayant une taille importante (c'est-à-dire les images à traiter au regard d'un critère de taille déterminé) en tuiles (c'est-à-dire en plusieurs éléments ou morceaux) dont la taille est adaptée au contexte de transmission du terminal. Puis le document sans ces images mais dans lequel des codes exécutables permettant de récupérer les tuiles des images lors d'un accès au document par le terminal remplacent ces images, est envoyé au terminal. Les tuiles résultant du découpage des images sont ensuite transmises au terminal sur requête des codes exécutables. Autrement dit, les codes exécutables permettent une transmission asynchrone des tuiles des images remplacées par ces codes (c'est-à-dire la transmission vers le terminal du document et celle des tuiles ne sont pas réalisées en même temps). Cette transmission asynchrone mise en œuvre par l'invention ne bloque pas avantageusement le processus global de l'accès au document (ou du chargement du document).
L'invention permet ainsi d'améliorer l'expérience de l'utilisateur du terminal grâce à un accès rapide via le réseau de communications au document qui ne contient plus d'images de taille importante mais les codes exécutables permettant de récupérer ces images ultérieurement.
Par ailleurs, l'invention permet d'optimiser la transmission de ces images vers le terminal, notamment sans sacrifier la qualité des images, grâce à un découpage en tuiles des images selon une taille de tuiles adaptée au contexte de transmission du terminal.
Dans un mode de réalisation, le serveur intermédiaire est apte à effectuer lui-même le découpage des images. En variante, il sous-traite ce découpage à une entité tierce et obtient de cette entité les tuiles à transmettre au terminal.
Comme mentionné précédemment, la taille des tuiles selon laquelle l'image à traiter est découpée, tient compte du contexte de transmission du terminal, c'est-à-dire notamment de conditions (caractéristiques) du réseau (par exemple, de sa bande passante, du protocole de transmission du réseau utilisé, de l'existence ou non d'un mécanisme de contrôle de congestion mis en œuvre par le protocole de transmission, de la latence du réseau, etc.), de contraintes de restitution imposées par le terminal (typiquement de la taille de l'écran du terminal), et/ou de caractéristiques de l'image à traiter (par exemple d'un type d'image, etc.).
Dans un mode particulier de réalisation, cette taille de tuiles vérifie un facteur de qualité d'image (ex. taux de compression d'image) et/ou un temps de transmission maximum.
Autrement dit, la transmission de l'ensemble des tuiles d'une image traitée selon l'invention permet de respecter, voire de dépasser, au moins un paramètre parmi un facteur de qualité de l'image et un temps de transmission de l'image spécifiés, par exemple, par le terminal. De tels paramètres sont particulièrement importants et représentatifs en termes d'expérience utilisateur et permettent de privilégier via l'invention cette expérience lors de la transmission des tuiles de l'image.
Par conséquent, il ne s'agit plus, comme dans l'état de la technique, de compresser l'image du document selon un taux de compression fixe, mais de découper l'image en tuiles selon une taille de tuiles tenant compte du contexte de transmission expérimenté par le terminal. Les contextes de transmission de terminaux distincts étant souvent différents, l'invention permet ainsi de garantir un traitement d'images personnalisé (c'est-à-dire destiné à un terminal donné). De plus, ce traitement est adapté aux besoins réels du terminal utilisateur. Par ailleurs, pour transmettre au terminal les tuiles d'une image traitée, l'invention propose d'envoyer au terminal en premier lieu le document dans lequel cette image est remplacée par un code exécutable, ce code exécutable étant configuré pour s'exécuter lors d'un accès au document (c'est-à-dire d'un chargement ou d'un affichage du document) par le terminal et pour requérir les tuiles de l'image remplacée par ce code. Préférentiel lement, ce code exécutable est un script, c'est-à-dire un programme en langage interprété (par exemple, en langage JavaScript), permettant des interactions avec le serveur intermédiaire et/ou avec l'utilisateur du terminal. Un tel code exécutable ayant une taille moindre par rapport à l'image qu'il remplace, cela permet une transmission rapide du document au terminal.
On note que selon l'invention, avant de traiter une image, le serveur intermédiaire vérifie préalablement s'il existe dans le document une ou plusieurs images à traiter en tenant compte d'un critère de taille déterminé. L'invention permet ainsi de vérifier « à la volée » (c'est-à- dire en temps réel) si au moins une image contenue dans le document a besoin d'être traitée en vue d'être transmise via le réseau au terminal. Autrement dit, il ne s'agit plus, comme dans l'état de la technique, de compresser systématiquement toutes les images d'un document lors de sa transmission vers le terminal. Le traitement effectué par le serveur intermédiaire est ainsi optimisé en ne découpant que les images du document qui en ont besoin, ce qui résulte en une complexité limitée de mise en œuvre de l'invention.
Selon une variante, une image est considérée comme satisfaisant au critère de taille déterminé si sa taille (i.e. le nombre d'octets qu'elle occupe) est supérieure à une taille prédéterminée, par exemple fixée par le serveur intermédiaire, ou déterminée dynamiquement en fonction du lien de transmission du serveur intermédiaire avec le terminal.
Selon une autre variante, une image est considérée comme satisfaisant au critère de taille déterminé si un temps de transmission de cette image vers le terminal sur le réseau estimé par le serveur intermédiaire est supérieur à une consigne de temps de transmission déterminée, par exemple spécifiée par le terminal. Cette consigne correspond par exemple à un temps de transmission maximal acceptable par le terminal. Le temps de transmission estimé de l'image peut être obtenu à partir de la taille de l'image en tenant compte de conditions du réseau expérimentées par le terminal. On s'assure ainsi que les contraintes imposées par l'utilisateur du terminal sont respectées.
Dans un mode particulier de réalisation, la taille de tuiles adaptée au contexte de transmission du terminal est reçue par le serveur intermédiaire dans une requête d'accès au document envoyée par le terminal.
Ce mode de réalisation permet de préserver les ressources du réseau en limitant la signalisation (i.e. échanges de messages entre le terminal et le serveur intermédiaire) pour la mise en œuvre de l'invention. En variante, la taille de tuiles adaptée au contexte de transmission du terminal est reçue par le serveur intermédiaire en provenance d'une entité tierce, ou calculée par le serveur intermédiaire directement.
Dans une autre variante, la taille de tuiles adaptée au contexte de transmission du terminal est mémorisée par le serveur intermédiaire en association avec un compte du terminal.
Grâce à cette association, l'efficacité du serveur intermédiaire est augmentée car ce serveur est apte à utiliser une même taille de tuiles pour découper plusieurs documents requis par le terminal.
Dans un mode particulier de réalisation, le procédé mis en œuvre par le serveur intermédiaire comporte une étape de réception d'un message destiné à modifier la taille de tuiles utilisée pour le découpage des images du document.
Par exemple, cette taille peut être modifiée dynamiquement, via un message envoyé au serveur intermédiaire par le terminal ou par un dispositif de détermination de taille de tuiles d'images, lors d'un changement des conditions du réseau expérimentées par le terminal (ex. changement de bande passante, augmentation/diminution de la latence du réseau).
Ce mode de réalisation garantit un découpage flexible de l'image à traiter en tuiles tout en tenant compte d'un éventuel changement du contexte expérimenté par le terminal.
Dans un mode particulier de réalisation, au cours de l'étape de transmission, les tuiles résultant du découpage d'au moins une image à traiter sont transmises au terminal via plusieurs tâches d'exécution se déroulant en parallèle. Par exemple, les tuiles de l'image sont transmises via 2 à 5 tâches d'exécution (ou fils d'exécution, « threads » en anglais) se déroulant parallèlement, chaque tâche étant destinée à transporter une partie des tuiles de l'image. Cela permet une transmission plus rapide de l'image.
Dans un mode particulier de réalisation, au moins un code exécutable remplaçant dans le document une image traitée est configuré pour requérir les tuiles de cette image sur autorisation d'un utilisateur du terminal.
En outre, lorsqu'il demande l'autorisation à l'utilisateur, le code exécutable peut être configuré pour fournir par exemple à l'utilisateur des informations sur l'image qu'il remplace (ex. nom, type, taille, temps de transmission, etc.).
Ce mode de réalisation permet de décider dynamiquement la transmission d'une image vers le terminal en fonction d'un souhait de l'utilisateur du terminal. Cela permet de ne charger que les images intéressant l'utilisateur et de réduire le temps d'accès au document complet (incluant les images requises par l'utilisateur).
En variante, au moins un code exécutable remplaçant dans le document une image traitée est configuré pour requérir automatiquement les tuiles de cette image, c'est-à-dire sans demander une autorisation de l'utilisateur du terminal.
Cette variante est davantage transparente pour l'utilisateur. Dans un mode particulier de réalisation, un code exécutable remplaçant dans le document une traitée est configuré pour afficher les tuiles de cette image selon un mode d'affichage choisi parmi :
un mode d'affichage des tuiles au fur et à mesure dans le courant de l'étape de transmission; et
un mode d'affichage des tuiles à la fin de l'étape de transmission.
Autrement dit, selon le premier mode d'affichage, ce code exécutable est configuré pour récupérer toutes les tuiles de l'image traitée correspondant à ce code avant de les afficher sur l'écran du terminal. Ceci permet un affichage complet de l'ensemble des tuiles de l'image en une seule fois.
Selon le deuxième mode d'affichage, le code exécutable est configuré pour afficher sur un écran du terminal une tuile de l'image à traiter dès qu'il la reçoit. Ceci permet un affichage en temps réel des tuiles de l'image même si toutes les tuiles de cette image ne sont pas reçues par le terminal. On obtient ainsi un affichage rapide de l'image bien que partiel.
Dans ce cas, les tuiles de l'image peuvent être par exemple affichées séquentiellement par ordre de leurs numéros de séquence ou en colimaçon, etc. en fonction d'une configuration du code exécutable.
Dans un mode particulier de réalisation, les différentes étapes du procédé de transmission ou du procédé de réception sont déterminées par des instructions de programmes d'ordinateur.
En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'information, ce programme étant susceptible d'être mis en œuvre dans un ordinateur, pour la mise en œuvre des étapes du procédé de transmission ou des étapes du procédé de réception selon l'invention, tels que brièvement décrits ci-dessus.
Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
L'invention vise aussi un support d'information lisible par un ordinateur, et comportant des instructions du programme d'ordinateur tel que mentionné ci-dessus.
Le support d'information peut être n'importe quel entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (« floppy dise » en anglais), un disque dur, ou une clé USB.
D'autre part, le support d'information peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Les programmes selon l'invention peuvent être en particulier téléchargés sur un réseau de type Internet. Alternativement, le support d'information peut être constitué de circuits intégrés dans lesquels le programme est incorporé, les circuits étant adaptés pour exécuter ou pour être utilisés dans l'exécution du procédé en question.
Selon un deuxième aspect, l'invention vise également un système de communication comprenant :
un serveur de documents mémorisant un document ;
un terminal selon l'invention apte à requérir un accès à ce document ; et
un serveur intermédiaire selon l'invention apte à recevoir le document du serveur de documents et à transmettre ce document au terminal via un réseau de communications.
Les avantages et caractéristiques particuliers du système de communication selon l'invention sont identiques à ceux du procédé de transmission, du procédé de réception, du terminal et du serveur intermédiaire décrits ci-dessus et ne seront pas rappelés ici.
On peut en outre également envisager, dans d'autres modes de réalisation, que le procédé de transmission, le procédé de réception, le terminal, le serveur intermédiaire et le système de communication selon l'invention présentent en combinaison tout ou partie des caractéristiques précitées.
Brève description des dessins
D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures :
la figure 1 représente un système de communication comportant un serveur intermédiaire, un terminal et un serveur de documents conforme à un mode particulier de réalisation de l'invention ;
- la figure 2 représente un serveur intermédiaire conforme à un mode particulier de réalisation de l'invention;
la figure 3 représente un terminal conforme à un mode particulier de réalisation de l'invention;
la figure 4 représente les différents échanges mis en œuvre entre le terminal, le serveur intermédiaire et le serveur de documents du système de communication de la figure 1 dans un mode particulier de réalisation de l'invention pour la transmission d'un document entre le serveur intermédiaire et le terminal.
Description détaillée de l'invention
La figure 1 représente, dans son environnement, un système de communication SYS conforme à l'invention, dans un mode particulier de réalisation de l'invention. Ce système SYS permet à un terminal TM (ex. téléphone portable, tablette tactile, ordinateur personnel, etc.) d'accéder, par l'intermédiaire d'un serveur intermédiaire SI (ex. serveur mandataire ou proxy), à un document DOC stocké sur un serveur de documents S2 (ex. serveur web, serveur de gestion de courriels, etc.) à travers un réseau de communications NW.
Dans l'exemple envisagé à la figure 1 :
— le terminal TM, le serveur intermédiaire SI et le serveur de documents S2 sont respectivement un téléphone mobile, un serveur proxy et un serveur web ;
— le document DOC est une page web comprenant une ou plusieurs images ; et
— le réseau de communications NW est un réseau 3G dont la bande passante est limitée à 1 Mb/s.
Aucune limitation n'est toutefois attachée à la nature du document DOC destiné à être transmis. Il peut s'agir de tout type de documents, comme par exemple une page web, un courriel, un fichier numérique, etc. Par ailleurs, les images contenues dans ce document peuvent être de différentes natures (ex. image médicale, photographie haute définition, etc.), et/ou de différentes résolutions.
De même, aucune limitation n'est attachée à la nature du réseau de communications NW. Il peut s'agir indifféremment d'un réseau de télécommunications fixe, mobile, sans fil, filaire, etc.
Le terminal TM communique avec le serveur intermédiaire SI et avec le serveur de documents S2 via le réseau NW. Le serveur intermédiaire SI et le serveur de documents S2 communiquent entre eux préférentiellement via un réseau de communications haut débit ou filaire (non illustré sur la figure 1).
Dans le mode de réalisation décrit ici, le serveur intermédiaire SI et le terminal TM ont chacun l'architecture matérielle d'un ordinateur, représentée schématiquement à la figure 2 et figure 3 respectivement.
En référence à la figure 2, le serveur intermédiaire SI comporte notamment un processeur 10, une mémoire non volatile réinscriptible 11, une mémoire morte de type ROM 12, une mémoire vive de type RAM 13 et un module de communication 14.
Le module de communication 14 permet au serveur intermédiaire de communiquer avec le terminal TM via le réseau de communications NW ainsi qu'avec le serveur de documents S2. Il comprend par exemple à cet effet des moyens connus en soi comme une carte réseau, une carte SIM (Subscriber Identity Module), etc.
Il permet notamment au serveur intermédiaire SI de recevoir le document DOC requis par le terminal TM auprès du serveur de documents S2.
La mémoire morte 12 du serveur intermédiaire SI constitue un support d'enregistrement conforme à l'invention, lisible par le processeur 10 et sur lequel est enregistré un programme d'ordinateur PG1 conforme à l'invention comportant des instructions pour l'exécution des étapes d'un procédé de transmission selon l'invention tel qu'il est mis en œuvre par le serveur intermédiaire SI et dont les étapes sont détaillées ultérieurement en référence à la figure 4. Ce programme d'ordinateur définit de façon équivalente des modules fonctionnels du serveur intermédiaire SI (modules logiciels ici). Ces modules s'appuient ou commandent les éléments matériels 10-14 décrits précédemment. Ils comprennent notamment ici un module VRF de vérification configuré pour vérifier l'existence dans le document DOC d'au moins une image IM à traiter conformément à l'invention, un module CT de traitement configuré pour traiter ladite image IM, et un module d'émission/réception COM. Le module d'émission/réception COM est configuré pour envoyer via le réseau NW au terminal TM le document DOC conformément à l'invention (c'est-à-dire tel quel ou dans lequel au moins une image du document a été remplacée par un code exécutable COD comme expliqué plus en détail ultérieurement), et pour transmettre via le réseau NW au terminal TM les tuiles des images découpées du document DOC.
Les fonctions des modules VRF, CT et COM sont détaillées davantage ultérieurement en référence aux étapes du procédé de transmission selon l'invention.
En référence à la figure 3, le terminal TM comporte notamment un processeur 20, une mémoire non volatile réinscriptible 21, une mémoire morte de type ROM 22, une mémoire vive de type RAM 23, et un module de communication 24.
Le module de communication 14 permet au terminal de communiquer avec le serveur intermédiaire SI via le réseau de communications NW, ainsi qu'avec le serveur de documents S2. Il comprend par exemple à cet effet des moyens connus en soi comme une carte SIM (Subscriber Identity Module), etc.
La mémoire morte 22 du terminal TM constitue un support d'enregistrement conforme à l'invention, lisible par le processeur 20 et sur lequel est enregistré un programme d'ordinateur PG2 conforme à l'invention comportant des instructions pour l'exécution des étapes d'un procédé de réception selon l'invention tel qu'il est mis en œuvre par le terminal TM et dont les étapes sont illustrées ultérieurement en référence à la figure 4.
Ce programme d'ordinateur définit de façon équivalente des modules fonctionnels du terminal TM (modules logiciels ici). Ces modules s'appuient ou commandent les éléments matériels 20-24 décrits précédemment. Ils comprennent notamment ici un module d'émission/réception COM', un module ACC d'accès configuré pour accéder depuis le terminal TM au document DOC reçu du serveur intermédiaire SI et déclencher l'exécution dudit au moins un code exécutable COD, et un module RCN de reconstitution configuré pour reconstituer au moins une image IM document DOC à partir de tuiles de cette image reçues du serveur intermédiaire SI. Le module d'émission/réception COM' est configuré pour envoyer au serveur intermédiaire SI (via le module de communication 24 notamment) une requête RQ d'accès au document DOC stocké sur le serveur de documents S2, et pour recevoir le document DOC ou une version modifiée de ce document DOC via le réseau de communications NW en provenance du serveur intermédiaire SI. Il est également configuré pour recevoir via le réseau NW en provenance du serveur intermédiaire SI, les tuiles résultant d'un découpage d'au moins une image IM du document DOC conformément à l'invention. Les fonctions des modules COM', ACC et RCN sont détaillées davantage ultérieurement en référence aux étapes du procédé d'accès selon l'invention.
Nous allons maintenant décrire, en référence à la figure 4, les différents échanges mis en œuvre entre le terminal TM, le serveur intermédiaire SI et le serveur de documents S2 du système de communication SYS de la figure 1 pour la transmission du document DOC requis par le terminal TM dans un mode particulier de réalisation de l'invention.
On rappelle que dans l'exemple de la figure 1, d'une façon générale, le terminal TM, le serveur intermédiaire SI et le serveur documents S2 sont respectivement un téléphone mobile, un serveur proxy et un serveur web.
Conformément à l'invention, l'accès par le téléphone mobile TM à un document DOC comprenant des images, telle qu'une page web, et hébergé par le serveur web S2, est réalisé par l'intermédiaire du serveur proxy SI, et non directement auprès du serveur S2. A cet effet, le serveur proxy SI obtient la page web requise par le téléphone mobile TM en provenance du serveur web S2, et effectue un traitement sur les images IM présentes dans la page web afin de limiter le temps de transmission de cette page web vers le téléphone mobile TM. Ce traitement consiste en un découpage en tuiles des images de la page web qui vérifient un critère de taille prédéterminée, selon une taille (x,y) de tuiles (i.e. dimensions verticale et horizontale des tuiles) prédéfinie. Cette taille (x,y) de tuiles est avantageusement adaptée au contexte de transmission (et notamment aux caractéristiques du réseau 3G NW) expérimenté par le téléphone mobile TM et facilite donc la transmission de l'image IM sur le réseau NW jusqu'au terminal TM. La façon dont la taille (x,y) de tuiles est déterminée sera décrite plus en détail ultérieurement.
Le serveur proxy SI remplace ensuite dans la page web DOC chaque image traitée par un code exécutable et envoie le document ainsi obtenu au téléphone mobile TM via le réseau NW. Le code exécutable permet au terminal de récupérer ultérieurement les tuiles de l'image qu'il remplace.
Ainsi, l'invention permet au téléphone mobile TM d'accéder rapidement à une version modifiée de la page web DOC initiale, c'est-à-dire la page web DOC sans image IM. Par ailleurs, grâce au code exécutable inséré par le serveur proxy SI dans cette page web, le téléphone mobile TM peut récupérer facilement l'image IM que le code exécutable remplace.
Nous allons maintenant décrire en détail chaque étape du procédé mis en œuvre par le téléphone mobile TM et du procédé mis œuvre par le serveur proxy SI.
On suppose ici que le téléphone mobile TM envoie (F10) par l'intermédiaire de son module COM' au serveur proxy SI une requête RQ pour accéder à la page web DOC stockée sur le serveur web S2. Cette requête RQ comporte l'URL (« Uniform Resource Locator » en anglais) de la page web DOC ainsi qu'une ou plusieurs informations optionnelles. Ces informations optionnelles comprennent ici la taille (x,y) de tuiles d'image adaptée au contexte de transmission du téléphone mobile TM, une consigne de facteur de qualité d'image spécifiée par le téléphone mobile TM, ainsi que d'autres paramètres décrits ultérieurement (ex. débit courant du réseau expérimenté par le téléphone mobile lors de son accès à la page web DOC et temps de transmission Td maximal acceptable par l'utilisateur du terminal). Cette consigne est ici un taux de compression destiné à utiliser par le serveur proxy SI lors d'une éventuelle compression d'image.
On note (x,y) cette taille de tuiles, x désignant la dimension verticale de la tuile et y la dimension horizontale, ces dimensions étant exprimées ici en pixels et pouvant être différentes ou identiques dans le cas de tuiles carrées.
En variante, la taille (x,y) des tuiles d'image peut être exprimée dans d'autres unités de mesure connues en soi.
Dans l'exemple envisagé ici, cette taille (x,y) de tuiles est calculée par une entité tierce E sur requête du téléphone mobile TM et communiquée à ce téléphone TM par l'entité tierce E. Elle est déterminée par l'entité tierce E de sorte que la transmission d'une image via des tuiles de cette taille (x,y) sur le réseau 3G NW entre le téléphone TM et le serveur proxy SI respecte un facteur Qmin de qualité de l'image et/ou un temps Tmax de transmission de l'image sur le réseau 3G NW.
Cette taille (x,y) de tuiles est par exemple calculée et obtenue par le téléphone mobile TM comme décrit dans une demande française FR 15 55701 non publiée à ce jour. Selon le procédé décrit dans cette demande, pour déterminer la taille (x,y) de tuiles, le facteur Qmin de qualité de l'image et le temps Tmax de transmission de l'image sont spécifiés par le téléphone mobile TM à l'entité tierce E. Cette entité évalue ensuite une fonction de coût représentative d'une valeur du temps de transmission de l'image à transmettre sur le réseau NW entre le serveur proxy SI et le téléphone mobile TM en fonction d'une valeur du facteur de qualité de l'image et d'une taille de tuiles de l'image. Cette fonction de coût tient compte de caractéristiques/conditions (ex. débit maximal, latence, protocole de transport, etc.) du réseau 3G NW expérimentées par le téléphone mobile TM, de contraintes de restitution de l'image imposées par ce téléphone TM (ex. la taille d'écran du téléphone TM) et du type de l'image (par exemple, image médicale, photographie, etc.). L'entité E détermine alors à partir de la fonction de coût une taille (x,y) de tuiles à utiliser par le serveur proxy SI pour transmettre l'image au téléphone mobile TM, cette taille respectant au moins un du facteur Qmin de qualité de l'image et du temps Tmax de transmission spécifiés par le téléphone mobile TM.
Le serveur proxy SI reçoit (E10), via son module COM, la requête RQ en provenance du téléphone mobile TM. Comme décrit ci-dessus, cette requête RQ comprend ici la taille (x,y) de tuiles.
En variante, le serveur proxy SI reçoit la taille (x,y) de tuiles directement en provenance de l'entité tierce E. Dans une autre variante encore, le serveur proxy SI est apte à déterminer lui-même la taille (x,y) de tuiles à utiliser pour le téléphone mobile TM.
Sur réception de la requête RQ, le serveur proxy SI extrait la taille (x,y) de tuiles de la requête RQ puis envoie (E20) la requête RQ ainsi modifiée au serveur web S2 à partir de l'URL spécifiée dans la requête RQ. Dans l'exemple envisagé ici, la taille (x,y) de tuiles extraite est mémorisée dans le serveur proxy SI et associée à un compte du téléphone TM. Le serveur proxy SI est ainsi apte à utiliser cette taille (x,y) de tuiles pour des documents requis ultérieurement par le téléphone mobile TM. Cette taille (x,y) de tuiles peut être modifiée dynamiquement, notamment via un message envoyé au serveur proxy SI par le téléphone TM, par exemple lorsque le téléphone TM expérimente un changement de conditions du réseau.
Le serveur proxy SI reçoit (E30) ensuite, via son module COM, la page web DOC requise par le téléphone mobile TM du serveur web S2. On rappelle que dans l'exemple envisagé ici cette page web DOC comporte une ou plusieurs images.
Sur réception de la page web DOC et avant d'effectuer un traitement sur les images de la page web DOC, le serveur proxy SI vérifie (E40) via son module VRF s'il existe dans cette page web DOC au moins une image à traiter au regard d'un critère de taille déterminé (c'est-à-dire une ou plusieurs images dont la taille est trop importante pour être transmise directement dans le document DOC sans être traitée préalablement). Cette vérification préalable permet au serveur proxy SI de filtrer la/les image(s) présente(s) sur la page web DOC reçue du serveur web S2, pour identifier au moins une image IM qui a besoin d'être traitée (découpée).
Plus précisément, le serveur proxy SI vérifie ici à cette fin si, pour chaque image de la page web DOC, un temps Te de transmission estimé de cette image au téléphone mobile TM via le réseau NW de communications est supérieur à un temps Td de transmission prédéterminé.
Si le temps Te de transmission estimé pour l'image est supérieur au temps Td de transmission déterminé, l'image est considérée par le serveur proxy SI comme satisfaisant au critère de taille déterminé. Il s'agit donc d'une image à traiter au sens de l'invention.
En variante, le serveur proxy SI vérifie si la taille (i.e. le nombre d'octets) de chaque image de la page web DOC est supérieure à une taille prédéterminée, par exemple fixée par le serveur proxy SI en fonction du type de réseau de communications utilisé par le téléphone mobile TM (ex. 500 ko pour un réseau mobile 3G). Si oui, cette image est considérée par le serveur proxy SI comme satisfaisant au critère de taille déterminé et comme une image à traiter.
Le serveur proxy SI estime le temps Te de transmission de l'image considérée via son module VRF à partir de la taille de l'image et du débit courant du réseau NW 3G expérimenté par le téléphone mobile TM. Le serveur proxy SI obtient ici le débit courant du réseau (ex. 1 Mb/s) du téléphone mobile TM, par exemple dans la requête RQ.
Le temps Td de transmission est spécifié par le téléphone TM (ex. 10 s). Il est envoyé ici au serveur proxy SI par le téléphone TM dans la requête RQ, comme mentionné précédemment.
En variante, le téléphone TM peut envoyer le temps Td de transmission au serveur proxy SI via un message séparé, ou le serveur proxy SI peut le recevoir de l'entité tierce E déterminant la taille (x,y) de tuiles pour le téléphone TM. Si le serveur proxy SI détermine au cours de l'étape E40 qu'il n'existe aucune image à traiter, il envoie (E50) la page web DOC telle que reçue du serveur web S2 au téléphone TM.
On suppose ici qu'au cours de l'étape E40, le serveur proxy SI détecte la présence dans la page web DOC de deux images à traiter IM 1 et IM2. Pour chaque image IM 1 et IM2, le serveur proxy SI traite (E60) via son module CT l'image considérée en la découpant en tuiles TU selon la taille (x,y) de tuiles spécifiée par le téléphone TM dans sa requête RQ. Il stocke les tuiles ainsi obtenues par exemple dans sa mémoire non volatile 11.
En variante, au cours de l'étape E60, le découpage est réalisé par un dispositif de découpage tiers, qui transmet alors les tuiles ainsi découpées au serveur proxy SI.
Par ailleurs, pour chaque image traitée IM 1 et IM2, le serveur proxy SI construit (E62) un code exécutable, CODl et COD2 respectivement, qui est ici un script écrit selon le langage JavaScript. Chacun des scripts CODl et COD2 est configuré pour s'exécuter lorsque le téléphone mobile TM accède à (c'est-à-dire charge ou affiche) la page web DOC et pour requérir les tuiles de l'image correspondante.
Le serveur proxy SI remplace (E64) les images traitées IM 1 et IM2 respectivement par les scripts CODl et COD2 dans la page web DOC.
Puis il transmet (E70) au téléphone mobile TM, par l'intermédiaire de son module COM via le réseau NW, la page web DOC ainsi modifiée, c'est-à-dire sans les images IM 1 et IM2 mais avec les scripts CODl et COD2.
Le téléphone mobile TM reçoit (F30) du serveur proxy SI, par l'intermédiaire de son module COM', via le réseau NW, la page web DOC modifiée, requise précédemment par le téléphone TM et dans laquelle les deux scripts CODl, COD2 remplacent les images IM 1, IM2.
Lorsque le téléphone mobile TM accède (F40) à la page web DOC, par exemple via un navigateur web installé sur ce téléphone, les scripts CODl et COD2 s'exécutent ici séquentiellement (c'est-à-dire par ordre de leur présence sur la page web DOC parcourue de haut en bas).
En variante, les scripts CODl et COD2 sont programmés de sorte à s'exécuter simultanément.
Dans l'exemple envisagé ici, lorsque le script CODl s'exécute, une interface graphique apparaît à la position de l'image IM 1 remplacée par le script CODl sur la page web DOC. Cette interface graphique prend ici la forme d'une fenêtre d'information comprenant un bouton de d'autorisation et un bouton de refus. Cette fenêtre d'information demande à l'utilisateur du téléphone TM l'autorisation de récupérer l'image IM 1. La fenêtre d'information précise par ailleurs ici à l'utilisateur le nom, le type, la taille de l'image IM 1 vers le téléphone mobile TM.
Si l'utilisateur autorise via le bouton d'autorisation la récupération de l'image IM 1, le script CODl envoie une requête au serveur proxy SI pour obtenir les tuiles de cette image IM 1. Si l'utilisateur refuse la récupération de l'image IM1 via le bouton de refus, le script COD1 s'arrête, et ne requiert donc pas la transmission des tuiles de l'image IM1 en provenance du proxy SI.
On suppose ici que l'utilisateur autorise la transmission de l'image IM1.
Sur réception de la requête du script COD1, le serveur proxy SI transmet (E80), via le réseau NW au terminal TM, les tuiles TU résultant du découpage de l'image traitée IM1 et stockées dans sa mémoire non volatile 11.
Les tuiles TU de l'image traitée IM1 sont transmises dans le mode de réalisation décrit ici via plusieurs tâches d'exécution se déroulant en parallèle au téléphone mobile TM. Par exemple, ces tuiles peuvent être transmises via 5 threads, chacun étant destiné à transporter une partie des tuiles de l'image IM1. Ce nombre de 5 threads est bien entendu donné à titre illustratif seulement.
En variante, les tuiles de l'image peuvent être transmises séquentiellement ou selon un mode hybride en fonction du nombre de threads pouvant être utilisés en parallèle.
Le téléphone mobile TM reçoit (F50) ces tuiles de l'image IM1 remplacée par le script COD1 via les tâches d'exécution précitées sur le réseau NW en provenance du proxy SI.
Le téléphone mobile TM restitue (F60) ensuite via son module RCN l'image IM1 initialement contenue dans la page web DOC à partir des tuiles TU reçues.
Dans le mode de réalisation décrit ici, le script COD1 est configuré pour afficher les tuiles TU de l'image IM1 selon un mode d'affichage où ces tuiles TU sont affichées au fur et à mesure de leur réception par le téléphone TM.
En variante, le script COD1 peut être configuré pour afficher ces tuiles TU selon un mode d'affichage où elles sont affichées une fois toutes les tuiles TU de l'image IM1 sont reçues par le téléphone TM, c'est-à-dire affichées en une seule fois.
Dans le mode réalisation décrit ici, le script COD1 comporte une information indiquant la position (i.e. la ligne et la colonne) et un numéro de référence de chaque tuile pour assembler de manière appropriée les tuiles en l'image IM1 et les afficher sur l'écran du téléphone TM. Dans l'exemple envisagé ici, le script COD1 est configuré pour afficher les tuiles de cette image IM1 par ordre de leurs numéros de séquence. En variante, les tuiles de l'image IM1 sont affichées en colimaçon.
Dans l'exemple envisagé ici, une fois l'image IM1 reconstituée, le script COD2 est exécuté à son tour. Par ailleurs, l'exécution du script COD2 et la récupération de l'image IM2 sont selon cet exemple inconditionnelles, autrement dit aucune autorisation de l'utilisateur n'est requise pour récupérer l'image IM2 du serveur proxy SI. Le script COD2 requiert donc automatiquement les tuiles de l'image IM2 traitée remplacée par le script COD2 sans demander l'autorisation de l'utilisateur.
La récupération des tuiles de l'image IM2 par le téléphone mobile TM et la reconstitution de l'image IM2 à partir des tuiles récupérées étant effectuées de façon similaire à l'image IM1, elles ne sont pas redétaillées ici. Ainsi, le téléphone TM restitue les images IM1 et IM2 contenues initialement dans la page web DOC sur son écran. On note que grâce à la taille (x,y) de tuiles utilisée pour le découpage des images IM1 et IM2 qui respecte au moins une des consignes du facteur Qmin de qualité d'image et du temps Tmax de transmission spécifiés par le téléphone mobile TM, les images IM1 et IM2 restituées sur le téléphone TM ont ainsi une qualité et/ou un temps de transmission souhaité(e)(s) par l'utilisateur du téléphone mobile TM. L'expérience de l'utilisateur est ainsi améliorée par rapport à l'état de la technique.

Claims

REVENDICATIONS
1. Procédé de transmission d'un document (DOC) destiné à être mis en œuvre par un serveur intermédiaire (SI) placé entre un terminal (TM) et un serveur de documents (S2), le procédé comportant :
une étape (E30) de réception, en provenance du serveur de documents (S2), d'un document (DOC) requis par le terminal (TM);
une étape (E40) de vérification de l'existence dans ledit document (DOC) d'au moins une image (IM) à traiter au regard d'un critère de taille déterminé ;
- s'il n'existe pas d'image à traiter dans le document (DOC), une étape (E50) d'envoi du document (DOC) au terminal (TM) ;
s'il existe au moins une image (IM) à traiter dans le document (DOC) :
une étape (E60) de traitement de ladite au moins une image (IM) à traiter comprenant une étape d'obtention d'un ensemble de tuiles (TU) résultant du découpage en tuiles de ladite au moins une image (IM) à traiter selon une taille (x,y) de tuiles adaptée à un contexte de transmission du terminal (TM) sur un réseau (NW) de communications ;
une étape (E70) d'envoi, via ledit réseau (NW) au terminal (TM), du document (DOC) dans lequel chaque image (IM) traitée est remplacée par un code (COD) exécutable configuré pour s'exécuter lors d'un accès par le terminal (TM) au document
(DOC) et pour requérir les tuiles (TU) de l'image (IM) traitée remplacée par ce code (COD);
une étape (E80) de transmission, via ledit réseau (NW) au terminal (TM), des tuiles (TU) d'au moins une image (IM) traitée du document (DOC) sur requête du code exécutable (COD) remplaçant cette image (IM).
2. Procédé selon la revendication 1 dans lequel la taille (x,y) de tuiles vérifie un facteur (Qmin) de qualité d'image et/ou un temps (Tmax) de transmission maximum.
3. Procédé selon la revendication 1 ou 2 dans lequel la taille (x,y) de tuiles est reçue dans une requête (RQ) d'accès au document (DOC) envoyée par le terminal (TM).
4. Procédé selon l'une quelconque des revendications 1 à 3 dans lequel au cours de l'étape de vérification, le serveur intermédiaire (SI) détermine qu'il existe une image (IM) à traiter au regard d'un critère de taille déterminé si un temps (Te) de transmission estimé de cette image (IM) sur le réseau (NW) est supérieur à un temps (Td) de transmission déterminé spécifié par le terminal (TM), le temps (Te) de transmission estimé étant obtenu à partir d'une taille (TA) de l'image (IM) à traiter et du contexte de transmission du terminal (TM).
5. Procédé selon l'une quelconque des revendications 1 à 4 dans lequel au cours de l'étape de transmission, les tuiles (TU) sont transmises au terminal (TM) via plusieurs tâches d'exécution en parallèle.
6. Procédé selon l'une quelconque des revendications 1 à 5 dans lequel au moins un code exécutable (COD) remplaçant dans le document (DOC) une image (IM) traitée est configuré pour requérir les tuiles (TU) de de cette image (IM) sur autorisation d'un utilisateur du terminal (TM).
7. Procédé selon l'une quelconque des revendications 1 à 6 dans lequel un code exécutable (COD) remplaçant dans le document (DOC) une image (IM) traitée est configuré pour afficher les tuiles (TU) de cette image (IM) selon un mode d'affichage choisi parmi :
un mode d'affichage des tuiles (TU) au fur et à mesure dans le courant de l'étape de transmission; et
un mode d'affichage des tuiles (TU) à la fin de l'étape de transmission.
8. Procédé selon l'une quelconque des revendications 1 à 7 dans lequel le document (DOC) est une page web et/ou le code exécutable (COD) est un script réalisé en JavaScript.
9. Procédé de réception d'un document (DOC) destiné à être mis en œuvre par un terminal (TM), le procédé comportant :
une étape (F10) d'envoi, via un réseau (NW) de communications, d'une requête (RQ) d'accès à un document (DOC) stocké sur un serveur de documents (S2) ;
- une étape (F20) de réception, via le réseau (NW) en provenance d'un serveur intermédiaire (SI) placé entre le terminal (TM) et le serveur de documents (S2), dudit document (DOC) dans lequel au moins une image (IM) du document (DOC) est remplacée par un code exécutable (COD) configuré pour s'exécuter lors d'un accès par le terminal (TM) au document (DOC) et pour requérir les tuiles (TU) de l'image (IM) remplacée par ce code (COD);
- une étape (F30) d'accès au document (DOC) reçu du serveur intermédiaire (SI) déclenchant l'exécution dudit au moins un code exécutable (COD) ;
une étape (F40) de reconstitution d'au moins une image (IM) remplacée dans le document (DOC) par un code exécutable (COD) sur réception de tuiles (TU) de cette image (IM) en provenance du serveur intermédiaire (SI).
10. Serveur intermédiaire (SI) placé entre un terminal (TM) et un serveur de documents (S2), apte à transmettre un document (DOC), le serveur intermédiaire (SI) comportant : un module (COM) de réception, en provenance du serveur de documents (S2), d'un document (DOC) requis par le terminal (TM);
une module (VRF) de vérification de l'existence dans ledit document (DOC) d'au moins une image (IM) à traiter au regard d'un critère de taille déterminé ;
- un module (COM) d'envoi du document (DOC) au terminal (TM), activé s'il n'existe pas d'image à traiter dans le document (DOC) ;
des modules, activés s'il existe au moins une image (IM) à traiter dans le document (DOC), lesdits modules comprenant :
un module (CT) de traitement de ladite au moins une image (IM) à traiter configuré pour obtenir un ensemble de tuiles (TU) résultant du découpage en tuiles de ladite au moins une image (IM) à traiter selon une taille (x,y) de tuiles adaptée à un contexte de transmission du terminal (TM) sur un réseau (NW) de communications ; un module (COM) d'envoi, via ledit réseau (NW) au terminal (TM), du document (DOC) dans lequel chaque image (IM) traitée est remplacée par un code (COD) exécutable configuré pour s'exécuter lors d'un accès par le terminal (TM) au document
(DOC) et pour requérir les tuiles (TU) de l'image (IM) traitée remplacée par ce code (COD);
un module (COM) de transmission, via ledit réseau (NW) au terminal (TM), des tuiles (TU) d'au moins une image (IM) traitée du document (DOC) activé sur requête du code exécutable (COD) remplaçant cette image (IM).
11. Terminal (TM) apte à recevoir un document (DOC), le terminal (TM) comportant : un module (COM) d'envoi, via un réseau (NW) de communications, d'une requête (RQ) d'accès à un document (DOC) stocké sur un serveur de documents (S2) ;
- un module (COM) de réception, via le réseau (NW) en provenance d'un serveur intermédiaire (SI) placé entre le terminal (TM) et le serveur de documents (S2), dudit document (DOC) dans lequel au moins une image (IM) du document (DOC) est remplacée par un code exécutable (COD) configuré pour s'exécuter lors d'un accès par le terminal (TM) au document (DOC) et pour requérir les tuiles (TU) de l'image (IM) remplacée par ce code (COD);
- un module (ACC) d'accès au document (DOC) reçu du serveur intermédiaire (SI) déclenchant l'exécution dudit au moins un code exécutable (COD) ;
un module (RCN) de reconstitution d'au moins une image (IM) remplacée dans le document (DOC) par un code exécutable (COD) activé sur réception de tuiles (TU) de cette image (IM) en provenance du serveur intermédiaire (SI).
12. Système (SYS) de communication comprenant :
un serveur (S2) mémorisant un document (DOC) ; un terminal (TM) selon la revendication 11 apte à requérir un accès au document
(DOC) ; et
un serveur intermédiaire (SI) selon la revendication 10 apte à recevoir le document (DOC) du serveur (S2) de documents et à transmettre ce document (DOC) au terminal (TM) via un réseau de communications (NW).
13. Programme d'ordinateur (PGl, PG2) comportant des instructions pour l'exécution des étapes d'un procédé selon l'une quelconque des revendications 1 à 8 ou des étapes d'un procédé selon la revendication 9, lorsque ledit programme (PGl, PG2) est exécuté par un processeur.
14. Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur (PGl, PG2) selon la revendication 13.
PCT/FR2016/053533 2015-12-24 2016-12-16 Procédés et serveurs de transmission et de réception de documents comprenant des images WO2017109362A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1563342A FR3046318A1 (fr) 2015-12-24 2015-12-24 Procedes et serveurs de transmission et de reception de documents comprenant des images
FR1563342 2015-12-24

Publications (1)

Publication Number Publication Date
WO2017109362A1 true WO2017109362A1 (fr) 2017-06-29

Family

ID=55650480

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2016/053533 WO2017109362A1 (fr) 2015-12-24 2016-12-16 Procédés et serveurs de transmission et de réception de documents comprenant des images

Country Status (2)

Country Link
FR (1) FR3046318A1 (fr)
WO (1) WO2017109362A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6049821A (en) * 1997-01-24 2000-04-11 Motorola, Inc. Proxy host computer and method for accessing and retrieving information between a browser and a proxy
EP1274247A2 (fr) * 2001-06-27 2003-01-08 Ricoh Company, Ltd. JPEG 2000 pour une transmission efficace d'images dans un environnement serveur-client
US20120194519A1 (en) * 2011-01-28 2012-08-02 Strangeloop Networks Inc. Image Optimization

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6049821A (en) * 1997-01-24 2000-04-11 Motorola, Inc. Proxy host computer and method for accessing and retrieving information between a browser and a proxy
EP1274247A2 (fr) * 2001-06-27 2003-01-08 Ricoh Company, Ltd. JPEG 2000 pour une transmission efficace d'images dans un environnement serveur-client
US20120194519A1 (en) * 2011-01-28 2012-08-02 Strangeloop Networks Inc. Image Optimization

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
FOX A ET AL: "ADAPTING TO NETWORK AND CLIENT VARIABILITY VIA ON-DEMAND DYNAMIC DISTILLATION", PLDI09 : PROCEEDINGS OF THE 2009 ACM SIGPLAN CONFERENCE ON PROGRAMMING LANGUAGE DESIGN AND IMPLEMENTATION ; JUNE 15 - 20, 2009, DUBLIN, IRELAND; [SIGPLAN NOTICES : A MONTHLY PUBLICATION OF THE SPECIAL INTEREST GROUP ON PROGRAMMING LANGUAGES OF THE AS, vol. 31, no. 9, 1 September 1996 (1996-09-01), pages 160 - 170, XP000639230, ISBN: 978-1-60558-392-1, DOI: 10.1145/248209.237177 *
JAMES S JANOSKY ET AL: "Using JPEG2000 for Enhanced Preservation and Web Access of Digital Archives - A Case Study", 31 December 2004 (2004-12-31), XP055298661, Retrieved from the Internet <URL:http://charlesolson.uconn.edu/Works_in_the_Collection/Melville_Project/IST_Paper3.rtf> [retrieved on 20160830] *

Also Published As

Publication number Publication date
FR3046318A1 (fr) 2017-06-30

Similar Documents

Publication Publication Date Title
FR2985130A1 (fr) Procede de partage d&#39;un contenu multimedia entre au moins un premier utilisateur et un second utilisateur sur un reseau de telecommunications
WO2014096660A1 (fr) Procédé de traitement de requêtes d&#39;accès et navigateur web
FR2863127A1 (fr) Procedes et dispositifs pour la delivrance asynchrone de donnees numeriques
EP3087706B1 (fr) Procédé et système de communication entre navigateurs web, utilisant un environnement de communication unifiée
FR3022657A1 (fr) Procede de partage de navigation sur une page web affichee par un navigateur web
EP2915109A1 (fr) Procédé de communication entre plusieurs utilisateurs munis de terminaux de communication, par l&#39;intermediaire d&#39;un espace virtuel de communication
FR3034943A1 (fr) Procede de lecture en continu sur un equipement client d&#39;un contenu diffuse au sein d&#39;un reseau pair a pair
EP2939450B1 (fr) Transmission d&#39;un message multimédia doublée par émission d&#39;un message textuel
EP2706730B1 (fr) Procédé et dispositif de suggestion d&#39;applications
EP2656589B1 (fr) Procede et dispositif de communication de donnees numeriques
EP2360889B1 (fr) Création et utilisation d&#39;un lien de télécommunication entre deux utilisateurs d&#39;un réseau de télécommunication
WO2017109362A1 (fr) Procédés et serveurs de transmission et de réception de documents comprenant des images
EP3205067B1 (fr) Diffusion de contenus en streaming dans un réseau pair à pair
EP2882165B1 (fr) Procédé de traitement de données pour l&#39;établissement d&#39;une communication WebRTC, dispositif et programme d&#39;ordinateur correspondants
EP2545437B1 (fr) Procédé et système de prise de contrôle à distance d&#39;un écran d&#39;affichage
EP3476110B1 (fr) Procédé et dispositif de traitement d&#39;un objet multimédia
FR3025625A1 (fr) Generation et partage d&#39;applications personnalisees de communication
EP1370045B1 (fr) Système d&#39;accès à des données disponibles sur réseau actif
EP1906625B1 (fr) Procédé et système de partage de fichiers sur un réseau, utilisant des capacités de stockage d&#39;un boîtier de connexion au réseau
EP2893732A1 (fr) Procédé pour la connexion d&#39;un terminal au meilleur réseau de téléphonie mobile disponible
FR3057373A1 (fr) Securisation d&#39;une base de donnees d&#39;authentification par un reseau
FR3079711A1 (fr) Procede de gestion d&#39;acces a un contenu numerique.
FR3102874A1 (fr) Procédé de collecte d’information contenue dans des messages électroniques stockés dans un terminal
EP2677708B1 (fr) Procédé de communication d&#39;un message audiovisuel, et système de communication
EP3648443A1 (fr) Gestion d&#39;une communication entre un terminal de communication appelant, disposant d&#39;un identifiant d&#39;appel principal et d&#39;un identifiant d&#39;appel secondaire, et un terminal de communication appelé

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16829411

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16829411

Country of ref document: EP

Kind code of ref document: A1