JP6381426B2

JP6381426B2 - 情報処理装置、制御方法、及びプログラム

Info

Publication number: JP6381426B2
Application number: JP2014244099A
Authority: JP
Inventors: 譲大久保
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2014-12-02
Filing date: 2014-12-02
Publication date: 2018-08-29
Anticipated expiration: 2034-12-02
Also published as: US20160154613A1; US10452324B2; JP2016110203A

Description

本発明は、情報処理システム、印刷システム、情報処理装置、制御方法、及びプログラムに関する。

近年、多くの情報機器がインターネットに接続されるようになっており、様々な連携が考えられている。例えば、インターネット上の印刷ソリューションが挙げられる。モバイル端末からプリンタに対して印刷したい場合に、モバイル端末が印刷可能なドキュメントフォーマットへ直接変換出来ないことが多い。このとき、モバイル端末がインターネット上のサービスに対して、印刷可能なドキュメントフォーマットへの変換を依頼することで、モバイル端末から印刷が可能となる。

このようなインターネットを活用したソリューションを作る際に、第三者のクラウド基盤を利用することが多くなっている。クラウド基盤とは仮想化されたプラットフォームを提供するインターネット上のサービスである。第三者のクラウド基盤を利用すると、ソリューション提供者は、ハードウェアを保持及び保守しなくても良く、初期投資が少ないというメリットがあるため、利用が進んでいる。

クラウド基盤は、様々なサービスを提供している。そのサービスの中でも、機能がシンプルなサービスの方がより安価である。例えば仮想ＰＣを貸し出すコンピュートサービスと、ファイルの保存及び読み出しのみ利用可能なストレージサービスとでは、独自の処理が行えないストレージサービスの方が安価である。ソリューション提供者は、ソリューションのコストを抑えるために、ソリューションに安価なストレージサービスを組み込むことが多い。

上述したように、第三者のクラウド基盤で提供されるストレージサービスは、ファイルのアップロード及びダウンロードのみを行う場合が多く、機能が限られている。そのため、インターネット上の印刷ソリューションにおいてストレージサービスを組込んだ場合に、例えば、印刷可能なドキュメントフォーマットに変換するサーバが印刷元ドキュメントの変換完了などをクライアントに対して通知することができない。クライアントは、ポーリングで処理の終了を確認する必要がある。
特許文献１は、予めサーバ側に、端末に対してファイルをダウンロードするための情報であるダウンロードファイルリストを格納しておき、端末に送信するファイル送信方法を開示している。また、端末は、取得したダウンロードリストと、前回取得したダウンロードリストの内容を比較し、該内容が更新されている場合に、サーバにファイルを要求を行う。

特開平１１−３１６７２１号公報

印刷ソリューションシステムにおいて、クライアントが、印刷可能なドキュメントフォーマットに変換済みのファイルをストレージサービスからＵＲＬリスト（ダウンロードリスト）としてポーリングにより取得することが考えられる。このとき、クライアントは、印刷データの総ファイル数（総ページ数）と変換済みのファイル数（ページ数）が一致するまでＵＲＬリストの再取得を行うことで処理の終了を確認することができる。しかし、総ページ数と変換済みのページ数が一致するまでＵＲＬリストを取得し続けるため、サーバへの負荷と通信コストが増大してしまう。ＵＲＬリストの取得回数に上限を設けることも考えられるが、途中でＵＲＬリストが更新された場合（正常な場合）であっても、取得回数が上限に達したことにより取得をやめてしまう可能性がある。

本発明は、データ処理を実行するサーバが正常に稼働しているか否かをサーバへの負荷及び通信コストを増大させることなくクライアントが適切に判断することが可能な情報処理システムを提供することを目的とする。

本発明の一実施形態の情報処理装置は、サーバの作成済みファイルの一覧を取得する取得手段と、前回取得されたファイルの一覧と、今回取得されたファイルの一覧に基づいて、前記サーバにより新たに作成されたファイルが存在するか判断する判断手段と、前記サーバにより新たに作成された前記ファイルが存在しないと判断された場合に、前記ファイルの一覧の取得回数をカウントするカウント手段と、前記取得回数が所定の回数を超えた場合にエラーを通知する通知手段と、を有する。

本発明の一実施形態に係る情報処理システムによれば、データ処理を実行するサーバが正常に稼働しているか否かをサーバへの負荷及び通信コストを増大させることなくクライアントが適切に判断することが可能となる。

本発明の一実施形態に係る情報処理システムの全体構成例を示す図である。情報処理装置のハードウェア構成例を示す図である。クライアントコンピュータのソフトウェア構成例を示す図である。ドキュメント変換ソリューションを説明するためのシーケンス図である。ＵＲＬリストのやり取りについて説明するための図である。ＵＲＬリストのやり取りについて説明するための図である。変換処理を説明するためのフローチャートである。ダウンロード処理を説明するためのフローチャートである。ＵＲＬリスト取得処理を説明するためのフローチャートである。サーバ状態判定処理を説明するためのフローチャートである。サーバ状態判定処理を説明するためのフローチャートである。ＵＲＬリストの取得タイミングの一例を示す図である。サーバタイムスタンプ確認処理を説明するためのフローチャートである。

