JP4874559B2 - サービスコンシューマが、サービスを要求した際に誤った動作をするアプリケーション群を制御する方法およびシステム - Google Patents

Description

本発明は、一般に、サービスプロバイダによって提供される否認できない証拠（ｎｏｎ−ｒｅｐｕｄｉａｔａｂｌｅ ｅｖｉｄｅｎｃｅ）に基づき、サービスプロバイダとサービスコンシューマの間の争い（ｄｉｓｐｕｔｅ）を解決することに関する。

多種多様なサービスが、インターネットを介してサービスプロバイダから利用可能である。例えば、一部のサービスプロバイダは、地図情報、気象情報、株式情報などを提供する。サービスコンシューマ（例えば、パーソナルコンピュータ）が、サービスを求める要求をサービスプロバイダのＷｅｂサーバに送信する。Ｗｅｂサーバは、サービスを実行し（例えば、要求された情報を取り出し）、Ｗｅｂページを介してサービスの結果を要求側のサービスコンシューマに提供する。それらのサービスプロバイダの多くは、自らのサービスを無料でサービスコンシューマに提供する。ただし、サービスプロバイダは、通常、サービスコンシューマによって要求される情報を提供するＷｅｂページ上で広告スペースを売ることによって収入を得る。

コンピューティングデバイスがますます小さくなるにつれ、情報を表示するためのコンピューティングデバイスのスクリーンも小さくなる。例えば、セル電話機は、Ｗｅｂアクセスが可能なコンピューティングデバイスであるが、広告を含む典型的なＷｅｂページを表示することのできない非常に小さいスクリーンしか有さない可能性がある。このため、セル電話機にサービスを提供するサービスプロバイダは、広告を介して収入を得ることができない可能性がある。そのようなコンピューティングデバイスにサービスを提供することと引き換えに、サービスプロバイダが収入を得ることができるようにすることが望ましい。

それらのコンピューティングデバイスはより小型化しているが、コンピューティングデバイスの処理能力は高くなっている。この結果、コンピューティングデバイス（例えば、セル電話機およびパーソナルデジタルアシスタント）は、多くの異なるアプリケーションプログラムをホストすることができる。例えば、セル電話機は、電子メール、地図情報、位置情報、カレンダ情報などを提供するアプリケーション群をホストすることができる。それらのアプリケーション群は、コンピューティングデバイスが購入された際に、あらかじめインストールされていること、または購入後にユーザによってインストールされることが可能である。例えば、セル電話機ユーザが、自分のセル電話機スクリーン上に自分の現在位置の地図が表示されることを所望することが可能である。地図アプリケーションがあらかじめインストールされていない場合、セル電話機ユーザは、インターネットから地図アプリケーションをダウンロードし、そのアプリケーションを自分のセル電話機にインストールすることができる。地図アプリケーションは、位置サービスプロバイダのサービス、および地図サービスプロバイダのサービスを使用する必要があるかもしれない。地図アプリケーションは、位置サービスプロバイダを使用して、セル電話機の近くの様々なセルからの読み取り値に基づき、セル電話機の現在位置を特定することができ、その現在位置を地図サービスプロバイダに供給して、ユーザに表示するための適切な地図を得る事ができる。

そのようなコンピューティングデバイス上のアプリケーション群の使用で、いくつかの問題に直面する可能性がある。１つの問題は、サービスプロバイダによって使用される広告収入モデルが、そのようなコンピューティングデバイスの使用ではうまくいかない可能性があることである。１つの問題解決法は、サービスプロバイダが、要求された各サービスについて料金を請求することである。例えば、位置サービスプロバイダが、要求された各位置について０．０２ドルを請求することが可能である。しかし、位置サービスプロバイダが要求された各サービスについてクレジットカードに料金請求することは、料金請求の処理費用が高すぎるため、実際的ではない。位置サービスプロバイダは、サービスコンシューマに対する料金請求を集計し、１ヶ月に１回だけクレジットカードに料金請求することもできるが、サービスコンシューマ（またはコンピューティングデバイスのユーザ）がそのような料金請求を争う費用対効果の大きいやり方は存在しない。例えば、集計された料金請求が、１０ドルである可能性があり、１０ドルでは、争いを解決するのに必要とされるクレジットカード会社による調査の処理費用を賄うのに遠く及ばない。そのような争いを自動的に解決する仕方を有することが望ましい。

争いの解決に関連する処理費用が全くない場合でも、料金請求の集計は、依然、サービスプロバイダに不利な点をもたらす。詳細には、１つの不利な点は、サービスプロバイダが、サービスコンシューマによる不払いを被る危険を冒すことである。サービスプロバイダが、サービスコンシューマのクレジットカード番号を有している可能性があっても、例えば、カード保持者が最近、クレジットカードをキャンセルしたという理由で、料金請求が断られる可能性がある。不払いをそのように被ることを制限するため、サービスプロバイダは、より頻繁にクレジットカードに料金請求することを望む可能性があるが、そのような頻繁な料金請求の不利な点は、各料金請求に、料金請求される金額を超える可能性がある最低処理費用がかかる可能性があることである。サービスプロバイダが、不払いを被ることとサービスの料金を請求する処理費用の間で、容認できるバランスを指定できるようにすることが望ましい。

そのようなコンピューティングデバイスの使用が抱える別の問題は、コンピューティングデバイスにダウンロードされ、インストールされたアプリケーションが、正しく動作しない可能性があることである。例えば、アプリケーションは、位置サービスプロバイダから１０秒ごとに位置情報を要求するウイルスを含む可能性がある。そのような要求は、位置サービスプロバイダが、その月のサービス料金として５０００ドルを超える額をサービスコンシューマに料金請求したことを示すクレジットカード明細書が受け取られるまで、サービスコンシューマに知られない可能性がある。そのようなアプリケーションが正しく動作していないのではないかどうかを自動的に検出する仕方を有することが望ましい。さらに、サービスプロバイダが、あるアプリケーションが信頼できないのではないかどうかを、アプリケーションの動作の履歴に基づいて示して、サービスコンシューマが、そのようなアプリケーションをインストールすることについて、より情報を得た上で決定を下すことができるようにすることが望ましい。

