FR2918527A1 - URL address inserting method for telecommunication system, involves obtaining address from identifier before insertion of address in request, and sending request with address to server after insertion of address in request - Google Patents

Abstract

The method involves intercepting a HTTP request sent by a mobile terminal (10) of a telecommunication system (1) to a third party server (40), and obtaining an identifier (C-M) of a terminal category from the request. An URL address permitting access of a user agent Profile (UAPROF) is obtained from the identifier before insertion of the address in the request, where the profile contains content formats supported by the terminal category. The request including the address is sent to the server after insertion of the address in the request. Independent claims are also included for the following: (1) a computer program comprising instructions for executing a URL address inserting method (2) a recording medium readable by a computer, on which the program for executing a URL address inserting method is recorded (3) a device for inserting an address e.g. URL address, in a header field of a request sent by a terminal to a third party server.

Description

BACKGROUND OF THE INVENTION The present invention relates to the field

  General Telecommunications. The invention relates more particularly to the mechanisms enabling a content server and / or services accessed by a terminal via the Internet, to know the content formats supported by this terminal, in order to adapt the contents and / or services that he delivers him. Thus, the invention applies in a privileged but nonlimiting manner in the context of mobile telecommunications, in which a mobile terminal accesses the server of a provider of content and / or services on the Internet. In the current state of the art, there is a standard, UAPROF (User Agent PROFILE), which allows a mobile terminal to insert, in a standardized field of the request that it sends to a service provider. and / or content, a URL (Uniform Resource Locator). This URL allows the service provider and / or contents to access a UAPROF type file describing the characteristics of this mobile terminal (model, manufacturer, screen size, multimedia capabilities, etc.). These characteristics include the content formats supported by the mobile terminal, and in particular by its browser, that is to say by the application allowing access to the Internet. For GSM terminals for example, these UAPROF files are generated by the terminal manufacturers. However, the generation of UAPROF files associated with the various terminals is optional and suffers from a lack of reliability. Thus, there is not necessarily a UAPROF file associated with each terminal, or more precisely with each category or model of terminals. Moreover, it often happens that a UAPROF file associated with a terminal contains errors or that it is not complete and in particular that it does not include the formats of the contents supported by the terminal. It is even possible that this file is not adapted to the terminal with which it is associated, for example, because one associated with a category of terminals a file corresponding to another category of terminals. In the face of this unreliability, most service providers and / or content providers do not use the information included in the UAPROF file. They then deliver content to the terminal without adapting it to the formats supported by the terminal, thus incurring a significant risk that these contents are not compatible with the terminal, result in a browser error and induce a complaint from the user of the terminal. from the service provider and / or content.

  OBJECT AND SUMMARY OF THE INVENTION According to a first aspect, the present invention aims at a method of inserting an address in a request sent by a terminal to a third party server, this address making it possible to access a file.

  According to the invention, the insertion method comprises, before the insertion of the address in the request: a step of intercepting the request - a step of obtaining, from this request, a identifier of a category of terminals a step of obtaining, with the aid of this identifier, the address allowing access to the file, this file comprising the content formats supported by a terminal of the category identified by the identifier; and after the step of inserting the address into the request, a step of sending the request including the address to the third party server.

  Correlatively, the invention also aims a device for inserting an address in a request sent by a terminal to a third party server, this address to access a file. According to the invention, this insertion device comprises: means for intercepting the request; means for obtaining, from this request, an identifier of a category of terminals; means for obtaining, with the aid of this identifier, the address making it possible to access the file of the database, this file comprising the content formats supported by a terminal of the category identified by the identifier; means for inserting the address into the request; and means for sending the modified query to the third party server. The means for intercepting the request are for example implemented by a proxy. Within the meaning of the invention, a category of terminals may designate a model of terminals. This model is for example identified by a reference and a manufacturer's name or a mark. Alternatively, a class of terminals may designate terminals having some common capabilities or supporting identical content formats. Preferentially, the terminals considered in the invention will be mobile terminals. However, this assumption is in no way limiting, the invention also applying to fixed terminals. Thus the invention makes it possible to intercept a request sent by a terminal to a particular third party server, to insert an address allowing this third party server to access a file of a reliable database, including the content formats supported by the terminal. The address inserted into the request is obtained using an identifier of a category of terminals. This category of terminals is preferably the category to which the terminal at the origin of the request belongs. The identifier of this category is obtained from the request sent by the terminal. On receipt of the request containing the address of the format file, the third party server can consult this file and guarantee the quality of the contents delivered to the terminal by adapting them to the formats supported by this terminal. This operation is advantageously transparent to the user of the terminal. In a particular embodiment of the invention, the insertion device according to the invention is located at an Internet access provider. By necessity, an access provider has its own centralized database containing the content formats supported by the different categories of mobile terminals of its subscribers. This database is therefore by definition reliable and exhaustive (or almost relative to its subscribers). The insertion device can thus be advantageously placed in flow cutoff output of any access platform without impact on these accesses. It can for example be located on a proxy cache such as those usually deployed at the output of this type of platform. Preferably, the address obtained at the obtaining step and inserted in the intercepted request is a URL type address. During the insertion step, the address can be inserted in particular in a field of the header of the intercepted request (for example HTTP request, HyperText Transfer Protocol). This field is, for example, the standardized field of the UAPROF standard in which the mobile UAPROF file URLs are inserted by the mobile terminals in accordance with this standard. This is for example the x-wap-profile field or the profile field. In a particular embodiment of the invention in which the terminals are mobile terminals, the format files supported by the different categories of terminals as well as the header field in which the URL is inserted, comply with the UAPROF standard. Advantageously, the third party server does not need to develop a particular interface for consulting the centralized database containing the content format files. He can access these files via the addresses inserted in the requests by the insertion device according to the invention and identify the format information that is useful to him according to the UAPROF standard. The invention thus offers a transparent operation from the point of view of the third party server of the service provider, already adapted to process a request sent by a terminal in accordance with the UAPROF standard, that is to say comprising in its header a field in which is a URL to access a UAPROF file supposed to contain the content formats supported by this terminal.

  In a particular embodiment of the invention, the insertion method further comprises a step of obtaining an access code to the database. According to the invention, this access code thus obtained is inserted with the address in the request. Correlatively, the insertion device according to the invention further comprises means for obtaining an access code to the database. According to the invention, this code is inserted with the address by the insertion means of the device according to the invention in the intercepted request. This access code makes it possible in particular to limit the access to the database of the format files only to service providers and / or partner contents of the device according to the invention. Moreover, when this access code is temporary, it also makes it possible to limit access to the database in time. This can be useful especially in case of updating the database, for example to update the format files associated with the different categories or to add a new category of terminals. The address and access code can also be encrypted or encrypted before being inserted into the request. The various keys then necessary to encrypt and decrypt the address and the access code are respectively held by the insertion device according to the invention and the third party server of the service provider. This makes it possible in particular to secure, on the one hand, the transmission of the address intended for the third party server, but also the access to the database of the insertion device, in particular limiting this access to only the service providers who have keys needed to decrypt the address. According to a second aspect, the invention also provides a telecommunications system comprising: a mobile terminal adapted to send an access request to a third party server; an insertion device according to the invention adapted to insert an address in the access request sent by the terminal to the third party server; and the third party server, the latter being able to deliver content to the terminal in response to the request sent by this terminal, after adapting the format of the content according to a category of terminals. In a particular embodiment, the various steps of the insertion method are determined by computer program instructions. Accordingly, the invention also relates to a computer program on an information carrier, this program being capable of being implemented in an insertion device or more generally in a computer, this program comprising adapted instructions. in carrying out the steps of an insertion process as 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, comprising instructions of a computer program as mentioned above. The information carrier may be any entity or device capable of storing the program. For example, 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 diskette (floppy disc) or a disk hard.

  On the other hand, 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 program according to the invention can be downloaded in particular on an Internet type network.

  Alternatively, the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question.

  BRIEF DESCRIPTION OF THE DRAWINGS Other characteristics and advantages of the present invention will emerge from the description given below, with reference to the drawings and annex which illustrate an embodiment of this embodiment which is devoid of any limiting character and in which: . FIG. 1 represents a telecommunications system according to FIG.

  the invention in a particular embodiment;

  FIG. 2 represents, in flowchart form, the main steps of an insertion method according to the invention, in a

  particular embodiment in which the insertion device implementing this method is located at a provider of access and contents

  Appendix 1 is an extract of a UAPROF file comprising the content formats supported by a category of terminals, in a particular embodiment of the invention, Detailed description of an embodiment

  Figure 1 shows a telecommunications system 1

  according to the invention in a particular embodiment. According to the invention this telecommunications system 1

