特許 6491352 サービスのバッチ請求を規制する方法および装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6491352

(24)【登録日】2019年3月8日

(45)【発行日】2019年3月27日

(54)【発明の名称】サービスのバッチ請求を規制する方法および装置

(51)【国際特許分類】

   G06F 21/55 20130101AFI20190318BHJP

【ＦＩ】

   G06F21/55

【請求項の数】6

【全頁数】10

(21)【出願番号】特願2017-550895(P2017-550895)

(86)(22)【出願日】2016年1月27日

(65)【公表番号】特表2018-513472(P2018-513472A)

(43)【公表日】2018年5月24日

(86)【国際出願番号】CN2016072359

(87)【国際公開番号】WO2016155411

(87)【国際公開日】20161006

【審査請求日】2017年11月2日

(31)【優先権主張番号】201510148230.7

(32)【優先日】2015年3月31日

(33)【優先権主張国】CN

(73)【特許権者】

【識別番号】517156872

【氏名又は名称】北京京東尚科信息技術有限公司

【氏名又は名称原語表記】Ｂｅｉｊｉｎｇ Ｊｉｎｇｄｏｎｇ Ｓｈａｎｇｋｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｔｅｃｈｎｏｌｏｇｙ Ｃｏ．， Ｌｔｄ．

(73)【特許権者】

【識別番号】517241916

【氏名又は名称】北京京東世紀貿易有限公司

【氏名又は名称原語表記】Ｂｅｉｊｉｎｇ Ｊｉｎｇｄｏｎｇ Ｃｅｎｔｕｒｙ Ｔｒａｄｉｎｇ Ｃｏ．， Ｌｔｄ．

(74)【代理人】

【識別番号】110002000

【氏名又は名称】特許業務法人栄光特許事務所

(72)【発明者】

【氏名】リ ウェイチ

【審査官】 宮司 卓佳

(56)【参考文献】

【文献】 中国特許出願公開第１０４２５３６８７（ＣＮ，Ａ）

【文献】 特開２００９−２６６０６７（ＪＰ，Ａ）

【文献】 特開２００３−１６７８５０（ＪＰ，Ａ）

【文献】 兼子拓弥他，計算機援用ユーザ認証，情報処理学会 論文誌（ジャーナル） Ｖｏｌ．５５ Ｎｏ．９ ［ｏｎｌｉｎｅ］，日本，情報処理学会，２０１４年 ９月１８日，第55巻,第9号，p.2072-p.2080

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ２１／３０−Ｇ０６Ｆ２１／５７

(57)【特許請求の範囲】

【請求項1】

サービスのバッチ請求を規制する方法であって、
端末から送信されたサービス請求情報をサーバ側において受信するステップと、
前記サーバ側より前記端末に対して前記端末の計算リソースに対する需要量が前記サーバ側の計算リソースに対する需要量よりも大きい計算問題を送信するステップと、
前記サーバ側において前記問題に対する前記端末の計算結果を受信し、その後当該結果を検証し、正しければ、前記端末にサービスを提供し、正しくなければ、前記端末へのサービス提供を拒否するステップと、
を含み、
前記計算問題は、前記端末のメモリを消耗させるための計算問題を含み、
前記サーバ側より前記端末に計算問題を送信する前に、前記サーバ側よりサーバ側デバイスのメモリにおける複数のデータ断片のデータを前記端末に送信するステップをさらに含み、
前記計算問題は、前記複数のデータ断片のうち１つの指定されたデータ断片におけるデータを提供するよう前記端末に要求するものを含むことを特徴とする方法。

【請求項2】

サービスのバッチ請求を規制する方法であって、
端末から送信されたサービス請求情報をサーバ側において受信するステップと、
前記サーバ側より前記端末に対して前記端末の計算リソースに対する需要量が前記サーバ側の計算リソースに対する需要量よりも大きい計算問題を送信するステップと、
前記サーバ側において前記問題に対する前記端末の計算結果を受信し、その後当該結果を検証し、正しければ、前記端末にサービスを提供し、正しくなければ、前記端末へのサービス提供を拒否するステップと、
を含むことを特徴とし、
前記計算問題は、前記端末のネットワークリソースを消耗させるための計算問題を含むことを特徴とする方法。

