Method for distributing file between 3gpp mcdata interconnected systems

Description

Title of the invention: File distribution method between interconnected 3GPP MCData systems

TECHNICAL FIELD OF THE INVENTION

[0001] The technical field of the invention is that of telecommunications.

[0002] The present invention relates to a method for distributing files between interconnected 3GPP MCData systems, and in particular making it possible to manage access to a file stored within a system by an external system while limiting security risks, as well as as a process for deleting such a file.

TECHNOLOGICAL BACKGROUND OF THE INVENTION

[0003] The PMR radiocommunication standards (according to the Anglo-Saxon name “Professional Mobile Radio” for “Professional Mobile Radio”) TETRAPOL®, TETRA® or even P25® allow the implementation of secure professional networks. These narrowband networks are national or local networks: they are implemented for example within an organization such as a company, within a country for example for communications of firefighters, law enforcement, soldiers etc.

[0004] These networks are evolving towards supporting broadband exchanges. The 3GPP standard governing mobile networks of the “GSM” type according to the Anglo-Saxon name “Global System for Mobile Communications” and more particularly in deployments using critical communications services defined by the 3GPP called “MCS” according to the name Anglo-Saxon “Mission Critical Services” allows these secure broadband exchanges.

[0005] The term "communication network according to the 3GPP MCS standard" means a communication network compatible with the 3GPP MCS standard and more particularly with the current version of the 3GPP which is version 17, with previous versions from version 13 and with subsequent versions incorporating all the characteristics of the invention.

[0006] In the 3GPP MCS standard, the following communication services are defined: • MCPTT, from the English “Mission Critical Push To Talk” for “Appuyer Pour Parler en Mission Critique” in French, which allows voice communications to be carried out , • MCVideo, which allows video communications, • MCData, which includes three sub-services:

• SDS from English “Short Data Service” in French and • FD from English “File Distribution” for “File Distribution” in French, • IPCon from English “IP Connectivity” for “IP Connectivity” in French.

[0007] An R network making it possible to implement FD file distribution of the MCData service is for example represented in [Fig.l]. This network R is distributed over several interconnected systems A and B. System A includes an MCData Cl client connected to an MCData SCI content server (also called “MCData Content Server” according to the name of 3GPP MCS in English). The SCI content server can communicate with other servers in the R network. In [Fig.l], the SCI content server can communicate with a 3GPP MCS SL server. Such an SI server includes an FD file distribution function, in collaboration with the SCI file content server. This is represented in [Fig.2], which shows the exchanges included in a known file distribution process in the network R of [Fig.l]. The process is also shown in [Fig.3]. This process is described in 3GPP technical specification TS 23.282 (MCData Stage 2) Revision 17 Section 7.5.2.4.3. This process requires the implementation of a service agreement in the two interconnected systems A and B, in particular to share MCData information such as messages or files. This process uses the HTTP protocol (“Hypertext Transfer Protocol” according to the Anglo-Saxon name for “Hypertext Transfer Protocol” in French).

[0008] In a step 11, the client Cl loads its file F on the content server SCI, as described in the technical specification 3GPP TS 23.282 (MCData Stage 2) Revision 17 Section 7.5.2.2. The file F is then assigned, by the SCI content server, a URL address (“Uniform Resource Locator” according to the Anglo-Saxon name for “Uniform Resource Locator”) URL1. The URL1 address locates the file F and allows a client or a server of the network R or an external network to identify the file F and therefore to access the file F stored by the content server SCI.

[0009] In a step 12, the client Cl sends an MCData file distribution request, called “MCData FD Request” according to the Anglo-Saxon name. Such a request includes the URL1 address of the F file and is intended:

• to a client C2 of the network R, for file sharing between two MCData clients, • to a plurality of clients belonging to an MCData group of the network R for file sharing in the MCData group.

[0010] This request makes it possible to inform the recipient clients that a file F is available at the address URL1 on the content server SCI of the network R. In the case shown in [Fig.2], the client C2, belonging to system B interconnected with system A, is the recipient of the request sent in step 12. Step 12 includes several sub-steps of transmitting this request, first sent by the client Cl to the server SL. The server SI receiving this request carries out a sub-step Aut of verifying that the client Cia is indeed authorized to send the request, and checking with the SCI content server that the file F is still available at the URL1 address included in the request, this sub-step being represented by dotted arrows of different sizes. If the file is no longer available, request 12 is not transmitted and the process is stopped. If the file F is still available, after checking the authorization and availability of the file F, the request is sent from the server SI to a server S2 included in the system B interconnected with the system A, because the system B includes the recipient C2 client. The S2 server is a 3GPP MCS server implementing an FD file distribution function. The request is transmitted, in step 12, via gateway GW1 belonging to system A and via gateway GW2 belonging to system B.

[0011] The server S2 receives the request and checks which users have the possibility of receiving a file and which users are authorized to receive the file F. The file F is then transmitted to the client C2, used by a user authorized to receive the file F. The client C2 receiving the request can inform its user of the availability of the file F, for example via an alert Al, for example via a screen of the client C2.