has:

  a mobile terminal 10, adapted to communicate over the Internet via a mobile telecommunications network. The mobile terminal 10 is notably equipped with a navigator, enabling it to send and

  Receiving HTTP requests to and from different content servers and / or services;

  a server 40 of a service provider and / or content FC Internet (third server within the meaning of the invention);

  a server 20 of an Internet Service Provider ISP. This provider

  ISP access is for example the mobile operator to which the user of the mobile terminal 10 is subscribed to communicate with his terminal; and

  an internal database 30 generated and maintained, in the example described here, by the ISP access provider.

  The mobile terminal 10 belongs to a category of terminals identified by an identifier This identifier is here a reference corresponding to the model of the terminal 10. It consists for example of the brand or the name of the manufacturer of the terminal 10 and its reference. For example C_M = Orange123. In the following description, for the sake of simplification, it is possible to use indifferently the terminal expressions of category C_M or terminal C_M to designate a terminal belonging to the category of terminals C_M, that is to say here a terminal corresponding to the model C_M . The ISP provider database 30 associates each category C of terminals with a URL U (C) and a file f (C) of the UAPROF type comprising the content formats supported by the terminals of the category C. Thus, in the example described here, by consulting the database 30 using the identifier C_M mobile terminal category, we obtain the URL U (C_M), which provides access to the file UAPROF f ( C_M) describing the capabilities of a terminal belonging to the category C_M. It is assumed that all categories of mobile terminals adapted to communicate on the mobile communications network operated by the access provider (and ISP operator) are present in the database 30. An extract of a file UAPROF f (C) is given in the appendix described now. As seen previously, this file f (C) UAPROF comprises various information, including, in particular, the name of the constructor of the terminal C (ie, here of the terminal model C), its model, the size of its screen and the multimedia characteristics of this terminal information not shown in annex 1). This file is a file written in XM 10 language also includes the different content formats supported by the terminals C associated with this file. Thus, for example, line 19 of file f (C) of Appendix 1 indicates that the mobile terminal C supports mp3 audio content. Similarly, this terminal also supports images in the format bmp or gif according to lines 23 and 24 of Appendix 1. The files of the database 30 described here are UAPROF compliant XML files. This allows in particular to achieve a transparent operation for the service provider, already adapted to consult and manage such files. The latter does not therefore need to develop a particular interface to isolate in the files of the database the information concerning the content formats supported by the terminals sending him requests. However, this hypothesis is in no way limiting. Other file formats, written in other languages, may be used in the context of the invention. The ISP provider 20 comprises a Proxy 21. In the example described here, this Proxy 21 intercepts HTTP streams (requests and responses), via the standardized protocol 'CAP (Internet Content Adaptation Protocol). This protocol makes it possible to encapsulate the requests and the HTTP responses thus intercepted and to send them to a personalization service 22 implementing an ICAP interface (also called ICAP service 22). For more information on the ICAP protocol, the person skilled in the art will refer to the site www.i-cap.org/spec/rfc3507.txt. The ISP provider's server 20 is an insertion device in the sense of the invention. In the example described here, this server 20 has the hardware architecture of a computer, it comprises in particular a processor, a read-only memory and a random access memory not shown in FIG. 1. The server's read-only memory includes in particular a program computer adapted to perform the main steps of the insertion method according to the invention, these main steps being shown in the form of a flowchart in a particular embodiment of the invention in Figure 2 described now. It is assumed that the content and service provider FC has previously agreed to a partnership agreement with the ISP provider, who is also the mobile operator to which the user of the terminal 10 is subscribed. In accordance with this agreement, the ISP IS intercepts any access request issued by a mobile terminal to the service provider FC to insert a URL type address. This address will then allow the service provider FC to access a UAPROF file containing the content formats supported by the mobile terminal at the origin of the access request. It is now assumed that the mobile terminal 10 issues an HTTP R request to the FC service provider's website (request to the server 40). This request R passes through the ISP access provider. It is intercepted at the step UE) by the proxy 21 of the server 20 of the access provider FAT, placed in a flow cut between the mobile terminal 10 and the server 40 of the service provider FC. This Proxy 21 is for example a cache proxy usually placed at the platform exit at an access provider. In the course of the step E12, the proxy 21 analyzes the request R and identifies during a step E14 that the recipient of this request R 25 is the server of a service provider partner of the service provider. The request R is then sent by the Proxy 21, via the ICAP protocol, to the ICAP personalization service 22, during a step E18. If during step E14, the proxy 21 identifies that the recipient 40 of the request R does not correspond to a provider of content and / or partner services of the service provider FAT, then it relays without modification the request R to the recipient site 40, during a step E16. In another embodiment of the invention, the Proxy 21 intercepts all the requests and sends them back to the ICAP service 22. It is the ICAP service 22 which then identifies which requests are intended for a content provider and / or partner service provider of the FAT access provider, and then processes them according to the invention. Requests not intended for a content provider and / or partner services ISP provider provider are relayed without modification via the Proxy 21 to the site of the content provider and / or services. It is assumed here that the ICAP service 22 operates in query mode that is to say that it is adapted to modify an intercepted request and transmitted by the Proxy 21 according to the ICAP protocol.

  During a step E20, the ICAP service 22 obtains from the intercepted request R an identifier C_M of the category of terminals to which the terminal 10 belongs. This identifier is here, as mentioned above, the reference (or designation) of the model of the terminal 10 (C_M = Orangel23). In the example described here, the identifier C_M has been included in the user agent field of the request R by the browser of the terminal 10. The ICAP service 22 therefore extracts the identifier C_M from this user agent field. the request R. In another embodiment of the invention, it is assumed that the category identifier C_M designates a set of terminals supporting the same content formats and is not limited to a single model of terminals. It is then assumed that there exists at the level of the ISP access provider a base establishing for each terminal model an identifier of the category of terminals with which it is associated. The ICAP service 22, after having extracted from the user agent field the model of the terminal 10, then obtains on consultation of this base, the identifier C_M corresponding to the terminal 10. In another embodiment of the invention, the identifier of category C_M can be obtained from an identifier of the terminal 10 from the ISP operator (for example the telephone number of the subscribed user of the terminal 10). A base associating with each telephone number a terminal category identifier then allows the ICAP service 22 to deduce from the telephone number of the terminal 10 the corresponding category identifier C_M.

  The identifier C_M is then used by the ICAP service 22 to interrogate, during a step E22, the internal database 30 of the ISP access provider according to principles known to those skilled in the art. At the end of this interrogation, the ICAP service 22 obtains the URL U (C_M) allowing access to the file UAPROF f (C_M) corresponding to the model of the terminal 10. For example: U (C_M) = http: // baseterminauxorange / recherche In this example, the U (C_M) address is the same for different C_M identifiers. However, this hypothesis is in no way limiting. The address U (C_M) may be different for each identifier.

  For example: U (C_M) = http: // baseterminalsorange / search? Input = C_M The ICAP service 22 also obtains in this step a temporary access code CAT at the base 30 for the server 40 of the service provider FC. This access code CAT, generated by the database 30, is for example here consisting of an encrypted combination of the identifier C_M, the date, the site 40 and a secret code. For example: CAT = 654765789. Alternatively, in another embodiment of the invention, the temporary access code CAT is generated by the ICAP service 22.

  During a step E24, the ICAP service 22 inserts into a field of the header of the HTTP request R, for example in the field xwap-profile or profile according to the WAP (Wireless Application Protocol) version used, the URL U (C_M) and CAT access code. In the embodiment described here, the access code is provided as a parameter of the URL U (C_M). For example, the ICAP service 22 inserts in the field x-wapprofile or profile of the request R: http: // baseterminauxorange / recherche? Entry = 654765789. The request R thus modified, comprising in its header the URL U (C_M) and the CAT access code, is denoted R '. Alternatively, the access code CAT can be provided also in a field of the HTTP request different from the field in which the URL is inserted. In another embodiment of the invention, the ICAP service 22 applies to the URL U (C_M) and CAT access code an encryption algorithm before inserting these elements in the field of the header of the invention. the request R. This algorithm is for example an encryption algorithm using a key shared by the ISP access provider and the service provider FC. Such algorithms are known to those skilled in the art and will not be further described here. This thus makes it possible to guarantee that only a service provider FC partner of the ISP access provider and having the shared key can access the base 30 of the access provider FAT. During a step E26, the ICAP service 22 then sends the modified request R 'to the proxy 21, which transfers it during a step E28 to the server 40 of the service provider FC. Upon receipt of the request R ', the server 40 sends a request I to the URL U (C_M) of the database 30. In the example described here, the temporary access code CAT is provided as a parameter of the Variant URL, temporary access code CAT can be provided in the header of the request 'to URL U (C_M). In response to this request, the database 30 delivers to the server 40 the file UAPROF f (C JI) corresponding to the terminal 10 identified by the identifier C_ The server 40 of the service provider FC then extracts from the file f C jvl) different content formats supported by the mobile terminal 10. It then realizes the adaptation of the requested content in the request R issued by the terminal 10 according to these formats, and returns this content to the terminal 10 via the answer A. This response transits here by the Proxy 21 server 20 ISP ISP before reaching the terminal 10 and display on its browser.

  In the particular embodiment of the invention described above, the insertion device according to the invention (ISP provider server 20) includes both Proxy 21 and ICAP service 22. However this assumption is not in any way limiting. Indeed, in another embodiment of the invention, the various means of the insertion device according to the invention can be distributed over separate physical entities (for example Proxy 21 and the service CAP 22 are on two separate servers) interconnected via interconnection means (eg via a data bus).

