JP2004513422A - Network-based payment service between users - Google Patents

Abstract

The network-based payment service has various functions for facilitating online user payment on a computer network. This service is provided by a service provider website (66) running a pay page application (76), which allows the user to remotely define a customized pay page for receiving payments from other users. I do. The paypage application (76) also handles remittances between accounts (72) of service users. In one embodiment, the paypage application (76) includes a feature for paypage owners that defines one or more "payboxes", including an associate web site that receives a commission for the resulting payment. Payment can be started from the Web site (120). As another function, a function is provided for a user to execute one-time operation settlement from a Web site (120) outside the service provider site (66). It also discloses various features that control access to content and services based on whether or not the visitor has made a voluntary or mandatory payment, or to what extent.

Description

【０１００】
好ましくはページタイトル、金額、説明フィールドなどのいくつかの要素がすべてのテンプレートに必要である。他の要素は、テンプレート設計者側が随意に選択できる。
【０１０１】
テンプレートはさらに、特定の操作を実行するためのページハンドラを参照することもできる。例えば、リベートテンプレートのハンドラは、購入した品目のシリアル番号を抽出し、その番号が有効なシリアル番号のリストに載っているか否かを調べることができる。このハンドラは、データベースを更新してこのシリアル番号に「使用済み」のマークを付けることもできる。さらに、テンプレートに、フィールド確認、計算、またはその他の機能を実行するジャバスクリプト（Ｊａｖａｓｃｒｉｐｔ）またはその他のコードを含めることもできる。
【０１０２】
ＵＲＬで渡すことができる要素については、ＵＲＬ内に含まれるパラメータ値によってペイページの値を指定変更することができる（図３のブロック９２を参照）。これらの修正された値は、ペイボックスまたはペイページの他のリンク（例えば、指定変更する提案決済金額）によって指定されるか、上級ユーザによって指定され得る。好ましい実施の形態では、これらのパラメータは名前−値のペアとして渡され、渡す順序は任意である。例えば、数量（ａｍｏｕｎｔ）、ＳＫＵ、販売価格（ｓａｌｅ ｐｒｉｃｅ）、税金（ｔａｘ）、および品目の発送（ｓｈｉｐｐｉｎｇ）を指定するＵＲＬは、以下の形式をとることができる。
ｈｔｔｐ：／／ＷＷＷ．ｓｅｒｖｅｒ．ｃｏｍ／ｂｏｂ＠ａｎｔｉｑｕｅｓ．ｃｏｍ／？ａｍｏｕｎｔ＝２０．００，ｓｋｕ＝１２３４，ｔａｘ＝４．５０，ｓｈｉｐｐｉｎｇ＝３．５０，ｉｔｅｍｐｒｉｃｅ＝１２．００
【０１０３】
Ｖ．ペイボックスおよびＳＰ生成表示オブジェクト
それぞれのペイボックスは、ペイページ所有者によって作成後割り当てられた一意的な識別子を持つのが好ましい。対応するペイページの識別は、この識別子内にエンコードされ、この識別子から判別することができる。この識別子を画像サーバ７７（図２）で使用し、コンテンツデータベースから関連するペイボックス指定を検索するのが好ましい。それとは別に、スタイル、色、ペイページ識別子などのペイボックスの指定の一部または全部をペイボックス識別子内にエンコードすることもできる。
【０１０４】
それぞれのペイボックスに２つのＵＲＬを関連付けるのが好ましい。第１のＵＲＬは、ペイボックスグラフィックを提供するのに使用され、例えば、以下の形式をとることができる。
ｈｔｔｐ：／／ｗｗｗ．ｓｅｒｖｅｒ．ｃｏｍ／ｐａｙｂｏｘｅｓ／｛ｐａｙ ｂｏｘ ＩＤ｝．ｇｉｆ
第２のＵＲＬは、対応するペイページを指しており、ユーザがペイボックスグラフィックをクリックしたときにペイページを取得するのに使用される。このＵＲＬは、例えば、次の形式をとることができる。
ｈｔｔｐ：／／ｗｗｗ．ｓｅｒｖｅｒ．ｃｏｍ／｛ｐａｙ ｂｏｘ ＩＤ｝
上記したように、この第２のＵＲＬとともに、１つまたは複数のパラメータ（提案決済金額など）を渡すことができる。ペイボックスＩＤを第２のＵＲＬに入れて、アプリケーション７６がペイボックス毎にクリックスルーのイベントを追跡するのが好ましい。ペイボックスグラフィックの要求も、ペイボックスのインプレッションに対するクリックスルーのイベントの比を追跡するために使用することができる。後述するように、インプレッション（つまり、表示イベント）、クリックスルー率、および成功（決済）率に関する履歴データをペイページ所有者に提供することができる。
【０１０５】
アソシエートホストペイボックスでは、ＵＲＬ形式は、ホスティングアソシエートの識別子を含むことを除き同じである。例えば、ＵＲＬは以下の形式をとることができる。
ｈｔｔｐ：／／ｗｗｗ．ｓｅｒｖｅｒ．ｃｏｍ／ｐａｙｂｏｘｅｓ／｛ａｓｓｏｃｉａｔｅ ＩＤ｝／｛ｐａｙ ｂｏｘ ＩＤ｝．ｇｉｆ
ｈｔｔｐ：／／ｗｗｗ．ｓｅｒｖｅｒ．ｃｏｍ／｛ａｓｓｏｃｉａｔｅ ＩＤ｝／｛ｐａｙ ｂｏｘ ＩＤ｝
アソシエートホストペイボックスが要求される毎に、またペイページがそのペイボックスに要求される毎に、アソシエートＩＤを記録するのが好ましい。上記したように、アソシエート参照ビジターが決済を行うときに、ペイページアプリケーション７６はさらにアソシエートＩＤを使用して参照アソシエートのアカウントを記入する。
【０１０６】
上記したように、ペイボックスＵＲＬおよび関連ＨＴＭＬコーディングは、第二者（所有者）または第三者（アソシエート）がホスティング対象となるペイボックスを選択するときにアプリケーション７６により自動的に生成される（図１０および１６を参照）。それとは別に、Ｗｅｂサイト開発者が、手動でＨＴＭＬまたはその他のコーディングを生成することによりペイボックスをインストールすることもできる。
【０１０７】
図２０は、一実施の形態において、ユーザ（ビジター）がペイボックスが含まれる外部（第二者または第三者）Ｗｅｂページを要求して表示したときに、発生するイベントの一般的シーケンスを示す図である。この図は、ＳＰサイト側でペイボックス画像以外のカスタマイズされた表示オブジェクトを提供する場合に使用する方法も示している。最初に、ビジターのブラウザ８４が、ページの要求を第二者または第三者サイト１２０に送信する（イベント１）。サイト１２０は、ペイボックスグラフィック（のＵＲＬ）を参照して要求されたＨＴＭＬ文書を返すことにより応答する（イベント２）。そのＨＴＭＬ文書を構文解析し、この参照を検出した後、ブラウザはＳＰサイト６６にペイボックスグラフィックを要求する（イベント３）。ビジターが決済サービスの既存のユーザであれば、この要求に、ＳＰサイト側でビジターの名前と１−Ｃｌｉｃｋ設定を検索するために使用するクッキーを含めることができる。
【０１０８】
ＳＰサイト６６は、図３を参照して説明したように、ペイボックスグラフィックを生成することによってこの要求に応答する（イベント４）。このプロセスの一部として、画像サーバ７７は、ペイボックスの指定をペイボックスＩＤから検索し、かつ／またはデコードする。例えば、これらの指定には、ペイページ所有者によって指定されたペイボックスのサイズ、色、メッセージ、および提案決済金額を含めることができる。さらに、要求に有効なクッキーが含まれていた場合、画像サーバ７７はビジターの名前および１−Ｃｌｉｃｋ設定を検索する。画像サーバを７７は、ペイボックス指定およびビジター固有の情報（使用可能な場合）を使用し、ペイボックスグラフィックを生成する。上記したように、グラフィックにはビジターの名前を含めることができ、また１−Ｃｌｉｃｋサービスが有効になっている場合には、１−Ｃｌｉｃｋ決済ボタン９２Ｆ（図４）を含めることができる。一実施の形態では支払人は、ペイボックスグラフィックス内に用意されているカスタマイズの種類またはレベルをあらかじめ指定することができる（セクションＸＩＩＩ「外部サイトでの処理に関する支払人の選択」を参照）。
【０１０９】
画像サーバ７７は、グラフィック内、または他の表示オブジェクト内に他の種類の個人化情報を含めることもできる。例えば、グラフィックまたは別の動的生成グラフィックは、ビジターのデフォルトクレジットカードの選択した数字を含むように、カスタマイズされ得る。一実施の形態では、例えば、画像サーバは、同じ外部Ｗｅｂページの最上段に表示される独立のバーを生成し、提供する。このバーには、ビジターの名前（ＳＰサイトで認識されている場合）と、現在の参照セッションで行った決済に関する情報が表示されるのが好ましい。このバーには、直前の決済を取り消したり、表示されている記事をＳＰによって維持されている個人ライブラリに追加するなどのいくつかの機能を実行するボタンが配置されてもよい。
【０１１０】
さらに、ペイボックスグラフィックまたはその他の表示オブジェクトには、ＳＰからの購入に使用できる製品またはサービスの個人推奨事項を含めることができる。個人推奨事項は、当技術分野でよく知られている方法を使用して、ユーザの購入履歴、参照履歴、および／または明示的に指定された関心事項に基づいて生成することができる。これらの個人推奨事項および／またはグラフィックのその他の表示属性は、さらにホスティングサイト１２０の識別に基づいて選択されることもできる。例えば、ホスティングサイト１２０がオンラインスポーツショップであり、ビジターのプロファイルがサーフィンに関心のあることを示している場合、そのグラフィックは、ＳＰによって販売されるサーフィン関連製品の一覧を表示する。さらに、ＳＰサイトは、カスタマイズしたグラフィックを提供するのではなく、テキストリンクやストリーミングオーディオまたはビデオクリップなどのユーザの識別に基づいて選択またはカスタマイズされた別の種類のオブジェクトを提供することもできる。さらに、個人化されたグラフィック画像またはその他の表示オブジェクトをあらかじめ生成し（要求の前に生成）、および／または動的生成の後にキャッシュして、要求毎にオンザフライ（ｏｎ−ｔｈｅ−ｆｌｙ）で生成しなくてもよいようにできることが理解されるであろう。
【０１１１】
さらに図２０で説明されているように、画像サーバは動的に生成されたペイボックスグラフィックをブラウザに返し（イベント５）、ブラウザにＷｅｂページ１２４内のグラフィック１２２が表示される。ＳＰサイトでは、グラフィックを直接ビジターのブラウザに送るので、グラフィックに含まれている個人情報は外部Ｗｅｂサイトまたはその運営者に公開されることはない。ビジターがその後ペイボックスを選択した場合（例えば、グラフィックをクリックする）、ブラウザは対応するペイページの要求をＳＰサイト６６（イベント６）に送信する。上記したように、この要求には１つまたは複数のペイページパラメータを含めることができる。
【０１１２】
上記のことから明らかなように、ＳＰサイトで外部サイトに個人化グラフィックスを表示する方法を、さまざまな非決済関連アプリケーション（例えば、個人推奨事項または関連するコンテンツへのリンクの提供）に対して使用することができる。さらに、この方法を使用して画像以外の個人化されたオブジェクトを提供することもできる。
【０１１３】
ＶＩ．ペイボックスの追跡およびフィードバックレポート
ペイページアプリケーション７６は、定期的フィードバックレポートをペイページ所有者および／またはそのアソシエートに送ることができる。所有者のために、フィードバックレポートには、所有者のペイボックスのそれぞれについて別々に示される、（ａ）ペイボックスインプレッションの数（表示イベント）、（ｂ）ペイボックスのクリックスルーイベントの数、（ｃ）そのようなクリックスルーイベントから生じる決済の数、および（ｄ）その結果生じる委託手数料といった１つまたは複数の基準が含まれ得る。ペイページアソシエートのために、定期的フィードバックレポートに同じ測定基準（ａ）〜（ｄ）を含めることができるが、データは、そのアソシエートがホストとなるペイボックス毎に別々に提供される。
【０１１４】
フィードバックレポートを生成するために、ペイページにアプリケーション７６は、ビジターのブラウザによってペイボックスが要求されるたび毎に、（ａ）ペイボックスＩＤ、（ｂ）もしあれば、アソシエートＩＤ、（ｃ）ビジターがその後ペイボックスをクリック（選択）していったかどうか、（ｄ）クリックスルーイベントの結果、ペイページ所有者に対して決済が行われたかどうか、（ｅ）もしあれば、決済の金額、（ｆ）もしあれば、アソシエート委託手数料の金額、（ｇ）知られている場合、ビジターの素性、および（ｈ）閲覧の日時などの情報をログに記録するのが好ましい。これらの種類及びその他の種類の情報を、よく知られている方法によってサーバアクセスログから抽出することができる。
【０１１５】
上記の情報に加えて、所有者に対し、サインアップして各ペイボックスのホストとなっているアソシエートの数に関するデータを提供することができる。
【０１１６】
ＶＩＩ．決済履歴またはその他のユーザ属性に基づくコンテンツへのアクセス制御（図２１）
アプリケーション７６はさらに、一部または全部の受取人に対する自発的決済履歴に応じて支払人を格付けする機能を含むこともできる。この情報を使用することにより、ペイページ所有者またはその他のコンテンツプロバイダは、「良い」支払人に対して追加コンテンツを提供する（または他の処置を講じる）ことができる。例えば、音楽家は、ボーナストラック、高音質ＭＰ３ファイルを決済履歴が適正な人々に提供することができる。
【０１１７】
格付けを生成するために、アプリケーション７６は、支払人毎に、（１）表示されているペイページの数、（２）行われた決済の数、（３）提案金額と比較した決済金額（決済が行われる場合）、および（４）上記データに関して、ペイページの種類（慈善、自己申告システム、ティップ支払など）といった情報を取得することができる。このようなデータを使用することで、アプリケーションは（１）ペイページ表示／決済％、（２）支払額合計／提案額合計（決済が行われたページについて）、および（３）支払済み金額合計／提案額合計（表示された全てのページについて）などの基準のうち１つ以上（および、場合によっては、さらに別の基準）に基づいて、支払人格付けを計算することができる。アプリケーションは、支払人がペイボックスを表示した回数を追跡して格付けに取り込むこともできる。さらに、アプリケーションは、いくつかのペイページの種類毎に別々の支払人格付けを生成することができる。
【０１１８】
さまざまな方法を用いることで、コンテンツプロバイダは、格付けベースのコンテンツをビジターに提供することができる。このような方法の１つに、ＳＰサイト６６を使用して、ビジターを格付けベースの目的サイトにリダイレクトする方法がある。この方法を使用する場合、コンテンツプロバイダはまず最初に、「悪い」、「平均的」、「良い」などの複数の支払人格付けカテゴリのそれぞれについて別々の目標（例えば、各々のＵＲＬ）を設定する。例えば、コンテンツプロバイダは、「悪い」ＵＲＬにサンプルバージョンのダウンロード可能ミュージックタイトルをポストし、「平均的」ＵＲＬに標準バージョンのタイトルをポストし、「良い」ＵＲＬに高級バージョンのタイトル（例えば、ボーナストラック付き、または高音質オーディオ）をポストすることができる。コンテンツプロバイダサイトから他の方法ではアクセスできないＵＲＬ（例えば、入るためのリンクまたはその他のリンクが設定されていない）をこの目的のために使用することができる。
【０１１９】
その後、コンテンツプロバイダは、ＳＰサイト６６の「格付けベースのコンテンツ設定」領域にアクセスし、（１）目標のＵＲＬ、および（２）画像サーバ７７によって提供される対応するグラフィックスに表示するメッセージを指定する。上記の例を続けると、メッセージは次のようである。
悪い：「Ｍｏｂｙの最新シングルのサンプルをダウンロードするにはここをクリック」
平均的：「Ｍｏｂｙの最新シングルをダウンロードするにはここをクリック」
良い：「Ｍｏｂｙの最新ＣＤをダウンロードするにはここをクリック」
このようなメッセージがそれぞれ、ＳＰサイト６６によって提供されるさまざまなバージョンのグラフィック上に表示される。ペイボックスグラフィックに、（例えば、設定変更可能な「ありがとうございました」ページのＵＲＬを介して、）決済機能とコンテンツへのアクセス機能の２つの役割を持たせることができるが、これらのグラフィックスは、ペイボックスグラフィックスと別になっているのが好ましい。次に、ＳＰサイトは、（図１０および１６のように、）Ｗｅｂページ内にグラフィックをインストールするＨＴＭＬまたはその他のコードを生成することができる。ペイボックスの場合と同様に、グラフィックの代わりに、他の種類の表示オブジェクト（アニメーションなど）を使用することもできる。
【０１２０】
図２１は、グラフィックがインストールされているページにビジターがアクセスしたときに発生するイベントのシーケンスを示す図である。最初に、ビジターのブラウザ８４が要求されたＨＴＭＬ文書を要求し、コンテンツプロバイダサイト１４０がそれを返す（イベント１および２）。次に、ブラウザ８４は、このＨＴＭＬ文書内で参照されているグラフィックの要求をＳＰサイト６６に送信する（イベント３）。ビジターが決済サービスのユーザである場合、この要求にビジターのクッキーを含めることができる。グラフィックの要求に応答して、ＳＰサイト６６（画像サーバ７７）は、ビジターの格付けを検索し、対応するバージョンのグラフィックを選択する（イベント４）。ビジターが不明な場合、またはそのビジターに対して格付けが存在していない場合、デフォルトのバージョンのグラフィックが選択される。選択されたグラフィック１４２は、事前に生成されたものか、または動的に生成されたものであり、ブラウザに返信され（イベント５）、Ｗｅｂページ内に表示される。続いて、ビジターがこのグラフィック１４２をクリックすると、ブラウザはビジターのクッキーとともにＳＰサイト６６にコンテンツの要求を送信する（イベント６）。ＳＰサイトは、ユーザの格付けおよび対応する目標のＵＲＬを検索し（イベント７）、ブラウザをこのＵＲＬにリダイレクトする（イベント８および９）ことによってこの要求に応答する。この方法の１つの重要な点は、ＳＰがビジターの素性または格付けをコンテンツプロバイダサイトに明かさないことである。
【０１２１】
図２１に示されている方法を変えることで、ＳＰサイトが、自発的決済履歴以外の何らかのユーザ属性に基づいて目標のＵＲＬを選択するようにできる。例えば、ＳＰサイトで、ユーザが特定の品目を購入したかどうかに基づいて目標のＵＲＬを選択することも可能である（例えば、特定のＣＤを購入したユーザはそのＣＤに関連するボーナストラックにアクセスできるが、それ以外のユーザはそのようなボーナストラックのサンプルにしかアクセスできない）。他の例として、ＳＰサイトが、ユーザがコンテンツプロバイダから購読を購入したか否かに基づいて目標のＵＲＬを選択する方法がある。
【０１２２】
ＶＩＩＩ．決済ベースのコンテンツアクセス
外部コンテンツにアクセスする前に、サービスのペイページおよびペイボックスの機能を使用して必要な決済の集金を行うこともできる。このような機能を提供するために、決済サービスでは支払を受け取ったときにコンテンツプロバイダ／受取人に通知するためのプロトコルをサポートする。このようなプロトコルの一実施例を以下に示す。
【０１２３】
１）各コンテンツプロバイダは、ペイページを設定するときに、コンテンツプロバイダの公開鍵及び１つまたは複数の目的のＵＲＬをＳＰに渡す。例えば、目的のＵＲＬは、ダウンロード可能または表示可能なコンテンツへのアクセスを提供する。
２）顧客がそのペイページを使用して決済を行うときに（オプションにより、セクションＸで説明している１回操作決済方法を使用して）、販売額、日時、および／またはその他の取引情報（例えば、顧客の電子メールアドレス、要求を出すコンピュータのＩＰアドレスなど）を文字列にフォーマットし、その文字列をコンテンツプロバイダの公開鍵により暗号化する。
３）暗号化された文字列は、ＳＰサイトによって、リダイレクトメッセージ中の目的のＵＲＬ中のパラメータとして、最初にビジターのブラウザに渡され、最終的にコンテンツプロバイダサイト１４０に渡される。この代わりに、この文字列を別の通信方法でコンテンツプロバイダサイトに転送することもできる。
４）コンテンツプロバイダサイトは、その文字列を復号化し、抽出された情報の妥当性に応じてコンピュータへのアクセスを提供する。コンテンツプロバイダは、ＵＲＬが１回限りのＵＲＬとなるように、この文字列の再利用を禁止することができる。この時点では、ＳＰは、かかわっている必要はない、あるいはさらなる情報をコンテンツプロバイダに渡さない。
【０１２４】
ＩＸ．ペイページ内の決済カウンタデータの表示
上述のように、このサービスによって実装できる機能の１つを使い、ペイページ所有者は目標チャートなどのリアルタイム決済カウンタデータをペイページ内に表示することができる。いくつかの種類のペイページ（例えば、慈善および自己申告システムページ）に対して、この機能を有効にすることができ、また決済履歴データをペイページビジターに伝達するのに、この機能を使用することができる。例えば、慈善団体用のペイページには、寄付金集めイベント全体を通して集められる金額を示すチャートを表示することができ、またダウンロード可能作品の作成者は、その作品に対して自己申告システム決済を行ったビジターの人数を表示することができる。両方の場合において、このチャートは、所有者指定の目標に関するリアルタイムの合計を示す目標チャートの形式とすることができる。このカウンタは、特定のペイページ、または所有者によって指定された１組の共同所有のペイページに基づいていてもよい。
【０１２５】
この機能の一実施態様では、ペイページ所有者に対して、（ａ）受け取った決済の件数、（ｂ）そのような決済の合計額、または（ｃ）その両方を示すカウンターを表示するオプションが与えられる。さらに、所有者に対して、このカウンタを目標チャートとして表示するオプションを与えてもよいが、その場合、所有者は目標値を指定するように求められる。目標チャートを使用する場合、所有者は、目標に達したときに決済の集金を続けるべきか否かを指定することもできる。一度カウンタが定義されると、アプリケーション７６は、決済の受け取り時にカウンタを更新し、カウンタ合計値をペイページ内に表示する。例えば、合計額を棒グラフまたは温度計として表示し、目標に関して受け取った合計額を示すことができる。
【０１２６】
さまざまな他の種類の履歴データもペイページ内に表示できる。例えば、アプリケーションは、平均決済額、決済を行うビジターの割合、及びペイページのアソシエートが稼いだ平均の合計手数料のうちの１つ以上を表示する機能を提供できる。
【０１２７】
Ｘ．外部サイトからの１−Ｃｌｉｃｋ決済（図２２）
サービスによって実装できる他の機能を使うと、ユーザは外部ホストペイボックスまたはその他の表示オブジェクトから直接１−Ｃｌｉｃｋ（１回の操作）決済を（即ち、決済プロセスで対応するペイページを表示しないで）行うことができる。この機能を実装するために、各ペイページに、ペイボックスからの１−Ｃｌｉｃｋ決済が有効か否かを示す「パススルー（ＰａｓｓＴｈｒｕ）」プロパティを割り当てることができる。所有者に、ペイページの作成または編集時にそのページのパススルー（ＰａｓｓＴｈｒｕ）設定を指定することを許可することができる。パススルー有効化ペイページに対して、ＳＰサイト６６が、特別な１−Ｃｌｉｃｋペイボックスを承認された１−Ｃｌｉｃｋビジターに提供する。ビジターが１−Ｃｌｉｃｋペイボックスを選択すると、ＳＰサイトは、即座にそのユーザを所有者（または場合によってはホスティングアソシエート）によってあらかじめ指定されている「ありがとうございました」ＵＲＬにリダイレクトする。
【０１２８】
図２２は、このプロセスを詳細に示している。図示した例では、ユーザが１−Ｃｌｉｃｋサービスをオンにしていること、且つ要求されたペイボックスに関連するペイページがパススルー有効化されている（ＰａｓｓＴｈｒｕがオンになっている）ことを仮定している。イベント１〜３は、図２０と同じものである。ペイボックスグラフィックの要求（イベント３）に応答して、ＳＰサイト６６は、ビジターが１−Ｃｌｉｃｋサービスをオンにしており、ペイページがパススルー有効化されていると判断する。したがって、ＳＰサイトは、特別な１−Ｃｌｉｃｋバージョンのグラフィックを生成して返信する（イベント４および５）。このグラフィックには、選択することで取引が完了することを示す１−Ｃｌｉｃｋボタンまたはメッセージが含まれる。さらに、上記したように、ペイボックスグラフィックに、ビジターと受取人の名前が表示され、また取引に使用されるクレジットカード番号の選択された数字などのその他の情報も含むことができる。
【０１２９】
ペイボックスグラフィックを選択した後、ブラウザ８４はユーザのクッキーとともにペイページの要求を送信する（イベント６）。クッキーはユーザが１−Ｃｌｉｃｋユーザであることを示すので、サイト６６は、（１）ビジターの１−Ｃｌｉｃｋ設定に従って取引を実行し（イベント７）、（２）ブラウザを所有者指定の「ありがとうございました」ＵＲＬにリダイレクトする（イベント８）ことによって、この要求に応答する。例えば、このＵＲＬは、ペイページ所有者の外部Ｗｅｂサイトのページとしてもよい。この代りに、ビジターのブラウザを決済が開始された外部ページにリダイレクトで戻すことができ、その場合、このページを決済確認メッセージ（例えば、「ＣｏｎｔｅｎｔＰｒｏｖｉｄｅｒ．ｃｏｍに１ドル支払ました」）が含まれるＳＰ提供の表示オブジェクトとともに表示することができる。
【０１３０】
特別の１−Ｃｌｉｃｋバージョンのペイボックスグラフィックは、承認された１−Ｃｌｉｃｋユーザに対して表示されるのが好ましいが（図２２のイベント４および５）、その代りに標準のグラフィックまたはその他のリンクをすべてのユーザに対して表示することができる（例えば、「ここをクリックすると２５セントを支払います」と表示されているボタン）。このような実施の形態では、承認されたビジターの名前は、オプションとして、ＳＰサイトによって提供される他の何らかの表示オブジェクトに表示され（Ｗｅｂページの最上段にあるバーなど）、同じ外部Ｗｅｂページ内に表示され得る。さらに、上記の例のペイボックスグラフィックスは決済額を示すテキストを含んでいるが、決済額を別の方法で伝達することもできる。例えば、緑色、青色、および赤色の決済ボタンは、それぞれ５セント、１０セント、および２５セントの支払を表す。さらに、所定の外部Ｗｅｂページは、ビジターが決済額を選択できるように、複数の１−Ｃｌｉｃｋペイボックス（例えば、上記した３色の色分けボタン）を含むことができる。
【０１３１】
さらに、受取人が、自分のペイページを持たなくても、図２２に示し、上記で説明した方法を使用することができる。例えば、ＳＰに登録した後、受取人に、ビジターから外部（第二者および／または第三者）サイトへの支払を受け取るために使用する一意的なＵＲＬを与えることができる。このＵＲＬは、一意的ペイページＵＲＬの代わりになる。承認された１−Ｃｌｉｃｋビジターの場合、このプロセスは図２２に示し、上記で説明したのと同じである（即ち、ビジターは即座に「ありがとうございました」ページなどにリダイレクトされる）。承認１−Ｃｌｉｃｋユーザでないビジターの場合には、ペイボックスを選択するとＳＰサイトがサインインページを返すのが好ましい。そこで、ユーザはサインインし（または、必要ならば登録し）、汎用決済パイプラインを介して決済を完了する。
【０１３２】
また、このサービスで、外部サイトから行われる決済をすべて１−Ｃｌｉｃｋ決済にすることを要求することも考えられる（即ち、ユーザに対して、このような決済を行うために、１−Ｃｌｉｃｋサービスのオン、オフの設定を行うオプションを与えない）。このような実施の形態では、承認されたすべてのビジターは、１−Ｃｌｉｃｋユーザとして取り扱われる。
【０１３３】
ＸＩ．コンテンツ配布モデル
上記したように、ＳＰサイト６６は、ペイページ所有者のダウンロード可能なコンテンツのホストとなるサービスを実装することができる。ペイページ所有者は、サイトの特別領域を介してこのようなコンテンツを（オプションによって、説明文とともに）サービスプロバイダデータベースにアップロードすることができる。このようなサービスが提供される場合、サイトは、ユーザが、ダウンロード可能なコンテンツを検索し、作成者に対する自発的または要求される決済を行うための機能を備えることができる。例えば、検索エンジンがダウンロード可能な作品の製品詳細ページを返した場合、その詳細ページに自動的には、作成者のペイボックスが表示される。ＳＰサイトは、ペイページ所有者が自分のコンテンツへのリンクを作成し、それらのリンクを自分のペイページ内に埋め込むようにもできる。例えば、小説家のペイページに、ＳＰサイトがホストとなるそれぞれの小説へのリンクを張ることができる。
【０１３４】
ＳＰサイト６６は、Ｗｅｂサイト運営者が、（１）ペイページ所有者によりアップロードされたコンテンツを（例えば、検索エンジンを使用して）見つけ、（２）そのようなコンテンツを、関連するペイページ所有者のペイボックスとともに自分のＷｅｂサイトに再発行することができるメカニズムを提供することもできる。Ｗｅｂサイト運営者が、このプログラムに参加するには、対応するペイボックス無しではコンテンツを再発行しないことを、オンライン契約によって要求されてもよい。新しいコンテンツをＳＰデータベースにアップロードするとき、ペイページ所有者は自分が受け取りたい手数料（もしあれば）を指定することができる。
【０１３５】
ＳＰサイト６６は、他のユーザが、他のユーザのサービスプロバイダホストコンテンツを見つけて、そのようなコンテンツへのリンクを作成し、それらのリンクを自分のＷｅｂサイト内に埋め込むメカニズムを提供することもできる。例えば、音楽サイトの運営者は、ＳＰデータベース内で音楽ファイルを検索し、そのようなファイルへの（または作成者のペイページへの）リンクを音楽サイト内に組み込むことができる。アソシエートホストペイボックスの場合と同様に、これらのリンクは、ＳＰサイトによって自動的に生成され、ＳＰが付託の手数料を追跡して支払うことを可能にするアソシエート識別子を設定することができる。ビジターがこのようなリンクを辿ると、常にサイトは、ペイボックス、ペイページ、または決済システムへのその他のエントリポイントとともにコンテンツを表示する。このモデルによれば、このようなリンクのホストとなるユーザは、別のユーザがリンクを辿り、自発的または要求される支払を所有者に対して行うときに、常に手数料を受け取ることができる。
【０１３６】
ＸＩＩ．外部コンテンツプロバイダサイトへの決済サービスの組み込み
図２３〜２５は、上記の機能の内のいくつかがどのように使用され、ユーザが、外部コンテンツプロバイダサイトから１−Ｃｌｉｃｋ、自己申告システム少額決済を行い、他のＳＰサービスにアクセスすることが可能になるかを示す画面表示例である。これらの例では、サービスプロバイダサイトはＡｍａｚｏｎ．ｃｏｍ　Ｗｅｂサイトである。
【０１３７】
図２３は、外部コンテンツプロバイダサイト「Ｆｏｒｂｅ．ｃｏｍ」という仮想のＷｅｂページの例を示している。外部ページは、２つの決済リンク１６０および１６２を含んでおり、それぞれのリンクは対応する記事と関連させて提供されている。これらのリンクは、ＳＰサイトを指しているが、Ｆｏｒｂｅ．ｃｏｍのパススルー有効化ペイページを指すのが好ましい。
【０１３８】
図２４は、承認された１−Ｃｌｉｃｋユーザが、図２３において決済リンク１６０を選択したときに表示されるＦｏｒｂｅ．ｃｏｍサイトの仮想ページを示している。上記したように、サービスプロバイダアカウントを持つすべてのビジターを、この目的のために１−Ｃｌｉｃｋユーザとして扱うことができる。この例では、ＳＰサイトは、ビジターであるＦｕＭｉｎｇ　Ｙｏｕｎｇのアカウントに０．０５ドルを課金し、直ちにこのビジターを記事が表示されるページ（「ストーリーページ」）にリダイレクトすることにより、リンクの選択に応答する。この例のストーリーページは、バー１６６及びディスカッション領域１６８を含み、これらは、上記の方法に従ってサービスプロバイダサイトによって動的に生成され、提供される。バー１６６は、ビジターのアカウントに０．０５ドル課金されたことを示す決済確認メッセージを表示する。バー１６６は、さらに、（ａ）検索を開始するボタン、（ｂ）この記事の対価を支払ったユーザによって普通に購入された品目の一覧を表示するボタン、および（ｃ）関連する製品を表示するボタンの（ＳＰサイトにリンクしている）各ボタンが含まれている。ディスカッション領域ボックス１６８は、ビジターが記事に関するコメントを表示し追加することを可能にする。ディスカッション領域オブジェクトを介して追加されたコメントは、ＳＰサイトのデータベースに格納される。
【０１３９】
図２５は、他の実施の形態に係るストーリーページを示している。この実施の形態では、バー１６６は、記事にアクセスするため行った自発的決済を無効にする「決済取消」ボタン１６７も含む。このボタン１６７が選択されると、ＳＰサイトは、（１）支払人のクレジットカードがまだ課金されていない場合には取引を取り消し、（２）クレジットカードがすでに課金されている場合にはその取引の返金を行う。このようにして決済の取り消しまたは返金を行う機能も、ユーザが上記のような自発的または自己申告システム決済を行う他の状況において使用される。この機能のいくつかの実施の形態では、支払人は、その決済後の特定の時間内では自発的決済を取り消すことだけができる。それぞれの受取人またはコンテンツプロバイダが、ＳＰサイトを介して、オプションによってはペイページ毎に別々に、この時間を指定するようにできる。
【０１４０】
さらに、バー１６６は、ビジターがサービスプロバイダサイトに維持されている個人ライブラリに記事を追加することを可能とする「ライブラリに追加」ボタンを含む。この例では、「ディスカッション領域」ボックス１６８は、ドロップダウンまたは「展開された」状態で示されているドロップダウンボックスである。
【０１４１】
図２６は、コンテンツプロバイダが手動でＨＴＭＬコードを、コンテンツを「決済有効化」するリンクの周りに追加する（つまり、図２３に示されている種類の決済リンクを追加する）方法を説明するＳＰサイトのページの例である。このページは、オプションのディスカッション領域ボックス１６８を決済リンクと同じ外部Ｗｅｂページ内に挿入する方法についても説明する。
【０１４２】
図２７は、ＳＰサイトで提供される、決済リンクを追加するＨＴＭＬまたはその他のコーディングを自動的に生成する「決済リンク作成ツール」フォームを示している。一度ユーザがフォーム（付託追跡に使用されるニックネームを指定する操作を含む）に記入し、送信すると、ＳＰサイトは外部ＷｅｂページのＨＴＭＬ文書に挿入されるコーディング（図２８）を生成して返信する。
【０１４３】
ＸＩＩＩ．外部サイトでの処理に関する支払人の選択
ＳＰサイト６６は、支払人が、ペイボックスまたはその他のＳＰカスタマイズコンテンツのホストになっている外部（第二者および／または第三者）Ｗｅｂサイトを閲覧するときに、ＳＰによって扱われる方法をあらかじめ指定する機能を備えることもできる。例えば、それぞれの支払人は、ＳＰサイトのアカウント設定領域を介して、（ａ）外部Ｗｅｂサイトのページ内で承認されるか否か、（ｂ）外部Ｗｅｂサイト内で個人的製品／サービス推奨を表示されるか否か、（ｃ）関連するサイトへのリンク、および／または外部サイト内の関連するコンテンツを表示されるか否か、（ｄ）支払人格付けベースのコンテンツへのアクセスを許可されるか否か（上のセクションＶＩＩを参照）、（ｅ）外部サイトから１−Ｃｌｉｃｋ決済を行えるか否か、（ｆ）外部サイトに行った決済の通算合計を表示されるか否か、（ｇ）外部サイトに行った決済があるしきい値に達したときに通知されるか否かなどの１つ以上の選択を指定するオプションを利用できる。これらおよびその他の選択を「ユーザアカウント」データベース７２に格納することができ（図２）、またＳＰサイトではこの選択を使用して、外部サイト内に表示されるペイボックスグラフィックスおよび／またはその他のコンテンツをカスタマイズすることができる。支払人はさらに、外部サイトから行った１−Ｃｌｉｃｋまたはその他の決済を処理する１つ以上の決済オプションを設定するオプションを利用することができる（例えば、サイトＡで行ったすべての１−Ｃｌｉｃｋ決済をクレジットカードＡに課金し、サイトＢで行ったすべての１−Ｃｌｉｃｋ決済をクレジットカードＢに課金する）。
【０１４４】
本発明は、好ましいいくつかの実施の形態として説明されたが、本明細書で述べているすべての特徴および利点を備えているわけではない実施の形態も含めて、当業者には明白である他の実施の形態も、本発明の範囲内に含まれる。そして、本発明の範囲は、付属の請求項によって定義されている。
【図面の簡単な説明】
【図１】ユーザを決済サービスに登録し、ペイページを管理し、サービスプロバイダサイトを利用して各種関連操作を実行するプロセスの全体の流れを示す図である。
【図２】決済サービスを実装するために使用される基本Ｗｅｂサイトコンポーネントを示す図である。
【図３】サービスプロバイダサイト側でペイページを表示し、ペイページ取引を処理するプロセスを示す図である。
【図４】ペイページの例を示す図である。
【図５】ユーザがサービスプロバイダサイトを通じてペイページ及びペイボックスを管理する方法を示すＷｅｂページの例を示す図である。
【図６】ユーザがサービスプロバイダサイトを通じてペイページ及びペイボックスを管理する方法を示すＷｅｂページの例を示す図である。
【図７】ユーザがサービスプロバイダサイトを通じてペイページ及びペイボックスを管理する方法を示すＷｅｂページの例を示す図である。
【図８】ユーザがサービスプロバイダサイトを通じてペイページ及びペイボックスを管理する方法を示すＷｅｂページの例を示す図である。
【図９】ユーザがサービスプロバイダサイトを通じてペイページ及びペイボックスを管理する方法を示すＷｅｂページの例を示す図である。
【図１０】ユーザがサービスプロバイダサイトを通じてペイページ及びペイボックスを管理する方法を示すＷｅｂページの例を示す図である。
【図１１】ユーザがサービスプロバイダサイトを通じてペイページ及びペイボックスを管理する方法を示すＷｅｂページの例を示す図である。
【図１２】ユーザがサービスプロバイダサイトを通じてペイページ及びペイボックスを管理する方法を示すＷｅｂページの例を示す図である。
【図１３】ユーザが他のユーザのペイボックスを見つけてインストールし、ペイページアソシエートになる方法を示すＷｅｂページの例を示す図である。
【図１４】ユーザが他のユーザのペイボックスを見つけてインストールし、ペイページアソシエートになる方法を示すＷｅｂページの例を示す図である。
【図１５】ユーザが他のユーザのペイボックスを見つけてインストールし、ペイページアソシエートになる方法を示すＷｅｂページの例を示す図である。
【図１６】ユーザが他のユーザのペイボックスを見つけてインストールし、ペイページアソシエートになる方法を示すＷｅｂページの例を示す図である。
【図１７】ユーザが既存のペイページのカスタマイズしたバージョンを使って他のユーザに決済を要求するための機能を示す画面表示である。
【図１８】ユーザが既存のペイページのカスタマイズしたバージョンを使って他のユーザに決済を要求するための機能を示す画面表示である。
【図１９】ユーザが既存のペイページのカスタマイズしたバージョンを使って他のユーザに決済を要求するための機能を示す画面表示である。
【図２０】ユーザがペイボックスが含まれるＷｅｂページを要求したときに発生するイベントのシーケンスを示す図である。
【図２１】ビジターの自発的決済履歴に基づき（通常は、ペイページ所有者の）ユーザを外部コンテンツにリダイレクトするサービスの方法を示す図である。
【図２２】１−Ｃｌｉｃｋユーザが外部ホストのペイボックスから直接決済取引を完了するための方法を示す図である。
【図２３】（ａ）サービスプロバイダサイトによって提供されるサービスへのリンク、および（ｂ）サービスプロバイダサイトによって提供される個人化されたコンテンツによって、外部ＷｅｂサイトのＷｅｂページをどのように強化できるかを示す仮説的画面表示である。
【図２４】（ａ）サービスプロバイダサイトによって提供されるサービスへのリンク、および（ｂ）サービスプロバイダサイトによって提供される個人化されたコンテンツによって、外部ＷｅｂサイトのＷｅｂページをどのように強化できるかを示す仮説的画面表示である。
【図２５】（ａ）サービスプロバイダサイトによって提供されるサービスへのリンク、および（ｂ）サービスプロバイダサイトによって提供される個人化されたコンテンツによって、外部ＷｅｂサイトのＷｅｂページをどのように強化できるかを示す仮説的画面表示である。
【図２６】決済リンクおよび顧客検討モジュールを外部Ｗｅｂサイトのページに追加するためのインストラクションページを示す図である。
【図２７】サービスプロバイダサイトの決済リンク生成ツールを示す図である。
【図２８】サービスプロバイダサイトの決済リンク生成ツールを示す図である。[0001]
(Field of the Invention)
The present invention relates to computer-implemented services and user interfaces that a user can use to pay other users. The invention further relates to a method of incorporating the user-to-user payment service into an external website including, but not limited to, a content or service provider website.
[0002]
(Background of the Invention)
Various web-based services have been developed that allow users to collect money from other users. Examples of such services include Qpass and BillPoint. Generally, these services have various deficiencies.
[0003]
One such deficiency is that the payer usually has to perform a significant number of setup steps before the new payee can be paid. As such, existing services are not well-suited for recipients to collect small or one-off payments from many users. For example, such payments may need to be collected when an author, musician, or other content creator wants to ask a consumer of downloadable content to make a donation, or a charity may ask the public for online donations. It is time to want.
[0004]
Also, many existing payment services have the disadvantage that they do not have a simple mechanism for website operators to incorporate the collection process into their website. For this reason, the settlement service of the prior art is not suitable for a small website operator to request a payment and collect money on its own website. For example, this may be necessary when a website operator wants to pay for content hosted by that website from consumers. Still further, existing payment services have the disadvantage that the payee does not have an appropriate mechanism to ask other web site operators to assist in the collection process.
[0005]
Prior art payment services also typically lack the ability to efficiently send customized or personalized payment requests to recipients. Such a request may need to be made, for example, when a seller wants to send a personalized invoice to a buyer, or when an individual wants to request an event-related contribution from a small group of friends.
[0006]
Also, many payment services include mechanisms by which external websites provide content to users, whether or not such users voluntarily or requested pay. Is missing. Further, conventional payment systems typically do not recognize returning customers.
[0007]
(Summary of features of the invention)
The present invention solves the above and other problems by presenting various inventive functions related to inter-user settlement. These functions can be individually implemented in a predetermined payment service, or can be implemented in an appropriate combination. This payment service can be implemented through a payment service provider's website. (As used herein, the term “Web” generally refers to a navigation interface for a user to navigate between pages or documents that use hyperlinks, and “Web sites” refer to such Generally means a networked server system that supports a navigation interface.)
[0008]
One feature of the present invention is the use of a customizable payee-specific pay page to receive payment. In one embodiment, each user of the service can set up one or more pay pages for receiving payments from other users through a set of pay page configuration pages at the service provider site. The pay page can be customized by the payee with textual and graphical content describing the payee and / or the purpose of the pay page. For example, a content creator may create a pay page for collecting self-reported system payments from a user downloading a work, and describe the content creator and / or the work on the pay page. The payee can also specify certain parameters or actions of the pay page, such as a minimum payment amount and a proposed payment amount. Other users may visit the pay page and make a credit card or other payment to the payee. In one embodiment, the user (payer) sets the 1-Click ™ option, activates it, and then activates the pay page to other users with a single operation, such as clicking a mouse. Payment can be made.
[0009]
Another feature of the present invention is to use pay page templates that allow the user to set up customized pay pages for various payment scenarios. Preferably, each template specifies the display elements and actions of the pay page. The service provider provides templates for various payment scenarios, including but not limited to general payments, self-reported system payments, tipping, required payments, charities, auctions, invoice creation, and events. Can be provided by the side.
[0010]
Another feature includes the use of payboxes that allow payers to initiate pay page payments from payee and / or third party websites. Each paybox is used as a link to the corresponding paypage and can be displayed as a banner-type graphic image (or other type of display object) in the host page. Each instance of the paybox may specify one or more paypage parameters that can be preset or passed by Uniform Resource Locator (URL), such as a proposed payment amount, a paypage color, or a text description.
[0011]
In a preferred embodiment, this paybox image is provided at the service provider site and is customized for authorized users of the service (eg, by displaying the user's name). By selecting the paybox, the user's browser may be referred to the corresponding pay page (customized according to the parameters passed) or, in some embodiments, may be settled in a single operation. Run as By using this function, the website operator can request payment on his own website while collecting payment for payment using a service provider. In addition, the website operator can customize the message functions displayed to the payer during and after the payment process.
[0012]
As another function, there is a function of providing an individual display object such as a paybox image personalized in a page of an external Web site (separated from a service provider site and a different Web site). In one embodiment, the reference to the display object is incorporated into the coding of the external web page so that the visitor's browser requests the display object from the service provider site. After receiving such a request from an authorized user / browser, the service provider site personalizes the content of the display object for a particular user and returns the personalized object for display back to the web page. For example, the display object may be (a) the name of the user, (b) a portion of the user's credit card number, (c) a notification that a particular recipient will be paid a particular amount by selecting the object, Personalization can be achieved by displaying one or more of information such as personal recommendations for products and / or services, (e) links to related content, and (f) payment confirmation messages. An important aspect of this feature is that when displaying personalized content in an external web page, we do not disclose such content or other personal information of the user to external web sites or their operators. There is that.
[0013]
Another feature of the invention is that the user of the service hosts another user's paybox or other payment link, preferably in exchange for a fee, bounty payment, or other compensation for submitting the result. There is an associate program that can do it. In one embodiment, the payee (pay page owner) can associate activate the pay page and set up one or more corresponding pay boxes to allow other users to host. Thereafter, other users can install their payboxes on their websites and earn commissions for referrals that result in payments. For example, using this feature, a user can fund a favorite charity (by hosting a paybox). In addition, the author, musician, or other content creator may allow reprints of the downloadable work by other users, provided that the content creator's paybox is displayed with the work.
[0014]
Another feature is the ability to rate individual users based on a voluntary payment history (eg, the frequency of performing a voluntary payment when an option is displayed). These payer ratings can be used to allow content providers (typically pay page owners) to offer special treatment, such as access to bonus content, to serious payers. In one embodiment, the content provider can design the payment service to redirect the visitor's browser to one of a plurality of redirected URLs depending on the visitor's payment history. For example, a user with a poor payment rating may be redirected to a standard version of an audio work, and a user with a good rating may be redirected to a dedicated version of a work. By using this method, when providing rating-based content to a user, the user's identity or payment rating need not be disclosed to the content provider. Another feature, however, is the ability to redirect the visitor's browser as described above, based on some user attribute other than the settlement history. For example, a service provider site may select a redirect URL based on whether a user has made a particular purchase (eg, a user who has purchased a particular CD may have access to bonus tracks associated with that CD). Other users can only access samples of such bonus tracks).
[0015]
Another feature is that the content at the redirect destination URL specified by the pay page owner can be accessed on a payment basis. In one embodiment, when the visitor completes the payment process, the service provider site formats and encrypts the transaction data stream according to specific terms. For example, the transaction data may include one or more of a payment amount, a date, a time, a user's email address, and an IP address of a requesting computer. At the service provider site, the encrypted string is passed to the destination site, preferably with a redirect URL, via a redirect message. The redirect destination site decrypts the character string, checks the validity, and permits or prohibits access to the related content depending on whether the transaction data is valid. In another embodiment, the URL is provided in clear text to the payer in a subsequent settlement.
[0016]
Another feature is a service in which a user sends a customized payment request to another user. To send the payment request, the payee preferably creates or selects an existing pay page and then specifies how to display that page to the payer. For example, an auction seller can specify the item name, winning bid, tax, and shipping charges to be displayed in the pay page. Next, the service sends an e-mail containing a link to the pay page to the payment request recipient. Preferably, the URL portion of the link includes a parameter that specifies how the page is displayed. For example, this feature can be used to send custom invoices to buyers and collect dues and event-related donations from a small group of users.
[0017]
In another service feature, the payee can display a real-time payment counter on his pay page. For example, the counter may be displayed as a target chart showing the number or amount of payments received since commencement, along with a recipient-specified target. This feature can be used on a charity pay page, for example, to display the total amount of money received during a donation collection event in real time. In addition, the creator of the downloadable work can use this feature to indicate the number of visitors who have made a self-reported system payment for a particular work.
[0018]
As another feature, there is a function that prepares a payment link that can be performed in a single operation in an external Web page, and enables a user to access an item of content and perform the payment. For example, a payment link can be inserted into a content provider site for a user to access a particular item and pay for it. When a recognized 1-Click user selects this link, the SP site charges the visitor's account (typically a small payment in the range of 5 cents to 50 cents) and causes the visitor's browser to render the content. Redirect to the included content provider page. In this content page, one or a plurality of display objects prepared on the service provider site side, such as a bar for displaying a payment confirmation message, can be inserted. If the same user makes multiple payments, these payments are aggregated due to the user's credit card payment. The content page may also include links to other services offered by the service provider site, such as a "cancel payment" button or a button for adding a content item to a personal library.
[0019]
The various features of the present invention can be implemented in conventional websites based on HTML (Hyper Text Markup Language), plus HDML (Portable Device Markup Language), XML (Extended Markup Language), and others It can also be implemented in Web sites that use the coding convention of
[0020]
(Detailed description of preferred embodiments)
Computer-implemented payment services that implement various functions of the present invention will be described with reference to the drawings. The service is hosted at a service provider site (also commonly referred to as a "system"), and in the illustrated embodiment is an HTML-based World Wide Web site. As can be seen, the service and its various functions can also be implemented in other types of website and server systems, such as systems with wireless browsing capabilities. The various service functions described herein are preferably implemented in software executed by one or more general-purpose computers, but may be implemented using other types of computing devices. It is.
[0021]
As will be apparent, the various features of the services of the present invention can be implemented differently than described herein. Further, the services implemented may include only a subset of the disclosed features and / or may include additional features that are not disclosed. The following description is illustrative of the invention and is not limiting. The scope of the present invention is defined by the appended claims.
[0022]
The description of the payment service is divided into the following sections and subsections.
I. the term
II. Overview
A. General process flow
B. System components
C. Pay page transaction processing
III. Page and pageflow example
A. Manage pay pages and pay boxes
B. Paybox Associate Hosting
C. Submit payment request
IV. Pay page templates and parameters
V. Paybox and SP generated display object
VI. Paybox tracking and feedback reports
VII. Control access to content based on payment history or other user attributes
VIII. Payment-based content access
IX. Display of payment counter data in pay page
X. 1-Click payment from external site
XI. Content distribution model
XII. Integration of payment services into external content provider sites
XIII. Select payer for processing at external site
[0023]
I. the term
The following terms are used throughout to describe payment services.
[0024]
Pay Page-a custom page or screen for the associated user ("Payee" or Pay Page "Owner") to receive payments from other users. Usually, the pay page contains information about the owner. The paypage is permanent, ie, it can receive many different payments (from the same or different users) using a given paypage over time. In one embodiment, the payee can use various types of payment scenarios, such as general purpose payments, self-assessment system payments, charitable donations, and invoice payments (using corresponding pay page templates). Pay pages can be created.
[0025]
Service Provider or "SP"-Generally, a business entity (or a combination of related entities) that operates a payment service.
[0026]
Service Provider Site (or SP Site)-a networked computer system such as a web-based server system that implements payment services. The system can be accessed through one or more Internet domain names and can include computers that are geographically separated from one another. In the screen display example, amazon. com web site is included. In one embodiment, the SP site is further hosted or linked to other types of e-commerce services such as retail, song download, and online auction services. A different site or page different from the SP site is referred to as "outside." In the described embodiment, it is assumed that all external sites are hosted by computers outside the control of the SP, and such sites are managed by enterprise entities other than the SP.
[0027]
Paybox-a display object that can be incorporated into a page with the ability for a viewer of the page to initiate a payment to a pre-specified recipient. In a preferred embodiment, each paybox contains a graphic image provided by the SP site and provides a link to the corresponding paypage. In one embodiment, the paybox pointing to a particular paypage is stored on the paypage owner's website ("second party site") and / or a third party website ("third party site" or "third party site"). Associate Site "). In the pay box, pay page parameters such as a proposed settlement amount can be optionally specified.
[0028]
Paybox Graphic (or "Paybox Image")-the graphic image portion of the Paybox (e.g., a GIF or JPEG file). When the user displays the page on which the paybox is installed, the user's browser issues a request for a paypage graphic to a service provider (SP) site. In one embodiment, once the user is recognized by the SP site, the graphic is customized for a particular user (eg, by incorporating the user's name into the graphic). The graphic may be similar in size and appearance to a conventional banner ad graphic, but need not be. Alternatively, text links, buttons, or other types of content (Flash, Shockwave, etc.) may be used.
[0029]
Associate-A website owner or operator that hosts (displays) a paybox or other link to another user's pay page, possibly in return for a commission or other compensation. For example, a music download site could host payboxes for related artists and users could make voluntary or mandatory payments for those artists, and the operator of the music download site (associate) would pay fees for such payments. Can receive. Displaying a paybox by a third party using a website is further referred to as "paybox syndication".
[0030]
Self-assessment system payments-Payments where visitors are required to pay a certain amount in exchange for access to content. For example, the user is required to pay $ 1 for each downloaded MP3 file via a paybox provided on a music download site. The content can also be in the form of a computer implemented service (eg, finding the best price for an item). Voluntary payments to access content are also commonly referred to as “tips”.
[0031]
1-Click-A service that allows a customer to complete a transaction with a single operation, such as a single mouse click, using pre-specified information. One embodiment of such a service is described in US Pat. No. 5,960,411.
[0032]
I. Overview
Preferably, the payment service has a function for a user to receive payment from another user via a pay page customized by the payee. In one embodiment, after a user opens an account with the SP, a default pay page is automatically created for the user. In another embodiment, a pay page exists only for a user who has actively created a pay page. In any case, it is preferable that a plurality of pay pages are prepared for each user. For example, a music group may create a separate pay page for each piece of work posted in digital form (see FIG. 7) and use those pay pages to voluntarily pay (tips) from users who download such works. Or self-report system settlement) can be collected. In addition, an individual can create a pay page for personal use and another for business use.
[0033]
In a preferred embodiment, each pay page is based on a template that specifies the layout and behavior of that pay page. Each template describes a default value that can be overwritten by the pay page owner in the pay page setting process. Each pay page is provided with (1) title, (2) pay page "owner" or "payee" identifier, (3) description, and (4) "mandatory" information fields such as amount, Preferably, it can be modified by the payer. Additional fields and options can be defined by specific templates. Different templates can be provided for different types of organizations, such as charities, authors, musicians, other content providers, and individuals. In addition, templates can be prepared for specific types of pay page applications, such as tip payments, self-assessment system settlement, invoice creation, auctions, dues, rebate requests, and settlement required for content access. The types of elements that can be described in a template in one embodiment are described in Section IV ("Pay Page Templates and Parameters") below.
[0034]
It is preferable to set a unique URL (Uniform Resource Locator) for each pay page. The URL of the default page (if used) is preferably based on a naming convention where the user's email address is the only variable (eg, www.paypages.com/<email address> .htm). This allows the user to easily find another user's default pay page. A nickname assigned by the SP or selected by the user may be used in place of the email address. Other types of pay pages may be assigned encoded URLs that are relatively difficult to identify by trial and error. As described below, the service can support various methods for finding and accessing pay pages, such as pay boxes and search engines.
[0035]
In addition to the payee-specified pay page, the service can include a general "remittance" page for remittance to payer-specified payees.
[0036]
Although the websites and pages of the described embodiment use HTML (Hyper Text Markup Language) coding, those skilled in the art will also appreciate that other markup languages can be used. There will be. For example, the functionality of the present invention can be implemented using websites and web pages that use HDML (Portable Device Markup Language), XML (Extensible Markup Language), or other suitable markup languages. . Further, it will be appreciated that the use of a personal pay page provides significant benefits, but allows the recipient to implement many of the features of the present invention without having a pay page.
[0037]
A. General process flow (Figure 1)
FIG. 1 is a diagram showing a basic process flow for registering a user in a service, managing a pay page, and executing various related operations. Each state in FIG. 1 generally corresponds to one or more pages on the SP Web site. As can be seen from the figure numbers shown in FIG. 1, some examples of these Web pages are included in later figures. The process by which a user makes a payment via a pay page is shown in another drawing (FIG. 3).
[0038]
As indicated by the "login" state 30, the user first enters the payment service by logging in using a preselected username and password (or other authentication information). The new user may first register for the service (state 32) and then make or receive payment via the pay page. In the registration process, the user enters various account information such as name, credit card number, password, and email address. Preferably, during or after the registration process, the user can further perform the task of entering and enabling the system's 1-Click ™ service. As will be described later, when the 1-Click service is activated, the user can make a paypage settlement by clicking the mouse once or performing another selection operation once. In one embodiment, the user may also perform a 1-Click payment directly from a paybox provided on an external website. During or after the registration process, the SP site stores a cookie on the user's computer to allow further identification of the user.
[0039]
As shown in state 34, the user may optionally further link the account at the SP to an existing checking account. The bank route number associated with the checking account is based on the information entered by the user from the face value of the check using the process described in U.S. patent application Ser. No. 09 / 517,563, filed Mar. 2, 2000. Can be determined automatically. Once the paypage account is linked to the checking account, the user can initiate a transfer between the two accounts (state 60).
[0040]
As shown in state 36, the service can include a main page (see FIG. 5) or other areas where a user can initiate various operations. Preferably, the main page displays a list of the user's pay pages (if any) so that the user can select a particular pay page on which to perform the operation. As shown in state 40, the user can create a new paypage and edit, display, or delete an existing paypage (as described in Section III-A below, (See examples of page flows shown in FIGS. 5-7).
[0041]
As shown in state 42, the user may further create, edit, or delete payboxes for a particular paypage (see FIGS. 8 to 8 described below in Section III-A). 11 (see page flow example). After the paybox is created, the paypage owner (and in some embodiments, other users) "installs" the paybox in one or more external Web pages and responds to the corresponding paybox. You can set a link to the page. To facilitate this process, the service automatically generates HTML (Hyper Text Markup Language) coding to add to the host Web page (see FIGS. 10 and 16 below). The HTML coding includes a reference to a paybox image (provided on the SP site), and when the page is displayed by the browser, an image request is automatically issued to the SP site. Alternatively, the coding can be generated according to other markup languages or link coding rules. For example, in a wireless environment, appropriate HDML (Portable Device Markup Language) coding can be generated. In addition, the payment service can generate coding that sets other types of links (eg, text links) on the pay page.
[0042]
One particular application of the paybox feature provides a mechanism for compensating digital content creators. For example, a content creator, such as a music group, author, or website operator, may install a paybox on his (second) website to prompt the user for voluntary or mandatory payment. You can also. A user accessing the content can click through the paybox and make a voluntary or mandatory payment to the content creator. The amount of this payment (e.g., $ 1 per download) is offered by the paybox, in which case the amount is displayed in the pay page when the user clicks on it (as described below). Is preferred. If payment is "required", an appropriate mechanism can be used to prohibit access to the content until the user pays for it (see, for example, section VIII entitled "Payment Based Content Access"). .
[0043]
A variation on this model is that the SP itself provides a forum for content creators to post their work in a downloadable format. In this way, the posted work will be displayed with the paybox (eg, on the product detail page) and may seek voluntary (or required) payment. Using this model, a user can post a work to an SP site (whether or not they operate a Web site) and collect money from the user using a payment service. For example, a relatively unknown music group may post songs or albums in MP3 format along with a paybox and request voluntary payment of $ 1 for each download.
[0044]
In one embodiment of the payment service, during the paypage creation or editing process (state 40), the user may "associate activate" a particular paypage. When a pay page is associated and activated, other users may use one or more of their pay boxes on their web page, optionally in exchange for a resulting referral fee or other compensation. Can be installed within. For example, a charity, such as the Red Cross, can associate enable a pay page and create one or more pay boxes for that page. Thereafter, other users (associates) can install these payboxes on their websites and provide a mechanism for other users to find the Red Cross pay page. When the user (a) follows (clicks on) such a pay box and makes a payment on the corresponding pay page, or (b) makes a 1-Click payment in the pay box, if applicable, The associate who created the referral is given a portion of the settlement.
[0045]
To become a paypage associate, the user first retrieves or navigates to the desired associate-enabled paypage (state 46). A search engine can be provided for this purpose. Next, the user selects the corresponding paybox (or, optionally, some other type of link to the paypage) and installs the paybox on one or more third-party sites (state 48). This process is illustrated by the example page flow of FIGS. 13-16 described in Sections III-B below.
[0046]
One particular application of the associate function provides a mechanism to compensate digital content distributors. Third party (associate) distributors of digital content (e.g., music or ebook download sites) can display the paybox of the artist, author, or other content creator along with the associated content. When the user clicks on such a box and makes a voluntary payment to the content creator, a part of the content can be given for each payment as a price for distributing the content to a third party associate. In another particular application, a web site operator may raise funds for a favorite charity while receiving a fee.
[0047]
As shown in state 52, the system further allows a user to generate and send a settlement request to another user. To initiate a payment request, the recipient user specifies one or more recipient email addresses and specifies how to display the recipient's pay page to such recipients. Enter pay page customization data. This customization data can include, for example, the requested payment amount and an associated text description. The system responds by initiating a payment request by sending an email to each recipient with a URL-encoded link to the pay page. The URL portion of this link contains parameters used by the SP website to determine how to display the page. This feature of the system can be used, for example, when sending customized invoices to other users. Other applications for this feature are described in Section III-C ("Sending a Payment Request").
[0048]
As indicated by state 54, the service may further provide an option to set up an automated or periodic payment request. For example, an automatic payment request can be used by an online auction seller to automatically send an invoice (a link to a customized pay page) to the winning bidder. For such a pay page, the image and description of the auction item (displayed in the corresponding auction page) and the winning bid can be automatically input as initial values. A recurring payment request can be used to collect any type of recurring payments, such as subscription fees and group dues.
[0049]
Finally, the service may include various account management pages, as generally indicated by states 56-60. From these pages, the user can perform operations such as viewing pay page transactions (both payee and payer), transferring money between accounts, and updating the user profile. The service can also generate, send, and retain transaction receipts and generate taxable reports (eg, paying charities).
[0050]
B. System components (Figure 2)
FIG. 2 shows a set of components that can be used to implement a payment service at the SP site 66. This system includes a Web server 68 that accesses a content database 70 and a user account database 72. The system may further include a database for storing other types of information, such as a product database and an auction database (not shown).
[0051]
The web server 68 includes a pay page application 76 that implements various pay page related functions described in this specification. The pay page application is passed along with (a) identifying visitors returning to the SP site using cookies, (b) customizing pay pages and pay boxes according to settings specified by the recipient, and (C) page requests. A pay page customized to the parameters and displayed with the visitor name / 1-Click setting displayed on the visitor, (d) tracking and crediting the associate for the referral, and sending a "Thank you" email to the payer Processing of payment transactions, such as (e) generating HTML or other coding to install a paybox or other link to the paypage in an external page, (f) associate-enabled paypage and its associated Paybox user reference, (g) Payment request Generation, and (h) Pay page such users to view and update account information or comprises a module to perform some or all of the tasks or services, or use. Each module preferably contains executable code and, if possible, comprises a web page for interacting with the user. Other functions and services that can be implemented by the paypage application are described in the following paragraphs.
[0052]
As shown, a web server 68 communicates with an image server 77 that dynamically generates and provides paybox graphics (and possibly other types of images) for display within an external web page. . Alternatively, other types of object servers may be used, such as a server for animated objects or other executable display objects. In one embodiment, the paypage application 76 and the image server 77 recognize different browser capabilities (HDML, wireless, WAP, etc.) and device type and select the paypage and paybox to display accordingly.
[0053]
The web server may further include an application 78 that implements other types of services, such as retail services and one or more personal-to-person sales services. The various applications 76, 78 can share code modules that implement common tasks such as registration, user authentication, and credit card processing.
[0054]
The web server also preferably communicates with a search engine 80 that searches various areas of the site. Using this search engine, a user can search for another user's pay page based on the username and other criteria. As described above and shown in FIG. 12, the user may specifically perform a search for an associate-enabled pay page.
[0055]
As shown in FIG. 2, the content database 70 includes pay pages created by the user and further includes pay page templates that can be used to generate pay pages. As described above, different templates can be prepared for different payment related scenarios. Although the template is preferably created at the service provider, the service can provide the ability for the recipient to create his own template. The content database further includes web pages and templates for various other areas of the site.
[0056]
The content database 70 can further store a description of the paybox style prepared by the SP and a paybox designation defined by the paypage owner. The paybox designation may, for example, define the paybox style, color, proposed settlement amount, text message, and greeting format (see FIGS. 8 and 9). Alternatively, some or all of these paybox parameters can be encoded in the paybox identifier passed by the URL. As described below, the image server 77 uses the paybox designation to dynamically generate paybox graphics (eg, GIF images) and provide it to the user computer 84. Paybox graphics are also customized to include information about the name and visitor, if known.
[0057]
In embodiments where the SP site allows users to post and receive voluntary payments for digital works (as described above), the content database may further include a copy of such works ( Not shown). These works can be found using the site's search engine or other suitable navigation interface.
[0058]
As further shown in FIG. 2, the user account database 72 stores account-specific information about site users. For each user, this information includes the user profile (name, credit card number, 1-Click settings, etc.), account balance, transaction history (including incoming and outgoing paypage payments), and It is preferable to include information regarding the pay page association relationship created by the user.
[0059]
C. Pay Page Transaction Processing (FIGS. 3 and 4)
FIG. 3 is a diagram showing a basic process used to display a pay page on the SP website 66 side and process a pay page transaction via the pay page application 76. As indicated by block 90, the website first receives a URL request from user / computer 84 for a particular pay page. When a URL request is generated by the user selecting a pay box, the URL may include one or more parameters for rewriting pay page default values. For example, when a proposed payment amount is specified in a pay box, this amount is passed via a URL and the default amount displayed in the pay page is rewritten. Details on how to use the parameters are described in Section IV ("Pay Page Templates and Parameters") below. If a URL request arises by selecting a paybox hosted by the associate, the URL preferably further includes the unique identifier of the associate.
[0060]
If the URL request is from an existing user of the service, the request typically includes a cookie that the system uses to identify the user. The use of cookies for this purpose is well known in the art.
[0061]
As indicated by block 92 in FIG. 3, the web site responds to the URL request by generating and returning (displaying) a pay page. FIG. 4 shows an example of a pay page displayed to the user. As shown, the pay page includes a default or owner assigned title 92A, a graphic image (logo or photo) 92B uploaded by the pay page owner, and a note or description 92C entered by the pay page owner. It is preferred to include In addition, the pay page includes a greeting message 92D (if known) that identifies the visitor by name. If you do not know the identity of the visitor, you can use a default message such as "Please sign in".
[0062]
As further shown in FIG. 4, the pay page also includes an "Amount" field 92E where the visitor can enter a settlement amount and a settlement button 92F or other link for the visitor to initiate the settlement process. In the illustrated example, $ 2 is displayed in the amount field 92E as the proposed settlement amount. If the visitor is known and the 1-Click service is enabled (as in the example of FIG. 4), set the payment button 92F as a 1-Click button that can be selected to perform a payment transaction; Preferably, it is labeled. On the other hand, if the visitor is not identified (a) or (b) is identified, but the 1-Click service is not activated, the settlement button 92F indicates “pay now! Please select ")."
[0063]
If the visitor selects the 1-Click version of the payment link 92C, as shown in the "1-Click" path of FIG. 3, the system 66 does not require any further action by the user (preferably in advance). Execute the transaction (within a specified period). In addition, the system displays a "Thank You" page (block 98) or redirects the user to a page specified by the owner (typically, a "Thank You" page on the owner's external website). . At this point, the user does not need to perform any other operations to complete the payment transaction. On the other hand, if the visitor initiates a payment via a non-1-Click link, the visitor must log in or register, select a credit card, and then execute the transaction (blocks 94 and 96).
[0064]
Although a credit card is used in the illustrated embodiment, any suitable method for transferring money between users can be used. Further, it will be appreciated that throughout the various embodiments described herein, the payer's credit card need not actually be charged at the time of the transaction. For example, in embodiments where the user typically makes frequent small payments (less than $ 1) to access articles or other content, the SP site aggregates multiple payments to charge the user's credit card. be able to.
[0065]
As shown in block 100, when a visitor is redirected from a paybox displayed on the associate website to a pay page, the system credits the associate user's account with a commission. The system may additionally or alternatively be configured to credit the associate's account with a bounty settlement (eg, for each referenced user who has set up an account with the SP). An example of a method that can be used to track referrals from associate web sites and determine associate fees is described in US Pat. No. 6,029,141. As indicated at block 102, the SP may deduct the transaction fee before crediting the payee's account with the remainder of the settlement amount.
[0066]
As described in section X below (“1-Click Payment from External Site”), the above process is modified so that a 1-Click visitor simply clicks on a paybox to access an external host. You can execute transactions directly from the paybox. At that moment, the SP site responds to the paybox selection by immediately redirecting the visitor's browser to an external URL specified by the paypage owner (or, in some embodiments, the associate). Therefore, the transaction is completed without the visitor requesting the display of the pay page.
[0067]
The process shown in FIG. 3 further includes an appropriate error handling task (eg, an invalid pay page parameter, an invalid pay page entry (eg, a payment amount less than the minimum payment amount), and other error conditions for handling error conditions. (Not shown).
[0068]
III. Page and pageflow example
FIG. 5 shows an example of the “main page” of the payment service. On this page, the account balance of the user's pay page is displayed, and a list of pay pages currently active in the account is displayed. The page further provides links for the user to perform operations on the selected pay page, such as editing the page, deleting the page, displaying the page, managing the page's paybox, and sending a payment request. The option to send a payment request may be omitted, but may also be used only for certain types of pay pages (eg, a user's default pay page). The main page also provides links for the user to create a new pay page, become a pay page associate, and access other areas of the site.
[0069]
A. Management of pay pages and pay boxes (FIGS. 6 to 12)
The basic process of creating and managing pay pages and associated pay boxes will be described with reference to FIGS. In this example flow, assume that all pay pages are created using the same template. If different templates exist for different types of pay pages, the user attempting to create a new pay page may be required to first select a pay page type.
[0070]
FIG. 6 shows the “Step 1” page of the pay page management process. This page can be accessed by selecting one of the "Create New Pay Page" or "Edit" button on the main page (FIG. 5). The “Step 1” page displays a group of six categories of pay page settings that can be customized, and has “Edit” buttons for allowing the user to change the default settings.
[0071]
The first setting category is message transmission related to pay pages. The message transmission includes a description of the pay page displayed on the pay page, a “thank you” message displayed to the payer after settlement, and a “thank you” message sent to the payer by e-mail. Also, the pay page owner may be provided with an option to upload an audio or video clip that can be played within the pay page.
[0072]
The second category is the title and color scheme of the pay page. For example, the color scheme may be selected to be similar to the owner's reference site.
[0073]
The third category is optional images to be displayed in the pay page. This can be used, for example, to display a picture of the pay page owner or to display an image associated with the downloadable content to which the pay page corresponds.
[0074]
The fourth category is a payment setting of a pay page. The settings include the default settlement amount (the amount that will be remitted if the payer does not modify the amount field) and the minimum settlement amount.
[0075]
The fifth category is a detailed setting of the pay page. By editing the detailed settings, the user can specify whether to associate-enable the page and, if so, the commission rate to be paid to the referral. In addition, the user can specify the location and email address to be displayed in the pay page, and specify the URL of the "Thank You" page to be displayed after the payment process is completed.
[0076]
The sixth category uses an optional payment counter. Use this function to display optional charts on the pay page. When this feature is enabled, a counter is set on the pay page that indicates in real time the amount of money received and / or the number of payments received, via the pay page or a collection of co-owned pay pages specified by the owner. This counter may optionally be displayed as a goal chart showing the total settlement amount for the owner specified goal. For example, the payment counter feature can be used to display real-time donation collection data for a charity. An example implementation of this feature is described in section IX below, entitled "Displaying Payment Counter Data in Pay Pages".
[0077]
After finishing customizing the pay page settings, the user can select the “Continue” button to access the “Step 2” page (FIG. 7). At step 2, the user can preview the pay page and choose to go back and make further changes or go to step 3.
[0078]
In step 3 (FIG. 8), the user can select a paybox style to use on the paypage. Alternatively, the user can select the "pay page management" link to return to the main page (FIG. 5). In the example shown, each style corresponds to a particular paybox size. Although a rectangular paybox is used in this example, other shapes of paybox may be used.
[0079]
In step 4 (FIG. 9), the user can create a paybox with a style already selected. In particular, the user can specify a greeting and a message to be displayed in the paybox, and select a frame color for the paybox. Further, the user can specify a proposed settlement amount (for example, $ 1) to be used in the pay box.
[0080]
When the proposed amount is specified, it is preferable that the amount is passed by URL as a parameter and displayed on the pay page when the user accesses the pay page through the pay box. If the same pay page has a different pay box, the proposed payment amount (or other pay page parameters) may be different. Although only one type of pay page parameter (payment amount) is shown in FIG. 9, the creator of the pay box is requested to specify other types of parameters such as the display color of the pay page and other text fields. You can also. In this way, pay pages can be customized (displayed) differently for different pay boxes. The use of parameters to specify pay page display attributes is described in Section IV ("Pay Page Templates and Parameters"). If the user selects the "Continue" button and proceeds to step 5, the paybox settings are stored in the content database 70 for later use.
[0081]
In step 5 (FIG. 10), when the paybox is displayed to the user, the HTML code for installing the paybox on the Web site is also displayed. The paypage owner can install a paybox in any number of webpages by copying blocks of HTML code into the HTML coding of such webpages. Advanced users can also manually add additional parameters to the pay page URL to control other display attributes of the pay page.
[0082]
As shown in FIG. 10, the HTML code includes a reference to a paybox graphic provided by the SP site. Thus, when the user / browser retrieves the HTML document with the paybox installed, the browser automatically requests the paybox graphics from the SP site. If the request includes a cookie for the SP site to identify the user, the SP site preferably incorporates the identified user's name into the paybox graphic, as shown. Upon selecting the “Continue” button on the “Step 5” page, the user returns to the main page (FIG. 5).
[0083]
As shown in FIG. 5, the user displays a paybox associated with a particular paypage by selecting a corresponding link titled "Manage payboxes for this paypage." And manage it. FIG. 11 shows an example of a “manage paybox” page displayed when this link is selected.
[0084]
The payboxes shown in FIGS. 8-11 differ in size and include text content, but alternatively, a "standard" paybox that does not include text content may be used. For example, as described below, standard buttons or icons may be used where the payment amount is represented in a particular color (e.g., green, blue, representing 5 cents, 10 cents, and 25 cents of payment, respectively). And red payment button). This is useful, for example, when making small, frequent, 1-Click or other payments from external content provider sites using payboxes (see Section X “1-Click Payment from External Sites”). reference).
[0085]
FIG. 12 shows a simplified web form that can be used to create a pay page. In this example, the pay page creator can specify a commission (rate) for the pay associate.
[0086]
B. Paybox Associate Hosting (Figures 13-16)
The process of registering as a paypage associate involves finding an associate-enabled paypage, selecting a paybox associated with the paypage, and installing the paybox in one or more Web pages. Thereafter, when a visitor to such a Web page clicks a pay box and makes a payment, the associate usually receives a commission. There is no limit on the number of associates that can be set for a given pay page. Further, a given user may be associated with different pay pages and pay page owners.
[0087]
FIG. 13 shows a page that can be used to search for an associate-enabled pay page. As shown, a user can search for pay pages based on one or more of name / description, city, and state. Various other navigation tools for finding associated enabled pay pages may be provided, such as a reference tree in which the pay pages are arranged by category.
[0088]
FIG. 14 shows an example of a page of the search result for the search “Name or description = Animal Society”. On this page, a list of matching pay pages is displayed, and a link displaying the pay page and its associated pay box is displayed. If multiple commission rates are supported, this page can indicate the commission rates offered by the owner.
[0089]
FIG. 15 is an example of a page that displays a list of payboxes defined for a paypage titled “The Animal Society in Seattle WA” (Sea Animal in Seattle, WA). From this page, the user can select the style of the provided paybox. When the "Continue" button is selected, the SP site returns a page in which the style of the selected pay box is set and an HTML sequence for installing the pay box (FIG. 16). This HTML sequence is similar in format to the sequence of FIG. 10, but includes the unique identifier of the associate (assigned by the pay page application 76 and stored in the account database 72) in the URL of the paybox graphic. . As described above with reference to FIG. 3, the pay page application uses this identifier to look up the identity of the reference associate and track the referral event.
[0090]
In some embodiments, the associate is provided with an option (not shown) that defines pay page parameters for use with the paybox's associate host instance. For example, the associate may be allowed to enter a proposed payment amount, an associate name or logo associated with the pay page, and / or a post-payment redirect URL. Some or all of these parameters automatically rewrite the owner-specified parameters associated with the paybox.
[0091]
C. Transmission of settlement request (Figs. 17-19)
As described above, the payment service may provide a service in which a user transmits a payment request to another user via a customized pay page. Preferably, the user initiates the payment request by selecting a pay page to use for the request (eg, selecting a “send payment request” link as shown in FIG. 5). Alternatively, the user can be requested to select from a list of predefined payment request templates, in which case a new pay page is created to process the payment request.
[0092]
FIG. 17 shows an example of a page that can be used to send a payment request using the selected pay page. From this page, the payer (payment request recipient) user can enter a name and email address (or select from a personal address book). In one embodiment, the new payer is automatically added to the user's personal address book.
[0093]
As further shown in FIG. 17, the user may also enter an optional description and an optional payment amount, both of which may be associated with the description and payment amount (if any) defined within the pay page. rewrite. Depending on the type of pay page used (template), the user may be required to specify other pay page fields and options (not shown). For example, if the payment request corresponds to the pay page of the auction invoice, the user (recipient) is further required to input the name of the successful bidder and details of the transaction (item number, successful bid amount, shipping cost, etc.). You can also request.
[0094]
In the illustrated embodiment, the “send payment request” page also includes a link 108 to a page (not shown) that automates or periodically cycles the payment request. For example, the user can specify whether to resend the settlement request monthly or automatically send to the winning bidder after the auction is completed.
[0095]
When the user selects the "Send Payment Request" link, system 66 stores the submitted form data and sends an e-mail message to each of the listed payers. As shown in FIG. 18, the email message includes a hyperlink 110 to a customized version of the selected pay page. The URL portion (not shown) of the hyperlink points to the pay page and includes one or more parameters that customize the pay page. These parameters may include a value entered by the pay page owner (eg, a payment amount) and / or may include an identifier for retrieving such a value from a table in the pay page application 76. The use of URLs to pass pay page parameters is described below in Section IV ("Pay Page Templates and Parameters"). When the payment request recipient selects the hyperlink, system 66 returns a customized pay page as described above with reference to FIG.
[0096]
FIG. 19 shows an example of a pay page used to request a donation associated with an event. In this embodiment, the payer is recognized by the system and the 1-Click service has been disabled. As described above, pay pages used for other types of payment request scenarios can include other types of fields. For example, a pay page used to request settlement from an auction winner will include fields for item number, winning bid, shipping fee, tax, and shipping address, which will indicate that the auction completed successfully. Initial values may be automatically entered by the pay page application 76 in response to the request, or may be entered by the seller.
[0097]
IV. Pay page templates and parameters
The pay page template specifies both the "look and feel" and the behavior of the pay page. In the preferred embodiment, all pay pages are based on templates. As described above, templates may be provided by the SP for various payment scenarios, such as donations for charity, events, invoices, auctions, rebate requests, and downloading digital content.
[0098]
Preferably, each template specifies an element to be displayed on the pay page. Table 1 below lists and describes the elements that can be included in the template in one embodiment of the present invention. The column labeled "Type or Size" in Table 1 indicates the type or size of the element. The "display on template" column indicates whether the owner displays the element in the pay page creation / editing process (if "NO", the element takes the default value specified by the SP). The "edit by creator" column specifies whether the owner / creator can modify the value associated with the element when creating the pay page. The "edit by payer" column indicates whether the payer (pay page visitor) can modify the value. The “pass by URL” column specifies whether the value of the element can be passed as a parameter with the pay page URL.
[0099]
[Table 1]

[0100]
Preferably, some elements such as page title, amount, description field, etc. are required for all templates. Other elements can be freely selected by the template designer.
[0101]
Templates can also reference page handlers to perform specific operations. For example, the rebate template handler can extract the serial number of the purchased item and check if the number is on the list of valid serial numbers. This handler can also update the database to mark this serial number as "used". In addition, the template can include Javascript or other code that performs field validation, calculations, or other functions.
[0102]
For elements that can be passed in a URL, the value of the pay page can be overridden by the parameter values contained in the URL (see block 92 in FIG. 3). These modified values may be specified by a paybox or other link on a paypage (eg, a suggested settlement amount to override) or by an advanced user. In the preferred embodiment, these parameters are passed as name-value pairs, in any order. For example, a URL specifying a quantity (amount), an SKU, a sale price, a tax (tax), and an item shipping (shipping) can take the following form:
http: // WWW. server. com / bob @ antiques. com /? Amount = 20.00, sku = 1234, tax = 4.50, shipping = 3.50, item = 12.00
[0103]
V. Paybox and SP generated display object
Each paybox preferably has a unique identifier assigned after creation by the paypage owner. The identity of the corresponding pay page is encoded in this identifier and can be determined from this identifier. This identifier is preferably used by the image server 77 (FIG. 2) to retrieve the relevant paybox designation from the content database. Alternatively, some or all of the paybox designations, such as style, color, paypage identifier, etc., may be encoded within the paybox identifier.
[0104]
Preferably, two URLs are associated with each paybox. The first URL is used to provide paybox graphics and can take the following form, for example:
http: // www. server. com / payboxes / {pay box ID}. gif
The second URL points to the corresponding pay page and is used to get the pay page when the user clicks on the pay box graphic. This URL can take, for example, the following format:
http: // www. server. com / {pay box ID}
As described above, one or more parameters (such as the proposed settlement amount) can be passed along with this second URL. Preferably, the paybox ID is included in the second URL so that the application 76 tracks click-through events on a per paybox basis. Paybox graphic requests can also be used to track the ratio of clickthrough events to paybox impressions. As described below, historical data regarding impressions (ie, display events), click-through rates, and success (payment) rates can be provided to pay page owners.
[0105]
For the Associate Host Paybox, the URL format is the same, except that it contains the identifier of the hosting associate. For example, a URL can take the following form:
http: // www. server. com / payboxes / {associate ID} / {pay box ID}. gif
http: // www. server. com / {associate ID} / {pay box ID}
Preferably, an Associate ID is recorded each time an Associate Host paybox is requested and each time a pay page is requested for that paybox. As described above, when the associate reference visitor makes a payment, the paypage application 76 further fills out the reference associate's account using the associate ID.
[0106]
As mentioned above, the paybox URL and the associated HTML coding are automatically generated by the application 76 when a second party (owner) or third party (associate) selects a paybox to host ( 10 and 16). Alternatively, the website developer may manually install the paybox by generating HTML or other coding.
[0107]
FIG. 20 shows a general sequence of events that occur when a user (visitor) requests and displays an external (second or third party) Web page that includes a paybox in one embodiment. FIG. This figure also shows a method used when the SP site provides a customized display object other than the paybox image. First, the visitor's browser 84 sends a request for a page to a second or third party site 120 (Event 1). Site 120 responds by returning the requested HTML document with reference to (the URL of) the paybox graphic (event 2). After parsing the HTML document and detecting this reference, the browser requests a paybox graphic from the SP site 66 (event 3). If the visitor is an existing user of the payment service, the request may include a cookie used by the SP site to retrieve the visitor's name and 1-Click settings.
[0108]
The SP site 66 responds to this request by generating a paybox graphic as described with reference to FIG. 3 (Event 4). As part of this process, the image server 77 retrieves and / or decodes the paybox designation from the paybox ID. For example, these specifications may include the size, color, message, and proposed settlement amount of the paybox specified by the paypage owner. In addition, if the request contained a valid cookie, the image server 77 retrieves the visitor's name and 1-Click settings. The image server 77 uses the paybox designation and visitor-specific information (if available) to generate paybox graphics. As described above, the graphic can include the visitor's name and, if the 1-Click service is enabled, a 1-Click payment button 92F (FIG. 4). In one embodiment, the payer can pre-specify the type or level of customization provided in the paybox graphics (see Section XIII, "Selection of Payer for Processing at External Site").
[0109]
The image server 77 may also include other types of personalization information in graphics or other display objects. For example, the graphic or another dynamically generated graphic may be customized to include a selected number of the visitor's default credit card. In one embodiment, for example, the image server generates and provides a separate bar displayed at the top of the same external Web page. This bar preferably displays the visitor's name (if recognized at the SP site) and information about the payment made in the current reference session. The bar may have buttons that perform some functions, such as canceling the last payment or adding the displayed article to the personal library maintained by the SP.
[0110]
In addition, paybox graphics or other display objects may include personal recommendations for products or services available for purchase from the SP. Personal recommendations can be generated based on the user's purchase history, reference history, and / or explicitly specified interests, using methods well known in the art. These personal recommendations and / or other display attributes of the graphic may also be selected based on the identity of the hosting site 120. For example, if the hosting site 120 is an online sports shop and the visitor's profile indicates that he or she is interested in surfing, the graphic will display a list of surfing related products sold by the SP. In addition, rather than providing a customized graphic, the SP site may provide another type of object selected or customized based on the user's identification, such as a text link or a streaming audio or video clip. In addition, personalized graphic images or other display objects can be pre-generated (generated before the request) and / or cached after dynamic generation and generated on-the-fly on a per-request basis It will be appreciated that this need not be the case.
[0111]
As further described in FIG. 20, the image server returns the dynamically generated paybox graphic to the browser (event 5), and the graphic 122 in the web page 124 is displayed on the browser. In the SP site, the graphic is sent directly to the visitor's browser, so the personal information included in the graphic is not disclosed to an external Web site or its operator. If the visitor subsequently selects a paybox (eg, clicks on a graphic), the browser sends a request for the corresponding paypage to SP site 66 (event 6). As mentioned above, the request may include one or more pay page parameters.
[0112]
As can be seen from the above, the method of displaying personalized graphics on external sites on the SP site has been changed for various non-payment related applications (eg providing personal recommendations or links to related content). Can be used. In addition, the method can be used to provide personalized objects other than images.
[0113]
VI. Paybox tracking and feedback reports
The paypage application 76 can send periodic feedback reports to the paypage owner and / or its associates. For the owner, the feedback report shows separately for each of the owner's payboxes: (a) the number of paybox impressions (display events); (b) the number of paybox click-through events; One or more criteria may be included such as c) the number of payments resulting from such a click-through event, and (d) the resulting commission. For pay page associates, the same metrics (a)-(d) can be included in the periodic feedback report, but the data is provided separately for each pay box that the associate hosts.
[0114]
To generate a feedback report, the application 76 on the pay page, whenever a paybox is requested by the visitor's browser, (a) paybox ID, (b) associate ID, if any, (c) visitor ID Then clicked (selected) the paybox, (d) whether the payment was made to the paypage owner as a result of the click-through event, (e) the amount of the payment, if any, ( f) It is preferable to record information such as the amount of the associate commission fee, if any, (g) the identity of the visitor, if known, and (h) the date and time of viewing. These and other types of information can be extracted from the server access log by well-known methods.
[0115]
In addition to the above information, the owner can be provided with data on the number of associates hosting each paybox by signing up.
[0116]
VII. Control access to content based on payment history or other user attributes (Figure 21)
Application 76 may further include the ability to rate payers according to a voluntary settlement history for some or all payees. Using this information, the paypage owner or other content provider can provide additional content (or take other action) to "good" payers. For example, a musician can provide bonus tracks and high-quality MP3 files to people whose payment history is appropriate.
[0117]
To generate a rating, application 76 provides, for each payer, (1) the number of pay pages being displayed, (2) the number of payments made, and (3) the payment amount compared to the proposed amount (settlement). And (4) information on the data, such as the type of pay page (charity, self-report system, tip payment, etc.). By using such data, the application can (1) pay page display / settlement%, (2) total paid / suggested (for pages on which payment was made), and (3) total paid amount The payer rating can be calculated based on one or more of the criteria, such as / total offer amount (for all displayed pages) (and possibly further criteria). Applications can also track the number of times payers view payboxes and incorporate them into their ratings. Further, the application can generate separate payer ratings for some types of pay pages.
[0118]
Using various methods, a content provider can provide rating-based content to visitors. One such method is to use the SP site 66 to redirect the visitor to a rating-based destination site. When using this method, the content provider first sets separate goals (eg, respective URLs) for each of a plurality of payer rating categories, such as “bad”, “average”, “good”, etc. . For example, a content provider posts a sample version of a downloadable music title to a "bad" URL, a standard version title to an "average" URL, and a high-grade version title (e.g., a bonus track) to a "good" URL. With or with high quality audio). URLs that are otherwise inaccessible from the content provider site (eg, no links to enter or other links are set) can be used for this purpose.
[0119]
Thereafter, the content provider accesses the "Rating-based content settings" area of the SP site 66 and specifies (1) the target URL and (2) the message to be displayed in the corresponding graphics provided by the image server 77. I do. Continuing the example above, the message is as follows:
Bad: "Click here to download a sample of Moby's latest single."
Average: "Click here to download Moby's latest single"
Good: "Click here to download the latest Moby CD"
Each such message is displayed on various versions of graphics provided by SP site 66. Paybox graphics can have dual roles (e.g., via a configurable thank you page URL) with a payment function and a content access function, but these graphics are , Preferably separate from paybox graphics. Next, the SP site can generate HTML or other code that installs the graphic in the web page (as in FIGS. 10 and 16). As with payboxes, other types of display objects (such as animations) can be used instead of graphics.
[0120]
FIG. 21 is a diagram showing a sequence of events that occur when a visitor accesses a page on which a graphic is installed. Initially, the visitor's browser 84 requests the requested HTML document and the content provider site 140 returns it (events 1 and 2). Next, the browser 84 transmits a request for a graphic referred to in the HTML document to the SP site 66 (event 3). If the visitor is a user of the payment service, the request may include the visitor's cookie. In response to the graphic request, the SP site 66 (image server 77) retrieves the visitor's rating and selects the corresponding version of the graphic (event 4). If the visitor is unknown, or if no rating exists for that visitor, a default version of the graphic is selected. The selected graphic 142, either pre-generated or dynamically generated, is returned to the browser (event 5) and displayed within the web page. Subsequently, when the visitor clicks the graphic 142, the browser sends a request for the content to the SP site 66 together with the visitor cookie (event 6). The SP site responds to this request by retrieving the user's rating and the corresponding target URL (Event 7) and redirecting the browser to this URL (Events 8 and 9). One important aspect of this method is that the SP does not disclose the identity or rating of the visitor to the content provider site.
[0121]
By changing the method shown in FIG. 21, the SP site can select the target URL based on some user attribute other than the voluntary settlement history. For example, at the SP site, it is also possible to select a target URL based on whether the user has purchased a particular item (eg, a user who has purchased a particular CD will have access to bonus tracks associated with that CD). Yes, but other users can only access samples of such bonus tracks). As another example, there is a method in which an SP site selects a target URL based on whether a user has purchased a subscription from a content provider.
[0122]
VIII. Payment-based content access
Prior to accessing the external content, the required payment may be collected using the pay page and pay box functions of the service. To provide such functionality, payment services support a protocol for notifying a content provider / recipient when a payment is received. One embodiment of such a protocol is described below.
[0123]
1) Each content provider passes the content provider's public key and one or more target URLs to the SP when setting up the paypage. For example, the target URL provides access to downloadable or displayable content.
2) When the customer makes a payment using the pay page (optionally using the one-time payment method described in Section X), the sale amount, date and time, and / or other transaction information (Eg, the customer's email address, the IP address of the computer making the request, etc.) is formatted into a character string, and the character string is encrypted with the public key of the content provider.
3) The encrypted string is first passed by the SP site to the visitor's browser and finally to the content provider site 140 as a parameter in the destination URL in the redirect message. Alternatively, this character string can be transferred to the content provider site by another communication method.
4) The content provider site decrypts the string and provides access to the computer according to the validity of the extracted information. The content provider can prohibit reuse of this character string so that the URL is a one-time URL. At this point, the SP does not need to be involved or pass any further information to the content provider.
[0124]
IX. Display of payment counter data in pay page
As described above, using one of the functions that can be implemented by this service, the pay page owner can display real-time payment counter data, such as a target chart, in the pay page. This feature can be enabled for some types of pay pages (eg, charitable and self-reported system pages) and is used to communicate payment history data to pay page visitors be able to. For example, a charity pay page could display a chart showing the amount of money collected throughout the donation event, and the creator of the downloadable work could make a self-reported system payment for the work. You can display the number of visitors. In both cases, the chart may be in the form of a goal chart showing real-time totals for owner-specified goals. This counter may be based on a particular pay page or a set of co-owned pay pages specified by the owner.
[0125]
In one embodiment of this feature, the pay page owner has the option of displaying a counter indicating (a) the number of payments received, (b) the total amount of such payments, or (c) both. Given. In addition, the owner may be given the option to display this counter as a target chart, in which case the owner will be asked to specify a target value. If a goal chart is used, the owner can also specify whether to continue collecting payments when the goal is reached. Once the counter is defined, the application 76 updates the counter upon receipt of the payment and displays the total counter value in the pay page. For example, the total amount may be displayed as a bar graph or thermometer, indicating the total amount received for the goal.
[0126]
Various other types of historical data can also be displayed within the pay page. For example, the application can provide a function to display one or more of an average payment amount, a percentage of visitors making payments, and an average total commission earned by the pay page associate.
[0127]
X. 1-Click payment from external site (Fig. 22)
With other features that can be implemented by the service, the user can make a 1-Click (one operation) payment directly from an external host paybox or other display object (ie, without displaying the corresponding pay page in the payment process). It can be carried out. To implement this function, a “PassThru” property indicating whether 1-Click payment from the paybox is valid can be assigned to each pay page. The owner can be allowed to specify pass-through (PassThru) settings for a pay page when creating or editing the page. For the pass-through enabled pay page, the SP site 66 provides a special 1-Click paybox to authorized 1-Click visitors. When the visitor selects the 1-Click paybox, the SP site immediately redirects the user to the "thank you" URL pre-specified by the owner (or in some cases the hosting associate).
[0128]
FIG. 22 illustrates this process in detail. In the example shown, it is assumed that the user has turned on the 1-Click service and that the pay page associated with the requested paybox is pass-through enabled (PassThru is on). I have. Events 1 to 3 are the same as those in FIG. In response to the paybox graphic request (Event 3), the SP site 66 determines that the visitor has turned on the 1-Click service and that the paypage is pass-through enabled. Therefore, the SP site generates and returns a special 1-Click version of the graphic (events 4 and 5). The graphic includes a 1-Click button or message indicating that the selection completes the transaction. Further, as described above, the paybox graphic displays the name of the visitor and the payee, and may also include other information, such as the selected number of the credit card number used for the transaction.
[0129]
After selecting the paybox graphic, browser 84 sends a request for a paypage along with the user's cookie (event 6). Since the cookie indicates that the user is a 1-Click user, the site 66 (1) performs the transaction according to the visitor's 1-Click settings (Event 7), and (2) places the browser in the owner-specified "Thank you. Responds to this request by redirecting to the URL "event 8". For example, the URL may be a page on an external website of the pay page owner. Alternatively, the visitor's browser can be redirected back to the external page where the payment was initiated, in which case the page would include a payment confirmation message (eg, "Paid $ 1 to ContentProvider.com") It can be displayed together with the display object provided by the SP.
[0130]
A special 1-Click version of the paybox graphics is preferably displayed to authorized 1-Click users (events 4 and 5 in FIG. 22), but instead uses standard graphics or other links. Can be displayed to all users (eg, a button labeled "Click here to pay 25 cents"). In such an embodiment, the name of the approved visitor is optionally displayed on some other display object provided by the SP site (such as a bar at the top of the web page) and within the same external web page. Can be displayed. Further, although the paybox graphics in the above example include text indicating the payment amount, the payment amount may be communicated in other ways. For example, the green, blue, and red payment buttons represent payments of 5, 10, and 25 cents, respectively. Further, the predetermined external Web page can include a plurality of 1-Click pay boxes (for example, the above-described three color-coded buttons) so that a visitor can select a payment amount.
[0131]
In addition, the method shown in FIG. 22 and described above can be used without the payee having his own pay page. For example, after registering with the SP, the recipient can be given a unique URL used to receive payment from the visitor to external (second and / or third party) sites. This URL takes the place of the unique pay page URL. For an approved 1-Click visitor, the process is the same as shown in FIG. 22 and described above (i.e., the visitor is immediately redirected to a "Thank You" page, etc.). Approval 1-For visitors who are not a Click user, the SP site preferably returns a sign-in page when the paybox is selected. There, the user signs in (or registers if necessary) and completes the payment through the general purpose payment pipeline.
[0132]
It is also conceivable that this service requires that all payments made from external sites be 1-Click payments (that is, in order to make such payments to the user, the 1-Click service is required). Do not give the option to set on, off). In such an embodiment, all authorized visitors are treated as 1-Click users.
[0133]
XI. Content distribution model
As described above, the SP site 66 can implement a service that hosts the downloadable content of the pay page owner. Paypage owners can upload such content (optionally with explanatory text) to the service provider database via a special area of the site. When such a service is provided, the site may include a function for the user to search for downloadable content and make a voluntary or required payment to the creator. For example, if the search engine returns a product detail page for a downloadable work, the detail page automatically displays the creator's paybox. The SP site also allows pay page owners to create links to their content and embed those links within their pay pages. For example, a link to each novel hosted by the SP site can be provided on the novelist's pay page.
[0134]
The SP site 66 allows the website operator to (1) find (eg, using a search engine) content uploaded by the pay page owner, and (2) publish such content to the associated pay page owner. A mechanism can be provided that can be re-issued to their own website with the paybox of the other party. An online contract may require that a web site operator not reissue content without a corresponding paybox in order to participate in the program. When uploading new content to the SP database, pay page owners can specify the commission (if any) they want to receive.
[0135]
The SP site 66 may also provide a mechanism for other users to find other users' service provider hosted content, create links to such content, and embed those links within their own website. it can. For example, a music site operator may search for music files in the SP database and incorporate links to such files (or to the creator's pay page) within the music site. As with the Associate Host Paybox, these links can be automatically created by the SP site and set up an Associate Identifier that allows the SP to track and pay the referral fee. Whenever a visitor follows such a link, the site displays the content along with a paybox, paypage, or other entry point to the payment system. According to this model, the user hosting such a link can always receive a commission when another user follows the link and makes a voluntary or required payment to the owner.
[0136]
XII. Integration of payment services into external content provider sites
Figures 23-25 show how some of the above functions can be used to allow a user to make 1-Click, self-report system micropayments and access other SP services from an external content provider site. It is a screen display example which shows whether it becomes possible. In these examples, the service provider site is Amazon. com web site.
[0137]
FIG. 23 shows an example of a virtual Web page called an external content provider site “Forbe.com”. The external page includes two payment links 160 and 162, each of which is provided in association with a corresponding article. These links point to the SP site, but Forbe. com preferably pointing to a pass-through enabled pay page.
[0138]
FIG. 24 is a diagram showing Forbe. Displayed when an authorized 1-Click user selects the payment link 160 in FIG. 4 shows a virtual page of a com site. As mentioned above, any visitor with a service provider account can be treated as a 1-Click user for this purpose. In this example, the SP site charges the visitor's FuMing Young account $ 0.05 and immediately redirects the visitor to the page where the article is displayed (the "story page"), thereby selecting the link. respond. The example story page includes a bar 166 and a discussion area 168, which are dynamically generated and provided by the service provider site according to the methods described above. Bar 166 displays a payment confirmation message indicating that the visitor's account has been charged $ 0.05. Bar 166 further displays (a) a button to initiate a search, (b) a button to display a list of items normally purchased by the user who paid for this article, and (c) a related product. Each of the buttons (linking to the SP site) is included. Discussion area box 168 allows visitors to view and add comments about the article. Comments added via the discussion area object are stored in the database of the SP site.
[0139]
FIG. 25 shows a story page according to another embodiment. In this embodiment, bar 166 also includes a “cancel payment” button 167 that overrides voluntary payments made to access the article. When this button 167 is selected, the SP site will (1) cancel the transaction if the payer's credit card has not yet been charged, or (2) cancel the transaction if the credit card has already been charged. Make a refund. The ability to cancel or refund a payment in this manner is also used in other situations where a user makes a voluntary or self-reported system payment as described above. In some embodiments of this feature, the payer can only cancel the voluntary payment within a certain time after the payment. Each recipient or content provider can specify this time via the SP site, and optionally separately for each pay page.
[0140]
In addition, bar 166 includes an "Add to Library" button that allows visitors to add articles to a personal library maintained at the service provider site. In this example, the "discussion area" box 168 is a drop-down box shown in a drop-down or "expanded" state.
[0141]
FIG. 26 illustrates a method by which a content provider manually adds HTML code around links that “payment enable” content (ie, adds a payment link of the type shown in FIG. 23). It is an example of a page of a site. This page also describes how to insert an optional discussion area box 168 within the same external web page as the payment link.
[0142]
FIG. 27 shows a “payment link creation tool” form provided at the SP site that automatically generates HTML or other coding to add a payment link. Once the user fills out and submits the form (including the operation to specify the nickname used for recruitment tracking), the SP site generates and replies the coding (FIG. 28) that is inserted into the HTML document of the external web page .
[0143]
XIII. Select payer for processing at external site
The SP site 66 describes in advance how the payer will be treated by the SP when browsing external (second and / or third party) Web sites that host payboxes or other SP customized content. It can also have a function to specify. For example, each payer may, via the account setting area of the SP site, determine whether (a) approved in a page on an external web site, (b) personal product / service recommendations in the external web site. (C) links to related sites, and / or whether to display related content in external sites, and (d) access to payer rating-based content. (E) whether 1-Click payment can be made from an external site, (f) whether the total sum of payments made to the external site is displayed, g) Options are available to specify one or more choices, such as whether to be notified when a payment made to an external site reaches a certain threshold. These and other choices can be stored in the "User Accounts" database 72 (FIG. 2), and the SP site can use these choices to display paybox graphics and / or other Content can be customized. The payer may also have the option to set one or more payment options that handle 1-Click or other payments made from external sites (e.g., all 1-Click payments made at Site A). Is charged to the credit card A, and all 1-Click payments made at the site B are charged to the credit card B).
[0144]
Although the present invention has been described in terms of several preferred embodiments, it will be apparent to those skilled in the art, including those embodiments that do not provide all of the features and advantages described herein. Other embodiments are also within the scope of the present invention. And the scope of the present invention is defined by the appended claims.
[Brief description of the drawings]
FIG. 1 is a diagram showing an overall flow of a process for registering a user in a settlement service, managing a pay page, and executing various related operations using a service provider site.
FIG. 2 illustrates a basic website component used to implement a payment service.
FIG. 3 is a diagram showing a process of displaying a pay page on a service provider site side and processing a pay page transaction.
FIG. 4 is a diagram illustrating an example of a pay page.
FIG. 5 is a diagram illustrating an example of a Web page showing a method for a user to manage a pay page and a pay box through a service provider site.
FIG. 6 is a diagram illustrating an example of a Web page showing a method for a user to manage a pay page and a pay box through a service provider site.
FIG. 7 is a diagram illustrating an example of a Web page illustrating a method for a user to manage a pay page and a pay box through a service provider site.
FIG. 8 is a diagram illustrating an example of a Web page showing a method for a user to manage a pay page and a pay box through a service provider site.
FIG. 9 is a diagram illustrating an example of a Web page showing a method for a user to manage a pay page and a pay box through a service provider site.
FIG. 10 is a diagram illustrating an example of a Web page showing a method for a user to manage a pay page and a pay box through a service provider site.
FIG. 11 is a diagram illustrating an example of a Web page showing a method for a user to manage a pay page and a pay box through a service provider site.
FIG. 12 is a diagram illustrating an example of a Web page illustrating a method for a user to manage a pay page and a pay box through a service provider site.
FIG. 13 is a diagram illustrating an example of a Web page showing a method in which a user finds and installs another user's pay box and becomes a pay page associate.
FIG. 14 is a diagram showing an example of a Web page showing a method in which a user finds and installs another user's pay box and becomes a pay page associate.
FIG. 15 is a diagram illustrating an example of a Web page showing a method in which a user finds and installs another user's pay box and becomes a pay page associate.
FIG. 16 is a diagram showing an example of a Web page showing a method in which a user finds and installs another user's pay box and becomes a pay page associate.
FIG. 17 is a screen display showing a function for a user to request payment from another user using a customized version of an existing pay page.
FIG. 18 is a screen display showing a function for a user to request payment from another user using a customized version of an existing pay page.
FIG. 19 is a screen display showing a function for a user to request payment from another user using a customized version of an existing pay page.
FIG. 20 is a diagram showing a sequence of events that occur when a user requests a Web page including a pay box.
FIG. 21 illustrates a method of service for redirecting a user (usually a paypage owner) to external content based on a visitor's voluntary payment history.
FIG. 22 illustrates a method for a 1-Click user to complete a payment transaction directly from a paybox of an external host.
FIG. 23 shows how (a) links to services provided by the service provider site and (b) personalized content provided by the service provider site can enhance the web pages of external web sites. FIG.
FIG. 24 shows how (a) links to services provided by the service provider site and (b) personalized content provided by the service provider site can enhance the web pages of external websites. FIG.
FIG. 25 shows how (a) links to services provided by the service provider site and (b) personalized content provided by the service provider site can enhance web pages on external websites. FIG.
FIG. 26 is a diagram showing an instruction page for adding a payment link and a customer review module to a page of an external website.
FIG. 27 is a diagram showing a payment link generation tool of a service provider site.
FIG. 28 is a diagram showing a payment link generation tool of a service provider site.

