Patent Application
20160294893
Embodiments described herein relate generally to organizing conversations containing various forms of communication in communication networks.
Communication systems that enable communication over a network, such as a Voice over Internet Protocol (VoIP) system, play an increasingly important role in lowering operating cost, especially for large companies with international locations. Instead of subscribing to individual telephone lines for each telephone device, a company is able to purchase or subscribe to a communication system that allows users to communicate internally amongst the employees over a network at a relatively low cost, while allowing users to share a manageable number of external telephone lines. Typically, a server controls voice-related forms of communication, such as, but not limited to, phone calls, video chats, voicemail, call history, and contacts between users in a network. Other forms of communication utilized by the company may be provided by other servers. For instance, instant messaging (IM) and conferencing (e.g., using a conferencing device) may each be provided by a separate server unrelated to the server that provides voice-related forms of communication. Due to the increasing importance of communication over a network, improved methods for such communication systems are constantly desired.
Embodiments described herein provide improved methods for communication systems in a network. Specifically, a plurality of communication fragments between a group of parties can be organized into one conversation. Organizing the communication fragments includes assigning a conversation tag to each communication fragment. The conversation tag may correspond to the group of parties that are having the conversation. Thus, a conversation between the group of parties can be organized based upon the conversation tag.
As an example, in accordance with an embodiment, a method for organizing communications between parties in a VoIP system includes monitoring, by a VoIP client application, a plurality of different forms of communication between a first party associated with the VoIP client application and other parties, the plurality of different forms of communication including at least two of voice communication, conference communications, and instant messaging communications, at least some of the plurality of different forms of communication provided by different communication servers. The method may include assigning, by the VoIP client application, a conversation tag to a communication fragment between the first party and one or more of the other parties, the communication fragment generated by a communication between the first party and the one or more of the other parties using at least one of the different forms of communication, the conversation tag corresponding to the first party and the one or more of the other parties. The method may include storing, by the VoIP client application, the conversation tag and the communication fragment in a memory. The method may further include forming, at the VoIP client application, a conversation history between the first party and the one or more of the other parties by identifying in the memory the communication fragment based on the associated conversation tag and at least one other communication fragment associated with the same conversation tag, wherein the communication fragment and the at least one other communication fragment are from communications between the first party and the one or more of the other parties. The method may further still include displaying, at the VoIP client application, the conversation history.
In an embodiment, the communication fragment is sent in a form of communication provided by a first communication server of the different communication servers, and the at least one other communication fragment is sent in a form of communication provided by at least a second server of the different communication servers, wherein the first and second servers are unable to directly communicate with each other. In another embodiment, the conversation tag includes at least one string. The VoIP client application may be run on an application server. In an embodiment, the communication fragment is a phone call, and the at least one other communication fragment is an instant message (IM). In an embodiment, the conversation history may include a list of all communication fragments corresponding to the first party and the one or more of the other parties. The list of all communication fragments may be arranged in chronological order. Each of the different communication servers may be unable to directly communication with others of the different communication servers.
In an embodiment, a method for organizing communications between parties in a VoIP system includes monitoring, by a VoIP client application, a plurality of different forms of communication between a first party associated with the VoIP client application and other parties, at least some of the plurality of different forms of communication provided by different communication servers. The method may include assigning, by the VoIP client application, a conversation tag to a communication fragment between the first party and one or more of the other parties, the conversation tag corresponding to the first party and the one or more of the other parties. The method may further include forming, at the VoIP client application, a conversation history between the first party and the one or more of the other parties by identifying in a memory the communication fragment based on the associated conversation tag and at least one other communication fragment associated with the same conversation tag.
In another embodiment the communication fragment may be generated by a communication between the first party and the one or more of the other parties using at least one of the different forms of communication. In an embodiment, the plurality of different forms of communication includes at least two of voice communications, conference communications, and instant messaging communications. The communication fragment may be sent in a form of communication provided by a first communication server of the different communication servers, and the at least one other communication fragment is sent in a form of communication provided by at least a second server of the different communication servers. In an alternative embodiment, the communication fragment and the at least one other communication fragment are from communications between the first party and the one or more other parties.
In an embodiment, a system for organizing communication between parties includes a plurality of different communication servers, and an application server containing software for a VoIP client application. The VoIP client application may be configured to monitor a plurality of different forms of communication between a first party associated with the VoIP client application and other parties, the plurality of different forms of communication provided by the plurality of different communication servers. The VoIP client application may also be configured to assign a conversation tag to a communication fragment between the first party and one or more of the other parties, the conversation tag corresponding to the first party and the one or more of the other parties. The VoIP client application may be further configured to form a conversation history between the first party and the one or more of the other parties by identifying in a memory the communication fragment based on the associated conversation tag and at least one other communication fragment associated with the same conversation tag.
In an embodiment, a computer-implemented system includes one or more processors, and a non-transitory computer-readable storage medium containing instructions configured to cause the one or more processors to perform operations including monitoring, by a VoIP client application, a plurality of different forms of communication between a first party associated with the VoIP client application and other parties, at least some of the plurality of different forms of communication provided by different communication servers. The non-transitory computer-readable storage medium may also contain instructions configured to assign, by the VoIP client application, a conversation tag to a communication fragment between the first party and one or more of the other parties, the conversation tag corresponding to the first party and the one or more of the other parties. The non-transitory computer-readable storage medium may further contain instructions configured to form, at the VoIP client application, a conversation history between the first party and the one or more of the other parties by identifying in a memory the communication fragment based on the associated conversation tag and at least one other communication fragment associated with the same conversation tag.
Numerous benefits are achieved using embodiments described herein over conventional techniques. For example, in some embodiments, a conversation composed of different forms of communication can be organized into one chronological conversation, regardless of whether or not backend servers that provide the forms of communication are able to communicate with one another. In such embodiments, the backend servers do not need to be reconfigured and/or upgraded to communicate with one another, thereby saving cost. Additionally, the conversation can be organized by a client application, which does not require the client server to have any knowledge of whether the backend servers are able to communicate with one another. In such embodiments, organization of conversations is substantially simplified. Depending on the embodiment, one or more of these benefits may exist. These and other benefits are described throughout the specification.
Embodiments described herein provide improved methods for organizing a conversation in a communication system. The communication system may include a plurality of different servers that each provide a different form of communication. The servers may include client servers as well as backend servers. In some embodiments, the backend servers are unable to communicate with each other, but the client server is able to communicate with each backened server. Thus, the client server can organize the conversation between the different backend servers by utilizing a conversation tag, as will be discussed further herein.
While the system illustrated in
In this example, the first site 102, the second site 134, and the third site 152 are each communicatively coupled via a network 120. The network 120 may be the Internet or another packet switched network over which the VoIP system operates.
The first site 102 includes several devices including a server 110, a conferencing device 112, a switch 114, a trunk 115, and an instant messaging (IM) server 113. The first site 102 also includes communication devices such as an Internet Protocol (IP) phone 104 and a soft phone 106. Also included within the first site 102 is a data storage device 108. Each of these devices may communicate with each other via the network 120 or via a local network.
The server 110 may be configured to provide some of the applications in the VoIP system. For example, the server 110 may be configured to provide applications such as auto attendant features, media on hold (MOH), voicemail services, and the like. The server 110 may also be configured to provide a client application that can organize a conversation in accordance with embodiments of the present invention. The server 110 may store data in local memory or in the data storage 108.
In an embodiment, the server 110 may be linked directly to the data storage 108 as shown in
The conferencing device 112 may be configured to link participants (e.g., users of IP phones 104, 132, 150; soft phones 106, 130, 148; and/or other endpoints) in a conference call and enable the sharing of resources between the participants. A conferencing device may also provide conferencing services such as recording and reporting functions. A conferencing device typically includes a number of ports each configured to provide one or more resources (e.g., audio, video, web and/or the like) to a conference participant. The number of participants that can join a conference call is typically limited by the number and configuration of the ports on the conferencing device hosting the conference combined with other hardware and software limitations (e.g., CPU resources, available memory, and the like).
The switch 114 may be a telephone switch that communicates with the IP phone 104 and the soft phone 106 to establish communications channels that are used to make and receive calls. As used herein, the term “calls” refers broadly to any type of communications (e.g., phone calls, conference calls, video calls, text messaging, or other communications). The switch 114 may manage call setup and resource allocation by provisioning extensions for the IP phone 104 and the soft phone 106. In the example illustrated in
The IM server 113 may be a server that provides instant messaging services to users of the first site 102. Although
Other communication devices that are used to make or receive calls may also be included within the VoIP system and within each site. For example, although not shown in this example, a VoIP system may include analog or digital phones, button boxes, “virtual phones” (e.g. extensions that are not assigned to a specific device), and other communication devices. Both fixed and mobile devices may be part of the VoIP system. Moreover, such devices may be part of the VoIP system temporarily or on a more permanent basis. For example, a desktop phone at an enterprise may be a more permanent part of a VoIP system. Alternatively, a mobile device may be part of a VoIP system on a more transient basis, such as when the mobile device is at a particular location and/or during a certain period of time. Additionally, a user may use a call manager program to make, receive, and manage calls within the VoIP system. Such a program may run on a user's phone or on a separate communication device.
The trunk 115 may be an analog, digital, or IP trunk (e.g., a session initiation protocol (SIP) trunk). In the illustrated configuration, the trunk 115 provides an interface between the VoIP system and the public switched telephone network (PSTN) 116. The trunk 115 facilitates inbound and outbound calls between endpoints within the VoIP system (e.g., IP phones 104, 132, 150 and softphones 106, 130, 148) and endpoints accessible via the PSTN 116 (e.g., external phone 118) or via other telephony systems.
The server 110, conferencing device 112, switch 114, trunk 115, and IM server 113 typically include familiar software and hardware components. For example, they may include operating systems, processors, local memory for storage, I/O devices, and system buses interconnecting the hardware components. RAM and disk drives are examples of local memory for storage of data and computer programs. Other types of local memory include magnetic storage media, optical storage media, flash memory, networked storage devices, and the like.
In some embodiments, the server 110 may include more than one server (e.g. a server cluster). Also, in some embodiments the server 110 may be configured to implement some or all of the features that are normally provided by the conferencing device 112, the switch 114, the trunk 115, and/or the IM server 113. Alternatively, the switch 114 may be configured to implement some or all of the features that are normally provided by the server 110, the conferencing device 112, the trunk 115, and/or the IM server 113.
In the VoIP system illustrated in
In a similar manner, the third site 152 includes several devices including a server 144, a conferencing device 142, a switch 140, and an IM server 143. The third site 152 also includes communication devices such as an IP phone 150 and a soft phone 148. Also included within the third site 152 is a data storage device 146. Similar to the devices within the other sites, each of the devices within the third site 152 may communicate with each other via the network 120 or via a local network. Each of the devices within the third site 152 may be configured in a manner similar to the corresponding devices within the first site 102 described above.
In accordance with some embodiments, virtual machines may be used to replace devices in systems such as the VoIP system illustrated in
This figure provides another example of a system in which some of the embodiments described herein may be implemented. The communications system includes a first site 202 and a second site 232. The first site 202 includes an IP phone 204, a soft phone 206, and a switch 212. The second site includes an IP phone 234, a soft phone 236, a switch 242, and a trunk 248. The trunk 248 facilitates inbound and outbound calls between endpoints within the communications system and endpoints outside the communications system (e.g., external phone 252).
In this example, neither of the sites include a conferencing device or an IM server. Instead, a conferencing device 266 and an IM server 267 are provided in the cloud 262. The cloud also includes a server 270 and data storage 268. These devices may be configured to provide applications and/or services to the devices at both the first site 202 and the second site 232.
Some embodiments described herein relate to a conversation between multiple parties containing more than one form of communication provided by different servers.
In an embodiment, each back-end server may provide communication services to one or more devices. For instance, a voice server 306, such as an Internet Protocol Private Branch Exchange (IP PBX) server, may provide voice service, such as, but not limited to, phone calls, voicemail, video chat, call history, and contact list management, for an IP phone 312 and/or a soft phone 314. An IM server 308 may provide instant messaging service to an IM device 316, which may be any suitable device capable of allowing a user to input a message. An exemplary IM device may be a smartphone, a computer, or a tablet. Additionally, a conference server 310 may provide conferencing services to a conferencing device 318.
In embodiments, the servers 306, 308, and 310 may or may not be able to communicate with one another. If the servers are unable to communicate with one another, the voice server 306 may not know whether the IM server is providing IM services to the IM device 316, or whether the conference server 310 is providing conferencing services to the conferencing device 318. It may therefore be difficult to consolidate a conversation containing multiple forms of communication that utilize multiple backend servers. According to an embodiment of the present invention, a client server, such as server 110 in
Additionally, the client application 304 may be communicatively coupled to the devices in the network. For instance, the client application 304 may be coupled to the IP phone 312, soft phone 314, IM device 316, and conferencing device 318. Thus, the client application 304 may be aware of operations of the devices 312, 314, 316, 318 as well as the servers 306, 308, and 310. Accordingly, the client may be able to organize conversations made in the VoIP system.
Briefly referencing another embodiment depicted in
With reference back to
To organize the conversation between party A and party B, the conversation may be divided into a plurality of communication fragments. A communication fragment may be a single instance in a conversation between party A and party B. As an example, a communication fragment may be a single IM message from party A to party B, or a single, uninterrupted phone call between party A and party B. Additionally, a communication fragment may be a historical phone call, a voice message, a file, a data conference, or a contact card. Although the phone call 408 and the IM 410 may be provided by different servers that are unable to communicate with one another, the client application may still be able to monitor each communication fragment as they are sent in real time because of the communication means 320 established between the servers and the client application, as illustrated in
According to embodiments of the present invention, a conversation tag is utilized by the client application to organize a conversation between parties, such as party A and party B. The conversation tag may uniquely identify a set of conversation participants. For instance, a unique conversation tag may identify a conversation between only party A and party B (see
In embodiments, the conversation tag may be a string that includes a variety of information to identify a party in a conversation. If the client application operates with JavaScript, for example, the conversation tag may have the following JavaScript Object Notation (JSON) structure:
where id1, id2, id3, . . . are identifiers from an information source or database, such as, but not limited to, a Client Application Server (CAS) Contact Search and a Buddies Application Programming Interface (API), and addr1, addr2, addr3, . . . are canonical phone numbers or canonical IM addresses.
Referring back to the conversation between party A and party B of
where the identifier only identifies party B because party A, the user of the client application, is having a conversation with only party B. In this embodiment, party B is identified as “B” instead of a canonical phone number because party B is part of the communication network with party A. In other words, party A and party B are part of the same VoIP system, e.g., network 120 of
With reference to the conversation between party A, party B, and party C of
where the identifier only identifies party B and party C because party A, the user of the client application, is having a conversation with party B and party C. In this embodiment, party C is not part of the same VoIP system as party A and party B. Thus, party C is identified by a canonical phone number.
It is to be appreciated that the conversation tag may be specific to the parties involved in the conversation irrespective of time elapsed between conversations or forms of communication used during the conversation. For instance, a conversation made between party A and party B may still be considered to be part of the same conversation of a subsequent conversation between party A and party B made several months later. Thus, communication fragments generated in both conversations may be assigned the same conversation tag. Further, a phone call made between party A and party B utilizing only a voice server may still be considered to be part of the same conversation of an IM and phone conversation between party A and party B utilizing a voice server and an IM server.
According to embodiments of the present invention, the conversation tags may be used to organize a conversation. For instance, a client application may gather all the communication fragments assigned with the same conversation tag and display it for a user.
At step 504, the client application may assign a conversation tag to a communication fragment between the first party and the one or more other parties. The conversation tag may correspond to the particular parties involved in the communication as discussed herein with respect to
At step 508, the client application may form a conversation history between the first party and the one or more other parties by identifying in the memory the communication fragment based on the associated conversation tag and at least one other communication fragment associated with the same conversation tag. The client application may search the memory for communication fragments that are assigned the same conversation tag. Such communication fragments may then be organized together in a logical format, such as in chronological order. The organized communication fragments may form the conversation history.
At step 510, the client application may display the conversation history to a user. For instance, the client application may display the IM messages and/or the phone calls on a computer screen. The user may be advantageously informed of the history of his or her conversation with the other parties through all forms of communication.
It should be appreciated that the specific steps illustrated in
In the exemplary embodiment illustrated in
It should be appreciated that some embodiments may be implemented by hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof. When implemented in software, firmware, middleware, or microcode, the program code or code segments to perform the necessary tasks may be stored in a computer-readable medium such as a storage medium. Processors may be adapted to perform the necessary tasks. The term “computer-readable medium” includes, but is not limited to, portable or fixed storage devices, optical storage devices, wireless channels, sim cards, other smart cards, and various other non-transitory mediums capable of storing, containing, or carrying instructions or data.
While the present invention has been described in terms of specific embodiments, it should be apparent to those skilled in the art that the scope of the present invention is not limited to the embodiments described herein. For example, features of one or more embodiments of the invention may be combined with one or more features of other embodiments without departing from the scope of the invention. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. Thus, the scope of the present invention should be determined not with reference to the above description, but should be determined with reference to the appended claims along with their full scope of equivalents.