ANNEX 1

  <rdf: li> application / java </ rdf: li> << rdf: Ii> application / java-archive </ rdf: Ij> <rdf: Ii> application / sdp </ rdf: li> <rdf: Ii> application / smil </ rdf: li> <rdf:> application / vnd.wap.connectivity-wbxmI </ rdf: Ii> <rdf: li> application / vnd.wap.multipart.related </ rdf: li> <rdf : Ii> application / vnd.wap.sic </ rdf: Ij> <rdf: application / vnd.wap.wbxmI </ rdf:> <rdf: Ii> application / vnd.wap.wmIc </ rdf: Ii> < rdf: 1i> applicationivnd.wap.wmIscriptc </ rdf: Ii> <rdf: li> application / wml + xml </ rdf: li> <rdf: li> application / xhtml + xml </ rdf: li> <rdf: > application / x-java-archive </ rdf: li> <rdf: li> application / x-msmetafile </ rdf: li> <rdf: Ii> application / x-pip </ rdf: ii> <rdf: Ii > audio / mp3 </ rdf: Ii> <rdf: li> audio / mp4 </ rdf: ll> <rdf: Ii> audio / mpeg </ rdf: Ii> <rdf: Ii> audio / wav </ rdf: 11> <rdf: li> image / bmp </ rdf: li> <rdf: li> image / gif </ rdf: Ii> <rdf: li> image / jpeg </ rdf:> <rdf: li> image / jpg </ rdf: 11> <rdf: li> multipart / mixed </ rdf: li> <rdf: Ii> text / htmI </ rdf: Ii> <rdf: li> textiplain </ rdf: Ii> 30