【請求項3】

請求項２に記載の方法であって、
前記サーバ側より前記端末に計算問題を送信する前に、それぞれ１つのファイルを有している複数のネットワークアドレスを記憶するとともに、前記複数のネットワークアドレスにおけるファイルのデジタルダイジェスト値を記憶するステップをさらに含み、
前記計算問題は、前記複数のネットワークアドレスのうち指定されたネットワークアドレスにおけるファイルのデジタルダイジェスト値を提供するよう前記端末に要求するものを含むことを特徴とする方法。

【請求項4】

サービスのバッチ請求を規制する装置であって、
端末から送信されたサービス請求情報を受信する受信モジュールと、
前記端末に対して前記端末の計算リソースに対する需要量がサーバ側の計算リソースに対する需要量よりも大きい計算問題を送信する出題モジュールと、
前記問題に対する前記端末の計算結果を受信し、その後当該結果を検証し、正しければ、前記検証にパスしたことを示す情報を前記端末に返信し、正しくなければ、前記検証にパスしなかったことを示す情報を前記端末に返信する検証応答モジュールと、
を備え、
前記計算問題は、前記端末のメモリを消耗させるための計算問題を含み、
サーバ側デバイスのメモリにおける複数のデータ断片のデータを前記端末に送信するためのメモリデータ送信モジュールをさらに含み、
前記計算問題は、前記複数のデータ断片のうち１つの指定されたデータ断片におけるデータを提供するよう前記端末に要求するものを含むことを特徴とする装置。

【請求項5】

サービスのバッチ請求を規制する装置であって、
端末から送信されたサービス請求情報を受信する受信モジュールと、
前記端末に対して前記端末の計算リソースに対する需要量がサーバ側の計算リソースに対する需要量よりも大きい計算問題を送信する出題モジュールと、
前記問題に対する前記端末の計算結果を受信し、その後当該結果を検証し、正しければ、前記検証にパスしたことを示す情報を前記端末に返信し、正しくなければ、前記検証にパスしなかったことを示す情報を前記端末に返信する検証応答モジュールと、
を備え、
前記計算問題は、前記端末のネットワークリソースを消耗させるための計算問題を含むことを特徴とする装置。

【請求項6】

請求項５に記載の装置であって、
それぞれ１つのファイルを有している複数のネットワークアドレスを記憶するとともに、前記複数のネットワークアドレスにおけるファイルのデジタルダイジェスト値を記憶するためのネットワークアドレス記憶モジュールをさらに含み、
前記計算問題は、前記複数のネットワークアドレスのうち指定されたネットワークアドレスにおけるファイルのデジタルダイジェスト値を提供するよう前記端末に要求するものを含むことを特徴とする装置。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、コンピュータ技術分野に係わり、とりわけサービスのバッチ請求を規制する方法および装置に係わる。

【背景技術】

【0002】

サービスプロバイダは、インターネットが持っている強力なビジネス支援能力を享受している反面、パブリックネットワークからの厳しくかつ悪意のある攻撃にさらされている。これらの攻撃のうち、例えばバッチ登録、バッチポスティング、ブラッシュランキング、スパイキング、クローラを用いたウエブサイトの複製など、バッチプログラムを利用して迅速かつ繰り返しアクセスすることによってサービスを獲得する攻撃が数多く存在しており、これらのバッチ操作によって一連のユーザ操作を偽装するという目的を果たすことができる。バッチ登録プログラムを例に見ると、サービスプロバイダが規制しなければ、一台のパソコンで１つのバッチ登録プログラムを１時間並行実行するだけで、万単位の偽装ユーザを登録することができる。これらの偽装ユーザを利用すれば、非合法的な利益を得ることができる。

【0003】

