JP2014137802A

JP2014137802A - 情報処理装置およびその制御方法、並びにプログラム

Info

Publication number: JP2014137802A
Application number: JP2013007846A
Authority: JP
Inventors: Yuzuru Okubo; 譲大久保
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2013-01-18
Filing date: 2013-01-18
Publication date: 2014-07-28
Anticipated expiration: 2033-01-18
Also published as: JP6021654B2

Abstract

【課題】定期的に情報を外部装置に送信する場合に、プロキシサーバを介した外部装置との接続を考慮しておらず、認証画面におけるユーザの操作の負担が生じていた。
【解決手段】情報処理装置であって、デバイスに関する動作ログの外部装置に対する送信を定期的に行うことを確認するためのダイアログの表示を制御する表示制御手段と、前記動作ログを送信する際に、プロキシサーバとの認証を行う認証手段と、前記プロキシサーバとの認証が成功した場合に、動作ログを外部装置に対して送信する送信手段と、前記プロキシサーバとの認証が失敗した場合に、前記送信手段による動作ログの定期的な送信を抑制する制御手段とを有し、前記制御手段は、前記プロキシサーバの設定が変更された場合に、前記動作ログの定期的な送信の抑制を解除する。
【選択図】図１０

Description

本発明は情報処理装置およびその制御方法、並びにプログラムに関し、特に外部ネットワークの接続の有無に応じて使用状況を管理サーバに送信するシステムに関する。

デバイスに対するユーザの使用状況の調査のための送信プログラムが存在する。このようなプログラムは、定期的にインターネット上の管理サーバに対して使用状況を定期的に送信する。

また、定期的に遠隔地のデバイスの設定を行ったり、遠隔地のデバイスから各種情報を取得したりする技術がある。例えば、特許文献１は、遠隔地の複数のデバイスに係る情報の収集・取得を行う方法について開示している。

特開２００７−９４９４７号公報

デバイス等から使用状況を収集し、収集した使用状況をインターネット上の管理サーバへ送信する際に、ネットワーク内のプロキシサーバの認証が必要なシステムを想定する。送信の際に、プロキシサーバを介する必要がある場合、またはプロキシサーバがインターネットと通信できていない場合、システムは送信の度に利用者に対して認証要求を出さなければならない。

特許文献１では、プロキシサーバを介した環境を想定していないため、定期的に認証操作が必要となり、ユーザのシステムの操作性を損なう場合があるという課題がある。また、クライアント環境のネットワーク設定によっては、ユーザがインストール時に確認画面なしに情報を送信することを同意したとしても、送信のタイミングでプロキシ設定の認証画面がポップアップしてしまい、ユーザの利便性が低下している。

上記の課題を解決するための本発明に係る情報処理装置は、以下の構成を有する。すなわち、デバイスに関する動作ログの外部装置に対する送信を定期的に行うことを確認するためのダイアログの表示を制御する表示制御手段と、前記動作ログを送信する際に、プロキシサーバとの認証を行う認証手段と、前記プロキシサーバとの認証が成功した場合に、動作ログを外部装置に対して送信する送信手段と、前記プロキシサーバとの認証が失敗した場合に、前記送信手段による動作ログの定期的な送信を抑制する制御手段とを有し、前記制御手段は、前記プロキシサーバの設定が変更された場合に、前記動作ログの定期的な送信の抑制を解除する。

本発明によれば、定期的に情報を外部装置に送信する場合に、プロキシサーバを介した外部装置との接続を考慮した制御を行うことで、ユーザの操作の負担を減らすことができる。

本発明に係るコンピュータを含むネットワーク構成の例の図。本発明に係るコンピュータの構成例のブロック図。本発明に係るネットワーク構成の例の図。本発明に係るソフトウェア構成の例の図。プロキシサーバの認証情報入力ダイアログの例の図。ユーザに対する送信の承認ダイアログの例の図。プロキシサーバの設定ダイアログの例の図動作ログ送信処理部のプロキシ認証処理のフローチャート。動作ログ送信処理部の動作ログ送信処理のフローチャート。動作ログ送信処理部のプロキシ設定変更検出処理のフローチャート。

＜実施例１＞
（システム構成）
本発明に係る情報処理装置の一実施形態としてのコンピュータについて説明する。図２は、本実施形態のコンピュータの構成例を説明するブロック図である。なお、特に断らない限り、本発明の機能が実行されるのであれば、単体の機器であっても、複数の機器から構成されるシステムであっても、本発明を適用できることは言うまでもない。また、本発明の機能が実行されるのであれば、ＬＡＮ、ＷＡＮ、インターネット等の有線／無線のネットワークを介して接続がなされ、処理が行われるシステムであっても本発明を適用できる。

