Simplifying determination of the groups to which users belong when using dynamic groups

BACKGROUND

p-00021. Technical Field

p-0003The present disclosure relates to management of users and more specifically to simplifying determination of the groups to which users belong when using dynamic groups.

p-00042. Related Art

p-0005A group refers to a set of users, treated as a single entity in the management of various tasks. For example, groups are often used to simplify specification of access controls of shared resources, to facilitate easier addressing when sending communications (e.g., email) to the users/members of a group, to facilitate co-operative work (e.g., software coding, work-flows), etc. Thus, each user of a group is said to be a member of that group. A user may be a member of (can belong to) multiple groups.

p-0006A dynamic group is a type of group in which the members are identified based on corresponding rule/criteria indicating the conditions to be satisfied by the user attributes (such as name, location, job title, etc.). The users whose values of the attributes satisfy the rule are determined to belong to the corresponding dynamic group. In sharp contrast, in static groups, the list of users/members belonging to each group is maintained manually by an administrator.

p-0007It is often required that the groups to which users belong be determined (a common operation along with determining the user that belong to a group). Such a determination may be performed efficiently with static groups by checking whether the user is contained in the member lists maintained by the administrator.

p-0008On the other hand, for dynamic groups, the determination of the groups to which a user belongs may necessitate that member lists corresponding to each of the dynamic groups be determined dynamically and then be checked as done with respect to static groups. Alternatively, the values of the user attributes may be checked against the rules corresponding to each of the dynamic groups. It may be appreciated that such determination may require considerable amount of time and/or resources, in particular, when the number of dynamic groups is large.

p-0009Accordingly, it may be desirable that the determination of the groups to which user belong be simplified (or made more efficient) even when using dynamic groups.

BRIEF DESCRIPTION OF THE DRAWINGS

p-0010Example embodiments of the present invention will be described with reference to the accompanying drawings briefly described below.

p-0011<figref idrefs="DRAWINGS">FIG. 1</figref> is a block diagram illustrating an example environment (computing system) in which several aspects of the present invention can be implemented.

p-0012<figref idrefs="DRAWINGS">FIG. 2</figref> is a flowchart illustrating the manner in which the determination of the groups to which a user belongs when using dynamic groups is simplified according to an aspect of the present invention.

p-0013<figref idrefs="DRAWINGS">FIGS. 3A and 3B</figref> depicts portions of a user data (maintained in a directory server <b>160</b>) at two different time instances in one embodiment.

p-0014<figref idrefs="DRAWINGS">FIGS. 4A and 4B</figref> depicts portions of cache data maintained at two different time instances in one embodiment.

p-0015<figref idrefs="DRAWINGS">FIG. 4C</figref> depicts portions of include/exclude data maintained in a database in one embodiment.

p-0016<figref idrefs="DRAWINGS">FIG. 5</figref> is a block diagram illustrating the details of a digital processing system in which various aspects of the present invention are operative by execution of appropriate executable modules.

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

DESCRIPTION OF EXAMPLE EMBODIMENTS

p-00181. Overview

p-0019According to an aspect of the present invention, a search tool maintains a cache data indicating which users are members of which dynamic groups. When a membership request is received requesting a set of dynamic groups to which a user belongs, the search tool examines the cache data to determine the set of dynamic groups to which the user belongs and sends the determined groups as a response to the membership request.

p-0020In one embodiment, the search tool maintains the cache data in the form of tables in a database server (supporting relational database technologies). Accordingly, the cache data is examined by forming and executing a structured query language (SQL) query designed to retrieve the set of dynamic groups corresponding to the user from the tables in the database server.

p-0021Thus, the determination of the dynamic groups to which users belong is simplified since the execution of a SQL query in general requires considerably less amounts of time and/or resources.

p-0022According to another aspect of the present invention, the search tool may store an include list and an exclude list, respectively indicating the users to be included and excluded from each dynamic group. The lists are inspected in forming the set of dynamic groups to which the user belongs.

p-0023Such a feature enables a user/administrator to manually specify the members belonging to a dynamic group, for example, when a user is required to be added (or removed) to/from a dynamic group even when the attribute values of the user does not satisfy (or satisfies) the rule defined for the dynamic group.

p-0024Several aspects of the invention are described below with reference to examples for illustration. However one skilled in the relevant art will recognize that the invention can be practiced without one or more of the specific details or with other methods, components, materials and so forth. In other instances, well-known structures, materials, or operations are not shown in detail to avoid obscuring the features of the invention. Furthermore the features/aspects described can be practiced in various combinations, though only some of the combinations are described herein for conciseness.

p-00252. Example Environment

