JP7494585B2 - 情報処理装置 - Google Patents

Description

本発明は、情報処理装置及びプログラムに関する。

今日、インターネット経由で様々なウェブサービスの利用が可能である。例えばユーザのデータに予め定めた処理を加えるサービスやユーザのデータを記憶するサービスがある。以下では、インターネット上で提供されるサービスをクラウド型のサービス（以下「クラウドサービス」という）という。
障害によりクラウドサービスが停止すると、クラウドサービスを利用するユーザの活動に影響が及ぶ。そこで、クラウドサービスにおける障害の発生の有無を検知する仕組みがある。この仕組は、ヘルスチェックと呼ばれる。ヘルスチェックの頻度が高いほど、障害を事前に検知する精度が高くなる一方、通信に使用するシステム（以下「通信システム」という）に加わる負荷も高くなる。そこで、通信システムの負荷の変化に応じてヘルスチェックを実行する間隔を能動的に制御する方法や負荷が比較的少ない時間帯にヘルスチェックの実行を計画する方法がある。

特開２００９－１１７９１５号公報

しかし、ユーザによりクラウドサービスが利用できていれば、ヘルスチェックを実行しなくてもクラウドサービスが動作していることは分かる。また、通信システムの負荷が比較的少ない時間帯にヘルスチェックの実行を計画する場合でも、現実にヘルスチェックを実行する場面では通信システムの負荷が高いことも起こり得る。

本発明は、クラウドサービスのユーザによる使用中もヘルチェックが実行される場合に比して、システムに対する負荷を抑制することを目的とする。

請求項１に記載の発明は、ユーザが操作する端末によるクラウドサービスの利用を中継するサービスを提供する情報処理装置はプロセッサを有し、前記プロセッサは、受け付けたリクエストに関する処理の状態を監視し、処理が継続している前記リクエストがある間、ヘルスチェックのリクエストを発行しない情報処理装置である。
請求項２に記載の発明は、前記プロセッサは、ユーザが操作する前記端末で発行された前記リクエストの処理が完了するまで、前記ヘルスチェックのリクエストを発行しない、請求項１に記載の情報処理装置である。
請求項３に記載の発明は、前記プロセッサは、前記リクエストに関する処理がいずれも完了した後、前記ヘルスチェックのリクエストの発行を許可する、請求項２に記載の情報処理装置である。
請求項４に記載の発明は、前記プロセッサは、前記クラウドサービスの障害の発生を監視し、当該障害の発生が確認された場合、前記ヘルスチェックのリクエストを発行しない、請求項１に記載の情報処理装置である。
請求項５に記載の発明は、前記プロセッサは、プラグインサービスのログを通じ、前記障害の発生を監視する、請求項４に記載の情報処理装置である。
請求項６に記載の発明は、前記プロセッサは、前記障害の復旧が確認された場合、前記ヘルスチェックのリクエストの発行を許可する、請求項４に記載の情報処理装置である。
請求項７に記載の発明は、前記プロセッサは、前記クラウドサービスの障害からの復旧が確認された場合、前記ヘルスチェックのリクエストの発行を許可する、請求項１に記載の情報処理装置である。
請求項８に記載の発明は、前記プロセッサは、前記クラウドサービスの停止を、ユーザが操作する前記端末に通知する、請求項４に記載の情報処理装置である。
請求項９に記載の発明は、前記プロセッサは、前記クラウドサービスの復旧を、ユーザが操作する前記端末に通知する、請求項４又は８に記載の情報処理装置である。

