U.S. Pat. No. 8,261,199

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

As is known, users may view web pages within a browser and navigate to different web pages by clicking on links or typing in uniform resource locator addresses (URLs). Using the web browser, users typically return to previously visited web pages using “back” or “forward” buttons, or clicking on links within a browser history menu. Unlike the page-to-page navigation of the 2D environment, avatar navigation within a virtual world is much more fluid For example, while a virtual world typically provides a universe with many different locations, users generally have the freedom to move their avatars throughout any one location by walking, running, even flying. Accordingly, breakpoints are not as readily identifiable in the virtual world as they are in the 2D environment. Therefore, returning to a desired area requires a different approach.

Users may have their avatars back up, or re-trace their steps. However, re-tracing one's steps can be tedious, and even prove impossible if a user does not remember the path back to a desired location. Further, virtual worlds are dynamic, and when a user returns to a location in a virtual world, the scene may have changed. For example, other avatars may have come and gone from the location. There may be changes in scenery; objects may have been moved, etc.

Embodiments of the invention provide a method to allow a user to navigate through a virtual environment using breakpoints. Each breakpoint may contain a context of a virtual location within the virtual world, recorded for the moment in time when the user's avatar occupied the location. Further, in persistent virtual worlds, embodiments of the invention may restore the avatar to a breakpoint location, as well as restoring elements of the virtual world, based on what was present when the breakpoint was created. Embodiments of the invention may also present a snapshot of a breakpoint to the user, visually displaying a virtual location as seen by the user at the moment the breakpoint was captured.

In the following, reference is made to embodiments of the invention. However, it should be understood that the invention is not limited to specific described embodiments. Instead, any combination of the following features and elements, whether related to different embodiments or not, is contemplated to implement and practice the invention. Furthermore, in various embodiments the invention provides numerous advantages over the prior art. However, although embodiments of the invention may achieve advantages over other possible solutions and/or over the prior art, whether or not a particular advantage is achieved by a given embodiment is not limiting of the invention. Thus, the following aspects, features, embodiments and advantages are merely illustrative and are not considered elements or limitations of the appended claims except where explicitly recited in a claim(s). Likewise, reference to “the invention” shall not be construed as a generalization of any inventive subject matter disclosed herein and shall not be considered to be an element or limitation of the appended claims except where explicitly recited in a claim(s).

One embodiment of the invention is implemented as a program product for use with a computer system. The program(s) of the program product defines functions of the embodiments (including the methods described herein) and can be contained on a variety of computer-readable storage media. Illustrative computer-readable storage media include, but are not limited to: (i) non-writable storage media (e.g., read-only memory devices within a computer such as CD-ROM disks readable by a CD-ROM drive) on which information is permanently stored; (ii) writable storage media (e.g., floppy disks within a diskette drive or hard-disk drive) on which alterable information is stored. Such computer-readable storage media, when carrying computer-readable instructions that direct the functions of the present invention, are embodiments of the present invention. Other media include communications media through which information is conveyed to a computer, such as through a computer or telephone network, including wireless communications networks. The latter embodiment specifically includes transmitting information to/from the Internet and other networks. Such communications media, when carrying computer-readable instructions that direct the functions of the present invention, are embodiments of the present invention. Broadly, computer-readable storage media and communications media may be referred to herein as computer-readable media.

Embodiments of the present invention may also be delivered as part of a service engagement with a client corporation, nonprofit organization, government entity, internal organizational structure, or the like. Aspects of these embodiments may include configuring a computer system to perform, and deploying software, hardware, and web services that implement, some or all of the methods described herein. The software in these embodiments may be deployed in these embodiments using any suitable software fulfillment technique, including without limitation: (i) distributing non-rewritable storage media (e.g., CD-ROM disks readable by a CD-ROM drive or DVD-ROM disks readable by a DVD-ROM drive); (ii) storing a program on a network accessible storage media (e.g., a public website, a public FTP site), receiving a request for the program, and transmitting the program to the requester over the network. Aspects of these embodiments may further include analyzing the client's operations, creating recommendations responsive to the analysis, building systems that implement portions of the recommendations, integrating the systems into existing processes and infrastructure, metering use of the systems, allocating expenses to users of the systems, and billing for use of the systems.

