WO2007101143A2

WO2007101143A2 - Facilitating real-time communication between end users of different service networks

Info

Publication number: WO2007101143A2
Application number: PCT/US2007/062776
Authority: WO
Inventors: Satyanarayana R. Maruri; Deepak Swamy
Original assignee: Maruri Satyanarayana R; Deepak Swamy
Priority date: 2006-02-27
Filing date: 2007-02-25
Publication date: 2007-09-07
Also published as: WO2007101143A3

Abstract

A user system bridges communication sessions to different server networks such that end users of different service networks can participate in a common communication session in real-time. For example, a present user may set up a first session (e.g., chat or voice call) with one service network (e.g., Yahoo service) and a second session with another service network (e.g., GoogleTalk), and bridges the two communication sessions (at the user system) such that the present user and the two remote users corresponding to the two communication sessions can participate in the same common communication session.

Description

Facilitating Real-time Communication Between End Users of Different Service

Networks Related Application

The present application is related to and claims priority from US provisional patent application entitled, "Methodology & Apparatus For Facilitating Unification Of

Presence And Voice/Video/Data Communications Across Disparate Service

Networks", serial number: 60/767039, filed on: 2006-02 -27, naming as inventors

Maruri et al, and is incorporated in its entirety to the present application.

Background A service network generally contains several server systems, which enable different end users to communicate with each other. In a typical scenario, an end user (person) uses a user system (e.g., a personal computer system, a note book system, a mobile phone, hand-held devices, etc.) and communicates with another end user using another user system. The end users often engage in real-time communications, which refer to situations in which both users can be party to the communication at the same time in an interactive mode. For example, when users exchange text in real time, such communication is generally referred to as a 'chat'. When users talk to each other in real time, the communication is referred to as a 'voice call' (or a telephone call). Similarly, when video information is exchanged, the communication is referred to as video conferencing. In general, the communication is often in a combination of one or more of text, graphics, images and voice ("content types").

There are several service networks, which enable real time communication between corresponding subscribing end users. Yahoo Messenger (YM), Windows Live Messenger (WLM) GoogleTalk, Skype, Vonage, PSTN are examples of such different service networks. In general, each service network has a corresponding set of subscribing users, and each user generally establishes his/her identity (by logging on) and establishes a communication session with another subscribing user.

There is a general need to establish communication between end users of various communication networks.

Description of the Drawings

Example embodiments will be described with reference to the accompanying drawings briefly described below. Figure 1 is a block diagram illustrating the details of an example environment in which several aspects of the present invention can be implemented.

Figure 2 is a flow chart illustrating the manner in which enhanced communication is provided to end users of a service according to an aspect of the present invention.

Figure 3A depicts a user interface that can be used by a present end user to log on to a user system in an embodiment.

Figure 3B is a user interface using which an end user can specify the various service networks on which the end user can establish communication sessions to users of corresponding service networks in an embodiment.

Figure 3C is a user interface using which an end user can specify authentication for each service network in an embodiment.

Figure 3D is a user interface in which the address book containing contacts information from multiple service networks is displayed in an embodiment. Figures 4A, 4B, 4C and 4D together illustrate the user experience of various end users when text is the content exchanged in communication sessions in one embodiment.

Figure 5 is a user interface illustrating the controls that may be available to a present end user conferencing multiple remote end users for audio conference in an embodiment.

Figure 6 is a block diagram illustrating the details of an example embodiment of a user system in an embodiment.

Figure 7 is a block diagram illustrating the details of digital processing system in which various aspects of the present invention are operative by execution of appropriate software instructions.

In the drawings, like reference numbers generally indicate identical, functionally similar, and/or structurally similar elements. The drawing in which an element first appears is indicated by the leftmost digit(s) in the corresponding reference number.

Detailed Description 1. Overview

