EP3949458A1 - Transmission de messages dans un contexte multi-terminaux - Google Patents

Transmission de messages dans un contexte multi-terminaux

Info

Publication number
EP3949458A1
EP3949458A1 EP20713922.1A EP20713922A EP3949458A1 EP 3949458 A1 EP3949458 A1 EP 3949458A1 EP 20713922 A EP20713922 A EP 20713922A EP 3949458 A1 EP3949458 A1 EP 3949458A1
Authority
EP
European Patent Office
Prior art keywords
message
terminal
sms1
synchronization
intended
Prior art date
Legal status (The legal status 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 status listed.)
Pending
Application number
EP20713922.1A
Other languages
German (de)
English (en)
Inventor
Vladimir RENARD
Christophe Suart
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
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 SA filed Critical Orange SA
Publication of EP3949458A1 publication Critical patent/EP3949458A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/12—Messaging; Mailboxes; Announcements
    • H04W4/14—Short messaging services, e.g. short message services [SMS] or unstructured supplementary service data [USSD]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/74—Address processing for routing
    • H04L45/742—Route cache; Operation thereof
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/58—Message adaptation for wireless communication

Definitions

  • the present invention relates to the transmission of messages in a multi-terminal context, and in particular to the sending of an SMS type message in such a context.
  • the SMS messaging system (for "Short Message Service” in English) was developed years ago, to allow the sending of short text messages between mobile terminals, by means of signaling messages used in the networks of second generation mobile communications at the time. This system was standardized through the 3GPP TS 23.240 and TS 23.040 standards and has met with immense success to the point that it is still widely used today.
  • SMS messaging system as standardized was designed from its outset for cases of message transmission from a single sending mobile terminal to a single receiving mobile terminal.
  • This common identifier can be the phone number natively linked to one of the system's terminals.
  • This common identifier can also be a number not linked natively to one of the terminals of the system, such a number can then be called an “extra-number”, or even “virtual number” (“Virtual number”). number ”in English), which is typically a new number assigned by the operator, not linked to a SIM card or to a particular terminal.
  • This common identifier can be used by a user, with any of the terminals of the system, to call or receive a telephone call either from one of these terminals by means of this identifier.
  • the SMS messaging system described above is not completely compatible with this type of "multi-terminal" systems.
  • each mobile terminal of the multi-terminal system behaves completely independently from the other terminals of this system, without taking into account the existence of other mobile terminals which are nevertheless associated with it with the common identifier within the multi-terminal system.
  • Patent application EP 1 613 102 A1 describes a system for controlling the delivery of short messages, in which it is possible to program so flexible, by means of instructions stored in a database of a network entity, the redirection, copy or distribution of short messages sent by a source terminal which would be received by this network entity.
  • the distribution of short messages to a plurality of recipient terminals is based on the use of distinct MSISDN identifiers for each recipient terminal, in order to be able to address the short message to be distributed to each of these terminals.
  • recipients using a conventional messaging network architecture proves to be incompatible with the sending of messages to a “multi-terminal” system as described above, since the terminals of such a “multi-terminal” system share the same common identifier while the control of this patent application EP 1 613 102 A1 requires separate identifiers for each terminal to which to distribute a short message.
  • the patent application FR 3 053 560 A1 for its part describes a message redirection system resulting from the modification of a conventional SMS messaging system, in which a database is added making it possible to redirect a message intended for a first phone line to a separate second phone line and, if this redirection fails, then redirect this message to the first phone line.
  • the present invention therefore overcomes these drawbacks.
  • source terminal comprising the steps of transmitting, from the source terminal to a synchronization server, a first synchronization message in which is inserted the message intended for the destination terminal and of retrieving, by said at least one associated terminal, the intended message at the destination terminal B to the synchronization server by means of at least one second synchronization message.
  • this method further comprises the transmission, from the source terminal to a routing gateway, of the message intended for the destination terminal, so that said routing gateway can retransmit said message in the signaling plane to the terminal. recipient.
  • this method further comprising the transmission, from the synchronization server to a network node, responsible for storing and forwarding the message, of the message intended for the destination terminal , so that said network node can retransmit said message to the destination terminal.
  • the method further comprises a step of determining, by the synchronization server, the transmission of the message from the source terminal to a routing gateway, the transmission of the message from the synchronization to the network node only takes place if the result of this determination is positive.
  • This determination step can in particular be carried out by means of the detection of an indicator for activating the transmission of the message from the source terminal to a routing gateway, inserted in the first synchronization message.
  • the method further comprises the storage, by the synchronization server, of the message intended for the destination terminal, extracted from the first synchronization message, in order to allow the recovery by said at least one associated terminal of the. message intended for the destination terminal.
  • the message intended for the recipient terminal is a message in SMS format.
  • the first and / or the second synchronization message is a message conforming to a protocol among the IMAP, J MAP, OMA DS or OMA NMS protocols.
  • a synchronization server comprising a communication module capable of exchanging synchronization messages with a first terminal, said source terminal, and at least one second terminal, said associated terminal, sharing the same identifier with the source terminal, and a processing module configured to extract a message intended for a third terminal, called a terminal recipient, of a first synchronization message received by the communication module and to insert said message in a second synchronization message to be transmitted to said at least one associated terminal.
  • the processing module is further configured to transmit the extracted message to a network node responsible for storing and retransmitting messages, so that said network node can retransmit said message to the destination terminal.
  • a terminal comprising a communication module and a processing module, the processing module being configured to insert a message intended for another terminal, called the destination terminal, in a synchronization message and the communication module being configured to. send said synchronization message to a synchronization server, so that at least one other terminal, said associated terminal, can retrieve the message intended for the destination terminal from said synchronization server.
  • the processing module is further configured to instruct the communication module to transmit the message to a routing gateway allowing its retransmission in the signaling plane to the destination terminal.
  • a system is also proposed for the transmission of a message intended for a first terminal, said destination terminal, from a second terminal, said source terminal, to at least a third terminal, said associated terminal, sharing the same identifier with the terminal.
  • source comprising a synchronization server as described above and said at least one associated terminal, configured to retrieve the message from the synchronization server by means of a synchronization message.
  • this system further comprises a source terminal, this source terminal being a terminal as presented above.
  • FIG. 1 schematically shows the architecture provided for the transmission of SMS message, as currently standardized
  • FIG. 2 represents an embodiment of the message transmission method according to the present invention
  • FIG. 4 illustrates a terminal according to an embodiment of the present invention.
  • FIG. 5 illustrates a synchronization server according to an embodiment of the present invention.
  • FIG. 1 schematically illustrates the architecture currently provided for in the existing 3GPP standards, to allow the transmission of SMS messages from a sending mobile terminal UE-A to a receiving mobile terminal UE-B .
  • the mobile terminal UE-A formats the message to be transmitted, typically a series of alphanumeric characters entered by the user of this mobile terminal by means of the user interface of this terminal, according to the SMS format.
  • the mobile terminal UE-A is provided with a message formatting module, also called “messaging client” in English, such a module being native, that is to say integrated into the mobile terminal UE. -A from its construction.
  • a message formatting module also called “messaging client” in English, such a module being native, that is to say integrated into the mobile terminal UE. -A from its construction.
  • the mobile terminal UE-A transmits (step A1 10) this SMS message to a routing gateway A_SMS, belonging to the network A to which the terminal UE-A is subscribed or attached, depending on the case, this gateway being specially dedicated to the retransmission of this type of message in the network, by means of a network protocol provided for such transmission between terminals and this A_SMS routing gateway.
  • This network protocol is typically a signaling protocol, that is to say a protocol relating to the transmission of signaling messages in the signaling plane.
  • this A_SMS routing gateway is implemented in the form of an MSC (for “Mobile Switching Center”) server to which the UE-A terminal directly sends the message.
  • SMS while in the case of a 4G access network, this A_SMS routing gateway is implemented in the form of an IP-SM-GW gateway, the message SMS1 then being encapsulated in a message according to the protocol of SIP signaling (for "Session Initiation Protocol” in English) transmitted to network nodes intermediaries (“P-CSCF” or “S-CSCF” nodes for example, not illustrated here) which retransmit it to this IP-SM-GW gateway.
  • SIP signaling for "Session Initiation Protocol” in English
  • This A_SMS routing gateway then retransmits this SMS message according to a MAP (for “Mobile Application Part”) or Diameter signaling protocol to a network node of the SMSC type, for “Short Message Service Center” in English (sub-step A1 12), so that this SMSC network node memorizes (substep A1 13) this SMS message with a view to its subsequent retransmission to the network B to which the destination terminal is attached.
  • An acknowledgment of good reception can then also be transmitted, from the SMSC node to the UE-A terminal at this stage (step A11 1).
  • the SMSC attempts to transmit (substep A1 14) immediately the SMS message to a routing gateway B_SMS of this network B, by means of the MAP signaling protocol.
  • this B_SMS routing gateway is implemented in the form of an MSC network node (for “Mobile Switching Center” in English) while in the case of a network 4G access, this B_SMS routing gateway is implemented in the form of an IP-SM-GW gateway.
  • the B_SMS gateway extracts the SMS from this signaling message and transmits it (step A1 15) to the UE-B terminal using a protocol of type NAS ("Non Access Stratum").
  • NAS Non Access Stratum
  • the B_SMS gateway transmits the SMS1 message to the UE-B terminal by encapsulating it in a message according to the SIP protocol.
  • the other terminals which could be associated with the UE-A terminal within a “multi-terminal” system cannot be informed of the sending, by the UE-A terminal, of a message. SMS type to the UE-B terminal.
  • FIG. 2 illustrates a message transmission method according to a first embodiment of the present invention.
  • a first terminal 10 wishes to send a message to a second terminal 20, called destination terminal thereafter.
  • the terminals 10 and 20 can in particular be mobile terminals, for example of the smartphone type.
  • the message in question is illustrated here as being an SMS1 message, formatted according to the SMS format, without the invention being limited to this single message format, the latter being able to be applied to any type of message to be transmitted between terminals. .
  • the terminal 10 is associated with at least one other terminal, called an associated terminal, in the context of a communication context called "multi-terminal context".
  • an associated terminal in the context of a communication context called "multi-terminal context”.
  • it may be a mobile terminal, for example of the smartphone type.
  • the various associated terminals share the same identifier, also called a common identifier, which can typically be the same telephone number (ie the same MSISDN identifier of one of the associated terminals), or also be a number not linked natively to one of the terminals of the system, of the “extra-number” or “Virtual number” type previously discussed, which is typically a new number assigned by the operator, not linked to a SIM card or to a particular terminal , so that the other terminals called by (or recipients of a message coming from) one of the associated terminals see only one and the same identifier, independently of the associated terminal which is actually used.
  • a common identifier can typically be the same telephone number (ie the same MSISDN identifier of one of the associated terminals), or also be a number not linked natively to one of the terminals of the system, of the “extra-number” or “Virtual number” type previously discussed, which is typically a new number assigned by the operator, not linked to a SIM card or to a
  • FIG. 2 illustrates the case of a multi-terminal system with three associated terminals, in which two other associated terminals 10 'and 10 ”are associated with the source terminal 10, and therefore share the same identifier with it.
  • MSISDN- IO in this case the identifier of the source terminal 10
  • N a number of terminals which can be associated with the destination terminal 10 within such a system.
  • the associated terminals within a multi-terminal system can be in particular mobile terminals (smartphones, connected watches, tablets, among others), but also other less mobile types of terminals, such as voice assistants, or connected refrigerators, that is to say any terminal connected to the network and capable of sending and receiving messages, possibly by displaying them or by vocalizing them.
  • this embodiment involves a synchronization server 30, with which the terminal mobile source 10 and the associated terminals 10 'and 10 "exchange synchronization messages, here designated" SYNC ".
  • client synchronization modules are installed in the associated terminals 10, 10 'and 10 ”while a synchronization server module is installed in the synchronization server, these modules being synchronized so that the client modules are notified of changes in the content of the server module of the synchronization server, either in real time as soon as such a change takes place, or in a deferred manner when one of the client modules interrogates the server module in order to know the changes that have taken place since the last connection of the client terminal to the server.
  • Such SYNC synchronization messages conform to a synchronization protocol suitable for use between a client module and a server module, which can be the IMAP (for “Interactive Message Access Protocol”), JMAP (for the implementation) protocol. Java of IMAP protocol), OMA DS (Data Sync) or OMA NMS (Network Message Storage), for example.
  • the terminals 10, 10 'and 10 synchronize with the synchronization server by exchanging synchronization messages in accordance with a synchronization protocol such as one of the aforementioned protocols, cited by way of example. synchronization protocol.
  • the terminals 10 ′ and 10 ′′ associated with the source terminal 10 register with the synchronization server 30, in order to subsequently benefit from the synchronization service managed by this server.
  • the synchronization server 30 has the information making it possible to establish the link between all the associated terminals, typically an identifier common to all these terminals such as an identifier MSISDN10 of the source terminal 10, or even an additional number of the type “Extra-number”, ie a new number, supplied by the operator, not linked to a SIM card or to a particular terminal.
  • the terminal 10 When an SMS1 message (here a message in the SMS format) is to be transmitted from the source terminal 10 to a destination terminal 20, the terminal 10 firstly transmits the SMS1 message to the terminal 20 in the manner illustrated. previously in FIG. 1, using steps A110 to A115 described previously in relation with this FIG. 1.
  • the terminal 10 inserts (step S120) this message SMS1 in a message of SYNC synchronization in accordance with the synchronization protocol used by the synchronization server 30.
  • this SYNC message can be an HTTP POST type request with a Mime Text / plain type structure in which the SMS1 message is inserted, as shown below:
  • the server 30 can transmit to the terminal 10 a unique identifier, assigned by the server 30 to the message SMS1, inserted in an XML or JSON structure for example.
  • the resulting synchronization message SYNC [SMS1] is transmitted by the source terminal 10 to the synchronization server 30 (step S130), in the data transport plane.
  • step A1 10 of transmitting the message SMS1 directly to the terminal 20 on the one hand, and steps S120 and S130 of inserting and sending the synchronization message containing the message SMS1 to the synchronization server On the other hand, can be carried out in parallel, i.e. simultaneously or in any order with respect to each other.
  • SMS1 SYNC synchronization message [SMS1]
  • SMS1 message that it contains can be extracted and stored by this synchronization server 30 (step S140), or even within a memory of this server, or in a database associated with this server.
  • the associated terminals 10 ′ and 10 respectively retrieve the SMS1 message intended for the destination terminal 10 by means of synchronization messages which they exchange respectively with the synchronization server 30.
  • the synchronization server 30 recovers the message SMS1 intended for the destination terminal 20 by means of a synchronization message SYNC' [SMS1] that it transmits to this terminal 10 (step S150 '). It makes same for all the other associated terminals, in this case here for the terminal 10 ”(step S150”) to which it sends a synchronization message SYNC ”[SMS1] in which it has inserted the message SMS1.
  • the synchronization messages (here SYNC ’[SMS1] and SYNC” [SMS1]) are generated according to separate procedures, which can however use the same synchronization mechanisms and protocols. Alternatively, these synchronization messages can use different synchronization protocols.
  • synchronization messages can be implemented in the form of a message containing an attribute in which the SMS1 message is inserted. It may in particular be a message of the “pager-messenger” type according to the REST NMS interface, containing an object of the so-called “inline” SMS type, in which the SMS1 message can be directly inserted in a “textContent” attribute. , as illustrated by the example below:
  • These synchronization messages can also be implemented in the form of a message with a “payload” field containing an address allowing the subsequent downloading of the SMS1 message (by GET request for example).
  • it may be a “pager-messenger” type message according to the NMS REST interface, as illustrated by the example below:
  • These synchronization messages can also be implemented in the form of a notification from the synchronization server, containing in its subject a URL making it possible to directly download an “SMS1 message” object, as illustrated by the example below, where the element "Oldl OOO" at the end of the URL represents a unique identifier for this message:
  • Each associated terminal can then, after having received such a synchronization message, retrieve the SMS1 message intended for the destination terminal 20, either by extracting it from the synchronization message when it is inserted therein, or by downloading this SMS1 message from an address indicated in this message from synchronization.
  • the associated terminals 10 ′ and 10 ′′ can then store this SMS1 message in their own memories, for consultation or subsequent reproduction by a user.
  • all the terminals associated with the source terminal have the SMS1 message sent by the source terminal, as well as the information associated with this message, such as the time of sending of the message, the place of sending. message, read or reply status of the message, etc.
  • the user of a multi-terminal system therefore has access to the same message sending history, regardless of the terminal through which he accesses it.
  • the method illustrated in FIG. 2 can be triggered for all the messages using as the original identifier a common identifier potentially used on other terminals, entered by a user on the source terminal 10.
  • the source terminal 10 can include a synchronization message formatting module, configured to receive as input all the messages to be transmitted using an identifier common to several terminals and to insert them into synchronization messages to be transmitted to the synchronization server 30.
  • this synchronization message formatting module operates in parallel with the native message formatting module to be transmitted, so as to transmit in parallel both the message intended for the recipient terminal according to a conventional scheme (steps A1 10 to A1 15) than a synchronization message containing this message to the synchronization server 30 (step S130).
  • the message remains transmitted to the destination terminal by means of signaling messages, therefore in the signaling plane, while copies of this message are transmitted to the terminals associated with the source terminal, in the data transport plan.
  • This makes it possible to guarantee a certain speed of transmission to the destination terminal, while saving resources of the signaling plane with regard to the copies transmitted to the associated terminals, for which the transmission time is less critical than for the destination terminal.
  • this synchronization message formatting module is placed at the output of the native message formatting module to be transmitted, so as to intercept the messages at the output of the latter.
  • a message intended for the destination terminal 20 is not sent as is, according to the conventional scheme (ie to a routing gateway of the network).
  • only a synchronization message containing this message is sent, to the synchronization server 30.
  • FIG. 3 illustrates a message transmission method according to a second embodiment of the present invention.
  • This other embodiment differs from the previous one in that the direct transmission of the message SMS1, from the terminal 10 to the terminal 20 in the single signaling plane, is inhibited, the message SMS1 then being transmitted by means of a synchronization message, to the less in part in the data transport plan, just as for the terminals associated with terminal 10.
  • an SMS1 message (here again a message in the SMS format) is to be transmitted from the source terminal 10 to a destination terminal 20, the terminal 10 does not carry out the transmission. transmission of this SMS1 message to the terminal 20 in the manner previously illustrated in FIG. 1, and therefore does not use steps A1 10 to A115 described previously in relation to this FIG. 1. This traditional transmission is here inhibited at the level of the terminal 10.
  • the method according to the present embodiment begins with step S120 of inserting the message SMS1 into a synchronization message SYNC [SMS1], followed by step S130 of transmitting this synchronization message to the synchronization server 30 and step S140 of storing this message SMS1, after its possible extraction from the synchronization message, by the synchronization server 30, as described previously in relation to FIG. 2.
  • the associated terminals 10 'and 10 can retrieve the message SMS1 intended for the destination terminal 20, by means of synchronization messages which they exchange respectively with the synchronization server 30, during respective steps S150' and S150 ”As previously described in relation to figure 2.
  • the synchronization server 30 can also at this stage transmit the message SMS1, which it has extracted from the synchronization message SYNC [SMS1] received from the terminal 10, to the network node 40 responsible for storing and retransmit the messages between mobile terminals, in this case the SMSC center in the case of SMS messages (step S142), for example by means of the MAP signaling protocol used for example by the IP-SM-GW gateways to transmit the SMS messages to such a network node 40. Any other IP protocol of synchronization, or even an API, can be used alternatively.
  • step A113 This allows the network node 40 to temporarily store this SMS1 message (step A113) before retransmitting it (step A1 14) to a gateway for routing B_SMS such messages (an IP-SM-GW gateway in the case of a network 4G access or an MSC server in the case of a 2G or 3G access network), located in the network B to which the destination terminal 20 is subscribed / attached, so that it retransmits (step A1 15) the message to the destination terminal 20.
  • B_SMS such messages
  • steps A1 13 to A1 15 are similar to those already described in relation to Figures 1 and 2.
  • steps S142, A1 13, A114 and A1 15 on the one hand, allowing the transmission of the message SMS1 from the synchronization server to the terminal 20, and the steps S140, S150 'and S150 ”, allowing the recovery of this SMS1 message by the terminals associated with the source terminal, can be performed in parallel, that is to say simultaneously or in any order with respect to each other.
  • all the terminals associated with the source terminal have the SMS1 message sent by the source terminal, as well as the information associated with this message, such as the time of sending of the message, the place of sending. message, etc.
  • the user of a multi-terminal system therefore has access to the same message sending history, regardless of the terminal he is accessing.
  • the source terminal 10 can include a synchronization message formatting module, configured to receive as input all the messages to be transmitted using an identifier potentially common to several terminals and to insert them into synchronization messages to be transmitted to the synchronization server 30.
  • this synchronization message formatting module can be placed at the output of the native message formatting module to be transmitted, so as to intercept the messages at the output of the latter.
  • a message intended for the destination terminal 20 is not sent as it is, according to the conventional scheme (ie to a routing gateway of the network).
  • only a synchronization message containing this message is sent, to the synchronization server 30, during step S130.
  • the messages to be transmitted are therefore transmitted almost entirely in the data transport plane, which has the advantage of saving even more the resources of the signaling plane of the network, so that they can be allocated to other services.
  • the use of the only data transport plan, for the transmission of such messages from or to the terminals, may turn out to be slower than the use of the signaling plan, but this inconvenience may turn out to be minor compared to the gain. obtained in terms of saving signaling plane resources, especially if we consider that there is no real need to transmit such messages in real time and that a slight latency is then tolerable .
  • the source terminal 10 and the synchronization server 30 can be configured to implement only the first or the second embodiment.
  • the terminal 10 can be natively configured (or configured by software update) to synchronize with the synchronization server (step S120) in addition to the transmission. of the message SMS1 to the routing gateway 50 (step A1 10).
  • the synchronization server 30 can be configured to synchronize with the associated terminals (steps S150 ’and S150”), without sending a signaling message including the message SMS1 to the network node 40.
  • the terminal 10 can be natively configured (or configured by software update) to synchronize with the synchronization server (step S120) without however sending the message SMS1 to the routing gateway 50.
  • the synchronization server 30 can then be configured for, in addition to the fact to synchronize with the associated terminals (steps S150 ′ and S150 ′′), also send a signaling message including the message SMS1 to the network node 40 (S142), in order to allow this message to reach the destination terminal 20.
  • the synchronization server 30 can be configured to synchronize with the associated terminals (steps S150 ’and S150”), without sending a message including the message SMS1 to the network node 40.
  • both the terminal 10 and the synchronization server 30 can implement the first or the second embodiment of the method described above.
  • the terminal 10 is then configured natively (or configured by software update) to synchronize with the synchronization server (step S120) and, moreover, to be able to activate or deactivate the transmission of the message SMS1 to the routing gateway 50 in the signaling plane (step A1 10).
  • This activation or deactivation can be instructed by the user of the terminal, by means of a command entered via the user interface or a configuration menu of the terminal 10, or else remotely by a command message transmitted from the network. communication, for example by the operator of this network.
  • this module can be configured to receive such a command to activate, or deactivate, this type of transmission (step A1 10) and activate, or deactivate, this transmission according to this command.
  • the synchronization server 30 is then, for its part, configured to synchronize with the associated terminals (steps S150 ′ and S150 ′′) and, in addition, to be able to activate or deactivate the transmission of a signaling message including the message. SMS1 to the network node 40 (step S142).
  • This activation or deactivation can be instructed by an operator of the server, by means of a command entered via a user interface or from a configuration menu of this server 30, or else remotely by a command message transmitted from the network of communication, for example by the operator of this network.
  • the method can advantageously comprise a step of determining (not illustrated), by the synchronization server 30, of the transmission (step A110) of the SMS1 message from the source terminal 10 to a routing gateway 50.
  • the transmission (step S142) of the message SMS1 from the synchronization server 30 to the network node 50 then takes place only if the result of this determination is positive.
  • This determination can be made by means of the detection of an activation or deactivation indicator of step A1 10, inserted in the SYNC synchronization message [SMS1] that the terminal 10 transmits to the server 30.
  • the terminal 10 when the transmission (step A1 10) of the SMS1 message is activated on the terminal 10 side, the terminal 10 inserts an indicator signaling this activation in the SYNC message [SMS1] sent to the server 30.
  • this server 30 receives this SYNC message [SMS1] and detects this indicator therein, it then deactivates the transmission (step S142) of the message SMS1 to the network node 40, which would be redundant.
  • the terminal 10 inserts an indicator signaling this deactivation in the SYNC message [SMS1] sent to the server 30.
  • this server 30 When this server 30 receives this SYNC message [ SMS1] and detects this indicator there, it then activates the transmission (step S142) of the message SMS1 to the network node 40, in order to trigger the retransmission of this message SMS1 to the terminal 20.
  • FIG. 4 illustrating a terminal according to an embodiment of the present invention.
  • the terminal 10 (which can be a mobile terminal, such as for example a smartphone) comprises in particular a user interface module 11, allowing a user to enter a message, called “raw message”, to be transmitted to a recipient mobile terminal.
  • this user interface module being able to take the form of a keyboard or of a touch screen making it possible to enter alphanumeric characters, or even of a voice recognition interface allowing such an input.
  • the terminal 10 also comprises a processing module 13 configured to receive, as input, the raw message entered by a user and to format it in the form of a message which can be transmitted over the communication network to which the terminal is attached.
  • the processing module 13 comprises a native message formatting module 13i to be transmitted, configured to encapsulate the raw message entered by the user in a formatted message allowing its transmission over the network, typically an SMS formatting module delivering , on output, SMS messages to be transmitted to the network.
  • this native 13i module can be configured to receive an instruction to inhibit direct transmission of messages to the network, in particular when it is desired to implement the method as illustrated in FIG. 3.
  • Such a processing module is typically implemented in the form one or more processors executing code instructions of a computer program, associated with a random access memory and / or a read only memory in which these code instructions are stored.
  • the terminal 10 further comprises a storage module 15 in which is stored, among other things, an identifier of the terminal 10, typically but not exclusively a telephone number assigned to the terminal, here MSISDN 10 .
  • This storage module 15 can also store an identifier common to the multi-terminal system to which the terminal 10 belongs, or a virtual identifier, which can then be used to indicate that the messages transmitted by this terminal are to be broadcast to the terminals associated with this. terminal in such a system.
  • This storage module can be implemented in the form of a removable SIM card, or else of an eSIM card integrated into the terminal 10.
  • the native module 13i accesses this module 15 to extract the identifier MSISDN10 therein in order to either l '' insert as it is as a common identifier in the formatted message that it prepares, or to use it in a request to retrieve the common identifier from a remote HLR type server when attaching to the network, before inserting this recovered identifier in the formatted message that it prepares, so that this message can identify its sender.
  • the processing module 13 further comprises a module 13 2 for formatting a synchronization message, receiving as input the message delivered by the native module 13i and inserting it into a synchronization message intended to be transmitted to a synchronization server with which the terminal 10 is registered.
  • the terminal 10 finally comprises a communication module 17, able to receive the messages prepared by the processing module 13 in order to transmit them, by radio, to the communication network to which the terminal 10 is attached.
  • a communication module can be implemented in particular in the form of one or more radio antenna (s) connected to a digital / analog converter receiving as input the messages prepared by the processing module 13, in particular the synchronization messages delivered. by module 13 2.
  • this communication module 17 can, in addition to the SYNC synchronization encapsulating messages intended for a recipient terminal, also receiving messages prepared by the native module 13i, in order to transmit them in parallel with synchronization messages containing these messages.
  • FIG. 5 illustrating a synchronization server according to an embodiment of the present invention.
  • This synchronization server 30 comprises in particular a communication module 31 (typically implemented in the form of a transceiver) configured to exchange SYNC synchronization messages with the source terminal 10, as well as SYNC 'synchronization messages with the one or more. terminals 10 ', 10 ”associated with it (only one associated terminal 10' being shown here).
  • a communication module 31 typically implemented in the form of a transceiver
  • the synchronization server 30 further comprises a processing module 33, configured first of all to process the SYNC synchronization messages received from the source terminal 10, and in particular to extract therefrom a message intended for a destination terminal 20, for example. an SMS message, when such a message has been inserted therein (this case being illustrated here in FIG. 5 by the SYNC message [SMS1]).
  • a processing module is typically implemented in the form of one or more processors executing code instructions of a computer program, associated with a random access memory and / or a ROM in which these code instructions are stored.
  • This message SMS1 once extracted from the synchronization message SYNC [SMS1], can then be stored in a storage module 35 (typically implemented in the form of a non-volatile memory), here illustrated as being included in the synchronization server 30, but can also be implemented in the form of a database separate from this server, to which this server has access to store these messages and then access them.
  • a storage module 35 typically implemented in the form of a non-volatile memory
  • the storage of this message, in the storage module 35, can be done in association with an identifier of the source terminal 10 (here, its identifier “MSISDN- IO” ) in order to facilitate its subsequent retrieval.
  • the processing module 33 can then check with the storage module 35 whether an SMS1 message associated with the unique identifier associated with it has been stored and, if this 'is the case, the module 33 can then retrieve this message in order to insert it in a synchronization message SYNC' [SMS1] that it provides to the communication 31 so that the latter transmits the synchronization message SYNC '[SMS1] to the associated terminal in question.
  • the SYNC [SMS1] and SYNC '[SMS1] messages can be sent spontaneously (that is to say without a prior request having been received to trigger the sending of this message) respectively by the source terminal 10 and the synchronization server 30, for example at regular intervals, in a “push” mode.
  • these messages can be messages sent in response to synchronization requests received respectively from the synchronization server 30 and from the source terminal 10, in a so-called “pull” mode (such requests being illustrated by “REQ SYNC” in FIG. 4).
  • SMS type messages have been discussed previously as an example of short messages that can be advantageously transmitted by virtue of the embodiments of the present invention.
  • any other type of message, more or less short can also be concerned, the invention being however particularly advantageous when the size of the message to be transmitted is less than the size of the field available for inserting it into a synchronization message between a terminal and a synchronization server, so that a single synchronization message is sufficient to transmit one (or even several) message (s), intended for a "recipient" terminal, to another terminal associated with this destination terminal.
  • the synchronization server presented above can be specific equipment, dedicated only to the synchronization of messages with terminals associated with a terminal recipient of messages, but also any network equipment having other functionalities, in which a software module of “server” type is installed to exchange the SYNC synchronization messages presented above with a “client” type software module installed in terminals associated with the destination terminal.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)

