MXPA06000448A - Method and system for placing restrictions on sessions - Google Patents

Abstract

A method and system for initiating a communications session with a restriction is provided. A communications system allows a user to place a restriction on a session to be conducted with another user. If the other user does not agree to the restriction or if the other user's system does not support the restriction, then the session will not be conducted. The communications system may also enforce the restrictions on the session.

Description

METHOD AND SYSTEM FOR PLACING RESTRICTIONS IN SESSIONS Technical Field The described technology refers in general to data communication networks and, in particular, to communication sessions BACKGROUND Applications sometimes need to establish and manage a session between computing devices. A session is a set of interactions between computing devices that occurs over a period of time. As an example, real-time communications applications, such as MICROSOFT MESSENGER or Voice over Internet Protocol ("VolP"), establish sessions between communication devices on behalf of users. These applications can use various mechanisms to establish sessions, such as a "Session Initiation Protocol" ("SIP"). An SI P is an application-layer control protocol that devices can use to discover each other and to establish, modify, and end sessions between devices. The SIP is a standard proposed by the Internet. Its specification, "RFC 3261", is available at http: // www. ietf.org/rfc/rfc3261 .txt. A specification for extensions to SIP in relation to event notifications, "RFC 3265", is available at http: // www. ietf.org/rfc/rfc3265.txt A specification to locate SIP servers, "RFC 3263", is available at http://www.ietf.org/rfc/rfc3263.txt. A specification for session descriptions, "RFC 2327," is available at http: //www.ietf. org / rfc / rfc2327.txt. All of these specifications are incorporated herein in their entirety for reference. Applications can use the SI P with another protocol to send or receive information. As an example, an application can use SIP with Real Time Transport Protocol ("RTP") to transport data in real time during a session. When using SIP with other protocols, applications can create and manage a session and exchange information during the session. The protocol used with SI P to exchange information can segment information into messages. As an example, a Vol P application can segment a long narrative into shorter messages. The exchange of messages during a session is referred to as a "dialogue". The SIP may use lower-level communication layers to transport dialogue messages, such as Transmission Control Protocol / Internet Protocol ("TCP / I P"), which employ commonly used transport layer and network protocols. An SI P network comprises entities that participate in a dialogue such as a client, server, or both. The SIP supports four types of entities: user agent, power server, redirection server, and registrar. User agents initiate and terminate sessions by exchanging messages with other SIP entities.