請求項１記載の発明によれば、クラウドサービスのユーザによる使用中もヘルチェックを実行する場合に比して、システムに対する負荷を抑制できる。
請求項２記載の発明によれば、ユーザの端末からのリクエストの進捗により、システムの負荷を増やすこと無く、クラウドサーバの状態を把握できる。
請求項３記載の発明によれば、システムの負荷を抑制しながらヘルスチェックを実行できる。
請求項４記載の発明によれば、不要なヘルスチェックの実行を抑制できる。
請求項５記載の発明によれば、ヘルスチェックを実行することなく、クラウドサービスの状態を監視できる。
請求項６記載の発明によれば、クラウドサービスが復旧するのを待ってヘルスチェックを再開できる。
請求項７記載の発明によれば、クラウドサービスが復旧するのを待ってヘルスチェックを再開できる。
請求項８記載の発明によれば、ユーザの操作を抑制してシステムの負荷を抑制できる。
請求項９記載の発明によれば、ユーザによる操作の再開を可能にできる。

実施の形態１で想定するクラウドシステムの構成例を示す図である。 中継サーバの構成例を説明する図である。 実施の形態１で使用する中継サーバの機能構成の一例を説明する図である。 リクエスト状態管理部が管理するリクエストの状態を説明する図である。 端末からリクエストが与えられた場合における中継サーバの処理動作の一例を説明する図である。 リクエスト状態管理部で管理されるリクエストの状態の遷移を説明する図である。 ヘルスチェックのためのリクエストが発行される場合における中継サーバの処理動作の一例を説明する図である。 リクエスト状態管理部で管理されるリクエストの状態の遷移を説明する図である。 実施の形態２で使用する中継サーバの機能構成の一例を説明する図である。 クラウドサービスに障害が発生した場合における中継サーバの処理動作の一例を説明する図である。 リクエスト状態管理部で管理されるリクエストの状態の遷移を説明する図である。 実施の形態３で使用する端末と中継サーバの機能構成の一例を説明する図である。 プラグインサービス状態保持部に保持されている状態の例を説明する図である。 端末からプラグインサービスの状態が問い合わされた場合における中継サーバの処理動作の一例を説明する図である。 プラグインサービスの状態を示す画面の表示例を示す図である。 プラグインサービスの状態を示す他の画面の表示例を示す図である。 画像形成装置の表示部に対するユーザの操作の例を説明する図である。 ユーザが選択したフォーマットＡへの文字データへの変換を実行できない場合に代替フォーマットへの変換を提示する画面の例を示す図である。

以下、添付図面を参照して、実施の形態について詳細に説明する。
＜実施の形態１＞
＜システム構成＞
図１は、実施の形態１で想定するクラウドシステム１の構成例を示す図である。
クラウドシステム１は、クラウドネットワーク１０と、ユーザが操作する端末２０と、クラウドサービスを提供するクラウドサーバ３０と、端末２０とクラウドサーバ３０の間で通信を中継する中継サーバ４０とで構成されている。中継サーバ４０は、情報処理装置の一例である。
クラウドネットワーク１０は、例えばインターネットやＶＰＮ（＝Virtual Private Network）であり、専用線でもよい。

ユーザが操作する端末２０は、クラウドサーバ３０との連携により、様々なサービスをユーザに提供する。図１では、端末２０の例として、画像形成装置２０Ａとノート型のコンピュータ２０Ｂを表している。もっとも、端末２０は、通信機能を有し、クラウドサービスを活用して機能の拡張が可能な機器であればよい。端末２０は、例えばスマートフォン、タブレット型のコンピュータ、コネクティッドカー、ＩｏＴ（＝Internet of Things）家電、スマート家電でもよい。
本実施の形態で使用する画像形成装置２０Ａは、印刷、コピー、ファックス、スキャナ等の複数の機能を有している。この種の画像形成装置２０Ａは、複合機とも呼ばれる。

クラウドサーバ３０は、クラウドサービスを提供するサーバであり、本実施の形態の場合、サービス毎に用意される。クラウドサービスには、例えばグループウェア、バックオフィス、オンラインストレージ、ＯＣＲ（＝Optical Character Recognition）処理、データのフォーマット変換がある。本実施の形態では、データをストレージに記憶するサービスをストレージ型といい、データを処理するサービスや外部と接続するサービスを業務型という。

