Limiting access to network functions based on personal characteristics of the user

FIELD OF THE INVENTION

This invention relates in general to computer networking, and more particularly to limiting access to network functions based on personal characteristics of the user.

BACKGROUND OF THE INVENTION

Technologies such as instant messaging (IM) have become increasingly popular to users of both mobile and non-mobile computing devices. These messaging technologies allow text and other data (e.g., multimedia content) to be exchanged between network users on a real-time or near-real-time basis. The text-based nature of the communications allows users to exchange thoughts in real-time without the distractions inherent in voice communications. Thus, people can engage in an IM conversation while continuing to do other things, such as work on a computer or listen to a lecture.

Some of the most enthusiastic adopters of IM and related technologies are young people. More young people own IM-capable cell phones or other mobile devices, and IM becomes a convenient yet innocuous way to communicate with friends. In addition, many young people, especially, teenagers, use IM as a way to meet new people, such as in Internet chat rooms or IM chat groups.

The use of IM technologies by young people presents hazards to the participants. It is well known that predators sometimes try to engage in conversation with children on chat rooms. As a result, providers of IM related services must find ways to provide a safe environment for young people to engage in appropriate interactions using data networks. Improving the safety of IM services for children is not only good business practice, but may also be a requirement as laws are developed to help protect children and other vulnerable people who engage in communication over publicly accessible networks. The present disclosure is directed to improvements in safety of communication technologies such as IM.

SUMMARY OF THE INVENTION

To overcome limitations in the prior art described above, and to overcome other limitations that will become apparent upon reading and understanding the present specification, the present invention discloses a system, apparatus and method for limiting session access and filtering user profile and group searches based on personal information of a user.

In accordance with one embodiment of the invention, a method for establishing a data communications session involves determining a personal characteristic associated with a user of a terminal. A predetermined criterion for allowing establishment of the data communications session based on the personal characteristic is obtained. A token is embedded in a signaling message used to establish the data communications session. The token represents at least one of the personal characteristic and the predetermined criterion. The signaling message is communicated with a network entity capable of allowing users to establish the data communications session. The data communications session is established via the network entity if the personal characteristic satisfies the predetermined criterion.

In more particular embodiments, the personal characteristic includes the user's age. The personal characteristic of the user may be obtained from a network accessible user profile database. In one arrangement, embedding the token in the signaling message comprises embedding the token in at least one of an Accept-Contact and a Contact header of a Session Initiation Protocol (SIP) INVITE message. Embedding the token in the signaling message may involve intercepting the session establishment request at an intermediary server and embedding the token in the signaling message via the intermediary server. Establishment of the data communications session may involve any combination of allowing membership into an instant messaging group, allowing membership into a push-to-talk communications group, and/or establishing the data communication session between two or more users.

In another embodiment of the invention, a method for searching for communication endpoints accessible via a network involves determining a criterion related to a personal characteristic of a user. A token is embedded in a signaling message used to initiate the search. The token represents at least one of the criterion and the personal characteristic. A search result is obtained in response to the signaling message. The search result is filtered by excluding endpoints referenced in the search results that do not satisfy the criterion, and the filtered search result is returned to an initiator of the signaling message.

In another embodiment of the invention, a data processing arrangement includes a network interface capable of communicating via a network. A processor is coupled to the network interface, and a memory is coupled to the processor. The memory includes instructions that cause the processor to receive a signaling message from a terminal via the network. The signaling message includes at least one of a personal characteristic of a user of the terminal and a predetermined criterion related to the personal characteristic. A network service is provided to the terminal via the data processing arrangement in response to the signaling message based on whether the personal characteristic satisfies the predetermined criterion.

In a more particular embodiment, the data processing further includes an instant messaging server module. The instructions are configure to establish an instant messaging session between the terminal and at least one other user via the instant messaging module in response to the signaling message if the personal characteristic satisfies the predetermined criterion.

In another more particular embodiment, the data processing further includes a push-to-talk server module. The instructions are configured to establish a push-to-talk session between the terminal and at least one other user via the push-to-talk server module in response to the signaling message if the personal characteristic satisfies the predetermined criterion.

In another more particular embodiment, the data processing further includes a search module configured to provide a search result containing descriptions of individual communication endpoints accessible via the network in response to the signaling message. The instructions are configured to filter individual descriptions of the search result based on whether the descriptions satisfy the predetermined criterion.

In other more particular embodiments the signaling message includes the predetermined criterion, and the instructions are configured to determine the personal characteristic via a user profile database accessible via the network. Alternatively, the signaling message may include the personal characteristic, and the instructions are configured to obtain the predetermined criterion via a database.

These and various other advantages and features of novelty which characterize the invention are pointed out with particularity in the claims annexed hereto and form a part hereof. However, for a better understanding of the invention, its advantages, and the objects obtained by its use, reference should be made to the drawings which form a further part hereof, and to accompanying descriptive matter, in which there are illustrated and described representative examples of systems, apparatuses, and methods in accordance with the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention is described in connection with the embodiments illustrated in the following diagrams.

<figref idrefs="DRAWINGS">FIG. 1</figref> is a block diagram illustrating a system according to an embodiment of the invention;

<figref idrefs="DRAWINGS">FIG. 2</figref> is a block diagram illustrating a SIP-based instant messaging system according to an embodiment of the invention;

<figref idrefs="DRAWINGS">FIG. 3</figref> is a block diagram illustrating protocols used by a SIP-based instant messaging system according to an embodiment of the invention;

<figref idrefs="DRAWINGS">FIG. 4A</figref> is a sequence diagram illustrating local network verification of personal characteristics to determine whether a data communications session should be established according to an embodiment of the invention;

<figref idrefs="DRAWINGS">FIG. 4B</figref> is a sequence diagram illustrating remote network verification of personal characteristics to determine whether a data communications session should be established according to an embodiment of the invention;

<figref idrefs="DRAWINGS">FIG. 5A</figref> is a sequence diagram illustrating originating terminal verification of personal characteristics to determine whether a data communications session should be established according to an embodiment of the invention;

<figref idrefs="DRAWINGS">FIG. 5B</figref> is a sequence diagram illustrating verification of personal characteristics to determine whether joining a server-initiated data communications session should be allowed according to an embodiment of the invention;

<figref idrefs="DRAWINGS">FIG. 5C</figref> is a sequence diagram illustrating verification of personal characteristics via a network-to-network interface to determine whether a data communications session should be established according to an embodiment of the invention;

