Methods for processing pseudonymized calls and managing pseudonymized numbers, and devices implementing these methods
By leveraging session initialization protocols to generate failure messages directly from pseudonymized number management devices, the method addresses network strain and improves reliability in handling failed calls to pseudonymized numbers, providing transparent failure explanations.
Patent Information
- Application Number
- FR2024006173
- Authority / Receiving Office
- FR · FR
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2024-06-11
- Publication Date
- 2025-12-12
- Estimated Expiration
- 2044-06-11
AI Technical Summary
Existing methods for handling failed calls to pseudonymized numbers incur network bandwidth strain and reliability issues due to the use of media servers and tromboning, especially when intermediation platforms are in different countries.
Utilize session initialization protocols like SIP or ISUP to divert error messages for call failures, allowing the pseudonymized number management device to generate media streams explaining the failure reason directly to the caller, bypassing the need for additional media servers and reducing network congestion.
Ensures efficient handling of failed calls with reduced network infrastructure impact, improved reliability, and transparent communication of failure reasons to callers.
Smart Images

Figure 00000000_0000_ABST
Abstract
Description
Title of the invention: Methods for processing a pseudonymized call and managing a pseudonymized number and devices implementing these methods. Field of the invention
[0001] This invention relates to the field of communications.
[0002] More specifically, the invention relates to the treatment of failed calls made to pseudonymized telephone numbers. Previous art
[0003] The development of intermediary platforms, for example commercial or social platforms, contributes to the increase in ad hoc and / or ephemeral communications between users, or between users and platforms. In the context of these communications, individuals interacting with or via these platforms, whether they are callers or called upon, generally do not wish to disclose their personal telephone number.
[0004] To address this problem of confidentiality and security of a user's personal telephone number (this number directly identifying the user), one solution is to use a call pseudonymization mechanism. Pseudonymization is based on using a secondary call identifier called a pseudonymized number instead of the user's personal telephone number (hereafter referred to as the primary call identifier or primary number).
[0005] A pseudonymized number is therefore, in a sense, a "borrowed" telephone number, typically assigned by a pseudonymization service to a primary number. When a call is made from a terminal (or specifically by a terminal associated with a specific number) to this pseudonymized number, it is routed by the pseudonymization service to the primary identifier of the called party corresponding to the pseudonymized number, so that the caller can reach the called party without knowing their primary identifier. This process assumes that the pseudonymized number of the called party is communicated to the caller beforehand.
[0006] There are also cases where the caller also uses a pseudonymized number which will be displayed in place of their personal number on the called party's terminal; this number can then be used by the called party to call the caller back. This solution allows the caller, in particular, to avoid revealing their primary number to the person they are calling.
[0007] These solutions thus make it possible to resolve confidentiality issues between caller and called party, particularly with regard to interactions involving intermediary platforms. However, they can generate processing overhead when calls fail to connect, especially when a call failure message is returned to the caller.
[0008] In addition to technical reasons, specific causes of failure of calls to pseudonymized numbers may be related to the motivations of the persons called via these numbers and / or the circumstances which led to the creation and / or allocation of these numbers.
[0009] For example, - for a commercial intermediation platform offering items for sale, when an item has found a buyer and the corresponding advertisement has been removed, the seller no longer needs to be contacted via the pseudonymized phone number assigned to him by the commercial platform; - for an intermediation platform such as a dating site, following an unpleasant exchange, a called party may no longer wish to be contacted by a specific caller.
[0010] In such cases, it is then desirable to inform the caller that his calls to the pseudonymized number can no longer be completed and the specific reasons for this situation (for example, following a withdrawn advertisement or a block).
[0011] To broadcast such a message to the caller, in the current state of the art, a media server is requested within the platform implementing the pseudonymized calling service, then the message is broadcast from the media server to the caller's network, to finally be delivered to the latter.
[0012] As it is an audio and / or video message, the routing of this message has an impact on the bandwidth of the telephone network.
[0013] Furthermore, when the intermediation platform implementing the pseudonymized calling service is not located in the same country as the caller, the message must pass through several telephone networks, which generates a so-called "paperclip" effect, more commonly known as "tromboning." Tromboning refers to the forced passage of traffic (here, the media stream carrying the message) through a specific point (the paperclip) between operators, which negatively impacts the bandwidth of these operators' networks and can, by extension, reduce the reliability of the service.
[0014] Object and summary of the invention
[0015] The invention addresses these problems in particular by proposing a method for processing a call originating from a terminal to a pseudonymized number, said call conforming to a session initialization protocol and passing through a pseudonymized number management device that manages said pseudonymized number, said the process being implemented by a pseudonymized call handling system and comprising: - a step to determine that the call cannot be completed for the terminal, - a step of sending to the pseudonymized number management device an error message conforming to the session initialization protocol, said error message being capable of triggering a transmission by the pseudonymized number management device of a media stream notifying the terminal of the non-successful call.
[0016] The invention also relates to a method of managing a pseudonymized number by a pseudonymized number management device, said method comprising: - a step of transmitting to a pseudonymized call processing device a call received by said management device and sent by a terminal to said pseudonymized number, said call being in accordance with a session initialization protocol, - when said pseudonymized call processing device determines that the call cannot be completed for the terminal, a step of receiving from said processing device, an error message in accordance with the session initialization protocol, said error message being capable of triggering a transmission by the management device of a media stream notifying the terminal of the failure of the call, and . - a step of transmitting said media stream to said terminal.
[0017] According to a particular embodiment, the session initialization protocol is the SIP (Session Initiation Protocol) or ISUP (Integrated Services Digital Network User Part).
[0018] By "suitable to trigger", it is meant here that the error message, when received by the pseudonymized number management device, is interpreted by the latter as an instruction (or a command) to carry out a particular action, in this case sending a media stream to the terminal explaining the reason for the call not being completed, which may be supplemented possibly by other actions such as sending an error message to the terminal, etc.
[0019] Session initialization protocols are known to those skilled in the art to allow the sending of requests such as, for example, for the SIP protocol: - INVITE, which allows a client to request a new session, typically a call session, - ACK, which confirms the establishment of the session, or - CANCEE, which allows you to cancel a pending INVITE request,
[0020] To which standard responses can be associated, such as: - 200 OK: Request accepted,
[0021] - 4XX: customer error, such as: -- 400: Bad Request (when the request was not understood by the server) - 5XX: Server failure, such as: -- 502: Bad Gateway (when a problem in other networks prevents the request from being processed), — 503: Service Unavailable (when the service is temporarily unavailable) - etc.
[0022] One of the principles of the invention consists of inventively exploiting existing messages of the session initiation protocol, and more particularly error messages of the protocol typically based on existing codes, by diverting them from their primary function and giving them a specific meaning, interpreted as such by the pseudonymized number management device and corresponding to causes of call failure to reach pseudonymized numbers.
[0023] Thanks to the invention, the handling of failed calls to pseudonymized numbers is ensured, as is notification to the caller of the reason for the failed call, while reducing network costs, limiting the infrastructure used, and improving service reliability. Since these are error messages from the session initiation protocol, their transmission via intermediate equipment to the pseudonymized number management device is guaranteed and does not, in itself, trigger any undesirable effects or unwanted processing by this intermediate equipment.
[0024] By way of illustration, these processes make it possible in particular to no longer have to request a media server (also known as an MRF server for Media Resource Function Server in English) deployed within the anonymized call management platform, contrary to the state of the art.
[0025] Indeed, in typical implementations and in the context of a failed call, an MRF server is commonly used to transmit a media stream, providing information on the reasons for the failed call, over the telephone network, from the MRF server to the calling terminal via a pseudonymized number management platform. Such an implementation negatively impacts bandwidth. Furthermore, it is common for this equipment, for example the PFS platform, the MRF server, and the calling terminal, to belong to different communication networks, resulting in congestion on each network.
[0026] According to the invention, the methods exploit the ability of the session initiation protocol (e.g., SIP or ISUP) to send error messages by advantageously associating them with "typical reasons" for call failure, which are interpreted as such by the pseudonymized number management device. This occurs only at the end of the information flow, before transmission. to the caller, that a server (here the pseudonymized number management device) will interpret it and generate a media stream corresponding in some way to a "verbalization" of the session initiation protocol code associated with the reason for the call not being routed.
[0027] In addition to reducing the strain on the infrastructure that makes up the telecom network, the invention proves to be relatively simple to implement and allows for better compatibility of the pseudonymized calling service within telecom networks already using session initialization protocols.
[0028] According to a particular embodiment, the error message is also capable of triggering the sending, by the pseudonymized number management device, to the terminal, of an end-of-call message conforming to the session initialization protocol.
[0029] This embodiment makes it possible, in particular, to prevent cases where the caller's network itself transmits another media stream to the terminal regarding the call failure. This solution therefore has the advantage of offering more comprehensive management of call failures, which ultimately guarantees a better understanding of the situation for the caller (by preventing them from receiving other, potentially contradictory, messages regarding the call failure).
[0030] According to a particular embodiment, the media stream transmitted by the pseudonymized number management device is specific to a cause of call failure specified by the error message.
[0031] This embodiment offers greater transparency to the caller by providing the reason for the failure of their call to the pseudonymized number.
[0032] The reason for the failed call can, for example, be transmitted within the error message itself in a format conforming to the session initialization protocol, thus limiting the network resources used. A specific media stream is then sent to the calling terminal depending on the reason for the failed call received.
[0033] To implement this embodiment, several predetermined media streams can be available at the level of the pseudonymized number management device, each of these streams corresponding to a type of reason for call failure (for example, caller blocking, withdrawal of the advertisement with respect to which the pseudonymized number had been associated with the called party, etc.) and depending on the reason for failure received within the error message, the corresponding stream (to this reason) is transmitted to the calling terminal.
[0034] In a particular embodiment, the error message includes a download address for specific call failure data intended for use during media stream transmission.
[0035] According to one embodiment, said data includes an audio and / or video file intended to be played within said media stream.
[0036] These embodiments make it easy to provide the caller with a personalized and / or more precise reason for the call's failure. For example, the file in question may include a pre-configured message, or a personalized message adapted to the context. Examples of such messages include: - an audio message explaining why the called party no longer wishes to be contacted by the caller, - a message containing details provided by the intermediary service that communicated the pseudonymized number to the caller, - etc.
[0037] The invention also relates to a device for processing pseudonymized calls originating from a terminal to a pseudonymized number, said call conforming to a session initialization protocol and passing through a pseudonymized number management device managing said pseudonymized number, said pseudonymized call device comprising: - a determination module configured to determine that the call cannot be completed for the terminal, and - a transmission module configured to send to the pseudonymized number management device an error message conforming to the session initialization protocol, this error message being capable of triggering the transmission, by said pseudonymized number management device, of a media stream notifying the terminal of the failure of the call.
[0038] The invention also relates to a pseudonymized number management device, configured to receive a call originating from a terminal to a pseudonymized phone number managed by said management device, said call conforming to a session initialization protocol, the management device comprising: - a transmission module configured to transmit said call to a pseudonymized call processing device, - a receiving module configured to, when said pseudonymized call processing device determines that the call cannot be completed for the terminal, receive from said pseudonymized call processing device an error message conforming to the session initialization protocol, capable of triggering the transmission by the pseudonymized number management device of a media stream notifying the terminal of the call failure, - a sending module configured to transmit said media stream to said terminal.
[0039] The invention further relates to a computer program comprising instructions for implementing the methods of processing a call and managing a number pseudonymized, according to any of the particular embodiments described above, when these programs are executed by a processor.
[0040] Such instructions can be stored permanently in a non-transient memory medium of a terminal implementing the call processing method according to the invention.
[0041] These programs 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 a partially compiled form, or in any other desirable form.
[0042] The invention also relates to a computer-readable information or recording medium on which a computer program such as those mentioned above is recorded.
[0043] The recording medium can be any entity or device capable of storing the program. For example, the medium can include a storage means, such as a ROM (Read Only Memory), for example a CD ROM (Compact Disc Read-Only Memory) or a microelectronic circuit ROM, or a magnetic recording means, for example a mobile medium, a hard disk or an SSD (Solid State-Drive).
[0044] On the other hand, the recording medium can be a transmissible medium, such as an electrical or optical signal, which can be transmitted via an electrical or optical cable, by radio, or by other means, so that the computer program it contains can be executed remotely. The programs according to the invention can, in particular, be downloaded onto a network, for example, an Internet-type network.
[0045] Alternatively, the recording medium may be an integrated circuit in which one of the programs is incorporated, the circuit being adapted to execute or to be used in the execution of the aforementioned call processing and pseudonymized number management processes.
[0046] The invention also relates to a system for processing a pseudonymized call, said system comprising: - a pseudonymized call processing device according to the invention, and - a pseudonymized number management device conforming to the invention.
[0047] The pseudonymized call processing device, the pseudonymized number management device, the computer program, the recording medium and the system according to the invention have the same advantages mentioned above as the methods of processing a call and managing pseudonymized numbers.
[0048] Furthermore, it can be envisaged, in other embodiments, that the processes and devices according to the invention present in combination all or part of the aforementioned characteristics. Brief description of the drawings
[0049] Other features and advantages will become apparent upon reading particular embodiments of the invention, given by way of illustrative and non-limiting examples, and the accompanying drawings, among which:
[0050] Figure [Fig. 1] represents, in its environment, a system according to the invention, in a particular embodiment,
[0051] Figure [Fig.2] describes the steps of the pseudonymized call processing and pseudonymized number management processes according to one embodiment,
[0052] Figure [Fig.3] schematically represents the hardware architecture of a pseudonymized call processing device according to one embodiment of the invention.
[0053] Figure [Fig. 4] schematically represents the hardware architecture of a pseudonymized number management device according to one embodiment of the invention. Detailed description
[0054] Description of a system according to the invention, in a particular embodiment
[0055] Figure [Fig.1] shows, in its environment, a SYS system according to the invention, in a particular embodiment.
[0056] This SYS system comprises: - a pseudonymized call processing device (DT), according to the invention, configured to implement a method for processing a call originating from a terminal to a pseudonymized number according to the invention, and, - a DG pseudonymized number management device according to the invention, configured to implement a method for managing a pseudonymized number according to the invention.
[0057] DT and DG devices are, for example, servers or configurable network equipment such as routers. Since they are involved in call management (for example, when the pseudonymized number is called or is the caller), they use a session initiation protocol, such as the SIP protocol in the example considered here, to communicate with other equipment or terminals. Of course, the invention is not limited to this protocol, and other session initiation protocols can be considered, such as the ISUP protocol, a proprietary protocol, etc.
[0058] In the embodiment envisaged here, the SYS system is deployed in an environment comprising: - a terminal Tl, associated with a primary call number ID1, connected to a telephone network R and making a call to a pseudonymized number ID2Bis in order to be contacted by a user U2. The terminal Tl can be any type of user equipment such as, for example, a landline telephone, a smartphone, etc. - a T2 terminal, to which is associated a pseudonymized ID2Bis number which is provided to the user of terminal T1 to call terminal T2. The T2 terminal is connected to a telephone network R, and can be any type of user equipment such as, for example, a landline telephone, a smartphone, etc., or even a server, and - a PFS server, to which is associated an intermediation service S, using the pseudonymized number ID2Bis to connect users of terminals T1 and T2.
[0059] The network R, to which terminals T1 and T2, as well as the PFS server and devices DG and DT, are connected, allows the terminals, server, and devices to communicate with each other according to, in the example considered here, the SIP session initialization protocol. In other embodiments, a different session initialization protocol, for example ISUP, is used.
[0060] According to the embodiments, the pseudonymized call processing device DT, the pseudonymized number management device DG, and the PFS server communicate with each other using one or more (sub)networks (or secondary networks), typically the caller's network, the called party's network, and intermediate networks not shown in the figure. These (sub)networks may be managed by the same or different operators, and may be deployed within the same country or different countries, be separate networks or a single network, etc. By way of illustration, in the example considered here, terminals T1 and T2 are smartphones associated respectively with (sub)networks of R, named RI and R2, operated by two different telecom operators.
[0061] According to provisions known to the person skilled in the art, the DG pseudonymized number management device manages at least one ID2Bis pseudonymized telephone number so that calls to this number are directed to said DG pseudonymized number management device.
[0062] In this embodiment, the pseudonymized number management system DG is managed by a pseudonymized number provider (alias number provider), for example, a mobile operator that has entered into an agreement with a fixed-line telephone operator on the R network to which the said telephone number ID2Bis belongs, and which it has subsequently delegated (i.e., assigned) under the agreement entered into with the mobile operator. These are arrangements well known to those skilled in the art whereby a company, for example, a mobile virtual network operator (MVNO) or a mobile network operator (MNO), can obtain one or more telephone numbers from other operators in order to use them to implement its own service offering.
[0063] In this embodiment, the pseudonymized number management device DG is configured to transfer calls destined for the ID2Bis number to a pseudonymized call processing device DT.
[0064] The DT pseudonymized call processing device is a network device intended to redirect incoming calls to primary telephone numbers specified by the PFS server. In this embodiment, the DT pseudonymized call processing module corresponds to an "aliased" (i.e., pseudonymized) AS Call processing service.
[0065] The PFS server stores information concerning the routes linking a pseudonymized telephone number and a terminal's primary telephone number. In this specific case, this information relates to the routing to the ID2 number associated with terminal T2 of calls originating specifically from terminal T1 to the ID2Bis number. The PFS server also has information regarding the routing status of pseudonymized numbers and information on the reasons and circumstances of said status. Typically, in the example considered here, the PFS server corresponds to a backend service for "aliased" numbers (AliasNumber) that has information indicating the reason(s) for the failure of a call originating from terminal T1 to the ID2Bis number of terminal T2.
[0066] According to the embodiment described here, the ID2Bis number was communicated to user U1 of terminal Tl following a request by user U1 (the caller) stating his wish to get in touch with user U2 (the called party).
[0067] According to provisions known to those skilled in the art, this connection request was made from the intermediation service S, associated with the PFS server. The PFS server, which also knows the primary numbers of terminals T1 and T2, subsequently created a route associated with the pseudonymized number and the primary telephone numbers of terminals T1 and T2, so that a call originating from terminal T1 and destined for the number ID2Bis would be routed to terminal T2. It then communicated the pseudonymized number ID2Bis to the user Ul.
[0068] The fact that a connection request precedes the call from terminal T1 to terminal T2 offers the advantage of allowing the same pseudonymized number to be used simultaneously for several caller-called pairs. Indeed, here, the routing from caller to called party is established both based on the number dialed by the caller (ID2Bis) and based on the telephone number associated with their terminal (ID1). In this way, two distinct callers can dial the same pseudonymized called party number but be routed to two different called parties.
[0069] In another embodiment, the routing of the telephone number ID2Bis to the terminal T2 is not specific to the terminal T1 so that all calls made to the number ID2Bis are redirected to the terminal T2 regardless of the calling terminal.
[0070] According to yet another embodiment, the caller's terminal number T1 can also be pseudonymized: in this case, another pseudonymized IDIBis number is displayed on the called party's terminal T2 instead of the main telephone ID1 number associated with terminal T1. This is referred to as double pseudonymization.
[0071] As shown in the figure, the pseudonymized call processing device and the PFS server constitute two separate network devices; however, in other embodiments, they may constitute only one device.
[0072] The nature of the terminals T1 and T2, the structure of the networks and subnets R, RI and R2, the nature of the pseudonymized number management devices DG and call processing devices DT as well as that of the PFS server correspond to an illustrative and non-limiting embodiment.
[0073] Description of the steps in the processes for handling a call and managing a pseudonymized number according to a first embodiment
[0074] Figure [Fig.2] represents the main steps of the methods according to the invention as implemented respectively by the pseudonymized call processing devices DT and the pseudonymized number management device DG of the SYS system shown in Figure [Fig.1], in a particular embodiment.
[0075] It is assumed here that during step E201, terminal T1 makes a call to terminal T2 using the pseudonymized phone number ID2Bis. This call is routed in a manner known per se to the pseudonymized number management device DG, which manages said pseudonymized phone number ID2Bis.
[0076] In E202, the DG device receives the call and transmits it to the pseudonymized call processing device DT.
[0077] The transmission of this call results from a prior configuration of the DG pseudonymized number management device so that a call to the pseudonymized number ID2Bis is transmitted to the DT pseudonymized call processing device.
[0078] This call conforms to the SIP protocol and takes, for example, the following form: SIP Invite (SDPID1) R-URI= IDTech ; user=phone From = PAI= ID1 To = IDTech Diversion : ID2Bis
[0079] Where IDTech is the technical number associated with the DT device for handling pseudonymized calls, i.e., the equivalent of its primary telephone number. This number is known beforehand; the forwarding of such a call to the DT device for handling pseudonymized calls is part of the configuration of the pseudonymized number management device.
[0080] In E203, after receiving the call, the pseudonymized call handling device DT determines that the call cannot be completed for the terminal. The reasons for this failure can vary. By way of illustration and without limitation, the reason for the failure corresponds, in a first example, to a case where the advertisement for which the ID2Bis telephone number was created has been withdrawn, and in a second example to a case where the called party has blocked the caller in particular. Other causes may exist, such as the recipient putting the number on standby for a given period, a non-routing due to a technical problem, etc.
[0081] To this end, in the embodiment described here, the pseudonymized call processing device DT communicates call data to the PFS server, and more particularly the caller ID1 number and the pseudonymized ID2Bis number called, and receives in return the information that the call cannot be completed, as well as the reason associated with this failure.
[0082] Thus, by way of illustration, in Example 1 considered above, as soon as the advertisement to which the pseudonymized number is associated is withdrawn, information is generated and then automatically reported to the PFS server, indicating that future calls will no longer be successful. The reason for call failure indicated is "advertisement withdrawn".
[0083] According to example 2, following the notification on the dating service by the recipient of their wish to no longer be contacted by the caller, information is generated and then automatically reported to the PFS server, indicating that future calls from ID1 will no longer be completed. The reason given for the failed call is "caller blocked".
[0084] In other embodiments, this determination can be carried out directly by the pseudonymized call processing device DT, for example in the case where the pseudonymized call processing device DT and the PFS server are a single technical entity.
[0085] According to this embodiment, the reason for the failure of the call is, as in the examples above, specific to the service associated with this call as well as to the caller and / or the called party.
[0086] According to other embodiments, the reason for failure is technical, for example if the DT pseudonymized call processing device fails to reach the PFS server or if the PFS server data has been lost etc.
[0087] In E204, according to the invention, the pseudonymized call processing device DT sends an error message conforming to the session initialization protocol to the pseudonymized number management device DG, this error message being capable of triggering the transmission, by said DG device, of a media stream notifying terminal Tl of the failure of the call.
[0088] By way of illustration, and in the case of the SIP session initialization protocol, according to the two examples mentioned above, such an error message takes the following form: Example 1: SIP 4xx (Reason-Header: Q.850; cause=announce_cancel), in the case of a withdrawn announcement,
[0089] Example 2: SIP 4xx (Reason-Header: Q.850; cause=caller_blocked), in the case of caller ID blocking, where: - 4xx is a SIP status code chosen as part of the implementation to communicate the failure of a call to a pseudonymized number, - Reason-Header: Q.850 is a cause code title, - cause = announce_cancel or callerjblocked the reasons for the call not succeeding according to the two examples.
[0090] According to other embodiments, rather than indicating the reason for the call not being completed by means of a cause code heading, SIP status codes, such as for example 4xx or 6xx, are used to indicate a particular cause. For example, according to one embodiment: - SIP 4xx corresponds to a message failure due to a withdrawn advertisement, and - SIP 6xx corresponds to a message failure due to caller blockage.
[0091] According to these examples, the returned cause (field "cause") provides specific information on the failure of the pseudonymized call without this information being specific to the caller, the called party or the intermediation service that caused the call. For example, the cause "announce_cancel" does not specifically state that the removed ad was published on a particular intermediation platform, or that for the cause "caller_blocked" it is specifically the recipient of the call who blocked the caller's number.
[0092] In E205, the reception of the error message from the pseudonymized call processing device DT triggers the transmission by the pseudonymized number management device DG of a media stream notifying terminal Tl of the call not being completed.
[0093] According to this embodiment, there is a typical media stream, corresponding to a generic message, for each type of reason for call failure. Thus, the transmitted media stream corresponds to the received reason for call failure. As For example, in the case of examples 1 and 2 previously considered, these media streams can convey the following generic messages: - Example 1: "The advertisement you are calling about has been removed." - Example 2: "The person you wish to contact has blocked you"
[0094] According to another embodiment, in E204, the error message sent by the DT pseudonymized call processing device contains a link to download specific content, for example an audio and / or video file.
[0095] In this alternative embodiment, the message is no longer necessarily generic and can instead be specific to the service, the caller, and / or the called party. Typically, in the examples considered previously: - Example 1: the file may include a text message: "Hello Julien, Julie's blue sofa has been sold, this ad has been removed, our classifieds service thanks you for your call", - Example 2: the file could be an audio file corresponding to the following message: "Hello Paul, I don't wish to see you again".
[0096] In addition, in E205, this message is downloaded by the DG management device from the PFS server and then sent to the Tl terminal.
[0097] According to yet another embodiment, in E204, the error message sent by the pseudonymized call handling device (DT) is also capable of triggering the sending, by the pseudonymized number management device, to the terminal, of an end-of-call message conforming to the session initialization protocol. Such an end-of-call message signifies, according to the session initialization protocol used, that the call is terminated and that it should not lead to any further actions such as sending messages to the network equipment involved in the call. For example, in the case of the SIP protocol, such an end-of-call message can be a SIP 410 message (Reason-Header: Q.850; value=16), or a SIP 607 message (Reason-Header: Q.850; value=16).
[0098] The value code 16 corresponds to information "Normal call clearing", as detailed in the document The Reason Header Field for the Session Initiation Protocol (SIP) published by 1TETF (https: / / www.ietf.org / rfc / rfc3326.txt). The SIP code, here 410 or 607, corresponds to a code whose meaning has been, within the framework of the invention, diverted in order to provide information on a cause of failure of a call to a pseudonymized number.
[0099] According to this embodiment, in E205, the pseudonymized number management device DG then transmits the media stream to terminal Tl, and once the media stream has been played at terminal Tl, it sends it the end-of-call message. In this mode In this implementation, the call end message ensures, on the one hand, that no equipment within the R network, or one of its RI or R2 subnets involved in the call routing, generates an additional media stream beyond that sent by the DG pseudonymized number management device to terminal Tl, and on the other hand, that the DG pseudonymized number management device terminates the call (in particular, in this embodiment, thanks to the code "value=16").
[0100] It should be noted that the call termination message may be a separate message from the error message received from the pseudonymized call processing device DT; alternatively, it may be the error message received from the pseudonymized call processing device DT which is relayed by the pseudonymized number management device DG to the terminal Tl as soon as this message carries an end-of-call instruction (for example, a code such as the code "value=16" in the example of the SIP protocol).
[0101] Description of a device for processing pseudonymized DT calls according to an embodiment of the invention
[0102] Figure 3 presents the simplified structure of a DT device configured to implement the process of processing a pseudonymized call in a particular embodiment.
[0103] In this embodiment, the DT device includes an ER1 communication module adapted to receive and transmit calls and information.
[0104] Furthermore, in the particular embodiment of the invention described herein, the steps performed by the DT device, within the framework of implementing the method for processing a pseudonymized call of the present invention, are implemented by means of instructions from a computer program PG1. For this purpose, the DT device has the classic architecture of a computer and includes, in particular, a memory MEM1, a processing unit UTR1, equipped, for example, with a PROC1 processor, and controlled by the computer program PG1 stored in memory MEM1. The memory MEM1 is a storage medium within the meaning of the invention.The computer program PG1 includes instructions for implementing the steps of the method for processing a pseudonymized call according to the invention, and in particular: - determining that the call cannot be completed for the terminal, - sending to the pseudonymized number management device an error message conforming to the initialization protocol, capable of triggering the transmission by the pseudonymized number management device of a media stream notifying the terminal of the call's failure to complete.
[0105] The PG1 program thus defines functional modules of the DT pseudonymized call processing device which include: - a Detl determination module to determine that the call cannot be completed for the terminal, - an Envi transmission module sending to the pseudonymized number management device an error message conforming to the initialization protocol, capable of triggering the transmission of a media stream notifying the terminal of the call not being completed.
[0106] Description of a device for managing pseudonymized numbers according to an embodiment of the invention
[0107] Figure 4 presents the simplified structure of a DG device configured to implement the pseudonymized number management process in a particular embodiment.
[0108] In this embodiment, the DG device includes an ER2 communication module adapted to receive and transmit calls and information.
[0109] Furthermore, in the particular embodiment of the invention described herein, the steps performed by the DG device, within the framework of implementing the pseudonymized number management method of the present invention, are implemented by means of instructions in a computer program PG2. For this purpose, the DG device has the conventional architecture of a computer and includes, in particular, a MEM2 memory, a UTR2 processing unit, equipped, for example, with a PROC2 processor, and controlled by the PG2 computer program stored in MEM2 memory. The MEM2 memory is a storage medium within the meaning of the invention. The PG2 computer program includes instructions for implementing the steps of the pseudonymized number management method, in particular: - transmit said call to a pseudonymized call processing device, - when said pseudonymized call processing device determines that the call cannot be completed for the terminal, receive from said module an error message conforming to the initialization protocol, capable of triggering the transmission of a media stream notifying the terminal of the non-completion of the call, - the transmission of said media stream to the terminal.
[0110] The PG2 program thus defines functional modules of the DG pseudonymized number management device receiving a call originating from a terminal to a pseudonymized phone number, said call conforming to a session initialization protocol and comprising: - a Tr2 transmission module configured to transmit said call to a pseudonymized call processing device, - a Rec2 receiving module configured to, when said pseudonymized call processing device determines that the call cannot be completed for the terminal, receive from said DT device an error message conforming to the protocol session initialization, capable of triggering the transmission of a media stream notifying the terminal that the call failed, - an Env2 sending module configured to transmit said media stream to said terminal.
Claims
Demands
1. A method for processing a call originating from a terminal to a pseudonymized number, said call conforming to a session initialization protocol and passing through a pseudonymized number management device managing said pseudonymized number, said method being implemented by a pseudonymized call processing device and comprising: - a step (E203) of determining that the call cannot be completed for the terminal, - a step (E204) of sending to the pseudonymized number management device an error message conforming to the session initialization protocol, said error message being capable of triggering a transmission by the pseudonymized number management device of a media stream notifying the terminal of the non-completion of the call.
2. A method for managing a pseudonymized number by a pseudonymized number management device, said method comprising: - a transmission step (E202) to a pseudonymized call processing device of a call received by said management device and made by a terminal to said pseudonymized number, said call being in accordance with a session initialization protocol, - when said pseudonymized call processing device determines that the call cannot be completed for the terminal, a reception step (E204) by said processing device of an error message in accordance with the session initialization protocol, said error message being capable of triggering a transmission by the management device of a media stream notifying the terminal of the non-completion of the call, and - a transmission step (E205) of said media stream to said terminal.
3. A method according to claim 1 or 2, wherein the error message is further capable of triggering the sending, by the pseudonymized number management device, to the terminal, of an end-of-call message conforming to the session initialization protocol.
4. A method according to any one of claims 1 to 3, wherein the media stream transmitted by the pseudonymized number management device is specific to a cause of call failure specified by the error message.
5. A method according to any one of claims 1 to 4, wherein the error message includes a call failure specific data download address intended for use during media stream transmission.
6. A method according to claim 5, wherein said data includes an audio and / or video file intended to be played within said media stream.
7. A method according to any one of claims 1 to 6, wherein the session initialization protocol is the SIP (Session Initialization Protocol) or the ISUP (Integrated Services Digital Network User Part) protocol.
8. A device for processing pseudonymized calls originating from a terminal to a pseudonymized number, said call conforming to a session initialization protocol and passing through a pseudonymized number management device managing said number, said processing device comprising: - a determination module (Dl) configured to determine that the call cannot be completed for the terminal, and - a transmission module (El) configured to send to the pseudonymized number management device an error message conforming to the session initialization protocol, this error message being capable of triggering the transmission, by said pseudonymized number management device, of a media stream notifying the terminal of the call's failure to complete.
9. A pseudonymized number management device, configured to receive a call originating from a terminal to a pseudonymized phone number managed by said management device, said call conforming to a session initialization protocol, the management device comprising: - a transmission module (Tr2) configured to transmit said call to a pseudonymized call processing device, - a reception module (Rec2) configured to, when said pseudonymized call processing device determines that the call cannot be completed for the terminal, receive from said pseudonymized call processing device an error message conforming to the session initialization protocol, capable of triggering transmission by the pseudonymized number management device. a media stream notifying the terminal of the call not being completed, - a sending module (E2) configured to transmit said media stream to said terminal.
10. Computer program (PG1, PG2), comprising instructions for implementing the methods of handling a call and managing a pseudonymized number, according to any one of claims 1 to 7, when said program is executed by a processor.
11. Information or recording medium (MEM1), respectively (MEM2), readable by a computer on which a computer program according to claim 10 is recorded.
12. System (SYS) for handling pseudonymized calls, said system comprising: - a device for handling pseudonymized calls according to claim 8, and - a device for managing pseudonymized numbers according to claim 9.
Citation Information
Patent Citations
Routing multiple numbers for one telecommunications device
EP3278548B1
Algorithm to make optimal use of network resources during a mass calling event
US8059799B1