p-0026<figref idrefs="DRAWINGS">FIG. 1</figref> is a block diagram illustrating an example environment (computing system) in which several aspects of the present invention can be implemented. The block diagram is shown containing client systems <b>110</b>A-<b>110</b>C, network <b>120</b>, directory server <b>160</b>, collaboration system <b>170</b> (containing search tool <b>150</b>), data store <b>180</b> and server system <b>190</b>. The different systems may be provided as part of a single enterprise.

p-0027Merely for illustration, only representative number/type of systems is shown in the Figure. Many environments often contain many more systems, both in number and type, depending on the purpose for which the environment is designed. Each system/device of <figref idrefs="DRAWINGS">FIG. 1</figref> is described below in further detail.

p-0028Network <b>120</b> provides connectivity between client systems <b>110</b>A-<b>110</b>C, directory server <b>160</b>, collaboration system <b>170</b>, and server system <b>190</b>. Network <b>120</b> may be implemented using protocols such as Internet Protocol (IP) well known in the relevant arts. In general, in IP environments, an IP packet is used as a basic unit of transport with the source address being set to the IP address assigned to the source system from which the packet originates and the destination address set to the IP address of the target system to which the packet is to be eventually delivered.

p-0029Data store <b>180</b> represents a non-volatile storage facilitating storage and retrieval of a collection of data by one or more applications executing in collaboration system <b>150</b>. Data store <b>180</b> may store information regarding the users and/or groups, the member lists corresponding to static groups, the definitions of dynamic groups, cache lists, etc.

p-0030In one embodiment, data store <b>180</b> is implemented using relational database technologies and therefore provides storage and retrieval of data using structured queries such as SQL (Structured Query Language). SQL refers to a special-purpose, generally non-procedural language (generally indicates what to retrieve based on conditions, in contrast to how to retrieve) that supports the definition, manipulation, and control of data in systems implementing relational database technologies.

p-0031Each of client systems <b>110</b>A-<b>110</b>C represents a system such as a personal computer, workstation, mobile station, etc, used by users in the enterprise to generate (client) requests to business/enterprise applications executing in collaboration system <b>170</b> and/or server system <b>190</b>. The requests may be generated using appropriate interfaces. In general, a client system requests an application for performing desired tasks and receives corresponding responses containing the results of performance of the requested tasks.

p-0032Each of collaboration system <b>170</b> and server system <b>190</b> represents a server (or several servers), such as a web/application server, which executes business/enterprise applications capable of processing client requests received from client systems <b>110</b>A-<b>110</b>C. Each of collaboration system <b>170</b> and server system <b>190</b> may also contain other software programs such as operating system, device drivers, etc., (not shown) that provides a (common) run time environment facilitating the execution of the business/enterprise applications.

p-0033Server system <b>190</b> may execute enterprise applications that are related to users and/or groups of users such as a payroll application, customer resource management (CRM) application, human resource management (HRM) application, etc. Such enterprise applications typically require the details of the users and/or the groups to be maintained in a secondary storage, such as a database or file system. For example, a payroll application may require the salary/flexible benefit of each user/employee, business unit bonuses, department/group wise expenses/bonuses, etc. to be maintained.

p-0034Users/groups related information is often maintained by identity management servers/systems provided within an enterprise. An identity management server in general maintains the identity (details) of users and also the details of static and/or dynamic groups defined for the users. In one embodiment, the information related to users/groups (required for enterprise applications executing in server system <b>190</b>) is maintained in directory server <b>160</b> (an identity management server).

p-0035Directory server <b>160</b> represents a non-volatile storage facilitating information related to an enterprise (such as users, dynamic/static groups, resources, organizational units, etc.) to be maintained in a logical/hierarchical manner by enterprise applications executing in server system <b>190</b> (and collaboration system <b>170</b>). Directory server <b>160</b> facilitates dynamic groups to be defined in terms of corresponding rules (containing conditions to be satisfied by user attributes). The rules defining each group and a group identifier are stored in directory server <b>160</b>, which may respond to membership requests based on such stored information. Directory server <b>160</b> may be implemented using protocols such as lightweight directory access protocol (LDAP) well known in the relevant arts.

p-0036Collaboration system <b>170</b> may execute collaborative/enterprise applications designed to perform group/collaborative activities. The collaborative applications may use users/groups as senders (users) and recipients (users/groups) of communication by way of email, voicemail, instant messaging applications/subsystems, as invitees to meetings and online voice/video conference applications/subsystems, as owners and participants of collaborative contexts such as workspaces, discussion forums, etc., as owners, viewers and reviewers of collaborative artifacts such as documents, images etc. and also in specifying authorization that allows/denies usage of specific system functions.

p-0037The collaborative applications may be designed to use the user/group related information maintained in an identity management server in the enterprise. In one embodiment described below where user/group information is maintained in directory server <b>160</b>, collaborative applications (as well as search tool <b>150</b>) executing in collaboration system <b>170</b> are designed to interact/communicate with directory server <b>160</b> for retrieving the user/group information of interest (related to either all the users/groups maintained in directory server or a subset of users/groups based on requirements/design of the collaborative applications).