これらのバッチ操作請求によってサービスプロバイダの大量の計算リソースが消耗されるだけでなく、無効なトラフィックが発生し、サービス機能が低下し、正規ユーザのアクセスが妨害されてしまう。サービスの正常な運転を確保し、サービスのリソースを正規ユーザに提供できるように、サービスプロバイダは、これらのバッチ操作を如何にして規制する（一般に「アンチブラッシュ」という）かを考えなければならない。

【0004】

現在広く用いられているサービスのバッチ請求規制（アンチブラッシュ）方法は下記のとおりである。

【0005】

１．ネットワークレベルの規制：ネットワークレベルで請求頻度に対する規制戦略を講じる。例えば、
（１）単位時間内に許容するアクセス回数を規制するなど、ＩＰアドレスおよびポートナンバーのアクセス状況に応じて具体的に規制する。
（２）ＵＲＬの単位時間にアクセスするＩＰの量を規制しクッキーなどの情報を判断するなど、ＨＴＴＰヘッダに基づいて規制戦略を講じる。
（３）ブラウザ側の設定を変更し、クッキーの変化、Javascript（登録商標）などの技術を利用して繰り返し請求を阻止する。例えば、http_refererを規制することによってリーチを防止し、http_user_agentを規制することによってクローラを防止し、request_method方法を規制し、http_cookieを規制し、正規のクッキーを所有していないビジターのアクセスを禁止するなどを挙げることができる。

【0006】

２．アプリケーションレベルの規制：プログラムによってアクセス行為を積極的にコントロールする。例えば、
（１）単位時間内のアクセス回数を制限する；
（２）アクセスの時間的間隔設定を設定する；
（３）ブロック時間を設定する。
（４）ブラックリストおよびホワイトリストを設定する。

【0007】

３．リバースチューリングテスト（ＣＡＰＴＣＨＡ、識別コードなど）によって自動プログラムからのアクセスを遮蔽する。一般的には、人間によって比較的容易に識別できるが機械にとって非常に解決しにくい開放的な質問を設定する。強制的に実際の人間を質問の回答に参与させることによってプログラムのバッチ請求行為を規制する。現在はやっている識別コードテストとして、画像によって識別する方法、ランダムの質問に回答させる方法、音声検証などを挙げることができる。

【0008】

４．携帯電話のショートメッセージを用いて検証する。具体的には、サービスからユーザの携帯電話に識別コードを送信するとともに、請求を完成する前に当該識別コードを入力するようユーザに要求する。

【0009】

上記方法は数多くの欠点が存在している。以下簡単に分析する。

【0010】

ネットワークレベルでアクセス頻度を規制する方法は、簡単にバイパスすることができるだけでなく、フェーズブロッキング率が非常に高い。例えば、現在のネットワークには大量のＮＡＴ構造が存在しており、サーバ側において採集されるビジターのＩＰアドレスが同じであり、そのためアクセス頻度に基づいて規制することが不可能である。代理技術を用い、またはhttp_cookie、ＩＰアドレスを偽造することによって容易に規制をかわすことができる。また、プログラムによってアクセス行為を積極的にコントロールする方法は、コントロールのルールを設定する必要があり、このルールの有効性を把握しコントロールすることが難しい。また、適切なブラックリストおよびホワイトリストを設定することが非常に難しい。不適切なコントロールのルールは、サービスの用性を低下させてしまうおそれがある。例えば、単位時間のアクセス回数を設定することは、ある意味において、サービスの有効性を低下させてしまうことになる。

【0011】

識別コードによって検査する方法は、現在最も多用されかつ最も成熟した解決方法であり、広範囲に用いられている。しかし、識別コードの有効性は、機械が効果的に識別しかつ質問に回答可能か否かにかかっている。質問が難しすぎると、ユーザが質問に答えられないおそれがある。一方において、マシン知能の進歩により、易しい質問はマシンによる自動識別を効果的に阻止することがすでにできなくなっている。また、ＯＣＲ技術の進歩によりキャラクタをねじれさせ変形させることなどによる画像識別によるテストの有効性が低下している。マシン知能の進歩により、機械が自動的に質問に答える試験の信頼性が低くなっている。そのほか、識別コード試験を行うことによってユーザの体験を低下させ、色覚異常者やお年寄りたちに戸惑いを感じさせてしまうおそれがある。