以下、本発明を実施するための形態について図面などを参照して説明する。
（第１実施形態）
まず、本実施形態の説明に用いる用語について定義する。
ＴＣＰ（ＴｒａｎｓｍｉｓｓｉｏｎＣｏｎｔｒｏｌＰｒｏｔｏｃｏｌ）とは、ファイルの送受信のような信頼性を要求する通信に一般的に利用されるプロトコルである。ＨＴＴＰ（ＨｙｐｅｒｔｅｘｔＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ）とは、ＷｅｂクライアントとＷｅｂサーバの間で各種コンテンツの送受信に用いられるプロトコル（ＲＦＣ１９４５、ＲＦＣ２０６８、及びＲＦＣ２６１６）である。Ｗｅｂサービスでは一般的に、このＨＴＴＰを使用して通信を行う。

図１は、本実施形態に係る情報処理システムの一例としての印刷ソリューションシステム（印刷システム）の全体構成例を示す図である。
サーバ側のネットワーク１００とクライアント側のネットワーク１０４は、それぞれインターネット１０３に接続されている。インターネット１０３は、各ネットワーク間で情報をやり取りするために、ＴＣＰ／ＩＰプロトコルなどの国際規格に準拠する通信回線網である。変換サーバ１０１は、ドキュメントの変換機能を持つ。ストレージサーバ１０２は、ストレージ機能を提供する。無線ルータ１０５は、インターネット１０３と接続されている。無線ルータ１０５は、クライアントコンピュータ１０６と無線通信が可能である。また、クライアントコンピュータ１０６は、無線ルータ１０５を経由して、印刷処理装置（画像処理装置）１０７と互いに通信可能とする。ここで、印刷処理装置１０７は、プリンタ機能のほか、コピー機能、スキャナ機能、またはファクス送信機能等を備えていても良い。印刷処理装置１０７は、無線ルータ１０５と相互に通信可能であり、その接続形態は無線であっても良い。また、変換サーバ１０１は、印刷処理装置１０７が印刷可能なドキュメントフォーマット（データの形式）、またはクライアントコンピュータ１０６が処理可能なドキュメントフォーマットに変換可能とする。また、変換サーバ１０１及びストレージサーバ１０２は、複数台のコンピュータで構成されていても構わない。また、仮想ＰＣとして構成されていても構わない。

図２は、本実施形態に係るクライアントコンピュータ及び各サーバ等の情報処理装置のハードウェア構成例を示す図である。
情報処理装置２００は、ＣＰＵ２０１を備える。ＣＰＵ２０１は、ＲＯＭ２０２、ＲＡＭ２０３、または外部記憶装置２０５に記憶された文書処理プログラム等に基づいて図形、イメージ、文字、及び表（表計算等を含む）等が混在した処理を実行する。さらに、ＣＰＵ２０１は、システムバス２０４に接続される各デバイスを統括的に制御する。クライアントコンピュータ１０６は、他に入出力装置を備えていても良い。
ＲＯＭ２０２または外部記憶装置２０５は、ＣＰＵ２０１の制御プログラムであるオペレーションシステム等を記憶する。また、ＲＯＭ２０２または外部記憶装置２０５は、各種データを記憶する。ＲＡＭ２０３は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能し、ネットワークＩ／Ｆ制御装置２０６は、ＬＡＮ２０７とのデータの送受信を制御する。なお、ネットワークＩ／Ｆ制御装置２０６は、無線通信装置であっても構わない。すなわち、無線アンテナやその制御のための装置を備えていても良い。

図３は、本実施形態に係るクライアントコンピュータのソフトウェア構成例を示す図である。
ドキュメント変換処理部３０２は、ＨＴＴＰ通信を用いた送受信処理を管理し、上位レイヤアプリケーション３０１へのインターフェースを提供する。また下位レイヤに対するデータの送受信を管理する。ドキュメント変換処理部３０２は、本実施形態では１つのソフトウェアライブラリの形で記述する。しかし、オペレーティングシステムそのものに本機能を実装してもよく、またネットワークＩ／Ｆ３０６のハードウェアに実装してもよい。すなわち、同等の機能及びインターフェースが上位レイヤアプリケーション３０１に提供できれば、実施箇所は問わない。

