JP4690075B2 - サービスプロバイダとサービス利用者の間の争いを解決する方法およびシステム - Google Patents

Description

本発明は、一般に、サービスプロバイダによって提供される否認不能な証拠に基づくサービスプロバイダとサービス利用者との間の争いの解決に関する。

様々なサービスが、インターネットを介してサービスプロバイダから入手可能である。例えば、一部のサービスプロバイダは、地図情報、気象情報、株価情報などを提供する。サービス利用者（ｃｏｍｓｕｍｅｒ）（例えばパーソナルコンピュータ）は、サービスに関する要求をサービスプロバイダのウェブサーバに送信する。ウェブサーバは、サービスを実行し（例えば、要求された情報を検索し）、ウェブページを介して要求元のサービス利用者にサービスの結果を提供する。これらのサービスプロバイダの多くが、サービスをサービス利用者に無料で提供する。しかし、サービスプロバイダは、通常、サービス利用者によって要求された情報を提供するウェブページ上の広告スペースを売ることにより収入を得る。

コンピューティング装置が小さくなるにつれて、情報を表示する画面が小さくなる。例えば、セル電話機は、ウェブアクセスを可能にすることができるコンピューティング装置であるが、広告を含む通常のウェブページを表示できない非常に小さい画面だけを有する場合がある。したがって、セル電話機にサービスを提供するサービスプロバイダは、広告を介して収入を得ることができない可能性がある。サービスプロバイダが、そのようなコンピューティング装置にサービスを提供して収入を得られる形を有することが望ましい。

これらのコンピューティング装置は、小さくなりつつあるが、その処理能力は高まりつつある。その結果、これらのコンピューティング装置（例えば、セル電話機および携帯情報端末）は、多数の異なるアプリケーションプログラムをホストすることができる。例えば、セル電話機は、電子メール、地図情報、位置情報、カレンダリング情報などを提供するアプリケーションをホストすることができる。これらのアプリケーションは、コンピューティング装置が購入されるとき予めインストールされているか、購入後にユーザによってインストールされる場合がある。例えば、セル電話機ユーザが、現在位置の地図をセル電話機画面に表示することを望む場合がある。地図アプリケーションがプリインストールされていない場合に、セル電話機ユーザは、インターネットから地図アプリケーションをダウンロードし、セル電話機にインストールすることができる。地図アプリケーションは、位置サービスプロバイダおよび地図サービスプロバイダのサービスを使用することを必要とする場合がある。地図アプリケーションは、位置サービスプロバイダを使用して、セル電話機の近くの様々なセルからの読み取りに基づくセル電話機の現在位置を識別することができる。その現在位置を地図サービスプロバイダに提供し、ユーザに表示される適当な地図を入手することができる。

そのようなコンピューティング装置でのアプリケーションの使用に関して、複数の問題に遭遇する可能性がある。問題の１つは、サービスプロバイダが使用する広告収入モデルが、そのようなコンピューティング装置の使用と共にうまく働かない可能性があることである。解決策の１つは、サービスプロバイダが、要求されるサービスごとに料金を請求することである。例えば、位置サービスプロバイダは、要求される位置ごとに０．０２ドルを請求することができる。しかし、位置サービスプロバイダが、要求されたサービスごとにクレジットカードに請求することは、請求のトランザクション費用が高すぎるので、非実用的である。位置サービスプロバイダは、サービス利用者に関する料金を集計し、毎月１回だけクレジットカードに請求することができる。しかし、サービス利用者（またはコンピューティング装置のユーザ）がそのような請求について争いを起こす（ｄｉｓｐｕｔｅ）費用効率の良い形はない。例えば、集計された料金が１０ドルである場合があるが、この金額は、争いを解決するのに必要なクレジットカード会社による調査のトランザクション費用に見合わない。そのような争いを自動的に解決する形を有することが望ましい。

争いの解決にトランザクション費用が絡まない場合であっても、料金の集計は、依然としてサービスプロバイダに対して不利益を与える。具体的に言うと、不利益の１つは、サービスプロバイダが、サービス利用者による不払いに曝される危険を冒すことである。サービスプロバイダは、サービス利用者のクレジットカード番号を有する場合であっても、例えばカード保有者が最近にクレジットカードを取り消したので、請求が断られる可能性がある。そのような不払いに曝されることを抑制するため、サービスプロバイダは、クレジットカードに対しより頻繁に請求することを望む可能性がある。しかし、そのような頻繁な請求から被る不利益は、各請求が、請求額より高い可能性がある最低限のトランザクション費用を有する可能性があることである。サービスプロバイダが、不払いに曝されることと、サービスに関する請求のトランザクション費用との間の許容可能なバランスを指定できるようにすることが望ましい。

そのようなコンピューティング装置の使用に伴うもう１つの問題は、コンピューティング装置にダウンロードされ、インストールされるアプリケーションが、正しく振る舞わない場合があることである。例えば、アプリケーションに、１０秒ごとに位置サービスプロバイダに位置情報を要求するウィルスが含まれる場合がある。そのような要求は、位置サービスプロバイダがその月のサービス料でサービス利用者に５０００ドル以上を請求することを示すクレジットカード明細書が受け取られるまで、サービス利用者に分からない可能性がある。そのようなアプリケーションが正しく振る舞っていないか否かを自動的に検出する形を有することが望ましい。さらに、サービスプロバイダが、挙動の履歴に基づいて、あるアプリケーションが信頼に値するか否かを示し、その結果、サービス利用者が、そのようなアプリケーションのインストールに関してより確かな裏付けに基づく判断を行えるようにすることが望ましい。

一般に、サービスプロバイダがサービスを提供し、サービス利用者が、参加者（すなわち、サービスプロバイダ、サービス利用者、アプリケーション、およびその作成者）が信頼できない場合がある環境においてさまざまなアプリケーションを使用する、費用効率の良い形を有することが望ましい。

本発明の目的は、サービスプロバイダがサービス利用者にサービスを提供でき、サービスが受け取られたことの否認不能な証拠を有するサービスを提供する機構を提供する争いを解決するシステムを提供することである。