According to an aspect of the present invention, a user system enables an end user to set up communication sessions with different end users of corresponding service networks, and then to bridge the communication sessions such that all the end users can participate in a common session. For example, a first user can set up a telephone (or voice) call with a second user using GoogleTalk™ service, and another telephone call with a third user using Vonage™ service. Similar bridging is facilitated at the user systems for other types of content (text, video, etc.) Several aspects of the invention are described below with reference to examples for illustration. I t should be understood that numerous specific details, relationships, and methods are set forth to provide a full understanding of the invention. One skilled in the relevant art, however, will readily recognize that the invention can be practiced without one or more of the specific details, or with other methods, etc. In other instances, well-known structures or operations are not shown in detail to avoid obscuring the features of the invention.

2. Example Environment

Figure 1 is a block diagram illustrating the details of an example environment in which several aspects of the present invention can be implemented. The block diagram is shown with user systems 1 10A, 1 10B and 1 10C, service networks 120A and 120B, and Internet 130. Though shown merely with a few (both in number and type) of components for illustration, typical environments generally contain many more components. Each component of Figure 1 is described below in further detail.

Internet 130 refers to a conglomeration of networks (containing Intranets, access networks, connectivity backbone, etc.), inter-operable using protocols such as Internet Protocol (IP). Each individual network can operate internally using other protocols and/or transports, though it is assumed that each of the networks is also implemented using IP (in combination with Ethernet or ATM or Frame Relay) for ease of understanding. In general, Internet 130 provides transport for various data packets between the different systems (1 10A-1 10C and 120A-120B) to provide the necessary connectivity among the systems. Each data packet is typically forwarded based on a destination IP address to the corresponding target system (identified by the destination address)

Each service network 120A and 120B generally contains multiple server systems and associated infrastructure (e.g., for authentication, accounting, security, connectivity, administration) and enables end users to establish and conduct communication sessions with each other. Thus, each service provider operating the service network provides a service by facilitating establishment of a communication session. The service network may or may not have a substantial role in conducting communication on the established session. Each service network is characterized by a corresponding protocol interface in terms of one or more aspects such as how to establish a communication sessions, which end users to permit to use the service, the packet format/content/sequence in supporting the communication session for the same content type. Examples of service networks are Windows Live Messenger, MSN Messenger, Yahoo Messenger, AOL IM/ACQ, Skype, GoogleTalk, Vonage, etc.

The internal implementation of each service network 120A and 120B depends in part on the content types supported by each communication session. For example, in case of Skype service, end users can establish independent sessions for text and voice (after a single authentication), with different end users. A video session can also be established in parallel with the voice session. The implementation of each service network 120A and 120B depends on the communication services being facilitated, and will be apparent to one skilled in the relevant arts.

Each service network 120A and 120B is viewed as being operated by a service provider and providing communication services to the corresponding set of subscribing end users. For example, service network 120A can be viewed as providing communication services among end users subscribing to Skype service and service network 120B can be viewed as providing communication services among end users subscribing to GoogleTalk service. User systems 1 10A, 1 10B and 1 10C refer to any digital processing systems using which an end user can initiate and conduct a communication session with other end users subscribing to the same service. Examples of end user systems are personal computer s, note book computers, mobile phones, hand-held devices, etc. Various aspects of the present invention simplify, facilitate and/or enable the communication sessions to different service networks to be bridged at the user systems 1 10A, 1 10B and 1 10C, as described below in further detail.

2. Enhanced Communication Between End Users

Figure 2 is a flow chart illustrating the manner in which communication is enhanced between end users according to an aspect of the present invention. The flowchart is described with respect to the environment of Figure 1 , and in particular with respect to user system 1 10A, merely for illustration. However, the features can be implemented in various other environments as well. Similarly the steps are described in a specific sequence merely for illustration. However, the steps can be implemented in other sequences as well. Implementations according to such modifications and in different environments and in other systems, without departing from several aspects of the present invention, will be apparent to one skilled in the relevant arts by reading the disclosure provided herein. The flowchart begins in step 201 , in which control passes to step 210.

In step 210, user system 1 10A sets up a first communication session with a first end user of a first service network and a second communication session with a second end user of a second service network. In general, setting up of a communication session depends on the interface requirements of each service network, which can be determined, for example, by applicable protocol descriptions or by examining the packet content (on Internet 130). The communication sessions can be initiated at user system 1 10A or from remote user systems 1 10B/1 10C.

