WO2005015880A1

WO2005015880A1 - Computer network architecture for persistent, distributed virtual environments

Info

Publication number: WO2005015880A1
Application number: PCT/US1999/027187
Authority: WO
Inventors: R. Coulter; Chun-Ming Chang; Yuntao Cui; Mike Fletcher; Todd Schneider; Eric Mason; Henry Gnad; Henning Pangels
Original assignee: Tpresence, Inc.
Priority date: 1998-12-29
Filing date: 1999-11-17
Publication date: 2005-02-17

Abstract

A shared telepresence system comprising a plurality of separate computers enabling their respective users to interact within a common virtual environment. The virtual environment comprises a VRML 'world' having a plurality of shared objects therein with which participants' avatars can interact. Individual participants in a telepresence session communicate with one another as necessary via a network connection such as the Internet. A session host is provided for coordinating the distributed control of the state of the shared virtual environment among a plurality of participants in a telepresence session. The session host may reside on and be executed by one of the participants of a telepresence session. The session host receives messages from each participant with information regarding changes to the environment and shared objects as they are made. The session host broadcasts messages to the participants. The messages contain information regarding the network locatoins at which incremental updated information about the changed state of the environment are stored. Individual participants retrieve incremental updated environment state information directly from the network locations designated in the session hosts' broadcasted messages. Distributed control of the state of the virtual environment is implemented such that no central server with extraordinary computational capability or bandwidth is required. A listing service is provided for validating the identity of users and providing network address information for users, including users having dynamic network addresses. In accordance with one aspect of the invention, a collection of extensions to the virtual reality modeling language (VRML) are provided to facilitate the establishment of the shared, dynamic, distributed and persistent virtual environment. The architecture of the disclosed invention is suitable for implementation of a transactional-based electronic commerce environment.

Description

TITLE

COMPUTER NETWORK ARCHITECTURE FOR PERSISTENT, DISTRIBUTED VIRTUAL ENVIRONMENTS

PRIORAPPLICATION This application is a continuation in part of U.S. Patent Application Serial No. 09/222,517 which claims the priority of prior provisional U.S. patent application Serial No. 60/108,194, filed on November 13, 1998.

FIELD OF THE INVENTION This invention relates generally to the field of electronic communication, and more particularly relates to a method and apparatus for providing "telepresence" connectivity between two or more users of computers communicating via a network.

BACKGROUND OF THE INVENTION "Telepresence" may be defined generally as the projection of a person's presence across a distance, achieved by integrating audio and visual communications technologies. Telepresence systems have been the topic of research for at least a decade, with many systems being developed for military and space applications. Telepresence may be regarded as an natural offshoot or extension of various computer-based simulation technologies, such as the well-known flight simulator systems developed over the years for the benefit of defense department, aviation, and even entertainment concerns. Telepresence technology may be distinguished from such simulation applications primarily by the former's emphasis on real-time interaction between two or more users, whereas simulation technology in its simplest form involves the presentation of a "virtual" environment to perhaps only a single user of the technology. As used herein, the expression "virtual environment" is e sensation of being within, and interacting within, an environment in which he or she is not actually present, and which may not actually even exist. Advances in computer technology have increasingly enabled virtual environments to involve the interaction between two or more human users-example of multi-user virtual environment-desktop videoconferencing in which two or more remotely-located computer users may interact as if actually situated in a common location. When accompanied by a real-time audio feed between the users, each user can interact with the other(s) in essentially the same manner as if each user was actually present at a single location, for example, in a conference room. The "virtual"-ness of the situation arises from the reality that the participants may in fact be located in quite distant locations with respect to one another. Typically the "virtual environment" is established primarily through the use of visual

(video) and aural (sound) stimuli, although the extension of the virtual environment to include other stimuli (e.g., tactile, or even olfactory, equilibraic, or others) would be apparent to those of ordinary skill in the art. Virtual environment-technology has,, given rise to the concept of an "avatar," or simulated visual representation of a person or thing within a virtual environment. Those of ordinary skill in the art will appreciate that "the Internet," commonly described as "a global interconnection of computer networks," is by its very nature difficult to define with precision. It is inherently dynamic in its topology, geographic extent, patronage, oversight, application, and accessibility, but otherwise sufficiently well-known to be referred to herein simply as "the Internet. The following abbreviations will also be referred to herein:, uniform resource locators ("URLs") the "hypertext transfer protocol" ("http"), and the "transmission control protocol/Internet protocol" ("TCP/IP").

SUMMARY OF THE INVENTION The present invention is a system for supporting shared, multi-user Internet telepresence sessions. Internet telepresence allows users to project their presence over the Internet into 3D virtual reality spaces. Generally, the system of the present invention is produced by integrating a virtual reality graphics engine such as the CosmoPlayer 2.1 of Computer Associates, Inc.; an Internet telephony system; and a collection of file transfer protocols; with a client / server application - also called a node (hereinafter also referred to as "N").

Telepresence sessions in the present invention are enabled by the creation of a novel network communications system that is comprised of a set of client / server applications linked in a decentralized network architecture. The network communications system links together a number of users who wish to share the experience of a single virtual reality world. The shared world experience is created by rending the same world scene on each user's local machine. Data is passed among the users to maintain a consistent world state, to support Internet telephony, and to transfer files. In the present invention, one of the novel features is the use of a d "client / server application". This software module can act as either a network client or a network server, depending upon the needs of the user and of the system. By combining the capabilities of client and server into a single application, the network topography generalizes from the classical central server architecture to a generic set of interconnected nodes, which is referred to herein as a decentralized server architecture. The decentralized architecture has several advantages over centralized architectures of the prior art. In the first place the architecture of the present invention is generally more flexible; more robust to failure and more graceful in degradation; and more efficient in its utilization of available resource.

In a presently preferred embodiment of the invention, any node in the network (and therefore any user) can act as a network host. The function of network host can be dynamically reassigned among network nodes as needed. The invention also provides more efficient utilization of available bandwidth, especially where intelligent monitoring of network messaging permits the application of classical network optimization solutions, such as dynamic programming. Further efficiencies are obtained in the present invention by reducing the required messaging sets to be delivered among system nodes. Scene geometries, for example, are downloaded and locally cached once, minimal sets of state information describing the configuration of system objects are passed thereafter. File descriptors are passed to users rather than entire files - users may then load files directly to their local machine, rather than through a central server.

In a presently preferred embodiment, the system nodes enable point to point transfer of digital data throughout the network. The integration of compression schemes specifically enables the support of Internet telephony in addition to general file transfer. Distribution of data among multiple nodes can be supported, assuming the availability of sufficient network bandwidth. Interactive objects allow passing and visualization of data within the virtual reality world. File transfer and image display objects allow users to import and display files and images for other users sharing the telepresence session. Interactive objects provide maximum system integrability as they can be tied to databases, back-end systems, shopping cart systems, and other general corporate information systems.

Connection information is provided by a database server (the Listing Server) which maintains a listing of the IP address of each node within the system. The listing server enables users to employ dial-up services where their IP address is dynamically allocated. In addition, the listing server can track system usage parameters; telepresence site usage; world usage; and can be expanded to track user behavior within individual worlds.

Accordingly, the present invention is directed to a shared telepresence system for enabling multiple users, who may be remotely located with respect to one another, to interact within a shared virtual environment. More generally, the present invention relates to a distributed architectural arrangement whereby a plurality of computers cooperate to establish a persistent, shared virtual environment within which one or more users may interact, and obtain and exchange information.

In accordance with one aspect of the invention, a session host software component is provided for a telepresence session. In one embodiment, the session host is a software module which may reside and be executed on the computer(s) of one or more of the participants in the telepresence session. As users (as e.g. represented by their avatars) navigate within the virtual environment, they periodically exchange messages with the session host. Users may send messages requesting information about the status and attributes of shared objects defined within the virtual environment, and may also send messages informing the session host that they have changed the state of the environment or of a shared object within the environment. The session host responds to requests for state information about the environment and objects within the environment with a message identifying for the requesting user(s) the location of the requested information. Notably, the session host does not necessarily itself provide the requested information, but may provide only an identification of the location of the requested information. When individual users need the information, they are responsible for establishing a link, e.g., via the Internet, to the location identified by the session host, to obtain the desired state information. When the session host is informed of a change in the state of the shared environment made by one of the participants in the session, the host provides this information to all other users. The host does not necessarily provide the changed state information itself to the users, but may merely identify the location from which the changed information may be obtained. In accordance with another aspect of the invention, the distributed control of the state of the virtual environment among all participants in a telepresence session is accomplished without the necessity of a large, computationally powerful, high-bandwidth central server. The present invention relates in another aspect to a set of architectural attributes for providing distributed, persistent, shared virtual environments, where the communications protocols employed may be dynamically reconfigured in real-time to improve quality of service by reallocating bandwidth usage. Improved quality of service may exist in reduced system latencies, reduced processor overhead, improved network flow and the like. The architecture in accordance with the present invention enables the employment of the principles of operations research including, but not limited to, the solutions to linear and dynamic programming problems (well known branches of operations research mathematics). In accordance with still another aspect of the invention, communication between nodes is achieved through communication between modules. Communication between nodes is dynamically reconfigurable by altering the path through the network of nodes through which messages are selectively passed between any selected nodes, e.g. communications in the network may be point to point, broadcast, daisychained, etc... Messages may be passed from one node to another through one or more intermediary nodes, which may take one or more of the following actions: the message be forwarded to one or more nodes; the message may be acted upon in the present node; and the like. In accordance with still another aspect of the present invention, the architecture of the present invention is implemented by a system comprising general-purpose personal computers operating over the Internet or like network. Each of the computers comprises, or is a constituant component of, one or more "nodes," where each node comprises one or more software "modules." In accordance with another aspect of the invention, the software implementation of the various modules in a given system may not be the same at each node, e.g. one module may be tailored toward broadcast and another might save messages without acting upon them; both would use the same communication protocol, but perform different functions. In accordance with another aspect of the invention, a collection of extensions to the virtual reality modeling language ("VRML") are provided to support the distributed architectural arrangement used to establish a persistent and dynamic virtual environment. The extensions include: the addition of system-level hooks to allow VRML content to affect and be affected by system-level elements of individual users' computers; user interface mechanism to allow VRML content to function as control interfaces within the shared virtual environment; enhance inter-object and inter-participant messaging flexibility; definitions of shared, metaphor-mediated simulation systems within VRML environments for visualization of files; and a system for facilitating run-time binding of animations and controls within a multi-user VRML system. One embodiment of the invention, referred to as the Holodesk application, comprises a Communicator Node made up of a MuTech module, an Achat module, an http module, a link module, and a listing module, and a Connector Node made up of one or more link modules and a listing module. A listing node is also preferably included for coordinating information regarding the identities and addresses of nodes that may be available for participation in a telepresence session. The disclosed system is believed to be particularly beneficial for establishing virtual environments adapted to support electronic commerce transactional interaction among a plurality of users. BRIEF DESCRIPTION OF THE DRAWINGS The foregoing and other features and aspects of the subject invention may be best understood with reference to a detailed description of a specific embodiment of the invention, which follows, when read in conjunction with the accompanying drawings, in which: Figure 1 is a block diagram depicting the hardware configuration and software architecture of a multi-user telepresence system in accordance with one embodiment of the invention; Figure 2 is a depiction of the appearance of a graphical user interface presented to a user of the system of Figure 1, showing one view of a virtual environment; Figure 3 is depiction of the appearance of a graphical user interface presented to a user of the system of Figure 1, showing a different view of the virtual environment from

