JP2009116894A - System and method for electronic commerce transaction - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To easily perform a small amount of micropayment transaction with a single log-in. <P>SOLUTION: Electronic tokens are issued by a micropayment service provider 60. Goods offered by member vendors 55 are purchased or rented by a user 50 using the electronic tokens. Once the user 50 accesses the site of the provider, the user can visit the websites of a plurality of vendors 55 during a predetermined term. A security means for a vendor and a user is provided to prevent unauthorized use of the user's account, to prevent unauthorized downloading of content from a vendor site and to prevent unauthorized change of transaction data. Settlement of payments between the service provider 60 and the vendor 55 is aggregated and can be performed upon reaching pre-determined amount or time thresholds, thus reducing transaction costs. A service charge becomes relatively inexpensive even in a small amount of transaction. <P>COPYRIGHT: (C)2009,JPO&INPIT

Description

TECHNICAL FIELD OF THE INVENTION

  The present invention relates to a system and method for performing electronic commerce that requires micropayment to purchase a content item or service, and more particularly, it is simple, secure and private without incurring high transaction costs. Relates to a system and method for purchasing digital content in an efficient manner.

  Note that this application is a continuation-in-part of US patent application Ser. No. 09 / 753,784, filed Jan. 2, 2001, which is US patent application Ser. No. 09 / 665,237 filed Sep. 18, 2000. Which is a continuation-in-part of US patent application Ser. No. 09 / 553,695 filed Apr. 21, 2000. This application also claims priority to US Provisional Application No. 60 / 178,239, filed Jan. 26, 2000, and US Provisional Application No. 60 / 311,446, filed Aug. 9, 2001. .

