クライアント推定装置、クライアント推定方法及びコンピュータプログラム
【課題】ＨＴＴＰリクエストの送信元の装置で動作しているＨＴＴＰクライアントの属性をより正確に推定すること。
【解決手段】ＨＴＴＰ（HyperText Transfer Protocol）リクエストの記述の規則を、ＨＴＴＰクライアントの属性毎に記憶する規則記憶部を備え、規則記憶部に記憶される規則と、端末装置から送信されたＨＴＴＰリクエストの記述と、に基づいて、端末装置におけるＨＴＴＰクライアントの属性を推定する。
【解決手段】ＨＴＴＰ（HyperText Transfer Protocol）リクエストの記述の規則を、ＨＴＴＰクライアントの属性毎に記憶する規則記憶部を備え、規則記憶部に記憶される規則と、端末装置から送信されたＨＴＴＰリクエストの記述と、に基づいて、端末装置におけるＨＴＴＰクライアントの属性を推定する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、端末装置から送信されるデータに基づいて、端末装置で動作しているＨＴＴＰ（HyperText Transfer Protocol）クライアントの属性を推定する技術に関する。
【背景技術】
【０００２】
従来、端末装置から送信されるＨＴＴＰリクエストの内容に基づいて、端末装置で動作しているＨＴＴＰクライアント（ユーザエージェントも含む。以下同様。）の属性を推定することが行われている。特許文献１に開示された技術は、ＨＴＴＰリクエストに含まれるUser-Agentヘッダの内容が格納された環境変数HTTP_USER_AGENTに、ウェブブラウザ（ＨＴＴＰクライアント）の種類及びバージョンと、クライアント端末で動作しているＯＳ（Operating System）の種類及びバージョンが記載されていることを利用している。すなわち、特許文献１に開示されたサーバは、環境変数HTTP_USER_AGENTに記載されている上記情報を読み出すことによって、クライアント端末で動作しているウェブブラウザの種類及びバージョンと、クライアント端末で動作しているＯＳの種類及びバージョンとが推定される。この場合、ウェブブラウザの種類及びバージョンと、ＯＳの種類及びバージョンが属性である。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０００−１０９２３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、User-Agentヘッダに記載されている情報が正確性に欠ける場合があるという問題があった。そのため、User-Agentヘッダの内容がそのまま格納された環境変数HTTP_USER_AGENTの情報のみに基づいて推定を行うと、誤った推定結果が得られる場合があった。
上記事情に鑑み、本発明は、ＨＴＴＰリクエストの送信元の装置で動作しているＨＴＴＰクライアントの属性をより正確に推定する技術を提供することを目的としている。
【課題を解決するための手段】
【０００５】
本発明の一態様は、ＨＴＴＰリクエストの記述の規則を、ＨＴＴＰクライアントの属性毎に記憶する規則記憶部と、前記規則記憶部に記憶される規則と、端末装置から送信されたＨＴＴＰリクエストの記述と、に基づいて、前記端末装置におけるＨＴＴＰクライアントの属性を推定する推定部と、を備えるクライアント推定装置である。
【０００６】
本発明の一態様は、ＨＴＴＰリクエストの記述の規則を、ＨＴＴＰクライアントの属性毎に記憶する規則記憶部を備える情報処理装置が、前記規則記憶部に記憶される規則を読み出すステップと、前記情報処理装置が、読み出された前記規則と、端末装置から送信されたＨＴＴＰリクエストの記述と、に基づいて、前記端末装置におけるＨＴＴＰクライアントの属性を推定するステップと、を有するクライアント推定方法である。
【０００７】
本発明の一態様は、ＨＴＴＰリクエストの記述の規則を、ＨＴＴＰクライアントの属性毎に記憶する規則記憶部を備える情報処理装置に対し、前記規則記憶部に記憶される規則を読み出すステップと、読み出された前記規則と、端末装置から送信されたＨＴＴＰリクエストの記述と、に基づいて、前記端末装置におけるＨＴＴＰクライアントの属性を推定するステップと、を実行させるためのコンピュータプログラムである。
【発明の効果】
【０００８】
本発明により、ＨＴＴＰリクエストの送信元の装置で動作しているＨＴＴＰクライアントの属性をより正確に推定することが可能となる。
【図面の簡単な説明】
【０００９】
【図１】クライアント推定システムのシステム構成を表すシステム構成図である。
【図２】ＨＴＴＰサーバの機能構成の概略を示す図である。
【図３】応答内容テーブルの概略を示す図である。
【図４】規則テーブルの具体例を示す図である。
【図５】ＨＴＴＰサーバの動作例を表すフローチャートである。
【発明を実施するための形態】
【００１０】
図１は、クライアント推定システム１のシステム構成を表すシステム構成図である。クライアント推定システム１は、端末装置１０、ＨＴＴＰサーバ２０を備える。端末装置１０とＨＴＴＰサーバ２０とは、ネットワーク３０を介して互いに通信可能である。
端末装置１０は、パーソナルコンピュータ、携帯電話、スマートフォン、テレビ受像機、ゲーム装置、プリンタ、複合機等の装置である。端末装置１０ではＯＳが動作し、ＯＳ上でＨＴＴＰクライアントが動作している。ＨＴＴＰクライアントとは、ＨＴＴＰに従ってＨＴＴＰサーバと通信を行うアプリケーションのことである。ＨＴＴＰクライアントの具体例として、ウェブブラウザがあり、他にもソフトウェアやファームウェアの更新システム、検索エンジン等が情報収集するために使うクローラ（ボット、ロボット、スパイダとも呼ばれる）等がある。端末装置１０は、ＨＴＴＰサーバ２０に対してＨＴＴＰリクエストを送信し、ＨＴＴＰサーバ２０からＨＴＴＰレスポンスを受信する。
ＨＴＴＰサーバ２０は、端末装置１０から送信されたＨＴＴＰリクエストに基づいて、端末装置１０におけるＨＴＴＰクライアントの属性を推定する。属性とは、ＨＴＴＰクライアントの種類及びバージョンと、ＯＳの種類及びバージョンである。
【００１１】
図２は、ＨＴＴＰサーバ２０の機能構成の概略を示す図である。ＨＴＴＰサーバ２０は、バスで接続されたＣＰＵ（Central Processing Unit）やメモリや補助記憶装置などを備え、プログラムを実行する。ＨＴＴＰサーバ２０は、プログラムの実行により、通信部２０１、応答内容記憶部２０２、応答部２０３、クライアント推定部４０を備える装置として機能する。なお、ＨＴＴＰサーバ２０の各機能の全て又は一部は、ＡＳＩＣ（Application Specific Integrated Circuit）やＰＬＤ（Programmable Logic Device）やＦＰＧＡ（Field Programmable Gate Array）等のハードウェアを用いて実現されても良い。プログラムは、コンピュータ読み取り可能な記録媒体に記録されても良い。コンピュータ読み取り可能な記録媒体とは、例えばフレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置である。プログラムは、電気通信回線を介して送信されても良い。
【００１２】
通信部２０１は、ネットワーク３０を介して端末装置１０と通信する。通信部２０１は、ＨＴＴＰリクエストを受信すると、受信したＨＴＴＰリクエストをクライアント推定部４０及び応答部２０３に渡す。
応答内容記憶部２０２は、磁気ハードディスク装置や半導体記憶装置などの記憶装置を用いて構成される。応答内容記憶部２０３は、応答内容テーブルを記憶する。図３は、応答内容テーブルの概略を示す図である。応答内容テーブルは、ＨＴＴＰリクエストの条件と、クライアント推定部４０の推定結果と、応答内容とを対応付けたテーブルである。推定結果として、応答内容テーブルは、ＨＴＴＰクライアントの種類、ＨＴＴＰクライアントのバージョン、ＯＳの種類、ＯＳのバージョンの項目を有する。図３の場合、受信されたＨＴＴＰリクエストの内容が条件Ｒ１に一致し、推定されたＨＴＴＰクライアントの種類、ＨＴＴＰクライアントのバージョン、ＯＳの種類、ＯＳのバージョンがそれぞれｍ１、ｖｍ１、ｎ１、ｖｎ１である場合には、応答内容がＣ１となる。
応答内容テーブルにおけるＨＴＴＰリクエストの条件として以下のようなものがある。例えば、条件としてＨＴＴＰリクエストに含まれるリクエストＵＲＩ（Uniform Resource Identifier）を設定してもよい。この場合、リクエストＵＲＩとＨＴＴＰクライアントの組み合わせ毎に応答内容を定めることができる。また、条件としてＨＴＴＰリクエストに含まれることがあるAccept-Languageヘッダの内容を設定してもよい。この場合、Accept-Language ヘッダの内容に応じて日本語や英語といった言語毎に、ＨＴＴＰクライアント毎の応答内容を定めることができる。また、その他のヘッダ等、ＨＴＴＰリクエストの内容を条件に指定し、その条件毎に、ＨＴＴＰクライアント毎の応答内容を定めることもできる。
【００１３】
応答内容テーブルにおける応答内容の具体例として以下のようなものがある。例えば、応答内容として、端末装置１０に送信するコンテンツの識別情報が設定されても良い。この場合、同じＨＴＴＰリクエストの条件であっても、属性に応じて異なるコンテンツが送信される。また、原則として全てのＨＴＴＰクライアントに対して同じコンテンツが送信されるものの、特定の属性のＨＴＴＰクライアントに対してのみ他とは異なるコンテンツが送信されるように設定することも可能である。また、応答内容として特定のウェブページへのリダイレクトを送信することが設定されても良い。この場合、特定の属性のＨＴＴＰクライアントに対して、特定のウェブページへのリダイレクトが送信されるように設定することも可能である。
【００１４】
図２に戻って説明を続ける。応答部２０３は、ＨＴＴＰリクエストの条件と、クライアント推定部４０による推定結果とに応じて、応答内容テーブルを参照することによって応答内容を決定する。応答部２０３は、決定した応答内容に基づいてＨＴＴＰレスポンスを生成する。応答部２０３は、通信部２０１を介してＨＴＴＰリクエストの送信元にＨＴＴＰレスポンスを送信する。
【００１５】
応答部２０３が生成するＨＴＴＰレスポンスの具体例について説明する。例えば、応答内容テーブルの応答内容としてコンテンツの識別情報が設定されている場合、応答部２０３は、識別情報によって表されるコンテンツを端末装置１０に出力させるためのＨＴＴＰレスポンスを生成する。例えば、識別情報によって表されるコンテンツがウェブページである場合には、応答部２０３は、ウェブページを表示させるためのＨＴＭＬ（HyperText Markup Language）データを生成しても良い。応答内容として、特定のウェブページへのリダイレクトを送信することが設定されている場合、応答部２０３は、特定のウェブページへのリダイレクトのコードを含むＨＴＴＰレスポンスを生成しても良い。
【００１６】
クライアント推定部４０は、ＨＴＴＰリクエストの内容に基づいて、ＨＴＴＰリクエストの送信元である端末装置１０で動作しているＨＴＴＰクライアントの属性を推定する。クライアント推定部４０は、規則記憶部４０２、推定部４０３を備える。
規則記憶部４０２は、磁気ハードディスク装置や半導体記憶装置などの記憶装置を用いて構成される。規則記憶部４０２は、ＨＴＴＰクライアントの属性毎に規則テーブルを記憶する。規則テーブルは、ＨＴＴＰクライアントの属性毎に、そのＨＴＴＰクライアントから送信されるＨＴＴＰリクエストの記述の規則を表す。
【００１７】
図４は、規則テーブルの具体例を示す図である。図４に示す規則テーブルには、ＨＴＴＰクライアントの具体例としてブラウザに関する情報が記録されている。図４の規則テーブルは、ブラウザ（ＨＴＴＰクライアント）の種類が“ｘｘｘ”、ブラウザのバージョンが“１”、ＯＳの種類が“ｙｙｙ”、ＯＳのバージョンが“１”である属性のブラウザから送信されるＨＴＴＰリクエストの記述の規則を表す。ブラウザの種類、ブラウザのバージョン、ＯＳの種類、ＯＳのバージョン毎に規則テーブルが設けられる。
【００１８】
必ず存在するヘッダの欄に設定されている値は、上記属性のブラウザから送信されるＨＴＴＰリクエストに必ず記載されているヘッダの項目の名前を示す。図４の規則テーブルに定義された属性のブラウザから送信されるＨＴＴＰリクエストには必ず“Accept”、“Accept-Language”、“Accept-Encoding”、“User-Agent”、“Host”、“Connection”の項目が記述されている。
【００１９】
必ず存在しないヘッダの欄に設定されている値は、上記属性のブラウザから送信されるＨＴＴＰリクエストに必ず記載されていない項目の名前を示す。図４の規則テーブルに定義された属性のブラウザから送信されるＨＴＴＰリクエストには必ず“Accept-Charset”、“Date”の項目が記述されていない。
【００２０】
ヘッダの順番の欄に設定されている値は、上記属性のブラウザから送信されるＨＴＴＰリクエストに記述されている項目の順番を示す。図４の規則テーブルに定義された属性のブラウザから送信されるＨＴＴＰリクエストには“Accept”、“Accept-Language”、“Accept-Encoding”、“If-Modified-Since”、“If-None-Match”、“User-Agent”、“Host”、“Connection”の項目がこの順番で記述されている。この欄に定義されている項目と項目との順番が守られていれば、その間にこの欄に定義されていない他の項目が入ったとしても、あるいはこの欄に定義されている項目が無かったとしても、規則を満たしたこととなる。例えば、“Accept”と“Accept-Language”との間に、この欄に定義されていない他の項目が存在したとしても、“Accept”の後に“Accept-Language”が記述されている限りは、規則が満たされている。例えば、この欄に定義されている“If-Modified-Since”、“If-None-Match”が存在しなくても、存在している項目が定義の順番通り記述されている限りは、規則が満たされている。
例えば、ＨＴＴＰリクエストに“Accept”、“Keep-Alive”、“Accept-Language”、“Accept-Encoding”、“User-Agent”、“Host”、“Connection”という順番でヘッダが記述されていた場合について説明する。この場合、“Accept”と“Accept-Language”の間に、この欄に定義されていない項目“Keep-Alive”が挿入されている。さらに、この欄で定義されている“If-Modified-Since”、“If-None-Match”が存在しない。しかしながら、その他の項目は定義の順番通り記述されているので、規則は満たされている。
個別条件の欄に設定されている事項は、各項目に設定された具体的な値に関する条件である。例えば、ＨＴＴＰリクエストの”Accept”の項目に設定されている値の末尾が「，＊／＊」と一致すれば、図４に示される規則を満たす。
【００２１】
推定部４０３は、規則記憶部４０２に記憶されている規則テーブルに基づいて、受信されたＨＴＴＰリクエストの送信元である端末装置１０で動作しているＨＴＴＰクライアントの属性を推定する。例えば、図４に示される規則テーブルに示された規則を全て満たすＨＴＴＰリクエストが受信された場合には、推定部４０３は、送信元のＨＴＴＰクライアントの属性について以下のように推定する。ブラウザ（ＨＴＴＰクライアント）の種類は“ｘｘｘ”、ブラウザのバージョンは“１”、ＯＳの種類は“ｙｙｙ”、ＯＳのバージョンは“１”。
【００２２】
以下、推定部４０３について詳細に説明する。推定部４０３は、項目判定部４０４、順序判定部４０５、個別条件判定部４０６を備える。
項目判定部４０４は、ある属性では必ず記述されている項目の有無と、ある属性では必ず記述されていない項目の有無と、に基づいて、ＨＴＴＰリクエストの送信元である端末装置１０で動作しているＨＴＴＰクライアントの属性の候補（属性候補）を判定する。具体的には以下の通りである。項目判定部４０４は、規則テーブルの必ず存在するヘッダの欄と、必ず存在しないヘッダの欄とに基づいて、規則テーブルの規則を満たすか否か全ての規則テーブルについて判定する。規則を満たす場合、項目判定部４０４は、その規則テーブルに応じた属性を、属性候補と判定する。一方、規則を満たさない場合、項目判定部４０４は、その規則テーブルに応じた属性を、属性候補から外す。なお、規則を満たす場合とは、規則テーブルの必ず存在するヘッダに規定されている項目が全てＨＴＴＰリクエストに記述されており、必ず存在しないヘッダに規定されている項目が全てＨＴＴＰリクエストに記述されていない場合である。
【００２３】
順序判定部４０５は、記述された項目の順序に基づいて属性候補を判定する。具体的には以下の通りである。順序判定部４０５は、規則テーブルのヘッダの順番の欄に基づいて、規則テーブルの規則を満たすか否か、項目判定部４０４で属性候補と判定された全ての規則テーブルについて判定する。規則を満たす場合、順序判定部４０５は、その規則テーブルに応じた属性を、属性候補と判定する。一方、規則を満たさない場合、順序判定部４０５は、その規則テーブルに応じた属性を、属性候補から外す。
【００２４】
個別条件判定部４０６は、ヘッダの項目の個別条件に基づいて、属性候補の中から属性を推定する。具体的には以下の通りである。個別条件判定部４０６は、規則テーブルの個別条件の欄に基づいて、規則テーブルの規則を満たすか否か、順序判定部４０５で属性候補と判定された全ての規則テーブルについて判定する。規則を満たす場合、個別条件判定部４０６は、その規則テーブルに応じた属性を、ＨＴＴＰクライアントの属性と推定する。一方、規則を満たさない場合、個別条件判定部４０６は、その規則テーブルに応じた属性を、ＨＴＴＰクライアントの属性ではないと推定する。個別条件判定部４０６は、推定結果を、クライアント推定部４０の推定結果として応答部２０３に出力する。
【００２５】
図５は、ＨＴＴＰサーバ２０の動作例を表すフローチャートである。まず、通信部２０１は、ＨＴＴＰリクエスト以外のデータを受信した場合には（ステップＳ１０１）、受信したデータを応答部２０３に渡す。一方、通信部２０１は、ＨＴＴＰリクエストを受信すると（ステップＳ１０１−ＹＥＳ）、受信したＨＴＴＰリクエストをクライアント推定部４０に渡す。項目判定部４０４は、受信したＨＴＴＰリクエストについて、必須項目（必ず存在するヘッダの項目、必ず存在しないヘッダの項目）に基づいて、ＨＴＴＰクライアントの属性候補を判定する（ステップＳ１０２）。順序判定部４０５は、受信したＨＴＴＰリクエストについて、項目の順序（ヘッダの順番）に基づいて、ＨＴＴＰクライアントの属性候補を判定する（ステップＳ１０３）。個別条件判定部４０６は、受信したＨＴＴＰリクエストについて、個別条件に基づいて、ＨＴＴＰクライアントの属性候補の中から属性を推定する（ステップＳ１０４）。そして、個別条件判定部４０６は、推定結果を応答部２０３に出力する（ステップＳ１０５）。
【００２６】
応答部２０３は、応答内容テーブルを参照し、受信されたＨＴＴＰリクエストの条件と、クライアント推定部４０による推定結果と、に基づいて応答内容を決定する（ステップＳ１０６）。応答部２０３は、決定した応答内容に基づいて、ＨＴＴＰレスポンスを生成する（ステップＳ１０７）。そして、応答部２０３は、生成したＨＴＴＰレスポンスを、通信部２０１を介して端末装置１０へ送信する（ステップＳ１０８）。
【００２７】
このように構成されたＨＴＴＰサーバ４０では、ＨＴＴＰクライアントの属性毎に固有のＨＴＴＰリクエストの記述の規則に基づいて、ＨＴＴＰクライアントの属性が判定される。このＨＴＴＰリクエストの記述の規則にはUser-Agent ヘッダ以外の規則も含まれている。そのため、たとえUser-Agentヘッダに記載された情報に誤りがあったとしても、ＨＴＴＰクライアントの属性をより正確に推定することが可能となる。
【００２８】
また、規則は具体的に必須項目と、項目の記述の順序と、個別条件との三つの種類の規則で構成される。そのため、いずれか一つの規則のみに基づいて推定を行うよりもより正確な推定を行うことが可能となる。
また、推定結果に応じた応答内容に基づいてＨＴＴＰレスポンスが生成される。そのため、端末装置１０で動作しているＨＴＴＰクライアントの属性に応じた適切なＨＴＴＰレスポンスを端末装置１０へ送信することが可能となる。
【００２９】
＜変形例＞
端末装置１０及びＨＴＴＰサーバ２０は、ＨＴＴＰのみならず、ＨＴＴＰＳ（Hypertext Transfer Protocol over Secure Socket Layer）で通信しても良い。
推定部４０３は、項目判定部４０４、順序判定部４０５、個別条件判定部４０６のうち、いずれか一つ又は二つのみによって構成されても良い。
【００３０】
項目判定部４０４、順序判定部４０５、個別条件判定部４０６の処理の順序は、図５のフローチャートに示す順序に限定される必要は無い。いずれの順序の場合も、最初に処理をする機能部は全ての属性から属性候補を絞り、次に処理をする機能部は属性候補をさらに絞り、最後に処理をする機能部は絞られた属性候補の中から属性を推定する。また、上述したように推定部４０３は、項目判定部４０４、順序判定部４０５、個別条件判定部４０６のうち、いずれか一つ又は二つのみによって推定部４０３が構成される場合の処理の順序も、適宜設計される。
属性は、ＨＴＴＰクライアントの種類及びバージョンと、端末装置１０で動作しているＯＳの種類及びバージョンとの全てを含むのではなく、これらのうちいずれか一つ又は複数の組み合わせであっても良い。
【００３１】
クライアント推定部４０は、ＨＴＴＰサーバ２０ではなく、他の装置に設けられても良い。
例えば、クライアント推定部４０は、ネットワーク３０に設置された中継装置に設けられても良い。この場合、中継装置は以下のように動作しても良い。例えば、中継装置は、属性毎にＨＴＴＰリクエストを異なるネットワークへ転送しても良い。例えば、中継装置は、特定の属性によるＨＴＴＰリクエストのみを転送し、他の属性によるＨＴＴＰリクエストを廃棄しても良い。例えば、中継装置は、特定の属性によるＨＴＴＰリクエストのみをネットワークから遮断し、他の属性によるＨＴＴＰリクエストを遮断しなくても良い。例えば、中継装置は、特定の属性によるＨＴＴＰリクエストが受信された場合に、ネットワーク３０の管理者に警告を発しても良い。
【００３２】
例えば、クライアント推定部４０は、端末装置１０とＨＴＴＰサーバとの間に設けられたプロキシサーバ（Proxy Server）に設けられても良い。この場合、プロキシサーバは以下のように動作しても良い。例えば、プロキシサーバは、属性毎に異なるＨＴＴＰサーバへプロキシしても良い。例えば、プロキシサーバは、特定の属性によるＨＴＴＰリクエストのみをプロキシしても良い。例えば、プロキシサーバは、特定の属性によるＨＴＴＰリクエストのみプロキシせず、エラー画面などの所定のコンテンツをＨＴＴＰレスポンスとして返信しても良い。例えば、プロキシサーバは、特定の属性によるＨＴＴＰリクエストのみ特定のウェブページへリダイレクトさせるＨＴＴＰレスポンスを返送しても良い。例えば、プロキシサーバは、特定の属性によるＨＴＴＰリクエストが受信された場合に、プロキシサーバの管理者に警告を発しても良い。なお、プロキシサーバは、端末装置１０とＨＴＴＰサーバとの間に一段設けられても良いし、多段設けられても良い。
【００３３】
以上、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。
【符号の説明】
【００３４】
１…クライアント推定システム， １０…端末装置， ２０…ＨＴＴＰサーバ， ３０…ネットワーク， ２０１…通信部， ２０２…応答内容記憶部， ２０３…応答部， ４０…クライアント推定部， ４０２…規則テーブル記憶部， ４０３…推定部， ４０４…項目判定部， ４０５…順序判定部， ４０６…個別条件判定部
【技術分野】
【０００１】
本発明は、端末装置から送信されるデータに基づいて、端末装置で動作しているＨＴＴＰ（HyperText Transfer Protocol）クライアントの属性を推定する技術に関する。
【背景技術】
【０００２】
従来、端末装置から送信されるＨＴＴＰリクエストの内容に基づいて、端末装置で動作しているＨＴＴＰクライアント（ユーザエージェントも含む。以下同様。）の属性を推定することが行われている。特許文献１に開示された技術は、ＨＴＴＰリクエストに含まれるUser-Agentヘッダの内容が格納された環境変数HTTP_USER_AGENTに、ウェブブラウザ（ＨＴＴＰクライアント）の種類及びバージョンと、クライアント端末で動作しているＯＳ（Operating System）の種類及びバージョンが記載されていることを利用している。すなわち、特許文献１に開示されたサーバは、環境変数HTTP_USER_AGENTに記載されている上記情報を読み出すことによって、クライアント端末で動作しているウェブブラウザの種類及びバージョンと、クライアント端末で動作しているＯＳの種類及びバージョンとが推定される。この場合、ウェブブラウザの種類及びバージョンと、ＯＳの種類及びバージョンが属性である。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０００−１０９２３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、User-Agentヘッダに記載されている情報が正確性に欠ける場合があるという問題があった。そのため、User-Agentヘッダの内容がそのまま格納された環境変数HTTP_USER_AGENTの情報のみに基づいて推定を行うと、誤った推定結果が得られる場合があった。
上記事情に鑑み、本発明は、ＨＴＴＰリクエストの送信元の装置で動作しているＨＴＴＰクライアントの属性をより正確に推定する技術を提供することを目的としている。
【課題を解決するための手段】
【０００５】
本発明の一態様は、ＨＴＴＰリクエストの記述の規則を、ＨＴＴＰクライアントの属性毎に記憶する規則記憶部と、前記規則記憶部に記憶される規則と、端末装置から送信されたＨＴＴＰリクエストの記述と、に基づいて、前記端末装置におけるＨＴＴＰクライアントの属性を推定する推定部と、を備えるクライアント推定装置である。
【０００６】
本発明の一態様は、ＨＴＴＰリクエストの記述の規則を、ＨＴＴＰクライアントの属性毎に記憶する規則記憶部を備える情報処理装置が、前記規則記憶部に記憶される規則を読み出すステップと、前記情報処理装置が、読み出された前記規則と、端末装置から送信されたＨＴＴＰリクエストの記述と、に基づいて、前記端末装置におけるＨＴＴＰクライアントの属性を推定するステップと、を有するクライアント推定方法である。
【０００７】
本発明の一態様は、ＨＴＴＰリクエストの記述の規則を、ＨＴＴＰクライアントの属性毎に記憶する規則記憶部を備える情報処理装置に対し、前記規則記憶部に記憶される規則を読み出すステップと、読み出された前記規則と、端末装置から送信されたＨＴＴＰリクエストの記述と、に基づいて、前記端末装置におけるＨＴＴＰクライアントの属性を推定するステップと、を実行させるためのコンピュータプログラムである。
【発明の効果】
【０００８】
本発明により、ＨＴＴＰリクエストの送信元の装置で動作しているＨＴＴＰクライアントの属性をより正確に推定することが可能となる。
【図面の簡単な説明】
【０００９】
【図１】クライアント推定システムのシステム構成を表すシステム構成図である。
【図２】ＨＴＴＰサーバの機能構成の概略を示す図である。
【図３】応答内容テーブルの概略を示す図である。
【図４】規則テーブルの具体例を示す図である。
【図５】ＨＴＴＰサーバの動作例を表すフローチャートである。
【発明を実施するための形態】
【００１０】
図１は、クライアント推定システム１のシステム構成を表すシステム構成図である。クライアント推定システム１は、端末装置１０、ＨＴＴＰサーバ２０を備える。端末装置１０とＨＴＴＰサーバ２０とは、ネットワーク３０を介して互いに通信可能である。
端末装置１０は、パーソナルコンピュータ、携帯電話、スマートフォン、テレビ受像機、ゲーム装置、プリンタ、複合機等の装置である。端末装置１０ではＯＳが動作し、ＯＳ上でＨＴＴＰクライアントが動作している。ＨＴＴＰクライアントとは、ＨＴＴＰに従ってＨＴＴＰサーバと通信を行うアプリケーションのことである。ＨＴＴＰクライアントの具体例として、ウェブブラウザがあり、他にもソフトウェアやファームウェアの更新システム、検索エンジン等が情報収集するために使うクローラ（ボット、ロボット、スパイダとも呼ばれる）等がある。端末装置１０は、ＨＴＴＰサーバ２０に対してＨＴＴＰリクエストを送信し、ＨＴＴＰサーバ２０からＨＴＴＰレスポンスを受信する。
ＨＴＴＰサーバ２０は、端末装置１０から送信されたＨＴＴＰリクエストに基づいて、端末装置１０におけるＨＴＴＰクライアントの属性を推定する。属性とは、ＨＴＴＰクライアントの種類及びバージョンと、ＯＳの種類及びバージョンである。
【００１１】
図２は、ＨＴＴＰサーバ２０の機能構成の概略を示す図である。ＨＴＴＰサーバ２０は、バスで接続されたＣＰＵ（Central Processing Unit）やメモリや補助記憶装置などを備え、プログラムを実行する。ＨＴＴＰサーバ２０は、プログラムの実行により、通信部２０１、応答内容記憶部２０２、応答部２０３、クライアント推定部４０を備える装置として機能する。なお、ＨＴＴＰサーバ２０の各機能の全て又は一部は、ＡＳＩＣ（Application Specific Integrated Circuit）やＰＬＤ（Programmable Logic Device）やＦＰＧＡ（Field Programmable Gate Array）等のハードウェアを用いて実現されても良い。プログラムは、コンピュータ読み取り可能な記録媒体に記録されても良い。コンピュータ読み取り可能な記録媒体とは、例えばフレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置である。プログラムは、電気通信回線を介して送信されても良い。
【００１２】
通信部２０１は、ネットワーク３０を介して端末装置１０と通信する。通信部２０１は、ＨＴＴＰリクエストを受信すると、受信したＨＴＴＰリクエストをクライアント推定部４０及び応答部２０３に渡す。
応答内容記憶部２０２は、磁気ハードディスク装置や半導体記憶装置などの記憶装置を用いて構成される。応答内容記憶部２０３は、応答内容テーブルを記憶する。図３は、応答内容テーブルの概略を示す図である。応答内容テーブルは、ＨＴＴＰリクエストの条件と、クライアント推定部４０の推定結果と、応答内容とを対応付けたテーブルである。推定結果として、応答内容テーブルは、ＨＴＴＰクライアントの種類、ＨＴＴＰクライアントのバージョン、ＯＳの種類、ＯＳのバージョンの項目を有する。図３の場合、受信されたＨＴＴＰリクエストの内容が条件Ｒ１に一致し、推定されたＨＴＴＰクライアントの種類、ＨＴＴＰクライアントのバージョン、ＯＳの種類、ＯＳのバージョンがそれぞれｍ１、ｖｍ１、ｎ１、ｖｎ１である場合には、応答内容がＣ１となる。
応答内容テーブルにおけるＨＴＴＰリクエストの条件として以下のようなものがある。例えば、条件としてＨＴＴＰリクエストに含まれるリクエストＵＲＩ（Uniform Resource Identifier）を設定してもよい。この場合、リクエストＵＲＩとＨＴＴＰクライアントの組み合わせ毎に応答内容を定めることができる。また、条件としてＨＴＴＰリクエストに含まれることがあるAccept-Languageヘッダの内容を設定してもよい。この場合、Accept-Language ヘッダの内容に応じて日本語や英語といった言語毎に、ＨＴＴＰクライアント毎の応答内容を定めることができる。また、その他のヘッダ等、ＨＴＴＰリクエストの内容を条件に指定し、その条件毎に、ＨＴＴＰクライアント毎の応答内容を定めることもできる。
【００１３】
応答内容テーブルにおける応答内容の具体例として以下のようなものがある。例えば、応答内容として、端末装置１０に送信するコンテンツの識別情報が設定されても良い。この場合、同じＨＴＴＰリクエストの条件であっても、属性に応じて異なるコンテンツが送信される。また、原則として全てのＨＴＴＰクライアントに対して同じコンテンツが送信されるものの、特定の属性のＨＴＴＰクライアントに対してのみ他とは異なるコンテンツが送信されるように設定することも可能である。また、応答内容として特定のウェブページへのリダイレクトを送信することが設定されても良い。この場合、特定の属性のＨＴＴＰクライアントに対して、特定のウェブページへのリダイレクトが送信されるように設定することも可能である。
【００１４】
図２に戻って説明を続ける。応答部２０３は、ＨＴＴＰリクエストの条件と、クライアント推定部４０による推定結果とに応じて、応答内容テーブルを参照することによって応答内容を決定する。応答部２０３は、決定した応答内容に基づいてＨＴＴＰレスポンスを生成する。応答部２０３は、通信部２０１を介してＨＴＴＰリクエストの送信元にＨＴＴＰレスポンスを送信する。
【００１５】
応答部２０３が生成するＨＴＴＰレスポンスの具体例について説明する。例えば、応答内容テーブルの応答内容としてコンテンツの識別情報が設定されている場合、応答部２０３は、識別情報によって表されるコンテンツを端末装置１０に出力させるためのＨＴＴＰレスポンスを生成する。例えば、識別情報によって表されるコンテンツがウェブページである場合には、応答部２０３は、ウェブページを表示させるためのＨＴＭＬ（HyperText Markup Language）データを生成しても良い。応答内容として、特定のウェブページへのリダイレクトを送信することが設定されている場合、応答部２０３は、特定のウェブページへのリダイレクトのコードを含むＨＴＴＰレスポンスを生成しても良い。
【００１６】
クライアント推定部４０は、ＨＴＴＰリクエストの内容に基づいて、ＨＴＴＰリクエストの送信元である端末装置１０で動作しているＨＴＴＰクライアントの属性を推定する。クライアント推定部４０は、規則記憶部４０２、推定部４０３を備える。
規則記憶部４０２は、磁気ハードディスク装置や半導体記憶装置などの記憶装置を用いて構成される。規則記憶部４０２は、ＨＴＴＰクライアントの属性毎に規則テーブルを記憶する。規則テーブルは、ＨＴＴＰクライアントの属性毎に、そのＨＴＴＰクライアントから送信されるＨＴＴＰリクエストの記述の規則を表す。
【００１７】
図４は、規則テーブルの具体例を示す図である。図４に示す規則テーブルには、ＨＴＴＰクライアントの具体例としてブラウザに関する情報が記録されている。図４の規則テーブルは、ブラウザ（ＨＴＴＰクライアント）の種類が“ｘｘｘ”、ブラウザのバージョンが“１”、ＯＳの種類が“ｙｙｙ”、ＯＳのバージョンが“１”である属性のブラウザから送信されるＨＴＴＰリクエストの記述の規則を表す。ブラウザの種類、ブラウザのバージョン、ＯＳの種類、ＯＳのバージョン毎に規則テーブルが設けられる。
【００１８】
必ず存在するヘッダの欄に設定されている値は、上記属性のブラウザから送信されるＨＴＴＰリクエストに必ず記載されているヘッダの項目の名前を示す。図４の規則テーブルに定義された属性のブラウザから送信されるＨＴＴＰリクエストには必ず“Accept”、“Accept-Language”、“Accept-Encoding”、“User-Agent”、“Host”、“Connection”の項目が記述されている。
【００１９】
必ず存在しないヘッダの欄に設定されている値は、上記属性のブラウザから送信されるＨＴＴＰリクエストに必ず記載されていない項目の名前を示す。図４の規則テーブルに定義された属性のブラウザから送信されるＨＴＴＰリクエストには必ず“Accept-Charset”、“Date”の項目が記述されていない。
【００２０】
ヘッダの順番の欄に設定されている値は、上記属性のブラウザから送信されるＨＴＴＰリクエストに記述されている項目の順番を示す。図４の規則テーブルに定義された属性のブラウザから送信されるＨＴＴＰリクエストには“Accept”、“Accept-Language”、“Accept-Encoding”、“If-Modified-Since”、“If-None-Match”、“User-Agent”、“Host”、“Connection”の項目がこの順番で記述されている。この欄に定義されている項目と項目との順番が守られていれば、その間にこの欄に定義されていない他の項目が入ったとしても、あるいはこの欄に定義されている項目が無かったとしても、規則を満たしたこととなる。例えば、“Accept”と“Accept-Language”との間に、この欄に定義されていない他の項目が存在したとしても、“Accept”の後に“Accept-Language”が記述されている限りは、規則が満たされている。例えば、この欄に定義されている“If-Modified-Since”、“If-None-Match”が存在しなくても、存在している項目が定義の順番通り記述されている限りは、規則が満たされている。
例えば、ＨＴＴＰリクエストに“Accept”、“Keep-Alive”、“Accept-Language”、“Accept-Encoding”、“User-Agent”、“Host”、“Connection”という順番でヘッダが記述されていた場合について説明する。この場合、“Accept”と“Accept-Language”の間に、この欄に定義されていない項目“Keep-Alive”が挿入されている。さらに、この欄で定義されている“If-Modified-Since”、“If-None-Match”が存在しない。しかしながら、その他の項目は定義の順番通り記述されているので、規則は満たされている。
個別条件の欄に設定されている事項は、各項目に設定された具体的な値に関する条件である。例えば、ＨＴＴＰリクエストの”Accept”の項目に設定されている値の末尾が「，＊／＊」と一致すれば、図４に示される規則を満たす。
【００２１】
推定部４０３は、規則記憶部４０２に記憶されている規則テーブルに基づいて、受信されたＨＴＴＰリクエストの送信元である端末装置１０で動作しているＨＴＴＰクライアントの属性を推定する。例えば、図４に示される規則テーブルに示された規則を全て満たすＨＴＴＰリクエストが受信された場合には、推定部４０３は、送信元のＨＴＴＰクライアントの属性について以下のように推定する。ブラウザ（ＨＴＴＰクライアント）の種類は“ｘｘｘ”、ブラウザのバージョンは“１”、ＯＳの種類は“ｙｙｙ”、ＯＳのバージョンは“１”。
【００２２】
以下、推定部４０３について詳細に説明する。推定部４０３は、項目判定部４０４、順序判定部４０５、個別条件判定部４０６を備える。
項目判定部４０４は、ある属性では必ず記述されている項目の有無と、ある属性では必ず記述されていない項目の有無と、に基づいて、ＨＴＴＰリクエストの送信元である端末装置１０で動作しているＨＴＴＰクライアントの属性の候補（属性候補）を判定する。具体的には以下の通りである。項目判定部４０４は、規則テーブルの必ず存在するヘッダの欄と、必ず存在しないヘッダの欄とに基づいて、規則テーブルの規則を満たすか否か全ての規則テーブルについて判定する。規則を満たす場合、項目判定部４０４は、その規則テーブルに応じた属性を、属性候補と判定する。一方、規則を満たさない場合、項目判定部４０４は、その規則テーブルに応じた属性を、属性候補から外す。なお、規則を満たす場合とは、規則テーブルの必ず存在するヘッダに規定されている項目が全てＨＴＴＰリクエストに記述されており、必ず存在しないヘッダに規定されている項目が全てＨＴＴＰリクエストに記述されていない場合である。
【００２３】
順序判定部４０５は、記述された項目の順序に基づいて属性候補を判定する。具体的には以下の通りである。順序判定部４０５は、規則テーブルのヘッダの順番の欄に基づいて、規則テーブルの規則を満たすか否か、項目判定部４０４で属性候補と判定された全ての規則テーブルについて判定する。規則を満たす場合、順序判定部４０５は、その規則テーブルに応じた属性を、属性候補と判定する。一方、規則を満たさない場合、順序判定部４０５は、その規則テーブルに応じた属性を、属性候補から外す。
【００２４】
個別条件判定部４０６は、ヘッダの項目の個別条件に基づいて、属性候補の中から属性を推定する。具体的には以下の通りである。個別条件判定部４０６は、規則テーブルの個別条件の欄に基づいて、規則テーブルの規則を満たすか否か、順序判定部４０５で属性候補と判定された全ての規則テーブルについて判定する。規則を満たす場合、個別条件判定部４０６は、その規則テーブルに応じた属性を、ＨＴＴＰクライアントの属性と推定する。一方、規則を満たさない場合、個別条件判定部４０６は、その規則テーブルに応じた属性を、ＨＴＴＰクライアントの属性ではないと推定する。個別条件判定部４０６は、推定結果を、クライアント推定部４０の推定結果として応答部２０３に出力する。
【００２５】
図５は、ＨＴＴＰサーバ２０の動作例を表すフローチャートである。まず、通信部２０１は、ＨＴＴＰリクエスト以外のデータを受信した場合には（ステップＳ１０１）、受信したデータを応答部２０３に渡す。一方、通信部２０１は、ＨＴＴＰリクエストを受信すると（ステップＳ１０１−ＹＥＳ）、受信したＨＴＴＰリクエストをクライアント推定部４０に渡す。項目判定部４０４は、受信したＨＴＴＰリクエストについて、必須項目（必ず存在するヘッダの項目、必ず存在しないヘッダの項目）に基づいて、ＨＴＴＰクライアントの属性候補を判定する（ステップＳ１０２）。順序判定部４０５は、受信したＨＴＴＰリクエストについて、項目の順序（ヘッダの順番）に基づいて、ＨＴＴＰクライアントの属性候補を判定する（ステップＳ１０３）。個別条件判定部４０６は、受信したＨＴＴＰリクエストについて、個別条件に基づいて、ＨＴＴＰクライアントの属性候補の中から属性を推定する（ステップＳ１０４）。そして、個別条件判定部４０６は、推定結果を応答部２０３に出力する（ステップＳ１０５）。
【００２６】
応答部２０３は、応答内容テーブルを参照し、受信されたＨＴＴＰリクエストの条件と、クライアント推定部４０による推定結果と、に基づいて応答内容を決定する（ステップＳ１０６）。応答部２０３は、決定した応答内容に基づいて、ＨＴＴＰレスポンスを生成する（ステップＳ１０７）。そして、応答部２０３は、生成したＨＴＴＰレスポンスを、通信部２０１を介して端末装置１０へ送信する（ステップＳ１０８）。
【００２７】
このように構成されたＨＴＴＰサーバ４０では、ＨＴＴＰクライアントの属性毎に固有のＨＴＴＰリクエストの記述の規則に基づいて、ＨＴＴＰクライアントの属性が判定される。このＨＴＴＰリクエストの記述の規則にはUser-Agent ヘッダ以外の規則も含まれている。そのため、たとえUser-Agentヘッダに記載された情報に誤りがあったとしても、ＨＴＴＰクライアントの属性をより正確に推定することが可能となる。
【００２８】
また、規則は具体的に必須項目と、項目の記述の順序と、個別条件との三つの種類の規則で構成される。そのため、いずれか一つの規則のみに基づいて推定を行うよりもより正確な推定を行うことが可能となる。
また、推定結果に応じた応答内容に基づいてＨＴＴＰレスポンスが生成される。そのため、端末装置１０で動作しているＨＴＴＰクライアントの属性に応じた適切なＨＴＴＰレスポンスを端末装置１０へ送信することが可能となる。
【００２９】
＜変形例＞
端末装置１０及びＨＴＴＰサーバ２０は、ＨＴＴＰのみならず、ＨＴＴＰＳ（Hypertext Transfer Protocol over Secure Socket Layer）で通信しても良い。
推定部４０３は、項目判定部４０４、順序判定部４０５、個別条件判定部４０６のうち、いずれか一つ又は二つのみによって構成されても良い。
【００３０】
項目判定部４０４、順序判定部４０５、個別条件判定部４０６の処理の順序は、図５のフローチャートに示す順序に限定される必要は無い。いずれの順序の場合も、最初に処理をする機能部は全ての属性から属性候補を絞り、次に処理をする機能部は属性候補をさらに絞り、最後に処理をする機能部は絞られた属性候補の中から属性を推定する。また、上述したように推定部４０３は、項目判定部４０４、順序判定部４０５、個別条件判定部４０６のうち、いずれか一つ又は二つのみによって推定部４０３が構成される場合の処理の順序も、適宜設計される。
属性は、ＨＴＴＰクライアントの種類及びバージョンと、端末装置１０で動作しているＯＳの種類及びバージョンとの全てを含むのではなく、これらのうちいずれか一つ又は複数の組み合わせであっても良い。
【００３１】
クライアント推定部４０は、ＨＴＴＰサーバ２０ではなく、他の装置に設けられても良い。
例えば、クライアント推定部４０は、ネットワーク３０に設置された中継装置に設けられても良い。この場合、中継装置は以下のように動作しても良い。例えば、中継装置は、属性毎にＨＴＴＰリクエストを異なるネットワークへ転送しても良い。例えば、中継装置は、特定の属性によるＨＴＴＰリクエストのみを転送し、他の属性によるＨＴＴＰリクエストを廃棄しても良い。例えば、中継装置は、特定の属性によるＨＴＴＰリクエストのみをネットワークから遮断し、他の属性によるＨＴＴＰリクエストを遮断しなくても良い。例えば、中継装置は、特定の属性によるＨＴＴＰリクエストが受信された場合に、ネットワーク３０の管理者に警告を発しても良い。
【００３２】
例えば、クライアント推定部４０は、端末装置１０とＨＴＴＰサーバとの間に設けられたプロキシサーバ（Proxy Server）に設けられても良い。この場合、プロキシサーバは以下のように動作しても良い。例えば、プロキシサーバは、属性毎に異なるＨＴＴＰサーバへプロキシしても良い。例えば、プロキシサーバは、特定の属性によるＨＴＴＰリクエストのみをプロキシしても良い。例えば、プロキシサーバは、特定の属性によるＨＴＴＰリクエストのみプロキシせず、エラー画面などの所定のコンテンツをＨＴＴＰレスポンスとして返信しても良い。例えば、プロキシサーバは、特定の属性によるＨＴＴＰリクエストのみ特定のウェブページへリダイレクトさせるＨＴＴＰレスポンスを返送しても良い。例えば、プロキシサーバは、特定の属性によるＨＴＴＰリクエストが受信された場合に、プロキシサーバの管理者に警告を発しても良い。なお、プロキシサーバは、端末装置１０とＨＴＴＰサーバとの間に一段設けられても良いし、多段設けられても良い。
【００３３】
以上、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。
【符号の説明】
【００３４】
１…クライアント推定システム， １０…端末装置， ２０…ＨＴＴＰサーバ， ３０…ネットワーク， ２０１…通信部， ２０２…応答内容記憶部， ２０３…応答部， ４０…クライアント推定部， ４０２…規則テーブル記憶部， ４０３…推定部， ４０４…項目判定部， ４０５…順序判定部， ４０６…個別条件判定部
【特許請求の範囲】
【請求項１】
ＨＴＴＰリクエストの記述の規則を、ＨＴＴＰクライアントの属性毎に記憶する規則記憶部と、
前記規則記憶部に記憶される規則と、端末装置から送信されたＨＴＴＰリクエストの記述と、に基づいて、前記端末装置におけるＨＴＴＰクライアントの属性を推定する推定部と、
を備えるクライアント推定装置。
【請求項２】
ＨＴＴＰリクエストの記述の規則を、ＨＴＴＰクライアントの属性毎に記憶する規則記憶部を備える情報処理装置が、前記規則記憶部に記憶される規則を読み出すステップと、
前記情報処理装置が、読み出された前記規則と、端末装置から送信されたＨＴＴＰリクエストの記述と、に基づいて、前記端末装置におけるＨＴＴＰクライアントの属性を推定するステップと、
を有するクライアント推定方法。
【請求項３】
ＨＴＴＰリクエストの記述の規則を、ＨＴＴＰクライアントの属性毎に記憶する規則記憶部を備える情報処理装置に対し、
前記規則記憶部に記憶される規則を読み出すステップと、
読み出された前記規則と、端末装置から送信されたＨＴＴＰリクエストの記述と、に基づいて、前記端末装置におけるＨＴＴＰクライアントの属性を推定するステップと、
を実行させるためのコンピュータプログラム。
【請求項１】
ＨＴＴＰリクエストの記述の規則を、ＨＴＴＰクライアントの属性毎に記憶する規則記憶部と、
前記規則記憶部に記憶される規則と、端末装置から送信されたＨＴＴＰリクエストの記述と、に基づいて、前記端末装置におけるＨＴＴＰクライアントの属性を推定する推定部と、
を備えるクライアント推定装置。
【請求項２】
ＨＴＴＰリクエストの記述の規則を、ＨＴＴＰクライアントの属性毎に記憶する規則記憶部を備える情報処理装置が、前記規則記憶部に記憶される規則を読み出すステップと、
前記情報処理装置が、読み出された前記規則と、端末装置から送信されたＨＴＴＰリクエストの記述と、に基づいて、前記端末装置におけるＨＴＴＰクライアントの属性を推定するステップと、
を有するクライアント推定方法。
【請求項３】
ＨＴＴＰリクエストの記述の規則を、ＨＴＴＰクライアントの属性毎に記憶する規則記憶部を備える情報処理装置に対し、
前記規則記憶部に記憶される規則を読み出すステップと、
読み出された前記規則と、端末装置から送信されたＨＴＴＰリクエストの記述と、に基づいて、前記端末装置におけるＨＴＴＰクライアントの属性を推定するステップと、
を実行させるためのコンピュータプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図２】
【図３】
【図４】
【図５】
【公開番号】特開２０１２−２４７９１９（Ｐ２０１２−２４７９１９Ａ）
【公開日】平成２４年１２月１３日（２０１２．１２．１３）
【国際特許分類】
【出願番号】特願２０１１−１１８０８４（Ｐ２０１１−１１８０８４）
【出願日】平成２３年５月２６日（２０１１．５．２６）
【出願人】（３９９０４０４０５）東日本電信電話株式会社 (286)
【公開日】平成２４年１２月１３日（２０１２．１２．１３）
【国際特許分類】
【出願日】平成２３年５月２６日（２０１１．５．２６）
【出願人】（３９９０４０４０５）東日本電信電話株式会社 (286)
[ Back to top ]