Figure 2; Figure 4 is depiction of the appearance of a graphical user interface presented to a user of the system of Figure 1, showing still a different view of the virtual environment from Figure 2; Figure 5 is a block diagram depicting the topology of a telepresence system in accordance with one embodiment of the invention; Figure 6 is a block diagram depicting an alternative topology of the telepresence system from Figure 5; Figure 7 is a block diagram illustrating another alternative topology of the telepresence system from Figure 5; Figure 8 is a block diagram illustrating a message passing protocol implemented in the system from Figure 5; Figure 9a is a flow diagram illustrating the procedure followed for a user, via its connection service 40, to connect to a telepresence session; Figure 9b is a flow diagram illustrating the steps taken by a user's Holodesk™ application upon connection to a telepresence session; Figure 9c is a flow diagram illustrating the procedure undertaken when a telepresence session participant wishes to introduce an electronic file into the virtual environment associated with a telepresence session; Figure 9d is a flow diagram illustrating the steps associated with initiation of an AChat (audio chat) connection between two participants in a telepresence session; Figure 9e is a flow diagram illustrating the steps associated with initiation of a text chat connection between two participants in a telepresence session; Figure 9f is a flow diagram illustrating the process of exchanging MUTech messages across connections 14 in a system 100 in accordance with the disclosed embodiment of the mvention; and Figure 9g is a flow diagram illustrating the steps involved in creation of user profile with listing service module 18. DETAILED DESCRIPTION OF A SPECIFIC EMBODIMENT OF THE INVENTION LEXICON The present disclosure, relating to flexible, distributed, and dynamic software and network architectures suitable for the establishment of persistent distributed telepresence or virtual reality environments, makes use of the following terminology: Network: A connection between or among two or more nodes. Local Telepresence Network, a group or sub-group of interconnected nodes. Nodes: A grouping of one or more modules which may be interconnected so as to form a network. One or more nodes may reside on a single computer, or a node may be distributed across multiple interconnected computers.

Module: A generalized term referring to a software implementation of an input output function. Modules are typically implemented as computer software programs, routines, or subroutines. Modules are implemented on nodes and hence may be implemented on one computer or on a plurality of interconnected computers. Telepresence Session: A sequence of events in which one or more users accesses nodes in a network so as to perceive and interact within a virtual environment. Because of the persistent nature of the virtual environment as established in accordance with the principles of the present invention, multiple telepresence sessions may be started, stopped, and resumed within a given virtual environment. Link Module: a specialized module for supporting communication between nodes in a network. User Interface (UI) Module: An interface between a user and one or more modules. Streaming Module: A module used to encode, send, route, receive, and decode data packets, data streams and the like. MUTech Module: A streaming module with additional characteristics, such as login, user identification and tracking, and the like; a module employed to track environment state, structure and/or pose information. AChat Module: A module for supporting streams of audio data between two or more nodes. VChat Module: A module for supporting streams of video data between two or more nodes. TChat Module: A module for supporting streams of text data between two or more nodes. Http Module: A module supporting http communication between two or more nodes. Listing Module: A module that updates and tracks node addresses, thereby enabling nodes with potentially dynamic network addresses to connect to one another Arbitration Module: A module that arbitrates between nodes to determine what roles different modules within the node may have during a given telepresence session. Database Module: A module that makes a database available to other modules. Artificial Intelligence (Al) Module: A module that uses Al algorithms to access database information and operate on the information, including but not limited to the contents of the database and the pose information in the world. World: A collection of static variables (such as geometry, texture, color, and the like) maintained by one or more nodes in a network and accessible from one or more nodes on such network. A World may contain one or more independent or dependent objects that may be inserted or removed from the world, and whose state may be changed. Also referred to herein as "Virtual Environment." State: As applied to a virtual environment, state refers to user or system variable parameters which can be included in structure to provide change therein. Structure: Fixed environment state information which may include scalar data such as integers and floating-point values as well as character strings and combinations of sealers identifying properties such as geometry, texture, color. Pose: The union of environment state and structure information. MUTech Node: A node containing a MUTech module and is capable of changing the state of a virtual environment. Passivated node: A node containing a MUTech module, but not capable of changing the state of a virtual environment. Support node: A node without a MUTech module. Distributed environment: A pose which can be observed and / or altered from one or more nodes Persistent environment: A virtual environment which maintains pose memory after execution. Shared Virtual Environment: A virtual environment whose pose is identical as perceived from all connected nodes.

More detailed definitions, clarifications, and/or descriptions of the foregoing terms shall be provided in the disclosure below.

OVERVIEW OF HARDWARE AND NETWORK ARCHITECTURE Referring to Figure 1, there is shown in block diagram form a representation of the hardware configuration and software architecture of a share telepresence system 10 in accordance with one embodiment of the invention. At the outset, it is to be noted that in the interest of clarity, not all features of actual implementations of a shared telepresence system are described in this specification, or in equal levels of detail. It will of course be appreciated that in the development of any such actual implementation, as in any such project, numerous engineering and programming decisions must be made to achieve the developers' specific goals and subgoals (e.g., compliance with system- and business-related constraints), which will vary from one implementation to another. Moreover, attention will necessarily be paid to proper engineering and programming practices for the environment in question. It will be appreciated that such a development effort might be complex and time- consuming, but would nevertheless be a routine undertaking for those of ordinary skill in the field of computer application development having the benefit of this disclosure. In the embodiment of Figure 1, two computers 12-1 and 12-2 are shown. The reference numeral 12 shall be used herein to refer generally to a computer such as 12-1 or 12-2 as shown in Figure 1. As will hereinafter become apparent, and in accordance with one aspect of the invention, each computer included as part of a shared telepresence system 10 in accordance with the disclosed embodiment is configured substantially identically with all others in the system (although it is to be understood that each computer may differ in terms of its particular make and model, processing speed, memory capacity, and so on). Further, although only two computers 12 (12-1 and 12-2) are shown in the system 10 of Figure 1, it is specifically contemplated that any number of computers 12 may be included in a given implementation of the invention or for a given telepresence "session" in which multiple users at mutually remote locations interact within a virtual environment. In one embodiment, the invention is implemented as a computer software application, hereinafter referred to as the "Holodesk " application, suitable for execution on "conventional" personal computers ("PCs"). "Conventional" PCs are currently nominally characterized as being based on a 133- to 450-MHz Pentium™ class of microprocessor platform with, in a typical configuration, 32 or more megabytes of on-board random access memory ("RAM"), a one or more gigabyte capacity hard disk drive mass storage unit, and a 28.8 kilobit-per-second (kbps) or faster modem with associated software for providing connectivity to the Internet. Of course, a "conventional" PC-class of computer will also have standard peripheral equipment, including a keyboard, mouse (or other cursor control device), and graphics display monitor. Notably, in accordance with one aspect of the invention, the present invention does not rely upon the provision of a central computer or computational facility having one or more computers of substantially greater computational power, memory capacity and, most significantly, connectivity bandwidth, such as, for example, a server computer facility with Internet connectivity via a "Tl" telecommunications link, in order to be advantageously practiced. Moreover, in accordance with another aspect of the invention, none of the computers 12 included in system 10 is required to have extraordinary computational, processing, data storage, or communications capabilities. With continued reference to Figure 1, a communications link 14 is shown between computer 12-1 and 12-2. In the disclosed embodiment, link 14 is intended to represent an electronic data connection between the computers, which connection may involve a direct connection, connection via a local area network (LAN), connection via a wide-area network (WAN), and/or, notably, connection via the Internet. It is to be understood that if more than two computers are included in a given telepresence session in accordance with the disclosed embodiment, electronic communications links similar to link 14 in the exemplary embodiment of Figure 1 may be established as necessary between any two computers 12 in the system 10. The exact nature of the communications connection(s) 14 in system 10 may vary depending upon the respective physical locations of the computers 12 included in system 10. For very remotely located computers, connection 14 may perhaps be best established via the Internet, whereas for computers 12 located within the same building, for example, connection(s) 14 may be advantageously made via a LAN. In any event, the present invention is believed to be particularly advantageous in the context of multiple computers communicating via the Internet. Those of ordinary skill in the art will appreciate that to the extent links 14 between computers 12 involve connection via the Internet, what is represented by link 14 in Figure 1 may incorporate several components, including, for example, a connection between a modem associated with computer 12 via telephone lines to an Internet service provider ("ISP") for connection via the Internet to another computer 12 which may be similarly coupled to the Internet via a modem and telephone line connection to another (or the same) ISP. The details of the particular mode of connection used to establish electronic communication link(s) 14 between two computers 12 in system 10 would be well understood by those of ordinary skill in the art and are not believed of any particular relevance to the present disclosure. Hence, such details about communications connection(s) 14 will not be further discussed herein. Similarly, Figure 1 shows that computers 12-1 and 12-2 in system 10 are connected via links 14 to a listing service module 18. Again, links 14 may be established in accordance with any one of numerous well-known computer connectivity schemes, including by way of example but not limitation, direct connections, LAN or WAN connections, and or Internet connections. Again, the details of how links 14 in system 10 are established are not believed to be of any particular relevance for the purposes of the present disclosure, and will not be further discussed herein. Listing service module 18 may operate on conventional PC class of computers. The primary function of listing service module 18 is to establish and maintain a telepresence listing service represented by block 20 in Figure 1. As will be hereinafter described in further detail, listing service module 18 maintains a mapping of the identities of participants in a telepresence session to their last known online addresses, for example, their last known Internet addresses. When two or more users wish to initiate a telepresence session in accordance with the presently disclosed embodiment, each user will establish a connection 14 with and consult listing service module 18 to obtain the address(es) of the other users intended to be included in the particular telepresence session being initiated. Obtaining this address information enables each user to establish, as necessary, connections 14 with other users. As noted above, the present invention is implemented in the form of a computer application adapted to be executed by each computer 12 included in system 10. This application is sometimes referred to herein as the Holodesk application, and the software architecture of the Holodesk application is what is represented by the blocks within each computer 12 shown in Figure 1. In the presently preferred embodiment, the Holodesk application is implemented as one or more computer programs or modules written in the C++ programming language (although those of ordinary skill in the field of computer science will appreciate that the application(s) may be written in other programming languages). The Holodesk application comprises a plurality of individual functional components, including, as shown in Figure 1: a graphical user interface component 20 having associated therewith a graphics component 21, a text component 22, and a list component 24; a listing module 26; a MUTech module 28; a link module 30; an AChat module 32; a service manager module 34; an http module 38. Finally, each computer has associated therewith a connection service module 40. The Holodesk application will be described hereinbelow in terms of these various architectural components.