<figref idrefs="DRAWINGS">FIG. 6</figref> is a block diagram illustrating a terminal device according to an embodiment of the invention;

<figref idrefs="DRAWINGS">FIG. 7</figref> is a block diagram illustrating a server device according to an embodiment of the invention;

<figref idrefs="DRAWINGS">FIG. 8</figref> is a flowchart illustrating a procedure for establishing a data communications session according to an embodiment of the invention; and

<figref idrefs="DRAWINGS">FIG. 9</figref> is a flowchart illustrating a procedure for performing a network search according to an embodiment of the invention.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

In the following description of various exemplary embodiments, reference is made to the accompanying drawings that form a part hereof, and in which is shown by way of illustration various embodiments in which the invention may be practiced. It is to be understood that other embodiments may be utilized, as structural and operational changes may be made without departing from the scope of the present invention.

Generally, the present invention falls within the area of instant digital communications, such as Instant Messaging (IM) and Push-to-Talk (PTT) over Cellular (PoC). IM services are already deployed using several proprietary technologies and open standards such as Wireless Village. Another IM standard is developing that is built on top the increasingly ubiquitous Session Initiation Protocol (SIP). SIP is a signaling protocol that assists digital devices in establishing end-to-end communications sessions. SIP provides features that resemble those provided by the Public Switch Telephone Network (PSTN) as well as Internet protocols such as Transmission Control Protocol/Internet Protocol (TCP/IP) and Hypertext Transfer Protocol (HTTP).

SIP was initially developed for use with voice and video communications technologies, such as Voice over IP (VoIP). SIP has also been adapted to support services collectively known as Instant Messaging and Presence. In particular, the Internet Engineering Task Force (IETF) has a working group for defining SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE). SIMPLE is a developing Instant Messaging and Presence standard for using SIP and related technologies for various functions such as transport of messages, delivery confirmation, and communicating presence status of end users. The Open Mobile Alliance (OMA) has chosen SIP/SIMPLE protocol for Instant Messaging and Presence Services. OMA services are utilizing IMS architecture developed by 3^rdGeneration Partnership Project (3GPP).

The objective of OMA SIMPLE IM is to define a complete IM system specification for SIP/IP networks. The features of such an IM system may include: one-to-one and one-to-many one-shot messaging, lists that can be shared with other applications (e.g. PoC or presence), one-to-one session-based messaging, “chatrooms” or messaging conferences, and interoperability with other media (e.g. PoC). One goal of the SIMPLE specification is to keep the system components interoperable with other IETF protocol specifications.

Teenagers are one important user segment for IM services. Due to international laws for child protection, operators are very interested to develop mechanisms for child protection in IM services. Generally, this protection involves allowing or denying access to communication groups based on the user's age. Therefore, OMA SIP/SIMPLE based IM and PoC standards should provide mechanisms for operators to be able to restrict access to services based on user age.

Although the present disclosure describes restricting group admission based on age, it will be appreciated that other personal characteristics may also be used to restrict or allow access. For example, personal characteristics such as gender, location (e.g., city or country), membership in certain social groups, language, interests, etc., may be used to control actions related to joining in communications sessions. These characteristics may be used alone or in any combination. The present invention may also be directed to other communication functions besides admissions. For example, personal characteristics could be the basis for limiting the transmission of certain types of data during the session (e.g., prevent transfer of images or executable files based on age), controlling the formatting of session data (e.g., control character sets used based on native language), determining maximum allowable connect/session times, etc.

The embodiments of the invention may be described herein in the context of SIMPLE-based IM and presence services. Those skilled in the art will appreciate, however, that these concepts may be applied to other IM standards, as well as to other communications frameworks similar to IM. For example, age and other personal characteristics can be used to control access to PTT/PoC groups, voice communications, video teleconferencing, etc.

In reference now to <figref idrefs="DRAWINGS">FIG. 1</figref>, a block diagram illustrates various concepts associated with modifying network access based on a user's personal characteristics according to embodiments of the invention. Generally, a user <b>100</b> has a communications device <b>102</b> capable of communicating via one or more data networks <b>104</b>, <b>106</b>. One communication service provided by the networks is the capability to form communications groups <b>108</b>, <b>110</b>. These groups <b>108</b>, <b>110</b> may allow similar or different devices to intercommunicate using standard media and protocols. For example, the members of the groups <b>108</b>, <b>110</b> may communicate using text messages transmitted via SIMPLE.

The networks may also provide for point-to-point communications, such as a one-to-one session between user terminal <b>104</b> and another terminal <b>112</b>. Whether the user <b>100</b> intends to communicate with a single terminal <b>112</b> or a group <b>108</b>, <b>110</b>, an important aspect is whether to allow the connection to occur. Previously, this determination hinged solely on technical issues (e.g., compatible media and protocols), but may be expanded to limit communications based on personal characteristics, particularly age.

Another important aspect in initiating communications with single terminals <b>112</b> or groups <b>108</b>, <b>110</b> relates to the discovery of users and groups. Network users may exchange contact information with acquaintances using traditional means (e.g., via telephone or email). This type of discovery does not necessarily require the use of the communications networks <b>104</b>, <b>106</b> at all. However, it may be advantageous to provide search capabilities via the communications networks <b>104</b>, <b>106</b> so that users may search for other individuals or groups of interest based on keywords or other descriptors.

The OMA SIP/SIMPLE IM uses a general solution for network data access that may be extended for use in search. Data access in SIP/SIMPLE IM is based on eXtensible Markup Language (XML) Document Management (XDM) enabler. The XDM defines a mechanism that makes network-accessible user information available to service enablers such as IM and PoC. This user information is defined in XML documents, and XDM defines protocols and procedures used to locate, access and modify such information via the network. The XDM enablers rely on the XML Configuration Access Protocol (XCAP) as the common protocol for manipulating these XML documents. In addition, XDM utilizes SIP subscription/notification mechanisms for notifying principals of changes to such documents

Search mechanisms should be able to take into account personal characteristics of the user <b>100</b> in order to limit who can discover the user's identity, as well as whom the user <b>100</b> can discover (e.g., based on age). In particular, child protection features should be extended to cover the initiation of IM communication sessions and for user/group search. XDM enablers (or related search frameworks) can achieve this goal by allowing service providers to confine the results of searches based on personal characteristics. For example, the service provider's policy could prohibit searches on children under the age of eighteen. Similarly, if an IM server has age restriction for searching, then the restricting server should exclude those users from the search results who are under the restricted age as determined by their Public Profile <b>114</b>.