[0012] The client C2 then sends a response to a step 13, transmitted by the server S2 to the server SI via the gateways GW1 and GW2, then by the server SI to the client CL This response is a protocol acknowledgment, without intervention of the user, informing of the successful receipt of the message by the client C2.

The client C2 then sends a request to download the file F in step 14. This request is sent to the content server SC2.

The content server SC2 receiving the request checks whether the file is stored locally and, if this is not the case, sends a file retrieval request F to the content server SCI. The file download request F includes the URL1 address of the file location in system A.

The file F is then transmitted from the content server SCI to the content server SC2 then to the client C2, as shown in dotted lines. The content server SC2 of the interconnected system B can then also store the file F.

[0016] At a step 15, the client C2 provides the client Cl with a report on the completion of the download of the file F, if this was requested by the user of the client Cl in the initial request of step 12.

The report on the completion of the download of the file F is sent to the server SI by the server S2. The S2 server may store the download completion report for querying the download history by authorized users in system B. The report received on the completion of the download of the file F is sent by the server SI to the user of the client CL The report of completion of the download of the file F coming from the client C2 can be stored by the server SI for querying download history by authorized users in system A.

[0018] Thus in the process shown in Figures 2 and 3, the URL1 address of the file F passes from system A to system B and within system B.

[0019] In the same way, [Fig.4] the exchanges included in a known method 1b for deleting the file F in the network R of [Fig.l]. Process 1b is also shown in [Fig.5]. This process is described in 3GPP technical specification TS 23.282 (MCData Stage 2) Revision 17 Section 7.5.2.8.

[0020] In a first step 16, the client MCData Cl wishes to delete the file included in the content server SCI. It therefore sends an http request including the URL1 address. This request is received by the content server SCI, which then deletes the file located at the address URL1, that is to say the file F, in step 17.

[0021] This deletion request is transmitted by the content server SCI to the content server SC2. This request also includes the URL1 address. The content server SC2 then deletes the file F if it stores it, in a step 19. The deletion method can include an alert Al to the user of the client C2 to inform him that the file F has been deleted. Information that the deletion has been carried out is then sent by the content server SC2 to the content server SCI then to the client Cl in a step 20.

[0022] Thus in method 1b shown in Figures 4 and 5, the URL1 address of file F also passes from system A to system B and within system B.

[0023] This presents a security risk for system A when it exposes internal information outside its security perimeter, in particular the URL1 address, or part of this address, where a file to be stored is directly stored. share.

[0024] There is therefore a need to be able to provide a file distribution service in a 3GPP MCS network that does not present the aforementioned drawbacks.

Summary of the invention

[0025] The invention offers a solution to the problems mentioned above, by proposing, to distribute a file in a network according to the 3GPP MCS standard, dynamic address modification at the level of gateways and content servers and storage in memory of the different address correspondences and the entities storing the file.

[0026] A first aspect of the invention relates to a method of distributing, by a first client entity, a file to at least one second client entity, in a communication network according to the 3GPP MCS “3rd Generation” standard. Partnership Program Mission-Critical System", the first client entity being included in a first system further comprising a first content server and a first file distribution management server, the second client entity being included in a second system further comprising a second content server and a second file distribution management server, the first system and the second system being interconnected by a first gateway included in the first system and by a second gateway included in the second system, the file being stored by the first content server and being associated with a first address in the first system, the network being formed by at least the first system and the second system, the method comprising at least the steps of:

• Transmission, by the first client entity to the first gateway, of a file distribution request comprising the first address associated with the file in the first system, • Modification, by the first gateway, in the file distribution request, of the first address associated with the file in the first system, into a second address associated with the file in the first system, • Storage, by the first gateway of a correspondence between the first address and the second address, • Transmission, by the first gateway to the second content server via the second gateway and the second file distribution management server, of the file distribution request file comprising the second address associated with the file in the first system, • Modification, by the second file distribution management server, in the file distribution request, of the second address associated with the file in the first system, into a third address associated with the file in the second system, • Storage, by the second file distribution management server of a correspondence between the second address and the third address, • Transmission, by the second content server, of the file distribution request comprising the third address to the second client entity, • Transmission, by the second client entity, of a request to download the file to the second content server, the request comprising the third address, • Receipt, by the second client entity, of the file.

[0027] Thanks to the invention, the address of the file within the first system is never shared with the second system. This is advantageously achieved thanks to the first gateway which modifies the first address with a second address specific to this first gateway. Thus, the system only sees the address of the first gateway and does not obtain information concerning the path inside the first system, nor concerning the composition and topology of the first system. Furthermore, the first gateway belonging to the first system stores the correspondence between the two addresses, which makes it possible to reverse the process and send information to the first system from the second system.