p-0038However, the features of the present invention can be implemented in other environments as well, wherein the user/group information is maintained in one or more types/number of collaboration systems and/or identity management systems. For example, collaboration system <b>170</b> may be designed to maintain (in data store <b>180</b>) user/group information independent of (or in addition to) directory server <b>160</b>, with the collaborative applications designed to operate with such maintained data. Oracle Beehive System available from Oracle Corporation, the assignee of the subject patent application, is an example of a collaboration system which is designed to maintain and operate with user/group information independent of (or in addition to, for example by maintaining a copy) the identity management systems present in the enterprise.

p-0039Collaborative activities such as sharing of documents/resources among different users often necessitate access to such documents/resources to be controlled. Such access control is commonly specified in relation to groups of users (rather than for individual users). For example, a project detail document may be allowed access to only programmers, managers, and administrators (each of which may be defined as a corresponding dynamic group). Accordingly, when a user desires to access the project detail document, it may be necessary to determine the specific groups to which the user belongs in order to determine whether the user is allowed access to the document.

p-0040Search tool <b>150</b>, provided according to various aspects of the present invention, simplifies the determination of the groups to which a user belongs when using dynamic groups as described below with examples. Search tool <b>150</b> may be implemented using appropriate combination of hardware, software and firmware.

p-0041Though search tool <b>150</b> is shown internal to collaboration system <b>170</b>, it may be appreciated that in alternative embodiments, search tool <b>150</b> may be implemented as an external independent tool or internal to directory server <b>160</b> or server system <b>190</b>. In general, search tool <b>150</b> needs to be implemented tightly coupled to the identity management system to ensure that several features of the present invention (e.g. updating cached lists) can be implemented in an atomic manner.

p-00423. Determining the Groups to which a User Belongs

p-0043<figref idrefs="DRAWINGS">FIG. 2</figref> is a flowchart illustrating the manner in which the determination of the groups to which a user belongs when using dynamic groups is simplified according to an aspect of the present invention. The flowchart is described with respect to <figref idrefs="DRAWINGS">FIG. 1</figref> merely for illustration. However, various features can be implemented in other environments also without departing from the scope and spirit of various aspects of the present invention, as will be apparent to one skilled in the relevant arts by reading the disclosure provided herein.

p-0044In addition, some of the steps may be performed in a different sequence than that depicted below, as suited in the specific environment, as will be apparent to one skilled in the relevant arts. Many of such implementations are contemplated to be covered by several aspects of the present invention. The flow chart begins in step <b>201</b>, in which control immediately passes to step <b>220</b>.

p-0045In step <b>220</b>, search tool <b>150</b> maintains a cache data indicating the users belonging to each of multiple dynamic groups (defined in an identity management server such as directory server <b>160</b>). Such maintaining implies that the rules defining the membership of each dynamic group are evaluated (a priori, before step <b>240</b>) and the cache data is generated/stored in a memory. The cache data is further updated to reflect changes in the user attributes and/or membership of the groups.

p-0046Accordingly, search tool <b>150</b> may be designed to monitor directory server <b>160</b> (or the identity management server maintaining user/group information) to determine when users and/or dynamic groups are being newly created/defined, updated and/or deleted. In one embodiment, directory server <b>160</b> is designed to provide notifications corresponding to creation, update and deletion of users/groups, with search tool <b>150</b> designed to capture (i.e., update cache data) such notifications.

p-0047Thus, on determining that a new dynamic group is created in directory server <b>160</b>, search tool <b>150</b> determines the members belonging to the new group (the member list corresponding to the dynamic group), for example, by querying directory server <b>160</b> for the member list. The determined member list is then included in the cache data. Similarly, when a dynamic group is updated (by modifying the rule associated with group), the member list corresponding to the updated dynamic group is determined (again, by querying directory server <b>160</b>) and included in the cache data. When a dynamic group is deleted, the corresponding member list maintained in the cache data may also be deleted.

p-0048Further, when a new user is determined to be created, the values of the user attributes of the new user are checked with the definitions/rules of the dynamic groups to determine the dynamic groups to which the new user belongs. The member lists of the determined dynamic groups contained in the cache data are then updated by adding the new user to the corresponding member lists. Similar operations of updating the member lists of the multiple dynamic groups contained in the cache data is performed when a user is determined to be updated (that is, the values of user attributes are changed) or deleted.

p-0049Thus, the cache data is updated to reflect the changes made in the user/group information. Though the updates to cache data are described as being performed by querying directory server <b>160</b>, in alternative embodiments, the information related to users/groups of interest may be retrieved and maintained in a data store <b>180</b> as a local copy, with search tool <b>150</b> designed to update the cache data based on the local copy of the user/group information.