一実施形態において、サービス利用者は、まず、サービス利用者とサービスプロバイダの両方によって信頼されるサービス仲介（ｓｅｒｖｉｃｅ ｉｎｔｅｒｍｅｄｉａｒｙ）に、コードのシーケンスの終了コードを登録する。コードのシーケンスは、開始コードから始め、終了コードで終わることによって、前のアプリケーションによって生成されたコードに１方向関数を連続して適用することによって生成される。サービス仲介は、終了コードをサービスプロバイダに提供する。サービス利用者は、終りから２番目のコードから始めて、生成と逆の順序で選択された各要求にコードを含むサービスプロバイダに、サービスの要求を送信する。サービスプロバイダは、要求を受信するとき、要求のコードに１方向関数を適用して、それが終了コードの導出に使用できるかどうかを調べることができる。そうである場合には、サービスプロバイダは、サービスの実行をサービス利用者によって要求されたことの否認不能な証拠として、そのコードをサービス仲介に提供することができる。

サービスプロバイダがサービス利用者によって要求されたサービスを提供したことを、サービスプロバイダがサービス仲介に実証することができる、サービスプロバイダにサービスを提供するように要求する争いの解決の方法およびシステムを提供する。一実施形態において、サービスプロバイダのサービスを要求することの開始を望むサービス利用者は、サービス仲介に終了コードを登録する。終了コードは、開始コードに１方向関数を適用することによって生成されるコードのシーケンスの最後のコードを表す（１方向関数とは、計算が比較的簡単であるが、逆を計算するのが比較的困難な関数である）。１方向関数を適用することによって、開始コードから始まり終了コードで終り、その間にある個数の中間コードがある、コードのシーケンスが生成される。サービス利用者の登録を受信したとき、サービス仲介は、終了コードをサービスプロバイダに提供する。サービス利用者は、サービスプロバイダへのサービス提供の要求を開始することができる。サービス利用者がサービスプロバイダに送信する各要求に、生成と逆の順序のシーケンスのコードが含まれる。この関数は１方向なので、サービスプロバイダが、サービス利用者から受信したものより開始コードに近いコードを生成するために逆関数を適用することは、非実用的である。したがって、サービスプロバイダが、シーケンスのコードを有する場合、そのコードを、それがサービス利用者から受信されたことの否認不能な証拠と見なすことができる。さらに、１方向関数は、計算が比較的簡単なので、サービスプロバイダは、その関数を適用して終了コードを正しく導出することができるか否かを判定することによって、サービス利用者から受信したコードがシーケンスの有効なコードであるか否かを簡単に検証することができる。したがって、サービスプロバイダは、要求を受信するとき、サービスを提供する前に、要求のコードを使用して終了コードを導出することができることを検証する。検証が成功である場合に、サービスプロバイダは、要求されたサービスをサービス利用者に提供する。サービスプロバイダは、検証されたコードが受信される前にサービス利用者が要求したサービスのすべてを提供したことの否認不能な証拠として、検証されたコードを用いることができる。検証が不成功の場合には、サービスプロバイダは、サービス利用者がそのサービスを要求したことの否認不能な証拠を有しないので、サービスの提供を断ることができる。サービス利用者が、要求したサービスを提供されないか、提供されたサービスに満足しない場合に、サービス利用者は、そのサービスプロバイダにそれ以上サービスを要求する必要がない。その場合には、サービスプロバイダは、サービス利用者がそれに関して提供されたサービスに満足しなかった第１の要求の際に受信した要求のコード（すなわち、否認不能な証拠）だけを有する。この形で、サービスプロバイダは、否認不能な証拠を有することを保証でき、サービス利用者は、提供されたサービスに満足しないとき、必ず、サービスの要求を停止することができる。

コードを受信した後に、サービスプロバイダは、提供したサービスについてサービス利用者に請求することができる。請求は、クレジットカードサービスなどの第三者の金融エンティティに提出することができる。サービス利用者が、請求について争いを起こす場合、サービスプロバイダまたはサービス利用者の一方が誤っている（実際には、ある情況で両方が誤っている場合がある）。争いは、サービス仲介によって解決され、サービス仲介は、金融エンティティと提携することができる。サービス仲介は、争いの指標を受信する場合、サービスプロバイダが請求されるサービスを提供したことの否認不能な証拠として、サービス利用者から受信したコードを提供するようにサービスプロバイダに要求することができる。サービス仲介は、サービスプロバイダからコードを受信する場合、１方向関数を用いて、受信したコードから始めて登録時にサービス利用者によって提供された終了コードを正しく導出することができるか否かを判定することができる。終了コードを正しく導出でき、１方向関数の適用の回数が請求されるサービスとの一貫性を有する（例えば、各アプリケーション、したがって各コードが、１つのサービスに対応することができる）場合、サービス仲介は、サービスプロバイダを争いの勝者と宣言する。サービスプロバイダによって受信されたコードの数が、サービス利用者に提供されたサービスの回数を表す。したがって、サービス利用者が、１０回のサービスについて請求される場合に、サービスプロバイダは、終了コードを導出する前に導出される必要がある少なくとも９つのコードを提供する必要がある。サービス仲介は、開始コードから始めて、提供されたコードで停止するコードを導出することによって、または提供されたコードから開始し、終了コードで終了することによって、提供されたコードを検証することができる。どちらの場合でも、生成されるコードの個数が、サービスプロバイダが提供したことを実証できるサービスの回数を表す。提供されたコードを検証できない場合には、サービス仲介は、サービス利用者を勝者と宣言することができる。したがって、サービス仲介は、自動的に低費用で（すなわち、人間の介入なしで）争いを解決することができる。

一実施形態において、サービス仲介は、まず、１方向関数の適用以外の方法を使用して、争いの解決を試みる。１方向関数の適用は、その逆と比較したとき、計算が比較的簡単ではあるが、頻繁な適用は実用的でなく、計算費が高くつく可能性がある。例えば、サービス仲介は、毎日数千件の争いを解決する可能性がある。サービス仲介は、まず、サービスプロバイダとサービス利用者の両方に、請求されたサービスに対応するコードを提供するように求めることによって争いの解決を試みることができる。コードが同一である場合に、サービス利用者が正しい否認不能な証拠と認めるコードをサービスプロバイダが提供したので、サービス仲介は、サービスプロバイダを勝者と宣言する。しかし、コードが同一でない場合には、サービスプロバイダまたはサービス利用者のいずれかが誤っている（あるいは両方が誤っている可能性がある）。その場合に、サービス仲介は、１方向関数を適用して、サービスプロバイダまたはサービス利用者によって提供されたコードのどちらが正しいかを判定する。サービス仲介は、正しいコードを提供したものを勝者と宣言する。サービスプロバイダおよびサービス利用者の両方が正しいコードを提供しない場合には、サービス仲介は、両方が不正な情報を提供しているので、争いを解決できないと宣言する。その代わりに、サービス仲介は、サービスプロバイダがその請求を支持する証拠を提供できないので、サービス利用者を勝者と宣言することができる。

