JP2004348670A

JP2004348670A - ログ仲介システム

Info

Publication number: JP2004348670A
Application number: JP2003148019A
Authority: JP
Inventors: Mitsuhiro Matsuda; 光弘松田; Shinji Kitagami; 眞二北上; Takayuki Ito; 孝之伊藤
Original assignee: Mitsubishi Electric Corp
Current assignee: Mitsubishi Electric Corp
Priority date: 2003-05-26
Filing date: 2003-05-26
Publication date: 2004-12-09

Abstract

【課題】拡張性、及び効率性の向上したログ仲介システムを得ることを目的とする。
【解決手段】ログ仲介システム１ａはログ変換部３０、３１、３２、３３と、Ｉサービス統一データ４０と、Ｊサービス統一データ４１と、サポートデータ生成部５０〜５２とを備えて構成される。ログ仲介システム１ａに対して、サービスカテゴリＩの、例えばＡ社製Ｉサーバ１０とそのログ２０、Ｂ社製Ｉサーバ１１とそのログ２１、サービスカテゴリＪの、例えばＣ社製Ｊサーバ１２とそのログ２２、Ｄ社製Ｊサーバ１３とそのログ２３がログを供給する側にあり、外部データＤＢ６０〜６３が外部データを供給する装置としてあり、ログ仲介システム１ａからサポートされるサポートシステムとして、例えばサポートシステム８０〜８２がある。
【選択図】図２

Description