p-0050The cache data may be maintained in a volatile storage, such as a RAM in collaboration system <b>170</b>. The cache data may also me maintained in data store <b>180</b> or a secondary storage in collaboration system <b>170</b>.

p-0051In step <b>240</b>, search tool <b>150</b> receives a (membership) request to find the groups to which a specific user belongs. The request may be received from a collaborative application (executing in collaboration system <b>170</b>) in response to the specific user desiring to access a shared document (which may necessitate determination of the groups to which the specific users belongs as described above). Alternatively, such a request may be received directly from a user/administrator using one of client systems <b>110</b>A-<b>110</b>C.

p-0052In step <b>250</b>, search tool <b>150</b> retrieves the cache data (from data store <b>180</b> or a secondary storage in collaboration system <b>170</b>). It should be noted that the retrieved cache data represents the updated cache data (based on the notifications received from directory server <b>160</b>) and accordingly contains the current member list corresponding to each of the dynamic groups.

p-0053In step <b>260</b>, search tool <b>150</b> identifies the dynamic groups to which the specific user belongs by examining the content of the retrieved cache data. The identification may be performed by checking whether the specific user is included in the current member lists contained in cache data. The specific user is identified to belong to a dynamic group only if the specific user is included in the member list maintained for the dynamic group.

p-0054In one embodiment, when cache data is maintained in data store <b>180</b> implemented according to relational database technologies, the retrieval of cache data and the identification of the dynamic groups is performed by executing an appropriate SQL query.

p-0055In step <b>280</b>, search tool <b>150</b> sends the determined groups as a response to the request. The response may be sent to the requesting collaborative application (executing in collaboration system <b>150</b>) or requesting client system <b>110</b>A-<b>110</b>C (used by the user/administrator) from where the request of determining groups to which a user belongs was received. The flowchart ends in step <b>299</b>.

p-0056Thus, search tool <b>150</b> by maintaining and using an updated cache data indicating the current member lists simplifies determination of the groups to which users belongs when using dynamic groups. The manner in which determination of dynamic groups to which a member belongs is implemented in one embodiment is described below with examples.

p-00574. Example Implementation

p-0058<figref idrefs="DRAWINGS">FIGS. 3A-3B</figref> and <b>4</b>A-<b>4</b>C together illustrate the manner in which determination of groups to be which specific user belongs when using dynamic groups is implemented in one embodiment. Broadly, sample user data at two different time instances is first described (along with an approach to determination of groups to which a member belongs) followed by the description of the cache data and the inventive approach. Each of the Figures is described in detail below.

p-0059<figref idrefs="DRAWINGS">FIGS. 3A and 3B</figref> depicts portions of a user data (maintained in a directory server <b>160</b>) at two different time instances in one embodiment. The user data is shown in a tabular form merely for convenience. Though only sample columns/rows are shown in <figref idrefs="DRAWINGS">FIGS. 3A-3B</figref> (as well as <figref idrefs="DRAWINGS">FIGS. 4A-4C</figref>), various other implementations may include other desired columns/rows based on the specific environments.

p-0060Table <b>300</b> specifies the details of various users in an enterprise at a first time instance. Column <b>321</b> “UserName” specifies a unique identifier/name corresponding to each user, column <b>322</b> “JobTitle” specifies the designation of each user within the enterprise, column <b>323</b> “Manager” specifies the identifier/name of the manager of each user and column <b>324</b> “Location” specifies the location of each user. Columns <b>321</b>-<b>324</b> represent the attributes of the corresponding user, with the values in the columns representing the attribute values for the corresponding user.

p-0061Each of the rows <b>351</b>-<b>359</b> specifies the details of corresponding users. In particular, row <b>351</b> specifies a user named “King” (column <b>321</b>) having the designation “President” (column <b>322</b>) with no manager (‘-’ in column <b>323</b>) and working from Seattle (column <b>324</b>). Row <b>352</b> specifies a user named “Jones” having the designation “Manager”, with manager “King” (shown in row <b>351</b>) and working from Seattle. Similarly, rows <b>353</b>-<b>359</b> specify details of other corresponding users in the enterprise.

p-0062Dynamic groups may be defined with respect to the user data shown in table <b>300</b> of <figref idrefs="DRAWINGS">FIG. 3A</figref>. The dynamic groups and the corresponding rules/criteria are shown below (in a convenient format):

p-0063G<b>1</b> [Manager=‘Jones’]

p-0064G<b>2</b> [Location=‘Bangalore’]

p-0065G<b>3</b> [Job_Title=‘Analyst’]

p-0066Wherein G<b>1</b>, G<b>2</b> and G<b>3</b> are the names of the dynamic groups and the text within the square brackets represents the corresponding rules/criteria for each of the dynamic groups. Thus, dynamic group G<b>1</b> is defined to include users/members whose manager (column <b>323</b>) is ‘Jones’, G<b>2</b> includes users whose location (column <b>324</b>) is ‘Bangalore’ and G<b>3</b> includes users whose job title (column <b>322</b>) is ‘Analyst’.