図２は、コンピュータ２００の構成を示す。なお、本実施例に係るクライアントコンピュータ１０３の構成及びサーバコンピュータ１０２の構成はコンピュータ２００の構成と同一である。

コンピュータ２００は、ＲＯＭ２０２のプログラム用ＲＯＭあるいは外部記憶装置２０５に記憶された文書処理プログラム等に基づいて図形、イメージ、文字、表（表計算等を含む）等が混在した処理を実行するＣＰＵ２０１を備える。さらに、ＣＰＵ２０１は、システムバス２０４に接続される各デバイスを統括的に制御する。また、コンピュータ２００は、これら以外に入出力装置を備えていても良い。

また、ＲＯＭ２０２のプログラム用ＲＯＭあるいは外部記憶装置２０５には、ＣＰＵ２０１の制御プログラムであるオペレーションシステム等を記憶する。また、外部記憶装置２０５には各種データを記憶する。ＲＡＭ２０３は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。ネットワークＩ／Ｆ制御部２０６は、ＬＡＮ２０７とのデータの送受信を制御する。

図１において、ＬＡＮ２０７は、上述の各装置の間で情報をやり取りするための通信回線である。インターネット１０１は、ファイアウォール（不図示）を越えて上述の各装置間で情報をやり取りするための通信回線である。インターネット１０１により、サーバコンピュータ１０２とクライアントコンピュータ１０３が属するＬＡＮ２０７とは、ファイアウォールを越えて通信が可能である。ＬＡＮ２０７、インターネット１０１は、例えば、ＴＣＰ／ＩＰプロトコルなどをサポートする通信回線網であり有線・無線は問わない。図１において、サーバコンピュータ１０２は、１台のサーバとして示されているが複数台のサーバコンピュータで構成されていても構わない。また、仮想ＰＣとして構成されていても構わない。

加えて、ＣＰＵ２０１が外部記憶装置２０５に記憶されているプログラムに基づき処理を実行することによって、以降に示すコンピュータ２００のソフトウェア構成及び後述するフローチャートの各ステップの処理が実現される。なお、本実施例において、クライアントコンピュータ１０３およびサーバコンピュータ１０２はいずれも、図２に示すコンピュータ２００の構成であるものとする。

本明細書で説明するシステムおよび方法は、各デバイスの動作ログを回収および送信する。また、本システムは周期的に各デバイスから回収した動作ログを、回収の度ではなく、まとめて定期的に管理サーバに送信することを想定する。

ここでデバイスとは、パーソナルコンピュータ（ＰＣ）や、ＰＣにおけるオペレーティングシステム（ＯＳ）を仮想化した仮想ＰＣ、もしくはリモートＰＣなどを指す。さらには、画像形成装置、プリンタやＭＦＰ（Ｍｕｌｔｉ−ＦｕｎｃｔｉｏｎＰｅｒｉｐｈｅｒａｌ）等の組み込みコンピュータを指す。また、動作ログとは、例えばＰＣであれば、任意のプログラムの起動回数、起動時間、任意のボタンの押下数などの情報を含む。画像形成装置、プリンタ等であれば、印刷枚数、インク、トナー容量などの情報を含む。なお、各メーカは、動作ログを回収することで市場における製品の利用状況を把握できるため、消耗品の適切な生産計画や、顧客のニーズに合う製品、アプリケーションの開発に役立てられるといった利点がある。

図３を用いて本実施例に係るより詳細なネットワーク構成例の図を示す。まず、ネットワーク内において、インターネット３０６経由でアクセス可能な管理センター３０７がある。管理センター３０７は、各デバイスから収集したログデータを回収するためのサーバである。

デバイスＡ３００は、インターネット３０６に直接接続されている。デバイスＡ３００は、自ら動作ログを回収し、管理センター３０７に送信することが可能である。