一般に、参加者（すなわち、サービスプロバイダ、サービスコンシューマ、ならびにアプリケーション群およびアプリケーション群の作成者）が信頼できない可能性がある環境において、サービスプロバイダが様々なアプリケーションを使用するサービスコンシューマにサービスを提供する、費用対効果の高いやり方を有することが望ましい。

アプリケーションが誤って動作しているかどうかを判定するためのシステムが提供される。アプリケーションがインストールされると、サービスコンシューマは、アプリケーションが使用することが許可されるサービスプロバイダのサービスに対する限度を確立することができる。アプリケーションが限度を超えようとしているかどうかを調べるのにランタイム環境が使用される。ランタイム環境は、アプリケーション群にその限度を提供して、正しく動作しているアプリケーションが、自らの限度を知り、遵守することができるようにする。サービスを求めるアプリケーションによるすべての要求は、ランタイム環境を介してルーティングされる。ランタイム環境は、各要求を調べて、その要求により、アプリケーションが限度を超えることがもたらされるかどうかを確認する。もたらされない場合、ランタイム環境は、要求をサービスプロバイダに転送する。しかし、アプリケーションが限度を超えようとしている場合、ランタイム環境は、そのアプリケーションを自動的にアンインストールして、アプリケーションが正しく動作していないことをサービスプロバイダに通知することができる。多くのサービスコンシューマが、アプリケーションが正しく動作していないと報告した場合、サービスプロバイダは、そのアプリケーションにサービスを提供するのを拒否することができ、他のサービスコンシューマに通知して、他のサービスコンシューマが、そのアプリケーションをインストールするかどうかについて情報を得た上で決定を下すことができるようにすることができる。

サービスコンシューマによって要求されたサービスをサービスプロバイダが提供したことを、サービスプロバイダがサービス仲介装置に証明することができるよう、サービスを提供するようにサービスプロバイダに要求するための争い解決の方法およびシステムが提供される。一実施形態では、サービスプロバイダのサービスを要求することを始めることを所望するサービスコンシューマは、サービス仲介装置に終了符号を登録する。終了符号は、一方向関数（ｏｎｅ−ｗａｙ ｆｕｎｃｔｉｏｎ）を開始符号に適用することにより生成された符号のシーケンスにおける最後の符号を表す。（一方向関数は、計算するのが比較的容易であるが、その逆関数は、計算するのが比較的困難な関数である。）一方向関数の適用により、開始符号で始まり、終了符号で終り、中間にいくつかの数の中間符号を有する符号のシーケンスが生成される。

サービスコンシューマの登録を受けると、サービス仲介装置は、終了符号をサービスプロバイダに提供する。次に、サービスコンシューマは、サービスを提供するようにサービスプロバイダに要求することを始めることができる。サービスコンシューマがサービスプロバイダに送信する各要求は、生成とは逆の順序のシーケンスの符号を含む。関数は一方向であるため、サービスプロバイダが、逆関数を適用して、サービスコンシューマから受け取られたものより開始符号に近い符号を生成することは、現実的ではない。このため、サービスプロバイダがシーケンスの符号を有する場合、そのことは、その符号がサービスコンシューマから受け取られた否認できない証拠であると見なすことができる。さらに、一方向関数は、計算するのが比較的容易であるため、サービスプロバイダは、関数を適用して、終了符号を正しく導出することができるかどうかを判定することにより、サービスコンシューマから受け取られた符号が、シーケンスの有効な符号であるかどうかを容易に検証することができる。このため、サービスプロバイダは、要求を受信すると、サービスを提供する前に、要求の符号を使用して終了符号を導出できることを検証する。

検証が成功すると、サービスプロバイダは、要求されたサービスをサービスコンシューマに提供する。サービスプロバイダは、検証された符号が受け取られる前にサービスコンシューマが要求したすべてのサービスを提供したことの否認できない証拠として、検証された符号を使用することができる。検証が成功しなかった場合、サービスプロバイダは、サービスコンシューマがサービスを要求したという否認できない証拠を有さないため、サービスを提供するのを断ることができる。サービスコンシューマは、要求したサービスの提供を受けなかった場合、または提供されたサービスに満足しなかった場合、そのサービスプロバイダのサービスをそれ以上、要求しなくてもよい。そのようなケースでは、サービスプロバイダは、サービスコンシューマが提供されたサービスに不満足であった最初の要求を介して、要求に関する符号（すなわち、否認できない証拠）だけを有する。このようにして、サービスプロバイダは、自らが否認できない証拠を有することを確実にすることができ、サービスコンシューマは、提供されたサービスに不満足であった場合にはいつでも、サービスを要求するのを止めることができる。

符号を受け取った後、サービスプロバイダは、提供したサービスの料金をサービスコンシューマに請求することができる。料金請求は、クレジットカードサービスなどの第三者金融エンティティに提出されることが可能である。サービスコンシューマが料金請求を争った場合、サービスプロバイダまたはサービスコンシューマが間違っている。（実際には、一部の状況では両方が間違っている可能性がある。）争いは、金融エンティティと提携していることが可能なサービス仲介装置によって解決される。サービス仲介装置は、争いの表示（ｉｎｄｉｃａｔｉｏｎ）を受け取った場合、サービスプロバイダが料金請求どおりサービスを提供したことの否認できない証拠として、サービスプロバイダがサービスコンシューマから受け取った符号を提供するようにサービスプロバイダに要求することができる。サービス仲介装置は、サービスプロバイダから符号を受け取ると、受け取られた符号から始めて一方向関数を適用し、登録時にサービスコンシューマによって提供された終了符号を正しく導出することができるかどうかを判定することができる。