p-0067The identifiers of the dynamic groups and the corresponding rules (containing one or more conditions) may be maintained in directory server <b>160</b> (along with the user data shown in <figref idrefs="DRAWINGS">FIGS. 3A and 3B</figref>.

p-0068The members of each of dynamic groups (that is, member lists) when determined with respect to the user data shown in table <b>300</b> (at a first time instance) are shown below:

p-0069G<b>1</b>={“Scott”, “Ford”, “Mike”}

p-0070G<b>2</b>={“Happy”, “Susan”, “Adam”, “Kelly”}

p-0071G<b>3</b>={“Scott”, “Ford”, “Susan”}

p-0072Thus, dynamic group G<b>1</b> is indicated to contain the users “Scott”, “Ford” and “Mike” (rows <b>353</b>-<b>355</b>), while the member list corresponding to dynamic group G<b>2</b> includes the users “Happy”, “Susan”, “Adam”, “Kelly” (rows <b>356</b>-<b>359</b>). It may be observed that the same user may belong to multiple groups, for example, “Scott” belongs to both dynamic groups G<b>1</b> and G<b>3</b> and “Susan” belongs to both the dynamic groups G<b>2</b> and G<b>3</b>.

p-0073Membership requests to determine the groups to which a specific user belongs may be received in the form “Get_Groups_Of[UserName]”, where “UserName” is the unique identifier/name of the specific user sought to be searched for. In one embodiment, such membership requests are directed to directory server <b>160</b>, with the directory server <b>160</b> then determining and sending the groups to which “UserName” belongs as corresponding responses. Some sample membership requests and the corresponding responses generated by directory server <b>160</b> are shown below:

p-0074Get_Groups_Of[‘Scott’]={G<b>1</b>, G<b>3</b>}

p-0075Get_Groups_Of[‘Susan’]={G<b>2</b>, G<b>3</b>}

p-0076On receiving the request Get_Groups_Of[‘Scott’], directory server <b>160</b> may first determine the member lists for each of the dynamic groups defined (as shown above) and then check whether the specific member “Scott” is included in the determined member lists to identify the dynamic groups G<b>1</b> and G<b>3</b>. Similar operations may be performed when the next request Get_Groups_Of[‘Susan’] is received.

p-0077It may be observed that the performance of such an operation would require considerable amount of time and/or resource, in particular, when there are a large number of dynamic groups defined in directory server <b>160</b>. It should be noted that caching of the member lists determined during the processing of the first request (for “Scott”) and subsequently using the cached member lists during the processing of the second request (for “Susan”) is generally not feasible, since the user data may be modified between the two request time instances as described below.

p-0078Referring to <figref idrefs="DRAWINGS">FIG. 3B</figref>, table <b>340</b> specifies the details of various users in an enterprise at a second time instance (later than the first time instance) corresponding to table <b>300</b>. Similar numbers are used to represent corresponding portions of <figref idrefs="DRAWINGS">FIGS. 3A and 3B</figref> and hence only the changed portions are described in detail below.

p-0079Row <b>353</b> indicates that the value of the location attribute (Column <b>324</b>) for the user “Scott” has changed to “Bangalore” (from the old value of “Seattle”). Row <b>360</b> represents a new user named “Betty”, having the job title “Programmer”, the user “Adam” as manager and located at “Bangalore”, who was added after the first time instance. It may be noted that row <b>354</b> (user “Ford”) has been deleted before the second time instance.

p-0080The members of dynamic groups when evaluated at second time instance with respect to the user data in table <b>340</b> are shown below:

p-0081G<b>1</b>={“Scott”, “Mike”}

p-0082G<b>2</b>={“Happy”, “Susan”, “Adam”, “Kelly”, “Scott”, “Betty”}

p-0083G<b>3</b>={“Scott”, “Susan”}

p-0084Further, on receiving the above requests for determining the groups to which specific users belong, directory server <b>160</b> generates the responses shown below:

p-0085Get_Groups_Of[‘Scott’]={G<b>1</b>, G<b>2</b>, G<b>3</b>}

p-0086Get_Groups_Of[‘Susan’]={G<b>2</b>, G<b>3</b>}

p-0087Thus, on receiving the request Get_Groups_Of[‘Scott’], directory server <b>160</b> may again determine the member lists for each of the dynamic groups defined, and check whether the specific user “Scott” is included in the determined member lists to identify the dynamic groups G<b>1</b>, G<b>2</b> and G<b>3</b>. It may be noted that the change in the membership status of the user “Scott” from one time instance to another may necessitate determination of the member lists for each membership request.

p-0088According to an aspect of the present invention, an updated cache data indicating the current member list for each dynamic group is maintained (removing the requirement to determine the member list for each request). The manner in which search tool <b>150</b> maintains cache data corresponding to the user data of <figref idrefs="DRAWINGS">FIGS. 3A-3B</figref> in one embodiment is described in detail below.

p-00895. Cache Data

p-0090<figref idrefs="DRAWINGS">FIGS. 4A and 4B</figref> depicts portions of cache data maintained at two different time instances in one embodiment. The description is continued assuming that the cache data is maintained as a table in a database in data store <b>180</b> (supporting relational database technologies). However, in other embodiments, the cache data may be maintained as queues, lists or other convenient data structures in a volatile memory and/or files in a secondary storage.

p-0091Table <b>400</b> represents a portion of cache data indicating members belonging to each of the multiple dynamic groups in an enterprise at a first time instance. Column <b>421</b> “Group” specifies the unique identifier/name of a dynamic group, while column <b>422</b> “MemberName” specifies the unique identifier/name of the user belonging to the group.

p-0092Each of rows <b>451</b>-<b>460</b> represents a combination of a dynamic group and a member, indicating that the member belongs to the group. Accordingly, rows <b>451</b>-<b>453</b> indicate that Scott, Ford and Mike belong to group G<b>1</b>; rows <b>454</b>-<b>457</b> indicate that Happy, Susan, Adam and Kelly belong to group G<b>2</b> and rows <b>458</b>-<b>460</b> indicate that Scott, Ford and Susan belong to group G<b>3</b>.

p-0093It may be observed that the data maintained in table <b>400</b> corresponds to the member lists determined by directory server <b>160</b> with respect to the user data shown in table <b>300</b> at a first time instance as described above.

p-0094In general, when search tool <b>150</b> receives a request to determine the groups to which a specific user belongs in the form “Get_Groups_Of[UserName]”, search tool <b>150</b> first forms a SQL query designed to retrieve cache data of table <b>400</b> and identify the groups to which the specific user “UserName” belongs. The SQL query may be generated as shown below:

p-0095<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="49pt" align="left" /><colspec colname="1" colwidth="168pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>SELECT Group</entry></row><row><entry /><entry>FROM MemberList</entry></row><row><entry /><entry>WHERE MemberName = ‘UserName’</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

p-0096Where, “SELECT”, “FROM”, “WHERE” and “=” are SQL keywords, Group and MemberName respectively indicate columns <b>421</b> and <b>422</b> and MemberList is the name of table <b>400</b> in which cache data is being maintained. UserName is a place holder for the name of the specific user (specified in the received membership request).

p-0097Thus, when the request Get_Groups_Of[‘Scott’] is received, the value of ‘Scott’ is substituted in place of the place holder “UserName” in the above query and the resultant SQL query is then executed. The execution of the query causes the values G<b>1</b> and G<b>3</b> in column <b>421</b> for the rows <b>451</b> and <b>458</b> to be retrieved.

p-0098Thus, the groups to which “Scott” belongs is determined to be {G<b>1</b>, G<b>3</b>}, similar to the output generated (by directory server <b>160</b>) for the first time instance. The cache data of table <b>400</b> is kept updated to reflect the modifications made to the user data between two instances as described below.

p-0099Referring to <figref idrefs="DRAWINGS">FIG. 4B</figref>, table <b>440</b> specifies the details of various users in an enterprise at a second time instance (later than the first time instance) corresponding to table <b>400</b>. Similar numbers are used to represent corresponding portions of <figref idrefs="DRAWINGS">FIGS. 4A and 4B</figref> and hence only the changed portions are described in detail below.

p-0100Rows <b>461</b> and <b>462</b> represent new rows added that respectively indicate that users “Scott” and “Betty” belong to group “G<b>2</b>”. Row <b>461</b> is added in response to an indication (from directory server <b>160</b>) that the attribute “Location” of the user “Scott” has been changed to “Bangalore” (from the old value of “Seattle”) as shown in row <b>353</b>. In response to the update indication, search tool <b>150</b> may check whether the user “Scott” belong to other dynamic groups and accordingly update cache data to reflect the changes made in the user data.

p-0101Row <b>462</b> is added in response to receiving an indication (from directory server <b>160</b>) that the new user named “Betty” has been created/added (as shown in row <b>360</b>) after the first time instance. It may be noted that row <b>452</b> has been deleted before the second time instance in response to an indication that the user “Ford” has been deleted/remove from the user data shown in table <b>340</b>.

p-0102Thus, cache data is kept updated to reflect the modifications made to the user data between the two time instances. It may be observed that the data maintained in table <b>440</b> corresponds to the member lists determined by directory server <b>160</b> with respect to the user data shown in table <b>440</b> at a second time instance as described above.

p-0103Accordingly, the execution of the SQL query by search tool <b>150</b> corresponding to the request Get_Groups_Of[‘Scott’] causes the values G<b>1</b>, G<b>2</b>, and G<b>3</b> in column <b>421</b> for rows <b>451</b>, <b>458</b> and <b>461</b> to be retrieved. Thus, the groups to which “Scott” belongs is determined to be {G<b>1</b>, G<b>2</b>, G<b>3</b>}, similar to the output generated (by directory server <b>160</b>) for the second time instance.

p-0104Thus, search tool <b>150</b> by maintaining cache data indicating the members that belong to each dynamic group, facilitates the determination of the groups to which specific users belong to be performed using corresponding SQL queries. As may be appreciated, the execution of SQL queries in general requires considerably less time and/or resources (in comparison generating the member lists and then checking for the specific user in each of the generated member lists). Accordingly, the determination of the dynamic groups to which a member belongs is simplified.

p-0105Accordingly to another aspect of the present invention, a user/administrator is enabled to manually specify that members belonging to a dynamic group. Such a feature may be desirable when a specific user is required to be added (or removed) to/from a dynamic group, even when the attribute values of the specific user does not satisfy (or satisfies) the rule defined for the dynamic group. In one embodiment, search tool <b>150</b> maintains an include/exclude list to enable users to manually specify members belonging to dynamic groups as described below with examples.

p-01066. Include/Exclude List

p-0107<figref idrefs="DRAWINGS">FIG. 4C</figref> depicts portions of include/exclude data maintained in a database in one embodiment. However, in other embodiments, the include/exclude list may be maintained as queues, lists or other convenient data structures in a volatile memory or as files in a secondary storage.

p-0108Table <b>460</b> represents a portion of include/exclude data indicating which members are to be included or excluded from which dynamic groups. Column <b>471</b> “Group” specifies the unique identifier/name of a dynamic group, and column <b>472</b> “MemberName” specifies the unique identifier/name of a user. Column <b>473</b> “ActionFlag” specifies whether the user specified in column <b>472</b> is to be included (value “Include”) or excluded (value “Exclude”) from the group specified in column <b>471</b>.

p-0109Thus, row <b>481</b> indicates that the user “King” is to be included in the group “G<b>3</b>”, while row <b>482</b> indicates that the user “Scott” is to be excluded from the group “G<b>2</b>”. It may be observed that the user “King” is indicated to be included in the group “G<b>3</b>” even though the location value “Seattle” of the user “King” does not satisfy the rule “Location=‘Bangalore’” corresponding to group “G<b>3</b>”. Similarly, the user “Scott” is indicated to be excluded from the group “G<b>2</b>” even though the attribute value “Analyst” for the attribute “Job_Title” satisfies the rule corresponding to group “G<b>2</b>”.

p-0110Similarly, a user/administrator may manually specify the users/members to be included/excluded from each of the dynamic groups (defined in directory server <b>160</b> and whose member lists are maintained in cache data as described above).

p-0111Search tool <b>150</b> is designed to inspect the data maintained in the include/exclude list and to perform appropriate actions. For example, when a request such as Get_Groups_Of[‘Scott’] is received with respect to the cache data of table <b>440</b>, search tool <b>150</b> first generates and executes a corresponding SQL query to determine the groups as {G<b>1</b>, G<b>2</b>, G<b>3</b>}. Search tool <b>150</b> then checks the include/exclude list of table <b>460</b>, and removes G<b>2</b> from the determined result as indicated by row <b>482</b>. Thus, search tool <b>150</b> determines the dynamic groups to which “Scott” belongs as being {G<b>1</b>, G<b>3</b>}.

p-0112A similar operation may be performed when search tool <b>150</b> is requested to identify the members belonging to the group “G<b>2</b>”. As such search tool <b>150</b> may determine that the users {“Happy”, “Susan”, “Adam”, “Kelly”, “Betty”} belong to the group “G<b>2</b>” at the second time instance (data of table <b>340</b>). It may be noted that the user “Scott” is not included in the member list corresponding to the group “G<b>2</b>” in accordance with the manual exclusion specified in row <b>482</b> of table <b>460</b>.

p-0113While table <b>460</b> is described as being used after execution of the SQL query in determining the groups to which a member belongs, it should be appreciated that in alternative embodiments, the SQL query itself (shown above) may be modified to provide the combined results of examining the cache data and inspecting the include/exclude list, as will be apparent to one skilled in the relevant arts by reading the disclosure provided herein.

p-0114It should be further appreciated that the above-described features may be implemented in a combination of one or more of hardware, software and firmware. The description is continued with respect to an embodiment in which various features are operative by execution of corresponding software instructions.

p-01157. Digital Processing System

p-0116<figref idrefs="DRAWINGS">FIG. 5</figref> is a block diagram illustrating the details of digital processing system <b>500</b> in which various aspects of the present invention are operative by execution of appropriate software instructions. Digital processing system <b>500</b> may correspond to collaboration system <b>170</b> (or to any other system such as directory server <b>160</b>) implementing search tool <b>150</b>.

p-0117Digital processing system <b>500</b> may contain one or more processors such as a central processing unit (CPU) <b>510</b>, random access memory (RAM) <b>520</b>, secondary memory <b>530</b>, graphics controller <b>560</b>, display unit <b>570</b>, network interface <b>580</b>, and input interface <b>590</b>. All the components except display unit <b>570</b> may communicate with each other over communication path <b>550</b>, which may contain several buses as is well known in the relevant arts. The components of <figref idrefs="DRAWINGS">FIG. 5</figref> are described below in further detail.

p-0118CPU <b>510</b> may execute instructions stored in RAM <b>520</b> to provide several features of the present invention. CPU <b>510</b> may contain multiple processing units, with each processing unit potentially being designed for a specific task. Alternatively, CPU <b>510</b> may contain only a single general-purpose processing unit. RAM <b>520</b> may receive instructions from secondary memory <b>530</b> using communication path <b>550</b>.

p-0119Graphics controller <b>560</b> generates display signals (e.g., in RGB format) to display unit <b>570</b> based on data/instructions received from CPU <b>510</b>. Display unit <b>570</b> contains a display screen to display the images defined by the display signals. Input interface <b>590</b> may correspond to a keyboard and a pointing device (e.g., touch-pad, mouse) and may be used to provide inputs.

p-0120Network interface <b>580</b> provides connectivity to a network (e.g., using Internet Protocol), and may be used to communicate with other connected systems (such as client systems <b>110</b>A-<b>110</b>B, directory server <b>160</b>, server system <b>190</b>) of <figref idrefs="DRAWINGS">FIG. 1</figref>.

p-0121Secondary memory <b>530</b> may contain hard drive <b>535</b>, flash memory <b>536</b>, and removable storage drive <b>537</b>. Secondary memory <b>530</b> may store the data (e.g., the user data of <figref idrefs="DRAWINGS">FIGS. 3A-3B</figref>, the cache data of <figref idrefs="DRAWINGS">FIGS. 4A-4B</figref>, the inclusion/exclusion data of <figref idrefs="DRAWINGS">FIG. 4C</figref>) and software instructions (e.g., those implementing the flowcharts and other features described above), which enable digital processing system <b>500</b> to provide several features in accordance with the present invention.

p-0122Some or all of the data and instructions may be provided on removable storage unit <b>540</b>, and the data and instructions may be read and provided by removable storage drive <b>537</b> to CPU <b>510</b>. Floppy drive, magnetic tape drive, CD-ROM drive, DVD Drive, Flash memory, removable memory chip (PCMCIA Card, EPROM) are examples of such removable storage drive <b>537</b>.

p-0123Removable storage unit <b>540</b> may be implemented using medium and storage format compatible with removable storage drive <b>537</b> such that removable storage drive <b>537</b> can read the data and instructions. Thus, removable storage unit <b>540</b> includes a computer readable (storage) medium having stored therein computer software and/or data. However, the computer (or machine, in general) readable medium can be in other forms (e.g., non-removable, random access, etc.).

p-0124In this document, the term “computer program product” is used to generally refer to removable storage unit <b>540</b> or hard disk installed in hard drive <b>535</b>. These computer program products are means for providing software to digital processing system <b>500</b>. CPU <b>510</b> may retrieve the software instructions, and execute the instructions to provide various features of the present invention described above.

p-0125It should be understood that numerous specific details, relationships, and methods are set forth to provide a full understanding of the invention. For example, many of the functions units described in this specification have been labeled as modules/blocks in order to more particularly emphasize their implementation independence.

p-0126Reference throughout this specification to “one embodiment”, “an embodiment”, or similar language means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, appearances of the phrases “in one embodiment”, “in an embodiment” and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment.

p-0127Furthermore, the described features, structures, or characteristics of the invention may be combined in any suitable manner in one or more embodiments. In the above description, numerous specific details are provided such as examples of programming, software modules, user selections, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc., to provide a thorough understanding of embodiments of the invention.

p-01288. Conclusion

p-0129While various embodiments of the present invention have been described above, it should be understood that they have been presented by way of example only, and not limitation. Thus, the breadth and scope of the present invention should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.

p-0130It should be understood that the figures and/or screen shots illustrated in the attachments highlighting the functionality and advantages of the present invention are presented for example purposes only. The present invention is sufficiently flexible and configurable, such that it may be utilized in ways other than that shown in the accompanying figures.

p-0131Further, the purpose of the following Abstract is to enable the U.S. Patent and Trademark Office and the public generally, and especially the scientists, engineers and practitioners in the art who are not familiar with patent or legal terms or phraseology, to determine quickly from a cursory inspection the nature and essence of the technical disclosure of the application. The Abstract is not intended to be limiting as to the scope of the present invention in any way