[0028] Furthermore, the second content server modifies the second address into a third address, thus making it possible to have, within the second system, an address dedicated to this file although stored in the first system. Thus, only the second gateway and the second content server have knowledge of the address of the first gateway, and the rest of the equipment in the second system has knowledge of the third address, dedicated to the file in the second system. This equipment then does not have the slightest knowledge of the first system and security is reinforced.

The invention is also available in two embodiments described in the dependent claims.

[0030] In addition to the characteristics which have just been mentioned in the preceding paragraphs, the file distribution method according to a first aspect of the invention may present one or more complementary characteristics among the following, considered individually or in all technically possible combinations. possible:

• the file is sent from the second content server to the client entity in response to the file download request, • in a first embodiment of the first aspect of the invention, the file is transmitted by the first content server content to the second content server and the file is stored by the second content server before transmission, by the second client entity, of the file download request, • after receiving the request to distribute the file and the file, the second content server transmits to the first gateway, via the second gateway, a response indicating that the file has been stored by the second content server, the response comprising the third address, • the second gateway, upon receipt of the response:

• creates a fourth address associated with the file stored by the second content server in the second system, • modifies the third address included in the response to the fourth address created, • stores a correspondence between the third address and the fourth address, • transmits the response including the fourth address to the first gateway, • and according to which the first gateway stores a correspondence between the second address and the fourth address and information about storage of the file by the second content server at the fourth address.

• In a second embodiment of the first aspect of the invention, the file distribution method further comprises the steps:

• the request to download the file is transmitted by the second client entity to the second content server, then • the third address included in the download request is transformed into the second address from the correspondence between the second address and the third address stored by the second management server, then • the request is transmitted by the second content server to the first gateway via the second gateway, then • the second address included in the download request is transformed into the first address from the correspondence between the first address and the second address stored by the first gateway, then • the request is transmitted by the first gateway to the first server content, then • the file is transmitted by the first content server to the second content server.

[0031] A first embodiment of a second aspect of the invention relates to a method of deleting the file distributed according to the file distribution method according to the first embodiment of the first aspect of the invention, comprising at least the steps of:

• Transmission, by the first client entity, of a request to delete the file to the first content server, the request comprising the first address associated with the file within the first system, • Deletion, by the first SCI content server, of the file that it stores, • Transmission, by the first content server, of the file deletion request to the first gateway, • Conversion, by the first gateway, from the first address associated with the file in the first system, to the second address associated with the file in the first system, from the correspondence between the first address and the second address stored by the first gateway, • Deletion, by the first gateway , of the correspondence between the first address and the second address stored by the first gateway, • Modification, by the first gateway, in the file deletion request, from the first address associated with the file in the first system, to the fourth address associated with the file in the second system, from the storage information of the file by the second content server at the fourth address, from the step of conversion and correspondence between the second address and the fourth address stored by the first gateway, • Transmission, by the first gateway, of the file deletion request to the second gateway, • Modification, by the second gateway, in the request to delete the file, of the fourth address, into the third address, from the correspondence between the fourth address and the third address stored by the second gateway, • Deletion, by the second gateway, of the correspondence between the fourth address and the third address stored by the second gateway, • Transmission, by the second gateway, of the file deletion request to the second content server via the second management server, • Deletion, by the second management server, of the correspondence between the second address and the third address stored by the second management server.

[0032] In a variant, the method of deleting the file further comprises a step of deleting, by the second content server, the file that it stores.

[0033] A second embodiment of the second aspect of the invention relates to a method of deleting the distributed file according to the second embodiment of the first aspect of the invention comprising at least the steps of:

• Transmission, by the first client entity, of a request to delete the file to the first content server, the request comprising the first address associated with the file within the first system, • Deletion, by the first SCI content server, of the file that it stores, • Transmission, by the first content server, of the file deletion request to the first gateway, • Conversion, by the first gateway, • Deletion, by the first gateway, of the correspondence between the first address and the second address stored by the first gateway, • Modification, by the first gateway, in the request to delete the file, of the first address associated with the file in the first system, into the second associated address to the file in the first system, from the correspondence between the first address and the second address stored by the first gateway, • Transmission, by the first gateway to the second content server, of the request to delete the file via the second gateway and the second management server, • Deletion, by the second management server, of the correspondence between the second address and the third stored address by the second management server.

Another aspect of the invention relates to a communication network according to the 3GPP MCS “3rd Generation Partnership Program Mission-Critical System” standard, the communication network being formed by at least:

• a first system comprising at least a first client entity, a first content server and a first file distribution management server, • a second system comprising at least a second client entity, a second content server and a second file distribution server file distribution management, • the first system and the second system being interconnected by a first gateway included in the first system and by a second gateway included in the second system, the communication network being configured to implement the file distribution method according to the invention and the file deletion method according to the invention.

[0035] According to another aspect, the invention relates to a computer program product comprising instructions which lead the network according to the invention to execute the steps of the method according to the invention and of the file deletion method according to the invention .

[0036] According to another aspect, the invention relates to a computer-readable medium, on which the computer program product according to the invention is recorded.