図１には、クラウドサーバ３０の例として、業務型のクラウドサービスを提供するクラウドサーバ３０Ａ（以下「業務型のクラウドサーバ３０Ａ」という）とストレージ型のクラウドサービスを提供するクラウドサーバ３０Ｂ（以下「ストレージ型のクラウドサーバ３０Ｂ」という）を表している。
業務型のクラウドサーバ３０Ａは、例えば端末２０から受信した文書データを処理して返却するサービスを提供する。ストレージ型のクラウドサーバ３０Ｂは、端末２０から受信した文書データを予め確保された領域に記憶する。なお、クラウドシステム１で扱うデータは文書データに限らない。

中継サーバ４０は、端末２０から入力されたリクエストに応じて１つ又は複数のクラウドサーバ３０にアクセスし、リクエストに応じた処理の結果を端末２０に通知する。本実施の形態における中継サーバ４０は、クラウドサーバ３０における障害の有無を検知するヘルスチェックを実行する。
図２は、中継サーバ４０の構成例を説明する図である。中継サーバ４０は、装置全体の動作を制御する制御ユニット４１と、データを記憶する記憶装置４２と、入出力ポート４３と、通信装置４４とを有している。なお、制御ユニット４１と他の処理部は、信号線やバスを用いて相互に接続されている。

制御ユニット４１は、ＣＰＵ（＝Central Processing Unit）４１Ａと、ＢＩＯＳ（＝Basic Input Output System）等が記憶されたＲＯＭ（＝Read Only Memory）と、ワークエリアとして用いられるＲＡＭ（＝Random Access Memory）とを有している。制御ユニット４１は、いわゆるコンピュータとして機能する。ＣＰＵ４１Ａは、プロセッサの一例である。
記憶装置４２は、例えば半導体メモリやハードディスク装置により構成される。記憶装置４２には、オペレーティングシステムやヘルスチェックに関するプログラムも記憶されている。

図３は、実施の形態１で使用する中継サーバ４０の機能構成の一例を説明する図である。図３に示す機能は、ＣＰＵ４１Ａによるプログラムの実行を通じて実現される。
中継サーバ４０は、コアサービス４１０と、タスク定義モジュール４２０と、プラグインサービス４３０と、キュー４４０と、リクエスト状態管理部４５０と、ヘルスチェックリクエスト発行部４６０として機能する。
コアサービス４１０は、外部とのデータの受け渡しを実行するサブ機能で構成される。図３の場合、コアサービス４１０は、ユーザが操作する端末２０と通信するタスクサービス４１０Ａと、業務型のクラウドサーバ３０Ａと通信するＡＰＩ（＝Application Programming Interface）デリゲートサービス４１０Ｂと、ストレージ型のクラウドサーバ３０Ｂと通信するＣＭＩＳ（＝Content Management Interoperability Services）ゲートウェイサービス４１０Ｃとを有している。

タスクサービス４１０Ａは、端末２０から受け付けたリクエストやヘルスチェックリクエスト発行部４６０から受け付けたリクエストに基づいて、タスク定義モジュール４２０のイベント処理モジュール４２０Ａを起動する処理、タスク定義モジュール４２０との連携によりプラグインを呼び出すリクエストを出力する処理、クラウドサービスから返却された文書データを端末２０に返信する処理、リクエスト状態管理部４５０にリクエストの発行や終了を通知する処理等を実行する。
タスクサービス４１０Ａは、イベント処理モジュール４２０Ａを起動する場合、タスク定義をイベント処理モジュール４２０Ａに与える。タスク定義は、プラグイン又は複数のプラグインの組み合わせにより実現される作業を定義する情報である。

ＡＰＩデリゲートサービス４１０Ｂは、業務型プラグインサービス４３０Ａから読み出したプラグインを用い、業務型のクラウドサーバ３０Ａと通信する処理等を実行する。
ＣＭＩＳゲートウェイサービス４１０Ｃは、ストレージ型プラグインサービス４３０Ｂから読み出したプラグインを用い、ストレージ型のクラウドサーバ３０Ｂと通信する処理等を実行する。
タスク定義モジュール４２０は、イベント処理モジュール４２０Ａと、タスク定義ライブラリ４２０Ｂで構成される。イベント処理モジュール４２０Ａは、タスク定義に関連するプラグインのライブラリを、タスク定義ライブラリ４２０Ｂから読み出す。

