(12) United States Patent
`Leahy et al.
`
`USOO621 9045B1
`(10) Patent No.:
`US 6,219,045 B1
`(45) Date of Patent:
`*Apr. 17, 2001
`
`(54)
`
`(75)
`
`(73)
`(*)
`
`(21)
`(22)
`
`(51)
`(52)
`(58)
`
`(56)
`
`SCALABLE VIRTUAL WORLD CHAT
`CLIENTSERVER SYSTEM
`
`Inventors: Dave Leahy, Oakland; Judith
`Challinger, Santa Cruz; B. Thomas
`Adler; S. Mitra Ardon, both of San
`Francisco, all of CA (US)
`Assignee: Worlds, Inc., San Francisco, CA (US)
`Notice:
`This patent issued on a continued pros
`ecution application filed under 37 CFR
`1.53(d), and is subject to the twenty year
`patent term provisions of 35 U.S.C.
`154(a)(2).
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 0 days.
`
`Appl. No.: 08/747,420
`Filed:
`Nov. 12, 1996
`(Under 37 CFR 1.47)
`Int. Cl. ............................................... G06F 15/16
`U.S. Cl. ............
`345/331; 709/204; 34.5/355
`Field of Search ..................................... 345/329, 334,
`345/335, 355, 976, 332, 330, 331, 419,
`427; 395/200.33, 200.34
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`2/2000 Hochstein et al. .
`Re. 36,574
`5,195,086 * 3/1993 Baumgartner et al. ......... 395/200.34
`5,206.934 * 4/1993 Naef, III ...............
`305,200.34
`5,347,306 * 9/1994 Nitta ...........
`... 345/302
`5,388,196 * 2/1995 Pajak et al. .......................... 345/329
`
`5,491,743
`5,572,248
`
`2/1996 Shiio et al. ..................... 395/200.34
`11/1996 Allen et al. .......................... 345/329
`OTHER PUBLICATIONS
`Dive-A Multi-User Virtual Reality System Swedish Insti
`tute of Computer Science, Sep. 18, 1993.*
`The Web’s Wave of Fun Electronics Communities Services,
`Nov. 9, 1998.*
`Valentine's Day Wedding in a Virtual World Newsbytes
`Copyright Feb. 1996.*
`“Release 1.0 Esther Dyson's Monthly Report,” EDventure
`Holdings Inc., Jun. 27, 1994, pp. 1-22. See particularly, pp.
`15–17 re: “Knowledge Adventure Worlds.”
`* cited by examiner
`Primary Examiner Raymond J. Bayerl
`Assistant Examiner-Cao H. Nguyen
`(74) Attorney, Agent, or Firm Townsend and Townsend
`and Crew LLP
`ABSTRACT
`(57)
`The present invention provides a highly Scalable architecture
`for a three-dimensional graphical, multi-user, interactive
`Virtual world System. A plurality of users can interact in the
`three-dimensional, computer-generated graphical Space
`where each user executes a client process to view a virtual
`world from the perspective of that user. The virtual world
`shows avatarS representing the other users who are neigh
`bors of the user viewing the virtual World. In order that the
`view can be updated to reflect the motion of the remote
`user's avatars, motion information is transmitted to a central
`Server which provides position updates to client processes
`for neighbors of the user at that client process. The client
`process also uses an environment database to determine
`which background objects to render as well as to limit the
`s
`movement of the user's avatar.
`5 Claims, 5 Drawing Sheets
`
`e
`
`IO
`
`Worlds (tm) Chot
`
`s
`
`
`
`3
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Welcome
`to
`Words
`Chat
`Click Me
`for Help
`
`Worlds, Inc. presents Worlds(tm)
`Chat
`-You are with
`angel2, PAULA, Ken, Budwoman,
`-You are with
`ange12, PAULA, W.J.
`-You are with
`el2, Ken, Dark Void, Heath
`TP.999
`To get a list of the people
`you are talking to, click the
`
`7
`
`KPAULA) hello everyone!
`<KEN> hows it going? LOL
`<COUNT BOND> Howdy all.
`
`5
`
`
`
`
`
`
`
`RPX Exhibit 1008
`
`