終了符号が正しく導出され、一方向関数の適用の回数が料金請求されたサービスと矛盾しない（例えば、各回の適用が、したがって、各符号が、１回のサービスに対応することが可能である）場合、サービス仲介装置は、サービスプロバイダが争いの勝者であると宣言する。サービスプロバイダによって受け取られた符号の数は、サービスコンシューマに提供されたサービスの回数を表す。したがって、サービスコンシューマに１０回のサービスの料金が請求される場合、サービスプロバイダは、終了符号を導出するまでに少なくとも９個の符号が導出される必要がある符号を提供する必要がある。サービス仲介装置は、開始符号から始め、提供された符号で止めて符号を導出すること、または提供された符号から始めて、終了符号で終わることにより、提供された符号を検証することができる。いずれにしても、生成される符号の数は、サービスプロバイダが提供したことを証明することができるサービスの回数を表す。提供された符号を検証することができない場合、サービス仲介装置は、サービスコンシューマが勝者であると宣言することができる。このように、サービス仲介装置は、争いを自動的に、低費用で（すなわち、全く人間の介入なしに）解決することができる。

一実施形態では、サービス仲介装置はまず、一方向関数を適用すること以外の方法を使用して争いを解決しようと試みる。一方向関数の適用は、その逆関数に比べて計算するのが比較的容易であるが、頻繁に適用するには計算費用が高すぎて現実的でない可能性がある。例えば、サービス仲介装置は、１日当たり数千件の争いを解決する可能性がある。サービス仲介装置は、最初、料金請求されたサービスに対応する符号を提供するようにサービスプロバイダとサービスコンシューマの両方に求めることにより、争いを解決しようと試みることができる。符号が同一である場合、サービス仲介装置は、サービスプロバイダが勝者であると宣言する。というのは、サービスプロバイダが、サービスコンシューマが正しい否認できない証拠であると同意する符号を提供したからである。しかし、符号が同一ではない場合、サービスプロバイダまたはサービスコンシューマが間違っている（または両方が間違っている）。そのようなケースでは、サービス仲介装置は、一方向関数を適用して、サービスプロバイダによって提供された符号が正しいか、またはサービスコンシューマによって提供された符号が正しいかを判定する。サービス仲介装置は、いずれであれ正しい符号を提供した方を勝者であると宣言する。サービスプロバイダとサービスコンシューマのいずれも正しい符号を提供しなかった場合、両方が誤った情報を提供しているので、争いは解決することができないとサービス仲介装置は宣言する。代替として、サービス仲介装置は、サービスプロバイダが料金請求を支持する証拠を提供することができなかったので、サービスコンシューマが勝者であると宣言することもできる。

争いを解決する際に使用されるさらなる証拠として、サービスプロバイダは、要求されたサービスを提供する際にサービスプロバイダ独自の符号をサービスコンシューマに提供することができる。サービスプロバイダは、独自の符号シーケンスを生成して、そのシーケンスをサービス仲介装置に登録することができる。サービス仲介装置は、終了符号をサービスコンシューマに提供することができる。次に、サービスプロバイダが、各サービス要求に応答して、それらの符号を生成と逆の順序でサービスコンシューマに提供することができる。争いを解決する際、サービス仲介装置は、サービスプロバイダとサービスコンシューマの両方によって生成された対応する符号を提供するようにサービスプロバイダおよびサービスコンシューマに求めることができる。サービス仲介装置は、サービスコンシューマの符号が検証されるのと同一の形で符号を検証することができる。サービスプロバイダが、正しいサービスコンシューマ符号と正しいサービスプロバイダ符号を提供した場合、サービス仲介装置は、サービスプロバイダが勝者であると宣言する。サービスプロバイダが、誤ったサービスコンシューマ符号を提供し、サービスコンシューマが、両方の符号を正しく提供した場合、サービス仲介装置は、サービスコンシューマが勝者であると宣言する。それ以外の場合、両方の当事者が誤っていると判明した証拠を提供したため、争いを解決することができないと宣言することができる。サービスプロバイダによって生成された符号の使用は、争いの解決が証拠と一致していることを検証する別のレベルを提供する。

この争い解決システムの多くの変形が可能であることが当業者には理解されよう。例えば、サービス仲介装置が、サービスコンシューマのための符号を生成して、それらをサービスコンシューマに提供し、サービスプロバイダのための符号を生成して、それらをサービスプロバイダに提供することができる。代替として、サービス仲介装置は、サービスコンシューマおよびサービスプロバイダの独自のシーケンスを生成する際に使用するために、登録プロセス中に開始符号を選択して、それらをサービスコンシューマおよびサービスプロバイダに提供してもよい。サービスコンシューマは、符号シーケンスを生成した場合、開始符号、終了符号、またはその両方を登録中にサービス仲介装置に提供することができる。サービス仲介装置に開始符号だけが提供される場合、サービス仲介装置は、一方向関数を指定された回数、適用して、終了符号を導出することができ、次に、その終了符号をサービス仲介装置は、サービスプロバイダに提供することができる。サービス仲介装置に終了符号が提供される場合、サービス仲介装置は、その終了符号をサービスプロバイダに直接に提供することができる。サービスプロバイダが否認できない証拠を提供すると、サービス仲介装置は、一方向関数を適用して、終了符号を導出することができるかどうかを確かめることができる。サービスプロバイダが独自の符号を生成した際にも類似のプロセスが行われることが可能である。

サービスコンシューマからサービスプロバイダに符号を送るタイミングは、変更することができることも当業者には理解されよう。例えば、サービスコンシューマは、サービスプロバイダが要求されたサービスを提供して初めて、符号を提供することも可能である。符号は、次のサービス要求において、またはサービスが提供された直後に提供されることが可能である。サービスプロバイダは、符号を受け取らなかった、または符号の正しさを検証できなかった場合、サービスコンシューマにそれ以上のサービスを提供するのを断ることができる。要求したサービスが提供される前に符号が送られる場合、サービスコンシューマが、サービスプロバイダが、サービスを提供しないリスクを引き受ける。反対に、要求したサービスが提供された後に符号が送られる場合、サービスプロバイダが、サービスコンシューマが符号を送らないリスクを引き受ける。サービスプロバイダは、サービスプロバイダが検証することができる符号を受け取った場合、その符号を使用して、サービスコンシューマがサービスを要求したことを証明できることが当業者には認められよう。

