WO2012049863A1 - 操作ログ格納システム、装置、およびプログラム - Google Patents

Abstract

　クライアントの対象アプリケーションの状態をサーバで記録し、状態変化ごとに符号効率を評価し、常に最適な符号効率を実現する。　クライアント装置３とその操作ログを格納するサーバ装置２で操作ログ格納システム１が構成され、サーバ装置のメモリ装置１４とストレージ装置１６は、通信インタフェース１０を介して、クライアント装置３から送信されてくる操作ログと、操作ログを符号化するための符号方式群５００と、操作ログに基づき推定したクライアント装置上のプログラム状態に基づいて、符号表を生成する符号表生成プログラム１０４等を記憶する。クライアント装置３のメモリ装置１４は、サーバ装置２から送信された符号表と、対象アプリケーション群１１０と、操作ログを取得する操作ログ取得プログラム１０８を記憶する。サーバ装置２は、クライアント装置３から受信した操作ログを操作ログとして順次ストレージ装置１６に格納する。

Description

操作ログ格納システム、装置、およびプログラム

　本発明はアプリケーションの操作ログの取得、格納システムに係り、特にシステムを構成する装置間の通信量削減技術に関する。

　近年、ネットワークを介した装置同士の通信が普及し、通信を利用した装置同士の連携が一般化してきている。特に顕著な例として、Ｗｅｂアプリケーションが挙げられる。これはサーバ装置が提供するブラウザ装置が解釈可能なアプリケーションをクライアント側で処理し、必要に応じてクライアント装置からサーバ装置へデータを送信することで、実現されるアプリケーション形態である。

　このＷｅｂアプリケーションにおいては、多種多様なクライアント装置上でアプリケーションが動作するため、そのユーザビリティや性能はユーザ環境ごとで異なる。そのため、クライアント装置上のＷｅｂアプリケーションに対して行われた操作あるいはイベントからＷｅｂアプリケーションの利便性を評価したいという要求が多く出てきている。

　そこで、サーバ装置のＷｅｂアプリケーションに一定間隔でクライアント装置の操作をサーバ装置に送信し、その操作ログを格納するアプリケーションが登場している。しかしながら、このアプリケーションの導入により、ネットワーク負荷が増加してしまうため、Ｗｅｂアプリケーションの元来の応答性能が低下してしまうという問題がある。

　これを解決するもっとも単純な方法は、ジップ(zip)圧縮などの符号方式を利用した操作ログの圧縮があるが、一般的に圧縮を目的とした符号化はその圧縮対象に同符号列が多く重複しないその符号効率(符号化前の符号長と符号化後の符号長の比)が高まらない。これは言い換えれば、操作ログの符号長が十分に長いという前提を必要としているが、これを実現するにはクライアント装置に一時的とはいえ長大な操作ログの格納を強要してしまう。

　このネットワーク負荷低減問題を軽クライアント負荷で解決するため、他方が送信する情報を前処理加工することで、ネットワーク負荷あるいは他方の装置の処理負荷を軽減する技術が特許文献１に記載されている。

特開２００６－２５９８１１号公報

　特許文献１記載の技術は、常に他方の装置で実行される処理が同等であるが故に、前処理に効果的な情報の送信を実現している。Ｗｅｂアプリケーションは通常、複数のページを含んでおり、それぞれのページで行われる処理は大きく異なる。そのため特許文献１記載の方法では、効果的な前処理情報を生成できず、ネットワーク負荷軽減効果が得られない、場合によっては負荷を向上させてしまう可能性がある。

　本発明は上記課題を鑑みて為されたものであって、他方の装置で実行される処理が多岐に渡る場合においても、その操作ログの取得を軽ネットワーク負荷で実現することが可能な操作ログ格納システム、装置、およびプログラムを提供することを目的としている。

　上記の目的を達成するため、本発明においては、操作ログを取得するクライアント装置と操作ログを格納するためのサーバ装置とから構成される操作ログ格納システムであって、クライアント装置とサーバ装置はそれぞれ、プログラム、データを格納する記憶部と、プログラムを処理する処理部と、通信インタフェース部とを備え、サーバ装置の記憶部は、通信インタフェース部を介して、クライアント装置から送信されてくる操作ログと、操作ログを符号化するための複数の符号方式と、受信した操作ログに基づいてクライアント装置上で処理されるプログラムの状態を推定し、推定されたプログラム状態に基づいて、符号表を生成する符号表生成プログラムを記憶し、クライアント装置の記憶部は、サーバ装置から送信された符号表と、プログラムとしての対象アプリケーションと、対象アプリケーションに対する操作ログを取得する操作ログ取得プログラムと、操作ログ取得プログラムが取得した操作ログを、サーバ装置から受信した符号表を用いて符号化する符号変換プログラムとを記憶し、クライアント装置の処理部は、符号変換プログラムにより符号化した操作ログをサーバ装置に送信し、サーバ装置の処理部は、受信した符号化操作ログを逆変換してサーバ装置の記憶部に順次格納する操作ログ格納システムを提供する。

　また、上記の目的を達成するため、本発明においては、クライアント装置で取得された操作ログを収集、格納するためのサーバ装置であって、プログラム、データを格納する記憶部と、プログラムを処理する処理部と、通信インタフェース部とから構成され、記憶部は、通信インタフェース部を介して、クライアント装置から送信されてくる操作ログと、操作ログを符号化するための複数の符号方式と、受信した操作ログに基づいてクライアント装置上で処理されるプログラムの状態を推定し、推定されたプログラム状態に基づいて、符号表を生成する符号表生成プログラムと、クライアント装置で操作ログを収集する対象プログラムであるアプリケーションを記憶し、処理部は、符号表生成プログラムを実行することにより、受信した操作ログに基づいてクライアント装置上で処理されるプログラム状態を推定し、推定されたプログラム状態に基づいて、符号表を生成して、前記クライアント装置に送信する構成のサーバ装置を提供する。

　更に、上記の目的を達成するため、本発明においては、プログラム、データを格納する記憶部と、プログラムを処理する処理部を備え、クライアントで取得されたプログラムの操作ログを収集、格納するサーバの処理部で実行される操作ログ格納プログラムであって、処理部を、通信インタフェース部を介して、クライアント装置から送信されてくる操作ログを受信して格納し、受信した操作ログに基づいてクライアント装置上で処理されるプログラムの状態を推定し、推定したプログラム状態に基づいて、符号表を生成し、生成した符号表をクライアント装置に送信するよう実行させる操作格納プログラムを提供する。

　すなわち、上記の目的を達成するため、本発明の好適な実施態様にあっては、操作ログを格納するためのサーバ装置と操作ログを取得するクライアント装置とから構成される操作ログ格納システムであって、サーバ装置は、プログラムあるいはデータを格納するメモリ装置と、メモリ装置に格納されたプログラムをロードして処理するプロセッサ装置と、クライアント装置と情報を送受信するための通信インタフェースとから構成され、サーバ装置のメモリ装置は、クライアント装置から送信されてくる操作ログを格納する操作ログ格納領域と、操作ログの統計情報及びその符号方式を記録する統計量記録領域とを有し、操作ログに基づいて、クライアント装置上で処理されているプログラムの状態を推定するプログラム状態推定プログラムと、クライアント装置より送信されてきた操作ログの符号化効率を評価する符号効率評価プログラムと、操作ログをプログラム状態推定プログラムにより推定されたプログラム状態に基づいて、最高効率と推定される符号表を生成する符号表生成プログラムと、符号化されて送信されてくる操作ログを逆変換する符号逆変換プログラムと、２つ以上の前記操作ログを符号化するための符号方式とを格納しており、クライアント装置は、プログラムあるいはデータを格納するメモリ装置と、メモリ装置に格納されたプログラムをロードして処理するプロセッサ装置と、プログラムの出力結果を出力する出力装置と、プログラムを操作するための入力装置と、サーバ装置と情報を送受信するための通信インタフェースとから構成され、クライアント装置のメモリ装置は、操作ログを一時的に格納する操作ログ領域と、サーバ装置より送信されてくる符号表生成プログラムによって生成された符号表を格納する符号表領域とを有し、1つ以上の操作を取得する対象アプリケーションと、対象アプリケーションに対する操作を取得する操作ログ取得プログラムと、サーバ装置により指定された符号方式を用いて、操作ログ取得プログラムが取得した操作ログを符号化する符号変換プログラムとを格納している構成の操作ログ格納システムを構成する。