Conventional technology

  The Internet and the World Wide Web (hereinafter “Web”) have brought about dramatic changes in the way information is transmitted and shared. The Internet allows millions of users around the world to access a great variety of information at the same time and perform extensive history such as shopping, games and financial transactions, among others.

  Users can access Internet information through various “Internet appliances”, which are electronic devices equipped with an Internet access system. Internet appliances include, but are not limited to, microprocessor-based devices such as personal and portable computers, and handheld appliances such as personal digital assistants (PDAs) and electronic organizers.

  Typically, access to information is via a connection to a “web page”, which is a multimedia composition displayed to the user on the “web browser window” by the “web browser software”. Do. Under the user's control, the web browser software establishes a connection over the internet between the user's internet appliance and the “web server”. This connection is used to download data representing the web page from the web server to the user's internet appliance. Web pages can include text, audio, graphics, images and videos, and any type of content representation that can be experienced through the use of a computer or other electronic device. Web pages can also be interactive, or can be used to send user-selected links to display other web pages, or to send information from a user to a web server. It can also contain forms, interactive executable code, or other elements that allow the user to interact with the web page. A “web site” refers to a group of one or more interconnected and closely related web pages, such as all web pages that contain information about a company, provided on one or more web servers Call it.

  Currently, many of the rapidly growing web sites for users are electronic commerce (“e-commerce”) web sites that offer a variety of content, services, and tangible goods for sale. Such content includes, but is not limited to, newspaper articles, music, movies, games, videos, and software, or other intangible items that can be purchased and delivered in electronic form. Examples of services offered for sale on an e-commerce web site include online technical support, medical and legal advice, and personal fitness training, among others. Tangible goods offered online range from books, clothes, food, and toys to more expensive items such as artwork, cars, homes, and furniture, and other items that can be shipped directly to consumers. .

  Electronic commerce involving tangible products typically involves an “e-commerce aggregator” web site where the user visits the e-commerce web site directly or displays a list of e-commerce web sites for various product categories. It starts with visiting the site. For example, users can go to the Amazon.com website and purchase books directly from Amazon.com, Inc. in Seattle, Washington, or maintained by Yahoo !, Inc. in Sunnyvale, California. You can go to the online shopping e-commerce aggregator website and search for books at many online bookstores, including Amazon.com and Barnesandnoble.com.

  In order to complete an e-commerce transaction that leads to the purchase of one or more tangible goods, the user typically follows two steps: The first step is to take time to browse the e-commerce website and search for the desired tangible product, depending on the internet traffic conditions at that time, the design and convenience of the website Can take several seconds to several hours. The tangible items selected by the user are collected in an electronic “shopping cart”, which, like a grocery store shopping cart, is selected by the user, including only what they want to view and purchase. Allows you to update the list of tangible products. In the second step, after updating the shopping cart, the user needs to go through a “checkout” process, in which the user will receive all relevant information needed to complete the transaction, e-commerce. • Enter on many forms provided on the website. Information required during the checkout process may include the user's name, address, email, payment information, and shopping information. Most e-commerce web sites also ask the user if they want to save this information for future web site visits in order to speed up the checkout process. The user can select a “login” user ID and password to be used for future purchases.

  Currently, there are many ways that a user can choose to purchase a tangible product on an e-commerce site. The only payment method available with the most popular payment methods is credit card payment, and the user only needs to provide a credit card number to the e-commerce web site. The e-commerce web site then confirms the credit card number via secure communication to the appropriate financial institution before completing the transaction. Other payment methods available to users include personal accounts established with vendors, gift certificates or electronic coupons, and a netcheck system developed at the Information Science Laboratory at the University of Southern California in Los Angeles, California. There are proposed electronic checks, the use of several types of electronic currency, and the use of electronic payment services provided by various Internet payment service providers.

  The simplest of these payment methods is that the user establishes a personal account with each e-commerce vendor. The user has a separate account for each vendor, and the vendor maintains an account for each customer. When a user purchases a product at the vendor's web site, the user opens an account and the vendor adds the cost of the product to the user's account. The vendor maintains account information and bills the user periodically.

  Other payment methods that users can easily use include “Digicash” proposed by eCash Technologies, Inc. in Bothell, Washington, and “InternetCash” (Internet Cash) proposed by InternetCash Crop. ) "And electronic currencies such as" Beens "proposed by Beenz.com, Inc. of New York, New York. DigiCash currency and Internet cash currency are issued to users by selected banks and are used on selected e-commerce websites to purchase tangible goods without using credit cards be able to. The DigiCash currency system relies on encryption and signature technology to authenticate users and ensure the security of payments made in DigiCash. The user may exchange any amount of real currency for the digital cash, but the Internet cash can be purchased only with a predetermined ticket type using a prepaid card. Both DigiCash and Internet Cash require users and e-commerce web sites to make arrangements with authorized banks to convert between electronic and real currencies.

  Unlike DigiCash and Internet Cash, Beans currency cannot be purchased by the user, but rather visits a specific web site, shopping online at a selected site, and other types of It can only be acquired by the user as an incentive for online history. The user can then purchase the merchandise at the selected web site using the acquired bean currency, which can be converted to the actual currency by the e-commerce vendor only through an authorized bank.

  Many patents related to electronic currency have been issued. Among them are U.S. Pat. No. 5,983,207 to Turk et al. And U.S. Pat. No. 5,671,364 to Turk, which are either gold or gold held in a central location. Describes an electronic currency system based on some other product. U.S. Pat. No. 4,977,595 to Ohta et al. Describes an encryption technique that can be used by banks to issue electronic cash. As with the other electronic currency systems described above, the methods described in these patents use a central institution such as a bank to manage user accounts and process transactions. Such an electronic currency system naturally has an overhead cost in that both vendors that accept these various forms of electronic currency and users who purchase products in exchange for electronic currency must deal with central institutions such as banks. Is required. Further, in such a system, the operation is complicated, and it is not possible for the user to purchase the content online only by clicking the content URL. These systems require the user to go through a lot of processing for simple content purchases that cost only a few cents.

  Another approach that can be used to make online payments for the purchase of tangible goods is provided by various systems developed by Internet payment service providers. One such system is provided by RocketCash Corporation of Mountain View, California. The RocketCash system allows users to open an account on a web site and put money into the account using a check, money order or credit card. The user can then purchase tangible goods at one of the e-commerce web sites listed on the Rocket Cash web site that accepts payments through a Rocket Cash account. An e-commerce web site that accepts a rocket cash account must first pass the rocket cash web site in order for users to connect to the e-commerce web site listed on the rocket cash web site. It is managed by the Rocket Cash web site so that it does not. Users are also awarded redeemable points called “RocketFuel” as an incentive to use rocket cash accounts, just as they are awarded frequent flyer miles at airlines. Rocket cash can also provide discounts to users at selected e-commerce web sites.

  Other payment methods that users can easily use include “c2it” developed by Citigroup, Inc. in New York, NY, and “PayPal” developed by PayPal, Inc. in Palo Alto, California. Electronic person-to-person ("P2P") systems. The “c2it” and “paypal” P2P systems are used to send funds online from one person to another via email. The user can send funds to another user who opened an account, similar to Western Union electronic money transfer. The user deposits funds into his / her bank account and / or credit card and then sends the funds via his / her email address. This remittance still relies on a third-party bank to facilitate the transfer of funds. Such a P2P system is used to transfer money from a buyer to a seller when purchasing a tangible product from an auction site or the like. These systems are not suitable for purchasing online content easily.

  As explained above, there are various payment methods available for purchasing tangible goods on e-commerce web sites, but these payment methods are not suitable for online purchase of content. Unlike most tangible products that are offered for sale online, content is usually provided free of charge and bundled with other content in a subscription-based model, or for permanent use, rental use, Or they are priced on a per-view basis. In addition to content, services such as online technical support may also be provided on a pay-per-use basis.

  The price of each content item may be from a few cents to a few dollars or less than a cent. These prices for content are much less than the typical charges associated with processing credit card transactions or subscription-based models. Therefore, these payments are called “micropayments”.

  For e-commerce transactions that require micropayments, personal accounts may be on the vendor's website, credit card payments, electronic currency, and various systems provided by the Internet payment service providers described above. There is a need to provide a payment method that does not incur the overhead costs of processing charges and fees that are common. Credit card companies settle payments immediately at the time of commerce, regardless of purchase price, thereby reducing the cost of settlement of payments and the overhead that credit card companies manage millions of micropayments and credit card charges・ Because costs are uneconomical, purchasing content, tangible goods or services that require micropayments using a credit card is not feasible. Credit card companies may also offer various features such as accounting for individual products, insurance, and fraud protection that increase overhead costs and are not necessary for micropayment transactions. Another problem with using credit cards to make micropayments is that users are reluctant to give credit card numbers to vendors that they do not know or trust. Although a credit card can insure a user against any loss, the user will still suffer from the processing disadvantages associated with the credit card.

  Using electronic currency to make payments for micropayment transactions means that users and content can rely on central banking institutions to exchange electronic currency for real money and vice versa. This is also not economically feasible because the transaction costs associated with currency exchange fees and other fees sought by providers and charged by central banking institutions can be higher than micropayments themselves. In addition, since the central banking organization manages the issuance of electronic currency, e-commerce vendors that accept electronic currency sell the value of electronic currency, its selling price, and the conditions under which it can be purchased or to whom I do not have control over what to do. For example, users must make payments to banks or other third-party financial institutions for electronic currency, and both e-commerce vendors and users are subordinated and dependent on bank and third-party financial institution policies. Therefore, it is not always possible for an e-commerce vendor of a tangible product, content, or service to agree with the user on payment terms for electronic currency.

  The payment alternative provided by the rocket cash system also allows users to enter a rocket cash account through the rocket cash website before purchasing any merchandise on an authorized e-commerce website This is cumbersome for the user because it is necessary. If the user wants to make a few cents of micropayment only once, the user still deposits into the rocket cash account with a credit card, check, or money deducted from the money order before making the micropayment. It is requested. Because payments are settled immediately, the user suffers all overhead costs associated with credit card, check and money order payments, as well as transaction cost issues.

  Another problem with using a rocket cash system to process micropayments is that an e-commerce web site that accepts a rocket cash account as a payment will have a shopping cart and checkout process to complete the transaction. Is to request. When browsing various e-commerce websites that offer to sell news archives articles, for example, a shopping cart may be used at every site to perform a check-out process and one or more e-commerce Purchasing an article or group of articles from a web site is generally not practical for users. Also, browsing from one web site to another web site, surfing, and going back to the first web site to purchase an article you are viewing or browsing will make your shopping cart The purchase of such articles used would be lengthy and time consuming. If a news article is priced at only 5 cents, for example, the user can click on the title of the article, pay for it, and immediately read and / or print it within a few clicks. Would want. The user will then want to move on to research or browse other articles provided on the same or different web sites.

  In the case of music, for example, a user wants to download one or several songs while surfing the web site of a different content provider, but promises to subscribe using a shopping cart or all CDs You may not always want to buy. Whether the user uses a shopping cart or not, if the user needs to go through a checkout process, this process makes purchasing content very inconvenient, lengthy and time consuming. This discourages users from continuing the content purchase process.

  In the system proposed by Rocket Cash, there is difficulty in processing micropayments related to the purchase of content using a credit card, electronic currency, or Internet payment service provider system, and the content is offered for sale • Most providers use a subscription-based pricing model. A subscription fee model is typically sufficient to justify the use of a credit card for payment and charges each user for a fixed monthly, quarterly or yearly fee. Examples of content providers that provide content to users based on subscription fees include the Wall Street Journal in New York, NY and EDGAR Online, Inc. in New York, NY. In addition to subscription fees, the Wall Street Journal also requires users to pay a premium for Journal Archives articles.

  However, such a subscription-based model is also not suitable for handling micropayment transactions. First, because the subscription method does not limit how much content each user can download during the subscription period, each user can download an unlimited number of content items without worrying about the cost of every item As it can, subscription-based models are significantly uneconomical and prohibitively expensive. Second, the subscription-based model does not provide the user with the flexibility to purchase content on time or from various content providers without having to subscribe to any content provider's website. . Users do not know in advance that they will use a given content provider's web site frequently enough to justify a large subscription fee and time to register a subscription on the site There is a case.

  Finally, when downloading an unlimited amount of content based on subscription payments, it is not possible to easily distribute royalties based on a single fixed fee, so intellectual property rights such as authors, publishers and musicians It is extremely difficult to pay the owner. Even if a content provider wants to pay royalties associated with each downloaded content, the content provider can easily identify the content and give it to the intellectual property owner of the content. There is only a limited way to calculate the associated royalties for payment.

  To address the need for a payment method that can efficiently process micropayment transactions, a number of systems focused on micropayment transactions have been developed. Such systems are offered by various micropayment service providers such as Magex Limited in London, UK, Compaq Computers in Houston, Texas, Clickshare Service Corporation in Williamstown, Massachusetts, and QPass, Inc. in Seattle, Washington. Includes provided systems. While all of these systems allow users and e-commerce vendors to conduct micropayment transactions online, there are several drawbacks that have so far prevented micropayment transactions from becoming popular on the web. is there.

  The system developed by Magex provides financial checkout services to support micropayment transactions, advanced multi-currency capabilities, multi-account funding options and flexible vendor settlements, purchased digital (eg, games, gambling) and physical Checking out both commercial products allows network operators to sell products, content and services such as games, pay-per-view movies, and information services. While browsing a web site, users can download music tracks, video games or novels. The Magex logo on the vendor's website informs the user whether the content is protected in a Digibox ™ container, ie a secure container that protects files from piracy. To open the file, the user needs to create a Magex wallet and download the software developed by Magex to create his own user ID and password. The user can put money in his wallet and pay for the downloaded music using the money in the wallet.

  The Magex wallet also provides a series of payment options that allow the user to choose between pay-per-play, renting content at set times, or unconditional purchases. However, the Magex system can only be used to purchase music and is limited to its own MP3 encryption system for the user's computer. The user cannot listen to music on any other MP3 platform such as an MP3 player. The user cannot purchase any other content in the open system format. The purchasing method also relies on a shopping cart and checkout process, which is inconvenient for online micropayment transactions.

  Another system that enables online micropayment transactions is the MilliCent system developed by Compaq Computer. The Millicent system is based on the Millicent Secure protocol for e-commerce over the Internet. This protocol is designed to support purchases of less than a cent, and for tangible goods, content, or services through simultaneous use of pay-per-click purchases, subscriptions, and advertisements. An e-commerce web site can be used to make a claim. This protocol can also be used to pay money directly to the user.

  The Millicent protocol allows users to purchase goods on an e-commerce web site through a broker acting as an accounting broker. Brokers were created specifically to mediate online financial transactions between online financial institutions such as banks and credit card companies, Internet service providers, or users and e-commerce vendors. There may be a single broker entity. Both the user and the vendor open an account with the broker, and the account opened with the broker is used as the payment mechanism. Such an account is called a “script” and consists of a signed message that authenticates that the script has a particular value.

  Unlike typical cash, the script includes other parameters such as an expiration date and the ID of a vendor that can redeem the script. That is, a script is only valuable when used with a specified vendor. The user first purchases a script at the broker and then uses the broker script at the vendor's web site to purchase a vendor script that can be used to purchase products at the vendor's site, You can purchase a script with a given value from a vendor. Since the vendor script has a pre-specified value, the user receives a “change script” whenever he purchases an item of value less than the script. Upon completing the series of transactions, the user can “cash” the remaining value of the script, ie close the account with the vendor. Brokers benefit from buying large amounts of vendor scripts at a discount and selling the vendor scripts to users at higher prices.

  The Millicent protocol is secure and designed to prevent vendor, user and broker fraud, but does not have the flexibility to direct users to the vendor web site to purchase goods . The overhead cost imposed on the user for having a large number of vendor accounts is compelling the user to think of a large number of vendors and make micropayment purchases. In addition, because the vendor script is only sold at a given value, the user establishes a relationship with the vendor in order to purchase one or several items of interest to the user at a price less than the value of the script. You may not want to do that. Also, the Millicent system gives too much control over the broker and places extra costs and overhead costs on users who must first purchase the broker script before they can purchase the vendor script. Finally, before a user can make a single micropayment transaction of several cents, he must first purchase a broker script with a credit card, check or money order, so credit card, check and money order It still suffers from all of the overhead transaction cost issues associated with payments in Japan.

  The micropayment system provided by ClickShare allows users to purchase content on participating websites listed on a website maintained by ClickShare without first having to put funds into the account. By eliminating online micropayments, this problem is eliminated. The user must first register with the “most trusted” participating vendor to open a clickshare account with a username and password. The user specifies a credit card number that is charged by clickshare only after having made enough transactions that are of a sufficiently high value in total. Clickshare accounts opened on the most trusted websites will be made available to all other participating vendors by entering the user's name and password only once on each vendor's website before purchasing the content item. Can be used. Subsequently, the user can purchase content items from the same web site without having to re-enter the user's name and password for each content item to be purchased. The most trusted websites are newspapers, internet or wireless service providers, banks, associations, retailers, postal mail, or specialized publishers that sell or resell text, music, video, multimedia, software or services. There may be.

  The main advantage of the clickshare system is that it allows users to make online purchases without having to disclose personal information to the vendor. This allows users to purchase various content anonymously without having to worry about personal information being used by vendors for marketing or other purposes. Another advantage is that clickshare brings together all of the content purchases the user has made in his clickshare account so that purchases are withdrawn from the user's credit card only once a month. However, if a user makes a single purchase less than one cent in a given month, the transaction cost and processing fee to debit the purchase on the user's credit card can be higher than the purchase price. . This can impose an unnecessary minimum limit on the price of content charged by the vendor.

  Clickshare also allows vendors to provide content volume discounts to users so that they can purchase a large number of content items at a discounted price for a specified period of time. For example, a user can purchase "60 articles for $ 9.95 over the next 12 months, each less than 17 cents" on the Dallas News web site. Such volume discounts are similar to subscription fees and have the same drawbacks associated with using subscription-based models for micropayment transactions.

  Yet another disadvantage of clickshare systems is that once a user selects a content item to purchase, such as a newspaper article that can be viewed online, the clickshare system records the transaction, but the user later If you want to see the same content item at, do not let the user know that the content item has already been purchased. As a result, a user may receive a large number of duplicate charges on his clickshare account. Even though users can contend for duplicate charges at a later date by checking account transactions on the clickshare website, clickshares will charge multiple charges before purchasing multiple copies of the content item. There is no way to prevent this.

  Also, purchased content items are managed by click share rather than by content providers. Once a content provider's content item is purchased in a clickshare account, the content provider loses control of the content and distorts it before the content item is viewed by the user on the clickshare website. There is no way to know if it has been done. Clickshare web sites do not provide any security mechanism to lock purchased content in order to prevent users from freely distributing purchased content items to other users. When the URL corresponding to the content item is distributed to others, there is no way for the user to know if someone else will see the article for free or purchase the article in the user's account.

  The system provided by Qpass eliminates clickshare system security issues by locking purchased content into the user's cuepass account that can be opened by registering at the vendor's site. Yes. That is, once a user purchases a given content item, the URL corresponding to that content item cannot be distributed to others without the user's account login information. The user is required to show account login information each time before viewing a previously purchased content item. Other features of the CuePass system that offer advantages over the clickshare system include multilingual and multicurrency, where each user selects a single language and currency for online cuepath purchase applications. Such as the ability to provide to the user and the ability to prevent duplicate charges for content items already purchased by the user.

  The CuePass system allows users to purchase directly from an e-commerce vendor's web site by logging into that cuepass account without having to first visit the CuePass web site. Similar to the system provided by clickshare. The CuePass system also organizes micropayment purchases made by the user so that the user is charged for the purchase only once a month. Users can also view their current account history online on a web site maintained by CuePass, including links to purchased content items. CuePass also provides volume discounts to allow users to purchase a large number of content items, such as articles offered at the New York Times Archives in New York, New York, at discounted prices over a specified period of time. Yes. Such volume discounts have the same drawbacks associated with using subscription-based models for micropayment transactions.

  The cue path system has the same disadvantage as the click share system in that content items purchased by a user using a cue path account are managed by the cue path rather than the content provider. That is, once a content item has been purchased in a CuePass account, the content provider loses control of the content and there is no way to know if the content item has been distorted before being viewed by the user. . The CuePass system also debits the user's purchase once a month on the user's credit card, so if the user makes a purchase less than 1 cent in a given month, the transaction cost and The processing fee for debiting purchases on the user's credit card may be higher than the purchase amount. This can impose an unnecessary minimum limit on the price of content charged by the vendor.

  The CuePath system also requires the vendor to install the client on the vendor's website to provide the Cuepass micropayment service to the vendor's users, thereby allowing the Cuepass client to be installed on the web. • It can take a great deal of time and effort on the part of the vendor to properly configure on site. The cuepath system also has the disadvantage of allowing users to disclose their personal information to a vendor web site. This prevents users from making online micropayment purchases anonymously, a feature often required by users who do not entrust personal information to many vendors.

  To date, there are no micropayment systems that provide users with full privacy and security when conducting micropayment transactions on many e-commerce vendor websites. Current micropayment systems also do not allow users to use multiple currencies and languages when conducting micropayment transactions on websites around the world. Also, the micropayment system described above often requires vendors to install a micropayment client on the vendor's web site, and a significant amount of money is required to properly configure the micropayment system. Vendors are forced to invest mounting time and effort. The micropayment system described above also gains control over the content item provided by the vendor once purchased by the user. There is also no micropayment system that collects user purchases and charges the user's credit card only after the minimum limit is reached, rather than once a month. In addition, content content that allows a user to purchase one or more content items from different vendors seamlessly without requiring the user to log in for each vendor site and perform a checkout process. There are no providers so far. In summary, it is extremely difficult and time consuming for users to conduct micropayment transactions online using currently available micropayment systems.

  In view of the foregoing shortcomings, it would be desirable to provide a system and method that facilitates micropayment transactions easily and seamlessly on a number of electronic commerce web sites to purchase tangible goods, content, or services.

  It would also be desirable to provide systems and methods that allow users to conduct micropayment transactions on multiple e-commerce web sites without having to disclose personal information to the web sites.

  Unauthorized use of a user's client computer, unauthorized viewing, modification, or downloading of content from a content provider web site to purchase content on a content provider web site It would also be desirable to provide a system and method for securely conducting micropayment transactions by preventing this.

  Allows e-commerce vendors to price Internet content for amounts less than a few cents, a few dollars or even a cent and requires users to pay a subscription fee to access the content It would also be desirable to provide a system and method that allows the user the flexibility to provide a single article, publication, song, video game, movie, and the like.

  A system and method that allows a user to purchase content priced in less than a few cents, a few dollars or even a cent without having to send credit or banking information with each purchase It is also desirable to provide.

  Users can easily register with a micropayment service provider and request micropayment to that micropayment service provider without requiring online communication with a bank or other financial institution to complete the micropayment transaction. Open an account, fund the account using various payment methods, and use the funds from the account to conduct micropayment transactions on multiple e-commerce websites in multiple currencies and other languages It would also be desirable to provide a system and method.

  The content provider can access the micropayment service provider from the user's micropayment account without having to provide content control or install a micropayment service provider client on the content provider's website. It would also be desirable to provide systems and methods that allow payments to be accepted.

  See an immediate overview of a user's account, place funds in that account, verify micropayment transactions recorded in that account, get refunds for any mischarged transactions, and make micropayments in that account It would also be desirable to provide systems and methods that allow users to manage their micropayment accounts by specifying per-transaction, daily, weekly or monthly usage limits for the transactions.

  Provided is a system and method that enables users to conveniently purchase content from different content providers without requiring the user to log in or perform a checkout process for each content provider web site It is also desirable to do.

  Using the account summary provided on the micropayment service provider web site web page, without requiring the user to revisit the content provider web site for the purchased content, the user It would also be desirable to provide systems and methods that allow easy access to already purchased content.

  In order to minimize the cost per e-commerce, the micropayment service provider will use the amount or time limit to bundle the e-commerce in the user's micropayment account for payment settlement with the vendor It would also be desirable to provide systems and methods that enable.

  For each content item sold on the content provider's website, each content provider can pay their royalty for their intellectual property owners such as authors, publishers and artists It would also be desirable to provide a system and method.

  In view of the above, it is an object of the present invention to provide a system and method for easily and seamlessly performing micropayment transactions on a number of electronic commerce websites to purchase tangible goods, content, or services. It is.

  Another object of the present invention is to provide a system and method that allows a user to conduct micropayment transactions on multiple e-commerce web sites without having to disclose personal information to the web sites. .

  Another object of the present invention is to unauthorized use of a user's client computer to purchase content on a content provider's web site, or unauthorized use of content from a content provider's web site. It is to provide a system and method for securely performing micropayment transactions by preventing viewing, modification and downloading.

  Another object of the present invention is to allow e-commerce vendors to price Internet content for amounts less than a few cents, a few dollars or even a cent, and such vendors subscribe to access the content. It is to provide a system and method that allows the user the flexibility to provide an article, publication, song, video game, movie, etc. without requiring the user to pay.

  Another object of the present invention is that a user purchases content that is priced less than a few cents, a few dollars or a cent without having to send credit or banking information with each purchase. It is to provide a system and method that enables it.

  Another object of the present invention is that a user can easily register with a micropayment service provider without requiring online communication with a bank or other financial institution to complete a micropayment transaction. Open a micropayment account with a payment service provider, fund the account using a variety of payment methods, and use the funds from that account to create micropayments on many e-commerce websites in multiple currencies and multiple languages It is to provide a system and method that allows payment transactions to be conducted.

  Another object of the present invention is to provide a content provider without the need to give the micropayment service provider content control or install a micropayment service provider client on the content provider's web site. Is to provide a system and method that allows a user to accept micropayments from a user's micropayment account.

  Another object of the present invention is to look at an immediate overview of a user's account, fund the account, verify the micropayment transaction recorded in the account, and receive a refund for any transaction that was incorrectly charged. A system and method for allowing a user to manage his micropayment account by specifying usage limits for that account on a per-transaction, daily, weekly or monthly basis for micropayment transactions conducted in that account Is to provide.

  Another object of the present invention is to allow users the convenience of purchasing content from different content providers without requiring the user to log in or perform a checkout process for each content provider web site A system and method is provided.

  Another object of the present invention is provided on the web page of the micropayment service provider web site without requiring the user to revisit the content provider web site for purchased content. It is to provide a system and method that allows a user to easily access content that has already been purchased using an account summary.

  Another object of the present invention is that the micropayment service provider uses the amount or time limit to minimize the cost per electronic commerce, and the user's micropayment account for payment settlement with the vendor. A system and method that enables electronic commerce to be bundled together.

  Another object of the present invention is that for each content item sold on the content provider's website, each content provider has its own royalties to the intellectual property owners such as authors, publishers and artists. To provide a system and method that allows paying as a reward.

  These and other objects of the present invention provide a system and method for easily and seamlessly performing micropayment transactions on multiple e-commerce websites to purchase tangible goods, content, or services. Is achieved. A micropayment transaction is a payment for a tangible product, content, or service that is on the order of a few cents, a few dollars, or less than a cent, and much more than the typical charge associated with a credit card transaction. This is a small transaction. The system and method of the present invention provides for the use of electronic tokens provided by a user by a micropayment service provider (“MSP”) or an electronic commerce vendor to tangible goods, content, or services on an electronic commerce website. It consists of a software solution that allows online micropayment transactions for purchases and is provided by MSP. The electronic token awarded by the MSP is an electronic certificate that is accepted by all e-commerce vendor web sites to allow users to purchase tangible goods, content, or services. Electronic tokens given by e-commerce vendors are intended for user incentives, and only at certain e-commerce vendor sites to enable users to purchase tangible goods, content, or services Accepted electronic authentication.

  In a preferred embodiment, the system and method of the present invention includes three main software components: (1) a micropayment server, (2) a micropayment account user interface, and (3) a micropayment Vendor API is involved. A micropayment server is an e-commerce vendor web site designated by the MSP as allowing a user to make purchases using a micropayment account, and includes tangible goods, content, Alternatively, a micropayment user account can be easily opened to the MSP to store electronic tokens that can be used to purchase services. A micropayment user account can be opened online by the user at a web site maintained by MSP, or through an e-commerce vendor web site authorized by MSP, or an MSP customer service representative Can be opened through. The micropayment server also maintains a micropayment vendor account for each vendor that accepts electronic tokens as a payment method.

  When opening a micropayment user account, payment options, such as by providing a credit card number, where users register their personal information and first place funds into the micropayment user account Select. A user can have several micropayment user accounts, each account being used for a different currency. Funds can be entered in multiple currencies so that a given number of real currency units correspond to electronic tokens. For example, a user can put $ 10 into his account to purchase 100 articles for $ 0.1 each. For each article purchase worth $ 0.1, the user is given an electronic token by the MSP to purchase the article on the content provider's web site. Users can also purchase tangible goods, content, or services using their micropayment user account before funding the account. The MSP can also give the user a sign-up bonus when the user opens his / her user account.

  Users can verify their micropayment user account history by accessing the micropayment account user interface provided on the MSP web site. Alternatively, the user can download the client to his Internet appliance so that his account history can be verified for instant access to his account by contacting an MSP customer service representative. The user interface, among other things, allows users to register with MSP, select multiple languages for multi-currency and funding their accounts using multiple payment methods, and conduct micropayment transactions online, Allows daily, weekly or monthly usage limits to be selected and recorded transactions confirmed with MSP. The micropayment user interface can also be accessed by the vendor to manage the vendor account with the MSP.

  The micropayment vendor API allows the e-commerce vendor web site to connect to the MSP server while the user is purchasing tangible goods, content, or services at the e-commerce vendor web site. , Consisting of several function calls provided by MSP to its e-commerce vendor. The API allows vendors to easily provide micropayment services to users without having to install separate client software provided by MSP. The vendor only makes an API function call when a user who wants to purchase a product at the vendor's web site clicks on a link or button on the web site that corresponds to the product they want to purchase.

  For example, when a user wants to purchase a news article on a news web site, simply click on the URL of the article and execute an API function call that sends the news web site information and the article information to the micropayment server. be able to. Upon receipt of the news web site information, the micropayment server confirms the vendor and then displays a “buy” window where the user confirms or cancels the purchase. A buy window can include parameters such as the headline or brief description of the article to be purchased, its price, and whether there are any incentives offered to the user to purchase the article, among others. Contains information. Upon confirming the purchase, the micropayment server verifies the user's login information, micropayment account balance, and other security mechanisms. The micro server then sends an authorization to the news web site to grant the user access to the article to be purchased. Finally, the news web site displays and downloads articles on the user's Internet appliance. The news web site allows users who purchase it to copy the URL of the article and send it to other users to prevent other users from seeing the article without having to make a payment. You can also lock down articles. The micropayment server deducts the price of the use article purchased by the user from the account balance of the user. Also, when the price or time limit is reached, all content items sold to all users by the news web site are collected and the service charge minus the amount of the news content vendor's bank. Pay to news content vendors via

  The system and method of the present invention also provides a back-end interface for e-commerce vendors. This includes security features for the system administrator that associates each function of this backend interface with a security level or security function. A system administrator login can be provided with a security profile that enables only a specific subset of possible security functions that require performing certain tasks.

  To protect the user's personal information from being disseminated to participating vendors, the system and method also allows the user to choose whether to give the vendor their email address in order to receive information about the vendor I have to. The system sends an email to the user at the end of the day that the user has made some commercial transaction, and if the user purchases an item from the vendor, the email includes a hyperlink to the vendor's web site.

  The system and method of the present invention provides the user with the convenience of minimizing the interaction between the user's Internet appliance and the vendor's server computer while also reducing the vendor's overhead costs. Because all purchases or transactions are made using tokens, little or no personal sensitive information, such as a user's credit card number, needs to be transmitted over the Internet. Information transmitted over the Internet may be encrypted, but such transmissions may be intercepted and decrypted, so it is desirable to eliminate or minimize them.

  In addition, since the user's personal information is stored only in the MSP by directly interacting with the registration, purchase and use of the electronic token, the user can store his / her personal information with a third party such as a bank or others. There is no need to provide it to any vendor. This gives the user even greater security and privacy.

  Yet another advantage of the system and method of the present invention is that it does not require the user to pay with his / her credit card, so that the user has a credit card, or the user and vendor are banks or other It is unnecessary to interact with other financial institutions to process credit card transactions. Since online purchases can be processed without credit card transactions, the overhead costs associated with such transactions can be reduced or eliminated, thus enabling micropayments. In addition, because the small purchase is paid with a token, the vendor does not need to incur invoices or incur other overhead costs associated with processing financial transactions with small purchases.

  The foregoing and other objects of the invention will become apparent from the following detailed description when read in conjunction with the accompanying drawings. In the accompanying drawings, like reference numerals designate like parts throughout.