争いを解決するとき使用されるさらなる証拠として、サービスプロバイダは、要求されたサービスを提供するとき、サービス利用者にサービスのコードを提供することができる。サービスプロバイダは、サービスのコードのシーケンスを生成し、サービス仲介に登録することができる。サービス仲介は、終了コードをサービス利用者に提供することができる。サービスプロバイダは、各サービス要求に応答して、生成と逆の順序でこのコードをサービス利用者に提供することができる。争いを解決するとき、サービス仲介は、サービスプロバイダおよびサービス利用者に、サービスプロバイダおよびサービス利用者の両方によって生成された対応するコードを提供するように求めることができる。サービス仲介は、サービス利用者のコードを検証するのとほぼ同一の形でこれらのコードを検証することができる。サービスプロバイダが、正しいサービス利用者コードおよび正しいサービスプロバイダコードを提供する場合に、サービス仲介は、サービスプロバイダを勝者と宣言する。サービスプロバイダが、不正なサービス利用者コードを提供し、サービス利用者が、両方のコードを正しく提供する場合に、サービス仲介は、サービス利用者を勝者と宣言する。そうでない場合に、サービス仲介は、両方の当事者が、不正であることが分かった証拠を提供したので、争いを解決できないと宣言することができる。サービスプロバイダによって生成されるコードの使用は、争いの解決が証拠との一貫性を有することを検証するもう１つのレベルを提供する。

当業者は、この争いを解決するシステムのさまざまな変形形態が可能であることを理解するであろう。例えば、サービス仲介が、サービス利用者のためにコードを生成し、これをサービス利用者に提供し、サービスプロバイダのためにコードを生成し、これをサービスプロバイダに提供することができる。その代わりに、サービス仲介が、サービス利用者およびサービスプロバイダ自体のシーケンスを生成する際に使用するために、登録処理中に開始コードを選択し、これをサービス利用者およびサービスプロバイダに提供することができる。サービス利用者は、コードのシーケンスを生成する場合に、開始コード、終了コード、またはこの両方を、登録中にサービス仲介に提供することができる。サービス仲介は、開始コードだけを提供される場合に、指定された回数だけ１方向関数を適用して、終了コードを生成することができ、その終了コードをサービスプロバイダに提供することができる。サービス仲介は、終了コードを提供される場合に、その終了コードをサービスプロバイダに直接に提供することができる。サービスプロバイダが、否認不能な証拠を提供するとき、サービス仲介は、１方向関数を適用して、終了コードを導出することができるかどうかを調べることができる。サービスプロバイダが、サービスのコードを生成するとき、類似する処理を行うことができる。

当業者は、サービス利用者からサービスプロバイダにコードを送信するタイミングを変更できることも理解するであろう。例えば、サービス利用者は、サービスプロバイダが、要求されたサービスを提供した後にのみコードを提供することができる。コードは、次のサービス要求で、またはサービスが提供された直後に提供することができる。サービスプロバイダは、コードを受信しないか、コードの正しさを検証できない場合に、そのサービス利用者へのそれ以上のサービス提供を断ることができる。要求されたサービスが提供される前にコードが送信されるときは、サービス利用者は、サービスプロバイダがサービスを提供しないことのリスクをとる。対照的に、要求されたサービスが提供された後にコードが送信されるときは、サービスプロバイダが、サービス利用者がコードを送信しないことのリスクをとる。サービスプロバイダが、検証できるコードを受信するとき、そのサービスプロバイダが、そのコードを使用して、サービス利用者がサービスを要求したことを実証できることを、当業者は理解するであろう。

シーケンスの長さまたはシーケンス内のコードの数は、１つの登録に基づいて要求できるサービスの数を表す。例えば、シーケンスに１０１個のコードがある場合に、１００個のサービスを要求することができる。終了コードは、サービスの要求には使用されない。というのは、これが、サービス仲介からサービスプロバイダに直接に提供されるからである。一実施形態において、シーケンス内のコードの数は、「請求単位」を表す。請求単位は、サービスプロバイダが単一の請求トランザクションで請求できるサービスの最小個数を表す。サービスプロバイダは、サービス利用者から開始コードを受信するとき、その請求単位のすべてのサービスについてそのサービス利用者に請求することができる。サービスプロバイダは、不払い債務に曝されることおよび請求トランザクション費用の均衡を図るために、請求単位のコードの数を指定することができる。サービスプロバイダは、多数のサービスの支払いを１回でのみ要求することによって、請求トランザクション費用を減らすことを望む場合がある。要求に含まれるサービスの数が多くなるほど、請求を行う必要がある要求の数が減り、提供されるサービスごとの請求トランザクション費用が安くなる。しかし、各請求に含まれるサービスの数が増えるほど、サービスプロバイダがサービス利用者による不払いに曝されるようになる。例えば、請求単位のサービスの数が、１０００である場合に、サービスプロバイダは、サービス利用者が支払えない（例えば破産した）場合に、１０００個のサービスの不払いに曝されることのリスクをとることになる。しかし、不払いのリスクよりも、請求単位ごとの多数のサービス要求を有することによる請求トランザクション費用の潜在的な節約がまさる可能性がある。

一実施形態において、サービス利用者は、それが実行しているアプリケーションが不正に振る舞っているかどうかを検出することができる。例えば、アプリケーションは、要求することを許可される数以上のサービスを要求することを試みる場合がある。サービス利用者は、そのような不正な挙動を検出するとき、そのアプリケーションを自動的にアンインストールし、サービスプロバイダに通知することができる。サービスプロバイダは、さまざまなサービス利用者によって提供される通知を分析して、アプリケーションが実際に不正に振る舞っているかどうかを判定することができる。そうである場合に、サービスプロバイダは、アプリケーションがそのサービスプロバイダを使用することを許可されないようにすることができる。別のサービス利用者が、そのアプリケーションのインストールを試みるとき、そのサービス利用者は、サービスプロバイダを用いて、そのアプリケーションが許可されるか否かを検査することができる。許可されない場合に、サービス利用者は、そのアプリケーションのインストールを打ち切ることができる。逆に、サービスプロバイダは、多数のアプリケーションが不正に振る舞っていることの通知をあるサービス利用者が提供しているが、他のサービス利用者がそのような通知を提供していないことを検出する場合に、サービスプロバイダは、アプリケーションではなくサービス利用者が不正に振る舞っていると推論することができる。その場合に、サービスプロバイダは、サービス利用者がそのサービスプロバイダを使用する許可を取り消すことができる。この形で、サービスプロバイダは、アプリケーションに関する情報を集計して、どのアプリケーションまたはサービス利用者が不正に振る舞っているかを判定することができる。