　本発明によれば、アプリケーション操作ログの高効率な収集を軽ネットワーク負荷、更には低クライアント負荷で実現できる。

第一の実施例に係る、操作ログ格納システムの全体構成を示す図である。 第一の実施例に係る、操作ログ格納フローの一例を示す図である。 第一の実施例に係る、最適符号生成機構の一構成例を示す図である。 第一の実施例に係る、符号効率評価ステップのフローチャートの一例を示す図である。 第一の実施例に係る、状態遷移検知ステップのフローチャートの一例を示す図である。 第一の実施例に係る、符号表の一例を示す図である。 第一の実施例に係る、符号方式の一例を示す図である。 第一の実施例に係る、符号方式の他の例を示す図である。 第一の実施例に係る、操作ログ格納システムの動作例を示すシーケンス図である。 第二の実施例に係る、操作ログ格納システムの一構成例を示す図である。 第二の実施例に係る、操作ログ格納フローの一例を示す図である。 第二の実施例に係る、操作ログ格納システムの動作例を示すシーケンス図である。

　本明細書においては、同じ符号が割り当てられている構成要素は同様の構成要素である。また、操作ログとは、アプリケーション上で生成されるイベント全般のログを指し、ユーザ操作による操作履歴とアプリケーションの状態変化であるイベント履歴の何れか一方あるいは両方を含むこととする。更に、本明細書においてデータベースとは、1つ以上のデータを規則づけて構成したデータ群であるレコードの集合であるテーブルを管理するためのデータ管理機能であるとする。

　　[実施例１]
　図１は第一の実施例による操作ログ格納システムの一構成例を示す図である。同図において、操作ログ格納システム１は、操作ログを格納するサーバ装置２と、操作ログ取得対象アプリケーション１１０を格納し、操作ログ取得対象アプリケーション１１０を処理するクライアント装置３から構成され、それぞれの装置は通信線４によって接続されている。この通信線４は、物理的なケーブルで実現してもよいし、無線技術を用いて実現してもよい。また、ＬＡＮ（Local Area Network）やＷＡＮ（Wide Area Network）などのネットワークを利用して実現してもよい。さらにはクライアント装置３、サーバ装置２の何れも一台で構成されている必要はなく、負荷分散などを目的としてそれぞれ複数台配置しても構わない。

　本実施例において、サーバ装置２はクライアント装置３で動作している対象アプリケーション１１０上での操作ログを半永続的に記録、あるいは操作ログの統計量を抽出及び半永続的に記録する装置として機能する。サーバ装置２は、通常の計算機の構成を備え、通信インタフェース１０と、処理部であるプロセッサ装置１２と、記憶部であるメモリ装置１４とストレージ装置１６と、これらの構成要素を接続する通信バス１８とから構成される装置である。

　サーバ装置２の通信インタフェース１０は、通信線４を介して接続された他の装置に対して命令及びデータを送信、或いは当該他の装置からの命令及びデータを受信するための装置である。通信インタフェース１０は必ずしも装置に1台である必要はなく、通信線４の種類が多岐に渡る場合、それらに対応した通信インタフェース１０を複数搭載しても構わないし、専用通信路の確保などを目的として、同一通信線４に複数の通信インタフェース１０を接続しても構わない。以降、サーバ装置２とクライアント装置３をまたぐデータの送受信において特に断りが無い場合は、暗黙的に通信インタフェース１０と通信線４を介して送受信を実現することとする。

　プロセッサ装置１２はメモリ装置１４に格納されているプログラムを実行し、あるいはメモリ装置１４やストレージ装置１６に対するデータの読み書きする、中央処理部(Central Processing Unit：ＣＰＵ)などの装置である。サーバ装置２は、このプロセッサ装置１２は複数台搭載していても構わない。メモリ装置１４から各種のプログラムをプロセッサ装置１２に読み込み、プロセッサ装置１２が処理する動作を、以降「プログラムを実行する」と表現する。

　メモリ装置１４は、サーバ装置２が使用する処理手段を格納および情報を記憶するための装置である。一般的にメモリ装置１４と言えばダイナミックラム（Dynamic RAM：ＤＲＡＭ）などの不揮発メモリによって構成される読み書きが高速なメモリ装置１４を指すが、アプリケーションのレイテンシが許すならば、ハードディスクドライブ（Hard Disk Drive：ＨＤＤ）やソリッドステートドライブ（Solid State Drive：ＳＳＤ）などの大容量記録メディアでもよいし、またはシーディーアール(CD-Recordable:ＣＤ－Ｒ)などのライトワンスメディアでも構わない。またメモリ装置１４は必ずしも単一の装置から構成されているわけではなく、複数台のメモリ装置１４をＲＡＩＤ(Redundant Arrays of Inexpensive Disks)のように並列、あるいはＪＢＯＤ（Just a Bunch Of Disks)のように直列に接続して実現しても構わない。

　メモリ装置１４はプログラム領域１４ｐとデータ領域１４ｄに分割されている。ただしこれらの領域は論理メモリ空間上で必ずしも明確な境界を持って分割されている必要はなく、この領域分け自体が便宜上であることに注意するべきである。

　このプログラム領域１４ｐには、クライアント装置３から送信されてくる操作ログに基づいて、クライアント装置３で動作している操作ログ取得対象アプリケーション１１０の状態を判定するアプリ状態判定プログラム１００と、操作ログの符号効率を評価する符号効率評価プログラム１０２と、指定された符号方式５００およびシーケンスの出現頻度から符号表を生成する符号表生成プログラム１０４と、符号化された操作ログを符号表に基づいて逆変換する符号逆変換プログラム１０６とが格納されている。

　これらのプログラムはメモリ装置１４に常に格納されている必要はなく、実行する際にストレージ装置１６やあるいは通信線４を介して接続された別の装置からロードしてきても構わないし、コンパイルプログラムを有する様態であれば、実行する際にプロセッサ装置１２が解釈できるネイティブコードにソースファイルから変換して、メモリ装置１４に配置しても構わない。

　データ領域１４ｄには、２つ以上の符号方式５００が格納され、対象アプリケーション１１０操作ログ取得セッションにおける現在状態や符号表を管理するためのセッション管理領域６００が配置されている。これらの符号方式５００に関しては、他のプログラムと同様にストレージ装置１６あるいは通信線４を介した別の装置から必要に応じてロードしてきても構わないし、専用の変換プログラムを有する様態であれば、他のプログラムに参照される際、動的に他の言語からネイティブコードに変換しても構わない。

　データ領域１４ｄ中のセッション管理領域６００は、ある対象アプリケーション１１０が起動され、終了するまでの状態を管理するための領域で、セッションで使われている対象アプリケーション１１０の状態ＩＤと符号表を管理している。以降、サーバ装置２におけるアプリケーションの現在状態および符号表の参照は、暗黙的にセッション管理領域６００に問合せしているものとする。