デバイスＢ３０４は、あるＬＡＮ（ＬｏｃａｌＡｒｅａＮｅｔｗｏｒｋ）３０１に属している。デバイスＢ３０４はインターネット３０６に直接接続できず、外部ネットワークと通信したい場合には、必ずＦＷ（ファイアウォール）３０５を経由する必要がある。デバイスＢ３０４がデバイスＡ３００と同様に自らログ送信機能を備える場合、ＦＷ３０５を介して管理センター３０７に動作ログの送信を行う。一方、デバイスＢ３０４がログ送信機能を備えていない場合、他のシステムによってログ送信を委託しても良い。例えばクライアントＰＣ３０２が、デバイスから動作ログを収集し、管理センター３０７に動作ログの送信機能を備える。このときクライアントＰＣ３０２は定期的にデバイスＢ３０４の動作ログを収集し、ＦＷ３０５を介して管理センター３０７に動作ログを送信することが出来る。

この場合、クライアントＰＣ３０２に動作ログの回収および送信機能を備えるプログラムを導入する必要がある。一般的にクライアントＰＣ３０２がデバイスＢ３０４を使用する際、デバイスＢ３０４用のデバイスドライバをインストールする必要がある。デバイスドライバはＯＳ上でデバイスＢ３０４を認識、操作するために必要であり、出荷時に予めインストールされている場合や、ＣＤ−ＲＯＭ等の記憶媒体またはインターネット３０６等の外部ネットワークから取得して導入する方法などがある。

また、動作ログの回収および送信機能を実現するためのプログラムを導入する機会として、デバイスドライバインストール時に同時に導入する方法がある。ただし、動作ログの回収、送信機能を実現するためのプログラムをクライアントＰＣ３０２に適切に設定できるのであれば、デバイスドライバ設定時以外に導入する方法であっても良い。

デバイスＣ３０３は、ＬＡＮ３０１には直接接続されていないため、自ら動作ログを管理センター３０７へ送信することはできない。しかし、デバイスＣ３０３は、クライアントＰＣ３０２と何らかの接続を持つものとする。この場合、デバイスＣ３０３は、デバイスＢ３０４と同様にクライアントＰＣ３０２に送信処理を委託することにより、管理センター３０７に動作ログを送信することが可能である。

更にＬＡＮ３０１に属する各デバイスと管理センター３０７との通信形態の場合、ＦＷ３０５以外にもプロキシサーバ３０８を経由する必要な場合がある。ここで、プロキシサーバ３０８は別の物理機器として図示されているが、ＦＷ３０５内の一機能として含まれていても良い。この場合、デバイスＢ３０４およびクライアントＰＣ３０２は、ＦＷ３０５を介して動作ログを直接送信できない。また、プロキシサーバ３０８は、通信の代理機能以外にも認証機能を備えるものがある。プロキシサーバ３０８が認証機能を備える場合、デバイスＢ３０４およびクライアントＰＣ３０２は、正しい認証情報を何らかの方法で取得する必要がある。

なお、プロキシサーバ３０８に認証情報を必要とさせる場合、機密情報の流出等のセキュリティを考慮する。そのため、予め認証情報を配布するようなことはせず、各ユーザから認証情報の直接入力を促すことが一般的である。図３のネットワーク構成図の場合、安全にプロキシサーバ３０８を経由して、外部のインターネット３０６に接続できるのは別途アカウント認証を行うクライアントＰＣ３０２のみである。一般的にクライアントＰＣ３０２でプロキシサーバ３０８の認証情報の入力を促す場合、ユーザに何らかのユーザインターフェース（ＵＩ）を表示することが多い。本実施例では図５に示す認証情報入力ダイアログ５００を表示する。ただし、認証情報入力ダイアログ５００を表示する以外でも、認証情報が別物理デバイスに保存されている、または電話オペレーションを必要とするなど、認証情報を入力出来る他の方法であっても良い。

（ソフトウェア構成）
次に図４にて、本実施例のソフトウェア構成の例を示す。情報処理装置４００は、本実施例において、デバイスの動作ログを収集および送信するデバイスを指す。例えば、クライアントＰＣ３０２が該当する。動作ログ管理処理部４０１は、デバイスの動作ログの収集および収集した動作ログを管理センター３０７に送信する処理を管理する。ＳＳＬ／ＴＬＳ管理処理部４０２は、動作ログ管理処理部４０１のＳＳＬ／ＴＬＳを通した通信処理を委託される処理部である。また、動作ログ管理処理部４０１は、直接ＴＣＰを用いて管理センター３０７にデバイスの動作ログを送信しても良い。そのため、動作ログ管理処理部４０１は、ＴＣＰ管理処理部４０３に直接、動作ログ送信を委託する場合もある。通信の送受信の処理を行うためにＴＣＰ管理処理部４０３は、下位レイヤ管理処理部４０４に下位レイヤの処理を委託する。その後、ネットワークＩ／Ｆ４１０を管理するドライバを介して外部ネットワークとの通信が行われる。