In step 230, user system 1 1 OA bridges the first communication session and the second communication session so that an end user of the present end system, the first end user and the third end user are all part of a common communication session. Bridging entails forwarding some or all of the information content (voice, video or text) from one of the end users to the remaining two end users (or the corresponding user systems 1 1 OB/1 10C).

The information content originating from each remote user is received according to the protocol interface using which each service network operates and forwarded to the other remote user using the protocol interface using which the other service network operates. As noted above, the protocol interfaces can be determined by examining the packet content/sequence or from the related description. In addition, information content from the user of user system 1 10A is received per any user interface that can be controlled by appropriate implementation of user system 1 10A. The flow chart ends in step 299.

Once bridged, some or all of the content originating from each end user can be experienced (heard/viewed) by the remaining end users. It may be appreciated that user system 1 10A may exercise some control in terms of which information to forward or how to sequence the different information content received from different end users, typically depending on the specific content type being bridged and other features sought to be provided. For example, in case of bridging text based communications, all the text received as a single packet may be entirely displayed (and sent for display) before sending the text originating from another user. Similar, in case of voice content, user system 1 10A may determine how to process the content if voice from multiple users is received at the same time.

From the above, it may be appreciated that an end user is provided the ability to connect communication sessions to multiple end users of different service networks. All the users thus connected can experience the same common content, at least to some extent, as desired in the specific context.

As may be appreciated, it may be desirable to enable a user of user system 1 10A to initiate the set up of at least some of the communication sessions thus bridged. Various types of user interfaces and experience may be provided in facilitating such a feature as described below with examples. First the manner in which user system 1 10A may facilitate users to provide various authentication information (user identifier and password combination) for various service networks is described below.

3. Providing Authentication Information for Various Service Networks

Figure 3A depicts an example user interface facilitating multiple end users, each having ability to access a different set of service networks, to use the same user system 1 10A. As shown there, a new user can be added by selecting 303 (create new profile). In the profile, the end user indicates a user identifier and a password sought to be used.

Once the profile is created, an end user enters the corresponding user identifier (field 301 ) and password (field 302). Upon entry of the correct pair, the user is logged on to user system 1 10A to be able to use several features provided by an aspect of the present invention. The user may select login to all service networks' 305 or login to selected service networks' 306 to indicate the corresponding intent. The logins would be attempted if the end user has already provided. The manner in which the end user can provide login information (typically user identifier and password for the corresponding network, but can be based on other mechanisms such as digital certificates, etc., as will be apparent to one skilled in the relevant arts) for each service network, is described below in further detail with respect to Figure 3B.

Figure 3B depicts an example user interface using which a user can manage login sessions with various service networks. Shown there are four rows 321 -324 (assuming same user identifier) to respectively login to Yahoo, GoogleTalk, MSN, and Skype services respectively. It should be understood that these are only example services to which the present end user can establish communication sessions. However communication sessions with other services, potentially with different features than in the example services, are also contemplated to be covered by several aspects of the present invention. Columns 331 and 332 respectively identify the user identifier and the service network to which the corresponding row relates. Column 333 indicates the login status to the corresponding service network. The user selects (by checking off, as shown in rows 321 and 322) the service network of the corresponding row to login to the service network. Button 330 is clicked on (or selected) to disconnect. A row can be removed by selecting button 329 when the corresponding row is selected/highlighted. Previously provided authentication information can be edited by selecting edit button 328. The user can add more service networks by selecting add button 327. An example interface resulting from selecting add button 327 is described with respect to Figure 3C. Figure 3C depicts an example user interface using which an end user can provide authentication information for each service network of interest. The user selects one of the service networks supported by user system 1 10A using select button 341. The specific choices may be added in the menu based on installation of supporting software/hardware (described below with respect to Figure 6) for the corresponding service network.