Abstract

L'invention concerne un procédé de transmission d'un message (SMS1) destiné à un premier terminal (20), dit terminal destinataire, depuis un deuxième terminal (10), dit terminal source, vers au moins un troisième terminal (10',10''), dit terminal associé, partageant un même identifiant avec le terminal source. Ce procédé comprend notamment la transmission (S130), du terminal source (10) vers un serveur de synchronisation (30), d'un premier message de synchronisation (SYNC[SMS1]) dans lequel est inséré le message destiné au terminal destinataire et la récupération (S150',S150''), par ledit au moins un terminal associé (10',10''), du message destiné au terminal destinataire auprès du serveur de synchronisation au moyen d'au moins un deuxième message de synchronisation (SYNC'[SMS1], SYNC''[SMS1]). L'invention concerne aussi un serveur de synchronisation, un terminal et un système correspondants.

Description

Transmission de messages dans un contexte multi-terminaux
La présente invention concerne la transmission de messages dans un contexte multi-terminaux, et en particulier l’envoi de message de type SMS dans un tel contexte.
Le système de messagerie SMS (pour « Short Message Service » en anglais) a été développé il y a des années de cela, pour permettre l’envoi de courts messages textuels entre terminaux mobiles, au moyen de messages de signalisation utilisés dans les réseaux de communications mobiles de deuxième génération, à l’époque. Ce système a été normalisé au travers des normes 3GPP TS 23.240 et TS 23.040 et a rencontré un immense succès au point qu’il est toujours amplement utilisé de nos jours.
Cependant, le système de messagerie SMS tel que normalisé a été conçu dès son origine pour des cas de transmission de message depuis un unique terminal mobile émetteur vers un unique terminal mobile destinataire.
Or il s’avère que des systèmes dits « multi-terminaux » ont été développés récemment, dans lesquels un ensemble de terminaux partagent un même identifiant, commun aux terminaux d’un même système. Cet identifiant commun peut être le numéro de téléphone lié nativement à l’un des terminaux du système. Cet identifiant commun peut aussi être un numéro non lié nativement à l’un des terminaux du système, un tel numéro pouvant alors être appelé « numéro supplémentaire » (« extra- number » en anglais), ou encore « numéro virtuel » (« Virtual number » en anglais), lequel est typiquement un nouveau numéro attribué par l'opérateur, non lié à une carte SIM ou à un terminal particulier. Cet identifiant commun peut être utilisé par un utilisateur, avec l’un quelconque des terminaux du système, pour appeler ou recevoir un appel téléphonique indifféremment depuis l’un de ces terminaux au moyen de cet identifiant.
Le système de messagerie SMS décrit ci-dessus ne s’avère pas complètement compatible avec ce type de systèmes « multi-terminaux ». En particulier, dans le cas de messages SMS envoyés en utilisant un identifiant pouvant être utilisé par un ensemble de terminaux mobiles associés au sein d’un système multi-terminaux, si l’on applique le système SMS tel que normalisé actuellement, chaque terminal mobile du système multi-terminaux se comporte de manière totalement indépendante des autres terminaux de ce système, sans tenir compte de l’existence des autres terminaux mobiles qui lui sont pourtant associés à l'identifiant commun au sein du système multi-terminaux.
La demande de brevet EP 1 613 102 A1 décrit un système de contrôle de livraison de messages courts, dans lequel il est possible de programmer de manière flexible, au moyen d’instructions stockées dans une base de données d’une entité réseau, la redirection, copie ou distribution de messages courts émis par un terminal source qui seraient reçus par cette entité réseau.
Cependant, la distribution de messages courts vers une pluralité de terminaux destinataires, telle qu’envisagée dans ce système, repose sur l’utilisation d’identifiants MSISDN distincts pour chaque terminal destinataire, pour pouvoir adresser le message court à distribuer vers chacun de ces terminaux destinataires en utilisant une architecture réseau conventionnelle de messagerie. Un tel système s’avère donc incompatible avec l’envoi de messages vers un système « multi-terminaux » tel que décrit précédemment, puisque les terminaux d’un tel système « multi-terminaux » partagent un même identifiant commun alors que le système de contrôle de cette demande de brevet EP 1 613 102 A1 requiert des identifiants distincts pour chaque terminal vers lequel distribuer un message court.
Le demande de brevet FR 3 053 560 A1 décrit pour sa part un système de redirection de message issu de la modification d’un système conventionnel de messagerie par SMS, dans lequel on ajoute une base de données permettant de rediriger un message destiné à une première ligne téléphonique vers une deuxième ligne téléphonique distincte et, si cette redirection échoue, de rediriger alors ce message vers la première ligne téléphonique.
Cependant, le principe de ce système repose sur la redirection d’un message vers un seul terminal à la fois, et donc n’envisage aucunement la problématique décrite précédemment liée à la transmission de messages vers les terminaux d’un système « multi-terminaux ». De plus, ici encore, chaque terminal étant nécessairement identifié par une ligne téléphonique distincte dans le système de cette demande de brevet, ce système s’avère incompatible avec l’envoi de messages vers un système « multi- terminaux » dans lequel plusieurs terminaux partagent un même identifiant commun.
La présente invention vient donc remédier à ces inconvénients.
Il est proposé à cet effet un procédé de transmission d’un message destiné à un premier terminal, dit terminal destinataire, depuis un deuxième terminal, dit terminal source, vers au moins un troisième terminal, dit terminal associé, partageant un même identifiant avec le terminal source, comprenant les étapes de transmission, du terminal source vers un serveur de synchronisation, d’un premier message de synchronisation dans lequel est inséré le message destiné au terminal destinataire et de récupération, par ledit au moins un terminal associé, du message destiné au terminal destinataire B auprès du serveur de synchronisation au moyen d’au moins un deuxième message de synchronisation.
Selon un mode de réalisation, ce procédé comprend en outre la transmission, du terminal source vers une passerelle d’acheminement, du message destiné au terminal destinataire, afin que ladite passerelle d’acheminement puisse retransmettre ledit message dans le plan de signalisation vers le terminal destinataire.
Selon un autre mode de réalisation de l’invention, pouvant être combiné au précédent, ce procédé comprenant en outre la transmission, du serveur de synchronisation vers un nœud réseau , chargé du stockage et de la retransmission de message, du message destiné au terminal destinataire, afin que ledit nœud réseau puisse retransmettre ledit message vers le terminal destinataire.
Selon un aspect avantageux de cet autre mode de réalisation, le procédé comprend en outre une étape de détermination, par le serveur de synchronisation, de l’émission du message du terminal source vers une passerelle d’acheminement, la transmission du message du serveur de synchronisation vers le nœud réseau n’ayant lieu que si le résultat de cette détermination est positif. Cette étape de détermination peut en particulier être réalisée au moyen de la détection d’un indicateur d’activation de émission du message du terminal source vers une passerelle d’acheminement, inséré dans le premier message de synchronisation.
Selon un autre aspect de l’invention, le procédé comprend en outre la mémorisation, par le serveur de synchronisation, du message destiné au terminal destinataire, extrait du premier message de synchronisation, afin de permettre la récupération par ledit au moins un terminal associé du message destiné au terminal destinataire.
Dans un mode particulier de réalisation, le message destiné au terminal destinataire est un message au format SMS.
Dans un mode particulier de réalisation, le premier et/ou le deuxième message de synchronisation est un message conforme à un protocole parmi les protocoles IMAP, J MAP, OMA DS ou OMA NMS.
Il est proposé également un serveur de synchronisation comprenant un module de communication apte à échanger des messages de synchronisation avec un premier terminal, dit terminal source, et au moins un deuxième terminal, dit terminal associé, partageant un même identifiant avec le terminal source, et un module de traitement configuré pour extraire un message destiné à un troisième terminal, dit terminal destinataire, d’un premier message de synchronisation reçu par le module de communication et pour insérer ledit message dans un deuxième message de synchronisation à transmettre vers ledit au moins un terminal associé.
Dans un mode particulier de réalisation, le module de traitement est configuré en outre pour transmettre le message extrait à un nœud réseau chargé du stockage et de la retransmission de messages, afin que ledit nœud réseau puisse retransmettre ledit message vers le terminal destinataire.
Il est proposé par ailleurs un terminal comprenant un module de communication et un module traitement, le module de traitement étant configuré pour insérer un message destiné à un autre terminal, dit terminal destinataire, dans un message de synchronisation et le module de communication étant configuré pour émettre ledit message de synchronisation vers un serveur de synchronisation, afin qu’au moins un autre terminal, dit terminal associé, puisse récupérer le message destiné au terminal destinataire auprès dudit serveur de synchronisation.
Dans un mode particulier de réalisation, le module de traitement est configuré en outre pour instruire au module de communication de transmettre le message vers une passerelle d’acheminement permettant sa retransmission dans le plan de signalisation vers le terminal destinataire.
Il est également proposé un système pour la transmission d’un message destiné à un premier terminal, dit terminal destinataire, depuis un deuxième terminal, dit terminal source, vers au moins un troisième terminal, dit terminal associé, partageant un même identifiant avec le terminal source, comprenant un serveur de synchronisation tel que décrit ci-avant et ledit au moins un terminal associé, configuré pour récupérer auprès du serveur de synchronisation le message au moyen d’un message synchronisation. Dans un mode de réalisation, ce système comprend en outre un terminal source, ce terminal source étant un terminal tel que présenté ci-avant.
D’autres caractéristiques et avantages de l’invention apparaîtront plus clairement à la lecture de la description suivante de modes de réalisation particuliers, donnés à titre de simples exemples illustratifs et non limitatifs, et des dessins annexés, parmi lesquels :
- La figure 1 représente schématiquement l’architecture prévue pour la transmission de message SMS, tel que normalisée actuellement ; - La figure 2 représente un mode de réalisation du procédé de transmission de message selon la présente invention ;
- La figure 3 représente un autre mode de réalisation du procédé de transmission de message selon la présente invention ;
- La figure 4 illustre un terminal selon un mode de réalisation de la présente invention ; et
- La figure 5 illustre un serveur de synchronisation selon un mode de réalisation de la présente invention.
Il est fait tout d’abord référence à la Figure 1 , laquelle illustre schématiquement l’architecture actuellement prévue dans les normes 3GPP existantes, pour permettre la transmission de messages SMS depuis un terminal mobile émetteur UE-A vers un terminal mobile destinataire UE-B.
En particulier, le terminal mobile UE-A formate le message à transmettre, typiquement une suite de caractères alphanumériques saisie par l’utilisateur de ce terminal mobile au moyen de l’interface utilisateur de ce terminal, selon le format SMS.
Pour formater ce message, le terminal mobile UE-A est pourvu d’un module de formatage de message, encore appelé « client messaging » en anglais, un tel module étant natif, c’est-à-dire intégré dans le terminal mobile UE-A dès sa construction.
Une fois ce message formaté, le terminal mobile UE-A transmet (étape A1 10) ce message SMS vers une passerelle d’acheminement A_SMS, appartenant au réseau A auquel est abonné ou attaché, selon les cas, le terminal UE-A, cette passerelle étant spécialement dédiée à la retransmission de ce type de message dans le réseau, au moyen d’un protocole réseau prévu pour une telle transmission entre terminaux et cette passerelle d’acheminement A_SMS. Ce protocole réseau est typiquement un protocole de signalisation, c’est-à-dire un protocole relatif à la transmission de messages de signalisation dans le plan de signalisation.
Dans le cas d’un réseau d’accès 2G ou 3G, cette passerelle d’acheminement A_SMS est implémentée sous la forme d’un serveur MSC (pour « Mobile Switching Center » en anglais) auquel le terminal UE-A envoie directement le message SMS, tandis que dans le cas d’un réseau d’accès 4G, cette passerelle d’acheminement A_SMS est implémentée sous la forme d’une passerelle IP-SM-GW, le message SMS1 étant alors encapsulé dans un message selon le protocole de signalisation SIP (pour « Session Initiation Protocol » en anglais) transmis vers des noeuds réseau intermédiaires (noeuds "P-CSCF" ou « S-CSCF » par exemple, non illustrés ici) qui le retransmettent vers cette passerelle IP-SM-GW.
Cette passerelle d’acheminement A_SMS retransmet alors ce message SMS selon un protocole de signalisation MAP (pour « Mobile Application Part » en anglais) ou Diameter vers un nœud réseau de type SMSC, pour « Short Message Service Center » en anglais (sous-étape A1 12), afin que ce nœud réseau SMSC mémorise (sous-étape A1 13) ce message SMS en vue de sa retransmission ultérieure vers le réseau B auquel le terminal destinataire est attaché. Un accusé de bonne réception peut alors être également transmis, du nœud SMSC vers le terminal UE-A à ce stade (étape A11 1 ).
A ce stade, le SMSC tente de transmettre (sous-étape A1 14) immédiatement le message SMS vers une passerelle d’acheminement B_SMS de ce réseau B, au moyen du protocole de signalisation MAP. Dans le cas d’un réseau d’accès 2G ou 3G, cette passerelle d’acheminement B_SMS est implémentée sous la forme d’un nœud réseau MSC (pour « Mobile Switching Center » en anglais) tandis que dans le cas d’un réseau d’accès 4G, cette passerelle d’acheminement B_SMS est implémentée sous la forme d’une passerelle IP-SM-GW.
Une fois le message de signalisation selon le protocole MAP encapsulant le message SMS reçu par la passerelle B_SMS, cette dernière extrait le SMS de ce message de signalisation et le transmet (étape A1 15) vers le terminal UE-B en utilisant un protocole de type NAS ("Non Access Stratum"). Dans le cas d’un réseau d’accès 4G, la passerelle B_SMS transmet le message SMS1 au terminal UE-B en l’encapsulant dans un message selon le protocole SIP.
Ainsi, dans cette architecture, les autres terminaux qui pourraient être associés au terminal UE-A au sein d’un système « multi-terminaux » ne peuvent pas être informés de l’envoi, par le terminal UE-A, d’un message de type SMS vers le terminal UE-B.
Il est fait maintenant référence à la Figure 2, laquelle illustre un procédé de transmission de message selon un premier mode de réalisation de la présente invention.
Dans ce premier mode de réalisation, un premier terminal 10, appelé terminal source par la suite, souhaite émettre un message vers un deuxième terminal 20, appelé terminal destinataire par la suite. Les terminaux 10 et 20 peuvent être en particulier des terminaux mobiles, par exemple de type smartphone.
Le message en question est ici illustré comme étant un message SMS1 , formaté selon le format SMS, sans que l’invention ne se limite à ce seul format de message, celle-ci pouvant s’appliquer à tout type de message à transmettre entre terminaux.
Dans le cas présent, le terminal 10 est associé avec au moins un autre terminal, appelé terminal associé, dans le cadre d’un contexte de communication dit « contexte multi-terminaux ». Il peut s’agir ici aussi d’un terminal mobile, par exemple du type smartphone.
Dans un tel contexte multi-terminaux, les différents terminaux associés partagent un même identifiant, encore appelé identifiant commun, qui peut typiquement être un même numéro de téléphone (i.e. le même identifiant MSISDN d’un des terminaux associés), ou aussi être un numéro non lié nativement à l’un des terminaux du système, du type « extra-number » ou « Virtual number » précédement discuté, lequel est typiquement un nouveau numéro attribué par l'opérateur, non lié à une carte SIM ou à un terminal particulier, de sorte à ce que les autres terminaux appelés par (ou destinataires d’un message provenant de) l’un des terminaux associés ne voient qu’un seul et même identifiant, indépendamment du terminal associé qui est réellement utilisé.
En l’occurrence, la figure 2 illustre le cas d’un système multi-terminaux à trois terminaux associés, dans lequel deux autre terminaux associés 10’ et 10” sont associés avec le terminal source 10, et donc partagent avec lui un même identifiant « MSISDN-IO » (en l’occurrence l’identifiant du terminal source 10), sans que l’invention ne se limite à ce seul cas, un nombre N (avec N>1 ) de terminaux pouvant être associés au terminal destinataire 10 au sein d’un tel système.
Les terminaux associés au sein d’un système multi-terminaux peuvent être notamment des terminaux mobiles (smartphones, des montres connectées, des tablettes, entre autres), mais aussi d’autres types moins mobiles de terminaux, tels que des assistants vocaux, ou des frigos connectés, c’est-à-dire tout terminal connecté au réseau et capable d’envoyer et de recevoir des messages, éventuellement en les affichant ou en les vocalisant.
Outre le terminal source et les terminaux associés à ce terminal source, ce mode de réalisation fait intervenir un serveur de synchronisation 30, avec lequel le terminal mobile source 10 et les terminaux associés 10’ et 10” échangent des messages de synchronisation, désignés ici par « SYNC ».
A ce titre, des modules clients synchronisation sont installés dans les terminaux associés 10, 10’ et 10” tandis qu’un module serveur de synchronisation est installé dans le serveur de synchronisation, ces modules étant synchronisés de sorte à ce que les modules clients soient notifiés des changements de contenu du module serveur du serveur de synchronisation, soit en temps réel dès qu’un tel changement a lieu, soit de manière différée lorsqu’un des modules clients interroge le module serveur afin de connaître les changements qui ont eu lieu depuis la dernière connexion du terminal client au serveur.
De tels messages de synchronisation SYNC sont conformes à un protocole de synchronisation apte à être utilisé entre un module client et un module serveur, lequel peut être le protocole IMAP (pour « Interactive Message Access Protocol » en anglais), JMAP (pour l’implémentation Java du protocole IMAP), OMA DS (Data Sync) ou OMA NMS (Network Message Storage), par exemple. En d’autres termes, les terminaux 10, 10’ et 10” se synchronisent avec le serveur de synchronisation en échangeant des messages de synchronisation conforme à un protocole de synchronisation tel que l’un des protocoles susmentionnés, cités à titre d’exemple de protocole de synchronisation.
Dans une étape préalable (non illustrée) au présent procédé, les terminaux 10’ et 10” associés au terminal source 10 s’enregistrent auprès du serveur de synchronisation 30, afin de bénéficier ultérieurement du service de synchronisation géré par ce serveur. En particulier, le serveur de synchronisation 30 dispose de l’information permettant de faire le lien entre tous les terminaux associés, typiquement un identifiant commun à tous ces terminaux tels qu’un identifiant MSISDN10 du terminal source 10, ou encore un numéro supplémentaire de type « extra-number », i.e. un nouveau numéro, fourni par l’opérateur, non lié à une carte SIM ou à un terminal particulier.
Lorsqu’un message SMS1 (ici un message selon le format SMS) est à transmettre depuis le terminal source 10 vers un terminal destinataire 20, le terminal 10 procède d’une part à la transmission de message SMS1 vers le terminal 20 de la manière illustrée précédemment à la figure 1 , en utilisant les étapes A110 à A115 décrites précédemment en relation avec cette figure 1.
Cependant, outre ces étapes de transmission du message directement au terminal 20 dans le plan de signalisation, dans le présent mode de réalisation, le terminal 10 insère (étape S120) ce message SMS1 dans un message de synchronisation SYNC conforme au protocole de synchronisation utilisé par le serveur de synchronisation 30.
En particulier, l’insertion de ce message peut se faire dans un champ du message de synchronisation permettant une telle insertion. A titre d’exemple, ce message SYNC peut être une requête de type HTTP POST avec une structure de type Mime Text/plain dans laquelle est inséré le message SMS1 , comme illustré ci-dessous :
POST texampteAPI/mi^vlinifStcrf ¾ ¾ %2B195055501 CWcÆiects
Accept: appfafcnftiin!
Autbertzatim: BEARER f»7Ji724-M«- 3*-a«4-2tKliMcM3
Host: bcr.t . ch
Content- T y e: tact/pian
Content- Lengti: 40
Hi Je ri , «hst abc ut a cirte this evertihg?
En réponse à cette requête, le serveur 30 peut transmettre au terminal 10 un identifiant unique, attribué par le serveur 30 au message SMS1 , inséré dans une structure XML ou JSON par exemple.
Une fois le message SMS1 à transmettre inséré dans le message de synchronisation, le message de synchronisation résultant SYNC[SMS1 ] est transmis par le terminal source 10 vers le serveur de synchronisation 30 (étape S130), dans le plan de transport de données.
Il convient de noter ici que l’étape A1 10 de transmission du message SMS1 directement au terminal 20 d’une part, et les étapes S120 et S130 d’insertion et d’envoi du message de synchronisation contenant le message SMS1 au serveur de synchronisation 30 d’autre part, peuvent être effectuées en parallèle, c’est-à-dire simultanément ou dans un ordre quelconque les unes par rapport aux autres.
Une fois ce message de synchronisation SYNC[SMS1 ] reçu par le serveur de synchronisation 30, le message SMS1 qu’il contient peut être extrait et stocké par ce serveur de synchronisation 30 (étape S140), soit au sein même d’une mémoire de ce serveur, soit dans une base de données associée à ce serveur.
A ce stade, les terminaux associés 10’ et 10” récupèrent respectivement le message SMS1 destiné au terminal destinataire 10 au moyen de messages de synchronisation qu’ils échangent respectivement avec le serveur de synchronisation 30. Ainsi, pour ce qui est du terminal associé 10’, le serveur de synchronisation 30 récupère le message SMS1 destiné au terminal destinataire 20 au moyen d’un message de synchronisation SYNC’[SMS1 ] qu’il transmet à ce terminal 10 (étape S150’). Il fait de même pour tous les autres terminaux associés, en l’occurrence ici pour le terminal 10” (étape S150”) auquel il envoie un message de synchronisation SYNC”[SMS1 ] dans lequel il a inséré le message SMS1.
Les messages de synchronisation (ici SYNC’[SMS1 ] et SYNC”[SMS1 ]) sont générés selon des procédures distinctes, pouvant toutefois utiliser les mêmes mécanismes et protocoles de synchronisation. Alternativement, ces messages de synchronisation peuvent utilisés des protocoles de synchronisation différents. En outre, les messages de synchronisation SYNC’[SMS1 ] ou SYNC”[SMS1 ] utilisés pour transmettre le message SMS1 vers l’un des terminaux associés 10’ ou 10“’ peuvent être générés selon les mêmes mécanismes et protocoles de synchronisation que le message de synchronisation SYNC[SMS1 ] utilisé pour transmettre le message SMS1 depuis le terminal source 10, ou bien encore être un message de synchronisation d’un type différent.
Ces messages de synchronisation peuvent être implémentés sous la forme d’un message contenant un attribut dans lequel le message SMS1 est inséré. Il peut s’agir notamment d’un message de type « pager-messager » selon l’interface REST NMS, contenant un objet de type SMS dit « inline », dans lequel le message SMS1 peut être directement inséré dans un attribut « textContent », comme illustré par l’exemple ci- dessous :
|<object>
<attributes>
<attribute>
<n ajie >Me s s age -Context /name>
<value>pager-message</value>
</attribute>
<attribute>
<name>F roii< / n ame >
<va1ue>tel :+19585550100</ va1 u e>
</attribute>
<attribute>
<name>To</name>
<value>tel :+19585550210</value>
</attribute>
<attrlbyte>
<name>Date</nafie>
<va1ue>2013-11-12T08 : 30: 10Z</value>
</attribute>
<attribute>
<name>Direction</name>
<valuG>In</value>
</attribute>
<attrlbute>
<naine >Con te nt -Type</ n ante>
<value>text/plain</value>
</attribute>
<attribute>
<name>TextContent</name>
<value>The weather is nice to ay, lef s go to the beach ! </value> </att:ribute>
</att ri butes >
Ces messages de synchronisation peuvent aussi être implémentés sous la forme de message avec un champ « payload » contenant une adresse permettant le téléchargement ultérieur du message SMS1 (par requête GET par exemple). En particulier, il peut s’agir d’un message de type « pager-messager » selon l’interface REST NMS, comme illustré par l’exemple ci-dessous : Ces messages de synchronisation peuvent aussi être implémentés sous forme d’une notification du serveur de synchronisation, contenant dans son objet une URL permettant de télécharger directement un objet « message SMS1 », comme illustrée par l’exemple ci-dessous, où l’élément « oldl OOO » en fin d’URL représente un identifiant unique de ce message :
Les trois exemples précédents sont au format XML, mais une structure JSON peut être également utilisée.
Chaque terminal associé peut alors, après avoir reçu un tel message de synchronisation, récupérer le message SMS1 destiné au terminal destinataire 20, soit en l’extrayant du message de synchronisation lorsqu’il y est inséré, soit en téléchargeant ce message SMS1 depuis une adresse indiqué dans ce message de synchronisation. Les terminaux associés 10’ et 10” peuvent alors stocker ce message SMS1 dans leurs propres mémoires, pour consultation ou restitution ultérieure par un utilisateur.
Ainsi, au terme de ce procédé, tous les terminaux associés au terminal source disposent du message SMS1 émis par le terminal source, ainsi que des informations associées à ce message, telles que l’heure d’envoi du message, le lieu d’envoi du message, l'état de lecture ou de réponse du message, etc. L’utilisateur d’un système multi-terminaux a donc accès à un même historique d’envoi de message, peu importe le terminal par lequel il y accède.
Dans un mode de réalisation, le procédé illustré sur la figure 2 peut être déclenché pour tous les messages utilisant comme identifiant d'origine un identifiant commun potentiellement utilisé sur d'autres terminaux, saisis par un utilisateur sur le terminal source 10. Pour ce faire, le terminal source 10 peut comprendre un module de formatage de message de synchronisation, configuré pour recevoir en entrée tous les messages à transmettre en utilisant un identifiant commun à plusieurs terminaux et pour les insérer dans des messages de synchronisation à transmettre vers le serveur de synchronisation 30.
Dans le présent mode de réalisation, ce module de formatage de message de synchronisation fonctionne parallèlement au module natif de formatage de message à transmettre, de sorte à transmettre en parallèle aussi bien le message destiné au terminal destinataire selon un schéma classique (étapes A1 10 à A1 15) qu’un message de synchronisation contenant ce message vers le serveur de synchronisation 30 (étape S130).
Dans un tel mode de réalisation « hybride », le message reste transmis vers le terminal destinataire au moyen de messages de signalisation, dans le plan de signalisation donc, tandis que des copies de ce message sont transmises aux terminaux associés au terminal source, dans le plan de transport de données. Ceci permet de garantir une certaine rapidité de transmission au terminal destinataire, tout en économisant des ressources du plan de signalisation pour ce qui est des copies transmises aux terminaux associés, pour lesquelles le temps de transmission est moins critique que pour le terminal destinataire.
Dans un autre mode de réalisation, ce module de formatage de message de synchronisation est placé en sortie du module natif de formatage de message à transmettre, de sorte à intercepter les messages en sortie de ce dernier. Dans ce cas, un message destiné au terminal destinataire 20 n’est pas émis tel quel, selon le schéma classique (i.e. vers une passerelle d’acheminement du réseau). Au contraire, seul un message de synchronisation contenant ce message est émis, vers le serveur de synchronisation 30.
Il est fait maintenant référence à la Figure 3, laquelle illustre un procédé de transmission de message selon un deuxième de réalisation de la présente invention.
Cet autre mode de réalisation diffère du précédent en ce que la transmission directe du message SMS1 , du terminal 10 au terminal 20 dans le seul plan de signalisation, est inhibée, le message SMS1 étant alors transmis au moyen d’un message de synchronisation, au moins en partie dans le plan de transport de données, tout comme pour les terminaux associés au terminal 10.
En d’autres termes, dans le présent mode de réalisation, lorsqu’un message SMS1 (ici encore un message selon le format SMS) est à transmettre depuis le terminal source 10 vers un terminal destinataire 20, le terminal 10 ne procède pas à la transmission de ce message SMS1 vers le terminal 20 de la manière illustrée précédemment à la figure 1 , et donc n’utilise pas les étapes A 1 10 à A115 décrites précédemment en relation avec cette figure 1. Cette transmission traditionnelle est ici inhibée au niveau du terminal 10.
Au contraire, le procédé selon le présent mode de réalisation début par l’étape S120 d’insertion du message SMS1 dans un message de synchronisation SYNC[SMS1 ], suivie par l’étape S130 de transmission de ce message de synchronisation au serveur de synchronisation 30 et de l’étape S140 de mémorisation de ce message SMS1 , après son éventuelle extraction du message de synchronisation, par le serveur de synchronisation 30, telles que décrites précédemment en relation avec la figure 2.
A ce stade, les terminaux associés 10’ et 10” peuvent récupérer le message SMS1 destiné au terminal destinataire 20, au moyen de messages de synchronisation qu’ils échangent respectivement avec le serveur de synchronisation 30, lors d’étapes respectives S150’ et S150” comme décrites précédemment en relation avec la figure 2.
Cependant, dans le présent mode de réalisation, le serveur de synchronisation 30 peut également à ce stade transmettre le message SMS1 , qu’il a extrait du message de synchronisation SYNC[SMS1 ] reçu du terminal 10, vers le nœud réseau 40 chargé de stocker et retransmettre les messages entre terminaux mobiles, en l’occurrence le centre SMSC dans le cas de messages SMS (étape S142), par exemple au moyen du protocole de signalisation MAP employé par exemple par les passerelles IP-SM-GW pour transmettre les messages SMS vers un tel nœud réseau 40. Tout autre protocole IP de synchronisation, voire une API, peut être utilisé alternativement.
Ceci permet au nœud réseau 40 de stocker temporairement ce message SMS1 (étape A113) avant de le retransmettre (étape A1 14) vers une passerelle d’acheminement B_SMS de tels messages (une passerelle IP-SM-GW dans le cas d’un réseau d’accès 4G ou un serveur MSC dans le cas d’un réseau d’accès 2G ou 3G), située dans le réseau B auquel le terminal destinataire 20 est abonné/attaché, afin que celle-ci retransmette (étape A1 15) le message vers le terminal destinataire 20. Ces étapes A1 13 à A1 15 sont similaires à celles déjà décrites en relation avec les figures 1 et 2.
Il convient de noter ici que les étapes S142, A1 13, A114 et A1 15 d’une part, permettant la transmission du message SMS1 du serveur de synchronisation vers le terminal 20, et les étapes S140, S150’ et S150”, permettant la récupération de ce message SMS1 par les terminaux associés au terminal source, peuvent être effectuées en parallèle, c’est-à-dire simultanément ou dans un ordre quelconque les unes par rapport aux autres.
Ainsi, au terme de ce procédé, tous les terminaux associés au terminal source disposent du message SMS1 émis par le terminal source, ainsi que des informations associées à ce message, telles que l’heure d’envoi du message, le lieu d’envoi du message, etc. L’utilisateur d’un système multi-terminaux a donc accès à un même historique d’envoi de message, peu importe le terminal auquel il accède.
Similairement au précédent mode de réalisation, pour implémenter ce procédé, le terminal source 10 peut comprendre un module de formatage de message de synchronisation, configuré pour recevoir en entrée tous les messages à transmettre utilisant un identifiant potentiellement commun à plusieurs terminaux et pour les insérer dans des messages de synchronisation à transmettre vers le serveur de synchronisation 30.
Cependant, dans le présent mode de réalisation, ce module de formatage de message de synchronisation peut être placé en sortie du module natif de formatage de message à transmettre, de sorte à intercepter les messages en sortie de ce dernier. Dans ce cas, un message destiné au terminal destinataire 20 n’est pas émis tel quel, selon le schéma classique (i.e. vers une passerelle d’acheminement du réseau). Au contraire, seul un message de synchronisation contenant ce message est émis, vers le serveur de synchronisation 30, lors de l’étape S130. Alternativement, dans le cas d’un module natif de formatage de message à transmettre qui serait placé en parallèle du module de formatage de message de synchronisation, et donc pourrait éventuellement transmettre directement le message SMS1 dans le plan de signalisation, il convient ici d’instruire à ce module natif de formatage de message à transmettre d’inhiber une telle transmission directe, qui serait redondante avec celle effectuée par le serveur de synchronisation lors des étapes S142 à S148.
Dans cet autre mode de réalisation, les messages à transmettre sont donc transmis quasiment intégralement dans le plan de transport de données, ce qui présente l’avantage d’économiser encore plus les ressources du plan de signalisation du réseau, afin qu’elles puissent être allouées à d’autres services. L’utilisation du seul plan de transport de données, pour la transmission de tels messages depuis ou vers les terminaux, peut s’avérer moins rapide que l’utilisation du plan de signalisation, mais ce désagrément peut s’avérer mineur au regard du gain obtenu en termes d’économie de ressources du plan de signalisation, surtout si l’on considère qu’il n’y a pas véritablement de besoin de transmettre de tels messages en temps-réel et qu’un léger temps de latence est alors tolérable.
Le terminal source 10 et le serveur de synchronisation 30 peuvent être configurés pour mettre en oeuvre uniquement le premier ou le deuxième mode de réalisation.
Ainsi, pour ce qui est du premier mode de réalisation illustré en figure 2, le terminal 10 peut être nativement configuré (ou configuré par mise à jour logicielle) pour se synchroniser avec le serveur de synchronisation (étape S120) en plus de l’émission du message SMS1 vers la passerelle d’acheminement 50 (étape A1 10). Le serveur de synchronisation 30 peut être configuré pour se synchroniser avec les terminaux associés (étapes S150’ et S150”), sans envoyer de message de signalisation incluant le message SMS1 vers le nœud réseau 40.
Pour ce qui est du deuxième mode de réalisation illustré en figure 3, le terminal 10 peut être nativement configuré (ou configuré par mise à jour logicielle) pour se synchroniser avec le serveur de synchronisation (étape S120) sans toutefois émettre le message SMS1 vers la passerelle d’acheminement 50. Autrement dit, sa fonction traditionnelle d’envoi du message directement dans le plan de signalisation peut être désactivée. Le serveur de synchronisation 30 peut alors être configuré pour, outre le fait de se synchroniser avec les terminaux associés (étapes S150’ et S150”), envoyer également un message de signalisation incluant le message SMS1 vers le nœud réseau 40 (S142), afin de permettre à ce message d’atteindre le terminal destinataire 20.
Le serveur de synchronisation 30 peut être configuré pour se synchroniser avec les terminaux associés (étapes S150’ et S150”), sans envoyer de message incluant le message SMS1 vers le nœud réseau 40.
Dans un autre mode de réalisation cependant, aussi bien le terminal 10 que le serveur de synchronisation 30 peut mettre en œuvre le premier ou le deuxième mode de réalisation du procédé décrit précédemment.
Le terminal 10 est alors configuré nativement (ou configuré par mise à jour logicielle) pour se synchroniser avec le serveur de synchronisation (étape S120) et, en outre, pouvoir activer ou désactiver l’émission du message SMS1 vers la passerelle d’acheminement 50 dans le plan de signalisation (étape A1 10).
Cette activation ou désactivation peut être instruite par l’utilisateur du terminal, au moyen d’une commande saisie via l’interface utilisateur ou d’un menu de configuration du terminal 10, ou encore à distance par un message de commande transmis depuis le réseau de communication, par exemple par l’opérateur de ce réseau. Ainsi, lorsque la transmission du message SMS1 est effectué par un module de communication du terminal 10, ce module peut être configuré pour recevoir une telle commande d’activation, ou de désactivation, de ce type de transmission (étape A1 10) et activer, ou désactiver, cette transmission en fonction de cette commande.
Le serveur de synchronisation 30 est alors, pour sa part, configuré pour se synchroniser avec les terminaux associés (étapes S150’ et S150”) et, en outre, pour pouvoir activer ou désactiver l’émission d’un message de signalisation incluant le message SMS1 vers le nœud réseau 40 (étape S142).
Cette activation ou désactivation peut être instruite par un opérateur du serveur, au moyen d’une commande saisie via une interface utilisateur ou d’un menu de configuration de ce serveur 30, ou encore à distance par un message de commande transmis depuis le réseau de communication, par exemple par l’opérateur de ce réseau.
Cependant, comme il est préférable que cette activation ou désactivation côté serveur 30 tienne compte de l’activation ou désactivation côté terminal 10, le procédé peut avantageusement comprendre une étape de détermination (non illustrée), par le serveur de synchronisation 30, de l’émission (étape A110) du message SMS1 du terminal source 10 vers une passerelle d’acheminement 50. La transmission (étape S142) du message SMS1 du serveur de synchronisation 30 vers le nœud réseau 50 n’a alors lieu que si le résultat de cette détermination est positif.
Cette détermination peut être réalisation au moyen de la détection d’un indicateur d’activation, ou de désactivation, de l’étape A1 10, inséré dans le message de synchronisation SYNC[SMS1 ] que le terminal 10 transmet au serveur 30.
En d’autres termes, lorsque l’émission (étape A1 10) du message SMS1 est activée côté terminal 10, le terminal 10 insère un indicateur signalant cette activation dans le message SYNC[SMS1 ] envoyé au serveur 30. Quand ce serveur 30 reçoit ce message SYNC[SMS1] et y détecte cet indicateur, il désactive alors l’émission (étape S142) du message SMS1 vers le nœud réseau 40, qui serait redondante. Inversement, lorsque l’émission (étape A1 10) du message SMS1 est désactivée côté terminal 10, le terminal 10 insère un indicateur signalant cette désactivation dans le message SYNC[SMS1 ] envoyé au serveur 30. Quand ce serveur 30 reçoit ce message SYNC[SMS1 ] et y détecte cet indicateur, il active alors l’émission (étape S142) du message SMS1 vers le nœud réseau 40, afin de déclencher la retransmission de ce message SMS1 vers le terminal 20.
On se réfère à présent à la figure 4, illustrant un terminal selon un mode de réalisation de la présente invention.
Le terminal 10 (lequel peut être un terminal mobile, comme par exemple un smartphone) comprend en particulier un module d’interface utilisateur 11 , permettant à un utilisateur de saisir un message, dit « message brut », à transmettre vers un terminal mobile destinataire, ce module d’interface utilisateur pouvant prendre la forme d’un clavier ou d’un écran tactile permettant de rentrer des caractères alphanumériques, voire d’une interface de reconnaissance vocale permettant une telle saisie.
Le terminal 10 comprend également un module de traitement 13 configuré pour recevoir, en entrée, le message brut saisi par un utilisateur et pour le formater sous la forme d’un message pouvant être transmis sur le réseau de communication auquel le terminal est attaché. A cet effet, le module de traitement 13 comprend un module natif 13i de formatage de message à transmettre, configuré pour encapsuler le message brut saisi par l’utilisateur dans un message formaté permettant sa transmission sur le réseau, typiquement un module de formatage SMS délivrant, en sortie, des messages SMS à transmettre vers le réseau. Comme discuté précédemment, ce module natif 13i peut être configuré pour recevoir une instruction d’inhibition de transmission directe de messages vers le réseau, notamment lorsque l’on souhaite mettre en oeuvre le procédé tel qu’illustré par la figure 3. Un tel module de traitement est typiquement implémenté sous la forme d’un ou plusieurs processeurs exécutant des instructions de code d’un programme informatique, associé à une mémoire vive et/ou une mémoire morte dans laquelle sont stockées ces instructions de code.
Le terminal 10 comprend en outre un module de mémorisation 15 dans lequel est mémorisé, entre autres, un identifiant du terminal 10, typiquement mais non exclusivement un numéro de téléphone attribué au terminal, ici MSISDN10. Ce module de mémorisation 15 peut également mémoriser un identifiant commun au système multi-terminaux auquel appartient le terminal 10, ou un identifiant virtuel, lequel peut alors être utilisé pour indiquer que les messages transmis par ce terminal sont à diffuser auprès des terminaux associés à ce terminal dans un tel système.
Ce module de mémorisation peut être implémenté sous la forme d’une carte SIM amovible, ou encore d’une carte eSIM intégrée dans le terminal 10. Le module natif 13i accède à ce module 15 pour y extraire l’identifiant MSISDN10 afin soit de l’insérer tel quel en tant qu’identifiant commun dans le message formaté qu’il prépare, soit de l’utiliser dans une requête pour récupérer l’identifiant commun auprès d’un serveur distant de type HLR lors de l’attachement au réseau, avant d’insérer cet identifiant récupéré dans le message formaté qu’il prépare, de sorte à ce que ce message puisse identifier son émetteur.
Dans le cadre de la présente invention, le module de traitement 13 comprend en outre un module 132 de formatage de message de synchronisation, recevant en entrée le message délivré par le module natif 13i et l’insérant dans un message de synchronisation destiné à être transmis à un serveur de synchronisation auprès duquel le terminal 10 est enregistré.
Le terminal 10 comprend enfin un module de communication 17, apte à recevoir les messages préparés par le module de traitement 13 afin de les transmettre, par voie radio, vers le réseau de communication auquel le terminal 10 est attaché. Un tel module de communication peut être implémenté en particulier sous la forme d’une ou plusieurs antenne(s) radio connectées à un convertisseur numérique/analogique recevant en entrée les messages préparés par le module de traitement 13, en particulier les messages de synchronisation délivrés par le module 132. Comme indiqué précédemment, ce module de communication 17 peut, outre les messages de synchronisation SYNC encapsulant des messages destinés à un terminal destinataire, également recevoir des messages préparés par le module natif 13i, afin de les transmettre en parallèle des messages de synchronisation contenant ces messages.
On se réfère à présent à la figure 5, illustrant un serveur de synchronisation selon un mode de réalisation de la présente invention.
Ce serveur de synchronisation 30 comprend en particulier un module de communication 31 (typiquement implémenté sous forme d’émetteur-récepteur) configuré pour échanger des messages de synchronisation SYNC avec le terminal source 10, ainsi que de messages de synchronisation SYNC’ avec le ou les terminaux 10’, 10” qui lui sont associés (un seul terminal 10’ associé étant illustré ici).
Le serveur de synchronisation 30 comprend en outre un module de traitement 33, configuré tout d’abord pour traiter les messages de synchronisation SYNC reçus en provenance du terminal source 10, et notamment pour en extraire un message destiné à un terminal destinataire 20, par exemple un message SMS, lorsqu’un tel message y a été inséré (ce cas étant ici illustré sur la figure 5 par le message SYNC[SMS1 ]). Un tel module de traitement est typiquement implémenté sous la forme d’un ou plusieurs processeurs exécutant des instructions de code d’un programme informatique, associé à une mémoire vive et/ou une mémoire morte dans laquelle sont stockées ces instructions de code.
Ce message SMS1 , une fois extrait du message de synchronisation SYNC[SMS1 ], peut être alors mémorisé dans un module de mémorisation 35 (typiquement implémenté sous forme d’une mémoire non-volatile), ici illustré comme étant compris dans le serveur de synchronisation 30, mais pouvant être aussi implémenté sous la forme d’une base de données distincte de ce serveur, à laquelle ce serveur a accès pour mémoriser ces messages et y accéder ensuite.
La mémorisation de ce message, dans le module de mémorisation 35, peut être faite en association avec un identifiant du terminal source 10 (ici, son identifiant « MSISDN-IO ») afin de faciliter sa récupération ultérieure.
Lorsqu’ultérieurement, un terminal associé au terminal source 10 doit être synchronisé, le module de traitement 33 peut alors vérifier auprès du module de mémorisation 35 si un message SMS1 associé à l’identifiant unique qui lui est associé a été mémorisé et, si c’est le cas, le module 33 peut alors récupérer ce message afin de l’insérer dans un message de synchronisation SYNC’[SMS1 ] qu’il fournit au module de communication 31 afin que ce dernier transmette le message de synchronisation SYNC’[SMS1 ] au terminal associé en question.
Les messages SYNC[SMS1 ] et SYNC’[SMS1 ] peuvent être émis spontanément (c’est-à-dire sans qu’une requête préalable n’ait été reçue pour déclencher l’émission de ce message) respectivement par le terminal source 10 et le serveur de synchronisation 30, par exemple à intervalle régulier, dans un mode « push ». Alternativement, ces messages peuvent être des messages émis en réponse à des requêtes de synchronisation reçues respectivement du serveur de synchronisation 30 et du terminal source 10, dans un mode dit « pull » (de telles requêtes étant illustrées par « REQ SYNC » sur la figure 4).
Bien entendu, l’invention n’est pas limitée aux exemples de réalisation ci-dessus décrits et représentés, à partir desquels on pourra prévoir d’autres modes et d’autres formes de réalisation, sans pour autant sortir du cadre de l’invention.
En particulier, les messages de type SMS ont été discutés précédemment comme exemple de messages courts pouvant être avantageusement transmis grâce aux modes de réalisation de la présente invention. Cependant, tout autre type de message, plus ou moins court, peut être également concerné, l’invention étant cependant particulièrement avantageuse lorsque la taille du message à transmettre est inférieure à la taille du champ disponible pour l’insérer dans un message de synchronisation entre un terminal et un serveur de synchronisation, de sorte à ce qu’un seul message de synchronisation suffise à transmettre un (voire plusieurs) message(s), destiné(s) à un terminal « destinataire », à un autre terminal associé à ce terminal destinataire.
De plus, le serveur de synchronisation présenté précédemment peut être un équipement spécifique, dédié uniquement à la synchronisation de messages avec des terminaux associés à un terminal destinataire de messages, mais également tout équipement réseau ayant d’autres fonctionnalités, dans lequel un module logiciel de type « serveur » est installé pour échanger les messages de synchronisation SYNC présentés ci-dessus avec un module logiciel de type « client » installé dans des terminaux associés au terminal destinataire.