図３に示すプラグインサービス４３０は、業務型プラグインサービス４３０Ａとストレージ型プラグインサービス４３０Ｂで構成される。
業務型プラグインサービス４３０Ａは、業務型のサービス毎に用意され、文書処理プラグイン４３０Ａ１と、プラグインライブラリ４３０Ａ２とで構成される。
ストレージ型プラグインサービス４３０Ｂは、ストレージ型のサービス毎に用意され、ストレージ登録プラグイン４３０Ｂ１と、プラグインライブラリ４３０Ｂ２で構成される。
キュー４４０は、タスクサービス４１０Ａから出力されたプラグインを呼び出すリクエストを格納する記憶領域である。

リクエスト状態管理部４５０は、ユーザが操作する端末２０やヘルスチェックリクエスト発行部４６０から受け付けたリクエストの処理の状態を管理する機能と、管理の対象であるリクエストの状態を変更する機能と、リクエストの状態に応じ、ヘルスチェックリクエスト発行部４６０に対してヘルスチェックのためのリクエストの発行を依頼する機能とを有している。
本実施の形態の場合、リクエスト状態管理部４５０は、処理中のリクエストが継続している場合は、ヘルスチェックのためのリクエストを発行しない。

換言すると、ユーザが操作する端末２０から受け付けたリクエストが処理中の場合やヘルスチェックのためのリクエストが処理中の場合、リクエスト状態管理部４５０は、それらの処理が完了するまで、ヘルスチェックのための新たなリクエストを発行しない。
本実施の形態におけるリクエスト状態管理部４５０がヘルスチェックのためのリクエストを発行するのは、処理中のリクエストがない場合に限られる。
ヘルスチェックリクエスト発行部４６０は、リクエスト状態管理部４５０から依頼があった場合に、ヘルスチェックのためのリクエストを発行してタスクサービス４１０Ａに与える。

図４は、リクエスト状態管理部４５０が管理するリクエストの状態を説明する図である。
本実施の形態の場合、リクエストの状態は、新規、待機中、処理中、完了、失敗の５つである。
新規は、ユーザが操作する端末２０又はヘルスチェックリクエスト発行部４６０から発行された新たなリクエストが登録された状態をいう。
待機中は、プラグインが処理待ちで待機している状態をいう。
処理中は、プラグインが処理を行っている状態をいう。
完了は、プラグインが処理を完了した状態をいう。
失敗は、プラグインの処理がエラーにより失敗した状態をいう。

前述したように、リクエストがない場合、又は、全てのリクエストが完了した場合に、リクエスト状態管理部４５０は、ヘルスチェックリクエスト発行部４６０に対してリクエストの発行を依頼する。一方、リクエストが新規、待機中、処理中、失敗の状態の場合に、リクエスト状態管理部４５０は、ヘルスチェックリクエスト発行部４６０に対してリクエストの発行を依頼しない。
リクエストの状態が新規、待機中、処理中、失敗の場合は、リクエストの処理が継続している状態の一例である。

＜処理動作＞
図５は、端末２０からリクエストが与えられた場合における中継サーバ４０の処理動作の一例を説明する図である。
図５で説明する処理動作は、端末２０からタスクサービス４１０Ａに対し、リクエストの通知が与えられることで開始される。
リクエストを受け付けたタスクサービス４１０Ａは、リクエスト状態管理部４５０に対し、新規のリクエストの発行を通知する。
通知を受け付けたリクエスト状態管理部４５０は、リクエストの状態を更新して「新規」とする。
この後、タスクサービス４１０Ａは、キュー４４０にリクエストを格納する。