　アプリ状態判定プログラム１００は、操作ログを入力とし、その操作ログに含まれる状態変化を示すイベントを検知した際に前状態と後状態を出力するプログラムである。

　符号効率評価プログラム１０２は操作ログを入力とし、その操作ログの統計量を統計量ＤＢ２２上で更新する機能と更新した統計量に基づいて、サーバ装置２が有する符号方式５００のうち最も符号効率が高い符号方式５００を評価する機能と、その符号効率評価機能により決定される符号方式５００を統計量ＤＢ２２上で更新する機能とを有するプログラムである。

　符号表生成プログラム１０４は操作ログの統計量と符号方式５００を入力とし、操作あるいは順序に従った操作群と対応する符号の対である符号表を出力するプログラムである。以降順序に従った操作群をシーケンスと表記する。

　符号逆変換プログラム１０６は符号化された操作ログと符号表を入力とし、符号逆変換すなわち復号された操作ログを出力するプログラムである。以降、符号化された操作ログを符号化ログと表記する。

　ストレージ装置１６は、クライアント装置３から送信されてくる操作ログとそこから抽出される統計量をデータベース化して半永続的に格納するための装置である。本明細書においてデータベースとは、レコード(1つ以上のデータを規則づけて構成したデータ群)の集合であるテーブルを管理するためのデータ管理機能であって、特定のテーブルに対するレコードの追加・削除・抽出・編集の４つの機能から構成されるデータ管理機能とする。

