Source: https://patents.google.com/patent/US20090279533A1/en
Timestamp: 2019-07-16 00:27:21
Document Index: 88165843

Matched Legal Cases: ['arty 106', 'arty 106', 'arty 106', 'arty 106', 'arty 106', 'arty 106', 'arty 106', 'arty 106', 'arty 106']

US20090279533A1 - Extensible and secure transmission of multiple conversation contexts - Google Patents
Extensible and secure transmission of multiple conversation contexts Download PDF
US20090279533A1
US20090279533A1 US12/117,727 US11772708A US2009279533A1 US 20090279533 A1 US20090279533 A1 US 20090279533A1 US 11772708 A US11772708 A US 11772708A US 2009279533 A1 US2009279533 A1 US 2009279533A1
US12/117,727
US8718042B2 (en
Pradipta K. Basu
2008-05-08 Priority to US12/117,727 priority Critical patent/US8718042B2/en
2008-07-24 Assigned to MICROSOFT CORPORATION reassignment MICROSOFT CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: ANANTHARAMAN, SUNDAR, RAMANATHAN, RAJESH, VYAGHRAPURI, RAMESH, AWAN, AATIF, BASU, PRADIPTA K, KOPPOLU, LOKESH SRINIVAS, SRINIVASAN, SRIVATSA, STREBEL, ANDREAS, TANDON, ANKIT
2009-11-12 Publication of US20090279533A1 publication Critical patent/US20090279533A1/en
2014-05-06 Publication of US8718042B2 publication Critical patent/US8718042B2/en
The entry and transmission of notes to recipients along the conversation chain. Notes can be created based on an incoming caller. The notes can be transmitted to the conversation recipient for viewing before, during, and after the recipient accepts the conversation. This is facilitated by a communications client that operates to allow entry of the notes, and forwarding of the call recipient via a SIP framework. Moreover, notes previously taken and/or information provided manually and/or automatically by the communications system can be provided to an agent (e.g., ACD, receptionist) receiving the conversation, at any point in the conversation chain for quick identification not only of the conversation source but of previous information already collected.
Call communications systems such as automated call transfer systems, as well as live call assistants continue to lack efficient means for sending notes and other information along with a call transfer. Consider the scenario where a receptionist uses a communications client to handle a conversation with a caller. The receptionist may want to take brief notes regarding this call and then transfer the call to a different person, the intended recipient, or consult another person before transferring the call.
Consider another scenario where a user receives a call through an automatic call distributor (ACD) infrastructure via the user communications client. The ACD infrastructure can be configured to provide additional information about the caller (such as the language preference chosen by the caller or other menu options that the caller may already have navigated through).
In these and other scenarios, the additional notes and information, which could be beneficial to one or all parties, are typically dropped or not passed on because of cumbersome mechanisms.
The disclosed architecture facilitates a mechanism that provides multiple “call contexts” in multiple formats to the recipient of a communications exchange (e.g., voice call, conversation, text exchange via instant messaging, etc.) with detailed information about the contexts (e.g., when the context was created, who created the context, etc.) and provide this securely, if desired. In addition, the contexts can be transferred to other calls.
In an IP-based call infrastructure, a source of the call contexts (e.g., a receptionist or an ACD server) can provide the call context as a multipart/mixed MIME (multipurpose Internet mail extensions) message or secure-MIME (S-MIME) as part of a SIP (session initiation protocol) implementation. S-MIME can be employed for non-repudiation or encryption. For example, INVITE, REFER and/or INFO messages instruction with one MIME part (a document in MIME format) dedicated to the traditional SDP (session description protocol) payload and other parts dedicated to other call-contexts (with each call context itself using multipart/alternative to deal with multiple sub parts). For security and privacy, an IRM (information rights management) model can be layered on top, if desired.
The architecture facilitates the accumulation and transmission of notes along the call chain. For example, if the original caller had been previously transferred with notes, notes that came with the original call as well as the notes taken by the receptionist can be sent, individually or as a set. Moreover, notes previously taken and/or information provided manually and/or automatically by the system can be provided to the agent receiving the call, at any point in the call chain for quick identification not only of the caller but of previous information already collected.
The architecture also handles metadata associated with each context that provides content description about the context. A mechanism is provided to notify a user that there is additional information about the call that can be accessed and viewed. Additionally, a mechanism is provided for dealing with clients that do not support sending or receiving contexts (published via presence, as well as via SIP headers and error notifications).
FIG. 1 illustrates a computer-implemented information sharing system for sharing context.
FIG. 2 illustrates a more detailed exemplary system for sharing call context in a telephone system.
FIG. 3 illustrates a more detailed system for sharing notes between communications clients.
FIG. 4 illustrates an example call-flow diagram for a blind transfer with call context.
FIG. 5 illustrates an example call-flow diagram where the transfer target cannot accept notes.
FIG. 6 illustrates an example call-flow diagram where the transfer of notes includes a consultation by audio.
FIG. 7 illustrates an example call-flow diagram where the transfer occurs with consultative context.
FIG. 8 illustrates a computer-implemented method of sharing call information.
FIG. 9 illustrates a method of sending call information using MIME.
FIG. 10 illustrates a method of sending call information using optional techniques.
FIG. 11 illustrates a block diagram of a computing system operable to execute call context sharing in accordance with the disclosed architecture.
FIG. 12 illustrates a schematic block diagram of an exemplary computing environment that supports call context sharing.
The disclosed architecture facilitates the accumulation and transmission of notes along a conversation chain. The conversation chain is intended to include any means of communication between two or more entities (e.g., users, systems) such as voice calls, text exchange, multimedia exchange, video, and so on. For example, if an original caller had been previously transferred with notes, notes that followed the original caller as well as the notes taken by the receptionist can be sent, individually or as a set. Moreover, notes previously taken and/or information provided manually and/or automatically by the system can be provided to an agent receiving the call, at any point in the call chain for quick identification not only of the caller but of previous information already collected.
FIG. 1 illustrates a computer-implemented information sharing system 100 for sharing context. Note that although described in a voice communications environment, it is to be understood that other communications systems can be employed to benefit from the sharing of context, such as instant messaging, for example. The system 100 can include voice communications system 102 (e.g., a telephone system) for enabling voice communications between a call source 104 and a call party 106. A context component 108 is provided to allow the call source 104 (e.g., a receptionist, software agent, ACD (automated call distributor), etc.) for electronically recording and storing context 110 (e.g., conversation, call, etc.) in association with communications of the voice communications system 102. A transfer component 112 allows the context 110 then to be transferred to call party 106 of the voice communication. The context 110 can include notes entered by a receptionist when answering the call for the call party 106, links (e.g., hyperlinks), and/or multimedia content (e.g., audio file attachments, video files, text documents, etc.).
The transfer component 112 makes the context 110 accessible to the call party 106 before entering the voice communication (e.g., phone call), during the voice communication session, and/or after the voice communication session is over. Moreover, the context can be transferred to other voice communication sessions, as well.
In one implementation, the system 100 is employed in an IP-based communications system (e.g., voice) such that a conversation occurs over an IP network. For example, in a SIP (session initiation protocol)-based call infrastructure, a receptionist or an ACD server can provide the call context as a multipart/mixed MIME (multipurpose Internet mail extensions) message or secure-MIME (S-MIME) as part of the SIP implementation. S-MIME can be employed for non-repudiation or encryption. as part of the SIP implementation. SIP messages such as INVITE, REFER and/or INFO can be employed to transmit the context. The multipart/mixed MIME message can include one MIMEpart (a document in MIME format) dedicated to an SDP (session description protocol) payload and other parts dedicated to other call-contexts (with each call context itself using multipart/alternative to deal with multiple sub parts). For security and privacy, an IRM (information rights management) model can be layered on top, if desired. Additionally, privacy, integrity, and non-repudiation can be obtained using PKI (public key infrastructure), as well as S-MIME.
In one example, the architecture can be extended to a shared line appearance scenario. Here, the supervisor has a private key (e.g., PKI key) that can be sent to the administrator so that the administrator can open the encrypted incoming context.
Alternatively, context can be transmitted using out-of-band REFER. For example, User A is in a call with User B, and User A wants to transfer the call to User C. User A sends a REFER message to User C directly with the context. User C then sends an INVITE with replaces to User B.
The system 100 can provide multiple call contexts in similarly multiple formats to a recipient of a call with detailed information about the contexts. The contexts can be transferred to other calls, as well.
Conversation history can be stored as an email in the email system (e.g., email server). Notes associated with the conversation (and also in case of missed calls) can also be stored in the history. A conversation can be started at anytime by using this missed call or conversation history item. In that case, the notes associated with the history email can then be automatically associated with the call and processed for forwarding as described herein.
The context 110 can also be transmitted by way of a presence document. For example, User A is in a call with User B. User A wants to transfer to User C. User A then publishes context in a presence document that is visible only to User C. User C receives the transferred call from User B, and User C notices that User A transferred the context. User C then pulls the presence document of User A to get any context that User A may have published.
FIG. 2 illustrates a more detailed exemplary system 200 for sharing call context in a telephone system. The system 200 includes the voice communications system 102 for connecting a call between the call source 104 and the call party 106, the context component 108 for creating electronically recording and storing notes as part of a call (conversation) context 110 in association with a conversation (e.g., phone call, text message) of an IP communications (e.g., telephone) system (e.g., IP-based call infrastructure), and the transfer component 112 for transferring the notes to the call party 106 via the telephone system. The call (conversation) context 110 can be transmitted using an encryption technology and as a multipart/mixed MIME message according to SIP messages that include at least one of INVITE, REFER or INFO.
The system 200 can also employ a description component 202 for generating a content description for content of the call context 110. For example, the content can include identification information (e.g., name, source ID) of the calling source 104. The transfer component 112 can then transfer one or both of the notes and content description to the call party 106 of the phone call via the telephone system. Alternatively, the transfer component 112 can transfer the context to the party via a presence document. The content description can be metadata associated with each context that provides a content description about the context.
The system 200 can comprise a notification component 204 for notifying the call party 106 of the presence of the context and/or content description via the voice communication system. Client support for sending, receiving context or transfer failures is conveyed (published) via a presence system as well as SIP headers and error notifications. Once notified, the call party 106 can access and view the context 110. The system 200 can further include a versioning component 206 for managing versions of the context 110 as generated and transmitted.
FIG. 3 illustrates a more detailed system 300 for sharing notes between communications clients. Here, a first communications client 302 is illustrated with a first user interface (UI) 304 for user interaction with one or more functionalities described herein. The user (a receptionist) can interact via the first UI 304 to view and/or create notes based on one or more phone communications sessions. For example, the first UI 304 can present a first conversation window 306 via which a first set of notes 308 can be entered and/or viewed. Additionally, the first UI 304 can present a second conversation window 310 via which a second set of notes 312 can be entered and/or viewed. It is to be understood that other windows 314 for other sessions can be open or reduced as the user desires.
In a typical implementation, the first communications client 302 can be for a receptionist computing system of a receptionist who receives the incoming call, interacts with the calling party, enters the first notes 308 about the calling party, and then forwards the first notes 308 to another entity (e.g., another communications client of the called party).
The first communications client 302 can also include conversation models 316 that support the associated conversation windows. For example, a first conversation model 318 interfaces to the first conversation window 306 for the storage of the first notes 308. Similarly, a second conversation model 320 interfaces to the second conversation window 310 for the storage of the second notes 312.
The first communications client 302 also provides the capability to support the different media sessions 322. For example, a first instant messaging (IM) media session 324 is utilized to transmit the notes 308 to another client via an IM message, and a first audio media session 326 can utilized to transmit the notes 312 to another client via audio signals. In support thereof, the first communications client 302 includes communications session stacks 328 (e.g., SIP) for transmitting the notes to other clients using the particular mode of communications (e.g., IM, audio, etc.). For example, the first notes 308 can be sent to another client (e.g., of the called party) via the first IM media session 324 and an associated first IM media communications session stack 330, and the second notes 312 can be sent to another client (e.g., of the called party) via the first audio media session 326 and an associated first audio media communications session stack 332.
The above description describes sending the first notes 308 and the second notes 312 to the same called party client. This is because it can be a common scenario where the called party will be on a call with a first calling party, and the receptionist will answer a second incoming call for the same called party, the incoming call from a second calling party. Thus, rather than interrupt the called party, the receptionist can now simply create notes to send to the called party such the called party can review the notes without interruption to the current call session, and then decide to terminate the existing call or remain on the line with the existing call.
As illustrated, the notes 308 are transmitted from the first communications client 302 via the first IM session 324 to a second client 334 through a second IM session stack 336 through an associated second IM media session 338 to the conversation model 338 for storage. The notes 308 can be sent via SIP using an INVITE, INFO, and/or REFER messages, for example. The called party then receives notification of the notes 308 available for review, and can then view the notes 308 via a second UI 342 of the second client 334.
It is further possible that the called party of the second communications client 334 chooses to forward the second calling party to a colleague to take the call. Thus, the calling party can change and/or add to the existing set of notes 308, and send the notes 308 to a third communications client (not shown) of the colleague using the IM stack 336. The colleague can then read the notes and pick up the call. In this case, the updated notes 308 or unedited notes can be sent in a SIP REFER message copied to an outgoing SIP INVITE message to the transfer-target (the colleague).
Following are example call flow diagrams, three of which illustrate common scenarios and a fourth call flow diagram illustrating the mechanisms.
FIG. 4 illustrates an example call-flow diagram 400 for a blind transfer with call context. Shown is a basic case of Mindy talking with Paul and taking notes. Mindy decides to transfer Paul to Marco. Marco sees an incoming call from Paul. In the toast (a small informational window), Marco sees the notes that Mindy had entered earlier. Marco then accepts the call and views Mindy's notes in the conversation window.
The first part at the top of the diagram 400 is generally an accept pattern. This is used to identify legacy clients. Once the legacy clients are distinguished, the call flow shows a success pattern. The call client (Paul's client) indicates “yes” or “no” for supporting transfer of context. This information is useful in that Mindy's client then understands whether notes can be included or not. Here, notes can be included, and Mindy will be presented with a check box in the UI to indicate as such.
Consider an example where Paul has a computer problem and Mindy takes some notes about the problem and asks Paul some basic questions such as “Is your computer running?”, “Do you have a blank screen?”, “What are the symptoms?, etc., and enters notes about each query. This is illustrates with the notes block 402.
Next, Mindy puts Paul on hold and seeks out Marco to service the call and computer problems. Mindy checks a box in the client UI to include the notes before issuing the transfer to Marco.
The call is then transferred (TRANSFER) to take Mindy out of the connection and provides a direct connection between Paul and Marco. Following the transfer, Mindy's client sends a REFER with the notes in the REFER body taken as the MIMEpart. The information passed includes conversation context plus additional properties such as the selection of whether notes are optional or required in XML format.
Paul's client accepts and sends a new INVITE to establish a dialogue with Marco's client including the context. The call flow diagram 400 indicates that the notification that Marco gets before accepting the call can occur at the same time as the ringing. Once Marco hears the ringing, Marco can check for the notes via email (TOAST W/ NOTES), for example, as to the calling party and to the notes. Marco decides to accept the call from Paul (e.g., by clicking on an icon) and a new window opens which then shows the notes again to Marco to have the notes accessible when speaking with Paul. The content-answering-CIDs indicate to Paul whether the notes were accepted or not by Marco. Feedback to Paul's client can also include the situation where Marco's client does not know how to render the notes, but still was able to accept the call. This information can then flow back to Mindy.
More specifically, if the transferee client indicates that it supports transferring notes (via Supported:ms-referred-body), then the transferor can add conversation-context to the Refer-Body as a MIME part. The transferee echoes the conversation-context back to the transfer-target in the outgoing invite.
It can also be the situation that the transferee consumes some part of the Refer-Body. Therefore, the transferor adds the MIME header ms-referred-body in Content-Disposition to indicate identify the parts that will be sent to the transfer-target. By default, the parts without this header can be consumed by the transferee. The transferee may reject the REFER with a 415 message if there are any MIME parts with handling=required and without ms-referred-body that the client does not understand. When transferor receives a 415 message for a REFER, the transferor can retry sending MIME with handling=optional, or simply retry without MIME in the Refer-Body.
Note that if the MIME in Refer-Body is nested, the ms-referred-body can be specified on the root MIME parts. If there are SDPs in the Refer-Body, the transferee can strip the SDPs out before copying the Refer-Body in the INVITE.
FIG. 5 illustrates an example call-flow diagram 500 where the transfer-target cannot accept notes. In this example, Mindy talks to Paul, takes notes, puts Paul on hold, and then initiates the transfer from Paul to Marco. The transfer includes a SIP INVITE through a communications server to Marco. The transfer also includes sending the INVITE from the server to the PSTN (public switch telephone network) via a PSTN gateway. Marco has set “simul” ring to his cell phone. Thus, Marco receives an incoming call on a computer (running the communications client) and his cell phone.
The toast in Marco's communications client shows the notes that Mindy entered. Marco is away from the desktop, and picks up the call on his cell phone. Mindy is notified that Marco did not receive the notes at the endpoint where the call was picked up.
FIG. 6 illustrates an example call-flow diagram 600 where the transfer of notes includes a consultation by audio. Here, Mindy talks to Paul over a two-way SIP channel and takes notes (NOTES). Mindy puts Paul on hold, and calls Marco to see if he would take Paul's call. The notes are sent to Marco via a SIP INVITE, and Marco speaks with Mindy, and looks at Mindy's notes (via a toast, with context) to confirm that Marco will take Paul's call. Mindy puts Marco on hold, resumes Paul from hold and then completes the transfer. Marco can see Mindy's notes while Marco talks to Paul.
FIG. 7 illustrates an example call-flow diagram 700 where the transfer occurs with consultative context. This call flow only describes the scenario when a conversation-context is added by an ACD. Paul calls the main number of a company and is directed to interaction with the ACD via a two-way RTP (realtime transport protocol) channel. Paul navigates through a voice menu and selects to speak with someone working on a project. The ACD connects to Mindy and Mary, who receive an incoming call and see that Paul, a premium customer of the company, is calling about the project. Both Mindy and Mary can view context associated with the call, as provided by the ACD, and presented via toast. Mindy is available and picks up Paul's call. Mary stops ringing and sees that Mindy picked up the incoming call.
Following are additional details on an exemplary format of the MIME messages used to share call context. SIP INVITEs have multipart/alternative parts within multipart/mixed. The italicized section is for ms-conversation-context. The underlined section can accommodate ICE (information and content exchange) support. The alternative MIME for ms-conversation-context can be used for sending content-types (e.g., images) that some clients may not understand.
--UniqueBoundary1
--UniqueBoundary3
--UniqueBoundary3--
--UniqueBoundary1-
<context data goes here>
--UniqueBoundary2
--UniqueBoundary2--
FIG. 8 illustrates a computer-implemented method of sharing call information. At 800, a phone call is received from a calling party via a call system. At 802, call information (e.g., notes, call topic, calling party name, location, etc.) associated with the call is entered via a communications client. At 804, the call information is sent to a call recipient via the communications client. At 806, the call information is presented to the call recipient. This process can also include sending a notification to the call recipient that call information is available for viewing. The notification can be related to the status of the delivery of the call information.
The method can further comprise sending the call information in multiple different communications formats using correspondingly different communications technologies via the communications client using SIP INVITE, REFER, and/or INFO messages. The method can further comprise receiving the call information in an encrypted format using a private key, sending the private key to a third party via a presence channel, and opening the call information for the call recipient using the private key.
The method can also comprise protecting the call information during the sending of the call information using information rights management technology or S-MIME. The disclosed architecture is extensible such that the call information can be extended with new call information via a third-party application.
The method can further comprise identifying if a recipient system of the call recipient can receive and process the call information and sending a notification related to status of delivery of the call information, and consulting with the call recipient using voice signals while the call recipient reviews the call information.
FIG. 9 illustrates a method of sending call information using MIME. At 900, call information is received as provided by a receptionist, agent or ACD. At 902, the call information is converted into a multipart/mixed MIME message of SDP payload and multipart/alternative message for multiple subparts. At 904, the converted call information is sent via a SIP INVITE, REFER and/or INFO message(s). At 906, the SIP information is sent using multiple different communications formats (e.g., instant messaging, audio signals, etc.) for correspondingly different communications technologies.
FIG. 10 illustrates a method of sending call information using optional techniques. At 1000, the user initiates send of call information via a communications client. The call information can be in the form of notes entered by a receptionist, for example. At 1002, optionally, the user can choose to send the call information blindly without first speaking to the call recipient. At 1004, optionally, the client application can identify that the recipient client lacks the capability to accept call information and notifies the user that the call information was not viewed. At 1006, optionally, the user can consult with the recipient while the recipient views the call information. At 1008, optionally, the calling party connects to an ACD such that conversation context is sent to the recipient before or during the call.
Referring now to FIG. 11, there is illustrated a block diagram of a computing system 1100 operable to execute call context sharing in accordance with the disclosed architecture. In order to provide additional context for various aspects thereof, FIG. 11 and the following discussion are intended to provide a brief, general description of a suitable computing system 1100 in which the various aspects can be implemented. While the description above is in the general context of computer-executable instructions that may run on one or more computers, those skilled in the art will recognize that a novel embodiment also can be implemented in combination with other program modules and/or as a combination of hardware and software.
A number of program modules can be stored in the drives and volatile memory 1112, including an operating system 1130, one or more application programs 1132, other program modules 1134, and program data 1136. The one or more application programs 1132, other program modules 1134, and program data 1136 can include the context component 108, context 110, transfer component 112, description component 202, notification component 204, versioning component 206, communications client 302, UI 304, conversation models 316, media sessions 322, session stacks 328, and SIP-based MIME messages, for example.
Referring now to FIG. 12, there is illustrated a schematic block diagram of an exemplary computing environment 1200 that supports call context sharing. The environment 1200 includes one or more client(s) 1202. The client(s) 1202 can be hardware and/or software (e.g., threads, processes, computing devices). The client(s) 1202 can house cookie(s) and/or associated contextual information, for example.
The client(s) 1202 can be the communications clients 302 and 334, and the server(s) 1204 can be the communications server in the call flow diagram 500 via which the notes, call context, etc. are transmitted.
1. A computer-implemented information sharing system, comprising:
a context component for electronically recording and storing context in association with communications of a communications system; and
a transfer component for transferring the context to a party of the communication.
2. The system of claim 1, wherein the context includes at least one of notes, links, or multimedia content.
3. The system of claim 1, wherein the transfer component makes the context accessible to the party before, during, or after the communications.
4. The system of claim 1, further comprising notification component for notifying the party of the context via the communications system.
5. The system of claim 1, wherein the context is transmitted as a multipart/mixed MIME message in one or more SIP messages.
6. The system of claim 5, wherein the multipart/MIME message includes a MIMEpart as an SDP payload and another MIMEpart for another context.
7. The system of claim 5, wherein the one or more SIP messages include one or more of INVITE, REFER or INFO.
8. The system of claim 1, further comprising a description component for generating a content description for the context.
9. The system of claim 1, further comprising a versioning component for managing versions of the context.
10. A computer-implemented information sharing system, comprising:
a context component for electronically recording and storing notes as part of a conversation context in association with a conversation of an IP communications system;
a description component for generating a content description for content of the conversation context; and
a transfer component for transferring the notes and content description to a party of the conversation via the IP communications system.
11. The system of claim 10, wherein the transfer component transfers the context to the party via a presence document.
12. The system of claim 10, further comprising a notification component for notifying the party of the conversation context via the IP communications system.
13. The system of claim 10, wherein the conversation context is transmitted using an encryption technology and as a multipart/mixed MIME message according to SIP messages that include at least one of INVITE, REFER or INFO.
14. A computer-implemented method of sharing call information, comprising:
receiving a phone call from a calling party via a call system;
entering call information associated with the call via a communications client;
sending the call information to a call recipient via the communications client; and
presenting the call information to the call recipient.
15. The method of claim 14, further comprising sending the call information in multiple different communications formats using correspondingly different communications technologies via the communications client using SIP INVITE, REFER or INFO messages.
receiving the call information in an encrypted format using a private key;
sending the private key to a third party via a presence channel; and
opening the call information for the call recipient using the private key.
17. The method of claim 14, further comprising protecting the call information during the sending of the call information using information rights management technology or S-MIME.
18. The method of claim 14, further comprising extending the call information with new call information via a third-party application.
19. The method of claim 14, further comprising identifying if a recipient system of the call recipient can receive and process the call information and sending a notification related to status of delivery of the call information.
20. The method of claim 14, further comprising consulting with the call recipient using voice signals while the call recipient reviews the call information.
US12/117,727 2008-05-08 2008-05-08 Extensible and secure transmission of multiple conversation contexts Active 2031-04-15 US8718042B2 (en)
US12/117,727 US8718042B2 (en) 2008-05-08 2008-05-08 Extensible and secure transmission of multiple conversation contexts
US20090279533A1 true US20090279533A1 (en) 2009-11-12
US8718042B2 US8718042B2 (en) 2014-05-06
ID=41266824
US12/117,727 Active 2031-04-15 US8718042B2 (en) 2008-05-08 2008-05-08 Extensible and secure transmission of multiple conversation contexts
US (1) US8718042B2 (en)
US20100086118A1 (en) * 2008-10-03 2010-04-08 Quanta Computer, Inc. Communication Network System and Call Pickup Method Thereof
JP2006109244A (en) * 2004-10-07 2006-04-20 Atsuo Inomata Encryption key sharing method and encryption key sharing apparatus
2008-05-08 US US12/117,727 patent/US8718042B2/en active Active
US8718042B2 (en) 2014-05-06
US8902749B2 (en) 2014-12-02 Multi-media messaging method, apparatus and application for conducting real-time and time-shifted communications
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:STREBEL, ANDREAS;TANDON, ANKIT;BASU, PRADIPTA K;AND OTHERS;REEL/FRAME:021282/0653;SIGNING DATES FROM 20080708 TO 20080721
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:STREBEL, ANDREAS;TANDON, ANKIT;BASU, PRADIPTA K;AND OTHERS;SIGNING DATES FROM 20080708 TO 20080721;REEL/FRAME:021282/0653