ステータスストア４０５、認証情報ストア４０６、認証試行数ストア４０７、プロキシ設定ストア４０８、および自動送信可否ストア４０９は、情報を格納する格納領域を示している。これらのストアはＲＯＭ２０２のデータ用ＲＯＭあるいは外部記憶装置２０５と同等の場所に永続的に確保される出来ることが望ましい。ステータスストア４０５には、動作ログ管理処理部４０１の状態を保存する。本実施例では通信可能状態および通信不可状態のいずれかが格納されるが、必要であれば他の状態を格納しても良い。

認証情報ストア４０６は、プロキシサーバまたは他のプロトコルの認証情報が格納される。ここで認証情報は、主に認証情報を毎回入力することを省くたびに利用される。認証情報ストア４０６は多くの場合、ＯＳが管理していることが多いが、システム独自で作成、管理しても良い。認証試行数ストア４０７は、動作ログ管理処理部４０１がプロキシサーバ３０８と認証処理を行う際に連続で失敗した数を記憶する領域である。プロキシ設定ストア４０８は通常外部ネットワークにアクセスする際のプロキシサーバ情報が格納されている。

プロキシ設定ストア４０８は、ＯＳによって管理され、ユーザはなんらかの手段と使って書き換えることが可能である。ただし、プロキシ設定ストア４０８をシステム独自で管理しても良い。自動送信可否ストア４０９はユーザにデバイスの操作ログを管理センター３０７に送信しても良いか否かの問い合わせを省略するかどうかの情報が格納される。

（ユーザインターフェース）
図５は、認証情報の入力の際に表示される認証要求のためのダイアログである。認証情報入力ダイアログ５００は、ユーザＩＤ入力ボックス５０２とパスワード入力ボックス５０３、ボタン５０４、および認証情報の記憶の可否を問う認証情報記憶チェックボックス５０５を有する。ただし、認証情報記憶チェックボックス５０５は必須ではない。また、対象プロキシサーバの表示５０１のように、どの認証サーバの認証を行おうとするかを表示しても良い。

本実施例のようなデバイスの使用状況を顧客から回収および送信するシステムは、顧客のプライバシーを含む情報を送信するために、一般的に送信には顧客の同意を得る必要がある。図６は、定期送信される動作ログの送信時に表示するダイアログ６００である。本実施例において、ダイアログ６００を用い、インターネット３０６を通して回収した動作ログを管理センター３０７に送信しても良いか否かをユーザに問い合わせて、確認する。ダイアログ６００は、原則として動作ログを送信する度にユーザに表示する必要がある。しかし、自動送信チェックボックス６０２にチェックを入れることで、以降の送信時にダイアログ６００を表示しないで動作ログを送信することが可能となる。自動送信動作により、動作ログを送信することを許可するユーザは、送信の度にダイアログ６００上で毎回同意する手間を省くことができる。

なお、このダイアログ６００は、動作ログの収集対象となるデバイスのためのデバイスドライバをインストールする際に、最初に表示されるように表示制御を行う。具体的には、デバイスドライバをインストールするためのインストーラが、インストール処理の途中で、ユーザにダイアログ６００を提供する。これにより、ユーザは、いずれのデバイスの動作ログが送信されるのかを容易に把握できるタイミングで、ダイアログ６００の問い合わせを確認できる。

ダイアログ６００のＯＫボタン６０１を押下することで本システムは動作ログの送信を開始する。動作ログ送信元（クライアントＰＣ）と管理センター３０７は、ＨＴＴＰプロトコルと、必要に応じてＳＳＬ／ＴＬＳプロトコルを用いて送信を行う。ただし、送信元から管理センター３０７に通信可能な、他の任意の通信プロトコルを用いても良い。多くの組織内のＬＡＮ３０１では、受信パケット以外にも機密情報の流出を防ぐために、ＦＷ３０５により送信パケットを制限している。

ダイアログ６００のＯＫボタン６０１を押下後、本システムは通信プロトコルを利用し、通信を行う。しかし組織内のＬＡＮ３０１から外部ネットワークにアクセスする際にプロキシサーバ３０８を経由する必要がある場合がある。この場合、プロキシサーバ３０８が必要かどうかを確認するために、クライアントＰＣ３０２のＯＳがプロキシサーバ情報を保持していることが一般的である。また、本実施例では、図７に示すようにプロキシサーバの設定手段を提供する。