Claims (96)

A server system for providing a settlement service between users,
A pay page generation module that provides a function for a payee to generate his or her own pay page in order to receive payment from another user;
A repository of payee-specific paypages generated using the paypage generation module, wherein the paypages allow a paypage visitor to enter a payment amount and initiate payment to a corresponding payee Has a function that allows you to
A server system comprising a transaction processing module responsive to a settlement request initiated by a remittance by a visitor to a pay page from the visitor to a payee associated with the pay page. 2. The system of claim 1, wherein the pay page generation module includes a function that allows a payee to specify a proposed payment amount to be displayed within the pay page of the payee and used as a default payment amount. . The system according to claim 1, wherein the pay page generation module includes a function that allows a payee to specify at least a text message and an image to be displayed in the pay page and a display color of the pay page. The system according to claim 1, wherein the pay page generation module has a function of allowing a payee to specify a URL of an external page to be displayed to a visitor after completion of payment. The system of claim 1, wherein at least some of the pay pages have been modified to allow for universal payment. A payment request module that provides a function of generating and transmitting a payment request e-mail message in response to the payment request information input by the recipient;
The system of claim 1, wherein the email message includes a link to the payee's pay page and includes at least one parameter that specifies how the payer customizes the pay page. Further comprising a plurality of pay page templates used to generate pay pages by the pay page generation module;
The system of claim 1, wherein each pay page template specifies a pay page layout and behavior. The system of claim 1, further comprising a pay page display module that customizes display of the pay page in response to a page request from a visitor. The pay page display module executes a single visit performed by the visitor while viewing the pay page to enable the payee to receive payment for at least a plurality of authorized visitors to the pay page. 9. The system according to claim 8, wherein an operation instruction is displayed. 9. The system of claim 8, wherein the pay page display module responds to a parameter passed to the server system with a visitor request to the pay page by customizing the pay page according to the parameter. The system according to claim 10, wherein the parameter is a payment amount displayed in the pay page. The system of claim 1, wherein the pay page generation module provides the payee with an option to display a real-time payment counter in the pay page of the payee. A paybox generation module that is modified to be installed in an external Web page to describe a link to the paypage of the payee, and that provides a function for generating a paybox that includes a display object. When,
An object server for dynamically generating and providing a display object for display in an external Web page on which the paybox is installed, and customizing the content of the display object according to the identification of an approved visitor. The system of claim 1 comprising: A feature that allows the recipient to define a link to the recipient's pay page and make the link available to other users via the server system to find and install it in an external web page The system of claim 1, further comprising a link generation module that provides: At least one type of link for creating a link to the payee's page for incorporation within an external web page, and for the payee to customize the paypage for visitors accessing the paypage from the link; The system of claim 1, further comprising a link generation module that provides an option to specify the following parameters. A method for performing network-based user-to-user payment, comprising:
Providing an online service that allows the user to set up a customized payee specific pay page and receive payment from other users;
Receiving, from a visitor's browser, a page request identifying a payee-specific pay page generated using the service;
Returning a pay page to the browser including a link for initiating a payment to a payee associated with the pay page for display to the visitor and the visitor including a field for specifying a payment amount; And a method including: Initiating a settlement transaction to transfer money from the visitor to the recipient in response to the selection of the link. 17. The method of claim 16, wherein returning the pay page comprises customizing the pay page according to parameters passed with the page request. 19. The method of claim 18, wherein customizing the pay page comprises displaying a proposed settlement amount passed with the page request. 19. The method of claim 18, wherein customizing the pay page includes displaying the pay page in a display color specified by the parameter. 17. The method of claim 16, wherein the page request includes an identifier of the recipient's associate and further comprising determining compensation for the associate for referencing the visitor. 17. The method of claim 16, wherein providing the online service comprises providing a plurality of pay page templates that specify at least a pay page layout and behavior. A computer-implemented method for performing user-to-user payments, comprising:
Providing a service for the payee to generate a customized pay page to receive payment from another user;
Generating and storing a pay page specific to the payee according to the pay page settings specified by the payee through the service;
Displaying to the visitor a customized version of the pay page indicating a one-time operation performed by the visitor within the pay page to pay the payee;
At least: (a) initiating a settlement, and (b) responding to the visitor's execution of a single operation by redirecting the visitor's browser to an external page previously specified by the recipient. And a method comprising: 24. The method of claim 23, wherein the pay page includes a field for a visitor to specify a payment amount. 24. The method of claim 23, further comprising responding to performing a single operation by the visitor by sending at least a recipient-specific message to the visitor by email. 24. The method of claim 23, wherein the pay page includes a proposed payment amount that is used as a default payment amount if not modified by the visitor. A server system for providing a settlement service between users,
A pay page generation module that provides a function for a payee to remotely generate a pay page to receive payment from another user;
A repository of payee-specific paypages generated using the paypage generation module;
A pay page display module that customizes the display of the pay page according to parameters included in the pay page request message;
A payment request module that provides the ability for the payee to customize the pay page for a particular payer and start sending an e-mail message containing a link to the pay page to the payer, wherein the link is Including one or more parameters that specify how the pay page display module customizes the pay page for the payer;
A server system comprising: a transaction processing module that processes a pay page settlement transaction. 28. The system of claim 27, wherein each of the pay pages includes a feature that allows pay page visitors to specify a payment amount and initiate a payment to a corresponding payee. 28. The system of claim 27, wherein the payment request module provides the payer with an option for a payee to specify a payment amount to be displayed in the pay page. 28. The system of claim 27, wherein the payment request module comprises an option for a payee to provide a plurality of email addresses to send an email message to a plurality of payers. A system for compensating the creator of the work,
A service provider site that provides a service for a user to create a customized pay page to receive payment from another user, and performs a user-to-user payment service for remittance from a pay page visitor to a pay page owner;
A pay page hosted by the service provider site and containing descriptive content associated with the creator of the work;
An external content provider website that hosts the work with a link to the pay page and allows a consumer of the work to make a voluntary payment to the creator of the work. 32. The system of claim 31, wherein the link is encoded with an identifier of a content provider web site operator so that the service provider site can track visitation of the visitor from the content provider site to the pay page. A link is communicated to the service provider site,
32. The system of claim 31, wherein the system is encoded with a proposed payment amount displayed within the pay page when the visitor follows the link. A link is placed in a paybox associated with the creator of the work,
32. The system of claim 31, wherein the paybox includes a display object provided by the service provider site when a visitor displays an external web page on which the paybox is installed. The service provider site stores a copy of the work;
32. The system of claim 31, wherein a service is provided for a user to find and republish the work as an associate of the creator. A transaction processing module that responds to the selection of the link by remittance to the creator;
32. The system of claim 31, whereby a visitor can perform the operation once and pay the creator. A server system for providing a network-based settlement service between users,
A pay page generation module that provides a payee with the ability to remotely create a customized pay page to receive payments from other users;
A pay box generation module for providing a function for a payee to remotely create a pay box for setting a link to an own pay page from an external web page;
A data repository for storing the pay page and the associated pay box description created by the payee;
A pay page display module for displaying a pay page to a visitor;
A server system comprising: a transaction processing module that responds to a payment request initiated by a pay page visitor by remitting the visitor to a payee associated with the pay page. 38. The server system of claim 37, wherein the paybox generation module provides a function for a recipient to specify a text message to be displayed in his or her paybox. 38. The pay box generation module provides a function for a payee to specify a payment amount associated with the pay box, and when a visitor selects the pay box, the payment amount is displayed in a corresponding pay page. The server system according to 1. 38. The server system of claim 37, wherein the paybox generation module generates a coding for a user to install a paybox in an external web page. The paybox generation module includes a user identifier in the coding;
41. The server system of claim 40, wherein the transaction processing module uses the identifier to track a resulting referral of a visitor to a corresponding pay page. The server system according to claim 37, further comprising a module that provides a function for a third-party user to find and install another user's pay box. Furthermore, an object server is provided for generating and providing a paybox display object to be displayed in an external Web page,
38. The server system of claim 37, wherein the object server customizes the paybox display object for approved visitors. 44. The server system according to claim 43, wherein the object server displays the name of the approved visitor in the paybox display object. 44. The server system according to claim 43, wherein the object server dynamically generates and provides a paybox image to be displayed in an external Web page. The object server generates and provides a display object for instructing an authorized visitor to perform a single operation performed to complete payment for the payee,
44. The server system according to claim 43, wherein the visitor can complete the payment to the payee by displaying the corresponding pay page by performing the one-time operation. 47. The server system of claim 46, wherein the transaction processing module is responsive to performing the single operation by redirecting the visitor's browser to an external target pre-specified by the recipient. 38. The server system of claim 37, wherein the pay page display module customizes the pay page based at least on parameters passed with a page request message generated from a pay box selection. A system for collecting payments,
A service provider site that hosts a pay page of a payee and provides a function for a visitor to the pay page to make a payment to the payee;
An associated Web site that is separate from the service provider site and that includes a Web page that hosts a display object provided by the service provider site;
The display object is provided in connection with a selectable link to the pay page;
A system wherein the service provider site has a function of compensating an operator of the associate web site when a visitor selects the link and makes a payment to the payee. 50. The system of claim 49, wherein the display object is a graphic provided by the service provider site. The system of claim 49, wherein the service provider site customizes the content of the display object for authorized visitors to a web page. The service provider site customizes the content of the display object to the visitor by displaying a message indicating the one-time operation to be performed by the visitor to complete the payment to the payee. And
50. The system of claim 49, wherein the service provider site responds to performing the single operation by completing payment to the payee without requiring a visitor to perform additional operations. 53. The system of claim 52, further comprising the service provider site responding to performing the one-time operation by redirecting the visitor's browser to an external web page pre-specified by the recipient. The link includes at least one pay page parameter passed to the service provider site when a visitor selects the link;
50. The system of claim 49, wherein the service provider site customizes the display of the pay page according to the parameters. 55. The system of claim 54, wherein the parameter is a suggested settlement amount displayed in the pay page. A service provider site,
A pay page generation module that provides the payee with the ability to create a customized pay page to receive payments from other users;
A pay box generation module that provides a function for a payee to create a pay box providing a link to a corresponding pay page and to make the pay box available to other host users as a pay page associate;
An associative hosting module that provides a user with a function of referring to a pay page and an associated pay box created by a payee and selecting a pay box to be installed in an external Web page. A link generation module for facilitating associate installation of payboxes by generating a paybox code sequence that the associate incorporates into web page coding;
57. The service provider site of claim 56, wherein the link generation module incorporates an associate identifier into the code sequence to enable the service provider site to track a visitor's associate recruitment. In addition, a transaction processing module for executing a remittance started from the pay page is provided,
57. The service provider site of claim 56, wherein the transaction processing module tracks visitor associate submissions to pay pages and provides compensation to associates for at least some submissions. Claims: The paybox generation module provides a payee with a function to specify the payment amount associated with the paybox, such that by selecting a paybox, the payment amount is displayed in a corresponding pay page. 61. A service provider site according to item 56. Further, an image server for generating and providing a paybox display object to be displayed in the associate Web page is provided.
57. The service provider site of claim 56, wherein the image server incorporates an approved visitor name into the paybox display object. 61. The service provider site according to claim 60, wherein the paybox display object is a graphic image. A system for collecting payment from a visitor to a content provider site,
A service provider site including a one-time operation settlement started from a page of an external site and having a function of collecting payment from a user;
A web page hosted by the content provider site outside the service provider site,
The web page includes a payment link that includes a reference to the service provider site to allow a user to pay for content provided on the content provider site;
The service provider site responds to the selection of the link by an authorized visitor by recording the visitor's account as a one-time transaction;
A system in which the visitor can perform one-time operation settlement directly from the content provider site. The service provider site is further responsive to the selection of the payment link by redirecting the visitor's browser to a content page of the content provider site;
63. The system of claim 62, wherein the payment link allows the visitor to pay and access a content page with a single selection operation. The content page includes a display object provided by the service provider site;
64. The system of claim 63, wherein the service provider site personalizes the content of the display object to authorized visitors. The system of claim 64, wherein the service provider site personalizes the display object with an authorized visitor's name. The system of claim 64, wherein the service provider site personalizes the display object with a payment confirmation message. 64. The system of claim 63, wherein the content page further includes a link that allows a visitor to cancel a payment made via the payment link. 63. The system of claim 62, wherein the service provider site further comprises a module that generates coding to add a payment link to an external web page. A system that provides fee-based access to content,
A service provider site that collects payments from users, including one-time payments initiated from a page on an external site,
The service provider external to the service provider site, comprising a content page, including an additional page including a selectable link to the content page, wherein the link allows the service provider site to collect payments; A content provider site that contains a reference to the site,
When the visitor registered on the service provider site selects the link, the service provider site charges the visitor a fee for accessing the content page, displays the content page on the visitor's browser,
A system that allows the visitor to pay for and access the content page in a single operation. 70. The system of claim 69, wherein the service provider site responds to the selection of the link by redirecting the browser to the content page. 70. The system of claim 69, wherein the service provider site displays the content page with a payment confirmation message. 70. The system of claim 69, wherein the service provider site displays the content page with a control that allows the visitor to cancel payment of the fee. 70. The system of claim 69, wherein the service provider site comprises a link creation tool that creates coding to embed a one-time payment link within an external web page. A method for providing a one-time payment function within a Web page outside a service provider site for collecting the payment,
Incorporate a reference to a display object provided by the service provider site in the coding of the web page, and when the visitor displays the web page, the display object is requested from the service provider site and displayed in the web page Steps to be performed,
At a service provider site, a customized version of the display object adapted to be selected by the visitor to make a one-time payment to a corresponding recipient in response to a request for the display object from an authorized visitor's browser. Responding by returning
Performing a payment from the visitor to the recipient without requiring the visitor to perform further operations in response to the visitor selecting the customized version of the display object. The method of claim 74, wherein the display object is a graphic. 75. The method of claim 74, wherein the service provider site is further responsive to the visitor's selection of a customized display object by redirecting the visitor's browser to an external goal previously specified by the recipient. 75. The customized version of the display object includes the visitor's name, a payment amount, and an indication that selecting the display object will result in the payment amount being remitted to the recipient. The described method. A method for providing personalized content to a website visitor without revealing the identity of the visitor to the website operator,
Incorporating a reference to an object provided by a server separate from the Web site in the coding of the Web page of the Web site so that the object is requested from the server when a user displays the Web page. When,
Receiving, at the server, a request for the object, generated by a visitor's browser, in response to a web page coding search from the web site;
At the server, at least (a) identifying the visitor; (b) customizing the object based on at least the visitor's identity to create a personalized object; (c) to the visitor Responding to the request by returning the personalized object to the visitor's browser as an output of the request. 79. The method of claim 78, wherein customizing the object comprises dynamically generating a graphic for display in the web page. 79. The method of claim 78, wherein when the personalized object is selected by the visitor, the visitor's browser obtains a pay page associated with the object. When the personalized object is selected by the visitor, the recipient associated with the object does not need to perform further operations by the visitor, and the amount displayed in the object is reduced. 79. The method of claim 78, wherein the method is paid. 79. The method of claim 78, wherein customizing the object comprises displaying at least one personal recommendation of a product or service within the object. 79. The method of claim 78, wherein the object is further customized based on an identity of the web site. A system for distributing content to users,
(A) a service provider site that collects voluntary payments from a user accessing content on an external site and (b) generates a user rating;
An external content provider site that uses the service provider site to host a digital work and collect payment from a user accessing the digital work,
The content provider site includes a plurality of rating-based redirects, each rating-based goal corresponding to a respective user rating, and providing access to content associated with the respective user rating;
The content provider site further includes a user selectable navigation link to access a rating-based goal associated with each rating, wherein the link points to the service provider site;
The service provider site is responsive to the user's selection of a link by determining a user rating, selecting a goal corresponding to the rating, and redirecting the user's browser to the selected goal;
A system wherein the user is provided with rating-based access to content on the content provider site without disclosing the identity or rating of the user to the operator of the content provider site. 85. The method of claim 84, wherein the service provider site generates the rating for the user based at least in part on a user's respective payment history. The link includes a selectable display object provided by the service provider site;
The service provider site selects a message to display on the display object based on a user's rating;
85. The method of claim 84, wherein the message is one of a plurality of messages pre-specified for the service provider site by an operator of the content provider site. The method of claim 86, wherein the display object is a graphic. 85. The method of claim 84, wherein at least two of the goals provide access to corresponding different versions of the digital work. A method for controlling user access to content, comprising:
Setting a plurality of goals on the content provider site such that each goal corresponds to a respective user rating and provides access to content associated with the respective user rating;
Incorporating a link to the service provider site on a web page of the content provider site to allow rating-based access to goals;
Determining a rating for the user, selecting a goal corresponding to the rating, and redirecting the user's browser to the goal in response to the user selecting the link;
The service provider site collects payment from a user of the content provider site and other external websites, generates a rating of the user,
A method wherein the user is granted rating-based access to content on the content provider site without disclosing the identity of the user or the rating to the operator of the content provider site. 90. The method of claim 89, wherein the server provider site generates the rating of the user based at least in part on a respective settlement history of the user. The link includes a selectable display object provided by the service provider site;
The service provider selects a message to display on the display object based on the rating of the user;
The method of claim 89, wherein the message is one of a plurality of messages pre-specified by an operator of the content provider site. 90. The method of claim 89, wherein at least two of the goals provide access to corresponding different versions of the digital work. A method for providing payment-based access to digital works,
Hosting the work on the content provider site in connection with the link to the payment service provider site;
(A) collecting payment from the user on the payment service provider site in response to the user selecting the link; and (b) generating a character string including transaction information associated with the payment. And (c) redirecting the user's browser to a target on the content provider site so that the string is passed to the content provider site along with a target URL;
Determining whether the string passed with the target URL is valid on the content provider site to determine whether the user has authority to access the work. Including methods. 94. The method of claim 93, wherein the string is passed in an encrypted form. 94. The method of claim 93, wherein the link is a link to a payee-specific pay page hosted by the service provider site. The link is a one-operation payment link that, when selected, (a) completes the payment and (b) immediately redirects the user's browser to the target;
94. The method of claim 93, wherein the user completes a payment without displaying the payment service provider site.

Images