図１は、一実施形態の争いを解決するシステムのコンポーネントを示すブロック図である。サービス利用者１０１、サービス仲介１０２、およびサービスプロバイダ１０３は、ネットワーク１０４に接続される。サービス仲介は、さまざまな周知の認証技法のいずれかを使用して、サービス利用者およびサービスプロバイダから来ると称する通信が、実際に詐称者ではなくサービス利用者またはサービスプロバイダから来たことを保証することができる。サービス利用者に、携帯情報端末、セル電話機、全地球測位システム装置、パーソナルコンピュータなどのすべてのタイプのコンピューティング装置を含めることができる。サービスプロバイダは、さまざまなサービスをサービス利用者に提供することができる。例えば、サービス利用者がセル電話機である場合に、サービスプロバイダは、現在位置を提供する位置サービスを提供することができる。

サービス利用者、サービスプロバイダ、およびサービス仲介のコンピュータシステムに、中央処理ユニット、メモリ、入力装置（例えばキーボードおよびポインティングデバイス）、出力装置（例えばディスプレイ装置）、および記憶装置（例えばディスクドライブ）を含めることができる。メモリおよび記憶装置は、生成システムを実施する命令を含むことができるコンピュータ可読媒体である。さらに、データ構造およびメッセージ構造を、通信リンク上の信号などのデータ伝送媒体を介して記憶または伝送することができる。インターネット、ローカルエリアネットワーク、広域ネットワーク、またはポイントツーポイントダイヤルアップ接続など、さまざまな通信リンクを使用することができる。

図１に、争いを解決するシステムを実施できる適切なオペレーティング環境の例を示す。このオペレーティング環境は、適切なオペレーティング環境の１つの例にすぎず、争いを解決するシステムの使用の範囲または機能性に関する制限を暗示することを意図されたものではない。使用に適する可能性がある他の周知のコンピューティングシステム、コンピューティング環境、およびコンピューティングコンフィギュレーションに、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルド装置、ラップトップ装置、マルチプロセッサシステム、マイクロプロセッサベースのシステム、プログラマブル一般電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記のシステムまたは装置のいずれかを含む分散コンピューティング環境、および類似物が含まれる。

争いを解決するシステムを、１つまたは複数のコンピュータまたは他の装置によって実行される、プログラムモジュールなどのコンピュータ実行可能な命令の全般的な文脈で説明することができる。一般に、プログラムモジュールには、特定のタスクを実行するか特定の抽象データ型を実施する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などが含まれる。通常、プログラムモジュールの機能性は、さまざまな実施形態で望み通りに組み合わせる、または分散することができる。

図２は、一実施形態の、サービス利用者、サービス仲介、およびサービスプロバイダの間の情報の流れの例を示す図である。この例では、サービスプロバイダ２０３が、サービスのコードのシーケンスを提供しない。サービス利用者２０１は、サービスプロバイダのサービスを要求することを望むとき、開始コードを選択し、その開始コードから導出されるコードのシーケンスを生成し、記憶する（ステップ１）。一実施形態において、シーケンスのコードの数を、例えばサービスプロバイダとサービス利用者との間の、サービス仲介２０２に登録された契約で、事前に定義することができる。サービス利用者は、登録要求をサービス仲介に送信する（ステップ２）。登録要求に、開始コード、終了コード、サービスプロバイダの識別、およびその下でサービスが提供される契約の識別を含めることができる。サービス仲介は、要求を検証し（例えば、サービスプロバイダおよび契約が有効であることを保証する）、サービス利用者の登録レコードを記憶することができる（ステップ３）。サービス仲介は、各登録に一意の登録番号を割り当てることができ、その結果、争われる請求を、対応する登録まで追跡できるようになる。サービス仲介は、登録の通知をサービスプロバイダに送信する（ステップ４）。この通知には、終了コード、サービス利用者の識別、および契約を含めることができる。サービスプロバイダは、通知を検証し、サービス要求の検証に使用するために通知の情報を記憶することができる（ステップ５）。サービスプロバイダは、サービス仲介に応答し、登録の通知を受け入れたことを確認する（ステップ６）。サービス仲介は、サービス利用者に応答し、登録が受け入れられたことを示す（ステップ７）。サービス利用者は、サービスプロバイダに要求を送信する（ステップ８）。各要求に、シーケンスのコードが含まれる。要求の受信時に、サービスプロバイダは、サービス利用者から前に受信した最後のコードを取り出すが、最初は、サービス仲介によって提供された終了コードを取り出す（ステップ９）。サービスプロバイダは、受信したコードに１方向関数を適用して、それが取り出されたコードと一致するか否かを判定する。そうである場合には、受信されたコードが正しいものとして検証され、サービスプロバイダは、受信したコードを記憶し（ステップ１０）、サービスを提供する。サービスプロバイダは、サービス実行の結果をサービス利用者に送信することができる（ステップ１１）。その代わりに、サービス利用者は、他のなんらかの形でサービスプロバイダがサービスを実行したことを検証することができる。例えば、サービス要求が、製品を分配するために自動販売機に許可を送信することであった場合に、ユーザは、サービスが提供されたか否かを視覚的に確認することができる。サービス利用者が要求するサービスごとに、シーケンスの所定の長さに達するまで、ステップ８から１１を繰り返す。シーケンス内のすべてのサービスが完了したとき、サービスプロバイダは、サービス利用者に請求することができる。請求に、登録の一意の識別を含めることができる。サービス利用者が、請求について争いを起こす場合に、サービスプロバイダは、それがサービスを提供したことの否認不能な証拠として、サービス利用者が提供した開始コードを用いることができる。サービスプロバイダは、開始コードを証拠としてサービス仲介に提供することができる。サービス仲介は、それを、登録時にサービス利用者が提供した開始コードと比較して、サービスプロバイダが争いに勝つか否かを判定することができる。