【0012】

携帯電話のショートメッセージによる検証は非常に高い信頼性を有しているが、同時に非常に大きな制限を受けてしまう。ユーザの携帯電話をバインディングしなければならないほか、ショートメッセージの送信コストが余分にかかってしまう。また、ユーザにとって操作方法が煩雑である。

【発明の概要】

【発明が解決しようとする課題】

【0013】

上記に鑑み、本発明は、サービスのバッチ請求を規制する方法および装置を提供し、サービスのバッチ請求行為の規制に資するとともに、従来技術における一部の欠点の克服に資することができる。

【課題を解決するための手段】

【0014】

上記の目的を実現するために、本発明の一つの面において、サービスのバッチ請求を規制する方法を提供した。

【0015】

本発明のサービスのバッチ請求を規制する方法は、端末から送信されたサービス請求情報をサーバ側において受信するステップと、前記サーバ側より前記端末に対して前記端末の計算リソースに対する需要量が前記サーバ側の計算リソースに対する需要量よりも大きい計算問題を送信するステップと、前記サーバ側において前記問題に対する前記端末の計算結果を受信するステップと、その後当該結果を検証するステップと、正しければ、前記端末にサービスを提供するステップと、正しくなければ、前記端末へのサービス提供を拒否するステップと、を含む。

【0016】

前記計算問題は前記端末のメモリを消耗させるための計算問題を含んでもよい。

【0017】

前記サーバ側より前記端末に計算問題を送信する前に、さらに、前記サーバ側よりサーバ側デバイスのメモリにおける複数のデータ断片のデータを前記端末に送信するステップを含んでもよい。前記計算問題は、前記複数のデータ断片のうち１つの指定されたデータ断片におけるデータを提供するよう前記端末に要求するものを含んでもよい。

【0018】

前記計算問題は、前記端末のネットワークリソースを消耗させるための計算問題を含んでもよい。

【0019】

前記サーバ側より前記端末に計算問題を送信する前に、さらに、それぞれ１つのファイルを有している複数のネットワークアドレスを記憶するとともに、前記複数のネットワークアドレスにおけるファイルのデジタルダイジェスト値を記憶するステップを含んでもよい。前記計算問題は、前記複数のネットワークアドレスのうち指定されたネットワークアドレスにおけるファイルのデジタルダイジェスト値を提供するよう前記端末に要求するものを含んでもよい。

【0020】

本発明の他方の面において、サービスのバッチ請求を規制する装置を提供した。

【0021】

本発明のサービスのバッチ請求を規制する装置は、端末から送信されたサービス請求情報を受信する受信モジュールと、前記端末の計算リソースに対する需要量が前記サーバ側の計算リソースに対する需要量よりも大きい計算問題を前記端末に送信する出題モジュールと、前記問題に対する前記端末の計算結果を受信し、その後当該結果を検証し、正しければ、前記検証にパスしたことを示す情報を前記端末に返信し、正しくなければ、前記検証にパスしなかったことを示す情報を前記端末に返信する検証応答モジュールと、を備えている。

【0022】

前記計算問題は前記端末のメモリを消耗させるための計算問題を含んでもよい。

【0023】

サーバ側デバイスのメモリにおける複数のデータ断片のデータを前記端末に送信するためのメモリデータ送信モジュールをさらに含んでもよい。前記計算問題は、前記複数のデータ断片のうち１つの指定されたデータ断片におけるデータを提供するよう前記端末に要求するものを含んでもよい。

【0024】

前記計算問題は前記端末のネットワークリソースを消耗させるための計算問題を含んでもよい。

【0025】