Claims

Revendications
1. Procédé de transmission d’un message (SMS1 ) destiné à un premier terminal (20), dit terminal destinataire, depuis un deuxième terminal (10), dit terminal source, vers au moins un troisième terminal (10’, 10”), dit terminal associé, partageant un même identifiant avec le terminal source, comprenant les étapes de :
transmission (S130), du terminal source (10) vers un serveur de synchronisation (30), d’un premier message de synchronisation (SYNC[SMS1 ]) dans lequel est inséré le message destiné au terminal destinataire ; et
récupération (S150’,S150”), par ledit au moins un terminal associé (10’, 10”), du message destiné au terminal destinataire auprès du serveur de synchronisation au moyen d’au moins un deuxième message de synchronisation (SYNC’[SMS1 ], SYNC”[SMS1 ])
2. Procédé selon la revendication 1 , comprenant en outre la transmission (A1 10), du terminal source (10) vers une passerelle d’acheminement (50), du message destiné au terminal destinataire (20), afin que ladite passerelle d’acheminement puisse retransmettre ledit message dans le plan de signalisation vers le terminal destinataire (20).
3. Procédé selon l’une des revendications 1 ou 2, comprenant en outre la transmission (S142), du serveur de synchronisation (30) vers un nœud réseau (40) chargé du stockage et de la retransmission de message, du message destiné au terminal destinataire, afin que ledit nœud réseau (40) puisse retransmettre ledit message vers le terminal destinataire (20).
4. Procédé selon la revendication 3, comprenant une étape de détermination, par le serveur de synchronisation (30), de l’émission (A1 10) du message (SMS1 ) du terminal source (10) vers une passerelle d’acheminement (50), la transmission (S142) du message du serveur de synchronisation (30) vers le nœud réseau (50) n’ayant lieu que si le résultat de cette détermination est positif.
5. Procédé selon la revendication 4, dans lequel l’étape de détermination est réalisée au moyen de la détection d’un indicateur d’activation de l’émission (A1 10) du message (SMS1 ) du terminal source (10) vers une passerelle d’acheminement (50), inséré dans le premier message de synchronisation (SYNC[SMS1 ]).
6. Procédé selon l’une des revendications 1 à 5, comprenant en outre la mémorisation (S140), par le serveur de synchronisation (30), du message destiné au terminal destinataire, extrait du premier message de synchronisation, afin de permettre la récupération par ledit au moins un terminal associé (10’, 10”) du message destiné au terminal destinataire.
7. Procédé selon l’une des revendications 1 à 6, dans lequel le message (SMS1 ) destiné au terminal destinataire est un message au format SMS.
8. Procédé selon l’une des revendications 1 à 7, dans lequel le premier et/ou le deuxième message de synchronisation est un message conforme à un protocole parmi les protocoles IMAP, JMAP, OMA DS ou OMA NMS.
9. Serveur de synchronisation (30) comprenant un module de communication (31 ) apte à échanger des messages de synchronisation avec un premier terminal (10), dit terminal source, et au moins un deuxième terminal (10’, 10”), dit terminal associé, partageant un même identifiant (MSISDN10) avec le terminal source, et un module de traitement (33) configuré pour extraire un message (SMS1 ) destiné à un troisième terminal (20), dit terminal destinataire, d’un premier message de synchronisation (SYNC[SMS1 ]) reçu par le module de communication et pour insérer ledit message dans un deuxième message de synchronisation (SYNC’[SMS1 ]) à transmettre vers ledit au moins un terminal associé (10’, 10”).
10. Serveur de synchronisation (30) selon la revendication 9, dans lequel le module de traitement est configuré en outre pour transmettre le message extrait (SMS1 ) à un nœud réseau (40) chargé du stockage et de la retransmission de messages, afin que ledit nœud réseau puisse retransmettre ledit message vers le terminal destinataire (20).
1 1. Terminal (10) comprenant un module de communication (17) et un module traitement (13), le module de traitement étant configuré pour insérer un message (SMS1 ) destiné à un autre terminal (20), dit terminal destinataire, dans un message de synchronisation et le module de communication étant configuré pour émettre ledit message de synchronisation (SYNC[SMS1 ]) vers un serveur de synchronisation (30), afin qu’au moins un autre terminal (10’, 10”), dit terminal associé, puisse récupérer le message destiné au terminal destinataire auprès dudit serveur de synchronisation.
12. Terminal (10) selon la revendication 1 1 , dans lequel le module de traitement (13) est configuré en outre pour instruire au module de communication (17) de transmettre le message (SMS1 ) vers une passerelle d’acheminement (50) permettant sa retransmission dans le plan de signalisation vers le terminal destinataire (20).
13. Système pour la transmission d’un message (SMS1 ) destiné à un premier terminal (20), dit terminal destinataire, depuis un deuxième terminal (10), dit terminal source, vers au moins un troisième terminal (10’, 10”), dit terminal associé, partageant un même identifiant avec le terminal source, comprenant un serveur de synchronisation (30) selon l’une des revendications 9 ou 10 et ledit au moins un terminal associé (10’, 10”), configuré pour récupérer auprès du serveur de synchronisation (30) le message (SMS1 ) au moyen d’un message synchronisation (SYNC’[SMS1 ]).
14. Système selon la revendication 13, comprenant en outre un terminal source, ledit terminal source étant un terminal selon l’une des revendications 1 1 ou 12.
EP20713922.1A 2019-04-05 2020-04-01 Transmission de messages dans un contexte multi-terminaux Pending EP3949458A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1903653A FR3094862A1 (fr) 2019-04-05 2019-04-05 Transmission de messages dans un contexte multi-terminaux
PCT/EP2020/059200 WO2020201321A1 (fr) 2019-04-05 2020-04-01 Transmission de messages dans un contexte multi-terminaux