図３から９は、争いを解決するシステムのサービス利用者、サービス仲介、およびサービスプロバイダによって実行される処理を示す流れ図である。図示の処理では、サービスプロバイダが、それ自体のコードのシーケンスを生成しない。図３は、一実施形態の、コードのシーケンスを登録するサービス利用者のコンポーネントの処理を示す流れ図である。このコンポーネントは、サービスプロバイダの指標およびその下でサービスが要求される契約を渡すことによって呼び出すことができる。サービス利用者とサービスプロバイダの間に契約が１つしかない場合には、それを識別する必要はない。また、契約は、サービス仲介またはサービスプロバイダによって示唆することができる。ブロック３０１で、コンポーネントが、契約に基づいて要求されるサービスの数を選択する。ブロック３０２で、コンポーネントが、関数を呼び出して、選択されたサービスの数についてコードのシーケンスを生成する。ブロック３０３で、コンポーネントが、サービス仲介に登録要求メッセージを送信する。登録要求メッセージに、開始コード、終了コード、ならびにサービスプロバイダおよび契約の識別を含めることができる。ブロック３０４で、コンポーネントは、サービス仲介からの応答を待つ。判断ブロック３０５で、応答から、登録が受け入れられたことが示される場合に、コンポーネントは、ブロック３０６に継続し、そうでない場合には、このモードは、拒絶された登録を処理することによって継続する。ブロック３０６で、コンポーネントは、提供されたサービスの数を追跡する変数を初期化する。コンポーネントは、その後、完了する。

図４は、一実施形態の、シーケンスを生成するコンポーネントの処理を示す流れ図である。コンポーネントは、シーケンスによって表されるサービスの数を渡される。ブロック４０１で、コンポーネントは、シーケンスの最初のコードすなわち開始コードを識別するようにインデックスｉをセットし、開始コードをセットする。開始コードは、乱数ジェネレータによって選択することができる。シーケンスは、配列Ｓに記憶される。ブロック４０２から４０４で、コンポーネントは、コードのシーケンスを生成するために、１方向関数を適用してループする。ブロック４０２で、コンポーネントは、シーケンスの次のコードをポイントするようにインデックスを増分する。判断ブロック４０３で、インデックスがシーケンスのサービスの数より大きい場合に、コンポーネントは、シーケンスを返し、そうでない場合に、コンポーネントは、ブロック４０４に継続する。ブロック４０４では、コンポーネントが、シーケンスの前のコードに１方向関数を適用することによって生成されるコードを、シーケンス内のインデクシングされた位置に記憶する。コンポーネントは、ブロック４０２にループして、シーケンスの次のコードを生成する。

図５は、一実施形態の、サービスプロバイダにサービスを要求するコンポーネントの処理を示す流れ図である。判断ブロック５０１で、シーケンスのサービスの数が、既に要求されている場合に、コンポーネントは、サービスを要求できないという指標を返し、そうでない場合に、コンポーネントは、ブロック５０２で継続する。ブロック５０２で、コンポーネントは、要求されたサービスの数を追跡するのに使用され、要求できるサービスの数を表す変数を減らす。ブロック５０３で、コンポーネントは、シーケンスのインデクス付けされたコードを含むサービス要求メッセージをサービスプロバイダに送信し、要求が送信されたという指標を返す。

図６は、一実施形態の、サービス利用者から登録要求メッセージを受信するとき呼び出されるサービス仲介のコンポーネントの処理を示す流れ図である。コンポーネントは、サービス利用者の指標、開始コード、終了コード、サービスプロバイダ、および契約を渡される。判断ブロック６０１で、契約が、サービス利用者とサービスプロバイダの間の有効な契約を表す場合に、コンポーネントは、ブロック６０２で継続し、そうでない場合に、コンポーネントは、エラーを返し、登録が拒絶されたことをサービス利用者に通知することができる。一実施形態において、サービス利用者およびサービスプロバイダは、その契約をサービス仲介に登録することができる。契約は、シーケンスに含まれるサービスの数および、サービスプロバイダが提供されるサービスごとに請求する額などの価格設定情報を識別することができる。サービス仲介は、争いを解決するとき、登録された契約情報を用いる。ブロック６０２で、コンポーネントは、渡された情報を記憶し、その結果、争いを解決する必要があるときに用いるようにする。ブロック６０３で、コンポーネントは、サービスプロバイダに登録通知メッセージを送信する。このメッセージは、サービス利用者、契約、および終了コードを識別する。ブロック６０４で、コンポーネントは、サービスプロバイダからの確認登録メッセージを待つ。確認応答が受信されるとき、コンポーネントは、ブロック６０５で、登録が受け入れられたことを示す登録応答メッセージをサービス利用者に送信する。その後、コンポーネントは、登録が成功したという指標を返す。

図７は、一実施形態の、登録通知メッセージがサービス仲介から受信されるとき呼び出されるサービスプロバイダのコンポーネントの処理を示す流れ図である。コンポーネントは、サービス利用者の指標、契約、および終了コードを渡される。コンポーネントは、サービス利用者および契約を検証することができる。有効でない場合に、コンポーネントは、非確認応答メッセージまたは拒絶応答メッセージをサービス仲介に送信することができる。ブロック７０１で、コンポーネントは、契約からシーケンス内のサービスの数を取り出す。ブロック７０２で、コンポーネントは、最初の数からカウントダウンすることによって、要求されたサービスの数を追跡する変数をセットする。ブロック７０３で、コンポーネントは、配列Ｓに終了コードをセットし、完了する。

図８は、一実施形態の、サービス要求メッセージがサービス利用者から受信されるとき呼び出されるサービスプロバイダのコンポーネントの処理を示す流れ図である。コンポーネントは、サービス利用者の指標、契約、およびコードを渡される。コンポーネントは、コードが正しいことを検証し、正しい場合に、サービスを実行する。ブロック８０１で、コンポーネントは、サービス利用者および契約についてシーケンスで提供される残りのサービスの数の指標を取り出す。判断ブロック８０２で、提供されるサービスが残っていない場合に、コンポーネントは、エラーを返し、そうでない場合には、ブロック８０３で継続する。判断ブロック８０３では、受信したコードへの１方向関数の適用が最後に受信したコードと等しい場合に、コンポーネントは、ブロック８０４で継続し、そうでない場合には、エラーの指標を返す。ブロック８０４で、コンポーネントは、提供される残りのサービスの数を追跡する変数を減らす。ブロック８０５で、コンポーネントは、受信したコードを記憶し、渡されたコードが検証されたという指標を戻す。サービスプロバイダは、否認不能な証拠として使用される最後に提供されたコードを記憶し、受信される次のコードの正しさを検証することだけが必要である。

