Method and system of bidding in a vehicle

A method of dynamically altering a user interface based on safety level is provided. A user interface is provided to a user in a vehicle with the user interface including a selectable option to wirelessly place a bid on an electronic auction. The selectable option is based, at least in part, on an auction parameter. A safety level score is then determined for the vehicle. The auction parameter is then dynamically altered based on the speed of the vehicle, resulting in a change to the selectable option.

BACKGROUND

Recently, it has been more common for users to utilize electronic devices in moving vehicles as in, for example, automobiles. The user interface may be displayed on an in-dash computer screen or may be located on a smartphone, which may be carried or may be physically mounted on a dashboard of the vehicle, for example. For the most part, the user experience with these in-vehicle electronic devices is somewhat static in nature. The user interface (UI) screens displayed are the same no matter the state of the vehicle. Some automobiles automatically deactivate particular element of such UIs while the vehicle is in motion and only allow the element to be activated when the vehicle is stopped and in “park,” thus the decision is simply “on/off: if the car is in motion, the element is disabled

DETAILED DESCRIPTION

Although the present embodiments have been described with reference to specific example embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the embodiments. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.

In an example embodiment, rules for an electronic auction may be dynamically modified based on the degree of motion (e.g., speed) of a vehicle or device utilized by a bidder. In an example embodiment, a bid increment for the electronic auction may be dynamically modified based on speed.

FIG. 1is a network diagram depicting a client-server system100, within which one example embodiment may be deployed. A networked system102, in the example form of a network-based marketplace or publication system, provides server-side functionality, via a network104(e.g., the Internet or Wide Area Network (WAN)) to one or more clients.FIG. 1illustrates, for example, a dashboard client106(e.g., software running in a dashboard) and a programmatic client108executing on respective machines, namely vehicle110and client machine112.

An Application Program Interface (API) server114and a web server116are coupled to and provide programmatic and web interfaces respectively to, one or more application servers118. The application servers118host one or more marketplace applications120and payment applications122. The application servers118are, in turn, shown to be coupled to one or more database servers124that facilitate access to one or more databases126.

The marketplace applications120may provide a number of marketplace functions and services to users that access the networked system102. The payment applications122may, likewise, provide a number of payment services and functions to users. The payment applications122may allow users to accumulate value (e.g., in a commercial currency, such as the U.S. dollar or a proprietary currency, such as “points”) in accounts and to redeem the accumulated value for products (e.g., goods or services) that are made available via the marketplace applications120at a later time. While the marketplace and payment applications120and122are shown inFIG. 1to both form part of the networked system102, it will be appreciated that, in alternative embodiments, the payment applications122may form part of a payment service that is separate and distinct from the networked system102.

Further, while the client server system100shown inFIG. 1employs a client-server architecture, the present disclosure is, of course, not limited to such an architecture and could equally well find application in a distributed or peer-to-peer architecture system, for example. The various marketplace and payment applications120and122could also be implemented as standalone software programs, which do not necessarily have networking capabilities.

The dashboard client106accesses the various marketplace and payment applications120and122via a web interface supported by the web server116. Similarly, the programmatic client108accesses the various services and functions provided by the marketplace and payment applications120and122via the programmatic interface provided by the API server114. The programmatic client108may, for example, be a seller application (e.g., the TurboLister application developed by eBay Inc., of San Jose, Calif.) that enables sellers to author and manage listings on the networked system102in an off-line manner and to perform batch-mode communications between the programmatic client108and the networked system102.

FIG. 1also illustrates a third party application128, executing on a third party server machine130, as having programmatic access to the networked system102via the programmatic interface provided by the API server114. For example, the third party application128may, utilizing information retrieved from the networked system102, support one or more features or functions on a website hosted by the third party. The third party website may, for example, provide one or more promotional, marketplace or payment functions that are supported by the relevant applications of the networked system102.

