Abstract:
A system for effecting and monitoring a real-time process that is participated in by multiple participants over a network. In one embodiment, multiple components of the system include: at least one participant computer with a display; at least one server coupled to the at least one participant computer through the network; and at least one memory device that stores instructions. When the instructions are executed, they cause a processor to periodically collect real-time data regarding the real-time process, and periodically update a display with a graphical representation of a current state of the process using the real-time data. The instructions also cause the processor to receive participant inputs via the display, wherein the participant inputs include changes to the real-time data. The processor also updates the display to reflect the changes to the real-time data in response to the participant inputs.

Description:
RELATED APPLICATIONS  
       [0001]    This patent application claims priority from U.S. Provisional patent application Ser. No. 60/183,677, entitled Method and Apparatus for Graphical Representation of Real-Time Data, filed Feb. 18, 2000. 
     
    
     
       FIELD OF THE INVENTION  
         [0002]    The invention is in the field of software for processing and representing real-time data.  
         BACKGROUND OF THE DISCLOSURE  
         [0003]    For many processes that involve constantly changing data, it is desirable for a user of the data to be able to have access to an understandable version of a current state of critical data. This is particularly true when the user must make a decision based upon real-time data that will not remain static for very long. Increasingly, interactive processes are conducted by multiple participants via some electronic network. Each participant may at any time take an action that changes the critical data of the process. An example of such a process is an auction that is conducted via the Internet. Participants are typically multiple buyers and sellers who may change ask prices and bid prices at any time.  
           [0004]    Currently, auctions that are conducted in a networked environment, such as the Internet, are limited in the types of information provided to auction participants. An auction participant generally lists a product or service, or solicits a product or service, on an auction site. Participants then bid upon the product or service of interest. Generally, the listing of a product or service, either offered or solicited, is placed in a standard hypertext markup language (HTML) text listing at a particular auction web site. Auction participants may submit a bid or solicit offers, typically via electronic mail, for a particular product or service. In conventional electronic auctions, the auction participants do not have access to auction information other than the current asking price of the offered or solicited product or service. In conventional electronic auctions, participants are generally not aware of the dynamics of a current active auction, such as: data on other offers or bids from other auction participants; whether a particular auction transaction has been completed; how the auction participant&#39;s offers or bids compare with those of other auction participants; and a variety of other changing auction data.  
           [0005]    The typical auction environment has another disadvantage, namely, general latency problems with updating and processing bids and offers. Commonly, in current auction systems, a series of different bids or offers sent via electronic mail are received by a particular auction system but are not expeditiously processed. As a result, some auction participants are excluded from effectively participating in particular auctions, or their participation is delayed. Current electronic auctions, therefore, do not provide participants with important data regarding current auction dynamics.  
         SUMMARY OF THE DISCLOSURE  
         [0006]    Embodiments of the present invention include a system for effecting and monitoring real-time processes. In one embodiment the system includes software instructions that cause an operating system to periodically collect real-time data regarding a real-time process. The real-time data is used to update a display with a graphical representation of the current state of the process. Multiple objects on the display represent, for example, buyers and sellers. The objects on the display convey various pieces of changing information, such as: the number of items offered by a seller; the relative magnitude of a price offered by a buyer; how close a bid price and an ask price are; how long a bid or ask has been outstanding; when a bid or ask has been updated; and when a transaction is consummated. The information is instantaneously conveyed in a variety of ways, including: color of objects; relative positions of objects; and position of objects relative to a point on the display. In one embodiment, a server is periodically polled for real-time data with which to update the display. The update frequency can be controlled by a user. The type of data updated can also be controlled by a user. The user interface is also interactive; for example a process participant can change the real-time data by manipulating objects on the display.  
       
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0007]    [0007]FIG. 1 is a block diagram of an embodiment of a system for graphical representation of real-time data.  
         [0008]    [0008]FIG. 2 shows an embodiment of a user interface display.  
         [0009]    [0009]FIG. 3 shows an embodiment of a user interface display.  
         [0010]    [0010]FIG. 4 shows an embodiment of a user interface display.  
         [0011]    [0011]FIG. 5 shows an embodiment of a user interface display.  
         [0012]    [0012]FIG. 6 shows an embodiment of a user interface display.  
         [0013]    [0013]FIG. 7 shows an embodiment of a user interface display.  
         [0014]    [0014]FIG. 8 shows an embodiment of a user interface display.  
         [0015]    [0015]FIG. 9 shows an embodiment of a user interface display.  
         [0016]    [0016]FIG. 10 shows an embodiment of a user interface display.  
         [0017]    [0017]FIG. 11 shows an embodiment of a user interface display.  
         [0018]    [0018]FIG. 12 shows an embodiment of a user interface display.  
         [0019]    [0019]FIG. 13 shows an embodiment of a user interface display.  
         [0020]    [0020]FIG. 14 shows an embodiment of a user interface display.  
         [0021]    [0021]FIG. 15 shows an embodiment of a user interface display.  
         [0022]    [0022]FIG. 16 shows an embodiment of a user interface display.  
         [0023]    [0023]FIG. 17 shows an embodiment of a user interface display.  
         [0024]    [0024]FIG. 18 shows an embodiment of a user interface display operating as a banner on an Internet web page.  
         [0025]    [0025]FIG. 19 shows an embodiment of a user interface display.  
     
    
     DETAILED DESCRIPTION  
       [0026]    A system for effecting and monitoring real-time processes is described. The system includes software instructions that cause real-time data about the process to be collected and graphical information about the current state of the process to be displayed to a user or participant. The display can be part of a client computer on a network such as the Internet. The real-time data is changeable by a participant who manipulates the graphical display. Participating in the process is therefore much easier and faster than previously possible. The user interface provides an intuitive, interactive real-time environment for participants in any data-intensive process. In one embodiment, the user interface provides an intuitive, interactive real-time environment for participants in a network electronic auction.  
         [0027]    [0027]FIG. 1 is a block diagram of a system  100 , which is an embodiment of a system for effecting and monitoring real-time processes. System  100  includes multiple client computers  1002 ,  1003 ,  1004 , and  1005 . Each of client computers  1002  through  1005  include a display (displays  1010 ,  1011 ,  1012 , and  1013 , respectively). Each of client computers  1002  through  1005  also include respective storage devices  1014  through  1017 . In various embodiments, there can be any number of client computers. Client computers  1002  through  1005  are in communication with each other and with server  1006  through network  1008 . The client computers and the server  1008  can communicate through a wireless coupling or a wired connection over any network. The Internet is a network through which the client computers and the server can communicate, but another network, such as a wide area network, will also work. The user interface described further herein allow users of client computers  1002  through  1005  to participate in a real-time process using the respective displays. In some embodiments, client software may be stored on the respective storage devices  1014  through  1017  to accomplish the real-time process. in other embodiments, the real-time process is accomplished by software stored on the server  1006 .  
         [0028]    In one embodiment, the user interface (“UI”) includes template-generated hypertext markup language (HTML) pages and dynamic content. The dynamic content could be in any form, such as Java and DHTML. One component of the UI is an interactive graphical representation (“display”)  100  of real-time data that is shown in FIG. 2. The display  100  typically appears on a display device of a user or participant. The display  100  conveys information and is also a control device in that it accepts participant input directly through manipulation of the objects on the display  100 . A single seller or buyer is represented by the large object  102  in the center of the display  100 , and individual buyers or sellers are represented by various buyer objects and seller objects around the object  102 .  
         [0029]    The display changes as the real-time auction data changes. For example, as shown in display  200  in FIG. 3, as the prices offered by the buyers (in one particular marketplace) more closely approach the asking price of the seller represented by seller object  202 , the pertinent buyer objects move proportionally on the display  200 . In display  300  of FIG. 4, as the prices offered by the buyers (in one particular marketplace) diverge from the asking price of the seller represented by seller object  202 , the pertinent buyer objects move proportionally on the display  300 . The display functions symmetrically with respect to buyers and sellers; that is, either a seller can be represented in the center, surrounded by many buyers, or a buyer can be depicted surrounded by many sellers. As will be further described below, the display is also used to represent many buyers and sellers at the same time. Additionally, any objects other than circles could be used to represent the buyers and sellers.  
         [0030]    The user interface includes many features, some of which will be discussed with reference to further figures. FIG. 5 illustrates how the position of objects relative to each other represents the degree to which transactions are close to consummation. Object positions are updated dynamically, and the distance between objects decreases as a transaction comes closer to consummation. This gives participants a clear impression of movement in the market. No participant action is required to watch updated information. In display  400 , the transaction represented by “A” is closer to consummation than the transaction represented by “B”. A transaction takes place when the distance between a buyer object and seller object becomes zero. On display  400 , a buyer object would travel to the center and touch seller object  402  when a transaction between the two is consummated. The movement of the buyer objects and seller objects on the display  400  produces an “at-a-glance” knowledge of market changes and conditions.  
         [0031]    Distance as a representation of price or “score” produced by a multi-parametric weighting can be represented on a logarithmic scale in one embodiment. This means that movements in the market are accelerated near the center. These accelerated movements produce an exaggerated representation of market conditions near the consummation of a transaction. In display  500  of FIG. 6, the grid lines  502 ,  504  and  506  are placed at ¼ of the asking price, ½ of the asking price, and ¾ of the asking price, respectively. The lines  502 ,  504  and  506  provide a yet more specific, immediate visual quantification of the progress of an offer. These grid lines could be given other value representations (e.g. ⅓, ½, ⅔) if desired. In addition, the grid lines do not necessarily represent a percentage of an asking price; the lines can also represent the degree to which a proposal by a central buyer is met, in the case where the central object is a buyer. In that case, the grid lines  502 ,  504  and  506  would represent “ask ¼ of bid,” “ask ½ of bid,” etc. In other embodiments, distance is measured using a linear or other scale in place of the logarithmic scale.  
         [0032]    Another feature of the display, illustrated in the display  600  of FIG. 7, is that the size of an object represents the number of items held or desired by a seller or buyer. Object “B” represents an offer for a greater number of items, while object “A” represents an offer for a smaller number of items because object B is larger than object A.  
         [0033]    Color is also used to convey information. As an example: asks are colored orange; bids are colored blue; objects representing particular buyers or sellers who are using the user interface are colored red; updated offers are flashed yellow; and when a deal is consummated objects representing the participants in the deal are briefly colored purple. The flashing of updated offers in yellow and consummated transactions in purple gives an immediate visual impression of activity in the market.  
         [0034]    Sound is used to convey information as well. When a transaction is consummated, a sound is produced. When new offers are entered into the user interface, a different sound is generated.  
         [0035]    As shown in FIG. 8, the position of an offer on the display  700  as measured in radians or degrees from a reference point is used to convey information. The information conveyed includes the time a particular buyer or seller entered the auction. For example, offerors enter the auction at the 360° position on the display  700  and travel clockwise around the display as time progresses. Therefore, offer B has been in the auction for a longer period of time than offer A.  
         [0036]    Embodiments of the user interface include an interactive display as shown in FIGS. 9 and 10. Buyers and sellers can manipulate their respective buyer objects and seller objects on the display to change the real-time auction data. In one embodiment, objects on the display are manipulated with an input device such as a mouse. For example, when a particular offer is selected and moved on the display, a corresponding price change (or “score” change, in a multi-criteria auction) is automatically entered for that offer. That is, the real-time data used by the system is changed to reflect the new price or score. This is a much easier and faster method of entering or changing an offer than conventional keyboard-based or template-based input systems.  
         [0037]    The display  800  shows an offer being increased by dragging a corresponding object closer to the center of the display  800 . The display  900  shows an offer being decreased by dragging a corresponding object away from the center of the display  900 . In addition to the display, “price” button B and “confirm order” button C display the current offer price and allow the participant to confirm an order, respectively. As the object is dragged through the display field, the price at B is dynamically updated. The method described here (with a dynamically varying price display and a confirmation button) is one possible implementation of this system. For example, the confirmation button can be eliminated. After an offer is confirmed, the updated offer is sent to an auction engine.  
         [0038]    Another feature of the user interface is that a user can learn more about an individual offer, such as quantity, price, and other information, with a “mouse over” using an arrow pointer or other similar technique.  
         [0039]    As illustrated in FIG. 11, offers can be graphically entered and placed in the display  1000  field. Offers can be removed from the display  1000  field in a similar fashion. The price is dynamically updated at B and the participant confirms at C.  
         [0040]    As illustrated in FIG. 12, offers can be dragged to the center of the display  1100  for consummation. The price is dynamically updated at B and the participant confirms at C.  
         [0041]    In one embodiment, a buyer or seller in the center can capture multiple offers at once through a “pull” feature. This is illustrated in FIGS. 13 and 14. For example, as a seller whose object is in the center of the display  1200  clicks in the center and drags outward from A to B, a dynamic calculation is made as to the number of offers inside the generated “ring” and how much money (in the case of offers defined by price) would be received by the seller if all the offers in the ring were accepted. Approximately nine offers have been captured inside the ring on the display  1200 . The quantity and price are updated at C and D, and the participant can confirm at E. In FIG. 14, approximately twenty-four offers have been captured in display  1300 . This interactive technique allows quick and intuitive cash and unit management for buyers and sellers. Offers inside the ring may represent different quantities, and this is included in the quantity and price calculations.  
         [0042]    Referring to FIGS. 15 and 16, a buyer or seller whose object is in the center can dynamically vary his or her offering price by “grabbing” the display field and moving it closer or farther from the center. The display  1400  field is being dragged away from the center, resulting in a higher offer price. The display  1500  field is being dragged closer to the center, resulting in a lower offer price.  
         [0043]    The user interface can be generalized to show many buyers and sellers at the same time, as shown in FIG. 17. Interactive features such as those previously described are implemented for a double display  1600 . In one embodiment, the A side of the display  1600  represents buyers and the B side represents sellers. Transactions are consummated in the center C.  
         [0044]    The user interface can be displayed over the Internet or any other network as a banner advertisement, which will give users the opportunity to see markets in a live fashion throughout the world wide web, as shown in FIG. 18. Users can also interact with the display  1700 , through for example, DHTML and Java, or DHTML and JavaScript. Many other implementations are possible.  
         [0045]    One embodiment of a user interface that includes multiple buyers and multiple sellers is shown in FIG. 19. The display  1800  has a “butterfly” design that separates the buyers and sellers. Two radial lines define an area occupied by either buyer objects or seller objects. In the display  1800 , area A contains seller objects, and area B contains buyer objects. The remaining areas, as illustrated by C, are blank.  
         [0046]    The manner in which the real-time data is collected and processed is variable. For example, in one embodiment, the user interface provides updates to web browsers in real time. To accomplish this, the display, as a Java applet in a browser, “polls back” to an originating server on a timed basis (e.g. once a second) to receive real-time data updates. These data updates allow the display to reflect the relative changes in offer positions. In some circumstances, this technique can result in a number and/or frequency of server requests that becomes burdensome to the server. Other embodiments help reduce the number of server requests while still providing pertinent real-time information graphically.  
         [0047]    One of the alternate embodiments allows a participant to specify that the data associated with a subset of the objects displayed will be updated on a relatively more frequent basis, while the remainder are updated relatively less frequently. For example, suppose that there are M current offers (bids and asks) being displayed, and no differentiation is made as to data to be updated. In the previously described embodiment, each time an object is moved, the display polls back to the originating server with requests for M pieces of data to be displayed. In a first alternative embodiment, however, the user can specify that only N offers (where N is less than M) will be updated in real time, while the remaining M-N offers will receive updates on a less frequent basis. Generally, the N offers that are updated will be the highest bids and the lowest asks, or those most likely to result in a transaction at any particular time. As an actual example, if fifty offers are displayed, the user might specify that twenty of those offer be updated in real-time, or about once per second. The frequency with which the remaining thirty offers are updated can be specified as, for example, one fifth or less of the original frequency, that is, once every five seconds or less often. The frequency specified can be any frequency that is less than the original frequency. The frequency is typically chosen to optimize the reduction of server requests and the amount of data transferred per request.  
         [0048]    A second alternative embodiment provides another way to reduce the number of requests to the server. In this embodiment, the display is initially set to refresh its data from the server at a specified frequency, for example once per second. The user interface then measures the rate of data change by determining an amount of change in a current set of data received and comparing it to the amount of change in a data set previously received. If the rate of data change is low, the user interface increases its refresh interval, for example from one second to two seconds. Conversely, if the rate of change is high, the user interface reduces its refresh interval. The user can set the upper and lower bounds for this procedure. Thus, a user might specify that the display will refresh no more often than once a second, but no less frequently than once every five minutes. In this way, an optimal refresh rate can be determined and the server is only heavily loaded when the rate of data change is high. In addition, the user experience is relatively unaffected, because the data refresh period is lengthened only when there are relatively few changes in the data to be observed.  
         [0049]    The invention has been described with reference to specific examples. One skilled in the art might make various modification to the example embodiments without departing from the scope of the invention, which is defined by the following claims.