プラグインサービス４３０は、キュー４４０にアクセスし、格納されているリクエストを取得する。その後、プラグインサービス４３０は、リクエストの処理を開始し、リクエスト状態管理部４５０に対し、リクエストの状態の更新を通知する。これにより、リクエスト状態管理部４５０による状態の管理は、「新規」から「処理中」に変更される。
やがて、リクエストの処理が終了すると、プラグインサービス４３０は、タスクサービス４１０Ａに対し、リクエストの処理の完了を通知する。なお、業務型のプラグインサービスの場合は、処理済みのデータ又は結果もタスクサービス４１０Ａに通知される。

通知を受けたタスクサービス４１０Ａは、リクエスト状態管理部４５０に対し、リクエストの処理の完了を通知する。
通知を受けたリクエスト状態管理部４５０は、リクエストの状態を更新して「完了」とする。
図６は、リクエスト状態管理部４５０で管理されるリクエストの状態の遷移を説明する図である。リクエストの状態は、リクエストＩＤ（＝IDentification）と紐付けて管理される。図６の場合、リクエストＩＤは、「REQ00001」で管理されている。図６の場合、状態は「新規」→「処理中」→「完了」に変化する。

図７は、ヘルスチェックのためのリクエストが発行される場合における中継サーバ４０の処理動作の一例を説明する図である。
図７で説明する処理動作は、リクエスト状態管理部４５０が、予め定めた状態を検知することで開始される。具体的には、リクエストが無い、又は、全て完了している場合、リクエスト状態管理部４５０が、ヘルスチェックリクエスト発行部４６０に対し、リクエストの発行の依頼を通知する。
通知を受けたヘルスチェックリクエスト発行部４６０は、タスクサービス４１０Ａに対し、ヘルスチェックのリクエストの発行を通知する。

リクエストの発行の通知を受け付けたタスクサービス４１０Ａは、リクエスト状態管理部４５０に対し、新規のリクエストの発行を通知する。
通知を受け付けたリクエスト状態管理部４５０は、リクエストの状態を更新して「新規」とする。
この後、タスクサービス４１０Ａは、キュー４４０にリクエストを格納する。
プラグインサービス４３０は、キュー４４０にアクセスし、格納されているリクエストを取得する。その後、プラグインサービス４３０は、リクエストの処理を開始し、リクエスト状態管理部４５０に対し、リクエストの状態の更新を通知する。これにより、リクエスト状態管理部４５０による状態の管理は、「新規」から「処理中」に変更される。ヘルスチェックのためのリクエストは、クラウドサービスの動作の状態を確認することを目的とするので、処理自体は簡易である。

やがて、リクエストの処理が終了すると、プラグインサービス４３０は、タスクサービス４１０Ａに対し、リクエストの処理の完了を通知する。
通知を受けたタスクサービス４１０Ａは、リクエスト状態管理部４５０に対し、リクエストの処理の完了を通知する。
通知を受けたリクエスト状態管理部４５０は、リクエストの状態を更新して「完了」とする。
図８は、リクエスト状態管理部４５０で管理されるリクエストの状態の遷移を説明する図である。図８の場合、リクエストＩＤは、「REQ00002」で管理されている。
図８の場合、「REQ00002」のリクエストは、「REQ00001」のリクエストが完了した後に発行される。このため、「REQ00002」の状態が「新規」として登録されたときには、「REQ00001」の状態が既に「完了」になっている。その後の「REQ00002」の状態の変化は、「REQ00001」の状態の変化と同じである。

＜実施の形態２＞
実施の形態２の場合にも、実施の形態１で説明したクラウドシステム１（図１参照）を想定する。
図９は、実施の形態２で使用する中継サーバ４０の機能構成の一例を説明する図である。図９には、図３との対応部分に対応する符号を付して示している。
本実施の形態で使用する中継サーバ４０は、障害管理部４７０を有する点で実施の形態１と相違する。
本実施の形態における障害管理部４７０には、プラグインサービス４３０のログから障害の発生を検知する機能と、プラグインサービス４３０のログから障害からの復旧を検知する機能と、障害の発生をリクエスト状態管理部４５０に通知する機能と、障害からの復旧をリクエスト状態管理部４５０に通知する機能とが設けられている。