Electronic auctions, such as auctions conducted online via online auction sites such as eBay™, have various auction parameters. Certain parameters, such as auction complete time, minimum price, etc., are sometimes set by the seller. Other parameters, such as minimum bid increment, are often set by the system. However, all of these parameters are fixed when the auction begins and remain static throughout the course of the auction. In the case of minimum bid increments, the bid increment will sometimes change during the course of the auction but only in a fixed pattern. For example, an auction may have a minimum bid increment of $0.05 until the bid reaches $1, then have a minimum bid increment of $0.10 until the bid reaches $5, then have a minimum bid increment of $0.25 until the bid reaches $10, and so on. Despite the minimum bid increment changing during the course of the auction, it does so in a fixed, predictable pattern and does not change dynamically based on some run-time condition.

In an example embodiment, auction parameters are dynamically altered during the auction based on motion of a device where a bid is being placed. Specifically, for an embodiment where the device is part of or located inside a vehicle, auction parameters are dynamically altered based on the speed of the device (and ultimately, the vehicle).

When dealing with user interfaces presented in moving vehicles, safety becomes a big factor. Oftentimes, it is a driver of a vehicle who is interacting with the user interface. As the speed of the vehicle increases, the danger of losing attention on driving while interacting with the user interface increases. Recognizing this fact, in an example embodiment, the system attempts to minimize the amount of user interaction required to place bids. One way in which the user interaction can be reduced is by decreasing the number of bids necessary to be entered. Oftentimes, a user will enter into a competitive bidding process during an auction: the user will enter one bid only to be outbid by an amount equal to the minimum bid increment, and then renter another bid higher than the current bid by the minimum bid increment. This process can repeat innumerable times until the auction is completed. In an example embodiment, the minimum bid increment increases as the speed of the vehicle in which the user interface is being run increases. By increasing the minimum bid increment, the number of times the user will likely have to rebid is reduced and, thus, makes being outbid less likely.

FIG. 2is a diagram illustrating a progression of dynamic alteration of a user experience, in accordance with another example embodiment. Depicted are three states of a user interface200a,200b, and200c, displaying an auction notification. The user has bid and has, subsequently, been outbid on an online auction. As such, the system is attempting to notify the user that he/she has been outbid to see if he/she wishes to rebid and in what amount. User interface200aincludes a notification202, a bid next increment button204which allows the user to automatically make a bid one increment higher than the highest bid, a buy it now button206which allows the user to simply end the auction by purchasing the item at a pre-set price, and a cancel button208which allows the user to do nothing but dismiss the notification202. The user interface200amay be displayed when it is deemed safe enough for the user to do so, based on the various factors described earlier.

As the user drives the vehicle, the device may ultimately be deemed to be in a “less safe” state: the vehicle is moving faster than before, but still at a slow speed. In such an instance, a transition may be made to user interface200bwhere the bid next increment button204now reflects a bid increment of $25 instead of $5.

As the user continues to speeds up, a transition may be made to user interface200c, wherein the bid net increment button204now reflects a bid increment of $50 instead of $25.

The modifications to the user experience may not solely be based on speed. Indeed, various information related to the safety level of the vehicle may be utilized in order to determine how to dynamically modify one or more parameters of the electronic auction.

FIG. 3is a diagram illustrating a system, in accordance with an example embodiment. The system300may include a dynamic auction parameter module302. Coupled to the dynamic auction parameter module302may be various information sources and/or sensors304-326from which the dynamic auction parameter module302may gather information related to the current safety level of a vehicle. These various information sources and/or sensors304-326may be located in a vehicle, in a mobile device travelling in the vehicle, or outside the vehicle. Presented here are a number of examples of these information sources and/or sensors304-326, but the disclosure is not limited to the examples provided. Additionally, not all embodiments will contain each of these information sources and/or sensors304-326and, in fact, some embodiments may rely on a single information source and/or sensor304-326(such as, for example, one that provides speed information). Indeed, certain types of information may be gathered from various alternative mechanisms. As an example, speed information could be gathered from examining a GPS module304over time and calculating the change in distance over that time. Alternatively, speed information could be gathered directly from a speedometer sensor306. Other possible sensors that might be commonly located within the vehicle may be an RPM sensor308which could be used to generally gauge acceleration, a steering wheel sensor310which could be used to gauge how much the vehicle is moving laterally, a cruise control sensor312which may be used to gauge whether cruise control is engaged (which typically would imply a safer environment), a brake sensor314which may be used to gauge whether the vehicle is currently braking, and a traction control sensor316which may be used to gauge whether traction control is currently engaged (which typically would imply a less safe environment).