GRAPHICAL USER INTERFACE 20 Graphical user interface ("GUI") component 20 operates to present a graphical image corresponding to a virtual environment on a computer's display; for example, a cathode ray tube (CRT) or the like. A graphics component 21 of GUI 20 is, in the presently disclosed embodiment of the invention, a virtual reality modeling language ("VRML") browser with a Component Object Model- ("COM")-based interface. VRML browsers are well-known to those of ordinary skill in the art; in the presently preferred embodiment of the invention, graphics component 21 is the Cosmo^® Player 2.1 Universal VRML 2.0 Client, commercially available from Platinum Technology, Inc., Oakbrook Terrace, Illinois. Other VRML browsers believed to be suitable for the purposes of practicing the invention are known and commercially available. As those of ordinary skill in the art will appreciate, being COM-based allows graphics component 21 to run inside an application rather than, as is more common, inside a web browser. The text or dialog component 22 of GUI 20 may "pop up" within GUI 20 at different times during a Holodesk telepresence session and ask user to take action. For example, text component 22 may be displayed within GUI 20 with a request that the user identify (for example, by typing on the computer keyboard (not shown)) a computer file stored on a user's hard disk drive to be brought into the virtual environment and made accessible to other participants in a telepresence session. In one embodiment, text component 22 is

Active-X control component of Internet Explorer™ commercially available from Microsoft

Corporation, Redmond, Washington. The text component has standard user-interface text input and output fields, as would be familiar to those of ordinary skill in the art. List component 24 of GUI 20 essentially comprises a menu or list of various operations that may be performed in connection with a telepresence session. In the presently disclosed embodiment, such operations include, by way of example, initiating a private textual exchange ("whispering") to another participant during a telepresence session. It is believed that the development of a list component 24 would be a matter of routine software development for those of ordinary skill in the art. Each GUI 20, accompanied by audio communication between participants of a telepresence session, constitutes the primary means by which a virtual environment is presented to users of system 10. As noted above, each GUI 20 is displayed on a computer display screen (monitor) associated with one of the computers 12 in system 10. The virtual environment is "shared" among each user, in the sense that the virtual environment is dynamic in its appearance, and in the sense that changes to the virtual environment are manifested in real-time in the GUI of each user of system 10. (For the purposes of the present disclosure, the term "real-time" shall be construed to take into account the transmission delays that may be introduced as electronic information is communicated between computers 12 via links 14 in system 10. Thus, for example, a change to the virtual environment brought about through the actions of the user of computer 12-1 will manifest itself in the virtual environment displayed at computer 12-2 at a time perhaps slightly later than the change was made at computer 12-1, due to the propagation delay necessary for the information reflecting the change to be transmitted across link 14 between computer 12-1 and computer 12-2, and for such information to be processed by computer 12-2 and the GUI 20 associated with computer 12-2 to be updated. The terms "simultaneously" and "essentially simultaneously" should be similarly construed for the purposes of the present disclosure to recognize such propagation and processing delays.) In the presently disclosed embodiment of the invention, the shared virtual environment is a two-dimensional rendering of a virtual three-dimensional space. The general appearance of the virtual environment is defined a priori, and is sometimes referred to as a "world." For example, in one embodiment, a virtual environment is provided that uses the metaphor of a business office space, with virtual desks, tables, chairs, doors, windows, and the like. It is contemplated that the users of system 10 may select from among a plurality of different "worlds" upon initiation of a telepresence session using system 10. The range of possible "worlds" is essentially limitless; some worlds may be more or less realistic, such as the office metaphor world mentioned above, while others may be more fanciful or surreal. In any case, in accordance with one aspect of the invention, the virtual environment is presented in a manner such that each user of system 10 is able to "navigate" through the virtual world represented by an avatar. Where multiple users are "present" in the virtual environment (i.e., participating in a telepresence session), each user can "see" and interact with the avatars representing the other participants in the session. The "world" defining a virtual environment consists of a plurality of "objects" defined in the VRML language. Each object in a world has certain initial attributes, including, by way of example, a predefined appearance (i.e., how that object is visually represented in GUI 20), behavior (i.e., how it may move within the virtual environment), and properties (i.e., how users may interact with an object in the world). As used herein, the term "world" essentially refers to the aggregation of VRML objects which initially define the appearance of a virtual environment as it is displayed in the GUI 20 of each user of system 10. In accordance with one aspect of the invention, the

"state" of the virtual environment, i.e., the aggregation of objects in the world and their attributes at any given time, is dynamic, being subject to changes as a result of actions that individuals interacting in the virtual environment might take during a telepresence session. Additionally, users may introduce new objects into the world, thereby altering the overall state of the virtual environment. For example, a user may cause a computer file stored on his or her local hard disk drive to be introduced into the world. The file could be assigned its own representation in the virtual environment much like an "avatar," (although the term "avatar" is more commonly applied to the representation of human beings in a virtual environment), and could be made accessible to other users who might, through their respective avatars, "pick up" the representation of the file, copy the file to their hard drives, and so on. In view of the dynamic nature of the state of the virtual environment during a telepresence session, it is necessary that information about the state of the environment be exchanged among all participants in the session on a real-time basis, so that each user can interact with others in a shared virtual environment that appears essentially the same to all users at all times. As will be described in further detail below, it is the MUTech module 28 associated with each user's Holodesk application that is primarily responsible for coordinating the exchange of virtual environment state information to support this shared virtual environment aspect of the system 10 in accordance with the presently disclosed embodiment of the invention.