Publications (1)

Publication Number Publication Date
EP3949458A1 true EP3949458A1 (fr) 2022-02-09

Family

ID=67810767

Family Applications (1)

Application Number Title Priority Date Filing Date
EP20713922.1A Pending EP3949458A1 (fr) 2019-04-05 2020-04-01 Transmission de messages dans un contexte multi-terminaux

Country Status (4)

Country Link
US (1) US12526610B2 (fr)
EP (1) EP3949458A1 (fr)
FR (1) FR3094862A1 (fr)
WO (1) WO2020201321A1 (fr)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8331963B1 (en) * 2012-01-04 2012-12-11 Cellco Partnership D/B/A Verizon Wireless Enabling retrieval of a mobile messaging service message from multiple devices associated with a single mobile directory number

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5602976A (en) 1993-02-23 1997-02-11 Adobe Systems Incorporated Method and apparatus for saving printer memory
FR2865092B1 (fr) * 2004-01-09 2006-04-28 Freever Procede permettant a des utilisateurs disposant d'un telephone mobile d'echanger des messages texte ou multimedia notamment de type sms, mms ou 3g en mettant en oeuvre differents reseaux de telephonie
EP1613102A1 (fr) * 2004-06-29 2006-01-04 BMD Wireless AG Méthode et système de télécommunication permettant la livraison commandée des messages courts (SMS)
FR3053560A1 (fr) * 2016-06-29 2018-01-05 Orange Procede de redirection de message dans un reseau de telecommunications

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8331963B1 (en) * 2012-01-04 2012-12-11 Cellco Partnership D/B/A Verizon Wireless Enabling retrieval of a mobile messaging service message from multiple devices associated with a single mobile directory number