Yahoo service is shown as being selected in field 342. The user name and password are entered in the respective fields 343 and 344. The user can save the information by selecting save button 345 (and be ready to enter information for next service network), or save and close by selecting button 346, and just close without saving by selecting button 347. The user may require user system 1 10A to remember password by checking off field 348 as shown, in which the user need not enter the password for the service network when logging in to the service network.

Once the user has provided login information for all service networks of interest, user system 1 10A may connect with each of the service networks (using the provided authentication information) and retrieve the contacts information (indicating the identifiers of the remote end users that the present end user has indicated to be of interest and stored in the address book of that service) from each service network. The retrieved information may be shown in a common address book shown in Figure

3D. Figure 3D depicts a common address book for all the service networks an end user has provided login information for, in one embodiment. Column 371 indicates the name of the remote end user (editable by the present end user), column 372 the user identified of the remote end user in the corresponding service network, column 373 the identifier of the service network, and column 374 the content types supported for the corresponding remote end user. The specific values in column 374 may be based on knowledge of content types supported by the specific service network, or information available based on content types supported for the specific remote end users. Thus, row 381 indicates a communication session of voice/video or text types can be established with a remote end user having name Jane Doe and user identifier friendly-person using a service network New-service (akin to Skype, etc.). Though not shown, the address book may contain several entries, with each entry for a remote end user on a corresponding service network. Thus, once a present end user of user system 1 10A has provided the information noted above for login information for different service networks of interest, bridged communication sessions can be established with multiple remote end users participating, as described in sections below with examples. Merely for illustration, the examples show a situation in which a present end user establishes a communication session with one remote end user (using a first service network) and later joins other end users (possibly of same or different service networks) to form a common communication session for all the end users (including present end user).

However, a common communication session can be established by just selecting all the end users of interest and starting the common session without departing from the scope and spirit of various aspects of the present invention, as will be apparent to one skilled in the relevant arts by reading the disclosure provided herein.

Further, merely for ease of understanding, it will be assumed that a present end user is using user system 1 10A to establish a communication session with a first remote end user on user system 1 1 OB and then joining a second remote end user on user system 1 1 OC. For convenient, the user systems 1 1 OB and 1 1 OC are referred to as remote (end) systems and the users there are referred to as remote (end) users. 4. Common Communication Session for Text Content

Figure 4A depicts an example user interface provided when a present end user of user system 1 10A initiates a communication session for text content. In the description related to text content, each line entered by a user is conveniently shown in the format AA_LN, wherein AA identifies the end user entering the line (PU for present user, R1 for the first remote user and R2 for the second remote user) and N the position in the sequence in which the line is received by user system 1 1 OA system irrespective of whether from the present end user or the remote end users. Thus, a line with N=2 would be received after a line with N=1 , and before a line with N=3. Thus, in the display of Figure 4A, the present user of user system 1 10A is shown entering lines PU-L1 and PU-L3 in entry area 41 1 (in which various lines are entered). Similarly, in the display of Figure 4B corresponding to the first remote user, line R1 -L2 is shown entered in entry area 421. Assuming the internal implementation in user system 1 10A received lines PU-L1 , R1_L2 and PU-L3 in that sequence, the three lines are shown displayed in that sequence in display areas 410 and 420 on user system 1 10A and user system 1 10B respectively. An end user may indicate completion of entry of a line by pressing the 'Enter' key or clicking on send button 413.

Now it is assumed that the present user wishes to add the second remote end user of user system 1 10B and thus clicks on area 414. The example user interface shown in Figure 4C may be displayed.

Figure 4C depicts an example user interface provided when a present end user wishes to add more end users to an existing communication session. Assuming all the newly added parties are also with respect to text communication, only those users of column 374 (of Figure 3D) having Text in the corresponding row are shown as potential end users for addition in area 431. The user may highlight each user of interest in area 431 and select Add button 432 to cause the corresponding name/identifier moved to area 438. An entry (not shown) in area 438 may be selected and deleted from that area 438 by selecting remove button 433.