A user agent can be a user agent client, which is usually a device that initiates SIP requests (for example, to initiate a session), or a user agent server, which is a device that generally receives SIP requests and responds to such requests. As an example, "I-Phones", personal digital assistants, and any other type of computing device can be user agents. One device can be a user agent client in one dialog and a user agent server in another, or you can change roles during the dialog. A power server is an entity that acts as a server for clients and a client for servers. By doing so, proxy servers intercept, interpret or forward messages between clients and servers. Power servers contribute to network security, for example, by validating senders and message recipients. A redirection server accepts an SI P request and generates a YES P response that directs the client sending the request to contact an alternate network resource. As an example, a redirection server can indicate for which of the various devices a particular user is currently available. A registrar is a server that accepts customer registration information IF P and reports a location service or other entities of the received registration information. The SI P supports two types of messages: requests, which are sent from a client to a server and replies, which are sent from a server to a client, generally when responding to a request. A message SI P comprises three parts. The first part of a SIP message is a "start line", which includes fields that indicate a message type and a protocol version. The second part of a SI P message comprises header fields whose values are represented as name-value pairs. The third part of a SIP message is the body of the message, which is used to describe the session by starting or containing data in relation to the session. Message bodies can appear in requests or responses. SIP messages are mourned based on the contents of their header fields. To be valid, a SIP request must contain at least the following five header fields: To, From, Contact, Max-Advances, and Path. The To header field indicates the logical identity of the recipient of the request. The From header field indicates the logical identity of the request initiator. The Contact header field indicates the identity of the place where the sender wishes to receive subsequent messages from the dialogue. The Max-Advances header field indicates a number of hops a request can make before reaching its destination. As an example, if a message from device A transits to device B before it arrives at destination device C, the message is said to have made two jumps (for example, devices B and C). The Via header field includes the path taken by the request (for example, a sequence of network addresses of devices through which the request has traveled) and indicates the path that must be followed when the response is routed. A header can also contain Record-Path fields that are used to indicate that future requests and responses should be routed through an indicated device. Network devices can insert Record-Path header fields that specify devices when a SIP message is pushed forward in an attempt to force subsequent messages in a dialogue to be directed through the specified devices. The Record-Path header field may contain an identifier (for example, network address) for the device and the parameters. These and other header fields are described in the SIP specifications referred to above. SI P has a notion of a dialogue or session that represents a relationship between two parities that persist for some time and facilitate ordering in sequence and the routing of messages between them. To maintain a proper SI P dialog, parities need to be stored in a SIP routing path between themselves, which can include a hop but can be much larger when multiple SI P commands (eg, routers) separate the parities. A SIP session can be described by using Session Description Protocol ("SDP"), RFC 2327. SDP can be used to describe multiple sessions for the purposes of session announcement, session invitation and other forms of login. The SDP data describes the name and purpose of the session, the time that the session is active, the middle of the session and the information to receive the medium (for example, addresses and ports). SDP is extensible since new attribute-value pairs can be defined to describe customary information about a session. One difficulty with typical real-time sessions, such as sending instant messages, is that very few, if any, restrictions can be placed on those who participate in a session or what can be done with the messages of the session. For example, if user A invites user B to participate in a session and user B agrees, then user B is free to invite other users to participate in the session, such as user C. However , user A may not want user C to participate. As another example, user A may wish to keep the session with user B private, in the sense that no other user is able to see the messages of that session. Even if user B is unable to invite user C to participate in the session, user B can still effectively forward messages to user C by using a traditional copy and paste in order to copy the message content and paste it into a message from another session with user C or in an email message sent to user C. It would be desirable to have a technique that allows users to place restrictions on sessions so that unwanted users can not participate in those sessions or see the content of the messages of those sessions.

BRIEF DESCRIPTION A method and system to initiate a communications session with a restriction is provided. A communication system allows a user to place a restriction on a session to be conducted with another user. If the other user does not agree with the restriction or if the other user's system does not support the restriction, then the session will not be conducted. A session is initiated by an "inviter" who specifies that a session with a restriction with a "guest" is about to be conducted. The communications system then sends an invitation specifying the restriction to the guest. If the guest agrees to abide by the restriction in the session, then the guest sends a response to the inviter. When the inviter receives an indication that the guest will abide by the restriction in the session, then the inviter and the guest can conduct the session, such as an instant messaging session. A client component of the communications system that runs on the guest's computer system can help reinforce the restriction in the session.

BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 is a deployment page illustrating a user interface provided by an inviting client component through which an inviter can invite a guest to participate in a session in a modality. Figure 2 is a deployment page illustrating a user interface provided by a guest client component through which a guest can agree to abide by the restrictions of a session in a modality. Figure 3 is a deployment page illustrating a user interface of an inviting client component indicating that restrictions in the session have been accepted in a modality. Figure 4 is a block diagram illustrating the components of the communication system in one embodiment. Figure 5 is a flow diagram illustrating the processing of the invitation component sent from an inviting client component in a mode. Figure 6 is a flow diagram illustrating the processing of the invitation component received from a guest client component in a modality. Figure 7 is a flow chart illustrating the processing of the guest action component of receiving a guest client component in a mode. Figure 8 is a flow diagram illustrating the processing of the received message component of a server component in a mode. Figure 9 is a flow diagram illustrating the processing of the receive invitation component of a server component in a mode.