シーケンスの長さ、またはシーケンス内の符号の数は、１回の登録に基づいて要求されることが可能なサービスの回数を表す。例えば、シーケンス内に１０１の符号が存在する場合、１００回のサービスが要求されることが可能である。終了符号は、サービスを要求するのに使用されない。というのは、終了符号は、サービス仲介装置からサービスプロバイダに直接に提供されるからである。一実施形態では、シーケンス内の符号の数は、「料金請求単位」を表す。料金請求単位は、サービスプロバイダが単一回の料金請求処理で料金請求することができる最少回数のサービスを表す。サービスプロバイダは、サービスコンシューマから開始符号を受け取ると、その料金請求単位の全回数のサービスの料金をサービスコンシューマに請求することができる。サービスプロバイダは、不払いの不利益を被ることと料金請求処理費用のバランスをとるため、料金請求単位内の符号の数を指定することができる。サービスプロバイダは、多数回のサービスに限って一度に支払いを要求することにより、料金請求処理費用を低減することを所望することが可能である。要求内のサービスの回数が多いほど、行われる必要がある要求の回数が少なくなり、提供されるサービス当たりの料金請求処理費用が少なくなる。しかし、各料金請求が対象に含むサービスの回数が多くなるほど、サービスコンシューマによる不払いよるサービスプロバイダへの影響も大きくなる。例えば、料金請求単位内のサービスの回数が１０００である場合、サービスプロバイダは、サービスコンシューマが支払うことができない（例えば、破産した）場合、１０００回のサービスの不払いを被るリスクを冒す。ただし、不払いのリスクに、料金請求単位当たり多数回のサービス要求を有することにより実現可能な料金請求処理費用の節約が優る可能性もある。

一実施形態では、サービスコンシューマは、サービスコンシューマが実行しているアプリケーションが正しく動作しているかどうかを検出することができる。例えば、アプリケーションは、許可されているより多くの回数のサービスを要求しようと試みる可能性がある。サービスコンシューマは、そのような誤った動作を検出すると、そのアプリケーションを自動的にアンインストールし、サービスプロバイダに通知することができる。サービスプロバイダは、様々なサービスコンシューマによって提供された通知を分析して、アプリケーションが実際に誤った動作をしているかどうかを判定することができる。誤った動作をしている場合、サービスプロバイダは、アプリケーションがサービスプロバイダを使用することが許可されないことを確実にすることができる。別のサービスコンシューマがそのアプリケーションをインストールしようとする場合、そのサービスコンシューマは、サービスプロバイダに問い合わせて、そのアプリケーションが許可されているかどうかを確認することができる。許可されていない場合、サービスコンシューマは、アプリケーションのインストールを中止することができる。反対に、サービスプロバイダは、あるサービスコンシューマが、多数のアプリケーションが誤った動作をしているという通知を提供していることを検出したが、他のいずれのサービスコンシューマも、そのような通知を提供していない場合、アプリケーション群ではなく、そのサービスコンシューマが誤った動作をしていると推論することができる。そのようなケースでは、サービスプロバイダは、そのサービスコンシューマがサービスプロバイダを使用する許可を取り消すことができる。このようにして、サービスプロバイダは、アプリケーション群に関する情報を集約して、いずれのアプリケーションまたはサービスコンシューマが誤った動作をしているかを特定することができる。

図１は、一実施形態における争い解決システムのコンポーネントを示すブロック図である。サービスコンシューマ１０１、サービス仲介装置１０２、およびサービスプロバイダ１０３が、ネットワーク１０４に接続されている。サービス仲介装置は、様々な周知の認証技術のいずれかを使用して、サービスコンシューマおよびサービスプロバイダから来ていると称する通信が、本当にサービスコンシューマおよびサービスプロバイダから来ており、詐称者からではないことを確実にする。サービスコンシューマには、パーソナルデジタルアシスタント、セル電話機、グローバルポジショニング（ｇｌｏｂａｌ ｐｏｓｉｔｉｏｎｉｎｇ）システムデバイス、パーソナルコンピュータなどの任意のタイプのコンピューティングデバイスが含まれることが可能である。サービスプロバイダは、多種多様なサービスをサービスコンシューマに提供することができる。例えば、サービスコンシューマがセル電話機である場合、サービスプロバイダは、現在位置を提供する位置サービスを提供することができる。

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

図１は、争い解決システムを実装することができる適切な動作環境の実施例を示す。動作環境は、適切な動作環境の一例に過ぎず、争い解決システムの用途または機能の範囲について何ら限定を示唆するものではない。使用するのに適する可能性がある他の周知のコンピューティングシステム、コンピューティング環境、およびコンピューティング構成には、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドデバイスまたはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、プログラマブル家庭用電化製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、以上のシステムまたはデバイスのいずれかを含む分散コンピューティング環境などが含まれる。

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

図２は、一実施形態におけるサービスコンシューマ、サービス仲介装置、およびサービスプロバイダの間における情報の典型的な流れを示す図である。この実施例では、サービスプロバイダ２０３は、独自の符号シーケンスを提供しない。サービスコンシューマ２０１は、サービスプロバイダのサービスを要求することを望む場合、開始符号を選択し、その開始符号から導出された符号のシーケンスを生成し、格納する（流れ１）（流れｎ（ｎ；数字）とは、図２中の丸付き数字に対応）。

一実施形態では、シーケンス内の符号の数は、サービスプロバイダと、サービス仲介装置２０２に登録されたサービスコンシューマとの間の契約で事前定義されていることが可能である。次に、サービスコンシューマが、登録要求をサービス仲介装置に送信する（流れ２）。登録要求は、開始符号、終了符号、サービスプロバイダのＩＤ、サービスが提供される契約のＩＤを含むことが可能である。サービス仲介装置は、要求を検証する（例えば、サービスプロバイダおよび契約が有効であることを確実にする）ことができ、サービスコンシューマに関する登録レコードを格納する（流れ３）。サービス仲介装置は、各登録に固有登録番号を割り当てて、争われている料金請求を対応する登録まで辿ることを可能にすることができる。次に、サービス仲介装置は、登録の通知をサービスプロバイダに送信する（流れ４）。通知は、終了符号、ならびにサービスコンシューマのＩＤおよび契約を含むことが可能である。サービスプロバイダは、通知を検証し、サービス要求を確認する際に使用するためにその通知の情報を格納することができる（流れ５）。