Once the remote end users of interest are included in area 438, the present end user may select OK button 434 to invite each remote user to the communication session in progress. It is assumed for simplicity only a second remote user at user system 1 10C is invited to the conference. The corresponding displays for the present user and the second remote end user are shown in Figures 4D and 4E respectively. Figure 4E represents an updated user interface at user system 1 1 OA assuming the present user has entered a line PU-L4, and received lines R2-L5 and R1 -L6 in that sequence (from the user system 1 10B and user system 1 10C respectively). Thus, area 41 1 is shown with PU-L4 entered and PU-L4, R2-L5 and R1 -L6 added in that sequence in comparison to the display in Figure 4D. On the other hand, in Figure 4E corresponding to the user interface for the second remote end user, the entry area 421 is shown with line R2-L5 and the three lines PU-L4, R2-L5 and R1 -L6 displayed.

According to an aspect of the present invention, each of the two user systems 1 1 OB and 1 1 OC may operate without the knowledge of the addition of a third party to the conference. Such a feature may be enabled by user system 1 10A providing data received from one user system to the other user system(s) as if the data originated from the present end user itself.

Such a feature generally entails using the same protocol conventions/format indicating that the source of the data is user system 1 10A (in the packets sent to recipient remote user systems) even though the content is received from the remote user system. Thus, the remote users may be able to see the data entered by the present end user (who caused the communication sessions to be bridged) as well as by the other remote users party to the common communication session.

Such a feature may be referred to as transparent conferencing. Transparent conferencing has advantages in that the only user system 1 10A needs to be modified (compared to supporting point to point communication sessions) to provide the features described above, while other user systems can continue to operate without further modifications or extensions. It may be observed that the option 'Add to conference' 414 is absent on user systems 1 10B and 1 1 C assuming the features of the present invention are not provided from those user systems, yet they interoperate with user system 1 10A. However, it should be appreciated that alternative embodiments can be implemented which are aware of the addition of third parties and the user systems can be extended consistent with such a requirement.

Transparent conferencing at user systems (by end users) may be provided associated with audio and video content as well, as described below.

5. Common Communication Session for Audio/Video Content

The present end user at user system 1 10A may initiate communication with a remote end user at user system 1 10B, and then join other remote end users using an interface similar to that shown in Figure 4C. Even in this case, user system 1 1 OA can control how much of voice content received from one remote end user is to be forwarded to other end users, or the manner in which voice content from different end users is to be mixed. In an embodiment, the same content is forwarded to all the end users participating in the common communication channel. The end user at user system 1 1 OA may be provided control as illustrated with respect to Figure 5.

Figure 5 depicts the content of a panel operable by a present end user at user system 1 10A when conferencing multiple end users. Each added user is shown in a corresponding row 51 1 -514. Each user may be muted (i.e., the sound received from that user is not forwarded to any user, with or without mixing) by entering Y in the corresponding row of column 501. However, all the users receives the same voice content in an embodiment.

Priority column 502 contains priority numbers. All users of lower priority number are muted (not available for mixing) if voice content from a user with a higher priority number is received around that time instance (say in the previous one second). In the example of Figure 5, the voice of user-1 is not heard by any other participants. The voice of user-4 is heard by others only voice content is not received from if users 2 and 3 (of rows 512 and 513). If voice content is received from users 2 and 3, the content is mixed before forwarding to all the participating end users. Various other features can be provided while bridging voice communication channels, without departing from the scope and spirit of several aspects of the present invention, as will be apparent to one skilled in the relevant arts by reading the disclosure herein. Many such implementations are contemplated to be covered by such aspects of the present invention. The user experience related to video content is similarly described except that user system 1 10A may construct a new frame containing the video frames received from different remote end users. Such new frame may be transmitted to each participating user system, as if originating from user system 1 10A, to provide transparent bridging. A common audio channel may also accompany a common video channel, as is often common with video conferencing applications.

It should be appreciated that the above described features can be realized with various architectures implemented within user systems. The description is provided with respect to an example architecture. 6. Architecture