図１０は、クラウドサービスに障害が発生した場合における中継サーバ４０の処理動作の一例を説明する図である。
図１０で説明する処理動作は、プラグインサービス４３０のログを通じてリクエストの処理に障害が発生したことを検知した障害管理部４７０が、リクエスト状態管理部４５０に対し、障害の発生を通知が与えることで開始される。通知を受けたリクエスト状態管理部４５０は、リクエストの状態を更新して「失敗」とする。
やがて、プラグインサービス４３０のログを通じてリクエストの処理が復旧したことを検知すると、障害管理部４７０は、リクエスト状態管理部４５０に対し、障害からの復旧を通知する。通知を受けたリクエスト状態管理部４５０は、リクエストの状態を更新して「処理中」とする。

図１１は、リクエスト状態管理部４５０で管理されるリクエストの状態の遷移を説明する図である。
図１１の場合、「REQ00002」で管理されるリクエストの処理中に、リクエストを処理しているクラウドサービスに障害が発生している。このため、「REQ00002」の状態が「処理中」から「失敗」に変化している。なお、障害からの復旧が確認された後は、「REQ00002」の状態が「失敗」から「処理中」に戻っている。
この後、「REQ00002」の処理が完了すると、「REQ00002」の状態は、「完了」に変化する。

＜実施の形態３＞
実施の形態３の場合にも、実施の形態１で説明したクラウドシステム１（図１参照）を想定する。
図１２は、実施の形態３で使用する端末２０と中継サーバ４０の機能構成の一例を説明する図である。図１２には、図９との対応部分に対応する符号を付して示している。
本実施の形態の場合、ユーザが操作する端末２０には、自装置からプラグインサービス４３０の状態を問い合わせるプラグインサービス状態確認部２１０と、プラグインサービス４３０の状態を表示部に表示するプラグインサービス状態表示部２２０とが設けられている。

プラグインサービス状態確認部２１０は、操作画面上でプラグインサービスの状態の確認を求める操作を受け付けた場合、中継サーバ４０に対して、プラグインサービスの状態の問い合わせを実行する。この問い合わせは、クラウドサービスに対してデータの処理を求めるリクエストではないので、タスクサービス４１０Ａには送信されない。
本実施の形態の場合、プラグインサービス状態表示部２２０は、問い合わせに対する応答として、プラグインサービスの現在の状態を表示する。なお、リクエスト状態管理部４５０が、ユーザからの問い合わせとは無関係に、プラグインサービスの現在の状態をプラグインサービス状態表示部２２０に表示させてもよい。

本実施の形態で使用する中継サーバ４０には、実施の形態２の機能構成に加え、プラグインサービス状態保持部４８０と、プラグインサービス状態受付部４９０と、プラグインサービス状態通知部５００とが設けられている。
プラグインサービス状態保持部４８０は、障害管理部４７０より通知されたプラグインサービス４３０の状態を保持する。
プラグインサービス状態受付部４９０は、端末２０からプラグインサービス４３０の状態の問い合わせを受け付ける。プラグインサービス状態受付部４９０は、問い合わせを受け付けた場合、プラグインサービス状態保持部４８０に保持されている状態を読み出し、プラグインサービス状態通知部５００に通知する。
プラグインサービス状態通知部５００は、プラグインサービス状態受付部４９０から与えられたプラグインサービスの状態を端末２０に通知する。

図１３は、プラグインサービス状態保持部４８０に保持されている状態の例を説明する図である。
図１３の場合、３つのプラグインサービスの状態が保持されている。図１３の場合、プラグインサービスの「PLGSVC001」と「PLGSVC002」の状態は「活性」であり、プラグインサービスの「PLGSVC003」の状態は「非活性」である。
図１４は、端末２０からプラグインサービスの状態が問い合わされた場合における中継サーバ４０の処理動作の一例を説明する図である。
図１４に説明する処理動作は、端末２０（図１参照）のプラグインサービス状態確認部２１０が、プラグインサービス状態受付部４９０に対し、プラグインサービス４３０（図１２参照）の状態を問い合わせることで開始される。前述したように、問い合わせは、ユーザが端末２０を通じて指示した場合に送信される。