図９は、一実施形態の、争いを処理するサービス仲介のコンポーネントの処理を示す流れ図である。このコンポーネントは、サービス利用者が、サービスプロバイダからの請求について争いを起費用き呼び出される。このコンポーネントは、サービス利用者によって生成されたコードのシーケンスだけに基づいて争いの解決を処理する。コンポーネントは、サービス利用者の指標、サービスプロバイダ、および争われるシーケンスの登録を渡される。ブロック９０１で、コンポーネントは、サービス利用者に適当なコードを要求する。適当なコードは、サービス利用者が請求されたサービスの数を表す。ブロック９０２で、コンポーネントは、適当なコード（すなわち、否認不能な証拠）を提供するようにサービスプロバイダに要求する。判断ブロック９０３で、受信したコードが一致する場合に、コンポーネントは、サービスプロバイダを勝者と宣言し、そうでない場合には、ブロック９０４で継続する。ブロック９０４で、コンポーネントは、その登録の開始コードおよびサービスの個数を取り出す。ブロック９０５で、コンポーネントは、シーケンスのコードを生成する。判断ブロック９０６で、サービスプロバイダのコードが生成されたコードと一致する場合に、コンポーネントは、サービスプロバイダを勝者と宣言し、そうでない場合には、ブロック９０７で継続する。判断ブロック９０７で、サービス利用者のコードが生成されたコードと一致する場合には、コンポーネントは、サービス利用者を勝者と宣言し、そうでない場合には、コンポーネントは、サービス利用者とサービスプロバイダの両方が、請求されたサービスを支持するコードを提供しないので、争いを解決できないことを報告する。

一実施形態において、サービスプロバイダとサービス利用者の両方が、コードシーケンスを生成するとき、サービス仲介は、当事者の両方が正しいコードを提供するとき限って、勝者を宣言する。争いを解決するために、サービス仲介は、当事者の双方に、それぞれの立場を支持するサービスプロバイダコードおよびサービス利用者コードを提供するように要求する。サービスプロバイダによって提供されたコードが正しい場合には、サービス仲介は、サービスプロバイダを勝者と宣言する。そうではなく、サービス利用者が提供したコードの両方が正しい場合に、サービス仲介は、サービス利用者を勝者と宣言する。それ以外のすべての場合に、両方の当事者が、少なくとも１つの不正なコードを提供しており、サービス仲介は、勝者なしと宣言する。

図１０は、一実施形態の、サービス利用者のコンポーネントを示すブロック図である。サービス利用者１０００には、サービス利用者コードコンポーネント１００１、ランタイムコンポーネント１００２、アプリケーション１００３、コードストア１００４、契約ストア１００５、およびアプリケーションストア１００６が含まれる。サービス利用者コードコンポーネントは、シーケンスを生成し、そのシーケンスをサービス仲介に登録する責任を負う。ランタイムコンポーネントは、アプリケーションがそれを介してサービスプロバイダにアクセスできる環境をアプリケーションに提供する責任を負う。ランタイムコンポーネントは、その許可を超えてサービスを要求するアプリケーションがアンインストールされるステップと、対応する通知がサービスプロバイダに送信されるステップを保証する。コードストアに、登録に関する情報が含まれる。各エントリは、サービスプロバイダ、契約、シーケンス、および各登録されたシーケンスのシーケンスへの現在のインデックスを識別する。契約ストアには、サービス利用者の契約を記述する情報が含まれる。契約ストアの各エントリは、サービスプロバイダおよび契約条件を識別する。アプリケーションストアには、各アプリケーションのサービスの限度を記述した情報が含まれる。アプリケーションストアの各エントリは、アプリケーション、サービスプロバイダ、許可される限度、およびそのサービスの現在の使用量を識別することができる。

図１１は、一実施形態の、サービス利用者のユーザが、アプリケーションに関する許可される限度を確立する方法を示すディスプレイ記述である。ディスプレイ記述１１００に、アプリケーション名１１０１および許可テーブル１１０２が含まれる。許可テーブルには、サービスプロバイダの列、累積限度の列、許可される限度の列、および期間の列が含まれる。サービスプロバイダの列は、アプリケーションがアクセスを許可されるサービスプロバイダを識別する。累積限度は、すべてのアプリケーションにまたがって許可された、そのサービスプロバイダへのサービス要求の総数を指定する。許可限度は、アプリケーションがサービスプロバイダに要求することを許可されるサービス要求の数を示す。例えば、このテーブルの最初の行は、アプリケーションが位置サービスプロバイダを使用することを必要とすること、グループとしてのアプリケーションが毎月５００回のサービスを要求することを許可されていること、およびこのアプリケーションが毎月５０回までのサービスを要求することを許可されることを示す。このディスプレイ画面からの情報は、アプリケーションストアに記憶される。

図１２は、一実施形態の、ランタイムコンポーネントのインストールサブコンポーネントの処理を示す流れ図である。ブロック１２０１で、コンポーネントは、アプリケーションから許可情報を取り出す。アプリケーション情報は、アプリケーションの秘密鍵を使用して暗号化されたアプリケーション名とすることができる。コンポーネントは、アプリケーションの公開鍵を使用して、名前を暗号化解除することができる。判断ブロック１２０２で、コンポーネントが、アプリケーションが真である（例えば、名前が正しく暗号化解除される）と判定する場合に、コンポーネントはブロック１２０３で継続し、そうでない場合には、コンポーネントは、ブロック１２０８に継続して、インストールを打ち切り、完了する。ブロック１２０３から１２０７では、コンポーネントは、ループして、サービス利用者が、アプリケーションが必要とするサービスプロバイダに加入しているかどうかを判定する。ブロック１２０３で、コンポーネントは、アプリケーションに、それが必要とする次のサービスプロバイダを尋ねる。判断ブロック１２０４で、アプリケーションが、別のサービスプロバイダを必要とすると示す場合に、コンポーネントは、ブロック１２０５に継続し、そうでない場合には、ブロック１２０９に継続する。判断ブロック１２０５で、サービス利用者が、そのサービスプロバイダに加入している場合には、コンポーネントは、ブロック１２０６で継続し、そうでない場合には、サービス利用者はそのアプリケーションをサポートできず、ブロック１２０８でインストールを打ち切り、完了する。ブロック１２０６で、コンポーネントは、アプリケーションがそのサービスプロバイダの使用を許可されるかどうかをサービスプロバイダに尋ねる。判断ブロック１２０７で、アプリケーションが許可される場合に、コンポーネントはブロック１２０３にループして、必要な次のサービスプロバイダについてアプリケーションに尋ね、そうでない場合には、コンポーネントは、ブロック１２０８でインストールを打ち切り、完了する。ブロック１２０９で、サービス利用者は、アプリケーションが必要とするすべてのサービスプロバイダを提供することができ、コンポーネントは、図１１のディスプレイ記述を使用して、各サービスプロバイダのサービス許可限度を入力する。ブロック１２１０で、コンポーネントは、アプリケーションのインストールに進み、完了する。