Figure 6 is a block diagram illustrating the details of user system 1 10A in one embodiment. The user system 1 10A is shown containing network interface 610, session manager 620, session table 625, service interfaces 630A - 630C, connection setup block 640, video adapter 650A, audio adapter 650B, text adapter 650C, user interface block 670, address book 675, audio I/O (input/output) 690A, video capture 690B, text input interface 690C, and display interface 690D. Each block is described below in further detail.

Audio I/O 690A represents an interface from which audio content is received from the present end user and also the audio content sought to be played for the user is provided. Once provided, it is assumed that a reproduction unit (either within audio I/O or an external component, not shown) plays the audio content thus provided.

Video capture interface 690B receives image frames captured for video sessions. The frames may be captured and received according to various standards or interface requirements, as will be apparent to a skilled practitioner. Each image frame may contain pixel values, with each pixel value representing the corresponding point of the image.

Text input interface 690C receives the text received from the present user system. Thus, the text entered in area 41 1 may be received via text input interface 690C.

Display interface 690D may be connected to a display unit (e.g., a flat panel monitor, not shown) on which various images can be displayed. Thus, the various interfaces shown above with respect to Figures 3A-3C, 4A-4E, and 5 may be displayed on the display unit. In addition, the video pictures captured by display interface 690D or video images sent to all the participants may also be displayed on the same display unit.

Address book 675 contains all the contact information of all the remote users in the various service networks. Thus the data shown in Figure 3D above may be stored in address book. Network interface 610 provides the physical, electrical and protocol interfaces to be able to send and receive IP packets. In general, user system 1 10A is configured with an associated IP address and all packets received with a matching IP address in the destination field are processed further. The payload of each IP packet may be forwarded to session manager 620. Session table 625 may contain information to enable each packet to be identified with each communication session, for example, in the form of a table. The information to be stored depends on the implementation interface provided by the service networks. For example, in the case of text communication sessions in one embodiment, the sender's identifier (conference participant in the form of user@service-network-domain.com) in a received IP packet may be compared (by session manager 620) with entries in the table for a matching entry for the same corresponding values. The matching entry may indicate the specific upper layer application (in this case the specific ones of the service interfaces 630A-630C) to which to forward the packet. The table may also indicate that a packet is to be forwarded to connection setup block 640 (though connectivity is not shown in the figure).

The session table can also indicate the specific conference to which each session relates to and conference participants. As more communication sessions are bridged into a common communication session, the corresponding information is added in the session table. Though not shown, such information is made available to each of the adapters. Session table 625 can be implemented in the form of multiple tables as well (e.g., some of transport/TCP level information to be able to forward each IP packet to the corresponding next module, and another table to indicate the conferences each connection belongs to).

Each service interface block 630A-630C is adapted to process the packets received from a corresponding service network and to be sent to the corresponding service network. Each service interface implements the corresponding protocol specifications of the service network. These specifications may include login/ authentication, logout, online status, setup/teardown of chat, audio, video session, data transfer, and other tasks. In an embodiment, each service interface block receives (from the adapter corresponding to the content type) a stream of data to be sent to a service network, and packs the data into one or more IP packets to be sent using session manager 620. The session manager 620 may pass the data to network interface 610 for forwarding to the service network indicated by the destination IP address contained in each packet. Similarly, when packets are received, the service interface may forward the packet to the session manager 620 or to one of the adapters (as indicated by the data in session table 625). In addition, the service interface block is also designed to send appropriate packets to manage a session with the corresponding service network. In general, the implementation of each service interface block (630A-630C) depends on the protocol/interface requirements of the corresponding service network. Accordingly, the packet sequences may be examined for each service network to determine the manner in which service interface block is to operate. To the extent the interface requirements are different for different content types, the corresponding implementation may also be added to the service interface block. A service interface block is added for each service network with which communication sessions are sought to be established.

