System and method for presenting chat QoS indication to user

FIELD OF THE INVENTION

The present invention relates generally to chat systems.

BACKGROUND OF THE INVENTION

Various communication systems that use computer networks have appeared in recent years due to the expansion of the Internet. One of these is known as chat systems, operating using multi-user and real-time communication. These chat systems have become a convenient and efficient means of communication through the internet, providing alternatives to electronic mail and telephone services. In essence, “chat” can be thought of as “live email.” In other words, chat is a form of online messaging, an exchange of remarks, through a server or system that uses the internet.

A computer system communicating through a network via a server computer, running a software program enabling a user to chat with another computer user on the same network, may be referred to as a “chat client.” Users create a chat network, what is commonly referred to as a virtual space, by chatting through chat clients and the matching servers. In doing so, chat users establish a chat medium, or so-called channel, through which chat clients converse in real time via the common server. Therefore, a “chat system” is a communication system marked by chat client users that share a number of these virtual spaces.

As recognized by the present invention, there is no way to monitor or display the current real time quality of service (QoS) available in the chat system. The present invention understands that this real time quality of service is an important indicator of the general chat reliability of a chat client user and its messaging capabilities, as well as its file sharing capabilities, because information regarding the quality of service can be acted upon once it is determined that another user's connection is unreliable. As set forth further below, chat client users can change their connection type (i.e. wireless to wired) or defer chatting/file transferring until such time when the connection is deemed sufficiently reliable.

SUMMARY OF THE INVENTION

A computer-implemented method includes establishing a communication link between first and second chat client computers to facilitate a chat session between the computers. An indication representing a real time quality of service (QoS) metric relating to the communication link is displayed at one or both clients.

In non-limiting embodiments the metric can be an aggregated QoS metric, or it can be link availability, data throughput, link error rate, or link latency. One of the chat clients can send a QoS test signal to another chat client to facilitate obtaining real time QoS information pertaining to the link. Alternatively, a chat server can ping chat clients to facilitate obtaining real time QoS information pertaining to the link. The information can be displayed using icons and/or alpha-numeric characters.

In another aspect, a service includes gathering, in real time, quality of service (QoS) information pertaining to a communication link having as one node a first chat client. The service also includes providing the QoS information to first chat client and/or to a Web server associated with the first chat client.

In another aspect, a computer system includes a chat client computer that receives real time quality of service (QoS) information relating to a chat link used by the chat client computer. An output device communicates with the chat client computer for displaying the QoS information.

The details of the present invention, both as to its structure and operation, can best be understood in reference to the accompanying drawings, in which like reference numerals refer to like parts, and in which:

BRIEF DESCRIPTION OF THE DRAWINGS

<figref idref="DRAWINGS">FIG. 1</figref> is a block diagram of a system for undertaking the present invention;

<figref idref="DRAWINGS">FIG. 2</figref> is a flow chart of the logic for gathering real-time quality of service (QoS) information;

<figref idref="DRAWINGS">FIG. 3</figref> is a flow chart of alternate logic for gathering real-time quality of service (QoS) information;

<figref idref="DRAWINGS">FIG. 4</figref> is a flow chart of logic for presenting QoS information; and

<figref idref="DRAWINGS">FIG. 5</figref> is a schematic diagram of an exemplary non-limiting user display of QoS information.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

Referring initially to <figref idref="DRAWINGS">FIG. 1</figref>, a system is shown, generally designated <b>10</b>, that includes a first chat client computer <b>12</b> having one or more processors <b>14</b> receiving user input from an input device <b>16</b>, such as but not limited to one or more of a keyboard, mouse, keypad, voice recognition device, etc. The chat client computer <b>12</b> also has an output device <b>18</b> such as but not limited to one or more of a computer monitor, audio speaker, printer, computer, or computer network.

The first chat client computer <b>12</b> may communicate with a server <b>20</b> over a communication path <b>22</b> such as the Internet. In the embodiment shown, the server <b>20</b> is a chat server that includes one or more processors <b>24</b>. In turn, the chat server <b>20</b> can communicate with a second chat client computer <b>26</b> that has a processor <b>28</b>, input device <b>30</b>, and output device <b>32</b>.