プラグインサービス状態受付部４９０は、プラグインサービス４３０の状態の問い合わせを受信すると、プラグインサービス状態保持部４８０に対し、プラグインサービス４３０が利用可能かを問い合わせる。問い合わせは、特定のプラグインサービス４３０を指定せずに行ってもよいが、特定のプラグインサービス４３０を指定して行ってもよい。例えば端末２０で実行されている機能に関連するプラグインサービス４３０を指定する。指定は、プラグインサービス状態確認部２１０が行ってもよいし、プラグインサービス状態受付部４９０が行ってもよい。
プラグインサービス状態保持部４８０は、保持している状態をプラグインサービス状態受付部４９０に戻す。図１４の場合、「非活性」との情報がプラグインサービス状態受付部４９０に戻される。

次に、プラグインサービス状態受付部４９０は、プラグインサービス状態通知部５００に対し、プラグインサービス４３０の状態の通知を依頼する。
依頼を受け付けたプラグインサービス状態通知部５００は、プラグインサービス状態表示部２２０に対し、プラグインサービス４３０の状態を通知する。
この後、プラグインサービス状態表示部２２０は、表示部にプラグインサービス４３０の状態を表示する。
図１５は、プラグインサービス４３０の状態を示す画面２３０の表示例を示す図である。図１５に示す画面２３０は、プラグインサービス４３０（図１２参照）の状態を問い合わせた端末２０（図１参照）の表示部２００Ａに表示される。図１５に示す画面２３０は、ＸＸＸサービスが停止していることを示している。
図１６は、プラグインサービス４３０の状態を示す他の画面２４０の表示例を示す図である。図１６に示す画面２４０は、停止していたＸＸＸサービスが復旧した直後に表示される。

なお、プラグインサービス状態受付部４９０には、プラグインサービス４３０の状態が非活性の場合に、ユーザからの問い合わせがなくてもユーザにより選択された処理を実行するプラグインサービス４３０に障害が検知されると、代替が可能な他のサービスを端末２０に通知する機能を設けてもよい。
図１７は、画像形成装置２０Ａ（図１参照）の表示部２００Ａに対するユーザの操作の例を説明する図である。（Ａ）は画像形成装置２０Ａで読み取った原稿の画像データのＯＣＲ処理を選択した状態を示し、（Ｂ）はＯＣＲ処理後の文字データをフォーマットＡで記憶する状態を示す。
なお、ＯＣＲ処理は、業務型のクラウドサーバ３０Ａで実行され、フォーマットＡによる文字データの記憶は、ストレージ型のクラウドサーバ３０Ｂで実行される。図１７では、ＯＣＲ処理が選択された状態とフォーマットＡへの変換が選択された状態を破線で囲んで示している。

図１８は、ユーザが選択したフォーマットＡへの文字データへの変換を実行できない場合に代替フォーマットへの変換を提示する画面２７０の例を示す図である。
図１８の場合、画面２７０には、「ただいま、サーバの障害によりフォーマットＡへの変換ができません。代替機能として、フォーマットＢへの変換は可能です。フォーマットＢに変換し、処理を継続しますか？」と表示されており、「はい」か「いいえ」の選択が可能である。
フォーマットＡは、例えばＰＤＦ（＝Portable Document Format）であり、フォーマットＢは、例えばDocuWorks（登録商標）である。

なお、図１８に示す画面２７０を表示しても、ユーザによる代替機能の選択がいつまで経っても入力されない状況も考えられる。例えば原稿のスキャンの実行を画像形成装置２０Ａに指示した後に、ユーザが画像形成装置２０Ａから離れた場合である。
予め定めた時間が経過してもユーザによる選択が入力されない場合に備えた機能として、プラグインサービス状態表示部２２０に、予め登録されているユーザのメールアドレスに対して他のフォーマットへの変換を実行するかを問い合わせる機能を設けてもよい。
ユーザからの選択を受け付ける前に障害が復旧した場合、クラウドサービスの処理が再開される。

