JP2004516776A

JP2004516776A - リターントラフィックに基づくインターネット支払いプロセス

Info

Publication number: JP2004516776A
Application number: JP2002553384A
Authority: JP
Inventors: ミデルヤンス，ヤコブス; カーテ，ウァルネルエルテーテン
Original assignee: Koninklijke Philips Electronics NV
Current assignee: Koninklijke Philips NV
Priority date: 2000-12-22
Filing date: 2001-12-10
Publication date: 2004-06-03
Also published as: DE60114888T2; ATE309578T1; CN1478240A; EP1368762B1; US20020091544A1; WO2002052813A2; WO2002052813A3; ES2252153T3; DE60114888D1; US7103557B2; EP1368762A2; KR20030001366A

Abstract

本発明は、リターントラフィックに基づくインターネット支払いシステムに関わる。インターネット上で配信されたコンテンツに対する支払いに関して、本発明の面は、パケットの明確なリターンフローを提供する。サーバーによるこれらリターンパケットの受け取りは、サーバーによるクライアントの支払いトークンの受け取り、及び、コンテンツの配信を続けるサーバーに対する合図を含む。クライアントによるマスクリーディングは、データパケットと共にチャレンジを送り、クライアントがこれに対する応答をリターンパケットと共に送ることで防止され得る。

Description