図７に示すプロキシサーバの設定ダイアログ７００では、プロキシサーバ３０８を手動で設定するか自動的に検出するかを選択して設定することができる。プロキシサーバ３０８の自動的な検出は、例えばＷＰＡＤ（ＷｅｂＰｒｏｘｙＡｕｔｏＤｉｓｃｏｖｅｒｙ）と呼ばれるプロトコルを用いて自動的な検出を行うことができる。しかし、自動的に検出可能であれば他のプロトコルを用いても良い。また、ＰｒｏｘｙＡｕｔｏ−Ｃｏｎｆｉｇファイル（ｐａｃファイル）と呼ばれる、アクセスしたいＵＲＬ（ＵｎｉｆｏｒｍＲｅｓｏｕｒｃｅＬｏｃａｔｏｒ）によって自動的にプロキシサーバの使用、およびプロキシサーバの選択を決定するファイルを指定しても良い。手動でプロキシサーバ３０８を決定する場合、プロキシサーバ３０８のＩＰアドレスまたはドメイン名をアドレス入力ボックス７０３に、またＴＣＰのポート名をポート入力ボックス７０４に入力することで設定が行える。プロキシサーバに関する情報は、ＯＳが有するプロキシサーバ情報を更新することで設定を完了する。ここでは、ＵＩとして設定ダイアログ７００を用いて設定する方法を示したが、ＵＩを表示せずに、単にプログラムおよびスクリプトを用いて、設定を行っても良い。

（プロキシ認証処理）
プロキシ認証処理の詳細について図８を用いて説明する。本処理フローは、クライアントＰＣ３０２のＣＰＵがＨＤＤ等に記憶されたプログラムをＲＡＭに読み出し、実行することにより実現される。

Ｓ８０１にて、動作ログ管理処理部４０１は、設定ダイアログ７００を介して設定されたプロキシサーバ情報を読み込む。また、必要であればプロキシサーバ情報からプロキシサーバを確定させるために、この段階で対象のプロキシサーバと通信を行ってもよい。本実施例では、プロキシサーバ３０８のＩＰアドレスおよびポート番号が取得される。

Ｓ８０２にて、動作ログ管理処理部４０１は、プロキシサーバ３０８に対してサーバ認証が必要か否かを判定する。Ｓ８０２にて、動作ログ管理処理部４０１は、Ｓ８０１で取得したプロキシサーバ情報を用いてプロキシサーバ３０８に対して通信を行う。ＨＴＴＰプロトコルに準拠したプロキシサーバであれば、認証が必要である旨を記載したデータがクライアントＰＣ３０２に返信される。認証が必要である場合には（Ｓ８０２にてＹＥＳ）、動作ログ管理処理部４０１は、プロキシサーバ３０８から返送された情報からどの認証方式を使用するかを決定する。プロキシの認証方式はいくつか種類があり、プロキシサーバ３０８が使用可能な認証方式をクライアントＰＣ３０２に提示し、その中で最もセキュリティが強固なものをクライアントＰＣ３０２が決定する。その後、Ｓ８０３へ進む。認証が必要でなく、そのまま外部ネットワークと通信可能であれば（Ｓ８０２にてＮＯ）、本処理のフローを終了する。

Ｓ８０３にて、動作ログ管理処理部４０１は、認証試行数ストア４０７に保持された値をひとつ増加させる。Ｓ８０４にて、動作ログ管理処理部４０１は、認証試行数ストア４０７から読み出した情報を基に、認証試行回数が規定値を超えたか否かの判定を行う。ここで規定値は、任意に設定して構わない。規定値は、認証が連続して何回まで失敗してよいかを示す。また、規定値は静的に決定する必要はなく、例えば、収集対象のデバイスの数や管理センター３０７からの指示など、何らかの条件を元に動的に変動させてもよい。認証試行数が規定値を超えた場合（Ｓ８０４にてＹＥＳ）、動作ログ管理処理部４０１は、一定期間通信が不可能であると判定し、Ｓ８１０へ遷移する。一方、認証試行数が規定値未満であった場合（Ｓ８０４にてＮＯ）、Ｓ８０５へ進む。

Ｓ８１０にて、動作ログ管理処理部４０１は、一定期間通信が不可能であると判定されたため、ステータスストア４０５のステータスを通信不可状態に設定する。そして、本処理フローを終了する。