　一般的にストレージ装置１６と言えば、ＨＤＤやＳＳＤなどの大規模不揮発記録メディアを指すが、アプリケーションが許容する半永続保存が可能であれば、高速なＤＲＡＭなどの不揮発メモリでもよいし、アプリケーションが要求する時間内にデータベースの機能を実現できるならば、ブルーレイディスク(Bru-lay Disc：ＢＤ）などの更新可能光記録メディアを用いても構わないし、データベースが管理できるならば、ＣＤ－Ｒなどのライトワンスメディアを用いても構わない。さらには、メモリ装置１４の容量に余裕があれば、メモリ装置１４内にデータベース領域を配置して、そこに操作ログとその統計量をデータベース化して配置してもよい。あるいは通信インタフェース１０を用いて接続された外部のストレージ装置１６を利用してもよい。

　また、メモリ装置１４と同様にストレージ装置１６も必ずしも単一の装置から構成されている必要はなく、複数台のストレージ装置１６を並列あるいは直列化して実現しても構わない。

　通信バス１８は装置内の構成要素間でのデータ送受信を実現するための装置であり、ＣＰＵバスやアドレスバスなどの内部バスと、シリアルＡＴＡ（Serial ATA）やPCI Expressなどの拡張バスなどを接続して構成される装置である。上記は一般的に有線の通信バス１８であるが、配線の簡素化などを目的として無線の通信バス１８で構成しても構わない。以降、サーバ装置２あるいはクライアント装置３内の装置間での通信において特に断りが無い場合は、暗黙的に通信バス１８を介して送受信を実現することとする。

　クライアント装置３は、操作ログの取得対象となるアプリケーションが動作している装置であり、通常の計算機構成を備え、通信インタフェース１０と、プロセッサ装置１２と、メモリ装置１４と、入力装置２００と、出力装置２２０から構成される装置である。通信インタフェース１０、処理部であるプロセッサ装置１２、記憶部であるメモリ装置１４については、サーバ装置２と同様の構成要素である。

　入力装置２００はユーザの入力を装置が理解可能な電気などの物理信号に変換する装置であり、例えばキーボード、マウス、マイク、センサが挙げられる。入力装置２００は、装置に備え付けである必要はなく、通信線４を介して接続してもよい。出力装置２２０は装置の出力を画像・音波などの人間が理解できる情報へ変換する装置である。例えばディスプレイ、プリンタ、プロッタ、スピーカ、モータが挙げられる。出力装置２２０も同様に、装置に備え付けである必要はなく、通信線４を介して接続してもよい。

　メモリ装置１４上のプログラム領域１４ｐには、操作ログ取得対象となる対象アプリケーション１１０プログラムと、対象アプリケーション１１０を監視してアプリケーションの操作ログを取得してログを符号化してサーバ装置２に送信する操作ログ取得プログラム１０８とが配置されている。対象アプリケーション１１０プログラムは一つでも良いし、複数個あっても構わない。またこれらのプログラムはサーバ装置２のプログラムと同様にメモリ装置１４に常に格納されている必要はない。

　メモリ装置１４上のデータ領域１４ｄには、対象アプリケーション１１０から取得した操作ログが格納される操作ログ領域６０２と、サーバ装置２から受け取った対象アプリケーション１１０毎の符号表が格納されるまた符号表領域６０４とが配置されている。

　以上が第１の実施例による操作ログ格納システムの構成である。これらの構成要素の関連を示すため、図２を用いて、操作ログの生成から格納までの経路について説明する。図２は本実施例による操作ログ格納システムにおける操作ログの取得から格納までの経路を示す図の一例である。なお本明細書の図面においてＰＧとはプログラム(program)を指す。

　まず、図２において、クライアント装置３上の対象アプリケーション１１０での操作は、それぞれ操作ログ取得プログラム１０８によって取得される。この取得された操作ログ４２は操作ログ領域６０４に一時的に格納される。操作ログ４２が蓄積された時点で、操作ログ取得プログラム１０８は、符号表領域６０４に格納されている、それぞれのアプリケーションに応じた符号表を参照して操作ログ４２を符号化し、符号化ログ４２ｅを生成するとともに、符号化が完了した操作ログ４２を操作ログ領域６０２から消去する。この符号化を開始する操作ログ４２の蓄積量は、操作ログ取得プログラム１０８の設定によって決定される値で、クライアント装置３が操作ログ４２の一時格納を許可しない様態においては、1操作ログ４２ごとに符号化を実施する。符号化が完了した時点で、操作ログ取得プログラム１０８は通信インタフェース１０を介して、符号化ログ４２ｅをサーバ装置２へと送信する。

　サーバ装置２に送信された操作ログの符号化ログ４２ｅはまず、サーバ装置２の符号逆変換プログラム１０６によって受信される。符号逆変換プログラム１０６は符号表４０を参照して符号化ログ４２ｅを逆変換する。この符号表４０はクライアント装置３に送信した符号表と同様の符号表であり、セッションごとの管理は符号表生成プログラム１０４がセッション管理領域６００を用いて実現している。符号逆変換プログラム１０６は逆変換した操作ログ４２を最適符号生成機構９００に送信する。

　最適符号生成機構９００は最適符号方式５００の決定ならびに符号表４０の生成、操作ログ４２とその統計量の記録を行う処理機構である。最適符号生成機構９００の符号効率評価プログラム１０２は、各符号方式５００について、受信した操作ログ４２に対して適用した場合の符号効率を評価、また操作ログ４２から統計量を抽出し、それらに対応する統計量ＤＢ２２内のテーブルを更新する。その後、符号効率評価プログラム１０２はアプリケーション状態判定プログラム１００に操作ログ４２を送信する。

　アプリケーション状態判定プログラム１００は受信した操作ログ４２に含まれるイベント履歴より、アプリケーション状態の変更を判定する。変更があった場合、統計量ＤＢ２２より適合する符号方式５００を抽出し、符号表生成プログラム１０４に通知する。

　通知を受けた符号表生成プログラム１０４は、必要があれば符号方式５００群から適切な符号方式５００を選択し、符号表４０を再生成してクライアント装置３に送信する。クライアント装置３が受信した符号表４０は操作ログ取得プログラム１０８によって、符号表領域６０４で更新される。最後に、アプリケーション状態判定プログラム１００は、操作ログ４２を操作ログＤＢ２０に格納し、操作ログ４２の格納が完了する。

　以上が操作ログ４２の生成から格納までの大まかな過程である。以降、本実施例における、最適符号生成機構９００での処理を、図３～図８を用いて詳しく説明する。

　図３は最適符号生成機構９００の実装の一具体例を示す図である。以下、その要部構成の詳細について説明する。
<符号効率評価プログラム１０２動作>
　符号逆変換プログラム１０６から送信されてくる操作ログ４２を受信した符号効率評価プログラム１０２は、統計量抽出ステップ７８０にて操作ログ４２より統計量を抽出し、統計量ＤＢ２２の操作出現事後確率記録テーブル３０６、シーケンス出現事後確率記録テーブル３０８およびシーケンス管理テーブル３０４の中で現在状態に対応するレコードをそれぞれ更新する。また符号効率評価ステップ７８２でサーバ装置２が有する符号方式５００のうち、最高符号効率で更新した統計量を符号化可能な符号方式５００を決定する。

　図４は操作ログ４２の符号効率評価ステップ７８２の実装例であり、順次ステップＳ４０１～Ｓ４０６を説明する。まず、最適符号効率Rを1、カウンタiを1で初期化する。（Ｓ４０１）このカウンタiはサーバ装置２が有する各符号方式５００の参照に使用するカウンタであり、変域を1からnとする。

　その後、サーバ装置２が有する符号方式５００で受信した操作ログ４２を符号化し、その符号長を基の操作ログ４２の符号長で除算する。（Ｓ４０２）この除算結果が符号方式５００による符号効率rであり、符号効率評価ステップ７８２はすべての符号方式５００の中から最小のrを検出するアルゴリズムである。

　その後、rを現在のRと比較し、rがRより小さければ最適符号効率Rをrで更新する。（Ｃ４００－ＹＥＳ，Ｓ４０３）また、符号方式５００を最適符号方式(図示せず)とする。（Ｓ４０４）その後、カウンタiとサーバ装置２が有する符号方式５００の数nと比較し、等しくなければ、すなわち全ての符号方式５００の比較が終了していなければ、カウンタiを進め、次の符号方式５００m(i+1)の符号効率rを算出する。（Ｃ４０１－ＮＯ,Ｓ４０５）
　全ての符号方式５００の符号効率算出が完了していれば、符号効率評価ステップ７８２を終了し、最適符号方式を出力する。（Ｓ４０６）
　符号効率評価プログラム１０２は、符号効率評価ステップ７８２にて決定した最適符号方式を統計量ＤＢ２２が管理している符号方式管理テーブル３００で現在の状態に対応するレコードを更新する。その後、操作ログ４２をアプリ状態判定プログラム１００へ送信する。
<アプリ状態判定プログラム１００の動作>
　図３に示したアプリ状態判定プログラム１００はまず、状態遷移検知ステップ７００にて、受信した操作ログ４２を走査して、対象アプリケーション１１０の状態が変化したか検知し、変化があれば、前状態と現在状態のペア４８を出力する。この状態遷移検知ステップ７００について図５を用いて説明する。

　図５は対象アプリケーション１１０の状態遷移検知ステップ７００の実装例である。同図において、まずカウンタiを1で初期化する。（Ｓ５０１）このカウンタは操作ログ４２が含む各ログの参照に使用するカウンタであり、変域は1からnである。

　状態遷移検知ステップ７００はカウンタiにより参照される操作ログ４２が状態遷移イベントかどうか検知する。（Ｃ５００）この状態遷移イベントとは、たとえばアプリケーションが有するチェックボックスなどのチェック状態の変化や、画面にＩＤが振られているアプリケーションならばそのＩＤの変化などであるし、アプリケーションなどにおいてはＵＲＬをＩＤとみなし、ＵＲＬの変化すなわちページ遷移を状態遷移イベントとなる。状態遷移イベントを検知した場合、まず状態遷移イベントを検知したことを示すフラグを立てる。（Ｃ５００－ＹＥＳ，Ｓ５０２）すなわち、対象アプリケーションがＷｅｂアプリケーションの場合、ページ遷移が状態遷移となる。

　その後、操作ログ４２を統計量ＤＢ２２のアプリ状態管理テーブル３０２に問い合わせて現在状態ＩＤを取得する。（Ｓ５０３）もし、この状態が今まで出現したことがない未知の状態であったならば、統計量ＤＢ２２に状態を新規に登録し、割り当てられたＩＤを取得する。（Ｃ５０１－ＮＯ，Ｓ５０４）
　その後、セッション管理領域６００に格納された現在状態ＩＤを前状態ＩＤとして保持し、統計量ＤＢ２２から取得した現在状態ＩＤを新しい現在状態ＩＤとしてセッション管理領域６００に格納する。（Ｓ５０５）上記の操作を全ての操作ログ４２に対して実行し、完了した時点で状態遷移検知フラグが立っている場合は、以上のステップで取得した現在状態ＩＤと前状態ＩＤを符号方式決定ステップ７０２へと送信し、状態遷移検知ステップ７００を終了する。（Ｃ５０３－ＹＥＳ，Ｓ５０７，Ｓ５０８）
　図３の最適符号生成機構９００の説明に戻る。アプリ状態判定プログラム１００の符号方式決定ステップ７０２は、受信した現在状態ＩＤと前状態ＩＤ４８を、統計量ＤＢ２２の符号方式管理テーブル３００に問い合わせて符号方式を抽出する。その後、抽出した符号方式４６を符号表生成プログラム１０４に送信し、符号方式の変更を通知する。

　ただしこのとき、前状態ＩＤで使用していた符号方式の符号効率と現在状態ＩＤで使用するべき符号方式の符号効率より、符号効率の変更による通信負荷軽減量が符号表送信による通信負荷量よりも大きいことを検知できる様態において、符号表交換による通信負荷軽減が見込めない場合は、符号方式決定ステップ７０２は、符号方式の変更を通知しなくてもよい。なお、解析が完了した操作ログ４２は操作ログＤＢ２０に格納する。

　図３に示すように、符号方式の変更通知を受けた符号表生成プログラム１０４は、統計量ＤＢ２２の操作出現事後確率テーブル３０６、シーケンス出現事後確率テーブル３０８およびシーケンス管理テーブル３０４と、変更された符号方式を参照して、符号量計算ステップ７４０において、符号表４０を生成する。

　図６は符号表生成プログラム１０４によって生成される符号表４０の一例である。符号表４０は複数の処理が一つのユニークな符号に対応する表である。本実施例においては、２進表記の符号を割り当てているが、シーケンスと一意に対応するのであれば、別の符号でも構わない。

　ここで、図７および図８を用いて符号表を生成するための符号方式のアルゴリズムについて説明する。図７は符号方式の一例で、一般的にハフマン符号と呼ばれる符号方式である。図８は一般的にRange Coderと呼ばれる符号方式の亜種であり、一定のシーケンス長で符号の生成を中断する点で、元々のRange Coderと異なる。

　図７の符号方式のアルゴリズムにおいて、まず、統計量ＤＢ２２のシーケンス出現事後確率テーブルを参照し、現在状態におけるシーケンスの出現事後確率リストＳを抽出する。（Ｓ７０１）出現事後確率リストＳはシーケンスとその出現確率のペアsから構成される集合である。

　その後符号表生成プログラム１０４はＳと同サイズの符号表４０Ｅを生成する。（Ｓ７０２）符号表４０Ｅはシーケンスとそれに対応する符号のペアcから構成される集合である。

　まず、符号表生成プログラム１０４は全てのシーケンスに対応する符号を空文字で初期化する。（Ｓ７０３）その後、出現事後確率リストSをその出現確率に基づいて降順ソートする。（Ｓ７０４）
　ここから符号表４０の生成手順に入る。まず、符号表生成プログラム１０４は最も小さい出現確率を有するs(i-1)とリスト上で次の要素(出現確率が次に小さい要素ではない)をs(i)選択する。（Ｓ７０５）初期状態においては降順ソートされているため、先頭の要素s(0)とその次の要素s(1)が選択される。そして、s(i-1)に含まれるシーケンスに対応するＥ内の符号cに’0’、s(i)に含まれるシーケンスに対応するＥ内の符号cに'1’をそれぞれ追記する。（Ｓ７０６）
　この「sに含まれるシーケンス」の意味を明らかにするため、ここでシーケンス出現情報加算操作Ｓ７０７について説明する。2つのsの加算は、sのシーケンスは集合として、sの出現確率は数値としてそれぞれ加算する。

　すなわち、
s(a)=({シーケンスＡ},0.1)
s(b)=({シーケンスＢ},0.05)
の加算操作s(a)+s(b)は
s(a)+s(b)=({シーケンスA,シーケンスB},0.15)
となる。このとき、「s(a)+s(b)に含まれるシーケンス」はシーケンスＡとシーケンスＢであるので、符号表４０ＥのシーケンスＡとシーケンスＢに対応するそれぞれの符号に対して操作を行う。

　符号方式１（５００a)の説明に戻る。s(i-1)に含まれるシーケンスに対応する符号に’0’,s(i)に含まれるシーケンスに対応する符号に’１’を付与した後、s(i-1)にs(i)をシーケンス出現情報加算操作により、加算する。（Ｓ７０７）
その後、s(i)を出現事後確率リストＳより除外する。（Ｓ７０８）この操作により、Sのサイズは１小さくなる。この操作をＳのサイズが１になるまで繰り返す。（Ｃ７００）
　そして、最後に符号表４０Ｅを出力すれば、それぞれのシーケンスに対してハフマン符号が割り当てられており、符号方式１（５００a)による符号表の生成を終了する。（Ｓ７０９，Ｓ７１０）
　次に図８を用いて符号方式２（５００b)による符号表生成について説明する。上述したように、図８は一般的にRange Coderと呼ばれる符号方式５００の亜種であり、一定のシーケンス長で符号の生成を中断する点で、元々のRange Coderと異なる。