In general, the routines executed to implement the embodiments of the invention, may be part of an operating system or a specific application, component, program, module, object, or sequence of instructions. The computer program of the present invention typically is comprised of a multitude of instructions that will be translated by the native computer into a machine-readable format and hence executable instructions. Also, programs are comprised of variables and data structures that either reside locally to the program or are found in memory or on storage devices. In addition, various programs described hereinafter may be identified based upon the application for which they are implemented in a specific embodiment of the invention. However, it should be appreciated that any particular program nomenclature that follows is used merely for convenience, and thus the invention should not be limited to use solely in any specific application identified and/or implied by such nomenclature.

FIG. 1is a block diagram illustrating a system100for identifying and presenting breakpoints in a virtual world, according to one embodiment of the invention. As shown, system100includes client computers110, a network130, and a server computer140. Client computer110and server computer140are intended to represent any type of computer, computer system or other programmable electronic device, including a portable computer, an embedded controller, a PC-based server, a minicomputer, a midrange computer, a mainframe computer, and other computers adapted to support embodiments of the invention. The network130could be any communications or computer network, or collection of networks capable of facilitating communications between the client110and the server140. In one embodiment, the network130is the internet.

As shown, client110includes a central processing unit (CPU)112, which obtains instructions and data via a bus126from a main memory114and storage122. The processor112could be any processor used to perform an embodiment the invention. The main memory114is any memory sufficiently large to hold the necessary programs and data structures. The main memory114could be one or a combination of memory devices, including Random Access Memory, nonvolatile or backup memory, (e.g., programmable or flash memories, read-only memories, etc.). In addition, main memory114and storage122may include memory physically located elsewhere in a client110, for example, on another computer coupled to the client110. Finally, client110is connected to the network130by a network interface124.

Main memory114includes an operating system115. Operating system115is the software used for managing the operation of the client110. Examples of operating systems115include UNIX, a version of the Microsoft Windows® operating system, and distributions of the Linux® operating system. (Note, Linux is at trademark of Linus Torvalds in the United States and other countries.) Illustratively, main memory114also includes a client application116and a user profile120.

In one embodiment, client application116provides a software program that allows a user to connect to a virtual world146, and once connected, to explore and interact with virtual world146. Further, client application116may be configured to generate and display a visual representation of the user within the immersive environment, generally referred to as an avatar.

The user's avatar is generally visible to other users in the virtual world, and the user may view avatars representing the other users. The client application116may also be configured to transmit the user's desired actions to a virtual world146on server140. The client application116may also be configured to generate and present the user with a display of the virtual world146. Such a display generally includes content from the virtual world146determined from the avatar's line of sight at any given time. For the user, the display may include the avatar of that user or may be a camera eye where the user sees the virtual world146through the “eyes” of their avatar.

The user may view the virtual world146using a display device106, such as an LCD or CRT monitor display, and interact with the client application using a mouse and keyboard104. Further, in one embodiment, the user may interact with client application116and virtual world146using a variety of virtual reality interaction devices128. For example, the user may don a set of virtual reality goggles that have a screen display for each lens. Further, the goggles could be equipped with motion sensors that cause the view of the virtual world146presented to the user to move based on the head movements of the individual. As another example, the user could don a pair of gloves configured to translate motion and movement of the user's hands into avatar movements within the virtual world146environment. Of course, embodiments of the invention are not limited to these examples and one of ordinary skill in the art will readily recognize that the invention may be adapted for use with a variety of devices configured to present the virtual world146to the user and to translate movement/motion or other actions of the user into actions performed by the avatar representing that user within virtual world146.

The user profile120may include criteria used to define a breakpoint152. Criteria can encompass a number of conditions within a virtual world146, including an avatar's actions. In one embodiment, a breakpoint is created when the conditions within a virtual world match the criteria specified in user profile120. Examples of criteria include movement (or a lack thereof), clicking on links or objects in the virtual world146or otherwise interacting with elements of the virtual world146in specified ways, communicating with other avatars or objects in the virtual world146, and viewpoint orientation. The breakpoint manager150on server140interacts with the user profile120to determine when to create a breakpoint152.