【０００１】
本発明は、クライアントに受信されるディジタルワークのコンテンツが支払いを必要とする場合にインターネットのような通信チャネル上でのディジタルワークの配信（ｄｅｌｉｖｅｒｙ）を制御するプロセス及びシステムに関わる。特に、上記プロセスに好適な上記システムに含まれる送信プロトコルに関わる。
【０００２】
インターネットトラフィックは、ベスト・エフォート型サービスであることを特徴とする。つまり、インターネット上で送られるデータパケットは、途中で損失又は遅延される可能性がある。これを解決するための対策は、クオリティ・オブ・サービス又はＱｏＳに関して一般的に参照される。
【０００３】
上記タイプのシステムは、文書ＥＰ‐０７１５２４７から公知である。この文書は、レンダリングシステム、ディジタルワークの構造、ディジタルワークに対するユーザ権利の結び付け、リポジトリ、クレジットサーバー、ユーザ権利言語、及び、上記システムが含み得るリポジトリ・トランザクションの広範囲にわたる記述を提供する。
【０００４】
上記文書に開示される送信プロトコルは、ある故障モード、例えば、通信チャネルでの故意の或いは偶然の干渉を妨げることに向けられる。その明確な目的は、ディジタルワークを使用した後に支払いを回避する手段として通信に関係した人が接続を断つ時間がないようにすることである。完全なディジタルワークは、それに対する支払いが達成される前に配信される必要がある。つまり、配信でのトランザクションは本質的にアトミック性である。
【０００５】
動作に関して、上記文書は、送られるべきブロックが幾つかある場合に要求側（クライアント）から確認応答メッセージを受信するまでサーバーが待機することを記載する。サーバーは、確認応答メッセージを受信すると、次のブロックを要求側に送り、再び確認応答メッセージを待つ。従って、送信は、１ブロック毎の動作モードで行われる。要求側（クライアント）は、同じ状態のサイクルを繰り返す。
【０００６】
サーバーは、もはや送るブロックがなくなると、トランザクションをコミットし、最終確認応答メッセージを待つ。サーバーが最終通信メッセージを受信する前に通信故障があった場合、サーバーは、まだトランザクションをコミットするがクレジットサーバーへのそのイベントに関するレポートを含む。このレポートは、２つの目的を果たし、その一つは、完全に受信されていないディジタルワークに対する請求に関して、ユーザによる全てのクレームを正当化することを助ける。同様のプロトコルが要求側（クライアント）にも存在し、その重要な特性は、サーバーと要求側の双方が、全てのデータブロックが配信される前に送信が中断された場合には送信を取り消し、全てのデータブロックが配信された場合には送信をコミットすることである。
【０００７】
配信におけるこのようなトランザクションのアトミック性質は、関係するディジタルワークが大きいとき、又は、コンテンツが長期間にわたってストリーミングされなくてはならないときに幾つかの問題を生じさせる。このような情況は、例えば、オーディオ及び／又はビジュアル又は他のマルチメディア素材のコンテンツ全体の受け取り完了後に、最初にそれら素材に対する支払いに関して起こる。要求側（消費者）は、これらコンテンツに対する支払いを済ます前にディジタルワーク全体を見る（即ち、受信する）ことができない。一つの問題は、ディジタルワークの大きさ、従って、転送するのに必要な時間に比例して大きい、通信の中断の可能性に関わる。別の問題は、ディジタルワークに対する支払いを正当化することに関して、サーバー並びに要求側の両方からクレジットサーバーに対するレポートを必要とすることに関わる。更に別の問題は、サーバーが要求側から最終確認を受信するまでどの転送されたディジタルワークも削除することができず、且つ、データ損失の防止に関してファイルを使用することもできないことに関わる。これは、例えば、実際に責任が増すことなく２相コミット又は暗号化レベルを含む広範囲のプロトコルを必要とする。
【０００８】
上記トランザクションのアトミック性質に関わる別の問題がまだある。この問題は、実時間処理要求に関わる。連続的なメディアの配信は、（その配信がダウンロード動作でない場合）実時間の取り扱いを必要とするため、アトミック性の支払いは、それに関するプロセス又は機能がメディア表示を停止（「ヒックカップ」又は「ヒッチ」）させないよう、例えば、１パケット当たり２０ｍｓの配信速度で行われる必要がある。
【０００９】
本発明は、上記プロセス及び上記プロセスに好適なシステムに対する送信プロトコルを簡略化することを目的とする。
【００１０】
本発明は、サーバーコンピュータ及びクライアントコンピュータ（いわゆる、エンドホスト、従って、エンド−ユーザ操作）で実行可能な送信プロトコルを提供することを別の目的とする。
【００１１】
本発明は、ディジタルワークの停止された送信の場合にも、受信した全てのディジタルパケットに対する支払いを課す送信プロトコルを提供することを目的とする。
【００１２】
本発明の一面によると、一つ以上の上記目的は、請求項１に記載する通り、インターネットのような通信チャネル上でのディジタルワークの配信を制御するプロセスによって実現される。
【００１３】
基本的な新規の発明の概念は、利用できる送信プロトコルから既知の一連の確認応答コード（ＡＣＫ）にも支払いトークンの機能を担わせることである。この概念の中心は、ストリーミング配信、即ち、ある期間にわたって続くパケットの通常の流れに支払いをリンク又は関連付けることである。支払いは、その期間の経過と共に上がり、コンテンツの配信は受け取りの確認の応答の促進がなく、従って、コンテンツに対する支払いが上がらないと停止される。
【００１４】
関連する技術的利点は、確認応答コードの連続的なストリームによって実現され含まれるように受信したパケットのコンテンツに対する支払いを規制するために、ディジタルワーク（又はその一部）をクライアントが受信したといった既存の明確な監査証跡（ａｕｄｉｔｔｒａｉｌ）を用いる点である。更なる技術的利点は、この既に利用できる確認応答コードの連続的なストリームにコンテンツに対する支払いをリンクさせることで、配信されたコンテンツに対する支払いの規制が簡略化される点である。その結果、支払いトークン、コミットメント、又は、暗号化に関して送信プロトコルにレイヤを追加する必要性は排除される。従って、さほど厳しくない送信プロトコル又はインテグリティ機構で十分である。クライアントは、望ましいオーダーで受信したと自身が既に確認した各パケットに対して支払うに過ぎない。クライアントは、受信したとおりに支払う。これにより、支払いトランザクションの冗長構成がより少なく、より高速な実行が可能となる。従って、サーバー及びクライアントの両方に対してより効率的となる。
【００１５】
送信及びトランスポートプロトコルといった用語は、ストリーミングプロトコルも含むことに注意する。ストリーミングは、送信又はトランスポートプロトコルに制限されず、少なくともサーバー・クライアントアプリケーションプロセスはこれに関して役割を担う。
【００１６】
本発明の更なる面によると、一つ以上の上記目的は、請求項３に記載する通りサーバーによるディジタルパケットの送信中にクレジットウィンドウを利用することで実現される。これは、ディジタルワークのコンテンツの支払いに関してディジタルワーク全体の送信がこれに対する支払いを確実に行う前に完了されなくてはならないことに関する先入観を克服する。関連する技術的利点は、ディジタルワーク全体と比較して非常に小さいクレジットの量をサーバーが許可する点である。これによりサーバー（又はコンテンツプロバイダ）は、クライアント（要求側）から更なる確認応答コードを受信しないときにクレジットにおいて送ったパケットに対する支払いがなくとも大きい被害を受けないことを伴う。クレジットウィンドウの大きさは、実際の送信状態及びトランザクションの方針に適合可能である。
【００１７】
ウィンドウの概念は送信の流れ速度を制御する使用に関して公知である。例えば、Ｄ．Ｐ．Ｂｅｒｔｓｅｋａｓ及びＲ．Ｇ．Ｇａｌｌａｇｅｒによる“ＤａｔａＮｅｔｗｏｒｋｓ”，Ｐｒｅｎｔｉｃｅ−Ｈａｌｌ，Ｉｎｃ．，ＮＪ，ＵＳＡ，１９９２，第６．２章を参照する。インターネットのＴＣＰプロトコルは、ウィンドウ制御に基づく。つまり、「トランジットウィンドウ」は公知であるが、ディジタルワークの（一部の）ストリーミングコンテンツに関して本例における「クレジットウィンドウ」の概念は新規である。
【００１８】
送信制御プロトコル（ＴＣＰ）は、送信されるべきデータをＩＰパケットにセグメンテーション化し、バイトを番号付けすることを可能にする。これらの番号を用いて、ＴＣＰ接続の受信器は、ＩＰが誤ったオーダーで配信した場合に、受信したパケットを再び順番付けする。更に、この受信器は、先行するパケットに関しても受信された、受信したパケット夫々に対してＡＣＫパケット（確認応答）を送り側に送り返す。ＴＣＰ送り側は、損失を補償するためにどのパケットが再送信される必要があるかを決定し、それによりＩＰベスト・エフォート型配信を信頼あるエンド・ツー・エンドトランスポートにする。パケットは、待っているＡＣＫが受信されないタイム・アウト期間が経過した後、又は、前のパケットが３回確認されたとき再送信される。タイム・アウト期間は、ラウンド・トリップ・タイム（ＲＴＴ）の推定に基づく。二重のＡＣＫは、失ったパケットに後続するパケットが受信されたことを示し、これは反対にトランスポートチャネルにおいて更なる輻輳がないことを示す。
【００１９】
失なわれたパケットに関して送り側に通知する他の代替法は、ＮＡＫ、即ち、否定応答又はＳＡＣＫ、即ち選択応答を送ることである。
【００２０】
ＴＣＰは、その送信速度を決定するためにもＡＣＫを使用する。この速度は、確認が必要な途中のパケットの数としてＲＴＴに対するウィンドウに従う。ウィンドウは、成功した送信の際に増分される一方で、反対に、パケットが失われると減少される。このようにしてＴＣＰは、その送信速度を利用できる帯域幅に適合させる。
【００２１】
本発明は、請求項５記載するように使用するプロセスを提供する。
【００２２】
本発明は、請求項６記載の方法を更に提供する。
【００２３】
本発明は、請求項９記載のコンピュータプログラムを提供する。
【００２４】
本発明の上記及び他の面は、以降に説明する実施例を参照して明らかとなり明確となるであろう。
【００２５】
本発明の実施例によると、例えば、セッション開始フェーズ中のクライアントからサーバーへの要求に続き、確認応答コード及び支払いトークンのリターントラフィックの設定に関して双方の間で交渉フェーズがある。これに関して、更にコンテンツのタイプ、タイプコーディング、ＩＰアドレス、ポート番号等のような他の技術的な面に関して同意が得られなくてはならない。本発明によるプロセスにおける次の段階は、例えば、マルチメディアコンテンツを有するディジタルワーク（１００）がサーバー（２００）で幾つかのディジタルパケット（１００_１・・・１００_Ｚ）に形成されることを含む。パケット（１００_１・・・_ｉ・・・_Ｚ）の大きさは、該ディジタルワーク（１００）の大きさに比べて小さい。例えば、オーディオコンテンツの場合、パケットの大きさは、２０ｍｓ間隔の送信に従うことができるに十分に小さい。サーバー（２００）は、クライアント（３００）にパケット（１００_１・・・１００_Ｚ）を送信するために使用する送り側ソフトウェア及び／又はハードウェアコンポーネント（２１０）を有する。クライアント（３００）は、受信したパケットを記憶（３１０）又は再現（３２０）さもなければ処理する。クライアント（３００）は、サーバーに確認応答コード（ＡＣＫ）を送ることで受信したパケットを確認（３３０）する。受信側ソフトウェア及び／又はハードウェアコンポーネント（図示せず）を有するサーバーのモニタ（２２０）は、クライアントによって送られた確認応答コード（ＡＣＫ）を受信し、これら確認応答コードに基づいてパケット送信の続きを制御する。このためにモニタ（２２０）は、送り側ソフトウェア及び／又はハードウェア（２１０）に制御コマンドを発する。クライアントから要求された確認応答コードがサーバーによって指定された通りに受信された場合だけ、サーバーによる上記コンテンツのストリーミングが続き、さもなければ、クライントからサーバーへの確認応答コードの開始された連続的なリターントラフィックが中断された場合、サーバーによるストリーミング送信は停止される。受信した確認応答メッセージは、追加請求を取り扱う支払いレジストリ（図示せず）で累積される。クライアントは、サーバーが送る一つ一つのデータパケットに対して一つのＡＣＫパケットを返す必要がないことに注意する。他のマッピングも同様に機能することは明らかである。
【００２６】
図２は、図１によるモニタ（２２０）の制御動作の詳細を示す。図２は、メディアストリームの連続的なパケットの順番を示す。Ｎ−１と示されるパケットまでのパケットが送信される。Ｔのパケットが送信されるが、これらのパケットはまだクライアントによって確認されていない、即ち、これらのパケットは通過中である。サーバーは、任意の所与の瞬間にＷまでのパケットをまだ確認されていないとして受け入れられるよう設定される。Ｗのパケットがいずれ確認されないと、サーバーは送信を停止させる。
【００２７】
モニタ（２２０）は、送信されているパケットの数、及び、通過中のパケットの数を管理する。送信されているパケットは、そのパケットに対してＡＣＫが受信されたか否かに依存して夫々Ｓｕｃｃｅｓｓｆｕｌ或いはＵｎｓｕｃｃｅｓｓｆｕｌとラベル付けされる。各パケットは、送信時間及び再送信デッドラインと関連付けられる。送信時間は、通常の動作中にパケットがいつ送信されるかを示し、再送信デッドラインは、クライアントが再現するまでにパケットを受信することができることにおいて再送信が有効か否かを示す。（ダウンロード動作に関して常にこの場合である）。これらの時間は、パケットの数（オーダー）に比例して必ずしも増加しない。本実施例において、例として、これらの時間が該パケットのオーダーに比例して増加すると仮定する。
【００２８】
本発明の一実施例では、受信したデータの確認応答は、意図的に時間制限され得る。その例は、オーディ素材の傾聴又はビデオ素材の視聴が夫々事前傾聴又は事前視聴状態において与えられる場合である。確認応答は制限され、サーバーは時間制限設定が経過した後に停止する。事前傾聴又は事前視聴期間中、クライアント又はユーザは、トランザクションを確認する可能性を与えられ、要求通りに確認されない場合、更なるトランザクションは許可されない。
【００２９】
事前視聴又は事前傾聴期間中に受信したコンテンツに対して異なる支払い方針があることが予想される。更に、クレジットウィンドウの任意の再設定後に上記コンテンツが支払い方針に関して夫々に扱われることが予想される。
【００３０】
本発明の別の実施例では、クレジットウィンドウは最初大きくてもよい。事前視聴又は事前傾聴期間後にクレジットウィンドウの大きさを再び一回または何回か設定することが可能である。クレジットウィンドウの大きさにおけるインクリメントは、事前視聴又は事前傾聴或いは任意の他のタイプの試験期間中にサーバーが受信する必要のない幾つかのＡＣＫに関連する。更に、要求された場合に、又は、所望の場合にクレジットウィンドウの大きさのデクリメントを考慮し実行することも可能である。クライアントによる更なるアクション、例えば、試験期間が経過する前のクライアントによる確認応答は、決定木又はプロトコルにおいて技術的に実行され得る。別の実施例では、クレジットウィンドウ機構は、試験期間が経過した後にだけ開始され得る。これは、クライアント側の処理と処理を実行するシステムとの同期化を必要とする。
【００３１】
ユーザ確認は幾つかの方法で与えられ得る。例えば、クライアント又はユーザがどのアクションも行わない場合、サーバーはファイルが配信されたときにデータパケットの正しい受け取りを確認する。これは、「クライアントからの知らせがないことはよい知らせ（＝正しい受け取り）」への類推であり、従って、トランザクションは適切である。第２の例は、クライアント又はユーザによるレコーディングの終わりにおけるデータパケットの望ましい配信に関するアクションの生成である。上記アクションは、再生装置に関連する任意のアクティブモーブに対してでもよい。ユーザが行う全ての種類のクリックまたは他のアクションを区別する必要があることは容易に明らかとなり、さもなければ、データパケットの配信中にどの同時アクションも始めることができない。第３の例は、例えば、「正しく受信」と示すボタンのファシリティをユーザスクリーン及び／又は遠隔制御ファシリティに含むことである。これに関して様々な種類のユーザインタフェースが適用され得る。
【００３２】
図３は、サーバーとクライアントとの間のトラフィックにおける様々な例のプロトコルの役割を示す。図３は、サーバーとクライアントとの間のトラフィックにおける異なる交換フェーズに有用なプロトコルの幾つかの例を示す。セッション開始及び交渉フェーズ中、ＨＴＴＰ／ＴＣＰプロトコルが使用され得、交渉及び開始／コンフィギュレーションはＳＤＰを用いて交換され得、セッションコントロール及びメディアコンテンツ転送中、ＲＴＳＰ／ＴＣＰ及びＲＴＰ／ＵＤＰプロトコルが使用され得る。
【００３３】
図２に示す動作状態を参照して、モニタ（２２０）は、以下のアルゴリズム（これらアルゴリズムは例に過ぎない）に従って、図２に示す様々なウィンドウ境界に対する様々なポインタを更新する。
【００３４】
ＡＣＫ_Ｎの受信の際
位置ＮにＡＣＫポインタを１だけインクリメントする
位置Ｎ＋Ｗにクレジットウィンドウポインタを１だけインクリメントする
位置ＮにＳｕｃｃｅｓｓｆｕｌと印を付ける
ＡＣＫ_Ｎ＋Ｐ，Ｐ＞０
位置Ｎ＋Ｗにクレジットウィンドウポインタを１だけインクリメントする
位置Ｎ＋ＰにＳｕｃｃｅｓｓｆｕｌと印を付ける
ｐ＝０乃至Ｐ−１に対して
パケットＮ＋ｐの再送信デッドラインが経過した場合、
位置Ｎ＋ｐ（前記した通り、本例では再送信デッドラインにおける単調な増加を仮定する）にＡＣＫポインタをインクリメントする
位置Ｎ＋ｐにＵｎｓｕｃｃｅｓｓｆｕｌと印を付ける
さもなければ（パケットＮ＋ｐの再送信デッドラインがまだ経過していない場合）
パケットＮ＋ｐを再送信する（再送信はタイム・アウトのような他の機構によって始動されてもよく、同様にして再送信は一つ以上のＡＣＫ_Ｎ＋Ｐ，Ｐ＞０の受け取りを要求し得る）
ＡＣＫ_Ｎ−Ｍ，Ｍ＞０の受け取りの際
位置Ｎ−ＭがＵｎｓｕｃｃｅｓｓｆｕｌと印が付けられた場合
位置Ｎ−ＭにＳｕｃｃｅｓｓｆｕｌと印を付ける
位置Ｎ＋Ｗにクレジットウィンドウポインタを１だけインクリメントする
パケットは通常のペースで送信され、即ち、パケット送信ポインタは通常のペースで１だけインクリメントされ、トランジットウィンドウを開ける。パケットは、トランジット及びクレジットウィンドウの両方にある場合に送信される。通常の動作では、図２に説明したように、パケットＮ＋Ｔはその送信時間が経過すると送られる。さもなければ、送信時間が経過したがその送信デッドラインが経過していない場合、パケットは、そのパケットを含むようクレジットウィンドウが開くと送られる。原則として送信デッドラインが経過した場合、パケットはＵｎｓｕｃｃｅｓｓｆｕｌと印が付けられる。このような情況では、送信全体は中断されると考えられる。
【００３５】
クレジットウィンドウＷの大きさに関して、オープンＡＣＫコードの数、即ち、クライアントによって受け取りがまだ確認されていないデータパケットに対して、ある数の（更なる）ＡＣＫが受信された場合、又は、データパケットがある期間にわたって送信され受信された場合にインクリメントされるよう設定され得る。反対に、クレジットウィンドウは送信が円滑に行われていない場合デクリメントされ得る。
【００３６】
支払いはＳｕｃｃｅｓｓｕｆｕｌカウントの数に従う。Ｔの選択は、損失したパケットの再送信が所与のデッドライン内で行われ得るよう選択される。Ｗの選択は、トランザクションが受け入れるであろうクレジットに依存する。Ｗは、送信されたパケットの合計と比べて小さい、即ち、重要でない。
【００３７】
クライアントによるＡＣＫの抑制はクレジットウィンドウＷを閉じさせる。結果的に送信は停止される。エラーを起こしやすい送信チャネルにおいて、パケットが受信されていないか、又は、そのＡＣＫが損失したため、ＡＣＫは受信されない。これは、クレジットウィンドウが開くことを禁止する。更に、再送信デッドラインが非常に重要である場合、クライアントが受信する全てのパケットを確認しても送信は停止され得る。
【００３８】
受信においてクライアントが経験する関連する歪みのため、損失は望ましくない。損失の持続によりウィンドウが閉じることは、Ｔと比べてＷのよく大きさが決められた選択によって避けられ得る。持続損失率は、接続の確立中に交渉フェーズにおいて避けられ得る。例えば、クライアントとサーバーがｅ％といった許容可能な損失に同意すると仮定する。更なる余分のパケットの可能な送信とは別に、Ｕｎｓｕｃｃｅｓｆｕｌと印が付けられた百／ｅ（ｅ％の逆数）パケット毎に１つだけクレジットウィンドウポインタはインクリメントされ（Ｓｕｃｃｅｓｓｆｕｌと再び印が付けられたパケットに対して補正される）。
【００３９】
クライアントによるマスクリーディングは、サーバーがデータパケットと共にいわゆる「チャレンジ」をクライアントに送ることで、及び、クライアントがこれに対する応答を確認応答コードのリターントラフィックと共に返すことで防止され得る。
【００４０】
本発明は、コンピュータプログラム、特に、本発明を実施するために適合される担体のコンピュータプログラムも含む。プログラムは、ソースコード、オブジェクトコード、部分的にコンパイルされた形態にあるコード中間ソース及びオブジェクトコード、又は、本発明によるプロセスの実行において使用するに好適な任意の他の形態でもよい。担体は、任意のエンティティ又はプログラムを行うことができる装置を有してもよい。
【００４１】
担体は、ＲＯＭ、例えば、ＣＤ−ＲＯＭ若しくは半導体ＲＯＭのような記憶媒体、又は、例えば、フレキシブルディスク若しくはハードディスクのような磁気記録媒体を有してもよい。更に、担体は、電気或いは光ケーブルを介して、又は、無線或いは他の手段によって伝達されてもよい電気或いは光学信号のような送信可能な担体でもよい。
【００４２】
プログラムがケーブル又は他の装置若しくは手段によって直接的に伝達されてもよい信号に含まれるとき、担体は、このようなケーブル又は他の装置手段によって構成されてもよい。
【００４３】
或いは、担体は、プログラムが埋め込まれた集積回路でもよく、このとき集積回路は、関連するプロセス段階の実施又はそのプログラムにおける使用に適合される。
【００４４】
プロセスと、プロセスの構成するプロトコルと、プロセスを実行するシステム及びコンピュータプログラムは、上記したとおりに、マイクロペイメントが行われる場合に一般的に適用可能である。幾つかの適切、且つ、制限的でない例は、インターネットのような通信チャネルに接続されたダウンロード又はストリーミング能力を有する装置、例えば、ジュークボックスに関わる。上記した一般的に新規な発明の概念は、テレビジョン及びセットトップボックスとの使用にも好適となり得る。
【図面の簡単な説明】
【図１】
本発明によるプロセスの一般的な設定を示す図である。
【図２】
図１によるモニタの動作を示す図である。
【図３】
サーバーとクライアントとの間のトラフィックにおけるプロトコルの役割を示す図である。