図１３は、一実施形態の、サービスプロバイダにサービス実行を要求するランタイムコンポーネントのサブコンポーネントの処理を示す流れ図である。ブロック１３０１で、コンポーネントが、アプリケーションストアからアプリケーションデータを取り出す。判断ブロック１３０２で、サービスの要求が、そのサービスプロバイダに関するアプリケーションの許可限度を超える場合に、コンポーネントは、ブロック１３０５で継続し、そうでない場合にはブロック１３０３で継続する。ブロック１３０３で、コンポーネントが、アプリケーションストアのアプリケーションデータを更新して、サービスの使用量の増加を示す。ブロック１３０４で、コンポーネントが、シーケンスの次のコードを含む要求をサービスプロバイダに送信する。その後、コンポーネントは完了する。ブロック１３０５で、コンポーネントは、アプリケーションが不正に振る舞っていることのレポートをサービスプロバイダに送信する。ブロック１３０６で、コンポーネントは、アプリケーションをアンインストールし、完了する。

当業者は、説明した技法の多数の変形形態が可能であることを理解するであろう。例えば、サービス利用者は、サービスのシーケンスを要求したいとき、公開鍵／秘密鍵対を生成することができる。サービス利用者は、公開鍵をサービス仲介に登録し、サービス仲介は、公開鍵をサービスプロバイダに提供する。サービス利用者は、サービス要求を送信するとき、秘密鍵を用いて暗号化されたシーケンス番号を含ませられる。サービスプロバイダは、要求を受信するとき、公開鍵を使用してシーケンス番号を暗号化解除し、それが正しいことを検証する。そうである場合に、サービスプロバイダは、暗号化されたシーケンス番号を否認不能な証拠として使用することができる。

当業者は、サービス利用者が、それが要求し、ある個数のサービスを提供されたことの否認不能な証拠として、サービスプロバイダが生成し、サービスプロバイダが提供したコードを使用できることも理解するであろう。そのような証拠は、例えば、サービス利用者が、ある最小の数のサービスを要求する場合に値引きを受けるとき、有用になる可能性がある。

当業者は、ランタイム環境が、アプリケーションが不正に振る舞っているか否かを判定するために、多数の異なる技法を使用できることも理解するであろう。例えば、ランタイム環境は、不正な振る舞いの指標として、アプリケーションが、タスクの実行に時間がかかり過ぎる（例えば無限ループの）場合、または、あまりに頻繁にサービスを要求する場合などを検出することができる。ランタイム環境は、ユーザがアプリケーションの動作に満足しているか否かに関する入力も受け取ることができる。ランタイム環境は、これらの不正な振る舞いをさまざまなサービスプロバイダに報告することができ、その結果、サービスプロバイダは、複数のサービス利用者からのレポートを集計して、アプリケーションが不正に振る舞っているか否かの正確な査定を提供できるようになる。

前述から、本発明の特定の実施形態を例示のために説明したが、本発明の趣旨および範囲から逸脱せずに、さまざまな変更を行えることを理解されたい。用語「サービス」に、サービスプロバイダに要求できるすべての種類のアクションが含まれることを、当業者は理解するであろう。例えば、アクションに、ユーザへの物理的製品または電子製品の販売（例えば音楽ＣＤ）、自動販売機での製品の分配、電話番号の突き止め、支払いの許可、家庭の電灯のリモートコントロール、ビデオのストリーミングなどを含むことができる。したがって、本発明は、請求項によってのみ限定される。

一実施形態の争いを解決するシステムのコンポーネントを示すブロック図である。 一実施形態の、サービス利用者、サービス仲介、およびサービスプロバイダの間の情報の流れの例を示す図である。 一実施形態の、コードのシーケンスを登録するサービス利用者のコンポーネントの処理を示す流れ図である。 一実施形態の、シーケンスを生成するコンポーネントの処理を示す流れ図である。 一実施形態の、サービスプロバイダにサービスを要求するコンポーネントの処理を示す流れ図である。 一実施形態の、サービス利用者から登録要求メッセージを受信するとき呼び出されるサービス仲介のコンポーネントの処理を示す流れ図である。 一実施形態の、登録通知メッセージがサービス仲介から受信されるとき呼び出されるサービスプロバイダのコンポーネントの処理を示す流れ図である。 一実施形態の、サービス要求メッセージがサービス利用者から受信されるとき呼び出されるサービスプロバイダのコンポーネントの処理を示す流れ図である。 一実施形態の、争いを処理するサービス仲介のコンポーネントの処理を示す流れ図である。 一実施形態の、サービス利用者のコンポーネントを示すブロック図である。 一実施形態の、サービス利用者のユーザが、アプリケーションに関する許可される限度を確立する方法を示すディスプレイ記述である。 一実施形態の、ランタイムコンポーネントのインストールサブコンポーネントの処理を示す流れ図である。 一実施形態の、サービスプロバイダにサービス実行を要求するランタイムコンポーネントのサブコンポーネントの処理を示す流れ図である。

符号の説明

１１００ ディスプレイ記述
１１０２ 許可テーブル

Claims (14)