LISTING MODULE 26Error! Bookmark not defined. Listing module 26 is a software module responsible for communicating with listing service 18. In particular, listing module 26 is responsible for keeping entries in listing service 18 up-to-date. For example, listing module 26 must inform listing service 20 when a user has an active Internet connection (i.e., when the user's IP address may change on a dynamic basis). Listing module 26 is also responsible for enabling a user to create one or more profiles to be listed in listing service 20, and to modify those profiles. Listing module 26 may communicate with listing service 18 over a TCP/IP socket, and may communicate using Microsoft ASP web-forms. The primary function of listing module 26 is to "register" a user with the listing service 18, i.e., to inform listing service 18 about a user's status (e.g., IP address, port number, user profile). The listing service information may be accessed by others wishing to locate and conduct a telepresence session with other users who are registered with listing service 18.

MUTECH MODULE 20

MUTech (short for "Multi-User Technology") module 28 is a software module which operates to support avatar-based interaction within a virtual environment established in accordance with the presently disclosed embodiment. MUTech modules 28 among all participating computers 12 in a system 10 collectively function to, among other things, coordinate the position and state of objects, including avatars, present in the virtual environment; coordinate the exchange of information between objects in a virtual environment; and identify and integrate at run-time, interaction capabilities implemented outside of VRML. In accordance with one aspect of the invention, one or more MUTech modules 28 D but not necessarily more than one MUTech module 28 D is designated at any time during a telepresence session on system 10 as the "host" MUTech module(s) 28 for a given telepresence session. Upon initiation of a telepresence session, some decision-making or arbitration scheme (the exact nature of which being of little relevance to the present disclosure) is preferably undertaken to determine, among all intended participants of the session, which participant's computer 12 will be designated as the MUTech host 28 for the session in question. In the presently disclosed embodiment of the invention, MUTech module 28 includes components that are to some extent derived from technology developed or being developed by the "Living Worlds" Working Group of the VRML Consortium, Inc. The VRML Consortium, Inc. (http://www.yrml.org; contact@vrml.org) is a nonprofit corporation with the stated mission of fostering and promoting VRML as an open standard for 3D multimedia and shared virtual worlds on the Internet. The present invention also adopts technology developed or being developed by the Humanoid Animation Working Group of the VRML Consortium, Inc.. Living Worlds is essentially a specification for method of multi-user communication in VRML, i.e., a proposal for extension or recommended practice of use for VRML. Living Worlds is public domain technology. MUTech module 28 is engaged in communicating the state of objects and environment to a MUTech module 28 acting as the host for a given telepresence session; the MUTech host 28H, in turn, functions to communicate the state information to all computers 12 in the telepresence system 10. (For the purposes of the present disclosure, the term "MUTech host 28H" shall be used to designate the one (or more) MUTech modules designated and functioning as the host for a given telepresence session, it being understood that all other MUTech modules 28 associated with other computers 12 in a system 10 having certain operational and functional responsibilities involving interaction with the MUTech host 28H for a particular telepresence session.) Similarly, MUTech modules 28 in accordance with the presently disclosed embodiment of the invention also include components derived to some degree from the work done by the Humanoid Animation Working Group (http://ece.uwaterloo.ca/~h-anim), which has developed a specification or definition of interchangeable humanoids and animations (e.g., avatars) in standard VRML 2.0. Animations include limb movements and the like, and possibly (in future versions), facial expressions, and lip synchronization with sound. The Humanoid Animation Working Group's specification is referred to herein as "H- Anim." The above-referenced Living Worlds specification is incorporated into the present disclosure as Appendix 1. Further, the specification of a "core subset" of the overall Living Worlds specification is incorporated herein as Appendix 2. The above-referenced H-Anim specification is incorporated herein as Appendix 3. It is assumed that persons of ordinary skill in the art have a working familiarity with and understanding of the specifications of Appendices 1, 2, and 3. In accordance with another aspect of the invention, communication of state information between computers 12 in system 10 is accomplished by socket TCP protocol using binary encoded packets. The packets may be compressed by MUTech modules 28 using any one of a number of known and commercially available compression technologies.

LINK MODULE 30 and CONNECTION SERVICE 40 Link module 30 is a software module used to communicate with the connection services 40 associated with other computers 12 in system 10. Together, link module 30 and connection service 40 operate to perform connection arbitration between computers 12 in system 10. It is the responsibility of connection service 40 of each computer 12 to verify other users by consulting with listing service 18 . Connection service 40 for each computer 12 communicates with listing service 18 via a TCP/IP socket, as well as via a web interface. Connection service 40 notifies listing service 18 of its current IP address and port number. Such notification is important to the extent that it supports dynamic IP addresses of users, i.e., users who access the Internet via an Internet service provider, whereby the user's IP address is likely to be different each time the user logs onto the Internet via his or her ISP.

ACHAT MODULE 32 AChat module 32 is a software component responsible for establishing point-to-point connections for two-way audio streaming between computers 12 in system 10. During a given telepresence session, each user can establish any number of connections, up to limit of user's bandwidth. Various audio streaming technologies are known and commercially- available, and it is believed that the details of implementing AChat module 32 for supporting audio streaming across links 14 between computers 12 in system 10 would be a matter of routine development to those of ordinary skill in the art. SERVICE MANAGER 34 Service manager 34 is a software component of the Holodesk application that is designed to provide extra services to the VRML content. Among other functions, service manager 34 provides a bridge between VRML content (description of world, what objects are in it, and so on) and the user's local operating system. This enables, for example, a user to introduce a locally-stored file as a new object in the virtual environment, such that other participants can access that file.

HTTP MODULE 38 For each computer 12 in system 10, an http component 38 is provided for establishing hypertext transfer protocol ("http") connections with other computers 12 in the system. Such connections are established periodically during a telepresence session when files or other data must be exchanged between two computers 12. For example, one participant may introduce a local file as a shared object into the virtual environment. Within the virtual environment, such a file would be identified with a URL. When another participant wishes to access the file, that participant would not obtain it from MUTech host 28H, but instead by establishing an http connection with the computer from which the file was introduced into the virtual environment. When a participant shares a file in Holodesk, that file becomes available for download via the built-in HTTP server module. In common use, a participant is likely to be attached to a publicly available network such as the Internet. Other users of this larger network may be able to download files without the participant's intention to provide access to those files. To reduce this risk, each file shared during a telepresence session is assigned a text-encoded 64-bit semi-random identifier only valid for the session in progress. Addresses created using these identifiers are provided to the VRML content instead of actual file paths on the user's computer. The HTTP server will also not service any directories or provide lists of files in any directory. The HTTP server will not service file requests other than those explicitly shared from the user's computer. It is believed that implementation of the http module 38 for the purposes of practicing the present invention would be a matter of routine development to those of ordinary skill in the art; hence the details of such implementation shall not be further described herein.

INITIATION OF A TELEPRESENCE SESSIONError! Bookmark not defined. Having described the various functional components of the Holodesk application in accordance with the presently disclosed embodiment of the invention, the invention may now be better appreciated with reference to the following description of the sequence of events which occur during initiation of a telepresence session. To become a participant in a telepresence session, each user must first establish a connection 14 with listing service module 18 . In this regard, it is to be noted that, the role of listing service module 18 in the presently disclosed embodiment of the invention is not directly comparable to that of a central server in conventional multi-user systems; this distinction will become more apparent in view of the following description. Once a connection 14 has been established to listing service module 18, a user of one of the computers 12 sends a request to log in identifying the user. The request may also have a preassigned password unique to the user associated therewith. Listing service module 18 verifies the identity of the user and sends a response message indicating whether the user can connect to the telepresence session. As previously noted, at some point, one or more of the users wishing to participate in the telepresence session must be designated as "host," i.e., the user(s) on whose computer(s) 12 a MUTech module 28 will take responsibility for the duties of MUTech host 28H as herein described. Notably, however, the MUTech host 28H is executed on the computer 12 of one or more of the participants in the telepresence session, and not on any sort of central server. This represents a principal distinction between the system 10 of the presently disclosed embodiment of the invention and conventional "central" servers in multi-user systems. After being granted permission to participate in the telepresence session, a user next must specify the avatar with which it desires to be represented in the virtual environment, along with a specification of the avatar's capabilities. This information is communicated to the MUTech host 28H for the telepresence session; MUTech host 28H is responsible for disseminating the information to all participants. In one embodiment, avatars are VRML objects. To identify its avatar to the participants in the telepresence session, a user merely specifies the location where the avatar is stored. Notably, this location may be essentially anywhere; users' avatars need not even be stored on any of the computers 12 participating in the session, but may be stored at a central location functioning essentially as a "library" of avatars. The "location" of a user's avatar may be identified to the MUTech host 28H in the form of an IP address or URL and a filename. This address/filename information is disseminated by the MUTech host 28H to all participants in the session; each participant's MUTech module 28 is then responsible for retrieving the avatar VRML objects for other participants from the specified locations. It will be appreciated by those of ordinary skill in the art that one benefit of specifying users' avatars in the manner described above is that it is not incumbent upon the MUTech host 28H to disseminate avatar VRML objects themselves, but merely information about their respective locations. This significantly reduces the computational overhead borne by the computer 12 executing the MUTech host 28H. This is in contrast to prior multi-user systems in which all information about the virtual environment is stored at a central server location and transmitted separately to each participant. Such an arrangement is known to place a large computational burden on the central server, and such central servers are typically required to be large, high-performance, and expensive computers, such as high-end servers and the like with hardware and networking capability beyond that of typical personal computers. Assuming that the users desiring to participate in a telepresence session have successfully completed the above-described login procedure, and that a MUTech host 28H has been instantiated on one of the user's computers 12, there follows an initialization procedure. To commence the initialization procedure, MUTech host 28H sends a message to all participants identifying the VRML "world" defining the appearance of the virtual environment. As with the identification of each user's avatar, the identification of the world is done in the form of an IP address or URL and a filename. The VRML world may reside essentially anywhere. It is incumbent upon each user to retrieve the identified world from the specified location. Again, this arrangement minimizes the computational burden on the host computer, which needs merely to transmit a small amount of address/filename information to the other users, rather than the larger VRML files themselves. It is contemplated that individual computers 12 in system 10 may have one or more VRML worlds stored locally on their hard drives. Thus, in some instances, the world identified by the MUTech host 28H in initiating a given telepresence session may already be present on some of the computers 12. In such instances, it would not be necessary for those computers 12 to retrieve the world from an external source. The file information provided by the MUTech host 28H includes a simple name, for example, "Garden" which may match a name of a world already installed on the client user's machine. Also included in the file information is a small amount of identification data, which the MUTech client 28 uses to identify if the world on the client user's machine with the same simple name is actually the same binary file as the one referred to by the address provided by the MUTech host 28H. If both the simple name and the binary data match, the data is loaded from the client user's machine locally without using the network address. Next, MUTech host 28H will begin sending packets of information to each of the participating computers 12 identifying other participants in the session. These packets of information would be essentially the same as those that each user initially sends to the

MUTech host 28H, comprising URL and/or IP addresses corresponding to the avatars by which each of the other users wishes to be represented in the virtual environment. Each user's MUTech module 28 would then be responsible for retrieving the identified avatars corresponding to the other users. Next, MUTech host 28H will broadcast information to all users identifying all

"shared objects" in the virtual environment. Shared objects are those VRML objects in the virtual environment with which each user's avatar may interact. Examples of shared objects will be described hereinbelow in further detail.

MUTECH MESSAGING Because the telepresence system 10 in accordance with the presently disclosed embodiment of the invention relies upon establishing, as necessary, communications links directly between individual computers 12 via the Internet or similar means, the packets of incremental, updated environment state information sent between MUTech modules 28 on individual computers 12 and MUTech host 28H are relatively small. In addition, there is a limited, predefined set of message types that are communicated between computers 12 and MUTech host 28H. In one embodiment, MUTech messages sent between MUTech modules 28 on computers 12 and MUTech host 28H are encoded, binary packets and include an opcode (operation code) identifying the type of message, along with one or more arguments. The following Tables 1 and 2 describe the messages that MUTech modules 28 can send to MUTech host 28H, and the types of messages that the MUTech modules 28 receive, respectively, in one embodiment of the invention: Table 1 : Messages that the MUTech Module sends to the MUTech Host

In the foregoing Tables 1 and 2, "int" refers to a data type "integer," e.g., a 16- or 32-bit binary number, and "String" refers to a data type "String," i.e., a series of eight-bit ASCII or UTF8 alphanumeric character codes. It is believed that those of ordinary skill in the art will be familiar with such designations. Thus, for example, an argument designated above as <int usernumber> refers to an integer identifying a participant's unique user number assigned to that participant upon he or she joining the telepresence session, while the argument <String URL> refers to an alphanumeric URL designator. As is apparent from Tables 1 and 2 above, there are a limited number of predetermined message types that are passed between MUTech host 28H and MUTech modules 28.

STEADY-STATE OPERATION Once the foregoing initialization procedure has been completed, the telepresence system enters into a steady-state mode of operation. In this mode, each participant, through his or her avatar, can navigate (i.e., "move") within the virtual environment, and can interact with other participant's avatars and with any shared objects defined within the virtual environment. It is contemplated that it will commonly be the case that not all areas of a particular virtual environment, and not all shared objects in the virtual environment, will be "visible" to a given user's avatar at one time. As noted above, each user's avatar's movement and interaction with objects and avatars in the virtual environment causes the "state" of the virtual environment to change on an ongoing, dynamic basis. In order for each participant to experience the same shared virtual environment, information about changes to the state of the environment must be communicated to each user. This is the responsibility of the MUTech host 28H in cooperation with each user's MUTech module 28. Thus, steady-state operation of system 10 involves the sending and receiving of MUTech messages between MUTech modules 28 and MUTech host 28H. MUTech modules send messages to MUTech host 28H reporting any changes to the state of the environment caused by the user with which they are associated, as well as messages requesting information about the environment and shared objects that are encountered in the environment. MUTech host 28H, on the other hand, broadcasts messages it has received from MUTech modules 28 reporting changes to the environment state, and responds to requests from MUTech modules 28 for information about shared objects. In particular, each time a user performs an action which changes the state of the virtual environment, that user's MUTech module 28 sends a packet of information to the MUTech host 28H describing the changes made. For example, if one user causes his avatar to move from one location to another within the virtual environment, information describing the user's new location is conveyed to the MUTech host, which then broadcasts the information to all users. In this way, the movement of the user is perceived by all participants. In accordance with a notable aspect of the present invention, sharing of environment state information among all participants in a telepresence session as described herein essentially amounts to distributing control of the state of the virtual environment among the multiple users. At the same time, however, such distributed control is not accomplished by having a central server periodically providing a complete updated state definition to multiple users, as is believed to be the case with most existing multiple-user virtual reality systems. Likewise, this system is distinguished from known multiple-user game systems, in which each participant broadcasts updated state information to all others. Instead, updating the state of the virtual environment is accomplished incrementally, by all users, upon being advised of changes to the environment. MUTech host 28H does not function in the role that a conventional central server does in known multiple-user systems; instead, MUTech host 28H functions merely as a broadcast point through which incremental packets of state information are disseminated from one user to all others.

TEXT CHAT (TCHAT) MODULE In one embodiment of the invention, system 10 is provided with a text chat feature by which participants may communicate with one another via typewritten text appearing in text component 22 of GUI 20. It is believed that implementation of this feature, which would involve transmission of text information across links 14 between two or more users, would be a matter of routine development to a person of ordinary skill in the art. Two different text chat modes are contemplated. In a broadcast chat mode, text entered by one participant is displayed in text component 22 of all other participants. One way to accomplish this mode is to have the sending computer 12 communicate the text information to MUTech host 28H, which would then relay the text to all participants. In another text chat mode, referred to as a "whisper" mode, one participant can communicate text to a specified participant, rather than to all participants. Again, this feature would involve the specified participant sending the text to MUTech host 28H with a specification of the user for which it was intended. MUTech host 28H would, in turn, forward the text to the intended recipient. EXAMPLES OF SHARED OBJECTS

A variety of different types of shared objects that may be defined in a virtual environment are contemplated. Referring now to Figures 2 through 4, there are shown line- drawing depictions of the appearance of GUI 20 during a telepresence session conducted on system 10. (It is to be understood that Figures 2 through 4 are line drawings in order to conform with the requirements for patent drawings, while in actual implementation, the screens appearing in GUI 20 during a telepresence session would preferably be much more life-like, having colors, textures, shading, and the like, as would be familiar to those of ordinary skill in the art.) The virtual environment shown in Figure 2 is a scene from a VRML "world" that adopts a business office metaphor, as discussed hereinabove. The scene depicted in Figure 2 is what would be displayed on the computer monitor of a participant in a telepresence session in accordance with the presently disclosed embodiment of the invention. As previously described with reference to Figure 1, GUI 20 comprises a graphics component 21, a text component 22, and a list component 24. As seen from Figure 2, graphics component 21 displays a realistic depiction of a conference room having a table 150, chairs 152, windows, 154, and so on. A collection of navigation buttons designated generally with reference numeral 156 in Figure 2 enables a user to navigate his or her avatar within the virtual environment, a concept that will be familiar to those of ordinary skill in the art. In one embodiment of the invention, it is contemplated that, by way of example, table 150 may be one of the shared objects within the virtual environment with which telepresence session participants may jointly interact. As described above, the VRML data defining the appearance and attributes of table 150 within the virtual environment is initially stored at some specified location (which may be essentially anywhere). The location of this data (i.e., a network address such as a IP address or URL) is maintained by the active MUTech hosts(s) 28H for the session. When participants "enter" the room depicted in Figure 2 (it being understood that as used herein, reference to such concepts as a user "entering a room" are intended to refer to the user guiding his or her avatar into the room), that user's MUTech module 28 is responsible for obtaining the data corresponding to the overall appearance of the room and the appearance and attributes of all shared objects in the room. To obtain this data, each user's MUTech module 28 issues queries to MUTech host 28H. MUTech host 28H responds by providing the addresses of relevant data, including appearance and object description data. When queried by the user's MUTech module, MUTech host 28H identifies the objects in the virtual environment. The host is again queried for current object state data. In the instant example, assuming table 150 is a shared object, each user whose avatar is in proximity to table 150 will be provided the same information about the appearance and attributes of table 150. One of the attributes of table 150 may be, for instance, that it is capable of having other shared objects placed thereon, such that those objects may be viewed and/or otherwise interacted with by other users. For example, one user, through operation of its service manager 34, may retrieve a computer file from his or her local storage and introduce a representation of that file into the virtual environment. To accomplish this, the user's MUTech module 28 would exchange messages with active MUTech host 28H for the purpose of informing MUTech host 28H that a new object has been introduced having a particular representation (i.e., VRML description), particular attributes, and a particular location within the virtual environment. MUTech host 28H will then broadcast a message to all participants (or at least those participants in proximity to table 15) informing each user of the introduction of the new object, and identifying for each user the locations from which the relevant data defining the object may be retrieved. Each user's MUTech module 28 is then responsible for retrieving the data. Each user's graphic component 21 would then be updated to display the newly-introduced shared object. The object may be represented on table 150, for example, as an icon. Suppose, in the instant example, that another user wishes to obtain a copy of the file whose representation appears on table 150. Such a user could maneuver his or her avatar appropriately near the file's representation and issue a command (for example, by typing a command in text component or clicking on the file's representation) to retrieve a copy. In response to such a command, the user's MUTech module 28 would obtain (if it had not already done so) information from the active MUTech host 28H regarding the location (i.e., address) of the requested file. In this example, the address might be a URL identifying the