Embodiment of the Invention

  Referring to FIG. 1, an illustration of parties and relationships in performing a micropayment transaction in accordance with the principles of the present invention is shown. Electronic commerce buyer 50 visits a web site provided by electronic commerce vendor 55 and uses an electronic token issued by micropayment service provider 60 to purchase tangible goods, content, or services. It is. Therefore, in the following, the electronic commerce buyer 50 may be referred to as a user 50. E-commerce vendor 55 is a content provider such as Washington Post in Washington DC, an online store such as Amazon.com in Seattle, Washington, an online service provider such as Expertcity, Inc. in Santa Barbara, California, or California Any e-commerce aggregator such as Sunnyvale's Yahoo !, Inc.

  A micropayment service provider (“MSP”) 60 provides services to the user 50 and e-commerce vendor 55 to allow them to conduct micropayment transactions online using an electronic token awarded by the MSP 60. To. An electronic token is an electronic authentication provided by the MSP 60 that is accepted by the electronic commerce vendor 55 and allows the user 50 to purchase tangible goods, content, or services using them as a payment method. The user 50 can purchase an electronic token directly from the electronic commerce vendor 55 or the MSP 60. Electronic tokens purchased by the user 50 are recorded in a micropayment user account maintained by the MSP 60. User 50 can open a micropayment user account in MSP 60, register personal information in MSP 60, select a login ID and password to access the account, and use MSP 60 to purchase electronic tokens The number of payment methods available. Such payment methods include both online payments using automatic debits on credit cards or personal bank accounts, and offline payments using checks, money orders or purchase orders. MSP 60 also maintains a micropayment vendor account for vendor 55.

  The user 50 may also select multilingual and multicurrency options for purchasing electronic tokens at the MSP 60 and options such as per-transaction, daily, weekly or monthly usage limits. In a preferred embodiment, the MSP 60 opens several micropayment user accounts for the user 50, one for each particular currency selected by the user 50. For example, user 50 may be a micropayment user account where all electronic tokens recorded in the account are purchased in US dollars, or another micropayment user where all electronic tokens recorded in the account are purchased in Japanese yen. You can have an account.

  In addition to the micropayment account and electronic tokens issued to the user 50, the MSP 60 also provides the user 50 with a micropayment account user interface that allows the user 50 to manage his micropayment account. The user interface can be any offline site such as a web site maintained by the MSP 60, a client downloaded to the user's Internet appliance by the user 50, an interactive voice response system, or an MSP 60 customer service representative. It can be a contact. The user interface allows the user 50 to obtain a history of past and current transactions in their various accounts, including links to content items purchased online, Allows verification of recorded transactions and selection of account history, such as account usage limits. The user interface can also be accessed by vendor 55 to maintain its micropayment vendor account.

  The MSP 60 can also issue a sign-up bonus and incentive to the user 50 for purchasing tangible goods, content, and services at the e-commerce vendor 55. In a preferred embodiment, the sign-up bonus is an electronic token that is issued to the user 50 when the micropayment user account is opened to the MSP 60, while the incentive is an electronic token provided by the MSP 60 and An electronic token issued to the user 50 at the discretion of the MSP 60 and / or the vendor 55 to encourage the user 50 to purchase additional goods, content, or services at the vendor 55 using the service. In order to allow vendor 55 to provide electronic tokens to user 50 as a payment method, MSP 60 provides vendor 55 with a micro-payment service as a basis for performing micropayment services on vendor 55's website. Provides payment API and code samples. The micropayment API will be described in further detail below.

  When the user 50 clicks on a link corresponding to a tangible product, content item, or service that the user 50 purchases, the vendor 55 credit information and transaction parameters are sent to the MSP 60 using a micropayment API function call. Upon receiving the vendor 55 credit information, including the vendor ID assigned to vendor 55 by MSP 60, vendor 55 password and URL, MSP 60 will receive the tangible product, content item, Or verify whether you are authorized to sell the service. Once the vendor 55 trust is verified, the MSP 60 displays a “buy” window on the user 50 Internet appliance. The buy window can display various transaction parameters including, for example, the title of the content, the price of the content and a brief description. The user 50 can proceed with the purchase of the content item from the vendor 55 by clicking the “buy” button displayed in the buy window. To prevent the user 50 from copying the URL of the content item and sending it to other users who do not pay for the content item, use the micropayment API function call to the user 50 You can also lock content items.

  When user 50 clicks the buy button displayed in the buy window, MSP 60 verifies user 50's micropayment user account and authorizes the transaction. Once the user's 50 account is verified, the MSP 60 allows the vendor 55 to close the transaction. At any point during the transaction, the user 50 is not required to register personal information with the vendor 55. If the user 50 has purchased a tangible product from the vendor 55, the shipping information regarding the product will be sent to the user 50 or MSP 60, depending on the privacy agreement that the user 50 entered into with the MSP 60 at the time of opening their user account. May be transmitted to the vendor 55. If the user 50 chooses not to disclose any shipping information to the vendor 55, the vendor 55 may have to ship the product to the MSP 60 so that the MSP 60 can ship the product to the user 50. . Other methods of disclosing shipping information to the vendor 55 can be provided without necessarily disclosing the personal information of the user 50 to the vendor 55.

  In a preferred embodiment, when the user 50 first logs into the MSP 60 before purchasing goods, content, or services online, the MSP 60 encrypts the login ID of the user 50 and provides the encrypted user ID to the user 50. Write to your Internet appliance. The encrypted user ID expires and is erased for a predetermined period of time to prevent any unauthorized user from performing a micropayment transaction using user 50's Internet appliance. Before the predetermined period of storing the user's 50 ID on the user's 50 Internet appliance expires, the user 50 browses various vendor web sites and purchases several products at various web sites. In the meantime, the user 50 needs to perform the login process only once.

  MSP 60 may also provide vendor incentives to vendor 55 to encourage vendor 55 to provide vendor 55 with an electronic token as a payment method and attract more users to sign up with MSP 60. The MSP 60 also settles with the vendor 55 payments for the user 50 and all other users that use the electronic token to make purchases at the vendor 55 web site. The payment settlement with the vendor 55 for the user 50 and all other users who have made purchases from the vendor 55 is performed only when one of the two limit values is reached. These limit values are: firstly, the total purchase amount of the user 50 and all other users is sufficiently high (amount limit value), and secondly, once a month to reduce the frequency of payment settlement. A sufficiently long period interval (time limit value). Payment settlement at the time limit value may not be performed when the total amount has not reached the amount limit value. Since these limit values may be individually agreed between the operator of the MSP 60 and each vendor, these limit values may be different for each vendor.

  Referring to FIG. 2, a schematic diagram of a system and network environment in which the present invention operates is shown. Users 65a-d are connected to a network 70, preferably the Internet, for the purpose of purchasing or renting tangible goods, content, or services from electronic commerce vendors 75a-c. A user 65a connects to the Internet 70 using a personal computer, a user 65b connects to the Internet 70 using a notebook computer, and a user 65c connects to the Internet 70 using a personal digital assistant (PDA). 65d connects to the Internet 70 using a wireless device such as a mobile phone. Users 65a-d can also connect to the Internet 70 by a video game console and game center (not shown) or any other Internet appliance that can connect to the Internet 70.

  Users 65a-d use electronic tokens provided by the micropayment server 80 managed by the MSP 60 to use the web pages maintained by the e-commerce vendor web servers 75a-c to generate tangible goods, content, Or buy a service. The micropayment server 80 provides a micropayment server to each of the web servers 75a-c that provide an electronic token, which is one of the payment options for users 65a-d to purchase tangible goods, content, or services. Provide service.

  The micropayment server 80 also provides micropayment user accounts to the users 65a-d. Micropayment user accounts purchase tangible goods, content, or services at vendor web servers 75a-c that allow users 65a-d to make purchases using their micropayment user accounts. Stores electronic tokens that can be used to The micropayment user account may be opened by a user 65a-d online or on a web site maintained by the micropayment server 80, or via a customer service representative at the MSP 60. The micropayment server 80 also provides the vendor with a micropayment vendor account so that each vendor can manage their electronic token transactions.

  When a user 65a-d selects an electronic token as a payment option when purchasing or renting tangible goods, content, or services at a web site maintained by the vendor web server 75a-c, The web servers 75a-c connect to the micropayment server 80 via the Internet 70 to advance micropayment transactions. Software resident in the micropayment server 80 is executed by the vendor web servers 75a-c via function calls specified in the micropayment API provided by the MSP 60. The function call sends to the micropayment server 80 information regarding the vendors managing the vendor web sites 75a-c as well as information regarding purchased goods, content, or services. Does the software residing in the micropayment server 80 validate the information sent by the vendor and is the vendor 75a-c allowed to sell tangible goods, content, or services using electronic tokens? Check whether the user 65a-c has logged into the micropayment server 80, verify the login information, and does the user 65a-c have enough tokens to complete the transaction? Check. When all information is verified, the micropayment server 80 returns authorization to the vendor web servers 75a-c. Upon approval, vendor web servers 75a-c send and display purchase confirmation and / or download content to users 65a-d. This completes the micropayment transaction.

  Referring to FIG. 3, a schematic diagram of the software components used in the preferred embodiment of the present invention is shown. The software components comprise (1) a micropayment server 80, (2) a micropayment account user interface 85, and (3) a micropayment vendor API 90.

  Micropayment server 80 allows a user to easily open a micropayment user account in MSP 60. A micropayment user account is an electronic commerce vendor web site designated by the MSP 60 as allowing a user to make a purchase using their micropayment user account, and a tangible product, content, or service It stores electronic tokens that can be used to purchase. The micropayment user account can be opened by the user online, on a web site maintained by the MSP 60, or through a customer service representative of the MSP 60. The micropayment server 80 also maintains a micropayment vendor account for each vendor that accepts electronic tokens as a payment method. The micropayment server 80 can be operated by an MSP 60, a third party Internet service provider, or a utility company such as a telephone company or a power company.

  When opening a micropayment user account, the user registers his personal information and a credit card number to initially fund his micropayment user account. Funds can be entered in multiple currencies so that a given number of currency units corresponds to an electronic token. Users can also purchase tangible goods, content, or services using their micropayment user account before funding the account. The MSP 60 may also provide a sign-up bonus to the user when the user opens his micropayment user account. As described below, the user's account and personal information is maintained by several databases within the micropayment server 80. These databases also manage payment settlement between users, vendors and MSPs 60, and also contain information about each vendor that accepts tokens as a payment option. These databases also store data corresponding to all transactions between users and vendors, including electronic tokens from vendors and purchases of users of tangible goods, content, or services. These databases also store the amount of royalties to be paid to content authors, publishers, artists, or other intellectual property owners.

  Micropayment account user interface 85 allows the user to verify and manage his micropayment user account history. The user interface 85 can be accessed via the MSP 60 web site. Alternatively, the user can download the client to his Internet appliance so that he can verify his account history for instant access to his account by contacting the MSP 60 customer service representative. The user interface 85, among other things, allows the user to register with the MSP 60, place funds into his micropayment account using multiple payment methods using multiple currencies, and select multiple languages for conducting micropayment transactions online. Allows you to select usage limits for each transaction, daily, weekly, or monthly, and perform account history such as contending with MSP 60 for recorded transactions. The user interface 85 also allows vendors to manage their micropayment vendor accounts, and allows the operator of the MSP 60 to manage all vendor accounts and user accounts.

  The micropayment vendor API 90 allows the e-commerce vendor web site to connect with the micropayment server 80 while the user purchases tangible goods, content, or services on the vendor web site. It consists of several function calls provided by MSP 60 to e-commerce vendors. In a preferred embodiment, the micropayment API 90 is invoked by a vendor to perform a service provided by the MSP 60 when a user clicks a link corresponding to a purchaseable content item, tangible product or service. Simple Object Access Protocol ("SOAP") function calls. The SOAP function call is contained in a web page designed by the vendor (using ASP / HTML / XML / Java script / PERL or other technology), and the vendor enters his web site. It enables electronic tokens to be provided as a payment method using a very simple and efficient mechanism without having to spend a lot of redesign time, money and implementation effort. API 90 allows vendors to easily provide micropayment services to users without having to install separate client software provided by MSP 60. The vendor only performs an API 90 function call when a user who wants to purchase a product at the vendor's web site clicks on a link or button on the web site that corresponds to the product he wants to purchase.

  For example, when a user wants to purchase a news article at a news web site, the user simply clicks on the article and sends information about the news web site and information related to the news article to the micropayment server 80. It is only necessary to execute the API 90 function call. Information about the news web site includes the news web site vendor ID assigned by the MSP 60, the vendor password, and the news article URL address. Once the news web site verifies that it is authorized to use an electronic token for the electronic transaction, the micropayment server 80 displays a buy-by window to the user to confirm or cancel the purchase. indicate. The buy-in window is, among other things, the news article, such as the headline and brief description of the article to be purchased and its price, and parameters such as whether there is an incentive provided to the user to purchase the article. Related information can be included. When the user clicks the buy button on the buy window, the micropayment server 80 checks whether the user has logged into the MSP 60. Upon verifying the user's login information, micropayment account balance and other security mechanisms, the micropayment server 80 sends an authorization to the news web site to grant the user access to the article to be purchased. Finally, the news web site displays and downloads the article on the user's Internet appliance. A news web site is an article that prevents users who purchase an article from copying the URL of the article and sending it to other users to view the article without the need for other users to pay. Another function call of API 90 can also be used that locks it down to the user who purchases it.