1. サービスプロバイダが、サービス利用者によって要求されたサービスを提供したことをサービス仲介者が判定することができるコンピュータ間でのサービスの提供を要求する方法であって、
   前記サービス利用者が使用するサービス利用者側コンピュータが、開始コードから終了コードまでのコードのシーケンスを前記開始コードに関数を適用することにより生成するステップと、
   前記サービス利用者側コンピュータが前記終了コード及び前記関数をサービス仲介サーバに登録するステップと、
   前記サービス仲介サーバが、前記サービスプロバイダが使用するサービスプロバイダ側コンピュータに前記終了コードを提供するステップと、
   前記サービス利用者側コンピュータが、前記サービスプロバイダ側コンピュータにサービスを１つ要求する毎に、前記サービス利用者側コンピュータが前記サービスプロバイダ側コンピュータに、生成と逆の順序でコードを１つ提供するステップと、
   前記サービスプロバイダ側コンピュータが、要求と共に提供された前記コードから前記終了コードを導出することができることを検証できる場合、前記サービス利用者側コンピュータに前記要求されたサービスを提供するステップと、
   前記サービス利用者側コンピュータが前記サービスプロバイダ側コンピュータに最後に提供したサービス利用者側コードを前記サービス仲介サーバに提供するステップと、
   前記サービスプロバイダ側コンピュータが前記サービス利用者側コンピュータから最後に提供されたサービスプロバイダ側コードを前記サービス仲介サーバに提供するステップと、
   前記サービス利用者側コードと前記サービスプロバイダ側コードとが同じ場合、前記サービス仲介サーバが、前記サービスプロバイダ側コンピュータから前記サービス利用者側コンピュータにサービスが提供されたと判定するステップと、
   前記サービス利用者側コードと前記サービスプロバイダ側コードとが異なる場合、前記サービス仲介サーバが、前記サービスプロバイダ側コードを前記関数に適用して生成された最終コードが、前記登録された最終コードと同じとき、前記サービスプロバイダ側コンピュータから前記サービス利用者側コンピュータにサービスが提供されたと判定し、前記登録された最終コードと異なるとき、前記サービスプロバイダ側コンピュータから前記サービス利用者側コンピュータにサービスが提供されなかったと判定するステップと、
   を含むことを特徴とする方法。
2. 前記登録するステップは、前記サービス利用者側コンピュータが前記終了コード及び前記関数に加えて前記開始コードを前記サービス仲介サーバに登録することを含むことを特徴とする請求項１に記載の方法。
3. 前記サービス利用者側コンピュータは、最後に要求したサービスが前記サービスプロバイダ側コンピュータによって提供された後に、次のサービスの提供を前記サービスプロバイダ側コンピュータに要求することを特徴とする請求項１に記載の方法。
4. 前記サービス利用者側コンピュータは、入力された前記開始コードを一方向関数に適用することによって前記シーケンスを生成することを特徴とする請求項１に記載の方法。
5. 前記シーケンスは、長さを有することを特徴とする請求項１に記載の方法。
6. 前記長さは、前記サービスプロバイダ側コンピュータおよび前記サービス利用者側コンピュータによって合意されることを特徴とする請求項５に記載の方法。
7. 前記サービス仲介サーバは、前記長さを前記サービスプロバイダ側コンピュータに提供することを特徴とする請求項５に記載の方法。
8. サービスプロバイダが、サービス利用者によって要求されたサービスを提供したことをサービス仲介者が判定することができるコンピュータ間でのサービスの提供を要求する方法をコンピュータに実行させるためのプログラムを記録したコンピュータ読取り可能な記録媒体であって、前記方法が、
   前記サービス利用者が使用するサービス利用者側コンピュータが、開始コードから終了コードまでのコードのシーケンスを前記開始コードに関数を適用することにより生成するステップと、
   前記サービス利用者側コンピュータが前記終了コード及び関数をサービス仲介サーバに登録するステップと、
   前記サービス仲介サーバが、前記サービスプロバイダが使用するサービスプロバイダ側コンピュータに前記終了コードを提供するステップと、
   前記サービス利用者側コンピュータが、前記サービスプロバイダ側コンピュータにサービスを１つ要求する毎に、前記サービス利用者側コンピュータが前記サービスプロバイダ側コンピュータに、生成と逆の順序でコードを１つ提供するステップと、
   前記サービスプロバイダ側コンピュータが、要求と共に提供された前記コードから前記終了コードを導出することができることを検証できる場合、前記サービス利用者側コンピュータに前記要求されたサービスを提供するステップと、
   前記サービス利用者側コンピュータが前記サービスプロバイダ側コンピュータに最後に提供したサービス利用者側コードを前記サービス仲介サーバに提供するステップと、
   前記サービスプロバイダ側コンピュータが前記サービス利用者側コンピュータから最後に提供されたサービスプロバイダ側コードを前記サービス仲介サーバに提供するステップと、
   前記サービス利用者側コードと前記サービスプロバイダ側コードとが同じ場合、前記サービス仲介サーバが、前記サービスプロバイダ側コンピュータから前記サービス利用者側コンピュータにサービスが提供されたと判定するステップと、
   前記サービス利用者側コードと前記サービスプロバイダ側コードとが異なる場合、前記サービス仲介サーバが、前記サービスプロバイダ側コードを前記関数に適用して生成された最終コードが、前記登録された最終コードと同じとき、前記サービスプロバイダ側コンピュータから前記サービス利用者側コンピュータにサービスが提供されたと判定し、前記登録された最終コードと異なるとき、前記サービスプロバイダ側コンピュータから前記サービス利用者側コンピュータにサービスが提供されなかったと判定するステップと、
   を含むことを特徴とするコンピュータ読取り可能な記録媒体。
9. 前記登録するステップは、前記サービス利用者側コンピュータが前記終了コード及び前記関数に加えて前記開始コードを前記サービス仲介サーバに登録することを含むことを特徴とする請求項８に記載のコンピュータ読取り可能な記録媒体。
10. 前記サービス利用者側コンピュータは、最後に要求したサービスが前記サービスプロバイダ側コンピュータによって提供された後に、次のサービスの提供を前記サービスプロバイダ側コンピュータに要求することを特徴とする請求項８に記載のコンピュータ読取り可能な記録媒体。
11. 前記サービス利用者側コンピュータは、入力された前記開始コードを一方向関数に適用することによって前記シーケンスを生成することを特徴とする請求項８に記載のコンピュータ読取り可能な記録媒体。
12. 前記シーケンスは、前記開始コードから前記終了コードまでの数を規定する長さを有することを特徴とする請求項８に記載のコンピュータ読取り可能な記録媒体。
13. 前記長さは、前記サービスプロバイダ側コンピュータおよび前記サービス利用者側コンピュータによって合意されることを特徴とする請求項１２に記載のコンピュータ読取り可能な記録媒体。
14. 前記サービス仲介サーバは、前記長さを前記サービスプロバイダ側コンピュータに提供することを特徴とする請求項１２に記載のコンピュータ読取り可能な記録媒体。

Images