＜他の実施の形態＞
以上、本発明の実施の形態について説明したが、本発明の技術的範囲は前述した実施の形態に記載の範囲に限定されない。前述した実施の形態に、種々の変更又は改良を加えたものも、本発明の技術的範囲に含まれることは、特許請求の範囲の記載から明らかである。

例えば前述の実施の形態では、端末２０の例として、印刷、コピー、ファックス、スキャナ等の複数の機能を備える画像形成装置２０Ａを想定したが、印刷の専用機やスキャナの専用機でもよい。また、端末２０は、画像形成装置２０Ａのように、用紙等の記録媒体に画像を形成する装置ではなく、例えば３次元データを用いて立体像を形成する３次元プリンタでもよい。

また、前述の実施の形態におけるプロセッサは、広義的な意味でのプロセッサを指し、汎用的なプロセッサ（例えばＣＰＵ等）の他、専用的なプロセッサ（例えばＧＰＵ、ＡＳＩＣ（＝Application Specific Integrated Circuit）、ＦＰＧＡ、プログラム論理デバイス等）を含む。
また、前述した各実施の形態におけるプロセッサの動作は、１つのプロセッサが単独で実行してもよいが、物理的に離れた位置に存在する複数のプロセッサが協働して実行してもよい。また、プロセッサにおける各動作の実行の順序は、前述した各実施の形態に記載した順序のみに限定されるものでなく、個別に変更してもよい。

１…クラウドシステム、１０…クラウドネットワーク、２０…端末、２０Ａ…画像形成装置、２０Ｂ…ノート型のコンピュータ、３０…クラウドサーバ、３０Ａ…業務型のクラウドサーバ、３０Ｂ…ストレージ型のクラウドサーバ、４０…中継サーバ、４１…制御ユニット、４１Ａ…ＣＰＵ、４２…記憶装置、４３…入出力ポート、４４…通信装置、４１０…コアサービス、４２０…タスク定義モジュール、４３０…プラグインサービス、４４０…キュー、４５０…リクエスト状態管理部、４６０…ヘルスチェックリクエスト発行部

Claims (9)

1. ユーザが操作する端末によるクラウドサービスの利用を中継するサービスを提供する情報処理装置はプロセッサを有し、
   前記プロセッサは、
   受け付けたリクエストに関する処理の状態を監視し、
   処理が継続している前記リクエストがある間、ヘルスチェックのリクエストを発行しない
   情報処理装置。
2. 前記プロセッサは、ユーザが操作する前記端末で発行された前記リクエストの処理が完了するまで、前記ヘルスチェックのリクエストを発行しない、請求項１に記載の情報処理装置。
3. 前記プロセッサは、前記リクエストに関する処理がいずれも完了した後、前記ヘルスチェックのリクエストの発行を許可する、請求項２に記載の情報処理装置。
4. 前記プロセッサは、前記クラウドサービスの障害の発生を監視し、当該障害の発生が確認された場合、前記ヘルスチェックのリクエストを発行しない、請求項１に記載の情報処理装置。
5. 前記プロセッサは、プラグインサービスのログを通じ、前記障害の発生を監視する、請求項４に記載の情報処理装置。
6. 前記プロセッサは、前記障害の復旧が確認された場合、前記ヘルスチェックのリクエストの発行を許可する、請求項４に記載の情報処理装置。
7. 前記プロセッサは、前記クラウドサービスの障害からの復旧が確認された場合、前記ヘルスチェックのリクエストの発行を許可する、請求項１に記載の情報処理装置。
8. 前記プロセッサは、前記クラウドサービスの停止を、ユーザが操作する前記端末に通知する、請求項４に記載の情報処理装置。
9. 前記プロセッサは、前記クラウドサービスの復旧を、ユーザが操作する前記端末に通知する、請求項４又は８に記載の情報処理装置。