　まず、統計量ＤＢ２２の符号方式管理テーブル３００を参照して符号化シーケンス長Ｌを抽出する。（Ｓ８０１）Ｌはユーザによって与えられる一定の値でもよいし、符号効率評価プログラム１０２が数個のＬに関して符号効率を評価し、その中で最適なＬを見出すようにしてもよい。

　次に、統計量ＤＢ２２の操作現事後確率テーブルを参照し、現在状態における操作の出現事後確率リストＯを抽出する。（Ｓ８０２）操作事後確率リストＯは操作とその出現確率のペアoから構成される集合である。

　その後操作出現事後確率リストＯを出現確率に基づいて降順ソートする。(Ｓ８０３)その後符号表生成プログラム１０４は操作出現情報をＬ乗する。（Ｓ８０４）
　この操作について説明する。Ｏ同士の乗算操作(=2乗)はＯに含まれるすべてのo同士を乗算する操作である。この操作を1度実行するたびにそのサイズはＯに含まれる要素数倍になる。また、o同士の乗算操作は、操作は順序を維持して、集合として加算され、その出現確率は数値として乗算される。

　すなわち、その後符号表生成プログラム１０４はＳと同サイズの符号表４０Ｅを生成する。符号表４０Ｅはシーケンスとそれに対応する符号のペアcから構成される集合である。

　まず、符号表生成プログラム１０４は全てのシーケンスに対応する符号を空文字で初期化する。
o(a)=({操作Ａ,操作Ｂ},0.1)
o(b)=({操作Ｃ},0.05)
の乗算操作o(a)*o(b)は、
o(a)*o(b)=({操作Ａ,操作Ｂ,操作Ｃ},0.005)
となる。ここで({操作Ａ,操作Ｂ,操作Ｃ},0.005)≠({操作Ａ,操作Ｃ,操作Ｂ},0.005)は異なるoであることに注意するべきである。

　この順序を有する操作群とはすなわちシーケンスであり、操作出現情報のＬ乗はある状態における全ての操作の出現確率が独立であると仮定して、発現しうる長さＬのシーケンスの出現確率を計算する操作である。

　符号方式２（５００b)の説明に戻る。ＯのＬ乗が含む全てのo(i)について、その出現確率p(i)とその次の要素o(i+1)までの累積出現確率P(i+1)に含まれる任意の数のうち、最小の符号長で表現できる数をc(i)とする。

　たとえば、
o(i)=({操作Ａ,操作Ｂ,操作Ｃ},0.2)
o(i+1)=({操作Ａ,操作Ｃ,操作Ｂ},0.1)であったならば、区間[p(i),P(i+1)]は[0.2,0.3]となり、その中で最小符号長で表現できる数は0.25=0.01(2進表記)である。本方式においては、全ての符号は小数で示されるため、小数点以下の有効数である’01’がシーケンス(操作Ａ,操作Ｂ,操作Ｃ)に対応する符号として割り当てられる。

　上記の操作を全てのoに対して実施すれば、現在状態で発生しうる全ての長さLのシーケンスに対して符号が割り当てられ、符号表が完成する。（Ｃ８００，Ｓ８０９、Ｓ８１０）
　符号方式２（５００b)の説明の中で触れたが、符号方式２（５００b)はその状態において、発生する全ての操作が独立であることを仮定した符号方式である。そのため、この仮定に沿うアプリケーションおよびユースケースならば、符号方式２（５００b)は符号方式１（５００a)に比べて一般的に高符号効率であることが知られている。その一方でたとえば、「操作Ａと操作Ｂが排他である」などの制約を多く含む場合やシーケンス出現確率リストＳが非常に長大である場合、符号方式１（５００a)の符号効率は符号方式２（５００b)に近づくあるいは良くなる。

　このようなユースケースは実際の対象アプリケーション１１０の解析だけでは、十分ではなく、実際の操作から取得してそれを評価しなければ検知できない点に本実施例の本質がある。

　以上、本実施例において、操作ログの統計から最適な符号方式を選択し、符号表を生成する方法について説明した。以降、図９を用いて本実施例による操作ログ格納システム１の全体の動作について説明する。

　図９は操作ログ格納システム１の動作の一例を示す図である。同図において、Ｐ１は初期化手続き、Ｐ２はログ取得手続き、Ｐ３は符号表更新手続きを示している。
<初期化手続きＰ１の処理>
　まずクライアント装置３の操作ログ取得プログラム１０８は対象アプリケーション１１０の監視を開始する(Ｓ９００)。次にクライアント装置３において、対象アプリケーション１１０がユーザによって起動されると、操作ログ取得プログラム１０８は対象アプリケーション１１０の起動を検知する。(Ｓ９０１,Ｓ９０２)
　操作ログ取得プログラム１０８は初期状態を抽出して、サーバ装置２へと通知する(Ｓ９０３)。