Similarly, it is desirable for a user's personal characteristics to be determined as part of and access policy when joining in chat group or other session. For example, a moderator element such as an IM server <b>116</b> should allow group administrators to specify a minimum age requirement for joining chat groups, such as the restriction <b>118</b> indicated for group <b>108</b>. Similarly, the server <b>116</b> should prevent those users that are under an age specified in the group properties to join the group, such as the restriction <b>120</b> indicated for group <b>110</b>.

The IM server <b>116</b> controls whether new members are able to join chat groups <b>108</b>, <b>110</b>. Information on group characteristics (e.g., age limitations for group membership) is in an IM XDM Server (XDMS) <b>122</b>. An XDMS is a logical repository in the network used for storing XML documents associated with a particular functional entity. Thus, the IM XDMS <b>122</b> stores data related to various IM users and groups, and a Profile XDMS <b>124</b> stores user profile information (e.g., data that includes user's age). It will be appreciated that the IM server <b>116</b> may also define groups for purposes of one-to-one and one-to-many ad hoc sessions. These ad hoc groups may exist only so long as the sessions are active. The concepts described herein related to limiting establishment of such sessions based on age (or other characteristics) also applicable to ad hoc sessions.

In order to determine whether the user <b>100</b> may join a group <b>108</b>, <b>110</b> based on age or other personal characteristic, the IM server <b>116</b> needs to access both the IM XDMS <b>122</b> in order to determine the group policies, as well as a Profile XDMS <b>124</b> in order to view the user's public profile <b>114</b>. Generally, the XCAP allows clients to read, write and modify application configuration data, stored in XML format on a server. XCAP maps XML document sub-trees and element attributes to HTTP URIs, so that these components can be directly accessed by HTTP. Therefore, the IM server <b>116</b> can access the IM XDMS <b>122</b> and Profile XDMS using XCAP.

Other network entities may also have a need to access various XDMS. In particular, a Search server <b>126</b> can use XCAP to access the Profile XDMS <b>124</b> and IM XDMS <b>122</b> in order to match users with desired groups, and vice versa. The Search server <b>126</b> will also need to be aware of age limitations associated with users and groups in order to apply to proper filtering of results.

If operations relating to searching and joining of sessions are all performed in same network (e.g., network <b>104</b>), the IM server <b>116</b> and Search server <b>126</b> can access a local Profile XDMS (not shown) and fetch user profiles with age information when required. However, in the illustrated arrangement, the Profile XDMS <b>124</b> is located on a different network <b>106</b> than the network <b>104</b> of the IM server <b>116</b> controlling the group sessions. This is a common case when the user <b>100</b> is roaming, because the Profile XDMS <b>124</b> is located at the home network <b>106</b>, yet the user's device <b>102</b> and/or the groups <b>108</b>, <b>110</b> may be on a different network <b>104</b>.

The IM server <b>116</b> in network <b>104</b> may be able to access the Profile XDMS <b>124</b> in another network <b>106</b> in order to fetch the joining user's user profile <b>114</b>. In one example, these inter-network data transfers can be accomplished via an XCAP network-to-network interface (XCAP NNI) <b>128</b>. One problem with this approach is that the NNI <b>128</b> is optional, and may not be implemented in all networks. Another problem is that user profile fetching in this way generates an unnecessarily heavy load for that particular interface <b>128</b>.

A similar problem arises as to the Search server <b>126</b>. The Search server <b>126</b> may need to perform searches on group characteristics (e.g., age limitation for group joining) and user profiles (e.g., containing user's age). However, if the IM XDMS <b>122</b> and Profile XDMS <b>124</b> are in different networks <b>104</b>, <b>106</b>, then the data transfer may either be impossible or place too heavy a burden on the NNI <b>128</b>.

In one embodiment of the present invention, mechanisms are used to embed the personal information into search request sent between networks. One use of this age information (from the user profile) to limit access to chat groups or limiting of search results, but the presented mechanism can be utilized for other user profile information (e.g., country, city) as well. The personal information can also be embedded in session establishment requests, so that a controlling authority such as the IM server <b>116</b> can decide whether to allow access based on the request itself, rather than requiring a separate inter-network profile lookup.

In reference now to <figref idrefs="DRAWINGS">FIG. 2</figref>, a block diagram illustrates a more detailed view of an OMA architecture for IM and PoC service according to an embodiment of the invention. The functional elements are shown for two networks <b>200</b>, <b>201</b>. Only a subset of functional elements is shown for the second network <b>201</b>. A main component of the networks <b>200</b>, <b>203</b> are SIP/IP cores <b>202</b>, <b>203</b>. The SIP/IP cores <b>202</b>, <b>203</b> may provide, among other things, routing of SIP signaling, discovery and address resolution services, authentication/authorization, charging, accounting, and QoS control.

An aggregation proxy <b>204</b> acts as single contact point for an XDM client <b>205</b> to access documents stored in any of the XDMS. A shared XDMS <b>206</b> is a repository that manages XML documents (e.g., URI lists) that are needed for a particular service enabler and that may be shared with other service enablers (e.g., IM, Presence, PoC). Two repositories for specific service enablers are also illustrated the Presence XDMS <b>208</b> and the IM XDMS <b>210</b>.

A presence server <b>212</b> maintains the presence status of IM clients <b>214</b>. Presence relates to the availability and willingness of a presence source <b>216</b> (also referred to as a presentity) to communicate. A presence watcher <b>218</b> tracks different states of the presence source <b>216</b>, and thereby can determine when the presence source <b>216</b> is willing and able to communicate.

Other functional entities of the network <b>200</b> include an IM server <b>219</b> and a search server <b>220</b>. The operations of these entities <b>218</b>, <b>220</b> are described in greater detail elsewhere herein. A remote IM client <b>222</b> and IM server <b>224</b> are shown in the second network <b>201</b>. It will be appreciated that the networks <b>200</b>, <b>201</b> may include components that are not illustrated in this example, including service enablers and data repositories related to PoC.

In reference now to <figref idrefs="DRAWINGS">FIG. 3</figref>, a system diagram illustrates the protocols used to communicate between various entities according to embodiments of the present invention. The functional entities in <figref idrefs="DRAWINGS">FIG. 3</figref> are analogous to those entities described in relation to <figref idrefs="DRAWINGS">FIG. 2</figref>. As in <figref idrefs="DRAWINGS">FIG. 2</figref>, the diagram of <figref idrefs="DRAWINGS">FIG. 3</figref> encompasses two different networks, <b>300</b> and <b>301</b>. Note the interconnect lines in <figref idrefs="DRAWINGS">FIG. 3</figref> have labels indicating the protocols used in communicating between the entities. In particular, SIP is used for SIP session control for actions such as joining chat room, and XCAP can be used for data access and group management, among other things. The search operations may also use an XCAP based interface

The systems such as shown in <figref idrefs="DRAWINGS">FIGS. 2 and 3</figref> may include adaptations for checking personal characteristics of end-users and limiting group access based on those characteristics. One way to communicate these characteristics is to embed descriptive data into signaling requests and/or responses. It will be appreciated that any combination of data may be added to signaling messages by clients, servers, or other intermediary elements to one or both responses. Generally, for SIP/SIMPLE IM systems, the data can be embedded using feature tags for indicating the personal information and associated criterion for entering the group. For example, if the criterion is based on age, the age will be the personal data placed in a feature tag. The feature tag can be added to the Accept-Contact header or Contact header as defined in IETF RFC 3840 and RFC 3841.

Example feature tag names for describing age and age criterion are shown below in Listing 1. These example tags are useful because of their simplicity, however the names could be different. Similarly, a single feature tag name could be used to described both the characteristic (e.g., age) and the criterion that characteristic must meet in order to be allowed to join a group or see results of a search (e.g., age limit).

<tables id="TABLE-US-00001" num="00001"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="56pt" align="left" /><colspec colname="1" colwidth="161pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>+age.group_limit = numeric_value</entry></row><row><entry /><entry>#Indicates the age limit for a group.</entry></row><row><entry /><entry>+age.user = numeric value</entry></row><row><entry /><entry>#Indicates the age of the user.</entry></row><row><entry /><entry>© 2005, Nokia Corporation</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

Listing 1

If +age.group_limit in Listing 1 has no value, it defaults to “TRUE”, meaning the group has no special age limit. This could be needed in inter-operator domain or intercontinental service cases to solve legal issues. The values of +age.group_limit and +age.user can be stored in a capability database as contact predicates or set of features tags. RFC 3840 describes how feature set predicates are constructed and provided by a UA as Contact header field parameter to the SIP registrar to store as part of the UA capabilities during SIP registration.

User characteristics such as age can be located and accessed from network databases such as Profile XDMS, as well as any local user capabilities database. Another way of determining these capabilities is described in IETF RFC 3841. RFC 3841 provides a means for callers to express their preferences on the characteristics of the User Agent (UA) that the caller is attempting to reach. The capabilities of the target UA may be stored in a registrar. The preferences of the caller agent are then matched with the feature set provided by the targeted UA via the registrar. This assumes that a UA Server (UAS) or a proxy has access to a location service that has capabilities associated with the target UA.

One way to populate the target UA's capabilities in the registrar is to carry it in the contact header field as a feature parameter during the target UA's SIP registration. However if the UAS/proxy knows the capabilities of the user through some other means, then it may apply the same processing for the matching process. The present invention is applicable under any scenario of accessing capabilities, including where target UA capabilities is stored in the SIP Registrar, in a Profile XDMS, or any local database that can be accessed by UAS/Proxy. Generally, the Accept-Contact header field preference expression is matched with the sending user's request. In cases where the UAS/proxy gets the capabilities via the registrar, then there should be a mechanism to ensure that the feature tag (+age.user=numeric_value) that is carried in the contact header field during registration is verified and genuine.

In reference now to <figref idrefs="DRAWINGS">FIGS. 4A and 4B</figref>, sequence diagrams illustrate the use of personal information in allowing session access according to an embodiment of the present invention. The session establishment requests in <figref idrefs="DRAWINGS">FIGS. 4A and 4B</figref> span two networks, Network A <b>402</b> and Network B <b>404</b>. Relevant functional entities within the networks <b>402</b>, <b>404</b> share the same reference numbers in both figures, and the entities include an IM client <b>406</b>, IM server <b>408</b> and Profile XDMS <b>410</b> in the first network <b>402</b>, and an IM server <b>412</b> and IM XDMS <b>414</b> in the second network <b>404</b>. The functions performed by these entities are described in greater detail with reference to <figref idrefs="DRAWINGS">FIGS. 2 and 3</figref>.

The sequence in <figref idrefs="DRAWINGS">FIG. 4A</figref> begins when the IM Client <b>406</b> sends a request <b>420</b> (e.g., a SIP INVITE) from Network A <b>402</b> to join a chat group that is located in Network B <b>404</b>. The IM server <b>408</b> in Network A <b>402</b> fetches <b>422</b> relevant data contained in the User Profile (e.g., age information) from the Profile XDMS <b>410</b>. The IM server <b>408</b> then embeds <b>424</b> the data (e.g., inserts an “age” field) into the SIP INVITE and sends <b>426</b> the modified message to the IM server <b>412</b> in Network B <b>404</b>. The IM server <b>412</b> fetches <b>428</b>, <b>429</b> the IM Group definition from the IM XDMS <b>410</b>. The definition includes predetermined criterion (e.g., age limit) for establishing the service, which in this example is joining an IM group. The IM server <b>412</b> uses this criterion to check <b>430</b> if the user of the IM client <b>406</b> is allowed to join the chat group based on the predetermined criterion (e.g., age limit) and sends <b>432</b>, <b>434</b> the appropriate response, either positive or negative, to the IM client <b>406</b> based on the results of the check <b>430</b>.

As described above, the IM server <b>408</b> of the originating network <b>402</b> can embed <b>424</b> a tag containing the user's personal message in a session initiation request message (e.g., SIP INVITE). This data can be placed in the Accept-contact header field. For example, assume Alice is eighteen years old and is sending an INVITE request to a chat room from her IM client <b>406</b>. An example header of this request is shown in Listing 2.

<tables id="TABLE-US-00002" num="00002"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>INVITE sip:chat_lounge@biloxi.com SIP/2.0</entry></row><row><entry /><entry>Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8</entry></row><row><entry /><entry>Max-Forwards: 70</entry></row><row><entry /><entry>To: Chat_lounge &lt;sip:chat_lounge@biloxi.com&gt;</entry></row><row><entry /><entry>From: Alice &lt;sip:alice@atlanta.com&gt;;tag=1928301774</entry></row><row><entry /><entry>Call-ID: a84b4c76e66710</entry></row><row><entry /><entry>CSeq: 314159 INVITE</entry></row><row><entry /><entry>Contact: &lt;sip:alice@Atlanta.com&gt;</entry></row><row><entry /><entry>Accept-contact: *; language=″en,de″ ;description=″&lt;PC&gt;″;+oma-</entry></row><row><entry /><entry>sip.im</entry></row><row><entry /><entry>Content-Type: application/sdp</entry></row><row><entry /><entry>Content-Length: 142</entry></row><row><entry /><entry>*</entry></row><row><entry /><entry>*</entry></row><row><entry /><entry>© 2005, Nokia Corporation</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

Listing 2

The IM server <b>408</b> terminates the request and creates a similar INVITE to chat_lounge with a modified Accept-contact header. The IM server <b>408</b> may retrieve Alice's age (UA capabilities) from any combination of the Profile XDMS <b>410</b>, a SIP registar, and/or any local profile server. Based on Alice's age obtained from her User Profile, the IM server <b>408</b> populates the Accept-Contact header as shown below in Listing 3. The “+age.group-limit” entry in the Accept-contact header indicates that terminating end (IM server <b>412</b>) should accept the invitation only if the indicated age satisfies the age.group-limit for the chat_lounge group. For example, Alice would be allowed to join a chat room that has an age limit of eighteen years or below, but not one that has an age limit of fourteen years or below, or a limit of nineteen years and above.

<tables id="TABLE-US-00003" num="00003"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>INVITE sip: chat_lounge@biloxi.com SIP/2.0</entry></row><row><entry /><entry>Via: SIP/2.0/UDP im_server.atlanta.com;branch=z9hG4bKnashds8</entry></row><row><entry /><entry>Max-Forwards: 70</entry></row><row><entry /><entry>To: Chat_lounge &lt;sip:chat_lounge@biloxi.com&gt;</entry></row><row><entry /><entry>From: Alice &lt;sip:alice@atlanta.com&gt;;tag=1928301774</entry></row><row><entry /><entry>Call-ID: s09a233cbsdfglk</entry></row><row><entry /><entry>CSeq: 594131 INVITE</entry></row><row><entry /><entry>Contact: &lt;sip:im_server@.atlanta.com&gt;</entry></row><row><entry /><entry>Accept-contact: *; language=″en,de″;description=″&lt;PC&gt;″;+oma-</entry></row><row><entry /><entry>sip.im;+age.group_limit&lt;=″#18″</entry></row><row><entry /><entry>Content-Type: application/sdp</entry></row><row><entry /><entry>Content-Length: 142</entry></row><row><entry /><entry>*</entry></row><row><entry /><entry>*</entry></row><row><entry /><entry>*</entry></row><row><entry /><entry>© 2005, Nokia Corporation</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

Listing 3

If the age communicated to chat_lounge chat room is above eighteen years, the IM server <b>412</b> network <b>404</b> hosting the chat room will reject <b>432</b>, <b>434</b> this INVITE with a decline error code and example reason, such as “603 decline (user below the accepted age limit for this communication i.e. +age.group_limit&gt;18).”

<figref idrefs="DRAWINGS">FIG. 4B</figref> also illustrates a request to join a group similar to that shown in <figref idrefs="DRAWINGS">FIG. 4A</figref>, except that the embedding of information and determination of acceptance is handled by different entities. In the sequence of <figref idrefs="DRAWINGS">FIG. 4B</figref>, the IM client <b>406</b> sends <b>440</b> a standard request (e.g., SIP INVITE) to join a chat group that is located in Network B <b>404</b>. The IM server <b>408</b> in Network A <b>402</b> forwards <b>442</b> the request to the IM server <b>412</b> in Network B <b>404</b>. The IM server <b>412</b> fetches <b>444</b>, <b>446</b> the IM Group definition with predetermined criterion from the IM XDMS <b>410</b>. The IM server <b>412</b> in Network B <b>404</b> determines if chat group has predetermined limitations on joining and embeds <b>448</b> appropriate data fields into response sent <b>450</b> to the IM server <b>408</b> in Network A <b>402</b>. The IM server <b>408</b> fetches <b>452</b>, <b>454</b> the User Profile with personal information from Profile XDMS <b>410</b>. The IM server <b>408</b> determines <b>456</b> whether the user of the IM client <b>406</b> is allowed to join the chat group based on this determination <b>456</b>. The IM server <b>408</b> then sends <b>458</b> the appropriate response (positive or negative) to the IM client <b>406</b>.

In this scenario, when the IM server <b>412</b> hosting the chat room receives the join-in request <b>442</b> from user, it should respond <b>450</b> with “<b>421</b> extension required” or with “<b>183</b> session progressing.” The response <b>450</b> should include an extension header that indicates the age limitation for chat room, e.g., “Contact: +age.group_limit&gt;=18.” Returning to the example where Alice desires to join chat_lounge, this would indicate that there is age limitation for joining the group. In that example, the IM server <b>408</b> in Alice's network retrieves <b>452</b>, <b>454</b> Alice's age via the Profile XDMS <b>410</b> or some other profile server. If the IM server <b>408</b> determines the age limit is met, session establishment can continue. Otherwise, the originating IM server <b>408</b> terminates session establishment. In this latter case, the IM server <b>408</b> may include an Accept-Contact header into a code “<b>421</b>” or “<b>183</b>” response, indicating the required age for the user, e.g., “Accept-Contact: +age.user&gt;=18;require.”

Another variation of sending personal information in signaling requests to join a group according to an embodiment of the invention is shown in <figref idrefs="DRAWINGS">FIG. 5A</figref>. <figref idrefs="DRAWINGS">FIG. 5A</figref> includes Network A <b>502</b> having and IM client <b>506</b> and IM server <b>508</b>, and Network B having an IM server <b>510</b> and IM XDMS <b>512</b>. The IM client <b>506</b> embeds <b>520</b> a tag containing personal information (e.g., user's age) into a request message (e.g., SIP INVITE). An example tag that can be added to the Accept-Contact header for this purpose is shown below in Listing 3. The IM server <b>508</b> receives <b>522</b> this message and forwards <b>524</b> it to the IM server <b>510</b> of Network B <b>504</b> in order to join the chat group located in Network B <b>504</b>. The IM server <b>510</b> in Network B <b>504</b> receives the request and fetches <b>526</b>, <b>528</b> the IM Group definition with predetermined criterion for joining the group from the IM XDMS <b>512</b>. The IM server <b>510</b> checks <b>530</b> to see whether the personal data embedded in the response allows the IM client <b>506</b> to join chat group, and the appropriate response is sent <b>532</b>, <b>534</b> to the entities in Network A <b>502</b>.

<tables id="TABLE-US-00004" num="00004"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>INVITE sip:chat_lounge@biloxi.com SIP/2.0</entry></row><row><entry /><entry>Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8</entry></row><row><entry /><entry>Max-Forwards: 70</entry></row><row><entry /><entry>To: Chat_lounge &lt;sip:chat_lounge@biloxi.com&gt;</entry></row><row><entry /><entry>From: Alice &lt;sip:alice@atlanta.com&gt;;tag=1928301774</entry></row><row><entry /><entry>Call-ID: a84b4c76e66710</entry></row><row><entry /><entry>CSeq: 314159 INVITE</entry></row><row><entry /><entry>Contact: &lt;sip:alice@Atlanta.com&gt;</entry></row><row><entry /><entry>Accept-contact: *; language=″en,de″;description=″&lt;PC&gt;″;+oma−</entry></row><row><entry /><entry>sip.im; +age.group_limit&lt;=″#18″</entry></row><row><entry /><entry>Content-Type: application/sdp</entry></row><row><entry /><entry>Content-Length: 142</entry></row><row><entry /><entry>*</entry></row><row><entry /><entry>*</entry></row><row><entry /><entry>*</entry></row><row><entry /><entry>*</entry></row><row><entry /><entry>© 2005, Nokia Corporation</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

Listing 4

The implementation shown in <figref idrefs="DRAWINGS">FIG. 5A</figref> may be more challenging to implement, in that it is necessary to prevent the IM client <b>506</b> (or other terminal software) from easily including false age information into outgoing message headers. This may require that the message <b>522</b> contain some authentication key (e.g., cryptographic token) to ensure the message has not been tampered with by the originating terminal or intermediary network entities.

It is also possible that the request to join a chat room is sent from server to terminal, such as when a user receives an invitation to join a chat room. Limiting the ability to join in that case based on age or other characteristics is also desirable. This scenario is illustrated in <figref idrefs="DRAWINGS">FIG. 5B</figref>, which includes networks <b>502</b>, <b>504</b> and entities <b>506</b>, <b>508</b>, <b>510</b>, and <b>512</b> similar to those described in relation to <figref idrefs="DRAWINGS">FIG. 5A</figref>, with the addition of a Profile XDMS <b>536</b> in Network A <b>502</b>. The IM server <b>510</b> that initiates the request first gets <b>540</b>, <b>542</b> the criterion for joining the group and embeds <b>544</b> the criterion in the invitation. For example, the IM server <b>510</b> may add a “+age.user age” tag in the Accept_Contact header of the invitation message. The IM server <b>510</b> then sends <b>546</b> the INVITE request to the IM server <b>508</b> on the user's network. The IM server <b>508</b> will fetch <b>548</b>, <b>550</b> the related profile data via the Profile XDMS <b>536</b> (or other source). The IM server <b>508</b> then checks <b>552</b> the criterion for limiting group entry against the profile data. If the criterion is not met, then INVITE request is rejected <b>554</b>. If the criterion are met, then the IM server <b>508</b> will send <b>556</b> the INVITE request to the invited user's IM client <b>506</b>.

Although the examples described in relation to <figref idrefs="DRAWINGS">FIGS. 4A-B</figref>, <b>5</b>A-B show embedding either personal characteristics or criterion in signaling messages, alternate implementations may not require the use of data embedded in signaling messages. In reference now to <figref idrefs="DRAWINGS">FIG. 5C</figref>, a sequence diagram illustrates example exchanges that occur independently of the signaling messages for determining personal characteristics and criterion related to those characteristics. The diagram of <figref idrefs="DRAWINGS">FIG. 5C</figref> includes networks <b>502</b>, <b>504</b> and entities <b>506</b>, <b>508</b>, <b>510</b>, <b>512</b> and <b>536</b> similar to those described in relation to <figref idrefs="DRAWINGS">FIGS. 5A-B</figref> and that share the same reference identifiers used in <figref idrefs="DRAWINGS">FIGS. 5A-B</figref>.

In the first example of <figref idrefs="DRAWINGS">FIG. 5C</figref>, a SIP INVITE is sent <b>560</b> from the IM client <b>506</b> to the local IM server <b>508</b>. The INVITE is forwarded <b>562</b> to the IM server <b>510</b> in Network B <b>504</b>. The IM server <b>510</b> fetches <b>564</b>, <b>566</b> the predetermined criteria (e.g., age limit) from the IM XDMS <b>512</b>. The IM server <b>510</b> also fetches <b>568</b>, <b>570</b> the personal characteristic related to the criterion (e.g., age) from the Profile XDMS <b>536</b> of Network A <b>502</b>. Note that the IM server <b>510</b> and Profile XDMS <b>536</b> (or intermediary entities acting on their behalf) will utilize a NNI in order to perform this transaction <b>568</b>, <b>570</b>. Thereafter, the characteristic is verified <b>572</b> and appropriate responses (e.g., acceptance, denial) are sent <b>574</b>, <b>578</b> to the originating IM server <b>508</b> and client <b>506</b>.

In another example of <figref idrefs="DRAWINGS">FIG. 5C</figref>, SIP INVITE is sent <b>580</b> from the IM client <b>506</b> to the local IM server <b>508</b> as before. This time the IM server <b>508</b> locally verifies eligibility by fetching <b>582</b>, <b>584</b> the predetermined criteria (e.g., age limit) from the IM XDMS <b>512</b> in Network B <b>504</b> such as via NNI. The IM server <b>508</b> also fetches <b>586</b>, <b>588</b> the personal characteristic related to the criterion (e.g., age) from the Profile XDMS <b>536</b> and verifies <b>590</b> the characteristic satisfies the criterion. If the criterion is satisfied, the INVITE is forwarded <b>592</b> to the remote IM server <b>510</b>, and if the criterion is not satisfied a rejection is returned <b>594</b> to the client <b>506</b>.

It will be appreciated that the order and substance of transactions presented in <figref idrefs="DRAWINGS">FIGS. 4A-B</figref>, <b>5</b>A-C is merely exemplary, and interactions may occur in different sequences than those illustrated. For example, in <figref idrefs="DRAWINGS">FIG. 5C</figref>, the fetching of personal characteristics <b>586</b>, <b>588</b> may occur before the fetching of criterion <b>582</b>, <b>584</b>. Similarly, the messages may be processed by additional or alternate entities, such as proxies, mirrors, routing nodes, encoders/decoders, etc.

The examples described in relation to <figref idrefs="DRAWINGS">FIGS. 4A-B</figref>, <b>5</b>A-C relate to allowing access to group sessions based on user characteristics such as age. The mechanisms described for embedding characteristics in messages are for purposes of example, and those skilled in the art will appreciate that other variations may be used to include such data, such as the placement of feature tags in Contact, Accept-Contact, and other message headers The communications sessions in <figref idrefs="DRAWINGS">FIGS. 4A</figref>, <b>4</b>B, <b>5</b>A were described in terms of IM groups/chat rooms, but the concepts similarly apply to related data communications sessions such as one-to-one and one-to-many ad hoc sessions, audio video teleconferencing, PoC conferencing, etc. Similarly, these solutions may be applied to signaling that occurs when searches of such communications occur. The search protocols will often operates on top of well-known protocol stacks such as HTTP. Descriptors of personal characteristics such as age could be included into HTTP headers or other search protocol headers.

Many types of apparatuses may be able communicate in point-to-point or group sessions as described herein. Mobile devices are particularly useful in this role. In reference now to <figref idrefs="DRAWINGS">FIG. 6</figref>, an example is illustrated of a representative mobile computing arrangement <b>600</b> capable of carrying out operations in accordance with embodiments of the invention. Those skilled in the art will appreciate that the exemplary mobile computing arrangement <b>600</b> is merely representative of general functions that may be associated with such mobile devices, and also that landline computing systems similarly include computing circuitry to perform such operations.

The processing unit <b>602</b> controls the basic functions of the arrangement <b>600</b>. Those functions associated may be included as instructions stored in a program storage/memory <b>604</b>. In one embodiment of the invention, the program modules associated with the storage/memory <b>604</b> are stored in non-volatile electrically-erasable, programmable read-only memory (EEPROM), flash read-only memory (ROM), hard-drive, etc. so that the information is not lost upon power down of the mobile terminal. The relevant software for carrying out conventional mobile terminal operations and operations in accordance with the present invention may also be transmitted to the mobile computing arrangement <b>600</b> via data signals, such as being downloaded electronically via one or more networks, such as the Internet and an intermediate wireless network(s).

The mobile computing arrangement <b>600</b> includes hardware and software components coupled to the processing/control unit <b>602</b> for performing network data exchanges. The mobile computing arrangement <b>600</b> may include multiple network interfaces for maintaining any combination of wired or wireless data connections. In particular, the illustrated mobile computing arrangement <b>600</b> includes wireless data transmission circuitry for performing network data exchanges.

This wireless circuitry includes a digital signal processor (DSP) <b>606</b> employed to perform a variety of functions, including analog-to-digital (A/D) conversion, digital-to-analog (D/A) conversion, speech coding/decoding, encryption/decryption, error detection and correction, bit stream translation, filtering, etc. A transceiver <b>608</b>, generally coupled to an antenna <b>610</b>, transmits the outgoing radio signals <b>612</b> and receives the incoming radio signals <b>614</b> associated with the wireless device. The mobile computing arrangement <b>600</b> may also include an alternate network/data interface <b>615</b> such as USB, Bluetooth, Ethernet, 802.11 Wi-Fi, IRDA, etc.

The processor <b>602</b> is also coupled to user-interface elements <b>618</b> associated with the mobile terminal. The user-interface <b>618</b> of the mobile terminal may include, for example, a display <b>620</b> such as a liquid crystal display. Other user-interface mechanisms may be included in the interface <b>618</b>, such as keypads <b>622</b>, speakers, microphones, voice commands, switches, touch pad/screen, graphical user interface using a pointing device, trackball, joystick, etc. These and other user-interface components are coupled to the processor <b>602</b> as is known in the art.

The program storage/memory <b>604</b> typically includes operating systems for carrying out functions and applications associated with functions on the mobile computing arrangement <b>600</b>. The program storage <b>604</b> may include one or more of read-only memory (ROM), flash ROM, programmable and/or erasable ROM, random access memory (RAM), subscriber interface module (SIM), wireless interface module (WIM), smart card, hard drive, or other removable memory device. The storage/memory <b>604</b> of the mobile computing arrangement <b>600</b> may also include software modules for performing functions according to embodiments of the present invention.

In particular, the program storage/memory <b>604</b> may include one or more network protocol stacks <b>624</b>. The protocol stack <b>624</b> contains processing layers associated with conventional Internet communications, including HTML and SIP protocol layers. It will be appreciated that the layers of the protocol stack <b>624</b> need not be separate entities, and may share common functions/libraries. Generally, the protocol stack <b>624</b> interfaces with network hardware and data bearers through low-level routines/drivers <b>628</b>. These drivers <b>628</b> provide a software interface for controlling data communications hardware such as the DSP <b>606</b>, transceiver <b>606</b>, and alternate data interface <b>615</b>.

The mobile computing arrangement <b>600</b> may also include a specialized signaling layer <b>630</b> capable of controlling the ability of network applications <b>632</b> to engage in communication with target entities <b>634</b> via a network <b>636</b>. For example, the signaling module <b>632</b> may be able to determine user profile data either via a local profile database <b>638</b> or via a server on the network <b>636</b>. This profile data may be used to form signaling messages containing characteristics (e.g., age) that may control whether the end user is admitted to a communications session. An authentication module <b>640</b> may ensure that the profile data is correct, and used to form special tokens to ensure the messages have not been tampered with on the arrangement <b>600</b> or elsewhere.

The mobile computing arrangement <b>600</b> of <figref idrefs="DRAWINGS">FIG. 6</figref> is provided as a representative example of a computing environment in which the principles of the present invention may be applied. From the description provided herein, those skilled in the art will appreciate that the present invention is equally applicable in a variety of other currently known and future mobile and landline computing environments. For example, desktop computing devices similarly include a processor, memory, a user interface, and data communication circuitry. Thus, the present invention is applicable in any known computing structure where data may be communicated via a network.

In order for an age limitation scheme to work, various network entities will be required to monitor signaling messages, access age criterion from the messages and profile databases, and enforce the restrictions by denying sessions or limiting search results. These functions may be provided by computing arrangements distributed across multiple communications networks. However, an example apparatus that may carry out various combinations of these functions is shown in <figref idrefs="DRAWINGS">FIG. 7</figref>.

<figref idrefs="DRAWINGS">FIG. 7</figref> shows an example computing structure <b>700</b> suitable for providing message monitoring and access/search control according to embodiments of the present invention. The computing structure <b>700</b> includes a computing arrangement <b>701</b>. The computing arrangement <b>701</b> may include custom or general-purpose electronic components. The computing arrangement <b>701</b> includes a central processor (CPU) <b>702</b> that may be coupled to random access memory (RAM) <b>704</b> and/or read-only memory (ROM) <b>706</b>. The ROM <b>706</b> may include various types of storage media, such as programmable ROM (PROM), erasable PROM (EPROM), etc. The processor <b>702</b> may communicate with other internal and external components through input/output (I/O) circuitry <b>708</b>. The processor <b>702</b> carries out a variety of functions as is known in the art, as dictated by software and/or firmware instructions.

The computing arrangement <b>701</b> may include one or more data storage devices, including hard and floppy disk drives <b>712</b>, CD-ROM drives <b>714</b>, and other hardware capable of reading and/or storing information such as DVD, etc. In one embodiment, software for carrying out the operations in accordance with the present invention may be stored and distributed on a CD-ROM <b>716</b>, diskette <b>718</b> or other form of media capable of portably storing information. These storage media may be inserted into, and read by, devices such as the CD-ROM drive <b>714</b>, the disk drive <b>712</b>, etc. The software may also be transmitted to computing arrangement <b>701</b> via data signals, such as being downloaded electronically via a network, such as the Internet. The computing arrangement <b>701</b> may be coupled to a user input/output interface <b>722</b> for user interaction. The user input/output interface <b>722</b> may include apparatus such as a mouse, keyboard, microphone, touch pad, touch screen, voice-recognition system, monitor, LED display, LCD display, etc.

The computing arrangement <b>701</b> may be coupled to other computing devices via networks. In particular, the computing arrangement includes a network interface <b>724</b> for interacting with a local “home” network <b>726</b> and remote “foreign” networks <b>728</b>. The network interface <b>724</b> may include a combination of hardware and software components, including media access circuitry, drivers, programs, and protocol modules. Ultimately, the computing arrangement <b>701</b> may affect session interactions between clients <b>730</b>, <b>732</b> for purposes of limiting search and join capabilities based on personal characteristics such as age. The session interactions between clients <b>730</b>, <b>732</b> may take place on a single network (e.g., network <b>726</b>) or across two or more networks <b>726</b>, <b>728</b>.

The computing arrangement <b>701</b> includes processor executable instructions <b>734</b> for carrying out tasks of the computing arrangement <b>701</b>. These instructions may include a communications services module <b>736</b> capable of providing core network services such as IM or PoC. The arrangement <b>701</b> may also include a module <b>738</b> for providing or accessing profile data. For example, the arrangement <b>701</b> may be configured as an aggregation proxy, and may access a Profile XDMS <b>740</b> in the local network <b>726</b> and/or a Profile XDMS <b>742</b> in a foreign network <b>728</b>. Similarly, if the arrangement <b>701</b> includes a services module <b>736</b> for providing IM services, the arrangement <b>701</b> may access one or more IM XDMS <b>744</b>, <b>746</b> on the respective networks (although for most purposes, and IM server would only need to access the local XDMS <b>744</b>).

The computing arrangement may also host or utilize network search services via a search services module <b>750</b>. The search service module <b>750</b> may be able to communicate with clients <b>730</b>, <b>732</b> and network data repositories such as the Profile and IM XDMS <b>740</b>, <b>742</b>, <b>744</b>, <b>746</b> in order to locate, format, and filter searches for data related to chat groups and/or end users. Generally, the intercommunications between the search module <b>750</b> (as well as the communication and profile modules <b>732</b>, <b>738</b>) and other network entities will require communication using standard protocols, as represented by the protocol layer <b>752</b>. The protocol layer <b>752</b> may include stacks for processing SIP <b>754</b>, HTTP <b>756</b>, XCAP <b>758</b>, and XCAP NNI <b>760</b>. Generally, the XCAP NNI protocol stack <b>760</b> is configured for inter-network communications, as indicated by path <b>762</b>. The other stacks <b>754</b>, <b>756</b>, <b>758</b> may be configured for communications via the home network, although are not strictly limited as such. The stacks of the protocol layer <b>752</b> may be configured as either or both client and server stacks where appropriate.

The computing structure <b>700</b> is only a representative example of network infrastructure hardware that can be used to provide services as described herein. Generally, the functions of the computing structure <b>700</b> can be distributed over a large number of processing and network elements, and can be integrated with other services, such as service enablers, gateways, mobile communications messaging, etc.

In reference now to <figref idrefs="DRAWINGS">FIG. 8</figref>, a flowchart illustrates a procedure <b>800</b> for establishing a data communications session. A personal characteristic associated with a user of a terminal is determined <b>802</b>, and a predetermined criterion for allowing establishment of the data communications session based on the personal characteristic is obtained <b>804</b>. A token is embedded <b>806</b> in a signaling message used to establish the data communications session. The token represents at least one of the personal characteristic and the predetermined criterion the personal characteristic. For example, the token may represent an age associated with a user and/or represent an age limit associated with a communication session. The signaling message is communicated <b>808</b> with a network entity capable of allowing users to establish data communications sessions. The data communications session is established <b>810</b> via the network entity if the personal characteristic satisfies the predetermined criterion.

In reference now to <figref idrefs="DRAWINGS">FIG. 9</figref>, a flowchart illustrates a procedure <b>900</b> for searching for communication endpoints accessible via a network. A criterion related to a personal characteristic of a user is determined <b>902</b>. A token is embedded <b>904</b> in a signaling message used to initiate the search. The token represents at least one of the criterion and the personal characteristic. A search result is obtained in response to the signaling message. The search result is filtered <b>908</b> by excluding endpoints referenced in the search result that do not satisfy the criterion. The filtered search result is returned <b>910</b> to an initiator of the signaling message.

The foregoing description of the exemplary embodiments of the invention has been presented for the purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed. Many modifications and variations are possible in light of the above teaching. It is intended that the scope of the invention be limited not with this detailed description, but rather determined by the claims appended hereto.