An accelerometer318, such as those commonly found in smartphones, could also be accessed.

Also presented are information sources320-326that may commonly be located outside of the vehicle, such as a mapping server320which may be used to determine how safe the current physical location is (e.g., a curvy mountain road may be less safe than a straight desert highway), a weather server322which may be used to determine local weather conditions (e.g., is the vehicle located in a storm front), a user profile database324which may store demographic information about the user (e.g., a driver), such as age, which could be useful in determining the relative safety level (e.g., a 16 year old driver or an 85 year old driver may require a “safer” user experience than a 40 year old driver), and an insurance database326which may contain information from an insurer of the vehicle, such as a safety record of the driver.

The dynamic auction parameter module302may be located in the vehicle, on a mobile device, or on a separate server, such as a web server. The dynamic auction parameter module302may act to calculate a score identifying the relative safety level of the vehicle based on one or more of the factors described above. This score may be compared with a series of thresholds to determine which of a number of different possible auction parameter modifications should be made. The thresholds may be stored in a table maintained in a data store328.

A user interface presentation module330may receive the instructions for the updated user interface from the dynamic auction parameter module302and update the user interface accordingly. This update may take a number of forms, including the modification of a web page to be displayed in a browser, or the modification of visual or audio elements of an application user interface running in the vehicle.

FIG. 4is a diagram illustrating a table of dynamic auction parameter adjustments, in accordance with an example embodiment. The table400includes an identification of value for an auction parameter in one column402and a score threshold in another column404. As an example, the dynamic auction parameter module302may calculate a safety level score on a scale of 0-100. The table400, therefore, identifies six different values for auction parameters406-414each of which is used if the score is between the identified threshold and the next threshold. If the dynamic auction parameter module302calculated a current safety level score of 56, then value410(correlating to a bid increment of $25) would be utilized. If the situation changes to a less safe situation and the safety level score drops to 35, the table indicates that the bid increment should be changed to a user experience value408(correlating to a bid increment of $50).

It should be noted that the above example provides fixed values for each safety level. However, there may be certain auction parameters where fixed values may not be appropriate in all circumstances. For bid increment, for example, the increment may be somewhat based on the current bid amount. As such, the table400may express different parameter values in terms of percentage or incremental variations on a default bid increment. For example, when the value of an auction is at $1, the default bid increment may be $0.05. The default bid increment may be used for the value at the highest category of the safety score. As such, values for subsequent categories of safety score may be represented as a percentage of that default bid increment (e.g, 2× default bid increment, 3× default bid increment, etc.)

Alternatively, bid increments may increase incrementally. For example, the system may already be designed with the knowledge that bid increments typically are one value up to a certain current bid amount, and then a different value up to another current bid amount, and so on. For example, default bid amounts may be $0.05, $0.10, $0.25, $0.50, $1, $2, $5, $10, $25, and $50, depending on current bid amount (increasing incrementally). In an example embodiment, as speed (or other safety factors) makes the vehicle more dangerous, the bid increment increases from the default bid increment for the current bid amount (say, e.g., $1 on a $100 item) to the next highest bid increment for the system (say, e.g., $2, which would ordinarily only be in force for a $200 item. However, since the safety of the vehicle in this example is compromised, it would be used for the $100 item).

