Patent Application
20130073409
The disclosure relates to the field of electronic commerce, and more particularly to user interface facilities for carrying out real-time online auctions.
A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
Procurement organizations often conduct ecommerce auctions to identify the most preferred suppliers for goods and services that the procurement organization is looking to procure. These ecommerce auctions often involve multiple goods and/or service items, and often many suppliers are invited to participate in the auction. In an ecommerce auction, the frequency of bid updates from suppliers tends to increase as the auction nears completion and the bidding gets more and more competitive. Even as the auction nears completion and activity increases, the buyers within the procurement organizations have to keep track of incoming bids from suppliers, determine the impact of new bids, calculate or estimate the effect on the relative rankings between bidding suppliers, calculate or estimate projected savings, and so on.
Based on such fast-changing information, the buyer may be compelled to take necessary actions such as pause the auction, extend the remaining time duration, etc. In fast paced auctions, it becomes very difficult for the buyer to absorb the fast-changing information (e.g., the changes to incoming bids) and assess their impact to the organization and to the supplier selection process. Legacy systems have rudimentary bid monitoring capabilities intended to show data regarding incoming bids. However, legacy systems fall short of aiding the buyer in order to show (e.g., via a highlight or emphasis) the changed bid, and to show (e.g., via a highlight emphasis) the impact of the changed bids. Moreover, towards the close of the auction this information is ever more fast-changing, making it nearly impossible for the user to manually figure out what information had changed and interpret the impact or impacts resulting from the changed information.
Therefore, there is a need for an improved approach involving fast-paced dynamic monitoring of changing data in a real-time online auction using interpretive data change indicators.
A method, system, and computer program product for updating an auction monitor display with highlighting or emphasis in the form of graphic data change indicators. The method commences by capturing a first set of auction variables, the auction variables pertaining to an ecommerce auction involving sellers participating in the ecommerce auction. Then, for ongoing refresh of the monitor display, the method introduces a delay of a variable duration of time, the variable duration of time based on the length of time before the end of the auction. Additionally, some implementations allow a manual establishment of the refresh interval and/or a forced refresh at any point in time.
At various points within each delay period, the method captures a second set of auction variables which are compared to the first set of auction variables to identify a candidate set of changed auction variables for emphasis. The determination of the manner of emphasis is based on the changed auction variable and characteristics of the type of change affecting the changed auction variable.
Further details of aspects, objects, and advantages of the disclosure are described below in the detailed description, drawings, and claims. Both the foregoing general description of the background and the following detailed description are exemplary and explanatory, and are not intended to be limiting as to the scope of the claims.
Embodiments of the present disclosure are directed to an improved dynamic auction monitor with graphic interpretive data change indicators.
As earlier indicated, legacy systems fall short of aiding the buyer in order to show activity (e.g., bidding activity) during the course of an auction. Additionally, legacy systems fall short of aiding the buyer in order to assess the impact of changed bids or other bidding activity. Moreover, towards the close of the auction this information is ever more fast-changing, and users need computer-aided support to figure out what information changed and computer-aided support to interpret the impact resulting from the changes. The system and methods disclosed herein provide dynamic bid monitoring screens that automatically display information about incoming bids. The screens are refreshed in real-time at dynamically-updated screen refresh rates, which rates are responsive to (a) manual refresh requests, (b) manual screen refresh rate requests, and/or (c) refresh rates determined by the progression of the auction toward a scheduled completion time (or any combination thereof). Also, as new bids come in, the system graphically highlights changes compared to prior bids and interprets the positive or negative impact brought about by said changes. Bids that have changed between screen refreshes are highlighted by a change icon or other screen device placed next to the changed bid. The new bid amount and variance from previous bid amount are also displayed, and highlighted (if changed). In some cases an up/down arrow icon is displayed next to the bid amount, which up/down arrow icon serves to indicate the direction of change. In other cases, the color of the arrow (e.g., green, red, etc.) indicates whether the change was favorable or unfavorable. Other auction variables (e.g., overall price, vendor/supplier rankings, projected savings, etc.) are highlighted using up/down and/or green/red arrow icons. In this manner, the attention of the buyer is quickly brought to the existence of and the nature of changed information from one screen refresh to the next.
Returning to
In exemplary embodiments, the seller clients are configured to submit bids in the ecommerce auction, and the existence and use of the network 130 supports remote bidding. That is, a seller can submit bids (and/or changes to a bid) from a remote location using the network 130 (e.g., a distributed computer network) to submit such bids, which bids are then processed by an exchange server 101 and presented to a buyer (e.g., at a buyer client 120) using a graphical user interface. In this embodiment, the exchange server can receive multiple bids from multiple seller clients, and can interpret and/or forward the changes to a buyer client 120. In some embodiments, the interpretation and/or forwarding of the changes is configured to occur at the exchange server so that it can, in turn, provide changes to a buyer client 120 in accordance with the configuration. The changes provided by exchange server to a buyer client 120 can be provided in the form of changed data, and/or changed data with an indication of the nature of the changes, and/or any portions of a GUI (e.g., graphical screen devices, or parameters) or any combination of changed data representations. In some embodiments, the changed data is interpreted by an exchange server. In other embodiments, the changed data is interpreted by a buyer client 120, and the changed data can be viewed by a user 105, and such viewing can be at least partially controlled by a user 105.
In the embodiment shown, the change interpreter 124 includes a time table 140 for automatically determining the frequency of communications over data path 125 and command path 127, and further includes a change analyzer 142 for determining the nature of the communications over the data path 125 and command path 127.
The embodiments of
In exemplary embodiments, a buyer client 120 implemented using an auction monitor display 122 and a change interpreter 124 operates as follows: As any auction variables 129 are displayed (e.g., as a new bid comes in or as a new value of a bid comes in), the system 160 graphically highlights changes compared to prior bids and interprets the positive or negative impact brought about by said changes. For example, bids that had changed between screen refreshes are highlighted by a change icon placed next to the corresponding screen device (e.g., a screen device to display a bid number). The new bid amount and its variance from the previous bid are displayed. As another example, when a bid amount changes, a screen device (e.g., an up/down arrow icon) indicates the direction of change, while the color of the screen device (e.g., green or red) highlights the interpretation as to whether the change was favorable or unfavorable. Similarly, impact to other values are interpreted and displayed with emphasis. For example, a change in a bid (e.g., a change in a per unit bid) would likely impact the price of the total order, and thus the change in price would be highlighted or otherwise emphasized. Other auction-related values that are impacted by a change (e.g., the rankings among multiple bidders, projected savings, etc.) are emphasized by up/down arrow icons and/or green/red arrow icons. In this manner, the attention of the buyer is quickly brought to the changed auction values (e.g., a bid changed by a supplier) as well as to the impacted/changed calculated variables (e.g., percent change, etc.) from one refresh of the screen to next. In some cases, an auction monitor display 122 might be displayed before the auction begins, or before any auction values have changed. In other cases when some auction values had indeed changed, they are highlighted, thus rendering an emphasized auction monitor display 180 with highlighting and/or change indicator graphics and/or other emphasis.
In the embodiment of system 160, the timing and content of any rendering of an emphasized auction monitor display 180 is controlled by a scheduler engine 126, and presentation emphasis engine 128. For example, scheduler engine 126 uses a time table 140 and/or screen refresh rate 144 to determine the timing for the next rendering of a changed auction variable 182, and to determine a change to the frequency of successive renderings. Also, the content of any rendering of an emphasized auction monitor display 180 is controlled the presentation emphasis engine 128. For example, presentation emphasis engine 128 uses a change analyzer 142 to determine the highlighting and/or change indicator graphics and/or other emphasis to be used in a particular rendering.
As another example, when a bid amount changes, the color of a screen device (e.g., green up arrow or red down arrow) interprets whether the change was favorable or unfavorable. Similarly, impact to other values are interpreted and displayed with highlighting or other emphasis as is appropriate for the particular value and interpretation whether the change was favorable or unfavorable. In this manner the attention of the buyer is quickly brought to the changed auction values (and the impacted/changed calculated variables) from one refresh of the screen to the next.
The method of
In exemplary embodiments, the values of time-variant variables are highlighted or emphasized as they change. Accordingly, the operation 210 serves to capture an initial snapshot. In a subsequent step, (see operation 230) a later snapshot is compared to the earlier snapshot, and compared specifically with a purpose to identify changes.
Returning to the earlier discussion regarding the time table 140 and its use to specify a screen refresh rate 144, it is reasonable and envisioned that a default screen refresh rate be established. One possible default refresh rate is given in Table 2.
In some embodiments a default refresh rate can be adjusted by a user 105, and/or a refresh can be forced at any point in time. Given the specific values of the refresh rate time table 140, an operation 220 serves to calculate the then current refresh rate based on real-time conditions. For example, if there remains only 9 minutes in the auction, and the auction is not suspended, then the refresh rate might be calculated (referring to Table 2) to be 30 seconds. The operation 210 and operation 220 (and other operations) generally execute many times during the course of an auction (see return path 275); thus, various groups of operations of method 200 might be organized into functions or subroutines (e.g., see subroutine 246, and subroutine 248).
Inasmuch as the techniques disclosed herein serve to implement a dynamic auction monitor with graphic interpretive data change indicators, mechanisms are provided to identify changed data. Accordingly, operation 230 and operation 240 serve to identify changed data for interpretation and emphasized display. Specifically, operation 230 serves to capture a second snapshot of selected time-variant auction variables for comparison with the first snapshot from operation 210. Continuing, the operation 240 serves to compare changed values of the time-variant auction variables. The techniques of operation 230 and operation 240 can be implemented in any environment. For example techniques of operation 230 and operation 240 can be implemented as a function within system 160 (e.g., a function within change analyzer engine 142).
Now, even at this juncture, it is possible to render an emphasized auction monitor display 180 using only the changed auction values as determined in operation 240; however in exemplary embodiments, a user 105 might like to see emphasis at or near the changed calculated variables 186 that were changed during the most recent refresh period. To prepare an emphasized display of changed calculated variables 186, operation 250 serves to interpret the impact that a changed auction variable 182 (e.g., with new value) has on other variables. It is often the case that a change in an auction variable will be reflected in one or more changed calculated variables 186, and those changed calculated variables 186 might be highlighted as described above. The foregoing notwithstanding, it is possible that the specific change of a changed calculated variable 186 or of a changed auction variable may or may not be regarded as sufficient to warrant emphasis in the emphasized auction monitor display 180. For example, it is possible that a small change in a bid (e.g., a few cents) might be calculated, and flowed to the total contract price, yet it is possible that the impact of the small change in the bid might not change the displayed total contract price when the total contract price is displayed in whole dollars. For this and other reasons, embodiments herein use thresholding techniques in the process of comparing auction variables to identify statistically small changes (e.g., below a threshold, below a calculated threshold) in order to remove them from a candidate set of changed auction variables.
On the other hand, certain specific changes (e.g., changes larger than a threshold) of a changed calculated variable 186 or of a changed auction variable may indeed be regarded as sufficient to warrant emphasis, and operation 260 serves to display the changes in the emphasized auction monitor display 180.
The series of operations 210 through operation 260 are repeated until the auction is deemed as ended (see decision 270). Of course any of the operations 210 through operation 260 may retrieve data and perform calculations anew as may be appropriate for the real-time conditions. Just as an example, the operation 260 iteratively selects the refresh rate based on the then-current real-time conditions.
Operation 330 calculates a refresh rate at least partially based on the amount of time before the end of the auction. Such a calculation might use a table such as Table 2, or it might use a table such as Table 2 in conjunction with other variables. Further, a table such as Table 2 might be initially provided as a default table, and might be modified by a user 105. Techniques for handling the variables mentioned in the preceding paragraph that could be used in conjunction with amount of time before the end of the auction include (but are not limited to): (1) calculation of the number of suppliers currently online to predict when new information might be available; (2) calculations including the occurrence of an updated supplier bid to influence the refresh rate; and/or (3) calculations including the occurrence of a new supplier entering the auction to influence the refresh rate, and/or (4) consideration of manually established refresh rate inputs to calculate a refresh rate.
Continuing, and having calculated a refresh rate (see operation 330), the method 300 proceeds to introduce a real-time delay. Such a real-time delay (see decision 340 and operation 350) serves to introduce real-time delay between screen refreshes. It is possible in some situations that the method 300 should complete and return to the caller without introducing a delay, and in such situations, a delay flag can be used to control the introduction of a real-time delay (e.g., such delay as introduced by operation 350), which real-time delay serves to separate the calculation and display of changed time-variant variables and display of changed calculated variables 186.
In exemplary embodiments, a variable duration of time (e.g., a refresh rate) is determined within the time interval between the action of capturing the first set of auction variables (see operation 210) and the action of capturing the second set of auction variables (see operation 230).
As shown, the technique 400 uses a function 428, which function 428 can receive as inputs one or more values in the form of a time-invariant variable 422, a time-variant variable 424, and/or a calculated time-variant variable 426. Execution of the function 428 then results in an output value, the output value being a changed calculated variable 186.
Accordingly, the auction variables are monitored over time (e.g., an earlier set of auction variables are compared to a later set of auction variables) and when changes are detected in one or more of the compared instances of auction variables, and a set of candidate changed auction variables is created for further processing. However, some of the candidate changed auction variables might be changed by a lot (requiring one sort of further processing) and some candidate changed auction variables might be changed by only a little (requiring a different sort of further processing). As an example, there is a class of changes to auction variables that have low impact to the status of the auction. And there is a class of changes to auction variables that can be classified as phantom changes, and unless filtered, might result in undesired change indications. For example, a time-variant auction variable (e.g., a bid price) might have been changed by a supplier, yet the change to the variable might have been so small as to be numerically insignificant (e.g., a bid change from $1.00 to $1.001), or too small to display (e.g., if the display were in whole dollars rather than in dollars and cents). Or, a time-variant variable (e.g., a bid price) might have been changed by a supplier to indicate a different direction of change (e.g., from $0.99 to $1.00 and then back to $0.99), yet the change is so small as to be deemed negligible, and should not be highlighted as a change.
As another example, a group of suppliers might be changing their bids over a wide range, such as by many percentage points or more; yet one particular supplier is concurrently changing their bid in a very narrow, possibly numerically insignificant range. In such a case, that narrowly changed bid has a low impact to the status of the auction, and should be filtered from the set of variable selected for highlighting. There are many techniques applicable in order to determine the significance of a change in relation to other changes. One possible technique is to obtain a statistical measure via application of one or more statistical analysis techniques to compare changed variables. Referring again to the example of a small bid change in the face of many other much larger bid changes, a histogram or other distribution of the changes can be calculated, and (for example) if the small change is smaller than (for example) two sigma standard deviation from the norm, then the small change is a candidate for filtering.
Referring again to the flowchart of operations 600 to select one or more changes as candidates for highlighting, the operation 610 serves to perform statistical analysis on the changed auction values, and to use the results of such statistical analysis on the changed auction values to classify the changed auction values (see operation 620). Such a classification might be in the form of classifying into statistical ranges, such as one-sigma, two-sigma, etc. Or a classification might include qualitative assessment, such as ‘nuisance’, ‘negligible’, ‘important’, ‘critical’, etc. Having classified the changed values, some of the changed variables are selected for use in calculating dependent variables. For example, a numeric change to an offer price has a numeric impact to the total cost over all units ordered in the line. However, it is possible that such a change to an offer to sell price does not have a displayable impact to the total cost over all units ordered in the line. The operation 630 exemplifies one technique where changes classified as negligible do not cause recalculation of dependent variables, thus the dependent variables are unchanged in this iteration and are not highlighted in the emphasized auction monitor display 180.
On the other hand, changed auction variables flowed to recalculated dependent variables (e.g., changed calculated variables 186) might indeed be so significant as to warrant being highlighted in the emphasized auction monitor display 180. Operation 640 serves to perform statistical analysis on the changed calculated variables, and operation 650 serves to classify changed calculated variables using statistical measures, again to determine a quantitative and/or qualitative assessment in order to deem the change to be significant enough as to be selected as a candidate for being highlighted in the emphasized auction monitor display 180 (see operation 660).
Operation 630 and operation 660 are similar in the regard that both operations select candidates for being highlighted in the emphasized auction monitor display 180. However, yet another filter might be applied, and such an additional filter can be implemented in the form of a threshold (see operation 670). Of course, a threshold can be implemented according to many techniques, including a raw numeric threshold, a percentage threshold, or a moving average threshold, to name a few. Operation 670 serves to apply a threshold to determine if a given variable (e.g., a changed auction variable, or a changed calculated variable, etc.) is to be highlighted or otherwise emphasized.
Of course, the aforementioned function or table can involve additional processing beyond a mere lookup in a table, and might include temporal considerations, or biasing toward showing changes using visually aesthetic techniques such as smooth movement, fade-in and dissolve techniques, movement of bars in bar charts, etc. And, any such determinations of manner of emphasis can be sent to cooperating system components (e.g., the presentation emphasis engine 128) in preparation for rendering and display (see operation 730).
According to one embodiment of the disclosure, computer system 1100 performs specific operations by processor 1107 executing one or more sequences of one or more instructions contained in system memory 1108. Such instructions may be read into system memory 1108 from another computer readable/usable medium, such as a static storage device 1109 or a disk drive 1110. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement the disclosure. Thus, embodiments of the disclosure are not limited to any specific combination of hardware circuitry and/or software. In one embodiment, the term “logic” shall mean any combination of software or hardware that is used to implement all or part of the disclosure.
The term “computer readable medium” or “computer usable medium” as used herein refers to any medium that participates in providing instructions to processor 1107 for execution. Such a medium may take many forms, including but not limited to, non-volatile media and volatile media. Non-volatile media includes, for example, optical or magnetic disks, such as disk drive 1110. Volatile media includes dynamic memory, such as system memory 1108.
Common forms of computer readable media includes, for example, floppy disk, flexible disk, hard disk, magnetic tape, or any other magnetic medium; CD-ROM or any other optical medium; punch cards, paper tape, or any other physical medium with patterns of holes; RAM, PROM, EPROM, FLASH-EPROM, or any other memory chip or cartridge, or any other non-transitory medium from which a computer can read data.
In an embodiment of the disclosure, execution of the sequences of instructions to practice the disclosure is performed by a single computer system 1100. According to other embodiments of the disclosure, two or more computer systems 1100 coupled by a communication link 1115 (e.g., LAN, PTSN, or wireless network) may perform the sequence of instructions required to practice the disclosure in coordination with one another.
Computer system 1100 may transmit and receive messages, data, and instructions, including program, i.e., application code, through communication link 1115 and communications interface 1114. Received program code may be executed by processor 1107 as it is received, and/or stored in disk drive 1110 or other non-volatile storage for later execution.
In the foregoing specification, the disclosure has been described with reference to specific embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the disclosure. For example, the above-described process flows are described with reference to a particular ordering of process actions. However, the ordering of many of the described process actions may be changed without affecting the scope or operation of the disclosure. The specification and drawings are, accordingly, to be regarded in an illustrative rather than restrictive sense.