次に、サービスプロバイダは、サービス仲介装置に応答して（流れ６）、登録の通知を受領したことを確認する。すると、サービス仲介装置が、サービスコンシューマに応答して（流れ７）、登録が受理されたことを示す。次に、サービスコンシューマが、要求をサービスプロバイダに送信する（流れ８）。各要求は、シーケンスの符号を含む。要求を受信すると、サービスプロバイダは、サービス仲介装置によって提供された終了符号を最初に取り出して、サービスコンシューマから以前に受け取られた最後の符号を取り出す（流れ９）。サービスプロバイダは、受け取られた符号に一方向関数を適用して、その符号が取り出された符号と一致するかどうかを判定する。一致する場合、受け取られた符号が正しいことが確認され、サービスプロバイダは、受け取られた符号を格納し（流れ１０）、サービスを提供する。サービスプロバイダは、サービスを実行したことの結果をサービスコンシューマに送信することができる（流れ１１）。代替として、サービスコンシューマが、サービスプロバイダがサービスを他の何らかの形で実行したことを確認してもよい。例えば、サービス要求が、製品を取り出せるようにする（ｄｉｓｐｅｎｓｅ）許可を自動販売機に送ることであった場合、ユーザは、サービスが提供されたかどうかを視覚的に確認することができる。

流れ８〜１１は、事前定義された長さのシーケンスまで、サービスコンシューマが要求する各回のサービスについて繰り返される。シーケンス内の全回数のサービスが完了すると、サービスプロバイダは、サービスコンシューマに料金請求を行うことができる。料金請求は、登録の固有ＩＤを含むことが可能である。サービスコンシューマが料金請求を争う場合、サービスプロバイダは、サービスコンシューマによって提供された開始符号を、サービスプロバイダがサービスを提供したという否認できない証拠として使用することができる。サービスプロバイダは、証拠として開始符号をサービス仲介装置に提供することができる。サービス仲介装置は、その符号を、登録時にサービスコンシューマによって提供された開始符号と比較して、サービスプロバイダが争いに勝つかどうかを判定することができる。

図３〜９は、争い解決システムのサービスコンシューマ、サービス仲介装置、およびサービスプロバイダによって実行される処理を示す流れ図である。例示した処理では、サービスプロバイダは、独自の符号シーケンスを生成しない。図３は、一実施形態における符号シーケンスを登録するサービスコンシューマのコンポーネントの処理を示す流れ図である。コンポーネントは、サービスプロバイダとサービスが要求される際に基づく契約の指示を送ることにより、呼び出されることが可能である。サービスコンシューマとサービスプロバイダの間に１つの契約だけしか存在しない場合、契約は、特定される必要がない。また、契約は、サービス仲介装置またはサービスプロバイダにより暗示されることも可能である。ブロック３０１で、コンポーネントが、契約に基づいて要求されるべきサービスの回数を選択する。ブロック３０２で、コンポーネントは、選択された回数のサービスに関する符号シーケンスを生成する機能を呼び出す。ブロック３０３で、コンポーネントは、登録要求メッセージをサービス仲介装置に送信する。登録要求メッセージは、開始符号、終了符号、ならびにサービスプロバイダのＩＤ、および契約を含むことが可能である。ブロック３０４で、コンポーネントは、サービス仲介装置からの応答を待つ。判定ブロック３０５で、登録が受理されたことを応答が示した場合、コンポーネントは、ブロック３０６に進み、示さなかった場合、モードは、拒否された登録を処理することに進む。ブロック３０６で、コンポーネントは、提供されたサービスの回数を追跡する変数を初期設定する。その後、コンポーネントは完了する。

図４は、一実施形態におけるシーケンスを生成するコンポーネントの処理を例示する流れ図である。コンポーネントには、シーケンスで表されるサービスの回数が送られる。ブロック４０１で、コンポーネントは、開始符号であるシーケンス内の最初の符号を特定するインデックスｉを設定し、開始符号を設定する。開始符号は、乱数発生器によって選択されることが可能である。シーケンスは、アレイＳの中に格納される。ブロック４０２〜４０４で、コンポーネントは、ループして、符号シーケンスを生成するように一方向関数を適用する。ブロック４０２で、コンポーネントは、シーケンス内の次の符号をポイントするようにインデックスを増分する。判定ブロック４０３で、インデックスがシーケンスのサービスの回数より大きい場合、コンポーネントは、シーケンスを戻し、大きくない場合、ブロック４０４に進む。ブロック４０４で、コンポーネントは、シーケンス内の前の符号に一方向関数を適用することによって生成された符号を、シーケンス内のインデックスの付いた位置に格納する。次に、コンポーネントは、ブロック４０２にループしてシーケンス内の次の符号を生成する。

図５は、一実施形態におけるサービスプロバイダからのサービスを要求するコンポーネントの処理を示す流れ図である。判定ブロック５０１で、シーケンス内のサービスの回数が既に要求済みである場合、コンポーネントは、サービスを要求することができないという指示を戻し、そうでない場合、ブロック５０２に進む。ブロック５０２で、コンポーネントは、要求されたサービスの回数を追跡するのに使用され、要求されることが可能なサービスの回数を表す変数を減分する。ブロック５０３で、コンポーネントは、シーケンスのインデックス付きの符号を含むサービス要求メッセージをサービスプロバイダに送信し、次に、要求が送信されたという指示を戻す。

