Abstract:
Methods and apparatuses for managing anonymized character profile information and scheduling in-game activities for online virtual game environments. The disclosure describes a trusted method for automatic synchronization of character profile information with a trusted information management system that minimizes the possibility of fraudulent character profile information and allows for the efficient coordination of in-game activities by the users of the online virtual environment. Methods are described for interacting with a trusted information management system in both in-game and out-of-game settings. According to one embodiment of the invention, an in-game module of the virtual environment allow for automatically synchronization of virtual environment state information with a trusted information management system at periodic intervals. According to another embodiment of the invention, access to the trusted information management system via a web browser application allows for out-of-game management and scheduling of in-game activities by the user of the online virtual environment.

Description:
FEDERALLY SPONSORED RESEARCH 
       [0001]    Not applicable 
       SEQUENCE LISTING OR PROGRAM 
       [0002]    Not applicable 
       FIELD OF THE INVENTION 
       [0003]    The present invention relates in general to tools and methods for online virtual environments. In particular, the present invention relates to tools and methods for management of character information and activities in online virtual environments. 
       BACKGROUND OF THE INVENTION 
       [0004]    Online virtual environments are relevant to many useful applications. Online virtual environments which support a large number of simultaneous users (also known as players) are referred to as massively multiplayer. Online virtual environments provide a shared space that can host up to a large number of users (e.g., thousands to millions of concurrent users). Typically an online virtual environment includes a server-side component (the “server”), which may be implemented as software running on a single general purpose computer or networked cluster of general purpose computers, and a client-side component (the “client”), which is typically implemented as software running on each player&#39;s personal computer (PC), which is in communications with the server hosting the online virtual environment. 
         [0005]      FIG. 1  shows a simplified block diagram of an exemplary online virtual environment system  100  comprising a plurality of client machines  102 - 108  and a server machine  110 . Each client machine  102 - 108  is connected to the server machine  110 . Typically, clients communicate to the server via TCP/IP over the internet or private network. In this diagram, four client machines  102 - 108  are depicted, though it is understood by those of ordinary skill in the art that any number of client machines are possible. For example, in current commercial online virtual environments, it is not uncommon for thousands or even millions of clients to be connected concurrently to the server  110  hosting the virtual environment. Additionally, the server machine  110  is depicted in the  FIG. 1  as a single machine, though it is understood by those of ordinary skill in the art that the server machine  110  may also refer to a networked cluster of computers that perform an analogous function. 
         [0006]    The server  110  is responsible for hosting centralized information about the shared virtual environment state and the clients  102 - 108  are responsible for interfacing the user to said virtual environment, for example, by displaying and rendering the graphical view of the online virtual environment and handling user interaction. The virtual environments hosted by the server  110  are often expansive, such that the details of the virtual environment cannot be viewed in a single screen. Virtual environments include their own virtual geographies, landmarks, and interactive agents (known as non-player characters). Additionally, there are a wide variety of activities that users of the online virtual environment can engage in via the virtual environment. 
         [0007]    Typically, the user of an online virtual environment creates an agent (also known as an avatar, or character) which is a virtual representation of the user inside the online virtual environment. As in the real world, characters in the game have a customizable appearance and may have a gender, a race, virtual property, professions, and skills, among other attributes. It is common for users of an online virtual environment to spend a substantial amount of time and effort in customizing the virtual appearance of their characters, acquiring virtual property, and acquiring experiences in the virtual environment. Additionally, users may also spend real money in order to participate in the online virtual environment. One of the most popular categories of online virtual environment is the massively multiplayer online game (MMOG). MMOGs are a class of online virtual environments that are adapted for the purposes of entertainment. For example, one popular MMOG entitled World of Warcraft, produced by Blizzard Entertainment, licenses game client software and charges users a monthly subscription fee for access to the servers hosting the World of Warcraft virtual environment operated by Blizzard Entertainment. Also, many of the virtual items and properties of the virtual environment can be purchased or exchanged for real monetary value. 
         [0008]    The sheer number of players and the expansive virtual geography of many online virtual environments present challenges for social interaction within the virtual environment. Namely, because players are distributed in different regions of the virtual game geography, they are often remote from other players within the virtual geography. Additionally, often a player desires to find a particular second player in the game such that the desired second player is someone that the first player is familiar with or possesses a particular skills or inventory item that is necessary for some activity that the first player wishes to partake in. 
         [0009]    For example, in some MMOGs, one type of activity is a quest, which is an activity typically involving some location in the virtual geography and some predetermined goal, such as the slaying of a monster (a class of non-player character) or the acquisition of some rare inventory item. On the completion of the predetermined goal of the quest, players are often rewarded by some designation, experience points, or inventory item. 
         [0010]    Another type of activity that is available in MMOGs is known as an “instance” or a “dungeon”. Instances, or dungeons, refer to portions of the virtual geography that can be cloned, and allow a character or group of characters to enter and interact inside the instance. Multiple instances can be cloned from the same portion of the virtual geography and each instance is independent of every other instance, much like a copy of a virtual room, which is disconnected from the rest of the virtual geography. Likewise, players can have predetermined goals to be accomplished in an instance and engage in various activities and interactions. 
         [0011]    A third type of activity that is common in MMORPGs is player-player interaction. This refers to activities that involve two or more players. These activities may include simulated combat between the two players, also known as Player-versus-Player activities. Other types of activities that involve interactions between players include trading of inventory, or performing other actions upon the player, such as healing or casting a spell. 
         [0012]    Players of a MMOG often associate themselves with player groups, known as guilds, or clans. Guilds refer to named associations comprising a set of players that engage in organized activities together. Some guilds may be social or competitive in nature, engaging in game competitions with other guilds. Certain guilds may have selective requirements for membership, and actively recruit highly skilled players. 
         [0013]    In all of the activities mentioned above, social coordination is required between the participating players in order to form groups well-suited to seeking the aforementioned objectives. For example, in a quest activity, a group of players must convene in the virtual environment on the game server at the same time and comprise the right type of characters. This may involve scheduling time for the quest amongst the participating players and in addition, recruiting characters to the group with skills that will balance and enhance the group&#39;s strengths. Certain combinations of characters on a team may be desirable. For example, it may be necessary to have a character on the team of a certain profession in order to place an “enchantment” (i.e. cast a spell) on the item in a second character&#39;s possession. A character may also be required to be of a certain profession in order to create a particular item that is needed by a second character. 
         [0014]    Therefore, players seek techniques that would allow them to optimize their experiences in the online virtual environment by maximizing the time spent enjoying desirable activities and minimizing the time spent finding and managing suitable activities and finding players to partake in activities with them. Such techniques can be broadly categorized into methods that operate within the virtual environment environment (in-game methods) and methods that operate outside of the virtual environment (out-of-game methods). 
         [0015]    In-game methods refer to methods of inter-player collaboration and management that take place within the virtual environment itself. Many online virtual environment clients are graphics intensive and have a primary program window in a full-screen configuration such that entire output of the display device is utilized, as well as most of the most of the mappings for the input devices. Thus, in-game methods avoid the need to switch the current foreground process to an external program or system. For example, conventionally, engaging in an activity with another character may involve navigating the virtual environment while looking for other characters in proximity, examining the character for the desired qualities, and chatting with the character to arrange the exchange of items or plan activities. This manual process is very time intensive and intractable in practice, since the total virtual geography is generally very large relative to the visible area displayable in one screen on the display device. Furthermore, the presence of characters may be sparsely located in this geography the desired qualities of the character may be rare. 
         [0016]    Another in-game method that can be used for activity planning, implemented in some MMOGs, is virtual chat rooms. In each virtual chat room, each player can input text that is mutually seen by the other players currently in the same room. Players often spend substantial amounts of time posting messages in chat rooms to solicit other players to participate in planned activities. Because there is a limited buffer of past messages that are viewable in a chat room, players often post the same solicitation message in a chat room periodically, resulting in much wasted effort and re-reading of the same message. 
         [0017]    A third method of in-game activity management that is available in some MMOGs is a built-in character search facility. This allows for players of the game to query for specific desired qualities and view search results that list characters matching the desired qualities. A player can then examine the characters listed in the search results and contact candidates for arranging potential activities. Some MMOGs also provide in-game calendar applications for scheduling future activities. Players can use in-game calendar applications to create appointments for future activities by specifying the details of the activity, such as time and virtual location, invite other players to the activity and accept invitations initiated by other players. 
         [0018]    Out-of-game methods for activity management refer to methods that reside outside of the game client environment. This would include methods that are not considered in-game methods. Out-of-game methods allow for management and scheduling of activities when the game client is not running or when the player is not playing the game. Out-of-game methods are convenient when the player does not wish to load the game client or is physically away from the device that has the game client software installed. For instance, if a player of a MMOG is an acquaintance of a second player of the same MMOG, the first play may contact the second player using traditional methods such as telephone, in-person conversation, e-mail, or instant messenger in order to arrange game activities. However, because of the large number of players of MMOGs, players will not generally be acquainted with the majority of the other players of the game. Additionally, players will not always wish to play with players that they are familiar with or have played with in the past. Thus, out-of-game methods exist that allow searching for unfamiliar characters with certain desirable qualities. 
         [0019]    One common out-of-game method of activity management and scheduling is an online web forum. Web forums are online message boards that allow users of the web forum to create message threads and respond to existing message threads. Each message thread consists of a time ordered sequence of textual message posts by various users of the web forum. Web forums may be provided by either the producer of the MMOG or by a third party. However, web forums are used for many other general purposes, and have few features specific to MMOGs and particularly activity management and activity scheduling in MMOGs. Therefore, it can be cumbersome to schedule activities via web forums, often requiring much time and resulting in confusion over what activities were agreed upon. Additionally, these out-of-game methods typically cannot be used at the same time as the player is playing the MMOG, as often the MMOG game client requires the entire full screen of the display device; switching between the MMOG game client and the management tool would require switching between the active foreground process on the computing device. 
         [0020]    Another out-of-game method that is well known to those of skill in the art is a social network. Social networks are a category of online web sites that are designed for social interactions amongst users of the social network. Each registered user of a social network site can have connections to other registered users of the social network site, thus forming an interconnected community of users. Typically each registered user of the site has a profile, listing information about the user typically including, but not limited to, name, age, sex, religious affiliation, location, personal preferences, favorites, and pictures. Users of the social network can typically send textual messages to other users of the social network. A gamer social network is a social network that is tailored towards the gamer community. Thus, the profile listing of a user of a typical gamer social network may additionally include information such as the game systems that the player owns (e.g. Microsoft Xbox, Sony Playstation, Nintendo Wii, Personal Computer, etc.), game or games that the player plays, and information about the player&#39;s current progress and history in each game. For example, a profile on a gamer social network may include the picture of the player&#39;s character&#39;s likeness or list the experience level of the player&#39;s character in a particular game. The communications tools provided by the gamer social network may be used to manage and schedule game activities. 
         [0021]    Besides the inconvenience of switching between the client and management tool, out-of-game methods suffering from several other common drawbacks. Because these systems exist outside of the virtual environment, it is common to find character listings or profiles with false or stale information (referred to as fake profiles). Fake profiles are an undesirable barrier to effective activity scheduling because they are often difficult to distinguish from valid profiles in search results. The prevalence of fake profiles reduces the trustworthiness of the social network and lowers the chances that a scheduled activity will be successful. Another drawback of social networks is the lack of user privacy. Although a user may wish to utilize the communications tools provided for arranging game activities, he may not be willing to disclose the personal information about himself that is required in creating a profile on a gamer social network. 
         [0022]    A consequence of out-of-game methods is that registering virtual environment state and character information can be prohibitively labor intensive. Since the system resides outside of the virtual environment, the system typically does not have access to the data fields that contain the character attributes residing in the client and hosted on the server. It is therefore common for the out-of-game methods to require to the user to manually enter his character&#39;s attributes. Additionally, these attributes need to be updated as the player progresses in the virtual environment and the player&#39;s character&#39;s attributes change. 
         [0023]    Thus, it would be desirable to have an activity management system for online virtual environments that allows for automatic maintenance of character data, privacy of player personal information, and efficient scheduling of in-game activities. 
       SUMMARY OF THE INVENTION 
       [0024]    A system for management of information and scheduling of in-game activities by players participating in an online virtual environment is herein disclosed. In one embodiment of the invention, a synchronization module communicates with a client process on a client machine. The synchronization module obtains character profile information directly from the client and transmits the character profile information to a trusted information management server, thus requiring no manual input of character data and no disclosure of personal player information. A trusted information management server is disclosed which allows for management of character profile information, such as that received by the synchronization module, and provides mechanisms for the search and scheduling of in-game events. Both in-game and out-of-game methods for interfacing the information management server are described. In one embodiment of the invention, out-of-game access to the trusted information management server is enabled via a web-based interface, accessible by a web browser client. According to an alternative embodiment of the invention, events which are scheduled by the trusted information management system may generate notifications, which may synchronously or asynchronously send messages to the user of upcoming events. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0025]    The present invention may be further understood from the following description in conjunction with the appended drawings. In the drawings: 
           [0026]      FIG. 1  is a simplified block diagram of a virtual environment system containing a plurality of client machines and a server machine; 
           [0027]      FIG. 2  is a simplified schematic diagram of a virtual environment system utilizing a synchronization module on the game client machine to interface a Trusted Information Management Server; 
           [0028]      FIG. 3  is a flowchart illustrating the process for anonymous synchronization of character profile data with a Trusted Information Management Server; 
           [0029]      FIG. 4  is a simplified schematic diagram of an out-of-game system for interfacing a Trusted Information Management Server; 
           [0030]      FIG. 5  is a simplified schematic diagram of an in-game system for interfacing a Trusted Information Management Server; 
           [0031]      FIG. 6  is a diagram illustrating a user interface for searching, filtering, and displaying character profile search results using a Trusted Information Management Server; 
           [0032]      FIG. 7  is a flowchart illustrating a method for match scheduling and rating using a Trusted Information Management Server; 
           [0033]      FIG. 8  is a flowchart illustrating a method for servicing search requests using a Trusted Information Management Server; and 
           [0034]      FIG. 9  is a simplified schematic diagram of a notification system for a Trusted Information Management Server. 
       
    
    
     DETAILED DESCRIPTION 
       [0035]    A system for management of state information and scheduling of in-game activities by players participating in an online virtual environment is herein disclosed.  FIG. 2  depicts an online virtual environment system  200  utilizing a trusted information management system. The trusted information management system  200  comprises a client machine  202 , a server machine  208  and a trusted information management machine  212 . The client machine  202  further comprises a client  204  and an in-game synchronization module  206 . The server machine  208  further comprises a virtual environment server  210 . The trusted information management machine  212  further comprises a trusted information management server  214 , a character profile information database  216 , a post database  218 , and an event database  220 . 
         [0036]    The character profile information database  216  is a storage system for character profile information, which may be implemented as a relational database, file storage, or by other means. Character profile information refers to attributes of the player&#39;s character and may include, such attributes as race, class, gender, experience level, inventory items, guild membership, rankings, and images of the likeness of the character, among other possible attributes. The post database  218  is a storage system for posts, which may be implemented as a relational database. Posts refer to user-submitted requests for an activity. For example, one post may list a users request for a Player-versus-Player activity on a specified date. The types of posts and attributes of each post may vary depending on the particular online virtual environment that the trusted information management server is adapted for. The event database  220  is a storage system for events, which are activities that have a specified date. Each event may also specify a location in the virtual environment that the event shall take place, the characters that have confirmed the event, among other attributes. 
         [0037]    Wherein this detailed description the server machine  208  has been described as a single general-purpose computing device for the purposes of discussion, it is readily understood by those of ordinary skill in the art that the server machine  208  may be implemented as a cluster of one or more networked computing devices, or other configuration of a plurality of computing devices, operating in a an analogous role to a single game server machine. It is also understood that throughout this detailed description, the trusted information management machine  212  may also be implemented as a cluster of one or more networked computing device, or other configuration of a plurality of computing devices, operating in an analogous role to a single trusted information management machine. 
         [0038]    In a typical embodiment of the invention, the client machine  202  is the player&#39;s personal computer, which runs the client  204  typically provided by the publisher of the online virtual environment. During operation of the online virtual environment, the player primarily interacts with the client  204  via the input and output peripherals of the client machine  202 , engaging himself or herself in the online virtual environment. This interaction may include use of a display device, speakers, keyboard, mouse, joystick, or other input device. The client  204  runs as a software process on the client machine  202  operating system. Typically, the client  204  renders the display of the virtual environment to the player and accepts input from the player, which causes the player&#39;s character to perform the corresponding actions within the virtual environment. The actions that are possible will differ for each online virtual environment implementation, but commonly include activities such as navigation within a 3D virtual environment, chatting with other characters in the virtual environment via textual messages, simulated combat with other characters, configuring the appearance and inventory of a character, and engaging in in-game events, among other activities. 
         [0039]    The client  204  relays certain interactions to a server  210  running as a software process on a server machine  208 . The server machine  208  is typically hosted by the publisher of the online virtual environment or other third party at a location remote to the client machine  202 . Typically, the connection between the client machine  202  and the server machine  208  is over the Internet via TCP/IP. 
         [0040]    The server  210  receives the relayed interactions from the client  204 , as well as from other concurrently connected clients, and maintains the global state of the virtual environment. This state may include such information as the geography of the virtual environment, the coordinates of each of the characters within said geography, character profile attributes, character inventories, and player account information, among other attributes. The server  210  may also run a physics simulation of objects in the virtual environment. When the state maintained by the server  210  has changed, typically the server  210  will relay the changed information back to the client  204 , which the client  204  will then update its own local state to agree with the global state maintained by the server  210 . 
         [0041]    In many MMOGs, the client utilizes the entirety of the display device of the client machine  202 , such that no other running processes on the client machine  202  are visible by the player. Interactions that are done in this state are known as in-game. 
         [0042]    In one embodiment of the invention, during the in-game state, a synchronization module  206  may be invoked from within the client  204 . Modules are separate software libraries that can communicate to the client  204  via inter-process communications methods. Commonly, the publisher of the online virtual environment provides an application programming interface (API) for accessing functionality of the client  204  from a module. In this case, the synchronization module  206  communicates with the client  204  via the module API. In one embodiment of the invention, the player of the online virtual environment invokes the module by issuing a click on a button in the client  204 . The synchronization module  204  then communicates with the client  204  to obtain character profile information. 
         [0043]    In an alternative embodiment of the synchronization module  206 , state information is communicated between the client  204  and the synchronization module  206  via a file residing on the hard disk of the client machine  202 . In a preferred embodiment of the invention, the file is a log file of events that is generated by the client  204  during the in-game period. The synchronization module  206  can thereby obtain character profile information by reading the contents of the file and the changes to the file. 
         [0044]    Notably, character profile information is anonymous since it does not include identifying information concerning the player. For example, character profile information does not include the real name of the player, the player&#39;s sex, race, address or account information. This is advantageous since players may not wish for their personal information to be shared with others. 
         [0045]    The synchronization module  206  transmnits the anonymous character profile information to the trusted information management server  212 . According to alternative embodiments of the invention, other types of information may also be sent, such as a record of scheduled events that the player has arranged. The trusted information management server  212  is typically hosted at a location remote to the client machine  202 . Typically, the connection between the trusted information management machine  212  and the server machine  208  is over the Internet via TCP/IP. 
         [0046]    A trusted information management daemon  214  runs as a software process on the trusted information management server  212 . The trusted information management daemon  214  receives the anonymous character profile information from the synchronization module  206 . The trusted information management daemon  214  then parses the received anonymous character profile information and stores the information to a character database  216 . This process may involve resolving any conflicts between the character profile information received and that, if any, which was previously stored in the character database  216  by updating the previous entries with the current character profile attributes. Additionally, this process may involve data normalization of the character profile attribute values into predetermined categories. 
         [0047]      FIG. 3  depicts a flowchart  300  detailing the process of synchronizing character profile information with the trusted information management server  212 . In the first step  302 , the synchronization module  206  receives a user initiated synchronization request. As previously described, this request may be invoked by the clicking of a button from within the game client  204  or the issuance of some other command via player interaction with the game client  204 . Once the user initiated synchronization request has been received, in the second step  304 , the synchronization module  206  initiates a read of character profile information from the client  204  using the client API. The character profile attributes that are read by the synchronization module  206  can be customized depending on the application and may vary depending on the online virtual environment. In the third step  306 , the synchronization module  206  then transmits the character profile information via the Internet to the Trusted Information Management Server  212 . According to a preferred embodiment of the invention, the transmitted data is anonymous in that it does not contain player-identifiable information. In the next step, the trusted information management server  212  receives the anonymous character profile data  308 , which comprises decoding the transmitted information and parsing and interpreting the resultant data. Lastly, the final step  310  comprises updating the character profile information database  216  with the received character profile data. 
         [0048]    Since steps  304 - 310  require no player intervention and are fully automatic, manual entry of character profile information into the trusted information management server  212  is unnecessary, saving-user effort. Additionally, since the character profile information is read by the synchronization module  206  directly from the game client  204 , occurrences of inaccurate information and stale information are greatly reduced as compared to manual methods. 
         [0049]    In addition to enabling the in-game synchronization of character profile information, the trusted information management server  212  of  FIG. 2  may also be configured, according to an embodiment of the invention, to provide the ability to search and filter for characters, and manage in-game activities. This may be done via either an in-game interface or an out-of-game interface. 
         [0050]      FIG. 4  shows a simplified schematic diagram of a trusted information management server  212  with an out-of-game interface  400 . In this exemplary embodiment of the invention, the out-of-game interface illustrated is a web browser application, though many other out-of-game interfaces are possible. In this embodiment, the user interacts with the trusted information management server  406  via a client machine  402 . For example, the client machine  402  may be the player&#39;s personal computer, a web-enabled mobile phone, a computing device capable of running a web browser, or other electronic programmable device. The trusted information management server  406  comprises an HTTP server  408 , a trusted information management server  410 , a character profile information database  412 , a post database  414 , and an event database  416 . 
         [0051]    The player interfaces the system via a web browser application  404  running on the client machine  402 . The player can utilize the web browser application  404  to navigate to a URL locating the trusted information management server  406  hosting the trusted information management daemon  410 . The web browser application  404  on the client machine  402  communicates directly with an HTTP server  408  running as a software process on the trusted information management server  410  by sending HTTP requests and receiving HTTP responses. The HTTP server  408  handles generating the interface viewed by the player via the web browser  404 , including the hypertext markup (HTML), and any associated layout, styling and graphical elements. 
         [0052]    The HTTP server  408  connects directly to the trusted information management daemon  410  to retrieve information and forward query requests. To service the query requests, the trusted information management daemon  410  queries the character profile information database  412 , the post database  414 , and the event database  416 , depending on the nature of the request. 
         [0053]    In an alternative embodiment of the invention, in-game interfaces may be used to access the trusted information management server.  FIG. 5  shows a trusted information management system  500  wherein the interface to the system  500  is accessible in-game. The in-game trusted information management system  500  comprises a client machine  502  and a trusted information management server  508 . The client machine  502  further comprises a client  504  and a client add-on  506 . The trusted information management server  508  further comprises a trusted information management daemon  510 , which runs as a software process, a character profile information database  512 , a post database  514 , and an event database  516 . 
         [0054]    In this embodiment of the invention, the player may access the trusted information management server  508  while engaged with the client  504 . Inside the environment of the client  504 , the player may invoke a client add-on  506  that interfaces the trusted information management server  508 . The client add-on  506  is responsible for relaying player requests over the network to the trusted information management server  508  as well as receiving the responses from the trusted information management server  508 . Additionally, the client add-on  506  is responsible for generating and displaying the interface. In order to service requests, the trusted information management daemon  510  will alternatively be able to access the character profile information database  512 , the post database  514  and the event database  516 , depending on the nature of the request, which will be described in further detail in a subsequent section. 
         [0055]    Thus, we have described embodiments of the trusted information management system that allow for either in-game as well as out-of game interfaces to the trusted information management server, such as those illustrated in  FIGS. 4 and 5 , respectively. Alternatively, these embodiments can be easily combined to form a trusted information management system that allows for both in-game and out-of-game interfaces. This would be highly advantageous as it would allow for a player to have ubiquitous access to the trusted information management server, whether he is currently engaged in the online virtual environment or not 
         [0056]      FIG. 6  shows a simplified drawing of an exemplary web interface  600  to the trusted information management server, for example, such as the one of  FIG. 4 . The web interface  600  comprises a browser region  602  (also known as a chrome, or widget region) and a document content region  604 . The browser region  602  comprises a set of user interface elements for controlling navigation such as the navigation buttons, address bar, and menu bars. The document content region  604  contains the rendered output of the HTML code sent by the remote HTTP server. In this exemplary embodiment of the invention, the document content region  604  shows a search and filter area  606  and a results area  612 . The search and filter area  606  further comprises a search box  608  and a filter drop-down control  610 . In the typical operation of the web interface  600 , the user may enter in his search query into the search box  606  and select an appropriate filter from the filter drop-down widget  608 . On invoking the query, either manually via another widget or keystroke, or automatically, the web browser sends the query to the trusted information management server, which executes the query and returns the search results. Upon receiving the search results from the trusted information management server, the web browser parses and renders the results into the results area  612 . In this example, the results are shown in tabular form, with columns for the character picture, character name, character experience level, and character guild membership. While one possible embodiment of the search interface has been detailed, those of ordinary skill in the art will readily appreciate that other interfaces for the trusted information management system are possible. For example, in one embodiment of the invention, the search and filter area  606  of the web interface  600  requires no text entry and searches can be conducted purely with mouse input. This may be appropriate for certain event types whereby no textual queries are necessary in order to produce search results. 
         [0057]    Searching for characters registered in the online virtual environment that match certain desired criteria is typically the first step in scheduling an in-game activity with other players.  FIG. 7  is a flowchart  700  depicting a process for scheduling and rating an event between two users of the system, denoted User A and User B. The process  700  of scheduling and rating events comprises a pre-confirmation stage, further comprising nodes  702 - 710 , a post-confirmation stage further comprising nodes  712 - 714 , and a post-event stage comprise node  716 . 
         [0058]    The pre-confirmation stage begins with the first process node  702 , in which User A searches the trusted information management system for appropriate characters or posts that match User A&#39;s desired characteristics. The search process  702  may use a similar interface to that previously described in  FIG. 6 , with User A entering his search query, specifying an desired filter criteria and executing a search on the trusted information management server. Once the trusted information management server has returned the result set of the search  702 , User A determines  704  whether a post exists in the result set of the search that matches his desired criteria. 
         [0059]    If there exists a post that matches User A&#39;s desired criteria, then the process proceeds to node  706 , in which User A accepts the post of interest, which we shall assume was previously created by a User B. After User A has accepted User B&#39;s post, the process proceeds to confirm the event  712 . 
         [0060]    However, if at decision node  704 , there does not exist a suitable post in the result set that matches User A&#39;s desired criteria, then User A proceeds to create his own post  708 . At a future time, if a second user, User B, subsequently searches and finds the post created by user A at node  708  suitable, then User B proceeds to accept User A&#39;s post  710 . 
         [0061]    In either the case of User A accepting User B&#39;s post  706  or User B accepting User A&#39;s post  710 , the process proceeds to the post-confirmation stage by scheduling an event between User A and User B, which is stored in the event database at node  712 . The event entry that is created may also be stored alongside event-specific attributes, such as time of the planned event, location of the planned event in the virtual environment, among other attributes. The post-confirmation state may also be denoted in the event entry in the event database. 
         [0062]    Next, User A and User B are allowed to chat and exchange textual messages  714  in order to arrange further details concerning the event prior to the event date. This is only allowed in the post-confirmation state. These details may depend on the type of event that is being planned. For example, if the event is a quest, the participating players may wish to discuss strategies or arrange to equip their characters with certain inventory items that would be beneficial for the planned quest. In an alternative embodiment of the invention, communications are limited between users of the system that have established a “favorite” relationship between their respective characters and are simultaneously accessing the trusted information management server. A “favorite” relation is established between two characters when it is mutually agreed to by both characters&#39; corresponding user. The “favorite” relation may be stored in the character database, thus creating a social graph of characters. 
         [0063]    After the date of the event has passed, the event is then denoted as the post-event state. In the post-event state, User A and User B may both rate each other&#39;s performance during the in-game event, which would impact each users&#39; community reputation score. 
         [0064]    While the above description has described the scheduling of an event between two parties, User A and User B, it is understood by those of ordinary skill in the art that supporting multiple parties is also desirable and common. For example, in the case of more than two parties, a first can still create a post and the remaining users can accept the post created by the first user. 
         [0065]      FIG. 8  is a flowchart  800  depicting in further detail the process of handling a search request by the trusted information management server as in process node  702  of  FIG. 7 . In the first step  802 , the query is received from the client, such as the client add-on  506  of  FIG. 5  or alternatively the HTTP server  406  of  FIG. 4 . The query comprises a sequence of keywords, modified by operators, and with optionally specified filters, intended to restrict the results of the search. Once the query has been received, in the next step  804  the query data is parsed into an internal canonical representation, suitable for index lookup. That is, the fields contained in the query are parsed so that they can be looked up separately in the index. Next, the index lookup  806  retrieves each of the result sets matching each field and combines the result sets depending on whether Boolean ‘AND’ or ‘OR’ is used. If ‘AND’ is the implicit Boolean operator, then the intersection of the result sets is retained. If ‘OR’ is the implicit Boolean operator, then the union of the result sets is retained. 
         [0066]    After the result set is obtained, then in the next step  808 , the result set is optionally partitioned according to a specified criterion. In one preferred embodiment of the invention, the result set is partitioned such that one partition contains all of the results that reference characters in the same guild as the querying user, and the second partition contains all of the results that reference characters not in the same guild as the querying user. 
         [0067]    After partitioning  808 , each partition of results is then independently sorted  810  according to a ranking function. Many ranking function implementations are possible. In one preferred embodiment of the invention, the ranking function is an ordinal ranking of the experience level of the character, from greatest to least. In another embodiment of the invention, the ranking function is a weighted sum of character attribute values, including experience level, community-supplied rating, and date of most recent event. 
         [0068]    After each partition has been sorted according to a ranking function, then process proceeds to concatenate the partitions into a single result set and then transform the result set into the appropriate output format. 
         [0069]    According to another embodiment of the invention, notifications are sent to remind the players that are confirmed for an event of the upcoming date of the event. This functionality may optionally be set in the attributes of the event database.  FIG. 9  shows a simplified block diagram of a notification system  900  for the trusted information management server. The notification system  900  comprises a notification daemon  902 , event database  904  such as the event database  220  of  FIG. 2 , an SMTP Server  906  and a HTTP Server  908 . 
         [0070]    As previously disclosed, the event database  904  contains a store of all confirmed events that have been arranged between players registered in the trusted information management system. Periodically, a notification daemon  902  can poll the event database  904  for events that will occur in the future. This periodic interval may be user-configured or set by the system administrator. If the notification daemon  902  finds events matching the specified criteria to trigger a notification, then the notification daemon  902  can generate a notification message, containing details of the event for the user. Many forms of notification are possible. If it is desired that the notification be sent to the user in the form of an E-mail message, then the message can be transmitted to an SMTP server  906 , for dispatch to the user&#39;s email inbox. In another embodiment of the invention, notifications are sent to an instant message system, in order to deliver an instant message to a user&#39;s screen name. In yet another embodiment, notifications are sent to an HTTP server in order to update a “wall post” or trigger asynchronous JavaScript popup messages that can appear in the web interface. It is well known by those of ordinary skill in the art that other equivalent notification techniques, both synchronous and asynchronous, are possible. These include, but are not limited to generating RSS (Really Simple Syndication) feeds, SMS (Short Message Service) messages, and social network status messages. 
         [0071]    In one preferred embodiment of the invention, notifications are sent to the client via the synchronization module in communications with the trusted information management server. For example, the synchronization module may write notifications of events to a file residing on the client machine. The client-addon, such as that of  FIG. 5  is then capable of reading this file and displaying the notifications of events within the client application, thus providing an in-game ability to receive notifications in the virtual environment. The displaying of the notifications of events may be implemented in various ways, such as by presenting the events in a calendar interface. In this embodiment of the invention, anonymity is preserved to the fullest extent, because no personal information from the user is needed for the notification to be received. While the above is a complete description of the preferred embodiments of the invention sufficiently detailed to enable those skilled in the art to build and implement the system, it should be understood that various changes, substitutions, and alterations may be made without departing from the spirit and scope of the invention as defined by the appended claims.