It is to be understood that while only two chat client computers are shown, more client computers and more chat servers may be implemented in the present invention. The computers shown herein may be any suitable computers, e.g., personal computers, server computers, laptop computers, etc. It is to be further understood that at least portions of the inventive logic divulged herein may be executed by one or more of the processors shown in <figref idref="DRAWINGS">FIG. 1</figref>. Thus, the invention may be embodied as a computer-implemented method, a general purpose computer programmed to undertake the method, and a computer program product (i.e., an article of manufacture) such as a computer storage device that holds computer code such as but not limited to C++ or Java that embodies the present logic. The chat client computers <b>12</b>, <b>26</b> may communicate with each other through the chat server <b>20</b> or may communicate directly with each other.

Now referring to <figref idref="DRAWINGS">FIG. 2</figref>, commencing at block <b>34</b> a DO loop can be entered when, for instance, the chat server <b>20</b> “pings” a user for status, i.e., when the chat server determines, by means of, e.g., status request messages, what the status is of the chat client. Proceeding to block <b>36</b>, the information on the QoS of the server-client link is gathered at the chat server. This is done for each client. Then, when two clients are chatting, the chat server adds the metrics of each link to obtain the total QoS to present as discussed further below in reference to <figref idref="DRAWINGS">FIG. 4</figref>. The gathered QoS information may include link availability (e.g., “available” or “not available”), link data throughput in bits or bytes per second, link error rate in terms of number of errors per unit data or unit time, and link latency in term of average or peak time periods to convey a message or unit of data over the link.

<figref idref="DRAWINGS">FIG. 3</figref> shows an alternate method than that displayed in <figref idref="DRAWINGS">FIG. 2</figref>. The alternate method includes gathering QoS information for the entire path between one chat client to another. In essence, an end-to-end QoS is obtained by either client, at sign on and/or periodically thereafter. Block <b>38</b> shows the initiation of the process, wherein a DO loop can be entered periodically, causing the logic to flow to block <b>40</b>. At block <b>40</b>, the first chat client initiates a QoS test signal with the second chat client. Then, at block <b>42</b>, the QoS information is gathered by the first chat client computer for the entire link between the clients, including the link between the initiating client and one or more intermediate servers. Through this method, information about the direct connection between two chat clients is gathered, as opposed to gathering QoS information at the chat server itself.

If desired, one or more chat servers that form the link between chat clients can maintain the QoS information, either by generating it themselves as shown in <figref idref="DRAWINGS">FIG. 2</figref> or by requesting it or intercepting it as chat clients generate the information in accordance with <figref idref="DRAWINGS">FIG. 3</figref>. In any case, the QoS information may be used by a server or servers to optimize message routing between clients. For instance, a chat server might notice that the QoS between that chat server and a first relay server is poor for two particular clients, whereas the QoS between the chat server and a second relay server is good, in which case the chat server will relay chat messages between the clients using the second relay server.

Moving to <figref idref="DRAWINGS">FIG. 4</figref>, the logic for presenting QoS information that has been gathered through the methods prescribed in either <figref idref="DRAWINGS">FIG. 2</figref> or <figref idref="DRAWINGS">FIG. 3</figref> is shown. At block <b>44</b>, a specific weight for each QoS metric can be given, if desired. An example would be to give QoS factor 1 a weight of 2, but QoS factors 2-4 may be given a weight of 4 if they are held as more significant by the chat server or chat client. Block <b>46</b> shows how, after all the weighted factors are added together, the sum of the weighted factors may be divided by 4 (the total amount of factors, not their individual weights) to achieve an aggregated QoS measurement. This aggregated measurement can be presented quantitatively as a number, or it can be correlated to a qualitative value such as “good,” “fair,” or “poor.” This qualitative description can be displayed to the chat client user. However, the data collected does not have to be aggregated into one QoS measurement, but the data may also be broken down into categories 1-4 above and displayed individually.