As shown, server140includes a central processing unit (CPU)142, which obtains instructions and data via a bus158from a main memory144and storage154. The processor142may be any processor used to perform the methods of the invention. The main memory144is any memory sufficiently large to hold the necessary programs and data structures. Main memory144could be one or a combination of memory devices, including Random Access Memory, nonvolatile or backup memory, (e.g., programmable or Flash memories, read-only memories, etc.). In addition, main memory114and storage154may be considered to include memory physically located elsewhere in a server140, for example, on another computer coupled to the server140via bus158. Server140is connected to the network130by a network interface156.

Illustratively, memory144includes virtual world146and a breakpoint manager150. As stated, virtual world146may be a software application that allows users to explore and interact with the immersive environment provided by virtual world146. The virtual world146may define a virtual “space” representing, for example, a street, a room, a town, a building with multiple floors, a forest, or any other configuration of a virtual space. Illustratively, virtual world146includes user context148.

User context148contains data describing the current set of elements and avatars within a virtual location of a virtual world, and the location being currently occupied by the user's avatar. In an example of user context148from a virtual location such as a virtual shopping center, the user context148may include the interior of a virtual store, the items for sale in the store, sales clerk avatars, a manager avatar, and other “shopping” avatars. The manager avatar corresponds to a user operating the virtual store. The elements for sale may include both elements of the virtual world (e.g., virtual clothing that a user may purchase for their avatar), and may also include a shopping environment that allow the user to purchase real-world goods or services.

According to some embodiments, user context148may include unseen elements and avatars. In the example of the virtual store, the user context148may also include other floors or departments of the store with their respective sales items and avatars. Other examples of unseen avatars and elements could include elements from virtual fantasy worlds, such as invisible avatars, trap doors, and other unseen, but potentially “active” elements of the environment provided by virtual world146.

Storage154represents both volatile and non-volatile memory storage. In addition, storage154may include memory physically located elsewhere, for example, any storage capacity used as virtual memory or a mass storage device or on another computer coupled to the server140via bus158(e.g., an attached NFS server). Illustratively, storage154includes breakpoints152. Breakpoints152include the requisite user context148that allows the breakpoint manager150to restore an avatar to a previously visited location or present a snapshot of the location as seen by the user at the moment the breakpoint152was recorded.

The breakpoint manager150may be configured to monitor an avatar's behavior within a virtual world146and identify breakpoints152. Further, the breakpoint manager150may present or restore a given breakpoint152at a user's request. When the conditions within the virtual world146satisfy the criteria specified by a given user profile120, the breakpoint manager150may identify the current user context148as a breakpoint152for the user associated with the user profile120, and store a breakpoint152capturing the current user context148. When the user subsequently requests the breakpoint152to be restored, the breakpoint manager150may transmit the context information for the breakpoint152to the virtual world146, which may then restore the user's avatar to the position specified for the breakpoint152.

FIGS. 2A and 2Billustrate an example scenario of identifying and presenting a breakpoint152in a virtual world146, according to one embodiment of the invention. Illustratively,FIG. 2Aincludes a “room X” with “door A”, “door B”, and an avatar240. In one embodiment, the user may specify the criteria in the user profile120that triggers a breakpoint152. For example, a user represented by avatar240may specify a lack of movement and clicking on objects as criteria for creating a breakpoint152. Further, the user may specify thresholds for a given criteria. A threshold may be a minimum magnitude required for a breakpoint152to be created for some user activity (or inactivity). The breakpoint manager150may compare thresholds to the magnitude of an action that occurs in the virtual world146. For example, for the breakpoints created based on a user clicking on an object, the magnitude may be the number of clicks on one object required before a breakpoint is created. Accordingly, a low threshold for the clicking on objects criteria could specify that one click is sufficient to trigger a breakpoint152. Similarly, higher thresholds for the clicking on objects criteria may require greater numbers of clicks on a particular object to trigger breakpoints152.