ＴＣＰ管理処理部３０４は、ＴＣＰコネクションを管理する。具体的にはＴＣＰコネクションの接続、受付、及び送受信等を管理し、その結果を上位レイヤアプリケーション３０１等に通知する。また、直接結果を上位レイヤアプリケーション３０１に通知するだけでなく、ＳＳＬ／ＴＬＳ管理処理部３０３のような中間レイヤを使用してもよい。なお、ＳＳＬ／ＴＬＳとは認証、暗号化、及び改ざん検出を行うＷｅｂサービスであり、一般的に使用される技術である。
ＴＣＰ管理処理部３０４までの処理は、ＲＦＣ７９３（ＴＲＡＮＳＭＩＳＳＩＯＮＣＯＮＴＲＯＬＰＲＯＴＯＣＯＬ）の規定を満たし、利用可能なＡＰＩが提供されていればどのような実施方法でも構わない。すなわち、ＴＣＰ管理処理部３０４および下位レイヤ管理処理部３０５が適切なＡＰＩを提供していれば、その実装は問わない。このＴＣＰ管理処理部３０４および下位レイヤ管理処理部３０５は、多くの場合オペレーティングシステムが提供することが一般的であるが、直接実装していても構わない。その実施方法は一般的に広く知られているため、詳細な説明は省略する。

ここで、クライアントコンピュータ１０６が印刷処理装置１０７で印刷を行う際に、変換サーバ１０１においてクライアントコンピュータ１０６から受け取ったデータを印刷処理装置１０７が理解できるデータへと変換するサービスを考える。なお、本実施形態では、通信プロトコルとしてＨＴＴＰを用いるが、これに限られるものではなく、同様の機能を持つ他のプロトコルや独自のものを用いても良い。

図４は、本実施形態におけるインターネットを活用したドキュメント変換ソリューションの処理を説明するためのシーケンス図である。
まず、クライアントコンピュータ１０６は、ステップＳ４００にて変換サーバ１０１に対して変換を指示する。この指示に対して変換サーバ１０１は、変換元ドキュメントのアップロード先ＵＲＬをクライアントコンピュータ１０６に返す。ステップＳ４０１にてクライアントコンピュータ１０６は、ステップＳ４００で得たアップロード先ＵＲＬに対して変換元ドキュメントをアップロードする。なお、アップロード先ＵＲＬは、ストレージサーバ１０２を指している。ステップＳ４０１では変換元ドキュメントのみアップロードしているが、その他の補足情報をアップロードしてもよい。例えば変換後のフォーマットタイプの指定や、解像度、ファイル名、ページ範囲などである。

ステップＳ４０３にて変換サーバ１０１は、ストレージサーバ１０２から変換元ドキュメントを取得する。その後、ステップＳ４０４にて変換サーバ１０１は、ドキュメントの変換を開始する。ステップＳ４０５にて変換サーバ１０１は、ストレージサーバ１０２にＵＲＬリスト５０１を格納する。ＵＲＬリスト５０１とは、変換サーバ１０１により作成済みの変換後ドキュメントの１ページ分のデータが保存された保存先のＵＲＬのリスト（ファイルの一覧）のことである。ステップＳ４０６にて変換サーバ１０１は、ストレージサーバ１０２に変換後ドキュメントを格納する。ステップＳ４０７にてクライアントコンピュータ１０６は、ストレージサーバ１０２からＵＲＬリスト５０１を問い合せ、ダウンロードする。ステップＳ４０８にてクライアントコンピュータ１０６は、ストレージサーバ１０２から変換後ドキュメントをダウンロードする。なお、図４でステップＳ４０４〜Ｓ４０６の順に描かれている処理は、実際には順番を問わず非同期で行われる。すなわち、全てのページの変換が完了する前にステップＳ４０５及びステップＳ４０６の処理が行われる場合がある。そのため、ＵＲＬリスト５０１は、変換が完了した分のＵＲＬのみ記載されることになり、クライアントコンピュータ１０６は、総ページ数分のＵＲＬリスト５０１が取得できるまでステップＳ４０７を繰り返すこととなる。また、ステップＳ４０８の処理は、総ページ数分のＵＲＬリスト５０１が取得できるまで待つ必要はなく、変換後ドキュメントがダウンロード可能になり次第、クライアントコンピュータ１０６は、ダウンロードを開始して良い。

ステップＳ４０９にてクライアントコンピュータ１０６は、変換後ドキュメントを印刷処理装置１０７に送信し、ステップＳ４１０にて印刷処理装置は、受信した変換後ドキュメントを印刷する。なお、全体の処理時間短縮のために、ステップＳ４０８〜ステップＳ４１０を非同期で行ってもよい。すなわち、変換後ドキュメントの全てのページのダウンロード完了を待たずに、ダウンロードが完了したページを即座にステップＳ４０９及びステップＳ４１０の印刷処理に使用してもよい。なお、本実施形態ではクライアントコンピュータ１０６がステップＳ４０８〜Ｓ４０９にて変換後ドキュメントをダウンロードし、印刷処理装置１０７に送信したが、これに限られるものではない。例えば、印刷処理装置１０７がクライアントコンピュータ１０６を介さずに、変換後ドキュメントをストレージサーバ１０２から直接取得するようにしてもよい。