HTTP server 38 of the user who originally introduced the file as a shared object into the virtual environment. Having obtained this address, the user seeking a copy of the file would establish a connection 14 to the specified address and request a copy of the file. This request would be handled by HTTP server 38 of the first user, and the requested data would be sent via connection 14 to the requesting user. Notably, in the current example, during the entire process of a first user introducing the shared object into the environment, and a second user requesting and obtaining a copy of the file, the only information passed to and from MUTech host 28H may be address information identifying the locations of relevant data, and not necessarily the relevant data itself. This is in contrast to more conventional configurations, in which the data such as the shared file and the VRML data defining its appearance and attributes in the virtual environment must be maintained by a high-performance central server whose responsibility it would be to retrieve and store shared files from all participants and transmit this potentially large amount of data to each user. Other environments of the present invention using share objects, for example, include education which would remove the limitation of size and provide a cursive digitized set of human e events. Text books can take on a vicarious set of experiences for the user, e.g. rather than viewing the human anatomy in 2-dimensional pictorial format, the student can journey through all parts of the body in 3-dimension. Virtual mentors can be provided such as great philosophers, mathematicians and the like. Figure 3 depicts another scene from the virtual environment of the presently disclosed example. In this example, a shared object in this case having a defined appearance of a fountain and designated with reference numeral 158 in Figure 3 is given attributes like table 150 described above with reference to Figure 2 whereby it functions as a central repository for users to introduce computer files into the virtual environment. In Figure 3, files introduced by users into the virtual environment are represented by familiar file icons 160 (such as those used to represent files within the Microsoft^® Windows^® operating system). The process of introducing files into the environment would be the same as previously described with reference to Figure 2. The introducing user advises MUTech host 28H of the creation of the shared object and of the locations (e.g., IP addresses and/or URLs) of the object's representation and the file represented by the object.

The MUTech host 28H provides this information to the appropriate users. Other users wishing to obtain a copy of the file represented by a particular icon 160 would do so by establishing a connection 14 to the specified location and download the data. Turning to Figure 4, there is shown still another scene from the exemplary embodiment of the invention. At this location in the virtual environment, a shared object 162 having the appearance of a projection screen is defined. As a shared object, projection screen 162 may be used to enable multiple users present in the room (e.g., avatar 164 is shown in Figure 4) to view images displayed thereon, as follows: First, the MUTech module 28 of a user wishing to display images on screen 162 would exchange messages with the active MUTech server 28 identifying the location(s) of images to be "displayed." MUTech server 28 then relays this information to the MUTech modules 28 of the appropriate users. Those MUTech modules 28 are then responsible for accessing the information at the specified location. In one example, a user may wish to display a Microsoft^® PowerPoint^® or other type of graphics presentation on screen 162 to be viewable by other users whose avatars are in proximity to screen 162 in the virtual world. The presenting user's MUTech module 28 will exchange messages with active MUTech server 28 advising of the location of the graphics data to be displayed. This data may reside on the computer 12 of the presenting user, or can reside essentially anywhere else to which a connection can be established. All participants wishing to view the images on screen 162 will establish a connection to the specified location and retrieve the data. Again, it is to be noted that the graphics data itself is not necessarily transferred from its source to individual users via the active MUTech server 28 (although it may be); only the location(s) of the data incremental updated information about the state of the virtual environment, including identification of the shared object and its attributes may be transferred in this way. Again, it is to be understood that all participants in the telepresence session whose avatars are present in the area of the virtual environment depicted in Figure 4 are able to "see" the image(s) displayed on projection screen 162, in the sense that assuming each user's avatar is "looking" in the proper direction within the virtual environment, projection screen 162 will appear in graphics component 21 for those users. DISTRIBUTION AND REDUNDANCY As thus far described, it will be apparent to those of ordinary skill in the art that systems implemented such as system 10 in accordance with the functional and operational aspects of the present invention have generally distributed and potentially redundant characteristics. In one aspect of the invention, it is contemplated that responsibility for the functions and operations of MUTech host 28H as herein described may be distributed among more than one of the computers 12 comprising a system 10. In another aspect, it is contemplated that the functions and operations of MUTech host 28H may be performed redundantly and/or simultaneously by more than one computer 12 in a given system 10. It is also to be noted that responsibility for the functions and operations performed by listing service 18, while represented as being performed by separate computer in Figure 1, may in fact be allocated or distributed among multiple computers 12 which are at the same time participating in a given telepresence session, and/or among one or more computers which may be dedicated to the MUTech host functions.