それぞれ１つのファイルを有している複数のネットワークアドレスを記憶するとともに、前記複数のネットワークアドレスにおけるファイルのデジタルダイジェスト値を記憶するためのネットワークアドレス記憶モジュールをさらに含んでもよい。前記計算問題は、前記複数のネットワークアドレスのうち指定されたネットワークアドレスにおけるファイルのデジタルダイジェスト値を提供するよう前記端末に要求するものを含んでもよい。

【0026】

本発明の技術的解決手段によれば、サービスを提供するサーバ側よりサービスを請求する端末に対して計算問題を出題する。当該計算問題は、サーバ側の計算リソースに対する需要量と端末の計算リソースに対する需要量とが非対称的である。この方法を用いれば、端末は当該計算問題を解いてはじめてサービスを受けることができる。このような規制はバイパスすることができない。また、１回または数回しか請求しない合法な端末にとって、多くの計算リソースが消耗されることがないので、サービスの有効性を低下させるおそれがない。一方で、プログラムを利用してバッチ請求する悪意ある端末にとって、その計算リソースが大量に消耗されるので、継続的請求が難しくなる。さらに、本発明の技術的解決手段によれば、従来技術の識別コードによる端末検査、携帯電話のショートメッセージによる端末識別などの方法の限界を克服することができる。

【図面の簡単な説明】

【0027】

【図1】本発明の実施例におけるサービスのバッチ請求を規制する方法の主なステップを示す概略図である。

【図2】本発明の実施例におけるサービスのバッチ請求を規制する装置の主なモジュールを示す概略図である。

【0028】

なお、図面は本発明をよりよく理解するためのものであり、本発明はこれによって限定されない。

【発明を実施するための形態】

【0029】

以下において図面を参照しながら本発明の代表的な実施例を説明する。本発明の実施例における詳細な説明は本発明を理解していただくためのものであり、例示的なものにすぎない。したがって、当業者は、本発明の範囲および主旨を離脱せずに下記の実施例にさまざまな変更と修正を加えることができることを認識しなければならない。また、説明を簡潔化するために、下記の説明では、公知の機能および構造に対する説明が省略される。

【0030】

本発明の実施例において、バッチ請求発動者のプログラムの１回あたりの請求リソースの消耗を高め、これによってバッチ請求発動者の単位時間内に実行できる請求回数が自然規制される。本実施例のサービスのバッチ請求を規制する方法において、サービスプロバイダによってサービス請求側に問題を出題し、サービス請求側のプログラムが計算リソース（ＣＰＵ、メモリ、ネットワークリソースなど）を費やして問題を解かなければならないようにする。一人の離散的な正規ユーザの計算規模に対してクライアント側のリソースの消耗量を適切な範囲に抑える一方、並行バッチ請求とりわけ並行バッチ請求のリソースに対する需要量を倍増させることによって並行バッチ請求の実行を極めて難しくするために、問題の難しさを合理的な範囲に設定することが好ましい。設定された問題は、請求側（問題を解く側）のリソースに対する需要量とサーバ側（チェックする側）のリソースに対する需要量とを非対称的なものにする。また、チェックするために必要なリソースの消耗を極僅かなものに抑えてサーバ側の機能を低下させるおそれを無くす。前記非対称的な問題は、非対称アルゴリズム（たとえば因数分解）または情報の非対称性（たとえばサービスプロバイダにとって既知のファイルのダイジェスト値をダウンロードして計算するようサービス請求側に要求する）に基づいて設計することができる。

【0031】

ユーザのバッチ登録を例に見ると、１つの悪意ある登録プログラムは、一台の一般構成のパソコンを用いて非常に簡単に２５６個のバッチ処理スレッドを並行に実行することができる。１スレッドあたりメモリ１Ｍを消耗する。登録１回あたりのネットワークトラフィックの消耗が８Ｋバイトである。１つのスレッドが１秒あたり一人の新ユーザを登録することができる。すなわち、１分間に２５６×６０＝１５３６０の新ユーザを登録することができる。この場合のリソース消耗量はメモリ２５６×１Ｍ、トラフィック２５６×８Ｋ＝２Ｍバイトとなる。