図５は、クライアントコンピュータとストレージサーバとの間のＵＲＬリストのやり取りについて説明するための図である。
ＵＲＬリスト５０１は、変換後ドキュメントの１ページ分のデータが保存された保存先のＵＲＬのリストのことである。図５では、クライアントコンピュータ１０６）、変換サーバ１０１、及びストレージサーバ１０２が正常にＵＲＬリスト５０１のやり取りを終えた場合を示している。
まず、クライアントコンピュータ１０６からの変換要求に対して、変換サーバ１０１は、変換が可能であるという情報と変換後の総ページ数とを返す。図５の例では変換後の総ページ数として５ページを返している。変換後の総ページ数は、変換元ドキュメントのサイズを印刷用ページサイズに合わせる際に、変換元ドキュメントの総ページ数と変換後ドキュメントの総ページ数とが一致しない場合があるために必要である。なお、図５では変換元ドキュメントや印刷設定のアップロードは明示していないが、変換要求の時点で行ってもよい。

次に、クライアントコンピュータ１０６は、１回目のＵＲＬリスト要求をストレージサーバ１０２に送信する。ストレージサーバ１０２は、変換サーバ１０１から受信したＵＲＬリスト５０１をクライアントコンピュータ１０６に対して返す。図５の例では３ページ分のデータのＵＲＬリスト５０１を返している。
続いてクライアントコンピュータ１０６は、２回目のＵＲＬリスト要求をストレージサーバ１０２に送信する。ストレージサーバ１０２は、１回目と同様に変換サーバ１０１から受信したＵＲＬリスト５０１をクライアントコンピュータ１０６に返す。図５の例では５ページ分のデータのＵＲＬリスト５０１を返している。クライアントコンピュータ１０６は、総ページ数と受信したＵＲＬリスト５０１のページ数が一致したことから、変換サーバが変換処理を終えたと判断する。

図６は、変換サーバとストレージサーバの間、または変換サーバ内で何等かの問題が発生した場合の、クライアントコンピュータとストレージサーバとの間のＵＲＬリストのやり取りについて説明するための図である。
１回目のＵＲＬリスト要求までは図５と同様である。クライアントコンピュータ１０６が２回目のＵＲＬリスト要求をストレージサーバ１０２に送信するが、ＵＲＬリスト５０１は、１回目と同様に３ページ分のデータのＵＲＬしか含まれていない。その後、何度要求してもストレージサーバ１０２からは３ページ分のデータのＵＲＬリスト５０１しか得られないとする。この場合、サーバ側で何等かの問題があると考えられる。ただし、ここで単にＵＲＬリストの取得回数を制限するだけでは大量ページのドキュメントの変換等、時間のかかる処理を行っている場合に、正常に変換中であっても問題があると誤判定してしまう恐れがある。そこで、本実施形態では、ＵＲＬリストの更新された内容に基づき、サーバの状態を判定する。

図７は、本実施形態においてクライアントコンピュータが行う変換処理を説明するためのフローチャートである。
なお、変換サーバ１０１とストレージサーバ１０２は、一般的なＨＴＴＰサーバの機能を満たし、ＧＥＴメソッド、ＨＥＡＤメソッド、及びＰＵＴメソッド等が使用可能であるとする。また、ＨＴＴＰに従う一般的なサーバ及びクライアント間の処理については広く知られており、詳細な説明は省略する。
まず、クライアントコンピュータ１０６の上位レイヤアプリケーション３０１は、エンドユーザから印刷指示を受け、ドキュメント変換処理部３０２に対して変換指示を出す。変換指示を受けたドキュメント変換処理部３０２は、変換処理７００を開始する。ステップＳ７０１にてドキュメント変換処理部３０２は、変換サーバ１０１へ変換指示を出す。ステップＳ７０１は、図４のステップＳ４００と同様の処理である。ドキュメント変換処理部３０２は、ステップＳ７０１の結果として変換元ドキュメントのアップロード先ＵＲＬを取得する。ステップＳ７０２にてドキュメント変換処理部３０２は、取得したアップロード先ＵＲＬに対して変換元ドキュメントをアップロードする。アップロードする方法としては、ＨＴＴＰのＰＯＳＴメソッド及びＰＵＴメソッドがあるがこれに限られるものではなく、ＨＴＴＰを使用してアップロード可能であれば他の方法でもよい。ステップＳ７０２は、図４のステップＳ４０１と同様の処理である。

ステップＳ７０３にてドキュメント変換処理部３０２は、変換サーバ１０１にアップロード完了の通知を出す。通知方法としては、ＨＴＴＰのＧＥＴメソッド及びＰＯＳＴメソッド等があるがこれに限られるものではなく、ＨＴＴＰを使用して通知可能であれば他の方法でもよい。ステップＳ７０３は、図４のステップＳ４０２と同様の処理である。ステップＳ７０４にてドキュメント変換処理部３０２は、ダウンロードスレッドを開始する。ダウンロードスレッドとは、変換サーバ１０１によって変換されたドキュメントを非同期にダウンロードし、上位レイヤアプリケーション３０１に結果を通知するためのスレッドである。ダウンロード高速化のためにダウンロードスレッドを複数用意してもよい。ステップＳ７０５にてドキュメント変換処理部３０２は、ＵＲＬリスト５０１の取得を行う。