Those skilled in the art should understand that when an e-commerce vendor registers with MSP 60 to use the micropayment service provided by MSP 60, a micropayment vendor API 90 is provided to that vendor. At the time of vendor registration, the vendor can select a vendor ID and password, open a micropayment vendor account in the MSP 60, and provide an electronic token as a payment method to the user registered in the MSP 60. Vendors can access their micropayment vendor accounts by visiting the micropayment account user interface 85 maintained by the MSP 60 or by contacting the customer service representative of the MSP 60 by phone.
I. Micropayment Server Referring to FIG. 4, a schematic diagram of micropayment server software constructed in accordance with the principles of the present invention is shown. In the preferred embodiment, the micropayment server 80 runs a web server 100 that communicates with a number of web browsers across the Internet to provide access to web pages 95. Web page 95 may be a predetermined static web page, CGI script, servlet, or other that allows a web server to dynamically create or modify a web page. It may include web pages that are dynamically generated using techniques. For example, the web page 95 can be generated to include a list of vendors that accept tokens as payment options, extracted from the vendor database 125 in the database server 110.

  The micropayment server 80 also executes a web engine 105 that processes electronic tokens, as described in detail below. The web engine 105 communicates between the web server 100 and the database server 110 to process data about the user, the user's micropayment account, the vendor account, and other data about the electronic token, the user and the vendor. .

  The micropayment server 80 also executes a database server 110 that stores a user account number / vendor ID / transaction ID 115, a user database 120, a vendor database 125, and a transaction database 130. The database server 110 can also manage other databases and tables (not shown) for operating an e-commerce web site. Database server 110 also manages payment settlement between users, vendors and operators of micropayment server 80, as well as payment settlement to content authors, publishers, artists, or other intellectual property owners. To do.

  The user account number / vendor ID / transaction ID 115 is an index for user account numbers, i.e. for instant access to the corresponding user, vendor or transaction ID in the user database 120, vendor database 125 and transaction database 130. Includes login user ID, vendor ID, and transaction ID.

  User database 120 registers with a micropayment user account to use the token as a payment method to purchase tangible goods, content, or services from a vendor's website that provides the token as a payment option. Contains information about each user. Registration can be through a vendor web site or directly through a micropayment server 80 web page. Information about each user includes the user's name and other identifying information, an account number, and any personal information about the user, such as the credit card number, bank account information, phone number, address, etc. requested by the vendor. Information about each user also includes the user's preferred payment method for the token. Users can register with multiple micropayment user accounts, each account being traded in a different currency and a different language. For example, a user can open a micropayment user account to purchase a US dollar electronic token for use in an English website operated in the United States, or use it on a Japanese website operated in Japan. You can also open a micropayment user account to purchase Japanese yen electronic tokens.

  The system and method of the present invention can be used online or offline by providing a user's personal bank account number from which the user can debit using a credit card or the cost of purchasing a token. , Allowing electronic tokens to be purchased. When offline, payment methods include payment by check, money order, purchase order, bank wire transfer or cash, and credit card payments over the Internet. Other payment methods can also be used to purchase electronic tokens.

  If the operator of the micropayment server 80 is an Internet service provider (ISP) or a utility company such as a telephone company or a power company, the operator will pay the user's token purchase cost each month. Can be added to ISP fee or utility bill. In this case, a specific credit line that allows the user to purchase tangible goods, content, or services and pay for the purchase upon receipt of the monthly invoice is an ISP or utility. Given by the company. The user may use more than one credit card and may have multiple payment methods. Thus, the user database 120 stores user selections regarding payment and detailed user information.

  The user database 120 preferably also includes information regarding the number of electronic tokens available to each user. Available tokens may be multi-currency. Tokens include paid tokens that can be used for all vendor websites and incentive tokens that can only be used on the issuing vendor's website, which may or may not expire. The system and method of the present invention also allows a group of vendors to issue incentive tokens that can only be used by a particular group of vendors. The system and method of the present invention also allows the operator of the micropayment server 80 to issue incentive tokens that can be used on any vendor website that accepts tokens as a payment option. These incentive tokens may or may not expire. The user database 120 contains data regarding how the user has used tokens in the past and whether the user is a “preferred customer” who deserves discounts and other bonuses on token purchases, user confidence And the payment status and any other information that can assist the operator of the micropayment server 80 to process and track each user.

  Vendor database 125 contains information about each vendor that accepts tokens as a payment option. Typically, a vendor can only accept one type of currency used at the vendor's location. This information includes the vendor's name, address, who is authorized to access the micropayment vendor account, vendor bank name / account number, royalty rate, payment settlement limits and payment status, and the micropayment server 80 Contains other relevant information that allows the operator to provide services to each vendor. Vendor database 125 may also include sales records and content royalties for content authors, publishers, artists, or other intellectual property owners regarding content sold by vendors.

  The transaction database 130 relates to all transactions between the user and the vendor related to the user purchasing tangible goods, content or services from the vendor and to the user purchasing tokens from the micropayment server 80. Includes all transactions between the user and the operator or micropayment server 80. The transaction database 130 may also include a record of verifications (fights) involving the user and their resolution.

  As will be appreciated by those skilled in the art, the software described herein as being executed on the micropayment server 80 can be distributed among multiple server computers. Similarly, databases and other records and data maintained by database server 110 can be distributed among multiple database servers running on multiple micropayment servers.

  Referring to FIG. 5, a flowchart is shown illustrating the steps taken by a user when registering with an MSP to open a micropayment user account. The user 50 can register with the MSP 60 directly or via a participating vendor. In the case of going through a participating vendor, the participating vendor only passes the registration request of the user 50 to the MSP 60. The operator of the MSP 60 can provide incentives to each vendor and group of vendors to encourage each vendor to attract users and register tokens as payment methods. In order to operate the incentive program efficiently, the user database 120 and the vendor database 125 record relevant attributes regarding the relationship between the user and the vendor. The operator of the MSP 60 can provide incentives to the user and the vendor according to the electronic commerce relationship between the user and the vendor using the related attribute.

  In step 140, the MSP 60 prompts the user 50 with his / her name, address, telephone number, email address, personal information including the user ID and password used to log the user 50 into the micropayment account, credit card information, user 50. Request to provide other sensitive information such as the mother's maiden name, pet name, etc. This confidential personal information is collectively referred to as “other identifiers”, and when the MSP 60 discovers any abnormalities in usage such as abnormally large purchases, or the user 50 changes his / her password, usage limit value, etc. If desired, it is used in a timely manner by the system and method of the present invention to ensure proper identification.

  When the user 50 registers offline, it is required to fill in the questionnaire by email, telephone, facsimile, mail, or directly at the office accepting such applications. This questionnaire contains information about usernames, addresses, telephone numbers, facsimile numbers, email addresses, user IDs, passwords and other identifiers, and other information associated with online registration. Some of this information is mandatory and is indicated to that effect (for example, using the red ground color). Other information is optional (eg, using a black ground color).

  The MSP 60 is also required to provide information regarding how the user 50 wishes to pay for an electronic token. As shown in step 145, the user 50 can purchase a token or put funds into his account using a credit card or a personal bank account for online purchase of tokens. The user 50 is required to provide detailed information regarding his credit card, debit card, and / or personal bank account. If the user 50 wishes, the billing method of adding the cost of purchasing the token to his monthly ISP bill or utility bill can be accepted by the operator of the MSP 60 if this billing method is accepted. You can request a way. The user 50 can also request specific credit limits that allow the user 50 to be charged at a later date. The system and method of the present invention uses the user's 50 ISP, monthly bill for utility bills, or a personal credit line with the MSP 60 to “debit” the user's 50 account record for later payment. Record "Gold Account".

  In step 150, the credit status of the user 50 is verified online for a credit card or personal bank account payment method or offline for a monthly ISP or utility bill bill. If the credit status is certified, the user 50 is given a specific credit limit and is notified accordingly. Upon receipt of the user's 50 personal information and payment method preferences, the micropayment server 80 creates a user record in the user database 120 at step 155. Depending on the registration being done online or offline (step 160), at step 165, confirmation and permission regarding the registration of the user 50 for online registration is displayed, or as shown in step 175, the user 50 You are notified by e-mail or other offline method to confirm that registration is complete.

  Referring now to FIG. 6, an exemplary database in the MSP 60 database server that includes a record of total token sales and a record of vendor total sales in the vendor's bank account for payment settlement. The schematic shown is shown. The user 50 purchases a token using the Internet appliance 185 from the vendor web page via the vendor web server 190 or directly from the MSP 60 web page. The token purchase is then recorded in a user record 195 in the user database 120 in the database server 110. User record 195 includes user 50's login ID and password, user 50's personal data, and paid user tokens or various incentive tokens, including the user micropayment account from which the vendor obtains the tokens. The user record 195 shows the approved payment method used to purchase tokens (credit card, bank account or offline) and credit card name, card number and expiration date, or personal bank account. Also includes detailed user information such as number and bank name.

  The vendor record 200 in the vendor database 125 includes the vendor ID, vendor name, address, telephone number, facsimile number, vendor bank information, and the name of the person with special security privileges to access the vendor record 200 and their individuals. Contains information. These are vendor administrators who can monitor all transactions that occur on the vendor's web site at any time. Vendor record 200 also includes a royalty rate agreed between the vendor and the operator of MSP 60. This loyalty rate can be slid or adjusted to encourage vendor marketing and sales initiatives. Royalty rates may vary from vendor to vendor. The vendor record 200 also indicates that the user 50 has registered to use tokens with the MSP 60 via the vendor web site, or the user 50 has purchased a large amount of tokens again via the vendor web site. In some cases, the commission rate for the commission that the vendor has the right to receive from the operator of the MSP 60 is also included to facilitate the vendor's marketing initiative. In addition, the vendor record 200 includes a record of all sales and the amount of content royalties to be paid to content authors, publishers, artists, or other intellectual property owners.

  The transaction database 130 includes a number of transaction records 205. Each transaction record 205 includes a user ID and vendor ID related to the micropayment transaction, and a transaction ID including the content title or product ID and transaction amount. The transaction amount is recorded in the currency in which the transaction was made. The transaction record 205 also includes the date and time when the transaction was performed. Each time a micropayment transaction between a user and a vendor or a transaction between a user and a micropayment server 80 is performed, the micropayment server 80 stores a user transaction record 205 in the transaction database 130. create.

  A micropayment transaction involves the user 50 purchasing a token in a particular currency or purchasing a tangible product, content, or service. The amount paid by the user 50 for the token is added to the total token sales record 210. This transaction related to purchasing tokens is also recorded in the user account record in user record 195. When a user purchases a tangible product, content, or service, the price that the user pays at a particular vendor is added to the vendor account record 220 for that vendor in the total vendor sales record 215. Similarly, each time a user purchases a tangible product, content, or service, the transaction is recorded in user record 195 and vendor record 200. Accordingly, the total token sale record 210 and the vendor account record 220 for each vendor are for one user who purchases tokens, and the other is for users who purchase tangible goods, content, or services from the vendor. Aggregate micropayment transactions. In addition, when a user purchases content, the amount of royalty to be paid to the author, publisher, or owner of the content can also be recorded in the vendor record 200. This royalty amount can also be added to the total content royalty in the vendor sales total record 220. The total token sales record 210 and the vendor account record 220 are stored in the currency used by the vendor for the transaction.

  When payment settlement between the operator of the MSP 60 and the vendor is initiated by one of the above two events, the micropayment server 80 was recorded in the total vendor sales record 220 by the bank or other financial institution. From the token sale account 225 of the bank holding the money earned from the token sale, recorded in the token sale total record 210 for the amount minus the content royalty total, and also recorded in the vendor sales total record 220, Each vendor's bank account 230a-b is instructed to transfer funds online. This payment settlement between the operator of the MSP 60 and the vendor can be done using an off-line method such as sending a check to the vendor. Then, the amount recorded in the vendor total sales record 220 is updated, and “settled” is displayed with the date and time. Similarly, MSP60 operators must pay royalties to content authors, publishers, artists or other intellectual property owners when the price or time limit is reached. Can do.

  Various databases in the database server 110 including the user database 120, the vendor database 125, and the transaction database 130, and other databases described in this specification include user information, vendor information, and various micro data. It should be noted that the purpose is to illustrate how payment transactions and content loyalty are recorded in the system and method of the present invention. Those skilled in the art will be able to configure these databases in different ways and whether or not some of the described records can be duplicated in such a way as to increase the efficiency of system operation. You will understand that you can add additional records.

  In another embodiment of the invention, in addition to the hardware and software security system, several levels of application software security, usually provided by Internet service hosting providers, are added. ing. The personal information that MSP 60 requests from the user at the time of user registration includes a normal user, including the maiden name of the user's mother, the number of sisters and / or siblings, the name of the pet, etc. (collectively referred to as “other identifiers”) Includes questions that are not answered. The micropayment server 80 requests the user to answer one of the other identifier questions whenever an abnormal history is detected. If the question is not answered after several attempts, the micropayment server 80 disconnects the user from the vendor web site.

  In addition, the user can set a usage amount limit value for purchasing a product or content for each transaction, session (login to logout period), daily, weekly, or monthly total. If the limit is reached or exceeded when a micropayment transaction is made, the micropayment server 80 informs the user that the limit has been reached and requests the user to reduce purchases. Or reject the establishment of micropayment transactions. The user can change the limit value by logging into the MSP 60. However, the user is required to successfully answer one of the other identifier questions in order to properly identify the user. The limit setting is applicable to all participating vendors.

  The user can also set the above usage limit value to apply only to a specific vendor. In doing so, purchases of tangible goods, content, or services are limited to one of the specific vendors listed. Further, the user cannot access an undesignated vendor and purchase the product or content. This feature allows a parent to be prevented from purchasing unwanted merchandise or content from children, for example, from vendors that provide merchandise or content that is not suitable for children.

  The micropayment server 80 can also automatically send an email to the user at the end of the day for any micropayment transaction made by the user at any vendor web site. This e-mail notifies the user that at least one micropayment transaction has been performed in one day. Users can log in to MSP 60 to access their account records and view micropayment transaction details. This includes the vendor name, product name, price, and total price along with the date of purchase. The user account interface 85 also includes links that allow the user to immediately prevent himself from making any micropayment transactions. This minimizes potential damage to the user when the user's ID and password are stolen. A user can reinstate his account by logging into the MSP 60 via a link on the user account interface 85 called “contact us”.