After the QoS measurement is generated, block <b>48</b> shows the user receiving a display of each QoS metric and/or aggregated QoS (quantitatively or qualitatively). If desired, at block <b>50</b> a chat client may automatically establish chat parameters based on the QoS. For instance, the chat client might automatically switch the chat link to another channel, e.g., it might switch from a wireless link to a wired link. As another example, the chat client might prohibit the transmission of certain documents or messages until link QoS is above a threshold.

It is to be understood that this QoS data display can initially occur at chat start, or it can occur some time thereafter. In a “push” the chat server notices the chat clients are chatting and sends the QoS information immediately to the two chat client users. In a “pull” a chat client computer, once it establishes a connection with another chat client computer, does one of two things. It either asks the server for QoS information if the method in <figref idref="DRAWINGS">FIG. 2</figref> is being implemented, or it initiates its own QoS test signal through the process shown in <figref idref="DRAWINGS">FIG. 3</figref>. In either case, the QoS information is presented to the user and potentially acted upon automatically by the user's client computer as discussed above.

Referring to <figref idref="DRAWINGS">FIG. 5</figref>, a schematic diagram of an exemplary user display <b>52</b> of QoS information, including sample icons, is shown. <figref idref="DRAWINGS">FIG. 5</figref> shows a list <b>54</b> of chat partners for a given chat client and the corresponding QoS ratings <b>56</b> for the overall link between the chat client viewing the display and a chat partner. Each of these corresponding QoS ratings can be shown with matching icons <b>58</b>.

In addition to or in lieu of the end-to-end ratings <b>56</b>, as shown by the QoS indication column <b>60</b> in <figref idref="DRAWINGS">FIG. 5</figref> the QoS information displayed to a chat client may include an indication of the real-time QoS between the client and the chat server. In this way, the user can determine whether a QoS problem, if any, is system-wide or is caused simply by the connection between the user's computer and the user's chat server. For example, as shown in <figref idref="DRAWINGS">FIG. 5</figref> the QoS between the chat client and its server is high, but for partner “Mark” the end-to-end QoS is medium and for partner “Stephen” the end-to-end QoS is low, indicating to the user that the QoS difficulties at least do not arise because of the link between the user's computer and the chat server.

It is to be understood that the monitoring and communicating of QoS data on display may be enabled/disabled for privacy by each client. When enabled, the information regarding the QoS data shown gathered in the process in <figref idref="DRAWINGS">FIG. 4</figref>, through the sample display shown in <figref idref="DRAWINGS">FIG. 5</figref>, would be displayed on an output device such as the output device <b>18</b> shown in <figref idref="DRAWINGS">FIG. 1</figref>.

The invention above can be provided as a service. For instance, the QoS information can be gathered by a service provider server, e.g., the server <b>20</b> shown in <figref idref="DRAWINGS">FIG. 1</figref>, and then provided, free or for a cost, to the chat client computers so that link QoS information is displayed for the users of the chat client computers.

While the particular SYSTEM AND METHOD FOR PRESENTING CHAT QoS INDICATION TO USER as herein shown and described in detail is fully capable of attaining the above-described objects of the invention, it is to be understood that it is the presently preferred embodiment of the present invention and is thus representative of the subject matter which is broadly contemplated by the present invention, that the scope of the present invention fully encompasses other embodiments which may become obvious to those skilled in the art, and that the scope of the present invention is accordingly to be limited by nothing other than the appended claims, in which reference to an element in the singular is not intended to mean “one and only one” unless explicitly so stated, but rather “one or more”. It is not necessary for a device or method to address each and every problem sought to be solved by the present invention, for it to be encompassed by the present claims. Furthermore, no element, component, or method step in the present disclosure is intended to be dedicated to the public regardless of whether the element, component, or method step is explicitly recited in the claims. Absent express definitions herein, claim terms are to be given all ordinary and accustomed meanings that are not irreconcilable with the present specification and file history.