図８は、図７で示したステップＳ７０４のダウンロードスレッドを開始する処理について説明するためのフローチャートである。
ドキュメント変換処理部３０２は、ダウンロード処理８００を起点としたスレッドをステップＳ７０４で開始する。ステップＳ８０１にてドキュメント変換処理部３０２は、変換後ドキュメントの該当ページＵＲＬが通知されるまでスレッドを待機させる。該当ページＵＲＬが通知された後、ステップＳ８０２にてドキュメント変換処理部３０２は、該当ページＵＲＬから変換されたページをダウンロードする。ステップＳ８０３にて、ダウンロードが成功した場合には処理はステップＳ８０５へ進み、失敗した場合には処理はステップＳ８０４へ進む。ステップＳ８０４にてドキュメント変換処理部３０２は、上位レイヤアプリケーション３０１に該当ページのダウンロードが失敗したことを通知する。また、ステップＳ８０５にてドキュメント変換処理部３０２は、上位レイヤアプリケーション３０１にダウンロードしたページを渡す。なお、図８ではページのダウンロードを一回のみ行っているが、無線回線の混雑などを考慮して再試行を行う処理を行ってもよい。ステップＳ８０６にてドキュメント変換処理部３０２は、ダウンロード処理が済んでいないページがあるか否かを確認し、済んでいないページがあればステップＳ８０１に戻り、続けて該当ページのダウンロードを試みる。全てのページのダウンロードが済んでいれば処理を終了し、呼び出し元に戻る。

図９は、図７で示したステップＳ７０５のＵＲＬリスト取得処理について説明するためのフローチャートである。
ＵＲＬリスト取得処理９００は、ドキュメント変換処理部３０２が行う。まず、ステップＳ９０１にてドキュメント変換処理部３０２は、ＵＲＬリスト５０１の取得済みページ数（作成済みのファイル数）と総ページ数とを比較する。もし総ページ数のＵＲＬを全て取得できていなければ、処理はステップＳ９０２に進む。総ページ数分のＵＲＬを全て取得できていれば処理を終了し、呼び出し元に戻る。ステップＳ９０２にてドキュメント変換処理部３０２は、ＵＲＬリスト５０１を取得するために、ストレージサーバ１０２に対してＨＴＴＰのＧＥＴメソッドのリクエストを送信する。なお、ＧＥＴメソッドに限られるものではなく、ＨＴＴＰを使用するのであれば他の方法でもよい。ステップＳ９０３にてドキュメント変換処理部３０２は、レスポンスを取得し、ステップＳ９０４にてレスポンスの解析を行う。ステップＳ９０５にてドキュメント変換処理部３０２は、変換サーバ１０１が正しく動作しているか否かの判定を行う。もしドキュメント変換処理部３０２が、変換サーバ１０１の状態が異常であると判定した場合には、処理はステップＳ９０７に進む。ステップＳ９０７にてドキュメント変換処理部３０２は、ダウンロードスレッドにサーバ異常エラーを通知する。一方、ドキュメント変換処理部３０２が、で変換サーバ１０１の状態が正常であると判定した場合には、処理はステップＳ９０８に進む。ステップＳ９０８にてドキュメント変換処理部３０２は、ダウンロードスレッドに取得した変換後ドキュメントのページＵＲＬを通知する。

図１０は、図９で示したステップＳ９０５のサーバ状態判定処理について説明するためのフローチャートである。
サーバ状態判定処理１０００は、ドキュメント変換処理部３０２が行う。まずステップＳ１００１にてドキュメント変換処理部３０２は、取得したＵＲＬリスト５０１のページ数を算出する。ステップＳ１００２にてドキュメント変換処理部３０２は、ＵＲＬリスト５０１の取得済みページ数が前回取得したページ数よりも大きいか否かを比較する。もし大きい場合には処理はステップＳ１００３に進み、大きくない場合には処理はステップＳ１００５に進む。ステップＳ１００３にてドキュメント変換処理部３０２は、前回取得したページ数として、今回取得したページ数を保存する。ステップＳ１００４にてドキュメント変換処理部３０２は、ＵＲＬリスト５０１の取得回数を０にリセットする。このように、取得回数をリセットすることにより、大量ページのドキュメントに対する変換サーバ１０１の長時間の変換処理を異常状態と誤検知することを抑制し、変換後ドキュメントの取得を行えるようになる。

