Patent Publication Number: US-2015085855-A1

Title: Method and system for managing the communication between two users

Description:
TECHNICAL FIELD 
     The present invention relates to a method and a system for managing the communication between two users through the Internet. 
     In general, the present invention finds application in the field of Internet communications, in particular voice or telephone Internet communications of the “Click-to-call” type. 
     PRIOR ART 
     Internet communications have now become widespread and make use of many different technologies. The available Internet communication technologies include the so-called “Click-to-call” technology, wherein a user can click an element shown on a Web page in order to request in real time an immediate connection to another user. Typically, such a communication takes place by voice, e.g. through a Voice-Over-IP (VoIP) protocol, thus being similar to a classic telephone or videophone call. 
     Among the variants of this “Click-to-call” technology, the most interesting one allows a calling user to click a web link in order to establish a voice connection to the called user identified by the clicked element, e.g. a link. In this way, the calling user can reach the called user “on the phone” without incurring in any direct costs, provided that an Internet connection is available between the two users. In some cases, the software for voice and/or videophone communication is implemented in the web browser itself, so that the client needs not install and configure any additional software in his/her own operating system. This feature is especially useful when the called user is assigned a permanent web link, without any time limit, which he/she can then make available as an alternative and free means of reaching him/her, even though the caller does not know that user&#39;s telephone number. 
     This technology becomes particularly interesting when the called user is a company and the calling user is a prospect. Under this aspect, the “Click-to-call” technology represents a valid successor to the long-known “toll-free” numbers. 
     One example of a significant technology in this regard is the Skype© service. This service allows a user to call other users with just one click, through the respective Skype© accounts. However, the Skype© service requires that both users have already registered into the service, thus making the interaction between unregistered users difficult. 
     Since it is desirable to improve the easiness of “Click-to-call” communications, it becomes necessary to allow any calling user, even an unregistered one, to be able to make a call to a called user. 
     However, also allowing any calling user to initiate a communication may give rise to problems. 
     With a “Click-to-call” element, in fact, a user who wants to be reachable earns visibility and can more easily communicate with third parties, but at the same time he/she will expose him/herself to the risk of receiving undesired calls. 
     Also, since the ideal form of a “Click-to-call” service is gratuitous for the calling user and is associated with a widespread public service such as the Internet, there is a definite risk that the called user will be submerged with undesired calls—which is a kind of “spam”—even from ill-intentioned calling users. 
     Aiming at controlling a voice communication through the Internet, patent application US2003/0152207 by Ryan proposes a control system according to which a user of an Internet telephone communication service can individually control the communication options assigned to various called users, including the possibility of establishing a telephone connection. 
     In a first embodiment, patent US2003/0152207 to Ryan uses a list of calling user identifiers to be filled in by the called user, and only those users who are included in this list will be allowed to establish a telephone connection. If on the one hand this first embodiment effectively avoids the problem of undesired calls, on the other hand it significantly restricts the possibility of user interaction, in that the users must be included in a list of “welcome” identifiers known a priori. 
     In a second embodiment, patent US2003/0152207 to Ryan employs an “emergency call” mode, in which a calling user can contact the called user even if he/she is not included in a list of “welcome” identifiers known a priori. In this second embodiment, the calling user is required to provide an e-mail address to which a verification code will then be sent, which code must be entered by the calling user on a Web page. If the code entered by the calling user is correct, he/she will be able to initiate the call to the called user. 
     Although this second embodiment does limit the problem of undesired calls, it still has the drawback of excessively limiting the flexibility of user communication; therefore, it is only recommended for managing emergency situations in which it is of vital importance to be able to contact the called user by whatever means. For example, even this second embodiment gives the called user no information useful for deciding whether the call should be answered or not, depending on the calling user&#39;s identity. 
     BRIEF DESCRIPTION OF THE INVENTION 
     The object of the present invention is to provide a method and a system which allow overcoming the above-mentioned drawbacks of the prior art, as well as other problems. 
     In particular, it is one object of the present invention to provide a method and a system which make the use of “Click-to-call” services more desirable for the users, by improving the easiness of use and security thereof. 
     It is another object of the present invention to provide a method and a system wherein the calling user can easily and immediately initiate, through “Click-to-call” services, a communication with a called user. 
     Finally, it is a further object of the present invention to provide a method and a system wherein a user called by means of “Click-to-call” services can effectively filter the incoming calls and avoid any undesired calls. 
     These and other objects of the present invention are achieved through a method and a system for managing the Internet communication between two users incorporating the features set out in the appended claims, which are an integral part of the present description. 
     A general idea at the basis of the present invention is to provide a method for managing the communication between a calling user and a called user, wherein the communication takes place in real time through the Internet network, comprising the steps of: receiving a request to initiate a communication with a called user from a calling user; requesting the calling user to provide an identity element; validating the identity element of the calling user; transmitting the validated identity element to the called user. 
     In this manner, the called user can better evaluate whether the “Click-to-call” call should be answered or not. 
     Moreover, the provider of a “Click-to-call” communication service may be able to assign permanent “Click-to-call” web addresses to its clients, and to manage the communication requests directed to clients who want to be called and made by a plurality of calling users who may want to communicate with a selected called user. Advantageously, the called user is given a validated identity element of the calling user, i.e. tendentially reliable information about the identity of the called user; in this way, the calling user is informed about some personal data of the calling user. Advantageously, the validation procedure allows the calling user to gain access to a practical and useful service, wherein he/she can select and establish a communication with a called user and complete the validation procedure simply by providing an identity element to be validated by the service provider. 
     Preferably, the identity element directs to a recipient adapted to receive digital information, and the validation process comprises the steps of: sending a validation element addressed to the identity element; receiving a reply based on said validation element to confirm the actual availability of the identity element from the calling user. 
     Advantageously, this improves the security of the method by verifying, through a short but effective procedure, the correspondence between the identity element provided by the calling user and the actual availability of the identity element from the same calling user. In this manner, it is possible to transmit to the called user an identity element which more reliably represents the calling user&#39;s identity, so that the called user can decide whether to pick up the call or not. 
     In a preferred embodiment, the identity element provided by the calling user comprises an e-mail address, to which the method provides for sending a validation link; through the validation link, the calling user can then confirm the actual availability of the identity element. 
     In one possible preferred embodiment, the communication request received by the called user includes a piece of information about the e-mail address of the calling user, and is made simultaneously with the validation of the e-mail address by the calling user. 
     In another preferred embodiment, the identity element provided by the calling user comprises a telephone number, preferably a cellular phone number, to which the method provides for sending validation information, such as, for example, an alphanumeric code, which will then be requested to the calling user in order to confirm the actual availability of the identity element, so that the call request may include the caller&#39;s telephone number. 
     Advantageously, both of these embodiments rely on already widespread and available tools, which allow improving the real-time communication between the calling user and the called user. In addition, these identifiers allow providing an identity element with a reasonable degree of reliability and in a quick and inexpensive manner for the users. 
     In yet another preferred embodiment, the calling user directly provides a digital identifier certified by third parties, e.g. an identity document comprising a “smart card”, so that said identity can be transmitted to the called user along with the communication request. This embodiment may turn out especially advantageous should smart-card identification technologies become widespread. 
     Preferably, in all of the above-described cases the method provides for storing a validation acknowledgement into the computer terminal through which the calling user is accessing the “Click-to-call” service, e.g. by storing “Cookies” into the Internet browser. This advantageously avoids, while still ensuring the necessary security, having to repeat the validation procedure for subsequent “Click-to-call” calls from the same user, either for a single called user or for any other user who may be called in the future. After the validated identity element has been transmitted to the called user, the method further comprises the step of starting the communication if the called user accepts the call. Therefore, the “Click-to-call” service provider of the called user provides the information about the caller&#39;s identity element, but allows the called user to freely decide whether to establish or not the communication; advantageously, this improves the quality of the service for the called user, i.e. the main client of the service, who is put in a condition of being able to handle the call flow according to his/her preferences. 
     The method for managing the communication between a calling user and a called user according to the present invention is applicable, in particular, to real-time voice or videophone communications, which are established by relying on a communication network such as the Internet. 
     Preferably, the method is implemented through a digital computer system, comprising or associated with suitable software, adapted to manage the communication between a calling user and a called user. Said computer system may comprise a Web server, e.g. controlled by a service provider, connected to the Internet and adapted to interface through it to the computer terminals used by the calling user and the called user. 
     Further objects and advantages of the present invention will become more apparent from the following detailed description and from the annexed drawings, which are supplied by way of non-limiting example. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       In the drawings referred to in the description, the same reference numerals designate the same or equivalent elements or actions. 
         FIG. 1  schematically shows a “Click-to-call” communication through the Internet between two users; 
         FIG. 2  is a flow chart which illustrates an embodiment of the method according to the present invention; 
         FIG. 3  is a further flow chart which illustrates an embodiment of the method according to the present invention; 
         FIG. 4  is a further flow chart which illustrates an embodiment of the method according to the present invention; 
         FIG. 5  is a further flow chart which illustrates an embodiment of the method according to the present invention; 
         FIG. 6  is a further flow chart which illustrates an embodiment of the method according to the present invention; 
         FIG. 7  is a further flow chart which illustrates an embodiment of the method according to the present invention. 
     
    
    
     DETAILED DESCRIPTION 
       FIG. 1  illustrates the management of a “Click-to-call” communication by a server  101  of a service provider. The server  101  is connected, through a connection  102 , to a digital network that allows devices to exchange data. In this example, the connection  102  allows the server  101  to be connected to the Internet  103 . 
     The server  101  gives a plurality of users access to a “Click-to-call” system. 
     The user  104  has a computer terminal  105  connected to the Internet  103  through a connection  106 . For example, the user  104  may have a laptop connected to the Internet through a WiFi system. Alternatively, the user  104  may have a Smartphone connected to the Internet by means of WWAN technology. 
     The server  101  is adapted to give the terminal  105  access to at least one “Click-to-call” link, which can be acted upon by the user  104 . 
     In this example, the user  104  displays on the screen  107  a Web page containing a “Click-to-call” link associated with a user  108 , whom the user  104  wishes to call. 
     In an alternative example, the user  104  has a terminal  105  which is running a dedicated “Click-to-call” application (or program), i.e. comprising a user interface other than a Web page, while still allowing communication through the Internet network  103 . 
     In the present description, reference will be made without limitation whatsoever to the user  104  as “calling user” and to the user  108  as “called user”, it being understood that the communication might take place with exchanged roles or might include a larger number of users on both the calling side and the called side, mutually communicating with each other. In the event that no communication is established between the two users, in accordance with the teachings that will be provided below, the terms “called user” and “calling user” will have to be understood as potential qualifications, e.g. “he/she who is to be called” and “he/she who wants to call”. 
     The calling user  104  can thus act upon the Web link displayed on the screen  107  to forward to the server  101  a request to initiate a “Click-to-call” communication with the called user  107 . 
     This “Click-to-call” communication is preferably a real-time voice or videophone communication, and therefore the calling user  104  will use an earphone and a microphone or a hands-free system. In the present description, reference will be made to real-time communication by simply designating it as a “call”, it being understood that the communication might also take place in other known forms, such as: videophone call, instant messaging, file sharing, data sharing, etc. 
     The communication management method according to the present invention starts as soon as the server  101  receives the “Click-to-call” request from the user  104 , as will be described in detail below. 
     In general, the server  101  comprises a processor and an operating memory, and is adapted to prompt the calling user  104  to provide his/her “identity element”. In ways that will be described in detail below, the server  101  is adapted to validate the identity element of the user  104 . 
     Then the server  101  forwards the information about the identity element to the called user  108 . The called user  108  is also equipped with loudspeakers and a microphone, and in turn is using a computer terminal  109  connected to the Internet  103  through the connection  110 , e.g. an ADSL connection. 
     The server  101  is also adapted to exchange data with the terminal  109 . To this end, in one example of embodiment the terminal  109  of the called user  108  preferably comprises software in the form of a Java® applet in a un web browser, which performs the function of a web phone. 
     Said software interfaces to the audio devices (e.g. microphone and loudspeaker), the volume of which can be adjusted by the user, encodes and decodes the voice in IP packets, handles the signalling, and shows the identity element to the called user. As an alternative, the VoIP component may be implemented directly within the browser by means of “plug-ins” created ad hoc for the browsers used by the calling user to open a web link, or generic “plug-ins” such as, for example, Adobe Flash, which can also implement VoIP functions. 
     Similarly, in one example of embodiment the terminal  105  of the calling user  104  preferably comprises software of a web browser, as described above, which performs the function of a web phone. Said software interfaces to the audio devices (e.g. microphone and loudspeaker), the volume of which can be adjusted by the user, encodes and decodes the voice in IP packets, and handles the signalling. 
     The server  101  then sends a signal to the user  108 , preferably a visual and/or audible signal, which is representative of the fact that the user  104  wishes to establish a communication via “Click-to-call”. The screen  111  then displays a message which includes the information, validated by the server  101 , about the identity element of the calling user  104 . Such information may also be processed by software applications running on the called user&#39;s device, so as to facilitate the decision process that will lead to answer or not the call, e.g. through the use of “blacklists”, i.e. lists containing identifiers of unwelcome users. 
     Upon receiving this signal, the called user  108  may decide to accept the call; in such a case, the server  101  will initiate the communication between the terminal  105  and the terminal  109 , thus allowing the called user  108  and the calling user  104  to communicate with each other as requested by the latter. 
     Alternatively, upon receiving the signal the called user  108  may decide to reject the call. In this case, the server  101  will notify the calling user  104  about the impossibility of establishing the communication, or it will simply interrupt the connection with the calling user  104 . 
     It should be noted that the role of the server  101 , handled by the “Click-to-call” service provider, of which the user  108  is a client and the user  104  is an external user, only gives the possibility of establishing a communication between users and of notifying the called user that there is a pending call request. 
     The role thus structured of the server  101 , i.e. of the service provider, allows creating an “over-the-top” service, i.e. a service wherein there is a separation between the physical communication means (Internet) and the users&#39; identities. The service provider thus makes sure that, within the reasonable possibilities offered, a piece of information relating to an identity element of the calling user is transferred to the called user. In this manner, it is still up to the called user whether to accept the call or not, so that the service is characterized by the utmost flexibility. 
     The method of the present invention is particularly effective when there are no relationships, whether contractual, personal or interest ones, known a priori between the users. 
       FIG. 2  shows an embodiment of the method for managing the communication between the users  104  and  108 , which is implemented by the server  101  and by the apparatuses operationally connected thereto, e.g. the terminals  105  and  109 . 
     At step  201 , a request is received from the calling user  104  to initiate a communication with the called user  108 , e.g. as described with reference to  FIG. 1 . 
     In reply to the “Click-to-call” request received at step  201 , at step  202  the calling user  104  is asked to provide his/her own identity element. After the calling user  104  has provided his/her own identity element, at step  203  the identity element provided by the calling user  104  is validated. The implementation details of the steps  202  and  203  will become more apparent from the more detailed description of other embodiments referring to  FIGS. 3 ,  4  and  5 . 
     Finally, at step  204  the validated identity element is transmitted to the called user  108 , so that the called user  108  receives accurate information about the identity of the caller  104  and can decide whether or not to accept the call and establish the communication, e.g. as described with reference to  FIG. 1 . 
       FIG. 3  illustrates a more detailed embodiment of the communication management method. 
     At step  301 , a request is received from the calling user  104  to initiate a “Click-to-call” communication with the called user  108 , e.g. as described with reference to  FIG. 1 . 
     At step  302 , the calling user  104  is asked to provide his/her own e-mail address, e.g. by entering it into a form shown on the Web page displayed on the screen  107 . The e-mail address of the user  104  will be used as an “identity element” associated with that user. 
     At step  303 , an e-mail message is sent, e.g. by the server  101 , to the e-mail address specified by the calling user  104 , which message contains a validation element such as, for example, a non-public validation link that can be clicked by the user  104 . 
     At step  304 , an acknowledgement is received indicating that the validation link has been correctly clicked. In this case, it can be assumed with certainty that the user  104  actually has at his/her disposal the e-mail address specified at step  302 . 
     At step  305 , the information about the validated e-mail address of the user  104  is transmitted to the called user  108 . 
     Preferably, this transmission occurs simultaneously with the request to initiate a call with the user  104 , whose validated identity element is shown. The communication between the users can thus be established, e.g. as described with reference to  FIG. 1 . In a preferred embodiment, along with the transmission of the validated identity element to the called user  108 , the request to initiate the “Click-to-call” communication is sent as soon as the user  104  clicks the validation link. 
       FIG. 4  illustrates another more detailed embodiment of the communication management method. 
     At step  401 , a request is received from the calling user  104  to initiate a “Click-to-call” communication with the called user  108 , e.g. as described with reference to  FIG. 1 . 
     At step  402 , the calling user  104  is asked to provide his/her own cellular phone number, e.g. by entering it into a form shown on the Web page displayed on the screen  107 . The cellular phone number of the user  104  will be used as an “identity element” associated with that user. 
     At step  403 , a message, e.g. an SMS message sent by the server  101  via a suitable cellular connection, is sent to the cellular phone number specified by the calling user  104 , which message contains a validation element such as, for example, a non-public alphanumeric code, accessible to the user  104 . 
     At step  404 , the calling user  103  is asked to provide the validation element, e.g. by entering the validation code into a suitable form shown on the Web page displayed on the screen  107 . 
     At step  405 , it is verified if the calling user  104  has correctly provided the requested validation element. If, for example, the calling user  104  has entered the correct code, it can be assumed with certainty that the user  104  actually has at his/her disposal the cellular phone number specified at step  402 . 
     Then, at step  406 , the information about the validated cellular phone number of the user  104  is transmitted to the called user  108 . Preferably, this transmission occurs simultaneously with the request to initiate a call with the user  104 , whose validated identity element is shown. The communication between the users can thus be established, e.g. as described with reference to  FIG. 1 . 
     Alternatively, an embodiment may be conceived wherein the calling user  104  provides a fixed network number that cannot receive written messages. In such a case, the calling user  104  may be contacted by telephone and, for example, he/she may be given a password by means of a voice synthesis system, to be used as a validation element as previously described. 
     The embodiments described herein without any limitations whatsoever with reference to  FIGS. 3 and 4  may be combined with any technology that allows sending the validation element to the calling user, e.g.: telephone, videophone, fax, electronic mail, social network, etc., and possibly also receiving the validation acknowledgement. 
       FIG. 5  illustrates another more detailed embodiment of the communication management method. 
     At step  501 , a request is received from the calling user  104  to initiate a “Click-to-call” communication with the called user  108 , e.g. as described with reference to  FIG. 1 . 
     At step  502 , the calling user  104  is requested to provide a certified electronic identifier, e.g. by inserting a smart card into a suitable smart-card reader connected to the terminal  105 . Due to its very nature, one piece of information provided by the certified electronic identifier will be used as an “identity element” associated with the calling user  102 , in compliance with the privacy regulations in force. 
     In many countries, the use of official identity documents is rapidly increasing, which are associated with an electronic identifier of the smart-card type which allows access to many kinds of services. Therefore, it appears to be advantageous to be able to use the same identifier in order to gain access to “Click-to-call” services. 
     At step  504 , the electronic identifier of the calling user  104  is received and validated according to criteria dependent on the typology and encoding of the information contained in the electronic identifier. In this case, it can be assumed with even more certainty that the user  104  actually has at his/her disposal the identity element provided at step  502 . 
     Then, at step  504 , information about the validated identity element of the user  104  is transmitted to the called user  108 . Preferably, this transmission occurs simultaneously with the request to initiate a call with the user  104 , whose validated identity element is shown. The communication between the users can thus be established, e.g. as described with reference to  FIG. 1 . 
       FIG. 6  illustrates an embodiment of the communication management method which is particularly advantageous when the calling user  104  makes a plurality of successive “Click-to-call” requests. This case is especially relevant, for example, when there is a personal knowledge relationship (e.g. friendship) or a regular client relationship (e.g. provision of assistance services) between the users. 
     At step  601 , a request is received from the calling user  104  to initiate a “Click-to-call” communication with the called user  108 , e.g. as described with reference to  FIG. 1 . 
     At step  602 , information is searched for about an identity element already validated for the same calling user  104 . For example, the server  101  may send a request to the terminal  105  to verify the presence of “cookies” of the Internet browser which would prove that the identity element has been validated. 
     Preferably, the information pertaining to an already validated identity element is stored in both the server  101  and the terminal  105  of the calling user  104 . 
     Preferably, a cookie representative of said information is unique and cannot be predicted or synthesized by ill-intentioned users wanting to deceive the validation system. 
     Preferably, the information contained in the cookies is not algorithmically correlated with the calling user&#39;s identity. 
     In a preferred embodiment, the information stored in the terminal  105  of the calling user  104  must be compared, even automatically, with corresponding information stored in the server  101 . For this purpose, the server  101  comprises a table that matches callers&#39; identities with cookies assigned thereto. Likewise, the server  101  comprises means for generating cookies and associating them with callers&#39; identities. 
     If no stored information is available about a validated identity element, step  603  will be carried out, wherein the calling user  104  is asked to provide an identity element. 
     At step  604 , the identity element provided by the calling user  104  is validated, e.g. as previously described. 
     At step  605 , a piece of information relating to the currently validated identity element is stored, e.g. by saving it on the terminal  105 . This can be easily attained by setting a “cookie” on the Web browser used by the calling user  104 , i.e. by storing proprietary information in a dedicated “Click-to-call” application. 
     Then, at step  606 , the information about the validated identity element of the user  104  is transmitted to the called user  108 . Preferably, this transmission occurs simultaneously with the request to initiate a call with the user  104 , whose validated identity element is shown. The communication between the users can thus be established, e.g. as described with reference to  FIG. 1 . 
     If, on the contrary, stored information has been retrieved at step  602  about an identity element previously validated for the calling user  104 , the process will go directly to the above-described step  606  without needing to repeat the validation procedure, since the latter has already been carried out. 
     The embodiment described herein with reference to  FIG. 6  may make use of known techniques for storing access credentials associated with a user, e.g. by providing that the stored information about a previously validated identity element has a validity deadline, e.g. one month. A “public terminal” access mode is also conceivable, wherein no information is stored about the validated identity element, thus conditionally going back to the description referring to  FIG. 2 . In addition, the act of storing information relating to a previously validated identity element may confer validation on the identity element without limiting it to the called user  108 , thus identifying the calling user  104  also in front of all other users whom he/she may want to call. 
       FIG. 7  illustrates an embodiment of the communication management method which includes a final step  701 , e.g. following the steps  201 ,  202 ,  203  and  204  already described with reference to  FIG. 2 . 
     At step  701 , the user  108  is sent a signal which is representative of the fact that the user  104  wishes to establish a “Click-to-call” communication. This signalling takes place, for example, through an audible alert, such as the classic “ring”, or else through am audible/visual signal. 
     Preferably, this signalling is simultaneous with the already described step  204  or may even precede it. 
     Upon receiving this signal, the called user  108  may decide to accept the call, in which case the communication between the called user  108  and the calling user  104  will be established as requested by the latter and as already described, for example, with reference to  FIG. 1 . 
     As an alternative, upon receiving the signal the called user may reject the call, as already described, for example, with reference to  FIG. 1 . 
     The method for managing the communication between users according to the present invention is implemented through a management system which, of course, comprises one or more computers connected to one another by means of a computer network. In the example of  FIG. 1 , the management system comprises the server  101 , which is operationally connected to a plurality of terminals, e.g. the terminals  105  and  109 . 
     The server  101  and the terminals  105  and  109  comprise, in an operating memory associated therewith, programs or code portions adapted to implement the method of the present invention. 
     The method of the present invention may also be implemented through mere interaction between the terminals  105  and  109 , so long as at least one of them (preferably the called terminal) comprises, in an operating memory associated therewith, programs or code portions adapted to implement the method of the present invention. 
     A program or code portion executable on one or more computers and adapted to implement the communication management method of the present invention through a connection to a computer network may be contained in a memory residing in a computer, i.e. a “self-standing” memory such as a removable hard disk, a flash memory or an optical disk, or even residing in an Internet server, from which a user can download the program. 
     In general, it is conceivable to use other user validation techniques in combination with the teachings of the present invention, without however departing from the protection scope of the present invention as set out in the appended claims. 
     For example, validation of the calling user&#39;s identity element might be requested only after a predetermined time of “free” use of the “Click-to-call” service; this may be advantageous if the calling user is, for example, a private user, who scrupulously keeps the link in order to be called, without making it public. 
     In another embodiment, the called user can decide whether to use or not the method for validating the calling user&#39;s identity element by expressing a preference a priori, which will remain valid until the called user decides to change it. For example, some users may want to be called by any person, with no filter whatsoever; it is therefore advantageous to offer also this option to the called user. 
     Also, the validation of the calling user&#39;s identity element may be required only after a predetermined number of “Click-to-call” requests; this could be advantageous should the calling user be a fraudulent one, who is making many undesired calls to various call recipients.