U.S. Pat. No. 9,324,021

DETAILED DESCRIPTION OF THE INVENTION

The following detailed description of embodiments refers to the accompanying drawings, which illustrate specific embodiments of the invention. Other embodiments having different structures and operations do not depart from the scope of the present invention.

As will be appreciated by one of skill in the art, the present invention may be embodied as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, the present invention may take the form of a computer program product on a computer-usable storage medium having computer-usable program code embodied in the medium.

Any suitable computer usable or computer readable medium may be utilized. The computer-usable or computer-readable medium may be, for example but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or propagation medium. More specific examples (a non-exhaustive list) of the computer-readable medium would include the following: an electrical connection having one or more wires, a tangible medium such as a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), or other tangible optical or magnetic storage device; or transmission media such as those supporting the Internet or an intranet. Note that the computer-usable or computer-readable medium could even be paper or another suitable medium upon which the program is printed, as the program can be electronically captured, via, for instance, optical scanning of the paper or other medium, then compiled, interpreted, or otherwise processed in a suitable manner, if necessary, and then stored in a computer memory. In the context of this document, a computer-usable or computer-readable medium may be any medium that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. The computer-usable medium may include a propagated data signal with the computer-usable program code embodied therewith, either in baseband or as part of a carrier wave. The computer usable program code may be transmitted using any appropriate medium, including but not limited to the Internet, wireline, optical fiber cable, radio frequency (RF) or other means.

Computer program code for carrying out operations of the present invention may be written in an object oriented programming language such as Java, Smalltalk, C++ or the like. However, the computer program code for carrying out operations of the present invention may also be written in conventional procedural programming languages, such as the “C” programming language or similar programming languages, or in functional programming languages, such as Haskell, Standard Meta Language (SML) or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).

Aspects of the present invention are described below with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function/act specified in the flowchart and/or block diagram block or blocks.

The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

Aspects of the present invention provide systems, methods, and computer program products for avoiding non-intentional separation of avatars in a virtual world. Specifically, aspects of the present invention may involve detecting a first avatar seeking to enter a virtual world location. A virtual world location may be any type or form of virtual space in a virtual world, such as, for example, a store, a business, an arena, a building, a land area, an open space, a room, etc. Some aspects, if needed, determine whether a second avatar related to the first avatar is seeking to enter the same virtual location. This determination can be repeated for subsequent avatars if there are multiple avatars seeking to enter the virtual location. Depending on the embodiment, the situation is analyzed against predetermined rules to determine whether both the first avatar and second avatar can enter the first location or whether a substantially identical location needs to be created and they need to be transferred to the substantially identical location.

As an example, non-intentional separation of avatars may occur when a first avatar and any number of associated avatars attempt to enter a virtual world location, but the location does not have capacity for all of them together. A substantially identical location can be dynamically created and all avatars could be transported to the new location. From their respective displays, the associated avatars will be in a virtual world location substantially identical to the one they sought to enter and they will remain together as they attempted to enter.

The predetermined rule of capacity is used throughout for illustration purposes and is not meant to limit the different rules, as there are many other rules that can be established for a virtual location. For example, owners or managers of a virtual location may set a threshold for the number of avatars that are allowed in the virtual location at any given time to limit overcrowding. A threshold number of avatars may be related to a number for ideal avatar capacity for the virtual location or maximum avatar capacity for the virtual location. There are many other rules that can be used for a virtual location. For example, the owners or managers of the virtual location can set a threshold number of avatars based on other factors such as, for example, how large the area is (e.g., the larger the area the more avatars it can hold at one time and still have a positive user experience), how large the server capacity is that is hosting the virtual location, etc. Other than size capacity, other rules may dictate entry into a virtual location. For example, an owner or manager may specifically exclude particular avatars or types of avatars from a virtual location, which would, in turn, dictate that not all of a group may enter a virtual location if some in the group are specifically excluded.

As another example, avoiding non-intentional separation of avatars may occur when one or more associated avatars are proximate to a virtual world location in which another one or more associated avatars are located. The system can notify any of the avatar(s) (the ones outside or inside or both), and ask them if they would like to join, and if so, determine location capacity and if their presence would exceed capacity, dynamically create a new, substantially identical location and transport all associated avatars.