ステップＳ１００２にてＵＲＬリスト５０１の取得済みページ数が前回取得したページ数よりも大きくない、すなわち更新が無い（処理が進行していない）と判定した場合には、ステップＳ１００５の処理に進む。ステップＳ１００５にてドキュメント変換処理部３０２は、取得回数（カウント値）をインクリメントする。ステップＳ１００６にてドキュメント変換処理部３０２は、取得回数が取得回数の上限を超えているか否か比較する。取得回数の上限を超えていた場合には処理はステップＳ１００８に進み、超えていない場合には処理はステップＳ１００７に進む。ステップＳ１００７にてドキュメント変換処理部３０２は、サーバの状態を正常であると判定して処理を終了し、呼び出し元に戻る。一方、ステップＳ１００８にてドキュメント変換処理部３０２は、サーバの状態を異常であると判定して処理を終了し、呼び出し元に戻る。このように、変換後ドキュメントの総ページ数とＵＲＬリスト５０１の取得済みページ数とが一致しない状態において、サーバへの負荷及び通信コストを増大させることなく、適切に異常状態を推定することが可能となる。そして、ユーザに対してより早く異常を通知することができる。

以上のように、本実施形態によれば、データ処理を実行するサーバが正常に稼働しているか否かをサーバへの負荷及び通信コストを増大させることなくクライアントが適切に判断することが可能な情報処理システムを提供することができる。

（第２実施形態）
次に本発明の第２実施形態に係る情報処理システムについて説明する。第１実施形態では、情報処理システムの一例である印刷ソリューションシステムにおいて、ＵＲＬリスト５０１が更新されたか否かを判定した。そして、更新されていないＵＲＬリストを取得した取得回数が上限を超えた場合にサーバ状態を異常と判定した。本実施形態では、ＵＲＬリストの取得間隔を調整する。取得間隔が一定の場合には、例えば時間を要する処理を実行中の場合など、必要以上にストレージサーバにＨＴＴＰリクエストを送信してしまい、通信コストが増大してしまう。しかし、取得間隔を長くしてしまうと、上位レイヤアプリケーションへの通知が遅れ、最終的にエンドユーザへのレスポンスが遅れてしまう。そこで、本実施形態では、ＵＲＬリストの更新された内容に応じて最適な取得間隔を設定することができる。

図１１は、本実施形態に係るサーバ状態判定処理を説明するためのフローチャートである。なお、図１０に示した第１実施形態に係るサーバ状態判定処理と同一の処理には同一の符号を付し、説明を省略する。
サーバ状態判定処理１１００は、ドキュメント変換処理部３０２が行う。まず、ドキュメント変換処理部３０２は、図９に示したＵＲＬ取得処理のステップＳ９０５にて、サーバ状態判定処理のステップＳ１１００に進む。ステップＳ１００２にてドキュメント変換処理部３０２は、ＵＲＬリスト５０１の取得済みページ数が前回取得したページ数よりも大きいか否かを比較する。すなわち、ＵＲＬリスト５０１の更新があったか否かを判断し、更新があったと判断した場合には、処理はステップＳ１００３に進む。ステップＳ１１０１にてドキュメント変換処理部３０２は、取得間隔を最小時間にリセットする。そして、ステップＳ１１０３にてドキュメント変換処理部３０２は、現在のスレッドを設定された取得間隔の分だけスリープさせる。本実施形態では、単純に処理を止めるだけだが、ストレージサーバ１０２にリクエストを送らなければ、他の処理を行っていてもよい。一方、ステップＳ１００２にてドキュメント変換処理部３０２がＵＲＬリスト５０１の更新がなかったと判断した場合には、処理はステップＳ１００５に進む。

ステップＳ１１０２にてドキュメント変換処理部３０２は、ＵＲＬリストの取得間隔を現在（前回問い合せたとき）の２倍に設定する。本実施形態では取得間隔を延ばすために２倍に設定するが、これに限られるものではなく、例えばサーバやネットワークの状況に応じて、異なる延長方法を取ってもよい。続いてステップＳ１００６にてドキュメント変換処理部３０２は、ＵＲＬリスト５０１の取得回数が取得回数の上限を超えているか否か比較する。取得回数の上限を超えていなかった場合には、処理はＳ１１０３に進み、ステップＳ１１０２にて２倍にした取得間隔の分だけ現在のスレッドをスリープさせる。一方、ステップＳ１００６にてＵＲＬリストの取得回数の上限を超えていた場合には処理はステップＳ１００８に進み、サーバの状態を異常であると判定する。このように、ＵＲＬリストの取得間隔を調整することにより、例えば、大量ページのドキュメントに対する変換サーバ１０１の長時間の変換処理を異常状態と誤検知することを抑制し、変換後ドキュメントの取得を行えるようになる。また、取得間隔を長くした場合であっても、ステップＳ１００６の処理により、異常状態においてはスレッドをスリープさせることなくサーバを異常状態と判定するため、ユーザに対してより早く異常を通知することができる。