The invention and its various applications will be better understood on reading the following description and examining the accompanying figures.

BRIEF DESCRIPTION OF THE FIGURES

[0038] The figures are presented for information purposes and in no way limit the invention.

• [Fig.l] shows a schematic representation of a network according to the 3GPP MCS standard, • [Fig.2] shows a schematic representation of the exchanges of a known file distribution method within interconnected systems in the 3GPP MCS standard, • [Fig.3] shows a schematic representation of a known file distribution method within interconnected systems in the 3GPP MCS standard, • [Fig.4] shows a schematic representation of the exchanges of a known file deletion process within interconnected systems in the 3GPP MCS standard, • [Fig.5] shows a schematic representation of a file deletion process - known file pressure within interconnected systems in the 3GPP MCS standard, • [Fig.6] shows a schematic representation of the exchanges of a file distribution method according to a first embodiment of the invention within interconnected systems in the 3GPP MCS standard, • [Fig.7] shows a schematic representation of a file distribution method according to a first embodiment of the invention within interconnected systems in the 3GPP MCS standard, • [Fig.8] shows a schematic representation of the exchanges of a file distribution method according to a second embodiment of the invention within interconnected systems in the 3GPP MCS standard, • [Fig.9] shows a schematic representation of a file distribution method according to a second embodiment of the invention within interconnected systems in the 3GPP MCS standard, • [Fig. 10] shows a schematic representation of a file deletion method according to a first embodiment of the invention within interconnected systems in the 3GPP MCS standard, • [Fig.l 1] shows a schematic representation of a file deletion method according to a second embodiment of the invention within interconnected systems in the 3GPP MCS standard.

DETAILED DESCRIPTION

Unless otherwise specified, the same element appearing in different figures presents a unique reference.

[0040] Figures 6 and 7 both show a schematic representation of the file distribution method according to a first embodiment of the invention.

Figures 6 and 7 show a different representation of the same process. The method according to a first embodiment of the invention is implemented by the network R represented in [Fig.l].

[0041] Figures 8 and 9 both show a schematic representation of the file distribution method according to a second embodiment of the invention. Figures 6 and 7 show a different representation of the same process. The method according to a first embodiment of the invention is implemented by the network R represented in [Fig.l].

The method according to the invention is a file distribution method within interconnected systems forming a network according to the 3GPP MCS standard.

[0043] The network R represented in [Fig.l] implementing the methods according to the invention is a network according to the 3GPP MCS standard, that is to say it is implemented following the specifications defined by the 3GPP MCS standard.

This network R is formed by the first system A and the second system B. Systems A and B are interconnected, that is to say they are linked by gateways, a first gateway GW 1 belonging to the first system A and a second gateway GW2 belonging to the second system B. The invention is not limited to these two interconnected systems, and covers any network comprising a plurality of interconnected systems. The two gateways communicate with each other according to any known exchange protocol, for example via exchanges according to the HTTP protocol.

The first system A comprises a first client entity Cl, a first content server SCI, a first management server SI and the first gateway GW1. The second system B comprises second client entity C2, the second content server SC2, the second management server S2 and the second gateway GW2. The GW 1 and GW2 gateways can be implemented by servers.

[0046] A client entity is a device, preferably a user equipment (UE) comprising at least one memory and at least one processor, the memory comprising instructions which, when executed by the processor, lead the user equipment to implement the actions assigned to it in the rest of the description. Preferably, the client entities include a display device, in order to display the distributed file F, for example comprising text, a photo, or any other file. In the same way, the different servers, including content servers, file distribution management servers, and optionally the gateways are devices comprising at least one memory and at least one processor, the memory comprising instructions which, when they are executed by the processor, lead the server to implement the actions assigned to it in the remainder of the description. The servers and the client entities are connected to each other and form the network R such as that represented in [Fig.l], this network implementing wired, wireless communications, or any combination.

[0047] A content server is an MCData server intended to store F files, as defined by the 3GPP MCS standard under the name “MCData content server”. A file distribution management server is any server according to the 3GPP MCS standard implementing an FD file distribution function. The content server and the file distribution management server, also subsequently called "management server" for simplicity, can be confused, that is to say collocated in the same physical server, and be implemented by a server including an FD file distribution function and a file storage function.

[0048] The file distribution method according to the invention and the file deletion method according to the invention can be implemented for any MCData FD communication (for “File Distribution”), “on-network”, i.e. i.e. using an LTE network infrastructure (for “Long Term Evolution”) and “off-network”, i.e. without using an LTE network infrastructure:

• one to one file distribution using the HTTP protocol, • one to one file distribution using the 3GPP standard MCData service media plan MCS, • group standalone file distribution using the HTTP protocol, • group standalone file distribution using the media plan of the MCData service of the 3GPP MCS standard. [0049] Indeed, the file distribution method according to the proposed invention, although presented in communication between two client entities, is also applicable in the case of MCData group communication involving one or more interconnected MCData systems. In the same way, the file deletion method according to the invention, although presented in communication between two client entities, is also applicable in the case of an MCData group communication involving one or more interconnected MCData systems.