If a user's ID and password are stolen and the user has not set limits as described above and has not checked his email for a while, the biggest loss for that user is that user Will be the total amount of tokens available in your account.
II. Micropayment Account User Interface Referring to FIG. 7, an example of a micropayment account user interface screen for user registration is shown. User interface screen 235 shows a user interface web page hosted by a micropayment service provider such as MSP60. The user interface web page displays information regarding the micropayment service provided to the user by the MSP 60. The user can sign up for the MSP 60 by clicking on the hyperlink in the “Member Login” area 240. Member login area 240 can also be used by users who are already registered with MSP 60 to access information about their micropayment accounts. This web page also displays information in area 245 about the sign-up bonus provided to the user when the user registers with MSP 60. The sign-up bonus can be used by the user to purchase tangible goods, content, or services on participating vendor web sites.

  The user can download the user interface client by clicking a button 250 provided on the web page. The user interface client allows users to easily access information about their micropayment accounts without having to access the user interface web page or contact a customer service representative over the phone. Downloaded to other Internet appliances.

  Referring to FIG. 8, an example of a micropayment account user interface screen for entering user personal information and billing information is shown. The user interface screen 255 is a screen of a user interface web page that is accessed by the user after the user selects the hyper ring “Signup Now!” In the member login area 240 (FIG. 7). This web page describes the steps 260 that the user must follow to complete registration at the MSP 60, including entering the user's personal information and billing information into the field 265. The user's personal information includes the user's name and address, while the user's billing information includes the user's preferred payment options for purchasing an electronic token. Payment options include credit cards, automatic debits on a user's personal bank account, checks and electronic checks, money orders, purchase orders and the like.

  Referring to FIG. 9, an example of a micropayment account user interface screen showing a history of micropayment transactions is shown. The user interface screen 266 shows in field 269 a list of the last 10 transactions that the user has made using his micropayment account. Screen 266, as displayed in field 267, allows the user to access his account report and place funds into his account and provides a means to contact the operator of MSP 60. This screen also lists user information, incentives, usage limits, a link to access content items purchased by the user, and a link to place an order for billing (Dispute a Charge).

  Referring to FIG. 10, an example of a micropayment account user interface screen that is displayed when a user clicks on a user interface client previously downloaded to the user's Internet appliance is shown. The user interface screen 270 shows a history of micropayment transactions and displays a list of the last 10 transactions that the user has made using his micropayment account. Screen 270 allows a user to fund his account at link 275, view an account report at link 280, and access a screen at link 285 showing a detailed history of the content items purchased by the user. Also make it possible. The user can access the same screen by clicking the hyperlink “My Content” in the field 268 in FIG. 9. The “My Content” hyperlink displays a list of all content items that the user has purchased using his micropayment account. As with each content item displayed on screen 270, each content item displayed in the “My Content” hyperlink at link 285 includes the date and title of the content item as well as the content item that the user has already purchased. If the URL has not expired, it includes a URL link that allows the user to revisit and access the content item without requiring the user to revisit the content web site. Content providers can choose to expire content items based on the time or number of revisits.

  Referring to FIG. 11, an example of a micropayment account user interface screen for entering funds into a micropayment account is shown. The user can access the user interface screen 290 by clicking the link 275 shown in FIG. 10 or clicking the hyperlink “Add Funds” in the field 267 in FIG. Screen 290 allows the user to select in field 295 the actual currency for purchasing an electronic token, such as US dollar, Japanese yen, Brazilian real. Screen 290 also allows the user to select whether to purchase an electronic token by performing offline payment (link 300) or to purchase an electronic token by performing online payment (area 305). If the user wishes to make an offline payment, link 300 describes the user's preferred offline payment method, such as payment by check, money order, purchase order, or through a customer service representative. Open a form that the user can fill out. For online payments, the user can select the credit card number entered during registration at the MSP 60 or enter a new credit card number. Alternatively, the user can choose to withdraw automatically from his personal bank account or other online financial account.

  The user is not required to purchase an electronic token, i.e., fund an account, before making a micropayment purchase at a participating vendor web site. The user can make a negative withdrawal by paying at a later date via the user's ISP, a monthly bill for utility bills or a personal credit line at the MSP 60.

  Referring to FIG. 12, an example of a micropayment account user interface screen for specifying usage limits for a micropayment account is shown. The user can access the user interface screen 310 by clicking the hyperlink “My spending” in the field 268 in FIG. 9. Screen 310 allows the user to specify the usage limit for their micropayment account per transaction, daily, weekly, or monthly by filling in field 315. The user can specify a usage limit by selecting a number of currencies such as US dollars and Japanese yens in the field 320.

Referring to FIG. 13, an example of a micropayment account user interface screen is shown that describes participating vendors that provide electronic tokens as a payment method. The user interface screen 325 shows a list of vendors registered with the MSP 60 to provide an electronic token as a payment method to the user. The user can go to the participating vendor web site either directly or by clicking on any one of the links displayed on screen 325. Alternatively, the user can obtain a list of participating vendors by calling his MSP customer service representative.
III. Micropayment vendor API
Referring to FIG. 14, a flow chart for performing a micropayment vendor API function call when a content item is purchased by a user is shown. The content item can be accessed by a hyperlink on a vendor's web page, such as web page 405 shown in FIG. At step 335, the user clicks on a hyperlink to purchase a content item, such as hyperlink 410 on web page 405, to purchase a digital song titled “I'll Fly Away”. .

  Referring now to FIG. 16A, an exemplary hyperlink for a content item that can be purchased by a user using an electronic token is shown. Hyperlink 415 is a link to a digital song titled “I'll Fly Away” that can be purchased by the user for $ 0.10 using an electronic token. When the user moves the mouse cursor of the personal computer or notebook computer onto the hyperlink 415, a title 430 indicating the name and price of the song is displayed to the user. Alternatively, when the user taps a link on a personal digital assistant (PDA), selects a key on a cellular phone keypad, or performs a similar operation on another Internet appliance, the user is prompted to display the title 430 be able to.

  When the user clicks on hyperlink 415, the vendor web server that maintains the vendor web page where the content item is posted executes Java script function 420 to execute micropayment server 80. Initiate a micropayment transaction between a vendor and a user via a micropayment service provider such as MSP60 hosting The Java (registered trademark) script function 420 has a parameter 425 indicating the “content ID” of the content item to be purchased. In this case, the content ID of the song “I'll Fly Away” is 1500. Hyperlink 415 also includes an audio file 435 corresponding to the song purchased by the user.

  Referring to FIG. 16B, an exemplary Java script function for initiating a micropayment transaction at a vendor web site is shown. The Java script function 440 is used to send the content ID parameter 425 to an application server page (ASP) 445 created by the vendor web server. An ASP page is a dynamic web page generated by a program or script at a vendor web server to collect information from different sources, such as the ASP page itself or a database. The ASP 445 may be an HTML, XML (or other technology) page that is used to retrieve information about purchased content items from the ASP 445 or from a database maintained by the vendor web server. . Information retrieved by the ASP 445 includes content item title, price, description, information about the content item, such as expiration at the time or number of accesses, and information about the vendor.

  14 and 16, in step 340, the vendor web server sends a content ID parameter 425 to the ASP 445, and in step 345, the ASP 445 retrieves information about the content. The retrieved information is sent to the MSP 60 via the Simple Object Access Protocol (SOAP) in step 350 by invoking the micropayment vendor API function call 500 shown in FIG. 18A. The function call 500 is used to pass information about the vendor and the content item being purchased from the vendor web server to the micropayment server 80. In step 355, the micropayment server 80 verifies the vendor and content item information, and the vendor uses the electronic token as a payment method to sell the tangible product, content, or service to the user. Determine if you are one of the allowed participating vendors.

  The micropayment server 80 then creates a transaction ID for the transaction data, records both the transaction ID and transaction data in the transaction database 130, and then sends the function and transaction ID to the user's Internet appliance. This function opens a new window on the user's Internet appliance and sends the transaction ID back to the micropayment server 80. Next, at step 360, the micropayment server displays the transaction data in the buy window of the user's Internet appliance. An exemplary buy window is shown in FIG. The buy window 450 includes buttons such as “Buy” (470), “Incentive” (475) and “Cancel” (480), as well as “Content Title” 455, Includes any simple “Description” 460 and the “Price” 465 of the content.

  Buy button 470 can be selected by the user to purchase a content item using an electronic token stored in the user's micropayment account. The incentive button 475 can be selected by the user to purchase the content item using an incentive token provided to the user by the MSP 60 or vendor. If the user clicks on the incentive button 475, the user is asked to enter the appropriate incentive code corresponding to the incentive token. The MSP 60 then checks the incentive code given by the user. If the incentive code and other transaction data are not valid, the MSP 60 displays an error message on the user's Internet appliance.

  Returning to FIG. 14, in step 365, the MSP 60 verifies whether the user has already logged into his micropayment account at the MSP 60. If the user is not already logged in to MSP 60, the MSP logs in to the user by filling in field 490 of login window 485 (FIG. 17B), or login if the user has not yet registered. • Click on button 495 in window 485 to ask to register with MSP60. This login process needs to be done by the user only once while the user browses various vendor web sites and purchases several items at various vendor web sites. When a user first logs in to the MSP 60, the MSP 60 writes the encrypted user ID to the user's Internet appliance, which allows unauthorized users to purchase goods using the user's Internet appliance. In order to prevent this from happening, it expires after a predetermined period of time and is erased. The login window 485 indicates that the user is required to log in to the MSP 60 every time he purchases a product at various vendor websites because the Internet appliance he is using is a public computer. Also shown is a box 496 that is automatically checked by default. This is because the MSP 60 does not write the encrypted user ID to the user's Internet appliance. If the user does not check box 496, he is required to log in to MSP 60 only once as described above.

  After the user logs in to the MSP 60, the MSP 60 checks whether the user usage limit has been reached. If not, the MSP 60 checks whether the user's micropayment account contains a sufficient number of tokens to make the purchase of the content item. If the user is logged into the MSP 60 and has sufficient tokens, the micropayment server 80 encrypts the user ID with a time-varying encryption key and uses the URL address corresponding to the content item to be purchased. Open a blank window on the user's Internet appliance and, at step 370, send the encrypted user ID and content ID to the user's Internet appliance.

  The time-varying encryption ID is used to prevent the content item from being viewed, heard and downloaded without permission from the vendor web page. The time-varying encryption ID changes at a predetermined time period and is used by the micropayment server 80 to verify the user before sending authorization to the vendor web server to authorize the purchase. This prevents the user from purchasing the content item and sending a URL corresponding to the content item to the friend so that the friend can freely view, listen to or download the content item. . For example, if a user purchases a song and then emails the URL of the song to a friend, the friend cannot click on the URL because the time-varying encryption user ID has already changed.

  In step 375, the user's Internet appliance sends the user ID encrypted with the time-varying encryption key to the vendor web server. Upon receiving the ID and content ID encrypted with the time-varying encryption key, the vendor web server requests authorization from the MSP 60 at step 380 so that the user can be allowed to purchase. At step 385, the micropayment server 80 sends an authorization to the vendor web server to authorize the purchase.

  In step 390, the micropayment server prompts the user purchasing the content item so that the vendor web server cannot access the content item without other micropayment transactions. Check if the content item to be purchased should have been locked before. If the vendor web server has previously determined to lock the content item to be purchased, at step 395, the vendor web server selects the micropayment vendor API function shown in FIG. 18B. The call “Lock Content” 505, that is, the content locking process is executed, and the encrypted user ID and the URL address of the content are sent to the MSP 60. Then, the MSP 60 decrypts the user ID and confirms whether or not the user has an access right to the URL address of the content. In order for the user to have access rights, the time-varying encrypted user ID is valid, the content item has been paid, the content item has not expired, and the access count is It is necessary not to exceed the limit.

  If the user has access to the content item, at step 400, the MSP 60 allows the vendor web server to display or download the content to the user's Internet appliance. If the user does not have access to the content item, the MSP 60 can request the user to purchase the content again. Even if the above-mentioned content locking process copies the URL address of the content and the encrypted user ID and sends them to a third party, the time-varying encrypted user ID has changed. Prevent vendor web servers from displaying or downloading content items. If the page with the content URL address does not have the “lock content” option, the vendor web server displays or downloads the content item to the user's Internet appliance.

  Referring now to FIG. 19, a schematic diagram of the parameters of the micropayment vendor API function call shown in FIGS. 18A and 18B is shown. The API function call 500 includes (1) Vendor ID parameter 510a, (2) Vender Password parameter 510b, (3) ContentTitle parameter 510c, and (4) Price parameter 510d. , (5) ContentURL parameter 510e, (6) IsPost parameter 510f, and (7) Message parameter 510g, the requested parameters 510a to 510g are sent to the micropayment server 80. Send.

  The VendorID parameter 510a is a unique vendor identification number assigned to each participating vendor authorized to sell merchandise to the user online using an electronic token issued by the MSP 60 as a payment option. The VenderPassword parameter 510b is a password selected by the vendor when the vendor registers with the MSP 60 in order to use the micropayment service of the MSP 60. Vendors can change their password at any time by visiting a web site maintained by MSP 60 that contains information about the vendor's micropayment account.

  The ContentTitle parameter 510c is a title that the vendor wants to display in a buy-by-open window for the content. Price parameter 510d describes the price that the vendor wants to charge for the content. The price of the content also appears in the buy window displayed to the user. The ContentURL parameter 510e is a content URL that is transferred to the user after purchasing the content item. This parameter should also be unique because it is also used to track whether the user has already purchased a content item. The IsPost parameter 510f tells the micropayment server 80 whether to use “FormPost” or “GetAction” for content transferred to the user. IsPost is preferably set to FormPost so that the content parameter is not visible to others. Finally, the Message parameter 510g is variable, including the micropayment server 80 response that tells whether a micropayment transaction for the purchase of the content item is permitted.

  The API function call 500 includes (1) VendorContent (vendor content) ID parameter 515a, (2) NumberOfTimesToView (valid number of times) parameter 515b, (3) AbsoluteExpTime (valid absolute expiration date) parameter 515c, (4) NumberOfDaysToV (V) (Days) parameter 515d, (5) NumberOfHoursToView parameter 515e, (6) Incentive ID parameter 515f, (7) ShortDescription parameter 515g, and (8) OptionalData (optional data) Optional parameter 515a, including parameter 515h The 515h can be sent to the micropayment server 80.

  VendorContentID optional parameter 515a is an ID that is sent back to the vendor web server when the micropayment transaction is completed. This parameter can also be used by vendors for internal tracking purposes. The NumberOfTimesToView optional parameter 515b specifies the number of times a user purchasing a content item is allowed to view the content item. The AbsoluteExpTime optional parameter 515c describes the date and time of the GMT when the content item expires. The NumberOfDaysToView optional parameter 515d describes the number of days that the content item is valid, and the NumberOfHoursToView optional parameter 515e describes the number of hours that the content item is valid.

  The IncentiveID optional parameter 515f is a string that contains all valid incentive IDs associated with the content item. Leave this parameter blank when all valid incentive tokens can be used for the content item. If this parameter is set to “−1”, an incentive token cannot be used for this content. The ShortDescription optional parameter 515g is a brief description of the content. This parameter can also be displayed in a buy window displayed to the user. Finally, the OptionalData optional parameter 515h can be used for any optional data that the vendor wishes to pass to the content URL for internal tracking purposes.