図１２は、ＵＲＬリストの取得間隔を調整した場合の取得タイミングの一例を示す図である。
図１２において、１２０１及び１２０２は、クライアントコンピュータ１０６がＵＲＬリストの取得を行うタイミングを示している。すなわち、クライアントコンピュータ１０６がサーバ状態判定処理のステップＳ１００２において、ＵＲＬリスト５０１の更新を確認した後、ＵＲＬリスト５０１の取得要求をストレージサーバ１０２に送信する処理を行うタイミングである。１２０１は、ＵＲＬリスト５０１の更新があった場合を示しており、１２０２は、ＵＲＬリスト５０１の更新がなかった場合を示している。図１２では１回目に取得したＵＲＬリスト５０１は更新されていたが、２〜４回目取得したＵＲＬリスト５０１は更新されていなかったことを示している。図１２に示すように、２〜４回目において、ＵＲＬリストの取得要求を行った後の次回のＵＲＬリストの取得要求を行うまでの取得間隔が２倍ずつ延長されていることが分かる（ステップＳ１１０２の処理により）。また、５回目に取得したＵＲＬリスト５０１は更新されていたため、クライアントコンピュータ１０６が６回目にＵＲＬリストを取得する際の取得間隔を、通常の間隔に戻していることがわかる（ステップＳ１１０１の処理により）。

以上のように、本実施形態によれば、第１実施形態と同様の効果を奏する。さらに、本実施形態によれば、ＵＲＬリストが更新されていた場合には、短い間隔でＵＲＬリストの取得を行う。また、ＵＲＬリストが更新されていなかった場合には、変換サーバの処理に時間が掛かっていると推定し、ＵＲＬリストを取得する間隔を延ばしていく。その結果、変換サーバが時間を要する処理を行っている場合には、ＵＲＬリストの取得回数を減らし、通信コスト及びストレージサーバへの負荷を抑えことができる。また、処理が順調に進んでいると推定した場合には、上位レイヤアプリケーションに素早く通知を行うことができる。

（第３実施形態）
次に本発明の第３実施形態に係る情報処理システムについて説明する。第１実施形態では、情報処理システムの一例である印刷ソリューションシステムにおいて、ＵＲＬリストが更新されたか否かを判定した。そして、更新されていないＵＲＬリストを取得した取得回数が上限を超えた場合にサーバ状態を異常と判定した。本実施形態では、ＵＲＬリストが更新されたか否かに加えて、変換サーバが定期的な通信動作を行い、そのタイミングを示すタイムスタンプを取得することにより、変換サーバの状態を判定する。タイムスタンプを確認することにより、より明確にサーバの状態を確認することができる。

以下、本実施形態の具体的な処理について説明する。
まず、予めストレージサーバ１０２にタイムスタンプ用のファイルを作成しておく。そして、変換サーバ１０１がドキュメントの変換が終わっていない場合であっても、タイムスタンプをストレージサーバ１０２に定期的に書きこむ処理を行わせる。具体的には、図４に示したシーケンス図のステップＳ４０２にて、ドキュメント変換処理部３０２は、変換元ドキュメントのアップロード完了を通知する。この通知を基に変換サーバ１０１は、変換を開始する。そして、ステップＳ４０５とステップＳ４０６にて結果をストレージサーバ１０２に保存するまで、現在日時を記録したファイルをサーバの稼働確認用タイムスタンプとして、ストレージサーバ１０２に定期的に保存する。なお、保存されたタイムスタンプ（現在日時を記録したファイル）の保存先のＵＲＬは、ステップＳ４００やステップＳ４０２にて、変換サーバ１０１がクライアントコンピュータ１０６に通知するものとする。

図１３は、上述したタイムスタンプの確認を行うサーバタイムスタンプ確認処理について説明するためのフローチャートである。
図１３に示すサーバタイムスタンプ確認処理１３００は、ＵＲＬリスト取得処理９００の中で行ってもよいし、非同期で定期的に行ってもよい。
まず、ステップＳ１３０１にてドキュメント変換処理部３０２は、ストレージサーバ１０２から変換サーバ１０１の稼働を確認するためのタイムスタンプを取得する。次にステップＳ１３０２にてドキュメント変換処理部３０２は、現在日時を基に、取得したタイムスタンプが記録されてからの経過時間を計算する。経過時間が異常判定時間を上回っていれば、処理はステップＳ１３０３に進み、変換サーバ１０１が異常状態であると判定する。経過時間が異常判定時間を下回っていれば、処理はステップＳ１３０４に進み、変換サーバ１０１が正常状態であると判定する。ここで、サーバ状態判定処理１０００においてＵＲＬリストの取得回数が所定の閾値を超えた場合であっても、タイムスタンプに基づきサーバが正常に稼働していると判断できる場合には、サーバが正常に稼働していると判断する。これにより、変換サーバにおいて時間を要する処理を行っている場合に、正常に処理を行っていても変換サーバが異常状態であると誤判定してしまうことをより抑制できる。また、サーバ状態判定処理１０００においてＵＲＬリストの取得回数が所定の閾値を超えない場合であっても、タイムスタンプに基づきサーバが正常に稼働していないと判断できる場合には、サーバが正常に稼働していないと判断してもよい。これにより、ユーザに対してより早く異常を通知することができる。

以上のように、本実施形態によれば、第１実施形態と同様の効果を奏する。さらに、本実施形態によれば、変換サーバが定期的に保存するタイムスタンプを確認することにより、時間を要する処理を行っている場合であっても、変換サーバ１０１が正常に稼働中否かをより正確に判定することができる。