The file distribution method according to the invention can be implemented according to two embodiments. In a first embodiment, called "PUSH" mode for "push" in French, the file F is first sent to the second content server SC2 at the initiative of the first gateway GW1, then the second client entity C2 requires access to the F file directly from the second content server SC2. In a second embodiment, called “PULL” mode for “pull” in French, the file F is sent to the second system only in response to the request from the second client entity C2. In the same way, the file deletion method according to the invention is implemented according to the first embodiment "PUSH" when the distribution method is implemented according to the first embodiment "PUSH" and the method of file deletion according to the invention is implemented according to the second “PULL” embodiment when the distribution method is implemented according to the second “PULL” embodiment.

[0051] First embodiment: “PUSH” mode

[0052] The file distribution method according to a first embodiment of the invention called “PUSH” will now be described. Method 2 according to the first embodiment of the invention is shown in Figures 6 and 7.

[0053] [Fig.6] represents the exchanges between the different entities involved in the file distribution process 2, and [Fig.7] represents the file distribution process 2.

[0054] The file distribution method 2 comprises steps 11 to 15 of the file distribution method 1a of the state of the art, some of which take into account a different file address compared to the prior art, and includes additional steps.

The file distribution method 2 comprises the first step 11 of loading the file F on the first content server SCI, as described in the technical specification 3GPP TS 23.282 (MCData Stage 2) Revision 17 Section 7.5.2.2. This first step may be optional, because the F file may already be on the first SCI content server.

The file distribution method 2 comprises the second step 12 divided into a first part 12A and a second part 12B. The first part 12A comprises the transmission of a request for distribution of the file F from the first client entity Cl to the first gateway GW 1 via the first content server SCI and the first management server SL The request for distribution of the file includes a first URL1 address. The address URL1 is preferably of type URL (for “Uniform Resource Locator”) and is associated with the file F in the first system A, that is to say it indicates where the file F is stored in the first system A. As in the prior art, the first SI management server optionally performs an Aut step of authorizing the request and checking the availability of the file F at the first address URL1 included in the request. The request is then transmitted to the first gateway GW 1 by the first management server SL

[0057] The first gateway GW 1 then implements a step 21 of modification, by the first gateway GW1, in the file distribution request, of the first URL1 address associated with the file F in the first system A, in a second URLG1 address associated with file F in the first system A. The second URLG1 address is specific to the first gateway GW1, that is to say it designates a storage location of the first gateway GW 1 and/or a path leading to the first gateway GW1. At the same time, the first gateway GW1 stores a correspondence between the first URL1 address and the second URLG1 address.

[0058] Throughout the application, a “correspondence between two addresses” is at least one piece of data allowing an entity to relate the two addresses. This can be achieved by storing the two addresses in a database on the same row or in the same column, or by adding an indicator to each address in the database allowing the two addresses to be linked, an indicator was a piece of data boolean type, text or any other data type. Throughout the application, an entity “stores” data such as a correspondence or a file by recording the data on a physical medium that it understands or has access to. This data or file can for example be accessed via a database.

[0059] The first gateway GW 1 also implements a step 22 for retrieving the file F. Indeed, in the first “PUSH” embodiment, the file F is sent to the second content server SC2 of the second system B in at the same time as a request, during the process of establishing the different addresses. This step 22, included in the file distribution method 2, is implemented for example by sending, by the first gateway GW1 to the first content server SCI, a file retrieval request F comprising the first URL1 address of the file F within the first system A. This request can be of the “MCData file retrieve request” type as defined by the 3GPP MCS standard. In response to this request, the first content server SCI transmits to the first gateway GW1 the file F, which is then stored by the first gateway GW 1 at the second address URLG1.

The file F is then transmitted, in a step 23, by the first gateway GW 1 to the second content server SC2. This can be achieved by transmitting the F file with a “MCData FD Upload data request” as defined by the 3GPP MCS standard. This step 23 is carried out by transmitting the request from the first gateway GW1 to the second gateway GW2 then from the second gateway GW2 to the second management server S2, then from the second management server S2 to the second content server SC2. During this transmission 23, the second management server S2 creates a third URL2 address associated with the file F in the second system B and creates and stores a correspondence between the second URLG1 address and a third URL2 address. The third URL2 address is specific to the second content server SC2, that is to say it designates a storage location of the second content server SC2 and/or a path leading to the file F stored on the second content server SC2.

[0061] The file F is then stored by the second content server SC2, as shown by the rectangle entitled “F:URL2” in [Fig.6].

