Trusted information management system for virtual environment

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

Not applicable

SEQUENCE LISTING OR PROGRAM

Not applicable

FIELD OF THE INVENTION

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

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's personal computer (PC), which is in communications with the server hosting the online virtual environment.

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.

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.

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.

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.

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.

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.

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.

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.

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'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'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.

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).

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.

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.

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.

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.

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.

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's current progress and history in each game. For example, a profile on a gamer social network may include the picture of the player's character's likeness or list the experience level of the player's character in a particular game. The communications tools provided by the gamer social network may be used to manage and schedule game activities.

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.

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's attributes. Additionally, these attributes need to be updated as the player progresses in the virtual environment and the player's character's attributes change.

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

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

The present invention may be further understood from the following description in conjunction with the appended drawings. In the drawings:

FIG. 1 is a simplified block diagram of a virtual environment system containing a plurality of client machines and a server machine;

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;

FIG. 3 is a flowchart illustrating the process for anonymous synchronization of character profile data with a Trusted Information Management Server;

FIG. 4 is a simplified schematic diagram of an out-of-game system for interfacing a Trusted Information Management Server;

FIG. 5 is a simplified schematic diagram of an in-game system for interfacing a Trusted Information Management Server;

FIG. 6 is a diagram illustrating a user interface for searching, filtering, and displaying character profile search results using a Trusted Information Management Server;

FIG. 7 is a flowchart illustrating a method for match scheduling and rating using a Trusted Information Management Server;

FIG. 8 is a flowchart illustrating a method for servicing search requests using a Trusted Information Management Server; and

FIG. 9 is a simplified schematic diagram of a notification system for a Trusted Information Management Server.

DETAILED DESCRIPTION

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.

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'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.

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.

In a typical embodiment of the invention, the client machine 202 is the player'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'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.

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.

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.

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.

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.

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.

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's sex, race, address or account information. This is advantageous since players may not wish for their personal information to be shared with others.

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.

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.

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.

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.

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.

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'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.

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.

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.

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.

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.

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

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.

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.

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'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.

If there exists a post that matches User A'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's post, the process proceeds to confirm the event 712.

However, if at decision node 704, there does not exist a suitable post in the result set that matches User A'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's post 710.

In either the case of User A accepting User B's post 706 or User B accepting User A'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.

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' corresponding user. The “favorite” relation may be stored in the character database, thus creating a social graph of characters.

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's performance during the in-game event, which would impact each users' community reputation score.

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.

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.

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.

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.

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.

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.

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'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'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.

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.

Claims

1. A trusted information management system for a online virtual environment, the trusted information management system comprising:

a synchronization module, capable of receiving anonymized character profile information from a client; and

a trusted information management server, configured to receive said anonymized character profile information from said synchronization module,

whereby the trusted information management server is capable of managing scheduling of activities between the user's characters and characters controlled by other players of the online virtual environment.

2. The trusted information management system of claim 1 wherein said synchronization module resides on a client machine.

3. The trusted management system of claim 2 wherein said synchronization module is implemented as an add-on to a client.

4. The trusted information management system of claim 2 wherein said synchronization module is configured to receive anonymized character profile information from a client via an Application Programming Interface (API).

5. The trusted information management system of claim 2 wherein said synchronization module is configured to receive anonymized character profile information from a client by loading a file residing on the client machine.

6. The trusted information management server of claim 1, further comprising:

a trusted information management daemon, configured to receive anonymized character profile information from the synchronization module,

a character profile information database, capable of being queried and updated by said information management daemon,

a post database, capable of being queried and updated by said trusted information management daemon; and

an event database, capable of being queried and updated by said trusted information management daemon.

7. The trusted information management server of claim 6 wherein the post database contains posts predetermined normalized attributes such as a start and an end time, number of participating characters, and attributes of participating characters.

8. The trusted information management server of claim 6, wherein the character profile information database, the post database, and the event database are implemented by a relational database management system.

9. The trusted information management server of claim 6, further comprising:

a hypertext transport protocol (HTTP) server, capable of receiving HTTP requests and sending HTTP responses to a web browser and capable of communicating to the trusted information management daemon.

10. The trusted information management server of claim 6, further comprising:

a notification daemon, whereby said notification daemon is configured to receive event data from the event database and send configurable notification messages at configurable periods.

11. The trusted information management server of claim 10 wherein the notification daemon is capable of sending short message service (SMS) messages triggered by event data from the event database.

12. The trusted information management server of claim 10 wherein the notification daemon is capable of generating Really Simple Syndication (RSS) feeds triggered by event data from the event database.

13. The trusted information management server of claim 10, further comprising a mail server, whereby said mail server is configured to receive notification messages generated by the notification daemon and generate and deliver the notification messages as E-mail messages.

14. A client add-on to a client capable of communicating with a trusted information management server.

15. The client add-on of claim 14 whereby said client-addon is further configured to receive notification events from the trusted information management server and display the notification events in the client. A further add-on to a client capable of inserting the events scheduled in the website in the client calendar interface and notifying the character of the proximity of the event in time through the client.

16. A method for anonymous synchronization of character profile data comprising:

obtaining a trusted information management server,

receiving a user-initiated request for synchronization,

obtaining anonymized character profile information,

transmitting the anonymized character profile information to the trusted information management server,

receiving the anonymized character profile information; and

storing said anonymized character profile information on the trusted information management server.

17. A method for servicing search requests using a trusted information management server comprising:

receiving a search query from a client,

parsing the syntax of the search query into a representation containing terms,

looking up the terms parsed from the search query on the index of the appropriate database, in the trusted information management server, to generate a set of hits,

partitioning said set of hits into hit partitions based on a predetermined partitioning criterion,

sorting each of the hit partitions based on a predetermined sort criterion; and

outputting the hit partitions to the client.