`

`U.S. Patent
`US. Patent
`
`Apr. 17, 2001
`Apr. 17, 2001
`
`Sheet 1 of 5
`Sheet 1 0f 5
`
`US 6,219,045 B1
`US 6,219,045 B1
`
`.58:29>foosoggy_gIf;2..3|2.2,:5N39...
`
`[5;2..El
`
`
`
`58.2%as..33:NEE
`
`2%:2:tE.aaSmmmdz.
`
`2:Eu.295:22..a;
`
`
`
`E7233£583.2:was:
`
`LE:2..STEa
`
`
`
`AE:mute;
`
`mute;2oEoBm;
`
`404wagon:masonAzwxv
`
`
`
`zocobgu23;A<43<¢v
`
`
`
`.=c€30:Aozom.rzzoov
`
`:20
`
`02«6:0
`
`3o:5,.
`
`m.
`ÇI
`
`RPX Exhibit 1008
`
`V65K
`/ 39/-/
`
`RPX Exhibit 1008
`
`

`

`U.S. Patent
`
`Apr. 17, 2001
`
`Sheet 2 of 5
`
`US 6,219,045 B1
`
`
`
`20
`
`CLIENT A
`
`
`
`20
`
`CLIENT B
`
`
`
`
`
`20
`
`CLIENT C
`
`
`
`20
`
`CLIENT D
`
`24
`
`VIRTUAL
`WORLD
`SERVER(S)
`
`A/6 2.
`
`RPX Exhibit 1008
`
`

`

`U.S. Patent
`
`Apr. 17, 2001
`
`Sheet 3 of 5
`
`US 6,219,045 B1
`
`
`
`
`
`
`
`
`
`
`
`
`
`ROOMS/
`WORLD
`DB
`
`04
`
`ROOMS/
`WORLD
`DB
`
`OBJ D
`LOOKUP
`
`NETWORK
`MESSAGE
`PROCESSOR
`
`OBJ D
`LOOKUP
`
`NETWORK
`MESSAGE
`PROCESSOR
`
`PROTOCOL
`OBJECT A
`
`8
`
`WORLD OBJECT
`
`85
`
`90
`USER STATE
`DB
`
`
`
`66
`
`6
`
`
`
`92
`ROOMS/WORLD
`DB
`
`A/6 3.
`
`RPX Exhibit 1008
`
`

`

`U.S. Patent
`
`Apr. 17, 2001
`
`Sheet 4 of 5
`
`US 6,219,045 B1
`
`TO NETWORK
`
`60
`
`----------------4-------
`
`O2
`
`00
`
`NETWORK
`PACKET
`PROCESSOR
`70
`T
`104 C 3 O
`ROOMS/WORLD
`DATABASE
`AWAAR IMAGE
`DB
`
`NETWORK
`MESSAGE
`PROCESSOR
`
`
`
`
`
`CHAT
`
`-
`
`
`
`a?
`
`PROCESSOR
`
`
`
`
`
`Ellis
`
`20
`
`CURRENT
`AVATAR POSITION
`REGISTER
`
`6
`
`
`
`
`
`
`
`INPUT
`DEVICES CD
`24
`CUSTOM AVATAR
`IMAGES DB
`
`
`
`
`
`AUDO
`COMPRESSOR/
`DECOMPRESSOR
`
`
`
`SHORT OBJECT
`LD LOOK UP
`
`GRAPCS
`COMPRESSOR/
`DECONPRESSOR
`
`
`
`
`
`REMOTE ANATAR
`POSITION TABLE
`
`
`
`REER G
`
`122
`
`DISPLAY
`
`CLIENT A
`
`RPX Exhibit 1008
`
`

`

`U.S. Patent
`US. Patent
`
`Apr. 17, 2001
`Apr. 17, 2001
`
`Sheet 5 of 5
`Sheet 5 0f5
`
`US 6,219,045 B1
`US 6,219,045 B1
`
`
`
`
`
`RPX Exhibit 1008
`
`RPX Exhibit 1008
`
`

`

`1
`SCALABLE VIRTUAL WORLD CHAT
`CLIENTSERVER SYSTEM
`
`US 6,219,045 B1
`
`2
`Internet. As used herein, the term "Internet” refers to the
`global inter-network of networks which communicates pri
`marily using packets sent according to TCP/IP (Transport
`Control Protocol/Internet Protocol) standards well known in
`the art of computer intercommunication. With Internet
`communications, true broadcasting is not even possible
`because the network's extent is not known or fixed. Thus,
`messages to all playerS must be sent as Separate messages.
`An additional problem with Internet communications is that
`packet delivery is not guaranteed nor is it even as reliable as
`a dedicated network.
`Therefore, what is needed is an efficient system for
`communication between many client Systems over dedicated
`or open networks to provide graphical interaction between
`uSerS operating the client Systems.
`
`SUMMARY OF THE INVENTION
`The present invention provides a highly Scalable archi
`tecture for a three-dimensional graphical, multi-user, inter
`active virtual world System. In a preferred embodiment, a
`plurality of users interact in the three-dimensional,
`computer-generated graphical Space where each user
`executes a client process to view a virtual World from the
`perspective of that user. The virtual world shows avatars
`representing the other users who are neighbors of the user
`viewing the virtual world. In order that the view can be
`updated to reflect the motion of the remote user's avatars,
`motion information is transmitted to a central Server process
`which provides position updates to client processes for
`neighbors of the user at that client process. The client
`process also uses an environment database to determine
`which background objects to render as well as to limit the
`movement of the user's avatar.
`A further understanding of the nature and advantages of
`the inventions herein may be realized by reference to the
`remaining portions of the Specification and the attached
`drawings.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`FIG. 1 is a client screen view in a virtual world system
`according to the present invention.
`FIG. 2 is a logical block diagram of the hardware ele
`ments of a virtual World System.
`FIG. 3 is a block diagram of the elements of one embodi
`ment of a virtual world System, showing two clients and one
`SCWC.
`FIG. 4 is a more detailed block diagram of a client system
`according to one embodiment of the present invention.
`FIG. 5 is an illustration of an avatar.
`
`DESCRIPTION OF THE PREFERRED
`EMBODIMENT
`Although the preferred embodiment of the present inven
`tion can be used in a variety of applications, as will be
`apparent after reading the below description, the preferred
`embodiment is described herein using the example of a
`client-server architecture for use in a virtual world “chat”
`System. In this chat System, a user at each client System
`interacts with one or more other users at other client Systems
`by inputting messages and Sounds and by performing
`actions, where these messages and actions are Seen and acted
`upon by other clients. FIG. 1 is an example of what such a
`client might display.
`Each user interacts with a client System and the client
`system is networked to a virtual world server. The client
`
`BACKGROUND OF THE INVENTION
`The present invention relates to the field of packet com
`munications. More Specifically, in one embodiment the
`invention provides an efficient communications network for
`client-Server networks with large numbers of clients.
`A client-Server network is a network where one or more
`Servers are coupled to one or more clients over a commu
`nications channel. Typically, each Server and each client is
`assigned an address So that each can determine which
`network messages are directed to it. While Such a System
`may have only one server, it typically has many clients. A
`15
`Server object is one which waits for a request: from a client
`object and then performs. Some Service in response to the
`client request. A client is an object that makes the request.
`The designation of a particular object (computer hardware
`and/or software process) as a “server” object or a “client”
`object is not fixed. Thus, a given object can be a Server for
`Some Services and a client of other Services.
`A typical computer network has one or more file and print
`servers with a number of clients, where the clients are the
`desktop computers or WorkStations of the computer users, all
`25
`coupled to a high-Speed network cable. Client-server com
`munications in Such a network are easily handled for Several
`reasons. When clients are not all communicating with the
`Server at once the Server need not be designed to handle all
`the clients at one time. Another reason is that the network
`traffic is much less than the network capacity furthermore,
`the clients in a typical computer network need not neces
`Sarily be communicating in real-time with the Server.
`However, where many client machines or processes are
`communicating with each other in real-time through the
`Server, Several problems arise.
`For example, where a client-server System is used for
`real-time exchange of information, Such as a distributed
`Virtual reality network where users at client machines visu
`ally and aurally interact with other users at other client
`machines, communication is much more difficult, especially
`where the information is high-bandwidth data Such as audio
`Streams, graphic images and image Streams. One application
`of Such a client-Server System is for game playing, where the
`positions and actions of each user need to be communicated
`between all the players to inform each client of the state
`changes (position, actions, etc.) which occurred at the other
`clients. The Server might maintain global State information
`and Serve as a data Server for the clients as they request
`Visual, program and other data as the game progresses.
`Some game Systems use a peer-to-peer architecture. In a
`peer-to-peer architecture, a copy of the data which is com
`mon to all clients is kept by the client and information which
`needs to pass between clients is broadcast over the network.
`This limits the number of clients which can be connected to
`the network, because the number of messages passing
`between clients is on the order of the square of the number
`of clients. With true broadcasting, one message is sent and
`all clients listen for it, but not all network topologies can
`handle broadcasts. Where less than all the clients are par
`ticipating in a game, for example, messages cannot be
`broadcast because there are clients which should not be
`receiving the broadcast message. Instead, the broadcast
`between the playerS is handled by generating one message to
`each player client.
`This architecture is further limited where the network is
`not a dedicated network, but is an open network, Such as the
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`RPX Exhibit 1008
`
`

`

`3
`Systems are desktop computers, terminals, dedicated game
`controllers, WorkStations, or Similar devices which have
`graphical displayS and user input devices. The term "client'
`generally refers to a client machine, System and/or process,
`but is also used to refer to the client and the user controlling
`the client.
`FIG. 1 is an illustration of a client screen display 10 seen
`by one user in the chat system. Screen display 10 is shown
`with Several stationary objects (wall, floor, ceiling and
`clickable object 13) and two "avatars” 18. Each avatar 18 is
`a three dimensional figure chosen by a user to represent the
`user in the virtual world. Each avatar 18 optionally includes
`a label chosen by the user. In this example, two users are
`shown: “Paula' and "Ken', who have chosen the “robot'
`avatar and the penguin avatar, respectively. Each user inter
`acts with a client machine (not shown) which produces a
`display Similar to Screen display but from the perspective of
`the avatar for that client/user. Screen display is the view
`from the perspective of a third user, D, whose avatar is not
`shown since D's avatar is not within D's own view.
`Typically, a user cannot see his or her own avatar unless the
`chat system allows “out of body' viewing or the avatar's
`image is reflected in a mirrored object in the Virtual world.
`Each user is free to move his or her avatar around in the
`Virtual world. In order that each user Sees the correct
`location of each of the other avatars, each client machine
`Sends its current location, or changes in its current location,
`to the Server and receives updated position information of
`the other clients.
`While FIG. 1 shows two avatars (and implies a third),
`typically many more avatars will be present. A typical virtual
`World will also be more complex than a single room. The
`virtual world view shown in FIG. 1 is part of a virtual world
`of Several rooms and connecting hallways as indicated in a
`World map pane 19 and may include hundreds of users and
`their avatars. So that the virtual world is scalable to a large
`number of clients, the virtual world Server must be much
`more discriminating as to what data is provided to each
`clients. In the example of FIG. 1, although a status panel 17
`indicates that Six other avatars are present, many other
`avatars are in the room, but are filtered out for crowd control.
`FIG. 2 is a simplified block diagram of the physical
`architecture of the virtual world chat system. Several clients
`20 are shown which correspond with the users controlling
`avatars 18 shown in screen display 10. These clients 20
`interact with the virtual world server 22 as well as the other
`clients 20 over a network 24 which, in the specific embodi
`ment discussed here, is a TCP/IP network Such as the
`Internet. Typically, the link from the client is narrowband,
`Such as 14.4 kbps (kilobits/second).
`Typically, but not always, each client 20 is implemented
`as a separate computer and one or more computer Systems
`are used to implement Virtual world Server 22. AS used here,
`the computer System could be a desktop computer as are
`well known in the art, which use CPU's available from Intel
`Corporation, Motorola, SUN Microsystems, Inc., Interna
`tional Business Machines (IBM), or the like and are con
`trolled by operation systems such as the Windows(R program
`which runs under the MS-DOS operating system available
`from Microsoft Corporation, the Macintosh(R) O/S from
`Apple Computer, or the Unix(E) operating System available
`from a variety of vendors. Other suitable computer systems
`include notebook computers, palmtop computers, hand-held
`programmable computing devices, Special purpose graphi
`cal game machines (e.g., those sold by Sony, SEGA,
`Nintendo, etc.), workStations, terminals, and the like.
`
`15
`
`25
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`US 6,219,045 B1
`
`4
`The virtual world chat system is described below with
`reference to at least two hypothetical users, A and B.
`Generally, the actions of the System are described with
`reference to the perspective of user A. It is to be understood
`that, where appropriate, what is said about user A applies to
`user B, and Vice versa, and that the description below also
`holds for a system with more than two users (by having
`multiple users A and/or B). Therefore, where an interaction
`between user A and user B is described, implied therein is
`that the interaction could take place just as well with users
`A and B having their roles reversed and could take place in
`the same manner between user A and user C, user D, etc. The
`architecture is described with reference to a System where
`each user is associated with their own client computer
`System Separate from the network and Servers, however a
`perSon of ordinary skill in the art of network configuration
`would understand, after reading this description, how to vary
`the architecture to fit other physical arrangements, Such as
`multiple users per computer System or a System using more
`complex network routing Structures than those shown here.
`A perSon of ordinary skill in the art of computer program
`ming will also understand that where a process is described
`with reference to a client or Server, that process could be a
`program executed by a CPU in that client or Server System
`and the program could be Stored in a permanent memory,
`such as a hard drive or read-only memory (ROM), or in
`temporary memory, Such as random access memory (RAM).
`A perSon of ordinary skill in the art of computer program
`ming will also understand how to Store, modify and access
`data Structures which are shown to be accessible by a client
`O SCWC.
`Referring now to FIG. 3, a block diagram is shown of a
`world system 54 in which a user A, at a first client system
`60 (client A), interacts with a user B at a second client
`system 60 (client B) via a server 61. Client system 60
`includes Several databases, Some of which are fixed and
`Some of which are modifiable. Client system 60 also
`includes Storage for program routines. Mechanisms for
`Storing, reading and modifying data on computerS Such as
`client system 60 are well known in the art, as are methods
`and means for executing programs and displaying graphical
`results thereof. One Such program executed by client System
`60 is a graphical rendering engine which generates the user's
`view of the virtual world.
`Referring now to FIG. 4, a detailed block diagram of
`client 60 used by a user, A is shown. The other clients used
`by other users are similar to client 60.
`The various components of client 60 are controlled by
`CPU 100. A network packet processor 102 sends and
`receives packets over network connection 80. Incoming
`packets are passed to a network message processor 104
`which routes the message, as appropriate to, a chat processor
`106, a custom avatar images database 108, a short object ID
`lookup table 110, or a remote avatar position table 112.
`Outgoing packets are passed to network packet processor
`102 by network message processor in response to messages
`received from chat processor 106, short object ID lookup
`table 110 or a current avatar position register 114.
`Chat processor 106 receives messages which contain
`conversation (text and/or audio) or other data received from
`other users and Sends out conversation or other data directed
`to other users. The particular outgoing conversation is
`provided to chat processor 106 by input devices 116, which
`might include a keyboard, microphones, digital Video
`cameras, and the like. The routing of the conversation
`message depends on a Selection by user A. User Acan Select
`to Send a text message to everyone whose client is currently
`
`RPX Exhibit 1008
`
`

`

`US 6,219,045 B1
`
`15
`
`35
`
`40
`
`25
`
`S
`on line (“broadcast'), to only those users whose avatars are
`“in range' of A's avatar (“talk”), or to only a specific user
`(“whispering”). The conversation received by chat processor
`106 is typically received with an indication of the distribu
`tion of the conversation. For example, a text message might
`have a “whisper” label prepended to it. If the received
`conversation is audio, chat processor 106 routes it to an
`audio output device 118. Audio output device 118 is a
`Speaker coupled to a Sound card, or the like, as is well known
`in the art of personal computer audio Systems. If the received
`conversation is textual, it is routed to a rendering engine 120
`where the text is integrated into a graphical display 122.
`Alternatively, the text might be displayed in a region of
`display 122 distinct from a graphically rendered region.
`Current avatar position register 114 contains the current
`position and orientation of A's avatar in the Virtual world.
`This position is communicated to other clients via network
`message processor 104. The position Stored in register 114
`is updated in response to input from input devices 116. For
`example, a mouse movement might be interpreted as a
`change in the current position of A's avatar. Register 114
`also provides the current position to rendering engine 120,
`to inform rendering engine 120 of the correct view point for
`rendering.
`Remote avatar position table 112 contains the current
`positions of the “in range' avatars near A's avatar. Whether
`another avatar is in range is determined a “crowd control
`function, which is needed in Some cases to ensure that
`neither client 60 nor user Aget overwhelmed by the crowds
`of avatars likely to occur in a popular virtual World.
`Server 61 maintains a variable, N, which sets the maxi
`mum number of other avatars. A will see. Client 60 also
`maintains a variable, N', which might be less than N, which
`indicates the maximum number of avatars client 60 wants to
`See and/or hear. The value of N'can be sent by client 0 to
`server 61. One reason for setting N' less than N is where
`client 60 is executed by a computer with leSS computing
`power than an average machine and tracking N avatars
`would make processing and rendering of the Virtual World
`too slow. Once the number of avatars to be shown is
`determined, server 61 determines which N avatars are clos
`est to A's avatar, based on which room of the world As
`avatar is in and the coordinates of the avatars. This proceSS
`is explained in further detail below. If there are less than N
`45
`avatars in a room which does not have open doors or
`transparent walls and client 60 has not limited the view to
`less than N avatars, A will See all the avatars in the room.
`Those avatars are thus “neighboring” which means that
`client 60 will display them.
`Generally, the limit set by server 61 of Navatars and the
`limit set by client 60 of N'avatars control how many avatars
`A sees. If server 61 sets a very high value for N, then the
`limit set by client 60 is the only controlling factor. In some
`cases, the definition of “neighboring” might be controlled by
`other factors besides proximity. For example, the Virtual
`World might have a video telephone object where A can
`Speak with and See a remote avatar. Also, where N or more
`unfriendly avatars are in close proximity to A's avatar and
`they persist in following A's avatar, A will not be able to See
`or communicate with other, friendly avatars. To prevent this
`problem, user A might have a way to filter out avatars on
`other variables in addition to proximity, Such as user ID.
`In any case, remote avatar position table 112 contains an
`entry for each neighboring avatar. That entry indicates where
`the remote avataris (its position), its orientation, a pointer to
`an avatar image, and possible other data about the avatar
`
`50
`
`55
`
`60
`
`65
`
`6
`Such as its user's ID and name. The position of the avatar is
`needed for rendering the avatar in the correct place. Where
`N' is less than N, the client also uses position data to Select
`N" avatars from the N avatars provided by the server. The
`orientation is needed for rendering because the avatar
`images are three-dimensional and look different (in most
`cases) from different angles. The pointer to an avatar image
`is an indeX into a table of preselected avatar images, fixed
`avatar image database 71, or custom avatar images database
`108. In a simple embodiment, each avatar image comprises
`M panels (where M is greater than two with eight being a
`suitable number) and the i-th panel is the view of the avatar
`at an angle of 360i/M degrees. Custom avatar images are
`created by individual users and Sent out over network
`connection 80 to other clients 60 which are neighbors of the
`CuStOm avatar uSer.
`Short object ID lookup table 110 is used to make com
`munications over network connection 80 more efficient.
`Instead of fully Specifying an object, Such as a particular
`panel in a particular room of a world avatar, a message is
`Sent from Server 61 associating an object's full identification
`with a short code. These associations are Stored in Short
`object ID lookup table 110. In addition to specifying avatars,
`the short object ID's can be used to identify other objects,
`Such as a panel in a particular room.
`Short object ID lookup table 110 might also store purely
`local associations. Although not shown in FIG. 4, it is to be
`understood that connections are present between elements
`shown and CPU 100 as needed to perform the operations
`described herein. For example, an unshown connection
`would exist between CPU 100 and short object ID lookup
`table 110 to add, modify and delete local short object ID
`associations. Similarly, CPU 100 has unshown connections
`to rendering engine 120, current avatar position register 114
`and the like.
`Client 60 includes a rooms database 70, which describes
`the rooms in the Virtual world and the interconnecting
`passageways. A room need not be an actual room with four
`walls, a floor and a ceiling, but might be simply a logical
`open Space with constraints on where a user can move his or
`her avatar. CPU 100, or a specific motion control process,
`limits the motion of an avatar, notwithstanding commands
`from input devices 116 to do so, to obey the constraints
`indicated in rooms database 70. A user may direct his or her
`avatar through a doorway between two rooms, and if pro
`vided in the virtual world, may teleport from one room to
`another.
`Client 60 also includes an audio compressor/
`decompressor 124 and a graphics compressor/decompressor
`126. These allow for efficient transport of audio and graphics
`data over network connection 80.
`In operation, client 60 starts a virtual world Session with
`user A Selecting an avatar from fixed avatar image database
`71 or generating a custom avatar image. In practice, custom
`avatar image database 108 might be combined with fixed
`avatar image database 70 into a modifiable avatar image
`database. In either case, user A Selects an avatar image and
`a pointer to the Selected image is Stored in current avatar
`position register 114. The pointer is also communicated to
`server 61 via network connection 80. Client 60 also sends
`Server 61 the current position and orientation of A's avatar,
`which is typically fixed during the initialization of register
`114 to be the same position and orientation each time.
`Rooms database 70 in a fixed virtual world is provided to
`the user with the Software required to instantiate the client.
`Rooms database 70 specifies a list of rooms, including walls,
`
`RPX Exhibit 1008
`
`

`

`US 6,219,045 B1
`
`15
`
`25
`
`35
`
`40
`
`7
`doors and other connecting passagewayS. Client 60 uses the
`locations of walls and other objects to determine how A's
`avatar's position is constrained. Rooms database 70 also
`contains the texture maps used to texture the walls and other
`objects. Avatar database 70 specifies the bitmaps used to
`render various predefined avatars provided with the client
`System. Using rooms database 70 and the locations, tags and
`images of all the neighboring avatars, then a view of objects
`and other avatars in the virtual world can be rendered using
`the room primitives database and the avatar primitives
`database.
`Instead of Storing all the information needed for rendering
`each room Separately, a primitives database can be incor
`porated as part of rooms database 70. The entries in this
`primitives database describe how to render an object (e.g.,
`wall, hill, tree, light, door, window, mirror, sign, floor, road).
`With the mirrored primitive, the world is not actually
`mirrored, just the avatar is. This is done by mapping the
`avatar to another location on the other side of the mirrored
`Surface and making the mirror transparent. This will be
`particularly useful where custom avatars are created, or
`where interaction with the environment changes the look of
`the avatar (shark bites off arm, etc.).
`The typical object is inactive, in that its only effect is
`being viewed. Some objects cause an action to occur when
`the user clicks on the object, while Some objects just take an
`action when their activating condition occurs. An example
`of the former is the clickable objects 13 shown in FIG. 1
`which brings up a help Screen. An example of the latter is the
`escalator object. When a user's avatar enters the escalator's
`Zone of control, the avatar's location is changed by the
`escalator object automatically (like a real escalator).
`The avatars in fixed avatar image database 71 or custom
`avatar images database 108 contain entries which are used to
`render the avatars. A typical entry in the database comprises
`N two-dimensional panels, where the i-th panel is the view
`of the avatar from an angle of 360*i/N degrees. Each entry
`includes a tag used to Specify the avatar.
`In rendering a view, client 60 requests the locations,
`orientations and avatar image pointers of neighboring
`remote avatars from Server 61 and the Server's responses are
`stored in remote avatar position table 112. Server 61 might
`also respond with entries for short object ID lookup table
`110. Alternatively, the updates can be done asynchronously,
`with Server 61 sending periodic updates in response to a
`client request or automatically without request.
`Rendering engine 120 then reads register 114, remote
`avatar position table 112, rooms database 70 and avatar
`image databases as required, and rendering engine 120
`renders a view of the virtual world from the view point
`(position and orientation) of A's avatar. AS input devices 116
`indicate motion, the contents of register 114 are updated and
`rendering engine 120 re-renders the View. Rendering engine
`120 might periodically update the view, or it may only
`update the view upon movement of either A's avatar or
`remote avatarS.
`Chat processor 106 accepts chat instructions from user A
`via input devices 116 and Sends conversation messages to
`Server 61 for distribution to the appropriate remote clients.
`If chat processor 106 receives chat messages, it either routes
`them to audio output device 118 or to rendering engine 120
`for display.
`Input devices 116 Supply various inputs from the user to
`Signal motion. To make movement easier and more natural,
`client 60 performs Several unique operations. One Such
`operation is "Squared forward movement' which makes it
`
`45
`
`50
`
`55
`
`60
`
`65
`
`8
`easier for the user to move Straight. Unlike ordinary mouse
`movements, where one mouse tick forward results in an
`avatar movement forward one unit and one mouse tick to the
`left or right results in Side movement of one unit, Squared
`forward movement Squares the forward/backward ticks or
`takes the Square root of the SidewaySticks or divides by the
`number of forward/backward ticks. For example, if the user
`moves the mouse F mouse ticks forward, the avatar moves
`F Screen units forward, whereas if the user moves the mouse
`F mouse units forward and L mouse units to the left, the
`avatar moves Funits forward and L/FScreen units to the left.
`For covering non-linear distances, (FL) mouse units (i.e., F
`forward, L to the side) might translate to (F.L) Screen units.
`AS mentioned above, user input could also be used to
`Signal a desire for interaction with the environment (e.g.
`clicking on a clickable object). User input could also be used
`to Signal for a viewpoint change (e.g. head rotation without
`the avatar moving, chat inputs and login/logout inputS.
`In summary, client 60 provides an efficient way to display
`a virtual, graphical, three-dimensional world in which a user
`interacts with other users by manipulating the positions of
`h