The file distribution method 2 then comprises a step 24 of transmission, by the second content server SC2 to the first gateway GW1, of a response indicating that the file F has been stored by the second content server SC2. This response is first transmitted to the second gateway GW2, which then creates a fourth URLG2 address. The second gateway GW2 also stores a match between the third URL2 address and the fourth URLG2 address. Thus, any system outside the second system B can access the file F stored by the second content server SC2 at the third address URL2 without security risk for the second system B. For example, the first system A can access the file F stored by second content server SC2 using the fourth URLG2 address. Another system not shown can also access the file F stored by the second content server SC2 at the third URL2 address using the fourth URLG2 address. The second gateway GW2 receiving a request comprising the fourth URLG2 address will then convert the fourth URLG2 address into the third URL2 address.

The second gateway GW2 transmits the response indicating that the file F has been stored by the second content server SC2 to the first gateway GW1. This response includes the fourth URLG2 address, the third URL2 address included in the response having been modified by the second gateway GW2 into the fourth URLG2 address. The first gateway GW1 then stores storage information for the file F by the second system B at the fourth address URLG2.

As in the prior art, the first gateway GW1 then transmits a file distribution request in a second part of step 12 called 12B to the second client entity C2. Thus, the file distribution method file distribution method 2 is transparent for the second client entity C2 and appears, for the second client entity C2, identical to the method of the prior art. What differs from the prior art in the second part 12B of step 12 is that the address of the file F included in the file distribution request is the address of the file F in the second system B. The file distribution request transmitted by the first gateway GW1 includes the fourth address URLG2 because it is this address that the first gateway GW1 knows for the file F in the second system B and because the file distribution request makes it possible to inform the second system B of the availability and location of the file F.

The second gateway GW2, receiving this request, converts the fourth URLG2 address into the third URL2 address from the correspondence between the fourth URLG2 address and the third URL2 address that it stores, then transmits the request for file distribution to the second client entity C2 via the second management server S2 and the second content server SC2.

The second client entity C2 then optionally issues an alert Al, informing a user of the second client entity C2 that the file F is available, as in the prior art, for example on a screen of the second client entity C2.

The second client entity C2 then carries out a step 13 of response to the first client entity C1, the response comprising an acceptance or refusal of access to the file F by the second client entity C2. This step 13 is identical to step 13 of response to the state of the art.

The second client entity C2 then carries out a step 14 of transmitting a request to download the file F to the second content server SC2. This request is the same “MCData download data request” request as defined by the 3GPP MCS standard as the request in step 14 of the state of the art. The difference with the state of the art is that the request to download the file F includes the third address URL2, instead of an address constructed from and entirely containing the first address URL1.

[0069] Unlike the state of the art, the second content server SC2 can directly process the request to download the file F because the second content server SC2 stores the file F at the third address URL2 included in the request in downloading the file F issued by the second client entity C2. The second content server SC2 then directly sends the file F which it stores to the third address URL2. Thus, exchanges between interconnected systems are limited, limiting security risks. The second client entity C2 has no knowledge of the second address URLG1 nor the first address URL1, and the second client entity C2 and its user therefore have no information on the first system A interconnected with the second system B.

[0070] In step 14, the second client entity C2 then receives the file F. The file distribution method 2 may include an additional step 15 in which the second client entity C2 provides a download report to the first client entity CL

[0071] The file distribution method 2 according to a first “PUSH” embodiment of the invention thus makes it possible to limit security risks while being transparent for the first client entity C1 and second client entity C2. In addition, the file distribution method 2 makes it possible to distribute the file to an external system interconnected to the system which stores the file F originally, and makes it possible to set up, in the interconnected external system, the same security of addressing for access to the file stored in the external interconnected system after its distribution. Thus, the two interconnected systems are not subject to the state-of-the-art security risk.

[0072] [Fig. 10] shows a schematic representation of an F file deletion method, in which the F file has been distributed according to the file distribution method 2 in the first “PUSH” embodiment according to the invention.

[0073] In a first step 16, the first client entity Cl wishes to delete the file F included in the first content server SCI and in any content server of other interconnected systems which would store this file F following the implementation of the file distribution method 2 in the first “PUSH” embodiment. the first client entity Cl therefore sends a request to delete the file F including the only address of the file F that it knows, that is to say the first address URL1. This request is received by the content server SCI, which then deletes the file F located at the first address URL1, in step 17.

[0074] This deletion request is transmitted by the content server SCI to the first gateway GW1, which then carries out, in a step 41, a conversion of the first address URL1 into the second address URLG1, from the correspondence between the first address URL1 and the second address URLG1 stored by the first gateway GW1. This correspondence stored by the first gateway GW 1 is then deleted, in step 42, by the first gateway GW1.

[0075] The first gateway GW 1 then modifies, in the request to delete the file F, the first address URL1 into the fourth address URLG2. This modification is made from:

• the conversion step, which transformed the first URL1 address into a second URLG1 address, • the storage information of the file F by the second content server SC2 at the fourth URLG2 address, allowing the first gateway GW1 to know that the file F is stored by the second content server SC2, • and the correspondence between the fourth address URLG2 and the second address URLG1 stored by the first gateway GW1, because the first gateway GW 1 knows that the file F to be deleted is in the second system B and that the second system B includes the second gateway GW2 at the fourth address URLG2.

