EP4348982A1 - Procede de traitement d'un appel telephonique dans un reseau de communication, procede d'emission, procede de reception d'un tel appel, dispositifs, systeme et programmes d'ordinateur correspondants - Google Patents

Procede de traitement d'un appel telephonique dans un reseau de communication, procede d'emission, procede de reception d'un tel appel, dispositifs, systeme et programmes d'ordinateur correspondants

Info

Publication number
EP4348982A1
EP4348982A1 EP22732603.0A EP22732603A EP4348982A1 EP 4348982 A1 EP4348982 A1 EP 4348982A1 EP 22732603 A EP22732603 A EP 22732603A EP 4348982 A1 EP4348982 A1 EP 4348982A1
Authority
EP
European Patent Office
Prior art keywords
information
call
message
caller
terminal
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
EP22732603.0A
Other languages
German (de)
English (en)
Inventor
Paul Beardow
Frank Derville
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 EP4348982A1 publication Critical patent/EP4348982A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/42025—Calling or Called party identification service
    • H04M3/42034—Calling party identification service
    • H04M3/42042—Notifying the called party of information on the calling party
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/42025—Calling or Called party identification service
    • H04M3/42034—Calling party identification service
    • H04M3/42059—Making use of the calling party identifier
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/436—Arrangements for screening incoming calls, i.e. evaluating the characteristics of a call before deciding whether to answer it
    • H04M3/4365—Arrangements for screening incoming calls, i.e. evaluating the characteristics of a call before deciding whether to answer it based on information specified by the calling party, e.g. priority or subject