図６は、一実施形態における、サービス仲介装置のコンポーネントがサービスコンシューマから登録要求メッセージを受信した場合に呼び出されるサービス仲介装置のコンポーネントの処理を示す流れ図である。コンポーネントには、サービスコンシューマの指示、開始符号および終了符号、サービスプロバイダ、および契約が送られる。判定ブロック６０１で、契約が、サービスコンシューマとサービスプロバイダの間の有効な契約を表す場合、コンポーネントは、ブロック６０２に進み、そうでない場合、誤りを戻し、登録が拒否されたことをサービスコンシューマに通知することができる。一実施形態では、サービスコンシューマとサービスプロバイダは、契約をサービス仲介装置に登録することができる。契約は、シーケンスに含められるサービスの回数、および提供される各サービスについてサービスプロバイダが料金を請求する金額などの価格情報を特定することができる。サービス仲介装置は、争いを解決する際、登録された契約情報を使用する。ブロック６０２で、コンポーネントは、送られた情報を格納して、争いが解決される必要がある場合にその情報を使用することができるようにする。ブロック６０３で、コンポーネントは、登録通知メッセージをサービスプロバイダに送信する。メッセージは、サービスコンシューマ、契約、および終了符号を特定する。ブロック６０４で、コンポーネントは、サービスプロバイダからの登録確認メッセージを待つ。確認応答が受信されると、コンポーネントは、ブロック６０５で、登録が受理されたことを示す登録応答メッセージをサービスコンシューマに送信する。次に、コンポーネントは、登録が成功したという指示を戻す。

図７は、一実施形態における、サービス仲介装置から登録通知メッセージが受信された場合に呼び出されるサービスプロバイダのコンポーネントの処理を示す流れ図である。コンポーネントには、サービスコンシューマの指示、契約、および終了符号が送られる。コンポーネントは、サービスコンシューマおよび契約を検証することができる。有効ではない場合、コンポーネントは、確認できなかったという応答メッセージまたは拒否応答メッセージをサービス仲介装置に送信することができる。ブロック７０１で、コンポーネントは、契約からシーケンス内のサービスの回数を取り出す。ブロック７０２で、コンポーネントは、初期の数からカウントダウンを行うことにより、要求されたサービスの回数を追跡する変数を設定する。ブロック７０３で、コンポーネントは、アレイＳの中に終了符号を格納し、完了する。

図８は、一実施形態における、サービスコンシューマからサービス要求メッセージが受信された場合に呼び出されるサービスプロバイダのコンポーネントの処理を示す流れ図である。コンポーネントには、サービスコンシューマの指示、契約、および符号が送られる。コンポーネントは、符号が正しいことを確認し、正しい場合は、サービスを実行する。ブロック８０１で、コンポーネントは、サービスコンシューマおよび契約に関するシーケンス内でまだ提供されていないサービスの回数の指示を取り出す。判定ブロック８０２で、提供されるべきサービスが全く残っていない場合、コンポーネントは、誤りを戻し、残っている場合、コンポーネントは、ブロック８０３に進む。判定ブロック８０３で、受け取られた符号に一方向関数を適用して、受け取られた最後の符号と等しくなった場合、コンポーネントは、ブロック８０４に進み、等しくならなかった場合、コンポーネントは、誤りの指示を戻す。ブロック８０４で、コンポーネントは、まだ提供されていないサービスの回数を追跡する変数を減分する。ブロック８０５で、コンポーネントは、受け取られた符号を格納した後、送られた符号が確認されたという指示を戻す。サービスプロバイダは、否認できない証拠として使用されるために提供された最後の符号を保存し、受け取られる次の符号の正しさを確認するだけでよい。

図９は、一実施形態における争いを処理するサービス仲介装置のコンポーネントの処理を示す流れ図である。このコンポーネントは、サービスコンシューマがサービスプロバイダからの料金請求を争う場合に呼び出される。このコンポーネントは、サービスコンシューマによって生成された符号のシーケンスだけに基づき、争い解決を処理する。コンポーネントには、サービスコンシューマの指示、サービスプロバイダ、および争われているシーケンスの登録が送られる。ブロック９０１で、コンポーネントは、サービスコンシューマから適切な符号を要求する。適切な符号は、サービスコンシューマに料金請求が行われたサービスの回数を表す。ブロック９０２で、コンポーネントは、適切な符号（すなわち、サービスプロバイダの否認できない証拠）を提供するようにサービスプロバイダに要求する。判定ブロック９０３で、受け取られた符号が合致した場合、コンポーネントは、サービスプロバイダが勝者であると宣言し、合致しなかった場合、ブロック９０４に進む。ブロック９０４で、コンポーネントは、その登録に関する開始符号およびサービスの回数を取り出す。ブロック９０５で、コンポーネントは、シーケンスの符号を生成する。判定ブロック９０６で、サービスプロバイダの符号が生成された符号と合致した場合、コンポーネントは、サービスプロバイダが勝者であると宣言し、合致しなかった場合、ブロック９０７に進む。判定ブロック９０７で、サービスコンシューマの符号が生成された符号と合致した場合、コンポーネントは、サービスコンシューマが勝者であると宣言し、合致しなかった場合は、料金請求されたサービスをサポートする符号をサービスコンシューマもサービスプロバイダも提供することができなかったという理由で、争いを解決することができないと報告する。

一実施形態では、サービスプロバイダとサービスコンシューマの両方が符号シーケンスを生成する場合、サービス仲介装置は、当事者が両方の符号を正しく提供した場合にだけ勝者を宣言する。争いを解決するため、サービス仲介装置は、自らの立場をサポートするようにサービスプロバイダ符号とサービスコンシューマ符号を提供するように両方の当事者に求める。サービスプロバイダによって提供された符号が正しい場合、サービス仲介装置は、サービスプロバイダが勝者であると宣言する。そうではなく、サービスコンシューマによって提供された符号がともに正しい場合、サービス仲介装置は、サービスコンシューマが勝者であると宣言する。他のすべてのケースでは、両方の当事者が、少なくとも１つの誤った符号を提供しており、サービス仲介装置は、勝者が存在しないと宣言する。