Ｓ８０５にて、動作ログ管理処理部４０１は、該当する認証情報がすでにクライアントＰＣ３０２に存在するかどうか否かを判定する。該当する認証情報とは、図５に示す認証情報入力ダイアログ５００にて認証情報記憶チェックボックス５０５にチェックが入った状態で認証に成功した場合に、クライアントＰＣ３０２に保存される認証情報である。ここで認証情報とはユーザ名およびパスワードのことを指すが、他の認証に必要な情報を含んでいても良い。認証情報はＯＳが備える標準の認証情報管理サービスを用いても良いし、システム独自の認証情報記憶機能を用いても良い。

該当する認証情報がある場合（Ｓ８０５にてＹＥＳ）、Ｓ８０９にて動作ログ管理処理部４０１は、ＯＳの標準の認証情報管理サービスまたは独自の認証情報記憶機能から保存された認証情報を取得する。そして、Ｓ８０７へ進む。一方、該当する認証情報が無い場合（Ｓ８０５にてＮＯ）、Ｓ８０６にて動作ログ管理処理部４０１は、ユーザに認証情報を問い合わせる。この時、動作ログ管理処理部４０１は、認証情報入力ダイアログ５００、またはこれと同等な方法でユーザから認証情報を取得する。そして、Ｓ８０７へ進む。

Ｓ８０７にて、動作ログ管理処理部４０１は、Ｓ８０６またはＳ８０９で取得した認証情報を通信に用いる認証情報として設定する。Ｓ８０８にて、動作ログ管理処理部４０１は、設定された認証情報を用いてプロキシサーバ３０８と通信し、認証を行う。

Ｓ８１１にて、動作ログ管理処理部４０１は、認証に成功したか否かを判定する。認証に成功した場合（Ｓ８１１にてＹＥＳ）、Ｓ８１２に進む。認証が失敗した場合（Ｓ８１１にてＮＯ）、Ｓ８０３に遷移し、認証を再試行する。なお、図８のフローによると認証に成功するまでプロキシ認証処理を抜けられないことになっているが、必要であればリトライ処理やタイムアウト処理を含め、これらの処理結果に応じてフローから抜けるようにしても良い。

Ｓ８１２にて、動作ログ管理処理部４０１は、ステータスストア４０５のステータスを通信可能状態に設定する。Ｓ８１３にて、動作ログ管理処理部４０１は、認証試行数ストア４０７の認証試行数の値をリセットする。そして、本処理フローを終了する。

（動作ログ送信処理）
次に図９を用いて、動作ログ管理処理部４０１がデバイスから取得した動作ログを管理センター３０７に送信する動作ログ送信処理を説明する。本処理フローは、クライアントＰＣ３０２のＣＰＵがＨＤＤ等に記憶されたプログラムをＲＡＭに読み出し、実行することにより実現される。なお、動作ログ送信処理は、デバイスの動作ログを取得したい任意のタイミング、間隔で呼び出して良い。

Ｓ９０１にて、動作ログ管理処理部４０１は、送信すべき動作ログが存在するか否かの判定を行う。動作ログの取得方法、保管方法、および保管場所については、任意の方法、場所でかまわない。

送信すべき動作ログがない場合（Ｓ９０１にてＮＯ）、本処理フローを終了する。送信すべき動作ログがある場合（Ｓ９０１にてＹＥＳ）、Ｓ９０２にて動作ログ管理処理部４０１は、ステータスの情報を取得する。ここでステータスとは、ステータスストア４０５に格納されており、通信可能状態か否かを示す。Ｓ９０３にて動作ログ管理処理部４０１は、ステータスストア４０５から取得したステータスが通信可能状態か否かを判定する。通信可能状態である場合（Ｓ９０３にてＹＥＳ）はＳ９０４に遷移する。通信不可状態である場合（Ｓ９０３にてＮＯ）はＳ９０８に遷移する。

Ｓ９０４にて動作ログ管理処理部４０１は、自動送信が可能か否かの判定を行う。ここで自動送信の可否は、図６に示すダイアログ６００を介して設定され、自動送信可否ストア４０９からその設定値が取得される。自動送信が可能である場合（Ｓ９０４にてＹＥＳ）はＳ９０５に遷移する。自動送信が不可能である場合（Ｓ９０４にてＮＯ）はＳ９０５に遷移する。