Definitions

  • Method for processing a telephone call in a communication network method for sending, method for receiving such a call, devices, system and corresponding computer programs
  • the field of the invention is that of a communication network configured to route calls, for example in voice over IP.
  • the invention relates in particular to enriching such calls with caller identity information.
  • a first drawback of this solution is that it introduces latency into the processing of the call received.
  • a second drawback is that it only works if the identity of the caller is well recorded in the database queried by the application and if the database may be inaccessible at the time of the call.
  • a third disadvantage is that several databases coexist without common storage rules or caller ID information format. Companies wishing to register with such databases must therefore multiply the registration procedures, without guarantee of success.
  • the invention improves the situation.
  • the invention meets this need by proposing a method for processing a call setup request message sent by a calling terminal to a called terminal in a communication network, said network comprising communication equipment configured to receive said message.
  • Said method is implemented at the level of said communication equipment and comprises:
  • the invention proposes an entirely new and inventive approach to processing a call, which consists in enriching the call with additional information identifying the caller stored in the communications network and therefore verified beforehand.
  • the called party benefits from these verified identification information upon receipt of the call on his terminal and without latency.
  • the called user is therefore more inclined to take the call.
  • the invention contributes to reducing the number of unanswered calls due to lack of information on the caller.
  • the call is sent in voice over IP and the updated information field is a field of a header of said call set-up request message.
  • the updated information field is a field of a header of said call set-up request message.
  • the updated information field is a field of a header of said call set-up request message.
  • said additional caller identification information obtained from the first table belongs to a group comprising at least:
  • Information about an image or video associated with the caller may include a link to this file.
  • the file in question includes a company logo and/or a photograph of the caller and/or a company advertisement.
  • the method further comprises querying the first data table, for example called the caller's identity table, from a telephone number of the caller extracted from said message.
  • the update comprises the insertion of reputation information obtained from a second data table, in the message of call setup request.
  • reputation information indicates a type of caller among the following possible values: commercial canvasser (“TELE”), fraudulent (“SPAM”) or legitimate (“OK”).
  • the method further comprises querying the second data table, for example called the caller's reputation table, from a telephone number of the caller extracted from said message.
  • the method further comprises:
  • additional caller identification information may be additional information relating to a call context.
  • this information provides a subject of the call, an urgency level, an emotion of the caller, etc. They help to further enrich the presentation of the call to the called party.
  • the method further comprises the prior verification of an authorization of the calling terminal to update the first data table, the addition of the information received in the table being conditioned by this verification.
  • it further comprises sending a registration confirmation message to the calling terminal.
  • the method comprises the coding of at least one of said information obtained in the form of a code comprising a sequence of text-type characters flanked by two occurrences of a key-type character, said key type character being associated with predetermined call context information.
  • the key character is an asterisk “**” associated with caller reputation information.
  • the key character "%%" is used to enclose a link to an image or video file associated with the caller.
  • the invention also relates to a device for processing a call setup request message sent by a calling terminal to a called terminal in a communication network, said network comprising communication equipment configured to receive said message.
  • Said device is configured to implement at said communication equipment:
  • said device configured to implement the steps of the processing method as described above.
  • the processing device has in combination all or part of the characteristics set out throughout this document.
  • said device is integrated into communication equipment of a communication network, configured to intercept a request message for setting up a voice over IP call sent by a calling terminal to a called terminal.
  • the communication equipment and the processing device have at least the same advantages as those conferred by the aforementioned processing method.
  • the invention also relates to a method for sending a call set-up request message by a calling terminal to a called terminal in a communication network. Said method is implemented at the calling terminal and comprises, prior to sending said message:
  • the calling terminal includes a dedicated software application configured to fill in such a first table, for example called the caller's identity table, managed by the network operator.
  • he receives a confirmation of recording of said information from the communication equipment.
  • the method further comprises sending to the communication network a request for updating the first data table, said update request comprising at least one piece of context information of the call.
  • the context information of a call specifies for example a reason or a subject of the call, an urgency level, an emotion of the caller, etc.
  • the invention also relates to a device for sending a call setup request message by a calling terminal to a called terminal in a communication network. Said device is configured to implement at the level of the calling terminal, prior to transmission of said message:
  • said device configured to implement the steps of the transmission method as described previously.
  • the transmission device has in combination all or part of the characteristics set out throughout this document.
  • said device is integrated into a terminal of a user configured to send a call setup request message in voice over IP to a calling terminal via a communication network.
  • the user terminal and the transmission device have at least the same advantages as those conferred by the aforementioned transmission method.
  • the invention also relates to a method for receiving a call setup request message by a called terminal sent by a calling terminal in a communications network. Said method is implemented at the level of the called terminal and comprises, upon receipt of said message:
  • the triggering of at least one action comprising a notification of said information to a user of the terminal called during a presentation of the call.
  • the called terminal since the additional information relating to the caller is contained in the signaling of the message, the called terminal can exploit it directly to enrich the notification of the call.
  • the additional information (extracted) belongs to a group comprising at least: additional caller identification information; information relating to a context of the call; caller reputation information.
  • the additional caller identification information comes from a first data table, managed by the operator of the caller's communication network and have been previously integrated into the table at the request of the caller, who has subscribed to a dedicated service.
  • the information relating to a context of the call comes from this first data table and was transmitted by the caller to the first table before sending the call.
  • This possibility of dynamic modification of the additional information contained in the database allows a caller to enrich one or more calls intended for one or more customers to indicate to them a level of urgency of the call or a reason for the call (" are you available to talk?) or an emotion associated with this call using one or more emoticons.
  • the reputation information advantageously comes from a second data table, itself also managed by the operator of the communication network, but which is not filled in from information provided by the callers themselves. For example, they indicate whether the caller is legitimate, fraudulent, direct seller, etc.
  • At least one of said additional information relating to the call is coded in the form of a sequence of text type characters flanked by two occurrences of a key type character
  • the reception method comprises decoding said information, said decoding comprising identifying said key type character and the method comprising determining at least one notification action triggered at least as a function of the identified key type character.
  • the key character “*” is used to frame a sequence of textual characters qualifying a reputation of the caller (SPAM for fraudulent, TELE for a commercial canvasser or even OK for a legitimate caller).
  • the key character "! » frames the name of the caller and indicates an urgent call.
  • the key character ? frames the caller's name and aims to ask the called party if they are available to speak.
  • An advantage of such key characters is that they can be recognized by the called party's terminal which is configured to translate them into specific notifications (display, ringtone, vibration, etc.) which therefore take on a particular meaning for the called party. . For example, displaying a caller name between “!” »! is translated by a display of the caller's name in flashing red, generally associated with the notion of urgency or the emission of an urgent ringtone.
  • the identification of a sequence framed by the key character "*" triggers the display of a window (pop-up) indicating the type of call (commercial, fraudulent, legitimate).
  • the invention also relates to a device for receiving a call setup request message by a called terminal transmitted by a calling terminal in a communications network, characterized in that it is configured to implement at of the called terminal and understands, upon receipt of said message:
  • the triggering of at least one action comprising a notification of said information to a user of the terminal called during a presentation of the call.
  • said device is configured to implement the steps of the reception method as described above.
  • the receiving device has in combination all or part of the characteristics set out throughout this document.
  • said reception device is integrated into a terminal of a user configured to receive a voice over IP call setup request message from a calling terminal via a communication network.
  • the user terminal and the reception device have at least the same advantages as those conferred by the aforementioned reception method.
  • the invention also relates to a data table of a communication network, comprising records associating at least additional information identifying a caller with a telephone number of this caller.
  • this data table is organized in the form of a database indexed by the telephone numbers of callers.
  • it includes information relating to a context of a call, added dynamically by the caller before issuing this call in the network.
  • the invention also relates to a system for managing a call set-up request message sent in voice over IP by a calling terminal to a called terminal in a communication network, comprising the processing device, the first data table, the transmission device and the aforementioned reception device.
  • the invention also relates to computer program products comprising program code instructions for implementing the methods as described previously, when they are executed by a processor.
  • a program may use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in partially compiled form, or in any other desirable form.
  • the invention also relates to a recording medium readable by a computer on which is recorded a computer program comprising program code instructions for the execution of the steps of the methods according to the invention as described above.
  • Such recording medium can be any entity or device capable of storing the program.
  • the medium may include a storage medium, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or else a magnetic recording medium, for example a mobile medium (memory card) or a hard drive or SSD.
  • such a recording medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means, so that the program computer it contains is executable remotely.
  • the program according to the invention can in particular be downloaded on a network, for example the Internet network.
  • the recording medium may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the aforementioned display control method.
  • the present technique is implemented by means of software and/or hardware components.
  • the term "module" may correspond in this document to a software component, a hardware component or a set of hardware and software components.
  • a software component corresponds to one or more computer programs, one or more sub-programs of a program, or more generally to any element of a program or software capable of implementing a function or a set of functions, as described below for the module concerned.
  • Such a software component is executed by a data processor of a physical entity (terminal, server, gateway, set-top-box, router, etc.) and is likely to access the hardware resources of this physical entity (memories, recording media, communication bus, electronic input/output cards, user interfaces, etc.).
  • resources means all sets of hardware and/or software elements supporting a function or a service, whether unitary or combined.
  • a hardware component corresponds to any element of a hardware assembly (or hardware) able to implement a function or a set of functions, according to what is described below for the module concerned. It can be a hardware component that can be programmed or has an integrated processor for executing software, for example an integrated circuit, a smart card, a memory card, an electronic card for executing firmware ( “firmware” in English), etc.
  • firmware “firmware” in English
  • Figure 1 shows an example of the architecture of a system for processing a request message to set up a voice over IP call in a communication network, according to the invention
  • Figure 2 schematically illustrates an example of the architecture of communication equipment of the communication network, said equipment integrating a device for processing a call setup request message according to one embodiment of the invention and an example of a user terminal, integrating a device for receiving a call setup request message according to one embodiment of the invention;
  • FIG. 3 describes in the form of a flowchart the steps of a process for processing a call set-up request message by the communication equipment, according to an exemplary embodiment of the invention
  • FIG. 4 describes in the form of a flowchart the steps of a method for sending a call set-up request message by the calling terminal, according to an exemplary embodiment of the invention
  • FIG. 5 describes in the form of a flowchart the steps of a method for receiving a call set-up request message by the called terminal, according to an exemplary embodiment of the invention
  • FIG. 6A, FIG. 6B, FIG. 6C illustrate examples of displays of additional caller identification information on the called terminal according to the invention
  • FIG. 7 describes in the form of a flow diagram the exchanges between a calling user terminal, the communication equipment and a called user terminal according to an example embodiment of the invention
  • FIG. 8 describes an example of the hardware structure of a device for processing a call set-up request message according to the invention
  • FIG. 9 describes an example of the hardware structure of a device for sending a call set-up request message according to the invention
  • FIG. 10 describes an example of the hardware structure of a device for receiving a call set-up request message according to the invention
  • the invention relates to the processing of a call sent by voice over IP in a communication network by a calling terminal to a called terminal.
  • the general principle of the invention is based on the enrichment, at the level of the communication network, of the call signaling message, using additional caller identification information stored in at least one database. of data managed by the operator of the communication network. This information is notified by the called terminal when presenting the incoming call to its user. In this way, the called party benefits without latency from reliable additional information on the identity of the caller, which enables him to decide to accept or refuse the call with full knowledge of the facts.
  • the invention finds a particularly interesting application for professionals who wish to see their calls to customers or suppliers succeed.
  • VoLTE Voice over Long Term Evolution
  • ViLTE Video over Long Term Evolution
  • VoIP Voice over Internet Protocol
  • SIP Signaling Protocol
  • the invention is not limited to this protocol and applies to any other protocol allowing call signaling in voice over IP. Nevertheless, in the remainder of the description, the examples presented will implement this signaling protocol.
  • FIG. 1 an example of the architecture of a system 10 for processing a request message for setting up a voice over IP call in a communication network RC according to an example of realization of the invention.
  • the communication network RC of an operator has been represented schematically, as a single entity, without showing, for the sake of simplicity, its various access networks. It is assumed that this communication network RC implements at least one of the voice over IP technologies mentioned above.
  • a first terminal equipment UE-A connects to the communication network RC via a fixed access network (not shown) of the ADSL or fiber type.
  • the first terminal equipment UE-A is connected to the local communication network (not shown) of a residential or professional gateway GW, for example using a wired connection, by example of the Ethernet or wireless type, for example of the Wi-Fi type.
  • a residential or professional gateway GW for example using a wired connection, by example of the Ethernet or wireless type, for example of the Wi-Fi type.
  • the invention is not limited to this example and applies just as well to a mobile access network of the cellular type, to which the first UEA terminal equipment via a 2G to 5G type link.
  • the first terminal equipment UE-A called the calling terminal, sends a voice over IP call setup request to a second terminal equipment UE-B of a user UTB, called the called terminal, also connected to the RC communication network.
  • the terminals UE-A and UE-B are telephones of the smart telephone type (for “smartphone”, in English).
  • it can also be fixed telephones, for example cordless telephones of the DECT type (for “Digital Enhanced Cordless Telecommunications”, in English), tablets, personal computers, etc., more generally any user terminals provided that they are provided with an interface with the access network to the RC network available nearby and configured to manage a telephone communication in voice over IP via this network.
  • the system 10 comprises, in addition to the two terminals calling UE-A and called UE-B, communication equipment EQ of the communication network RC.
  • This communication equipment EQ is placed on the path of the call set-up request message transmitted by the calling terminal UE-A. It is for example a router equipment, a telephone application server or TAS (for “Telephone Application Server”, in English) or indeed any other communication equipment of the RC network.
  • such equipment EQ is configured to interrogate at least a first data table, called a caller's identity table IDB, managed by the communication network RC.
  • the equipment EQ comprises two separate equipments, connected to one another: a server equipment TAS and an equipment EIDS implementing a caller identification service IDS.
  • a server equipment TAS and an equipment EIDS implementing a caller identification service IDS.
  • an application server in an operator's network such as the RC network, it is common for an application server to communicate with different equipment dedicated to the implementation of specific services, such as the EIDS equipment.
  • Such equipment is registered beforehand with the application server TAS so that it retransmits certain call signaling messages to them.
  • the invention is not limited to this example and also applies when the equipment item EQ is the TAS application server itself and when it hosts several software applications each implementing a specific service and in particular the IDS caller ID service.
  • FIG. 2 presents an example of architecture of the communication equipment EQ according to an embodiment of the invention.
  • the communication equipment EQ comprises a device 100 for processing a call setup request message according to the invention. This device is configured to intercept said message, extract therefrom a telephone number of the caller, obtain additional caller identification information by querying the identity table IDB from said telephone number, update an information field of said message by inserting the information obtained and routing the updated message to the called terminal.
  • the device 100 is configured to receive a request for recording additional information in the identity table, in association with the telephone number of the caller, to verify that the caller is authorized to record data in this table and send him a registration confirmation.
  • the device 100 thus implements the method for processing a call set-up request message according to the invention which will be detailed below in relation to FIG. 3.
  • it is implemented under the form of an API-IDS software application of the API type (for “Application Programming Interface”, in English), installed on the equipment EQ.
  • this application is dedicated to the implementation of the caller ID service according to the invention.
  • the device 100 can be independent of the EQ equipment, but connected to the latter by any link, wired or not.
  • FIG. 2 also presents an example of the architecture of a user terminal UE-A, or calling terminal, according to one embodiment of the invention.
  • the calling terminal UE-A comprises a device 200 for sending a call setup request message sent by the terminal UE-A.
  • the called terminal UE-A is configured to, prior to the transmission of said message, request a recording of additional information identifying the caller in a first data table, called the identity table of the caller, stored in said communication network, in association with a telephone number of the caller, said additional caller identification information being intended to be used by communication equipment configured to receive said request message call set-up, enrich it at least using the information contained in said identity table and retransmit it to the called terminal.
  • the device is also configured to request an update of the identity table of the caller, the update request comprising at least additional call context information.
  • the device 200 thus implements the method for sending a call set-up request message according to the invention which will be detailed below in relation to FIG. 4.
  • it is implemented in the form of a software application API-IDS-UE-A of API type, installed on the calling terminal UE-A.
  • this application is dedicated to the use of the caller ID service by the calling terminal according to the invention.
  • FIG. 2 finally presents an example of the architecture of a user terminal UE-B, or called terminal, according to one embodiment of the invention.
  • the called terminal UE-B comprises a device 300 for receiving a call setup request message sent by the terminal UEA.
  • the called terminal UE-B is configured to receive said message from the network, extract caller identification information from an information field of the message received, and trigger at least one action comprising notifying said caller identification information to a user of the called terminal.
  • the device 200 thus implements the method for receiving a call set-up request message according to the invention which will be detailed below in relation to FIG. 5.
  • this application is implemented in the form of an API-IDS-UE-B software application of the API type, installed on the terminal called UE-B.
  • this application is dedicated to the use of the caller ID service by the called terminal according to the invention.
  • FIG. 3 in the form of a flowchart, an example of implementation of a method for processing a call setup request message according to an embodiment of the invention.
  • This method is implemented by a communication device EQ configured to receive the call set-up request messages transmitted by the calling terminals.
  • a communication device EQ configured to receive the call set-up request messages transmitted by the calling terminals.
  • it is for example implemented in the form of an APIJDS software application.
  • the communication equipment EQ receives at 30 a message REGJCI requesting registration of additional information identifying the user. caller HERE from terminal UE-A.
  • the information ICI received is recorded in the identity table IDB in association with the telephone number of the terminal UE-A.
  • this recording step is conditioned by a prior verification that the user UT-A of the terminal UE-A is indeed authorized to record information in this table, because he has subscribed to the identification service of the caller from RC network operator.
  • the user UT-A of the terminal UE-A has provided information on his identity to the operator who manages the identity table during a preliminary registration phase, for example by completing an online form .
  • the identity information in question comprises, for example, his name, his telephone number, etc., and is stored in the identity table once validated by this operator.
  • the communication equipment EQ receives at 32 from the terminal UE-A, a message REG-ICC requesting the recording of additional information ICC relating to a call context.
  • This ICC context information is linked to the telephone number of the called party, as well as that of the caller. Both phone numbers are needed to find the specific information about the reason for the call for the called party, as it can vary from call to call and from person to person. For example, a salesperson might call a first customer about fixing one of their devices and a second customer to confirm an appointment. These calls from the same caller have different call reasons.
  • This information specifies the context of one or more upcoming calls and includes, for example:
  • the ICC information is recorded in association with the telephone number of the user UT-A and completes the entry of the table IDB corresponding to the telephone number of the user UT-A.
  • this additional recording can also be conditional on a prior verification of the rights of the user UT-A, that is to say that he has indeed subscribed to the caller ID service.
  • Such a request for recording ICC information can be received and processed at any time by the communication equipment EQ. It allows dynamic adaptation of the content of the identity table to the needs of the user of the calling terminal UE-A.
  • the equipment item EQ receives a call set-up request message REQ to the called terminal UE-B.
  • the call signaling messages exchanged between the calling and called terminals and the communication network RC comply with the SIP communication protocol.
  • the call establishment request REQ message is of the SIP INVITE type.
  • This SIP INVITE message includes information about the caller UT-A and the called party UT-B and initiates the process of exchanging information between the two terminals to establish the voice communication (coded codes supported, etc.) .
  • the SIP INVITE message generally includes several headers intended to specify technical information relating to the calling terminal, the codecs to be used to decode the audio streams, routing information, etc. It includes at least one header relating to the identities of the parties (in English, “From and P-Asserted Identity (PAI)”) which are used to transport the logical addresses of the parties, such as the telephone number or MSISDN (for “Mobile Station International Subscriber Directory Number”) or the VoIP address of the calling terminal UE-A and the telephone number of the called party or his address VoIP.
  • P-Asserted Identity PAI
  • This latter header also includes an information field relating to the caller's name (“DisplayName”). However, we note that this field is little used when it is a voice call, because the telephone number assigned in the header "From and P-Asserted Identity (PAI)" of the caller is sufficient to validate the caller's identity and initiate presentation of the call to the called party.
  • DisplayName an information field relating to the caller's name
  • This SIP INVITE message is routed in the operator's RC communication network via several communication devices such as router devices, session controller devices and telephony application servers or TAS (for "Telephony Application Server”.
  • TAS Telephony Application Server
  • an application server is configured to retransmit the SIP INVITE messages that it sees passing and relays, to communication equipment or software applications configured to render dedicated services in connection with the processing of a telephone communication .
  • These communication devices and software applications are registered beforehand with the TAS application server. These include, for example, billing or proxy services.
  • a proxy is a server that acts as an intermediary and whose main purpose is to hide the details of the network from external connections in order to maintain its security. The proxy forwards requests to sensitive areas of the network without sharing any details of that network, such as the IP address.
  • the software applications in question may be hosted by the application server itself or by separate EQ communication equipment.
  • a communication device EQ configured to implement a caller identification service according to the invention. It implements the method for processing a call set-up request message according to the invention or incorporates a processing device 100 according to the invention which has just been presented in relation to FIG.
  • This table includes records, each associating with a telephone number of a subscriber user of the communication network operator RC, one or more additional information HERE on his identity. He therefore obtains for example:
  • this additional information is relatively permanent.
  • they have been recorded in the IDB table at the caller's request, in an initial and prior phase, generally following his subscription to the caller's identification service offered by the operator.
  • the table IDB can also include additional information ICC relating to a call context for one or more calls that the caller plans to make.
  • the communication equipment EQ therefore obtains for example:
  • this additional information relating to the ICC call is subject to change depending on the intentions of the caller.
  • they are recorded in the IDB table at the caller's request, just before making one or more calls.
  • the response obtained is empty and does not include any additional information.
  • the method comprises obtaining information on the reputation of the caller UE-A from a second data table, called the RDB reputation table, comprising entries associating with the telephone number of a caller reputation information, such as for example a type of caller.
  • a caller type includes a commercial type and refers to commercial solicitors, a fraudulent type and a legitimate type.
  • This RDB reputation table is updated over time by the operator, in a manner known per se.
  • Reputation information can be obtained in different ways by the communication network operator.
  • the latter uses reports issued by users who have already received calls from this caller to indicate that the caller is a telemarketing company, for example.
  • the operator can analyze call recordings to identify callers of the commercial or fraudulent canvassing type on the basis of predetermined call patterns. For example, a sales caller typically makes many calls to many different people in a short period of time. A fraudulent caller seeks to entice the called party to call back a premium rate telephone number by making numerous short calls and hanging up before the called party can answer (“ping calls”).
  • the response obtained includes at least one additional identification information ICI, such as the name of the user UT-A "UT-A-name and optionally, additional ICC call context information.
  • additional identification information ICI such as the name of the user UT-A "UT-A-name and optionally, additional ICC call context information.
  • the communication equipment EQ has obtained additional information IC, which includes additional caller identification information ICI and/or additional call context information ICC and/or IR reputation information about the calling user UT-A.
  • This or these additional information items IC contained in the response from the identity table are then inserted at 38 into an information field of a header of the call set-up request message REQ received, for example, according to the SIP protocol, the “DisplayName” field of the “From and P-Asserted Identity” header.
  • the message REQ thus modified is then designated by REQ'.
  • the call set-up request REQ′ thus completed or updated is routed at 39 to its final destination, namely the called terminal UE-B.
  • certain additional information on the identity of the caller is coded beforehand at 38 before being inserted into the call set-up request message REQ′. This includes additional information other than the name of the caller.
  • ⁇ are encoded using a code comprising a sequence of text-type characters corresponding to the additional information IC to be transmitted, flanked by two occurrences of a key-type character, said key-type character being associated with a particular type of information.
  • the key character is an asterisk (*) associated with the type of caller, such as *TELE * for a
  • the invention also provides for associating a key character with the name of the caller, such as “' " Where " " ".”
  • FIG. 4 in the form of a flowchart, an example of the implementation of a method of reception by a called terminal of a call setup request message transmitted by a calling terminal. in voice over IP in a communication network, according to one embodiment of the invention.
  • the calling terminal UE-A prior to sending a call, sends in the communication network RC a REG-ICI request for recording additional information identification ICI of the calling user UT-A in the identity table IDB.
  • This table is stored in said communication network and managed by it.
  • the method comprises a step of receiving at 41 a message confirming registration ACK_REG-ICI of said information in the identity table IDB, coming from the communication equipment EQ.
  • the terminal UE-A sends at 42 a request UP-REG to update the identity table IDB, said update request comprising at least additional context information ICC of the call, which specifies for example a subject of the call, an urgency level, an emotion of the caller, etc.
  • he receives at 43 a registration confirmation message ACK_UP-REG of said information in the identity table IDB, coming from the communication equipment EQ.
  • An advantage is to allow the dynamic update of the identity table managed by the communication network by the caller before the transmission of one or more next messages intended for one or more terminals called using information specific to the context of these calls.
  • FIG. 5 in the form of a flowchart, an example of implementation of a method of reception by a called terminal of a call setup request message transmitted by a calling terminal. in voice over IP in a communication network, according to one embodiment of the invention.
  • the terminal called UE-B integrates the device 200.
  • the reception method according to the invention is implemented by the device 200 in the form of a software application API_IDS_UEB.
  • the called terminal UE-B receives a call set-up request message, for example of the SIP INVITE type, coming from the calling terminal UE-A. It is assumed that this is the message REQ' enriched by the communication equipment EQ in accordance with the processing method which has just been described in relation to FIG. 4.
  • this information IC can comprise:
  • At least certain information extracted from the call establishment request message is coded using a code comprising a sequence of textual information flanked by two occurrences of a character key type.
  • the method comprises in 52 the decoding of the extracted information. Such decoding includes identifying said key type character and obtaining at least one type of information associated with the identified key character.
  • the key character "! can be used to frame the caller's name and indicate an urgent call.
  • the key character "?" can be used to frame the name of the caller and is intended to ask the called party if they are available to speak, or to indicate a subject of the call, such as "Attempting to access your account” or “your vehicle is ready to be picked up”).
  • the key character "*" is used to frame a sequence of textual characters qualifying a type of caller (SPAM for fraudulent, TELE for a commercial canvasser or even OK for a legitimate caller).
  • At least one notification action of the extracted information is determined according to the identified key character.
  • the determination comprises consulting a table of actions TA stored in memory, said table comprising entries associating one or more notification actions with a key character.
  • the key character "! used to designate a call emergency character is associated with the emission of a specific ring tone, presenting an urgent reason or with the display of the sequence of text in flashing red or with the display of an “URGENT” banner next to the text sequence.
  • the key character "%" used to frame a link to an associated image or video is associated with the action of fetching the file on the indicated link and displaying it on the screen of the terminal called.
  • the key character "*" used to indicate a type of caller or call is associated with the display of a window, for example of the "pop-up" type comprising the type of caller received in the text sequence.
  • the action triggered is also adapted to the value of the textual sequence extracted.
  • notifications are presented in Figures 6A to 6C.
  • a PI window is displayed on the screen of the called terminal UE-B to notify the user of a fraudulent call, following receipt of the additional information *SPAM*. It comprises, for example, a warning or danger sign or icon.
  • a window P2 is displayed on the screen of the terminal called UE-B to notify the user of an urgent call from a banking institution, following receipt of the additional information! ORANGE BANK I. For example, it includes a red banner indicating the urgency of the call.
  • a window P3 is displayed on the screen of the terminal called UE-B to notify the user of an urgent call relating to a delivery, following receipt of additional information Inom from the company + deliverer ! and %link_company_logo%.
  • the action(s) of notification of additional information on the identity of the caller are triggered when the call is presented to the caller on his terminal UE-B.
  • the user UT-A of the terminal UE-A has previously subscribed to the caller ID service offered by the operator of the communication network RC.
  • it sends a registration request REG-ICI for additional information identifying the user UT-A.
  • the communication equipment EQ records at 31 the information received in the identity table IDB and sends an acknowledgment message ACK_REG-ICI to the terminal UE-A. It is received by the terminal UE-A at 41.
  • the terminal UE-A sends an update request UP-REG of the additional information HERE.
  • ICC context information of a call to a called terminal which specifies for example a level of urgency of the call or a subject of this call or even an emotion of the caller UT-A associated with this call.
  • This information is therefore associated both with the telephone number of the caller UE-A and with a telephone number of a terminal UE-B that the user UT-A of the calling terminal UE-A wishes to call.
  • the terminal UE-A sends a call set-up request message REQ, for example of the SIP INVITE type, to the called terminal UE-B.
  • REQ for example of the SIP INVITE type
  • the communication equipment EQ is configured to intercept the call signaling messages exchanged between the calling terminal UE-A and the called terminal UE-B. More specifically, it ignores all messages and relays them unchanged to the receiving party, except for the REQ message.
  • the communication equipment EQ Upon receipt of the message REQ at 34, the communication equipment EQ implements the processing method according to the invention which has just been described in relation to FIG. 3. It extracts at 35 the telephone number of the caller , queries 36 at least the identity table IDB, from this telephone number to obtain additional information IC to add to the call establishment request. From the identity table IDB, it obtains additional caller identification information ICI and/or call context information ICC. For example, he gets the following response to his request to query the IDB identity table: Name: Orange
  • Additional information HERE includes the name of the caller is the company Orange and a link to its logo.
  • the call context information to the UE-B called party includes a high urgency level, a subject ("Attempting to access your account") and a caller's wish ("Are you available to speak ?”).
  • the "AppName” information field can specify the name of an application that will be launched when the user answers the call.
  • the qualification field indicates that the name and telephone number of the caller have been validated by the operator who manages the identity table of a caller. Optionally, it also consults an RDB reputation table, from which it obtains the caller's IR reputation information. For example, it does this when it has not found a record in the IDB identity table that matches the caller's phone number.
  • the communication equipment EQ decodes the information obtained, updates 38 the call set-up request message with the decoded information and retransmits at 39 the updated message REQ' to the called terminal UE-B.
  • the message REQ' is enriched with the aid of additional information relating to the identity of the calling user UT-A and/or to a context of the call, which are for example transmitted in the field "DisplayName" of the "From and P-Asserted Identity” header of said message.
  • the communication equipment EQ by implementing the invention, renders an intermediate service, called the caller's identity service, which is for example implemented in the form of a dedicated software application.
  • the latter On receipt of this REQ' message at 50 by the called terminal UE-B, the latter responds by sending back a signaling message in the communication network RC, for example of type 100 "TRYING", to indicate that it has received the call set-up request message and that it is not necessary to send any more.
  • a signaling message in the communication network RC for example of type 100 "TRYING"
  • the called terminal UE-B implements the reception method according to the invention which has just been presented in relation to FIG. 5.
  • the additional information IC inserted by the communication equipment EQ is extracted in 51, decoded at 52 and translated at 53 into notification actions to be triggered when the call is presented to the user UT-B at 54.
  • the called terminal UE-B then presents the call to the user UT- B by triggering the notification action(s) A of additional information relating to the identity of the caller.
  • the reception method according to the invention is implemented in the form of a dedicated software application, which has been previously loaded into the terminal called UE-B.
  • the called terminal UE-B sends the calling terminal UE- a message of the SIP 180 “RING” type to inform it that the user UT-B has been alerted.
  • these signaling messages can also contain additional information, added by the called terminal UE-B, for example relating to the codecs available on the called telephone, or to its ability to play so-called early media streams, such as only one free message played during the interval before a call is sent to voicemail.
  • the calling terminal UE-A receives the SIP message 180 “RINGING”.
  • the called terminal UE-B sends a 200 OK signaling message in the communication network RC. It is retransmitted to the calling terminal UE-A, which responds to it with an acknowledgment message, for example of type 200 “OK”. The acknowledgment message is retransmitted to the called terminal UE-B.
  • the data traffic for example in accordance with the RTP (for "Real Time Protocol") communication protocol, which contains the audio or video media streams of the communication between the two terminals, starts to be transmitted.
  • RTP for "Real Time Protocol
  • the encoded information inserted into the "DisplayName” information field is as follows:
  • the caller is the company Orange. This is an urgent call, because the name Orange is surrounded by the key character "!”. A link to the Orange logo is provided. The purpose of the call is to alert the called party to an attempt to access their account, as indicated by the key character "?"".
  • a device 100 for processing a call set-up request message in a local communication network comprising at least one module for receiving said message, a module for extracting a telephone number of the caller from said message, a module for updating an information field of said message by inserting additional information identifying the caller obtained from a first data table, called the caller's identity table, and a message routing module updated to the called terminal.
  • the device 100 further comprises a module for verifying the rights of the user of the calling terminal, a module and the update module is configured to insert reputation information into the call setup request message. of the caller obtained from a second table of data, called the reputation table.
  • it also comprises a module for receiving a request to add information associated with a telephone number of a caller coming from a calling terminal, said request comprising said telephone number and information relating to a content of a next call and a module for adding said information relating to a content of a next call to the additional identification information associated with said telephone number.
  • module can correspond both to a software component and to a hardware component or a set of hardware and software components, a software component itself corresponding to one or more computer programs or sub-programs or in a more general to any element of a program capable of implementing a function or a set of functions.
  • such a device 100 comprises a random access memory 103 (for example a RAM memory), a processing unit 102 equipped for example with a processor, and controlled by a computer program Pg, representative of the reception modules, extraction , interrogation, update and routing, stored in a read only memory 101 (for example a ROM memory or a hard disk).
  • a computer program Pg representative of the reception modules, extraction , interrogation, update and routing, stored in a read only memory 101 (for example a ROM memory or a hard disk).
  • the code instructions of the computer program are for example loaded into the random access memory 103 before being executed by the processor of the processing unit 102.
  • the random access memory 103 can also contain a data table comprising an entry associating the caller's telephone number with access rights to the caller's identification service.
  • FIG. 8 only illustrates one particular way, among several possible ones, of making the device 100 so that it performs the steps of the method for processing a request message for setting up a voice over IP call in a network of communication as detailed above, in relation to FIGS. 3 and 7 in its various embodiments. Indeed, these steps can be carried out either on a reprogrammable calculation machine (a PC computer, a DSP processor or a microcontroller) executing a program comprising a sequence of instructions, or on a dedicated calculation machine (for example a set of logic gates like an FPGA or an ASIC, or any other hardware module).
  • a reprogrammable calculation machine a PC computer, a DSP processor or a microcontroller
  • a program for example a set of logic gates like an FPGA or an ASIC, or any other hardware module.
  • the corresponding program (that is to say the sequence of instructions) could be stored in a removable storage medium (such as for example an SD card , a USB key, a CD-ROM or a DVD-ROM) or not, this storage medium being partially or totally readable by a computer or a processor.
  • a removable storage medium such as for example an SD card , a USB key, a CD-ROM or a DVD-ROM
  • FIG. 9 is an example of the hardware structure of a device 200 for sending a call setup request message sent by a calling terminal to a called terminal in a communication network.
  • a device 200 for sending a call setup request message sent by a calling terminal to a called terminal in a communication network comprising at least one module for sending a request for recording additional caller identification information in the identity table IDB, stored in said communication network, in association with a telephone number of the caller, a module for receiving a registration confirmation and a module for sending the call setup request message.
  • the device 200 also comprises a module for sending to the communication network a request for updating the identity table of the caller, said update request comprising at least context information of the call.
  • module can correspond both to a software component and to a hardware component or a set of hardware and software components, a software component itself corresponding to one or more computer programs or sub-programs or in a more general to any element of a program capable of implementing a function or a set of functions.
  • such a device 200 comprises a random access memory 203 (for example a RAM memory), a processing unit 202 equipped for example with a processor, and controlled by a computer program Pg2, representative of the reception modules, d activation, login, verification, selection, obtaining, awakening and execution, stored in a read only memory 201 (for example a ROM memory or a hard disk).
  • a read only memory 201 for example a ROM memory or a hard disk.
  • the code instructions of the computer program are for example loaded into the random access memory 203 before being executed by the processor of the processing unit 202.
  • the random access memory 203 can also contain the additional information that the user of the calling terminal requests to be recorded in the identity table of the communication network.
  • FIG. 9 only illustrates one particular way, among several possible ones, of making the device 200 so that it performs the steps of the method for sending a call set-up request message as detailed above, by relationship with Figures 4 and 7 in its various embodiments. Indeed, these steps can be carried out either on a reprogrammable calculation machine (a PC computer, a DSP processor or a microcontroller) executing a program comprising a sequence of instructions, or on a dedicated calculation machine (for example a set of logic gates like an FPGA or an ASIC, or any other hardware module).
  • a reprogrammable calculation machine a PC computer, a DSP processor or a microcontroller
  • a dedicated calculation machine for example a set of logic gates like an FPGA or an ASIC, or any other hardware module.
  • the corresponding program (that is to say the sequence of instructions) can be stored in a removable storage medium (such as for example an SD card , a USB key, a CD-ROM or a DVD-ROM) or not, this storage medium being partially or totally readable by a computer or a processor.
  • a removable storage medium such as for example an SD card , a USB key, a CD-ROM or a DVD-ROM
  • an example of the hardware structure of a device 300 for reception by a called terminal of a call setup request message transmitted by a call terminal in a communication network comprising at least one module for receiving said message, a module for extracting additional information relating to the caller from an information field of the message received and a module for triggering at least one action comprising a notification of said information to a user of the called terminal.
  • the device 300 also comprises a module for decoding said information, said decoding comprising the identification of said key-type character and a module for determining a notification action to be triggered at least as a function of the identified key-type character.
  • module can correspond both to a software component and to a hardware component or a set of hardware and software components, a software component itself corresponding to one or more computer programs or sub-programs or in a more general to any element of a program capable of implementing a function or a set of functions.
  • a device 300 comprises a random access memory 303 (for example a RAM memory), a processing unit 302 equipped for example with a processor, and controlled by a computer program Pg, representative of the reception modules, extraction , decoding, determination and triggering, stored in a read only memory 301 (for example a ROM memory or a hard disk).
  • a read only memory 301 for example a ROM memory or a hard disk.
  • the computer program code instructions are for example loaded into the random access memory 303 before being executed by the processor of the processing unit 302.
  • the random access memory 303 can also contain a table comprising a entry associating a key character with one or more actions to be triggered when the call is presented.
  • FIG. 10 only illustrates one particular way, among several possible ones, of making the device 300 so that it performs the steps of the method for receiving a call establishment request message as detailed above, in relation with Figures 5, 6 and 7 in its various embodiments. Indeed, these steps can be carried out either on a reprogrammable calculation machine (a PC computer, a DSP processor or a microcontroller) executing a program comprising a sequence of instructions, or on a dedicated calculation machine (for example a set of logic gates like an FPGA or an ASIC, or any other hardware module).
  • a reprogrammable calculation machine a PC computer, a DSP processor or a microcontroller
  • a program comprising a sequence of instructions
  • a dedicated calculation machine for example a set of logic gates like an FPGA or an ASIC, or any other hardware module.
  • the corresponding program (that is to say the sequence of instructions) can be stored in a removable storage medium (such as for example an SD card , a USB key, a CD-ROM or a DVD-ROM) or not, this storage medium being partially or totally readable by a computer or a processor.
  • a removable storage medium such as for example an SD card , a USB key, a CD-ROM or a DVD-ROM
  • the invention which has just been described in its various embodiments has numerous advantages. Indeed, by enriching the call presented to the called terminal with the help of caller identification information, which is managed and validated, and therefore trustworthy, by the communication network, it contributes to increasing the rate call acceptance by the called terminals.
  • the enrichment of the call since the enrichment of the call is carried out in the communication network, it does not introduce any latency at the level of the called terminal before the presentation of the call to the user.
  • this enrichment is based on information stored in a single table managed by the network operator and as a result, they are transmitted according to a single data format, which simplifies their interpretation and their use by the called terminals.
  • the invention does not involve any modification of the syntax of the call signaling messages, since the additional information is advantageously transmitted in an information field of the call setup message which is already provided for by the standard, but was not yet used in practice.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Telephonic Communication Services (AREA)

Abstract

L'invention concerne un procédé de traitement d'un message (REQ) de demande d'établissement d'appel émis par un terminal appelant (UE‐A) vers un terminal appelé (UE‐B) dans un réseau de communication (RC), ledit réseau comprenant un équipement de communication (EQ) configuré pour recevoir (34) ledit message. Ledit procédé est mis en œuvre au niveau dudit équipement de communication et comprend : la mise à jour (38) d'un champ d'information dudit message (REQ, REQ') par insertion d'informations complémentaire d'identification de l'appelant obtenues d'au moins une première table de données; et la transmission (39) du message mis à jour (REQ') vers le terminal appelé (UE‐B).

Description

Procédé de traitement d'un appel téléphonique dans un réseau de communication, procédé d'émission, procédé de réception d'un tel appel, dispositifs, système et programmes d'ordinateur correspondants
Domaine technique de l'invention
Le domaine de l'invention est celui d'un réseau de communication configuré pour acheminer des appels, par exemple en voix sur IP. L'invention concerne en particulier l'enrichissement de tels appels par des informations d'identité de l'appelant.
Art antérieur
Beaucoup d'appels téléphoniques sont laissés sans réponse lorsque l'utilisateur appelé ne reconnaît pas le numéro de téléphone de l'appelant. En effet, les démarchages commerciaux ne passent plus par l'utilisation de numéros spéciaux facilement reconnaissables, mais impliquent au contraire tout type de numéro de téléphone fixe ou mobile et l'utilisateur appelé préfère souvent ne pas répondre pour éviter d'être dérangé.
Cela signifie qu'il peut manquer des appels légitimes et importants par exemple de la part d'un médecin, d'un hôpital, d'une école ou d'un livreur. Pire, le terminal de cet utilisateur peut bloquer le numéro de téléphone de l'appelant, si ce dernier renouvelle son appel.
Il existe déjà une solution pour tenter de résoudre ce problème, qui consiste notamment à installer une application logicielle spécifique sur le terminal de l'appelé. A la réception d'un appel en provenance d'un numéro de téléphone appelant inconnu, et notamment non enregistré dans les contacts de l'utilisateur appelé, l'application en question interroge une ou plusieurs bases de données accessibles sur Internet pour découvrir l'identité de l'appelant, les raisons de son appel et éventuellement des informations complémentaires à présenter à l'appelé, comme le nom de la société, un lien vers son site internet, etc.
Un premier inconvénient de cette solution est qu'elle introduit une latence dans le traitement de l'appel reçu. Un deuxième inconvénient est qu'elle ne fonctionne que si l'identité de l'appelant est bien enregistrée dans la base de données interrogée par l'application et si la base de données peut être inaccessible au moment de l'appel. Un troisième inconvénient est que plusieurs bases de données cohabitent sans mise en commun de règles de stockage ou de format des informations d'identité des appelants. Les sociétés qui souhaitent s'enregistrer auprès de telles bases doivent donc multiplier les démarches d'enregistrement, sans garantie de succès.
Il existe donc un besoin d'une solution plus performante et plus efficace.
L'invention vient améliorer la situation.
Présentation de l'invention L'invention répond à ce besoin en proposant un procédé de traitement d'un message de demande d'établissement d'appel émis par un terminal appelant vers un terminal appelé dans un réseau de communication, ledit réseau comprenant un équipement de communication configuré pour recevoir ledit message.
Ledit procédé est mis en oeuvre au niveau dudit équipement de communication et comprend :
- la mise à jour d'un champ d'information dudit message par insertion d'informations complémentaires d'identification de l'appelant obtenues d'au moins une première table de données ; et
- la transmission du message mis à jour vers le terminal appelé.
L'invention propose une approche tout-à-fait nouvelle et inventive du traitement d'un appel, qui consiste à enrichir l'appel d'informations complémentaires d'identification de l'appelant stockées dans le réseau de communications et donc préalablement vérifiées. De la sorte, l'appelé bénéficie de ces informations d'identification vérifiées dès réception de l'appel sur son terminal et sans latence. Mieux informé, l'utilisateur appelé est donc plus enclin à prendre l'appel. Il en résulte que l'invention contribue à réduire le nombre d'appels non répondus par manque d'information sur l'appelant. Avantageusement, l'appel est émis en voix sur IP et le champ d'informations mis à jour est un champ d'un en-tête dudit message de demande d'établissement d'appel. Par exemple, en SIP, il s'agit du champ « Display Name» de l'en-tête « From and P-asserted-ldentity header du message SIP INVITE. Par exemple, lesdites informations complémentaires d'identification de l'appelant obtenues de la première table appartiennent à un groupe comprenant au moins :
- un nom de l'appelant ;
- une information relative à une image ou une vidéo associée à l'appelant.
L'information relative à une image ou une vidéo associée à l'appelant peut comprendre un lien vers ce fichier. Par exemple, le fichier en question comprend un logo de la société et/ou une photographie de l'appelant et/ou une annonce publicitaire de la société.
Avantageusement, le procédé comprend en outre l'interrogation de la première table de données, par exemple appelée table d'identités de l'appelant, à partir d'un numéro de téléphone de l'appelant extrait dudit message.
Selon un aspect de l'invention, lorsqu'aucune information complémentaire n'est obtenue de la première table de données, la mise à jour comprend l'insertion d'informations de réputation obtenues d'une deuxième table de données, dans le message de demande d'établissement d'appel. Par exemple, une information de réputation indique un type d'appelant parmi les valeurs possibles suivantes : démarcheur commercial (« TELE »), frauduleux (« SPAM ») ou légitime (« OK »). Avantageusement, le procédé comprend en outre l'interrogation de la deuxième table de données, par exemple appelée table de réputation de l'appelant, à partir d'un numéro de téléphone de l'appelant extrait dudit message.
Selon un autre aspect de l'invention, le procédé comprend en outre :
- la réception d'une demande d'ajout d'informations complémentaires associées au numéro de téléphone de l'appelant en provenance du terminal appelant, ladite demande comprenant ledit numéro de téléphone et lesdites informations ; et
- le stockage desdites informations dans la première table de données en association avec ledit numéro de téléphone.
Il s'agit, dans une phase initiale, d'informations complémentaires d'identification de l'appelant. Avantageusement, dans une phase suivante, il peut s'agir d'informations complémentaires relatives à un contexte d'appel. Par exemple, ces informations renseignent un objet de l'appel, un niveau d'urgence, une émotion de l'appelant etc. Elles contribuent à enrichir encore davantage la présentation de l'appel à l'appelé.
Avantageusement, le procédé comprend en outre la vérification préalable d'une autorisation du terminal appelant à mettre à jour la première table de données, l'ajout des informations reçues dans la table étant conditionné par cette vérification. Optionnellement, il comprend en outre l'émission d'un message de confirmation d'enregistrement à destination du terminal appelant.
Selon encore un autre aspect de l'invention, le procédé comprend le codage d'au moins une desdites informations obtenues sous forme d'un code comprenant une séquence de caractères de type texte encadrée par deux occurrences d'un caractère de type clé, ledit caractère de type clé étant associé à une information de contexte d'appel prédéterminée.
Par exemple, le caractère clé est une astérisque « ** » associée à une information de réputation de l'appelant. Selon un autre exemple, le caractère clé « %% » est utilisé pour encadrer un lien vers un fichier image ou vidéo associé à l'appelant.
L’invention concerne également un dispositif de traitement d'un message de demande d'établissement d'appel émis par un terminal appelant vers un terminal appelé dans un réseau de communication, ledit réseau comprenant un équipement de communication configuré pour recevoir ledit message. Ledit dispositif est configuré pour mettre en oeuvre au niveau dudit équipement de communication :
- la mise à jour d'un champ d'information dudit message par insertion d'informations complémentaires d'identification de l'appelant obtenues d'au moins une première table de données; et
- la transmission du message mis à jour vers le terminal appelé. Avantageusement, ledit dispositif configuré pour mettre en oeuvre les étapes du procédé de traitement tel que décrit précédemment. Le dispositif de traitement présente en combinaison tout ou partie des caractéristiques exposées dans l'ensemble de ce document.
Avantageusement, ledit dispositif est intégré dans un équipement de communication d'un réseau de communication, configuré pour intercepter un message de demande d'établissement d'un appel en voix sur IP émis par un terminal appelant vers un terminal appelé.
L'équipement de communication et le dispositif de traitement présentent au moins les mêmes avantages que ceux conférés par le procédé de traitement précité.
Corrélativement, l'invention concerne aussi un procédé d'émission d'un message de demande d'établissement d'appel par un terminal appelant vers un terminal appelé dans un réseau de communication. Ledit procédé est mis en oeuvre au niveau du terminal appelant et comprend, préalablement à l'émission dudit message :
- l'émission d'une demande d'enregistrement d'informations complémentaires d'identification de l'appelant dans une première table de données stockée dans ledit réseau de communication, en association avec un numéro de téléphone de l'appelant, lesdites informations complémentaires d'identification de l'appelant étant destinées à être utilisées par un équipement de communication configuré pour recevoir ledit message de demande d'établissement d'appel, l'enrichir au moins à l'aide des informations contenues dans ladite première table et le retransmettre au terminal appelé. Par exemple, le terminal appelant comprend une application logicielle dédiée configurée pour renseigner une telle première table, par exemple appelée table d'identités de l'appelant, gérée par l'opérateur du réseau.
Avantageusement, il reçoit une confirmation d'enregistrement desdites informations de la part de l'équipement de communication.
Selon un aspect de l'invention, le procédé comprend en outre l'émission à destination du réseau de communication d'une demande de mise à jour de la première table de données, ladite demande de mise à jour comprenant au moins une information de contexte de l'appel.
Les informations de contexte d'un appel précisent par exemple un motif ou un objet de l'appel, un niveau d'urgence, une émotion de l'appelant etc.
De la sorte, la table d'identités gérée par le réseau de communication est mise à jour dynamiquement par l'appelant avant l'émission d'un ou plusieurs prochains messages à destination d'un ou plusieurs terminaux appelés à l'aide d'informations spécifiques au contenu de ces appels. L'invention concerne également un dispositif d'émission d'un message de demande d'établissement d'appel par un terminal appelant vers un terminal appelé dans un réseau de communication. Ledit dispositif est configuré pour mettre en oeuvre au niveau du terminal appelant, préalablement à l'émission dudit message :
- l'émission d'une demande d'enregistrement d'informations complémentaires d'identification de l'appelant dans une première table de données, stockée dans ledit réseau de communication, en association avec un numéro de téléphone de l'appelant, lesdites informations complémentaires d'identification de l'appelant étant destinées à être utilisées par un équipement de communication configuré pour recevoir ledit message de demande d'établissement d'appel, l'enrichir au moins à l'aide des informations contenues dans ladite première table et le retransmettre au terminal appelé. Avantageusement, ledit dispositif configuré pour mettre en oeuvre les étapes du procédé d'émission tel que décrit précédemment. Le dispositif d'émission présente en combinaison tout ou partie des caractéristiques exposées dans l’ensemble de ce document.
Avantageusement, ledit dispositif est intégré dans un terminal d'un utilisateur configuré pour émettre un message de demande d'établissement d'appel en voix sur IP vers un terminal appelant par l'intermédiaire d'un réseau de communication.
Le terminal utilisateur et le dispositif d'émission présentent au moins les mêmes avantages que ceux conférés par le procédé d'émission précité.
Corrélativement, l'invention concerne aussi un procédé de réception d'un message de demande d'établissement d'appel par un terminal appelé émis par un terminal appelant dans un réseau de communications. Ledit procédé est mis en oeuvre au niveau du terminal appelé et comprend, sur réception dudit message :
- l'extraction d'informations complémentaires relatives à un utilisateur du terminal appelant d'un champ d'information du message reçu ; et
- le déclenchement d'au moins une action comprenant une notification desdites informations à un utilisateur du terminal appelé lors d'une présentation de l'appel.
Selon l'invention, du fait que les informations complémentaires relatives à l'appelant sont contenues dans la signalisation du message, le terminal appelé peut les exploiter directement pour enrichir la notification de l'appel.
Avantageusement, les informations complémentaires (extraites appartiennent à un groupe comprenant au moins : des informations complémentaires d'identification de l'appelant ; des informations relatives à un contexte de l'appel ; des informations de réputation de l'appelant.
Avantageusement, les informations complémentaires d'identification de l'appelant proviennent d'une première table de données, gérée par l'opérateur du réseau de communication de l'appelant et ont été préalablement intégrées dans la table sur demande de l'appelant, qui a par souscrit à un service dédié.
Par exemple, les informations relatives à un contexte de l'appel sont issues de cette première table de données et ont été transmises par l'appelant à la première table avant d'émettre l'appel. Cette possibilité de modification dynamique des informations complémentaires contenues dans la base permet à un appelant d'enrichir un ou plusieurs appels destinés à un ou plusieurs clients pour leur indiquer un niveau d'urgence de l'appel ou une raison de l'appel (« êtes-vous disponibles pour parler ?) ou une émotion associée à cet appel à l'aide d'un ou plusieurs émoticônes.
Enfin, les informations de réputation proviennent avantageusement d'une deuxième table de données, gérée elle-aussi par l'opérateur du réseau de communication, mais qui n'est pas renseignée à partir d'informations fournies par les appelants eux-mêmes. Par exemple, elles indiquent si l'appelant est légitime, frauduleux, démarcheur commercial, etc.
Selon un aspect de l'invention, au moins une desdites informations complémentaires relatives à l'appel est codée sous la forme d'une séquence de caractères de type texte encadrée par deux occurrences d'un caractère de type clé, le procédé de réception comprend le décodage de ladite information, ledit décodage comprenant l'identification dudit caractère de type clé et le procédé comprend la détermination d'au moins une action de notification déclenchée au moins en fonction du caractère de type clé identifié.
Par exemple le caractère clé « * » est utilisé pour encadrer une séquence de caractères textuels qualifiant une réputation de l'appelant (SPAM pour frauduleux, TELE pour un démarcheur commercial ou encore OK pour un appelant légitime). Selon un autre exemple, le caractère clé « ! » encadre le nom de l'appelant et indique un appel urgent. Selon encore un autre exemple, le caractère clé ? encadre le nom de l'appelant et vise à demander à l'appelé s'il est disponible pour parler.
Un avantage de tels caractères clés est qu'ils peuvent être reconnus par le terminal de l'appelé qui est configuré pour les traduire en notifications spécifiques (affichage, sonnerie, vibration, etc) qui prennent de ce fait une signification particulière pour l'appelé. Par exemple, l'affichage d'un nom d'appelant entre « ! »! est traduit par un affichage du nom de l'appelant en rouge clignotant, généralement associé à la notion d'urgence ou à l'émission d'une sonnerie pressante.
Par exemple, l'identification d'une séquence encadrée par le caractère clé « * » déclenche l'affichage d'une fenêtre (pop-up) indiquant le type d'appel (commercial, frauduleux, légitime).
Par exemple, l'identification d'une séquence encadrée par le caractère clé « % » déclenche le téléchargement de l'image ou de la vidéo sur le lien indiqué puis son affichage sur l'écran du terminal de l'appelé. L'invention concerne également un dispositif de réception d'un message de demande d'établissement d'appel par un terminal appelé émis par un terminal appelant dans un réseau de communications , caractérisé en ce qu'il est configuré pour mettre en oeuvre au niveau du terminal appelé et comprend, sur réception dudit message :
- l'extraction d'informations complémentaires relatives à un utilisateur du terminal appelant d'un champ d'information du message reçu ; et
- le déclenchement d'au moins une action comprenant une notification desdites informations à un utilisateur du terminal appelé lors d'une présentation de l'appel.
Avantageusement, ledit dispositif est configuré pour mettre en oeuvre les étapes du procédé de réception tel que décrit précédemment. Le dispositif de réception présente en combinaison tout ou partie des caractéristiques exposées dans l’ensemble de ce document.
Avantageusement, ledit dispositif de réception est intégré dans un terminal d'un utilisateur configuré pour recevoir un message de demande d'établissement d'appel en voix sur IP en provenance d'un terminal appelant par l'intermédiaire d'un réseau de communication.
Le terminal utilisateur et le dispositif de réception présentent au moins les mêmes avantages que ceux conférés par le procédé de réception précité.
Corrélativement, l'invention concerne aussi une table de données d'un réseau de communication, comprenant des enregistrements associant au moins des informations complémentaires d'identification d'un appelant à un numéro de téléphone de cet appelant.
Par exemple, cette table de données est organisée sous la forme d'une base de données indexée par les numéros de téléphones des appelants. Avantageusement, elle comprend des informations relatives à un contexte d'un appel, ajoutées dynamiquement par l'appelant avant d'émettre cet appel dans le réseau.
Corrélativement, l'invention concerne aussi un système de gestion d'un message de demande d'établissement d'appel émis en voix sur IP par un terminal appelant vers un terminal appelé dans un réseau de communication, comprenant le dispositif de traitement, la première table de données, le dispositif d'émission et le dispositif de réception précités.
L'invention concerne également des produits programme d’ordinateur comprenant des instructions de code de programme pour la mise en oeuvre des procédés tels que décrits précédemment, lorsqu'ils sont exécutés par un processeur.
Un programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. L'invention vise également un support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions de code de programme pour l'exécution des étapes des procédés selon l'invention tel que décrits ci-dessus.
Un tel support d’enregistrement peut être n’importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu’une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d’enregistrement magnétique, par exemple un support mobile (carte mémoire) ou un disque dur ou un SSD.
D’autre part, un tel support d’enregistrement peut être un support transmissible tel qu’un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d’autres moyens, de sorte que le programme d'ordinateur qu'il contient est exécutable à distance. Le programme selon l’invention peut être en particulier téléchargé sur un réseau par exemple le réseau Internet.
Alternativement, le support d’enregistrement peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l’exécution du procédé de contrôle d'affichage précité.
Selon un exemple de réalisation, la présente technique est mise en oeuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme "module" peut correspondre dans ce document aussi bien à un composant logiciel, qu’à un composant matériel ou à un ensemble de composants matériels et logiciels.
Un composant logiciel correspond à un ou plusieurs programmes d’ordinateur, un ou plusieurs sous- programmes d’un programme, ou de manière plus générale à tout élément d’un programme ou d’un logiciel apte à mettre en oeuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci- dessous pour le module concerné. Un tel composant logiciel est exécuté par un processeur de données d’une entité physique (terminal, serveur, passerelle, set-top-box, routeur, etc.) et est susceptible d’accéder aux ressources matérielles de cette entité physique (mémoires, supports d’enregistrement, bus de communication, cartes électroniques d'entrées/sorties, interfaces utilisateur, etc.). Par la suite, on entend par ressources tous ensembles d'éléments matériels et/ou logiciels support d'une fonction ou d'un service, qu'ils soient unitaires ou combinés.
De la même manière, un composant matériel correspond à tout élément d’un ensemble matériel (ou hardware) apte à mettre en oeuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné. Il peut s'agir d'un composant matériel programmable ou avec processeur intégré pour l'exécution de logiciel, par exemple un circuit intégré, une carte à puce, une carte à mémoire, une carte électronique pour l'exécution d'un micrologiciel (« firmware » en anglais), etc. Chaque composante du système précédemment décrit met bien entendu en oeuvre ses propres modules logiciels.
Les différents modes de réalisation mentionnés ci-dessus sont combinables entre eux pour la mise en oeuvre de la présente technique.
Brève description des figures
D'autres buts, caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante, donnée à titre de simple exemple illustratif, et non limitatif, en relation avec les figures, parmi lesquelles :
Figure 1 : présente un exemple d'architecture d'un système de traitement d'un message de demande d'établissement d'un appel en voix sur IP dans un réseau de communication, selon l'invention ;
Figure 2 : illustre de façon schématique un exemple d'architecture d'un équipement de communication du réseau de communication, ledit équipement intégrant un dispositif de traitement d'un message de demande d'établissement d'appel selon un mode de réalisation de l'invention et un exemple d'un terminal utilisateur, intégrant un dispositif de réception d'un message de demande d'établissement d'appel selon un mode de réalisation de l'invention;
Figure 3 : décrit sous forme d'un logigramme les étapes d'un procédé de traitement d'un message de demande d'établissement d'appel par l'équipement de communication, selon un exemple de réalisation de l'invention ;
Figure 4 : décrit sous forme d'un logigramme les étapes d'un procédé d'émission d'un message de demande d'établissement d'appel par le terminal appelant, selon un exemple de réalisation de l'invention ;
Figure 5 : décrit sous forme d'un logigramme les étapes d'un procédé de réception d'un message de demande d'établissement d'appel par le terminal appelé, selon un exemple de réalisation de l'invention ;
Figure 6A, Figure 6B, Figure 6C: illustrent des exemples d'affichages d'informations complémentaires d'identification d'un appelant sur le terminal appelé selon l'invention ;
Figure 7 : décrit sous forme d'un diagramme de flux les échanges entre un terminal utilisateur appelant, l'équipement de communication et un terminal utilisateur appelé selon un exemple de réalisation de l'invention ;
Figure 8 : décrit un exemple de structure matérielle d'un dispositif de traitement d'un message de demande d'établissement d'appel selon l'invention ;
Figure 9 : décrit un exemple de structure matérielle d'un dispositif d'émission d'un message de demande d'établissement d'appel selon l'invention ; et Figure 10 : décrit un exemple de structure matérielle d'un dispositif de réception d'un message de demande d'établissement d'appel selon l'invention ;
Description détaillée de l'invention
L'invention concerne le traitement d'un appel émis en voix sur IP dans un réseau de communication par un terminal appelant vers un terminal appelé.
Le principe général de l'invention repose sur l'enrichissement, au niveau du réseau de communication, du message de signalisation de l'appel, à l'aide d'informations complémentaires d'identifications de l'appelant stockées dans au moins une base de données gérée par l'opérateur du réseau de communication. Ces informations sont notifiées par le terminal appelé lors de la présentation de l'appel entrant à son utilisateur. De la sorte, l'appelé bénéficie sans latence d'informations complémentaires fiables sur l'identité de l'appelant, ce qui lui permet de décider d'accepter ou de refuser l'appel en connaissance de cause.
L'invention trouve une application particulièrement intéressante pour les professionnels qui souhaitent voir leurs appels vers des clients ou des fournisseurs aboutir.
Elle s'applique au traitement d'appels téléphoniques en voix sur IP par un réseau de communication fixe ou mobile, par exemple selon une technologie VoLTE (pour « Voice over Long Term Evolution », en anglais), ViLTE (pour « Video over Long Term Evolution », en anglais) ou VoIP (pour « Voice over Internet Protocol », en anglais). Ces différentes technologies s'appuient généralement sur un protocole de signalisation, par exemple de type SIP (pour « Signalling Internet Protocol », en anglais) pour établir et gérer une session de communication téléphonique.
Bien sûr, l'invention n'est pas limitée à ce protocole et s'applique à tout autre protocole permettant la signalisation d'appel en voix sur IP. Néanmoins, dans la suite de la description, les exemples présentés mettront en oeuvre ce protocole de signalisation.
On présente désormais, en relation avec la figure 1, un exemple d'architecture d'un système 10 de traitement d'un message de demande d'établissement d'un appel en voix sur IP dans un réseau de communication RC selon un exemple de réalisation de l'invention. Dans cet exemple, on a représenté schématiquement, comme une seule entité, le réseau de communication RC d'un opérateur, sans faire apparaître, par souci de simplicité, ses différents réseaux d'accès. On suppose que ce réseau de communication RC met en oeuvre au moins une des technologies de voix sur IP précédemment évoquées. Dans cet exemple, un premier équipement terminal UE-A se connecte au réseau de communication RC via un réseau d'accès fixe (non représenté) de type ADSL ou fibre. Le premier équipement terminal UE-A est connecté au réseau de communication local (non représenté) d'une passerelle résidentielle ou professionnelle GW, par exemple à l'aide d'une connexion filaire, par exemple de type Ethernet ou sans fil, par exemple de type Wi-Fi. Bien sûr l'invention n'est pas limitée à cet exemple et s'applique tout aussi bien à un réseau d'accès mobile de type cellulaire, auquel se connecte le premier équipement terminal UEA par une liaison de type 2G à 5G.
On suppose que le premier équipement terminal UE-A, dit terminal appelant, émet une demande d'établissement d'appel en voix sur IP vers un deuxième équipement terminal UE-B d'un utilisateur UTB, dit terminal appelé, lui aussi connecté au réseau de communication RC. Par exemple, les terminaux UE-A et UE-B sont des téléphones de type téléphone intelligent (pour « smartphone », en anglais). Bien sûr, il peut s'agir aussi de téléphones fixes, par exemple sans fil de type DECT (pour «Digital Enhanced Cordless Télécommunications », en anglais), de tablettes, d'ordinateurs personnels, etc, plus généralement de n'importe quels terminaux utilisateurs pourvu qu'ils soient dotés d'une interface avec le réseau d'accès au réseau RC disponible à proximité et configurés pour gérer une communication téléphonique en voix sur IP par l'intermédiaire de ce réseau.
Comme illustré par la figure 1, le système 10 selon l'invention comprend, en plus des deux terminaux appelant UE-A et appelé UE-B, un équipement de communication EQ du réseau de communication RC. Cet équipement de communication EQ est placé sur le chemin du message de demande d'établissement d'appel émis par le terminal appelant UE-A. Il s'agit par exemple d'un équipement routeur, d'un serveur d'applications téléphoniques ou TAS (pour « Téléphoné Application Server », en anglais) ou bien de tout autre équipement de communication du réseau RC. Selon l'invention, un tel équipement EQ est configuré pour interroger au moins une première table de données, dite table d'identités d'un appelant IDB, gérée par le réseau de communication RC.
Dans l'exemple particulier de réalisation de la figure 1, l'équipement EQ comprend deux équipements distincts, connectés entre eux : un équipement serveur TAS et un équipement EIDS mettant en oeuvre un service d'identification d'appelant IDS. En effet, dans un réseau d'opérateur comme le réseau RC, il est courant qu'un serveur d'application communique avec différents équipements dédiés à la mise en oeuvre de services spécifiques, comme l'équipement EIDS. De tels équipements se sont préalablement enregistrés auprès du serveur d'application TAS afin qu'il leur retransmette certains messages de signalisation d'appels. Bien sûr, l'invention n'est pas limitée à cet exemple et s'applique aussi lorsque l'équipement EQ est le serveur d'application TAS lui-même et qu'il héberge plusieurs applications logicielles mettant chacune en oeuvre un service spécifique et en particulier le service d'identification d'appelant IDS.
La figure 2 présente un exemple d'architecture de l'équipement de communication EQ selon un mode de réalisation de l'invention. Selon cet exemple, l'équipement de communication EQ comprend un dispositif 100 de traitement d'un message de demande d'établissement d'appel selon l'invention. Ce dispositif est configuré pour intercepter ledit message, en extraire un numéro de téléphone de l'appelant, obtenir des informations complémentaires d'identification de l'appelant par interrogation de la table d'identités IDB à partir dudit numéro de téléphone, mettre à jour un champ d'information dudit message par insertion des informations obtenues et router le message mis à jour vers le terminal appelé.
Avantageusement, le dispositif 100 est configuré pour recevoir une demande d'enregistrement d'informations complémentaires dans la table d'identités, en association avec le numéro de téléphone de l'appelant, vérifier que l'appelant est autorisé à enregistrer des données dans cette table et lui envoyer une confirmation d'enregistrement.
Le dispositif 100 met ainsi en oeuvre le procédé de traitement d'un message de demande d'établissement d'appel selon l'invention qui sera détaillé ci-après en relation avec la figure 3. Selon un mode de réalisation, il est implémenté sous la forme d'une application logicielle API-IDS de type API (pour « Application Programming Interface », en anglais), installée sur l'équipement EQ. Avantageusement, cette application est dédiée à la mise en oeuvre du service d'identification de l'appelant selon l'invention.
Alternativement, le dispositif 100 peut être indépendant de l'équipement EQ, mais connecté à celui- ci par une liaison quelconque, filaire ou non.
La figure 2 présente aussi un exemple d'architecture d'un terminal utilisateur UE-A, ou terminal appelant, selon un mode de réalisation de l'invention. Selon cet exemple, le terminal appelant UE-A comprend un dispositif 200 d'émission d'un message de demande d'établissement d'appel émis par le terminal UE-A. Selon l'invention, le terminal appelé UE-A est configuré pour, préalablement à l'émission dudit message, demander un enregistrement d'informations complémentaires d'identification de l'appelant dans une première table de données, dite table d'identités de l'appelant, stockée dans ledit réseau de communication, en association avec un numéro de téléphone de l'appelant, lesdites informations complémentaires d'identification de l'appelant étant destinées à être utilisées par un équipement de communication configuré pour recevoir ledit message de demande d'établissement d'appel, l'enrichir au moins à l'aide des informations contenues dans ladite table d'identités et le retransmettre au terminal appelé.
Avantageusement, le dispositif est en outre configuré pour demander une mise à jour de la table d'identités de l'appelant, la demande de mise à jour comprenant au moins une information complémentaire de contexte de l'appel.
Le dispositif 200 met ainsi en oeuvre le procédé d'émission d'un message de demande d'établissement d'appel selon l'invention qui sera détaillé ci-après en relation avec la figure 4. Selon un mode de réalisation, il est implémenté sous la forme d'une application logicielle API-IDS-UE- A de type API, installée sur le terminal appelant UE-A. Avantageusement, cette application est dédiée à l'utilisation du service d'identification de l'appelant par le terminal appelant selon l'invention.
La figure 2 présente enfin un exemple d'architecture d'un terminal utilisateur UE-B, ou terminal appelé, selon un mode de réalisation de l'invention. Selon cet exemple, le terminal appelé UE-B comprend un dispositif 300 de réception d'un message de demande d'établissement d'appel émis par le terminal UEA. Selon l'invention, le terminal appelé UE-B est configuré pour recevoir ledit message en provenance du réseau, extraire des informations d'identification de l'appelant d'un champ d'information du message reçu, et déclencher au moins une action comprenant une notification desdites informations d'identification de l'appelant à un utilisateur du terminal appelé.
Le dispositif 200 met ainsi en oeuvre le procédé de réception d'un message de demande d'établissement d'appel selon l'invention qui sera détaillé ci-après en relation avec la figure 5.
Selon un mode de réalisation, il est implémenté sous la forme d'une application logicielle API-IDS-UE- B de type API, installée sur le terminal appelé UE-B. Avantageusement, cette application est dédiée à l'utilisation du service d'identification de l'appelant par le terminal appelé selon l'invention.
On présente désormais, en relation avec la figure 3, sous une forme de logigramme, un exemple de mise en oeuvre d'un procédé de traitement d'un message de demande d'établissement d'appel selon un mode de réalisation de l'invention. Ce procédé est mis en oeuvre par un équipement de communication EQ configuré pour recevoir les messages de demandes d'établissement d'appel émis par les terminaux appelants. Comme précédemment évoqué, il est par exemple implémenté sous la forme d'une application logicielle APIJDS.
Dans une phase d'initialisation, préalable à la réception d'un message de demande d'établissement d'appel, l'équipement de communication EQ reçoit en 30 un message REGJCI de demande d'enregistrement d'informations complémentaires d'identification de l'appelant ICI en provenance du terminal UE-A. En 31, les informations ICI reçues sont enregistrées dans la table d'identités IDB en association avec le numéro de téléphone du terminal UE-A. Avantageusement, cette étape d'enregistrement est conditionnée par une vérification préalable que l'utilisateur UT-A du terminal UE-A est bien autorisé à enregistrer des informations dans cette table, parce qu'il a souscrit au service d'identification de l'appelant de l'opérateur du réseau RC. Par exemple, l'utilisateur UT-A du terminal UE-A a fourni des informations sur son identité à l'opérateur qui gère la table d'identité lors d'une phase préalable d'enregistrement, par exemple en complétant un formulaire en ligne. Les informations d'identité en question comprennent par exemple son nom, son numéro de téléphone etc, et sont stockées dans la table d'identités une fois validées par cet opérateur. Selon un mode de réalisation, l'équipement de communication EQ reçoit en 32 de la part du terminal UE-A, un message REG-ICC de demande d'enregistrement d'informations complémentaires ICC relatives à un contexte d'appel. Ces informations de contexte ICC sont liées au numéro de téléphone de l'appelé, ainsi qu’à celui de l’appelant. Les deux numéros de téléphone sont nécessaires pour trouver les informations spécifiques sur la raison de l’appel pour la personne appelée, car elles peuvent varier d’un appel à l’autre et d’une personne à l’autre. Par exemple, un vendeur peut appeler un premier client au sujet de la réparation d'un de ses appareils et un deuxième client pour confirmer un rendez-vous. Ces appels émis par le même appelant ont des motifs d’appel différents. Ces informations précisent le contexte d'un ou plusieurs appels à venir et comprennent par exemple :
-une information relative à un niveau d'urgence de l'appel, par exemple lorsqu'il provient d'un livreur ou d'un professionnel de santé;
-une information relative à un objet ou motif de l'appel, par exemple pour indiquer à l'appelé que son véhicule est prêt à être récupéré ou encore pour lui demander s'il est disponible pour parler au téléphone .
En 33, les informations ICC sont enregistrées en association du numéro de téléphone de l'utilisateur UT-A et viennent compléter l'entrée de la table IDB correspondant au numéro de téléphone de l'utilisateur UT-A. Bien sûr, cet enregistrement complémentaire peut lui aussi être conditionnée à une vérification préalable des droits de l'utilisateur UT-A, c'est-à-dire qu'il a bien souscrit au service d'identification de l'appelant.
Une telle demande d'enregistrement d'informations ICC peut être reçue et traitée à tout moment par l'équipement de communication EQ. Elle permet une adaptation dynamique du contenu de la table d'identités aux besoins de l'utilisateur du terminal appelant UE-A.
En 34, l'équipement EQ reçoit un message REQ de demande d'établissement d'un appel vers le terminal appelé UE-B.
Dans la suite, on considère à titre d'exemple que les messages de signalisation de l'appel échangés entre les terminaux appelant et appelés et le réseau de communication RC sont conformes au protocole de communication SIP.
On suppose donc que le message REQ de demande d'établissement d'appel est de type SIP INVITE.
Ce message SIP INVITE comprend des informations sur l'appelant UT-A et sur l'appelé UT-B et initie le processus d’échange d’informations entre les deux terminaux pour établir la communication voix (codées pris en charge, etc.). Le message SIP INVITE comprend généralement plusieurs en-têtes destinés à spécifier des informations techniques relatives au terminal appelant, aux codées à utiliser pour décoder les flux audio, des informations de routage etc. Il comprend au moins un en-tête relatif aux identités des parties (en anglais, « From et P-Asserted Identity (PAI)») qui servent à transporter les adresses logiques des parties, comme le numéro de téléphone ou MSISDN (pour « Mobile Station International Subscriber Directory Number », en anglais) ou l'adresse VoIP du terminal appelant UE-A et le numéro de téléphone de l'appelé ou son adresse VoIP. Ce dernier en-tête comprend aussi un champ d'information relatif au nom de l'appelant ( « DisplayName », en anglais)). Toutefois, on note que ce champ est peu utilisé lorsqu'il s'agit d'un appel voix, car le numéro de téléphone attribué dans l'en-tête « From et P-Asserted Identity (PAI)» de l’appelant est suffisant pour valider l’identité de l'appelant et lancer la présentation de l'appel à l'appelé.
Ce message SIP INVITE est acheminé dans le réseau de communication RC de l'opérateur par l'intermédiaire de plusieurs équipements de communication tels que des équipements routeurs, des équipements contrôleurs de session et des serveurs d’application de téléphonie ou TAS (pour « Telephony Application Server », en anglais). En particulier, un tel serveur d'application est configuré pour retransmettre les messages SIP INVITE qu'il voit passer et relaie, vers des équipements de communication ou des applications logicielles configurés pour rendre des services dédiés en lien avec le traitement d'une communication téléphoniques. Ces équipements de communication et applications logicielles se sont préalablement enregistrés auprès du serveur d'application TAS. Il s'agit par exemple de services de facturation ou de proxy. Un proxy est un serveur qui sert d’intermédiaire et dont le principal objectif est de cacher les détails du réseau aux connexions externes afin de préserver sa sécurité. Le proxy transmet les demandes aux zones sensibles du réseau sans partager aucun détail de ce réseau, comme l’adresse IP. Les applications logicielles en question peuvent être hébergées par le serveur d'application lui-même ou par un équipement de communication EQ distinct.
Dans la suite, on considère en particulier un équipement de communication EQ configuré pour mettre en oeuvre un service d'identification de l'appelant selon l'invention. Il met en oeuvre le procédé de traitement d'un message de demande d'établissement d'appel selon l'invention ou intègre un dispositif 100 de traitement selon l'invention qui vient d'être présenté en relation avec la figure 2.
En 34, il reçoit le message de demande d'établissement d'appel REQ émis par le terminal appelant UE-A.
En 35, il extrait le numéro de téléphone de l'appelant d'un en-tête dudit message REQ, par exemple l'en-tête « From et P-Asserted Identity (PAI)».
En 36, il interroge la table d'identités IDB, locale ou distante, gérée par l'opérateur, par exemple en utilisant le numéro de téléphone extrait comme index, en vue d'obtenir des informations complémentaires d'identité ICI de l'appelant. Cette table comprend des enregistrements, associant chacun à un numéro de téléphone d'un utilisateur abonné de l'opérateur du réseau de communication RC, une ou plusieurs informations complémentaires ICI sur son identité. Il obtient donc par exemple :
- une information d'identité de l'appelant, telle que son nom ou le nom de la société, lorsqu'il s'agit d'un professionnel ;
- une information relative à une image ou une vidéo associée à l'appelant, par exemple un logo de la société, une photographie de l'appelant ou encore une vidéo publicitaire présentant la société.
Par nature, ces informations complémentaires sont relativement permanentes. Avantageusement, elles ont été enregistrées dans la table IDB à la demande de l'appelant, dans une phase initiale et préalable, généralement suite à sa souscription au service d'identification de l'appelant proposé par l'opérateur.
Selon un mode de réalisation particulier de l'invention, la table IDB peut aussi comprendre des informations complémentaires ICC relatives à un contexte d'appel pour un ou plusieurs appels que l'appelant envisager de passer. L'équipement de communication EQ obtient donc par exemple :
- une information relative à un niveau d'urgence de l'appel, par exemple lorsqu'il provient d'un livreur ou d'un professionnel de santé ;
-une information relative à un objet ou motif de l'appel, par exemple pour indiquer que son véhicule est prêt à être récupéré ou pour lui demander s'il est disponible pour parler au téléphone .
Par nature, ces informations complémentaires relatives à l'appel ICC sont susceptibles de changer en fonction des intentions de l'appelant. Avantageusement, elles sont enregistrées dans la table IDB à la demande de l'appelant, juste avant de passer un ou plusieurs appels.
Si le numéro de téléphone de l'appelant n'est pas enregistré dans la table d'identités IDB, la réponse obtenue est vide et ne comprend aucune information complémentaire.
Selon un mode de réalisation particulier, le procédé comprend l'obtention d'informations de réputation de l'appelant UE-A auprès d'une deuxième table de données, dite table de réputation RDB, comprenant des entrées associant au numéro de téléphone d'un appelant des informations de réputation, telles que par exemple un type d'appelant. Un type d'appelant comprend un type commercial et désigne les démarcheurs commerciaux, un type frauduleux et un type légitime. Cette table de réputation RDB est mise à jour au fil de l'eau par l'opérateur, de façon connue en soi.
Les informations relatives à la réputation peuvent être obtenues de différentes manières par l'opérateur du réseau de communication. Selon un premier exemple, ce dernier exploite des rapports émis par des utilisateurs qui ont déjà reçu des appels de cet appelant pour signaler que l’appelant est une société de télémarketing, par exemple. Selon un deuxième exemple, l’opérateur peut analyser des enregistrements d’appels pour identifier les appelants de type démarcheurs commerciaux ou frauduleux sur la base de modèles d'appels prédéterminés. Par exemple, un appelant démarcheur commercial passe généralement de nombreux appels à de nombreuses personnes différentes sur un court laps de temps. Un appelant frauduleux cherche à inciter l'appelé à rappeler un numéro de téléphone surtaxé en passant de nombreux appels courts et en raccrochant avant que l'appelé ne puisse répondre (« ping calls », en anglais).
Lorsque le numéro de téléphone de l'appelant est enregistré dans la table d'identités IDB, la réponse obtenue comprend au moins une information complémentaire d'identification ICI, telle que le nom de l'utilisateur UT-A « UT-A-name » et optionnellement, une information complémentaire de contexte d'appel ICC.
A l'issue de cette étape 36, on suppose que l'équipement de communication EQ a obtenu des informations complémentaires IC, qui comprennent des informations complémentaires d'identification de l'appelant ICI et/ou des informations complémentaires de contexte d'appel ICC et/ou des informations de réputation IR sur l'utilisateur appelant UT-A.
Cette ou ces informations complémentaires IC contenues dans la réponse de la table d'identités sont ensuite insérées en 38 dans un champ d'information d'un en-tête du message REQ de demande d'établissement d'appel reçu, par exemple, selon le protocole SIP, le champ « DisplayName » de l'en tête « From et P-Asserted Identity ». Le message REQ ainsi modifié est ensuite désigné par REQ'. Enfin, la demande d'établissement d'appel REQ' ainsi complétée ou mise à jour est acheminée en 39 vers sa destination finale, à savoir le terminal appelé UE-B.
Optionnellement, certaines informations complémentaires sur l'identité de l'appelant sont préalablement codées en 38 avant d'être insérées dans le message de demande d'établissement d'appel REQ'. Il s'agit notamment des informations complémentaires autres que le nom de l'appelant.
Par exemple, elles sont codées à l'aide d'un code comprenant une séquence de caractères de type texte correspondant à l'information complémentaire IC à transmettre, encadrée par deux occurrences d'un caractère de type clé, ledit caractère de type clé étant associé à un type d'information particulier.
Par exemple, le caractère clé est une astérisque (*) associée au type d'appelant, tel que *TELE * pour un Optionnellement, l'invention prévoit aussi d'associer un caractère clé au nom de l'appelant, tel que « ' » ou « " ».
On présente maintenant, en relation avec la figure 4, sous une forme de logigramme, un exemple de mise en oeuvre d'un procédé de réception par un terminal appelé d'un message de demande d'établissement d'appel émis par un terminal appelant en voix sur IP dans un réseau de communication, selon un mode de réalisation de l'invention.
En 40, le terminal appelant UE-A, préalablement à l'émission d'un appel, émet dans le réseau de communication RC une demande REG-ICI d'enregistrement d'informations complémentaires d'identification ICI de l'utilisateur appelant UT-A dans la table d'identités IDB. Cette table est stockée dans ledit réseau de communication et gérée par lui.
Avantageusement, le procédé comprend une étape de réception en 41 d'un message de confirmation d'enregistrement ACK_REG-ICI desdites informations dans la table d'identités IDB, en provenance de l'équipement de communication EQ.
Selon un mode de réalisation de l'invention, le terminal UE-A émet en 42 une demande UP-REG de mise à jour de la table d'identités IDB, ladite demande de mise à jour comprenant au moins une information complémentaire ICC de contexte de l'appel, qui précise par exemple un objet de l'appel, un niveau d'urgence, une émotion de l'appelant etc.
Avantageusement, il reçoit en 43 un message de confirmation d'enregistrement ACK_UP-REG desdites informations dans la table d'identités IDB, en provenance de l'équipement de communication EQ.
Un avantage est de permettre la mise à jour dynamique de la table d'identités gérée par le réseau de communication par l'appelant avant l'émission d'un ou plusieurs prochains messages à destination d'un ou plusieurs terminaux appelés à l'aide d'informations spécifiques au contexte de ces appels.
On présente maintenant, en relation avec la figure 5, sous une forme de logigramme, un exemple de mise en oeuvre d'un procédé de réception par un terminal appelé d'un message de demande d'établissement d'appel émis par un terminal appelant en voix sur IP dans un réseau de communication, selon un mode de réalisation de l'invention.
Selon ce mode de réalisation, le terminal appelé UE-B intègre le dispositif 200. Par exemple, le procédé de réception selon l'invention est implémenté par le dispositif 200 sous la forme d'une application logicielle API_IDS_UEB.
En 50, le terminal appelé UE-B reçoit un message de demande d'établissement d'appel, par exemple de type SIP INVITE, en provenance du terminal appelant UE-A. On suppose qu'il s'agit du message REQ' enrichi par l'équipement de communication EQ conformément au procédé de traitement qui vient d'être décrit en relation avec la figure 4.
Sur réception dudit message, il extrait en 51 une ou plusieurs informations complémentaires IC sur l'identité de l'appelant d'un champ d'information du message reçu, par exemple du champ « DisplayName » de l'en-tête « From et P-Asserted Identity ».
Avantageusement, ces informations IC peuvent comprendre :
- une ou plusieurs informations complémentaires ICI d'identification de l'appelant, et/ou
- une ou plusieurs informations complémentaires ICC de d'un appel vers un terminal appelant, et/ou
- une ou plusieurs information IR de réputation de l'appelant. Selon un mode de réalisation de l'invention, au moins certaines informations extraites du message de demande d'établissement d'appel sont codées à l'aide d'un code comprenant une séquence d'informations textuelles encadrée par deux occurrences d'un caractère de type clé. Dans ce cas, le procédé comprend en 52 le décodage des informations extraites. Un tel décodage comprend l'identification dudit caractère de type clé et l'obtention d'au moins un type d'informations associés au caractère clé identifié.
Par exemple, pour une information complémentaire d'identification de l'appelant ICI, de type lien vers un fichier image ou vidéo à télécharger, le caractère clé utilisé est « % ».
Par exemple, pour une information complémentaire de contexte d'appel ICC, le caractère clé « ! » peut être utilisé pour encadrer le nom de l'appelant et indiquer un appel urgent. Selon encore un autre exemple, le caractère clé « ? » peut être utilisé pour encadrer le nom de l'appelant et vise à demander à l'appelé s'il est disponible pour parler, ou encore pour indiquer un objet de l'appel, comme par exemple (« Tentative d'accès à votre compte » ou « votre véhicule est prêt à être récupéré »).
Par exemple pour une information de réputation IR, le caractère clé « *» est utilisé pour encadrer une séquence de caractères textuels qualifiant un type d'appelant (SPAM pour frauduleux, TELE pour un démarcheur commercial ou encore OK pour un appelant légitime).
En 53, au moins une action de notification des informations extraites est déterminée en fonction du caractère clé identifié. Selon un mode de réalisation de l'invention, la détermination comprend la consultation d'une table d'actions TA stockée en mémoire, ladite table comprenant des entrées associant à un caractère clé une ou plusieurs actions de notifications. Par exemple, le caractère clé « ! » utilisé pour désigner un caractère d'urgence de l'appel est associé à l'émission d'une sonnerie spécifique, présentant un motif pressant ou à l'affichage de la séquence de texte en rouge clignotant ou encore à l'affichage d'un bandeau « URGENT » à côté de la séquence de texte.
Selon un autre exemple, le caractère clé « % » utilisé pour encadrer un lien vers une image ou une vidéo associée est associé à l'action d'aller chercher le fichier sur le lien indiqué et de l'afficher sur l'écran du terminal appelé.
Selon encore un autre exemple, le caractère clé « * » utilisé pour indiquer un type d'appelant ou d'appel est associé à l'affichage d'une fenêtre, par exemple de type « pop-up » comprenant le type de l'appelant reçu dans la séquence textuelle.
Avantageusement, l'action déclenchée est en outre adaptée à la valeur de la séquence textuelle extraite. Pour illustrer cette adaptation, des exemples de notifications sont présentées sur les figures 6A à 6C. En relation avec la figure 6A, une fenêtre PI est affichée sur l'écran du terminal appelé UE-B pour notifier l'utilisateur d'un appel frauduleux, suite à la réception de l'information complémentaire *SPAM *. Elle comprend par exemple un signe ou icône d'alerte ou de danger. En relation avec la figure 6B, une fenêtre P2 est affichée sur l'écran du terminal appelé UE-B pour notifier l'utilisateur d'un appel urgent en provenance d'un organisme bancaire, suite à la réception de l'information complémentaire ! ORANGE BANK I. Elle comprend par exemple un bandeau de couleur rouge indiquant le caractère urgent de l'appel. En relation avec la figure 6C, une fenêtre P3 est affichée sur l'écran du terminal appelé UE-B pour notifier l'utilisateur d'un appel urgent relatif à une livraison, suite à la réception des informations complémentaires Inom de la société + livreur ! et %lien_logo_société%.
En 54, la ou les actions de notifications des informations complémentaires sur l'identité de l'appelant sont déclenchées lors de la présentation de l'appel à l'appelant sur son terminal UE-B.
On présente désormais, en relation avec la figure 7, sous une forme de diagramme de flux, les échanges de messages de signalisation entre le terminal appelant UE-A, l'équipement de communication EQ et le terminal appelé UE-B, selon un mode de réalisation de l'invention.
On suppose que l'utilisateur UT-A du terminal UE-A a préalablement souscrit au service d'identification de l'appelant proposé par l'opérateur du réseau de communication RC. Dans une phase d'initialisation, en 40, il émet une demande d'enregistrement REG-ICI d'informations complémentaires d'identification de l'utilisateur UT-A. A réception, l'équipement de communication EQ enregistre en 31 les informations reçues dans la table d'identités IDB et envoie un message d'accusé-réception ACK_REG-ICI au terminal UE-A. Il est reçu par le terminal UE-A en 41. Optionnellement, en 42, le terminal UE-A envoie une demande de mise à jour UP-REG des informations complémentaires ICI. Elle comprend par exemple des informations de contexte ICC d'un appel vers un terminal appelé, qui précisent par exemple un niveau d'urgence de l'appel ou un objet de cet appel ou encore une émotion de l'appelant UT-A associée à cet appel. Ces informations sont donc à la fois associées au numéro de téléphone de l'appelant UE-A et à un numéro de téléphone d'un terminal UE-B que l'utilisateur UT-A du terminal appelant UE-A souhaite appeler.
Elles sont reçues en 32 par l'équipement de communication EQ, qui les enregistre en 33 et répond par un message d'accusé-réception ACK_UP-REG. Il est reçu en 43 par le terminal UE-A.
Dans la suite, on considère un échange de messages de signalisation conformes au protocole SIP, par exemple décrit dans le document RFC 3261 de Rosenberg et al, publié par « The Internet Society » en juin 2002. Ces messages étant connus de l'homme de métier, les détails de leur format ne sont pas décrits ci-après.
En 44, Le terminal UE-A émet un message REQ de demande d'établissement d'appel, par exemple de type SIP INVITE, vers le terminal appelé UE-B.
L'équipement de communication EQ est configuré pour intercepter les messages de signalisation d'appel échangés entre le terminal appelant UE-A et le terminal appelé UE-B. Plus précisément, il ignore tous les messages et les relaie sans modification à la partie destinataire, à l'exception du message REQ. A réception du message REQ en 34, l'équipement de communication EQ met en oeuvre le procédé de traitement selon l'invention qui vient d'être décrit en relation avec la figure 3. Il extrait en 35 le numéro de téléphone de l'appelant, interroge 36 au moins la table d'identité IDB, partir de ce numéro de téléphone pour obtenir des informations complémentaires IC à ajouter à la demande d'établissement d'appel. Auprès de la table d'identités IDB, il obtient des informations complémentaires d'identification ICI de l'appelant et/ou des informations de contexte de l'appel ICC. Par exemple, il obtient la réponse suivante à sa requête d'interrogation de la table d'identités IDB : Name: Orange
Logo: orange.com/assets/logo.png Purpose: Attempted Access To Your Account Urgency: High AppName: None Qualification: Validated ReguestToTalk: <yes>
Les informations complémentaires ICI comprennent le nom de l'appelant est la société Orange et un lien vers son logo.
Les informations de contexte d'appel vers l'appelé UE-B comprennent un niveau d'urgence élevé, un objet (« Tentative d'accès à votre compte ») et un souhait de l'appelant (« Etes-vous disponibles pour parler ? »).
Le champ d'informations « AppName » peut spécifier le nom d'une application qui sera lancée lorsque l’utilisateur répondra à l’appel. Le champ qualification indique que le nom et le numéro de téléphone de l’appelant ont été validés par l'opérateur qui gère la table d’identité d'un appelant. Optionnellement, il consulte aussi une table de réputation RDB, auprès de laquelle il obtient des informations de réputation IR de l'appelant. Par exemple, il le fait lorsqu'il n'a pas trouvé d'enregistrement dans la table d'identités IDB correspondant au numéro de téléphone de l'appelant. En 37, l'équipement de communication EQ décode les informations obtenues, met à jour 38 le message de demande d'établissement d'appel avec les informations décodées et retransmet en 39 le message mis à jour REQ' au terminal appelé UE-B.
Il en résulte que le message REQ' est enrichi à l'aide d'informations complémentaires relatives à l'identité de l'utilisateur appelant UT-A et/ou à un contexte de l'appel, lesquelles sont par exemple transmises dans le champ « DisplayName » de l'en-tête « From et P-Asserted Identity » dudit message. De la sorte, l'équipement de communication EQ, en mettant en oeuvre l'invention, rend un service intermédiaire, dit service d'identité de l'appelant, qui est par exemple implémenté sous la forme d'une application logicielle dédiée.
A réception de ce message REQ' en 50 par le terminal appelé UE-B, ce dernier répond en renvoyant dans le réseau de communication RC un message de signalisation, par exemple de type 100 « TRYING », pour indiquer qu'il a bien reçu le message de demande d'établissement d'appel et qu'il n'est pas nécessaire d'en envoyer d'autres.
Ensuite, le terminal appelé UE-B met en oeuvre le procédé de réception selon l'invention qui vient d'être présenté en relation avec la figure 5. Par exemple, les informations complémentaires IC insérées par l'équipement de communication EQ sont extraites en 51, décodées en 52 et traduites en 53 en actions de notification à déclencher lors de la présentation de l'appel à l'utilisateur UT-B en 54. Le terminal appelé UE-B présente alors l'appel à l'utilisateur UT-B en déclenchant la ou les actions de notification A des informations complémentaires relatives à l'identité de l'appelant.
Par exemple, le procédé de réception selon l'invention est implémenté sous la forme d'une application logicielle dédiée, qui a été préalablement chargée dans le terminal appelé UE-B.
Une fois l'appel présenté à l'utilisateur, le terminal appelé UE-B envoie au terminal appelant UE-un message de type SIP 180 « RING » pour l'informer que l'utilisateur UT-B a été alerté.
De façon connue en soi, ces messages de signalisation peuvent également contenir des informations supplémentaires, ajoutées par le terminal appelé UE-B, par exemple relatives aux codées disponibles sur le téléphone appelé, ou à sa capacité de jouer des flux médias dits précoces, tels qu'un message gratuit joué pendant l'intervalle qui précède la transmission d'un appel à la messagerie vocale.
Le terminal appelant UE-A reçoit le message SIP 180 « RINGING ».
Si l'utilisateur appelé UT-B accepte l’appel, le terminal appelé UE-B envoie un message de signalisation 200 OK dans le réseau de communication RC. Il est retransmis au terminal appelant UE- A, qui y répond par un message d'accusé-réception, par exemple de type 200 « OK ». Le message d'accusé-réception est retransmis au terminal appelé UE-B. A ce stade, la communication entre les parties est établie et le trafic de données, par exemple conforme au protocole de communication RTP (pour « Real Time Protocol », en anglais), qui contient les flux médias audio ou vidéo de la communication entre les deux terminaux, commence à être transmis.
Par exemple, les informations codées insérées dans le champ d'informations « DisplayName » sont les suivantes :
DisplayName = !?Orange?! %orange.com/assets/logo.png% Attempted Access To Your Account L'appelant est la société Orange. Il s'agit d'un appel urgent, car le nom Orange est entouré du caractère clé « ! ». Un lien vers le logo d'Orange est fourni. L'objet de l'appel est d'alerter l'appelé au sujet d'une tentative d'accès à son compte, comme l'indique le caractère cle « ? ».
On présente maintenant, en relation avec la figure 8, un exemple de structure matérielle d'un dispositif 100 de traitement d'un message de demande d'établissement d'appel dans un réseau de communication local selon l'invention, comprenant au moins un module de réception dudit message, un module d'extraction d'un numéro de téléphone de l'appelant dudit message, un module de mise à jour d'un champ d'information dudit message par insertion d'informations complémentaires d'identification de l'appelant obtenues d'une première table de données, dite table d'identité de l'appelant, et un module d'acheminement du message mis à jour vers le terminal appelé. Avantageusement, le dispositif 100 comprend en outre un module de vérification des droits de l'utilisateur du terminal appelant, un module et le module de mise à jour est configuré pour insérer dans le message de demande d'établissement d'appel des informations de réputation de l'appelant obtenues d'une deuxième table de données, dite table de réputation.
Avantageusement il comprend aussi un module de réception d'une demande d'ajout d'informations associées à un numéro de téléphone d'un appelant en provenance d'un terminal appelant, ladite demande comprenant ledit numéro de téléphone et des informations relatives à un contenu d'un prochain appel et un module d'ajout desdites informations relatives à un contenu d'un prochain appel aux informations complémentaires d'identification associées audit numéro de téléphone.
Le terme « module » peut correspondre aussi bien à un composant logiciel qu'à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous-programmes d'ordinateur ou de manière plus générale à tout élément d'un programme apte à mettre en oeuvre une fonction ou un ensemble de fonctions.
Plus généralement, un tel dispositif 100 comprend une mémoire vive 103 (par exemple une mémoire RAM), une unité de traitement 102 équipée par exemple d’un processeur, et pilotée par un programme d’ordinateur Pg, représentatif des modules de réception, extraction, interrogation, mise à jour et acheminement, stocké dans une mémoire morte 101 (par exemple une mémoire ROM ou un disque dur). A l’initialisation, les instructions de code du programme d’ordinateur sont par exemple chargées dans la mémoire vive 103 avant d’être exécutées par le processeur de l’unité de traitement 102. La mémoire vive 103 peut aussi contenir une table de données comprenant une entrée associant au numéro de téléphone de l'appelant des droits d'accès au service d'identification de l'appelant. Elle peut aussi contenir une copie des informations IC extraites de la table d'identités et/ou de la table de réputation RDB à partir du numéro de téléphone de l'appelant. La figure 8 illustre seulement une manière particulière, parmi plusieurs possibles, de réaliser le dispositif 100 afin qu'il effectue les étapes du procédé de traitement d'un message de demande d'établissement d'un appel en voix sur IP dans un réseau de communication tel que détaillé ci- dessus, en relation avec les figures 3 et 7 dans ses différents modes de réalisation. En effet, ces étapes peuvent être réalisées indifféremment sur une machine de calcul reprogrammable (un ordinateur PC, un processeur DSP ou un microcontrôleur) exécutant un programme comprenant une séquence d'instructions, ou sur une machine de calcul dédiée (par exemple un ensemble de portes logiques comme un FPGA ou un ASIC, ou tout autre module matériel).
Dans le cas où le dispositif 100 est réalisé avec une machine de calcul reprogrammable, le programme correspondant (c'est-à-dire la séquence d'instructions) pourra être stocké dans un médium de stockage amovible (tel que par exemple une carte SD, une clé USB, un CD-ROM ou un DVD-ROM) ou non, ce médium de stockage étant lisible partiellement ou totalement par un ordinateur ou un processeur.
Les différents modes de réalisation ont été décrits ci-avant en relation avec un dispositif 100 intégré dans un équipement de communication EQ, mais il peut aussi être indépendant de cet équipement et connecté à lui par une interface de type filaire ou sans fil.
On présente aussi, en relation avec la figure 9, un exemple de structure matérielle d'un dispositif 200 d'émission d'un message de demande d'établissement d'appel émis par un terminal appelant vers un terminal appelé dans un réseau de communication selon l'invention, comprenant au moins un module d'émission d'une demande d'enregistrement d'informations complémentaires d'identification de l'appelant dans la table d'identités IDB, stockée dans ledit réseau de communication, en association avec un numéro de téléphone de l'appelant, un module de réception d'une confirmation d'enregistrement et un module d'émission du message de demande d'établissement d'appel.
Avantageusement, le dispositif 200 comprend aussi un module d'émission à destination du réseau de communication d'une demande de mise à jour de la table d'identités de l'appelant, ladite demande de mise à jour comprenant au moins une information de contexte de l'appel.
Le terme « module » peut correspondre aussi bien à un composant logiciel qu'à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous-programmes d'ordinateur ou de manière plus générale à tout élément d'un programme apte à mettre en oeuvre une fonction ou un ensemble de fonctions.
Plus généralement, un tel dispositif 200 comprend une mémoire vive 203 (par exemple une mémoire RAM), une unité de traitement 202 équipée par exemple d’un processeur, et pilotée par un programme d’ordinateur Pg2, représentatif des modules de réception, d'activation, de connexion, de vérification, de sélection, d'obtention, de réveil et d'exécution, stocké dans une mémoire morte 201 (par exemple une mémoire ROM ou un disque dur). A l’initialisation, les instructions de code du programme d’ordinateur sont par exemple chargées dans la mémoire vive 203 avant d’être exécutées par le processeur de l’unité de traitement 202. La mémoire vive 203 peut aussi contenir les informations complémentaires que l'utilisateur du terminal appelant demande à enregistrer dans la table d'identités du réseau de communication.
La figure 9 illustre seulement une manière particulière, parmi plusieurs possibles, de réaliser le dispositif 200 afin qu'il effectue les étapes du procédé d'émission d'un message de demande d'établissement d'appel tel que détaillé ci-dessus, en relation avec les figures 4 et 7 dans ses différents modes de réalisation. En effet, ces étapes peuvent être réalisées indifféremment sur une machine de calcul reprogrammable (un ordinateur PC, un processeur DSP ou un microcontrôleur) exécutant un programme comprenant une séquence d'instructions, ou sur une machine de calcul dédiée (par exemple un ensemble de portes logiques comme un FPGA ou un ASIC, ou tout autre module matériel).
Dans le cas où le dispositif 200 est réalisé avec une machine de calcul reprogrammable, le programme correspondant (c'est-à-dire la séquence d'instructions) pourra être stocké dans un médium de stockage amovible (tel que par exemple une carte SD, une clé USB, un CD-ROM ou un DVD-ROM) ou non, ce médium de stockage étant lisible partiellement ou totalement par un ordinateur ou un processeur.
On présente enfin, en relation avec la figure 10, un exemple de structure matérielle d'un dispositif 300 de réception par un terminal appelé d'un message de demande d'établissement d'appel émis par un terminal appel dans un réseau de communication selon l'invention, comprenant au moins un module de réception dudit message, un module d'extraction d'informations complémentaires relatives à l'appelant d'un champ d'information du message reçu et un module de déclenchement d'au moins une action comprenant une notification desdites informations à un utilisateur du terminal appelé.
Avantageusement, le dispositif 300 comprend aussi un module de décodage desdites informations, ledit décodage comprenant l'identification dudit caractère de type clé et un module de détermination d'une action de notification à déclencher au moins en fonction du caractère de type clé identifié.
Le terme « module » peut correspondre aussi bien à un composant logiciel qu'à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous-programmes d'ordinateur ou de manière plus générale à tout élément d'un programme apte à mettre en oeuvre une fonction ou un ensemble de fonctions. Plus généralement, un tel dispositif 300 comprend une mémoire vive 303 (par exemple une mémoire RAM), une unité de traitement 302 équipée par exemple d'un processeur, et pilotée par un programme d'ordinateur Pg, représentatif des modules de réception, extraction, décodage, détermination et déclenchement, stocké dans une mémoire morte 301 (par exemple une mémoire ROM ou un disque dur). A l'initialisation, les instructions de code du programme d'ordinateur sont par exemple chargées dans la mémoire vive 303 avant d'être exécutées par le processeur de l'unité de traitement 302. La mémoire vive 303 peut aussi contenir une table comprenant une entrée associant un caractère clé une ou plusieurs actions à déclencher lors de la présentation de l'appel.
La figure 10 illustre seulement une manière particulière, parmi plusieurs possibles, de réaliser le dispositif 300 afin qu'il effectue les étapes du procédé de réception d'un message de demande d'établissement d'appel tel que détaillé ci-dessus, en relation avec les figures 5, 6 et 7 dans ses différents modes de réalisation. En effet, ces étapes peuvent être réalisées indifféremment sur une machine de calcul reprogrammable (un ordinateur PC, un processeur DSP ou un microcontrôleur) exécutant un programme comprenant une séquence d'instructions, ou sur une machine de calcul dédiée (par exemple un ensemble de portes logiques comme un FPGA ou un ASIC, ou tout autre module matériel).
Dans le cas où le dispositif 300 est réalisé avec une machine de calcul reprogrammable, le programme correspondant (c'est-à-dire la séquence d'instructions) pourra être stocké dans un médium de stockage amovible (tel que par exemple une carte SD, une clé USB, un CD-ROM ou un DVD-ROM) ou non, ce médium de stockage étant lisible partiellement ou totalement par un ordinateur ou un processeur.
L'invention qui vient d'être décrite dans ses différents modes de réalisation présente de nombreux avantages. En effet, en enrichissant l'appel présenté au terminal appelé à l'aide d'informations d'identification de l'appelant, qui sont gérées et validées, donc dignes de confiance, par le réseau de communication, elle contribue à augmenter le taux d'acceptation des appels par les terminaux appelés. En outre, du fait que l'enrichissement de l'appel est réalisé dans le réseau de communication, il n'introduit pas de latence au niveau du terminal appelé avant la présentation de l'appel à l'utilisateur. Selon l'invention, cet enrichissement s'appuie sur des informations stockées dans une unique table gérée par l'opérateur du réseau et de ce fait, elles sont transmises selon un unique format de données, ce qui simplifie leur interprétation et leur utilisation par les terminaux appelés. Enfin, l'invention n'implique aucune modification de syntaxe des messages de signalisation d'appel, puisque les informations complémentaires sont avantageusement transmises dans un champ d'informations du message d'établissement d'appel qui est déjà prévu par la norme, mais n'était pas encore exploité en pratique.

Claims

REVENDICATIONS
1. Procédé de traitement d'un message (REQ) de demande d'établissement d'appel émis par un terminal appelant (UE-A) vers un terminal appelé (UE-B) dans un réseau de communication (RC), ledit réseau comprenant un équipement de communication (EQ) configuré pour recevoir (34) ledit message, caractérisé en ce que ledit procédé est mis en oeuvre au niveau dudit équipement de communication et comprend:
- la mise à jour (38) d'un champ d'information dudit message (REQ, REQ') par insertion d' informations complémentaires d'identification de l'appelant obtenues d'au moins une première table de données (IDB); et
- la transmission (39) du message mis à jour (REQ') vers le terminal appelé (UE-B).
2. Procédé de traitement selon la revendication 1, caractérisé en ce que, lorsqu'aucune information complémentaire n'est obtenue de la première table, la mise à jour (38) comprend l'insertion d'informations de réputation obtenues d'une deuxième table de données (RDB), dans le message de demande d'établissement d'appel.
3. Procédé de traitement selon l'une des revendications précédentes, caractérisé en ce qu'il comprend en outre :
- la réception (30, 32) d'une demande d'ajout d'informations complémentaires associées au numéro de téléphone de l'appelant en provenance du terminal appelant, ladite demande comprenant ledit numéro de téléphone et lesdites informations ; et
- le stockage (31, 33) desdites informations dans la première table en association avec ledit numéro de téléphone.
4. Procédé de traitement selon l'une des revendications précédentes, caractérisé en ce qu'il comprend le codage d'au moins une desdites informations obtenues sous forme d'un code comprenant une séquence de caractères de type texte encadrée par deux occurrences d'un caractère de type clé, ledit caractère de type clé étant associé à une information de contexte d'appel prédéterminée.
5. Procédé d'émission d'un message de demande d'établissement d'appel par un terminal appelant vers un terminal appelé dans un réseau de communication (RC), caractérisé en ce qu'il est mis en oeuvre au niveau du terminal appelant et comprend, préalablement à l'émission (44) dudit message :
- l'émission (40) d'une demande d'enregistrement d'informations complémentaires d'identification de l'appelant dans une première table de données (IDB) stockée dans ledit réseau de communication, en association avec un numéro de téléphone de l'appelant, lesdites informations complémentaires d'identification de l'appelant étant destinées à être utilisées par un équipement de communication configuré pour recevoir ledit message de demande d'établissement d'appel, l'enrichir au moins à l'aide des informations contenues dans ladite première table et le retransmettre au terminal appelé.
6. Procédé d'émission selon la revendication précédente, caractérisé en ce qu'il comprend en outre l'émission (42) à destination du réseau de communication d'une demande de mise à jour de la première table, ladite demande de mise à jour comprenant au moins une information de contexte (ICC) de l'appel.
7. Procédé de réception d'un message de demande d'établissement d'appel par un terminal appelé (UE-B) émis par un terminal appelant (UE-A) dans un réseau de communications (RC), caractérisé en ce qu'il est mis en oeuvre au niveau du terminal appelé et comprend, sur réception (50) dudit message :
- l'extraction (51) d'informations complémentaires (IC) relatives à un utilisateur (UT-A) du terminal appelant (UE-A) d'un champ d'information du message reçu ; et
- le déclenchement (54) d'au moins une action comprenant une notification desdites informations à un utilisateur du terminal appelé lors d'une présentation de l'appel.
8. Procédé de réception selon la revendication précédente, caractérisé en ce que au moins une desdites informations complémentaires relatives à l'appel est codée sous la forme d'une séquence de caractères de type texte encadrée par deux occurrences d'un caractère de type clé, en ce que le procédé comprend le décodage (52) de ladite information, ledit décodage comprenant l'identification dudit caractère de type clé et en ce que le procédé comprend la détermination (53) d'au moins une action de notification déclenchée au moins en fonction du caractère de type clé identifié.
9. Dispositif (100) de traitement d'un message (REQ) de demande d'établissement d'appel émis par un terminal appelant (UE-A) vers un terminal appelé (UE-B) dans un réseau de communication (RC), ledit réseau comprenant un équipement de communication (EQ) configuré pour recevoir (34) ledit message, caractérisé en ce que ledit dispositif est configuré pour mettre en oeuvre au niveau dudit équipement de communication:
- la mise à jour d'un champ d'information dudit message (REQ, REQ') par insertion d' informations complémentaires d'identification de l'appelant obtenues d'au moins une première table (IDB); et
- la transmission du message mis à jour (REQ') vers le terminal appelé (UE-B).
10. Dispositif (200) d'émission d'un message de demande d'établissement d'appel par un terminal appelant vers un terminal appelé dans un réseau de communication (RC), caractérisé en ce qu'il est configuré pour mettre en oeuvre au niveau du terminal appelant, préalablement à l'émission - dudit message :
- l'émission d'une demande d'enregistrement d'informations complémentaires d'identification de l'appelant dans une première table de données (IDB, stockée dans ledit réseau de communication, en association avec un numéro de téléphone de l'appelant, lesdites informations complémentaires d'identification de l'appelant étant destinées à être utilisées par un équipement de communication configuré pour recevoir ledit message de demande d'établissement d'appel, l'enrichir au moins à l'aide des informations contenues dans ladite première table et le retransmettre au terminal appelé.
11. Dispositif (300) de réception d'un message de demande d'établissement d'appel par un terminal appelé (UE-B) émis par un terminal appelant (UE-A) dans un réseau de communications (RC), caractérisé en ce qu'il est configuré pour mettre en oeuvre au niveau du terminal appelé et comprend, sur réception dudit message :
- l'extraction d'informations complémentaires (IC) relatives à un utilisateur (UT-A) du terminal appelant (UE-A) d'un champ d'information du message reçu ; et
- le déclenchement d'au moins une action comprenant une notification desdites informations à un utilisateur du terminal appelé lors d'une présentation de l'appel.
12. Table de données (IDB) d'un réseau de communication, caractérisée en ce qu'elle comprend des enregistrements associant au moins des informations complémentaires d'identification d'un appelant à un numéro de téléphone de cet appelant.
13. Système (10) de gestion d'un message de demande d'établissement d'appel émis en voix sur IP par un terminal appelant (UE-A) vers un terminal appelé (UE-B) dans un réseau de communication (RC), caractérisé en ce qu'il comprend un dispositif de traitement selon la revendication 9, un dispositif d'émission selon la revendication 10, un dispositif de réception selon la revendication 11 et une table de données selon la revendication 12.
14. Programme d'ordinateur comprenant des instructions de code de programme pour la mise en oeuvre d'un procédé selon l’une quelconque des revendications 1 à 8, lorsqu'il est exécuté par un processeur.
EP22732603.0A 2021-05-31 2022-05-30 Procede de traitement d'un appel telephonique dans un reseau de communication, procede d'emission, procede de reception d'un tel appel, dispositifs, systeme et programmes d'ordinateur correspondants Pending EP4348982A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2105725A FR3123529A1 (fr) 2021-05-31 2021-05-31 Procédé de traitement d’un appel téléphonique dans un réseau de communication, procédé d’émission, procédé de réception d’un tel appel, dispositifs, système et programmes d’ordinateur correspondants.
PCT/FR2022/051007 WO2022254133A1 (fr) 2021-05-31 2022-05-30 Procede de traitement d'un appel telephonique dans un reseau de communication, procede d'emission, procede de reception d'un tel appel, dispositifs, systeme et programmes d'ordinateur correspondants

Publications (1)

Publication Number Publication Date
EP4348982A1 true EP4348982A1 (fr) 2024-04-10

Family

ID=77411807

Family Applications (1)

Application Number Title Priority Date Filing Date
EP22732603.0A Pending EP4348982A1 (fr) 2021-05-31 2022-05-30 Procede de traitement d'un appel telephonique dans un reseau de communication, procede d'emission, procede de reception d'un tel appel, dispositifs, systeme et programmes d'ordinateur correspondants

Country Status (4)

Country Link
US (1) US20240251034A1 (fr)
EP (1) EP4348982A1 (fr)
FR (1) FR3123529A1 (fr)
WO (1) WO2022254133A1 (fr)

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6826271B1 (en) * 2000-05-10 2004-11-30 Lucent Technologies Inc. Enhanced caller identification
US7280646B2 (en) * 2003-04-18 2007-10-09 At&T Bls Intellectual Property, Inc. Dynamic Caller ID messaging
US7516184B2 (en) * 2005-11-22 2009-04-07 Cisco Technology, Inc. Method and system for a method for evaluating a message based in part on a registrar reputation
US8788704B1 (en) * 2007-04-18 2014-07-22 Cisco Technology, Inc. Sending incoming calling ID to devices after initiation of a call
US8290131B2 (en) * 2007-05-03 2012-10-16 At&T Intellectual Property Ii Customized caller ID based upon called party number
US8681958B2 (en) * 2007-09-28 2014-03-25 Centurylink Intellectual Property Llc Method for presenting additional information about a telecommunication user
US8750477B2 (en) * 2009-07-22 2014-06-10 Felix Calls, Llc Method and system for automatic assignment of outbound and inbound call identity
WO2011020494A1 (fr) * 2009-08-17 2011-02-24 Telefonaktiebolaget L M Ericsson (Publ) Procédé et appareil dans un réseau de télécommunication
US8462925B2 (en) * 2010-08-26 2013-06-11 Cloudtree, Llc User-defined identity mapping for directed communications
US9092616B2 (en) * 2012-05-01 2015-07-28 Taasera, Inc. Systems and methods for threat identification and remediation
US10165117B2 (en) * 2016-03-28 2018-12-25 Verizon Patent And Licensing Inc. Call handling based on augmented caller information
US9774731B1 (en) * 2016-03-28 2017-09-26 Verizon Patent And Licensing Inc. Adding additional information to caller ID information
FR3052618A1 (fr) * 2016-06-08 2017-12-15 Orange Procede d'enrichissement d'une signalisation d'une communication et dispositif
US10972602B1 (en) * 2019-10-18 2021-04-06 At&T Intellectual Property I, L.P. Call indicators for categories of calls

Also Published As

Publication number Publication date
US20240251034A1 (en) 2024-07-25
FR3123529A1 (fr) 2022-12-02
WO2022254133A1 (fr) 2022-12-08

Similar Documents

Publication Publication Date Title
KR100806409B1 (ko) 주문형 호출경보시스템 및 방법
WO2014190789A1 (fr) Procédé, dispositif, client et serveur destinés à une interaction
EP1406430A1 (fr) Procédé de messagerie vocale instantanée et dispositif de mise en oeuvre d&#39;un tel procédé
PT1847106E (pt) Notificação de chamadas controlada pelo sistema emissor de chamadas
EP2795870A1 (fr) Procede d&#39;acces par un terminal de telecommunication a une base de donnees hebergee par une plateforme de services accessible via un reseau de telecommunications
KR100810253B1 (ko) 통신 시스템에서 서비스 메뉴 제공 방법 및 시스템
JP2010016857A (ja) 発信側システムにより制御される呼通知システムとその呼通知方法
EP2783496A1 (fr) Procede de gestion de la mise en relation numerique
EP1941705B1 (fr) Procede et systeme de protection d&#39;un lien d&#39;acces a un serveur
EP3104585B1 (fr) Dispositif et procédé de traitement d&#39;une communication
EP4348982A1 (fr) Procede de traitement d&#39;un appel telephonique dans un reseau de communication, procede d&#39;emission, procede de reception d&#39;un tel appel, dispositifs, systeme et programmes d&#39;ordinateur correspondants
EP3127297B1 (fr) Procede de detection d&#39;une usurpation d&#39;identite appartenant a un domaine
WO2005053264A1 (fr) Systeme et procede de mise en relation entre au moins deux terminaux multimedia relies entre eux par un reseau fixe ou cellulaire
EP3800874A1 (fr) Procédé et dispositif de redirection d&#39;une requête de communication
EP3754956A1 (fr) Méthode et dispositif pour déterminer l&#39;usurpation de l&#39;identifiant de l&#39;appelant
FR3037465A1 (fr) Dispositif et procede de traitement d&#39;une communication
FR3037755A1 (fr) Etablissement d&#39;une communication par allocation a un terminal appelant d&#39;un identifiant d&#39;appel intermediaire dedie a la communication
FR3088159A1 (fr) Gestion d&#39;une communication entre un terminal de communication appelant, disposant d&#39;un identifiant d&#39;appel principal et d&#39;un identifiant d&#39;appel secondaire, et un terminal de communication appele.
EP2100430B1 (fr) Procédé et système de télécommunication permettant à au moins deux utilisateurs distincts d&#39;accéder à un meme ensemble d&#39;informations
FR3121808A1 (fr) Procédés et dispositifs d’enrichissement et de traitement d’un message de signalisation
WO2015128561A1 (fr) Procede et dispositif de decouverte des capacites de communication relatives a un utilisateur d&#39;un terminal
EP2506524B1 (fr) Procédés et dispositifs de notification d&#39;état de services de communication
EP3035723A1 (fr) Procédé de transmission de données en relation avec une communication
EP2992657A1 (fr) Procede et dispositif pour controler l&#39;utilisation d&#39;un flux de donnees d&#39;une communication
FR3013545A1 (fr) Procede de mise a jour d&#39;un historique de communications partage

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

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