なお、本発明の機能が実現されるのであれば、単体の機器であっても、複数の機器から成るシステムであっても、本発明を適用できる。また、本発明の機能が実現されるのであれば、ＬＡＮ、ＷＡＮ、ＷＷＡＮ、インターネット等のネットワークを介して接続が為され、処理が行われるシステムであっても本発明を適用できる。また、仮想化ＯＳなどで構成される場合も含めて一つの機器からなる装置に適用しても良い。さらに、情報処理装置がインターネットを経由したクラウドコンピューティングで構成されるシステムに適用しても良い。

（その他の実施形態）
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
上述した場合に、プログラムの機能を有していれば、形態は、プログラムである必要はない。また、プログラムの実行環境は、パーソナルコンピュータやパーソナルコンピュータでのオペレーションシステムを仮想化した仮想ＰＣやリモートＰＣを含む。さらには、印刷処理装置、プリンタやＭＦＰ（マルチファンクションペリフェラル）等の組み込みコンピュータで実行される場合も含まれる。
従って、本発明の機能処理をコンピュータで実現するために、該コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明のクレームでは、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等、プログラムの形態を問わない。

プログラムを供給するための記録媒体としては、様々なものが使用できる。例えば、フロッピー（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤなどである。
その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続し、該ホームページからハードディスク等の記録媒体にダウンロードすることによっても供給できる。その場合、ダウンロードされるのは、本発明のコンピュータプログラムそのもの、もしくは圧縮され自動インストール機能を含むファイルであってもよい。また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明のクレームに含まれるものである。

また、本発明のプログラムを暗号化してＤＶＤ−ＲＯＭ等の記憶媒体に保存してユーザに配布する形態としても良い。その場合、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせ、その鍵情報を使用することにより暗号化されたプログラムが実行可能な形式でコンピュータにインストールされるようにする。
また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される形態以外の形態でも実現可能である。例えば、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部または全部を行い、その処理によっても前述した実施形態の機能が実現され得る。
更に、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれるようにしてもよい。この場合、その後で、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される。

以上、本発明の好ましい実施形態について説明したが、本発明は、これらの実施形態に限定されず、その要旨の範囲内で種々の変形および変更が可能である。

１０１変換サーバ
１０２ストレージサーバ
１０６クライアントコンピュータ
３０２ドキュメント変換処理部

Claims

サーバの作成済みファイルの一覧を取得する取得手段と、
前回取得されたファイルの一覧と、今回取得されたファイルの一覧に基づいて、前記サーバにより新たに作成されたファイルが存在するか判断する判断手段と、
前記サーバにより新たに作成された前記ファイルが存在しないと判断された場合に、前記ファイルの一覧の取得回数をカウントするカウント手段と、
前記取得回数が所定の回数を超えた場合にエラーを通知する通知手段と、を有することを特徴とする情報処理装置。
前記カウント手段は、前記サーバにより新たに作成された前記ファイルが存在すると判断された場合に、前記取得回数を０に戻す、ことを特徴とする請求項１に記載の情報処理装置。
前記取得手段は、前記サーバにより新たに作成された前記ファイルが存在しないと判断された場合に、次にファイルの一覧を取得する間隔を、前回取得したときの間隔よりも長くする、ことを特徴とする請求項１または２に記載の情報処理装置。
前記取得手段は、前記サーバによる定期的な通信動作のタイミングを示すタイムスタンプをさらに取得し、
前記通知手段は、前記取得されたタイムスタンプと現在時刻との間隔が所定の時間を超えた場合に、エラーを通知することを特徴とする請求項１ないし３のいずれか１項に記載の情報処理装置。
前記通知手段は、前記取得回数が前記所定の回数を超えた場合であっても、前記取得されたタイムスタンプと現在時刻との間隔が所定の時間を超えない場合には、前記エラーを通知しない、ことを特徴とする請求項４に記載の情報処理装置。
前記取得手段は、前記サーバが前記ファイルの一覧を記録したストレージ装置から該ファイルの一覧を取得する、ことを特徴とする請求項１ないし５のいずれか１項に記載の情報処理装置。
前記サーバは、印刷のためのデータの形式を変換し、
前記形式が変換されたデータを画像処理装置に印刷させるサーバである、ことを特徴とする請求項１ないし６のいずれか１項に記載の情報処理装置。
サーバの作成済みファイルの一覧を取得する取得工程と、
前回取得されたファイルの一覧と、今回取得されたファイルの一覧に基づいて、前記サーバにより新たに作成されたファイルが存在するか判断する判断工程と、
前記サーバにより新たに作成された前記ファイルが存在しないと判断された場合に、前記ファイルの一覧の取得回数をカウントするカウント工程と、
前記取得回数が所定の回数を超えた場合にエラーを通知する通知工程と、を有することを特徴とする情報処理装置の制御方法。
請求項８に記載の制御方法をコンピュータに実行させることを特徴とするプログラム。