Claims (8)

  1. A method (E24) for inserting an address (U (C_M)) into a request (R) sent by a terminal (10) to a third party server (40), this address making it possible to access a file ( f (C_M)) said method being characterized in that it comprises, before said insertion (E24): - an interception step (EH)) of said request (R); a step of obtaining (E12), from said request (R), an identifier (C_M) of a category of terminals to a obtaining step (E22), using said identifier, of said address (U (C_M)) for accessing said file (f (C_M)), this file comprising content formats supported by a terminal of said category and after said insertion (E24) of said address (U (C_M) ) in said request (R): - a step of sending (E28) said request (R) comprising said address to said third server (40).   2. Method according to claim 1 characterized in that, in said obtaining step (E22), the obtained address (U (C_M)) is a URL.   3. Method according to claim 1 or 2 characterized in that during said insertion step (E24), said address is inserted in a field of the header of said request (R).   4. Method according to any one of claims 1 to 3, characterized in that it further comprises a step of obtaining (E22) an access code (CAT) and in that, during said insertion (E24), it also includes in said request (R) said access code (CAT) thus obtained.   5. Method according to claim 4, characterized in that said access code (CAT) and said address (U (C_M)) are encrypted before being inserted in said request (R).   Computer program comprising instructions for executing the steps of the insertion method according to any one of claims 1 to 5 when said program is executed by a computer.   A computer-readable recording medium on which a computer program is recorded including instructions for performing the steps of the insertion method according to any one of claims 1 to 5.   8. Device for inserting (20) an address (U (C_M)) into a request (R) sent by a terminal (10) to a third party server (40), this address (U (C_M)) enabling accessing a file (f (C_M)), said device (20) comprising: - means (21) for intercepting said request (R ù means (21) for obtaining, from said request (R), an identifier (C_M) of a category of terminals - means (22) for obtaining, by means of said identifier (CM), said address (U (C_M)) allowing access to said file (f (C_M)) , this file comprising the content formats supported by a terminal of said category - means (22) for inserting said address (U (C_M)) in said request (R); - means (21) for sending said request ( R ') comprising said address to said third server (40) 13. Insertion device according to claim 8, characterized in that it comprises a proxy (21) implementing said means for 0 intercepting said re quest 14. A telecommunications system (1) comprising a terminal (10) adapted to send an access request (R) to a third party server (40), an insertion device (20) according to claim 8 or 9 , adapted to insert an address (U (C_M)) in said access request sent by said terminal to said third party server and said third party server (40), the latter being able to deliver a content to said terminal (10) in response to said request, after adapting the format of this content according to a category of terminals.