Attorney Docket No. 17376-5
`
`
`
`
`PATENT APPLICATION
`
`SCALABLE VIRTUAL WORLD CHAT CLIENT-SERVER SYSTEM
`
`Inventors:
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Assignee:
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Dave Leahy
`a US citizen
`6056 Romany Road
`Oakland, CA 94618
`
`Judith Challinger
`a US citizen
`244 Northrop Place
`Santa Cruz, CA 95060
`
`B. Thomas Adler
`a US citizen
`510 Third Street, Suite 530
`San Francisco, CA 94107
`
`S. [Mitra] Ardon
`a US citizen
`1056 Noe
`San Francisco, CA 94114
`
`Worlds Inc.
`a Delaware corporation
`605 Market Street, 14th Floor
`San Francisco, CA 94105
`
`Entity: SMALL
`
`
`
`
`
`
`
`
`
`
`
`TOWNSEND and TOWNSEND and CREW LLP
`Two Embarcadero Center, 8th Floor
`San Francisco, CA 94111-3834
`Telephone: (415) 576-0200
`
`IPR2015-01264, -01268, -01269, -01319, -01321, -01325
`EX. 2020
`Page 1 of 39
`
`

`
`PATENT
`Attorney Docket No. 17376-5
`
`
`1
`
`
`
`
`
`SCALABLE VIRTUAL WORLD CHAT CLIENT-SERVER SYSTEM
`
`
`
`
` 5
`BACKGROUND OF THE INVENTION
`
`The present invention relates to the field of packet
`
`
`communications. 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
`communications 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 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 coupled to a high-speed network cable. Client-server
`communications 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 necessarily 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.
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`IPR2015-01264, -01268, -01269, -01319, -01321, -01325
`EX. 2020
`Page 2 of 39
`
`

`
`2
`
`
`
`
`
`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
`visually 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
`common 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 participating 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 Internet. As used herein, the term "Internet"
`refers to the global inter-network of networks which
`communicates primarily 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
`
`5
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`IPR2015-01264, -01268, -01269, -01319, -01321, -01325
`EX. 2020
`Page 3 of 39
`
`

`
`3
`
`
`
`
`
`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
`
`
`architecture for a three-dimensional graphical, multi-user,
`interactive 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
`word. 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
`positions 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
`elements of a virtual world system.
`
`5
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`IPR2015-01264, -01268, -01269, -01319, -01321, -01325
`EX. 2020
`Page 4 of 39
`
`

`
`4
`
`
`
`
`
`FIG. 3 is a block diagram of the elements of one
`
`embodiment of a virtual world system, showing two clients and
`one server.
`
`
`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
`
`
`invention 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 system 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 interacts with a client machine (not shown) which
`
`5
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`IPR2015-01264, -01268, -01269, -01319, -01321, -01325
`EX. 2020
`Page 5 of 39
`
`

`
`5
`
`
`
`
`
`produces a display similar to screen display 10, but from the
`perspective of the avatar for that client/user. Screen
`display 10 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 "our 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 see 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 panel 19, and may include hundreds or
`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 embodiment 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
`
`5
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`IPR2015-01264, -01268, -01269, -01319, -01321, -01325
`EX. 2020
`Page 6 of 39
`
`