【０００１】
【発明の属する技術分野】
この発明は、サービスを行う複数台、複数種類のサーバから出力されるログなどの情報を収集し、変換し、統一して、前記サーバに供給することによりログデータとサポートシステムの仲介を行うログ仲介システムに関するものである。
【０００２】
【従来の技術】
従来の技術の一例として、ＩＰＤＲ・ＮＤＭ−Ｕ（ＩｎｔｅｒｎｅｔＰｒｏｔｃｏｌＤｅｔａｉｌＲｅｃｏｒｄ−ＮｅｔｗｏｒｋＤａｔａＭａｎａｇｅｍｅｎｔ−Ｕｓａｇｅ）には、複数のサポートシステムに対応した３階層モデルがあり、複数のサーバから取得した複数のログデータ、および取得した外部データを統一フォーマットのＩＰＤＲ２７０に変換し、これを各サポートシステムに対して提供しているものである。その際、各サポートシステムに提供されるデータ項目およびデータフォーマットはサーバが提供するサービスの種類（以下、適宜「サービスカテゴリ」と記す）毎に全て同一であった。つまり、全てのサポートシステムは同一のデータを受信し、また、データの形式、即ち外部データ取得後のデータ形式でデータが保存され蓄積される。
【０００３】
また、他の例として複数のサービスシステムからログを収集すること、複数種類のログを統一フォーマットに変換すること、および複数のＢＳＳ（ＢｕｓｉｎｅｓｓＳｕｐｐｏｒｔＳｙｓｔｅｍｓ）に対応して４階層構造による拡張性の高いシステム設計について示すものがある（例えば、特許文献１参照）。
【０００４】
【特許文献１】
特開２００２−８２８４９号公報
【０００５】
【発明が解決しようとする課題】
従来の技術では、全てのサポートシステムに対して、サービスカテゴリ毎に同一のデータが提供される。その場合、あるサポートシステムにとっては不必要なデータも送られてしまうという問題があった。また、外部データを用い、その変換後にデータを保存、蓄積するが、その場合、サポートシステムの仕様変更、機能拡張があるとそれまでに保存されたデータが利用できないという問題があった。さらに、サポートシステムの仕様変更、機能拡張があると、多くのモジュールの改修が必要となるという問題があった。
【０００６】
また、特許文献１に示される例では、複数のサービスカテゴリのログには対応していなく、また、複数の利用方法、拡張性の高い設計は考慮されていないという問題がった。
【０００７】
この発明は上記のような問題点を解決するためになされたもので、拡張性、及び効率性の向上したログ仲介システムを得ることを目的とする。
【０００８】
【課題を解決するための手段】
この発明に係るログ仲介システムは、サービスをサポートするサポートシステムに対してサポートデータを供給するログ仲介システムにおいて、クライアントに対しネットワークを介してサービスを提供し、クライアントからのアクセス毎にログを出力するサーバと、サーバから出力されるログを、規定された形式で統一してデータを形成するログ変換手段と、統一したデータを取得し、そのデータに基づいて、サポートシステムとの間で規定された形式のデータを生成するデータ生成手段と、データ生成手段により生成されたデータをサポートシステムに送信するデータ送信手段とを備えるものである。
【０００９】
【発明の実施の形態】
以下、この発明の実施の一形態について説明する。
まず、各実施の形態に共通するログ仲介システムに関する技術の概要について図１を参照して説明する。
【００１０】
図１に示すようにログ仲介システム１の基本的構成は、ログ変換部４、統一データ５、サポートデータ生成部７を備えて構成され、各種サービスを行うサーバ２からのログ情報を記録したログ３からログ情報を得て、また、外部データ６からデータを得てログ情報を変換し、サポートデータ８としてサポートシステム９に供給する。
【００１１】
まず、ログ変換部４の動作について説明する。ログ変換部４の動作の概要は、種類の異なる複数のサーバ２から出力された複数種類のログを収集し、提供するサービスの種類であるサービスカテゴリ毎に予め規定される統一フォーマットのデータ（以下「統一データ」と記す）に変換し、統一データ５として保存することである。ログ変換部４は、サーバ２の種類毎に１つ用意されているか、サービスカテゴリ毎に１つ用意されているか、又は、全てのサーバ２に対して１つ用意されているものである。
【００１２】
ログ変換部４が、サーバ２の種類毎に１つ用意されている場合は、各ログ変換部４は対応するサーバ２のログを、そのサーバ２が属するサービスカテゴリの統一データに変換する機能をもつ。ログ変換部４が、サービスカテゴリ毎に１つ用意される場合、又は全てのサーバ２に対して１つの場合（即ち、１つのログ変換部４で複数のサーバ２に対応する場合）、ログ変換部４の内部で、取得したログがどの種類のサーバ２によって出力されたものかを判断し、適切な統一データに変換する機能を持つ。なお、サービスカテゴリには複数種類のサーバ２が含まれる。例えば、サービスカテゴリがＷｅｂである場合、サーバ２の種類には、Ａｐａｃｈｅ、ＩＩＳ（ＩｎｔｅｒｎｅｔＩｎｆｏｒｍａｔｉｏｎＳｅｒｖｅｒ）などが含まれる。
【００１３】
ログ変換部４の起動は、一日毎、一週間毎といった一定時間間隔でバッチ的に起動されるか、又は、各サーバ２上に新たなログが生成された時点で起動されるものとする。
【００１４】
まず、ログ変換部４は、予め設定されている１つ又は複数のサーバ２からネットワークを介してログを取得する。取得するログは通常サーバ２上に保存されているテキスト形式のログ３であるが、バイナリ形式でも、直接サーバプログラムに接続してデータを取得してもよい。ログ変換部４が取得したログは、一度ファイルとしてログ仲介システムが備える、図示しないディスクに保存した上で読み込むか、又は直接、ログ変換部４に入力される。
【００１５】
次に、ログ変換部４は読み込んだログを、予めサービスカテゴリ毎に規定される統一フォーマットのデータに変換する。通常ログは、クライアント、即ちコンピュータや携帯端末等の１回のアクセス、又は動作に対して、１レコード（１行）のログが生成されている。この１レコードのログには、クライアントのアクセス日時又はログが記録された日時、クライアントがアクセスしたファイル名、クライアントマシンの環境（即ち、ＯＳ、クライアントソフトウェア名、バージョン等）、リクエストの内容、クライアント−サーバ間で使用されたプロトコルなどのデータが記録される。
【００１６】
ログ変換部４はログの各レコードを読み取り、サービスカテゴリ毎に統一されたフォーマットに変換する。サーバ２によって出力されるログの形式、意味内容が異なるため、変換を行う際、必要に応じて、（ｉ）意味は同じだが異なる標記がされているデータ（例えばデータの形式やデータの単位が異なる場合）の変換すること、（ｉｉ）ある文字列から必要な部分のみを切り出すこと、（ｉｉｉ）複数のデータから必要な値を計算すること、（ｉｖ）ログ１レコードの内容を統一フォーマット複数のレコードに変換すること、（ｖ）複数のログレコードに記録されたデータ値から統一フォーマットの１レコードを生成すること、などが必要となる場合もある。
【００１７】
最後に、ログ変換部４は、統一したデータをディスクに保存する。保存する際の形態は、リレーショナルデータベース、ＸＭＬ（ＥｘｔｅｎｓｉｂｌｅＭａｒｋｕｐＬａｎｇｕａｇｅ）形式のテキストファイルなど汎用性の高い保存形態をとることが望まれるが、カンマ区切りのＣＳＶ（ＣｏｎｕｍａＳｅｐａｒａｔｅｄＶａｌｕｅ）形式のテキストファイルや特定のバイナリ形式のような何れの形式でもよい。ただし、その場合の条件として、保存したデータが、後に続くサポートデータ生成部７で読むことができる形式とする。
【００１８】
このようにサービスカテゴリ毎に統一フォーマットに変換し保存しておくことで、同一サービスカテゴリ内の異なる種類のサーバ２から出力されたログであっても、その後の処理で統一的にログデータを扱えるというメリットがある。また、例えばサポートシステム９やサポートデータ生成部７を変更したとしても、このログ変換部４を変更する必要はない。さらに、この時点ではログ以外の外部データを取得していないため、サポートシステム９やサポートデータ生成部７に変更があったとしても、それまでに保存されている統一フォーマットのデータは変更することを必要とせずに使用することが可能である。
【００１９】
つぎに、サポートデータ生成部７の動作を説明する。サポートデータ生成部７の動作の概要は、複数種類のサービスカテゴリ毎に統一された統一データと外部データ６から外部データを取得し、取得したデータを予めサポートシステム９との間で規定される必要十分なデータを生成し、生成したデータをサポートシステム９に出力することである。サポートデータ生成部７とサポートシステム９は１対１に対応しているため、サポートデータ生成部７はサポートシステム９と同数存在する。
【００２０】
サポートデータ生成部７の起動は、（ｉ）１日毎、１週間毎といった一定時間間隔か、又は（ｉｉ）統一フォーマットのログが新たに生成された時点でリアルタイムに行われるか、又は、（ｉｉｉ）対応するサポートシステム９から要求がきた時点のいずれかの時点で動作を開始する。各サポートデータ生成部７の起動のタイミングは同時である必要は無い。
【００２１】
まず、サポートデータ生成部７はサービスカテゴリ毎に統一された１つ又は複数のデータを取得する。次に、サポートデータ生成部７は必要となる外部データを外部データＤＢ（データベース）６から取得する。取得する外部データは対応するサポートデータ生成部７によって異なる。例えば、課金を想定したサポートデータ生成機能であれば、課金対象となるサービス、或いはコンテンツとそれに対する使用料金が示されている外部データが必要であり、利用動向分析データ生成機能であれば、ユーザ情報やコンテンツ情報が示されている外部データが必要になると考えられる。
【００２２】
サポートデータ生成部７は、取得した統一データと外部データの、選択、集計、結合等を行い、最終的に、予め規定されたサポートシステム９毎に必要十分なデータを生成し、サポートシステム９に出力する。
【００２３】
サポートデータ生成部７の動作は個々のサポートデータ生成部７によって異なり、また実装方法によっても動作が異なるため、その全ての動作内容をここで詳細に示すことはできないが、例として、ストリーミングとＦＴＰ（ＦｉｌｅＴｒａｎｓｆｅｒＰｒｏｔｃｏｌ）のサービスの課金を簡単に説明する。
【００２４】
課金を行う場合の、サポートシステムの名前を“課金サービス”、課金サービスに送信されるサポートデータを“課金データ”、課金データを生成するサポートデータ生成部７を“課金データ生成部”とし、以下でその動作を示す。なお、課金サービスに関するサポートシステムの詳細については、後段の実施の形態３、実施の形態４、実施の形態５において説明する。
【００２５】
まず、課金データ生成部はストリーミングとＦＴＰの統一データと、外部データとして存在する課金ルールを取得する。統一データには、“誰が、何を、どれだけ使用した”という情報が記録されており、課金ルールには、“何を、どれだけ使用したら、いくらか”という情報が指定されている。具体的な使用料金の決定方法はそれぞれの運用ルールに依存する。例えばここで、（ａ）ストリーミングはコンテンツ毎の再生時間で料金を決定し、（ｂ）ＦＴＰはコンテンツによらず転送バイト数で使用料金が決定されるとすると、外部から取得する課金ルールには、（ａ）全てのストリーミングコンテンツについて、それぞれ１秒間再生した際に発生する料金、及び（ｂ）ＦＴＰで１Ｋバイト転送した際に発生する料金が、予め決められたフォーマットで指定される。統一データには、ユーザ名、使用したストリーミングコンテンツのファイル名、及び、使用量、例えばストリーミングであればクライアントでの再生時間、ＦＴＰであれば転送Ｋバイト数等が記録されている。
【００２６】
次に、課金データ生成部は取得した統一データを集計し、ユーザ毎に料金を計算する。具体的には、統一データを参照し、ストリーミングであれば、“ユーザＡ、ファイルＡ、ユーザＡがファイルＡを再生した時間の合計ｘ”というデータを全てのユーザ名とファイル名の組み合わせについて集計する。ＦＴＰであれば、ユーザ毎に集計するだけでよく“ユーザＢ、転送Ｋバイト数ｘ”というデータを全てのユーザ名について集計する。この集計したデータに対して、課金ルールから単位時間、及び単位転送量あたりの料金を取得し、再生時間、及び転送量と掛け合わせて“ユーザＡ、ファイルＡ、ユーザＡがファイルＡを再生した時間の合計ｘ、左記の使用料金ｙ（円）”、及び“ユーザＢ、転送Ｋバイト数ｘ、左記の使用料金ｙ（円）”というデータを生成する。
【００２７】
最後に、上記の方法で集計したデータを、対応する課金システムをサポートするサポートシステム９に対して出力する。データを受け取った課金システムは、ユーザに対して決済を行い、或いはユーザや課金管理者からの紹介に対してそれまでの課金状況を表示する画面を生成するなどの処理を実施することが想定される。
【００２８】
このように、ストリーミングやＦＴＰなど複数のサービスに対する課金をまとめて管理することにより、管理者やユーザは分かりやすいというメリットがある。また、異なる種類のサービス、例えば割引セット料金を設定することも、課金ルールにセット割引を示す記述をすることで容易に実現することが可能である。
サポートシステム毎に対応するサポートデータ生成部７を用意し、サポートシステム９毎に特定の必要十分なデータを提供することにより、各サポートシステム９では不必要なデータを取得しなくてよいというメリットがある。
【００２９】
また、上述の例では示さなかったが、サポートデータ生成部７がサポートシステム９からの要求で動作を開始する場合、サポートシステム９側からの要求に特定のパラメータを指定することで、統一データを集計する範囲を指定することが可能である。例えば、ユーザ名をパラメータとして指定することで、指定したユーザに関する課金情報のみを取得できる。例えば、日時をパラメータとして与えることで、指定した日時以降、又は以前に関する課金情報のみを取得することができ、この機能を用いて、前述した課金システムは一度受け取ったデータをローカルのディスクに保存しておき、それ以降は日時を指定してサポートデータ生成部７を起動して、前回からの差分のみを受け取り、前回保存したデータと加算することで、処理時間を短縮することが可能となる。
【００３０】
実施の形態１．
この発明の実施の形態１に係るログ仲介システム１ａについて、図２〜図４を参照して説明する。なお、図２は実施の形態１に係るログ仲介システム１ａの構成を示す図であり、図３はこのログ仲介システム１ａの、クライアントからのアクセスによりログが蓄積される状態を示す図であり、図４はこのログ仲介システム１ａの、ＢＳＳメディエーションの流れを示す図である。
【００３１】
ログ仲介システム１ａは図２に示すように、ログ変換部３０、３１、３２、３３と、Ｉサービス統一データ４０と、Ｊサービス統一データ４１と、サポートデータ生成部５０〜５２とを備えて構成される。ログ仲介システム１ａに対して、サービスカテゴリＩの、例えばＡ社製Ｉサーバ１０とそのログ２０、Ｂ社製Ｉサーバ１１とそのログ２１、サービスカテゴリＪの、例えばＣ社製Ｊサーバ１２とそのログ２２、Ｄ社製Ｊサーバ１３とそのログ２３がログを供給する側にあり、外部データＤＢ６０〜６３が外部データを供給する装置としてあり、ログ仲介システム１ａからサポートされるサポートシステムとして、例えばサポートシステム８０〜８２がある。
【００３２】
Ａ社製Ｉサーバ１０とＢ社製Ｉサーバ１１は異なる種類のサーバであるが、同一、又は同種のサービス（この場合、サービスカテゴリＩ）を、ネットワークを介してクライアントに提供するサーバである。クライアントからアクセスがあった場合、アクセス情報やクライアントの情報をログ２０、２１に保存する。同種のサービスとは、例えば、Ｗｅｂ、ストリーミング、ＦＴＰなどを意味し、異なる種類の装置とは、Ｗｅｂであれば、Ａｐａｃｈｅ、ＩＩＳなど、ストリーミングであればＷｉｎｄｏｗｓ（登録商標）Ｍｅｄｉａ、ＲｅａｌＳｙｓｔｅｍなどを意味する。つまり、Ａｐａｃｈｅ、ＩＩＳは異なる種類の装置であるが、同種のサービスＷｅｂを提供するサーバである。
【００３３】
Ｃ社製Ｊサーバ１２とＤ社製Ｊサーバ１３は、Ａ社製Ｉサーバ１０とＢ社製Ｉサーバ１１と同様に、異なる種類の装置であり、同一、又は同種のサービスＪを、ネットワークを介してクライアントに提供するサーバである。クライアントからアクセスがあった場合、アクセス情報やクライアントの情報をログ２２、２３に保存する。図１ではこれらサーバを１台のサーバ２として図示したが、負荷分散された複数台のサーバであってもよい。
【００３４】
各サーバから出力され、ログ２０〜２３に格納されるログは、ログレコードの集合であり、ログレコードとは、クライアントからアクセスがあった場合に生成されるもので、アクセスに関する様々な情報やクライアントから送信される情報のセットである。ログはテキストフォーマットかバイナリフォーマットのファイルとしてサーバ上のディスクに保存されるか、又はネットワークを介して直接外部から参照されるか、又は外部のコンピュータのディスクに直接保存される（以降これらを全て「ログ」と記す）。Ａ社製Ｉサーバ１０、Ｂ社製Ｉサーバ１１、Ｃ社製Ｊサーバ１２、Ｄ社製Ｊサーバ１３は全て異なるため、ログ２０〜２３のログのデータ項目、データ形式は、通常異なる。
【００３５】
ログ変換部３０〜３３は、それぞれ、Ａ社製Ｉサーバ１０、Ｂ社製Ｉサーバ１１、Ｃ社製Ｊサーバ１２、Ｄ社製Ｊサーバ１３の各サーバと１対１に対応しており、サーバの種類と同数存在する。各ログ変換部３０〜３３は、対応するサーバから出力されたログを取得し、対応するサーバのサービスカテゴリ毎に統一のデータ項目、データ形式に変換し、Ｉサービス統一データ４０、Ｊサービス統一データ４１のいずれかに保存する。
【００３６】
外部データＤＢ６０〜６３は、サポートデータ生成部５０〜５２のうちの少なくとも１つに対応しており、そのデータ内容はそれぞれ異なる。外部データＤＢ６０〜６３に記録されている外部データは、Ｉサービス統一データ４０、Ｊサービス統一データ４１のデータを補完するためのデータで、最終的にサポートシステム８０〜８２において必要となるデータが予め保存されている。
【００３７】
サポートデータ生成部５０〜５２はそれぞれ、サポートシステム８０〜８２と１対１に対応しており、サポートシステムと同数存在する。サポートデータ生成部５０〜５２はそれぞれ、Ｉサービス統一データ４０、Ｊサービス統一データ４１の全ての統一データ、および、外部データＤＢ６０〜６３の外部データを０個以上取得し、取得した統一データと外部データを選択、集計、結合し、対応するサポートシステムとの間で規定されるデータ項目、データフォーマットをもつサポートデータ７０〜７２を生成し、対応するサポートシステム８０〜８２に提供する。
【００３８】
また、サポートデータ生成部５０〜５２はそれぞれ、処理開始時にパラメータを与えることが可能で、その際、与えられたパラメータに対応するレコードのみをログ２０〜２３から抽出し、パラメータに対応するデータのみのサポートデータ７０〜７２を生成する機能を有する。例えば、サポートシステム８０〜８２はあるユーザ名をパラメータとしてサポートデータ生成部５０〜５２を起動し、指定したユーザ名に関するデータのみが含まれるサポートデータ７０〜７２を取得することができる。各サポートシステム８０〜８２は、取得したデータをもとにＡ社製Ｉサーバ１０、Ｂ社製Ｉサーバ１１、Ｃ社製Ｊサーバ１２、Ｄ社製Ｊサーバ１３が提供するサービスをサポートする機能を有する。
【００３９】
次にログ仲介システム１ａの動作について説明する。
図３はＡ社製Ｉサーバ１０、Ｂ社製Ｉサーバ１１、Ｃ社製Ｊサーバ１２、Ｄ社製Ｊサーバ１３に対してクライアントがアクセスする際の状況を示している。ユーザはクライアントコンピュータ９０、９１や携帯端末９２などからネットワーク９３を介して１台、又は複数に負荷分散されたサーバ９４にアクセスし、サービスの提供を受ける。その際、サーバ９４は、クライアントのアクセス情報、クライアントの情報、アクセス日時などのデータをログ９５として記録する。
【００４０】
次に図２において、ログ変換部３０〜３３は、リアルタイム（ここで、リアルタイムとは、統一データが生成されたそのときを言い、以下同様の意味において用いる）、又は定期的（即ち、バッチ的）にログ２０〜２３をＡ社製Ｉサーバ１０、Ｂ社製Ｉサーバ１１、Ｃ社製Ｊサーバ１２、Ｄ社製Ｊサーバ１３から収集し、サービスカテゴリ毎に統一されたデータを生成し、ＸＭＬ形式、又はリレーショナルデータベースの形式でＩサービス統一データ４０およびＪサービス統一データ４１に保存する。
【００４１】
次に、サポートデータ生成部５０〜５２のうち１つ又は複数は、リアルタイム、定期的、又は各サポートシステム８０〜８２から要求がきた時点のいずれかのタイミングで、Ｉサービス統一データ４０およびＪサービス統一データ４１の統一データを収集、取得し、さらに、外部データＤＢ６０〜６３から外部データを取得し、取得した統一データと外部データを、選択、集計、結合し、最終的に、対応するサポートシステム８０〜８２に対して必要十分なデータを提供する。
【００４２】
また、サポートデータ生成部５０〜５２がサポートシステム８０〜８２から要求を受けて起動する際に、その要求にパラメータが指定された場合、サポートデータ生成部５０〜５２は、そのパラメータに応じて必要なデータのみ（又は不必要なデータ以外の全てのデータ）を生成し、パラメータを指定しなかった場合に提供されるデータと異なるデータをサポートシステム８０〜８２に提供することができる。例えば、サポートシステム８０〜８２からのリクエストにユーザ名が指定された場合、統一データの中から、指定されたユーザがサーバにアクセスしたことによって記録されたもののみを抽出して処理を行い、指定されたユーザに関するデータのみをサポートシステム８０〜８２に送信する。
【００４３】
つぎに、図４のフローチャートを参照してサポートデータ生成部５０〜５２の動作を説明する。サポートデータ生成部５０〜５２は、リアルタイム、定期的、又はサポートシステム８０〜８２から要求があった時点のいずれかのタイミングでサポートデータ生成機能を起動し（ステップＳＴ１０１）、サポートデータ生成部５０〜５２は、必要な統一データを取得する（ステップＳＴ１０２）。つぎに、外部データＤＢ６０〜６３から外部データを取得する（ステップＳＴ１０３）。
【００４４】
つぎに、サポートデータ生成部５０〜５２がサポートシステム８０〜８２からの要求で処理を開始し、かつそのサポートシステムからのリクエストに要求パラメータが含まれていたか否かを判別する（ステップＳＴ１０４）。含まれていた場合（ＹＥＳ）、受信したパラメータの値に従って、必要なデータのみ、又は不必要なデータ以外の全てのデータに対して処理を実行し、統一フォーマットのデータを生成する（ステップＳＴ１０５）。一方、パラメータが含まれていない場合（ＮＯ）、通常どおり全てのデータに対して処理を実行し、統一フォーマットのデータを生成して（ステップＳＴ１０６）、その生成したデータをサポートシステムに送信する（ステップＳＴ１０７）。上述したようにしてデータの提供を受けたサポートシステム８０〜８２は、受信したデータをもとに、Ａ社製Ｉサーバ１０、Ｂ社製Ｉサーバ１１、Ｃ社製Ｊサーバ１２、Ｄ社製Ｊサーバ１３のサービスをサポートするものである。
【００４５】
以上のように、実施の形態１によれば、サポートシステム毎に提供するデータを変えることで、各サポートシステムにおいて、必要で十分なデータを取得できる。また、新たなサポートシステムを追加する際、又は既存のサポートシステムの仕様を変更する際、該当するサポートシステムのモジュール・データ形式を追加、変更するだけでよい。さらに、新たなサポートシステムを追加する際、又は既存のサポートシステムの使用を変更する際、保存済みの統一データを変更することなく利用することが可能である。
これにより、複数種類のサービスを提供している環境に対して、様々なサポートシステムを容易に追加、拡張することが可能となる。
【００４６】
実施の形態２．
この発明の実施の形態２に係るログ仲介システム１ｂについて、図５を参照して説明する。なお、図５は実施の形態２に係るログ仲介システム１ｂの構成を示す図である。上述した実施の形態１では本発明のアーキテクチャを示したが、この実施の形態２では、ストリーミングサービスに対するユーザの利用動向分析として、この発明を実施する場合の形態を説明する。つまり、この実施の形態２は、１つのサービスカテゴリに対して１つのサポートシステムを適用する場合の具体例である。
【００４７】
実施の形態２のログ仲介システム１ｂはログ変換部１３０、１３１と、ストリーム統一データ１４０と、利用動向分析データ生成部１５２を備えて構成され、これに対して例えばＡ社製ストリーミングサーバ１１０とそのログ１２０、Ｂ社製ストリーミングサーバ１１１とそのログ１２１がログを供給する側にあり、コンテンツ情報ＤＢ１６２とユーザ情報ＤＢ１６３がログ仲介システム１ｂに情報を提供するものとしてあり、ログ仲介システム１ｂからサポートされるサポートシステムとして利用動向分析システム１８２がある。
【００４８】
Ａ社製ストリーミングサーバ１１０とＢ社製ストリーミングサーバ１１１は異なる種類の装置であり、ストリーミングサービスを、ネットワークを介してクライアントに提供するサーバであり、クライアントからアクセスがあった場合、アクセス情報やクライアントの情報をログ１２０、１２１に保存する。図５ではＡ社製ストリーミングサーバ１１０とＢ社製ストリーミングサーバ１１１のそれぞれを１台のサーバとして図示したが、負荷分散された複数台のサーバであってもよい。
【００４９】
ログ１２０、１２１はＡ社製ストリーミングサーバ１１０とＢ社製ストリーミングサーバ１１１から出力されるログであり、夫々、異なるサーバであるため出力されるログ１２０とログ１２１は異なるデータである。
【００５０】
ログ変換部１３０、１３１は、Ａ社製ストリーミングサーバ１１０とＢ社製ストリーミングサーバ１１１から出力されたログを収集し、ストリーミングで統一されているデータ項目、形式に変換しストリーム統一データ１４０にストリーム統一データとして保存する。
【００５１】
コンテンツ情報ＤＢ１６２およびユーザ情報ＤＢ１６３は、ストリーム統一データから利用動向分析データ１７２を生成する際に、ストリーム統一データを補完するためのデータを備えるデータベースである。例えば、コンテンツ情報ＤＢには、Ａ社製ストリーミングサーバ１１０とＢ社製ストリーミングサーバ１１１からユーザに対して提供されている各コンテンツの、ファイル名、タイトル、分類（例えば音楽、映画、ドラマなど）、著作権所有者などが含まれる。また、ユーザ情報ＤＢには、例えば、ストリーミングサービスの提供を受けるユーザのユーザ名、氏名、年齢、職業、メールアドレスなどが含まれる。
【００５２】
利用動向分析データ生成部１５２は、ストリーム統一データ１４０、コンテンツ情報ＤＢ１６２、ユーザ情報ＤＢ１６３から情報を取得して、取得したデータを選択、集計、結合し、利用動向分析データ１７２を生成し、利用動向分析システム１８２に提供する機能を有する。
【００５３】
利用動向分析システム１８２は、取得したデータをもとに、Ａ社製ストリーミングサーバ１１０とＢ社製ストリーミングサーバ１１１が提供するサービスをサポートする機能を有する。
【００５４】
次にログ仲介システム１ｂの動作について説明する。
まず、ログ変換部１３０、１３１は、リアルタイム、又は定期的にログ１２０、１２１を、Ａ社製ストリーミングサーバ１１０とＢ社製ストリーミングサーバ１１１から収集し、ストリーミング統一データを生成し、ＸＭＬ形式、又はリレーショナルデータベースの形式でストリーミング統一データ１４０に保存する。
【００５５】
次に、利用動向分析データ生成部１５２は、リアルタイム、定期的、又は各サポートシステムから要求がきた時点のいずれかのタイミングで、ストリーム統一データ１４０から統一データを取得し、一方、コンテンツ情報ＤＢ１６２、ユーザ情報ＤＢ１６３から外部データを取得し、取得した統一データと外部データを、選択、集計、結合して利用動向分析データ１７２を生成し、利用動向分析システム１８２に提供する。
【００５６】
また、利用動向分析データ生成部１５２が利用動向分析システム１８２から受けたリクエストにパラメータが指定された場合、利用動向分析データ生成部１５２はそのパラメータに応じて必要なデータのみを生成し、パラメータを指定しなかった場合に提供されるデータと異なるデータを利用動向分析システム１８２に提供することができる。例えば、利用動向分析システム１８２からのリクエストにユーザ名が指定された場合、統一データの中から、指定されたユーザがサーバにアクセスしたことによって記録されたデータのみを抽出して処理を行い、指定されたユーザに関するデータのみを利用動向分析システム１８２に送信する。
【００５７】
データの提供を受けた利用動向分析システム１８２は、受信したデータに基づき、Ａ社製ストリーミングサーバ１１０とＢ社製ストリーミングサーバ１１１によって提供されているサービスの利用動向を分析する処理を実行する。
【００５８】
以上のように、実施の形態２によれば、複数のストリーミング配信サーバのログを４階層モデルで処理する場合、サポートシステムの仕様が変更になったとしても保存されている統一データはそのままの形で利用することが可能である。
【００５９】
実施の形態３．
この発明の実施の形態３に係るログ仲介システム１ｃについて、図６を参照して説明する。なお、図６は実施の形態３に係るログ仲介システム１ｃの構成を示す図である。上述した実施の形態１ではこの発明のアーキテクチャを示し、実施の形態２では具体例としてストリーミングの利用動向分析を実施する場合の形態を示したが、この実施の形態３では、ストリーミングとＷｅｂサービスに対する課金を実施するための、複数のサービスカテゴリに対して１つのサポートシステムを適用する場合の具体例である。
【００６０】
実施の形態３のログ仲介システム１ｃはログ変換部１２０〜１２３と、ストリーム統一データ１４０と、Ｗｅｂ統一データ１４１と、課金データ生成部１５０を備えて構成され、これに対して例えばＡ社製ストリーミングサーバ１１０とそのログ１２０、Ｂ社製ストリーミングサーバ１１１とそのログ１２１、Ｃ社製Ｗｅｂサーバ１１２とそのログ１２２、Ｄ社製Ｗｅｂサーバ１１３とそのログ１２３がログを供給する側にあり、また、課金ルールＤＢ１６０がログ仲介システム１ｃに情報を提供するものとしてあり、ログ仲介システム１ｃからサポートされるサポートシステムとして課金システム１８０がある。
【００６１】
Ａ社製ストリーミングサーバ１１０とＢ社製ストリーミングサーバ１１１は異なる種類の装置であり、ストリーミングサービスを、ネットワークを介してクライアントに提供するサーバであり、クライアントからアクセスがあった場合、アクセス情報やクライアントの情報を、夫々ログ１２０、１２１に保存する。また、Ｃ社製Ｗｅｂサーバ１１２とＤ社製Ｗｅｂサーバ１１３は異なる装置であって、Ｗｅｂサービスをネットワークを介してクライアントに提供するサーバであり、クライアントからアクセスがあった場合、アクセス情報やクライアントの情報を、夫々ログ１２２、１２３に保存する。図６ではＡ社製ストリーミングサーバ１１０、Ｂ社製ストリーミングサーバ１１１、Ｃ社製Ｗｅｂサーバ１１２、Ｄ社製Ｗｅｂサーバ１１３の夫々を１台のサーバとして図示したが、負荷分散された複数台のサーバであってもよい。
【００６２】
ログ１２０〜１２３は、Ａ社製ストリーミングサーバ１１０、Ｂ社製ストリーミングサーバ１１１、Ｃ社製Ｗｅｂサーバ１１２、Ｄ社製Ｗｅｂサーバ１１３から出力されるログである。Ａ社製ストリーミングサーバ１１０とＢ社製ストリーミングサーバ１１１は同じストリーミングサービスを提供するサーバであるが、異なるサーバであるため出力されるログ１２０と１２１は異なるデータである。
また、Ｃ社製Ｗｅｂサーバ１１２とＤ社製Ｗｅｂサーバ１１３は同じＷｅｂサービスを提供するサーバであるが、異なるサーバであるため出力されるログ１２２とログ１２３は異なるデータである。
【００６３】
ログ変換部１３０、１３１は、ストリーミングサーバから出力されたログを収集し、ストリーミングで統一されているデータ項目、形式に変換し、ストリーム統一データ１４０にする機能を有する。ログ変換部１３２、１３３は、Ｗｅｂサーバから出力されたログを収集し、Ｗｅｂで統一されているデータ項目、形式に変換しＷｅｂ統一データ１４１にする機能を有する。
【００６４】
課金ルールＤＢ１６０は、ストリーム統一データ１４０、及び、Ｗｅｂ統一データ１４１を補完するための情報を格納したデータベースで、最終的に課金システム１８０にて必要となるデータが保存されている。課金ルールＤＢには、例えば、各ストリームコンテンツとその価格や各Ｗｅｂサービスとその価格などが記録されている。
【００６５】
課金データ生成部１５０はストリーム統一データ１４０、Ｗｅｂ統一データ１４１、及び、課金ルールＤＢから取得したデータを選択、集計、結合して課金データ１７０を生成し、課金システム１８０に提供する機能を有する。
【００６６】
課金システム１８０は、取得したデータをもとに、Ａ社製ストリーミングサーバ１１０、Ｂ社製ストリーミングサーバ１１１、Ｃ社製Ｗｅｂサーバ１１２、Ｄ社製Ｗｅｂサーバ１１３が提供するサービスをサポートする機能を有する。
【００６７】
次にログ仲介システム１ｃの動作について説明する。
まず、ログ変換１３０、１３１は、リアルタイム、又は定期的にログ１２０、１２１をＡ社製ストリーミングサーバ１１０、Ｂ社製ストリーミングサーバ１１１から収集し、ストリーム統一データ１４０を生成し、ＸＭＬ形式、又はリレーショナルデータベースの形式で保存する。同様に、ログ変換部１３２、１３３は、リアルタイム、又は定期的にログ１２２、１２３をＣ社製Ｗｅｂサーバ１１２、Ｄ社製Ｗｅｂサーバ１１３からから収集してＷｅｂ統一データ１４１を生成し、ＸＭＬ形式、又はリレーショナルデータベースの形式で保存する。
【００６８】
次に、課金データ生成部１５０は、リアルタイム、定期的、又は課金システムから要求がきた時点のいずれかのタイミングで、ストリーム統一データ１４０、Ｗｅｂ統一データ１４１、及び、課金ルールＤＢ１６０からデータを取得し、これら取得したデータを、選択、集計、結合して最終的に、予め規定されている課金データ１７０を生成し、課金システム１８０に提供する。
【００６９】
また、課金データ生成部１５０が課金システム１８０から受けたリクエストにパラメータが指定された場合、課金データ生成部１５０はそのパラメータに応じて必要なデータのみを生成し、パラメータを指定しなかった場合に提供されるデータと異なるデータをサポートシステムに提供することができる。例えば、課金システム１８０からのリクエストにユーザ名が指定された場合、統一データの中から、指定されたユーザがサーバにアクセスしたことによって記録されたデータのみを抽出して処理を行い、指定されたユーザに関するデータのみを課金システム１８０に送信する。
【００７０】
データの提供を受けた課金システム１８０は、受信したデータをもとに、Ａ社製ストリーミングサーバ１１０、Ｂ社製ストリーミングサーバ１１１、Ｃ社製Ｗｅｂサーバ１１２、Ｄ社製Ｗｅｂサーバ１１３によって提供されているサービスに対する課金処理を実行する。
【００７１】
以上のように、実施の形態３によれば、複数のサービスカテゴリのログを処理することが可能である。また、複数のサービスカテゴリのログを扱うことによって、例えば、Ｗｅｂサービスとストリーミングの課金を統一することが可能で、その場合一箇所で課金すれば、ユーザは自分がどのサービスをどれだけ利用していくら支払ったかという管理が容易になる。また、例えば、Ｗｅｂサービスとストリーミングの利用動向分析を組み合わせることでより詳細なクリック分析を行うことや、より詳細なユーザの嗜好を分析することが可能となる。
【００７２】
実施の形態４．
この発明の実施の形態４に係るログ仲介システム１ｄについて、図７を参照して説明する。なお、図７は実施の形態４に係るログ仲介システム１ｄの構成を示す図である。
【００７３】
実施の形態４のログ仲介システム１ｄはログ変換部１３０、１３１と、ストリーム統一データ１４０と、課金データ生成部１５０と、品質評価データ生成部１５１と、利用動向分析データ生成部１５２を備えて構成され、これに対して例えばＡ社製ストリーミングサーバ１１０とそのログ１２０、Ｂ社製ストリーミングサーバ１１１とそのログ１２１がログを供給する側にあり、課金ルールＤＢ１６０、システム構成情報ＤＢ１６１、コンテンツ情報ＤＢ１６２、ユーザ情報ＤＢ１６３がログ仲介システム１ｄに情報を提供するものとしてあり、ログ仲介システム１ｄからサポートされるサポートシステムとして課金システム１８０、品質評価システム１８１、利用動向分析システム１８２がある。
【００７４】
Ａ社製ストリーミングサーバ１１０とＢ社製ストリーミングサーバ１１１は異なる装置であり、ストリーミングサービスを、ネットワークを介してクライアントに提供するサーバであり、クライアントからアクセスがあった場合、アクセス情報やクライアントの情報をログ１２０、１２１に保存する。図７ではＡ社製ストリーミングサーバ１１０、Ｂ社製ストリーミングサーバ１１１のそれぞれを１台のサーバとして図示したが、負荷分散された複数台のサーバであってもよい。
【００７５】
ログ１２０、１２１はＡ社製ストリーミングサーバ１１０、Ｂ社製ストリーミングサーバ１１１の各サーバから出力されるログである。Ａ社製ストリーミングサーバ１１０とＢ社製ストリーミングサーバ１１１は同じストリーミングサービスを提供するサーバであるが、異なるサーバであるため出力されるログ１２０とログ１２１は異なるデータである。
【００７６】
ログ変換部１３０、１３１の各機能は、ストリーミングサーバから出力されたログを取得し、ストリーミングで統一されているデータ項目、データ形式に変換しストリーム統一データ１４０にストリーム統一データとして保存する機能を有する。
【００７７】
課金ルールＤＢ１６０、システム構成情報ＤＢ１６１、コンテンツ情報ＤＢ１６２は、ストリーム統一データを補完するための情報を格納したデータベースで、最終的に課金システム１８０、品質評価システム１８１、利用動向分析システム１８２で必要となるデータが保存されている。
【００７８】
例えば、課金ルールＤＢ１６０には、各ストリームコンテンツとその価格や各Ｗｅｂサービスとその価格などが記録されている。またシステム構成情報ＤＢ１６１には、システムを構成するサーバの配置やスペック、ネットワークの構成などが記録されている。またコンテンツ情報ＤＢ１６２には、Ａ社製ストリーミングサーバ１１０とＢ社製ストリーミングサーバ１１１からユーザに対して提供されている各コンテンツの、ファイル名、タイトル、分類（例えば音楽、映画、ドラマなど）、著作権所有者などが含まれる。またユーザ情報ＤＢ１６３には、Ａ社製ストリーミングサーバ１１０とＢ社製ストリーミングサーバ１１１のストリーミングサーバからストリーミングサービスの提供を受けるユーザの、ユーザ名、氏名、年齢、職業、メールアドレスなどが含まれる。
【００７９】
課金データ生成部１５０は、ストリーム統一データ１４０と課金ルールＤＢ１６０から取得したデータを選択、集計、結合して課金データ１７０を生成し、課金システム１８０に提供する機能を有する。
【００８０】
品質評価データ生成部１５１は、ストリーム統一データ１４０とシステム構成情報ＤＢからデータを取得し、取得したデータを選択、集計、結合して品質評価データ１７１を生成し、品質評価システム１８１に提供する機能を有する。
【００８１】
利用動向分析データ生成部１５２は、ストリーム統一データ１４０、コンテンツ情報ＤＢ１６２、ユーザ情報ＤＢ１６３からデータを取得し、取得したデータを選択、集計、結合して利用動向分析データ１７２を生成し、利用動向分析ステム１８２に提供する機能を有する。
【００８２】
課金システム１８０、品質評価システム１８１、及び、利用動向分析システム１８２は、取得したデータに基づいて、Ａ社製ストリーミングサーバ１１０とＢ社製ストリーミングサーバ１１１が提供するサービスをサポートする機能を有する。
【００８３】
次にログ仲介システム１ｄの動作について説明する。
まず、ログ変換部１３０、１３１は、リアルタイム、又は定期的にログ１２０、１２１を、Ａ社製ストリーミングサーバ１１０とＢ社製ストリーミングサーバ１１１から収集してストリーム統一データを生成し、ＸＭＬ形式、又はリレーショナルデータベースの形式で保存する。
【００８４】
次に、課金データ生成部１５０は、リアルタイム、定期的、又は課金システム１８０から要求がきた時点のいずれかのタイミングで、ストリーム統一データ１４０と課金ルールＤＢ１６０からデータを取得し、取得したデータを、選択、集計、結合して課金データ１７０を生成し、課金システム１８０に提供する。
【００８５】
また、課金データ生成部１５０が課金システム１８０から受けたリクエストに、パラメータが指定された場合、課金データ生成部１５０はそのパラメータに応じて必要なデータのみを生成し、パラメータを指定しなかった場合に提供されるデータと異なるデータをサポートシステムに提供することができる。例えば、課金システム１８０からのリクエストにユーザ名が指定された場合、統一データの中から、指定されたユーザがサーバにアクセスしたことによって記録されたデータのみを抽出して処理を行い、指定されたユーザに関するデータのみを課金システム１８０に送信する。
【００８６】
品質評価データ生成部１５１は、リアルタイム、定期的、又は品質評価システム１８１から要求がきた時点のいずれかのタイミングで、ストリーム統一データ１４０とシステム構成情報ＤＢ１６１からデータを取得し、取得したデータを、選択、集計、結合して品質評価データ１７１を生成し、品質評価システム１８１に提供する。
【００８７】
また、品質評価データ生成部１５１が品質評価システム１８１から受けたリクエストに、予め規定されている形式でパラメータが指定された場合、品質評価データ生成部１５１はそのパラメータに応じて必要なデータのみを生成し、パラメータを指定しなかった場合に提供されるデータと異なるデータをサポートシステムに提供することができる。例えば、品質評価システム１８１からのリクエストにホスト名が指定された場合、統一データの中から、指定されたホスト名のサーバに記録されたデータのみを抽出して処理を行い、指定されたホストに関するデータのみを品質評価システムに送信する。
【００８８】
利用動向分析データ生成部１５２は、リアルタイム、定期的、又は利用動向分析システム１８２から要求がきた時点のいずれかのタイミングで、ストリーム統一データ１４０、コンテンツ情報ＤＢ１６２、及び、ユーザ情報ＤＢ１６３からデータを取得し、取得したデータを、選択、集計、結合して利用動向分析データ１７２を生成し、利用動向分析システム１８２に提供する。
【００８９】
また、利用動向分析データ生成部１５１が、利用動向分析システム１８２から受けたリクエストにパラメータが指定された場合、利用動向分析データ生成部１５２はそのパラメータに応じて必要なデータのみを生成し、パラメータを指定しなかった場合に提供されるデータと異なるデータをサポートシステムに提供することができる。例えば、利用動向分析システム１８２からのリクエストにコンテンツ名が指定された場合、統一データの中から、指定されたコンテンツがアクセスしたことによって記録されたデータのみを抽出して処理を行い、指定されたコンテンツに関するデータのみのデータを利用動向分析システム１８２に送信する。
【００９０】
データの提供を受けた課金システム１８０、品質評価システム１８１、利用動向分析システム１８２は、受信したデータに基づいて、Ａ社製ストリーミングサーバ１１０とＢ社製ストリーミングサーバ１１１によって提供されているサービスに対する課金処理、品質評価、利用動向分析を実行する。
【００９１】
以上のように、実施の形態４によれば、複数のサポートシステムを統一的に扱うことが可能である。従って、各サポートシステム用に専用のシステムを別個に構築する必要がなく、新たなサポートシステムを開発する際は、本システムに一部のモジュールのみを追加することで可能である。
【００９２】
実施の形態５．
この発明の実施の形態５に係るログ仲介システム１ｅについて、図８を参照して説明する。なお、図８は実施の形態５に係るログ仲介システム１ｅの構成を示す図である。この実施の形態５では、ストリーミングとＷｅｂサービスに対する、課金、利用動向分析、及びサービス品質評価を実施する、複数のサービスカテゴリに対して、複数のサポートシステムを適用する場合の具体例である。
【００９３】
実施の形態５のログ仲介システム１ｅはログ変換部１３０〜１３３と、ストリーム統一データ１４０と、Ｗｅｂ統一データ１４１と、課金データ生成部１５０と、品質評価データ生成部１５１と、利用動向分析データ生成部１５２を備えて構成され、これに対して例えばＡ社製ストリーミングサーバ１１０とそのログ１２０、Ｂ社製ストリーミングサーバ１１１とそのログ１２１、Ｃ社製Ｗｅｂサーバ１１２とそのログ１２２、Ｄ社製Ｗｅｂサーバ１１３とそのログ１２３がログを供給する側にあり、課金ルールＤＢ１６０、システム構成情報ＤＢ１６１、コンテンツ情報ＤＢ１６２、ユーザ情報ＤＢ１６３がログ仲介システム１ｅに情報を提供するものとしてあり、さらにログ仲介システム１ｅからサポートされるサポートシステムとして課金システム１８０、品質評価システム１８１、利用動向分析システム１８２がある。
【００９４】
Ａ社製ストリーミングサーバ１１０とＢ社製ストリーミングサーバ１１１は異なる装置であり、ストリーミングサービスをネットワークを介してクライアントに提供するサーバであり、クライアントからアクセスがあった場合、アクセス情報やクライアントの情報をログ１２０、１２１に保存する。Ｃ社製Ｗｅｂサーバ１１２とＤ社製Ｗｅｂサーバ１１３は異なる装置であり、Ｗｅｂサービスをネットワークを介してクライアントに提供するサーバであり、クライアントからアクセスがあった場合、アクセス情報やクライアントの情報をログ１２２、１２３に保存する。図８ではＡ社製ストリーミングサーバ１１０、Ｂ社製ストリーミングサーバ１１１、Ｃ社製Ｗｅｂサーバ１１２、Ｄ社製Ｗｅｂサーバ１１３のそれぞれを１台のサーバとして図示したが、負荷分散された複数台のサーバであってもよい。
【００９５】
ログ１２０〜１２３はＡ社製ストリーミングサーバ１１０、Ｂ社製ストリーミングサーバ１１１、Ｃ社製Ｗｅｂサーバ１１２、Ｄ社製Ｗｅｂサーバ１１３の各サーバから出力されるログである。Ａ社製ストリーミングサーバ１１０とＢ社製ストリーミングサーバ１１１は同じストリーミングサービスを提供するサーバであるが、異なるサーバであるため出力されるログ１２０とログ１２１は異なるデータである。また、同様にＣ社製Ｗｅｂサーバ１１２とＤ社製Ｗｅｂサーバ１１３は同じＷｅｂサービスを提供するサーバであるが、異なるサーバであるため出力されるログ１２２とログ１２３は異なるデータである。
【００９６】
ログ変換部１３０、１３１は、ストリーミングサーバから出力されたログを取得し、ストリーミングで統一されているデータ項目、形式に変換しストリーム統一データ１４０にする機能を有する。同様に、ログ変換部１３２、１３３は、Ｗｅｂサーバから出力されたログを取得し、Ｗｅｂで統一されているデータ項目、形式に変換しＷｅｂ統一データ１４１にする機能を有する。
【００９７】
課金ルールＤＢ１６０、システム構成情報ＤＢ１６１、コンテンツ情報ＤＢ１６２、ユーザ情報ＤＢ１６３は、ストリーム統一データ、Ｗｅｂ統一データを補完するためのデータベースで、課金システム１８０、品質評価システム１８１、利用動向分析システム１８２のいずれかのサポートシステムにて必要となるデータが予め保存されている。
【００９８】
課金データ生成部１５０は、ストリーム統一データ１４０、Ｗｅｂ統一データ１４１、及び課金ルールＤＢ１６０からデータを取得して、取得したデータを選択、集計、結合し課金データ１７０を生成し、課金システム１８０に提供する機能を有する。
【００９９】
品質評価データ生成部１５１は、ストリーム統一データ１４０、Ｗｅｂ統一データ１４１、及びシステム構成情報ＤＢ１６１からデータを取得する。取得したデータを選択、集計、結合し品質評価データ１７１を生成し、品質評価システム１８１に提供する機能を有する。
【０１００】
利用動向分析データ生成部１５２は、ストリーム統一データ１４０、Ｗｅｂ統一データ１４１、コンテンツ情報ＤＢ１６２、及びユーザ情報ＤＢ１６３からデータを取得する。取得したデータを選択、集計、結合し利用動向分析データ１７２を生成し、利用動向分析ステム１８２に提供する機能を有する。
【０１０１】
課金システム１８０、品質評価システム１８１、及び利用動向分析システム１８２は、取得したデータに基づき、Ａ社製ストリーミングサーバ１１０、Ｂ社製ストリーミングサーバ１１１、Ｃ社製Ｗｅｂサーバ１１２、Ｄ社製Ｗｅｂサーバ１１３が提供するサービスをサポートする機能を有する。
【０１０２】
次にログ仲介システム１ｅの動作について説明する。
まず、ログ変換部１３０、１３１は、リアルタイム、又は定期的にログ１２０、１２１を、Ａ社製ストリーミングサーバ１１０とＢ社製ストリーミングサーバ１１１から収集してストリーミング統一データを生成し、ＸＭＬ形式、又はリレーショナルデータベースの形式で保存する。同様に、ログ変換部１３２、１３３は、リアルタイム、又は定期的にログ１２２、１２３を、Ｃ社製Ｗｅｂサーバ１１２、Ｄ社製Ｗｅｂサーバ１１３から収集し、Ｗｅｂ統一データ１４１を生成し、ＸＭＬ形式、又はリレーショナルデータベースの形式で保存する。
【０１０３】
次に課金データ生成部１５０は、リアルタイム、定期的、又は課金システムから要求がきた時点のいずれかのタイミングで、ストリーム統一データ１４０、Ｗｅｂ統一データ１４１、課金ルールＤＢ１６０からデータを取得し、取得したデータを、選択、集計、結合し、最終的に、予め規定されている課金データ１７０を生成し、課金システム１８０に提供する。
【０１０４】
また、課金データ生成部１５０が課金システム１８０から受けたリクエストに、予め規定されている形式でパラメータが指定された場合、課金データ生成部１５０はそのパラメータに応じて必要なデータのみを生成し、パラメータを指定しなかった場合に提供されるデータとは異なるデータをサポートシステムに提供することができる。例えば、課金システム１８０からのリクエストにユーザ名が指定された場合、統一データの中から、指定されたユーザがサーバにアクセスしたことによって記録されたデータのみを抽出して処理を行い、指定されたユーザに関するデータのみを課金システム１８０に送信する。
【０１０５】
品質評価データ生成部１５１は、リアルタイム、定期的、又は品質評価システム１８１から要求がきた時点のいずれかのタイミングで、ストリーム統一データ１４０、Ｗｅｂ統一データ１４１、システム構成情報ＤＢ１６１からデータを取得し、取得したデータを、選択、集計、結合し、最終的に、予め規定されている品質評価データ１７１を生成し、品質評価システム１８１に提供する。
【０１０６】
また、品質評価データ生成部１５１が品質評価システム１８１から受けたリクエストに、予め規定されている形式でパラメータが指定された場合、品質評価データ生成部１５１はそのパラメータに応じて必要なデータのみを生成し、パラメータを指定しなかった場合に提供されるデータとは異なるデータをサポートシステムに提供することができる。例えば、品質評価システム１８１からのリクエストにホスト名が指定された場合、統一データの中から、指定されたホスト名のサーバに記録されたデータのみを抽出して処理を行い、指定されたホストに関するデータのみを品質評価システム１８１に送信する。
【０１０７】
利用動向分析データ生成部１５２は、リアルタイム、定期的、又は利用動向分析システム１８２から要求がきた時点のいずれかのタイミングで、ストリーム統一データ１４０、Ｗｅｂ統一データ１４１、コンテンツ情報ＤＢ１６２、ユーザ情報ＤＢ１６３からデータを取得し、取得したデータを、選択、集計、結合し、最終的に、予め規定されている利用動向分析データ１７２を生成し、利用動向分析システム１８２に提供する。
【０１０８】
また、利用動向分析データ生成部１５２が利用動向分析システム１８２から受けたリクエストに、予め規定されている形式でパラメータが指定された場合、利用動向分析データ生成部１５２はそのパラメータに応じて必要なデータのみを生成し、パラメータを指定しなかった場合に提供されるデータとは異なるデータをサポートシステムに提供することができる。例えば、利用動向分析システム１８２からのリクエストにコンテンツ名が指定された場合、統一データの中から、指定されたコンテンツがアクセスしたことによって記録されたデータのみを抽出して処理を行い、指定されたコンテンツに関するデータのみのデータを利用動向分析システム１８２に送信する。
【０１０９】
データの提供を受けた課金システム１８０、品質評価システム１８１、利用動向分析システム１８２は、受信したデータに基づき、Ａ社製ストリーミングサーバ１１０、Ｂ社製ストリーミングサーバ１１１、Ｃ社製Ｗｅｂサーバ１１２、Ｄ社製Ｗｅｂサーバ１１３によって提供されているサービスに対する課金処理、品質評価、利用動向分析を実行する。
【０１１０】
以上のように、実施の形態５によれば、複数種類のサービスに対して、複数のサポートシステムを統一的に扱うことが可能である。従って、各サービスとサポートシステムの組に対して、専用のシステムを構築する必要がない。つまり、通常サービスＮ種類、サポートシステムＭ種類存在すれば、Ｎ×Ｍ個のシステムが必要になるのに対し、ログ仲介システム１ｅを用いることによって、１個のシステムで全てを統一的に扱うことができ、仕様の変更、機能の追加などに対しても一部のモジュールを修正、追加するのみで対応することが可能となる。
【０１１１】
【発明の効果】
以上のように、この発明によれば、各サポートシステムに対して、必要で十分なデータを取得することができ、また、新たなサポートシステムを追加する際、又は既存のサポートシステムの仕様を変更する際、該当するサポートシステムのモジュール・データ形式を追加、変更するだけで、そのサポートシステムに対して対応することが可能となる。
これにより、複数種類のサービスを提供している環境に対して、様々なサポートシステムを容易に追加、拡張することが可能となる。
【図面の簡単な説明】
【図１】この発明に係るログ仲介システムの概要について説明するための図である。
【図２】この発明の実施の形態１に係るログ仲介システムの構成を示す図である。
【図３】この発明の実施の形態１に係るログ仲介システムの、クライアントからのアクセスによりログが蓄積される状態を示す図である。
【図４】この発明の実施の形態１に係るログ仲介システムの、ＢＳＳメディエーションの流れを示す図である。
【図５】この発明の実施の形態２に係るログ仲介システムの実行形態を示す図である。
【図６】この発明の実施の形態３に係るログ仲介システムの実行形態を示す図である。
【図７】この発明の実施の形態４に係るログ仲介システムの実行形態を示す図である。
【図８】この発明の実施の形態５に係るログ仲介システムの実行形態を示す図である。
【符号の説明】
１，１ａ，１ｂ，１ｃ，１ｄ，１ｅログ仲介システム、２サーバ、３，２０，２１，２２，２３，１２０，１２１，１２２，１２３ログ、４，３０，３１，３２，３３，１３０，１３１，１３２，１３３ログ変換部（ログ変換手段）、５統一データ、６外部データＤＢ、７，５０，５１，５２サポートデータ生成部（データ生成手段）、８サポートデータ、９サポートシステム、１０Ａ社製Ｉサーバ、１１Ｂ社製Ｉサーバ、１２Ｃ社製Ｊサーバ、１３Ｄ社製Ｊサーバ、４０Ｉサービス統一データ、４１Ｊサービス統一データ、６０，６１，６２，６３外部データＤＢ、７０，７１，７２サポートデータ、８０，８１，８２サポートシステム、９０クライアントコンピュータＡ、９１クライアントコンピュータＢ、９２携帯端末、９３ネットワーク、９４サーバ、９５ログ、９６無線回線、１１０Ａ社製ストリーミングサーバ、１１１Ｂ社製ストリーミングサーバ、１１２Ｃ社製Ｗｅｂサーバ、１１３Ｄ社製Ｗｅｂサーバ、１４０ストリーム統一データ、１４１Ｗｅｂ統一データ、１５０課金データ生成部、１５１品質評価データ生成部、１５２利用動向分析データ生成部、１６０課金ルールＤＢ、１６１システム構成情報ＤＢ、１６２コンテンツ情報ＤＢ、１６３ユーザ情報ＤＢ、１７０課金データ、１７１品質評価データ、１７２利用動向分析データ、１８０課金システム、１８１品質評価システム、１８２利用動向分析システム。