【0032】

本発明の方法を用いれば、サービスプロバイダはユーザを登録するたびに１つの問題を解くよう請求側に要求する。そのため、必要とするリソースが多くなり、ＣＰＵが負荷１００％で計算する場合には、必要な計算時間が２秒、メモリの消耗が１Ｇ、ネットワークトラフィックの消耗が１Ｍバイトとなる。同じく上記の例で計算すると、攻撃側が２５６個のスレッドを起動する場合に、１分間に最多で３０のユーザしか登録することができない。一方で、リソースの消耗はＣＰＵの負荷が１００％、メモリの消耗量が２５６Ｇ、ネットワークトラフィックの消耗量が２５６Ｍバイトとなっている。

【0033】

図１は本発明の実施例におけるサービスのバッチ請求を規制する方法の主なステップを示す概略図である。当該方法は前記サービスプロバイダが維持しているサーバによって実行される。

【0034】

ステップ１１：端末から送信されたサービス請求情報をサーバ側において受信するステップである。ここで、端末とはユーザが使用しているクライアントサイドソフトウェアをいう。当該サービス請求情報は、正規ユーザによって送信される場合と悪意あるユーザによって送信される場合とがある。

【0035】

ステップ１２：サーバ側より当該端末に対して計算問題を送信するステップである。前述したとおり、当該計算問題は、端末の計算リソースに対する需要量をサーバ側の計算リソースに対する需要量よりも大きくすることによって端末の計算リソースを適当に消耗させることを実現する。

【0036】

ステップＳ１３：サーバ側において問題に対する端末の計算結果を受信するステップである。

【0037】

ステップＳ１４：受信された計算結果が正しいか否かをサーバ側において検証するステップである。正しければ、ステップＳ１５に移行し、端末にサービスを提供する。正しくなければ、ステップＳ１６に移行し、端末へのサービス提供を拒否する。もちろん、結果 が正しいか正しくないかに係わらず、端末に相応の指示情報を送信する。

【0038】

問題を解く際のリソースに対する需要量とチェックする際のリソースに対する需要量の非対称性を確保するために、検証問題を詳細に設計しなければならない。以下、三つの面に分けてリソースに対する需要をそれぞれ説明する。

【0039】

ＣＰＵの計算リソースの消耗：因数分解など複数種類の非対称アルゴリズムが存在している。問題を解く際の計算の複雑さは目標数の桁数によってコントロールすることができる。問題を解く際の計算リソースに対する需要量とチェックする際の計算リソースに対する需要量を非対称的なものに設定するとともに、チェックするためのコストを極力低いものに抑えなければならない（乗法操作の実行回数を僅かな回数に抑える）。実際のシステムでは、複数種類のアルゴリズムを組み合わせて使用することにより安全性をさらに高めることができる。

【0040】

メモリリソースの消耗：情報の非対称性に基づき、リソースに対する需要量の非対称性は下記の方法によって実現することができる。サービスプロバイダにとって、ランダムに一つのデータ断片を問題として選択するだけでよく、かつ、当該データ断片だけ記憶すればよい。場合によっては当該データ断片のダイジェストだけ記憶すればよい。一方で、サービス請求側にとっては、サービスプロバイダがどのデータ断片のデータ内容について回答を要求するか予測することができないため、すべてのデータ断片を記憶するしか選択肢がない。このような方法を採用すれば、サーバ側は複数回にわたってサーバ側デバイスのメモリにおける異なるデータ断片を端末に送信するとともに、「Ｘ断片内のデータは何ですか」のような内容の問題を端末に出題することができる。ここで、Ｘとは指定された１つの断片をいう。上記から分かるように、上記方法では、サーバ側のメモリリソースの消耗量とサービスを請求する端末のメモリリソースの消耗量が非対称的である。

【0041】