Each of the adapters 650A, 650B and 660C receives the corresponding content type from user interface block 670 (from the present end user) or from service interfaces 630A-630C (depending on the service networks to which the communication sessions are established), and uses the session table 625 to generate the content to be provided to each of the participating end users. Each of the adapters generates data representing content consistent with the description (Figures 4A-4E and 5 for text and audio respectively) provided above. The video and audio adapters 650A and 650B may perform encoding and decoding of video and audio data as per the specifications provided by the network interfaces. The content is then provided as a stream to one of the service interface blocks depending on the specific service networks to which the content is to be forwarded.

Connection setup block 640 receives a command from user interface block 670 to set up a communication session for specific content type, and interfaces with the specific one of the service interface block 630A-630C to setup a communication session. Once the session is setup, session table 625 is updated with the corresponding information.

User interface block 670 facilitates the various user interfaces described above with respect to Figures 3A-3D, 4A, 4D and 5. For example, user interface block 670 may enable a user create profiles and save the authentication information of various end users in a non-volatile memory (not shown in Figure 6). User interface block 670 may then receive authentication information for an end user for various server networks as described with respect to Figure 3B and store the corresponding information also in the non-volatile memory. User interface block 670 may then receive data indicating the remote end users to which communication sessions are to be set up. Using the information in the address book, user interface block 670 determines the service networks with which communication sessions are to be established. User interface block 670 then interfaces with the corresponding ones of service interfaces 630A,-630C to set up the communication sessions. For each communication session, user interface block 670 generates and stores session identifier and session participants, participants network interfaces, the port and IP address information session table 625.

If/when the user indicates that two communication sessions are to be conferenced, user interface 670 may update the corresponding entry in session table 625 to cause the bridging of the sessions. User interface block 670 also receives the corresponding content from each of the adapters, and provides the content in a suitable form for reproduction. Thus, a present user can be a part of a conference as described above. It should also be appreciated that the features described above can be implemented in various embodiments. The description is continued with respect to an embodiment in which various features are operative when software instructions are executed.

7. Example System

Figure 7 is a block diagram illustrating the details of a digital processing system facilitating verification of compliance of user interfaces with desired guidelines in one embodiment. Digital processing system 700 is shown containing host 701 connected to display unit 770 and removable storage unit 740. Host 701 is shown containing central processing unit (CPU) 710 (including one or more processors), random access memory (RAM) 720, secondary memory 730, graphics controller 760, network interface 780, and input interface 790. All the components except display unit 770 may communicate with each other over communication path 750, which may contain several buses as is well known in the relevant arts. The components of Figure 7 are described below in further detail.

CPU 710 may execute instructions stored in RAM 720 to provide several features described herein. CPU 710 may contain multiple processing units, with each processing unit potentially being designed for a specific task. Alternatively, CPU 710 may contain only a single general purpose-processing unit. RAM 720 may receive instructions and data from secondary memory 730 using communication path 750.

Graphics controller 760 generates display signals (e.g., in RGB format) to display unit 770 based on data/instructions received from CPU 710. Display unit 770 contains a display screen to display the images defined by the display signals. The displayed images form the basis for various user interfaces described in the present application. Input interface 790 may correspond to implements such as a keyboards and pointing devices (e.g., a tablet and/or a mouse), which facilitate providing various inputs in conjunction with the displayed images. Network interface 780 provides connectivity to a network (e.g., using Internet Protocol), and may be used to communicate with other systems of Figure 1 via Internet 130.

Secondary memory 730 may contain hard drive 735, flash memory 736 and removable storage drive 737. Secondary memory 730 may store various data (e.g., to store the set of validation rules described below) and software instructions (e.g., to provide the features described below with respect to Figure 2 below). Groups of software instructions (for example, in compiled/ object form or post-linking in a form suitable for execution by CPU 710) are termed as code,

Some or all of the data and instructions/code may be provided on removable storage unit 740, and the data and instructions may be read and provided by removable storage drive 737 to CPU 710. Floppy drive, magnetic tape drive, CD- ROM drive, DVD Drive, Flash memory, removable memory chip (PCMCIA Card, EPROM) are examples of such removable storage drive 737.

