Maintaining Multiple Chat Relationships With A User

The invention generally relates to instant messaging service. More particularly, the invention relates to maintaining multiple chat relationships with a user. BACKGROUND There is a growing usage of instant messaging service in recent times. Due to the rapid progress in development of internet and mobile services the instant messaging is spreading day by day. It also provides a very good medium for people to communicate with each other or a group of people in real time. The usage of instant messaging is observed both in personal as well as professional domains. The growth and spread of social networking has added more to its relevance. The methodologies of such systems have evolved from just being a one-one or one-many communication to being managing communications with respect to the relations between people or a group of people. People who are either directly or indirectly related over a network can communicate with each other through instant messaging. With such a huge growing number of people’s participation it is thus important to maintain dynamically the relationship between people. Some existing solutions pertain to different aspects and modes in a group conversation communication. As per existing solutions, a user can block a user or set of members in a group conversation session over instant messenger. Few solutions also talk about maintaining specific relation with specific members in that group conversation window. As per the current solutions, if a user prefers to block some particular member in that group conversation, the relationship between the two remains globally set. The user in cases where he blocks some members does not receive the input from those members. The existing solutions also point about flagging off selected content among specific members in a group conversation window. Despite the previously mentioned teachings, it can be said that there is still need to provide for improvements in this area of technology. 3 SUMMARY OF THE INVENTION In accordance with the purposes of the invention, the present invention as embodied and broadly described herein, provides a solution in the domain of group conversations over an instant messaging network. The user can communicate with a particular member of a group of members in a group conversation session. The user can be the administrator of the group conversation session or just a participating member. The solution also considers that the user can communicate with a group of people in active multiple parallel group conversation sessions. These parallel active group conversation sessions may include the same set of users, different set of users or some users that are common to these parallel running group conversation sessions. It is desirable by the user to be involved in such parallel and different sessions of group conversations that are running on different context or subject matter. The value of discussions in such sessions may be entirely different and independent from each other. The method and system according to the present invention rely on the conviction that the user can desire to communicate with other user or group of users preferably based on the context or subject matter of the group communication. As such, the user may prefer not to communicate with a certain user or group of user in an active group conversation over that subject matter. The user may feel that the communication from such users is of no value to him and annoying in particular. Therefore, he may desire to "disallow" such communication with those users in that group conversation session. Performing such an operation as described above, the user will not be made available the communications delivered into the group conversation by those selected users in the user's window. In this way, the user prefers to shield himself from the presumed annoying content to be presented to him. At the same time, this operation of the user may not affect the capacity of those users to actively communicate with other members in the same group conversation session. The user in this case also desires to communicate with a person or group of persons "disallowed" communication in a separate group conversation, which is ongoing in parallel, but on an entirely different context/subject matter. The user does not considers the inputs 4 from those members as annoying for this subject matter. Therefore, the user intends to "allow" the communications with such persons or selective persons from the above list. The system allows the user to practice such preference by providing him the option to "allow" communication with such users in an ongoing different group conversation session. The system at the same time does not affect the user’s preferences with respect to the selected members for other group conversation. Thus, the system allows users to maintain a different relationship status with respect to the same users/members in different group conversation sessions based on different contexts running parallel at the same instance. The system also provides the user flexibility of changing the relationship status at the run time in a group conversation session. Therefore, the user can "disallow" communication from certain members and can also revert the option for selected members in the same group conversation session. The system provides integrated menu options for the user to exercise such preference in runtime. The user when "disallows" communication from certain members may feel left out or may get out of sync from the ongoing group conversation as the user preferred not to view communication from those members. In such cases, the system provides the user with integrated option in the Menu. Utilising this option the user can view the input communication with respect to disallowed users in a separate preview window. The user may prefer to integrate some valid messages from such preview window, which could enable him to be in relevant sync with the ongoing conversation. The system provides much more flexibility to the user in terms of exercising his choice by providing a “partially allow” relationship behaviour. Once the user decides to set the above mentioned relationship behaviour he intends to view only the important context/phrase, or important word entered by the “partially disallowed” user. This will help the user to avoid the presumed annoying content and at the same time remain in active sync with the context in the ongoing group conversation. In this way, the proposed solution provides the user ability to manage the relationship status/behaviour with other members in multiple forms at the same time. The system thus manages many local relationships with respect to two users in multiple group conversation sessions running at the same time. The present solution provides user flexibility, preference, and choice in managing his relationship level for communication over the instant messaging 5 with a specified user or a group of specified users, that too dynamically and in a polymorphic manner. In this way, the user can manage his relationship access with others based on different contexts all running at the same time. These and other features as well as advantages will be more clearly understood from the following detailed description taken in conjunction with the accompanying drawings and claims. BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS: To further clarify advantages and aspects of the invention, a more particular description of the invention will be rendered by reference to specific embodiments thereof, which is illustrated in the appended drawings. It is appreciated that these drawings depict only typical embodiments of the invention and are therefore not to be considered limiting of its scope. The invention will be described and explained with additional specificity and detail with the accompanying drawings in which: Figure 1 illustrates an exemplary method for maintaining a plurality of relationship behaviour with a participant in a plurality of group conversations of an instant messaging service. Figure 2 illustrates an exemplary method for selective access of content in a group conversation of an instant messaging service. Figure 3 illustrates an exemplary computing system to implement above methods. Figures 4-9 illustrate a use case of the invention. Figure 10 illustrate client server architecture for implementing the invention. Figure 11 illustrates a block level representation of the client side system. Figure 12 provides a block level representation of the receiving unit at the client side. Figure 13 provides a block level representation of the system at server side. Figure 14 illustrates the functioning of the processing unit that includes a input parser engine. 6 Figure 15 illustrates a flow chart representation of working of input parser engine. Figure 16 illustrates a representation of frame message of method M1. Figure 17 illustrates a flow chart representation on working of method M1. Figure 18 illustrates a representation of the frame message composed in method M2. Figure 19 illustrates a flow representation on working of method M2. Figure 20 illustrates a flow chart representation on working of method M3. Figure 21 illustrates a flow chart representation on working of method M4. Figure 22 illustrates the functioning of the dynamic updation unit. Figure 23 illustrates a table showing the various categories of messages used at client side. Figure 24 illustrates the general format of the packet used over network. Figure 25 illustrates the category A1 message format. Figure 26 illustrates the category A2 message format. Figure 27 illustrates the category A3 message format. Figure 28 illustrates the category A4 message format. Figure 29 illustrates the representational data structure used for maintaining the database at the client side. Figure 30 illustrates a flow chart representation of the working of the input parser at DYU. Figure 31 illustrates a flow chart representation of the working of method D1. Figure 32 illustrates a flow chart representation of working of method D2. Figure 33 illustrates a flow chart representation of working of method D3. Figure 34 illustrates a flow chart representation of working of method D4. Figure 35 illustrates the message category table at server side. 7 Figure 36 illustrates the database structure used at the server side. Figure 37 illustrates flow chart representation of the working of receiving unit. Figure 38 illustrates flow chart representation of the working of the relationship manager unit. Figure 39 illustrates flow chart representation of the working of method R2. Figure 40 illustrates the TABLE 3 used at the server side. Figure 41 illustrates a flow chart representation of the working of broadcast Unit. It may be noted that to the extent possible, like reference numerals have been used to represent like elements in the drawings. Further, those of ordinary skill in the art will appreciate that elements in the drawings are illustrated for simplicity and may not have been necessarily drawn to scale. For example, the dimensions of some of the elements in the drawings may be exaggerated relative to other elements to help to improve understanding of aspects of the invention. Furthermore, the one or more elements may have been represented in the drawings by conventional symbols, and the drawings may show only those specific details that are pertinent to understanding the embodiments of the invention so as not to obscure the drawings with details that will be readily apparent to those of ordinary skill in the art having benefit of the description herein. DETAILED DESCRIPTION It should be understood at the outset that although illustrative implementations of the embodiments of the present disclosure are illustrated below, the present invention may be implemented using any number of techniques, whether currently known or in existence. The present disclosure should in no way be limited to the illustrative implementations, drawings, and techniques illustrated below, including the exemplary design and implementation illustrated and described herein, but may be modified within the scope of the appended claims along with their full scope of equivalents. The term “some” as used herein is defined as “none, or one, or more than one, or all.” Accordingly, the terms “none,” “one,” “more than one,” “more than one, but not all” or “all” would all fall under the definition of “some.” The term “some embodiments” may refer to no 8 embodiments or to one embodiment or to several embodiments or to all embodiments. Accordingly, the term “some embodiments” is defined as meaning “no embodiment, or one embodiment, or more than one embodiment, or all embodiments.” The terminology and structure employed herein is for describing, teaching and illuminating some embodiments and their specific features and elements and does not limit, restrict or reduce the spirit and scope of the claims or their equivalents. More specifically, any terms used herein such as but not limited to “includes,” “comprises,” “has,” “consists,” and grammatical variants thereof do NOT specify an exact limitation or restriction and certainly do NOT exclude the possible addition of one or more features or elements, unless otherwise stated, and furthermore must NOT be taken to exclude the possible removal of one or more of the listed features and elements, unless otherwise stated with the limiting language “MUST comprise” or “NEEDS TO include.” Whether or not a certain feature or element was limited to being used only once, either way it may still be referred to as “one or more features” or “one or more elements” or “at least one feature” or “at least one element.” Furthermore, the use of the terms “one or more” or “at least one” feature or element do NOT preclude there being none of that feature or element, unless otherwise specified by limiting language such as “there NEEDS to be one or more... ” or “one or more element is REQUIRED.” Unless otherwise defined, all terms, and especially any technical and/or scientific terms, used herein may be taken to have the same meaning as commonly understood by one having an ordinary skill in the art. Reference is made herein to some “embodiments.” It should be understood that an embodiment is an example of a possible implementation of any features and/or elements presented in the attached claims. Some embodiments have been described for the purpose of illuminating one or more of the potential ways in which the specific features and/or elements of the attached claims fulfil the requirements of uniqueness, utility and non-obviousness. Use of the phrases and/or terms such as but not limited to “a first embodiment,” “a further embodiment,” “an alternate embodiment,” “one embodiment,” “an embodiment,” “multiple embodiments,” “some embodiments,” “other embodiments,” “further embodiment”, “furthermore embodiment”, “additional embodiment” or variants thereof do NOT necessarily refer to the same embodiments. Unless otherwise specified, one or more 9 particular features and/or elements described in connection with one or more embodiments may be found in one embodiment, or may be found in more than one embodiment, or may be found in all embodiments, or may be found in no embodiments. Although one or more features and/or elements may be described herein in the context of only a single embodiment, or alternatively in the context of more than one embodiment, or further alternatively in the context of all embodiments, the features and/or elements may instead be provided separately or in any appropriate combination or not at all. Conversely, any features and/or elements described in the context of separate embodiments may alternatively be realized as existing together in the context of a single embodiment. Any and all details set forth herein are used in the context of some embodiments and therefore should NOT be necessarily taken as limiting factors to the attached claims. The attached claims and their legal equivalents can be realized in the context of embodiments other than the ones used as illustrative examples in the description below. Figure 1 illustrates an exemplary method (100) for maintaining a plurality of relationship behaviour with a participant in a plurality of group conversations of an instant messaging service. In one embodiment, the method comprises: receiving (101) a first user input for controlling display of a message received from a participant in a first group conversation from amongst the plurality of group conversations, wherein the first user input is specific to the first group conversation; and filtering (102) the message received from the participant in the first group conversation according to the first user input. In a further embodiment, the first user input is to allow, partially allow, or disallow the message received from the participant in the first group conversation. In a further embodiment, the filtering further comprises completely allowing and/or displaying the message received from the participant in the first group conversation. In a further embodiment, the filtering further comprises completely disallowing and/or blocking the message received from the participant in the first group conversation. In a further embodiment, the completely disallowing and/or the message comprises blocking the message from the participant in a main chat window of the first group conversation. 10 In a further embodiment, the filtering further comprises partially allowing the message received from the participant in the first group conversation. In a further embodiment, the partially allowed message comprises content allowable as per at least one predefined criterion, such as according to a predefined type of words. Examples of such predefined type of words include, but are not limited to subjects, nouns, verbs, etc. In a further embodiment, the partially allowing the message comprises displaying a partial message corresponding to the message received from the participant in a main chat window of the first group conversation. In a further embodiment, all messages received from the participant are indicated in a preview window that is other than a main chat window of the first group conversation. In a further embodiment, all the messages received from the participant are indicated in the preview window using corresponding time stamp. In a further embodiment, one or more messages selected from amongst all the messages are restored to the main chat window upon user request. In a further embodiment, the preview window is dynamically synchronized with the main chat window of the first group conversation. In a further embodiment, the preview window is displayed upon an event with respect to the participant in the first group conversation. In a further embodiment, the first user input is provided through an event with respect to the participant in the first group conversation. In a further embodiment, the event is at least one of right click, left click, long press, double tap, swipe, single tap, pinch gesture, zoom gesture, or a combination thereof. In a further embodiment, the message is a text message, an image message, an icon based message, a voice message, an audio message, a video message, or a combination thereof. In a further embodiment, the method (100) comprises: displaying (103) the filtered message in the first group conversation. 11 In a further embodiment, the method (100) comprises: receiving (104) a second user input for controlling display of a message received from the participant in a second group conversation from amongst the plurality of group conversations, wherein the second user input is specific to the second group conversation and different from the first user input; and filtering (105) the message received from the participant in the second group conversation according to the second user input. In a further embodiment, the method (100) comprises: displaying (106) the filtered message in the second group conversation. Figure 2 illustrates an exemplary method (200) for selective access of content in a group conversation of an instant messaging service. In one embodiment, the method (200) comprises: receiving (201) a user input for partially allowing at least one message received from a participant in a group conversation, wherein the user input is specific to said group conversation; partially allowing (202 the at least one message according to a predefined criterion; and displaying (203) the partially allowed message in a main window of the group conversation. In a further embodiment, the method (200) comprises: receiving (204) a user request to view a complete message corresponding to the partially allowed message; and displaying (205), in response to the user request, a preview window other than the main window of the group conversation, the preview window indicating a timestamp corresponding to the complete message received from the participant. In a further embodiment, the method (200) comprises: receiving (206 a user selection on the time stamp corresponding to the complete message; and displaying (207), in the main window, the complete message corresponding to the selected time stamp. Figure 3 illustrates a computing system (300), which may include a processor (301), a memory (302), an input means (303), a display (304), and a filter (305). In one preferred implementation, the computing system (300) may be a server system or a client system. In another implementation, the computing system’s functionality may be distributed between a client system and a server system. In one embodiment, the computing system (300) maintains a plurality of relationship behaviour with a participant in a plurality of group conversations of an instant messaging service. In said embodiment, the computing system (300) comprises: the input means (303) 12 for receiving a first user input for controlling display of a message received from a participant in a first group conversation from amongst the plurality of group conversations, wherein the first user input is specific to the first group conversation; and the filter (305) for filtering the message received from the participant in the first group conversation according to the first user input. In a further embodiment, the first user input is to allow, partially allow, or disallow the message received from the participant in the first group conversation. In a further embodiment, the filtering further comprises completely allowing and/or displaying the message received from the participant in the first group conversation. In a further embodiment, the filtering further comprises completely disallowing and/or blocking the message received from the participant in the first group conversation. In a further embodiment, the completely disallowing and/or the message comprises blocking the message from the participant in a main chat window of the first group conversation. In a further embodiment, the filtering further comprises partially allowing the message received from the participant in the first group conversation. In a further embodiment, the partially allowed message comprises content allowable as per at least one predefined criterion, such as according to a predefined type of words. Examples of such predefined type of words include, but are not limited to subjects, nouns, verbs, etc. In a further embodiment, the partially allowing the message comprises displaying a partial message corresponding to the message received from the participant in a main chat window of the first group conversation. In a further embodiment, all messages received from the participant are indicated in a preview window that is other than a main chat window of the first group conversation. In a further embodiment, all the messages received from the participant are indicated in the preview window using corresponding time stamp. In a further embodiment, one or more messages selected from amongst all the messages are restored to the main chat window upon user request. 13 In a further embodiment, the preview window is dynamically synchronized with the main chat window of the first group conversation. In a further embodiment, the preview window is displayed upon an event with respect to the participant in the first group conversation. In a further embodiment, the first user input is provided through an event with respect to the participant in the first group conversation. In a further embodiment, the event is at least one of right click, left click, long press, double tap, swipe, single tap, pinch gesture, zoom gesture, or a combination thereof. In a further embodiment, the message is a text message, an image message, an icon based message, a voice message, an audio message, a video message, or a combination thereof. In a further embodiment, the inputs means further receive a second user input for controlling display of a message received from the participant in a second group conversation from amongst the plurality of group conversations, wherein the second user input is specific to the second group conversation and different from the first user input; and the filter is further configured to filter the message received from the participant in the second group conversation according to the second user input. In another embodiment, the computing system (300) provides selective access of content in a group conversation of an instant messaging service. In said embodiment, the computing system (300) comprises: the input means (303) for receiving a user input for partially allowing at least one message received from a participant in a group conversation, wherein the user input is specific to said group conversation; the filter (305) for partially allowing the at least one message according to a predefined criterion; and the display screen (304) a display screen for displaying the partially allowed message in a main window of the group conversation. In a further embodiment, the input means (303) further receive a user request to view a complete message corresponding to the partially allowed message; and the display screen (304) is further configured to display, in response to the user request, a preview window other than the main window of the group conversation, the preview window indicating a timestamp corresponding to the complete message received from the participant. 14 In a further embodiment, the input means (303) further receive a user selection on the time stamp corresponding to the complete message; and the display screen (304) is further configured to display, in the main window, the complete message corresponding to the selected time stamp. The present invention aims to address the ‘N’ number of users who are connected over instant messaging network. Here, N is any positive integer. The users are allowed to maintain multiple relations with each other during the ongoing parallel multiple group conversation sessions over the network. The general working of the system with respect to user is explained below with reference to Figures 4-9. As shown, client A can exist in multiple group conversation sessions with other users at the same time (4000). The client A, maintains a “disallow” relationship with user C in “technical discussion” session at the same time client A maintains a “partial allow” relationship with user C in “political affairs” session & a “allow” relationship in “team event planning” group conversation sessions. The client A could not maintain multiple relationship behaviour with a particular member on group conversation sessions running in parallel based on different context in the existing systems (5000). The existing systems tend to observe a global behaviour of relationship between users connected over an instant messaging network. The Client A is provided a graphical option to set his relationship behaviour with members in a group conversation session. If the Client A, decides to “disallow” communication from User F, the content from USER F will not be made available to client A (6000). At the same time, if the client A decides to opt for the “partial allow” option, then the communication from user F will be partially displayed to client A (7000). By partial display we mean that using existing techniques, only the important context of the typed message will be displayed to client A and not the complete text input by user F. The Client A, is also provided the graphical option to view the blocked content with respect to a certain member in a group conversation session (8000). The client A, can also highlight selective messages in the provided view from the list of disallowed communication and the highlighted timestamps will be used to integrate the respective text messages back into the ongoing conversation session window dynamically. The user can now easily scroll back to have a stronger grasp of the ongoing conversation with respect to the disallowed member (9000). The main advantage of the present invention is that it provides the user much flexibility and choice in maintaining a relationship behaviour with respect to other members on the instant messaging network. This proves particular advantageous in professional 15 situations, where there is a need to maintain parallel group conversation sessions based on different contexts. The user now will have a choice to exercise his choice with respect to a member without in a way affecting his comfort level as well as taking care of professional goals. The system does not limit itself to any particular social networking domain and does not assume or discard the existence of relationships between participating member in the instant messaging network. The invention does not limit itself to particular architectural design for implementation across networks. The method is scalable across a particular instant messaging service or a group of instant messaging service governed by a central instant messaging network. The invention provides user much flexibility with respect to viewing a communication from certain member, which may be in particular emotionally disturbing for the user. The Invention is scalable to be implemented easily across different computing devices including the touch based computing devices or gesture based computing devices. The invention can also be scaled across various different ways of getting input from external devices for example using joysticks or stylus etc. Though the invention is further described based on a client and server architecture, yet those skilled in the art will appreciate that the invention is not restricted by the same and can be implemented in a similar system on client-client basis or only on the local client system side basis. The basic description of the units employed at each side is as follows: CLIENT SIDE SYSTEM The individual users who are the members of the group conversation session are the referred clients in the solutions. The clients are hosted on different computing devices, which are connected to the network via a centralized server offering the services of instant messaging. The system of client side will be composed of the modules listed in Table 1 below: 1 DISPLAY UNIT This is Hardware I/O unit which presents the user interface to the client/user 2 PROCESSING UNIT This module is responsible for processing the directed Inputs from the User and the database. 3 DYNAMIC UPDATION UNIT This module processes the runtime inputs from the Receiving unit, Database and the processing unit and presents a dynamic updated chat structure to be displayed to the user. 16 4 NETWORK RECEIVING UNIT This module receives the output from the display unit, processes it and outputs to the server. It also receives the inputs from the server, processes it and outputs to the Dynamic updation unit. 5 STORAGE UNIT This is storage memory unit where the referred database will be maintained. Table 1 SERVER SIDE SYSTEM The individual clients who are participating in the instant messaging sessions will be centrally controlled by the Server. The proposed system is integrated on the server end. The system on the server side will be composed of the modules listed in Table 2 below: 1 RECEIVING UNIT This module is responsible for maintaining active connections with clients & receiving the input from the clients over the network and passing it to processing unit. 2 RELATIONSHIP MANAGER UNIT This Module is responsible for maintaining the relationship of the user with individual members in different group conversation sessions active on the client window. 3 BROADCAST UNIT This module receives formatted packet from RM unit and broadcasts to provided clients in the network. 4 STORAGE UNIT The RM unit maintains this database, actively managing the relationship behaviour among members in different group conversation sessions. Table 2 Figure 10 illustrates a client (1001) and server (1002) architecture (1000) being followed by the system. The proposed system which gets implemented at the client side will be responsible to provide the user with the relevant display options to exercise his choices. The system does not intend to take care of how multiple group conversation sessions are started and how the members are added in the individual group conversation sessions. The System employs methods to provide the user with options: (a) To set a relationship behaviour 17 with any participating member in any of the ongoing group conversation sessions; (b) To provide the user menu options to be able to view the blocked content with respect to a specific user; (c) To provide user with options to selectively integrate the blocked content from a member into the current conversation window dynamically updating the ongoing conversation session; (d) To provide the user with menu options to set the relationship behaviour with respect to selected members in multiple groups at the same time; (e) To provide the functionality of transmitting the users relationship preferences when updated at the client side to server in a special formatted message. Figure 11 illustrates block level representation (1100) of the client side system, which includes a processing unit (1101), a display unit (1102), a dynamic updation unit (1103), a receving unit (1104), a database (1105), and network (1106). The processing unit (1101) performs the following functions: (a) To collect the input from the display unit. The input in itself can be either an event performed by the user or the data selected by the user from the output of the event performed; (b) The user can perform two events which are specified by the system. The user can perform the “right click” event on a member or can perform a “left click” of mouse event on a member active in a group conversation; (c) The “right click” event will allow the user to be displayed the choice of either selecting to “disallow” or “allow” communication from that member; (d) The “left click” event will allow the user to be displayed the set of messages logged in by the member from the time instance he was disallowed communication (let’s call this as Td) till the current time(Tc).The user once displayed the list of messages as per their occurrence timestamp can now select by highlighting the specific messages he wants to integrate back into the group conversation window; (e) The data highlighted by the user in step 4 will be provided as input to the parser engine; and (f) The parser engine routes the control to relevant methods M1, M2, M3 or M4 as per suitable calculations. The user interacts with the display unit (1102). The system provides the user with options to perform two basic events: (1) Event 1: “right click“ or simple Tap function over the displayed icon of the member in the group conversation session. This indicates the change of the relationship (allowed or disallowed). This can also be a “double Tap” or “double touch” function performed over the displayed icon of the member on a touch user interface based systems. This indicates the change of relationship to “Partial Allow” from either “allowed or not allowed” relationships between the chat users. The event 1 can also be 18 realized in terms of gesture-based technologies in future. The user will be presented with the choice to either “disallow” or “allow” or “partially allow” communication from that particular member. (2) Event 2: “left click” or long press or three tap function over the displayed icon of the member in the group conversation session. This brings a pop-up of a disallowed user with all his timestamps. User can choose a timeline to see that content. For an allowed user all his content with timestamps are visible in a pop-up. User can choose a timeline to remove that content from the chat. The event 2 can also be realized in terms of gesture-based technologies in future. The user will be presented with the content of the messages input into that group conversation session by that member since the time the communication was disallowed from him (Td) until current time (Tc). The dynamic update unit (1103) performs the following functions: (a) To prepare the instance of “current Database” and provide it to the display unit and store it in the database storage (1105); (b) The “current Database” signifies the dynamically updated Database visible to the user. This is prepared by the usual inputs of participating members from the network (1106) as well as the Retrieved disallowed communication data content by the user with respect to a specific member in the group conversation session; (c) The user exercises his “choice” of changing the relationship behaviour with respect to a particular member. The DYU creates this special category message (category A2) informing the central server about the users choice; (d).If the choice contains the value “partial allow” then the DYU does not create a special category ‘A2’ message to be send to server. In this case the DYU just maintains a record of the user’s choice and will apply this on the messages received from that member from the network t its end; (e) the DYU also performs the function of receiving the normal conversation packets from the network and integrating them in the “current Database” as well as stored database. Here the DYU takes particular care of the “partial allow” option and applies known methods to extract the central context of the message before integrating it into the “current database”; (f) The DYU is also responsible for retrieving the disallowed communication with respect to a certain member within a certain time frame (Td<->Tc) from network. This is achieved by creating a special category (category A3) retrieval request message to server; (g) The DYU is also responsible for integrating the highlighted content in the displayed disallowed content to the “current Database” and output it to the display unit; and 8. The DYU is also responsible for parsing the messages received from server. The messages can be of category A1(normal conversation messages ) or category A4 (request retrieval messages).The DYU processes the Category A4 messages, retrieves the data content 19 from the client stored database and sends the response to A4 back to the server in a composed list. The input parser engine for the dynamic update unit (1103) performs the following functionality: (a) the input parser engine in DYU receives input from the Receiving unit, the Processing unit, The display unit; (b) If the message is sent by the Display unit, method D1 is executed; (c) If the message is sent by the Processing unit, method D2 is executed; (d) If the message is sent by the Receiving unit, method D3 is executed; and (e) If no messages received the input parser maintains itself in idle/No Op state and continuously polls for the input. The receiving unit (1104) is a simple module, which performs the following functions: (a) To Receive the Incoming message packets over the network. These message are sent by the server to the client; (b) To transmit the messages from client to the server. This includes transmitting all A1, A2, A3, A4 category defined messages as standard messages over the network; (c) To interact directly with the Dynamic updation unit and the display unit; and (d) To implement the standard available network protocols to perform its functioning. Figure 12 provides a block level representation (1200) of the receiving unit (1104) at the client side. The receiving unit (1104) continuously receives input form the display unit, dynamic updation unit, and the network. If network is the sender, then signal is sent to dynamic updation unit. If network is not the sender, them the message to be sent if first standardized and then sent to the network. Figure 13 provides a block level representation (1300) of the system at server side, which includes a receiving unit (1301), a relationship manger unit (1302), a broadcast unit (1303), a database storage unit (1304), and network (1305). The server side system will perform the following functions. (a) The system will be responsible for inter-communication (reception & transmission) of the messages from 'N' number of clients connected to the instant messaging network. (b) The system will manage the Dynamic relationships between the number of users connected to each other in various group conversation sessions across the network (1304). (c) The system will also manage the "disallow" & "allow" choices of the user and accordingly filter the communication at its side, so that the intended user will not be transmitted the packets from the disallowed member. (d) The System will also manage and assist the user to retrieve the "disallowed" data with respect to certain member (client). (e) 20 The system continuously updates its database (1304) as per the current relationship behaviour among different clients across different group conversation sessions. (f) The system does not maintain any kind of storage of communication data between the connected clients at its end. The receiving unit (1301) at the server side performs the following functions: (a) continuously receives the packets from the instant messaging network; (b) delivers the received messages to the relationship manager unit or the broadcast unit; (c) provides the access to the message category table and clearly distinguishes between the various categories of the messages received. Further, the receiving unit employs method R1 to determine the correct receiver of the packets received from the network. The relationship manager (1302) can be described to be one of the core component at the server end. It performs the following functions. It manages the dynamic relationship behaviour of the different clients with respect to each other. A database table is maintained at the server side that keeps track of the current relationship of the user with respect to other members per group conversation session. It also processes the special category 'A3' message. This a retrieval request from the user. It employs method R2 to process the 'A3" request and create a 'A4' type packet to retrieve the messages from the intended client. It passes on the messages of 'A1' category to the broadcast unit. The broadcast unit (1303) performs the following functions at the server side: It is responsible for transmitting the message packets to the network. It can receive the messages either from the receiving unit or through the Relationship manager (RM) unit. If the messages are received from the RM unit, the messages are broadcast to the respective clients. The Broadcast unit accesses the database table corresponding to the group id in the message. It then populates the list of clients that are authorized for this message and broadcast the message to those members only. If the message if from Receiving unit, then it’s a response to a category ‘A4’ message. It accesses the TABLE 3 and determines the receiver client Id and the message is transmitted to that intended receiver only. Figure 14 illustrates the functioning of the processing unit that includes an input parser engine (1401), which receives inputs from a display I/O unit (1402) and dynamic updation unit (1403). The input is received by this parser continuously. The parser polls for the input infinitely. If the input is “Event 1”, then method M1 is executed by the parser engine. If the input is “Event 2”, then the parser engine checks. If it is a command type from user to present the data or input type with user selected data that needs to be dynamically 21 integrated. If “Event 2” is command type then method M2 is executed by the parser engine else if it is data input type then method M4 is executed by the parser engine. If the input is sent from the Dynamic updation unit, then method M3 is executed by the parser engine. Figure 15 illustrates a flow chart representation (1500) of working of input parser engine that performs pooling for input (1501). If sender is dynamic updation unit (1502), then method M3 is performed (1503). Otherwise, it is checked if event 1 is performed (1504) – If yes, then method M1 is performed (1505). Otherwise, it is checked if event 2 is performed (1506)– if yes, then method M2 is called (1507). Otherwise Method M4 is called (1508). Figure 16 illustrates a representation (1600) of frame message of method M1, while Figure 17 illustrates a flow chart representation (1700) on working of method M1. As shown, group id, member id, choice is collected from the user (1701). After that, the time instance Td is determined (1702). In the end, the message is prepared with group id, member id, choice which is passed to the dynamic updation unit for performing an update into TABLE[Group Id] in the Database (1703). Figure 18 illustrates a representation (1800) of the frame message composed in method M2, while the Figure 19 illustrates a flow representation (1900) on working of method M2. Firstly, the input from parser engine contains the Group id, member Id (1901). After that, the current time instance Tc is determined (1902). Then, the Last updated Time instance for “disallow” Td is to be determined (1903). The information is fetched from accessing TABLE[Group Id] from the Database. The time instance Td is fetched. The above information, [Group Id, member Id, Td, Tc] is framed in a message, which is passed on to the dynamic updation unit (1904). Similarly, Figure 20 illustrates a flow chart representation (2000) on working of method M3. Firstly, the Input from parser engine contains a message frame with information such as group Id, member Id, and the list of messages for that member from time Td till Time Tc fetched from the server by dynamic updation unit (2001). After that, the Messages are segregated from the frame (2002). The Input to the display Unit will consist of respective timestamps being displayed to the user in a preview window (2003). Similarly, Figure 21 illustrates a flow chart representation (2100) on working of method M4. Firstly, the inputs from parser engine contain the group id, member id and the index of the highlighted timestamps from the preview shown by method M3 (2101). After 22 that, the messages are selected by their indexes framed in a new packet with group id, member id and delivered to the dynamic updation unit (2102). Figure 22 illustrates the functioning (2200) of the dynamic updation unit. Here, input parser engine (2202) received inputs from the processing unit (2204), display unit (2201), and receiving unit (2203) and directly/indirectly calls methods D1, D2, D3, or D4. These methods continuously update the database storage unit (2205) and the display unit (2201). Current Database is a database containing the current content, which is being displayed in the group conversation window. This includes the message being received from other members in the conversation session. This includes the messages being received from the other members in the conversation session. This also includes the provided highlighted messages from the user. These highlighted messages are from the past data of the disallowed communication. This data is dynamically integrated into this database. The messages that are input by the user itself are also present in the current database. Stored Database is a database that is locally stored on the client storage unit. This is restricted copy of the current database. This does not include the disallowed communication data with respect to a certain member. In this way, the system does not store the disallowed communication data at the client side. It performs a data retrieval process from the network for the same on user’s request. The various categories of messages maintained by the system as demonstrated below. Figure 23 illustrates a table (2300) showing the various categories of messages used at client side. Figure 24 illustrates the general format (2400) of the packet used over network. Figure 25 illustrates the category A1 message format (2500). Figure 26 illustrates the category A2 message format (2600). Figure 27 illustrates the category A3 message format (2700). Figure 28 illustrates the category A4 message format (2800). 23 Figure 29 illustrates the representational data structure (2900) used for maintaining the database at the client side. Figure 30 illustrates a flow chart representation (3000) of the working of the input parser at DYU. It starts with polling for input (3001), then it is checked whether sender is the display unit (3002). If yes. Then method D1 is called (3003). Otherwise, it is checked whether the sender is processing unit (3004). If yes, then method (D2) is called (3005). Otherwise, it is checked whether the sender is receiving unit (3006). If yes, then method D3 is called (3007). Otherwise, the process goes to ideal state (3008), but keeps on polling for input (3001). Figure 31 illustrates a flow chart representation (3100) of the working of method D1. Firstly, the input from display unit here includes the data content inserted by the client in ongoing group conversation session (3101). After that, the input includes the group Id, Client id & the message itself (3102). The “current Database” is updated with the input message, The method D4 is executed in this way (3103). Figure 32 illustrates a flow chart representation (3200) of working of method D2. Firstly, the input is parsed based on the category of the message frame (3201). It is checked if the category is ‘A5’ (3202), the message contains the group id, member id, choice (3203). It is checked if the category is ‘A6’ (3205), the message contains the group id, member id, Td, Tc (3206). It is checked if the category is ‘A7’ (3207), the message contains the group id, member id, index of highlighted disallowed messages (3208). Each of these messages is sent to receiving unit (3204). The category ‘A5’ is processed by creating a special category ‘A2’ request message to be sent over the network to the server. The category ‘A6’ is processed by creating a special category retrieval request message ‘A3’ to be sent over the network to the server. The category ‘A7’ is processed by integrating the provided list of highlighted disallowed communication data into the “current database”. This data is not updated in the “stored database”. In the end, the process goes to ideal state (3209), but keeps on polling for input (3201). Figure 33 illustrates a flow chart representation (3300) of the working of method D3. The input from the network can contains the messages of category A1, A4. If the message is category ‘A1’,the Client id, group Id is retrieved from the message. The Data content is also parsed. The message is then appropriately updated in the “current Database”. The method D4 then is executed to store it in “stored database”. If the message is category ‘A4’, then it is a 24 Data retrieval request from the server. The message is parsed and the values of Td & Tc are extracted along with the Group Id. The Data content from the “stored Database” is accessed and the messages which lie within the timestamp Td to Tc are fetched. The messages selected have timestamp t >Td and t