Because an avatar typically does not move continuously in a virtual world146, a high threshold may be appropriate for the lack of movement criteria. Otherwise, with a low threshold, the breakpoint manager150may identify breakpoints152any time the avatar240hesitates, resulting in so many breakpoints that a user could not effectively use the breakpoints to return to a previous location. Suppose then, for the purposes of this example, that the user specifies a high threshold for the lack of movement criteria, and a low threshold for the clicking on objects criteria. In this example, the high threshold for the lack of movement criteria is thirty seconds and the low threshold for the clicking on objects criteria is one click. Of course, the metric for thresholds mentioned herein are merely examples for the purposes of description, and the actual settings may be tailored to suit the needs in a particular case.

For an example of creating a breakpoint, considerFIG. 2A. Suppose the user does not move avatar240from its position in front of “door A” for one minute, and then moves the avatar240to the position in front of “door B” shown inFIG. 2B. Because the magnitude (one minute) of the criteria (lack of movement) exceeds the threshold (i.e., more than thirty seconds), the breakpoint manager150may identify a breakpoint152, capture the user context148(room X, doors A and B), and store a breakpoint152containing the user context148.

FIG. 2Bincludes, in addition to the features described inFIG. 2A, a breakpoint icon230. In one embodiment, the virtual world146may display an icon230in the position at which a breakpoint152is identified.FIG. 2Billustrates an icon230representing the breakpoint152described inFIG. 2A. According to one embodiment, a user may return the avatar240to the position indicated by icon230by simply clicking on icon230. In response, the breakpoint manager150may retrieve the breakpoint152indicated by icon230, and return avatar240to the position in front of “door A,” as shown inFIG. 2A.

Assume the user clicks on “door B” (perhaps to have the avatar240knock on “door B”). Because clicking on objects is a criteria for identifying breakpoints152, with a low threshold, the breakpoint manager150may identify a breakpoint152when the user clicks on “door B.”

According to some embodiments, identifying breakpoints152may depend on the cumulative “size” of the criteria contained in user profile120. In other words, after a user has specified criteria for identifying breakpoints152and thresholds for the respective criteria, the user may also specify how many of the criteria have to meet their respective thresholds before the breakpoint manager150identifies a breakpoint152. In the example where the criteria are a lack of movement and clicking on objects, the user may specify that both criteria have to meet their thresholds before the breakpoint manager creates a breakpoint152. In other words, the breakpoints152described inFIGS. 2A and 2Bare only identified if the avatar does not move for at least thirty seconds, and during that time the user clicks on door “A” or door “B.”

In one embodiment, the breakpoint size may be a cumulative calculation based on the magnitude of the breakpoint-triggering criteria. Instead of thresholds for the criteria, a user may specify the degree of influence a particular criteria has on the breakpoint size calculation. In other words, a lack of movement criteria with a high influence is more significant to the breakpoint size calculation than the clicking on objects criteria with a low influence. Further, the user may also specify a threshold for the breakpoint size. Accordingly, the breakpoint manager150identifies a breakpoint152only if the breakpoint size meets or exceeds the breakpoint size threshold.

Suppose then, that the user specifies that the breakpoint size threshold is low. Any lack of movement or clicking on objects by the avatar240may trigger a breakpoint152. On the other hand, suppose the breakpoint size threshold is high. Triggering a breakpoint152may require a significant magnitude for the clicking on objects criteria, while only requiring a modest magnitude for the lack of movement criteria, because of the high influence of the lack of movement criteria and the low influence of the clicking on objects criteria. Of course, the breakpoint size calculation considers all criteria in the user profile, and appropriate combinations of the magnitudes of a lack of movement and clicking on objects may trigger a breakpoint152.

FIGS. 3A and 3Billustrate example scenarios of identifying and presenting breakpoints152in virtual worlds146, according to one embodiment of the invention. The virtual location300(also referred to as virtual park300) includes trees310and315, a lake320, benches330and345, avatars240,342,344, and346, and a path350.

Because virtual worlds146are fluid environments, the content of a particular location300may change in the time between the breakpoint manager's150creating the breakpoint152, and the user's240restoring the breakpoint152.