`
`6
`
`
`
`
`
`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.,
`International Business Machines (IBM), or the like and are
`controlled by operation systems such as the Windows® program
`which runs under the MS-DOS operating system available from
`Microsoft Corporation, the Macintosh® O/S from Apple Computer,
`or the Unix® operating system available from a variety of
`vendors. Other suitable computer systems include notebook
`computers, palmtop computers, hand-held programmable computing
`devices, special purpose graphical game machines (e.g., those
`sold by Sony, SEGA, Nintendo, etc.), workstations, terminals,
`and the like.
`
`
`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 programming
`will also understand that where a process is described with
`
`5
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`IPR2015-01264, -01268, -01269, -01319, -01321, -01325
`EX. 2020
`Page 7 of 39
`
`

`
`7
`
`
`
`
`
`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 programming will also understand
`how to store, modify and access data structures which are
`shown to be accessible by a client or server.
`
`
`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
`
`5
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`IPR2015-01264, -01268, -01269, -01319, -01321, -01325
`EX. 2020
`Page 8 of 39
`
`

`
`8
`
`
`
`
`
`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 A can select to send a text
`message to everyone whose client is currently 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
`distribution 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 A get overwhelmed by the
`crowds of avatars likely to occur in a popular virtual world.
`
`
`Server 61 maintains a variable, N, which sets the
`
`5
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`IPR2015-01264, -01268, -01269, -01319, -01321, -01325
`EX. 2020
`Page 9 of 39
`
`

`
`9
`
`
`
`
`
`maximum 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 closest to A's avatar, based on
`which room of the world A's avatar is in and the coordinates
`of the avatars. This process is explained in further detail
`below. If there are less than N 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 N avatars
`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 avatar is (its position), its
`orientation, a pointer to an avatar image, and possible other
`data about the avatar such as its user's ID and name. The
`position of the avatar is needed for rendering the avatar in
`
`5
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`IPR2015-01264, -01268, -01269, -01319, -01321, -01325
`EX. 2020
`Page 10 of 39
`
`

`
`10
`
`
`
`
`
`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 360*i/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
`communications 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
`
`5
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`IPR2015-01264, -01268, -01269, -01319, -01321, -01325
`EX. 2020
`Page 11 of 39
`
`

`
`11
`
`
`
`
`
`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 provided 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 71 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, 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 71 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
`
`5
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`IPR2015-01264, -01268, -01269, -01319, -01321, -01325
`EX. 2020
`Page 12 of 39
`
`

`
`12
`
`
`
`
`
`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
`incorporated 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
`
`5
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`IPR2015-01264, -01268, -01269, -01319, -01321, -01325
`EX. 2020
`Page 13 of 39
`
`

`
`13
`
`
`
`
`
`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
`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 sideways ticks 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 F
`units forward and L/F screen units to the left. For covering
`non-linear distances, (F,L) mouse units (i.e., F forward, L to
`the side) might translate to (F2,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
`
`5
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`IPR2015-01264, -01268, -01269, -01319, -01321, -01325
`EX. 2020
`Page 14 of 39
`
`

`
`14
`
`
`
`
`
`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 his or her avatar and sends chat messages to
`other users.
`
`
`Network connection 80 will now be further described.
` Commonly, network connection 80 is a TCP/IP network
`connection between client 60 and server 61. This connection
`stays open as long as client 60 is logged in. This connection
`might be over a dedicated line from client 60, or might be a
`SLIP/PPP connection as is well known in the art of network
`connection.
`
`
`The network messages which pass over network
`connection 80 between client 60 and server 61 are described
`immediately below briefly, with a more detailed description in
`Appendix A. Three main protocols exist for messaging between
`client 60 and server 61: 1) A control protocol, 2) a document
`protocol, and 3) a stream protocol. The control protocol is
`used to pass position updates and state changes back and forth
`between client 60 and server 61. The control protocol works
`with a very low bandwidth connection.
`
`
`The document protocol is used between client 60 and
`server 61 to download documents (text, graphics, sound, etc.)
`based on Uniform Resource Locators (URLs). This protocol is a
`subset of the well-known HTTP (Hyper-Text Transport Protocol).
` This protocol is used relatively sparingly, and thus
`bandwidth is not as much of a concern as it is with the
`control protocol. In the document protocol, client 60 sends a
`document request specifying the document's URL and server 61
`returns a copy of the specified document or returns an error
`(the URL was malformed, the requested URL was not found,
`etc.).
`The stream protocol is used to transfer real-time
`
`
`video and audio data between client 60 and server 61.
`Bandwidth is not as much a concern here as it is with the
`
`5
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`IPR2015-01264, -01268, -01269, -01319, -01321, -01325
`EX. 2020
`Page 15 of 39
`
`

`
`15
`
`
`
`
`
`control protocol.
`
`
`Each room, object, and user in a virtual world is
`uniquely identified by a string name and/or numerical
`identifier. For efficient communications, string names are
`not passed with each message between client 60 and server 61,
`but are sent once, if needed, and stored in short object ID
`lookup table 110. Thereafter, each message referring to an
`object or a user need only refer to the short object ID which,
`for 256 or less objects, is only an 8-bit value. Rooms are
`identified by a unique numerical value contained in two bytes
`(16 bits).
`
`
`
`The control protocol is used by client 60 to report
`
`the location and state information, such a "on" a