FIG. 1is a block schematic diagram depicting a general embodiment of an environment10in which aspects of the present invention may be implemented according to at least one embodiment. As illustrated, a plurality of users12-16may be connected to a network20, such as the Internet, LAN, WAN, etc. The users12-16interact with a virtual world system18. In particular, the virtual world system18may operate one or more virtual worlds in which users12-16may create one or more virtual personalities, sometimes referred to as avatars. The users, via their respective computers21, are capable of controlling their avatars to communicate with each other in various virtual scenarios. In general, users provide commands to the virtual world system18dictating various environments and situations to place their associated avatar(s) in and to control the actions and movements of the avatar. The virtual world system18receives these inputs and generates various graphic user interfaces (GUIs) to be displayed on each user's computer. Where users interact with each other in the virtual world, the virtual world system18displays scenes from the users' interactions on both users' computers.

As illustrated, the virtual world system18is typically implemented as a server/processor22accessible via the network20. This however, could include peer-to-peer type network configurations without a central host. (FIG. 1depicts only one possible embodiment for configuration of the virtual world system.) The server/processor22operates using various software modules stored in a file system24to create and operate the virtual world. The virtual world system18also includes data stored in the file system24typically in a datastore34.

In one embodiment, the datastore34of the virtual world system18may comprise data records28for each user and each avatar for each user, if the user has more than one avatar. While various data may be stored for each user and each user's avatar, for purposes of this invention, at least data are stored for each avatar regarding any friends or acquaintances or any other reciprocal or related avatars associated with each avatar of the user, and also recent communication history, hobbies, interests, etc. that would dictate non-separation guidelines for the avatars.

In the embodiment, the data records28may further comprise rules associated with anything including specific avatars, specific locations or even the entire virtual world. These rules may further comprise a set of non-separation rules based on separation preferences. These rules may also comprise rules associated with one or more virtual world locations, such as capacity rules, proximity rules, avatar exclusion rules, etc. These rules may be either user-defined rules or default rules that can be assigned to all avatars, locations or virtual worlds.

The system18may further include a detection module30for detecting avatars and associated avatars in a virtual world. In some embodiments, the system18further includes a transport module26and a location creation module32. An example of replicating, spawning or creating a new virtual space or location when an original virtual space or location reaches a maximum capacity that may be used for location creation module32is described in U.S. patent application Ser. No. 11/947,829 entitled “Automatic Increasing of Capacity of a Virtual Space in a Virtual World,” which was filed on Nov. 30, 2007, which is assigned to the same assignee as the present invention and incorporated herein in its entirety by reference.

The system18may further include computer readable instructions in the file system24so that modules can reference and query each other (when guided by the server/processor22), and send pertinent information to each other in order to perform the systems, methods and processes of the present invention.

In some embodiments, the data records28are stored in the datastore34accessible by the detection module30. In this embodiment, the rules may be stored in a simple file or may be stored in a relational datastore. In some embodiments, the rules are in the form of a rules engine embedded in the detection module30.

FIG. 2is a flow chart illustrating an example of a method100for avoiding non-intentional separation of avatars in a virtual world in accordance with an embodiment of the present invention. This embodiment illustrates a situation where a first avatar and second avatar seek to enter a virtual world location. Further, in this embodiment, the invention uses a central datastore of rules and determines which avatars seeking to enter are associated and whether the location has capacity for all associated avatars seeking to enter. If there is not capacity, in this embodiment, the method may dynamically create a substantially identical location and transport all associated avatars seeking to enter the location to the dynamically-created, substantially identical location.

In this embodiment, a first user12and a second user14direct their associated first and second avatars to a virtual world location. (The second avatar could be associated with the first user, as opposed to another user.) (FIG. 2, Block101). The server/processor18, through the detection module30, detects the presence of the first avatar and recognizes that the first avatar is attempting to enter the location. (FIG. 2, Block102).