Claims

ディジタルワークのコンテンツに対して支払う必要があり、サーバーコンピュータ及びクライアント（要求側）コンピュータ（いわゆる、エンドホスト）で実行可能な、インターネットのような通信チャネル上でのディジタルワークの配信を制御するプロセスであって、
ａ）上記クライアント及び上記サーバーが上記ディジタルワークのコンテンツの配信に同意し構成する一組の交渉段階と、
ｂ）送信又はトランスポートプロトコルを用いる上記サーバーから上記クライアントへのコンテンツの上記ディジタルワークの全体的な大きさに対して上記パケットの大きさが小さく、上記クライアントが受信したコンテンツを確認するよう要求されるとして、ある期間継続する（いわゆる「ストリーミング」）パケットの通常の流れをサーバーで形成し実行する段階と、
ｃ）各確認応答コード又は幾つかの確認応答コードと支払いトークンが関連付けられ、上記クライアントから上記サーバーに少なくとも一つの確認応答コードのリターントラフィックを開始する段階と、
ｄ）上記クライアントの要求された各確認応答コードが上記サーバーによって受信されたことを上記サーバーが確認する段階と、
ｅ）上記クライアントの要求された上記確認応答コードが上記サーバーによって指定された通りに受信された場合にだけ上記サーバーが上記コンテンツのストリーミングを継続する段階と、
ｆ）クライアントによって確認された各受信パケットに対して支払う動作モードにおいて上記クライアントから受信した確認応答コードと関連付けられる支払いトークンを累積する段階と、
ｇ）少なくとも上記累積した支払いトークンに基づいて全ての受信したパケットに対する請求及び上記クライアントによる支払いを配置する段階とを有するプロセス。
段階ｃ）及びｅ）において、上記クライアントによる確認応答は、上記サーバーから上記クライアントへの順方向フローにおける少なくとも一つのパケットと関連付けられることを特徴とする、請求項１記載の通信チャネル上でのディジタルワークの配信を制御するプロセス。
段階ｅ）において、上記サーバーによるコンテンツを含むパケットのストリーミングの続きが行われ、ある数のパケットが送信される一方でクレジットウィンドウに含まれる別の所定の数の確認応答コード以下の通過中の幾つかの確認応答コードは上記サーバーによってまだ受信されていないことを特徴とする請求項１又は２記載の通信チャネル上でのディジタルワークの配信を制御するプロセス。
上記クレジットウィンドウの大きさは、上記クライアントから受信した確認応答コードの数に適合可能であることを特徴とする請求３記載の通信チャネル上でのディジタルワークの配信を制御するプロセス。
受信したリターントラフィックに基づく支払いの規制を有する、ビジネス操作又は商取引を実施することに使用される請求項１乃至４のうちいずれか一項記載のプロセス。
更に、送信速度及び／又は送信セッションの長さ及び／又は送信されたディジタルパケットの損失率に請求が依存する、ビジネス操作又は商取引を実施することに使用される請求項５記載のプロセス。
サーバーとクライアントとを有するシステムによってパケットを送信及び／又は受信する方法であって、
請求項１乃至６のうちいずれか一項記載のプロセスの少なくとも段階ｃ）を含む一つ以上の段階を有する方法。
サーバーによってパケットを送信及び／又は受信する方法であって、
請求項１乃至６のうちいずれか一項記載のプロセスの少なくとも段階ｃ）又は段階ｅ）を含む一つ以上の段階を有する方法。
クライアントによってパケットを送信及び／又は受信する方法であって、
請求項１乃至６のうちいずれか一項記載のプロセスの少なくとも段階ｃ）又は段階ｅ）を含む一つ以上の段階を有する方法。
確認応答コードと上記確認応答コードと関連付けられる支払いトークンに関して実施されるべき処理又は機能を定義するコードを少なくとも含む命令を有し、送信ハードウェアに接続された若しくは接続されているプログラマブル処理装置を請求項７記載の方法を実行するよう動作可能にさせる、コンピュータプログラム。
確認応答コードと上記確認応答コードと関連付けられる支払いトークンに関して実施されるべき処理又は機能を定義するコードを少なくとも含む命令を有し、送信ハードウェアに接続された若しくは接続されているプログラマブル処理装置を請求項８記載の方法のサーバーに関連する段階を実行するよう動作可能にさせる、コンピュータプログラム。
確認応答コードと上記確認応答コードと関連付けられる支払いトークンに関して実施されるべき処理又は機能を定義するコードを少なくとも含む命令を有し、送信ハードウェアに接続された若しくは接続されているプログラマブル処理装置を請求項９記載の方法のクライアントに関連する段階を実行するよう動作可能にさせる、コンピュータプログラム。
記憶媒体を有する担体で又は担体における請求項１０乃至１２のうちいずれか一項記載のコンピュータプログラム。
電気的又は光学的信号のような送信可能な担体で又は担体における請求項１０乃至１２のうちいずれか一項記載のコンピュータプログラム。
請求項１０乃至１２のうちいずれか一項記載のコンピュータプログラムがコンポーネントとなる送信エンティティ。
ディジタルワークのコンテンツに対して支払う必要があり、サーバーコンピュータ及びクライアント（要求側）コンピュータで動作可能な、インターネットのような通信チャネル上でのディジタルワークの配信を制御するシステムであって、
ディジタルワークを記憶し交換する一つ以上のリポジトリを有し、上記各ディジタルリポジトリは、
ディジタルワーク、及び、上記ディジタルワークに関連する使用権利を記憶する記憶手段と、
要求が使用権を特定し、上記使用権に支払いトークンが付けられているとして、ディジタルワークへのアクセスを要求する要求側動作モードと、要求で特定された上記使用権及び上記ディジタルワークに関連付けられた使用権に基づいて上記要求されたディジタルワークをアクセスする要求を処理するサーバー動作モードとを有するトランザクション処理手段と、
請求項１乃至６のうちいずれか一項記載のプロセスを行うのに適切なプロトコルの下で動作可能な、上記サーバーから上記要求側にディジタルワークを送信する送信手段とを有する、システム。