図１０は、一実施形態におけるサービスコンシューマのコンポーネントを示すブロック図である。サービスコンシューマ１０００は、サービスコンシューマ符号コンポーネント１００１、ランタイムコンポーネント１００２、アプリケーション群１００３、符号ストア１００４、契約ストア１００５、およびアプリケーションストア１００６を含む。サービスコンシューマ符号コンポーネントは、シーケンスを生成すること、およびそのシーケンスをサービス仲介装置に登録することを担う。ランタイムコンポーネントは、アプリケーション群がサービスプロバイダにアクセスすることができる環境をアプリケーション群に提供することを担う。ランタイムコンポーネントは、許可を超えてサービスを要求するアプリケーションがアンインストールされること、および対応する通知がサービスプロバイダに送信されることを確実にする。符号ストアは、登録に関連する情報を含む。各エントリは、登録された各シーケンスに関して、サービスプロバイダ、契約、シーケンス、およびそのシーケンスへの現在のインデックスを特定する。契約ストアは、サービスコンシューマの契約を記述する情報を含む。契約ストアの中の各エントリは、サービスプロバイダおよび契約条件を特定する。アプリケーションストアは、各アプリケーションに関するサービスの限度を記述する情報を含む。アプリケーションストアの各エントリは、アプリケーション、サービスプロバイダ、許可された限度、およびそのサービスの現在の使用量（ｕｓａｇｅ）を特定することができる。

図１１は、一実施形態における、サービスコンシューマのユーザが、どのようにアプリケーション群に関して許可された限度を確立することができるかを例示するディスプレイ表示である。ディスプレイ表示１１００は、アプリケーション名１１０１および許可テーブル１１０２を含む。許可テーブルは、サービスプロバイダに関する列、累積限度、許可された限度、および期間を含む。サービスプロバイダ列は、アプリケーションがアクセスすることが許可されているサービスプロバイダを特定する。累積限度は、すべてのアプリケーションにわたって許可されたそのサービスプロバイダに対するサービス要求の総数を指定する。許可限度は、アプリケーションがサービスプロバイダに要求することが許可されているサービス要求の数を示す。例えば、テーブルの最初の行は、アプリケーションが、位置特定サービスプロバイダを使用する必要があること、アプリケーション群がグループとして、１ヶ月当たり５００回のサービスを要求することが許可されていること、およびそのアプリケーションが、１ヶ月当たり最大５０回のサービスを要求することが許可されることを示す。このディスプレイスクリーンからの情報は、アプリケーションストアの中に格納される。

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

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

説明した技術の多くの変形形態が可能であることが当業者には認識されよう。例えば、サービスコンシューマは、サービスのシーケンスを要求することを望む場合、公開キー−秘密キーペアを生成することができる。サービスコンシューマは、公開キーをサービス仲介装置に登録することができ、サービス仲介装置が、公開キーをサービスプロバイダに提供することができる。サービスコンシューマは、サービス要求を送信する際、秘密キーを使用して暗号化されたシーケンス番号を含める。サービスプロバイダは、要求を受信すると、公開キーを使用してシーケンス番号を解読し、シーケンス番号が正しいことを確認することができる。正しい場合、サービスプロバイダは、その暗号化されたシーケンス番号を否認できない証拠として使用することができる。

また、サービスコンシューマは、サービスプロバイダによって生成され、提供された符号を、サービスコンシューマがある回数のサービスを要求し、そのサービスの提供を受けたことの否認できない証拠として使用することもできることが当業者には認識されよう。そのような証拠は、例えば、サービスコンシューマが、最低限の回数のサービスを要求した場合に割引を受ける場合に役立つ可能性がある。

また、ランタイム環境は、アプリケーションが不正に動作しているかどうかを判定するために、多くの異なる技術を使用することができることも当業者には認識されよう。例えば、ランタイム環境は、アプリケーションが、あるタスクを実行するのにあまりにも長時間を要している（例えば、無限ループに入っている）こと、あまりにも頻繁にサービスを要求していること、などを不正な動作の指示として検出することができる。ランタイム環境は、ユーザが、アプリケーションの動作に満足しているかどうかについての入力を受け取ることもできる。ランタイム環境は、それらの不正な動作を様々なサービスプロバイダに報告して、サービスプロバイダが、複数のサービスコンシューマからのレポートを集約して、アプリケーションが不正な動作をしているかどうかの正確な評価を提供できるようにすることができる。

以上から、本発明の特定の実施形態を例示のために本明細書で説明してきたが、本発明の趣旨および範囲を逸脱することなく、様々な変更形態を実施できることが当業者には認識されよう。「サービス」という用語は、サービスプロバイダに要求されることが可能な任意のタイプのアクションを含むことが当業者には認識されよう。例えば、アクションには、物理的製品または電子製品（例えば、音楽ＣＤ）をユーザに販売すること、自動販売機において製品を取り出せるようにすること、電話番号を探し出すこと、支払いを許可すること、家庭の照明を遠隔で制御すること、ビデオをストリーミングすることなどが含まれることが可能である。したがって、本発明は、添付の特許請求の範囲による以外は限定されない。

本発明の一実施形態に係る、争い解決システムのコンポーネントを示すブロック図である。 本発明の一実施形態に係る、サービスコンシューマ、サービス仲介装置、およびサービスプロバイダの間における情報の典型的な流れを示す図である。 本発明の一実施形態に係る、符号のシーケンスを登録するサービスコンシューマのコンポーネントの処理を示す流れ図である。 本発明の一実施形態に係る、シーケンスを生成するコンポーネントの処理を示す流れ図である。 本発明の一実施形態に係る、サービスプロバイダからサービスを要求するコンポーネントの処理を示す流れ図である。 本発明の一実施形態に係る、サービス仲介装置のコンポーネントがサービスコンシューマから登録要求メッセージを受信した場合に呼び出されるサービス仲介装置のコンポーネントの処理を示す流れ図である。 本発明の一実施形態に係る、サービス仲介装置から登録通知メッセージが受信された場合に呼び出されるサービスプロバイダのコンポーネントの処理を示す流れ図である。 本発明の一実施形態に係る、サービスコンシューマからサービス要求メッセージが受信された場合に呼び出されるサービスプロバイダのコンポーネントの処理を示す流れ図である。 本発明の一実施形態に係る、争いを処理するサービス仲介装置のコンポーネントの処理を示す流れ図である。 本発明の一実施形態に係る、サービスコンシューマのコンポーネントを示すブロック図である。 本発明の一実施形態に係る、サービスコンシューマのユーザが、どのようにアプリケーション群に関して許可された限度を確立することができるかを例示するディスプレイ表示である。 本発明の一実施形態に係る、ランタイムコンポーネントのインストールサブコンポーネントの処理を示す流れ図である。 本発明の一実施形態に係る、サービスを実行するようにサービスプロバイダに要求するランタイムコンポーネントのサブコンポーネントの処理を示す流れ図である。