Accordingly, in one embodiment, the user may restore a breakpoint152either statically or dynamically. In an example of a dynamic restore, assume a user clicks on the bench345to sit the avatar240down. Because clicking on objects is a criteria with a low threshold for creating breakpoints152, the breakpoint manager150identifies a breakpoint152at the moment the park300appears as depicted inFIG. 3A, and stores the breakpoint152.

The avatar240may then leave the virtual park300by restoring a breakpoint152for “room X,” as described inFIG. 2A. In a persistent virtual world146, the virtual park300may change to appear as illustrated inFIG. 3B.

FIG. 3Bdepicts the virtual park300after the avatar240restores a breakpoint152back to the virtual park300, dynamically. The park300is changed from the moment that the bench-click breakpoint152was created and the park300appeared as illustrated inFIG. 3A. For example, the avatar342, formerly on the path350has left the virtual park300. The avatars344and346have changed positions. The avatar344has moved further along the path340, and the avatar346has swum further across the lake320. Additionally, the tree310has disappeared. It may be that another avatar cut down the tree and took it away. Because the avatar240was not here, it may be impossible to know what happened to the tree310.

While the park300has changed in the time before the avatar240restores the breakpoint for the park300, the user may again view the park300as illustrated inFIG. 3Aby restoring the bench-click breakpoint152statically. In some embodiments, statically restoring a breakpoint152allows a user to see a virtual location300as if a snapshot of the location300is taken at the moment the breakpoint152is identified. In this example, by restoring the breakpoint152to the park300statically, the user may view the park300as depicted inFIG. 3A. However, because the virtual world146has actually changed, the virtual world146may prohibit an avatar's240interaction in a virtual location300after restoring a breakpoint152statically. Further, after a static restore, the virtual world146may require a user to “resume” the avatar's240presence in the virtual location300before allowing the avatar240to interact in the virtual world146again.

FIGS. 4A and 4Billustrate example scenarios of presenting breakpoints152available to a user in virtual worlds146, according to one embodiment of the invention. InFIG. 4A, the virtual location400depicts a virtual city street, and includes a virtual store405, a virtual DMV410, a virtual public library420, a breakpoint list430, and avatar240.

The breakpoint list430shows all the breakpoints152available to the avatar240(described inFIGS. 2A,2B,3A, and3B). In one embodiment, a user may invoke the breakpoint list430display by right-clicking a mouse or using some other form of interaction with virtual world146. The breakpoint list430contains three breakpoints152, “PARK,” “ROOM X, DOOR B,” and “ROOM X, DOOR A.” In this example, the breakpoints152are listed in reverse chronological order, but could be presented in various sequences depending on the details of an implementation. Further, the number of breakpoints presented in list430may be limited to a pre-determined number to avoid screen clutter.

In one embodiment, the breakpoint manager150may present the breakpoint list430by sequencing breakpoints152by size, as described inFIGS. 2A and 2B. In other words, a pre-determined number of breakpoints152would appear sorted by breakpoint sizes. As stated, a breakpoint size may be used to indicate the significance of a particular breakpoint152. Consider the example with breakpoint criteria of lack of movement, and clicking on an object. If the user both stands before an item for a long enough time to trigger a breakpoint152, and clicks on the object, it could mean that a breakpoint is more significant than if the user merely clicked on the object or only stood before an object long enough to trigger a breakpoint152. Further, a breakpoint152created because an avatar does not move for a minute may be more significant than a breakpoint152created because an avatar does not move for only thirty seconds. The longer wait may indicate a greater interest in a virtual location, or an object near the avatar when the breakpoint152is created.

FIG. 4Bdepicts the same location shown inFIG. 4A; however, instead of a breakpoint list430,FIG. 4Billustrates available breakpoints432,434, and436. According to one embodiment, the available breakpoints152may be displayed persistently on screen, positioned so as to indicate the relative direction to a given breakpoint152from the current location400. As shown inFIG. 4B, both breakpoints152for “ROOM X,” appear on the left side of the screen, indicating to the user that “ROOM X” is to the avatar's240left. Similarly, the breakpoint152for the “PARK” appears on the right side of the screen, indicating to the user that the park is on the avatar's240right. Visual clues such as these may assist the user in understanding the meaning of a particular breakpoint and in navigating through the virtual world146. Similarly, the breakpoint manager150may present the breakpoints152in a font size proportionate to the breakpoint size. As shown inFIG. 4B, the size of the arrow for the breakpoint “ROOM X, DOOR B,” is smaller than the arrow for breakpoint “ROOM X, DOOR A,” indicating a greater breakpoint size for “ROOM X, DOOR A” than “ROOM X, DOOR B.” Breakpoints can also be visually represented by thumbnail images of the screen taken at the time of the breakpoint.