DETAILED DESCRIPTION A method and system for initiating a communication session with a restriction is provided. In one embodiment, the communication system allows a user to place a restriction on a session by driving with another user. If the other user does not accept the restriction or if the other user's system does not support the restriction, then the session will not be conducted. A session is initiated by an "inviter" who specifies that a session with a restriction is to be conducted with a "guest". The communications system then sends an invitation specifying the restriction to the guest. If the guest agrees to abide by the restriction in the session, then the guest sends a response to the inviter. When the inviter receives an indication that the guest will abide by the restriction in the session, then the inviter and the guest can conduct the session, such as an instant messaging session. A client component of the communications system that runs on the guest's computer system can help reinforce the restriction in the session. For example, if the restriction limits who can invite the guest to participate in the session (for example, only users can participate in a certain domain), then the client component can verify each invitation sent by the guest for that session in order to to ensure that it is consistent with the restriction. As another example, if the restriction limits the actions that the guest can carry out In a message (for example, prohibiting copying and pasting of a message), then the client component can verify each guest action to ensure that it is consistent with the restriction. In this way, an imitator can take restrictions on the sessions and ensure in a certain way that the guest will abide by the restrictions as long as they trust that the client component will reinforce the restrictions. In one embodiment, a client component of the communications system can initiate a session by using the Session Initiation Protocol. When an inviter wishes to initiate a session, the client component that executes the invoker's computer system may indicate to the inviter any restriction to be placed in the session. In addition, the company with which the inviter is associated (for example, the inviter may be an employee of a company) may wish to place certain restrictions on all sessions of its users. The client component creates an invitation that adapts to the Session Initiation Protocol and the Session Description Protocol. The communications system can be extended to the SDP to include custom attributes that specify restrictions in a session. For example, an attribute may limit the session to be private in the sense that no one is allowed to participate in the session or that its content may be available to anyone. The client component then generates a SIP invitation with the SDP data indicating restrictions of the inviter and / or the company. The client component advances the SIP invitation to the invited. The client component of the guest, after receiving the invitation, can determine if it can support the requested restrictions, defined by the attributes of the SDP data. If you can support the restrictions, then include those attributes in the SDP data from your SIP response to the invitation (for example, a SIP 200 OK message). If you can not support a restriction or do not recognize an attribute that specifies constraints, then it does not include those attributes in your response. When the client component supports a restriction, it can initiate the guest to see if the guest wishes to abide by the restrictions in the session. If the guest does not want to abide by the restriction, then the client component does not add the attribute that specifies that restriction to the SDP data of the response. When the client component of the guest receives the response, it checks the attributes of the SDP data to determine whether the guest will abide by the requirements of the restriction. If the guest will not abide by the restrictions, then the inviter may decide not to initiate the session, for example, by not sending a SIP acknowledgment. In one mode, a server reinforces certain restrictions in a session when the messages in the session mourn through the server. When a session is started, the invitation to participate in a session is directed through a command server, which stores restrictions in the session. After the session starts, the messages of the session, particularly those sent by the guest, are directed through the server. After receiving a message from a guest, the server determines if the message is consistent with the restrictions in the session. If the message is not consistent with the restrictions in the session, the server can discard the message so that the restrictions can be enforced and notify the invitee and / or the guest that the message was discarded. For example, if a restriction indicates that only users within a certain domain can be invited to participate in the session and the guest sends an invitation to a user in another domain, then the server would discard the message. However, a server can only reinforce certain restrictions. For example, a server may not be able to enforce any prohibition on a copy and paste of the content of messages, but may be able to reinforce a prohibition to forward a message. In one mode, the client component of the guest can provide credentials in response to the invitation indicating that the client component of the guest can be responsible for reinforcing the restrictions in the session. The client component of the inviter, after receiving the response, can then decide whether to proceed with the session based on the credentials. If credentials are not used, then a malicious client component can accept to abide by a restriction in a session, but fail to abide by it. In such a case, the client component of the inviter may be able to depend on a server to reinforce certain restrictions by insisting that all messages in the session be routed through the server. Figure 1 is a deployment page that illustrates a user interface provided by an inviting client component through which an inviter can invite a guest to participate in a session in a modality. Display page 100 includes a guest name entry field 101, restriction check boxes 1 02 and a submit button 103. The inviter enters the guest name in the guest name entry field and checks the boxes of adequate verification for the desired restrictions. The inviter then selects a submit button to send the invitation to the guest. Figure 2 is a deployment page illustrating a user interface provided by a guest client component through which a guest can agree to abide by the restrictions of a session in a modality. The deployment page 200 includes an invoker name field 201, restrictions to the session area 202, a button of accepted restrictions 203 and a restriction rejection button 204. The name field of the inviter contains the name of the inviter. The restrictions in the session area mention the various restrictions in the session in which the inviter invited the guest to participate. In this example, the restrictions in the session are that the messages are not for getting ahead and users in other domains are not invited to participate in the session. If the guest agrees to abide by the restrictions in the session, then the guest selects the button to accept restrictions. Otherwise, the guest selects the restriction rejection button. The interface The user can allow the guest to selectively accept or reject the restrictions. After the guest agrees to abide by the restrictions, the guest client component sends the response indicating the restrictions that the guest client component supports and that the invitees agree to abide by. Figure 3 is a deployment page illustrating a user interface of an inviting client component indicating that restrictions in the session have been accepted in a modality. Display page 300 indicates that the invitee has accepted the invitation sent by the inviter. The guest client component then sends an acknowledgment message to the guest to start the session. Figure 4 is a block diagram illustrating the components of the communication system in one embodiment. The communications system includes inviting and guest client components and may include server components when the server is used to enforce restrictions. The client computer systems 410 and a server computer system 420 are connected through a communications link 430, such as the Internet. The client computer systems include a user interface component 41 1, a reception guest action component 412, a reception invitation component 413, and a send invitation component 414. The user interface component provides the user interface of Figures 1 -3. The send invitation component is invoked when a Inviter wishes to send an invitation. The component informs the user of the restrictions in the session and then sends the invitation to the guest, indicating the restrictions in the session. The invitation reception component is invoked when a guest receives an invitation. The component tells the guest to determine if the guest agrees to abide by the restrictions in the session that the client component supports. If so, then the component sends a response to the inviter stating that the guest will abide by the restrictions in the session. The receiving guest action component is invoked whenever the guest performs an action related to the session. Actions may include an attempt to invite another user to participate in the session, an attempt to forward a message from the session, or an attempt to copy and paste content from a message. The component determines if the action is consistent with the restrictions in the session. If not, the component blocks the action. The server computer system includes a registration component 421, a registration store 422, an invitation receiving component 423, an acknowledgment receipt component 424, a message reception component 425, and a session store 426 The registration component and the record store can be conventional SI P components for registering users who are available to participate in sessions. The registration component can carry out the registration as defined by SIP. The invitation receiving component is invoked when the server receives an invitation from an inviter that is sent to a guest. The server computer system can function as a SIP command server. The invitation receiving component can store an indication of the restrictions in the session. The acknowledgment receipt component is invoked when the server receives a response from the inviter towards the guest that the inviter knows that the session can be initiated. The server computer system may also include a component to process the response sent by the guest to the inviter and record the restrictions that the guest has agreed to abide by. The message reception component is invoked when a message is received from the session. The message reception component determines whether the messages coming from the guest are consistent with the restrictions in the session and, if not, discards the messages. The session store stores the restrictions in a session so that they can be reinforced. The computing device in which the communication system is implemented can include a central processing unit, memory, input devices (e.g., disk drives). Memory and storage devices are computer readable media that may contain instructions that implement the communication system. In addition, data structures and message structures may be stored or transmitted through a data transmission medium, such as a signal in a communication link. The various communication links can used, such as the Internet, a local area network, a wide area network, a point-to-point dial-up connection, a cellular telephone network and so on. The modalities of the communications system can be implemented in various operating environments including personal computers, server computers, handheld or portable devices, multiprocessor systems, microprocessor-based systems, consumer-programmable electronics, digital cameras, networked PCs, minicomputers, mainframe computers, distributed computing environments that include any of the previous systems or devices, and so on. The computer systems can be cell phones, personal digital assistants, smart phones, personal computers, consumer programmable electronic, digital cameras and so on. Figure 5 is a flow diagram illustrating the processing of the invitation sending component of an inviting client component in a mode. The component is invoked when an inviter wishes to send an invitation. The component indicates to the inviter restrictions on the session and may apply restrictions throughout the company. The component then sends the invitation to the guest. When the component receives an indication that the guest has agreed to abide by the restrictions in the session, then the invitee sends an acknowledgment to the guest and indicates that the session can start. In block 501, the component enters the name of the guest and the restrictions to be placed in the session. In decision block 502, if there are any restrictions on the entire company to be placed in the sessions, then the component continues in block 503, otherwise the component continues in block 504. In block 503, the component adds the company restrictions. In block 504, the component creates the SIP data that identifies the inviter and the guest. In block 505, the component creates the SDP data that includes attributes for the restrictions by being placed in the session. In block 506, the component sends the invitation to the guest. In block 507, the component receives a response from the guest. In decision block 508, if the response is an OK response, then the component continues in block 509, otherwise the component completes the indication that session initiation has failed. In decision block 509, if the response indicates that the guest will abide by the restrictions in the session, then the component continues in block 510, otherwise the component completes the indication that the session has failed. In block 510, the component sends an acknowledgment to the guest and then completes the indication that the start of the session has been successful. Figure 6 is a flow chart illustrating the processing of the invite receiving component of a guest client component in a mode. The component receives an invitation and determines if it can withstand the restrictions in the session. The component then tells the guest to determine if the guest will abide by the restrictions that the client component supports. The component then sends an OK response to the inviter, indicating that the restrictions it supports and agree to abide by them. In block 601, the component identifies the restrictions that the client component supports and will abide by them. In block 602, the component instructs the guest to indicate whether the guest will abide by the restrictions in the session that the client component supports. In decision block 603, if the guest agrees to abide by the restrictions in the session, then the component continues in block 604, otherwise the component continues in block 606. In block 604, the component adds the accepted restrictions to block 604. the SDP data of the SIP response by being sent to the inviter. In block 605, the component sends an OK response to the inviter, indicating the restrictions that the guest will comply with and then complete indicating success. In block 606, the component sends a non-OK response to the inviter and then completes the indication that the session has failed. Figure 7 is a flow diagram illustrating the processing of the guest action component of receiving a guest client component in a mode. The component is invoked whenever a guest performs an action in relation to a session with a restriction. The component determines if the action is consistent with the restrictions in the session. If not, the component blocks the action. In block 701, the component compare the action with the restrictions in the session. In decision block 702, if the action is consistent with the restrictions in the session, then the component continues to carry out the action, otherwise the component continues in block 703. In block 703, the component notifies the invited that the action is inconsistent with restrictions in the session and may also notify the inviter. The component then completes the indication that the action has failed. Figure 8 is a flow diagram illustrating the processing of the message receiving component of a server component in a mode. The component is invoked whenever the server receives a message from the guest of the session. The component determines if the message is consistent with the restrictions in the session. In block 801, the component compares the message with the restrictions in the session. In decision block 802, if the message is consistent with the restrictions in the session, then the component continues in block 804, otherwise the component continues in block 803. In block 803, the component notifies the guest and / or to the inviter that the message is inconsistent with the restrictions in the session and then completes the indication that the message will not be advanced. In block 804, the component advances the message and then completes the indication that the message has been advanced. Figure 9 is a flow diagram illustrating the processing of the invitation receiving component of a server component in a mode. The component is invoked when the server receives an invitation from an inviter. The component stores the restrictions in the session so that the server can later reinforce the restrictions in the session. In block 901, the component saves the session information, including the identification of the session, the identification of the guest and the inviter and the restrictions in the session. In block 902, the component advances the invitation. In block 903, the component waits to receive the OK response from the guest. In decision block 904, if the OK response was received and the response indicates that the guest will abide by the restrictions in the session, then the component continues in block 905, otherwise the component indicates that the beginning of the session has failed In block 905, the component is prepared to monitor the messages of the session in order to reinforce the restrictions in the session. The component then completes the indication of success. The component can also expect the acknowledgment to be received from the inviter. From the foregoing, it will be appreciated that the specific embodiments of the communication system have been described herein for purposes of illustration, but that the various modifications may be made without departing from the spirit and scope of the invention. One skilled in the art will appreciate that an inviter may place any type of restriction on a session, such as the number or length of messages, synchronization of messages, domains or names of participants and so on. Also, during a session an invitee may send a re-invitation to the guest which includes an indication to withdraw or add one or more limitations. An inviter can place different restrictions on different guests. A guest who invites another to participate in the session may place different restrictions on the participation of the other. However, the communications system can ensure that the restrictions are at least restrictive as those placed on the guest by the original provider. One of skill in the art will appreciate that the communications system can be used with protocols to initiate a session other than SI Q. The communications system can also be used to see if a guest will accept the restrictions in a session even when a server or client component does not may be able to reinforce the restrictions. An expert in the field will appreciate that the restrictions of a company may not be for the entire company, but rather may be adapted to different users or groups of the company. According to the foregoing, the invention is not limited except by the appended claims.