　サーバ装置２へ送信された初期状態情報は、アプリケーション状態判定プログラム１００が受信する。その後、統計量ＤＢ２２に問い合わせて使用する符号方式を抽出する。このとき前状態は「状態なし」として問い合わせる。その後、アプリケーション状態判定プログラム１００は、符号表生成プログラム１０４に抽出した符号方式を通知する(Ｓ９０４、Ｓ９０５)。

　符号表生成プログラム１０４は、通知を受けた符号方式５００に従って符号表を生成５０５し、クライアント装置３に対して符号表を送信する(Ｓ９０６)。以上の初期化手続きにより、操作ログ取得プログラム１０８が操作ログを取得し、符号化して送信する準備が完了する。引き続き、ログを取得して、サーバ装置２へ送信する際の手続きについて説明する。
<ログ取得手続きＰ２の処理>
　次に初期化手続き終了後における、ログ取得手続きシーケンスについて述べる。クライアント装置３において、ユーザによって対象アプリケーション１１０の操作もしくはアプリケーション上でイベントが発生する度に、操作ログ取得プログラム１０８は操作ログを取得する (Ｓ９０７)。操作ログ取得プログラム１０８は、先に受信した符号表を参照し、取得した操作ログを符号化する（Ｓ９０８）。その後符号化した操作ログをサーバ装置２に対して送信する(Ｓ９０９)。この送信のタイミングは符号化した操作ログの情報量がクライアント装置３の操作ログ領域６０２において、予め決定しておいた閾値を超えるときに送信するようにしても良いし、符号化が成功するごとに送ってもよいし、クライアント装置３の操作ログ領域６０２が十分に用意された様態ならば、状態遷移が発生したタイミングで送信するようにしてもよい。

　サーバ装置２上の符号逆変換プログラム１０６は、クライアント装置３からログ受信し、セッション管理領域６００に格納されている符号表を参照して符号化ログ４２ｅを逆変換し、元の操作ログ４２を生成する。(Ｓ９１０)。その後、この操作ログ４２は、符号効率評価プログラム１０２へ送信される。

　符号効率評価プログラム１０２では、この操作ログ４２に適用するべき符号効率の評価を行う。符号効率評価プログラム１０２は、まず、操作ログ４２の統計量を計算し、統計量ＤＢ２２を更新する(Ｓ９１１)。次に、効率評価として、符号方式５００群を参照しながら、各符号方式を利用した場合の符号効率を計算し、もっとも高符号効率な方式を決定し、統計量ＤＢ２２を更新する(７８２，Ｓ９１２)。

　次に操作ログ４２は、アプリケーション状態判定プログラムに送信され、操作ログ４２を元にアプリケーションの状態を判定し、状態が前状態から変化したかどうかを検知する(Ｓ９１３，７００)。さらにアプリケーション状態判定プログラムは、操作ログ４２を操作ログＤＢ２０に格納する(Ｓ９１４)。

　以上の手続きにより、操作ログをクライアント装置３上で符号化し、サーバ装置２上で逆変換と符号方式の最適化を実現したうえで操作ログを格納できることを示した。以降、更新した符号方式をクライアント上で更新する手続きについて説明する。
<符号表更新手続きＰ３の処理>
　上記の操作ログ取得手続きＰ２において、対象アプリケーション１１０の状態変化を検知した場合、符号表更新手続きＰ３が呼び出される。
この手続きにおいては、まずアプリ状態判定プログラム１００が、前状態と現在状態を統計量ＤＢ２２に問い合わせて、合致した符号方式を抽出する。
その後、符号方式を符号表生成プログラム１０４に通知する(Ｓ９０４,Ｓ９０５)。符号表生成プログラム１０４は、通知を受けた符号方式に従って符号表を再生成５０６し、クライアント装置３に対して符号表を送信する(Ｓ９０６)。

　なお上記の手続きは符号表の更新をアプリ状態遷移発生時に行っているが、より最適な符号効率を求めるアプリケーションにおいては、最高符号効率な符号方式が変化する度に更新しても良いし、別の事象を契機にしても良い。

　以上詳述した、第一の実施例による操作ログ格納システムによれば、対象アプリケーションの状態に適した、符号効率でサーバ装置とクライアント装置間のネットワーク負荷を低減できる。

　　[実施例２]
　第一の実施例においては、対象アプリケーション１１０はクライアント装置３に予め格納されていたが、Ｗｅｂアプリケーションなどにおいては、サーバ装置２側に対象アプリケーション１１０があり、クライアント装置３が有するアプリケーション処理プログラムの要求に応じて、サーバ装置２から対象アプリケーション１１０を送信する様態もありうる。そのような実施態様を第二の実施例として以下説明する。

　図１０は第二の実施例における操作ログ格納システム１において、サーバ装置２から対象アプリケーション１１０を送信する態様の一例を示す図である。

　同図において、操作ログ格納システム１は、操作ログの対象アプリケーション１１０と操作ログを格納するサーバ装置２と、操作ログ取得対象アプリケーション１１０を処理するクライアント装置３から構成される。本実施例において、サーバ装置２とクライアント装置３の装置構成は、第一の実施例の図1に示した例と同様である。

　すなわち、サーバ装置２のプログラム領域１４ｐには、クライアント装置３から送信されてくる操作ログに基づいて、操作ログ取得対象アプリケーション１１０の状態を判定するアプリ状態判定プログラム１００と、操作ログの符号効率を評価する符号効率評価プログラム１０２と、指定された符号方式５００と、シーケンスの出現頻度から符号表を生成する符号表生成プログラム１０４と、符号化された操作ログを符号表に基づいて逆変換する符号逆変換プログラム１０６とが配置されている。本実施例においても、データ領域１４ｄには、２つ以上の符号方式５００が格納されている。

　また、本実施例のサーバ装置２のデータ領域１４ｄには、操作ログ取得対象となる対象アプリケーション１１０のプログラムと、対象アプリケーション１１０を監視してアプリケーションの操作ログを取得してログを符号化してサーバ装置２に送信する操作ログ取得プログラム１０８とが格納されている。本実施例において、これらのプログラムは、クライアント装置３からサーバ装置２に要求がある場合にクライアント側に送信されることで利用されるため、第一の実施例とは異なり、サーバ装置２上のデータ領域１４ｄに格納されている。なお、ストレージ装置１６及びストレージ装置１６内で保持されるＤＢ２０、２２については第一の実施例と同様である。

　また、本実施例のクライアント装置３のメモリ装置１４内のプログラム領域１４ｐには、サーバ装置２の操作ログ取得対象アプリケーション１１０に対して要求を行うアプリケーション処理プログラム１１２が配置されている。

　このアプリケーション処理プログラム１１２は、他の対象アプリケーション１１０を読込み、動作させるプログラムであり、具体的にはＷｅｂブラウザなどである。Ｗｅｂブラウザを例にとれば、別の装置あるいはクライアント装置３自身が有する、ＨＴＭＬ(Hyper Text Markup Language)やJavaScript(Ｊａｖａは登録商標）などで表現されるＷｅｂページをＨＴＴＰ（Hyper Text Transfer Protocol)などのプロトコルに従って取得し、Ｗｅｂブラウザが有するレンダリングエンジンやスクリプトエンジンを用いて、Ｗｅｂページを可視化、ユーザに提供するプログラムである。アプリケーション処理プログラム自体に改変がなくとも、読込む対象アプリケーション１１０によって振る舞いが変わることが特徴であり、本実施例は、対象アプリケーション１１０に操作ログ取得プログラム１０８と符号表４０を埋込んで送信し、クライアント装置３上での操作ログ４２を取得することを目的とした様態について説明する。