Claims

サービスをサポートするサポートシステムに対してサポートデータを供給するログ仲介システムにおいて、
クライアントに対しネットワークを介してサービスを提供し、クライアントからのアクセス毎にログを出力するサーバと、
前記サーバから出力されるログを、規定された形式で統一してデータを形成するログ変換手段と、
前記統一したデータを取得し、そのデータに基づいて、前記サポートシステムとの間で規定された形式のデータを生成するデータ生成手段と、
前記データ生成手段により生成されたデータを前記サポートシステムに送信するデータ送信手段とを備えることを特徴とするログ仲介システム。
複数種類のデータ生成手段を備え、複数種類のサポートシステムに対応することを特徴とする請求項１記載のログ仲介システム。
サービスの種類毎にログを統一することを特徴とする、請求項１および請求項２記載のログ仲介システム。
サービスの種類毎に統一したログをリレーショナルデータベース化して保存することを特徴とする請求項３記載のログ仲介システム。
サービスの種類毎に統一したログをＸＭＬ形式の汎用のデータとして保存することを特徴とする請求項３記載のログ仲介システム。
ログ変換手段は、ログ入手時、或いは定期的にログを統一データに変換することを特徴とする請求項１から請求項５のうちのいずれか１項記載のログ仲介システム。
データ生成手段は、サポートシステムで必要となるデータのうちログから取得できないデータを外部から取得することを特徴とする請求項１から請求項６のうちのいずれか１項記載のログ仲介システム。
データ生成手段は、ログ入手時、或いは定期的、若しくはサポートシステムからの要求が発信されたときに、統一データからサポートデータを生成し、前記サポートシステムに対して送信することを特徴とする請求項１から請求項７のうちのいずれか１項記載のログ仲介システム。
サポートシステムからデータ生成手段に対し、条件を指定してデータの要求がなされた場合、前記条件に合致したデータのみを供給することを特徴とする請求項１から請求項８のうちのいずれか１項記載のログ仲介システム。