AUCTION BIDDING SYSTEM FOR WIRELESS INTERNET ENABLED TELEPHONES
RELATED APPLICATION
[0001] Priority for this application is based on U.S. provisional application 60/358,687 filed on February 21, 2002.
TECHNICAL FIELD
[0002] The present invention relates generally to remote electronic financial negotiations on a wireless communication system such as wireless telephones in communication with a computer network, and more particularly to a system for participating in auctions from Internet enabled wireless telephones.
BACKGROUND OF THE INVENTION
[0003] Internet auction web-sites, such as eBay , are known to hold online auctions or electronic auctions. To link to the internet and participate in these auctions, a computer terminal must have a communication device such as a modem, integrated services digital network (ISDN) adapter or any other communication system/device that is used to communicate electronically, through wires, with an Internet service provider (ISP). With the aid of a web browser and navigation software, this permits the user's computer to download information from other computers linked to the Internet including web pages with options for participating in, or monitoring, an auction provided by the auctioneer's website computer or server. Conventionally, the user or bidder links to the auction web site from the computer terminal with a wired communication device (e.g. modem or ISDN adapter), registers to be a purchaser/bidder, views objects or products for sale, and submits bids via the web browser and web navigator to the auction website or auction server. The bidder can then monitor the auction web site to see if his bid was outbid by another bidder, and then rebid to recapture the lead.
[0004] For people who desire to monitor or bid on the online auctions while they are traveling, they are not always located where an Internet enabled connection for a computer terminal is available. This is important because, as is known with auctions, it can be important to make a bid or to recapture the lead within a short amount of time.
[0005] Many people carry wireless cellular telephones. A growing segment of these cell phones are Internet-capable. These phones, however, cannot access typical web sites on the Internet. They understand special languages, such as WML (Wireless Markup Language) for one example. Most sites on the Internet, however, are built for desktop/laptop computers using a markup language called HTML instead, making the cellular phones incapable of communicating with the Internet with the full range of functions of a computer desktop or laptop.
[0006] To overcome this problem, some wireless communication networks provide a wireless e-mail communication to the user's wireless device so that a message can be received on Internet or e-mail enabled ("web" enabled) devices such as a palm pilot (PDA or personal digital assistant, "blackberry", or web/Internet enabled (WAP (Web Access Protocol) enabled) cellular telephones. However, these systems only provide the ability to monitor the auction. In other words, the user will receive a message that reports the latest bid or whether or not they still have the highest bid, but no way exists to enter a new bid if the user is informed that he has been outbid. The user still must run to the nearest available web-enabled computer device to gain access to the Internet and to rebid.
SUMMARY OF THE INVENTION
[0007] In one aspect of the present invention, it is possible to participate fully in an auction, including monitoring and bidding in the auction, from an Internet-enabled wireless phone. More specifically, a system for bidding in an auction using an Internet enabled wireless telephone includes an auction server maintaining an auction web site for operating an auction over a network and receiving and transmitting information including prices for objects offered for sale in the auction. A rebidding server is also provided for receiving a new bid from the telephone, communicating with the auction server and submitting the bid to the auction site.
[0008] In another aspect of the present invention, a telephone in communication with a rebidding server has a numerical pad for inputting numbers and a display. The telephone is configured for receiving communications from, and sending communications back to, the rebidding server. The communications from the rebidding server provide bidding options for bidding in an auction, and the bidding options are displayed on the display of the telephone. The communications to the rebidding server include a selected new bid.
[0009] In yet a further aspect of the invention, an auction bidding system has a plurality of wireless telephones for the wireless transmission and reception of signals, each telephone has a display. A wide area network includes an auction site configured for hosting an auction among a plurality of participants including participants associated with respective telephones. The auction site accepts bids and rebids of at least one object at auction. A rebid server is coupled to the wide area network to be in communication with the auction site. The rebid server receives messages from and transmits messages to the auction site concerning bids for the object. The rebid server generates a plurality of potential rebids responsive to a message from the auction site that a participant's initial bid has been outbid. The rebid server also transmits the plurality of potential rebids to the telephone of the last said participant. The display of the last telephone displays the plurality of potential rebids so that the last participant can choose one or none of the potential rebids as a rebid to be submitted to the auction site. The chosen bid is transmitted through the telephone to the rebid server. Finally, the rebid server relays the choice of the last participant to the auction site to register a rebid for the object at auction.
BRIEF DESCRIPTION OF THE DRAWINGS
[0010] The above mentioned and other features of the present invention and the manner of obtaining them will be apparent, and the invention itself will be best understood by reference to the following description of the preferred embodiment of the invention in conjunction with the following drawings, in which:
[0011] FIG. 1 is a schematic diagram showing a communications/computer network of the bidding system in accordance with the present invention;
[0012] FIG. 2 is a flow chart describing the major steps in the bidding system of the present invention;
[0013] FIGs. 3A-3F is a flow chart describing notification parts of the bidding system of the present invention;
[0014] FIGs. 4A-4B is another flow chart describing rebidding parts of the bidding system of the present invention;
[0015] FIG. 5 is a simplified front face drawing of a web-enabled wireless telephone with a display showing options for participating in an Internet auction;
[0016] FIG. 6 is a sample of an administrative account page for establishing a user's profile with the bidding system of the present invention; and
[0017] FIG. 7 is a schematic diagram of tables of a database for using the bidding system of the present invention.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
[0018] Referring to FIG. 1, an auction bidding system generally indicated at 10 has a computer-communications network 12 that permits an Internet auction site 14 and a Wireless Auction Rebid Server(s) (hereinafter the "rebid server") 16 to communicate, through the Internet, World Wide Web or other WAN, with a user's Internet enabled wireless devices, such as wireless phones 18, 20 and 22, and a user's computer terminal 24.
[0019] Referring to FIG. 2, the computer network 12 is used to perform three basic phases of the process required for using the wireless auction rebidding system 10. In the first phase (step 100), the user signs up for the rebidding service by providing and sending information from the computer terminal 24 to the rebid server 16 so that the rebid server can establish a profile for the user. The rebid server 16 saves the profile information on the database 26 for later use. In the second phase (step 102), the network 12 permits the auction site or server 14 to send e-mail messages to the rebid server 16 with auction information to notify the user that he has been outbid (the latest bid by another user is higher than the current user's bid). The rebid server 16 is able to transmit notification of the outbid or other auction information to any of the Internet enabled phones 18, 20, 22 and
provide a display of options for rebidding. In step 104, the user can then immediately interact and transmit a rebid from his phone 18, 20 or 22 in real time, which is transmitted back to the rebid server 16, which in turn, acts on behalf of the user and forwards the rebid message or data to the auction site 14.
[0020] Referring again to FIG. 1, the User's or Bidder's computer terminal 24 should have a processor, ISDN adapter or modem (or other similar communication device or system), OS system and navigation software for access to the Internet. At a minimum, the terminal 24 must have a browser for downloading web pages (or analogous processing), and preferably includes the ability to fill in identifying information on an electronic registration form, and transmit the form and other information and data, back to the auction server 14 and rebid server 16 through the Internet. The computer terminal can be a desktop, laptop, or any other computer that has full Internet capabilities such as being able to download, view and transmit information using web pages.
[0021] The auction server 14 hosts the Internet auction web site, such as eBay®, or is one of the other known auction sites, or any other auction site that places articles or services up for bid. The auction server 14 is able to transmit email messages regarding auction information and the latest bids to the rebid server 16.
[0022] The rebid server 16 should be powerful enough to handle the community of users (i.e. the total number of users registered with the rebid server). It can be a general purpose computer with a processor programmed to <be a specific purpose computer. It will also be appreciated that the physical location of the rebid server 16 is not limited. Thus, while the rebid server is shown to be a completely separate entity from the auction site, inherent in the invention is that the rebid server could also be a part of the auction site and even a part of the auction server.
[0023] The pertinent number of users is the maximum number of simultaneous users at any given time. Generally, this number can be computed assuming a normal distribution of user accesses. The number of simultaneous "sessions" is usually less than 5% of the user community. This percentage sometimes drops to under 1% depending on day of the week, time of day, and when auctions typically start and end.
[0024] Each live session will use approximately 256k of memory, and an 800 MHz Intel processor will be enough computing power for a minimum of 500 live sessions. Data bandwidth between the wireless phone and the server is minimal compared to HTML browser based sessions (desktop). Each interaction between the phone and the server will typically involve 1000 to 1500 bytes of data. No strict requirements exist for the operating system in general, although Windows 2000 has been found to be satisfactory.
[0025] The software needed to perform the service on the rebid server 16 uses the HTTP protocol to communicate to the wireless phones 18, 20, 22. At the time of writing this application, this is the typical transport mechanism used by Internet-capable wireless phones. The data sent between the phone and the server can be encrypted using SSL (Secure Socket Layer) technology.
[0026] The rebid server 16 also communicates with the database 26 for storing and retrieving user profiles. The database management is explained further below.
[0027] Wireless Internet enabled phones 18 and 20 display text using a WML (Wireless Markup Language) browser, such as that provided by OpenWave®in the United States. Other wireless telephone technology companies such as Nokia®also supply such software for their phones. The carrier (company providing the wireless network and gateway between the phone and the Internet) must also support "push technology" for interactive messages (messages with URLs).
[0028] Some phones are WML based phones 20 that allow the text of a web page to be displayed on cell phones. WML phones 20 may have different protocols and may not accept WAP messages. Other Internet enabled phones are WAP (Wireless Application Protocol) phones 18, which is one example of a specific, and the most popular, protocol for WML based phones. Still another type of Internet enabled phone is an SMS phone 22. The SMS phones 22 can only display short text messages (such as 100 characters). These SMS phones, however, are still considered Internet-enabled phones because they can display the message based on WML and support "push" technology that permits a working-clickable URL to be embedded in the message. Other forms of SMS are not compatible with the "push" technology.
[0029] Referring to FIGs. 1-2, in order to participate in an auction from a wireless phone, the user must first register or "sign up" with the rebid server 16 (step 100). This is preferably accomplished while the user accesses the Internet through computer terminal 24. Through choices provided on a web site, the user is led to an electronic form for entering and then transmitting his information to the rebid server 16 and database 26. It will be appreciated, that while not preferred, the user could provide his sign-up information by other means such as by telephone (voice to voice, DTMF to computer, or voice to computer), mailing a (hard copy) form, or any other way of providing the rebid information so that it can be placed on the rebid server 16 and database 26.
[0030] The electronic form preferably asks for at least the following information which is necessary for the user to participate in the wireless services of system 10:
(a) Name of the user;
(b) Auction username;
(c) Mobile number;
(d) Carrier and service plan;
(e) Email address; and
(f) password.
[0031] The auction username merely means a typical user name, nickname or alias that is used for identification and to match to a password either chosen by the user or assigned by the rebid server.
[0032] The subscriber ID for a cell phone is required for the rebid server to be able to identify the user's phone. In the case of Nokia® gateways, the subscriber ID is the mobile [phone] number. With OpenWave® gateways, the subscriber ID is a machine generated ID that is not the same as the mobile number.
[0033] The subscriber ID can be determined by a number of ways if the user does not already know his ID number. First, some phones allow the user to determine the subscriber ID by using a certain sequence of numbers on the phone or by choosing options on various menus on the phones. Other phones require the user to contact the carrier to ask for the subscriber number.
[0034] Yet another way to determine the subscriber ID is to send the user an SMS message with a URL embedded in the message. The URL will contain the base URL for the rebid application as well as a query string that contains information such as the auction ID and possibly the user's auction username. Many carriers will allow the phone to "click" on the link. The URL will take them to the rebid server 16 that will detect their subscriber ID (typically sent in HTTP request headers) and ask the user for their username. The rebid server 16 will then associate the subscriber ID with the username. This data is stored in the user's profile in the database 26.
[0035] The user also has a couple of other options. If the user so chooses, the rebid server can encrypt and store the user's auction password in the rebid database 26. This is a useful feature that allows the user to bypass the tedious step of typing in their auction password on their phone when they want to rebid on an auction.
[0036] Another security option or feature is really an option for the rebid server 16 rather than the user. The rebid server 16 may require the user to type in a mobile PIN (numeric), either initially provided by the rebid server 16 or the user, as an extra step to authenticate the user's ID and to cross reference it with the ID from the auction server 14 The two security options, the PIN and password storage, can be used separately or together.
[0037] The user can also optionally enter in a blackout period for wireless notifications. If the user is outbid during this daily time period, the rebid server 16 will queue the notification until the blackout period has passed.
[0038] Once the user has submitted all the necessary information, it is stored on database 26 and a profile is activated. The auction site 14 is notified by the rebid server 16 that outbid email messages should be directed to the rebid server.
[0039] Referring to FIGs. 2, 3A-3F, once the user has successfully registered with the auction rebidding service or server 16 (step 100), the auction system 10 can send messages to the user's phone 18, 20 or 22 to notify the user of further auction activity (step 102). Usually the user will enter a bid in an online auction while he is accessing information directly from the auction site 14 from his computer terminal 24 and then instructs the auction site 14 to notify him, via email to the rebid server 16, on his wireless phone 18, 20 or 22 if he has been outbid (step 200). Alternatively, however, the user may just instruct
the auction site to notify him of the latest bid in an auction he wishes to monitor but never entered a first bid. Either way, the rebid server 16 receives the updates or outbid notifications (or alerts) from the auction site 14 via an email message from the auction site 14(step 202).
[0040] The email message indicates the user's auction username (such as the user's email alias), the user's auction ID or password, the auction description, and the new auction price. The rebid server 16 receives the message via standard email (SMTP) ports, and then obtains the data in the message by extraction programs readily available or easily created by those in the art. These programs may or may not require the email to be in a certain format or have defined fields. The rebid server 16 then reads the message (step 204), and searches the database 26 using the auction username (email alias) to look up the user's profile (step 206).
[0041] If the user's profile or account is not valid, the event is logged in a history table (711 on FIG. 7) in the database, and the message is discarded (steps 208, 210, 212). If the account is valid, the blackout period of the user's profile is inspected (steps 208, 214). If the current time is within the daily blackout period, then the outbid notification is queued in a database table for later processing (step 216). The queued notification will be processed when the end of the blackout period is reached (step 218).
[0042] The user's profile is further inspected to determine if the user's phone is an Internet-enabled phone (step 220). This information comes from a field in the user's profile in table 701 as well a set of carrier/message tables (706, 709 on FIG. 7). If the user's phone is not Internet-enabled, then the rebid server 16 will send a non-interactive outbid message to the user. The user, however, will not be able to wirelessly rebid on the auction.
[0043] Referring to FIG. 3B, two options are provided for sending non-interactive outbid message to the user. The best way to send the message to the user's mobile phone is via an SMS message. These SMS phones cannot establish Internet sessions because they do not have "push" technology/software that initiates the sessions with embedded URLs in a transmitted message.
[0044] The delivery details may differ among carriers. Some carriers require users to use their SMS gateways directly while other carriers allow messages to be delivered to their SMTP gateways. SMTP messages are governed by standard number RFC2821. The rebid server 16 searches the database 26 for the user's mobile number, and determines the delivery requirements by searching for, if one exists, the carrier (step 222). The SMS message is then created with the outbid information (step 224), and the an SMS alert is logged to the user in the database 26 (step 226).
[0045] If the user's mobile number/carrier is not stored in the profile, then the rebid server 16 will attempt to send the outbid message to the user's email address if it is present in the profile (step 228). If neither a mobile number/carrier nor an email address is present in the profile, a notification failure is logged in the database 26 (step 230). If the email address is present, a message is sent with the outbid information (step 232), and an email message to the user is logged (step 234).
[0046] Referring to FIG. 3C, if the user does have an Internet-enabled phone, the database 26 is searched for the subscriber ID for that phone (step 236). If the subscriber ID cannot be found, the rebid server will attempt to send a non-interactive outbid message as described previously (FIG. 3B).
[0047] Once the rebid server 16 finds the subscriber ID for the user, it is determined if the phone supports WAP, WML or SMS (Steps 238, 240, 241). The best way is to use WAP notifications. The use of WML notifications, which uses a different protocol is the next preferred way, followed by using SMS with an embedded URL. The rebid server can determine which method to use based upon information in the user's profile (carrier and service plan from tables 706, 709 on FIG. 7).
[0048] In the U.S., there are two primary providers of WAP technology: OpenWave®and Nokia. The vast majority of the carriers use OpenWave®for their phone browser and WAP gateway. Both companies have SDKs (Software Developer's Kit) available for delivering WAP and WML notifications. Typically, the information needed to send a notification is the gateway host name, the text message, the URL to be clicked on and the phone's subscriber ID.
[0049] Referring to FIG. 3D, if the phone is a WAP phone 18 that will accept WAP notifications, then a WAP message is constructed in two parts. The first part consists of the text message. This is built using information about the actions obtained from the e- mail notification message from the auction site 14 including the auction ID, the auction description and the new auction price (steps 242, 244). The second part is a customized URL assigned by the rebid server 16 that will allow the user to rebid on the auction through the rebid server (step 246). The two parts are combined and sent out to the carrier's wireless gateway 28 (step 248). The rebid server 16 will receive a receipt from the carrier's wireless gateway 28 (Step 250). This receipt, along with other information, will be logged in the database 26 (step 252).
[0050] Referring to FIG. 3E, if the phone is a WML phone 20 that does not accept WAP notifications but still accept WML notifications, then a similar process is followed. The text part of the WML message is created using information about the auction (the auction ID, the auction description and the new auction price) (step 254, 256). A URL is also constructed to allow the user to rebid on the auction (step 258). These two parts are combined and sent out to a WML carrier gateway 30 (Step 260). This gateway 30 for WML notifications does not return a notification receipt. The transaction is logged in the database (step 262).
[0051] Referring to FIG. 3F, even if the phone supports neither WAP nor WML notification, the rebidding system still works with an SMS phone 22 that supports SMS messages with embedded URLs. The outbid information is first collected as with the other two phone systems (step 264), and a URL is constructed (step 266). Then a custom message is created (step 268). This message contains (as a single body) the description of the auction and the URL for rebidding. The message is sent out through the carrier's SMS gateway 32, and typically this gateway 32 is visible as an SMTP (mail) gateway (step 270). If successful, a successful SMS message transaction is logged (step 272).
[0052] Finally, if none of the above notification options is available, then the rebid server 16 attempts to send out a non-interactive outbid message to the user as described above (FIG. 3B).
[0053] Referring to FIGs. 4A-4B, once the notification is received on the user's phone 18, 20 or 22 (step 300), the user will be able to view the message and a hyperlink that can be "clicked." (step 302). The link is an embedded URL in the message.
[0054] If the user clicks on the link, the URL will launch the mini-browser on the phone, connect the phone with the rebid server 16 and begin interacting with a wireless auction rebid application that resides on the rebid server 16 (step 304).
[0055] The rebid server 16 and the rebid application creates a wireless session for this interaction with the user (step 306). The URL retrieved from the user's phone will contain information indicating the subscriber ID, auction ID and the auction username of the user in the query string. The rebid server 16 will query the database 26 for the user's profile (step 308). If the account is valid, then the authentication options in the profile are inspected (step 310). If the user has a mobile PIN, then a screen will be sent back to the phone asking the user to type in their mobile PIN on the phone (step 312). This PIN is compared to the mobile PIN stored in the user's profile (step 314). If they do not match then the user is sent an error message and is denied access (step 316). If they match, the process continues with searching for the user's auction password in the profile (step 318).
[0056] If the user's profile does not have the auction password, then a screen will be sent back to the user's phone asking for the auction password (step 320). This password, combined with the user's auction username, is then used to authenticate the user on the actual auction site 14 (step 322, 324). If the authentication fails, the user is sent an error message and access is denied (step 326). If authentication succeeds, the process continues.
[0057] At this point, the rebid server 16 will take the auction ID (provided from the phone along with the URL) and query the auction site for the details of the auction (step 328). If the auction is not valid or is no longer active, the user is informed of this and the rebidding process stops (step 330). Otherwise, the rebid server 16 queries the auction site for the auction price or minimum auction bid (step 332).
[0058] The rebid application at the rebid server 16 takes the minimum bid and calculates two other optional bids. These are based upon customizable percentages of the minimum bid (i.e. min. bid + x% and min. bid + y%). For example, if the minimum bid on an
auction is $100 and the customizable rebid percentages were x = 10% and y = 20% then the three optional bids would be $100, $110, and $120.
[0059] Referring to FIGs. 4B and 5, a screen showing a list 504 of four rebid choices 508, 510, 512, 514 are transmitted back to the user's phone as shown on the display 502 of phone 500 for example (step 334). The list 504 may or may not have a title or other caption 506. It will also be appreciated that the bid options may be shown on the display 502 one at a time rather than in an entire list or any other way that conveys the same information to the user for the user to choose among the options.
[0060] The rebid option list 504 includes the three bid choices mentioned previously and a custom bid price 514. The user may choose one of the three previously established bids 508, 510, 512 or the user may choose to enter his own custom bid 514. For the latter, the user is provided a field on the display 502 to enter the exact amount to place as a new bid. The new bid is then transmitted to the rebid server 16, and the new bid amount is determined (step 336).
[0061] The rebid server 16 then interacts with the auction site 14 to place the new bid for the user (step 338). After the new bid has been placed, the bid results are received from the auction site 14 and then forwarded to the user's phone (step 340). If the user is the new auction leader, then the rebidding process is over. If the user did not succeed in becoming the bid leader, the user will be given the option of rebidding (step 342) and the process returns to step 334.
Rebidding Application
[0062] The rebidding mobile application executed by the rebid server 16 provides two major services. The first is to interface with the auction site 14 and the second is to produce the WML screens that are sent back to the phone for display.
[0063] The following is a sample mobile application definition.
GSML
<GSML NAME="WirelessAuction" VERSION="2" >
<PAGE NAME="Start" SERNICE="ItemStatusSvc">
<ASSIGΝ VAR="ItemNo" VALUE="1063971697" />
<ASSIGN VAR="buyernameM VALUE="IPBuyers" /> <ASSIGN VAR="buyerpassword" VALUE="inphonic" /> <GOTO DEST=" RebidPrompt" /> </PAGE>
<PAGE NAME="Done" DEST="Done">
<DISPLAY>
Thanks for using the wireless auction.
</DISPLAY> </PAGE>
<PAGE NAME="RebidPrompt">
<CHOICE VAR="RebidChoice"> Rebid Options
<CE DEST="MinBidPageM>$%MinBid% (Min Bid)</CE> <CE DEST="MinBidPlusl OPage">$%MinBidPlusl 0%</CE> <CE DEST="MinBidPlus20Page">$%MinBidPlus20%</CE> <CE DEST="CustomBidPage">Custom Bid</CE> <CE DEST="MainMenu">Main Menu</CE> </CHOICE>
</PAGE>
<PAGE NAME="MinBidPageM>
<ASSIGN VAR="NewBid" VALUE="%MinBid%"/>
<GOTO DEST="ConfirmRebid"/> </PAGE>
<PAGE NAME="MinBidPluslOPage">
<ASSIGN VAR="NewBid" VALUE="%MinBidPluslO%"/>
<GOTO DEST="ConfirmRebid > </PAGE>
<PAGE NAME="MinBidPlus20PageM>
<ASSIGN VAR="NewBid" VALUE="%MinBidPlus20%'7> <GOTO DEST="ConfirmRebid7> </PAGE>
<PAGE NAME="CustomBidPage" DEST="ConfirmRebid > <ASSIGN VAR="NewBid" VALUE="%MinBid% > <ENTRY VAR="NewBid">
Bid Amount: </ENTRY>
</PAGE>
<PAGE NAME=*'ConfirmRebid"> <CHOICE VAR="Confirm">
Place bid of %NewBid%? <CE DEST="Rebid">Yes</CE> <CE DEST="RebidPrompt">No</CE> </CHOICE> </PAGE>
<PAGE NAME="Rebid" SERVICE="RebidSvc" DEST="Done"> <DISPLAY>
%BidResultl%<BR/> %BidResult2%<BR/xBR/> Current Bid: %CurrentBid%<BR/> Max Bid: %MaxBid% </DISPLAY> </PAGE> </GSML> GSIDL
<GSIDL NAME="WirelessAuction" VERSION="2" OBJMODEL="xpdom" COOKIESTATE="false" >
<SERVICE NAME="ItemStatusSvc" URL=M%theURL%" METHOD="GET" INPUT="ItemStatusInputM INTERFACECLASS="auctionutil"
OUTPUT='TtemStatusOutputπ />
<BINDINGNAME="ItemStatusInput" TYPE^'TNPUT" >
<VARIABLE NAME="theURL" VALUE="http://www.auctionsite.com/?ViewItem&item=%ItemNo%" USAGE="INTERNAL" /> </BINDING>
<BINDING NAME-,TtemStatusOutput" TYPE="OUTPUT" > <VARIABLE NAME="Title" TYPE="String" NULLOK="TRUE"
REFERENCE=7descendant::body[l]/table[2]/tbody[l]/tr[l]/td[l]/center[l]/table[l ]/tbody[l]/tr[l]/td[l]/table[l]/tbody[l]/tr[l]/td[l]/font[l]/b[l]/text()'7>
<VARIABLE NAME="Price" TYPE="String" NULLOK="TRUE"
REFERENCE=7descendant::body[l]/center[2]/table[l]/tbody[l]/tr[l]/td[2]/table[l ]/tbody[l]/tr[l]/td[2]/b[l]/text()'7>
<VARIABLE NAME=" Quantity" TYPE="String" NULLOK="TRUE"
REFERENCE=7descendant::body[l]/center[2]/table[l]/tbody[l]/tr[l]/td[2]/table[l ]/tbody[l]/tr[2]/td[2]/b[l]/text()'7>
<VARIABLE NAME=*'TimeLeft" TYPE="String" NULLOK="TRUE"
REFERENCE=7descendant::body[l]/center[2]/table[l]/tbody[l]/tr[l]/td[2]/table[l ]/tbody[l]/tr[3]/td[2]/b[l]/text()" />
<VARIABLE NAME="MinBidFull" TYPE="String" NULLOK="TRUE"
REFERENCE=7descendant::body[l]/table[5]/tbody[l]/tr[l]/td[l]/table[l]/tbody[l] /fr[l]/td[l]/form[l]/table[l]/tbody[l]/fr[l]/td[l]/table[l]/tbody[l]/tr[5]/td[2]/font[l]/i[l]/te xt()'7>
</BINDING>
<SERVICE NAME="RebidSvc" ACTION="RebidAction"
OUTPUT="RebidOutput" />
<ACTION NAME="RebidAction" > <AE TYPE="TEXT"
VALUE="%NewBid%"
REFERENCE=7descendant::body[l]/table[5]/tbody[l]/tr[l]/td[l]/table[l]/tbody[l] /tr[l]/td[l]/form[l]/table[l]/tbody[l]/tr[l]/td[l]/table[l]/tbody[l]/tr[4]/td[4]/input[l]/@ref h'7>
<AE TYPE="CLICK" WAIT="TRUE"
REFERENCE=7descendant::body[l]/table[5]/tbody[l]/tr[l]/td[l]/table[l]/tbody[l] /tr[l]/td[l]/form[l]/table[l]/tbody[l]/tr[l]/td[l]/table[l]/tbody[l]/tr[6]/td[l]/input[l]/@ref h" />
</ACTION>
<BINDING NAME="RebidOutput" TYPE="OUTPUT" >
<CONDITION TYPE="SuccessM SERVICE="Rebid2Svc7> </BINDING>
<SERVICE NAME="Rebid2Svc" ACTION="Rebid2Action"
OUTPUT=*'Rebid2Output" />
<ACTION NAME="Rebid2Action" > <AE TYPE="TEXT"
VALUE="%buyername%"
REFERENCE=7descendant::body[l]/p[4]/form[l]/p[l]/table[l]/tbody[l]/tr[l]/td[l ]/table[l]/tbody[l]/tr[l]/td[l]/table[l]/tbody[l]/tr[l]/td[2]/input[l]/@refh'7>
<AE TYPE="TEXT"
VALUE="%buyerpassword%"
REFERENCE=7descendant::body[l]/p[4]/form[l]/p[l]/table[l]/tbody[l]/tr[l]/td[l ]/table[l]/tbody[l]/tr[l]/td[l]/table[l]/tbody[l]/tr[2]/td[2]/input[l]/@refh'7>
<AE TYPE="CLICK" WAIT="TRUE"
REFERENCE=7descendant::body[l]/p[4]/form[l]/p[4]/input[l]/@refh" /> </ACTION>
<BINDING NAME="Rebid2Output" TYPE="OUTPUT" > <VARIABLE NAME="BidResultl "
TYPE="String"
NULLOK^'TRUE"
REFERENCE=7descendant: :body[l]/font[l]/b[l]/text()" /> <VARIABLE NAME="BidResult2"
TYPE="String"
NULLOK="TRUE"
REFERENCE=7descendant::body[l]/font[2]/b[l]/text()'7> <VARIABLE NAME="CurrentBid"
TYPE="String"
NULLOK="TRUE"
REFERENCE=7descendant::body[l]/table[2]/tbody[l]/tr[l]/td[4]/text()'7>
<VARIABLE NAME="MaxBid" TYPE="String" NULLOK="TRUE"
REFERENCE=7descendant::body[l]/table[2]/tbody[l]/tr[2]/td[4]/text()'7> </BINDING> </GSIDL>
[0064] The application is described using an XML dialect called GSML/GSIDL. The GSML portion of the mobile application describes the user interface that the mobile phone user would see. This description is generic in nature meaning it is not specific to any one mobile device. The rebid server 16 will take the final screen to be sent to the mobile device and convert it to the markup language that the device is expecting (WML in the case of phones).
[0065] The GSIDL portion of the mobile application describes how to integrate with the auction site 14. This can typically be accomplished in one of three ways:
• Interact with the HTML web application at the auction server 14;
• Interact with the auction site 14 via XML; and
• Use APIs/SDKs provided by the auction site.
[0066] The rebid server 16 supports all three methods separately and in conjunction with one another. The GSIDL found in the sample mobile application above uses the first method - interacting with the HTML web application of the auction site 14. Because many Internet auction sites do not have any other means of interaction, interacting via the HTML web application is important. This method is sometimes referred to as screen scraping. Here, however, the rebid server 16 and rebid application go beyond simple screen scraping and allows a mobile application to fully describe how a user would interact with an HTML web application and then mimics that on the user's behalf. In other words, the application permits the rebid server 16 to interact with the auction site 14 just as the user would from his computer terminal 24.
[0067] The basic flow of the sample mobile application is as follows:
1. Collect information about the auction (request an HTML page from auction site)
2. Calculate the rebid options
3. Present the user with the rebid choices (4 in total)
4. If custom bid is selected, then ask user for rebid amount
5. Confirm that the user wants to place the bid
6. If so, place bid on auction site through HTML web application using the user's auction username, password, the auction ID, and the rebid amount
7. Display results of the bid attempt
Database Table Structure
[0068] Referring to FIG. 7, the database 26 used by the rebid server 16 can contain a number of different pieces of information. This depends on the functionality of the server software used. In the illustrated embodiment, the rebid server software uses a complex schema of tables 700 described as follows:
Table 701 : Users - the users or user IDs;
Table 702: Contacts - contact information including addresses and email address;
Table 703: Companies - companies associated with a number of users;
Table 704: Groups - groups which are typically defined by a company (i.e. managers, sales, engineers) so that each group can have different mobile applications;
Table 705: Providers - the providers of the rebidding service such as the companies mentioned above but it also includes entities providing the service to a number of companies;
Table 706: Carriers - the wireless carriers (Nextel, Voicestream, etc.) and the pertinent information for each such as name, gateway and message type ID;
Table 707:Devices - Subscriber IDs listed in association with users;
Table 708: Messages - this list keeps track of all messages sent out to the phones/subscribers and all messages received from the auction site 14;
Table 709: Message Types - defines the type of message that is unsupported by the user's phone ( Internet enabled SMS, non-enabled SMS, WAP, WML, other);
Table 710: Sessions - table of subscriber sessions that shows what the subscriber/user did each time they used the service;
Table 711 : Usage - log table that stores each mobile page that each user viewed during each session;
Table 712: Privileges - this table associates capabilities or security levels with users (i.e. administrators or normal users);
Table 713: System - a table for storing system variables and values used by the rebid server 16;
Table 714: Scenarios - list of mobile applications including storage of the XML code;
Table 715: User Selected Scenarios - storage of user's preferences for optional scenarios. Options may be provided on a group basis;
Table 716: Variables - a table defining persistent variables for user mobile scenarios;
Table 717: Relationships - table for internal associations of items on different tables, such as Privileges to an associated user for example;
Table 718: Variable Values - similar to the relationship table, it associates variable values or variable definitions to users;
Table 719: OID Types - working in conjunction with the relationship table, this table defines codes for associating entities on the table to each other; and
Table 720: Cookies - a system table with records for each user that are cookie strings used to drive the Internet/web based sessions with the auction site 14 on behalf of the user;
[0069] In this database 26, the user profile is spread across several tables including the User, Relationship, and Variable Values tables. The typical information needed for a user is as follows:
Name;
Auction username;
Auction password (optional);
Mobile PIN (optional);
Mobile number;
Carrier;
Service Plan / Delivery Mechanism (WAP/WML/SMS);
Subscriber ID; and
• Authentication Mechanism (combination of PIN / auction password).
[0070] Referring to FIG. 6, a sample administration account page 600 for a user profile is shown with fields 602-620 for displaying the information the user provided or was otherwise obtained for the profile. The administrator can use this web page to change or enter further information regarding the user.
[0071] The advantages of the present financial transaction system are now apparent. The auction system 10 has a user's Internet enabled wireless phone 18, 20 or 22 that displays options for rebidding in an auction. The desired bid is transmitted from the phone 18, 20 or 22 to a rebid server 16 which provides the bid to an auction site 14 for the user. With this structure, the user can enter a bid in an auction at any time and any place as long as the user has his phone with him.
[0072] While various embodiments of the present invention have been described, it should be understood that other modifications and alternatives can be made without departing from the spirit and scope of the invention, which should be determined from the appended claims.