　以上、図１０を用いて説明したシステム構成は、初期状態を示しているため、クライアント装置３のメモリ装置１４上にはアプリケーション処理プログラム以外の構成要素は無い。以降、図１１を用いてアプリケーション処理プログラムによる、サーバ装置２に対して対象アプリケーション１１０要求後の操作ログ取得から格納までの経路について説明する。

　図１１は第二の実施例による操作ログ格納システム１における操作ログ４２の取得から格納までの操作ログ４２の経路を示す図の一例である。

　まず、クライアント装置３上のアプリケーション処理プログラム１１２は、サーバ装置２側に対象アプリケーション１１０の取得を要求する。

　取得要求を受信したサーバ装置２は、対象アプリケーション群１１０中の該当する対象アプリケーション１１０に、操作ログ取得プログラム１０８と対象アプリケーション１１０の初期状態に適した符号方式で生成された符号表４０を対象アプリケーション１１０に埋め込んで送信する。アプリケーション処理プログラム１１２は、サーバ装置２から、操作ログ取得プログラム１０８と符号表４０が埋め込まれた対象アプリケーション１１０を受信し、アプリケーション処理プログラム１１２が管理するメモリ上に保持され、アプリケーション処理プログラム１１２の内部で動作を開始する。

　以降、アプリケーション処理プログラム１１２に対するユーザの操作は、クライアント装置３のメモリ装置１４にロードされた対象アプリケーション１１０ａ、１１０ｂでの操作は、クライアント装置３上のメモリ装置１４にロードされた操作ログ取得プログラム１０８によって取得され、アプリケーションに応じた符号表４０ａ、４０ｂを基に符号化され、通信インタフェース１０を介して、サーバ装置２へと送信される。

　生成、送信された符号化ログ４２ｅはサーバ装置２の符号逆変換プログラム１０６で受信され、符号化ログ４２ｅを、符号表４０を参照して逆変換し、操作ログ４２へと復号する。その後、符号逆変換プログラム１０６は逆変換した操作ログ４２を最適符号生成機構９００に送信する。

　最適符号生成機構９００の符号効率評価プログラム１０２は、符号方式５００群を参照して得た各符号方式について、受信した操作ログ４２に対して適用した場合の符号効率を評価、また操作ログ４２から統計量を抽出し、それらに対応する統計量ＤＢ２２内のテーブルを更新する。その後、符号効率評価プログラム１０２はアプリケーション状態判定プログラム１００に操作ログ４２を送信する。

　アプリケーション状態判定プログラム１００は操作ログ４２に含まれるイベント履歴より、アプリケーション状態の変更を判定する。変更があった場合、統計量ＤＢ２２より適合する符号方式を抽出し、符号表生成プログラム１０４に通知する。通知を受けた符号表生成プログラム１０４は、必要があれば符号方式５００群から適切な符号方式を選択し、符号表４０を再生成してクライアント装置３に送信する。クライアント装置３が受信した符号表４０は操作ログ取得プログラム１０８によって、符号表領域で更新される。

　最後に、アプリケーション状態判定プログラム１００は、操作ログ４２を操作ログＤＢ２０に格納し、操作ログ４２の格納が完了する。以上が第二の様態における対象アプリケーション１１０の要求から、操作ログ４２の生成、格納までの大まかな過程である。

　本実施例においては、第一の実施例と比較すると、初期の操作ログ取得プログラム１０８および符号表４０の埋め込みおよび対象アプリケーション１１０のロードを除けば、残りの過程は第一、第二それぞれの実施例で完全に等しいといえる。これは、各プログラムがいづれの実施例においても利用可能であることを意味しており、本発明の汎用性を示すものである。

　以降、図１２を用いて、第一の実施例と動作が異なる、対象アプリケーション１１０への操作ログ取得プログラム１０８および符号表４０の埋め込みを含む処理について説明する。

　図１２は第二の実施例における操作ログ格納システム１の動作例である。
<初期化手続き Ｐ１の処理>
　まずクライアント装置３のアプリケーション処理プログラム１１２はサーバ装置２の対象アプリケーション群１１０中のログ取得対象アプリケーションに対して、取得要求を実施する(Ｓ１２００)。要求を受けた対象アプリケーションはアプリケーション状態判定プログラム１１２に通知を行い、通知を受けたアプリケーション状態判定プログラム１１２は、通知を基に対象アプリケーションの状態を検知し、現在の状態を統計量ＤＢ２２に問い合わせて現在の状態に合致した符号方式を抽出し、符号表生成プログラム１０４に符号方式を通知する(Ｓ９０３，Ｓ９０４，Ｓ９０５)。

　符号表生成プログラム１０４は、通知を受けた符号方式に従って符号表４０を生成５０５し、符号表４０を対象アプリケーション１１０に埋め込む(Ｓ１２０１)。さらに操作ログ取得プログラム１０８を対象アプリケーション１１０に埋め込み、クライアント装置３に対して対象アプリケーション１１０を送信する(Ｓ１２０２、Ｓ１２０３)。

　以上の手続きにより、クライアント装置３およびサーバ装置２で動作しているプログラムの状態は第一の実施例と同等になる。そのため、ログ取得手続きに関しては、クライアント装置３側に送られた対象アプリケーション１１０及び操作ログ取得プログラム１０８及び符号表４０によって、第一の実施例の図７に示されるログ取得手続きＰ２と同様に、ログ取得手続きを実施できる。

　以降、符号表４０の更新手続きＰ３について説明する。
<符号表更新手続きＰ３の処理>
　本実施例においては、対象アプリケーション１１０の状態遷移時には、サーバ装置２に再度対象アプリケーション１１０の取得要求が実施されるものとする。状態遷移時にこのような手法をとらない様態においては、第一の実施例と同じ方法で符号表４０を更新すればよい。

　ログ取得手続きＰ２の処理において、アプリ状態判定プログラム１００が状態遷移を検知した場合には、前状態と現在状態を統計量ＤＢ２２に問い合わせて、合致した符号方式５００を抽出する。（Ｓ９０４）その後、抽出した符号方式を符号表生成プログラム１０４に通知する。(Ｓ９０５)。

　符号表生成プログラム１０４は、通知を受けた符号方式に従って符号表４０を再生成５０６する。次にサーバ装置２は、生成した符号表４０と操作ログ取得プログラム１０８を埋め込んだ対象アプリケーション１１０をクライアント装置３に送信し、ログ取得が可能な状態にする。(Ｓ１２０１，Ｓ１２０２，Ｓ１２０３)。

　上記の手続きにより、第二の実施例においても第一の実施例と同じ操作で軽通信路負荷の操作ログ格納を実現でき、また対象アプリケーション群をサーバ装置側で保持するため、低クライアント負荷を図ることができる。

　本発明はアプリケーションの操作ログの取得、格納システムを構成する装置間の通信量、負荷削減技術として有用である。

１　操作ログ格納システム
２　サーバ装置
３　クライアント装置
４　通信線
１０　通信インタフェース
１２　プロセッサ装置
１４　メモリ装置
１６　ストレージ装置
１８　通信バス
２０　操作ログデータベース
２２　統計量データベース
４０　符号表
４２　操作ログ
２００　入力装置
２２０　出力装置
５００　符号方式群
９００　最適符号生成機構

Claims (15)