The request for deletion of the file F is then transmitted to each interconnected system storing the file F of which the first gateway GW 1 is aware, that is to say in this example the second system B. The request is therefore transmitted to the second gateway GW2 in a step 18, the request for deletion of the file F comprising the fourth address URLG2.

[0077] The second gateway GW2, upon receipt of this request, modifies, in step 44, in the request, the fourth URLG2 address into the third URL2 address based on the correspondence between the fourth URLG2 address and the third third address URL2 address that it stores. This correspondence is then deleted by the second gateway GW2 in step 45.

[0078] The second gateway GW2 transmits the request for deletion of the file F to the second content server SC2 via the second management server S2, that is to say the request for deletion of the file F is transmitted to the second server of management S2 which in turn transmits it to the second content server SC2.

[0079] Upon receipt of this request, the second management server S2 deletes the correspondence between the second address URLG1 and the third address URL2 that it stores (not shown).

[0080] Upon receipt of this request, in step 19, the second content server SC2 deletes the file F that it stores.

[0081] The deletion method according to the first “PUSH” embodiment may include an alert Al to the user of the second client entity C2 to inform him that the file F has been deleted. Optionally, information that the deletion has been carried out is then sent by the content server SC2 to the content server SCI then to the Cl in a step 20.

[0082] Thanks to the deletion method according to the first “PUSH” embodiment, all correspondences stored by entities of the network R dealing with addresses linked to the file F are deleted. Likewise, the file F is deleted from the first system A and any copy of the file F on any systems included in the network R is deleted. The delete request never makes the address of the file in one system appear to another interconnected system, thereby solving the security problems of the prior art.

[0083] Second embodiment: “PULL” mode

[0084] The file distribution method according to a second embodiment of the invention called “PULL” will now be described. Method 3 according to the second embodiment of the invention is shown in Figures 8 and 9.

[0085] [Fig.8] represents the exchanges between the different entities involved in the file distribution process 3, and [Fig.9] represents the file distribution process 3.

[0086] The file distribution method 3 comprises steps 11 to 15 of the file distribution method 1a of the state of the art, some of which take into account a different file address compared to the prior art, and includes additional steps.

[0087] The file distribution method 3 comprises the first step 11 of loading the file F on the first content server SCI, as described in the technical specification 3GPP TS 23.282 (MCData Stage 2) Revision 17 Section 7.5.2.2. This first step may be optional, because the F file may already be on the first SCI content server.

The file distribution method 2 comprises the second step 12 divided into a first part 12A and a second part 12B. The first part 12A comprises the transmission of a request for distribution of the file F from the first client entity Cl to the first gateway GW 1 via the first content server SCI and the first management server SL The request for distribution of the file includes a first URL1 address. The address URL1 is preferably of type URL (for “Uniform Resource Locator”) and is associated with the file F in the first system A, that is to say it indicates where the file F is stored in the first system A. As in the prior art, the first SI management server optionally performs an Aut step of authorizing the request and checking the availability of the file F at the first address URL1 included in the request. The request is then transmitted to the first gateway GW 1 by the first management server SL

[0089] The first gateway GW1 then implements a step 31 of modification, by the first gateway GW1, in the file distribution request, of the first address URL1 associated with the file F in the first system A, into a second address URLG1 associated with file F in the first system A. The second URLG1 address is specific to the first gateway GW1, that is to say it designates a storage location of the first gateway GW 1 and/or a path leading to the first gateway GW1. At the same time, the first gateway GW1 stores a correspondence between the first URL1 address and the second URLG1 address.

[0090] In the second “PULL” embodiment, unlike the first “PUSH” mode, the first gateway GW1 does not recover the file F at this stage of the process. In a variant of the second "PULL" embodiment, the first gateway GW1 can request access to the file F from the first content server SCI and temporarily store the file F while awaiting a download request from a client entity of a system interconnected with the first system A.

[0091] As in the prior art, the first gateway GW1 then transmits a file distribution request in a second part of step 12 called 12B to the second client entity C2. Thus, the file distribution method file distribution method 2 is transparent for the second client entity C2 and appears, for the second client entity C2, identical to the method of the prior art. What differs from the prior art in the second part 12B of step 12 is that the address of the file F included in the file distribution request is the address of the first gateway GW1, because the distribution request of the file file makes it possible to inform the second system B of the availability and location of the file F, and because the first address URL1 has been hidden by the first gateway GW1.

The second gateway GW2, receiving this request, transmits it to the second client entity C2 via the second management server S2 and the second content server SC2.

The second management server S2 receiving this request creates a third URL2 address associated with the file F in the second system B in step 32 and creates and stores a correspondence between the second URLG1 address and a third URL2 address. The third URL2 address is specific to the second content server SC2, that is to say it designates a storage location of the second content server SC2 and/or a path leading to the second content server SC2. The second management server S2 modifies the second address URLG1 into the third address URL2 in the file distribution request F and transmits it to the second client entity C2.