It should be noted that while the above describes a single current safety level score based on one or more factors affecting the current safety level, the system could also be “forward-thinking” and calculate potential future changes to the current safety level and utilize such potential future changes in determining how to dynamically alter the user experience. This may involve, for example, calculating potential future safety level scores or weighting (e.g., discounting or increasing) the current safety level score based on the future projections. For example, the system may determine that the current safety level score is a relatively safe 78; however, due to increased traffic ahead on the vehicle's route and projected weather information, the safety level may drop dramatically within a short time frame (e.g., within 5 minutes). As such, the relatively safe 78 score may be discounted so that the user experience presented is one that is designed for a less safe environment than if the 78 score were anticipated to continue for an extended period of time.

FIG. 5is an interaction diagram illustrating a method500, in accordance with an example embodiment, of dynamically altering a user interface. In this method500, a vehicle502may contain a sensor504, a dynamic auction parameter module506, and a user interface presentation module508. At operation510, the sensor504sends sensor information to the dynamic auction parameter module506. At operation512, a safety level score is calculated from sensor information. At operation514, an auction parameter is dynamically modified based on the safety level score, thus changing a selectable option related to the auction in a user interface. At operation516, the dynamic auction parameter module506sends the modified user interface to the user interface presentation module508, which at operation518presents the modified user interface.

FIG. 6is an interaction diagram illustrating a method600, in accordance with another example embodiment, of dynamically altering a user interface. In this method600, a mobile device604, such as a smartphone, may contain a sensor separate from a vehicle602itself, which contains a dynamic auction parameter module606and a user interface presentation module608. At operation610, the mobile device604sends sensor information to the dynamic auction parameter module606. At operation612, a safety level score is calculated from sensor information. At operation614, an auction parameter is dynamically modified based on the safety level score which alters a selectable option in a user interface. At operation616, the dynamic auction parameter module606sends the modified user interface to the user interface presentation module608, which at operation618presents the modified user interface.

FIG. 7is an interaction diagram illustrating a method700, in accordance with another example embodiment, of dynamically altering a user interface. In this method700, a vehicle702may contain a sensor704and a user interface presentation module706. A dynamic auction parameter module708may be located elsewhere, such as on a server. At operation710, the sensor704may send sensor information to the user interface presentation module706, which at operation712may communicate the sensor information to the dynamic auction parameter module708. This may be communicated by, for example, a wireless communications standard such as 3G, 4G, LTE, Wi-Fi, or any other wireless communication standard. At operation714, a safety level score is calculated from sensor information. At operation716, an auction parameter is dynamically modified based on the safety level score, thus changing a selectable option in a user interface. At operation718, the dynamic auction parameter module708sends the modified user interface to the user interface presentation module706, which at operation720presents the modified user interface.

FIG. 8is a flow diagram illustrating a method800, in accordance with an example embodiment, of dynamically altering a user interface. At operation802, a user interface is provided to a user in a vehicle. The user interface includes a selectable option (the selectable option is based in part on an auction parameter) to wirelessly place a bid on an electronic auction. At operation804, a safety level score for the vehicle is determined. At operation806, the auction parameter is dynamically altered based on the safety level score resulting in a change to the selectable option.

The example computer system900includes a processor902(e.g., a central processing unit (CPU), a graphics processing unit (GPU), or both), a main memory904and a static memory906, which communicate with each other via a bus908. The computer system900may further include a video display unit910(e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). The computer system900also includes an alphanumeric input device912(e.g., a keyboard), a cursor control device914(e.g., a mouse), a drive unit916, a signal generation device918(e.g., a speaker), and a network interface device920.

The drive unit916includes a computer-readable medium922on which is stored one or more sets of instructions924(e.g., software) embodying any one or more of the methodologies or functions described herein. The instructions924may also reside, completely or at least partially, within the main memory904and/or within the processor902during execution thereof by the computer system900, with the main memory904and the processor902also constituting machine-readable media. The instructions924may be further transmitted or received over a network926via the network interface device920.

Although the inventive concepts have been described with reference to specific example embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the inventive concepts. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.