1. 操作ログを取得するクライアント装置と前記操作ログを格納するサーバ装置とから構成される操作ログ格納システムであって、
   前記クライアント装置と前記サーバ装置はそれぞれ、プログラム、データを格納する記憶部と、前記プログラムを処理する処理部と、通信インタフェース部とから構成され、
   前記サーバ装置の前記記憶部は、前記通信インタフェース部を介して、前記クライアント装置から送信されてくる前記操作ログと、前記操作ログを符号化するための複数の符号方式と、受信した前記操作ログに基づいて前記クライアント装置上で処理される前記プログラムの状態を推定し、推定されたプログラム状態に基づいて、符号表を生成する符号表生成プログラムを記憶し、
   前記クライアント装置の前記記憶部は、前記サーバ装置から送信された前記符号表と、前記プログラムとしての対象アプリケーションと、前記対象アプリケーションに対する操作ログを取得する操作ログ取得プログラムと、前記操作ログ取得プログラムが取得した前記操作ログを、前記サーバ装置から受信した前記符号表に基づき符号化する符号変換プログラムを記憶し、
   前記クライアント装置の前記処理部は、前記符号変換プログラムにより符号化した前記操作ログを前記サーバ装置に送信し、
   前記サーバ装置の前記処理部は、受信した前記操作ログを前記サーバ装置の前記記憶部に格納する、
   ことを特徴とする操作ログ格納システム。
2. 請求項１に記載の操作ログ格納システムであって、
   前記対象アプリケーションは、前記サーバ装置から、前記クライアント装置に送信されたものである、
   ことを特徴とする操作ログ格納システム。
3. 請求項１に記載の操作ログ格納システムであって、
   前記サーバ装置の前記記憶部は、前記操作ログに基づいて、前記クライアント装置上で処理されている前記プログラムの前記プログラム状態を推定するプログラム状態推定プログラムを記憶し、
   前記サーバ装置の前記処理部は、前記プログラム状態推定プログラムを実行することにより、前記プログラム状態を推定する、
   ことを特徴とする操作ログ格納システム。
4. 請求項１に記載の操作ログ格納システムであって、
   前記サーバ装置の前記記憶部は、前記操作ログの符号化効率を評価する符号効率評価プログラムを記憶し、
   前記サーバ装置の前記処理部は、前記符号化効率評価プログラムを実行することに、前記符号化方式の効率を評価し、前記符号表生成プログラムを実行する際に、当該評価結果を用いて前記符号表を生成する、
   ことを特徴とする操作ログ格納システム。
5. 請求項１に記載の操作ログ格納システムであって、
   前記プログラムとして前記対象アプリケーションは、Ｗｅｂアプリケーションであり、
   前記サーバ装置の前記処理部は、前記プログラム状態の遷移を示す前記Ｗｅｂアプリケーションのページ遷移時に、前記符号表生成プログラムを実行して前記符号表を生成する、
   ことを特徴とする操作ログ格納システム。
6. 請求項１に記載の操作ログ格納システムであって、
   前記サーバ装置の前記記憶部に、前記クライアント装置から送信されてくる、符号化された前記操作ログを逆変換する符号逆変換プログラムを備え、
   前記サーバ装置の前記処理部は、受信した、符号化された前記操作ログに対し前記符号逆変換プログラムを実行して逆変換する、
   ことを特徴とする操作ログ格納システム。
7. クライアント装置で取得された操作ログを収集、格納するためのサーバ装置であって、
   プログラム、データを格納する記憶部と、前記プログラムを処理する処理部と、通信インタフェース部とから構成され、
   前記記憶部は、前記通信インタフェース部を介して、前記クライアント装置から送信されてくる前記操作ログと、前記操作ログを符号化するための複数の符号方式と、前記操作ログに基づいて前記クライアント装置上で処理される前記プログラムの状態を推定し、推定されたプログラム状態に基づいて、符号表を生成する符号表生成プログラムと、前記クライアント装置で前記操作ログを収集する対象アプリケーションを記憶し、
   前記処理部は、前記符号表生成プログラムを実行することにより、前記操作ログに基づいて前記クライアント装置上で処理される前記プログラムの状態を推定し、推定されたプログラム状態に基づいて、複数の前記符号方式の一つを選定して符号表を生成し、前記クライアント装置に前記符号表を送信し、前記クライアント装置から受信した前記操作ログを前記記憶部に順次格納する、
   ことを特徴とするサーバ装置。
8. 請求項７に記載のサーバ装置であって、
   前記処理部は、前記クライアント装置からの取得要求に対応し、前記記憶部に記憶する前記対象アプリケーションを前記クライアント装置に送信する、
   ことを特徴とするサーバ装置。
9. 請求項８に記載のサーバ装置であって、
   前記処理部は、前記クライアント装置から、前記対象アプリケーションの取得要求を受信した際、前記対象アプリケーションの前記プログラム状態に合致する前記符号方式を抽出する、
   ことを特徴とするサーバ装置。
10. 請求項８に記載のサーバ装置であって、
    前記処理部は、前記クライアント装置から、前記対象アプリケーションの取得要求を受信した際、前記対象アプリケーションの前記プログラム状態に従い前記符号方式を抽出し、抽出した前記符号方式に基づき前記符号表を生成し、前記クライアント装置に前記対象アプリケーションを送信する際、生成した前記符号表を埋込んで送信する、
    ことを特徴とするサーバ装置。
11. 請求項８に記載のサーバ装置であって、
    前記サーバ装置の前記記憶部は、前記操作ログに基づいて、前記クライアント装置上で処理されている前記プログラムの前記プログラム状態を推定するプログラム状態推定プログラムを記憶し、
    前記サーバ装置の前記処理部は、前記プログラム状態推定プログラムを実行することにより、前記プログラム状態を推定する、
    ことを特徴とするサーバ装置。
12. 請求項８に記載のサーバ装置であって、
    前記サーバ装置の前記記憶部は、前記操作ログの符号化効率を評価する符号効率評価プログラムを記憶し、
    前記サーバ装置の前記処理部は、前記符号化効率評価プログラムを実行することに、前記符号化方式の効率を評価し、前記符号表生成プログラムを実行する際に、当該評価結果を用いて前記符号表を生成する、
    ことを特徴とするサーバ装置。
13. プログラム、データを格納する記憶部と、前記プログラムを処理する処理部を備え、クライアントで取得されたプログラムの操作ログを収集、格納するサーバの前記処理部で実行される操作ログ格納プログラムであって、
    前記処理部を、
    前記通信インタフェース部を介して、前記クライアント装置から送信される前記操作ログを受信し、
    受信した前記操作ログに基づいて前記クライアント装置上で処理される前記プログラムの状態を推定し、
    推定されたプログラム状態に基づいて、前記操作ログを符号化する符号表を生成し、
    生成した前記符号表を前記クライアント装置に送信し、
    受信した前記操作ログを順次格納する、
    よう実行させることを特徴とする操作ログ格納プログラム。
14. 請求項１３に記載の操作ログ格納プログラムであって、
    前記クライアント装置で前記操作ログを収集する前記プログラムがＷｅｂアプリケーションの場合、
    前記処理部を、
    前記Ｗｅｂアプリケーションのページ遷移時に、前記符号表を生成する、
    よう実行させることを特徴とする操作ログ格納プログラム。
15. 請求項１３に記載の操作ログ格納プログラムであって、
    前記処理部を、
    前記クライアント装置から、前記操作ログを収集する前記プログラムである対象アプリケーションの取得要求を受信した際、前記対象アプリケーションの前記プログラム状態に合致する前記符号方式を抽出し、
    抽出した前記符号方式に基づき、前記符号表を生成し、
    前記クライアント装置に前記対象アプリケーションを送信する際、前記符号表を埋込んで送信する、
    よう実行させることを特徴とする操作ログ格納プログラム。

Images