符号の説明

１０１ サービスコンシューマ
１０２ サービス仲介装置
１０３ サービスプロバイダ
１０４ ネットワーク
２０１ サービスコンシューマ
２０２ サービス仲介装置
２０３ サービスプロバイダ

Claims (10)

1. アプリケーションが不正な動作をしているかどうかを判定するためのコンシューマシステムにおける方法であって、
   前記コンシューマシステムにアプリケーションがインストールされる際、前記コンシューマシステムによって、前記アプリケーションによるサービスプロバイダのサービスについての使用制限を設定するステップと、
   前記コンシューマシステムによって、前記アプリケーションがサービスプロバイダのサービスの使用権限をもつか否かを当該サービスプロバイダに問い合わせることにより、当該アプリケーションがそのサービスプロバイダのサービスを要求する権限があるかを判定するステップであって、前記サービスプロバイダは、他のコンシューマシステムからの、前記アプリケーションが不正な動作をしていることを示した通知を集約して、当該アプリケーションが当該サービスプロバイダのサービスを要求する権限がもたないと判定する、ステップと、
   前記アプリケーションが前記サービスプロバイダのサービスを要求する権限をもつと判定された場合は、当該アプリケーションがインストールされた後に、ランタイム環境の制御下において、前記コンシューマシステムによって、
   前記設定された使用制限の範囲内で、前記アプリケーションに前記サービスプロバイダのサービスへのアクセスを提供するステップと、
   前記アプリケーションが前記サービスプロバイダのサービスを要求した場合、前記要求に基づいて前記使用制限を超えるかどうかを判定するステップと、
   前記使用制限を超えないと判定された場合、前記サービスを提供するように前記サービスプロバイダに要求するステップと、
   前記使用制限を超えると判定された場合、前記アプリケーションが不正な動作をしていることを前記サービスプロバイダに通知し、前記アプリケーションの実行を禁止するステップと
   を含むことを特徴とする方法。
2. 前記禁止するステップは、前記アプリケーションをアンインストールするステップを含むことを特徴とする請求項１に記載の方法。
3. 前記サービスプロバイダは、前記コンシューマシステムによって提供された通知を集約して、前記コンシューマシステムが前記サービスプロバイダのサービスを要求することが許可されるべきでないかどうかを判定することを特徴とする請求項１に記載の方法。
4. 前記使用制限は、前記コンシューマシステムのユーザによって設定されることを特徴とする請求項１に記載の方法。
5. 前記使用制限は、前記アプリケーションの公開された要件に基づいて設定されることを特徴とする請求項１に記載の方法。
6. 複数のサービスプロバイダが、同様のサービスを提供することができ、前記アプリケーションは、前記コンシューマシステムによって指定された前記複数のサービスプロバイダの１つにサービスを要求することができることを特徴とする請求項１に記載の方法。
7. アプリケーションが不正な動作をしているという通知をサービスプロバイダに提供するためのコンピュータシステムであって、
   前記コンピュータシステムは、
   アプリケーションがインストールされるとき、前記アプリケーションが使用するサービスプロバイダのサービスについての使用制限を設定する処理と、
   前記アプリケーションがサービスプロバイダのサービスの使用権限をもつか否かを当該サービスプロバイダに問い合わせることにより、当該アプリケーションがそのサービスプロバイダのサービスを要求する権限があるかを判定する処理であって、前記サービスプロバイダは、他のコンシューマシステムからの、前記アプリケーションが不正な動作をしていることを示した通知を集約して、当該アプリケーションが当該サービスプロバイダのサービスを要求する権限がもたないと判定する、処理と、
   前記アプリケーションが前記サービスプロバイダのサービスを要求する権限をもつと判定された場合は、当該アプリケーションをインストールし、前記アプリケーションが前記サービスプロバイダのサービスを要求する権限をもたないと判定された場合は、当該アプリケーションをインストールしない処理と、
   前記アプリケーションがインストールされた後に、ランタイム環境の制御下において、
   前記設定された使用制限の範囲内で、前記アプリケーションに前記サービスプロバイダのサービスへのアクセスを提供する処理と、
   前記アプリケーションが前記サービスプロバイダのサービスを要求した場合、 前記要求に基づいて前記使用制限を超えるかどうかを判定する処理と、
   前記使用制限を超えないと判定された場合、前記サービスを提供するように前記サービスプロバイダに要求する処理と、
   前記使用制限を超えると判定された場合、前記アプリケーションが不正な動作をしていることを前記サービスプロバイダに通知し、前記アプリケーションの実行を禁止する処理と
   を実行するように構成されていることを特徴とするコンピュータシステム。
8. 前記コンピュータシステムは、前記アプリケーションをアンインストールするように構成されていることを特徴とする請求項７に記載のコンピュータシステム。
9. 不正な動作の前記通知は、前記サービスプロバイダのサービスを求める要求の回数を超えることであることを特徴とする請求項７に記載のコンピュータシステム。
10. 前記サービスプロバイダは、異なるコンピュータによって提供される通知を集約して、前記アプリケーションが前記サービスプロバイダのサービスを要求することが許可されるべきかどうかを判定することを特徴とする請求項７に記載のコンピュータシステム。

Images