Of course, further parameters may be used by the MSP 60 and the vendor web server to establish a micropayment transaction for the purchase of tangible goods, content, or services. It will also be apparent that the micropayment vendor API can be implemented using different technologies other than the SOAP call described above.
IV. Micropayment Transaction Flow Between User, Vendor and Micropayment Service Provider Referring to FIG. 20, a vendor's web site that accepts electronic tokens as payment for content items offered for sale on a web site. A schematic of the site is shown. As will be appreciated by those skilled in the art, the appearance of the web site 520 in FIG. 19 only illustrates the major components that can be displayed on the content vendor's web site. The appearance of the web site 520 depends on the design by each vendor.

  The availability of a token as a payment option for content is displayed by icon 525. Several content items are available for purchase, including content items 530a-530c. The web site 520 may also include promotional windows 540 and 545 and various pop-up windows 548 as described below. When the user clicks on one of the content items 530a-c, the system and method of the present invention displays on the display of the vendor web site 520 the title of the content item, an optional brief description and the content item. Pop up a buy window 550 containing the price. The window 530 may also include an incentive button 555a, a buy button 555b, and a cancel button 555c. When deciding to purchase a content item, the user need only click on the buy button 555b. The user can also decide not to purchase the selected content, in which case the user may click on the cancel button 555c.

  As mentioned above, the system and method of the present invention allows each vendor and MSP 60 operator the freedom to provide an incentive token to the user. Pop-up window 550 includes an incentive button 555a that allows the user to make payments for content items using an incentive token that the user can have in their micropayment account at MSP 60. If the user decides to pay for the content item using an incentive token, the user can click on the incentive button 555a. A pop-up window 570 is then displayed requesting the user to enter the code assigned to the incentive token in field 575a. Note that there are several incentive tokens provided by each vendor and the operator of MSP 60, and these incentive tokens may have certain restrictions such as expiration dates. Accordingly, the system and method of the present invention assigns a code to each type of incentive token issued by each vendor and MSP 60 operator. This allows the system to identify the type of incentive token and allows appropriate management of the incentive token by the user and the operator of the MSP 60. After the user clicks on the buy button 555b or enters an incentive code and clicks the “Submit” button 575b, the system performs one of the following three processes.

  Case I: If the user has previously logged into the MSP 60 (not shown), the MSP 60 retrieves the user ID from the user's Internet appliance (not shown) and then the user database 120 (shown). 6) Immediately access the user record 195 to check if the user has enough tokens in his micropayment account. If there are enough tokens, the MSP 60 allows the vendor to sell and display the published content item, or to download the selected content item. Thus, the system and method of the present invention provides the user with the convenience of purchasing content from a vendor web site without requiring the user to log in or check out the vendor web site. If the user does not have enough tokens, the MSP 60 confirms that the user does not have enough tokens to make a purchase in his account, as described in more detail with reference to FIG. Displays a message (not shown) that tells the user and encourages the user to purchase more tokens (put into their account).

  Case II: If the user has not logged into the MSP 60, the system causes the vendor web site 520 to open a pop-up window 560. Pop-up window 560 logs in by entering user ID 565a and password 565b and requests the user to click on send button 565c. The other parts of this process are the same as described above for Case I. The MSP 60 then writes the encrypted user information to the user's Internet appliance.

  Case III: When the user logs in to the MSP 60, the encrypted user information that the MSP 60 wrote to the user's Internet appliance begins when the user logs in to the MSP 60, or at the user's choice, the vendor web It has a deadline set to be shut off after a predetermined period, starting from when the transaction was last made at site 520. Upon expiration, the system and method of the present invention requires the user to log in again. Thereafter, this process proceeds in the same manner as in the case II described above. This feature reduces the risk that a third party will purchase content using the user's Internet appliance without the user's permission.

  In another embodiment of the present invention, the MSP 60 can download “instant messaging” client software into the user's Internet appliance. This software displays a button 535 on the browser. When the user clicks on the button 535, the system instantly displays the user's content purchase during the user's login period or a summary of the past several transactions. This summary includes the vendor's URL address, content title, cost, date and time, and the balance of the user's tokens available in the user's micropayment account at MSP60. If the user wants to review all of his previous purchase activities (history), the user logs into the MSP 60 and clicks the “my account” button or the “statements” button (FIG. 9). Field 267) can be clicked. The system will include all trade transactions performed, user purchases, deposits of funds, trade orders that are ordered and problematic (contested) and transactions including customer credit, trade names or titles of content, The user's micropayment account report, including cost, date and type, is displayed on the user's Internet appliance. The system also displays the user's available token balance. The user can filter account reports by start date and / or end date, or by specific vendors or specific types of transactions.

  It will be appreciated that the process described above in which a user purchases a content item at a vendor web site can also be used to purchase a tangible product or service at another vendor web site. The system and method of the present invention allows a user to purchase content items, tangible goods or services at multiple vendor websites without having to disclose any personal or billing information to the vendor websites. It is advantageous to be able to

  FIG. 21 is an illustration showing the steps taken by the user when purchasing a content item using a token at a number of vendor web sites. FIG. 21 illustrates how a user can browse through a number of vendor web sites that accept tokens as payments without having to log in or log out at each vendor web site, and free and seamless content items. Shows you can buy. User 560 can purchase content from a number of vendors 555a-555c in any order. User 560 may visit any particular vendor 555a-555c multiple times. Thus, the system and method of the present invention provides the user with the convenience of purchasing content items using micropayments at a number of vendor websites without the cumbersome login and checkout process at each vendor site. provide.

  In step 1), the user 560 browses the various vendors 555a-555c websites and selects content items for purchase at any of the vendors 555a-555c websites using an Internet appliance. . When the user 560 clicks on a content item displayed on one of the vendor 555a-555c web sites, the vendor web server will display the content the user 560 clicked along with the vendor ID, as shown in step 2). Send item price to MSP550. At the same time, as shown in step 3), the Internet appliance of user 560 sends the user ID to MSP 550. In step 4), MSP 550 deducts the price of the content item from the user's micropayment account and grants the vendor web server permission for the user's purchase as shown in step 5). In step 6), the vendor web server downloads the content item to the user's internet appliance. In step 7), the MSP 550 records the amount of royalty that the vendor needs to pay to the MSP 550 for the electronic micropayment transaction performed. The user can know the processes in steps 2), 3), 4), 5) and 7). This completes the purchase of the content item from the vendor web site. The user 560 can continue to browse to find other content items to continue to purchase other content items from the same vendor or to purchase on other vendor web sites without a break.

  FIG. 22 is a schematic diagram illustrating system processing performed when a user purchases a content item using a token at a vendor web site. In step 1), the user 575 clicks a content hyperlink to purchase a content item at a vendor web site hosted on the vendor web server 570. In step 2), the vendor web server 570 determines the vendor ID, content ID, content URL address, content title, optional short description about the content, price, incentive token code (if applicable), content Transaction data such as the period during which the item is valid is sent to the MSP 565. In step 3), the MSP 565 checks the vendor and content top-level URL address and determines whether the content vendor is a member vendor registered with the MSP 565 to provide the user with an electronic token as a payment method. to decide. If so, this process continues.

  In order to preserve the integrity of transaction data, the system and method of the present invention reduces the limit on the number of transaction data transmissions over a communication line and allows illegal transaction data such as changes in content prices by Internet intruders. Prevent tampering. To achieve this goal, upon receiving transaction data from vendor web server 570, the system and method of the present invention causes MSP 565 to create a transaction ID for the transaction data, and the transaction data is stored in transaction database 130 (FIG. 4). ). The MSP 565 then returns the function and transaction ID to the vendor web server 570 in step 3). Thereafter, the communication between the MSP 565 and the vendor web server 570, or the communication between the vendor web server 570 and the user's 575 internet appliance uses the transaction ID rather than the transaction data.

  In step 4), vendor web server 570 sends the function and transaction ID to user 575's Internet appliance. This function opens a new blank window on user 575's Internet appliance and in step 5) causes user 575's Internet appliance to send the transaction ID and encrypted user ID to MSP 565. In step 6), the MSP 565 displays the transaction data including the title of the content, an optional brief description and the price on the user 575's Internet appliance with an incentive button, a buy button and a cancel button. Note that MSP 565 needs to send transaction data including the price of the content item and display it on user 575's Internet appliance. However, the MSP 565 will use the actual transaction data, including the price of the content item stored in its database, to confirm the transaction data before approving the micropayment transaction (step 2 above). It is difficult for a person to illegally modify, for example, content item prices or other transaction data.

  In step 7), the user 575 can purchase the content item by clicking the buy button. If user 575 has an incentive token in his micropayment account at MSP 565, user 575 can click the incentive button to pay for the content item using the incentive token. After reading the brief description (optional), the user 575 can decide not to purchase the content item or only decide not to proceed with the purchase. In that case, the user 575 can click the cancel button. If the user 575 clicks the buy button, the user 575's Internet appliance sends the incentive code (if applicable) and other transaction data back to the MSP 565.

  In step 8), the MSP 565 checks the incentive code (if applicable) and other transaction data before determining whether the user 575 has logged in. If the user is logged in, the MSP 565 also checks whether the user 575 is still below his usage limit. This is another security measure to protect the user's micropayment account at MSP565. The MSP 565 then checks whether the user 575 has enough tokens or incentive tokens (if applicable) to make a purchase. If the above checks and checks for user 575's available tokens are successful, the MSP 565 encrypts the user ID with a time-varying encryption key, opens a blank window on the user 575's Internet appliance with the content URL address, The encrypted user ID and content ID are transmitted to the user 575's Internet appliance. In step 9), the Internet appliance of the user 575 sends the encrypted user ID and content ID to the vendor web server 570 in order. Also, in step 10), the vendor web server sends the encrypted user ID and content ID to the MSP 565.

  In step 11), the MSP 565 decrypts the user ID and checks whether the user 575 has “access rights” to the content URL address. The user has “access right” to the content URL address that the user is logged in to the MSP 565 and the user's time-encrypted user ID is valid. This means that you are making a payment and all other transaction data is valid. If user 575 has access, MSP 565 sends an authorization to vendor web server 570. In step 12), vendor web server 570 displays and downloads the content item on user 575's Internet appliance. In step 13), the MSP 565 records the amount of royalty that the vendor needs to pay to the MSP 565 for the electronic micropayment transaction that has taken place. The above steps 2), 3), 4), 5), 8), 9), 10), 11), and 13) can be known by the user 575. This completes the micropayment transaction for the user purchasing content from the content vendor web site.

  The process shown in FIG. 22 provides a security measure against unauthorized downloading of content items from content vendor web sites and prevents unauthorized modification of transaction data by Internet intruders. The royalty rate that the operator of MSP 565 imposes on vendors that allow user 575 to purchase content items using tokens depends on the amount of content items sold by the vendor within a given period of time, May vary from vendor to vendor.

  In yet another embodiment of the invention, the system stores transaction records in its transaction database 130 (FIG. 4). Settlement of payments to vendors for tangible goods, content, or services sold or rented to users is performed by one of the following two events.

  First event: the amount paid to the vendor reaches a predetermined limit. This limit value is agreed in advance between each vendor and the operator of MSP565. This value may vary from vendor to vendor.

  Second event: the date of settlement is agreed in advance between each vendor and the operator of MSP565. This date can be once a week, twice a month, once a month or other pre-agreed arrangements and may vary from vendor to vendor. If the limit value of the predetermined amount has not been reached, payment settlement based on a date agreed in advance may not be performed.

  The payment settlement as described above eliminates the settlement for each commercial transaction between the MSP 565 and the vendor whenever an electronic micropayment transaction is performed between the user and the vendor. Accordingly, such payment settlement reduces the cost and fee of account settlement charged by the bank each time a payment is made from MSP 565 to the vendor.

  Referring to FIG. 23, a flow chart for purchasing tokens or funding a micropayment account is shown. As shown in step 585, the user can purchase tokens online or offline. The user can indicate in which currency he wishes to purchase the token. Unless specifically indicated, the tokens purchased are denominated in US dollars or in the currency of the country in which the vendor is located. If it is desired to purchase a token offline, the user is required to make a payment to the bank account designated by the MSP, as shown in step 600. Upon confirming the payment from the user at step 605, as shown in step 620, the MSP system administrator enters the amount of funds accepted into the user's micropayment account into the user record 195 (FIG. 6), The user's balance is updated to indicate that a new token has been purchased.

  If the user wishes to purchase a token online and the purchase is made via a vendor, the system and method of the present invention sets a vendor association flag to the vendor ID at step 595, which relates to step 635. Recorded as described below. At step 610, the system asks the user about the amount of tokens the user wishes to purchase or the amount of funds to place in his micropayment account at the MSP. Upon receipt of the desired amount, the system debits the user's credit card or user's bank account, or any payment method provided by the user, as shown in step 615. Then, as shown in step 620, the MSP updates the user record 195 (FIG. 6) to indicate that a new token has been purchased. In step 625, the user record 195 (FIG. 6) in the user database 120 is updated to indicate the amount of tokens purchased. This transaction is also entered in the user's micropayment account history (activity) record. The transaction database 130 and token sales total record 210 in FIG. 6 are also updated.

  When a token purchase is made through the vendor at step 630, the sales record in the vendor record 200 (FIG. 6) records the user ID and the user's token purchase amount. Then, as shown in step 635, the account status in user record 195 (FIG. 6) is updated to indicate the purchase of a token from a particular vendor. MSP operators can use this information to reward vendors for attracting users to purchase tokens. Similarly, the vendor can use this information to reward the user for purchasing the token, for example by issuing an incentive token to the user. MSP operators can also offer specific incentives to encourage each vendor to attract users to purchase more tokens.

Incentive tokens issued by vendors to such users can be used to purchase tangible goods, content, or services only from the vendor that issued the token. Incentive tokens may or may not have an expiration date. The decision to issue incentive tokens is entirely at the discretion of the vendor without any restrictions from third parties such as banks or MSP operators. The user database 120 and vendor database 125 (FIG. 6) store details of various incentive tokens issued to the user by the vendor. Finally, in step 640, the system emails the user at the end of each day. Confirm that the transaction has been carried out. Users can log in to the MSP and review their account history, indicating that the user has purchased a particular amount of token through the vendor or directly through the MSP, and the amount and date of purchase. .

  24-27 confirms vendor and content URL addresses, retains transaction data integrity and user authentication, and prevents content from being viewed or downloaded without authorization. A flow chart for secure purchase is shown. At step 655, the user browses the content vendor web site and clicks a content hyperlink to purchase a content item. This allows the vendor web server to provide the vendor ID, content ID, content URL address, content title, optional short description about the content, price, incentive token code (as applicable, as shown in step 660. ) And transaction data including the period during which the content item is valid is passed to the MSP.

  In step 665, the MSP checks the vendor and content top-level URL address to determine if the content vendor is a member vendor registered with the MSP to provide the user with an electronic token as a payment method. To do. Then, the MSP creates a transaction ID related to the transaction data, and stores the transaction ID and the transaction data in the transaction database 130 (FIG. 6). The transaction ID refers to the transaction data received by the MSP. The MSP then returns the function and transaction ID to the vendor web server. At step 670, the vendor web server sends the function and transaction ID to the user's Internet appliance. Then, as shown in step 675, the function opens a new window on the user's Internet appliance and sends the transaction ID to the MSP.

  At step 680, the MSP listed the transaction data including the content title, optional short description of the content, and the price of the content item, along with incentive buttons (if applicable), buy and cancel buttons. Display a window on the user's Internet appliance. If the content item is available for purchase using an incentive token issued by the content vendor or MSP operator, the user clicks the incentive button as shown in step 685 to The content item can be paid for using an incentive token that has in their micropayment account at the MSP. In step 690, the system displays the field in the same window and prompts the user to enter the incentive code assigned to the user. After the user enters the incentive code at step 695, the user can click the buy button, as shown at step 700.

  If the content item is not available for purchase using an incentive token, the system and method of the present invention does not display an incentive button on the user's Internet appliance display window. In this case, as shown in step 700, the user can click the buy button or the cancel button. If the user clicks the cancel button, as shown in step 705, the displayed window is closed and the user's Internet appliance returns to display the content vendor web page.

  If the user clicks the buy button, at step 710, the MSP verifies the incentive code (if applicable) and other transaction data. If it is determined in step 720 of FIG. 25 that any of these transaction data is incorrect, in step 725, the MSP displays an error message on the user's Internet appliance, and the user receives the error message. • You can close the window and return to the content vendor web site. If the MSP confirms all of the above transaction data successfully, the MSP checks whether the user is logged in, as shown in step 735.

  The system and method of the present invention allows a user to login to the MSP only once and browse several content provider vendor web sites without having to log in or check out at each vendor web site. Note that it is possible to purchase content items from different vendor web sites. However, in order to prevent unauthorized use of a user's Internet appliance to purchase content, the user must have either user logged in or made the last purchase of content. It is required to log in to the MSP again after a predetermined period from the time of selection.

  If the user is not logged in, or if the time limit since the user logged in has passed, the MSP requests the user to log in to the MSP, as shown in step 740. After the user enters the user ID and password in step 745, the MSP checks whether the user has successfully logged in to the MSP, as shown in step 750. If the user is not logged in, at step 755, the MSP prompts the user to register with the MSP, closes the window, and the user's Internet appliance returns to display the content vendor web page. Enable.

  The user only needs to log in to the MSP, and the user ID and password are entered between the user's Internet appliance and the MSP server, so the vendor web server does not recognize the identity of the user. This allows the system to protect user privacy and maintains user anonymity from the vendor.

  If the user has logged in before or has successfully logged in as shown in step 750, then in step 760, the MSP proceeds to check if the user is still within the usage limit. If not within the usage limit, the MSP informs the user that the user's usage limit has been reached and terminates the user's content purchase. This is another security measure provided by the system and method of the present invention to protect the user from unauthorized use of the user's micropayment account at the MSP.

  If the user is within the usage limit, as shown in step 765, the MSP proceeds to check if the user has enough tokens in his personal account to pay for the content item. If the user has enough tokens, the MSP encrypts the user ID with a time-varying encryption key and displays a blank window on the user's Internet appliance with the content URL address, as shown in step 770. Open and send the encrypted user ID and content ID to the user's Internet appliance. At step 775, the user's Internet appliance sends the encrypted user ID and content ID to the vendor web server. Only the user ID encrypted with the time-varying encryption key for that user is sent to the vendor web server and no other user information is sent. Thereby, the anonymity of the user from the vendor is maintained.

  The system and method of the present invention allows a content vendor to implement a “locked content” option that prevents unauthorized download of content by a third party. Such unauthorized download of content can occur when the user copies the content URL address and encrypted user ID and sends it to a third party such as the user's family or user's friend. is there. The user ID is encrypted with a time-varying encryption key so that the user ID becomes invalid when the time expires. Thus, the system and method of the present invention reduces the risk of unauthorized viewing or downloading of content from content vendor web pages.

  In step 820, the vendor web server checks whether the content URL address has the option of “locked content”. If the content URL address has the option, the vendor web server sends the encrypted user ID and content URL address to the MSP, as shown in step 825. At step 830, the MSP decrypts the user ID and checks whether the user has “access rights” to the content URL address, as shown at step 835. The user ID is valid (that is, the time-varying encrypted user ID has not been changed), the content item has been paid, and the content validity period has not expired. A user has “access rights” to a content item if the number of times the item is accessed does not exceed a limit value.

  If the user does not have “access rights” to the content, at step 845, the MSP checks whether the content URL includes a content ID. If so, the process proceeds to step 660 (FIG. 24). If not, the MSP displays an error message and ends the process, as shown in step 855. In step 840, if the user has "access rights" to the content, the MSP sends an authorization to the vendor web server in step 850, and the vendor web server connects to the user's Internet appliance. Send content or download it.

  Referring back to step 820, if the content URL address does not have a “locked content” option, the vendor web server will send the content item to the user's Internet appliance, as previously described in step 850. View or download.

  Referring back to step 765 (FIG. 25), if the user does not have enough tokens to make a purchase of the content item, the MSP adds to the user's micropayment account, as shown in step 790. Asks the user to purchase (or fund). As shown in step 795, the MSP may further use the user's credit card or personal bank account that the user previously provided to the MSP when registering a user for online purchase of tokens. Ask if it is acceptable to you.

  To provide the user with convenience and ease of use, the system indicates that the user does not have enough tokens to fulfill the purchase with his remaining balance, and gives the user additional tokens. A window is displayed to the user asking if he wants to purchase. An exemplary window is shown in FIG. Window 881 provides the user with the following options 882a-882c to proceed.

  Option 882a: “Automatic Deposit” for instantly purchasing additional tokens. To facilitate the purchase, the system debits the user's account with a “top-off” amount plus a shortage amount for the current purchase. The “top-off” amount is typically set at a level sufficient to pay for debiting the user's account, such as the cost charged to the user's credit card.

  Option 882b: “Manual Deposit” that links the user to the user interface 85 (FIG. 3) for the user to deposit funds into his micropayment account.