The detection operation can be performed in a number of different ways. For example, the detection module30may detect all avatars within a proximity of the virtual world location. This proximity can be user-defined or a default value particular to the location, virtual world or anything else. As an alternative, the detection module30may receive an indication from the avatar that it desires to enter the location. The avatar may indicate its intent to enter the location with any visual, textual or oral communication or gesture in a virtual world that an avatar may perform.

In this particular embodiment, once the detection module30determines that the first avatar is seeking to enter the location, the detection module30determines all avatars associated with the first avatar. (FIG. 2, Block104).

The detection module30can perform the determination function in a number of different ways. For example, it may query the datastore34for the first avatar's friend list and compare the avatars on the friend list to all surrounding avatars to see if there is a match. As another example, the detection module30may query the datastore34for associated friend rules—e.g., all avatars within a certain distance (e.g, 5 feet) are treated as associated avatars, and determine associated avatars based on these rules. A final example may include the detection module30recognizing any visual, textual or oral communication or gesture performed between the first avatar and proximate avatars and determining that they are associated in this way.

The server/processor22, through the detection module30, may determine whether any identified associated avatars are seeking to enter the same virtual world location. (FIG. 2, Block106). It can accomplish this function in a number of ways as discussed above. Please note that the function of determining the associated avatars and determining whether they are attempting to enter the location are interchangeable. For example, the server/processor22can first determine all of the avatars seeking to enter the location, and then determine if any of those avatars are associated with the first user's avatar.

In this embodiment, once the detection module30has determined all of the associated avatars seeking to enter the location, it may then determine whether allowing the associated avatars to enter would violate a rule associated with the virtual location, such as exceeding the location's capacity. (FIG. 2, Block108). Please note that there may be other reasons why all associated avatars would not be allowed in the store together besides capacity, such as for example, Religious groups, solicitors, possible gang related associations, legal (restraining order) issues, etc.

For example, if three (3) associated avatars seek to enter a location which has a maximum capacity of 30 avatars, and already has 29 avatars, the 3 associated avatars should not be let into that location. The maximum capacity can be a default value or it can be user-defined, such as, for example, set by the location's owner or manager. The detection module30may query the datastore34to determine the location's maximum capacity.

Continuing with the over-capacity example of this embodiment, the detection module30may then pass computer readable instructions and data to the location creation module32. The location creation module32may then dynamically create a location substantially identical to the one the associated avatars seek to enter similar to that described in U.S. patent application Ser. No. 11/947,829.

The transport module26may notify the users, through a transport request, that they are all going to be transported to another location which can accommodate all of them. (FIG. 2, Block112). The notification may be in any form, including a GUI display. For example, the server/processor22creates proper GUIs and transmits them to the computers21associated with the users of the avatars for display.

The notification/transport request GUI may further include a feature where the avatars' respective users can either accept or decline the transport request. In this example, assuming that all avatars accept the transport request, they will all be transported by the transport module26to the substantially identical location together. If one or more avatars decline, the server/processor22may repeat the determination function108with the remaining associated avatars.

FIG. 3is a flow chart illustrating an example of a method200for avoiding non-intentional separation of avatars in a virtual world in accordance with another embodiment of the present invention. This embodiment illustrates a situation where a first avatar is proximate to a virtual world location in which another associated avatar(s) is located, but they together or individually are not aware of this. In this embodiment, the invention can identify the first avatar's associated avatar(s), determine whether any are currently located in the location and notify the first and/or second avatars, and to determine whether the first avatar would like to enter.

In this embodiment, a first user12and a second user14have associated avatars. The server/processor22first, through the detection module30, detects the first avatar. (FIG. 3, Block201). The detection module30may query the datastore34for proximity rules such as for example all avatars within 5 feet of a location, and for example, may simply detect all avatars that fall within the rule. There are numerous other ways in which the detection module30may detect the first avatar. Please note that the detection module30need not detect the first avatar's desire to enter the location.

Once the server/processor22detects a first avatar via the detection module30, the detection module30may determine whether an avatar associated with the first avatar is inside the location, user14's avatar in this example. (FIG. 3, Block202). For example, the detection module30may query the first avatar's friend list and compare it to the avatars already inside the location (or vice-versa). As another example, the detection module30may query the datastore34for data specific to the first avatar and determine their recent contacts to determine if there has been contact with any avatar located in the store. In another example, the detection module30may compare the avatar's friend list against the friend lists of the avatars in the store to determine if they have associated friends in common.