Furthermore, it is contemplated that the raw data necessary to establish a particular virtual environment (including but not limited to the data corresponding to the VRML "world" defining the general appearance of the virtual environment, the VRML data defining the various shared objects present in the virtual environment, the data defining each user's avatar in the virtual environment, and so on) may be distributed among not only the computers 12 associated with the participants in a telepresence session, but also among any number of other computers at essentially any locations. For example, and as previously mentioned, the VRML "world" data selected to be used for a particular telepresence session may be stored essentially anywhere accessible by a network (e.g., Internet) connection. Each participant in a given telepresence session merely consults the MUTech hosts(s) 28H nominated or otherwise selected to be "active" for the telepresence session to obtain the network address where the "world" data is located, and then accesses that location (and not the location of the active MUTech host 28H itself) to obtain the "world" data. In one embodiment, it is contemplated that any number of "telepresence service providers" may exist where libraries of "world" data, avatars, shared object data, and the like may be stored. If data from such a service provider was selected to be used by a plurality of users initiating a telepresence session, that service provider would become a part of system 10 only in the sense that that service provider would be periodically accessed by the participants in the session to obtain the necessary data. The service provider would not function in the capacity of controlling the telepresence session, as in conventional central- server multi-user systems, but merely as a repository or database of data to be shared among participants in the telepresence system. Because of this feature of the present invention, the term "node" shall be used herein as a more general designation of a computer that is or is capable of becoming a part of a telepresence session (e.g., a MUTech node), either to perform the function of computers 12 in the embodiment described with reference to Figure 1, or to perform the function of a database to be accessed by such computers 12 (e.g., a passivated or support node), or both, as the case may be.

INTERCONNECTION Having described an illustrative embodiment 10 of the invention comprising a plurality of computers nodes interconnected in such a way as to enable a plurality of users to experience and participate in a shared virtual environment, a further aspect of the present invention, relating to the interconnectedness of nodes during a telepresence system, can be more fully appreciated. As used herein, "interconnectedness" is meant to include the interpretation that one or more individual systems 10 interconnected with one another essentially themselves comprise a larger telepresence system 10. That is, a telepresence system as contemplated by the inventors may comprise an interconnection and interaction of entire systems 10, in the sense that each of computers 12 in the embodiment of Figure 1 may, in some embodiments in fact comprise a separate (but by definition not necessarily or entirely unconnected) telepresence system 10. Stated differently, a system 10 such as is depicted in the illustrative embodiment of Figure 1 can itself comprise a node in a larger telepresence system of interconnected telepresence systems 10. Referring to Figure 5, there is shown one example of an interconnected system 100 of telepresence nodes, designated in Figure 5 with reference numerals 102, in accordance with one embodiment of the invention. In Figure 5, the character of each node 102 may be different. Some nodes 102 may be individual computers 12 executing the Holodesk application (e.g., nodes executing on one or more MUTech modules). Other nodes may comprise one or more computers not executing the Holodesk application but providing databases accessible to other computers in the system (e.g., passivated nodes or support nodes. Notably, and as is apparent from Figure 5, some nodes 102 in system 100 may comprise an entire telepresence system 10 comprising a plurality of interconnected computers 12 executing the Holodesk™ application. In this sense, the term "node 102" shall be interpreted herein to include both individual computers 12 and entire telepresence systems 10. The term "node 102" shall also be interpreted to include passivated nodes or support nodes, that is, computers or networks of computers functioning as a database of data accessed by other computers 12, telepresence systems 10, and/or nodes 102 to provide VRML "world" data, avatar data, shared object data, and the like, to participants in a telepresence session. The links between nodes 102 in system 100 are designated with reference numeral 14, just as the links between computers 12 in the simple embodiment of Figure 1 were. This emphasizes the essentially recursive or fractal-like nature of systems in accordance with the general principles of the present invention; there is no conceptual distinction between a connection 14 established between two computers 12 and a connection 14 established between two telepresence systems 10, or between two nodes 102, or between two complete telepresence systems 100, and so on. Connections 14 are established sporadically and on an as-needed basis, whenever information is to be communicated between two nodes 102 in a system. Connections 14 are established, for example, to provide to or request from active MUTech host 28H incremental updated information about the current state of the shared virtual environment. Connections 14 are also established for the purposes of obtaining data (such as VRML data and the like) from specified locations. Connections 14 are also established in support of the real-time audio Achat function discussed above. By interpreting the terms "node 102" and "connection 14" as set forth above, it will be apparent to those of ordinary skill in the art that systems 100 in accordance with the presently disclosed embodiment of the invention have an essentially recursive- or fractallike nature. Indeed, it is contemplated, for example, that one or more of computers 12 in system 10 shown in Figure 5 may comprise a separate telepresence system 10 comprising a network of computers 12. Likewise, system 100 in Figure 5 may itself be nothing more than a node 102 of a larger telepresence system; such larger telepresence system, in turn, may itself be a node of an even larger telepresence system, and so on ad infinitum. Further, it is to again be noted that a "node" 102 may reside on a single computer 12, or may be distributed across multiple computers 12 interconnected by links 14, and that multiple nodes 102 may reside on a single computer. To summarize, telepresence systems such as system 10 in Figure 1 or system 100 in

Figure 5 are characterized as follows:

Each system (10 or 100) is a collection of nodes 102, where a "node 102" may itself comprise, without limitation, a computer 12, a system 10 of interconnected computers 12, a system 100 of interconnected systems 10, and so on. Each node 102 has a connection, direct or indirect, most commonly over the Internet, to at least one active MUTech host 28H residing on some computer 12. Each node 102 can establish a connection to one or more databases containing data defining the appearance and content of a shared virtual environment. The overall collection of data defining a given virtual environment may (and is likely to) be distributed over a plurality of remote locations, i.e., the data may be stored in a plurality of separate remote nodes 102 in the overall system. Connections between individual nodes (be they computers 12, systems 10 or systems 100) may be established and/or activated in response to actions or events occurring within the virtual environment. Each active Holodesk application associated with a particular telepresence session is capable of searching for, transferring, receiving or otherwise acting upon data stored in any database in any node associated with the overall telepresence system. Users participating in a telepresence session are registered with a listing service 18, such that even if a user has a dynamic network (e.g., IP) address, other users shall be capable of maintaining contact with that user. The function of the listing service 18 may be performed by a single computer 12 in one of the nodes 102 of the overall system, or may be distributed among multiple computers 12, or may be performed collectively by a system 10 or even a system 100. Similarly, the functions of the active MUTech host 28H may at any given time be performed by a single computer 12, or by multiple computers 12, or collectively by a system 10 or by a system 100. The allocation of responsibility for performing the functions of the active MUTech host 28H may be dynamic, in the sense that the duties of the active MUTech host 28H may be transferred from computer 12 to computer 12, from system 10 to system 10, and/or from system 100 to system 100.

LISTING NODES AND META-LISTING NODES In the highly simplified embodiment of Figure 1, listing service 18 is depicted as residing in one location. It has already been noted herein that, as is the case for any functional node, the function of listing service 18 to maintain on a dynamic basis the necessary identifying information about users, including their addresses (e.g., IP addresses and/or URLs), names, locations from which avatar data may be retrieved, and so on) D can be performed centrally by any computer or may be distributed among a plurality of interconnected computers. In any case, the listing service function can be performed by any computer whether or not that computer is also executing the Holodesk application; that is, the listing service function may be performed by a MUTech node, a passivated node, or a support node. To reflect this concept generally, it may be expressed as follows: it is contemplated the listing service function can be performed by any node 102 in a telepresence system, where, as noted above, a node 102 can itself comprise a computer 12, or a telepresence system 10 comprised of a plurality of computers 122, or a telepresence system 100 comprised of a plurality of telepresence systems 10, and so on. In addition, one node 102 in a system 100 may perform a so-called meta-listing service function. By this it is meant that a node may maintain a list of a plurality of separate listing services 18. Those of ordinary skill in the art will appreciate that this concept of a meta-listing service is very similar to Internet World Wide Web ("WWW") sites that contain nothing but hyperlinks to other WWW sites. The concept of a meta-listing may be better appreciated with reference to the illustrative embodiment of Figure 6, which, like the embodiment of Figure 5, comprises a system 100' comprising a plurality of nodes 102 interconnected by connections 14, wherein each node 102 may be an individual computer 12, a telepresence system 10, and so on. Assuming that each of the computers in each of the nodes collectively comprises a telepresence system in accordance with the present embodiment of the invention, at least one MUTech host 28H and at least one listing service 18 will be provided. As noted above, the MUTech host function 28H may be distributed among one or more computers in one or more nodes 102 in system 100', as may the functions of listing service 18. Also included in the embodiment of Figure 6 is a meta-listing node ("MLN") 110.

Although MLN 110 is depicted in Figure 6 as a separate, apparently "standalone" component, it is to be understood that like the MUTech host 28H and listing service 20, the functions performed by MLN 110 as will be described herein may be performed by any one or more computers, including any one or more computers of which system 110' is comprised. In the disclosed embodiment, MLN 110 functions to maintain a listing of listing services like listing service 18. That is, MLN provides essentially a database of separate telepresence systems such as telepresence system 10 from Figure 1 or telepresence system 100 from Figure 5. By maintaining this list, MLN 110 gives a telepresence system such as telepresence system 100 the ability to allow migration of individual users, alone or in groups, from one subset of nodes to another, to define and undefine subsets of nodes by division or integration of other subgroups, on a dynamic basis, all without requiring any overriding or central control hierarchy. With reference to Figure 6, system 100' can be thought of as comprising essentially two sub-groups of nodes 102, a first being designated within dashed line 112-1 and a second being designated within dashed line 112-2. For the purposes of the present disclosure, subgroups of nodes 102 such as 112-1 and 112-2 in Figure 6 will be referred to generally as "local telepresence networks 112," with the "-x" suffix convention being used to distinguish one specific local telepresence network from another. At any given time, a particular local telepresence network 112 is characterized by the definition and state of its virtual environment. As has been described above, participants may join or leave a given telepresence session at will. To join, a participant needs only to identify the desired active MUTech host 28H for the session by means of a look-up in listing service 20, and then, through the participant's MUTech module 28, advising the active MUTech host 28H of its desire to join. The MUTech host 28H will notify all other participants of the "newcomer's" arrival, which essentially amounts to an incremental change in the state of the virtual environment. Other participants thereafter must retrieve information about the newcomer for example, the newcomer's avatar data and other attributes. Thus, adding a new participant to a telepresence session amounts to little more than the establishment of new links 14 between that newcomer, the MUTech host 28H, and other participants, a process that is coordinated through operation of MUTech server. In much the same way, it is contemplated to be possible to join two telepresence systems together; this is illustrated in Figure 6. MLN 110 in Figure 6 maintains a list of multiple listing services 18, including the listing services 18 associated with the local telepresence networks 112-1 and 112-2 in Figure 6. Thus, it is possible for local networks 112-1 and 112-2 to become aware of each other's existence, and for a link 14 to be established, either directly or indirectly, between one or more nodes 102 in the respective local networks 112-1 and 112-2. This may be accomplished even if the two (or more) local networks have completely different virtual environments. As a simple example: MUTech host 28H associated with local telepresence network 112-1 define a new shared object within the virtual environment of local network 112-1. This new shared object is defined to take on the appearance of a door in the virtual environment of local network 112-1. Further, the new shared object is defined to have attributes such that when activated by a participant in the telepresence environment of local network 112-1, it appears to the participant that he or she enters the virtual environment of local network 112-2; that is, the participant is directed to the active MUTech server in local network 112-2 to obtain virtual environment state information. A corresponding, reciprocal "door" can be defined within the virtual environment of local network 112-2, to enable participants in the virtual environment within local network 112-2 to similarly migrate to the virtual environment within local network 112-1. The migration of participants or nodes from the virtual environment of one local telepresence network to the virtual environment of another may or may not involve a connection made via MLN 110. It is contemplated that maintaining a connection between nodes in two local telepresence networks 112 via MLN 110 may be advantageous for the purposes of maintaining and ultimately reestablishing an association of a particular node 102 with its original local network 112, although it is also contemplated that a direct connection between a node 102 in one local network and the active MUTech host 28H in another local network, without further involvement by MLN, may also offer advantages In addition to migrating between separate virtual environments established within separate local telepresence networks 112, it is also possible to create separate subsidiary local telepresence networks, having separate virtual environments, within an individual local telepresence network. This is illustrated in Figure 6, wherein a subgroup of nodes 102 within local telepresence network 112-2 are shown within a dashed line designated with reference numeral 116. Participants associated with a sub-group of nodes 102 within a given local telepresence network, such as sub-group 114 of local network 112-2, can, without the intervention of any centralized server or controller, perceive a "space" within the virtual environment different from that perceived by participants associated with the remaining nodes 102 in the local network 112-2. Because sub-group 114 otherwise retains its association with the other nodes 102 in local network 112-2, including its links 14 with such other nodes, however, participants associated with nodes in sub-group 114 would perceive that others in the local network 112-2 are within the same virtual environment, but "seeing" different things at a different location. For example, all users within local network 112-2 would retain their abilities to AChat with one another even while sub-group 114 constitutes a subsidiary local network of local network 112-2.

REPEATER NODES Because of the highly distributed character of the system architecture as disclosed herein, It is, of course, desirable for each link 14 in a system 10 or 100 to have the highest possible bandwidth at all times, since slower links 14 can adversely affect "performance" of the system as a whole (e.g., the rate at which each user's virtual environment is updated upon notification of changes to the state made by other users, the length of time necessary for a shared file to be transmitted from one user to another, and so on). Those of ordinary skill in the art will appreciate, however, that as a practical matter, the throughput or bandwidth may vary from link 14 to link 14 in a system 10 or 100 in accordance with the presently disclosed embodiments. Moreover, the throughput or bandwidth of each individual link 14 in a system 10 or 100 may vary dynamically over time, depending, for example, upon the levels of traffic present on the communications provider(s) on which the links 14 are established. Some links 14 in a system 10 or 100 may be inherently faster "Tl" connections, for example, while others may have bandwidth limitations arising from the use of a relatively slower modem. To address the issue of link performance, it is contemplated that in one embodiment of the invention, one or more nodes 102 performing a message and data repeater function may be provided in a system 10 or system 100. It is contemplated that a node 102 providing such a repeater function (hereinafter referred to as a "repeater node 102") will establish multiple connections 14 with other nodes 102 such that it accepts input (MUTech messages, data, and the like) from one or more nodes 102 and output the received messages and data to one or more nodes 102. By providing one or more repeater nodes, the system as a whole can benefit from the higher bandwidth of some links 14 present in the system. Such a repeater node is one example of a passivated node (as that term is described above) that is capable of taking in and sending out data, including but not necessarily limited to environment state information, but not adapted to alter the state of the environment. As noted above, it is contemplated that a system 10 or 100 in accordance with the presently disclosed embodiment of the invention may include one or more than one repeater node. Further, it is contemplated that decisions as to which nodes 102, if any, in a given system are to perform the function of a repeater node may be made on a dynamic basis. For example, one or more nodes 102 in a system may periodically or on an ongoing basis undertake system performance monitoring to identify links 14 that are exhibiting poor throughput, and, conversely, links 14 that are exhibiting good throughput, and thereafter make decisions regarding the allocation of repeater duties with the goal of optimizing overall system performance. In one embodiment, for example, one or more nodes 102 may participate in monitoring the performance of various links 14 in the system by exchanging and relaying time-encoded test messages to assess the throughput performance. Various off- the-shelf network performance monitoring software packages that would be suitable for the purposes of this aspect of the invention are known and commercially available.

Additionally, in some cases network service providers (e.g., Internet service providers) will provide real-time feedback to users regarding throughput performance. Notably, the architectural characteristics of systems in accordance with the principles of the present invention are such that the optimization of overall system performance can be reduced to the classic computer science maximum flow problem. The maximum flow problem has been the subject of substantial study over the years, and those of ordinary skill in the art will appreciate how the fruits of such study may be applied to the task of optimizing a system such as systems 10 or 100 as disclosed herein. Specifically, it is contemplated that the optimization of a system in accordance with the principles of the present invention can be accomplished by dynamically configuring the number and location of repeater nodes within a system.

"ECOMMERCE" The present invention as described herein is believed to have characteristics of significant benefit to the area of many types of informational, promotional and/or transactional interaction conducted via computer-based platforms, including, e.g., Internet- based retail sales transactions. One expression of this concept is presently referred to in common parlance as "ecommerce," a concept generally known as encompassing the promotion, advertisement and/or exchange of data, information, goods or services, whether or not for value, conducted electronically. The concept of "ecommerce" at the time of this disclosure is widely understood and is commonly most closely associated with transactions involving communication conducted electronically via the Internet. It is specifically contemplated, however, that interconnections between computers, or networks of computers, not entirely or even at all involving the Internet would be suitable for the purposes of practicing the present invention. Those of ordinary skill in the art should therefore understand the term "ecommerce" as used herein, to encompass any type of promotion, advertisement and/or exchange of data, information, goods or services, whether or not for value, that is conducted electronically. (As used herein, the term "electronically" and related expressions shall be interpreted so as to recognize the fact that so-called "electronic" communication can involve information being transmitted in other forms, e.g., optically, via infrared transmission, via radio frequency transmission, microwave transmission, or the like.) Figure 7 represents one example of how systems in accordance with the present invention may be applied to the field of ecommerce. In Figure 7, there is shown a system 100" comprising a plurality of local telepresence networks 112. (While only three local networks 112-3, 112-4, and 112-5 are shown in Figure 7, it is to be understood that there is no theoretical limit on the number of local telepresence networks 112 that might be incorporated into a telepresence system such as is shown in Figure 7). As in previous embodiments, each local telepresence network 112 comprises a plurality of nodes 102 connected by links 14, where, to reiterate, each node 102 may be a single computer 12 associated with a single telepresence session participant, or a separate local telepresence network 112 or telepresence system 10, or a separate telepresence system 100 of interconnected telepresence systems 10. Additionally, as noted above, each node 102 in system 100", and each computer 12 associated with each node 102, may or may not be executing the Holodesk application, and/or may be simply a database of information accessible by other computers 12 in the system 100". At least one node 102 in system 100' ' has associated therewith a computer 12 functioning as the active MUTech host 28H for the overall system 100". In the exemplary embodiment of Figure 7, this node is a member of local telepresence network 112-4, and is designated with reference numerals 102, 12 and 28H to emphasize that this node 102 is a computer 12 functioning as the MUTech host 28H for system 100". In addition, at least one node 102 in system 100" has associated therewith a computer 12 functioning as a listing service 18. In the embodiment of Figure 7, this node is a member of local telepresence network 112-3, and is designated with reference numerals 102, 12, and 20 to emphasize that this node 102 is a computer 12 functioning as the listing service 18 for the system 100". Further, system 100" has associated therewith a meta- listing node 110, also a member of local telepresence network 112-3 in the present embodiment. This node is designated with reference numerals 102 and 114 to emphasize that this node 102 is performing the function of MLN 110 for the system 100". In the example of Figure 7, it is assumed that the virtual environment defined for the telepresence session adopts a retail shopping mall metaphor; that is, the virtual environment or "world" VRML data accessed by each participant's computer 12 as directed by MUTech host 28H is defined to present the image of a shopping mall on each participant's graphic component 21. Further, it is assumed that among the meta-list of listing servers maintained by MLN 110 in system 100" is the address of local network 112-5. In this example, it is assumed that local network 112-5 comprises a plurality of telepresence nodes 102 at which virtual environment data is stored which, when accessed enables participants to enter a virtual retail store in the virtual environment. As one example, it may be assumed that local telepresence network 112-5 is maintained by the nationally chain of retail outlets, and that each node 102 in local network 112-5 corresponds to a different category of goods offered for sale by that chain. One or more participants in the telepresence session being conducted on system 100' ' may wish to "shop" for particular goods. From meta-listing node 110, these participants can identify the address of the node 102 in local network 112-5 corresponding to those goods, and can, by establishing a subsidiary local network within whatever local network 112 they are in, can access the virtual environment data in the node 102 corresponding to those goods. This is analogous to a situation where a group of people enter a store, and where a sub-group of those people elect to break away from the others and go to a different department within that store. All of the people in the group are in the same store, but some are at different locations within that store. It is contemplated that the virtual environment data maintained at the nodes 102 in local network 112-5 can include shared objects corresponding to the goods offered for sale. Interacting with these shared objects would enable a participant to, for example, view a graphical image of the goods in question, view textual information regarding prices, sizes, availability, and so on. The virtual environment data may further include shared objects akin to virtual "cash registers" whereby a participant could purchase goods electronically (for example by using a credit card). On the other hand, from the retailer's perspective, the virtual environment databases it maintains in local network 112-5 may be tied into or be a part of the retailer's actual catalog sales, inventory system and/or accounting systems, such that when a purchase is made in the virtual environment, the purchased goods are automatically sent to the purchaser, and the transaction reflected in the retailer's inventory and accounting systems. The system discussed above with reference to Figure 7 is but one example of how telepresence systems in accordance with the presently disclosed embodiment of the invention may find advantageous application to the emerging concept of on-line transactions and ecommerce. It is believed that those of ordinary skill in the art having the benefit of the present disclosure will readily appreciate that other metaphors and configurations may be adopted for accomplishing a very wide variety of on-line transactions. To be sure, the technology of the present invention is in no sense limited to retail sales, but may find application in many types of transactional and/or interactive situations.

Electronic commerce using the present invention, therefore, will be initially based upon creating "full service" web sites that mimic the "brick-and-mortar" shopping experience. The present invention enables online merchants to render a virtual reality representation of a store and support interactive customer service online. The invention supports contextual selling, by enabling the creation of worlds that provide supporting context for the sale of a product. For example, a sporting goods retailer might create as their virtual reality world containing a football arena, baseball park, and hockey rink. Virtual reality simulations of players using selected products, demonstrating their features and capabilities within this world inform customers and encourage product sales. The invention makes more efficient use of display space, by allowing dynamic reallocation of display space. A commercial electronic commerce may reconfigure itself to better display products to meet the expectations of an individual customer, a new level of customer personalization. The invention supports integrated online transactions, as objects within the world can be tied to database constructs in the merchants inventory and pricing databases. Transactions in the virtual world mimic exactly transactions at an electronic cash register or customer service terminal. The interactive nature of telepresence enables direct, online customer service and support.

Telepresence fundamentally changes online commerce by lowering the distinction between brick-and-mortar establishments and online commerce sites. The virtual reality world can exactly model the features and aesthetics of its real counterpart, including interactive customer service. More impressively, however, virtual reality enables the creation of fantastic commercial environments. It will provide a different way of shopping from that conducted over the internet. This new experience as set out above is based on the shared object.

Catalogue sales is an important component of e-commerce over the networks of the present invention. Online customer service and customer relations management. Various catalogue items can be downloaded into the personal computer and reviewed off-line and sales and inquires completed online. By using a combination of stored data at user's node the bandwidth to conduct business is minimized.

Online Education is another feature of the present invention as mentioned with respect to share objects. The present invention provides new learning environments that complement current University and online learning models. The education community has been concentrating on the new possibilities afforded by distance education, as enabled by the Internet. The invention combines the power of network communications with an immersive learning environment to create a compelling new platform for online education. Imagine an anatomy class in which the students and the lecturer are aspirated into the human lung, cross over into the blood stream, and explore the human heart. For example, a chemistry class can be provided in which the periodic table of the elements is three- dimensional; students can directly observe the shell construction of Einsteinium and other elements.

Education currently suffer from the need to compress real world three-dimensional objects and phenomena into the two dimensions of print publications. A more intuitive method of communications would be to display the material as a three dimensional model. Students could explore the subject matter, manipulate it with their own hands - tear it apart, put it together again. Three dimensionality provides students with the ability to experience phenomena that might otherwise always exists beyond their ken - play with an atom, cruise the bottom of the Marianas Trench, or stand on the moon. The animation of a three- dimensional model creates and captures an educational simulation. Students can view or participate in the simulation, according to their own wishes. The student might choose to be an oxygen molecule aspirated into the human lung, or participate in Pickett's Charge, or learn to assemble a new class of computers. The three dimensional simulation allows us to capture and store a vicarious experience, either "real" such as an historical event, or imagined such as the theoretical collision of subatomic particles. Internet telepresence immediately lends itself to allow students to experience a wide variety of subject matters.

OPERATIONAL FLOW DIAGRAMS Figures 9a through 9g are flow diagrams outlining in detail the steps taken to initiate and conduct a telepresence session on a system such as a system 100 in accordance with one embodiment of the invention. Figures 9a through 9g utilize a standard flow diagramming convention, wherein individual steps of the process being diagrammed appear in rectangular symbols such as those designated with reference numerals 300 and 302 in Figure 9a, and decision steps in which the process can proceed in two or more separate directions depending upon dynamic system and state conditions are represented in diamond-shaped symbols, such as that designated with reference numeral 310 in Figure 9a. In particular: Figure 9a is a flow diagram consisting of elements designated with reference numerals in the range from 300 to 366 inclusive, and illustrates the procedure followed for a user, via its connection service 40, to connect to a telepresence session. Figure 9b is a flow diagram consisting of elements designated with reference numerals in the range from 368 to 410 inclusive, and illustrates the steps taken by a user's Holodesk™ application upon connection to a telepresence session; Figure 9c is a flow diagram consisting of elements designated with reference numerals in the range from 412 to 436 inclusive, and illustrates the procedure undertaken when a telepresence session participant wishes to introduce an electronic file into the virtual environment associated with a telepresence session; Figure 9d is a flow diagram consisting of elements designated with reference numerals in the range from 438 to 460 inclusive, and illustrates the steps associated with initiation of an AChat (audio chat) connection between two participants in a telepresence session; Figure 9e is a flow diagram consisting of elements designated with reference numerals in the range from 462 to 490 inclusive, and illustrates the steps associated with initiation of a text chat connection between two participants in a telepresence session; Figure 9f is a flow diagram consisting of elements designated with reference numerals in the range from 492 to 528 inclusive, and illustrates the process of exchanging MUTech messages across connections 14 in a system 100 in accordance with the disclosed embodiment of the invention; and Figure 9g is a flow diagram consisting of elements designated with reference numerals in the range from 530 to 544 inclusive, and illustrates the steps involved in creation of user profile with listing service module 18.

NOTES ON IMPLEMENTATION DETAILS As noted above, the invention may be implemented in part by programming a computer processor. The programming may be accomplished through the use of a program storage device readable by the processor that encodes a program of instructions executable by the processor for performing the operations described above. The program storage device may take the form of, e.g., a floppy disk; a CD-ROM; a memory device (e.g., RAM, ROM, EPROM, EEPROM, etc.); and other forms of the kind well-known in the art or subsequently developed. The program of instructions may be "object code," i.e., in binary form that is executable more-or-less directly by the computer; in "source code" that requires compilation or interpretation before execution; or in some intermediate form such as partially compiled code. The program storage device may be one that is directly readable by the processor, or it may be one that is unusable by the processor er se but that provides intermediate storage of the program of instructions. The program of instructions may be read directly from the program storage device by the processor; alternatively, the program of instructions may be temporarily or permanently stored in the program storage device and transmitted from it to the processor over one or more links, e.g., over a telephone connection (such as a modem connection or an ISDN line); over a cable-modem hookup; over the Internet; via radio- or satellite transmission; etc., possibly with other program storage devices providing intermediate storage along the way. The precise forms of the program storage device and of the encoding of instructions are immaterial here. Although a specific embodiment of the present invention has been described herein in detail, this has been done only for the purposes of describing various aspects of the invention, and is not intended to be limiting with respect to the scope of the invention as defined by the following claims. It is to be understood by those of ordinary skill in the art that various substitutions, alterations and/or modifications, including but not limited to those design alternatives and variants which may have been specifically noted herein, may be made to the disclosed embodiment without departing from the spirit and scope of the invention as defined in the claims. It is contemplated, for example, that, although the present invention has been described herein in the context of a shared virtual reality or "telepresence" system, in a broader sense the present invention has applications beyond virtual reality. Those of ordinary skill in the art having the benefit of the present disclosure will appreciate that the flexible, distributed, and dynamic architecture disclosed herein may be applied to other types of persistent, distributed environments where virtual reality is not necessarily the visualization medium. For example, the system may be implemented using video streams as the visualization medium. Thus, while presently preferred embodiments of the invention have been shown and described, the invention may be otherwise embodied within the scope of the appended claims.

Claims

WHAT IS CLAIMED IS:

1. A system architecture for a distributed, persistent, shared environment with dynamically configurable communication protocol, comprising i. n connectable nodes, where N > 2, ii. at least one of said nodes having stored pose and iii. at least two of said nodes being interconnected.

2. The system architecture set forth in Claim 1 wherein at least one of said interconnected nodes is a MUTech node.

3. The system architecture set forth in Claim 2 wherein said pose is stored dynamically in at least one interconnected MUTech node.

4. The system architecture set forth in Claim 1, 2 or 3 including at least one support nodeconnectable to at least one interconnected MUTech node.

5. The system architecture set forth in Claim 1, 2 or 3 including at least one passivated node connectable to at least one interconnected MUTech node or support node.

6. The system architecture set forth in Claim 4 wherein said at least one support node is a listing node for providing node addresses for node connection.

7. The system architecture set forth in Claim 6 wherein said support node comprise a meta node having at least a plurality of listing node addresses for connecting said listing nodes.

8. The system architecture set forth in Claim 1, 2, 3, 6 or 7 including a network having a plurality of nodes in which one of said nodes is an educational medium and one of said nodes is a student.

9 The system architecture set forth in Claim 1, 2, 3, 6 or 7 including a network having a plurality of nodes in which one of said nodes is a business and one of said nodes is an entity or person having a relationship or potential relationship with said business.

10. The system architecture set forth in Claim 9 wherein said business comprises a plurality of downloadable items and wherein said entity or person includes resident software on said node to access said items.

11. A distributed system having a persistent shared environment with a dynamically reconfigureable communication protocol, comprising:

(a) at least one computer having n connectable MUTech modules, where n >2, one of said computers having a stored initial pose or having a connection to a support module with an http module; and

(b) connection links between at least 2 MUTech modules.

12. The distributed system set forth in Claim 11 wherein pose is stored in at least one of said connected MUTech Modules.

13. The distributed system set forth in Claim 11 including at least one support module.

14. The distributed system set forth in Claim 11 or 13 including at least one passivated module.

15. The distributed system set forth in Claim 11 where is said pose is dynamically stored on at least one module selected from the group of connected modules consisting of MUTech Modules, support modules having at least an http module and passivated modules.

16 A computer-based system for presenting a shared virtual environment to at least two users, comprising: (a) a data storage device storing data defining an initial state of said virtual environment, said initial state being subject to change during operation of said system; (b) a plurality of computers, wherein each computer is capable of establishing a connection to at least a subset of others of said plurality of computers and to said data storage device, and wherein at least a subset of said computers are responsive to said data defining said initial state to present a graphical image of said virtual environment on a display; and (c) wherein one of said plurality of computers comprises a multiuser server adapted to (i) receive a state message from another of said plurality of computers identifying a location at which data reflecting a change to said state of said virtual environment is stored; and (ii) to relay said state message to others of said plurality of computers.

17. A system as set forth in Claim 16, wherein said data storage device is directly coupled to one of said plurality of computers.

18. A system as set forth in Claim 16, wherein said at least a subset of said computers are responsive to receipt of said state messages relayed by said multi-user server to access said data reflecting a change to said state at said identified location, and wherein said at least a subset of said computers are responsive to said data reflecting a change to correspondingly change said graphical image of said virtual environment.

19. A system as set forth in Claim 18, wherein said identified location is remote from said multi-user server.

20. A system as set forth in Claim 16, wherein said connection is made via the Internet.

21. A method of doing business electronically comprising electronically connecting a customer service call center to a shared virtual reality world.

22. A method a set forth in Claim 21 including the steps of connecting at least one customer to said customer service call center.

23. A method as set forth in Claim 21 or 22 including the steps of representing a customer as an avatar.

24. A method as set forth in Claim 21 wherein said connecting includes a distributed system.