Option 882c: “Cansel” of content purchase by the user.
Returning to FIG. 25, if the user agrees, at step 800, the MSP charges the user's credit card or debits the user's personal bank account with the amount of the new token purchased by the user. These new tokens purchased by the user are denominated in the currency indicated by the price of the content item.

  In step 805, the MSP updates the user's account balance in the user record 195 of the user database 120, transaction database 130, and total token sale record 210 of the database server 110 of FIG. 6, and a new token is purchased. It shows that. The above record is updated with the currency used by the user to purchase a new token. Then, the MSP proceeds to step 765 as described above. If the user does not want to purchase additional tokens online, as shown in step 810, the MSP purchases more tokens in the user's account to purchase the content item (fund To inform the user that it is necessary.

  FIG. 27 illustrates an alternative way in which a third party can purchase a content item that a user has previously purchased. At step 875, the third party (new user) receives a content URL address from someone who has already purchased a content item using the system and method of the present invention. As shown in step 880, the new user can enter the content URL address in the browser or click the content URL address of the received email. As shown in step 775 (FIG. 25), the user's Internet appliance sends the encrypted user ID and content ID to the vendor web server. This step is performed as described above. If already registered with MSP, the new user can proceed with the purchase of the content item, but the encrypted user ID received by the new user has a time-varying encryption key and the expiration date is Because it expires, the new user is required to pay for the content item using the token in his account.

  Referring now to FIG. 29, there is shown a schematic diagram illustrating the steps taken by a user when purchasing a tangible product or service using a token on a vendor's web site via a checkout process. . In step 1), user 895 requests to purchase goods or services via a checkout process at one of the vendor 890a-890c web sites and selects the token as his payment method. In step 2), one web server of vendors 890a-890c sends to the MSP 885 the vendor ID, user ID and password, and the total amount of tokens required to purchase the tangible goods or services. The MSP 885 accesses the user record 195 in the user database 120 (FIG. 6) to check if the user 895 has enough tokens to make a purchase. If the user 895 has enough tokens, the MSP 885 deducts the required tokens from the user's account balance and allows the vendor to make a micropayment transaction as shown in step 3).

  If user 895 is given prior authorization for a later payment, MSP 885 can debit the user 895's account as required for future payments and authorize the vendor for micropayment transactions. . In this case, the necessary tokens are also deducted from the user account balance. Thereby, the system of the present invention allows a vendor or operator of MSP 885 to provide a credit line to the user. In such a case, the user account balance may show a negative value. The range of this “negative withdrawal account” allowed for a user depends on the credit line limit that the vendor or MSP 885 operator provides to the user.

  Upon receiving authorization from MSP 885, the vendor confirms the micropayment transaction and delivers the tangible goods or services to user 895 as shown in step 4). In step 5), MSP 885 sends an email to user 895 to confirm that a micropayment transaction has been performed. If it is found that a micropayment transaction has not been made, the user 895 can immediately notify the MSP 885 and disable his account until further investigation is performed. In step 6), the MSP 885 records the amount of royalty that the vendor needs to pay to the MSP 885 for the electronic micropayment transaction made. The above steps 2), 3) and 6) are transparent to the user.

  In the method and system of the present invention, for an electronic micropayment transaction using tokens as payment, the royalty rate charged by the MSP885 operator to the vendor is the total amount of transactions performed in a predetermined period such as monthly or quarterly. Depending on the vendor, it may vary from vendor to vendor. This loyalty rate for vendors can also be set to slide down with the total amount of sales to reward vendors for vendor sales and marketing efforts.

  FIG. 30 shows a flowchart in the case of purchasing a tangible product on the vendor's website. The user first logs into the vendor by entering a user ID and password. The user then selects a tangible product from the vendor web site and places the tangible product in the shopping cart. This process is the same as most online shopping vendor web pages currently available on the Internet.

  When a user wants to check out a product, most of the vendor web pages allow the user to select one of various credit card options accepted by the vendor, Ask the user how they want to pay for the item. If the vendor accepts the token as a payment option, the vendor web page displays the token in addition to the various credit cards. If the user selects a token as the payment method, the vendor web page causes the MSP to turn off the window that prompts the user to enter the user ID and password that the user has registered with the MSP. When the user clicks the Submit button, the vendor web server provides the user ID, password, vendor ID, and token amount required for the user to make a purchase, as shown in step 905. Send to MSP.

  Upon receiving the above information, the MSP accesses the user record 195 (FIG. 6) and determines at step 910 whether the user has enough tokens in his account to make a purchase. If so, the MSP updates the user's account balance as shown in step 915. At step 920, the MSP updates the user record 195 and vendor record 200, enters the transaction record into the transaction database 130, and enters the vendor total sales record 220 into the MSP database server 215 (FIG. 6). Then, in step 925, the MSP grants the vendor a micropayment transaction. As with most online shopping web sites, at step 930, the vendor web site displays a purchase confirmation and sends a thank you note. In step 935, the MSP sends an email to the user at the end of the day or upon completion of the micropayment transaction, notifying that the user has performed at least one business transaction during the day.

  The user can log in to the MSP and review the details of the micropayment transaction on the user interface 85 (FIG. 3). This increases the level of security and allows the user's account in the MSP to be disabled if the user discovers something unusual in the transaction record. As shown in step 940, the vendor can deliver a tangible item to the user to complete the transaction.

  In this case, when the user account is opened, the user or the MSP can send the shipping information regarding the product to the vendor according to the privacy contract signed by the user with the MSP. If the user chooses not to disclose any shipping information to the vendor, the vendor must ship the merchandise to the MSP so that the MSP can ship the merchandise to the user. Those skilled in the art should understand that other ways of disclosing shipping information to the vendor can be provided without necessarily disclosing the user's personal information to the vendor.

  If the user does not have enough tokens to make a purchase, at step 950, the MSP notifies the user of the lack of tokens in the user's account. The user can choose to reduce the amount of merchandise the user has purchased at step 955 or purchase additional tokens at step 960. If, at step 965, the user chooses to purchase additional tokens, the user is prompted to perform the process described in FIG.

  A vendor that allows a user to select one or more products and place them in a “shopping cart” and settle a payment for a tangible product to be purchased through a checkout process While current online shopping on web sites works relatively well, this method of commerce is not suitable for users to purchase content on the Internet for the following reasons.

  First reason: When selecting a content item to purchase (eg, article, publication, music, software, movie), the user downloads the content item to his or her Internet appliance and We prefer to gain the convenience of searching for other content and browsing other vendor web sites without having to perform “login” and “checkout” steps on the web site.

  Second reason: The user revisits the published articles that have already been paid, after browsing some other vendor websites, without having to pay again for the same content, • You may want to read on the appliance display screen.

  Third reason: The cost of each content item is on the order of a few cents or a few dollars and is usually very small, so it is not suitable for paying for content using a credit card.

Fourth reason: The process of using a shopping cart for purchases that total less than a few cents, a few dollars, or even less than a cent is impractical.
Other embodiments of the system and method described above with reference to FIGS. 20-22 may purchase content at multiple content vendor web sites without requiring login and checkout at each web site. To provide users with convenience.

  FIG. 31 shows a flowchart relating to a process for summarizing payment settlements to vendors by MSP when each vendor reaches the settlement limit of the amount or time. In step 980, the system and method of the present invention searches the vendor total sales record 220 and the vendor record 200 (FIG. 6) to determine whether the amount limit for that vendor has been reached, as shown in step 985. Check if. If not, at step 990, the system continues to check whether the time limit has been reached.

  Note that both monetary limits and time limits may vary from vendor to vendor. These limit values are determined in advance between each vendor and the operator of the MSP and recorded in the vendor record 200. If the result of checking either the amount limit (step 985) or the time limit (step 990) is positive, the system displays the amount to be paid to the vendor as shown in step 995. The bank is instructed to pay from the token sales account 225 to the vendor account 230a for the amount to be paid to the vendor, obtained from the total amount record 220 (FIG. 6). The payment settlement with the vendor by the operator of the MSP can be performed using an offline method such as sending a check to the vendor.

  In step 1000, the MSP updates the total vendor sales record 220 (FIG. 6) by entering the payment (payment) amount, date and time. If the vendor's amount limit or time limit has not been reached, no account settlement is processed for that vendor. The above account settlement process is performed for each vendor registered in the MSP to use a token as one of the user's payment options. In step 1005, the system checks whether all vendor payments have been processed. If not, as shown in step 980, the next vendor sales total record 220 and vendor record 200 (FIG. 6) are obtained. If so, the process is complete and resumed at a predetermined time or time interval.

  The system and method of the present invention allows a user to dispense or verify any transaction he has made. Typical contention for contention is an inappropriate description of the content, such as problems downloading or accessing purchased material, or finding that the user purchased the content and did not want it Or expression. If a user contends for a sufficiently large number or amount of transaction, the dispute is "pending" until the administrator reviews the dispute. However, in order to save on service costs, MSP will issue a refund of a sufficiently small amount or quantity that the system will automatically handle the dispute and it is inappropriate to compete for transactions over a given number of days. Define a number of conditions that make it possible to do. The number of days is predetermined by the MSP operator and can be set differently for each currency. Also, if a small amount is disputed, the system and method of the present invention automatically recognizes the dispute and invalidates the transaction. A dispute is automatically approved if it meets the following conditions predetermined by the MSP operator.

  Condition I: The total amount disputed by the user during a certain period (predetermined by MSP for each currency) is less than “m” in each currency. Here, “m” is a currency amount set by the MSP for each currency.