Claims (20)

1. CLAIMS 1. A method in a computer system for initiating a session with a restriction, characterized the method because it comprises: receiving an indication of a restriction in the session; send from an inviter to a guest an invitation to participate in the session with the restriction; receiving from the guest an indication that the guest will participate in the session and if the guest will abide by the restriction in the session; and when the guest abides by the restriction in the session, conduct the session with the guest. The method according to claim 1, characterized in that the session is initiated by the use of the Session Initiation Protocol. The method according to claim 2, characterized in that the restriction is indicated as an attribute according to the Session Description Protocol. The method according to claim 3, characterized in that receiving the guest of the indication includes receiving an OK message from the Session Initiation Protocol with the attribute. The method according to claim 1, characterized in that the session is a session of sending instant messages. 6. The method according to claim 1, characterized in that the restriction restricts who the guest can invite to participate in the session. The method according to claim 1, characterized in that the restriction limits the actions that the guest can carry out in messages of the session. The method according to claim 1, characterized in that the indication of the restriction is received from the inviter. The method according to claim 1, characterized in that the indication of the restriction is received based on a policy of a company with which the inviter is associated. 1 0. A computer-readable medium containing instructions for controlling a computer system in order to conduct a session with a restriction, by a method comprising: receiving by a guest an invitation from an inviter to participate in the session with the restriction; determine if the guest will abide by the restriction in the session; when the guest abides by the restriction in the session, send from the guest to the speaker an indication that the guest will participate in the session and will abide by the restriction in the session; and driving with the invitator the session with the restriction. eleven . The computer readable medium according to claim 10, characterized in that the driving includes preventing the guest from taking any action that is consistent with the restriction in the session. The computer readable medium according to claim 10, characterized in that the determination includes a client component that determines whether it can reinforce the restriction in the session. 13. The computer readable medium according to claim 10, characterized in that the determination includes that the guest indicates whether the guest will abide by the restriction in the session. 14. The computer-readable medium according to claim 10, characterized in that the session is initiated by the use of the Session Initiation Protocol. The computer-readable medium according to claim 10, characterized in that the restriction is indicated as an attribute according to the Session Description Protocol. 16. The computer readable medium according to claim 10, characterized in that the session in an instant messaging session. 17. A computer-readable medium containing instructions for controlling a server in order to enforce a restriction in a session, by a method comprising: receiving from an inviter an invitation for a guest to participate in the session with the restriction; record the restriction in the session; receive a message from the session from the guest; determine if the message is consistent with the restriction in the session; and when it is determined that the message is not consistent with the restriction in the session, discard the message. 18. The computer readable medium according to claim 17, characterized in that the discard includes notifying the guest that the guest sent a message that was not consistent with the restriction in the session. 19. The computer readable medium according to claim 17, characterized in that the session is initiated by the use of the Session Initiation Protocol. 20. The computer readable medium according to claim 19, characterized in that the server is a command server.