"HTTPリクエストの記述の規則を、HTTPクライアントの属性毎に記憶する規則記憶部と、前記規則記憶部に記憶される規則と、端末装置から送信されたHTTPリクエストの記述と、に基づいて、前記端末装置におけるHTTPクライアントの属性を推定する推定部と、を備えるクライアント推定装置。HTTPリクエストの記述の規則を、HTTPクライアントの属性毎に記憶する規則記憶部を備える情報処理装置が、前記規則記憶部に記憶される規則を読み出すステップと、前記情報処理装置が、読み出された前記規則と、端末装置から送信されたHTTPリクエストの記述と、に基づいて、前記端末装置におけるHTTPクライアントの属性を推定するステップと、を有するクライアント推定方法。HTTPリクエストの記述の規則を、HTTPクライアントの属性毎に記憶する規則記憶部を備える情報処理装置に対し、前記規則記憶部に記憶される規則を読み出すステップと、読み出された前記規則と、端末装置から送信されたHTTPリクエストの記述と、に基づいて、前記端末装置におけるHTTPクライアントの属性を推定するステップと、を実行させるためのコンピュータプログラム。しかしながら、UserAgentヘッダに記載されている情報が正確性に欠ける場合があるという問題があった。そのため、UserAgentヘッダの内容がそのまま格納された環境変数HTTPUSERAGENTの情報のみに基づいて推定を行うと、誤った推定結果が得られる場合があった。上記事情に鑑み、本発明は、HTTPリクエストの送信元の装置で動作しているHTTPクライアントの属性をより正確に推定する技術を提供することを目的としている。本発明の一態様は、HTTPリクエストの記述の規則を、HTTPクライアントの属性毎に記憶する規則記憶部と、前記規則記憶部に記憶される規則と、端末装置から送信されたHTTPリクエストの記述と、に基づいて、前記端末装置におけるHTTPクライアントの属性を推定する推定部と、を備えるクライアント推定装置である。本発明の一態様は、HTTPリクエストの記述の規則を、HTTPクライアントの属性毎に記憶する規則記憶部を備える情報処理装置が、前記規則記憶部に記憶される規則を読み出すステップと、前記情報処理装置が、読み出された前記規則と、端末装置から送信されたHTTPリクエストの記述と、に基づいて、前記端末装置におけるHTTPクライアントの属性を推定するステップと、を有するクライアント推定方法である。本発明の一態様は、HTTPリクエストの記述の規則を、HTTPクライアントの属性毎に記憶する規則記憶部を備える情報処理装置に対し、前記規則記憶部に記憶される規則を読み出すステップと、読み出された前記規則と、端末装置から送信されたHTTPリクエストの記述と、に基づいて、前記端末装置におけるHTTPクライアントの属性を推定するステップと、を実行させるためのコンピュータプログラムである。本発明により、HTTPリクエストの送信元の装置で動作しているHTTPクライアントの属性をより正確に推定することが可能となる。図1は、クライアント推定システム1のシステム構成を表すシステム構成図である。クライアント推定システム1は、端末装置10、HTTPサーバ20を備える。端末装置10とHTTPサーバ20とは、ネットワーク30を介して互いに通信可能である。端末装置10は、パーソナルコンピュータ、携帯電話、スマートフォン、テレビ受像機、ゲーム装置、プリンタ、複合機等の装置である。端末装置10ではOSが動作し、OS上でHTTPクライアントが動作している。HTTPクライアントとは、HTTPに従ってHTTPサーバと通信を行うアプリケーションのことである。HTTPクライアントの具体例として、ウェブブラウザがあり、他にもソフトウェアやファームウェアの更新システム、検索エンジン等が情報収集するために使うクローラボット、ロボット、スパイダとも呼ばれる等がある。端末装置10は、HTTPサーバ20に対してHTTPリクエストを送信し、HTTPサーバ20からHTTPレスポンスを受信する。HTTPサーバ20は、端末装置10から送信されたHTTPリクエストに基づいて、端末装置10におけるHTTPクライアントの属性を推定する。属性とは、HTTPクライアントの種類及びバージョンと、OSの種類及びバージョンである。図2は、HTTPサーバ20の機能構成の概略を示す図である。HTTPサーバ20は、バスで接続されたCPUCentralProcessingUnitやメモリや補助記憶装置などを備え、プログラムを実行する。HTTPサーバ20は、プログラムの実行により、通信部201、応答内容記憶部202、応答部203、クライアント推定部40を備える装置として機能する。なお、HTTPサーバ20の各機能の全て又は一部は、ASICApplicationSpecificIntegratedCircuitやPLDProgrammableLogicDeviceやFPGAFieldProgrammableGateArray等のハードウェアを用いて実現されても良い。プログラムは、コンピュータ読み取り可能な記録媒体に記録されても良い。コンピュータ読み取り可能な記録媒体とは、例えばフレキシブルディスク、光磁気ディスク、ROM、CD-ROM等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置である。プログラムは、電気通信回線を介して送信されても良い。通信部201は、ネットワーク30を介して端末装置10と通信する。通信部201は、HTTPリクエストを受信すると、受信したHTTPリクエストをクライアント推定部40及び応答部203に渡す。応答内容記憶部202は、磁気ハードディスク装置や半導体記憶装置などの記憶装置を用いて構成される。応答内容記憶部203は、応答内容テーブルを記憶する。図3は、応答内容テーブルの概略を示す図である。応答内容テーブルは、HTTPリクエストの条件と、クライアント推定部40の推定結果と、応答内容とを対応付けたテーブルである。推定結果として、応答内容テーブルは、HTTPクライアントの種類、HTTPクライアントのバージョン、OSの種類、OSのバージョンの項目を有する。図3の場合、受信されたHTTPリクエストの内容が条件R1に一致し、推定されたHTTPクライアントの種類、HTTPクライアントのバージョン、OSの種類、OSのバージョンがそれぞれm1、vm1、n1、vn1である場合には、応答内容がC1となる。応答内容テーブルにおけるHTTPリクエストの条件として以下のようなものがある。例えば、条件としてHTTPリクエストに含まれるリクエストURIUniformResourceIdentifierを設定してもよい。この場合、リクエストURIとHTTPクライアントの組み合わせ毎に応答内容を定めることができる。また、条件としてHTTPリクエストに含まれることがあるAcceptLanguageヘッダの内容を設定してもよい。この場合、AcceptLanguageヘッダの内容に応じて日本語や英語といった言語毎に、HTTPクライアント毎の応答内容を定めることができる。また、その他のヘッダ等、HTTPリクエストの内容を条件に指定し、その条件毎に、HTTPクライアント毎の応答内容を定めることもできる。応答内容テーブルにおける応答内容の具体例として以下のようなものがある。例えば、応答内容として、端末装置10に送信するコンテンツの識別情報が設定されても良い。この場合、同じHTTPリクエストの条件であっても、属性に応じて異なるコンテンツが送信される。また、原則として全てのHTTPクライアントに対して同じコンテンツが送信されるものの、特定の属性のHTTPクライアントに対してのみ他とは異なるコンテンツが送信されるように設定することも可能である。また、応答内容として特定のウェブページへのリダイレクトを送信することが設定されても良い。この場合、特定の属性のHTTPクライアントに対して、特定のウェブページへのリダイレクトが送信されるように設定することも可能である。図2に戻って説明を続ける。応答部203は、HTTPリクエストの条件と、クライアント推定部40による推定結果とに応じて、応答内容テーブルを参照することによって応答内容を決定する。応答部203は、決定した応答内容に基づいてHTTPレスポンスを生成する。応答部203は、通信部201を介してHTTPリクエストの送信元にHTTPレスポンスを送信する。応答部203が生成するHTTPレスポンスの具体例について説明する。例えば、応答内容テーブルの応答内容としてコンテンツの識別情報が設定されている場合、応答部203は、識別情報によって表されるコンテンツを端末装置10に出力させるためのHTTPレスポンスを生成する。例えば、識別情報によって表されるコンテンツがウェブページである場合には、応答部203は、ウェブページを表示させるためのHTMLHyperTextMarkupLanguageデータを生成しても良い。応答内容として、特定のウェブページへのリダイレクトを送信することが設定されている場合、応答部203は、特定のウェブページへのリダイレクトのコードを含むHTTPレスポンスを生成しても良い。クライアント推定部40は、HTTPリクエストの内容に基づいて、HTTPリクエストの送信元である端末装置10で動作しているHTTPクライアントの属性を推定する。クライアント推定部40は、規則記憶部402、推定部403を備える。規則記憶部402は、磁気ハードディスク装置や半導体記憶装置などの記憶装置を用いて構成される。規則記憶部402は、HTTPクライアントの属性毎に規則テーブルを記憶する。規則テーブルは、HTTPクライアントの属性毎に、そのHTTPクライアントから送信されるHTTPリクエストの記述の規則を表す。図4は、規則テーブルの具体例を示す図である。図4に示す規則テーブルには、HTTPクライアントの具体例としてブラウザに関する情報が記録されている。図4の規則テーブルは、ブラウザHTTPクライアントの種類がxxx、ブラウザのバージョンが1、OSの種類がyyy、OSのバージョンが1である属性のブラウザから送信されるHTTPリクエストの記述の規則を表す。ブラウザの種類、ブラウザのバージョン、OSの種類、OSのバージョン毎に規則テーブルが設けられる。必ず存在するヘッダの欄に設定されている値は、上記属性のブラウザから送信されるHTTPリクエストに必ず記載されているヘッダの項目の名前を示す。図4の規則テーブルに定義された属性のブラウザから送信されるHTTPリクエストには必ずAccept、AcceptLanguage、AcceptEncoding、UserAgent、Host、Connectionの項目が記述されている。必ず存在しないヘッダの欄に設定されている値は、上記属性のブラウザから送信されるHTTPリクエストに必ず記載されていない項目の名前を示す。図4の規則テーブルに定義された属性のブラウザから送信されるHTTPリクエストには必ずAcceptCharset、Dateの項目が記述されていない。ヘッダの順番の欄に設定されている値は、上記属性のブラウザから送信されるHTTPリクエストに記述されている項目の順番を示す。図4の規則テーブルに定義された属性のブラウザから送信されるHTTPリクエストにはAccept、AcceptLanguage、AcceptEncoding、IfModifiedSince、IfNoneMatch、UserAgent、Host、Connectionの項目がこの順番で記述されている。この欄に定義されている項目と項目との順番が守られていれば、その間にこの欄に定義されていない他の項目が入ったとしても、あるいはこの欄に定義されている項目が無かったとしても、規則を満たしたこととなる。例えば、AcceptとAcceptLanguageとの間に、この欄に定義されていない他の項目が存在したとしても、Acceptの後にAcceptLanguageが記述されている限りは、規則が満たされている。例えば、この欄に定義されているIfModifiedSince、IfNoneMatchが存在しなくても、存在している項目が定義の順番通り記述されている限りは、規則が満たされている。例えば、HTTPリクエストにAccept、KeepAlive、AcceptLanguage、AcceptEncoding、UserAgent、Host、Connectionという順番でヘッダが記述されていた場合について説明する。この場合、AcceptとAcceptLanguageの間に、この欄に定義されていない項目KeepAliveが挿入されている。さらに、この欄で定義されているIfModifiedSince、IfNoneMatchが存在しない。しかしながら、その他の項目は定義の順番通り記述されているので、規則は満たされている。個別条件の欄に設定されている事項は、各項目に設定された具体的な値に関する条件である。例えば、HTTPリクエストのAcceptの項目に設定されている値の末尾が,/と一致すれば、図4に示される規則を満たす。推定部403は、規則記憶部402に記憶されている規則テーブルに基づいて、受信されたHTTPリクエストの送信元である端末装置10で動作しているHTTPクライアントの属性を推定する。例えば、図4に示される規則テーブルに示された規則を全て満たすHTTPリクエストが受信された場合には、推定部403は、送信元のHTTPクライアントの属性について以下のように推定する。ブラウザHTTPクライアントの種類はxxx、ブラウザのバージョンは1、OSの種類はyyy、OSのバージョンは1。以下、推定部403について詳細に説明する。推定部403は、項目判定部404、順序判定部405、個別条件判定部406を備える。項目判定部404は、ある属性では必ず記述されている項目の有無と、ある属性では必ず記述されていない項目の有無と、に基づいて、HTTPリクエストの送信元である端末装置10で動作しているHTTPクライアントの属性の候補属性候補を判定する。具体的には以下の通りである。項目判定部404は、規則テーブルの必ず存在するヘッダの欄と、必ず存在しないヘッダの欄とに基づいて、規則テーブルの規則を満たすか否か全ての規則テーブルについて判定する。規則を満たす場合、項目判定部404は、その規則テーブルに応じた属性を、属性候補と判定する。一方、規則を満たさない場合、項目判定部404は、その規則テーブルに応じた属性を、属性候補から外す。なお、規則を満たす場合とは、規則テーブルの必ず存在するヘッダに規定されている項目が全てHTTPリクエストに記述されており、必ず存在しないヘッダに規定されている項目が全てHTTPリクエストに記述されていない場合である。順序判定部405は、記述された項目の順序に基づいて属性候補を判定する。具体的には以下の通りである。順序判定部405は、規則テーブルのヘッダの順番の欄に基づいて、規則テーブルの規則を満たすか否か、項目判定部404で属性候補と判定された全ての規則テーブルについて判定する。規則を満たす場合、順序判定部405は、その規則テーブルに応じた属性を、属性候補と判定する。一方、規則を満たさない場合、順序判定部405は、その規則テーブルに応じた属性を、属性候補から外す。個別条件判定部406は、ヘッダの項目の個別条件に基づいて、属性候補の中から属性を推定する。具体的には以下の通りである。個別条件判定部406は、規則テーブルの個別条件の欄に基づいて、規則テーブルの規則を満たすか否か、順序判定部405で属性候補と判定された全ての規則テーブルについて判定する。規則を満たす場合、個別条件判定部406は、その規則テーブルに応じた属性を、HTTPクライアントの属性と推定する。一方、規則を満たさない場合、個別条件判定部406は、その規則テーブルに応じた属性を、HTTPクライアントの属性ではないと推定する。個別条件判定部406は、推定結果を、クライアント推定部40の推定結果として応答部203に出力する。図5は、HTTPサーバ20の動作例を表すフローチャートである。まず、通信部201は、HTTPリクエスト以外のデータを受信した場合にはステップS101、受信したデータを応答部203に渡す。一方、通信部201は、HTTPリクエストを受信するとステップS101-YES、受信したHTTPリクエストをクライアント推定部40に渡す。項目判定部404は、受信したHTTPリクエストについて、必須項目必ず存在するヘッダの項目、必ず存在しないヘッダの項目に基づいて、HTTPクライアントの属性候補を判定するステップS102。順序判定部405は、受信したHTTPリクエストについて、項目の順序ヘッダの順番に基づいて、HTTPクライアントの属性候補を判定するステップS103。個別条件判定部406は、受信したHTTPリクエストについて、個別条件に基づいて、HTTPクライアントの属性候補の中から属性を推定するステップS104。そして、個別条件判定部406は、推定結果を応答部203に出力するステップS105。応答部203は、応答内容テーブルを参照し、受信されたHTTPリクエストの条件と、クライアント推定部40による推定結果と、に基づいて応答内容を決定するステップS106。応答部203は、決定した応答内容に基づいて、HTTPレスポンスを生成するステップS107。そして、応答部203は、生成したHTTPレスポンスを、通信部201を介して端末装置10へ送信するステップS108。このように構成されたHTTPサーバ40では、HTTPクライアントの属性毎に固有のHTTPリクエストの記述の規則に基づいて、HTTPクライアントの属性が判定される。このHTTPリクエストの記述の規則にはUserAgentヘッダ以外の規則も含まれている。そのため、たとえUserAgentヘッダに記載された情報に誤りがあったとしても、HTTPクライアントの属性をより正確に推定することが可能となる。また、規則は具体的に必須項目と、項目の記述の順序と、個別条件との三つの種類の規則で構成される。そのため、いずれか一つの規則のみに基づいて推定を行うよりもより正確な推定を行うことが可能となる。また、推定結果に応じた応答内容に基づいてHTTPレスポンスが生成される。そのため、端末装置10で動作しているHTTPクライアントの属性に応じた適切なHTTPレスポンスを端末装置10へ送信することが可能となる。<変形例>端末装置10及びHTTPサーバ20は、HTTPのみならず、HTTPSHypertextTransferProtocoloverSecureSocketLayerで通信しても良い。推定部403は、項目判定部404、順序判定部405、個別条件判定部406のうち、いずれか一つ又は二つのみによって構成されても良い。項目判定部404、順序判定部405、個別条件判定部406の処理の順序は、図5のフローチャートに示す順序に限定される必要は無い。いずれの順序の場合も、最初に処理をする機能部は全ての属性から属性候補を絞り、次に処理をする機能部は属性候補をさらに絞り、最後に処理をする機能部は絞られた属性候補の中から属性を推定する。また、上述したように推定部403は、項目判定部404、順序判定部405、個別条件判定部406のうち、いずれか一つ又は二つのみによって推定部403が構成される場合の処理の順序も、適宜設計される。属性は、HTTPクライアントの種類及びバージョンと、端末装置10で動作しているOSの種類及びバージョンとの全てを含むのではなく、これらのうちいずれか一つ又は複数の組み合わせであっても良い。クライアント推定部40は、HTTPサーバ20ではなく、他の装置に設けられても良い。例えば、クライアント推定部40は、ネットワーク30に設置された中継装置に設けられても良い。この場合、中継装置は以下のように動作しても良い。例えば、中継装置は、属性毎にHTTPリクエストを異なるネットワークへ転送しても良い。例えば、中継装置は、特定の属性によるHTTPリクエストのみを転送し、他の属性によるHTTPリクエストを廃棄しても良い。例えば、中継装置は、特定の属性によるHTTPリクエストのみをネットワークから遮断し、他の属性によるHTTPリクエストを遮断しなくても良い。例えば、中継装置は、特定の属性によるHTTPリクエストが受信された場合に、ネットワーク30の管理者に警告を発しても良い。例えば、クライアント推定部40は、端末装置10とHTTPサーバとの間に設けられたプロキシサーバProxyServerに設けられても良い。この場合、プロキシサーバは以下のように動作しても良い。例えば、プロキシサーバは、属性毎に異なるHTTPサーバへプロキシしても良い。例えば、プロキシサーバは、特定の属性によるHTTPリクエストのみをプロキシしても良い。例えば、プロキシサーバは、特定の属性によるHTTPリクエストのみプロキシせず、エラー画面などの所定のコンテンツをHTTPレスポンスとして返信しても良い。例えば、プロキシサーバは、特定の属性によるHTTPリクエストのみ特定のウェブページへリダイレクトさせるHTTPレスポンスを返送しても良い。例えば、プロキシサーバは、特定の属性によるHTTPリクエストが受信された場合に、プロキシサーバの管理者に警告を発しても良い。なお、プロキシサーバは、端末装置10とHTTPサーバとの間に一段設けられても良いし、多段設けられても良い。以上、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。"