Even if Condition I is not met, the dispute still deserves automatic approval if the following conditions are met:
Condition II: The total amount disputed by the user during a period (predetermined by the MSP for each currency) is the total amount of purchases made by the user during that period (predetermined by the MSP for each currency) ) Less than 1 percent.

  Condition III: The total number of purchases disputed by the user during a period (predetermined by MSP for each currency) is the total number of purchases made by the user during that period (predetermined by MSP for each currency) Less than 1 percent).

  Condition IV: The total number of purchases contested by the user during a period (predetermined by MSP for each currency) is less than “n” (“n” is the number predetermined by MSP for each currency) Is).

  The systems and methods of the present invention also provide a back-end interface, which includes system administrator security features that associate each function of the back-end interface with a level or function of security. The system administrator login is given a security profile that allows only a specific subset of possible security functions that the system administrator needs to perform a specific task. Controlling the interruption of a security function under such a system administrator login hides control over that function. Both vendor and MSP administrator back-end interfaces can include this security feature.

  To make management easier, a system administrator with sufficient security rights can also create a security group with a subset of the security functions of that same system administrator. This makes it easier for security administrators to control the rights of so many people by adding them to or removing them from the security group.

  The system and method of the present invention protects the user's personal information from leaking to any participating vendor. In order to provide the user with the convenience of obtaining information about any participating vendor, the system allows the user to have “opt-out” and “opt-in” options.

  The opt-in option provides the user with the opportunity to receive additional information about sales and promotions from the vendor while continuing to maintain the highest possible privacy standards. This is accomplished in several ways. When a user queries an MSP by a vendor, the user follows a link from the vendor's web site to the MSP registration form. Upon completion of registration, the last page will contain a paragraph with a phrase such as "Yes, please send me information about special offers and promotions from [vendor name]", a check box that is checked by default Followed. The user can opt-out by not checking this box. If the user leaves this box checked, one of the following will happen: Either the MSP sends limited information (ie, the user's email address) to the vendor, or the MSP returns the user to the vendor's web page for filling out another form. If you opt out with registration, there is no subsequent opt-in method.

  MSP allows users who are already registered with MSP to select opt-in options for marketing from those vendors when they make their first purchase at the vendor. The opt-in option involves linking the user to a web page on the vendor's web site where the user can sign up on the vendor's mailing list. This link distribution method can be achieved by one of the following two methods. That is, when a user makes a first purchase at a vendor, the MSP displays a message on the user's Internet appliance that includes a link to the vendor's mailing list sign-up page, and the user When shopping for the first time, the MSP server sends out a “transaction summary” email every night, which includes a short message about the vendor, possibly to the vendor logo and vendor mailing list sign-up page. On the other hand, including links.

  In another embodiment of the present invention, content authors, publishers, or other intellectual property owners may use each vendor web that is authorized by MSP 60 to use the token as a user payment option for the content.・ When a user purchases content from the site, he always wins royalty. The price of each content is usually very small and requires micropayments as described in the method and system of the present invention, so payment to the author, publisher, or other intellectual property owner of such content The rewards to be paid are even smaller, in the range of amounts that are probably less than a cent. Therefore, it is necessary to organize micropayments. The content loyalty amount is entered into the vendor record 200 (FIG. 6) at the same time that the electronic transaction is recorded in the transaction database 130 (FIG. 6). This content loyalty amount is also added to the total content loyalty amount in the vendor total sales amount account 220 (FIG. 6) for each transaction between the user and the content vendor. Upon settlement of payment between MSP60 and each vendor, MSP60 operators will later provide the amount of royalty collected from each content vendor to each content author, publisher, or other intellectual property owner. The total amount of this content royalty is deducted so that it can be paid.

  FIG. 32 and FIG. 33 show flowcharts for calculating the total content royalty for each of the content authors, publishers, or other intellectual property owners, and for settlement of payments to these parties. . At step 1020, the system and method of the present invention accesses the vendor record 200 (FIG. 6) and, at step 1025, retrieves the content royalty amount and marks it “settled”. At step 1030, the content loyalty amount is placed in an account established for each content author, publisher, and other intellectual property owner. At step 1035, the process is repeated for all content loyalty amounts recorded in vendor record 200. At step 1040, the system checks whether the vendor records 200 for all vendors have been processed. If not, the system obtains the next vendor record 200 (FIG. 6), as shown in step 1020. If so, the system moves to settlement of payments to all content authors, publishers, or other intellectual property owners.

  In step 1045, the system and method of the present invention searches for the content author, publisher, or other intellectual property owner account, and then, as shown in step 1050, the content author, publisher, or , Check if other intellectual property rights owners have reached the price limit. If not, at step 1055, the system continues to check whether the time limit has been reached. Both the price limit and the time limit may be different for each content author, publisher, or other intellectual property owner.

  These limit values are pre-determined between each of the content author, publisher or other intellectual property owner and the operator of the MSP 60 and are recorded in an account opened for each. As a result of checking either the limit value of the amount (step 1050) or the limit value of time (step 1055), if the limit value is reached, the system proceeds to the token sales account 225 (FIG. 6) as shown in step 1060. To instruct the bank to make a payment to the bank account (not shown) of the author, publisher or other intellectual property owner of the content. The payment settlement by the operator of the MSP 60 can be performed using an off-line method such as sending a check to the content author, publisher, or other intellectual property owner.

  In step 1065, the MSP 60 updates the author, publisher, or other intellectual property owner of the content by entering the payment settlement amount and date. If the price limit or time limit has not been reached, account settlement is not processed for the author, publisher, or other intellectual property owner of the content. The above account settlement process is a content author, publisher, or other intellectual property owner whose content is sold by each vendor registered with MSP 60 to use the token as one of the user's payment options. For each of them.

  In step 1070, it is checked whether all of the content authors, publishers, or other intellectual property owners have been processed. If not, as shown in step 1045, the system obtains the next account for the author, publisher, or other intellectual property owner of the next content. If so, the process is complete and resumed at a predetermined time or interval.

  In another embodiment of the present invention, a user registered with the MSP 60 is also registered with the MSP 60 for a token (electronic fund) available in his account 195 in the user database 120 (FIG. 6). Allowed to send to another user who has his / her account 195 in the database 120. This feature provides the ability to conduct auctions on auction web sites to use tokens instead of using credit cards or electronic payment services provided by various Internet payment service providers. The auction buyer requests the MSP 60 to transfer the token from his account 195 to the seller's user account 195. The advantage of using a token instead of a credit card is that if the price of the item being auctioned is too low, it would be prohibitively expensive for the buyer to pay the seller using the credit card. Become more obvious. Using tokens in auctions gives sellers the opportunity to sell content items, tangible goods, or services that can be priced much less than those offered by current auction sites and buyers can purchase. To do.

  Furthermore, the operator of the MSP 60 can allow the micropayment server 80 to perform tasks such as token transfer at no cost, so that the user can transfer his token to the user account of the auction seller. On the other hand, no claim can be made. This adds another benefit to the auction site as current auction buyers need to pay a service charge to the electronic payment service provider. If the auction seller wants to get the actual currency instead of the token, the seller can request the MSP 60 to send a token for cash. The operator of the MSP 60 can then charge the seller (or user) for some service charge for redeeming the token for the actual currency. Upon receiving a request from the user, the operator of MSP 60 sends the funds to the user by sending a check or by transferring funds to the user's bank account.

  As described above, transferring a token from one user to another is not limited to an auction. The method and system of the present invention can also be used as an electronic person-to-person (P2P) system for one person to send money to another. The recipient first receives the funds in the form of a token. Unlike current electronic P2P systems, the recipient can have the flexibility to “cash” all or part of the received token.

  In yet another embodiment of the present invention, a single user account may be used by several users for the micropayment server 80 (FIG. 3). For example, in some cases, several family members may receive tangible goods, content, or services from vendor web sites that are allowed to accept tokens as one of their payment options by the operator of MSP60. It is desirable to be able to purchase. Similarly, a company may open a corporate account in MSP 60 and allow some of its authorized employees to make corporate purchases at various web sites using the same corporate account. When purchasing a company's own tangible goods within the same corporate account, the company must be replenished by authorized employees who need to replenish the company's inventory at retail outlets located in various regions. You may wish to have the company's own products purchased. In this case, the method and system of the present invention can be used to track each purchase made by an authorized employee through a company account open to MSP 60. This not only ensures accurate accounting for internal purchases of the company's own tangible goods, but also issues purchase orders and pays for invoices for each purchase made by employees. This also reduces the overhead cost.

  To handle the various purchase scenarios described above, the method and system of the present invention allows the user account 195 in the database 120 (FIG. 6) to have multiple passwords. As explained in the above example, each of a number of passwords given to a user account corresponds to a family member or corporate employee. The micropayment account user interface 85 has a user interface screen (not shown) that allows the user to enter an additional password into the user account 190 of the database 120. The account summary screen identifies each member of the multi-member account corresponding to each of the displayed member's individual transactions (not shown).

  In addition to filtering reports by start / end date, transaction type, transaction amount, etc., the user report screen also allows filtering of account reports by members of multi-member accounts (not shown). ) Further, although not shown, the micropayment account user interface 85 has a user interface screen that allows the user to set various access and usage limits for each member of the multi-member account. Usage limits can be set, for example, to prevent usage beyond the account balance agreed upon by family members, or access to undesirable web sites in the case of children.

  Although specific embodiments of the present invention have been described in detail above, it will be understood that this description is merely for purposes of illustration. Although specific features of the invention are shown in some drawings and not in others, this is for convenience only and any feature may be combined with other features in accordance with the invention. it can. The steps of the described processing can be interchanged or combined, and other steps can be included. Still other variations will be apparent to those skilled in the art in light of this disclosure. Applicants intend that such modifications fall within the scope of the claims.

FIG. 3 is an illustration showing the parties involved in performing a micropayment transaction in accordance with the principles of the present invention and the relationship between these parties. 1 is a schematic diagram of a system and network environment in which the present invention operates. FIG. 3 is a schematic diagram of software components used in a preferred embodiment of the present invention. FIG. 2 is a schematic diagram of micropayment server software configured in accordance with the principles of the present invention. FIG. 6 is a flow chart showing steps taken by a user when registering with an MSP to open a micropayment user account. Schematic showing an example of a database in a database server in MSP, including a record of total token sales sold and a record of vendor total sales in the vendor's bank account for payment settlement. is there. It is an illustration figure of the micropayment account user interface screen for user registration. FIG. 6 is an exemplary view of a micropayment account user interface screen for entering a user's personal information and billing information. FIG. 6 is an illustration of a micropayment account user interface screen showing a user's account summary and some links for accessing other micropayment account user interface screens. It is an illustration figure of the micropayment account user interface immediate summary screen which showed the history of micropayment transaction. FIG. 6 is an illustration of a micropayment account user interface screen for depositing funds into a micropayment account. FIG. 5 is an exemplary illustration of a micropayment account user interface screen for specifying usage limits for a micropayment account. FIG. 6 is an exemplary view of a micropayment account user interface screen describing a participating vendor that provides an electronic token as a payment method. FIG. 5 is a flow chart for performing a micropayment vendor API function call when a content item is purchased by a user. FIG. 6 is an illustration of a vendor web page that describes links to content items that a user can purchase. A is an example of a hyperlink for a content item that a user can purchase using an electronic token, and B is an example of a Java script function for initiating a micropayment transaction on a vendor web site. It is explanatory drawing. A is an illustrative view of a buy window displayed to a user when the user clicks a link on a vendor web page to purchase a content item, and B purchases the content item FIG. 8 is an illustration of a login window displayed to a user when the user clicks a link on a vendor web page and the user is not yet logged in to a micropayment service provider. A is an illustrative illustration of a micropayment vendor API function call performed by a vendor web server to initiate a micropayment transaction, and B locks down a content item that has been purchased by a user FIG. 6 is an illustrative illustration of a micropayment vendor API function call implemented by a vendor web server to accomplish this. It is explanatory drawing of the parameter passed by the micropayment vendor API function call shown in FIG. 18 from a vendor web server to a micropayment web server. FIG. 4 is a schematic diagram of a vendor's web site that accepts electronic tokens as payment for content items offered for sale on the web site. FIG. 3 is a schematic illustration showing steps taken by a user when purchasing a content item using a token at a number of vendor web sites. It is the schematic explanatory drawing which showed the system process performed when purchasing a content item using a token in a vendor web site. FIG. 5 is a flow chart relating to purchasing tokens or depositing funds into a micropayment account. FIG. 6 is a flowchart for securely purchasing content to verify vendor and content URL addresses, maintain integrity of transaction data and user authentication, and prevent unauthorized viewing or downloading of content. FIG. 6 is a flowchart for securely purchasing content to verify vendor and content URL addresses, maintain integrity of transaction data and user authentication, and prevent unauthorized viewing or downloading of content. FIG. 6 is a flowchart for securely purchasing content to verify vendor and content URL addresses, maintain integrity of transaction data and user authentication, and prevent unauthorized viewing or downloading of content. FIG. 6 is a flowchart for securely purchasing content to confirm vendor and content URL addresses, maintain transaction data and user authentication integrity, and prevent unauthorized viewing or downloading of content. FIG. 6 is an exemplary view of a window for funding a user's micropayment account when there is not enough funds in the user's micropayment account to purchase tangible goods, content, or services at the vendor website. FIG. 5 is a schematic explanatory diagram illustrating steps taken by a user when purchasing a tangible product or service using a token on a vendor's web site via a checkout process. FIG. 5 is a flowchart for purchasing a tangible product on a vendor website. FIG. It is a flowchart regarding summarizing the settlement of payment to the vendor by the MSP when each vendor reaches the settlement limit of the amount or time. Royalty paid to authors, publishers, artists, or other intellectual property owners for content sold by all vendors when the price or time settlement limit is reached, and authors issued by MSP FIG. 33 is a part of a flowchart showing the sum of settlement of payments to a person, an artist, or another intellectual property right owner. MSP authors combined with royalty payments as compensation to authors, publishers, artists or other intellectual property owners for content sold by all vendors when amount or time settlement limits are reached , Part of a flowchart showing settlement of payments to issuers, artists or other intellectual property owners, continued from FIG.

Claims (22)

A method of conducting electronic commerce over a computer network between a user and multiple vendors that rent or sell tangible goods, content, or services on multiple vendor websites, comprising:
Issuing a plurality of electronic tokens suitable for use in micropayment transactions from a micropayment service provider's micropayment service provider server to a user;
Providing a user with a micropayment user account from a micropayment service provider server, wherein each micropayment user account in the plurality of micropayment user accounts is purchased in a different currency Contains a subset of steps, and
Providing a micropayment vendor account to each of a plurality of vendors from a micropayment service provider server to settle a payment for an electronic token used by a user, wherein one or more of the plurality of vendors Providing a micropayment vendor account without disclosing the user's personal information without disclosing the user's personal information to
Recording for each electronic transaction between the user and the vendor a loyalty transaction in a corresponding micropayment vendor account in the micropayment service provider server. The method of claim 1, wherein at least some of the plurality of vendors provide content hosted on a vendor server hosting a vendor web site, the method further comprising:
Providing content to a user in exchange for an electronic token from the vendor server;
A method comprising recording, for each electronic transaction, a loyalty transaction for content at a vendor server in a corresponding micropayment vendor account. The method of claim 1, further comprising the step of maintaining a user database at the micropayment service provider server, the user database including micropayment user account information. And how to. The method of claim 1, further comprising the step of maintaining a vendor database at a micropayment service provider server, the vendor database including micropayment vendor account information. how to. The method of claim 1, further comprising maintaining a transaction database on a micropayment service provider server that includes a record of electronic transactions involving the use of electronic tokens at a plurality of vendor web servers. A method comprising the steps of: The method of claim 1, wherein the electronic token is issued directly to a user by a micropayment service provider or issued through a vendor server hosting multiple vendor web sites. Feature method. The method of claim 6, wherein an electronic token issued directly to a user by a micropayment service provider server or issued through a vendor server hosting multiple vendor web sites is A method comprising: a plurality of incentive tokens, wherein each incentive token of the plurality of incentive tokens is designed to provide incentives to a user at the sole discretion of the issuing party. 2. The method of claim 1, wherein the micropayment service provider server provides each user with a plurality of micropayment user accounts, the plurality of micropayment user accounts being a micropayment service provider server. Web sites hosted at, links on multiple vendor web sites to web sites hosted on a micropayment service provider server, and customer service representatives of micropayment service providers A method characterized by being opened by a user through one or more of the three. 9. The method of claim 8, wherein each micropayment user account of the plurality of micropayment user accounts stores a subset of electronic tokens purchased in different currencies in a micropayment service provider server. A method characterized in that it is configured. 9. The method of claim 8, wherein the micropayment service provider server provides a micropayment user interface to the user when the micropayment user account is opened by the user, and the micropayment user interface. A method wherein the interface is configured to allow a user to check the usage status of a micropayment user account. The method of claim 1, wherein the micropayment service provider server provides a micropayment vendor application program interface to multiple vendors when the micropayment vendor account is opened by multiple vendors. The micropayment vendor application program interface is configured such that a plurality of vendors can provide an electronic token as a payment method to a user. The method of claim 1, wherein the method further includes: free payment to one or more of a plurality of vendors to attract a user from a micropayment service provider server to use an electronic token for electronic transactions. A method comprising rewarding the vendor by providing a transaction with reduced electronic tokens or royalties. The method of claim 1, wherein the micropayment service provider server informs a plurality of vendors of purchases by a user that does not require multiple login and checkout procedures by the user at each vendor web site. A method characterized in that it is configured. The method of claim 1, wherein the micropayment service provider server is configured to allow a user to automatically block unauthorized charges in a micropayment user account. how to. The method of claim 1, wherein the micropayment service provider server places funds in the micropayment user account before or after the user purchases a tangible product, content, or service from the vendor. A method characterized by being configured to be able to. 2. The method of claim 1, wherein the step of settling the payment for the electronic token in the micropayment service provider server includes settling according to a predetermined amount limit value or a time limit value. how to. The method of claim 1, further comprising a routine that allows the micropayment service provider server to immediately view a summary of user purchases at multiple vendor websites. A method comprising the step of providing. The method of claim 1, further comprising a micropayment service provider server to allow a user to purchase content at multiple vendor websites. A method comprising providing a security routine for a predetermined period after a user logs into a provider server. The method of claim 1, wherein the micropayment service provider server further includes encryption of a user login identification with a time-varying encryption key by a security routine. A method comprising preventing unauthorized download of content from a vendor server hosting a site. The method of claim 1, wherein the method further comprises a micropayment service provider server in accordance with a security routine, a plurality of URL addresses corresponding to a plurality of vendor web sites, transaction data, and a user login. A method comprising preventing unauthorized download of content from a plurality of vendor web sites, including confirmation by an identification micropayment service provider server. The method of claim 1, further comprising: a micropayment service provider server creating a transaction ID for transaction data from a security routine; and the micropayment service provider server and a plurality of vendors. A method comprising the step of preventing unauthorized modification of transaction data by restricting transmission of transaction data with a vendor server hosting a web server. 2. The method of claim 1, further comprising: a micropayment service provider server, a web interface hosted on the micropayment service provider server; Providing a user interface including one or more of a downloaded client interface, an interactive voice response system, and an offline interface with a customer service representative of a micropayment service provider. A system characterized by

Images