Removable storage unit 740 may be implemented using mediums and storage formats compatible with removable storage drive 737 such that removable storage drive 737 can read the data and instructions. Thus, removable storage unit 740 includes a computer readable storage medium having stored therein computer software and/or data.

In general, the computer readable medium refers to any medium from which processors can read and execute instructions. The medium can be randomly accessed (such as RAM 720 or flash memory 736), volatile, non-volatile, removable or non-removable, etc. While the computer readable medium is shown being provided from within the digital processing system 700 of Figure 7 for illustration, it should be appreciated that the computer readable medium can be provided external to the digital processing system 700 as well. In this document, the term "computer program product" is used to generally refer to such computer readable medium. These computer program products are mechanisms for providing software to host 701. CPU 710 may retrieve the software instructions, and execute the instructions to provide various features of the present invention described below.

It may be appreciated that though the embodiment shows various features operative by execution of corresponding software instructions, alternative embodiments as a combination of one or more of hardware, software and, firmware may be implemented as will be apparent to one skilled in the relevant arts by reading the disclosure provided herein.

8. Conclusion

Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

What is claimed is:

1. A method implemented in a user system, said method comprising; bridging a first communication session and a second communication session, wherein said first communication session is provided between said user system and a first remote system using a first service network, wherein said second communication session is provided between said user system and a second remote system using a second service network, wherein said bridging enables a common communication session for a present user at said user system, a first remote user at said first remote system and a second remote user at said second remote system.

2. The method of claim 1 , further comprising: receiving a first content from said first remote user on said first communication session; and forwarding said first content to said second remote user on said second communication session.

3. The method of claim 2, further comprising: receiving a second content from said present user, wherein said forwarding forwards said second content to each of said first user system and said second user system, wherein said forwarding forwards said first content as well as said second content to said second remote system indicating that a source is said user system for both said first content and said second content.

4. The method of claim 3, wherein each of said first content and said second content comprises text.

5. The method of claim 3, wherein each of said first content and said second content comprises voice, said method further comprises: providing a panel to said present user on said user system, wherein said panel enables said present user to indicate whether to mute a corresponding end user, wherein said forwarding does not forward content received from a muted end user.

6. The method of claim 5, wherein said panel further enables said present end user to specify a priority associated with each of said first remote user and said second remote user, wherein said forwarding does not forward content received from said second remote user to said first remote user if the priority for said second remote user is lower than the priority for said first remote user and audio content from both of said first remote user and said second remote user is received in the same time duration.

7. The method of claim 6, wherein each of said first content and said second content comprises video.

8. The method of claim 2, further comprising: enabling said present users to specify authentication information to login to each of said first service network and said second network,; and setting up said first communication session and said second communication session using said authentication information.

9. The method of claim 8, further comprising: retrieving a respective set of contacts for said present user in said first service network and said second service network using the corresponding authentication information; and providing both of said sets of contacts in a common address book for said present user.

10. A computer readable medium storing a plurality of instructions, which when executed by one or more processors contained in a user system causes said user systems to perform the actions of: bridging a first communication session and a second communication session, wherein said first communication session is provided between said user system and a first remote system using a first service network, wherein said second communication session is provided between said user system and a second remote system using a second service network, wherein said bridging enables a common communication session for a present user at said user system, a first remote user at said first remote system and a second remote user at said second remote system.

1 1. The computer readable medium of claim 10, further comprising: receiving a first content from said first remote user on said first communication session; and forwarding said first content to said second remote user on said second communication session.

12. The computer readable medium of claim 1 1 , further comprising: receiving a second content from said present user, wherein said forwarding forwards said second content to each of said first user system and said second user system, wherein said forwarding forwards said first content as well as said second content to said second remote system indicating that a source is said user system for both said first content and said second content.

13. An article of manufacture for use in a user system, said article of manufacture comprising: means for setting up a first communication session between said user system and a first remote system using a first service network, and a second communication session between said user system and a second remote system using a second service network; and means for bridging said first communication session and said second communication session in said user system, wherein said bridging enables a common communication session for a present user at said user system, a first remote user at said first remote system and a second remote user at said second remote system