If the detection module30determines that the first avatar has an associated avatar inside the store, the server/processor22, through the transport module26, can create a GUI and notify the first avatar of the association, and give them the option of entering the store. (FIG. 3, Block204).

In some embodiments, the transport module26may notify the second avatar (user14's avatar) of the association, and allow them to extend a personal invitation to the first avatar (user12's avatar) to join them in the location.

If the first avatar decides to enter the location, the server/processor22performs the operations to determine whether the first avatar can enter the location. (FIG. 3, Block208). If the first avatar cannot enter without violating a rule (e.g., maximum capacity), then the location creation module32may dynamically create a substantially identical location, and the transport module26may notify and transport the associated avatars to the dynamically-created location as described above.

FIG. 4shows a diagram of avoiding non-intentional separation of avatars in a virtual world according to an example embodiment of the present invention. The diagram shows avatar A300, avatar B302, and avatar C304in a predetermined proximity306of each other and within a predetermined proximity or distance “D” of Store1320and Store2322. In this embodiment, avatar A300and avatar B302are associated avatars or have a relationship, such as the avatars may be on each others friend list or other relationship similar to that described herein. Avatar C304is this example does not have a relationship with avatar A300and avatar B302. All of the avatars are seeking to enter Store1320.

In this embodiment, a Merchant Gateway310of either Store1320or Store2322may detect avatars A300, B302and C304within the predetermined proximity306of each other and within the proximity or distance “D” of its associated store, Store1320. In this example, the proximity306is illustrated as a circular area. For example, the proximity306can be defined as all avatars within a circular area defined by a radius of ten feet. In this embodiment, the Merchant Gateway310for Store1320detects all avatars, determines whether the avatars are seeking to enter the store and then determines whether the avatars are associated using a Friendship Evaluation module314. The Merchant Gateway310and Friendship Evaluation module310may perform functions similar to those described with respect to the method illustrated inFIG. 2. Similarly, the Merchant Gateway310for Store1320could first detect avatar A300seeking to enter the store, determine its associated avatar B302using Friendship Evaluation314, and repeat the process for avatar C304. (SeeFIG. 2, Blocks102-106). The Merchant Gateway310for Store2322will also perform similar functions, but will end its inquiry when it determines that none of the avatars are seeking to enter Store2322.

Once the Merchant Gateway310determines that avatar A300and avatar B302are seeking to enter Store1320, it can determine whether to allow them to enter based on a predetermined rule such as, for example, store capacity. (SeeFIG. 2, Block108). The Merchant Gateway310can determine that Store1320has a maximum capacity of 15 avatars, for example, and that it already has 14 avatars currently in the store. As a result, the Merchant Gateway310determines that allowing 2 more avatars to enter the store would violate the store's capacity rule, and thus, the Merchant Gateway310can have a Transport Controller312transport avatar A300and avatar B302to Store3324, a dynamically-created location that is substantially identical to Store1320. (SeeFIG. 2, Blocks110,112).

AsFIG. 4illustrates, after avatars A300and B302enter Store3324, the Merchant Gateway310can determine whether to allow avatar C304to enter Store1320based on a predetermined capacity rule. (SeeFIG. 2, Block108). In this example, the Merchant Gateway310determines that Store1has capacity for one more avatar, so avatar C304is allowed to enter Store1320.

In the above embodiments, the various modules are described as software that is implemented by the server/processor to perform the various functions described above. In this instance, the various modules comprise computer code instructions for performing the various translation and display functions discussed above. It is understood, however, that various modules may also be a self contained systems with embedded logic, decision making, state based operations and other functions that may operate in conjunction with a virtual world simulation, such as Second Life.

The flowcharts and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

Although specific embodiments have been illustrated and described herein, those of ordinary skill in the art appreciate that any arrangement which is calculated to achieve the same purpose may be substituted for the specific embodiments shown and that the invention has other applications in other environments. This application is intended to cover any adaptations or variations of the present invention. The following claims are in no way intended to limit the scope of the invention to the specific embodiments described herein.