Ｓ９０５にて動作ログ管理処理部４０１は、プロキシ認証処理を行う。ここでのプロキシ認証処理は図８にて示したフローである。Ｓ９０６にて動作ログ管理処理部４０１は、プロキシ認証処理（Ｓ９０５）の結果、認証に成功した、または認証の必要が無い場合であるか否かを判定する。認証に成功した、または認証の必要が無い場合である場合（Ｓ９０６にてＹＥＳ）にＳ９０７に遷移する。一方、いずれも満たさない場合（Ｓ９０６にてＮＯ）、本処理フローを終了する。

Ｓ９０７にて動作ログ管理処理部４０１は、デバイスの動作ログを送信する処理を行う。動作ログの送信はＨＴＴＰ、ＳＳＬ／ＴＬＳ、または通信可能な任意のプロトコルを用いてよい。動作ログの送信完了後、本処理フローを終了する。

Ｓ９０８にて、動作ログ管理処理部４０１は、通信不可状態が一定期間以上続いているか否かを判定する。つまり、以前の認証処理において認証が失敗し、通信不可能状態となってから一定期間が経過したか否かを判定する。ここで一定期間とは、システムに要求に応じて任意に決めてよい。また、期間の長さを、プロキシ認証の失敗回数に応じて動的に長くしても良い。すなわち、プロキシ認証処理（Ｓ９０５）に繰り返し失敗した場合に、次回の接続試行までの時間を動的に長くする。または、一定回数プロキシ認証の失敗や、動的に延ばした期間が一定値を超えた場合に、システムの停止、またはアンインストールをユーザに促してもよい。

通信不可状態が一定期間以上続いている場合（Ｓ９０８にてＹＥＳ）、再び送信を試みるためＳ９０４に遷移する。一定期間を経過していない場合（Ｓ９０８にてＮＯ）、本処理フローを終了する。

Ｓ９０４にて自動送信が不可であると判定した場合（Ｓ９０４にてＮＯ）、Ｓ９０９にて動作ログ管理処理部４０１は、送信の承認処理を行う。本実施例では動作ログ管理処理部４０１は、図６に示すダイアログ６００を表示し、ユーザに承認を得る動作を行う。

Ｓ９１０にて、動作ログ管理処理部４０１は、ユーザから送信を承認されたか否かの判定を行う。承認された場合（Ｓ９１０にてＹＥＳ）、Ｓ９０５に遷移する。承認されなかった場合（Ｓ９１０にてＮＯ）、本処理フローを終了する。

以上により、プロキシサーバの認証が所定回数にわたって失敗した場合には、定期的な動作ログの送信を中止する。その後、一定期間が経過した場合には、再度、認証処理を行い、認証が成功した場合には動作ログの送信を再開することとなる。

以上、本実施例によれば、プロキシサーバの認証失敗を学習し、インターネットに接続できないと推定される場合に認証要求回数を抑制することで、ユーザの操作の負担を減らすことができる。

＜実施例２＞
実施例１における動作ログ送信処理（図９）では、外部ネットワークに通信不能と推定される場合に送信をやめ、一定期間以上経過後に通信を試行する方法を示した。本実施例では、実施例１に加え、プロキシサーバ情報の変更を自動的に検出することで外部ネットワークに通信可能となった可能性が高いと推定する手法を示す。

（プロキシ設定変更検出処理）
図１０を用いて本実施例に係るプロキシ設定変更検出処理の説明を行う。プロキシ設定変更検出処理は、実施例１にて示した動作ログ送信処理（図９）内のＳ９０８の判定の際に用いるものとする。すなわち、一度ステータスが通信不能状態となった場合に、Ｓ９０４に遷移し接続を試行するか、動作ログ送信処理を終了するかを決定するために用いる。なお、実施例１のＳ９０８のように時間を元に通信を試みる機構が更に組まれていても構わない。

Ｓ１００１にて動作ログ管理処理部４０１は、旧プロキシサーバ情報があるか否かを判定する。旧プロキシサーバ情報は、独自の格納領域に保持され、動作ログ管理処理部４０１は自由に読み書きが可能であるものとする。旧プロキシサーバ情報が無い場合（Ｓ１００１にてＮＯ）Ｓ１００４に遷移する。旧プロキシサーバ情報がある場合（Ｓ１００１にてＹＥＳ）Ｓ１００２に遷移する。

Ｓ１００２にて動作ログ管理処理部４０１は、旧プロキシサーバ情報の他に現在のプロキシサーバ情報をプロキシ設定ストア４０８から取得する。