ネットワークリソースの消耗：データベースを構築するとともに、インターネットウェブ上の公開ファイルに対する一連のリンクを当該データベースに記憶する。各ファイルのデジタルダイジェスト値を予め算出して記憶する。検証の際に、サービスプロバイダはランダムに１つのファイルを選択するとともに、検証にパスする条件として当該ファイルをダウンロードするとともにデジタルダイジェスト値を計算するようにサービス請求側に要求する。

【0042】

図２は本発明の実施例におけるサービスのバッチ請求を規制する装置の主なモジュールを示す概略図である。当該装置はコンピュータソフトウェアとして前記サーバ側デバイスに設定することができる。図２に示すように、サービスのバッチ請求を規制する装置２０は主として受信モジュール２１、出題モジュール２２および検証応答モジュール２３を備えている。受信モジュール２１は端末から送信されたサービス請求情報を受信する。出題モジュール２２は前記端末に対して前記端末の計算リソースに対する需要量が前記サーバ側の計算リソースに対する需要量よりも大きい計算問題を送信する。検証応答モジュール２３は前記問題に対する前記端末の計算結果を受信し、その後当該結果を検証し、正しければ、前記検証にパスしたことを示す情報を前記端末に返信し、正しくなければ、前記検証にパスしなかったことを示す情報を前記端末に返信する。

【0043】

計算問題は端末のメモリを消耗させるための計算問題を含んでもよい。このようにすれば、装置２０はサーバ側デバイスのメモリにおける複数のデータ断片のデータを端末に送信するためのメモリデータ送信モジュールをさらに含んでもよく、かつ、前記計算問題は、前記複数のデータ断片のうち１つの指定されたデータ断片におけるデータを提供するよう端末に要求するものを含んでもよい。

【0044】

計算問題は端末のネットワークリソースを消耗させるための計算問題を含んでもよい。このようにすれば、装置２０はそれぞれ１つのファイルを有している複数のネットワークアドレスを記憶するとともに、前記複数のネットワークアドレスにおけるファイルのデジタルダイジェスト値を記憶するためのネットワークアドレス記憶モジュールをさらに含み、かつ、前記計算問題は、前記複数のネットワークアドレスのうち指定されたネットワークアドレスにおけるファイルのデジタルダイジェスト値を提供するよう前記端末に要求するものを含んでもよい。

【0045】

本発明の実施例における技術的解決手段によれば、サービスを提供するサーバ側よりサービスを請求する端末に対して計算問題を出題する。当該計算問題は、サーバ側の計算リソースに対する需要量と端末の計算リソースに対する需要量とが非対称的である。この方法を用いれば、端末は当該計算問題を解いてはじめてサービスを受けることができる。このような規制はバイパスすることができない。また、１回または数回しか請求しない合法な端末にとって、多くの計算リソースが消耗されることがないので、サービスの有効性を低下させるおそれがない。一方で、プログラムを利用してバッチ請求する悪意ある端末にとって、その計算リソースが大量に消耗されるので、継続的請求が難しくなる。さらに、本発明の技術的解決手段によれば、従来技術の識別コードによる端末検査、携帯電話のショートメッセージによる端末識別などの方法の限界を克服することができる。

【0046】

以上、具体的な実施例を通じて本発明の基本原理を説明した。本発明の装置および方法において、各部材または各ステップは分解および／または新たに組み合わせることができることが明らかである。これらの分解および／または新たな組み合わせは本発明の等価的な技術的解決手段とみなすべきである。また、前記一連の処理ステップの実行順序は、自然に上述した順序に応じて時系列に実行することができる。しかし、前記一連の処理ステップは必ずしも時系列に実行する必要がない。一部のステップは、並行にまたは互いに単独に実行することができる。

【0047】

本発明の保護範囲は、前記具体的な実施形態によって制限されない。当業者は、設計要求およびその他の要因により、さまざまな修正、組み合わせ、サブ組み合わせおよび代替を行うことができることを理解すべきである。本発明の主旨および原則の範囲内でなされた修正、等価的な切り替えおよび改善等はすべて本発明の保護範囲内に含まれるものとする。

【図1】

【図2】