[0094] The second client entity C2, receiving this request comprising the third address URL2 then optionally issues an alert Al, informing a user of the second client entity C2 that the file F is available, as in the prior art, for example on a screen of the second client entity C2.

The second client entity C2 then carries out a step 13 of response to the first client entity C1, the response comprising an acceptance or refusal of access to the file F by the second client entity C2. This step 13 is identical to step 13 of response to the state of the art.

The second client entity C2 then carries out a step 14 of transmitting a request to download the file F to the second content server SC2. This request is the same “MCData download data request” request as defined by the 3GPP MCS standard as the request in step 14 of the state of the art. The difference with the state of the art is that the request to download the file F includes the third URL2 address, instead of the first URL1 address.

Unlike the first “PUSH” embodiment, in the second “PULL” embodiment the second content server SC2 does not store the file F at the third address third address URL2, and therefore transmits the request to the destination of the first system A. Before that, the second content server SC2 modifies the third URL2 address into the second URLG1 address in the request, thanks to the correspondence between the third URL2 address and the second URLG1 address stored by the second management server S2.

[0098] The request is transmitted by the second content server SC2 to the first content server SCI via the second management server S2, via the second gateway GW2, via the first gateway GW1 and via the first management server SL

[0099] The first gateway GW 1 receiving this request modifies the second address

URLG1 to first URL1 address thanks to the correspondence between the second URLG1 address and the first URL1 address that it stores. The first gateway GW 1 then transmits this request to the first content server SCI, which stores the file F.

[0100] The first SCI content server storing this file F accesses it by following the first address URL1.

[0101] The first content server SCI transmits the file F to the second client entity C2. For this, the F file is sent with a response to the request to download the F file.

[0102] The file F is transmitted via the first gateway GW1, which can temporarily store the file F. The second address URLG1 is then the address allowing access to the file F by an external system interconnected with the first system A.

[0103] Still in step 14, the second client entity C2 then receives the file F, which has passed via the second gateway GW2 and the second content server SC2. The file distribution method 3 may include an additional step 15 in which the second client entity C2 provides a download report to the first client entity CL

[0104] The file distribution method 3 according to a second “PULL” embodiment of the invention thus makes it possible to limit security risks while being transparent for the first client entity C1 and second client entity C2. In addition, the file distribution method 3 makes it possible to only keep the file F on servers within the first system A, unlike the first “PUSH” embodiment.

[0105] [Fig. 11] shows a schematic representation of an F file deletion method, in which the F file has been distributed according to the file distribution method 3 in the second “PULL” embodiment according to the invention.

[0106] In a first step 16, the first client entity Cl wishes to delete the file F included in the first content server SCI and the address correspondences stored in any server of other interconnected systems following the implementation of the method file distribution 3 in the second “PULL” embodiment. The first client entity Cl therefore sends a request to delete the file F including the only address of the file F that it knows, that is to say the first address URL1. This request is received by the content server SCI, which then deletes the file F located at the first address URL1, in step 17.

[0107] This deletion request is transmitted by the content server SCI to the first gateway GW1, which then carries out, in a step 41, a conversion of the first address URL1 into the second address URLG1, from the correspondence between the first address URL1 and the second address URLG1 stored by the first gateway GW1. This correspondence stored by the first gateway GW 1 is then deleted, in step 42, by the first gateway GW1.

[0108] The first gateway GW1 then modifies, in the request to delete the file F, the first URL1 address into the second URLGL address. This modification is carried out from the conversion step, which transformed the first URL1 address into the second address second URLGL address

[0109] The request for deletion of the file F is then transmitted to each interconnected system having implemented method 3 of which the first gateway GW 1 is aware, that is to say in this example the second system B. The request is therefore transmitted to the second gateway GW2 in a step 18, the request for deletion of the file F comprising the second address URLGL

[0110] The second gateway GW2, upon receipt of this request, transmits the request to delete the file F to the second content server SC2 via the second management server S2, that is to say the request to delete the file F is transmitted to the second management server S2 which in turn transmits it to the second content server SC2.

[0111] Upon receipt of this request, in a step 43, the second management server S2 deletes the correspondence between the second address URLG1 and the third address URL2 that it stores.

[0112] The deletion method according to the second “PULL” embodiment may include an alert Al to the user of the second client entity C2 to inform him that the file F has been deleted. Optionally, information that the deletion has been carried out is then sent by the content server SC2 to the content server SCI then to the Cl in a step 20.

[0113] Thanks to the deletion method according to the second “PULL” embodiment, all correspondences stored by entities of the network R dealing with addresses linked to the file F are deleted. Similarly, file F is deleted from the first system A and any copy of file F on any system included in network R is deleted. The delete request never makes the address of the file in one system appear to another interconnected system, thereby solving the security problems of the prior art.