Ｓ１００３にて動作ログ管理処理部４０１は、取得した旧プロキシサーバ情報と現在のプロキシサーバ情報との差分があるか否かを判定する。差分が存在する場合（Ｓ１００３にてＹＥＳ）、Ｓ１００４に遷移する。差分が存在しない場合（Ｓ１００３にてＮＯ）、Ｓ１００６へ遷移する。ここでプロキシサーバ情報の差分とは、例えば旧プロキシサーバ情報がｐｒｏｘｙ．ｓｅｒｖｅｒ．ｃｏｍであり、現在のプロキシサーバ情報がｐｒｏｘｙ２．ｓｅｒｖｅｒ．ｃｏｍである場合に差分が有るとみなす。この例以外にも、ＰｒｏｘｙＡｕｔｏ−Ｃｏｎｆｉｇファイルのアドレスの変更など、他のプロキシ通信に関わる設定変更の差分であっても良い。

Ｓ１００４にて動作ログ管理処理部４０１は、プロキシサーバ情報の差分があるため、外部ネットワークに通信できる可能性があるとみなし、通信試行を行うように設定する。つまり、それまでに通信試行が抑制されていた場合には、その抑制を解除することとなる。Ｓ１００５にて動作ログ管理処理部４０１は、現在のプロキシサーバ情報を旧プロキシサーバ情報として保存する。そして、本フローを終了する。

Ｓ１００６にて動作ログ管理処理部４０１は、プロキシ設定は変更されていないとして、通信試行を行わないように設定する。そして本処理フローを終了する。

以上、本実施例によれば、外部ネットワークへの通信設定の変更を自動的に検出することで、認証要求回数をより抑制し、操作の負担を減らすとともに、動作ログ収集の回収頻度を高めることが出来る。

＜その他の実施例＞
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施例の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

Claims

デバイスに関する動作ログの外部装置に対する送信を定期的に行うことを確認するためのダイアログの表示を制御する表示制御手段と、
前記動作ログを送信する際に、プロキシサーバとの認証を行う認証手段と、
前記プロキシサーバとの認証が成功した場合に、動作ログを外部装置に対して送信する送信手段と、
前記プロキシサーバとの認証が失敗した場合に、前記送信手段による動作ログの定期的な送信を抑制する制御手段と
を有し、
前記制御手段は、前記プロキシサーバの設定が変更された場合に、前記動作ログの定期的な送信の抑制を解除することを特徴とする情報処理装置。
前記制御手段は、前記プロキシサーバとの認証の失敗が所定の回数に達した場合に、前記送信手段による動作ログの定期的な送信を抑制することを特徴とする請求項１に記載の情報処理装置。
前記制御手段は、前記プロキシサーバの設定が変更され、さらに前記認証手段により前記プロキシサーバとの認証が成功した場合に、前記動作ログの定期的な送信の抑制を解除することを特徴とする請求項１または２に記載の情報処理装置。
前記表示制御手段は、前記デバイスのデバイスドライバのインストール処理に際して、前記ダイアログを表示することを特徴とする請求項１乃至３のいずれか１項に記載の情報処理装置。
情報処理装置における制御方法であって、
デバイスに関する動作ログの外部装置に対する送信を定期的に行うことを確認するためのダイアログの表示を制御する表示制御工程と、
前記動作ログを送信する際に、プロキシサーバとの認証を行う認証工程と、
前記プロキシサーバとの認証が成功した場合に、動作ログを外部装置に対して送信する送信工程と、
前記プロキシサーバとの認証が失敗した場合に、前記動作ログの定期的な送信を抑制する制御工程と
を有し、
前記制御工程では、前記プロキシサーバの設定が変更された場合に、前記動作ログの定期的な送信の抑制が解除されることを特徴とする制御方法。
前記制御工程では、前記プロキシサーバとの認証の失敗が所定の回数に達した場合に、前記動作ログの定期的な送信が抑制されることを特徴とする請求項５に記載の制御方法。
前記制御工程では、前記プロキシサーバの設定が変更され、さらに前記プロキシサーバとの認証が成功した場合に、前記動作ログの定期的な送信の抑制が解除されることを特徴とする請求項５または６に記載の制御方法。
前記表示制御工程では、前記デバイスのデバイスドライバのインストール処理に際して、前記ダイアログが表示されることを特徴とする請求項５乃至７のいずれか１項に記載の制御方法。
請求項１乃至４のいずれか１項に記載の各手段としてコンピュータを機能させるためのプログラム。