Patent Application
20150085855
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.
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'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's identity.
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'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'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'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.
In the drawings referred to in the description, the same reference numerals designate the same or equivalent elements or actions.
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'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' 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.
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
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
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
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
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
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
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
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
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
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
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
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'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' identities with cookies assigned thereto. Likewise, the server 101 comprises means for generating cookies and associating them with callers' 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
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
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
As an alternative, upon receiving the signal the called user may reject the call, as already described, for example, with reference to
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
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'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'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'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.
| Number | Date | Country | Kind |
|---|---|---|---|
| TO2011A000858 | Sep 2011 | IT | national |
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/IB2012/055063 | 9/24/2012 | WO | 00 |
