WO2001044999A2 - Method of doing business - Google Patents

Method of doing business Download PDF

Info

Publication number
WO2001044999A2
WO2001044999A2 PCT/IL2000/000834 IL0000834W WO0144999A2 WO 2001044999 A2 WO2001044999 A2 WO 2001044999A2 IL 0000834 W IL0000834 W IL 0000834W WO 0144999 A2 WO0144999 A2 WO 0144999A2
Authority
WO
WIPO (PCT)
Prior art keywords
client
service
package
clients
server
Prior art date
Application number
PCT/IL2000/000834
Other languages
French (fr)
Other versions
WO2001044999A8 (en
Inventor
Gad Gonen
Moti Suess
Original Assignee
Fastbeat.Com Limited
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fastbeat.Com Limited filed Critical Fastbeat.Com Limited
Priority to AU18817/01A priority Critical patent/AU1881701A/en
Publication of WO2001044999A2 publication Critical patent/WO2001044999A2/en
Publication of WO2001044999A8 publication Critical patent/WO2001044999A8/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00Commerce
    • G06Q30/06Buying, selling or leasing transactions

Definitions

  • the present invention is in the field of methods of doing business. More specifically, the invention relates to electronic contract applications using electronic methods.
  • a consumer When wishing to acquire services or products, a consumer often finds that, due to the large number of variables and the large selection of services and products, the amount of information facing him is overwhelming. In these situations, the consumer often makes use of a sales agent.
  • the role of the agent is to match the particular financial situation, preferences and desires of the consumer, with the available services and products offered by the various providers.
  • the agent presents information relating to the goods or services of interest to the consumer, assists the customer in making a decision, closes a transaction and accepts payment.
  • the selling of services and products through an agent is a labor-intensive process. It is therefore desirable to automate some of the functions presently performed by sales agents.
  • the present invention provides a method and system for selling services or products by means of an interactive system capable of performing functions of a sales agent.
  • communication between sellers and users on the one hand and the system, on the other, is conducted using an electronic network and central controller such as a world-wide web interface.
  • sellers input one or more sales-offers into the system.
  • Buyers access the system to obtain information relating to sales-offers of interest of them that have been inputted by sellers.
  • the system queries the buyer for input data concerning the desired services or products.
  • the system receives the input data and searches an inventory database of sales-offers for the availability of the desired services or products.
  • the system then provides to the buyer information relating to services or products satisfying the buyer's requirements, together with pricing information for the services or products.
  • the buyer selects the services or products he wishes to purchase and the system accepts payment for the services or products selected by the buyer.
  • Various payment methods may be utilized, including credit cards, personal checks, electronic funds transfer, debit cards, and digital cash.
  • the system provides to the buyer a code indicative of the completed transaction.
  • the user subsequently presents the code to the seller whose sales-offer he has selected in order to obtain the service or product already paid for from the seller.
  • the buyer presents the code to the seller in an electronic form, for example by contacting the seller by telephone and pressing the code on the telephone handset.
  • the invention can also be practiced in off-line embodiments.
  • buyers and sellers may communicate with the central controller via telephone, facsimile, postal mail, or another off-line communication tool.
  • sellers may use telephones to create sales-offers and potential buyers may use a telephone to browse sales-offers.
  • cryptographic protocols are used to authenticate the identity of buyers and/or sellers and verify the integrity of buyer and seller communications with the central controller.
  • the central controller can make it significantly more difficult for unauthorized persons to tamper with the system by passing themselves off as legitimate buyers or sellers or eavesdropping on system communications.
  • An embodiment of the present invention includes a mechanism for resolving disputes between buyers and sellers arising out of agreements consummated using the system.
  • a buyer and seller may be required to stipulate to binding arbitration and may be assisted in the arbitration process by the central controller.
  • the central controller may serve as an arbitrator or may refer the dispute to a third-party arbitrator for resolution.
  • the present invention provides a method for providing a client with a commodity, the commodity being a good or service, comprising:
  • the invention provides A method for providing a client with an allowance for using a service, comprising:
  • the invention provides a method for providing clients with an allowance for using a service, the method comprising: (a) providing a server and permitting a plurality of clients to connect to the server and transmit each a client-associated data by which each of the clients and accounts associated therewith may be identified;
  • the server aggregating clients together based on type of service packages chosen by the different clients to define a group of participating clients to obtain preferential terms from the service provider based on the number of participating clients in the group and executing a purchase sequence for the participating clients upon obtaining said preferential terms;
  • the server upon inducing said purchase sequence, initiating a billing sequence for billing each of the participating clients for the purchased service package by a purchase amount;
  • the invention provides a method for providing clients with a an allowance for using a service at preferential terms, the method comprising:
  • the invention provides a computerized system comprising:
  • the invention may be used, for example, in cases of a seller offer that includes a volume discount for a transaction involving a large number of commodity units. In this case, the invention allows remotely located buyers to conveniently search for such offers, and for interested buyers to conglomerate so as to be collectively eligible to receive the volume discount.
  • a seller wishing to make a sales-offer providing a volume discount accesses the central controller located at a remote server.
  • the seller will then create a volume-discounted sales-offer ("VDSO") by specifying the category of the commodity for sale and its description.
  • VDSO would also indicate the time limit for which the offer is valid.
  • the VDSO would further provide the volume discount being offered by specifying the price per unit when sold in a bulk transaction involving a number of units in some transaction volume range, for example, as detailed in Table 1.
  • the central controller allows an interested buyer to join, along with other interested buyers, a conglomerate of buyers that would collectively be eligible for one of the volume discounts of the VDSO. As exemplified in Table 1, the larger the conglomerate that forms, the greater the volume discount it is eligible to receive. If, after reviewing a particular VDSO, a potential buyer decides to become a member in the conglomerate, the buyer communicates his commitment to buy to the central controller indicating the number of units he will purchase at the unit price of each price level. The central controller will verify that the particular VDSO is still active, and if so, a unique number is assigned to the buyer's membership in the conglomerate that is stored in a database. The buyer is now party to a legally binding contract with the seller. The central controller may require a buyer to provide a credit card number and may ascertain that he has sufficient credit available to cover his commitment.
  • the aggregate conglomerate commitment is the number of units that the conglomerate members have collectively committed themselves to buy at each price level. It is displayed online and available to any new potential buyer. A typical situation is shown in Table 2.
  • the VDSO expires without a transaction having been consummated. If, however, new members were to join the conglomerate and collectively commit themselves to buy 701 units at price level 1, the deal would close at price level 1, with each member paying $575 per unit. If new members were to collectively commit themselves to buy 2001 units at Level 2, the deal would close at Level 2, with each member paying $530 per unit. Thus, as the conglomerate increases in size, the price drops and the incentive for others to join increases. The savings are particularly significant when the commodity has no inventory carrying costs, for example, airline tickets, hotel reservations and insurance policies. Insurance companies could thus use the present invention to reach thousands of potential insurance buyers and offer them volume-discounted insurance policies.
  • the invention a method for using a computer to facilitate a sales transaction of a commodity between a seller and a plurality of buyers, the method comprising the steps of: a inputting into the computer a volume discounted seller offer, the volume discounted seller offer including one or more price levels, wherein each price level specifies a price per unit commodity and a transaction volume range; b outputting the volume discounted seller offer to the plurality of buyers; c for one or more of the plurality of buyers, ca inputting into the computer a buyer commitment, the buyer commitment specifying a number of commodity units the buyer will buy at each price level; cb calculating an aggregate commitment for each price level where the aggregate commitment is the total number of commodity units that the plurality of buyers has committed itself so far to buy; and cc for each price level, determining whether the aggregate commitment is within the transaction volume range; d when the aggregate commitment of a price level is within the transaction volume range of a price level, da preventing additional buyer commitments from being inputted into the computer db out
  • Fig. 1 illustrates a first embodiment of the present invention
  • Fig. 2 is a block diagram showing one embodiment of the central controller
  • Fig. 3 is a block diagram showing one embodiment of the seller interface
  • Fig. 4 is a block diagram showing one embodiment of the buyer interface
  • Fig. 5 illustrates an embodiment showing how a sales-offer is generated
  • Fig. 6 illustrates an embodiment showing the acceptance of a sales-offer by the central controller
  • Fig. 7 illustrates a procedure for the maintenance of sales-offers.
  • Fig. 8 illustrates an embodiment showing a buyer selecting a sales-offer
  • Fig. 9 illustrates an embodiment showing a buyer accepting a sales-offer and effecting payment
  • Fig. 10 illustrates an exemplary procedure for transferring goods from buyer to seller
  • Fig. 11 is a block diagram showing one embodiment of the central controller for use with sales-offers that are volume discounted;
  • Fig. 12 illustrates an embodiment showing how a volume-discounted sales-offer is generated
  • Fig. 13 illustrates one embodiment of the maintenance of active volume-discounted sales-offers; and Fig. 14 illustrates an embodiment showing a buyer joining a conglomerate of a volume-discounted sales-offer.
  • FIG. 1 The system architecture of a first embodiment of the system and method of the present invention is illustrated with reference to Figs. 1 through 4. As shown in
  • the system of the present invention comprises seller interfaces 300, and seller modems 350, central controller 200, and buyer interfaces 400 and buyer modems 450, connected to each other via an Internet connection using a public switched phone network, such as those provided by a local or regional telephone operating company. Connection may also be provided by dedicated data lines, cellular Personal Communication Systems ("PCS"), microwave, or satellite networks.
  • Seller interface 300 and buyer interface 400 are the input and output gateways for communications with central controller 200.
  • buyer interfaces 400 and seller interface 300 including fax machines, PDAs with wireless connections, and beepers or pagers.
  • the present invention provides a method and system for a seller to input a sales-offer to central controller 200.
  • central controller 200 includes central processor (CPU) 205, cryptographic processor 210, RAM 215, ROM 220, payment processor 230, clock 235, operating system 240, network interface 245, and data storage device 250.
  • a conventional personal computer or computer workstation with sufficient memory and processing capability may be used as central controller 200. In one embodiment it operates as a web serve, receiving both sales-offers 100 and buyer purchase requests. Central controller 200 must be capable of high volume transaction processing, performing a significant number of mathematical calculations in processing communications and database searches.
  • a Pentium microprocessor such as the 100 MHz P54C, commonly manufactured by Intel Inc., may be used for CPU 205. This processor employs a 32-bit architecture. Equivalent processors include the Motorola 120 MHz PowerPC 604 or Sun Microsystems 166 MHz UltraSPARC-L. An MC6SHCI6 microcontroller, commonly manufactured by Motorola Inc, may be used for cryptographic processor 210. Equivalent processors may also be used.
  • Cryptographic processor 210 supports the authentication of communications between buyers and sellers as well as allowing for anonymous transactions.
  • Cryptographic processor 210 may also be configured as part of CPU 205.
  • Other commercially available specialized cryptographic processors include VLSI Technology's 33 MHz 6868 or Semaphore Communications' 40 MHz Roadrunner284.
  • payment processor 230 comprises one or more conventional microprocessors (such as the Intel Pentium), supporting the transfer and exchange of payments, charges, or debits, attendant to the method of the invention. Payment processor 230 may also be configured as part of CPU 205.
  • Processing of credit card transactions by payment processor 230 may be supported with commercially available software, such as the Secure Webserver manufactured by Open Market Inc.
  • This server software transmits credit card numbers electronically over the Internet to servers located at the Open Market headquarters where card verification and processing is handled.
  • Their Integrated Commerce Service provides back-office services necessary to run Web based businesses. Services include on-line account statements, order-taking and credit card payment authorization, credit card settlement, automated sales tax calculations, digital receipt generation, account-based purchase tracking.
  • Code generator 255 generates a code for each sales transaction consummated between a buyer and a seller. As explained below, the code is provided to the buyer and the seller by the system, and the buyer subsequently presents the code to the seller in order to obtain the goods or services he has purchased from the seller.
  • Data storage device 250 may include hard disk magnetic, or optical storage, units, as well as CD-ROM drives or flash memory.
  • Data storage device 250 contains databases used in the processing of transactions in the present invention, including seller database 260, sales-offer database 265, code database 283, purchase confirmation database 275, contract detail database 280, payment database 285, cryptographic key database 290, and audit database 295.
  • database software such as Oracle7, manufactured by Oracle Corporation, is used to create and manage these databases.
  • Seller database 260 maintains data on sellers with fields such as name, contact information, public/private key information, payment preferences, type of business, and commodities sold.
  • Contact information comprises a phone number, web page URL, bulletin board address, pager number, telephone number, electronic mail address, voice mail address, facsimile number, or any other way to contact the seller.
  • Sales-offer database 265 tracks all sales-offers 100 with fields such as status, tracking number, date, time, subject, price, expiration date, conditions, and seller identification number. This database is important in the event of disputes between a buyer and seller regarding payment, because details of the contract can be produced.
  • Seller account 298 tracks all information pertaining to the seller's account with fields such as seller's name, bank and credit account numbers, and debit or credit transactions. Buyer payments to the seller may be sent to this account.
  • Contract detail database 280 contains form background provisions for inclusion in sales-offers 100. These form provisions effectively fill the gaps between conditions specified by the seller, specifying generic contract details common to most sales-offers 100.
  • Purchase confirmation database 275 tracks messages sent to a buyer and a seller confirming a completed transaction, Fields include buyer name, buyer ID numbers, seller name, seller ID number, purchase confirmation tracking number, and the associated transaction code that will be used by the buyer to obtain the goods or services from the seller.
  • Code database 283 tracks codes that have been assigned to sales transactions.
  • Payment database 285 tracks all payments made by buyers with fields such as buyer name, buyer ID number, amount of payment, and associated transaction code.
  • Cryptographic key database 290 facilitates cryptographic functions, storing both symmetric and asymmetric keys. These keys are used by cryptographic processor 210 for encrypting and decrypting sales-offers 100, buyer purchase requests 110, and purchase confirmations 120.
  • Network interface 245 is the communication gateway with buyers and sellers through respective buyer interface 300 and seller interface 400.
  • Network interface 245 supports modems at a range of baud rates from 1200 upward, but may combine such inputs into a Tl or T3 line if more bandwidth is required.
  • network interface 245 is connected with the Internet and/or any of the commercial on-line services such as America Online. CompuServe, or Prodigy, allowing buyers and sellers access from a wide range of online connections.
  • Several commercial electronic mall servers include the above functionality. NCD Software manufactures "Post Office" a secure server-based electronic mail software package designed to link people and information over enterprise networks and the Internet. The product is platform independent and utilizes open standards based on Internet protocols. Users can exchange messages with enclosures such as files, graphics, video and audio. The system also supports multiple languages.
  • network interface 245 may be configured as a voice mail interface, web site, BBS, or electronic mail address. While the above embodiment describes a single computer acting as central controller 200, those skilled in the art will realize that the functionality can be distributed over a plurality of computers.
  • central controller 200 is configured in a distributed architecture, wherein the databases and processors are housed in separate units or locations. Some controllers perform the primary processing functions and contain at a minimum RAM, ROM, and a general processor. Each of these controllers is attached to a WAN hub that serves as the primary communication link with the other controllers and interface devices. The WAN hub may have minimal processing capability itself, serving primarily as a communications router. Those skilled in the art will appreciate that an almost unlimited number of controllers may be supported This arrangement yields a more dynamic and flexible system, less prone to catastrophic hardware failures affecting the entire system.
  • Figs. 3 and 4 describe seller interface 300 and buyer interface 400, respectively.
  • they are both conventional personal computers having an input device, such as a keyboard, mouse, or conventional voice recognition software package; a display device, such as a video monitor; a processing device such as a CPU; and a network interface such as a modem.
  • input device such as a keyboard, mouse, or conventional voice recognition software package
  • display device such as a video monitor
  • processing device such as a CPU
  • a network interface such as a modem.
  • seller interface 300 and buyer interface 400 may be voice mail systems, or other electronic or voice communications systems.
  • Devices such as fax machines or pagers are also suitable interface devices.
  • seller interface 300 that includes central processor (CPU) 305.
  • Cryptographic processor 310 and biometric device 355 may be added for stronger authentication as described later.
  • a Pentium microprocessor such as the 100 MHz P54C described above may be used for CPU 305.
  • Clock 335 is a standard chip-based clock that can serve to timestamp buyer purchase requests 110 produced with buyer interface 400.
  • Modem 350 may not require high-speed data transfer if most buyer purchase requests 110 produced are text-based and not too long. If a cryptographic processor is required, the MC68HC16 microcontroller described above is used. The structure of biometric device 355 will be described below in conjunction with the cryptographic authentication embodiment.
  • Data storage device 360 is a conventional magnetic-based hard disk storage unit such as those manufactured by Conner Peripherals.
  • Message database 370 may be used for archiving transaction details, while audit database 380 may be used for recording payment records and communications with central controller 200.
  • buyer interface 400 which includes central processor (CPU) 405, RAM 415, ROM 420, clock 435, video driver 425, video monitor 430, cryptographic processor 435, biometric device 455, communication port 440, input device 445, modem 450, message database 470, audit database 480, and data storage device 460. All of these components may be identical to those described in Fig. 3.
  • communications between buyers and sellers take place via electronic networks, with central controller 200 acting as a web server.
  • central controller 200 acting as a web server.
  • a seller logs onto central controller 200, creates sales-offer 100, and then disconnects from the network.
  • Periodic maintenance is performed by central controller 200 to ensure that active sales-offers 100 have not expired.
  • Central controller 200 contacts the seller to inform him of a completed sales transaction including the code of the transaction that was given to the buyer.
  • step 500 the seller logs onto central controller 200 using seller modem 350 of seller interface 300, establishing a communication link.
  • the seller might be an individual, a corporation, a partnership, a government, or any other entity.
  • central controller 200 has a page on the World Wide Web, allowing the seller to provide information through the interface of conventional web browser software such as Netscape Navigator, manufactured by Netscape Inc.
  • step 510 the seller selects the category of the goods he wants to sell by selecting from a list of possible categories. Categories might include airline tickets, hotel rooms, rental cars, insurance, mortgages, clothing, etc.
  • a form is displayed on video monitor 430 of seller interface 300. This form is an electronic contract between the seller and the system with a number of blanks to be filled out by the seller, with each blank representing a condition of sales-offer 100.
  • the seller enters a description of the goods including unit price of the goods.
  • the description of the goods might be, for example, first class round-trip tickets between San Francisco, leaving May 7 and returning May 12. There would be a place on the form for origin, destination, date of departure, date of return, number of tickets, class of service, etc. The seller simply fills in the blanks.
  • the seller adds an expiration date to sales-offer 100.
  • the seller adds any other conditions of the transaction, and at step 560, the seller attaches his name or ID number to sales transaction 100.
  • This ID number is received from central controller 200 when the seller registers for the service, or is chosen by the seller and then registered with central controller 200 by phone.
  • Central controller 200 maintains a database of seller ID numbers in seller database 260, and issues (or allows) only unique numbers. If less security is required, the user's telephone number could serve as the ID number since it has the advantages of being both unique and easily remembered. If additional security is required, cryptographic procedures may be implemented.
  • the seller transmits them to central controller 200 at step 570.
  • the seller does this by clicking on a "send" button located on the screen in which he entered the terms of sales-offer 100.
  • boilerplate legal language is added to the components of sales-offer 100 to form a complete sales 100.
  • the legal language is pulled from contract detail database 280 which stores a plurality of paragraphs These paragraphs are linked together with the above contract elements to form a complete sales-offer 100.
  • Authentication of the seller's identity by central processor 200 involves central controller 200 extracting the seller ID from sales-offer 100 and looking up the seller's identity in seller database 260. Information in seller database 260 then provides an indication of the seller's ability to provide the goods offered for sale.
  • sellers may also transmit sales-offer 100 data via electronic mail, voice mail, facsimile, or postal mail transmissions. With voice mail, the seller calls central controller 200 and leaves VDSO 100 in audio form. These sales-offers 100 may be transcribed into digital text at central controller 200, or made available to potential buyers in the same audio format.
  • Fig. 6 there is illustrated an embodiment in which sales-offer 100 is activated by central controller 200.
  • Central controller timestamps sales-offer 100 at step 610 and then stores sales-offer 100 in sales-offer database 265.
  • Sales-offer database 265 contains a record for each sales-offer 100, and includes fields such as status, category, tracking number, timestamp, description of goods, expiration date, conditions, and seller ID number.
  • the status field has values of "pending", “active”, “expired”.
  • a status of "pending” means that the sales-offer is not currently available to buyers, because, for example, either it is still being processed by central controller 200, or it has been temporarily suspended by the seller.
  • sales-offer 100 may go through a series of processing steps.
  • One step if necessary, is language translation, either creating a standard language that all sales-offer sales-offers must be written in, or translating to the language most appropriate for the buyers to whom it will be sent.
  • This translation is provided by language experts at central controller 200, or by automatic translation software such as Systran professional, manufactured by Systran Software. Twelve bi-directional language combinations are available, including English to/from French, Italian, German, Spanish, Portuguese, and Japanese.
  • Another step, if necessary, is to edit for spelling or grammatical errors. Sales-offer 100 might also be reviewed for clarity. Any sales-offer 100 with an unclear term or condition would be returned to the seller for clarification.
  • the status of the database record for sales-offer 100 is set to "active" at step 630.
  • the category of sales-offer 100 is extracted from the category field.
  • sales-offer 100 is posted in an appropriate category area.
  • central controller 200 has a web page for each possible category area. Thus all sales-offers 100 offering airline tickets would be displayed on the airline ticket web page. This makes it much easier for potential buyers to find sales-offers 100 of interest as they can go right to the category whose goods they wish to buy.
  • sales-offer 100 is electronically mailed to buyers, either individually or in groups. Buyers could elect to receive all sales-offers 100, or only those sales-offers 100 in their preselected categories.
  • Fig. 7 there is illustrated a procedure for the maintenance of sales-offers 100.
  • central controller 200 searches sales-offer database 265.
  • the expiration date field of each database record of sales-offer 100 is compared to the current date. If the expiration date of sales-offer 100 is earlier than the current date, the status of sales-offer 100 is changed to "expired" at step 720.
  • the maintenance process is completed at step 750 once all "active" sales-offer 100 database records have been examined.
  • Fig. 8 illustrates the process by which a buyer selects a sales-offer 100.
  • the buyer logs onto central controller 200 using modem 450 of buyer interface 400.
  • the buyer selects an appropriate category.
  • each sales-offer 100 is hyperlinked to a separate web page that provides complete details. The buyer clicks on sales-offer 100 and is immediately transferred to the page of supporting details.
  • Fig. 9 illustrates the process by which a buyer accepts a sales-offer 100.
  • the buyer selects the sales-offer 100, generating buyer purchase request 110.
  • the buyer purchase request 110 contains the number of units of each service or goods offered by sales-offer that the buyer wishes to buy.
  • central controller 200 receives buyer purchase request 110 from the buyer.
  • Central controller 200 then timestamps buyer purchase request 110 using clock 335 of buyer interface 400 and authenticates the identity of the buyer (step 920).
  • central controller 200 verifies the status of the sales-offer. If the sales offer is inactive (step 940), the buyer's purchase request is refused and transmitted back to buyer (Step 950). Otherwise, a unique tracking number is added to the buyer's purchase request at step 960.
  • payment processor 230 contacts the buyer's credit card clearinghouse to verify that the buyer has sufficient credit available to pay for his purchase. If not, then at step 985, the buyer purchase request 110 is refused and returned to buyer. Otherwise, at step 986 the buyer's credit card account is debited for the value of the transaction and the payment transferred to the seller's account.
  • details of the transaction are sent to the seller.
  • a code for the transaction is generated by code generator 255.
  • central controller 200 sends the transaction code to the buyer and to the seller.
  • Fig. 10 illustrates the transfer of goods from the seller to the buyer.
  • the buyer presents the transaction code to the seller.
  • the seller Upon validating the transaction code, the seller transfers the specified goods to the buyers (step 1110). This transfer could involve the delivery of physical goods as well as digital goods.
  • the buyer examines the delivered goods to verify that they meet all conditions and terms of sales-offer 100.
  • the buyer contacts an arbiter at central controller 200 for dispute resolution (step 1140).
  • the transaction is complete.
  • the invention may be used in cases where the sales-offer 100 is a volume discounted sales offer (VDSO).
  • VDSO volume discounted sales offer
  • data storage device 250 may contain additional databases used in the processing of VDSOs, such as buyer database 255, conglomerate database 267, buyer purchase request database 270, escrow account database 299, and buyer account database 297.
  • Buyer purchase request database 270 tracks all buyer purchase requests with fields such as buyer name, buyer ID number, date, time, number of units buyer committed to purchase at each price level, and the associated VDSO tracking number.
  • Buyer database 255 maintains data on buyers with fields such as name, address, credit card number, phone number, ID number, social security number, electronic mail address, credit history, past system usage, public/private key information, etc.
  • Buyer account 297 tracks all information pertaining to the buyer's account with fields such as buyer's name, bank and credit account numbers, and debit or credit transactions. This account may be a pointer to account data stored at the buyer's bank.
  • Conglomerate database 267 tracks the members of the conglomerate for each VDSO with fields such as membership list, purchase commitment of each member, and conglomerate aggregate commitment.
  • Escrow account 299 is an account that temporarily holds buyer funds before they are placed in seller account.
  • a seller logs onto central controller 200, creates a VDSO, and then disconnects from the network.
  • the VDSO is made available to buyers by posting the VDSO on the web page of central controller 200. Periodic maintenance is performed by central controller 200 to ensure that active VDSOs have not expired.
  • Central controller 200 contacts the seller to indicate that a conglomerate of buyers has formed eligible for a volume discount according to the VDSO.
  • Central controller 200 transfers credit card information to the seller as soon as the VDSO has been secured.
  • Fig.12 there is described the process by which the seller formulates a sales offer 100 that is a VDSO.
  • the seller logs onto central controller 200 using seller modem 350 of seller interface 300, establishing a communication link.
  • the seller adds an expiration date to VDSO 100.
  • the seller enters a unit price and transaction volume range for each price level.
  • the seller attaches his name or ID number to VDSO 100.
  • This ID number is received from central controller 200 when the seller registers for the service, or is chosen by the seller and then registered with central controller 200 by phone.
  • Central controller 200 maintains a database of seller ID numbers in seller database 260, and issues (or allows) only unique numbers. If less security is required, the user's telephone number could serve as the ID number since it has the advantages of being both unique and easily remembered. If additional security is required, cryptographic procedures may be implemented.
  • the seller transmits them to central controller 200 at step 1270.
  • the VDSO 100 is then processed as described in reference to Fig. 6.
  • VDSO 100 An "active" VDSO 100 is one for which it is possible for buyers to joint the conglomerate. The conglomerate of an "expired” VDSO 100 can no longer be joined. VDSOs 100 which have been consummated by a conglomerate of buyers have a status of "completed.”
  • Fig. 13 there is illustrated a procedure for the maintenance of VDSOs 100.
  • payment processor 230 contacts credit card clearinghouses to verify that every buyer in the VDSO conglomerate still has sufficient credit available to meet his commitment to the VDSO. Any buyers having insufficient credit are removed from the VDSO conglomerate at step 1340.
  • the maintenance process is completed at step 1350 once all "active" VDSO 100 database records have been examined.
  • Fig. 14 illustrates the process by which a buyer elects to join a conglomerate for accepting VDSO 100, after having selected a VDSO to join as described in reference to Fig. 8.
  • the buyer selects the VDSO 100 whose conglomerate he would like to join, generating buyer purchase request 110 representing his intention to join.
  • the buyer purchase request 110 contains the number of units the buyer commits himself to buy at each price level of the VDSO.
  • central controller 200 receives buyer purchase request 110 from the buyer. Central controller 200 then timestamps buyer purchase request 110 using clock 335 of buyer interface 400 and authenticates the identity of the buyer.
  • payment processor 230 contacts the buyer's credit card clearinghouse to verify that the buyer has sufficient credit available to meet his commitment to the VDSO. If not, then at step 1485, the buyer's purchase request 110 is refused and returned to buyer. Otherwise, at step 1486 payment processor 230 submits to the clearinghouse pre-authorization of the value of the buyer's commitment to the VDSO 100. This serves to "lock up" a portion of the available credit on the buyer's credit card to cover the cost of his commitment to the VDSO 100 as long as the VDSO 100 is still active. A unique tracking number is added to buyer purchase request 110 at step 1490. Central controller 200 then stores buyer purchase request 110 in buyer purchase request database 270 at step 1492 and in conglomerate database in step 1493.
  • step 1494 the new aggregate commitment of the conglomerate at each price level is calculated.
  • central processor 200 determines whether the aggregate commitment at any price level of the VDSO is within the transaction volume range of that level. If so, the seller and buyers are notified in step 1496. The status of the VDSO is changed to "completed" preventing subsequent buyers from joining VDSO 100.
  • the credit card account of each of the buyers in the conglomerate is debited at step 1497 for the value of each buyer's transaction and the payments transferred to the seller's account.
  • details of the transaction of each of the buyers are sent to the seller.
  • a code for the transaction of each buyer is generated by code generator 255.
  • central controller 200 sends each buyer's transaction code to the buyer and to the seller.
  • the goods or services are transferred to each of the buyers in the conglomerate as already described with reference to Fig. 10.
  • each of the buyers in the conglomerate presents his transaction code to the seller.
  • the seller Upon validating the transaction code, the seller transfers the specified goods to the buyer.

Abstract

A method for providing a client with a commodity. The client transmits client-associated data through a computer network by which the client is identified. The client then initiates a purchase transaction for a selected commodity. The client is billed for the commodity, and then receives a code permitting him to obtain the commodity from a provider of the commodity upon transmission of the code to the provider.

Description

METHOD OF DOING BUSINESS
FIELD OF THE INVENTION
The present invention is in the field of methods of doing business. More specifically, the invention relates to electronic contract applications using electronic methods.
BACKGROUND OF THE INVENTION
When wishing to acquire services or products, a consumer often finds that, due to the large number of variables and the large selection of services and products, the amount of information facing him is overwhelming. In these situations, the consumer often makes use of a sales agent. The role of the agent is to match the particular financial situation, preferences and desires of the consumer, with the available services and products offered by the various providers. The agent presents information relating to the goods or services of interest to the consumer, assists the customer in making a decision, closes a transaction and accepts payment. The selling of services and products through an agent, however, is a labor-intensive process. It is therefore desirable to automate some of the functions presently performed by sales agents.
SUMMARY OF THE INVENTION
The present invention provides a method and system for selling services or products by means of an interactive system capable of performing functions of a sales agent. In a preferred embodiment, communication between sellers and users on the one hand and the system, on the other, is conducted using an electronic network and central controller such as a world-wide web interface. In accordance with the invention, sellers input one or more sales-offers into the system. Buyers access the system to obtain information relating to sales-offers of interest of them that have been inputted by sellers. The system queries the buyer for input data concerning the desired services or products. The system receives the input data and searches an inventory database of sales-offers for the availability of the desired services or products. The system then provides to the buyer information relating to services or products satisfying the buyer's requirements, together with pricing information for the services or products. The buyer selects the services or products he wishes to purchase and the system accepts payment for the services or products selected by the buyer. Various payment methods may be utilized, including credit cards, personal checks, electronic funds transfer, debit cards, and digital cash. Finally, the system provides to the buyer a code indicative of the completed transaction. The user subsequently presents the code to the seller whose sales-offer he has selected in order to obtain the service or product already paid for from the seller. In a preferred embodiment, the buyer presents the code to the seller in an electronic form, for example by contacting the seller by telephone and pressing the code on the telephone handset.
The invention can also be practiced in off-line embodiments. Instead of using electronic mall or web-based servers, buyers and sellers may communicate with the central controller via telephone, facsimile, postal mail, or another off-line communication tool. For example, sellers may use telephones to create sales-offers and potential buyers may use a telephone to browse sales-offers.
In another on-line embodiment, cryptographic protocols are used to authenticate the identity of buyers and/or sellers and verify the integrity of buyer and seller communications with the central controller. Using cryptography and biometrics, the central controller can make it significantly more difficult for unauthorized persons to tamper with the system by passing themselves off as legitimate buyers or sellers or eavesdropping on system communications.
An embodiment of the present invention includes a mechanism for resolving disputes between buyers and sellers arising out of agreements consummated using the system. A buyer and seller may be required to stipulate to binding arbitration and may be assisted in the arbitration process by the central controller. The central controller may serve as an arbitrator or may refer the dispute to a third-party arbitrator for resolution. Thus, in one of its aspects, the present invention provides a method for providing a client with a commodity, the commodity being a good or service, comprising:
(a) providing at least one server linked to a computer network and permitting the client to connect to the server through the network and transmit a client-associated data by which the client may be identified;
(b) allowing the client to chose a desired commodity and to initiate a purchase transaction whereby the client is billed for the purchased commodity by a transaction amount;
(c) transmitting a code to the client permitting it to obtain said commodity by transmission of said code to a commodity provider.
In its second aspect, the invention provides A method for providing a client with an allowance for using a service, comprising:
(a) providing a server and permitting the client to connect to the server and transmit a client-associated data by which the client may be identified; (b) in the server, permitting the client to browse through a list of available service packages, choose a desired package, and execute a purchase sequence for said desired package;
(c) the server, upon inducing said purchase sequence, initiating a billing sequence for billing the client for the purchased package; (d) transmitting to the client, from said server, a code identifying the purchased service package; and
(e) the client, contacting a service provider and transmitting to it said code to activate said service package.
In its third aspect, the invention provides a method for providing clients with an allowance for using a service, the method comprising: (a) providing a server and permitting a plurality of clients to connect to the server and transmit each a client-associated data by which each of the clients and accounts associated therewith may be identified;
(b) permitting the clients to browse through one or more lists of available service packages for choosing a desired package;
(c) the server, aggregating clients together based on type of service packages chosen by the different clients to define a group of participating clients to obtain preferential terms from the service provider based on the number of participating clients in the group and executing a purchase sequence for the participating clients upon obtaining said preferential terms;
(d) the server, upon inducing said purchase sequence, initiating a billing sequence for billing each of the participating clients for the purchased service package by a purchase amount;
(e) the server, transmitting to each of the participating client a code identifying the purchased service package; and
(f) the client, contacting a service provider and transmitting to him said code to activate said service package.
In its fourth aspect, the invention provides a method for providing clients with a an allowance for using a service at preferential terms, the method comprising:
(a) providing a server and permitting a plurality of clients to connect to the server and transmit each a client-associated data by which each of the clients may be identified;
(b) in the server, providing one or more lists of volume discounted service packages comprising different price levels of said service packages, each price level being depended on a predefined aggregate number of participating clients, and permitting the client to chose a price level in which he commits to be a participating client;
(c) obtaining and storing for each of the clients an associate account data; (d) permitting time for clients to enter their commitments and determining for each client, based on his committed price and the number of commitments for each price level, whether he is a participating client;
(e) billing each participating client by a purchase amount equal or less than said price level and transmitting to each client an activating code for said service package; and
(f) the client, contacting a service provider and transmitting to him said code to activate said service package.
In its fifth aspect the invention provides a computerized system comprising:
(a) at least one server connected to a computer network permitting a client to connect to the server and receive from the client a client-associated data by which the client may be identified;
(b) a system software running on said at least one server for - displaying to the client a list of at least one commodity, the commodity being a good or a service, permitting the client to select a commodity from said list and to initiate a purchase of said commodity, and for upon such selection, initiating a billing sequence for billing a client-associated account with the cost of said commodity, and transmitting to the client a code permitting the client to obtain, through use of said code, the commodity from a commodity provider. The invention may be used, for example, in cases of a seller offer that includes a volume discount for a transaction involving a large number of commodity units. In this case, the invention allows remotely located buyers to conveniently search for such offers, and for interested buyers to conglomerate so as to be collectively eligible to receive the volume discount.
In accordance with the invention, a seller wishing to make a sales-offer providing a volume discount accesses the central controller located at a remote server. The seller will then create a volume-discounted sales-offer ("VDSO") by specifying the category of the commodity for sale and its description. The VDSO would also indicate the time limit for which the offer is valid. The VDSO would further provide the volume discount being offered by specifying the price per unit when sold in a bulk transaction involving a number of units in some transaction volume range, for example, as detailed in Table 1.
Table 1
Figure imgf000007_0001
The central controller allows an interested buyer to join, along with other interested buyers, a conglomerate of buyers that would collectively be eligible for one of the volume discounts of the VDSO. As exemplified in Table 1, the larger the conglomerate that forms, the greater the volume discount it is eligible to receive. If, after reviewing a particular VDSO, a potential buyer decides to become a member in the conglomerate, the buyer communicates his commitment to buy to the central controller indicating the number of units he will purchase at the unit price of each price level. The central controller will verify that the particular VDSO is still active, and if so, a unique number is assigned to the buyer's membership in the conglomerate that is stored in a database. The buyer is now party to a legally binding contract with the seller. The central controller may require a buyer to provide a credit card number and may ascertain that he has sufficient credit available to cover his commitment.
The aggregate conglomerate commitment is the number of units that the conglomerate members have collectively committed themselves to buy at each price level. It is displayed online and available to any new potential buyer. A typical situation is shown in Table 2.
Table 2
Figure imgf000008_0001
If the conglomerate aggregate commitment does not exceed the minimum volume requirement at any of the price levels by the VDSO closing deadline, the VDSO expires without a transaction having been consummated. If, however, new members were to join the conglomerate and collectively commit themselves to buy 701 units at price level 1, the deal would close at price level 1, with each member paying $575 per unit. If new members were to collectively commit themselves to buy 2001 units at Level 2, the deal would close at Level 2, with each member paying $530 per unit. Thus, as the conglomerate increases in size, the price drops and the incentive for others to join increases. The savings are particularly significant when the commodity has no inventory carrying costs, for example, airline tickets, hotel reservations and insurance policies. Insurance companies could thus use the present invention to reach thousands of potential insurance buyers and offer them volume-discounted insurance policies.
Thus, in another of its embodiments, the invention a method for using a computer to facilitate a sales transaction of a commodity between a seller and a plurality of buyers, the method comprising the steps of: a inputting into the computer a volume discounted seller offer, the volume discounted seller offer including one or more price levels, wherein each price level specifies a price per unit commodity and a transaction volume range; b outputting the volume discounted seller offer to the plurality of buyers; c for one or more of the plurality of buyers, ca inputting into the computer a buyer commitment, the buyer commitment specifying a number of commodity units the buyer will buy at each price level; cb calculating an aggregate commitment for each price level where the aggregate commitment is the total number of commodity units that the plurality of buyers has committed itself so far to buy; and cc for each price level, determining whether the aggregate commitment is within the transaction volume range; d when the aggregate commitment of a price level is within the transaction volume range of a price level, da preventing additional buyer commitments from being inputted into the computer db outputting to the seller the price level and aggregate commitment; dc outputting the price level to each of the buyers who made a buyer commitment to buy commodity units at the price level. provides
BRIEF DESCRIPTION OF THE DRAWINGS
In order to understand the invention and to see how it may be carried out in practice, a preferred embodiment will now be described, by way of non-limiting example only, with reference to the accompanying drawings, in which: Fig. 1 illustrates a first embodiment of the present invention;
Fig. 2 is a block diagram showing one embodiment of the central controller;
Fig. 3 is a block diagram showing one embodiment of the seller interface;
Fig. 4 is a block diagram showing one embodiment of the buyer interface;
Fig. 5 illustrates an embodiment showing how a sales-offer is generated; Fig. 6 illustrates an embodiment showing the acceptance of a sales-offer by the central controller;
Fig. 7 illustrates a procedure for the maintenance of sales-offers.
Fig. 8 illustrates an embodiment showing a buyer selecting a sales-offer; Fig. 9 illustrates an embodiment showing a buyer accepting a sales-offer and effecting payment;
Fig. 10 illustrates an exemplary procedure for transferring goods from buyer to seller;
Fig. 11 is a block diagram showing one embodiment of the central controller for use with sales-offers that are volume discounted;
Fig. 12 illustrates an embodiment showing how a volume-discounted sales-offer is generated;
Fig. 13 illustrates one embodiment of the maintenance of active volume-discounted sales-offers; and Fig. 14 illustrates an embodiment showing a buyer joining a conglomerate of a volume-discounted sales-offer.
DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT
The system architecture of a first embodiment of the system and method of the present invention is illustrated with reference to Figs. 1 through 4. As shown in
Fig. 1, the system of the present invention comprises seller interfaces 300, and seller modems 350, central controller 200, and buyer interfaces 400 and buyer modems 450, connected to each other via an Internet connection using a public switched phone network, such as those provided by a local or regional telephone operating company. Connection may also be provided by dedicated data lines, cellular Personal Communication Systems ("PCS"), microwave, or satellite networks. Seller interface 300 and buyer interface 400 are the input and output gateways for communications with central controller 200. There are a number of hardware options for buyer interfaces 400 and seller interface 300 including fax machines, PDAs with wireless connections, and beepers or pagers. Using the above components, the present invention provides a method and system for a seller to input a sales-offer to central controller 200. As shown in Fig. 2, central controller 200 includes central processor (CPU) 205, cryptographic processor 210, RAM 215, ROM 220, payment processor 230, clock 235, operating system 240, network interface 245, and data storage device 250.
A conventional personal computer or computer workstation with sufficient memory and processing capability may be used as central controller 200. In one embodiment it operates as a web serve, receiving both sales-offers 100 and buyer purchase requests. Central controller 200 must be capable of high volume transaction processing, performing a significant number of mathematical calculations in processing communications and database searches. A Pentium microprocessor such as the 100 MHz P54C, commonly manufactured by Intel Inc., may be used for CPU 205. This processor employs a 32-bit architecture. Equivalent processors include the Motorola 120 MHz PowerPC 604 or Sun Microsystems 166 MHz UltraSPARC-L. An MC6SHCI6 microcontroller, commonly manufactured by Motorola Inc, may be used for cryptographic processor 210. Equivalent processors may also be used. This microcontroller utilizes a 1 bit multiply-and-accumulate instruction in the 16 MHz configuration and requires less than one second to perform a 512-bit RSA private key operation. Cryptographic processor 210 supports the authentication of communications between buyers and sellers as well as allowing for anonymous transactions. Cryptographic processor 210 may also be configured as part of CPU 205. Other commercially available specialized cryptographic processors include VLSI Technology's 33 MHz 6868 or Semaphore Communications' 40 MHz Roadrunner284. Referring again to Fig. 2, payment processor 230 comprises one or more conventional microprocessors (such as the Intel Pentium), supporting the transfer and exchange of payments, charges, or debits, attendant to the method of the invention. Payment processor 230 may also be configured as part of CPU 205. Processing of credit card transactions by payment processor 230 may be supported with commercially available software, such as the Secure Webserver manufactured by Open Market Inc. This server software transmits credit card numbers electronically over the Internet to servers located at the Open Market headquarters where card verification and processing is handled. Their Integrated Commerce Service provides back-office services necessary to run Web based businesses. Services include on-line account statements, order-taking and credit card payment authorization, credit card settlement, automated sales tax calculations, digital receipt generation, account-based purchase tracking.
Code generator 255 generates a code for each sales transaction consummated between a buyer and a seller. As explained below, the code is provided to the buyer and the seller by the system, and the buyer subsequently presents the code to the seller in order to obtain the goods or services he has purchased from the seller.
Data storage device 250 may include hard disk magnetic, or optical storage, units, as well as CD-ROM drives or flash memory. Data storage device 250 contains databases used in the processing of transactions in the present invention, including seller database 260, sales-offer database 265, code database 283, purchase confirmation database 275, contract detail database 280, payment database 285, cryptographic key database 290, and audit database 295. In a preferred embodiment database software such as Oracle7, manufactured by Oracle Corporation, is used to create and manage these databases.
Seller database 260 maintains data on sellers with fields such as name, contact information, public/private key information, payment preferences, type of business, and commodities sold. Contact information comprises a phone number, web page URL, bulletin board address, pager number, telephone number, electronic mail address, voice mail address, facsimile number, or any other way to contact the seller.
Sales-offer database 265 tracks all sales-offers 100 with fields such as status, tracking number, date, time, subject, price, expiration date, conditions, and seller identification number. This database is important in the event of disputes between a buyer and seller regarding payment, because details of the contract can be produced.
Seller account 298 tracks all information pertaining to the seller's account with fields such as seller's name, bank and credit account numbers, and debit or credit transactions. Buyer payments to the seller may be sent to this account.
Contract detail database 280 contains form background provisions for inclusion in sales-offers 100. These form provisions effectively fill the gaps between conditions specified by the seller, specifying generic contract details common to most sales-offers 100. Purchase confirmation database 275 tracks messages sent to a buyer and a seller confirming a completed transaction, Fields include buyer name, buyer ID numbers, seller name, seller ID number, purchase confirmation tracking number, and the associated transaction code that will be used by the buyer to obtain the goods or services from the seller. Code database 283 tracks codes that have been assigned to sales transactions.
Payment database 285 tracks all payments made by buyers with fields such as buyer name, buyer ID number, amount of payment, and associated transaction code. Cryptographic key database 290 facilitates cryptographic functions, storing both symmetric and asymmetric keys. These keys are used by cryptographic processor 210 for encrypting and decrypting sales-offers 100, buyer purchase requests 110, and purchase confirmations 120.
Network interface 245 is the communication gateway with buyers and sellers through respective buyer interface 300 and seller interface 400.
Conventional internal or external modems may serve as network interface 245.
Network interface 245 supports modems at a range of baud rates from 1200 upward, but may combine such inputs into a Tl or T3 line if more bandwidth is required. In a preferred embodiment, network interface 245 is connected with the Internet and/or any of the commercial on-line services such as America Online. CompuServe, or Prodigy, allowing buyers and sellers access from a wide range of online connections. Several commercial electronic mall servers include the above functionality. NCD Software manufactures "Post Office" a secure server-based electronic mail software package designed to link people and information over enterprise networks and the Internet. The product is platform independent and utilizes open standards based on Internet protocols. Users can exchange messages with enclosures such as files, graphics, video and audio. The system also supports multiple languages. Alternatively, network interface 245 may be configured as a voice mail interface, web site, BBS, or electronic mail address. While the above embodiment describes a single computer acting as central controller 200, those skilled in the art will realize that the functionality can be distributed over a plurality of computers. In one embodiment, central controller 200 is configured in a distributed architecture, wherein the databases and processors are housed in separate units or locations. Some controllers perform the primary processing functions and contain at a minimum RAM, ROM, and a general processor. Each of these controllers is attached to a WAN hub that serves as the primary communication link with the other controllers and interface devices. The WAN hub may have minimal processing capability itself, serving primarily as a communications router. Those skilled in the art will appreciate that an almost unlimited number of controllers may be supported This arrangement yields a more dynamic and flexible system, less prone to catastrophic hardware failures affecting the entire system.
Figs. 3 and 4 describe seller interface 300 and buyer interface 400, respectively. In an exemplary embodiment, they are both conventional personal computers having an input device, such as a keyboard, mouse, or conventional voice recognition software package; a display device, such as a video monitor; a processing device such as a CPU; and a network interface such as a modem. These devices interface with central controller 200. Alternatively, seller interface 300 and buyer interface 400 may be voice mail systems, or other electronic or voice communications systems. Devices such as fax machines or pagers are also suitable interface devices.
Referring now to Fig. 3, there is described seller interface 300 that includes central processor (CPU) 305. RAM 315, ROM 320, clock 335, video driver 325, video monitor 330, communication port 340, input device 345, modem 350, and data storage device 360. Cryptographic processor 310 and biometric device 355 may be added for stronger authentication as described later. A Pentium microprocessor such as the 100 MHz P54C described above may be used for CPU 305. Clock 335 is a standard chip-based clock that can serve to timestamp buyer purchase requests 110 produced with buyer interface 400.
Modem 350 may not require high-speed data transfer if most buyer purchase requests 110 produced are text-based and not too long. If a cryptographic processor is required, the MC68HC16 microcontroller described above is used. The structure of biometric device 355 will be described below in conjunction with the cryptographic authentication embodiment.
Data storage device 360 is a conventional magnetic-based hard disk storage unit such as those manufactured by Conner Peripherals. Message database 370 may be used for archiving transaction details, while audit database 380 may be used for recording payment records and communications with central controller 200. Referring now to Fig. 4, there is described buyer interface 400 which includes central processor (CPU) 405, RAM 415, ROM 420, clock 435, video driver 425, video monitor 430, cryptographic processor 435, biometric device 455, communication port 440, input device 445, modem 450, message database 470, audit database 480, and data storage device 460. All of these components may be identical to those described in Fig. 3.
There are many commercial software applications that can enable the communications required by seller interface 300 or buyer interface 400, the primary functionality being message creation and transmission. Eudora Pro manufactured by Qualcomm Incorporated, for example, provides editing tools for the creation of messages as well as the communications tools to route the message to the appropriate electronic address. When central controller 200 is configured as a web server, conventional communications software such as the Netscape navigator web browser from Netscape Corporation may also be used. The buyer and seller may use the Netscape Navigator browser to transmit sales-offers 100 or buyer purchase requests 110. No proprietary software is required.
In one embodiment of the present invention, communications between buyers and sellers take place via electronic networks, with central controller 200 acting as a web server. A seller logs onto central controller 200, creates sales-offer 100, and then disconnects from the network. Periodic maintenance is performed by central controller 200 to ensure that active sales-offers 100 have not expired. Central controller 200 contacts the seller to inform him of a completed sales transaction including the code of the transaction that was given to the buyer.
With reference to Fig. 5, there is described the process by which the seller formulates sales-offer 100. At step 500 the seller logs onto central controller 200 using seller modem 350 of seller interface 300, establishing a communication link. It should be noted that the seller might be an individual, a corporation, a partnership, a government, or any other entity. In one embodiment, central controller 200 has a page on the World Wide Web, allowing the seller to provide information through the interface of conventional web browser software such as Netscape Navigator, manufactured by Netscape Inc. At step 510, the seller selects the category of the goods he wants to sell by selecting from a list of possible categories. Categories might include airline tickets, hotel rooms, rental cars, insurance, mortgages, clothing, etc. After the category has been selected, a form is displayed on video monitor 430 of seller interface 300. This form is an electronic contract between the seller and the system with a number of blanks to be filled out by the seller, with each blank representing a condition of sales-offer 100.
At step 520, the seller enters a description of the goods including unit price of the goods. The description of the goods might be, for example, first class round-trip tickets between San Francisco, leaving May 7 and returning May 12. There would be a place on the form for origin, destination, date of departure, date of return, number of tickets, class of service, etc. The seller simply fills in the blanks.
At step 530, the seller adds an expiration date to sales-offer 100. At step 550 he adds any other conditions of the transaction, and at step 560, the seller attaches his name or ID number to sales transaction 100. This ID number is received from central controller 200 when the seller registers for the service, or is chosen by the seller and then registered with central controller 200 by phone. Central controller 200 maintains a database of seller ID numbers in seller database 260, and issues (or allows) only unique numbers. If less security is required, the user's telephone number could serve as the ID number since it has the advantages of being both unique and easily remembered. If additional security is required, cryptographic procedures may be implemented.
Once the above elements have been developed, the seller transmits them to central controller 200 at step 570. The seller does this by clicking on a "send" button located on the screen in which he entered the terms of sales-offer 100. At step 580, boilerplate legal language is added to the components of sales-offer 100 to form a complete sales 100. The legal language is pulled from contract detail database 280 which stores a plurality of paragraphs These paragraphs are linked together with the above contract elements to form a complete sales-offer 100. Authentication of the seller's identity by central processor 200 involves central controller 200 extracting the seller ID from sales-offer 100 and looking up the seller's identity in seller database 260. Information in seller database 260 then provides an indication of the seller's ability to provide the goods offered for sale.
Instead of a World Wide Web based interface, sellers may also transmit sales-offer 100 data via electronic mail, voice mail, facsimile, or postal mail transmissions. With voice mail, the seller calls central controller 200 and leaves VDSO 100 in audio form. These sales-offers 100 may be transcribed into digital text at central controller 200, or made available to potential buyers in the same audio format. Referring now to Fig. 6, there is illustrated an embodiment in which sales-offer 100 is activated by central controller 200. At step 600, a unique tracking number is added to sales-offer 100. Central controller timestamps sales-offer 100 at step 610 and then stores sales-offer 100 in sales-offer database 265. Sales-offer database 265 contains a record for each sales-offer 100, and includes fields such as status, category, tracking number, timestamp, description of goods, expiration date, conditions, and seller ID number. The status field has values of "pending", "active", "expired". A status of "pending" means that the sales-offer is not currently available to buyers, because, for example, either it is still being processed by central controller 200, or it has been temporarily suspended by the seller.
After being stored at step 620, sales-offer 100 may go through a series of processing steps. One step, if necessary, is language translation, either creating a standard language that all sales-offer sales-offers must be written in, or translating to the language most appropriate for the buyers to whom it will be sent. This translation is provided by language experts at central controller 200, or by automatic translation software such as Systran professional, manufactured by Systran Software. Twelve bi-directional language combinations are available, including English to/from French, Italian, German, Spanish, Portuguese, and Japanese. Another step, if necessary, is to edit for spelling or grammatical errors. sales-offer 100 might also be reviewed for clarity. Any sales-offer 100 with an unclear term or condition would be returned to the seller for clarification.
Referring still to Fig. 6, the status of the database record for sales-offer 100 is set to "active" at step 630. At step 640, the category of sales-offer 100 is extracted from the category field. At step 650, sales-offer 100 is posted in an appropriate category area. In a World Wide Web environment, central controller 200 has a web page for each possible category area. Thus all sales-offers 100 offering airline tickets would be displayed on the airline ticket web page. This makes it much easier for potential buyers to find sales-offers 100 of interest as they can go right to the category whose goods they wish to buy. In an alternative embodiment, sales-offer 100 is electronically mailed to buyers, either individually or in groups. Buyers could elect to receive all sales-offers 100, or only those sales-offers 100 in their preselected categories.
Referring now to Fig. 7, there is illustrated a procedure for the maintenance of sales-offers 100. At step 700, central controller 200 searches sales-offer database 265. At step 710, the expiration date field of each database record of sales-offer 100 is compared to the current date. If the expiration date of sales-offer 100 is earlier than the current date, the status of sales-offer 100 is changed to "expired" at step 720. The maintenance process is completed at step 750 once all "active" sales-offer 100 database records have been examined. Fig. 8 illustrates the process by which a buyer selects a sales-offer 100. At step 800, the buyer logs onto central controller 200 using modem 450 of buyer interface 400. At step 810, the buyer selects an appropriate category. At step 820, the buyer browses the list of available sales-offers 100 (those with a status of "active") in the selected category, and at step 830 he selects a sales-offer. Sales-offers 100 may be listed with minimal details, with additional information available only if the buyer is interested in participate in sales-offer 100. A hotel sales-offer 100 might be listed as "Hotel, Sept. 16. 1996-Chicago-single occupancy-$35." A buyer wanting more information about this sales-offer 100 requests it at step 840. In one embodiment, each sales-offer 100 is hyperlinked to a separate web page that provides complete details. The buyer clicks on sales-offer 100 and is immediately transferred to the page of supporting details. The details might include hotel rating, type of bed, fitness facilities, and restaurants available. In another embodiment, sales-offer 100 is electronically transmitted directly to buyers via electronic mail, fax, telephone, beeper, etc. A frequent flyer from San Francisco to New York, for example, could instruct central controller 200 to beep him whenever a sales-offer 100 appeared for tickets between these two cities, providing details of sales-offer 100 over the beeper network, or telling him to log onto central controller 200 for further details. Fig. 9 illustrates the process by which a buyer accepts a sales-offer 100. At step 900, the buyer selects the sales-offer 100, generating buyer purchase request 110. The buyer purchase request 110 contains the number of units of each service or goods offered by sales-offer that the buyer wishes to buy. At step 910, central controller 200 receives buyer purchase request 110 from the buyer. Central controller 200 then timestamps buyer purchase request 110 using clock 335 of buyer interface 400 and authenticates the identity of the buyer (step 920).
At step 930, central controller 200 verifies the status of the sales-offer. If the sales offer is inactive (step 940), the buyer's purchase request is refused and transmitted back to buyer (Step 950). Otherwise, a unique tracking number is added to the buyer's purchase request at step 960.
At step 980, payment processor 230 contacts the buyer's credit card clearinghouse to verify that the buyer has sufficient credit available to pay for his purchase. If not, then at step 985, the buyer purchase request 110 is refused and returned to buyer. Otherwise, at step 986 the buyer's credit card account is debited for the value of the transaction and the payment transferred to the seller's account. At step 995 details of the transaction are sent to the seller. At step 990 a code for the transaction is generated by code generator 255. At step 1000 central controller 200 sends the transaction code to the buyer and to the seller. Fig. 10 illustrates the transfer of goods from the seller to the buyer. At step 1100, the buyer presents the transaction code to the seller. Upon validating the transaction code, the seller transfers the specified goods to the buyers (step 1110). This transfer could involve the delivery of physical goods as well as digital goods. At step 1120, the buyer examines the delivered goods to verify that they meet all conditions and terms of sales-offer 100. At step 1130, if the goods do not meet the seller's conditions as described in sales-offer 100 the buyer contacts an arbiter at central controller 200 for dispute resolution (step 1140). At step 1150 the transaction is complete. The invention may be used in cases where the sales-offer 100 is a volume discounted sales offer (VDSO). As shown in Fig. 11, in these cases, data storage device 250 may contain additional databases used in the processing of VDSOs, such as buyer database 255, conglomerate database 267, buyer purchase request database 270, escrow account database 299, and buyer account database 297.
Buyer purchase request database 270 tracks all buyer purchase requests with fields such as buyer name, buyer ID number, date, time, number of units buyer committed to purchase at each price level, and the associated VDSO tracking number. Buyer database 255 maintains data on buyers with fields such as name, address, credit card number, phone number, ID number, social security number, electronic mail address, credit history, past system usage, public/private key information, etc.
Buyer account 297 tracks all information pertaining to the buyer's account with fields such as buyer's name, bank and credit account numbers, and debit or credit transactions. This account may be a pointer to account data stored at the buyer's bank.
Conglomerate database 267 tracks the members of the conglomerate for each VDSO with fields such as membership list, purchase commitment of each member, and conglomerate aggregate commitment.
Escrow account 299 is an account that temporarily holds buyer funds before they are placed in seller account.
A seller logs onto central controller 200, creates a VDSO, and then disconnects from the network. The VDSO is made available to buyers by posting the VDSO on the web page of central controller 200. Periodic maintenance is performed by central controller 200 to ensure that active VDSOs have not expired. Central controller 200 contacts the seller to indicate that a conglomerate of buyers has formed eligible for a volume discount according to the VDSO. Central controller 200 transfers credit card information to the seller as soon as the VDSO has been secured. With reference to Fig.12, there is described the process by which the seller formulates a sales offer 100 that is a VDSO. At step 1200 the seller logs onto central controller 200 using seller modem 350 of seller interface 300, establishing a communication link. At step 1230, the seller adds an expiration date to VDSO 100. At step 1240, the seller enters a unit price and transaction volume range for each price level. At step 1250 he adds any other conditions of the transaction, and at step 1260, the seller attaches his name or ID number to VDSO 100. This ID number is received from central controller 200 when the seller registers for the service, or is chosen by the seller and then registered with central controller 200 by phone. Central controller 200 maintains a database of seller ID numbers in seller database 260, and issues (or allows) only unique numbers. If less security is required, the user's telephone number could serve as the ID number since it has the advantages of being both unique and easily remembered. If additional security is required, cryptographic procedures may be implemented. Once the above elements have been developed, the seller transmits them to central controller 200 at step 1270. The VDSO 100 is then processed as described in reference to Fig. 6.
An "active" VDSO 100 is one for which it is possible for buyers to joint the conglomerate. The conglomerate of an "expired" VDSO 100 can no longer be joined. VDSOs 100 which have been consummated by a conglomerate of buyers have a status of "completed."
Referring now to Fig. 13, there is illustrated a procedure for the maintenance of VDSOs 100. At step 1330, payment processor 230 contacts credit card clearinghouses to verify that every buyer in the VDSO conglomerate still has sufficient credit available to meet his commitment to the VDSO. Any buyers having insufficient credit are removed from the VDSO conglomerate at step 1340. The maintenance process is completed at step 1350 once all "active" VDSO 100 database records have been examined.
Fig. 14 illustrates the process by which a buyer elects to join a conglomerate for accepting VDSO 100, after having selected a VDSO to join as described in reference to Fig. 8. At step 1400, the buyer selects the VDSO 100 whose conglomerate he would like to join, generating buyer purchase request 110 representing his intention to join. The buyer purchase request 110 contains the number of units the buyer commits himself to buy at each price level of the VDSO. At step 1410, central controller 200 receives buyer purchase request 110 from the buyer. Central controller 200 then timestamps buyer purchase request 110 using clock 335 of buyer interface 400 and authenticates the identity of the buyer.
At step 1480, payment processor 230 contacts the buyer's credit card clearinghouse to verify that the buyer has sufficient credit available to meet his commitment to the VDSO. If not, then at step 1485, the buyer's purchase request 110 is refused and returned to buyer. Otherwise, at step 1486 payment processor 230 submits to the clearinghouse pre-authorization of the value of the buyer's commitment to the VDSO 100. This serves to "lock up" a portion of the available credit on the buyer's credit card to cover the cost of his commitment to the VDSO 100 as long as the VDSO 100 is still active. A unique tracking number is added to buyer purchase request 110 at step 1490. Central controller 200 then stores buyer purchase request 110 in buyer purchase request database 270 at step 1492 and in conglomerate database in step 1493.
In step 1494, the new aggregate commitment of the conglomerate at each price level is calculated. At step 1495, central processor 200 determines whether the aggregate commitment at any price level of the VDSO is within the transaction volume range of that level. If so, the seller and buyers are notified in step 1496. The status of the VDSO is changed to "completed" preventing subsequent buyers from joining VDSO 100.
The credit card account of each of the buyers in the conglomerate is debited at step 1497 for the value of each buyer's transaction and the payments transferred to the seller's account. At step 1498 details of the transaction of each of the buyers are sent to the seller. At step 1499 a code for the transaction of each buyer is generated by code generator 255. At step 1500 central controller 200 sends each buyer's transaction code to the buyer and to the seller. The goods or services are transferred to each of the buyers in the conglomerate as already described with reference to Fig. 10. Thus, each of the buyers in the conglomerate presents his transaction code to the seller. Upon validating the transaction code, the seller transfers the specified goods to the buyer.

Claims

CLAIMS:
1. A method for providing a client with a commodity, the commodity being a good or service, comprising:
(a) providing at least one server linked to a computer network and permitting the client to connect to the server through the network and transmit a client-associated data by which the client may be identified;
(b) allowing the client to chose a desired commodity and to initiate a purchase transaction whereby the client is billed for the purchased commodity by a transaction amount; (c) transmitting a code to the client permitting him to obtain said commodity by transmission of said code to a commodity provider.
2. A method according to Claim 1, wherein the computer network is the Internet.
3. A method according to Claim 1 or 2, wherein the client communicates with the commodity provider through a communication network other than said computer network.
4. A method according to Claim 3, wherein said communication network is a telephone network.
5. A method according to any one of Claims 1-4, comprising: (d) transferring to the commodity provider data on the purchased commodity and at least a portion of the transaction amount.
6. A method for providing a client with an allowance for using a service, comprising:
(a) providing a server and permitting the client to connect to the server and transmit a client-associated data by which the client may be identified;
(b) in the server, permitting the client to browse through a list of available service packages, choose a desired package, and execute a purchase sequence for said desired package; (c) the server, upon inducing said purchase sequence, initiating a billing sequence for billing the client for the purchased package;
(d) transmitting to the client, from said server, a code identifying the purchased service package; and (e) the client, contacting a service provider and transmitting to it said code to activate said service package.
7. A method according to Claim 6, wherein said service is a communication package.
8. A method according to Claim 7, wherein said service is an communication time ("airtime") package for cellular telephone communication, and wherein steps (b) and (e) comprise:
(b) in the server, permitting the client to browse through a list of available service packages for choosing a desired package and to induce a purchase sequence for said desired package; (e) the client, contacting the cellular service provider and transmitting the code to said provider to activate said airtime package.
9. A method according to Claim 8, wherein the client transmits said code to the cellular service provider through a client-associated cell phone and the cellular service provider defining the client-associated cell phone as operable for said airtime package.
10. A method according to any one of Claims 6-9, comprising simultaneously or after step ( c), (d) or (e):
(f) the server, transferring to the service provider data on the purchased service package and at least a portion of the traction amount.
11. A method according to Claim 10, wherein said computer network is the Internet.
12. A method according to any one of Claims 6-11, wherein the billing is either to the client's credit or debit card, bank or telephone account.
13. A method for providing clients with an allowance for using a service, the method comprising: (a) providing a server and permitting a plurality of clients to connect to the server and transmit each a client-associated data by which each of the clients and accounts associated therewith may be identified;
(b) permitting the clients to browse through one or more lists of available service packages for choosing a desired package;
(c) the server, aggregating clients together based on type of service packages chosen by the different clients to define a group of participating clients to obtain preferential terms from the service provider based on the number of participating clients in the group and executing a purchase sequence for the participating clients upon obtaining said preferential terms;
(d) the server, upon inducing said purchase sequence, initiating a billing sequence for billing each of the participating clients for the purchased service package by a purchase amount;
(e) the server, transmitting to each of the participating client a code identifying the purchased service package; and
(f) the client, contacting a service provider and transmitting to him said code to activate said service package.
14. A method for providing clients with a an allowance for using a service at preferential terms, the method comprising: (a) providing a server and permitting a plurality of clients to connect to the server and transmit each a client-associated data by which each of the clients may be identified;
(b) in the server, providing one or more lists of volume discounted service packages comprising different price levels of said service packages, each price level being depended on a predefined aggregate number of participating clients, and permitting the client to chose a price level in which he commits to be a participating client;
(c) obtaining and storing for each of the clients an associate account data; (d) permitting time for clients to enter their commitments and determining for each client, based on his committed price and the number of commitments for each price level, whether he is a participating client;
(e) billing each participating client by a purchase amount equal or less 5 than said price level and transmitting to each client an activating code for said service package; and
(f) the client, contacting a service provider and transmitting to him said code to activate said service package.
15. A method according to Claim 13 or 14, wherein said service package is a 10 communication package.
16. A method according to Claim 15, wherein said communication is a communication time package over a cellular phone package.
17. A method according to Claim 15 or 16, wherein the client contacts the service provider through a communication network.
15 18. A method according to any one of Claims 15-17, wherein said communication package is a connection time ("airtime") package and wherein the client transmits said code to a cellular service provider through a client-associated cell phone and the cellular service provider defining the client-associated cell phone as operable for said air time package.
20 19. A computerized system comprising:
(a) at least one server connected to a computer network permitting a client to connect to the server and receive from the client a client-associated data by which the client may be identified;
(b) a system software running on said at least one server for
25 - displaying to the client a list of at least one commodity, the commodity being a good or a service, permitting the client to select a commodity from said list and to initiate a purchase of said commodity, and for upon such selection, initiating a billing sequence for billing a 30 client-associated account with the cost of said commodity, and re transmitting to the client a code permitting the client to obtain, through use of said code, the commodity from a commodity provider.
20. A system according to Claim 19, wherein said computer network is the 5 Internet.
21. A system according to Claim 19 or 20, wherein said commodity is a service package.
22. A system according to Claim 21, wherein said service package is a communication package for communication over a communication network.
10 23. A system according to Claim 22, wherein said communication package is an airtime package for communication over a cellular telephone network.
24. A system according to any one of Claims 19-23, wherein said code is for transmission to a cellular service provider through a client associated cellular telephone, whereby said provider defines siad cellular telephone as having said
15 communication package.
25. A system for providing clients with an allowance for using a service, the service comprising:
(a) at least one server connected to a computer network permitting a plurality of clients to connect to the server through the network and receive from
20 each of the clients a client-associated data by which the clients may be identified;
(b) software running on said at least one server for displaying to the client a list of at least one service package to allow the client to chose a desired service package, aggregating clients together based on type of service packages 25 chosen by the different clients to define a group of participating clients to obtain preferential terms from the service provider and inducing a purchase sequence for each client upon obtaining said preferential terms, initiating a billing sequence for billing each participating client 30 with an amount according to the preferential terms price of the purchased service package and transmitting a code to each participating client identifying the purchased service package, (c) a clearance software for transferring at least a portion of said amount to said service provider.
26. A system for providing clients with an allowance for using a service, the service comprising:
(a) at least one server connected to a computer network permitting a plurality of clients to connect to the server through the network and receive from each of the clients a client-associated data by which the clients and accounts associated therewith may be identified;
(b) software running on said at least one server for displaying to the client a list of volume discounted service package comprising different price levels of said service packages, each price level being dependent on a predetermined aggregate number of participating clients, and permitting the client to chose a threshold price level in which he commits to be a participating client, storing particulars of clients and the threshold price level for each client, - aggregating clients together based on type of service packages chosen by the different clients to define a group of participating clients to obtain preferential terms from the service provider and inducing a purchase sequence for each client upon obtaining said preferential terms, determining for each client, based on the client's threshold price level and the threshold prices for other clients whether the client is a participating client, and billing the associated account for each participating client by an amount equal or less than said threshold price level and transmitting to each participating client, through the computer network and activating code for said service package permitting the client to contact the service provider and activate the service package; (i) a clearance software for transferring at least a portion of said amount to said service provider.
27. A system according to Claim 25 or 26, wherein said computer network is the Internet.
28. A system according to any one of Claims 25-27, wherein said commodity is a service package.
29. A system according to Claim 28, wherein said service package is a communication package for communication over a communication network.
30. A system according to Claim 29, wherein said communication package is an airtime package for communication over a cellular telephone network.
31. A system according to any one of Claims 25-30, wherein said code is for transmission to a cellular service provider through a client associated cellular telephone, whereby said provider defines said cellular telephone as having said communication package.
32. A method for using a computer to facilitate a sales transaction of a commodity between a seller and a plurality of buyers, the method comprising the steps of: (a) inputting into the computer a volume discounted seller offer, the volume discounted seller offer including one or more price levels, wherein each price level specifies a price per unit commodity and a transaction volume range;
(b) outputting the volume discounted seller offer to the plurality of buyers; (c) for one or more of the plurality of buyers,
(ca) inputting into the computer a buyer commitment, the buyer commitment specifying a number of commodity units the buyer will buy at each price level;
(cb) calculating an aggregate commitment for each price level where the aggregate commitment is the total number of commodity units that the plurality of buyers has committed itself so far to buy; and (cc) for each price level, determining whether the aggregate commitment is within the transaction volume range; (d) when the aggregate commitment of a price level is within the transaction volume range of a price level,
(da) preventing additional buyer commitments from being inputted into the computer
(db) outputting to the seller the price level and aggregate commitment;
(dc) outputting the price level to each of the buyers who made a buyer commitment to buy commodity units at the price level.
PCT/IL2000/000834 1999-12-16 2000-12-14 Method of doing business WO2001044999A2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU18817/01A AU1881701A (en) 1999-12-16 2000-12-14 Method of doing business

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
IL133563 1999-12-16
IL13356399A IL133563A0 (en) 1999-12-16 1999-12-16 Method of doing business

Publications (2)

Publication Number Publication Date
WO2001044999A2 true WO2001044999A2 (en) 2001-06-21
WO2001044999A8 WO2001044999A8 (en) 2002-06-20

Family

ID=11073610

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IL2000/000834 WO2001044999A2 (en) 1999-12-16 2000-12-14 Method of doing business

Country Status (3)

Country Link
AU (1) AU1881701A (en)
IL (1) IL133563A0 (en)
WO (1) WO2001044999A2 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003032207A1 (en) * 2001-10-12 2003-04-17 Best Profits Group Limited Method and system for providing self-optimized commodity directory

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
No Search *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003032207A1 (en) * 2001-10-12 2003-04-17 Best Profits Group Limited Method and system for providing self-optimized commodity directory

Also Published As

Publication number Publication date
IL133563A0 (en) 2001-04-30
WO2001044999A8 (en) 2002-06-20
AU1881701A (en) 2001-06-25

Similar Documents

Publication Publication Date Title
US7472074B1 (en) Method and apparatus for a commercial network system designed to facilitate buyer-driven conditional purchase offers
AU2001266597B8 (en) Internet bargaining system
US6260024B1 (en) Method and apparatus for facilitating buyer-driven purchase orders on a commercial network system
US8005747B2 (en) Method and apparatus for generating a sale offer over an electronic network system
US20090089198A1 (en) Method and Apparatus for Issue and Trade of Fractional Interest Real Estate Stock
US20030074273A1 (en) Apparatus and method for facilitating trade
AU2001266597A1 (en) Internet bargaining system
US20100153278A1 (en) Web sites that introduce a seller to a universe of buyers, web sites that receive a buyer's listing of what he wants to buy, other introduction web sites, systems using introduction web sites and internet-based introductions
US20020010685A1 (en) Electronic exchange apparatus and method
US20040220884A1 (en) Intelligent internet bargaining system
US20020069118A1 (en) Refund management
US20010037261A1 (en) Agent purchase method, agent purchase system and record medium containing transaction management program
US20020128935A1 (en) Many-to-many mediated commercial electronic publishing
MXPA06003962A (en) Computerized transaction bargaining system and method.
US20010047329A1 (en) Electronic exchange apparatus and method
US20090018942A1 (en) System and method for online auction
US20090089217A1 (en) Method and Apparatus for Issue and Trade of Real Estate Options
US20010034648A1 (en) Method and apparatus for obtaining remote photographs or video using unilateral contract applications
US20060173741A1 (en) Permission-based marketing method and system
WO2002007059A1 (en) Web-based account management
US20030061161A1 (en) Business method for facilitating offsetting payables against receivables
WO2001033447A1 (en) Auction fee processing method using computer network system
WO2001044999A2 (en) Method of doing business
EP1376425A1 (en) Charging device, charging method, transaction supporting device, and transaction supporting method
KR20010106611A (en) Business method for buying incomplete merchandises previously

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
AK Designated states

Kind code of ref document: C1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: C1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

D17 Declaration under article 17(2)a
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 69(1)EPC

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP