Method and apparatus for extracting data objects and locating them in virtual space6785667Abstract The invention provides method and apparatus for viewing information. In one embodiment, the system of the invention enables the user to view displayed information in a way that is comparable to a selected physical paradigm. Example physical paradigms include, but are not limited to, financial, educational, governmental, sports, media, retail, travel, geographic, real estate, medical, physiological, mechanical, surveillance, agricultural, industrial, infrastructure, scientific and other like paradigms. By presenting information to the user in a way that more closely mimics physical paradigms, the system provides an intuitive mechanism for the user to view, search through and interact with displayed information in an unrestricted manner. In another embodiment, the appearance is a graphical representation of one or more data objects, related to other data objects through hierarchical relationships defined by one or more templates. As the user adjusts the viewing perspective, the appearance changes in a seemingly continuous, non-discrete manner. Claims What is claimed is: Description FIELD OF THE INVENTION
TABLE 1
Physical Paradigm Macro Micro
Manufacturing Supply and Demand Unit Performance
Ecology Global Biology Local Chemistry
Information Systems Network Capacity Device Analysis
Economics Many Markets Many or One Product(s)
Organizational Charts Company-Wide Personal/Unit Inspection
diagram
Computer Programs Functional Diagrams/ Function Code
Flows
Electronics Broad Functions Detailed Circuitry
Retail Shopping Broad Categories Individual Products
As mentioned above, one example conceptual layout of a template employs a field metaphor. According to a field template, the system 100 organizes the leaf nodes representing data objects on the field, without covering them with labels. Such an embodiment enables the user to pan over the laid-out data objects and to zoom visually into data objects of interest. Such a template can be considered analogous to spreading out all of the pages of a document on a table, instead of stacking the pages into a pile. Such a template enables the user to easily preview and print large data sets, such as Web sites. Another example template 105 relates to a card catalog paradigm. In this embodiment, the extractor module 102 extracts information describing elements of a data source, such as author, date, brief description, number of pages, title, size, key words, images and/or logos. The system 100 then organizes the extracted information much like a library card catalog system, thus enabling the user to browse visually many data sources, such as Web sites, for their essential information. Another example template relates to organizing a graphical representation of data objects for use in a kiosk. In one embodiment, a kiosk is a remote computer in a public place with which the user can communicate by using, for example, a wireless link, between the user's handheld computer and the kiosk. In another embodiment, the kiosk is a computing device wherein the user communicates directly with the kiosk, for example, by way of a keypad or a touch screen to navigate through and interact with the displayed data objects. According to one embodiment, the system 100 arranges graphical representations of the data objects ergonomically in an arched pattern to fit a person's hand. In one preferred embodiment, the system 100 displays five or less options per hierarchical abstraction level so that the user can swiftly touch choices using one hand on the touch screen to navigate through the available data objects. Illustrative kiosk displays are depicted in FIG. 19 and discussed in further detail with respect to that Figure. In one embodiment, in response to the user navigating to the leaf nodes, the system 100 may display more than five graphical representations of data objects to the user. By way of example, in response to the user navigating to the men's pants node 406e of FIG. 4, the system 100 may display to the user more than five selections of men's pants. Another example template 105 relates to a geographical physical paradigm. The geographic appearance template 105 is similar to the retail template illustrated in FIG. 5. The system 100 extracts data objects to be the leaf nodes and conceptually spreads them out on a base plane or field. Next, the system 100 hierarchically groups, labels and generates graphic appearances for the leaf nodes until ultimately the system 100 provides a home display. However, with a geographical template, data nodes have spatial relevance. Hotels, restaurants, and stadiums all have a place in the world and therefore have a specific i, j, k coordinate location in the virtual space 110 associated with their actual position in the physical world. Hierarchical abstraction levels or groupings include, for example, World, Continent, Country, City, Street, Buildings, and IntraBuilding. Another example template is a Body Zoom.TM. template. This is a template to store, display, retrieve all the physiological, anatomic, medical, aesthetic and information about each and all body parts as related to medical, biotechnological, chemical, biologic, psychologic conditions. For example, the system 100 displays a human body, and the user chooses to zoom into a specific body part. The system 100 changes the viewing perspective to display information of/about and related to the body part chosen by the user. In one embodiment, the body template is a zoomable map of a clothing store where data objects corresponding to clothing products are located in virtual space in accordance with the body part they are intended for. Shoes are in the foot region, hats are in the head region, shirts in the torso region, and gloves in the hand region. A similar methodology can be used for supermarkets, using supermarket aisles as the template. Another example is a desktop financial template. Using this template, the system 100 displays a picture of a desk with a calendar, phone, stock ticker, a newspaper and the like. Each item displayed generates a function when the user navigates to that item. For example, when the user navigates to the phone, the system 100 performs calling functions (e.g., dialing a user entered number), and when the user navigates to the newspaper, the system 100 zooms the viewing perspective through the news, allowing the user to navigate in an unrestricted fashion. FIG. 6 depicts a block diagram 601 illustrating the use of multiple templates in combination. In this illustration, four templates 603, 605, 607 and 609 represent four different transportation services; car rentals 603, buses 605, taxies 607, and subways 609. Illustratively, the bus 605 and subway 609 templates contain map and schedule information, and fares are based on the number of stops between which a rider travels. The taxi template 607 has fare information based on mileage and can contain map information for calculating mileage and/or fares. The car rental template 603 contains model/size information for various vehicles available for rent, and fares are based on time/duration of rental. The hierarchical layout for each template 603, 605, 607, and 609 is organized in accord with the invention to provide an intuitive virtual experience to the user navigating the information. As depicted in FIG. 6, the templates 603, 605, 607, and 609 can themselves be hierarchically organized (i.e. a top-level hierarchical relationship) through the use of the super templates 611, 613 and 615. More specifically, in one example, the system 100 organizes the templates 603, 605, 607, and 609 using a menu super template 611. The menu super template 611 relates the templates 603, 605, 607, and 609 on a common hierarchical level, showing that all four transportation services 603, 605, 607, and 609 are available. Illustratively, the super template 611 organizes the templates 603, 605, 607, and 609 alphabetically. In another example, the system 100 organizes the templates 603, 605, 607, and 609 using a map super template 613. The map super template 613 relates to a geographical location physical paradigm. The map super template 613 relates the four templates 603, 605, 607, and 609 in accordance with the geographical relationship between the represented transportation services (i.e. car rental, bus, taxi and subway). The map super template 613 can be used, for example, when the user wants to know which transportation services are available at a particular geographical location. For example, the user may be trying to decide into which airport to fly in a certain state 614, and wants to locate information about transportation services available at the different airports within the state. In a further example, the system 100 organizes the templates 603, 605, 607 and 609 using a street super template 615. The street super template 615 relates to a street layout physical paradigm. The street super template 615 spatially relates the templates 603, 605, 607 and 609 to each other in terms of their street location. The super template 615 can be used, for example, when the user has a street address and wants to know which transportation services are available nearby. In a further embodiment, the user can begin with the map super template 613 to find a general location and then pan and zoom to the street level using the street super template 615. As skilled artisans will appreciate, the system 100 may also employ any number of templates 105 in combination. By way of example, with regard to the kiosk of FIG. 19, in one embodiment, the system 100 may first employ the ergonomic display discussed above, but then at some point switch to employing a display corresponding to a geographical template. Illustratively, such may be the case when a kiosk user is navigating to hotel accommodations. The system 100 may employ a geographic appearance template to display hotel locations to the user. Additionally, the system 100 may employ irregular display shapes for advanced visual recognition. For example, the graphic appearance associated with each data node can be defined to have a unique shape such as star, pentagon, square, triangle, or the like. With a conventional desktop metaphor, display area availability is at a premium, thus rendering it impractical to employ irregular shapes. However, the panning and zooming features of the system 100 render display space essentially infinite. Thus, the display of virtually any client can be configured in favor of readability and an overall user experience. An aspect of the illustrative viewing system 100 provides the user with the sense of real-time control of the displayed data objects. Rather than a stop and go display/interactive experience, the system 100 provides an information flow, a revealing and folding away of information, as the user requires information. Accordingly, the state of the system 100 is a function of time. The user adjusts the virtual viewing position over time to go from one data object to the next. Therefore, a command for the virtual viewing position of the user, represented in FIGS. 1 and 2 by the position of the camera 116, is of the form f(x, y, z), where (x, y, z)=f(t). The appearance of data objects that the system 100 displays to the user is a function of time as well as position. According to the illustrative embodiment, as the user changes viewing perspective, the system 100 changes the appearance of a graphical representation of the data objects in a smooth, continuous, physics-based motion. According to one embodiment, all motion between viewing perspective positions, whether panning (e.g., translational motion along the i, j and k axes of FIGS. 1 and 2) or zooming (e.g., increasing detail of closest data objects), is performed smoothly. Preferably, the system 100 avoids generating discrete movements between locations. This helps ensure that the user experiences smooth, organic transitions of data object graphical appearances and maintains context of the relationship between proximal data objects in the virtual space, and between the displayed data objects and a particular physical paradigm being mimicked by the system 100. In one embodiment, the system 100 applies a sine transformation to determine the appropriate display. For example, the virtual motion of the user can be described as linear change from t=0 to t=1. The system 100 applies a sine transform function to the discrete change, for example t_smooth=sin(t*pi/2) where t changes from 0 to 1. The discrete change is changed to a smoother, rounded transition. One way to model the motion for adjustments of the user viewing perspective is to analogize the user to a driver of a car. The car and driver have mass, so that any changes in motion are continuous, as the laws of physics dictate. The car can be accelerated with a gas pedal or decelerated with brakes. Shock absorbers keep the ride smooth. In terms of this model, the user controls 107 of system 100 are analogously equipped with these parts of the car, such as a virtual mass, virtual shocks, virtual pedals and a virtual steering wheel. The user's actions can be analogized to the driving of the car. When the user is actuating a control, such as key, joystick, touch-screen button, voice command or mouse button, this is analogous to actuating the car's accelerator. When the user deactuates the control and/or actuates an alternative control, this is analogous to releasing the accelerator and/or actuating the car's brakes. Thus, the illustrative system 100 models adjusting of the user viewing perspective as movement of the camera 116. The system assigns a mass, a position, a velocity and an acceleration to the camera 116. In another embodiment, the system 100 models the user's virtual position logarithmically, that is, for every virtual step the user takes closer to a data object (e.g., zooms in), the system 100 displays to the user a power more detail of that data object. Similarly, for every virtual step the user takes farther away from a data object (e.g., zooms out), the system 100 displays to the user a power less detail for that data object. For example, the following illustrative code shows how exemplary exp() and log() functions are used:
// returns the conversion factor of world width to screen width
static double world_screen_cfactor(double camera_z)
{
return exp(camera_z);
}
static double world_width_and_screen_width_to_camera_z(double world_dx, int
screen_dx)
{
if(world_dx==0) return 1;
return log(((double)screen_dx)/world_dx);
}
FIG. 7 provides a simplified flow diagram 600 depicting operation of the system 100 when determining how much detail of a particular data object to render for the user. This decision process can be performed by a client, such as the client 114 depicted in FIG. 11 or by the stylizer module 104. As the decision block 602 illustrates, the system 100 determines the virtual velocity of the change in the user's virtual position, and employs the virtual velocity as a factor in determining how much detail to render for the data objects. The system 100 also considers the display area available on the client to render the appearance of the data objects (e.g., screen size of client 114). As indicated in steps 602 and 604, in response to determining that the virtual velocity is above one or more threshold levels, the system 100 renders successively less detail. Similarly, as also indicated by steps 602 and 604, the system 100 also renders less detail as the available display area at the client 114 decreases. Alternatively, as indicated by steps 602 and 606, as the virtual velocity decreases and/or as the available display area at the client 114 increases, the system 100 renders more detail. Thus, the system 100 makes efficient use of display area and avoids wasting time rendering unnecessary details for fast-moving data objects that appear to pass by the user quickly. FIG. 8 illustrates various potential appearances 702a-702c for a textual data object 702, along with various potential appearances 704a-704c for an image data object 704. The axis 706 indicates that as virtual velocity increases and/or as client display area decreases, the system 100 decreases the amount of detail in the appearance. At the "full" end of the axis 706, the virtual velocity is the slowest and/or the client display area is the largest, and thus, the system 100 renders the textual data object 702 and the image data object 704 with relatively more detail, shown at 702a and 704a. At the "box outline" end of the axis 706, the velocity is the greatest and/or the client display area is the smallest, and thus the system 100 renders the appearance of the same data objects 702 and 704 with no detail 702c and 704c respectively. Instead, the system 100 renders the data objects 702 and 704 simply as boxes to represent to the user that a data object does exist at that point in the virtual space 100, even though because of velocity or display area, the user cannot see the details. In the middle of the axis 706 is the "line art" portion. In response to the virtual velocity and/or the available client display area being within particular parameters, the system 100 renders the data objects 702 and 704 as line drawings, such as that depicted at 702b and 704b respectively. In the illustrative embodiment, the system 100 transmits and stores images in two formats. The two formats are raster graphic appearances and vector graphic appearances. The trade-off between the two is that raster graphic appearances provide more detail while vector graphic appearances require less information. In one embodiment, raster graphic appearances are used to define the appearance of data objects. Raster graphic appearances define graphic appearances by the bit. Since every bit is definable, raster graphic appearances enable the system 100 to display increased detail for each data object. However, since every bit is definable, a large amount of information is needed to define data objects that are rendered in a large client display area. In another embodiment, the raster graphic appearances, which require large size data words even when compressed, are omitted and instead the system 100 employs vector graphic appearances and text, which require a smaller size data word than raster graphic appearances, to define the appearance of data objects. Vector graphic appearances define the appearance of data objects as coordinates of lines and shapes, using x, y coordinates. A rectangle can be defined with four x, y coordinates, instead of the x times y bits necessary to define the rectangle in a raster format. For example, the raster graphic appearance of the country of England, which is in gif form, highly compressed, is over three thousand bytes. However, the equivalent vector version is roughly seventy x, y points, where each x, y double is eight bytes for a total of five hundred sixty bytes. A delivery of text and vector images creates a real-time experience for users, even on a 14.4 kilobyte per second modem connection. FIG. 9 illustrates various embodiments of visual indicators employed by the system 100. In addition to displaying data objects to the user, the system 100 also displays visual indicators to provide the user an indication of the hierarchical path the user has virtually navigated through in the virtual space 110. This is sometimes referred to as a breadcrunb trail. In one embodiment, the system 100 provides a text breadcrumb bar 802. The illustrative text breadcrumb bar 802 is a line of text that concatenates each hierarchical level visited by the user. For example, referring back to FIG. 5, the graphic appearance 508a is the "home" level, the graphic appearance 506b is level 1, the graphic appearance 504a is level 2 and the graphic appearance 502 is the "leaves" level. The associated text breadcrumb trail is thus, "food.shopping.coffee&tea." This represents the selections (e.g., plates, data nodes) that the user virtually traveled through (e.g., by way of zooming and panning) to arrive at the display of products in the graphic appearance 502. According to another embodiment, the system 100 provides a text and image bread crumb bar 804. Like the text breadcrumb trail 802, the text and image breadcrumb trail 804 is a concatenation of each hierarchical level through which the user virtually travels. However, in addition to text, the trail 804 also includes thumbnail images 804a-804c to give the user a further visual indication of the contents of each hierarchical level. In another embodiment, the system 100 provides a trail of nested screens 806. Each nested screen 806a-806c corresponds to a hierarchical level navigated through by the user. In another embodiment, the system 100 provides a series of boxes 808 in a portion of the display. Each box 808a-808c represents a hierarchical level that the user has navigated through and can include, for example, mini screen shots (e.g., vector condensation), text and/or icons. In another embodiment, the user can perform an action to select a particular hierarchical level, for example click on the visual indicator of a particular hierarchical level, and the system 100 changes the viewing perspective to the virtual location of that particular hierarchical level. The system 100 effects this change by warping, as described in more detail below with FIGS. 10A and 10B, from the current virtual location to the selected virtual location. According to another feature, the system 100 enables the user to preview data objects without having to zoom to them. According to one embodiment, in response to the user moving a cursor over a region of the display, the system 100 reveals more detail about the data object(s) over which the cursor resides. By way of example, referring to the plates 204a-204c of FIG. 2, in response to the user placing the cursor in a particular location, the system 100 displays data objects on one or more plates behind the plate in current view. The term "fisheye" refers to a region, illustratively circular, in the display that acts conceptually as a magnified zoom lens. According to a fisheye feature, the system 100 expands and shows more detail of the appearance of the data objects within the fisheye region. In one embodiment, these concepts are used in combination with a breaderumb trail. For example, in response to the user locating the cursor or moving the "fisheye" on a particular hierarchical level of a breadcrumb trail the system 100 displays the contents of that particular hierarchical level. According to one embodiment, the system 100 displays such contents via a text information bar. Thus, these functions enable the user to preview a data object on a different hierarchical level, without actually having to change the viewing perspective to that level, and to make enhanced usage of the breadcrumb trails illustrated in FIG. 9. FIG. 10A provides a conceptual diagram 900 illustrating two methods by which the user can virtually navigate to any available data object, or hierarchical level. The two illustrative methods are "warping" and search terms. An exemplary use of search terms and warping is as follows. Referring also back to FIG. 5, from the home graphic appearance 508, the user can input a search term, such as "coffee" 902. In response, the system 100 automatically changes the user's virtual location (and thus, hierarchical level), and displays the graphic appearance 502, whereby the user can zoom into any of the graphic appearances of available products 502a-502h. As illustrated by the user `flight` path 904, the virtual motion of the viewing perspective is a seemingly continuous motion from a starting hierarchical level 904a at the data object graphic appearance 508 to the hierarchical level 904e of the data object graphic appearance 502 corresponding to the entered search term 902. As the user virtually travels through the intermediate hierarchical levels 904b-904d associated with the data objects 508a, 506b and 504a, respectively the system 100 also renders the data objects that are virtually and/or hierarchically proximate to the intermediate data objects 508a, 506b and 504a. This provides the user with an experience comparable of traveling through the virtual, multi-dimensional space 110 in which the data objects are located. However, very little detail is used, as the velocity of the automatic change of location of the viewing perspective is very fast. The system 100 also provides a new type of searching through an advertisement, even if the advertisement is located on a "traditional" Web page. According to one embodiment, in response to the user selecting a displayed advertisement, the system 100 virtually transports the user to a virtual space, such as the three-dimensional space 110, that contains data objects selected for the advertisement and hierarchically organized according to a template 105. Because of the nearly infinite virtual space, business entities can create advertisement spaces that contain aspect geared for all demographic appearances, and let the user browse through the data objects and gravitate to those of interest. For example, an advertisement might simply state "Enter the world of `FamousMark` merchandise." Illustratively, in response to the user selecting the advertisement, the system 100 displays a graphical representation of a multi-dimensional virtual space, having for example, conceptual plates, such as the plates 204a-204c, including graphical representations of data objects relating to various kinds of `FamousMark` merchandise, organized in spatial, hierarchical structure according to a template. Preferably, the merchandise is organized in an intuitive, hierarchical manner as illustrated in the previously discussed embodiments. According to another embodiment, the system 100 enables the user to warp from one data object to another through the use of a visual "wormhole." FIG. 10B illustrates the use of a wormhole 906 within the graphic appearance 908. In the graphic appearance 908, there are two data objects identified, the document 910 and a reduced version 912a of a document 912. In the spatial hierarchical relationship in the virtual space 110, the document 908 is located virtually far away from the document 912. However, the template 105 provides a connection (e.g., a hyperlink) between the two documents 910, 912. In response, the system 100 creates a wormhole 906. Since a wormhole exists, the system 100 displays the reduced version 912a (e.g., thumbnail) of the data object graphic appearance associated with the document 912 within document 908 to indicate to the user that the wormhole (e.g., hyperlink) exists. In response to the user selecting the data object 912a, the system 100 warps the user to the data object 912. As described above with respect to FIG. 10A, when warping, the system 100 displays to the user a continuous, virtual motion through all of the existing data objects between the document 908 and the document 912. However, the virtual path is direct and the user does not navigate, the system 100 automatically changes the user's viewing perspective. Of course, the user is always free to navigate to the document 912 manually. In a further example, the user interaction with a wormhole might proceed as follows. The user is viewing data objects organized based on a template associated with a geographical paradigm. Thus, all the data objects are displayed to the user and related in the virtual space 110 according to their actual geographical location. The user is more specifically viewing businesses in Boston. One business is a travel agent, and the travel agent has an advertisement for a business in Paris. This advertisement is associated with a wormhole to the business in Paris. In one embodiment, the wormhole is indicated as a wormhole to the user by a thumbnail of what information is at the other end of the wormhole. The user zooms into the advertisement (i.e., enters the wormhole) and the system 100 changes the viewing perspective, in a continuous manner, to the city of Paris to view information regarding the Parisian business. The user can also virtually navigate to Parisian business by panning to the east across the Atlantic. Similarly, the user can pan to the west around the world to Paris. However, the wormhole provides a quick and direct route to the user's desired virtual destination. Additionally, the wormhole 906 can be uni-directional or bi-directional. FIG. 11 is a schematic view depicting another exemplary implementation of the viewing system 100. As discussed with respect to FIG. 1, the system 100 includes an extractor module 102, a stylizer module 104, a protocolizer module 106, one ore more templates 105, user controls 107 and a display 108. FIG. 11 depicts each component 102, 104, 105, 106, 107 and 108 as individual components for illustrative clarity. However, actual physical location can vary, dependent on the software and/or hardware used to implement the system 100. In one embodiment, for example, the components 102, 104, 105 and 106 reside on a server (not shown) and components 107 and 108 reside on a client 114. In another embodiment, for example, all of the components 102, 104, 106, 107 and 108 reside on a personal computer. The extractor module 102 is in communication with a data source 112 (e.g., a database) from which the extractor module 102 extracts data objects. The extractor module 102 converts, if necessary, the data objects into a W3C standard language format (e.g., extended markup language "XML"). The extractor module 102 uses a mapping module 116 to relate each of the data objects to each of the other data objects. In one embodiment, the mapping module 116 is an internal sub-process of the extractor module 102. The extractor module 102 is also in communication with the stylizer module 104. The extractor module 102 transmits the data objects to the stylizer module 104. The stylizer module 104 converts the data objects from their W3C standard language format (e.g., XML) into a virtual space language format (e.g., ZML.TM., SZML.TM., referred to generally as ZML.TM.). The ZML.TM. format enables the user to view the data objects from an adjustable viewing perspective in the multi-dimensional, virtual space 110, instead of the two-dimensional viewing perspective of a typical Web page. The stylizer module 104 uses one or more templates 105 to aid in the conversion. The one or more templates, hereinafter referred to as the template 105 include two sub-portions, a spatial layout style portion 105a and a content style portion 105b. The spatial layout style portion 105a relates the data objects in a hierarchical fashion according a physical paradigm. The contents style portion 105b defines how the data objects are rendered to the user. The stylizer module 104 is also in communication with the protocolizer module 106. The stylizer module 104 transmits the data objects, now in ZML.TM. format, to the protocolizer module 106. The protocolizer module 106 converts the data objects to established protocols (e.g., WAP, HTML, GIF, Macromedia FLASH.TM.) to communicate with a plurality of available clients 114 (e.g., televisions; personal computers; laptop computers; wearable computers; personal digital assistants; wireless telephones; kiosks; key chain displays; watch displays; touch screens; aircraft; watercraft; and/or automotive displays) and browsers 118 (e.g., Microsoft Internet Explorer.TM., Netscape Navigator.TM.) to display the data objects from the user's viewing perspective in a navigable, multi-dimensional virtual space 110. The browser 118 is hardware and/or software for navigating, viewing and interacting with local and/or remote information. The system 100 also includes a Zoom Renderer.TM. 120. The Zoom Renderer.TM. 120 is software that renders the graphic appearances to the user. This can be, for example, a stand-alone component or a plug-in to the browser 118, if the browser 118 does not have the capability to display the ZML.TM. formatted data objects. Throughout the specification, the term "client" 114 is used to represent both the hardware and the software needed to view information although the hardware is not necessarily considered part of the system 100. The protocolizer module 106 communicates with the client 114 via a communication channel 122. Since the protocolizer module 106 converts the ZML.TM. format into an established protocol, the communication channel 122 can be any channel supporting the protocol to which the protocolizer module 106 converts the ZML.TM. format. For example, the communication channel 122 can be a LAN, WAN, intranet, Internet, wireless telephone network, wireless communication network (including third generation wireless devices), infrared radiation ("IR") communication channel, PDA cradle, cable television network, satellite television network, and the like. The data source 112, at the beginning of the process, provides the content (i.e., data objects). The content of the data source 112 can be of any type. For example, the content can take the form of a legacy database (e.g., Oracle.TM., Sybase.TM., Microsoft Excel.TM., Microsoft Access.TM.), a live information feed, a substantially real-time data source and/or an operating system file structure (e.g., MAC.TM. OS, UNIX.TM. and variations of UNIX.TM., Microsoft.TM. Windows.TM. and variations of Windows.TM.). In another embodiment, the data source 112 can be a Web server and the content can include, for example, an HTML page, a page written in Coldfusion.TM. Markup Language ("CFML"), an Active Server Page ("ASP") and/or a page written for a Macromedia FLASH.TM. player. In another embodiment, the data source 112 can also be a Web cache device. In these cases, the content typically is not stored in the ZML.TM. format (i.e., "zoom-enabled"). If the content is not stored in a ZML.TM. format, the extractor module 102 and stylizer module 104 convert the content into the ZML.TM. format. In other embodiments, the stored content is in the ZML.TM. format. In these embodiments, the system 100 transfers the content from the data source 112 to the extractor module 102, the stylizer module 104 and protocolizer module 106, without any additional processing. For example, if the content of the data source 112 is already in ZML.TM.0 format, the stylizer module 104 does not need to take any action and can transmit the content directly to the protocolizer module 106. The types of transactions processed by the data source 112 are transactions for obtaining the desired content. For example, for a legacy database, a representative input can be "get record" and the corresponding output is the requested record itself. For a file system, a representative input can be "get file(dir)" and the corresponding output is the content information of the "file/dir." For a Web site, a representative input can be "get page/part" and the corresponding output is the requested page/part itself. The system 100 transfers the output from the data source 112 to the extractor module 102. As briefly mentioned above, the extractor module 102 receives the content from the data source 112. The extractor module 102 separates the content into pieces referred to as data objects. The extractor module 102 converts the content into a hierarchical relationship between the data objects within the content. In one embodiment, the hierarchical data structure is one that follows a common language standard (e.g., XML). FIG. 12 is a schematic view 1100 depicting an illustrative conversion of a file system directory tree 1102 to a hierarchical structure 1104 of data objects by the extractor module 102. The extractor module 112 relates each of the data objects, consisting of the directories 1106a-1106d and the files 1108a-1108i to each other in the hierarchical data structure 1104, illustratively represented as a node tree. In this embodiment, relationships between the nodes 1106a-1106d and 1108a-1108i of the hierarchical data structure 1104 follow the relationships depicted in the directory tree 1102. The types of transactions processed by the extractor module 102 are transactions for converting the obtained content to data objects in a hierarchical data structure, for example, XML. For example, for a legacy database, representative inputs to the extractor module 102 can be data record numbers and mapping, if the database already contains a mapping of the data objects. A representative command can be, for example, "get_record(name).vertline.get_record(index)." The corresponding output from the extractor module 102 is an XML data structure of the data objects. For a file system, for example, a representative input can be filename(s), with representative commands such as "get_file(directory, name)" and "get_file_listing(directory)." For a Web site, a representative input can be Web pages/parts, with a representative command such as "get_Web_content(URL, start tag, end tag)." By way of further example, the extractor module 102 analyzes the content to convert the content to create an exemplary structure such as:
struct
{
void* data...
node* parent
node* child[ren]
}node;
As mentioned above, to create the exemplary structure, the illustrative extractor module 102 uses the mapping module 116. Operation of the mapping module 116 depends on the type of content received by the extractor module 102. For example, for a file structure, the mapping module 116 traverses the directory tree until it creates a node for each file (i.e., data object) and each directory (i.e., data object) and creates the appropriate parent-child relationship between the nodes (i.e., data objects). FIG. 12 illustrates how the mapping module 116 follows the directory tree 1102 when creating the hierarchical data structure 1104. For some databases, the mapping module 116 keeps the hierarchical relationships of data objects as they are in the data source. For example, a retail store might organize its contents in, for example, an Oracle.TM. database and into logical categories and sub-categories forming a hierarchical data structure that the mapping module 116 can copy. Another database might be, for example, a list of geographic points. The mapping module 116 can use geographical relationship to create the hierarchical relationship between the points. In other databases, there are no hierarchical relationships between data objects. In that case, the mapping module 116 creates them. In other databases, such as for example, a flat list of names and personal information, the hierarchical structure may be less evident. In that case, the mapping module 116, preferably, creates the relationships using some predetermined priorities (e.g., parent nodes are state of residence first, then letters of the alphabet). If the content is Web-related content, the mapping module 116 extracts the vital information by first determining the flow or order of the Web site. To zoom enable a typical Web site, the mapping module 116 extracts from the Web site a data hierarchy. HTML pages are a mix of data and formatting instructions for that data. HTML pages also include links to data, which may be on the same page or a different page. In one embodiment, the mapping module 116 "crawls" a Web site and identifies a "home" data node (for example, on the home page) and the name of the company or service. Next, the mapping module 116 identifies the primary components of the service such as, for example, a table of contents, along with the main features such as "order," "contact us," "registration," "about us," and the like. Then the mapping module 116 recursively works through the sub-sections and sub-subsections, until it reaches "leaf nodes" which are products, services, or nuggets of information (i.e., ends of the node tree branches). This process determines critical data and pathways, stripping away non-essential data and creating a hierarchical tree to bind the primary content. This stripping down creates a framework suitable for zooming, provides the user with a more meaningful focused experience, and reduces strain on the client/server connection bandwidth. FIG. 13 is a flow diagram 1200 illustrating operation of an exemplary embodiment of the extractor module 102 process for converting a Web page to a hierarchical data structure 1202. The extractor module 102 downloads (step 1204) the Web page (e.g., HTML document). From the contents between the Web page <head> </head> tags, the mapping module 116 obtains (step 1206) the title and URL information and uses this information as the home node 1202a (i.e., the root node). The extractor module 102 also obtains (step 1208) the contents between the Web page <body> </body> tags. The mapping module 116 processes (step 1210) the HTML elements (e.g., 1202b-1202g) to create the hierarchical structure 1202. For example, as shown, the first HTML element encountered is a table 1202b. The table 1202b includes a first row 1202c. The first row 1202c includes a first cell 1202d. The first cell 1202d includes a table 1202e, a link 1202f and some text 1202g. As the mapping module 116 traverses (step 1210) the HTML elements, it forms the hierarchical structure 1202. Any traversal algorithm can be used. For example, the mapping module 116 can proceed, after obtaining all of the contents 1202e-1202g of the first cell 1202d of the first row 1202c, to a second cell (not shown) of the first row 1202c. This traversal is repeated until all of the HTML elements of the Web page have been processed (step 1210) and mapped into the hierarchical structure 1202. In another embodiment, the extractor module 102 extracts each displayable element from a Web page. Each element becomes a data object. The mapping module 116, preferably, creates a hierarchical relationship between the data objects based on the value of the font size of the element. The mapping module 116 positions those data objects (e.g., HTML elements) with a larger value font size higher in the hierarchical relationship than those data objects with a smaller value font size. Additionally, the mapping module 116, preferably, uses the location of each element in the Web page as a factor in creating the hierarchical relationship. More particularly, the mapping module 116 locates those elements that are next to each other on the Web page, near each other in the hierarchical relationship. In another embodiment, to further help extract the vital information from Web sites, the mapping module 116 uses techniques such as traversing the hyperlinks, the site index, the most popular paths traveled and/or the site toolbar, and parsing the URL. FIG. 14 is a diagram 1300 illustrating two of these techniques; traversing the hyperlinks 1302 and the site index 1304. In the illustrative example, the mapping module 116 traverses the hyperlinks 1302 to help create a hierarchy. During this process, the mapping module 116 tracks how each page 1306 relates to each link 1308, and essentially maps a spider web of pages 1306 and links 1308, from which the mapping module 116 creates a hierarchy. The mapping module 116 can also use the site map 1304 and tool bars when those constructs reveal the structure of a Web site. As discussed above, the mapping module 116 can also use the size of the font of the elements of the site map 1304, along with their relative position to each other, to create a hierarchy. Additionally, the mapping module 116 can parse the URL to obtain information about the Web site. Typically, URLs are in the form http://www.name.com/dir1/dir2/file.html. The name.com field generally indicates the name of the organization and the type of the organization (.com company, .cr for Costa Rica, .edu for education and the like). The dir1 and dir2 fields provide hierarchical information. The file.html field can also reveal some information, if the file name is descriptive in nature, about the contents of the file. The mapping module 116 can also access information from Web sites that track the popularity of URL paths traveled. Such sites track which links and pages are visited most often, and weights paths based on the number of times they are traversed. The illustrative mapping module 116 uses the information obtained from such sites, alone or in combination with other relationship information gained with other techniques, to create the hierarchical relationships between extracted data objects. Once the mapping module 116, working in conjunction with the extractor module 102, creates a hierarchical data structure for the extracted data objects, the extractor module 102 processes the data objects of the content in terms of their relationship in the hierarchy. In one embodiment, a W3C standard language data structure (e.g., XML) is used to create a platform and vendor independent data warehouse, so that the rest of the system 100 can read the source content and relate the data objects of the content in virtual space 110. The types of transactions processed by the extractor module 102 are transactions relating to obtaining the hierarchical relationships between data objects. For example, for node information, a representative input can be "get node[x]" and the corresponding output is the requested node[x] itself. For data information, a representative input can be "get data" and the corresponding output is the requested data itself. For parent information, a representative input can be "get parent" and the corresponding output is the requested parent itself. For child information, a representative input can be "get child[x]" and the corresponding output is the requested child[x] itself. The extractor module 102 provides the output (i.e., the XML data structure) to the stylizer module 104. As mentioned briefly above, the stylizer module 104 converts the data objects from the extractor module 102 into ZML.TM. format. The stylizer module uses one or more templates 105, which are related to one or more physical paradigms, to aid in the conversion. The template 105 includes two sub-portions, the spatial layout style portion 105a and the contents style portion 105b. The spatial layout style portion 105a relates the data objects in a hierarchical fashion according to a physical paradigm. The contents style portion 105b defines how the data objects are rendered to the user. The stylizer module 104 can be implemented using any of a plurality of languages, including but not limited to JAVA.TM., C, XML related software, layout algorithms, GUI-based programs, and C and Macromedia FLASH.TM. compatible programs. The stylizer module 104 receives data objects from the extractor module 102 and converts the data objects from an XML format to the ZML.TM. format. The ZML.TM. format generated by the stylizer 104 is analogous to HTML, except designed for the multi-dimensional virtual space 110. The ZML.TM. format employs a mark up language that describes one or more of the data objects organized within the virtual space. Like HTML, ZML.TM. format uses tags to describe the attributes of, for example, the conceptual plates 204a-204c discussed above with respect to FIG. 2. Illustratively:
<Tags> Attributes
<plate> x, y, z, width, height, depth
<raster> URL
<vector> URL
<text> font, size, justify
<link> URL
The stylizer module 106 uses one or more templates 105 to generate ZML.TM. formatted data objects. As discussed above, templates describe how data objects from a data source are arranged in the multi-dimensional virtual space 110. Templates include a plurality of properties relating to a physical paradigm. The following list contains some exemplary properties of a template relating to a financial paradigm. Specifically, the list of properties is for a section of the template 105 for viewing a stock quote including historical data, news headlines and full text.
p=parent
j=justify
n=name
ab=all_borders
cx=children_x
bb=bottom_border
tb=top_border
lb=left_border
rb=right_border
cb=cell_border
fow=fade_out_on_width
fiw=fade_in_on_width
zt=zoom_to
bt=border_thickness
t=title
lbi=left_border_internal
rbi=right_border_internal
w=wrap
pv=plot_val
pyl=plot_y_label
pmx=plot_min_x
pxx=plot_max_x
pmy=plot_min_y
pxy=plot_max_y
Each property in the list is limited to a few letters to save memory for use in handheld devices and/or other low capacity (e.g. bandwidth, processor and/or memory limited) devices. The template properties listed above describe characteristics of the information relating to the exemplary financial paradigm and displayed to the user in the virtual space 110. Some properties describe visibility. For example, the fade properties describe when the appearance of data objects on a hierarchical plate comes within the viewing perspective (e.g., becomes visible to the user). Properties can also describe the appearance of included text. For example, some properties describe how the text appears, whether the text is wrapped, how the text is justified and/or whether the text is inverted. Properties can also describe dimensions of the data objects on the plate. For example, some properties describe whether the data object of the focus node has any borders and/or how the data objects corresponding to any children nodes are arranged. The focus node is the node corresponding to the data object virtually closest to the current viewing perspective location. Properties can further describe the appearance of the data object on the hierarchical plate. For example, some properties describe whether the hierarchical plate contains charts and/or maps and/or images. Templates also contain a plurality of placeholders for input variables. The following list includes illustrative input variables for the exemplary financial template. The input variables describe parameters, such as high price, low price, volume, history, plots and labels, news headlines, details, and the like.
$q$ (name)
$s_td$ (last)
$o_td$ (open)
$v_td$ (volume)
$h_td$ (high)
$l_td$ (low)
$c_td$ (change)
$b_td$ (bid)
$a_td$ (ask)
$pv_td$ (today's prices)
$pmx_3m$ (3 month t0)
$pxx_3m$ (3 month t1)
$h_3m$ (3 month price high)
$l_3m$ (3 month price low)
$pv_3m$ (3 month prices)
$pmx_3m$ (6 month t0)
$pxx_3m$ (6 month t1)
$h_3m$ (6 month price high)
$l_3m$ (6 month price low)
$pv_3m$ (6 month prices)
$pmx_1y$ (1 year t0)
$pxx_1y$ (1 year t1)
$h_1y$ (1 year price high)
$l_1y$ (1 year price low)
$pv_1y$ (1 year prices)
$pmx_5y$ (5 year t0)
$pxx_5y$ (5 year t1)
$h_5y$ (5 year price high)
$l_5y$ (5 year price low)
$pv_5y$ (5 year prices)
$nzh1$ (new headline 1)
$nzh2$ (new headline 2)
$nzh3$ (new headline 3)
$nzd1$ (new detail 1)
$nzd2$ (new detail 2)
$nzd3$ (new detail 3)
The SZML.TM. format is similar to ZML.TM. format, except instead of plates, the SZML.TM. format describes attributes of the appearance in terms of a screen display. The SZML.TM. format is the ZML.TM. format processed and optimized for display on a reduced sized screen. One advantage of the SZML.TM. format is that when zooming and panning, the user tends to focus on certain screen-size quantities of information, regardless of what level of hierarchical abstraction the user is viewing. In other words, when the user wants to look at something, the user wants it to be the full screen. For example, in a calendar program the user may want to concentrate on a day, a week or a year. The user wants the screen to be at the level on which the user wants to concentrate. The SZML.TM. format is vector based. Vector graphic appearances enable the appearance of data objects to be transmitted and displayed quickly and with little resources. Using the SZML.TM. format gives the user a viewing experience like they are looking at a true three dimensional ZML.TM. formatted environment, while in reality the user is navigating a graphical presentation optimized for a reduced size two-dimensional display. In the illustrative embodiment, the SZML.TM. format provides the content author ultimate and explicit control of what the appearance user sees on the screen. In the illustrative embodiment, the SZML.TM. format is based on `Screens` described by a series of vector graphic appearance elements such as rectangles, text, axes and polygons. The SZML.TM. elements are described by a mark-up language, and as such, uses tags to describe attributes. For example:
<text> title=$str$
justify=int
wrap=int
format=int
<axes> x_label=$str$
x_low=$str$
x_high=$str$
y_label=$str$
y_low=$str$
y_high=$str$
<polygon> points=$int$
values=`$int$,$int$ $int$,$int$ $int$,$int$ ...` //$int$=0...99
<void>
<rect> coordinates=`$int$,$int$ $int$,$int$ $int$,$int$ $int$,$int$ `
<*all*> name=$str$
zoom_to=$str$
coordinates=`$int$,$int$ $int$,$int$ $int$,$int$ $int$,$int$ `
The <*all*> tag is not a separate tag, but shows attributes for each element, regardless of the type of the element. Each element has a name, rectangular bounds, and potentially a `zoom to` attribute, which when clicked will transport the user to another screen. To increase the speed at which the data is transmitted, decrease the bandwidth requirements and decrease the storage capacity needed, the SZML.TM. tags can be reduced to one or two characters. The attributes listed above, for example, can be reduced as follows:
T = text t = title
j = justify
f = format
w = wrap mode
A = axes x = x_label
xl = x_low
xh = x_high
y = y_label
yl = y_low
yh = y_high
P = Polygon s = points
v = values
R = rect c = coordinates
All
n = name
z = zoom_to
c = coordinates
To further improve data transmission, SZML.TM. formatted text may be compressed before transmission and decompressed after reception. Any known compression/decompression algorithms suffice. The SZML.TM. format stores and relates data objects as screens, and stores a plurality of full screens in memory. In SZML.TM. formatted information, each screen has travel regions (e.g., click regions) which are `zoom-links` to other screens. When the user clicks on the `click region`, the viewing perspective zooms from the currently viewed screen to the "zoom_to" screen indicated in the attributes of the screen. For zooming, screens can be thought of as containing three states; small (e.g., 25% of normal display), normal (e.g., 100%) and large (e.g., 400% of normal display). When zooming in, the focus screen (the screen currently being displayed) transitions from normal to large (e.g., from 100% of normal display to 400% of normal display). Subsequently, approximately when the `click region` reaches its small state (i.e., 25% of normal display), the "zoom-to" screen is displayed and transitions from small to normal (e.g., 25% of normal display to 100% of normal display). Subsequently, approximately when the focus screen reaches its large state and prior to the clicked screen reaching its normal state, the focus screen is no longer displayed in the appearance. This gives the appearance to the user of zooming into the `click region` (which expands) through the focus screen (which also expands). Illustratively, the expansion is linear, but this need not be the case. When zooming out, the focus screen (the screen currently being displayed) transitions from normal to small (e.g., from 100% of normal display to 25% of normal display). Subsequently, the parent screen transitions from large to normal (e.g., 400% of normal display to 100% of normal display) and at some point in time, the focus screen is no longer displayed. This gives the appearance to the user of zooming out of the focus screen (which contracts) to the parent screen (which also contracts). Illustratively, the contraction is also linear. However, it also need not be the case. There is no need for a three-dimensional display engine since the graphic appearances can be displayed using a two-dimensional display engine. Yet, the user still receives a three-dimensional viewing experience. When panning, screens are modeled as a pyramidal structure based on hierarchy level and relative position of parent screens within the pyramid. For example, each screen can have a coordinate (x, y, z) location. The z coordinate corresponds to the hierarchical level of the screen. The x, y coordinates are used to indicated relative position to each other, base on where the parent screen is. For example, refer to the appearances of data objects 1804 and 1810 of FIG. 18. In the parent screen 1804, the "news" data object element is to the right of the "charts" data object element. The user changes the viewing perspective to the hierarchical level corresponding with the appearance 1810. The user can pan at this level. When panning right at this lower hierarchical level, the screen to the right is a more detailed screen, at that particular hierarchical level, of the travel region of the "news" data object element. One embodiment of the viewing system 100 addresses low bandwidth, memory and processor limited clients 114. With high bandwidth and performance, these features become somewhat less critical, but are still very useful. Described above is an illustrative embodiment of the SZML.TM. format, which is essentially the ZML.TM. format transformed and optimized for direct screen display. The SZML format defines graphic appearances as vectors. The SZML.TM. format is much faster and simpler to render than the ZML.TM. format. As mentioned above, the stylizer module 104 employs the template 105 having a spatial layout portion 105a and a contents style portion 105b. FIG. 15 is a block diagram 1400 illustrating how the spatial layout style portion 105a and the contents style portion 105b of the template 105 operate to enable the stylizer module 104 to convert an XML source content data structure extracted from a data source 1404 into ZML.TM. formatted data objects. The spatial layout style portion 105a arranges a plurality of data records 1406a-1406e in the multi-dimensional, virtual space 110 independent of the details 1405 in each of the records 1406a-1406e. For example, if the source content 1404 is a list of a doctor's patients, the spatial layout style portion 105a arranges the records 1406a-1406e, relative to each other, in the virtual space 110 based on the person's name or some other identifying characteristic. The spatial layout style portion 105a generally does not deal with how the data 1405 is arranged within each record 1406a-1406e. As previously discussed, the nature of the arrangement (e.g., mapping) is variable, and relates to a particular physical paradigm. This mapping, in one embodiment, translates to a function wherein the three-dimensional coordinates of the data objects are a function of the one-dimensional textual list of the data objects and the template 105. After the spatial layout style portion 105a assigns the records 1406a-1406e to locations in the virtual space 110, the contents style portion 105b determines how to render each record detail 1405 individually. A shoe store, a Web search engine, and a hotel travel site, for example, typically would all display their individual products and/or services and thus, record details 1405, differently. The contents style portion 105b creates the user-friendly style, and arranges the data 1405 within each record 1406a-1406e. Referring back to the patient example, the contents style portion 105b arranges the patient's information within a region 1416 (e.g., a plate), placing the title A1 on top, the identification number B1 of the patient over to the left, charts in the middle and other information D1 in the bottom right corner. The system 100, optionally, provides a graphical interface 1412 for enabling the user to modify the template 105 easily. As depicted, the interface 1412 includes a display screen 1413. The display screen 1413 includes a portion 1414a that enables the user modify hierarchical connections. The display screen 1413 also includes a portion 1414b that enables the user to change the content of particular data nodes, and a portion 1414c that enables the user to change the display layout of particular data nodes. This enables the user to edit the definitions of data objects defined in ZML.TM. or SZML.TM. format, without the need of the user to understand those formats. The interface 1412 enables the user to change the zoomed layout of data objects manually like a paint program. The user selects graphic appearance tools and then edits the ZML.TM. or SZML.TM. formatted information by manually using the interface 1412. For example, if there was special of the week, the user manually selects that node that corresponds to the data object representing the special of the week and using the tools 1414a-1414c, makes modifications. Also, the user can use the interface 1412 to go beyond the layout algorithm and design the look and feel of the virtual space with greater control. The graphical alteration interface 1412 operates in combination with the automated layout. Once the stylizer module 104 has arranged all of the data objects spatially using the template 105, the data objects are now in ZML.TM. format, and the have a location in the multi-dimensional, virtual space 110. The stylizer module 104 transfers the data objects in ZML.TM. format to the protocolizer module 106 for further processing. The protocolizer module 106 receives the data objects in the ZML format and transforms the data objects to a commonly supported protocol such as, for example, WAP, HTML, GIF, Macromedia FLASH.TM. and/or JAVA.TM.. The protocolizer module 106 converts the data objects to established protocols to communicate with a plurality of available clients 114 and browsers 118 to display the data objects from an adjustable viewing perspective in the navigable, multi-dimensional, virtual space 110. For example, a Macromedia FLASH.TM. player/plug-in is available in many browsers and provides a rich graphical medium. By translating the ZML.TM. formatted data objects to Macromedia FLASH.TM. compatible code, the data objects in the spatial hierarchy (i.e., ZML.TM. format) can be browsed by any browsers with a Macromedia FLASH.TM. player/plug-in, without any additional software. In one embodiment, the protocolizer module 106 is implemented as a servlet utilizing JAVA.TM., C, WAP and/or ZML formatting. The protocolizer module 106 intelligently delivers ZML.TM. formatted data objects as needed to client 114. The protocolizer module 106 preferably receives information regarding the bandwidth of the communication channel 122 used to communicate with the client 114. In the illustrative embodiment, the protocolizer module 106 delivers those data objects that are virtually closest to the user's virtual position. Upon request from the Zoom Renderer.TM. 120, the protocolizer module 106 transmits the data objects over the communication channel 122 to the client 114. An example illustrating operation of the protocolizer module 106 involves data objects relating to clothing and a template 105 relating to the physical paradigm of a clothing store. Due to the number of data objects involved, it is unrealistic to consider delivering all the data objects at once. Instead, the protocolizer module 106 delivers a virtual representation of each data object in a timely manner, based at least in part on the virtual location and/or viewing perspective of the user. For example, if the user is currently viewing data objects relating to men's clothing, then the protocolizer module 106 may deliver virtual representations of all of the data objects relating to men's pants and shirts, but not women's shoes and accessories. In a model of the data objects as a node tree, such as depicted in FIGS. 4A-4C, the focus node 402c is the node corresponding to the data object appearance 406c displayed from the current viewing perspective shown by the camera 416a. The protocolizer module 106 delivers to the client 114 those data objects that correspond to the nodes virtually closest the user's focus node 402c and progressively delivers data that are virtually farther away. As discussed with regard to FIGS. 4A-4C, the system 100 employs a variety of methods to determine relative nodal proximity. For example, referring once again to FIG. 4A, while the user is viewing the data object of node 402c, the protocolizer module 106 delivers those nodes that are within a certain radial distance from the focus node 402c. If the user is not moving, the protocolizer module 106 delivers nodes 402a, 402b, 402d and 402e, which are all an equal radial distance away. As also discussed with regard FIG. 4A, calculating virtual distances between nodes can be influenced by the hierarchical level of the nodes and also the directness of the relationship between the nodes. As skilled artisans will appreciate, the importance of prioritizing is based at least in part on the bandwidth of the communication channel 122. The Zoom Renderer.TM. 120 on the client 114 receives the data transmitted by the protocolizer module 106 authenticates data via checksum and other methods, and caching the data as necessary. The Zoom Renderer.TM. 120 also tracks the location of the user's current viewing perspective and any predefined user actions indicating a desired change to the location of the current viewing perspective, and relays this information back to the protocolizer module 106. In response to the viewing perspective location information and user actions from the Zoom Renderer.TM. 120, the protocolizer module 106 provides data objects, virtually located at particular nodes or coordinates, to the client 114 for display. More particularly, the Zoom Renderer.TM. 120 tracks the virtual position of the user in the virtual space 110. According to our feature, if the user is using a mobile client 114, the Zoom Renderer.TM. 120 orients the user's viewing perspective in relation to the physical space of the user's location (e.g., global positioning system ("GPS") coordinates). The user can influence which data objects the protocolizer module 106 provides to the client 114 by operating the user controls 107 to change virtual position/viewing perspective. As discussed above, delivery of data objects is a function of virtual direction (i.e. perspective) and the velocity with which the user is changing virtual position. The protocolizer module 106 receives user position, direction and velocity information from the Zoom Renderer.TM. 120, and based on this information, transmits the proximal data node(s). For example, in FIG. 4A, if the user is at node 402c and virtually traveling toward nodes 402e and 402h, the protocolizer module 106 delivers those no | ||||||