FIG. 5Ais a flowchart illustrating a process500for creating breakpoints152, according to one embodiment of the invention. At step505, the breakpoint manager150monitors the behavior of a given avatar. At step510, the breakpoint manager150may compare the avatar's behavior to the criteria stored in the user profile120associated with that avatar. If the avatar's behavior does not match the criteria in user profile120, the process continues with the process at pointer “A,” which is described in detail inFIG. 5B.

If the avatar's behavior matches the criteria in the user profile120, at step515, the breakpoint manager150compares the magnitude of the avatar's behavior to the threshold(s) for the matching criteria in the user profile120. If the magnitude meets or exceeds the threshold, at step520, the breakpoint manager determines the current user context148for the newly identified breakpoint152.

Using the avatar with in the virtual park300shown inFIG. 3, the user context148includes all the objects (trees310and315, the lake320, the benches330and345, and the path350) and avatars342,344, and346in the park. After capturing the context148, at step525, the breakpoint manager150may store a breakpoint152based on the user context identified at step520. The process500then returns to step505.

FIG. 5Bis a flowchart illustrating a process530for restoring a breakpoint152, according to one embodiment of the invention. Process530flows from step510of the process500described inFIG. 5A. At step535, the breakpoint manager150may determine whether the user has requested to restore a given breakpoint152. If not, the process530continues to the process500at pointer “B,” which returns to the behavior monitoring process described inFIG. 5A.

If the user requests to restore a breakpoint152, then at step540, the breakpoint manager150retrieves the breakpoint152from storage140. At step545, the breakpoint manager150determines the user context148of the breakpoint152, recalling the details of a virtual location, e.g. park300, stored for the breakpoint152. At step550, the breakpoint manager150determines whether the user has requested the breakpoint to be restored dynamically. If not, the breakpoint manager150may display a snapshot of the virtual location300, as captured at the time the breakpoint152was created. The process530then returns to the behavior monitoring process described inFIG. 5A.

Otherwise, if the user requested the breakpoint to be restored dynamically, then the breakpoint manager sends the user context148to the virtual world146. In response, the virtual world146may return the user's avatar240to the location captured at the time the breakpoint152was created. For example, to dynamically restore, the virtual world146using the breakpoint created while the user's avatar was sitting on the pack bench, the virtual world may return the avatar240to the virtual park300, resulting in a scene displayed to the user like that depicted inFIG. 3B.

In one embodiment, the breakpoint manager150may modify the criteria stored in the user profile120to reflect a user's preferences for restoring a breakpoint152. In the example where lack of movement and clicking on objects are the criteria for creating a breakpoint, the user may exclusively restore breakpoints that are identified in response to the user's clicking on objects. In such a case, the breakpoint manager150may modify the influence of the criteria, changing the influence of the clicking on objects criteria to high, and the lack of movement criteria to low. Alternately, the breakpoint manager150may remove the lack of movement criteria from the user profile120altogether. Of course, one of ordinary skill in the art will recognize that many different permutations for modifying criteria may be useful in a particular case.

Advantageously, embodiments of the invention may be used to enhance a user's experience interacting with a virtual world. By capturing breakpoints that reflect some significant interaction with the virtual world, a user may restore their avatar to the location a given breakpoint was captured. Further, the restore may be dynamic or static, returning the user to another location in the virtual world, or presenting the user with a “snapshot” of the virtual world recorded when the breakpoint was created. By providing a flexible set of criteria used to specify when breakpoints are set within the virtual environment, users can customize the breakpoint generation process to suit their needs.

While the foregoing is directed to embodiments of the present invention, other and further embodiments of the invention may be devised without departing from the basic scope thereof, and the scope thereof is determined by the claims that follow.