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

Transmission de messages dans un contexte multi-terminaux

Info

Publication number
EP3949457A1
EP3949457A1 EP20713921.3A EP20713921A EP3949457A1 EP 3949457 A1 EP3949457 A1 EP 3949457A1 EP 20713921 A EP20713921 A EP 20713921A EP 3949457 A1 EP3949457 A1 EP 3949457A1
Authority
EP
European Patent Office
Prior art keywords
message
terminal
sms1
destination terminal
synchronization
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
EP20713921.3A
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 EP3949457A1 publication Critical patent/EP3949457A1/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
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/12—Messaging; Mailboxes; Announcements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W56/00—Synchronisation arrangements
    • H04W56/001—Synchronization between nodes

Definitions

  • the present invention relates to the transmission of messages in a multi-terminal context, and in particular to the transmission of SMS type messages 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 natively linked to one of the terminals of the system, such a number then being able to be called an “extra-number”, or even a “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.
  • each terminal of the multi-terminal system -terminaux behaves completely independently of the other terminals of this system, without taking into account the existence of other terminals which are nevertheless associated with it 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.
  • destination terminal comprising the following steps, following receipt of the message by a routing gateway: transmission from the routing gateway to a synchronization server, of the message by means of a first signaling and recovery protocol, by said at least one terminal Associated B, of the message intended for the recipient terminal with the synchronization server by means of a first synchronization message.
  • the method further comprises the determination, by the routing gateway, of the membership of the destination terminal to a multi-terminal system comprising the destination terminal and said at least one associated terminal, the step recovery taking place only in the event of a positive result of said determination.
  • the method further comprises transmitting, from the routing gateway to the destination terminal, the message by means of a second signaling protocol.
  • the transmission, from the routing gateway to the destination terminal, of the message by means of a second signaling protocol is carried out only if it is determined, during the determination step, that the destination terminal does not belong to a multi-terminal system.
  • the method further comprises the storage, by the synchronization server, of the message following its reception from the routing gateway.
  • the message intended for the destination 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, JMAP, OMA DS or OMA NMS protocols.
  • the first and / or the second signaling protocol is a protocol among the SIP, MAP and NAS protocols.
  • a routing gateway comprising a communication module capable of receiving a message intended for a first terminal, said recipient terminal, according to a first signaling protocol and a processing module, configured to insert the message in a signaling message to be transmitted to a synchronization server in order to allow at least one second terminal, said associated terminal, sharing an identifier with the destination terminal, to retrieve said message from said synchronization server.
  • this processing module is further configured to instruct the communication module to transmit said message to the destination terminal by means of a signaling message according to a second signaling protocol.
  • this processing module is further configured to inhibit the transmission of said message by the communication module to the destination terminal.
  • a synchronization server comprising a communication module capable of receiving a signaling message according to a first signaling protocol, this signaling message containing a message intended for a first terminal, called the destination terminal, and a processing module configured for inserting the message received in at least a first synchronization message to be transmitted, by the communication module, to at least one second terminal, said associated terminal, sharing an identifier with said recipient terminal.
  • the processing module is further configured to insert the message in a second synchronization message to be transmitted, by the communication module, to said destination terminal.
  • a terminal capable of sharing the same identifier with another terminal, called a recipient terminal, comprising a processing module, a communication module configured to receive messages intended for said terminal, and a storage module configured to store said said terminal. messages intended for said terminal with a view to presenting it to a user.
  • the communication module is further configured to receive, from a synchronization server, a synchronization message containing a message intended for the destination terminal, and the processing module is configured to extract, from the message synchronization received, the message intended for the destination terminal and to deliver said message to the storage module in order to store said message therein with a view to presenting it to a user with the messages intended for said 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.
  • recipient comprising a routing gateway and a synchronization server as presented above.
  • this system further comprises at least one terminal as presented above.
  • Figure 1 schematically shows the architecture provided for the transmission of SMS message, as currently standardized
  • FIG. 2 shows an embodiment of the message transmission method according to the present invention
  • FIG. 3 shows another embodiment of the message transmission method according to the present invention
  • Figure 4 illustrates a routing gateway according to one embodiment of the present invention
  • FIG. 5 illustrates a synchronization server according to an embodiment of the present invention.
  • FIG. 6 illustrates a terminal according to an embodiment of the present invention.
  • FIG. 1 schematically illustrates a currently conceivable architecture, based on 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 transmits (step A1 10) this SMS message to a routing gateway belonging to the communication network B to which the destination terminal is attached, so that this gateway can address this message to this UE-B terminal as soon as the latter becomes reachable.
  • a transmission typically breaks down into a first transmission of the SMS message according to a SIP (for “Session Initiation Protocol”) or NAS (“Non Access Stratum”) signaling protocol, from the UE-A terminal to a gateway.
  • SIP Session Initiation Protocol
  • NAS Non Access Stratum
  • this gateway then retransmitting this SMS message according to a MAP signaling protocol (for "Mobile Application Part” in English) to a network node of the SMSC type, for "Short Message Service Center ”in English (substep 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 subscribed.
  • a MAP signaling protocol for "Mobile Application Part” in English
  • a network node of the SMSC type for "Short Message Service Center ”in English
  • this SMSC network node transmits (substep A1 14) the SMS message to a B_SMS routing gateway of this network B, by means of the protocol MAP signaling (this B_SMS gateway being typically an IP-SM-GW gateway in the case of a 4G access network or an MSC node in the case of a 2G or 3G access network).
  • this B_SMS gateway being typically an IP-SM-GW gateway in the case of a 4G access network or an MSC node in the case of a 2G or 3G access network).
  • this routing gateway B_SMS of the network B has been configured beforehand to transmit any SMS message intended for the destination terminal UE-B to other terminals which are associated with it (here the two terminals UE-B 'and UE-B ”Purely by way of illustration), this routing gateway must then proceed with the duplication (step A120) of this SMS message in as many messages as there are associated terminals, in order to transmit (step A130) this SMS message to the destination terminal UE-B using a signaling protocol (here the SIP protocol by way of example), to transmit (step A130 ') this same SMS message to the first associated terminal UE-B' still using a signaling protocol and to transmit (step A130 ”) this same SMS message to the second associated terminal UE-B” still using a signaling protocol.
  • a signaling protocol here the SIP protocol by way of example
  • a first terminal 10 called source terminal hereafter, wishes to send a message to a second terminal 20, called destination terminal hereafter.
  • 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 intended for use. transmitted, between terminals and, in particular between mobile terminals, only in the signaling plane.
  • the destination terminal 20 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 in particular be the same telephone number (ie the same MSISDN identifier) serving as a unique identifier in a defined numbering plan, 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 in particular be the same telephone number (ie the same MSISDN identifier) serving as a unique identifier in a defined numbering plan, 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.
  • FIG. 2 illustrates the case of a multi-terminal system with three associated terminals, in which two other “associated” terminals 20 'and 20 ”are associated with the destination terminal 20, and therefore share with it a same identifier “MSISDN 2 o” (in this case the identifier of the destination terminal 20), without the invention being limited to this single case, a number N (with N> 1) of terminals which can be associated with the terminal recipient 20 within such a system.
  • MSISDN 2 o in this case the identifier of the destination terminal 20
  • the associated terminals within a multi-terminal system can in particular be mobile terminals (smartphones, connected watches, tablets, among others), as well as 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 associated terminals 20 ′ and 20 ′′ (or even also the destination terminal 20, as will be seen later) exchange synchronization messages, designated here by “SYNC”.
  • client synchronization modules are installed, typically in software form, in the associated terminals 20 'and 20 ”(or also in the destination terminal 20 as will be seen below) while a synchronization server module, typically in software form, is installed in the synchronization server 30, these modules being synchronized so that the client modules are notified of changes in content of the server module of the synchronization server, or in real time as soon as such a change takes place, either in a deferred manner when one of the client modules interrogates the server module in order to know the changes which 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 the IMAP protocol) OMA DS (for “Data Synchronization” in English) or OMA NMS (for “Network Message Storage” in English), for example.
  • the terminals 20 'and 20 ”(or also the terminal 20) synchronize with the synchronization server 30 by exchanging synchronization messages in accordance with a synchronization protocol such as one of the aforementioned protocols, mentioned above. as an example of a synchronization protocol.
  • the terminals 20 ′ and 20 ′′ associated with the destination terminal 20 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 MSISDN20 of the destination terminal 20, 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.
  • step S1 1 When an SMS1 message (here a message in the SMS format) is to be transmitted from the source terminal 10 to the destination terminal 20, the terminal 10 transmits (step S1 1 1) this SMS1 message according to a signaling protocol (here illustrated as being the SIP protocol) to a first routing gateway 50 (here illustrated without limitation by a gateway of IP-SM-GW type) belonging to the network to which the terminal 10 is attached, which retransmits (step S1 12) this message SMS1 to the means of a signaling protocol (here illustrated by the MAP protocol) to a network node 40 (here illustrated by an SMSC node) which stores this message (step S1 13) before retransmitting it (step S1 14) to a second gateway routing 50 '(here illustrated without limitation by a gateway of the IP-SM-GW type) by means of a signaling protocol (illustrated here by the MAP protocol).
  • a signaling protocol here illustrated as being the SIP protocol
  • a first routing gateway 50 here illustrated without limitation
  • Such a retransmission can be done immediately (upon receipt of the message) and, if it fails, can be retried periodically until it succeeds, or else be retried once the network node 40 has been alerted by the network B of the availability. of the destination terminal 20.
  • the second routing gateway 50 transmits (step S1 15) this SMS message to the destination terminal 20, within the network B to which this terminal 20 is attached, according to a signaling protocol which can be the SIP protocol, or a combination of the MAP and NAS protocols (for “Non-Access Stratum”), for example.
  • a signaling protocol which can be the SIP protocol, or a combination of the MAP and NAS protocols (for “Non-Access Stratum”), for example.
  • the second routing gateway 50 ' can transmit (step S130) the SMS1 message to the synchronization server 30 according to a signaling protocol, for example the MAP protocol as illustrated without limitation in FIG. 2, or even the OMA NMS protocol, among other protocols suitable for transmission signaling messages between routing gateway and synchronization server.
  • a signaling protocol for example the MAP protocol as illustrated without limitation in FIG. 2, or even the OMA NMS protocol, among other protocols suitable for transmission signaling messages between routing gateway and synchronization server.
  • the second routing gateway 50 has been advantageously configured beforehand to know the network address of this synchronization server 30, in order to be able to send it a signaling message containing the message SMS1, as well as to determine s' it is necessary, or not, to trigger the transmission of the transmission of this message SMS1 to this synchronization server 30, typically as a function of an identifier retrieved in the signaling message received from the routing gateway 50 ′, in particular from the identifier of the destination terminal indicated in a field of the SMS1 message.
  • the routing gateway 50 when it receives an SMS1 message from the network node 40, the routing gateway 50 'can then determine (step S120) whether this SMS1 message must also be transmitted to the synchronization server 30, in addition to being transmitted to the destination terminal 20.
  • This determination step can be performed as a function of an identifier associated with the destination terminal of the SMS1 message received from the network node 40, typically the MSISDN of the destination terminal as indicated in this SMS1 message.
  • the routing gateway 50 ' can check whether this identifier has been previously stored by the routing gateway 50' (or by querying a database, for example an HLR) as being the identifier of a terminal belonging to a multi-terminal system involving several terminals, that is to say to the identifier of a destination terminal for which messages should be transmitted to the synchronization server 30.
  • the method stops at this stage and only the destination terminal 20 receives the message SMS1 (step S1 15) in the signaling plane, in the traditional manner.
  • the routing gateway 50 'then proceeds to the transmission (step S130) of this message SMS1 to the synchronization server 30, by inserting this message SMS1 in a signaling message conforming to a signaling protocol suitable for exchanges of signaling between routing gateways and synchronization servers, here the MAP protocol (but could also be the OMA NMS protocol).
  • a signaling protocol suitable for exchanges of signaling between routing gateways and synchronization servers
  • this determination step S120 can take place either before or after the transmission step S1 15 to the destination terminal 120, insofar as this transmission S115, in the signaling plane, of the message SMS1 is systematically performed in this mode implementation, whether the destination terminal belongs to a multi-terminal system or not.
  • the synchronization server 30 stores (step S140) this message SMS1, after having extracted it from the signaling message in which it was received, or even within a storage module of this server , or in a database associated with this server.
  • the associated terminals 20 'and 20 ” can then retrieve the SMS1 message, intended for the destination terminal 20, from the synchronization server 30, by means of synchronization messages conforming to a synchronization protocol suitable for synchronization in mode.
  • client-server such as IMAP, JMAP, OMA DS or OMA NMS, among others.
  • the synchronization server 30 retrieves the message SMS1 intended for the destination terminal 20 and inserts it into a synchronization message SYNC ′ [SMS1] which 'it transmits to this terminal 20' (step S150 ').
  • the server 30 does the same for all the other associated terminals, in this case for the terminal 20 "(step S150") to which it transmits a synchronization message SYNC "[SMS1] in which it has inserted the message SMS1.
  • 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 shown in the example below:
  • 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 message SMS1 (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: ⁇ obj ect>
  • 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:
  • the SYNC synchronization message '[SMS1] used to transmit the SMS1 message to the associated terminal 20' can be the same as the SYNC synchronization message ”[SMS1] used to transmit the SMS1 message to the associated terminal 20 ”, or even be a synchronization message of a different type but conforming to the same synchronization protocol, or else conforming to a different synchronization protocol. All these synchronization messages are transmitted in the data transport plane, and not in the signaling plane as would be the case if the message SMS1 were to be duplicated and transmitted to each associated terminal.
  • Each associated terminal 20 'and 20 "can then, after having received respectively these synchronization messages SYNC' and SYNC", extract the message SMS1 intended for the destination terminal 20 and store it in their own respective memories, for subsequent consultation or reproduction by an user.
  • all the terminals associated with the destination terminal 20 have the SMS1 message to be received by the destination terminal 20, as well as information associated with this message, such as the time of sending of the message, the where the message was sent, read status, reply indicator, etc.
  • the user of a multi-terminal system therefore has access to the same message reception history, regardless of the terminal he is accessing.
  • FIG. 3 illustrates a message transmission method according to another embodiment of the present invention.
  • This other embodiment is relatively similar to that illustrated in FIG. 2, with the difference that after having received the message SMS1, the routing gateway 50 'of the network to which the destination terminal is subscribed does not necessarily transmit it directly. at the destination terminal, in the signaling plane, but can on the contrary leave it to the synchronization server to take care of it, in the data transport plane.
  • the traditional step (illustrated by S1 15 in FIG. 2) of transmitting the message SMS1 to the destination terminal 20 according to a signaling protocol can be hereby inhibited, and therefore does not systematically take place.
  • the routing gateway 50 determine (step S220) whether this message SMS1 must be transmitted to the synchronization server 30, this determination which can be carried out in a similar manner to step S120 described in relation to FIG. 2.
  • a signaling protocol here illustrated by the SIP protocol, but which can also be the combination of MAP and NAS protocols for example
  • step S225 is inhibited and does not take place
  • this message SMS1 is inserted in a signaling message conforming to a signaling protocol suitable for signaling exchanges between routing gateways and synchronization server (here the MAP protocol by way of example) and transmitted (step S230) to the synchronization server 30.
  • a signaling protocol suitable for signaling exchanges between routing gateways and synchronization server here the MAP protocol by way of example
  • the routing gateway 50 ' can insert in this signaling message an indicator, interpretable by the server 30, indicating that the message SMS1 was not transmitted to the destination terminal 20 by the gateway 50 '.
  • the synchronization server 30 extracts this message SMS1 and stores it (step S240), either within a storage module of this server, or in an associated database. to this server.
  • the destination terminal 20 can then retrieve the message SMS1, intended for the destination terminal 20, from the synchronization server 30, by means of synchronization messages in accordance with a synchronization protocol adapted to client-server synchronization, such as IMAP, JMAP, OMA DS or OMA NMS, among others.
  • a synchronization protocol adapted to client-server synchronization such as IMAP, JMAP, OMA DS or OMA NMS, among others.
  • the synchronization server 30 retrieves the message SMS1 intended for the destination terminal 20 and inserts it in a second synchronization message SYNC' [SMS1 ] which it transmits to this terminal 20 '(step S250'). It does the same for all the other associated terminals, in this case for the terminal 20 "(step S250") to which it transmits a third synchronization message SYNC "[SMS1] in which it has inserted the message SMS1.
  • the synchronization server 30 can be configured to systematically retrieve the message SMS1 intended for this destination terminal 20 and insert it in a first synchronization message SYNC [SMS1] which 'it transmits to this terminal 20 (step S250), without taking into account a possible direct transmission to the terminal 20 of this message SMS1 in the signaling plan.
  • the method can comprise an optional step (step S245) of determination, by the synchronization server, in order to transmit a synchronization message SYNC [SMS1] to the destination terminal 20 only when it is not determined. has not already been transmitted, in the signaling plane, by the routing gateway 50 '.
  • This determination can in particular be carried out by verifying the presence, in the signaling message received from the routing gateway 50 ′ during step S230, of an indicator indicating that the message SMS1 has not been transmitted (or on the contrary, it was transmitted) to the destination terminal 20 by the gateway 50 '.
  • the synchronization messages SYNC [SMS1], SYNC '[SMS1] and SYNC ”[SMS1] used to transmit the message SMS1 respectively to terminals 20, 20' and 20” can be one and the same type of synchronization message, or even be synchronization messages of different types but conforming to the same synchronization protocol, or else respectively conforming to different synchronization protocols.
  • Each terminal 20, 20 'and 20 can then, after having received respectively these synchronization messages SYNC, SYNC' and SYNC", extract the message SMS1 intended for the destination terminal 20 and store it in their own memories. respective ones, for consultation or subsequent restitution by a user.
  • all the terminals associated with the destination terminal have the message SMS1 to be received by the destination terminal, as well as the information associated with this message, as described above.
  • FIG. 4 illustrating a routing gateway according to one embodiment of the present invention.
  • This routing gateway 50 comprises in particular a communication module 51 (typically implemented in the form of a transceiver) configured to receive, from a network node 40 responsible for storing and transmitting messages in the plane. signaling, a signaling message (illustrated by “MAP [SMS1]”) conforming to a signaling protocol suitable for signaling exchanges between network node and routing gateway (here the MAP protocol) in which an SMS1 message has been inserted to be transmitted to a destination terminal 20.
  • MAP [SMS1] signaling message conforming to a signaling protocol suitable for signaling exchanges between network node and routing gateway (here the MAP protocol) in which an SMS1 message has been inserted to be transmitted to a destination terminal 20.
  • This communication module 51 is also configured to transmit, to a synchronization server 30, a signaling message (illustrated by “MAP [SMS1]”) conforming to a signaling protocol suitable for signaling exchanges between routing gateway and server.
  • a signaling message illustrated by “MAP [SMS1]”
  • MAP [SMS1] a signaling protocol suitable for signaling exchanges between routing gateway and server.
  • synchronization here also the MAP protocol
  • this SMS1 message has been inserted, as well as possibly an indicator indicating the possible absence of transmission of this SMS1 message from this gateway directly to the destination terminal 20.
  • this communication module 51 is also configured to transmit, to the destination terminal 20, a signaling message conforming to a signaling protocol suitable for signaling exchanges between routing gateway and terminals ( here the SIP protocol, but could also be the MAP or NAS protocol, for example) in which this SMS1 message was inserted.
  • a signaling protocol suitable for signaling exchanges between routing gateway and terminals here the SIP protocol, but could also be the MAP or NAS protocol, for example
  • This routing gateway 50 further comprises a processing module 53 (typically implemented in the form of one or more processor (s) executing computer program instructions stored by the routing gateway), configured first of all to process the signaling messages received from the network node 40, and in particular to extract therefrom an SMS1 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. 4 by the message “MAP [SMS1]”).
  • This SMS1 message once extracted from the “MAP [SMS1]” signaling message, can be analyzed in order to retrieve an identifier associated with the terminal 20 for which it is intended (here its identifier “MSISDN 2 o) ⁇
  • the processing module 53 can determine whether the destination terminal 20 belongs to a multi-terminal system previously signaled to the gateway 50 ′, by means of this identifier.
  • the processing module 53 interrogates a storage module 55 (typically a non-volatile memory, which is here illustrated as being included in the routing gateway 50 ', but being able to also be implemented in the form of a database separate from this gateway, to which this gateway has access) to check whether this identifier is stored there.
  • a storage module 55 typically a non-volatile memory, which is here illustrated as being included in the routing gateway 50 ', but being able to also be implemented in the form of a database separate from this gateway, to which this gateway has access
  • the processing module 53 can then insert the SMS1 message into a signaling message according to a signaling protocol suitable for the terminals (here the SIP protocol, but could be the MAP or NAS protocol , for example) and instruct the communication module 51 to transmit this signaling message to the destination terminal 20, without requesting the synchronization server 30.
  • a signaling protocol suitable for the terminals here the SIP protocol, but could be the MAP or NAS protocol , for example
  • the processing module 53 can then insert the message SMS1 in a signaling message suitable for exchanges with a synchronization server (here the MAP protocol) and instruct the communication module 51 to do so. transmit to the synchronization server 30.
  • a synchronization server here the MAP protocol
  • the processing module 53 can determine whether it is appropriate to insert this SMS1 message in a signaling message suitable for exchanges with terminals (eg the SIP, MAP or NAS protocol) and d '' instruct the communication module 51 to transmit this signaling message directly to the destination terminal 20, or on the contrary not to do (in which case it is then up to the destination terminal 20 to retrieve this message SMS1 directly from the synchronization server).
  • a signaling message suitable for exchanges with terminals eg the SIP, MAP or NAS protocol
  • a parameter indicative of a direct transmission to the destination terminal, in the signaling plane can be associated with the identifier indicating the membership of the destination terminal to a multi-terminal system, during the prior storage of this identifier by the routing gateway 50 ', in the storage module 55.
  • the processing module 53 determines that the recovered identifier is stored in the storage module 55 (and therefore that the destination terminal belongs to a multi-terminal system)
  • the processing module can also determine whether it is appropriate to transmit the SMS1 message directly to this destination terminal 20, checking for the presence of a parameter indicative of such direct transmission in the signaling plane.
  • the identifier “MSISDN20” is associated with the parameter “+” indicating that a direct transmission in the signaling plane is to be carried out.
  • the identifier “MSISDN 30” is associated with the parameter “-” indicating that a direct transmission in the signaling plane is to be inhibited, and therefore that the destination terminal 30 must recover itself, from the synchronization server. , the messages intended for it.
  • the processing module 53 comprises what is stored in the storage module 55, not only that one or more synchronization messages should be prepared, including the message SMS1, to be transmitted to the terminals associated with the terminal 20, but also a signaling message should be prepared including this message SMS1 to be transmitted to the terminal 20.
  • the processing module can insert, in the signaling message intended for the synchronization server 30, an indication that this synchronization server does not need to send a synchronization message to the destination terminal 20.
  • the processing module 53 comprises what is stored in the storage module 55, which it is only necessary to prepare one or more synchronization messages, including this message, to be transmitted to the terminals associated with the terminal 30, without preparing a signaling message including this message to be transmitted directly to the terminal 30.
  • the processing module can insert, in the signaling message intended for the synchronization server 30, an indication that this synchronization server must allow the destination terminal 20 to retrieve the message SMS1, for example by inserting this message SMS1 in a synchronization message that it transmits to it.
  • the indication mentioned in the two preceding cases is then up to the destination terminal 20 to detect that it has already received the message SMS1 directly, and therefore that it does not need to retrieve it from of the synchronization server.
  • the SMS messages sent to such a type of identifier are always transmitted in the signaling plane, and therefore without retrieval from the synchronization server.
  • the synchronization server can then be configured, by means of a global parameter, to apply such a network policy.
  • 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 receive, from a routing gateway 50 ', a signaling message comprising a message SMS1 intended for a destination terminal 20.
  • This communication module is also configured to exchange synchronization messages with the terminal or terminals 20 ′, 20 ”associated with the destination terminal 20, or even also with the destination terminal 20 itself.
  • the synchronization server 30 further comprises a processing module 33, configured first of all to process the signaling messages received from the routing gateway 50 ', and in particular to extract therefrom an SMS1 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 message MAP [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 read only memory in which these code instructions are stored.
  • This message SMS1 once extracted from the synchronization message MAP [SMS1], can then be stored in a storage module 35 (typically a non-volatile memory), which is here illustrated as being included in the synchronization server 30, but which 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 a non-volatile memory
  • the storage of this message, in the storage module 35, can be done in association with an identifier of the destination terminal 20 (here, its identifier “MSISDN20”) 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 into a synchronization message SYNC '[SMS1] that it provides to the communication module 31 so that the latter transmits the synchronization message SYNC' [SMS1] to the associated terminal 20 'in question.
  • This operation is repeated for all the terminals associated with the destination terminal 20, to be synchronized by means of the server 30 (here also the terminal 20 ", to which the synchronization message SYNC" [SMS1] is transmitted). In one embodiment, this operation is also performed for the destination terminal 20 when it can be synchronized by means of a SYNC message [SMS1] sent by the server 30.
  • the SYNC [SMS1], SYNC '[SMS1] and SYNC ”[SMS1] messages can be sent spontaneously (ie without a prior request having been received to trigger the sending of this message) by the synchronization server 30 respectively to the terminals 20, 20 'and 20 ”, for example at regular intervals, in a“ push ”mode.
  • these synchronization messages can be messages sent in response to synchronization requests received by the synchronization server 30 respectively from the terminals 20, 20 'and 20 ”, in a so-called“ pull ”mode (such requests being illustrated by “REQ SYNC” in figure 5).
  • FIG. 6 illustrating a so-called “associated” terminal, sharing the same identifier as another terminal, called “recipient”, recipient of a message transmitted by a source terminal, according to an embodiment of the present invention.
  • This terminal 20 ′ (which may in particular be a mobile terminal of smartphone type) comprises in particular a communication module 21 ′ configured to receive, from a synchronization server 30 as described above, a synchronization message SYNC ′ [SMS1] in which the message SMS1 intended for a destination terminal 20 has been inserted.
  • This communication module 21 ' can also be configured to send (for example, but not necessarily, at predefined intervals) the synchronization request “REQ SYNC” discussed previously to this synchronization server 30, with a view to triggering the sending of the synchronization message SYNC ′ [SMS1] in return.
  • Such a communication module can be implemented in particular in the form of a radio transceiver, e.g. of one or more radio antenna (s) connected to a digital / analog converter.
  • the terminal 20 'further comprises a processing module 23' configured first of all to process the synchronization messages received from the synchronization server 30, and in particular to extract therefrom from such a synchronization message a message intended for a another destination terminal 20, for example an SMS format message, when such a message has been inserted therein (this case being illustrated here in FIG. 5 by the message SYNC '[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.
  • SMS1 message once extracted from the SYNC synchronization message [SMS1], can then be stored in a storage module 25 ′ (typically a non-volatile memory) also included in the terminal 20 ’.
  • a storage module 25 ′ typically a non-volatile memory
  • this SMS1 message extracted from the synchronization message can be stored with other SMSA, SMSB messages (ie in the storage area associated with this same type of message in the terminal 20 '), so that this message SMS1 is accessible to the user in the same way as any other message of the same type which would be received in a more traditional manner (ie without resorting to a synchronization server).
  • the terminal 20 ' also comprises a user interface module 27', typically in the form of a touch screen
  • the user consults his messages received from the mobile network (for example the messages in the SMS format), he will not only see the SMSA and SMSB messages received conventionally from the mobile network (ie without resorting to the synchronization server 30), but also the SMS1 message received from the synchronization server 30.
  • the module managing the user interface 27 ' can optionally distinguish (for example by means of different colors) these messages SMSA and SMSB, on the one hand, and SMS1 on the other hand, when they display them. in order to alert the user to the difference in origin of these messages.
  • this module presents these messages identically, so that the implementation of the present invention is transparent for the user, who sees only a series of messages of the same type, regardless of whether they have been. received traditionally or through synchronization with a synchronization server.
  • 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

La présente invention concerne un procédé de transmission d'un message (SMS1) destiné à un premier terminal (2), dit terminal destinataire, depuis un deuxième terminal (10), dit terminal source, vers au moins un troisième terminal (20', 20''), dit terminal associé, partageant un même identifiant avec le terminal destinataire, comprenant, suite à la réception (S114) du message par une passerelle d'acheminement (50'), la transmission (S130, S230), de la passerelle d'acheminement vers un serveur de synchronisation (30), du message (SMS1) au moyen d'un premier protocole de signalisation (MAP) et la récupération (S150', S250'), par le au moins un terminal associé (20', 20''), du message destiné au terminal destinataire auprès du serveur de synchronisation au moyen d'un premier message de synchronisation (SYNC'[SMS1]). Elle concerne également une passerelle d'acheminement, 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 la transmission de messages 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-dispositifs ».
En particulier, dans le cas de messages SMS reçus par un terminal mobile appartenant à 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 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 qui lui sont pourtant associés 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 destinataire, comprenant les étapes suivantes, suite à la réception du message par une passerelle d’acheminement: transmission de la passerelle d’acheminement vers un serveur de synchronisation, du message au moyen d’un premier protocole de signalisation et récupération, par ledit au moins un terminal B associé, du message destiné au terminal destinataire auprès du serveur de synchronisation au moyen d’un premier message de synchronisation.
Dans un mode de réalisation avantageux, le procédé comprend en outre la détermination, par la passerelle d’acheminement, de l’appartenance du terminal destinataire à un système multi-terminaux comprenant le terminal destinataire et ledit au moins un terminal associé, l’étape de récupération n’ayant lieu qu’en cas de résultat positif de ladite détermination.
Dans un mode de réalisation avantageux, le procédé comprend en outre la transmission, de la passerelle d’acheminement au terminal destinataire, du message au moyen d’un deuxième protocole de signalisation.
Selon un mode de réalisation particulier, la transmission, de la passerelle d’acheminement au terminal destinataire, du message au moyen d’un deuxième protocole de signalisation n’est réalisée que s’il est déterminé, lors de l’étape de détermination, que le terminal destinataire n’appartient pas à un système multi- terminaux.
Selon un mode de réalisation particulier, le procédé comprend en outre la récupération, par ledit terminal destinataire, du message destiné au terminal destinataire auprès du serveur de synchronisation au moyen d’un deuxième message de synchronisation. En particulier, la récupération, par ledit terminal destinataire, du message destiné au terminal destinataire auprès du serveur de synchronisation au moyen d’un deuxième message de synchronisation peut n’être réalisée que s’il est déterminé que le message n’a pas été transmis de la passerelle d’acheminement au terminal destinataire au moyen d’un message de signalisation.
Selon un mode de réalisation particulier, le procédé comprend en outre la mémorisation, par le serveur de synchronisation, du message suite à sa réception en provenance de la passerelle d’acheminement.
Dans un mode de réalisation particulier, 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, JMAP, OMA DS ou OMA NMS. Dans un mode particulier de réalisation, le premier et/ou le deuxième protocole de signalisation est un protocole parmi les protocoles SIP, MAP et NAS.
Il est également proposé une passerelle d’acheminement comprenant un module de communication apte à recevoir un message destiné à un premier terminal, dit terminal destinataire, selon un premier protocole de signalisation et un module de traitement, configuré pour insérer le message dans un message de signalisation à transmettre vers un serveur de synchronisation afin de permettre à au moins un deuxième terminal, dit terminal associé, partageant un identifiant avec le terminal destinataire, de récupérer ledit message auprès dudit serveur de synchronisation.
Selon un mode particulier de réalisation, ce module de traitement est configuré en outre pour instruire au module de communication de transmettre ledit message vers le terminal destinataire au moyen d’un message de signalisation selon un deuxième protocole de signalisation.
Selon un mode particulier de réalisation, ce module de traitement est configuré en outre pour inhiber la transmission dudit message par le module de communication au terminal destinataire.
Il est également proposé un serveur de synchronisation comprenant un module de communication apte recevoir un message de signalisation selon un premier protocole de signalisation, ce message de signalisation contenant un message destiné à un premier terminal, dit terminal destinataire, et un module de traitement configuré pour insérer le message reçu dans au moins un premier message de synchronisation à transmettre, par le module de communication, vers au moins un deuxième terminal, dit terminal associé, partageant un identifiant avec ledit terminal destinataire.
Selon un mode particulier de réalisation, le module de traitement est configuré en outre pour insérer le message dans un deuxième message de synchronisation à transmettre, par le module de communication, vers ledit terminal destinataire.
Il est également proposé un terminal, apte à partager un même identifiant avec un autre terminal, dit terminal destinataire, comprenant un module de traitement, un module de communication configuré pour recevoir des messages destinés audit terminal, et un module de stockage configuré pour mémoriser lesdits messages destinés audit terminal en vue de le présenter à un utilisateur. Dans ce terminal, le module de communication est configuré en outre pour recevoir, en provenance d’un serveur de synchronisation, un message de synchronisation contenant un message destiné au terminal destinataire , et le module de traitement est configuré pour extraire, à partir du message de synchronisation reçu, le message destiné au terminal destinataire et pour fournir ledit message au module de stockage afin d’y mémoriser ledit message en vue de le présenter à un utilisateur avec les messages destinés audit terminal. 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 destinataire, comprenant une passerelle d’acheminement et un serveur de synchronisation tels que présentés ci-avant. Dans un mode de réalisation, ce système comprend en outre au moins 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 une passerelle d’acheminement selon un mode de réalisation de la présente invention ;
La figure 5 illustre un serveur de synchronisation selon un mode de réalisation de la présente invention ; et
La figure 6 illustre un terminal 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 une architecture actuellement envisageable, basée sur 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, une fois qu’un message de type SMS destiné à un terminal mobile destinataire UE-B a été saisi par un utilisateur sur le terminal mobile UE-A, le terminal mobile UE-A transmet (étape A1 10) ce message SMS vers une passerelle d’acheminement appartenant au réseau B de communication auquel le terminal destinataire est attaché, afin que cette passerelle puisse adresser ce message vers ce terminal UE-B dès que celui-ci devient joignable. Une telle transmission se décompose typiquement en une première transmission du message SMS selon un protocole de signalisation SIP (pour « Session Initiation Protocol » en anglais) ou NAS (« Non Access Stratum » en anglais), du terminal UE-A vers une passerelle d’acheminement A_SMS (qui est typiquement une passerelle IP-SM-GW dans le cas d’un réseau d’accès 4G ou un nœud MSC dans le cas d’un réseau d’accès 2G ou 3G) qui lui est affectée dans le réseau A auquel il est attaché (sous-étape A1 1 1 ), cette passerelle retransmettant alors ce message SMS selon un protocole de signalisation MAP (pour « Mobile Application Part » en anglais) 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 abonné. Par la suite, lorsque la disponibilité du terminal destinataire UE-B est signalée à ce nœud réseau SMSC, celui transmet alors (sous- étape A1 14) le message SMS vers une passerelle d’acheminement B_SMS de ce réseau B, au moyen du protocole de signalisation MAP (cette passerelle B_SMS étant typiquement une passerelle IP-SM-GW dans le cas d’un réseau d’accès 4G ou un nœud MSC dans le cas d’un réseau d’accès 2G ou 3G).
Si cette dernière passerelle d’acheminement B_SMS du réseau B a été configurée au préalable pour transmettre tout message SMS destiné au terminal destinataire UE-B vers d’autres terminaux qui lui sont associés (ici les deux terminaux UE-B’ et UE-B” à titre purement illustratif), cette passerelle d’acheminement doit alors procéder à la duplication (étape A120) de ce message SMS en autant de messages qu’il y a de terminaux associés, afin de transmettre (étape A130) ce message SMS au terminal destinataire UE-B en utilisant un protocole de signalisation (ici le protocole SIP à titre d’exemple), de transmettre (étape A130’) ce même message SMS au premier terminal associé UE-B’ toujours en utilisant un protocole de signalisation et de transmettre (étape A130”) ce même message SMS au deuxième terminal associé UE- B” toujours en utilisant un protocole de signalisation.
Comme on peut le constater, ce mécanisme se révèle particulièrement fastidieux et consommateur de ressources dans le plan de signalisation, proportionnellement au nombre de terminaux associés qui sont concernés.
Il est fait maintenant référence à la Figure 2, laquelle illustre un procédé de transmission de message selon un mode de réalisation de la présente invention. Dans ce 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 à destinés à être transmis, entre terminaux et, notamment entre terminaux mobiles, uniquement dans le plan de signalisation.
Dans le cas présent, le terminal destinataire 20 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 notamment être un même numéro de téléphone (i.e. le même identifiant MSISDN) servant d’identifiant univoque dans un plan de numérotation défini, 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 » 20’ et 20” sont associés avec le terminal destinataire 20, et donc partagent avec lui un même identifiant « MSISDN2o » (en l’occurrence l’identifiant du terminal destinataire 20), 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 20 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), ainsi que 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 destinataire et les terminaux associés à ce terminal destinataire, ce mode de réalisation fait intervenir un serveur de synchronisation 30, avec lequel les terminaux associés 20’ et 20” (voire également le terminal destinataire 20, comme il sera vu plus loin) échangent des messages de synchronisation, désignés ici par « SYNC ».
A ce titre, des modules clients de synchronisation sont installés, typiquement sous forme logicielle, dans les terminaux associés 20’ et 20” (voire également dans le terminal destinataire 20 comme il sera vu plus loin) tandis qu’un module serveur de synchronisation, typiquement sous forme logicielle, est installé dans le serveur de synchronisation 30, 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 (pour « Data Synchronisation » en anglais) ou OMA NMS (pour « Network Message Storage » en anglais), par exemple. En d’autres termes, les terminaux 20’ et 20” (voire également le terminal 20) se synchronisent avec le serveur de synchronisation 30 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.
Comme il sera expliqué ci-après, le recours à un tel serveur de synchronisation permet de surmonter l’impossibilité qu’il y a, avec les systèmes de messagerie conventionnels décrits précédemment, à recevoir un message sur les différents terminaux d’un système multi-terminaux partageant un même identifiant.
Dans une étape préalable (non illustrée) au présent procédé, les terminaux 20’ et 20” associés au terminal destinataire 20 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 MSISDN20 du terminal destinataire 20, 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 le terminal destinataire 20, le terminal 10 transmet (étape S1 1 1 ) ce message SMS1 selon un protocole de signalisation (ici illustré comme étant le protocole SIP) vers une première passerelle d’acheminement 50 (ici illustré non limitativement par une passerelle de type IP-SM-GW) appartenant au réseau auquel le terminal 10 est attaché, laquelle retransmet (étape S1 12) ce message SMS1 au moyen d’un protocole de signalisation (ici illustré par le protocole MAP) vers un nœud réseau 40 (ici illustré par un nœud SMSC) qui mémorise ce message (étape S1 13) avant de le retransmettre (étape S1 14) vers une deuxième passerelle d’acheminement 50’ (ici illustré non limitativement par une passerelle de type IP-SM- GW) au moyen d’un protocole de signalisation (illustré ici par le protocole MAP). Une telle retransmission peut se faire immédiatement (dès réception du message) et, si elle échoue, peut être retentée périodiquement jusqu’à ce qu’elle réussisse, ou bien être retentée une fois le nœud réseau 40 alerté par le réseau B de la disponibilité du terminal destinataire 20.
Une fois reçu le message SMS1 , la deuxième passerelle d’acheminement 50’ transmet (étape S1 15) alors ce message SMS vers le terminal destinataire 20, au sein du réseau B auquel ce terminal 20 est attaché, selon un protocole de signalisation qui peut être le protocole SIP, ou une combinaison des protocoles MAP et NAS (pour « Non-Access Stratum » en anglais), par exemple.
Après avoir reçu le message SMS1 du nœud réseau 40, et parallèlement à l’envoi de ce message SMS1 vers le terminal 20 (c’est-à-dire avant, pendant ou après cet envoi), la deuxième passerelle d’acheminement 50’ peut transmettre (étape S130) le message SMS1 au serveur de synchronisation 30 selon un protocole de signalisation, par exemple le protocole MAP comme illustré à titre non limitatif sur la figure 2, ou encore le protocole OMA NMS, entre autres protocoles adaptés pour la transmission de messages de signalisation entre passerelle d’acheminement et serveur de synchronisation.
A cette fin, la deuxième passerelle d’acheminement 50’ a été avantageusement configurée au préalable pour connaître l’adresse réseau de ce serveur de synchronisation 30, pour pouvoir lui transmettre un message de signalisation contenant le message SMS1 , ainsi que pour déterminer s’il faut, ou non, déclencher la transmission la transmission de ce message SMS1 vers ce serveur de synchronisation 30, typiquement en fonction d’un identifiant récupéré dans le message de signalisation reçu depuis la passerelle d’acheminement 50’, en particulier de l’identifiant du terminal destinataire indiqué dans un champ du message SMS1.
Ainsi, lorsqu’elle reçoit un message SMS1 depuis le nœud réseau 40, la passerelle d’acheminement 50’ peut alors déterminer (étape S120) si ce message SMS1 doit aussi être transmis au serveur de synchronisation 30, en plus d’être transmis au terminal destinataire 20.
Cette étape de détermination peut être réalisée en fonction d’un identifiant associé au terminal destinataire du message SMS1 reçu depuis le nœud réseau 40, typiquement le MSISDN du terminal destinataire tel qu’indiqué dans ce message SMS1. En particulier, la passerelle d’acheminement 50’ peut vérifier si cet identifiant a été préalablement mémorisé par la passerelle d’acheminement 50’ (ou en interrogeant une base de données, par exemple un HLR) comme étant l’identifiant d’un terminal appartenant à un système multi-terminaux impliquant plusieurs terminaux, c’est-à-dire à l’identifiant d’un terminal destinataire pour lequel il convient de transmettre les messages au serveur de synchronisation 30.
Si le résultat de cette détermination s’avère négatif (par exemple dans le cas où le terminal destinataire 20 ne fait pas partie d’un système multi-terminaux préalablement déclaré auprès de la passerelle d’acheminement 50’, et donc que son identifiant MSISDN n’a pas été mémorisé au préalable par la passerelle 50’), le procédé s’arrête à ce stade et seul le terminal destinataire 20 reçoit le message SMS1 (étape S1 15) dans le plan de signalisation, de manière traditionnelle.
Si le résultat de cette détermination s’avère positif (typiquement dans le cas où le terminal destinataire 20 fait partie d’un système multi-terminaux et est associé à un identifiant mémorisé par la passerelle d’acheminement 50’ pour signaler que tel est le cas), la passerelle d’acheminement 50’ procède alors à la transmission (étape S130) de ce message SMS1 vers le serveur de synchronisation 30, en insérant ce message SMS1 dans un message de signalisation conforme à un protocole de signalisation adapté aux échanges de signalisation entre passerelles d’acheminement et serveurs de synchronisation, ici le protocole MAP (mais pourrait être aussi le protocole OMA NMS).
Il convient de noter ici que cette étape de détermination S120 peut avoir lieu indifféremment avant ou après l’étape de transmission S1 15 vers le terminal destinataire 120, dans la mesure où cette transmission S115, dans le plan de signalisation, du message SMS1 est systématiquement réalisée dans le présent mode de réalisation, que le terminal destinataire appartienne à un système multi-terminaux ou pas.
Une fois reçu ce message SMS1 , le serveur de synchronisation 30 mémorise (étape S140) ce message SMS1 , après l’avoir extrait du message de signalisation dans lequel il a été reçu, soit au sein même d’un module de mémorisation de ce serveur, soit dans une base de données associée à ce serveur.
A ce stade, les terminaux associés 20’ et 20” peuvent alors récupérer le message SMS1 , destiné au terminal destinataire 20, auprès du serveur de synchronisation 30, au moyen de messages de synchronisation conformes à un protocole de synchronisation adapté à la synchronisation en mode client-serveur, tel que le protocole IMAP, JMAP, OMA DS ou OMA NMS, entre autres.
Ainsi, pour ce qui est du terminal associé 20’, lorsque ce terminal 20’ est à synchroniser, le serveur de synchronisation 30 récupère le message SMS1 destiné au terminal destinataire 20 et l’insère dans un message de synchronisation SYNC’[SMS1 ] qu’il transmet à ce terminal 20’ (étape S150’). Le serveur 30 fait de même pour tous les autres terminaux associés, en l’occurrence ici pour le terminal 20” (étape S150”) auquel il transmet un message de synchronisation SYNC”[SMS1] dans lequel il a inséré le message SMS1.
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>
<attri ute>
<name>Message-Context</na e>
<value>pager-message</value>
</attribute>
<attribute>
<name>From</name>
<value>tel :+19585550100</value>
</attri ute>
<attribute>
<name>To</name>
<value>tel :+19585550210</value>
</attribute>
<attribute>
<name>Date</name>
<value>2013-ll-12T08 : 30: 10Z</value>
</attribute>
<attribute>
<name>Direction</name>
<value>In</value>
</attribute>
<attribute>
<name>Content-Type</name>
<va1ue>text/plain</value>
</attribute>
<attribute>
<name>TextContent</name>
<value>The weather is nice today, let's go to the beach ! </value> </attribute>
</attributes>
<flags>
<flag>\Seen</flag>
</flags>
</object>
Ces messages de synchronisation peuvent aussi être implémentés sous 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 : <obj ect>
<attributes>
<attribute >
<name>Message -Context</name>
<value>pager-message</value>
</attribute >
<attribute>
< n aine > From< / n atne >
<value>tel : +19585550100</value>
</attribute>
<attribute>
<na*e>To</name>
<value>tel:+19585550210</value>
</attribute>
<attribute>
<naflie>Date</name>
<value>2013 -ll-12T08 : 30 : 10Z</value>
</attrlbute>
<attribute>
<name>Direction</name>
<value>In</value>
</attribute >
<attribute>
< n âne>Cont e nt -Type</ name >
<value>tex:t/plaln</value >
</attribute>
</attributes>
<flags>
<flag>\Seen</flag>
</flags>
<payloadPart>
<contentType>text/plain</contentType>
<slze>49</size>
<hnef>/niis/vl/myStore/tel¾3A%2B19585550100/objects/old999/payloadParts/blobl23</href>
</payloadPart>
</ob ect>
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.
Le message de synchronisation SYNC’[SMS1 ] utilisé pour transmettre le message SMS1 vers le terminal associé 20’ peut être le même que le message de synchronisation SYNC”[SMS1 ] utilisé pour transmettre le message SMS1 vers le terminal associé 20”, ou bien encore être un message de synchronisation d’un type différent mais conforme à un même protocole de synchronisation, ou bien encore être conforme à un protocole de synchronisation différent. Tous ces messages de synchronisation sont transmis dans le plan transport de données, et non dans le plan de signalisation comme cela serait le cas si le message SMS1 devait être dupliqué et transmis à chaque terminal associé.
Chaque terminal associé 20’ et 20” peut alors, après avoir reçu respectivement ces messages de synchronisation SYNC’ et SYNC”, y extraire le message SMS1 destiné au terminal destinataire 20 et le stocker dans leurs propres mémoires respectives, pour consultation ou restitution ultérieure par un utilisateur. Ainsi, au terme de ce procédé, tous les terminaux associés au terminal destinataire 20 disposent du message SMS1 devant être reçu par le terminal destinataire 20, 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, l'indicateur de réponse, etc. L’utilisateur d’un système multi-terminaux a donc accès à un même historique de réception de message, peu importe le terminal auquel il accède.
On se réfère à présent à la figure 3, laquelle illustre un procédé de transmission de message selon un autre mode de réalisation de la présente invention.
Cet autre mode de réalisation est relativement similaire à celui illustré à la figure 2, à la différence près qu’après avoir reçu le message SMS1 , la passerelle d’acheminement 50’ du réseau auquel le terminal destinataire est abonné ne le transmet pas nécessairement directement au terminal destinataire, dans le plan de signalisation, mais peut au contraire laisser le soin au serveur de synchronisation de s’en charger, dans le plan transport de données.
En d’autres termes, au niveau de la passerelle d’acheminement 50’, l’étape traditionnelle (illustrée par S1 15 en figure 2) de transmission du message SMS1 vers le terminal destinataire 20 selon un protocole de signalisation peut être ici inhibée, et n’a donc pas systématiquement lieu.
Pour permettre une telle inhibition, après avoir reçu un message SMS1 depuis le nœud réseau 40 (étape S1 14), la passerelle d’acheminement 50’ peut déterminer (étape S220) si ce message SMS1 doit être transmis au serveur de synchronisation 30, cette détermination pouvant être effectuée de manière similaire à l’étape S120 décrite en relation avec la figure 2. Si le résultat de cette détermination s’avère négatif (par exemple parce que le numéro destinataire MSISDN20 n’est pas indiqué, au niveau de la passerelle d’acheminement 50’ comme faisant partie d’un système multi-terminaux impliquant plusieurs terminaux associés), la passerelle d’acheminement 50’ peut alors transmettre (étape S225) le message SMS1 selon un protocole de signalisation (ici illustré par le protocole SIP, mais pouvant aussi être la combinaison de protocoles MAP et NAS par exemple) adapté aux échanges de signalisation entre passerelle réseau et terminaux, de manière traditionnelle, sans le transmettre en parallèle au serveur de synchronisation 30.
Si le résultat de cette détermination s’avère positif (par exemple parce qu’un identifiant associé au terminal destinataire 20 est mémorisé par la passerelle d’acheminement 50’ comme indiquant que ce terminal 20 fait partie d’un système multi- terminaux impliquant plusieurs terminaux), alors il n’y a pas de transmission de ce message directement vers le terminal destinataire 20 dans le plan de signalisation (i.e. l’étape S225 est inhibée et n’a pas lieu), mais au contraire ce message SMS1 est inséré dans un message de signalisation conforme à un protocole de signalisation adapté aux échanges de signalisation entre passerelles d’acheminement et serveur de synchronisation (ici le protocole MAP à titre d’exemple) et transmis (étape S230) vers le serveur de synchronisation 30.
De préférence ici, pour signaler au serveur de synchronisation 30 que l’étape S225 a été inhibée et donc qu’il revient au serveur de synchronisation 30 de permettre la récupération du message SMS1 par le terminal destinataire 20, la passerelle d’acheminement 50’ peut insérer dans ce message de signalisation un indicateur, interprétable par le serveur 30, signalant que le message SMS1 n’a pas été transmis au terminal destinataire 20 par la passerelle 50’.
Une fois reçu ce message de signalisation incluant le message SMS1 , le serveur de synchronisation 30 extrait ce message SMS1 et le mémorise (étape S240), soit au sein même d’un module de mémorisation de ce serveur, soit dans une base de données associée à ce serveur.
A ce stade, non seulement les terminaux associés 20’ et 20”, mais également le terminal destinataire 20, peuvent alors récupérer le message SMS1 , destiné au terminal destinataire 20, auprès du serveur de synchronisation 30, au moyen de messages de synchronisation conformes à un protocole de synchronisation adapté à une synchronisation client-serveur, tel que le protocole IMAP, JMAP, OMA DS ou OMA NMS, entre autres.
Tout comme dans le mode de réalisation illustré en figure 2, pour ce qui est du terminal associé 20’, le serveur de synchronisation 30 récupère le message SMS1 destiné au terminal destinataire 20 et l’insère dans un deuxième message de synchronisation SYNC’[SMS1 ] qu’il transmet à ce terminal 20’ (étape S250’). Il fait de même pour tous les autres terminaux associés, en l’occurrence ici pour le terminal 20” (étape S250”) auquel il transmet un troisième message de synchronisation SYNC”[SMS1 ] dans lequel il a inséré le message SMS1.
Pour ce qui est du terminal destinataire 20, dans un mode de réalisation, le serveur de synchronisation 30 peut être configuré pour systématiquement récupérer le message SMS1 destiné à ce terminal destinataire 20 et l’insérer dans un premier message de synchronisation SYNC[SMS1 ] qu’il transmet à ce terminal 20 (étape S250), sans tenir compte d’une éventuelle transmission directe au terminal 20 de ce message SMS1 dans le plan de signalisation.
Dans un mode de réalisation alternatif, le procédé peut comprendre une étape optionnelle (étape S245) de détermination, par le serveur de synchronisation, afin de ne transmettre un message de synchronisation SYNC[SMS1 ] au terminal destinataire 20 déterminer que lorsqu’il n’a pas déjà été transmis, dans le plan de signalisation, par la passerelle d’acheminement 50’. Cette détermination peut en particulier être réalisée en vérifiant la présence, dans le message de signalisation reçu de la passerelle d’acheminement 50’ lors de l’étape S230, d’un indicateur signalant que le message SMS1 n’a pas été transmis (ou au contraire a été transmis) au terminal destinataire 20 par la passerelle 50’.
Tout comme pour le mode de réalisation illustré en figure 2, les messages de synchronisation SYNC[SMS1 ], SYNC’[SMS1 ] et SYNC”[SMS1 ] utilisés pour transmettre le message SMS1 respectivement aux terminaux 20, 20’ et 20” peuvent être un seul et même type de message de synchronisation, ou bien encore être des messages de synchronisation de types différents mais conformes à un même protocole de synchronisation, ou bien encore être respectivement conformes à des protocole de synchronisation différents.
Chaque terminal 20, 20’ et 20”peut alors, après avoir reçu respectivement ces messages de synchronisation SYNC, SYNC’ et SYNC”, y extraire le message SMS1 destiné au terminal destinataire 20 et le stocker dans leurs propres mémoires respectives, pour consultation ou restitution ultérieure par un utilisateur. Ainsi, au terme de ce procédé, tous les terminaux associés au terminal destinataire disposent du message SMS1 devant être reçu par le terminal destinataire, ainsi que des informations associées à ce message, comme décrites précédemment.
Dans le mode de réalisation illustré en figure 3, seul le plan de transport de données est utilisé pour diffuser le message à recevoir entre les différents terminaux du système multi-terminaux, ce qui permet une économie optimale des ressources dans le plan de signalisation.
On se réfère à présent à la figure 4, illustrant une passerelle d’acheminement selon un mode de réalisation de la présente invention.
Cette passerelle d’acheminement 50’ comprend en particulier un module de communication 51 (implémenté typiquement sous forme d’émetteur-récepteur) configuré pour recevoir, en provenance d’un nœud réseau 40 chargé du stockage et de la transmission de message dans le plan de signalisation, un message de signalisation (illustré par « MAP[SMS1 ] ») conforme à un protocole de signalisation adapté aux échanges de signalisation entre nœud réseau et passerelle d’acheminement (ici le protocole MAP) dans lequel a été inséré un message SMS1 à transmettre à un terminal destinataire 20.
Ce module de communication 51 est également configuré pour transmettre, vers un serveur de synchronisation 30, un message de signalisation (illustré par « MAP[SMS1 ] ») conforme à un protocole de signalisation adapté aux échanges de signalisation entre passerelle d’acheminement et serveur de synchronisation (ici aussi le protocole MAP) dans lequel a été inséré ce message SMS1 , ainsi éventuellement qu’un indicateur signalant l’éventuelle absence de transmission de ce message SMS1 de cette passerelle directement vers le terminal destinataire 20.
En outre, dans un mode particulier de réalisation, ce module de communication 51 est également configuré pour transmettre, vers le terminal destinataire 20, un message de signalisation conforme à un protocole de signalisation adapté aux échanges de signalisation entre passerelle d’acheminement et terminaux (ici le protocole SIP, mais pourrait être aussi le protocole MAP ou NAS, par exemple) dans lequel a été inséré ce message SMS1.
Cette passerelle d’acheminement 50’ comprend en outre un module de traitement 53 (typiquement implémenté sous la forme d’un ou plusieurs processeur(s) exécutant des instructions de programme d’ordinateur mémorisées par la passerelle d’acheminement), configuré tout d’abord pour traiter les messages de signalisation reçus en provenance du nœud réseau 40, et notamment pour en extraire un message SMS1 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 4 par le message « MAP[SMS1 ] »). Ce message SMS1 , une fois extrait du message de signalisation « MAP[SMS1 ] », peut être analysé afin de récupérer un identifiant associé au terminal 20 auquel il est destiné (ici son identifiant « MSISDN2o )·
Une fois cette identifiant récupéré, le module de traitement 53 peut déterminer si le terminal destinataire 20 appartient à un système multi-terminaux préalablement signalé à la passerelle 50’, au moyen de cet identifiant.
Afin d’effectuer cette opération, dans un mode de réalisation, le module de traitement 53 interroge un module de mémorisation 55 (typiquement une mémoire non- volatile, laquelle est ici illustrée comme étant comprise dans la passerelle d’acheminement 50’, mais pouvant être aussi implémentée sous la forme d’une base de données distincte de cette passerelle, à laquelle cette passerelle a accès) pour vérifier si cet identifiant y est mémorisé.
Si le résultat de cette détermination s’avère négatif (i.e. l’identifiant
« MSISDN20 » récupéré ne correspond à aucun identifiant mémorisé), le module de traitement 53 peut alors insérer le message SMS1 dans un message de signalisation selon un protocole de signalisation adapté aux terminaux (ici le protocole SIP, mais pourrait être le protocole MAP ou NAS, par exemple) et instruire au module de communication 51 de transmettre ce message de signalisation vers le terminal destinataire 20, sans solliciter le serveur de synchronisation 30.
Si le résultat de cette détermination s’avère positif (i.e. l’identifiant
« MSISDN20 » récupéré correspond à un identifiant mémorisé), le module de traitement 53 peut alors insérer le message SMS1 dans un message de signalisation adapté aux échanges avec un serveur de synchronisation (ici le protocole MAP) et instruire au module de communication 51 de le transmettre vers le serveur de synchronisation 30.
En outre, dans un mode particulier de réalisation, le module de traitement 53 peut déterminer s’il convient d’insérer ce message SMS1 dans un message de signalisation adapté aux échanges avec des terminaux (e.g. le protocole SIP, MAP ou NAS) et d’instruire au module de communication 51 de transmettre ce message de signalisation directement vers le terminal destinataire 20, ou au contraire de ne pas le faire (auquel cas il revient alors au terminal destinataire 20 de récupérer ce message SMS1 directement auprès du serveur de synchronisation).
Pour déterminer cela, un paramètre indicatif d’une transmission directe vers le terminal destinataire, dans le plan de signalisation, peut être associé à l’identifiant signalant l’appartenance du terminal destinataire à un système multi-terminaux, lors de la mémorisation préalable de cet identifiant par la passerelle d’acheminement 50’, dans le module de mémorisation 55.
Ainsi, lorsque le module de traitement 53 détermine que l’identifiant récupéré est mémorisé dans le module de mémorisation 55 (et donc que le terminal destinataire appartient à un système multi-terminaux), le module de traitement peut aussi déterminer s’il convient de transmettre directement le message SMS1 vers ce terminal destinataire 20, en vérifiant la présence d’un paramètre indicatif d’une telle transmission directe dans le plan de signalisation.
A titre d’exemple, sur la figure 5, l’identifiant « MSISDN20 » est associé au paramètre « + » indiquant qu’une transmission directe dans le plan de signalisation est à effectuer. A contrario, l’identifiant « MSISDN30 » est associé au paramètre « - » indiquant qu’une transmission directe dans le plan de signalisation est à inhiber, et donc que le terminal destinataire 30 doit récupérer lui-même, auprès du serveur de synchronisation, les messages qui lui sont destinés.
Ainsi, lorsque la passerelle 50’ reçoit un message à partir duquel est récupéré l’identifiant « MSISDN20 » associé à un terminal destinataire 20, le module de traitement 53 comprend de ce qui est mémorisé dans le module de mémorisation 55, non seulement qu’il convient de préparer un ou plusieurs messages de synchronisation, incluant le message SMS1 , à transmettre aux terminaux associés au terminal 20, mais également qu’il convient de préparer un message de signalisation incluant ce message SMS1 à transmettre au terminal 20.
Dans ce cas, le module de traitement peut insérer, dans le message de signalisation destiné au serveur de synchronisation 30, une indication que ce serveur de synchronisation n’a pas besoin d’émettre de message de synchronisation à destination du terminal destinataire 20.
A contrario, lorsque la passerelle 50’ reçoit un message à partir duquel est récupéré l’identifiant « MSISDN30 » associé à un terminal destinataire 30, le module de traitement 53 comprend de ce qui est mémorisé dans le module de mémorisation 55, qu’il convient seulement de préparer un ou plusieurs messages de synchronisation, incluant ce message, à transmettre aux terminaux associés au terminal 30, sans préparer de message de signalisation incluant ce message à transmettre directement au terminal 30. Dans ce cas, le module de traitement peut insérer, dans le message de signalisation destiné au serveur de synchronisation 30, une indication que ce serveur de synchronisation doit permettre au terminal destinataire 20 de récupérer le message SMS1 , par exemple en insérant ce message SMS1 dans un message de synchronisation qu’il lui transmet.
Si l’indication évoquée dans les deux cas précédents n’est pas insérée, il revient alors au terminal destinataire 20 de détecter qu’il a déjà reçu directement le message SMS1 , et donc qu’il n’a pas besoin de le récupérer auprès du serveur de synchronisation.
Par ailleurs, dans le cas d’un identifiant commun correspondant à un numéro natif du terminal destinataire 20, il peut être prévu (typiquement au niveau de l’opérateur du réseau) que les messages SMS envoyés vers un tel type d’identifiant sont toujours transmis dans le plan de signalisation, et donc sans récupération auprès du serveur de synchronisation. Le serveur de synchronisation peut alors être configuré, au moyen d’un paramètre global, pour appliquer une telle politique réseau.
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 (implémenté typiquement sous forme d’émetteur-récepteur) configuré pour recevoir, en provenance d’une passerelle d’acheminement 50’, un message de signalisation comprenant un message SMS1 destiné à un terminal destinataire 20. Ce module de communication est également configuré pour échanger des messages de synchronisation avec le ou les terminaux 20’, 20” associés au terminal destinataire 20, voire également avec le terminal destinataire 20 lui-même.
Le serveur de synchronisation 30 comprend en outre un module de traitement 33, configuré tout d’abord pour traiter les messages de signalisation reçus en provenance de la passerelle d’acheminement 50’, et notamment pour en extraire un message SMS1 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 MAP[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 MAP[SMS1 ], peut être alors mémorisé dans un module de mémorisation 35 (typiquement une mémoire non-volatile), laquelle est 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 destinataire 20 (ici, son identifiant « MSISDN20 ») afin de faciliter sa récupération ultérieure.
Lorsqu’ultérieurement, un terminal 20’ associé au terminal destinataire 20 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é 20’ en question. Cette opération est répétée pour tous les terminaux associés au terminal destinataire 20, à synchroniser au moyen du serveur 30 (ici le terminal 20” également, auquel le message de synchronisation SYNC”[SMS1 ] est transmis). Dans un mode de réalisation, cette opération est aussi effectuée pour le terminal destinataire 20 lorsqu’il peut être synchronisé au moyen d’un message SYNC[SMS1 ] émis par le serveur 30.
Les messages SYNC[SMS1 ], 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) par le serveur de synchronisation 30 respectivement vers les terminaux 20, 20’ et 20”, par exemple à intervalle régulier, dans un mode « push ». Alternativement, ces messages de synchronisation peuvent être des messages émis en réponse à des requêtes de synchronisation reçues par le serveur de synchronisation 30 respectivement des terminaux 20, 20’ et 20”, dans un mode dit « pull » (de telles requêtes étant illustrées par « REQ SYNC » sur la figure 5).
On se réfère à présent à la figure 6, illustrant un terminal dit « associé », partageant le même identifiant qu’un autre terminal, dit « destinataire », destinataire d’un message transmis par un terminal source, selon un mode de réalisation de la présente invention.
Ce terminal 20’ (qui peut être en particulier un terminal mobile de type smartphone) comprend en particulier un module de communication 21’ configuré pour recevoir, en provenance d’un serveur de synchronisation 30 tel que décrit précédemment, un message de synchronisation SYNC’[SMS1 ] dans lequel a été inséré le message SMS1 destiné à un terminal destinataire 20. Ce module de communication 21’ peut être également configuré pour émettre (par exemple, mais non obligatoirement, à intervalles prédéfinis) la requête de synchronisation « REQ SYNC » discutée précédemment vers ce serveur de synchronisation 30, en vue de déclencher l’envoi du message de synchronisation SYNC’[SMS1 ] en retour. Un tel module de communication peut être implémenté en particulier sous la forme d’un émetteur-récepteur radio, e.g. d’une ou plusieurs antenne(s) radio connectées à un convertisseur numérique/analogique.
Le terminal 20’ comprend en outre un module de traitement 23’ configuré tout d’abord pour traiter les messages de synchronisation reçus en provenance du serveur de synchronisation 30, et notamment pour en extraire d’un tel message de synchronisation un message destiné à un autre terminal destinataire 20, par exemple un message de format 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 25’ (typiquement une mémoire non-volatile) également compris dans le terminal 20’.
En particulier, dans le module de mémorisation 25’ du terminal 20’, ce message SMS1 extrait du message de synchronisation peut être mémorisé avec d’autres messages SMSA, SMSB (i.e. dans la zone de mémorisation associé à ce même type de message dans le terminal 20’), de sorte à ce que ce message SMS1 soit accessible pour l’utilisateur de la même manière que tout autre message du même type qui serait reçu de manière plus traditionnelle (i.e. sans recourir à un serveur de synchronisation).
Ainsi, dans un mode de réalisation où le terminal 20’ comprend également un module d’interface utilisateur 27’, typiquement sous la forme d’un écran tactile, lorsque l’utilisateur consulte ses messages reçus du réseau mobile (par exemple les messages selon le format SMS), il verra non seulement les messages SMSA et SMSB reçus de manière classique depuis le réseau mobile (i.e. sans recourir au serveur de synchronisation 30), mais également le message SMS1 reçu depuis le serveur de synchronisation 30.
Le module gérant l’interface utilisateur 27’ (sous forme logicielle typiquement) peut éventuellement distinguer (par exemple au moyen de couleurs différentes) ces messages SMSA et SMSB, d’une part, et SMS1 d’autre part, lorsqu’ils les affichent afin d’alerter l’utilisateur sur la différence de provenance de ces messages. Alternativement, ce module présente ces messages de manière identique, de sorte à ce que l’implémentation de la présente invention soit transparente pour l’utilisateur, qui ne voit qu’une série de messages de même type, peu importe s’ils ont été reçus de manière traditionnelle ou par le biais d’une synchronisation avec un serveur de synchronisation.
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 (2), dit terminal destinataire, depuis un deuxième terminal (10), dit terminal source, vers au moins un troisième terminal (20’, 20”), dit terminal associé, partageant un même identifiant avec le terminal destinataire, comprenant les étapes suivantes, suite à la réception (S1 14) du message par une passerelle d’acheminement (50’) :
transmission (S130,S230), de la passerelle d’acheminement vers un serveur de synchronisation (30), du message (SMS1 ) au moyen d’un premier protocole de signalisation (MAP); et
récupération (S150’,S250’), par ledit au moins un terminal associé (20’, 20”), du message destiné au terminal destinataire auprès du serveur de synchronisation au moyen d’un premier message de synchronisation (SYNC’[SMS1 ]).
2. Procédé selon la revendication 1 , comprenant en outre la détermination (S120,S220), par la passerelle d’acheminement (50’), de l’appartenance du terminal destinataire à un système multi-terminaux comprenant le terminal destinataire et ledit au moins un terminal associé, l’étape de récupération (S150’,S250’) n’ayant lieu qu’en cas de résultat positif de ladite détermination.
3. Procédé selon l’une des revendications 1 ou 2, comprenant en outre la transmission (S1 15,S225), de la passerelle d’acheminement (50’) au terminal destinataire (20), du message au moyen d’un deuxième protocole de signalisation (SIP).
4. Procédé selon la revendication 3, dans lequel la transmission (S225), de la passerelle d’acheminement (50’) au terminal destinataire (20), du message au moyen d’un deuxième protocole de signalisation (SIP) n’est réalisée que s’il est déterminé, lors de l’étape de détermination (S220), que le terminal destinataire n’appartient pas à un système multi-terminaux.
5. Procédé selon l’une des revendications 1 à 4, comprenant en outre la récupération (S250), par ledit terminal destinataire (20), du message destiné au terminal destinataire auprès du serveur de synchronisation au moyen d’un deuxième message de synchronisation (SYNC[SMS1 ]).
6. Procédé selon la revendication 5, dans lequel la récupération (S250), par ledit terminal destinataire (20), du message destiné au terminal destinataire (20) auprès du serveur de synchronisation (30) au moyen d’un deuxième message de synchronisation (SYNC[SMS1 ]) n’est réalisée que s’il est déterminé (étape S245) que le message SMS1 n’a pas été transmis de la passerelle d’acheminement (50’) au terminal destinataire (20) au moyen d’un message de signalisation.
7. Procédé selon l’une des revendications 1 à 6, comprenant en outre la mémorisation (S130,S230), par le serveur de synchronisation (30), du message (SMS1 ) suite à sa réception en provenance de la passerelle d’acheminement.
8. Passerelle d’acheminement (50’) comprenant un module de communication (51 ) apte à recevoir un message (SMS1 ) destiné à un premier terminal (20), dit terminal destinataire, selon un premier protocole de signalisation (MAP) et un module de traitement (53), configuré pour insérer le message (SMS1 ) dans un message de signalisation à transmettre vers un serveur de synchronisation (30) afin de permettre à au moins un deuxième terminal (20’, 20”), dit terminal associé, partageant un identifiant avec le terminal destinataire, de récupérer ledit message auprès dudit serveur de synchronisation.
9. Passerelle d’acheminement (50’) selon la revendication 8, dans laquelle le module de traitement (53) est configuré en outre pour instruire au module de communication de transmettre ledit message (SMS1 ) vers le terminal destinataire (20) au moyen d’un message de signalisation selon un deuxième protocole de signalisation.
10. Passerelle d’acheminement (50’) selon la revendication 8, dans laquelle le module de traitement (53) est configuré en outre pour inhiber la transmission dudit message (SMS1 ) par le module de communication au terminal destinataire (20).
11. Serveur de synchronisation (30) comprenant :
un module de communication (31 ) apte recevoir un message de signalisation selon un premier protocole de signalisation (MAP), ledit message de signalisation contenant un message (SMS1 ) destiné à un premier terminal (20), dit terminal destinataire, et
un module de traitement (33) configuré pour insérer le message (SMS1 ) reçu dans au moins un premier message de synchronisation (SYNC’[SMS1 ]) à transmettre, par le module de communication (31 ), vers au moins un deuxième terminal (20’, 20”), dit terminal associé, partageant un identifiant (MSISDN2o) avec ledit terminal destinataire.
12. Serveur de synchronisation selon la revendication 14, dans lequel le module de traitement (33) est configuré en outre pour insérer le message (SMS1 ) dans un deuxième message de synchronisation (SYNC[SMS1 ]) à transmettre, par le module de communication (31 ), vers ledit terminal destinataire (20).
13. Terminal (20’), apte à partager un même identifiant (MSISDN2o) avec un autre terminal, dit terminal destinataire (20), comprenant un module de traitement (23’), un module de communication (2T) configuré pour recevoir des messages destinés audit terminal, et un module de stockage (25’) configuré pour mémoriser lesdits messages destinés audit terminal en vue de le présenter à un utilisateur, caractérisé en ce que :
le module de communication (2T) est configuré en outre pour recevoir, en provenance d’un serveur de synchronisation (30), un message de synchronisation contenant un message (SMS1 ) destiné au terminal destinataire ; et
le module de traitement (23’) est configuré pour extraire, à partir du message de synchronisation reçu, le message (SMS1 ) destiné au terminal destinataire et pour fournir ledit message (SMS1 ) au module de stockage afin d’y mémoriser ledit message en vue de le présenter à un utilisateur avec les messages destinés audit terminal.
14. 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 (20’, 20”), dit terminal associé, partageant un même identifiant avec le terminal destinataire, comprenant une passerelle d’acheminement selon l’une des revendications 8 à 10 et un serveur de synchronisation (30) selon l’une des revendications 1 1 ou 12.
15. Système selon la revendication 14, comprenant en outre au moins un terminal selon la revendication 13.
EP20713921.3A 2019-04-05 2020-04-01 Transmission de messages dans un contexte multi-terminaux Pending EP3949457A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1903652A FR3094861A1 (fr) 2019-04-05 2019-04-05 Transmission de messages dans un contexte multi-terminaux
PCT/EP2020/059199 WO2020201320A1 (fr) 2019-04-05 2020-04-01 Transmission de messages dans un contexte multi-terminaux

Publications (1)

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

Family

ID=67810766

Family Applications (1)

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

Country Status (4)

Country Link
US (1) US12137394B2 (fr)
EP (1) EP3949457A1 (fr)
FR (1) FR3094861A1 (fr)
WO (1) WO2020201320A1 (fr)

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

Also Published As

Publication number Publication date
US20220182800A1 (en) 2022-06-09
WO2020201320A1 (fr) 2020-10-08
FR3094861A1 (fr) 2020-10-09
US12137394B2 (en) 2024-11-05

Similar Documents

Publication Publication Date Title
US6779022B1 (en) Server that obtains information from multiple sources, filters using client identities, and dispatches to both hardwired and wireless clients
CN108881354B (zh) 一种推送信息存储方法、装置、服务器和计算机存储介质
US10764228B1 (en) Automated message recall from a sender&#39;s device
US8064575B1 (en) Method and system for transmission of messages via multiple messaging servers
US8755397B2 (en) Asynchronous communication in an unstable network
CA2804562A1 (fr) Procede d&#39;etablissement d&#39;une communication sur internet entre terminaux mobiles, programme d&#39;ordinateur et support d&#39;enregistrement
US20060086798A1 (en) Deferred email message system and service
EP3949457A1 (fr) Transmission de messages dans un contexte multi-terminaux
EP1595371A1 (fr) PROCEDE DE GESTION DE PRESENCE SELECTIVE POUR SERVICE DE MESSAGERIE INSTANTANEE AU SEIN D&amp;rsquo;UN RESEAU DE TELECOMMUNICATION TEL QUE LE RESEAU INTERNET
FR2863810A1 (fr) Procede et systeme de coordination de services de telecommunication
EP1763187A1 (fr) Procédé de transfert de fichiers dans un système de messagerie instantanée, serveur et programme d&#39;ordinateur associés
WO2020201321A1 (fr) Transmission de messages dans un contexte multi-terminaux
FR3071126A1 (fr) Procede de mise en liaison telephonique d’un terminal de communication a numero multiple
FR3021774A1 (fr) Procede de traitement automatique de la mise a jour d&#39;une base de donnees
CN103095554A (zh) 媒体消息发送方法、装置及系统
EP1935149B1 (fr) Procede et systeme de notification de reception de messages asynchrones
EP3035723B1 (fr) Procédé de transmission de données en relation avec une communication
EP4258137B1 (fr) Procédé de distribution de fichier entre systèmes 3gpp mcdata interconnectés
FR2925810A1 (fr) Procede de communicatin entre un terminal et un reseau de communication
CA2895921A1 (fr) Systeme et procede pour obtenir une partie d&#39;un courriel archive
FR2888706A1 (fr) Procede de mise en relation interpersonelle
FR2977434A1 (fr) Procede et systeme de communication au sein d&#39;une communaute heterogene d&#39;utilisateurs
EP1542424A1 (fr) Système et procédé de partage de données entre des terminaux WAP
WO2011023904A1 (fr) Procede de diffusion d&#39;un contenu dans un reseau de telecommunications de maniere geolocalisee
FR2908251A1 (fr) Procede et systeme de synchronisation de repertoires

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: 20250730