Also Published As

Publication number Publication date
US20220191654A1 (en) 2022-06-16
WO2020201321A1 (fr) 2020-10-08
US12526610B2 (en) 2026-01-13
FR3094862A1 (fr) 2020-10-09

Similar Documents

Publication Publication Date Title
US7171222B2 (en) Multimedia messaging method and system for transferring multimedia content
EP1352499B1 (fr) Systeme et procede d&#39;acheminement de service de messagerie multimedia
US8924593B2 (en) Apparatus and method for communication services network
FR2844948A1 (fr) Procede d&#39;archivage de messages multimedias
US20140220947A1 (en) Transmission of MMS Messages with the Conversion of Data Types and/or Data Formats
FR2893803A1 (fr) Methode de communication entre une cartre (u)sim en mode serveur et un client
FR2921531A1 (fr) Dispositif de traitement adaptatif de notifications apllicatives destinees a des terminaux de communication connectes a une infrastructure de transmission
EP2939450B1 (fr) Transmission d&#39;un message multimédia doublée par émission d&#39;un message textuel
CA2804562A1 (fr) Procede d&#39;etablissement d&#39;une communication sur internet entre terminaux mobiles, programme d&#39;ordinateur et support d&#39;enregistrement
EP3949458A1 (fr) Transmission de messages dans un contexte multi-terminaux
EP1558052B1 (fr) Procédé de localisation assistée de terminaux mobiles de communication d&#39;un réseau cellulaire, par utilisation d&#39;un canal de transport USSD
EP1850602B1 (fr) Procédé et système pour accélérer l&#39;accès à un contenu à partir d&#39;un terminal mobile
EP3949457A1 (fr) Transmission de messages dans un contexte multi-terminaux
EP2819074B1 (fr) Procédé de gestion d&#39;un carnet d&#39;adresses utilisateur déporté, et programme d&#39;ordinateur et serveur d&#39;applications afférents
EP4258137B1 (fr) Procédé de distribution de fichier entre systèmes 3gpp mcdata interconnectés
FR2977434A1 (fr) Procede et systeme de communication au sein d&#39;une communaute heterogene d&#39;utilisateurs
FR2908251A1 (fr) Procede et systeme de synchronisation de repertoires
EP2124410A1 (fr) Système, procédé, serveur d&#39;application et HSS pour l&#39;autoprovisionnement d&#39;au moins un service dans au moins un serveur d&#39;application d&#39;une architecture IMS
WO2006087455A1 (fr) Procede de transmission de messages multimedia et systeme pour la mise en œuvre du procede
WO2010139775A1 (fr) Systeme et procede d&#39;archivage de messages
WO2016156386A1 (fr) Système de diffusion de contenus audio et/ou vidéo par un réseau wifi local, et appareils mettant en œuvre le procédé

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20211018

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20250731