特開 2023-37368 情報処理装置、メンテナンス状況提供方法、プログラム、サービス提供システム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2023037368

(43)【公開日】2023-03-15

(54)【発明の名称】情報処理装置、メンテナンス状況提供方法、プログラム、サービス提供システム

(51)【国際特許分類】

   G06Q 50/10 20120101AFI20230308BHJP

【ＦＩ】

G06Q50/10

【審査請求】未請求

【請求項の数】10

【出願形態】ＯＬ

(21)【出願番号】P 2021144070

(22)【出願日】2021-09-03

(71)【出願人】

【識別番号】000006747

【氏名又は名称】株式会社リコー

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(72)【発明者】

【氏名】岸本 充弘

【テーマコード（参考）】

5L049

【Ｆターム（参考）】

5L049CC15

(57)【要約】      （修正有）

【課題】複数の取得方法に優先順位を設定して外部サーバーのメンテナンス情報を取得できる情報処理装置、メンテナンス状況提供方法、プログラム及びサービス提供システムを提供する。
【解決手段】サービス提供システムにおいて、第二の情報処理装置である文書配信管理サーバー１１０がサービスの提供に使用する外部サーバーである配信サーバーを監視する情報処理装置である監視サーバー１４０は、外部サーバーに関する情報を取得する複数の取得方法のうち、予め設定された優先順位で外部サーバーに関する情報を取得する情報取得部と、情報取得部が取得した外部サーバーに関する情報に基づいて、外部サーバーのメンテナンス状況を前記第二の情報処理装置に提供する提供部と、を有する。
【選択図】図３

【特許請求の範囲】

【請求項1】

第二の情報処理装置がサービスの提供に使用する外部サーバーを監視する情報処理装置であって、
前記外部サーバーに関する情報を取得する複数の取得方法のうち、予め設定された優先順位で前記外部サーバーに関する情報を取得する情報取得部と、
前記情報取得部が取得した前記外部サーバーに関する情報に基づいて、前記外部サーバーのメンテナンス状況を前記第二の情報処理装置に提供する提供部と、
を有することを特徴とする情報処理装置。

【請求項2】

前記外部サーバーに関する情報を解析して、前記外部サーバーのメンテナンス状況を判断するメンテナンス情報解析部を有することを特徴とする請求項１に記載の情報処理装置。

【請求項3】

前記複数の取得方法は、前記外部サーバーが公開するＷｅｂ ＡＰＩを使用する方法、前記外部サーバーがメンテナンス情報を公開するＷｅｂサイトから取得する方法、及び、前記外部サーバーに電子メールで問い合わせ、前記問い合わせに対する返信として取得する方法、であることを特徴とする請求項１又は２に記載の情報処理装置。

【請求項4】

前記情報取得部は、前記外部サーバーが前記Ｗｅｂ ＡＰＩを公開している場合は前記Ｗｅｂ ＡＰＩを使用し、
前記外部サーバーが前記Ｗｅｂ ＡＰＩを公開していない場合は、前記Ｗｅｂサイトから取得し、
前記外部サーバーが前記Ｗｅｂサイトを公開していない場合は、前記電子メールを用いて前記外部サーバーに関する情報を取得することを特徴とする請求項３に記載の情報処理装置。

【請求項5】

前記複数の取得方法のそれぞれについて、前記外部サーバーが公開するＷｅｂ ＡＰＩ、前記ＷｅｂサイトのＵＲＬ、及び、前記外部サーバーのメールアドレス及びメールサーバの登録画面を端末装置に提供し、前記端末装置から前記外部サーバーが公開するＷｅｂ ＡＰＩ、前記ＷｅｂサイトのＵＲＬ、及び、前記外部サーバーのメールアドレス及びメールサーバの設定を受け付ける設定受付部を有することを特徴とする請求項３又は４に記載の情報処理装置。

【請求項6】

前記設定受付部は、前記複数の取得方法の優先順位の設定を受け付けることを特徴とする請求項５に記載の情報処理装置。

【請求項7】

前記優先順位は前記外部サーバーによって異なることを特徴とする請求項６に記載の情報処理装置。

【請求項8】

第二の情報処理装置がサービスの提供に使用する外部サーバーを監視する情報処理装置のメンテナンス状況提供方法であって、
前記外部サーバーに関する情報を取得する複数の取得方法のうち、予め設定された優先順位で前記外部サーバーに関する情報を取得するステップと、
取得した前記外部サーバーに関する情報に基づいて、前記外部サーバーのメンテナンス状況を前記第二の情報処理装置に提供するステップと、
を有することを特徴とするメンテナンス状況提供方法。

【請求項9】

第二の情報処理装置がサービスの提供に使用する外部サーバーを監視する情報処理装置を、
前記外部サーバーに関する情報を取得する複数の取得方法のうち、予め設定された優先順位で前記外部サーバーに関する情報を取得する情報取得部と、
前記情報取得部が取得した前記外部サーバーに関する情報に基づいて、前記外部サーバーのメンテナンス状況を前記第二の情報処理装置に提供する提供部、
として機能させるためのプログラム。

【請求項10】

外部サーバーを使用してサービスを提供するにサービス提供システムであって、
前記外部サーバーに関する情報を取得する複数の取得方法のうち、予め設定された優先順位で前記外部サーバーに関する情報を取得する情報取得部と、
前記情報取得部が取得した前記外部サーバーに関する情報に基づく、前記外部サーバーのメンテナンス状況に応じて、サービスを実行するサービス実行制御部と、
を有することを特徴とするサービス提供システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、情報処理装置、メンテナンス状況提供方法、プログラム、及び、サービス提供システムに関する。

【背景技術】

【0002】

文書の配信などの種々のジョブを実行するサービス提供システムが知られている。サービス提供システムがジョブを実行する際に外部サーバーの障害によりジョブが失敗する場合がある。この場合、サービス提供システムの管理者は例えば外部サーバーの管理者から障害が解消した旨を受信して、復旧したことを検出することができる。

【0003】

また、外部サーバー等のネットワーク上のサービスが復旧したかどうかを、サービスを公開しているＷｅｂサーバーから取得する技術が知られている（例えば、特許文献１参照。）。特許文献１には、複数の方法でサーバーのメンテナンス状況等を確認する方法が開示されている。

【発明の概要】

【発明が解決しようとする課題】

【0004】

しかしながら、従来の技術では、複数の取得方法に優先順位を設定して外部サーバーのメンテナンス情報を取得できないという問題がある。例えば、複数の取得方法の精度に差がある場合に精度のよいものから実行することが困難である。

【0005】

本発明は、上記課題に鑑み、複数の取得方法に優先順位を設定して外部サーバーのメンテナンス情報を取得できる情報処理装置を提供することを目的とする。

【課題を解決するための手段】

【0006】

上記課題に鑑み、本発明は、第二の情報処理装置がサービスの提供に使用する外部サーバーを監視する情報処理装置であって、前記外部サーバーに関する情報を取得する複数の取得方法のうち、予め設定された優先順位で前記外部サーバーに関する情報を取得する情報取得部と、前記情報取得部が取得した前記外部サーバーに関する情報に基づいて、前記外部サーバーのメンテナンス状況を前記第二の情報処理装置に提供する提供部と、を有することを特徴とする。

【発明の効果】

【0007】

複数の取得方法に優先順位を設定して外部サーバーのメンテナンス情報を取得できる情報処理装置を提供することができる。

【図面の簡単な説明】

【0008】

【図1】サービス提供システムのシステム全体の概略構成図の一例である。

【図2】コンピュータの一例のハードウェア構成図である。

【図3】文書配信管理サーバー及び監視サーバーの機能構成例を示す図である。

【図4】記憶部に格納されるテーブルの例を示す図である。

【図5】管理者端末が表示するメンテナンス情報取得設定情報の登録画面の一例を示す図である。

【図6】取得方法の優先順位を変更できるメンテナンス情報取得設定情報の登録画面の一例を示す図である。

【図7】Ｗｅｂ ＡＰＩにより取得されるメンテナンス情報の一例を示す図である。

【図8】ＷｅｂサイトのＵＲＬへのアクセスにより取得されるメンテナンス情報の一例を示す図である。

【図9】電子メールにより取得されるメンテナンス情報の一例を示す図である。

【図10】サービス提供システムが機器からの要求に応じてジョブを実行する手順を示すシーケンス図の一例である。

【図11】監視サーバーがメンテナンス情報を解析する手順を示すフローチャート図の一例である。

【発明を実施するための形態】

【0009】

以下、本発明を実施するための形態の一例として、サービス提供システムとサービス提供システムが行うメンテナンス状況提供方法について図面を参照しながら説明する。

【0010】

＜サービス提供システムの動作の概略＞
監視サーバーが配信先サーバーなどの外部サーバーのメンテナンス情報を取得する方法として、
１．外部サーバーが用意するＷｅｂ ＡＰＩ（Application Programming Interface）
２．外部サーバーのＷｅｂページで公開される情報
３．外部サーバーに対する問い合わせ先のメールアドレス
を使用する方法がある。

【0011】

本実施形態のサービス提供システムは、上記のような複数の方法を組み合わせ、外部サーバーのメンテナンス情報を取得する。これにより、上記の複数の取得方法のうち１つしか対応していない外部サーバーが存在しても、外部サーバーのメンテナンス情報を幅広く取得できる。

【0012】

また、サービス提供システムは、メンテナンス情報を取得する取得方法に優先順位をつけることでメンテナンス情報の判断精度を向上できる。

【0013】

＜用語について＞
Ｗｅｂ ＡＰＩとは、HTTPプロトコルを用いてネットワーク越しに呼び出すアプリケーション間又はシステム間のインターフェースをいう。

【0014】

サービスとは、処理を行うことや処理結果を提供することをいう。処理の結果は有体物でも無体物でもよい。

【0015】

外部サーバーに関する情報とは、外部サーバーのメンテナンス状況を判断できる情報であればよい。また、メンテナンスとは、外部サーバーの維持、保守又は管理等のために使用が制限されることをいい、メンテナンス状況は理由を問わずにメンテナンスが行われているかどうかをいう。

【0016】

＜システム構成例＞
図１は、本実施形態におけるサービス提供システムのシステム全体の概略構成図である。図１では、一例として、サービス提供システム１００は、文書配信管理サーバー１１０と監視サーバー１４０を有している。また、文書配信管理サーバー１１０は配信先サーバー１２０と通信することができる。文書配信管理サーバー１１０、監視サーバー１４０、及び配信先サーバー１２０は、情報処理装置であり、互いにネットワークを介して通信可能である。

【0017】

本実施形態の文書配信管理サーバー１１０（第二の情報処理装置の一例）は、ＭＦＰ（Multi－Function Peripheral）１３０などの画像処理装置が読み込んだ文書（スキャンした画像データ）を、ＰＤＦ等の所定の形式のファイルで配信先サーバー１２０に配信することで、ジョブを実行する。文書配信管理サーバー１１０はジョブを実行することでジョブに応じたサービスを提供する。このようなジョブをワークフローや処理フローという場合がある。ＭＦＰ１３０がスキャンした文書の他、ＦＡＸ受信した文書もジョブの対象となる。

【0018】

ジョブには、例えば、ＭＦＰが原稿をスキャンして得た文書にＯＣＲ（Optical Character Reader）を施してＰＤＦに変換し、電子メールで送信したり、フォルダに配信したりするものがある。このような一連の処理（すなわちジョブ）は、顧客側の管理者が登録しておくことができ、エンドユーザーはＭＦＰ１３０が表示するジョブのリストから所望のジョブを選択して、実行できる。

【0019】

なお、配信対象となる文書は、ＭＦＰ１３０以外の装置から提供されるものであってもよい。また、文書配信管理サーバー１１０は、実行するジョブの設定を管理者端末１１１から行うことができる。

【0020】

管理者端末１１１は、管理者が使用する端末装置である。管理者端末は、例えば、ＰＣ(Personal Computer)、スマートデバイス（スマートフォン、タブレット端末等）が挙げられているが、この他、ゲーム機、ＰＤＡ(Personal Digital Assistant)、デジタルカメラ、ウェアラブルＰＣ等、Ｗｅｂブラウザが動作するか、ジョブの設定用に使用されるアプリが動作すればよい。

【0021】

配信先サーバー１２０は、文書配信管理サーバー１１０から受信した文書を格納する。情報処理端末１２１は、配信先サーバー１２０とネットワークを介して接続され、各ユーザーは、配信された文書を情報処理端末１２１から閲覧することができる。

【0022】

配信先サーバー１２０は、文書配信管理サーバー１１０とは管理者や運営元が異なる外部サーバーである。このため、配信先サーバー１２０のメンテナンス時間等は文書配信管理サーバー１１０から制御できない。また、図１では、配信先サーバー１２０は一台だが、各種の配信先サーバー１２０が、複数存在することが想定される。どの配信先サーバー１２０に配信されるかは、予めジョブに設定されている。配信先サーバー１２０としては、Dropbox（登録商標）、Box（登録商標）、OneDrive（登録商標）、Google ドライブ（登録商標）、Microsoft365（登録商標）等があるが、これらは一例に過ぎない。

【0023】

監視サーバー１４０は、配信先サーバー１２０のメンテナンス状況を監視する（情報処理装置の一例）。監視サーバー１４０は、文書配信管理サーバー１１０からの要求に応じて配信先サーバー１２０のメンテナンス状況を取得してもよいし、自律的に、配信先サーバー１２０のメンテナンス状況を取得してもよい。このため、監視サーバー１４０はネットワークを介して各種の配信先サーバー１２０と通信可能に接続されている。

【0024】

図１に示すサービス提供システム１００の概略構成は一例であって、文書配信管理サーバー１１０と監視サーバー１４０は一体でもよい。また、監視サーバー１４０の機能が複数のサーバーに分散して配置されていてもよい。

【0025】

また、例えば、文書配信管理サーバー１１０と、ＭＦＰ１３０とが行う処理が、１の装置で行われるような構成であってもよい。また、サービス提供システム１００に含まれる各装置の台数は一例であり、図示する以外の数の装置が存在してよい。

【0026】

＜ハードウェア構成例＞
図１の文書配信管理サーバー１１０、及び監視サーバー１４０は例えば図２に示すハードウェア構成のコンピュータにより実現される。図２はコンピュータの一例のハードウェア構成図である。図２のコンピュータ５００はコンピュータによって構築されており、図２に示されているように、ＣＰＵ５０１、ＲＯＭ５０２、ＲＡＭ５０３、ＨＤ５０４、ＨＤＤコントローラ５０５(Hard Disk Drive)、ディスプレイ５０６、外部機器接続Ｉ/Ｆ５０８(Interface)、ネットワークＩ/Ｆ５０９、バスライン５１０、キーボード５１１、ポインティングデバイス５１２、光学ドライブ５１４、メディアＩ/Ｆ５１６を備えている。

【0027】

これらのうち、ＣＰＵ５０１は、コンピュータ全体の動作を制御する。ＲＯＭ５０２は、ＩＰＬ等のＣＰＵ５０１の駆動に用いられるプログラムを記憶する。ＲＡＭ５０３は、ＣＰＵ５０１のワークエリアとして使用される。ＨＤ５０４は、プログラム等の各種データを記憶する。ＨＤＤコントローラ５０５は、ＣＰＵ５０１の制御にしたがってＨＤ５０４に対する各種データの読み出し又は書き込みを制御する。ディスプレイ５０６は、カーソル、メニュー、ウィンドウ、文字、又は画像などの各種情報を表示する。外部機器接続Ｉ/Ｆ５０８は、各種の外部機器を接続するためのインターフェースである。この場合の外部機器は、例えば、ＵＳＢ(Universal Serial Bus)メモリやプリンタ等である。ネットワークＩ/Ｆ５０９は、通信ネットワークを利用してデータ通信をするためのインターフェースである。バスライン５１０は、図２に示されているＣＰＵ５０１等の各構成要素を電気的に接続するためのアドレスバスやデータバス等である。

【0028】

また、キーボード５１１は、文字、数値、各種指示などの入力のための複数のキーを備えた入力手段の一種である。ポインティングデバイス５１２は、各種指示の選択や実行、処理対象の選択、カーソルの移動などを行う入力手段の一種である。光学ドライブ５１４は、着脱可能な記録媒体の一例としての光記憶媒体５１３に対する各種データの読み出し又は書き込みを制御する。光学ドライブ５１４はＣＤ、ＤＶＤ、Blu－Ray（登録商標）等である。メディアＩ/Ｆ５１６は、フラッシュメモリ等の記録メディア５１５に対するデータの読み出し又は書き込み（記憶）を制御する。

【0029】

＜機能について＞
図３は、文書配信管理サーバー１１０及び監視サーバー１４０の機能構成例を示す図である。

【0030】

＜＜文書配信管理サーバー＞＞
文書配信管理サーバー１１０は、ジョブ入力受付部３１０、サービス実行制御部３２０、通知送受信部３３０、設定部３４０、通信部３５０、記憶部３６０の各モジュールを含む。文書配信管理サーバー１１０が有するこれら各機能部は、文書配信管理サーバー１１０にインストールされた１以上のプログラムに含まれる命令を図２に示したＣＰＵ５０１が実行することで実現される機能又は手段である。以下に、各機能手段について詳細に説明する。

【0031】

ジョブ入力受付部３１０は、ＭＦＰ１３０から文書を配信するジョブの入力（実行要求）を受け付ける。文書は、例えば、ＭＦＰ１３０のスキャン機能によって読み取られた文書であり、ＰＤＦなどの所定の形式に変換されたファイルとして入力される。

【0032】

サービス実行制御部３２０は、予め登録されたジョブの設定情報を参照し、当該設定情報に基づいて、ジョブの実行を制御する手段である。例えばサービス実行制御部３２０は、ジョブ入力受付部３１０にジョブが入力されると、所定の配信先に文書ファイルを配信することで、ジョブを実行する。また、サービス実行制御部３２０は、通知送受信部３３０に対して、ジョブの実行の成否に応じた通知を依頼する。更に、サービス実行制御部３２０は、実行に失敗したジョブの保留や、保留されたジョブの再実行などの処理を行うことができる。

【0033】

通知送受信部３３０は、ネットワークＩ/Ｆ５０９を介して、種々の通知を行う手段である。通知送受信部３３０は、例えば、ジョブの実行処理を行ったユーザーに対して、当該ジョブの成否の通知を送信することができる。また、通知送受信部３３０は、配信先サーバー１２０のエラーによってジョブを実行できなかった場合に、当該サーバー装置の管理者に対して、配信先サーバー１２０にエラーが発生している旨や、修復などの対処を依頼する旨の通知を送信する。更に、通知送受信部３３０は、配信先サーバー１２０の管理者から、サーバーを修復した旨の通知を受信することができる。

【0034】

設定部３４０は、ジョブに関する種々の設定を行う手段である。設定部３４０は、設定用の画面を生成して管理者端末１１１に送信し、画面に入力された情報を受け付けるＷｅｂサーバーとして機能する。本実施形態においては、サービス提供システム１００の管理者が、管理者端末１１１から文書配信管理サーバー１１０にアクセスすることで、文書を配信するジョブの種々の処理について設定することができる。

【0035】

通信部３５０は、監視サーバー１４０のＡＰＩを介して、監視サーバー１４０に配信先サーバー１２０のメンテナンス状況を問い合わせたり、メンテナンス状況を取得したりする。

【0036】

記憶部３６０は、種々のデータを記憶する。本実施形態の記憶部３６０は、保留ジョブテーブル３６１と、異常サーバテーブル３６２とを格納する。記憶部３６０に格納されるテーブルについて、図４を参照して説明する。図４は、本実施形態の記憶部３６０に格納されるテーブルの例を示す図である。

【0037】

図４（ａ）は、保留ジョブテーブル３６１の例を示す。保留ジョブテーブル３６１は、実行に失敗したジョブを、実行が保留されているジョブ（以下、「保留ジョブ」として参照する）として格納する記憶領域である。保留ジョブテーブル３６１には、各ジョブを識別する番号と、各ジョブの内容などとを対応付けて格納することができる。図４（ａ）に示す例では、保留ジョブテーブル３６１は、ジョブを識別する番号、各ジョブに基づいて配信される文書の配信先サーバー名、配信先サーバー１２０のアドレス、配信先のフォルダ、認証情報などを対応付けて格納している。なお、保留ジョブテーブル３６１には、図４（ａ）に示したもの以外の項目が含まれてもよい。

【0038】

図４（ｂ）は、異常サーバテーブル３６２の例を示す。異常サーバテーブル３６２には、エラーが発生した配信先サーバー名と、当該サーバーが配信の対象となっているジョブとが対応付けられたリストが格納されている。本実施形態では、実行に失敗したジョブについて、文書の配信先となっている配信先サーバー１２０を、エラーが発生したサーバーとして保留ジョブと対応付けて異常サーバテーブル３６２に格納する。また、新たに発生したエラーに係るサーバーが、すでに異常サーバテーブル３６２に格納されているものである場合には、当該サーバーに対応する保留ジョブの項目に、エラーが発生したジョブのジョブ識別番号を追加する。図４（ｂ）では、図４（ａ）の保留ジョブテーブル３６１に格納されている各配信先サーバー名が、保留ジョブのジョブ識別番号と対応付けられて異常サーバテーブル３６２に格納されている例を示している。

【0039】

＜＜監視サーバー＞＞
監視サーバー１４０は、通信部１１、情報取得部１２、メンテナンス情報解析部１３、設定受付部１４、及び、提供部１５を有している。監視サーバー１４０が有するこれら各機能部は、監視サーバー１４０にインストールされた１以上のプログラムに含まれる命令を図２に示したＣＰＵ５０１が実行することで実現される機能又は手段である。以下に、各機能手段について詳細に説明する。

【0040】

通信部１１は、文書配信管理サーバー１１０から配信先サーバー１２０のメンテナンス状況の問い合わせを受信する。また、通信部１１は、配信先サーバー１２０のメンテナンス状況を文書配信管理サーバー１１０に送信する。

【0041】

情報取得部１２は、文書配信管理サーバー１１０からメンテナンス状況の取得依頼を受信した場合に、後述のメンテナンス情報取得設定情報に従い、配信先サーバー１２０から配信先サーバー１２０のメンテナンス情報を取得する。

【0042】

メンテナンス情報を取得する場合、配信先サーバー１２０がメンテナンス情報の取得用のＷｅｂ ＡＰＩを公開していれば、Ｗｅｂ ＡＰＩから取得できるメンテナンス情報が最も正確であると思われる。そのため、Ｗｅｂ ＡＰＩが公開されている場合、情報取得部１２は第一の取得方法としてＷｅｂ ＡＰＩを使用する。

【0043】

ただしすべての配信先サーバー１２０がメンテナンス情報を取得できるＷｅｂ ＡＰＩを公開しているとは限らない。その場合、情報取得部１２は、第二の取得方法としてメンテナンス情報を公開するＷｅｂサイトのＵＲＬにアクセスし、Ｗｅｂページの情報を取得する。アクセスするＵＲＬは後述のメンテナンス情報取得設定情報に登録されている。第二の取得方法によって取得された情報は後述のメンテナンス情報解析部１３に渡され、メンテナンス状況の判断に使われる。

【0044】

第一の取得方法と第二の取得方法が使用できない場合、情報取得部１２は第三の取得方法として配信先サーバー１２０の問い合わせ用のメールアドレスに電子メールを自動で送信し、それに対し問い合わせ先担当者が返信することでメンテナンス情報を取得する。電子メールの送信先は後述のメンテナンス情報取得設定情報に登録されている。第三の取得方法によって取得された情報は後述のメンテナンス情報解析部１３に渡され、メンテナンス状況の判断に使われる。

【0045】

メンテナンス情報解析部１３は、情報取得部１２が取得した情報を解析してメンテナンス状況を判断する。
・第一の取得方法であるＷｅｂ ＡＰＩにより取得された情報の場合、メンテナンス情報解析部１３はＷｅｂ ＡＰＩのレスポンス仕様（フォーマット）にしたがってメンテナンス状況を判断する。レスポンス仕様とは、予め決まった項目名にメンテナンス状況を示す情報が対応付けられていることをいう。
・第二の取得方法であるＷｅｂサイトのＵＲＬへのアクセスにより取得されたメンテナンス状況（htmlファイル）の場合、メンテナンス情報解析部１３は、Ｗｅｂページにアクセスしたときに取得されるhtmlファイルなどを解析することでメンテナンス状況を判断する。

【0046】

メンテナンス状況の判断方法として機械学習を使用する方法がある。例えば、ナイーブベイズを使用してＷｅｂページのテキストデータがメンテナンス中かどうかを判断する。ナイーブベイズはあるデータがどのカテゴリーに属するものなのか判断する機械学習の手法のひとつである。この場合、テキストデータの単語にもとついてメンテナンス中かそうでないかが判断される。また、メンテナンス情報解析部１３は、ディープラーニングを使用して、判断してもよい。あるいは、メンテナンス情報解析部１３は、単に、Ｗｅｂページのテキストデータを形態素解析して、メンテナンスの開始、メンテナンス中、又は、終了したことを示すキーワードと、予め登録しておいたキーワードを比較してもよい。
・第三の取得方法である電子メールにより取得されたメンテナンス情報の場合、メンテナンス情報解析部１３は、予め決められた文面の問い合わせメールを自動送信し、返信された受信メールの文面からメンテナンス状況を判断する。判断方法は第二の取得方法と同様でよい。

【0047】

設定受付部１４は、メンテナンス情報取得設定情報の登録を受け付ける。サービス提供システム１００の管理者は一例として後述する図５のような登録画面によりメンテナンス情報取得設定情報を登録できる。

【0048】

提供部１５は、メンテナンス情報解析部１３が生成したメンテナンス状況を、通信部１１を介して文書配信管理サーバー１１０に提供する。

【0049】

＜メンテナンス情報取得設定情報の登録画面＞
図５は、管理者端末１１１が表示するメンテナンス情報取得設定情報の登録画面２１０の一例である。管理者は管理者端末１１１を監視サーバー１４０に接続させ、Ｗｅｂブラウザが監視サーバー１４０から受信したメンテナンス情報取得設定情報の登録画面２１０の画面情報に基づいて、この登録画面２１０を表示する。画面情報は、ＨＴＭＬ、ＸＭＬ、スクリプト言語、及びＣＳＳ（Cascading Style Sheet）等で記述されたプログラムであり、主にＨＴＭＬによりＷｅｂページの構造が規定され、スクリプト言語によりＷｅｂページの動作が規定され、ＣＳＳによりＷｅｂページのスタイルが規定される。

【0050】

管理者はサービス提供システム１００で使用され得る配信先サーバー１２０に"Ｗｅｂ ＡＰＩ"、"メンテナンス情報取得ＵＲＬ"及び"問い合わせアドレス/メールサーバ"の１つ以上を設定する。管理者は"Ｗｅｂ ＡＰＩ"の項目にメンテナンス情報が公開されているＷｅｂ ＡＰＩを設定する。また、管理者は"メンテナンス情報取得ＵＲＬ"の項目には、配信先サーバー１２０のメンテナンスページのＵＲＬを入力する。また、管理者は、"問い合わせアドレス/メールサーバ"の項目に各配信先サーバー１２０の問い合わせ先メールアドレスとメールサーバに関する情報（ＳＭＴＰサーバーとＰｏｐサーバーのＩＰアドレス等）を入力する。図５でＳＭＴＰサーバーとＰｏｐサーバーのＩＰアドレスが、配信先サーバーＡとＣで同じなのは、文書配信管理サーバー１１０が使用するメールサーバのＩＰアドレスだからである。

【0051】

管理者により設定されたメンテナンス情報取得設定情報は、管理者端末１１１から監視サーバー１４０に送信される。設定受付部１４は、メンテナンス情報取得設定情報をメンテナンス情報取得設定情報記憶部１９に保存する。メンテナンス情報取得設定情報は前述の情報取得部１２により参照される。

【0052】

また、図５では、取得方法の優先順位が配信先サーバー１２０に共通であるが、配信先サーバー１２０に応じて取得方法の優先順位を管理者が設定できてもよい。

【0053】

図６は、取得方法の優先順位を変更できるメンテナンス情報取得設定情報の登録画面２２０の一例である。図６（ａ）では、配信先サーバーＡの優先順位は、Ｗｅｂ ＡＰＩ、メンテナンス情報取得ＵＲＬ、問い合わせアドレス/メールサーバの順である。図６（ｂ）では、配信先サーバーＢの優先順位は、Ｗｅｂ ＡＰＩ、問い合わせアドレス/メールサーバ、メンテナンス情報取得ＵＲＬの順である。

【0054】

例えば、配信先サーバーＢがメンテナンス情報取得ＵＲＬを公開しているが、更新が遅いことが分かっているような場合、管理者が問い合わせアドレス/メールサーバの優先順位を高くすることで、正確な情報を得やすくなる。

【0055】

＜各メンテナンス情報の一例＞
次に、図７～図９を参照して、第一～第三の取得方法により取得される各メンテナンス情報について説明する。

【0056】

図７は、Ｗｅｂ ＡＰＩ（第一の取得方法）により取得されるメンテナンス情報の一例を示す。図７（ａ）はメンテナンス中に取得されるメンテナンス情報を示し、図７（ｂ）は復旧後に取得されるメンテナンス情報を示す。図７のメンテナンス情報では、"Status"２３０の項目が、配信先サーバー１２０がメンテナンス中（"Stopped"）か通常稼働中か（"Running"）を示す。したがって、メンテナンス情報解析部１３はメンテナンス情報の"Status"２３０の項目に基づいて、メンテナンス中かどうかを判断する。

【0057】

なお、図７ではJson形式のメンテナンス情報を示すが、メンテナンス情報はXMLやCSV等のどのような形式でもよい。また、メンテナンス情報の"Status"２３０の項目がメンテナンス中を表すかどうかは一例に過ぎない。項目名と、メンテナンス中かどうかを示す値は配信先サーバー１２０ごとに決まっており、メンテナンス情報解析部１３は決まった項目を参照する。

【0058】

図８は、ＷｅｂサイトのＵＲＬへのアクセス（第二の取得方法）により取得されるメンテナンス情報の一例を示す。図８（ａ）はメンテナンス中に取得されるメンテナンス情報を示し、図８（ｂ）は復旧後に取得されるメンテナンス情報を示す。図８のメンテナンス情報では、サポートタグ２３１に、日時に対応付けて、コメント２３２が表示される。メンテナンス情報解析部１３は最新のコメント２３２に着目する。なお、図８では説明のためにＷｅｂページの形式でメンテナンス情報を示すが、メンテナンス情報解析部１３はｈｔｍｌファイルの形式でメンテナンス情報を取得する。

【0059】

図８（ａ）によれば、最新のコメント２３２は「１月１日１２時から臨時メンテナンスのためサービスを停止しております。大変ご不便をおかけしますが、今しばらくお待ちください。」である。メンテナンス情報解析部１３は、上記のように、ナイーブベイズ、ディープラーニング、コメント２３２の形態素解析等により、メンテナンス中であると判断できる。

【0060】

同様に、図８（ｂ）によれば、最新のコメント２３３は「１月１日１２時から１月４日１２時にかけ、データセンターのサーバー破損によりWeb Service Aの利用が不可能になりました。ご迷惑をおかけ致しましたことをお詫び申し上げます。現在サーバーの復旧作業が完了し、通常通りご利用頂けます。」である。メンテナンス情報解析部１３は、上記のように、ナイーブベイズ、ディープラーニング、コメント２３３の形態素解析等により、メンテナンスから復旧した（通常稼働中）と判断できる。

【0061】

なお、機械学習の手法はディープラーニングに限られず、パーセプトロン、サポートベクターマシン、ロジスティック回帰、決定木、ランダムフォレストなどがあり、本実施形態で説明する手法には限られない。機械学習とは、コンピュータに人のような学習能力を獲得させるための技術であり、コンピュータが、データ識別等の判断に必要なアルゴリズムを、事前に取り込まれる学習データから自律的に生成し、新たなデータについてこれを適用して予測を行う技術のことをいう。機械学習のための学習方法は、教師あり学習、教師なし学習、半教師学習、強化学習、深層学習のいずれかの方法でもよく、更に、これらの学習方法を組み合わせた学習方法でもよく、機械学習のための学習方法は問わない。

【0062】

図９は、電子メール（第三の取得方法）により取得されるメンテナンス情報の一例を示す。まず、図９（ａ）は情報取得部１２が配信先サーバー１２０に送信する、メンテナンス情報を問い合わせる電子メールの文例である。図９（ａ）では「当メールは貴社のWeb Service Aを利用している○○社のサービス提供システム△△より自動送信されています。こちらのメールにService Aの復旧状況を記載し返信をお願いします。」と記載されている。このような文面は情報取得部１２に予め設定されている。また、送信元のメールアドレス（監視サーバー１４０のメールアドレス）はメンテナンス情報取得設定情報記憶部１９に予め登録されている。

【0063】

図９（ｂ）はメンテナンス中に返信される電子メール（メンテナンス情報）を示し、図９（ｃ）は復旧後に返信される電子メール（メンテナンス情報）を示す。図９（ｂ）の電子メールには、「１月１日１２時からメンテナンスのためサービスを停止しております。大変ご不便をおかけしますが、今しばらくお待ちください。」と記載されている。メンテナンス情報解析部１３は、上記のように、ナイーブベイズ、ディープラーニング、電子メールの形態素解析等により、メンテナンス中であると判断できる。

【0064】

同様に、図９（ｃ）の電子メールには、「１月１日１２時から１月４日１２時にかけ、データセンターのサーバー破損によりWeb Service Aの利用が不可能になりました。ご迷惑をおかけ致しましたことをお詫び申し上げます。現在サーバーの復旧作業が完了し、通常通りご利用頂けます。」と記載されている。メンテナンス情報解析部１３は、上記のように、ナイーブベイズ、ディープラーニング、電子メールの形態素解析等により、メンテナンスから復旧したと判断できる。

【0065】

＜動作手順＞
図１０は、サービス提供システムが機器からの要求に応じてジョブを実行する手順を示すシーケンス図の一例である。

【0066】

S11：ＭＦＰ１３０を操作するユーザーは文書配信管理サーバー１１０にログインして、該ユーザーに登録されているジョブ（ワークフローのアプリともいう）のリストをＭＦＰに表示させる。ユーザーはリストから実行するジョブを選択し、ジョブを実行する。ＭＦＰ１３０はジョブの実行を受け付けて、ユーザーが用意した原稿をスキャンするなどして、文書とともにジョブ実行要求を文書配信管理サーバーに送信する。

【0067】

S12：文書配信管理サーバー１１０の通信部３５０はジョブ実行要求を受信すると、該ジョブで使用する配信先サーバー１２０を指定して、メンテナンス状況を監視サーバー１４０に問い合わせる。

【0068】

S13：監視サーバー１４０の通信部１１はメンテナンス状況の問い合わせを受け付け、情報取得部１２が配信先サーバー１２０に対しメンテナンス情報を要求する。このステップS13の処理の詳細を図１１にて説明する。

【0069】

S14：監視サーバー１４０の提供部１５は、通信部１１を介して、メンテナンス情報に基づいて判断したメンテナンス状況を文書配信管理サーバー１１０に提供する。メンテナンス状況は、例えばメンテナンス中や通常稼働中等である。

【0070】

S15：文書配信管理サーバー１１０の通信部３５０はメンテナンス状況を受信し、サービス実行制御部３２０はメンテナンス中でなければ、文書を配信先サーバー１２０に配信する。

【0071】

S16：メンテナンス中である場合、通知送受信部３３０はユーザーのメールアドレス宛にメンテナンス中のため実行を保留にした旨を送信する。あるいは、通知送受信部３３０は、ＭＦＰ１３０にメンテナンス中のため実行を保留にした旨を送信し、ＭＦＰ１３０のログに保存させてもよい。サービス実行制御部３２０は、実行に失敗したジョブを保留ジョブテーブル３６１と異常サーバテーブル３６２に登録し、メンテナンスから復旧すると、保留されたジョブを再実行する。メンテナンスからの復旧を検出するため、通信部３５０は一定時間ごとにメンテナンス状況を監視サーバー１４０に問い合わせる。

【0072】

図１１は、監視サーバー１４０がメンテナンス情報を解析する手順を示すフローチャート図の一例である。

【0073】

まず、通信部１１が、文書配信管理サーバー１１０から配信先サーバー１２０を指定してメンテナンス状況の解析依頼を受信する（Ｓ１）。文書配信管理サーバー１１０は、例えば、ジョブの実行時にジョブが文書を配信する配信先サーバー１２０を指定する。

【0074】

情報取得部１２は、指定された配信先サーバー１２０について、メンテナンス情報取得設定情報にＷｅｂ ＡＰＩが設定されているか否かを判断する（Ｓ２）。

【0075】

ステップＳ２の判断がＹｅｓの場合、情報取得部１２は配信先サーバー１２０のＷｅｂ ＡＰＩにHTTPリクエストを送り、HTTPレスポンスとしてメンテナンス情報を取得する。そして、メンテナンス情報解析部１３がメンテナンス情報を解析し、メンテナンス中か通常稼働中かを判断する（Ｓ３）。

【0076】

ステップＳ２の判断がＮｏの場合、情報取得部１２は、指定された配信先サーバー１２０について、メンテナンス情報取得設定情報にメンテナンス情報取得ＵＲＬが設定されているか否かを判断する（Ｓ４）。

【0077】

ステップＳ４の判断がＹｅｓの場合、情報取得部１２はメンテナンス情報取得ＵＲＬにアクセスし、Ｗｅｂページの情報を取得する。メンテナンス情報解析部１３は、Ｗｅｂページの情報を解析して、メンテナンス中か通常稼働中かを判断する（Ｓ５）。

【0078】

ステップＳ４の判断がＮｏの場合、指定された配信先サーバー１２０について、メンテナンス情報取得設定情報に"問い合わせメールアドレス/メールサーバが設定されているか否かを判断する（Ｓ６）。

【0079】

ステップＳ６の判断がＮｏの場合、情報取得部１２がメンテナンス情報を取得できないので図１１の処理は終了する。

【0080】

ステップＳ６の判断がＹｅｓの場合、情報取得部１２が"問い合わせメールアドレス/メールサーバ"のアドレス宛に電子メールを送信する（Ｓ７）。この問い合わせの電子メールに対し電子メールが返信されるまでは、配信先サーバー１２０において人間が介在するため時間がかかる。このため、通信部１１は、返信を待機し、電子メールの返信があるまで文書配信管理サーバー１１０に"判断中"という結果を返す（Ｓ８）。

【0081】

配信先サーバー１２０から返信の電子メールを受信した場合、メンテナンス情報解析部１３は文面を解析してメンテナンス中か通常稼働中かを判断する（Ｓ９）。

【0082】

そして、通信部１１は、配信先サーバー１２０のメンテナンス状況（配信先サーバー１２０がメンテナンス中か、通常稼働中）を文書配信管理サーバー１１０に送信する（Ｓ１０）。

【0083】

このように、情報取得部１２は、予め設定されている優先順位にしたがって、異なる方法でメンテナンス情報を配信先サーバー１２０から取得できる。Ｗｅｂ ＡＰＩが用意されている場合、Ｗｅｂ ＡＰＩで得られるメンテナンス情報は、メンテナンス中か否かを簡潔に示すので解析が不要か又は解析が容易である。Ｗｅｂ ＡＰＩが用意されていない場合、情報取得部１２はＷｅｂページに記載されたメンテナンス情報をＷｅｂ ＡＰＩと同様に即座に得られる。また、Ｗｅｂページのメンテナンス情報は決まった文体が多いので、メンテナンス中か否かの解析が容易である。メンテナンス情報取得ＵＲＬが用意されてない場合でも、情報取得部１２は電子メールによりメンテナンス情報を取得できるので、配信先サーバー１２０によってＷｅｂ ＡＰＩとメンテナンス情報取得ＵＲＬが用意されていなくても、メンテナンス情報を取得する機会を増やすことができる。

【0084】

なお、本実施形態では、Ｗｅｂ ＡＰＩ、メンテナンス情報取得ＵＲＬ、電子メールの順に優先順位が高いとしたが、必ずしも優先順位はこの順番でなくてもよい。

【0085】

また、情報取得部１２は文書配信管理サーバー１１０からの要求がなくても、例えば定期的に配信先サーバー１２０からメンテナンス情報を取得してもよい。この場合、メンテナンス情報解析部１３は、将来予定されるメンテナンスも解析で明らかにし、予め、文書配信管理サーバー１１０に送信しておくことができる。

【0086】

＜主な効果＞
本実施形態のサービス提供システムは、上記のような複数の方法を組み合わせ、配信先サーバー１２０（外部サーバー）のメンテナンス状況を取得する。これにより、上記の複数の方法のうち１つしか対応していない配信先サーバー１２０が存在しても、配信先サーバー１２０のメンテナンス状況を幅広く取得できる。

【0087】

また、本実施形態では、メンテナンス状況を取得する方法に優先順位をつけることでメンテナンス状況の判断精度を向上できる。

【0088】

＜その他の適用例＞
以上、本発明を実施するための最良の形態について実施例を用いて説明したが、本発明はこうした実施例に何等限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々の変形及び置換を加えることができる。

【0089】

本実施形態では、サービス提供システムが文書を配信する配信先サーバー１２０のメンテナンス状況を監視サーバー１４０が監視したが、サービス提供システムはサービスの提供に外部サーバーを使用すればよく、文書を配信しなくてもよい。例えば、外部サーバーは画像データのファイル形式の変換、ＯＣＲ(Optical Character Reader)、翻訳、各種の計算等を行ってもよい。

【0090】

また、ジョブの実行にはＭＦＰが使用されなくてもよい。例えば、ユーザーは、ＰＪ(Projector：プロジェクタ)、電子黒板（電子式の黒板機能を有する白板)等、ＭＦＰ以外の機器を使用してジョブを実行できる。

【0091】

また、図３などの構成例は、文書配信管理サーバー１１０及び監視サーバー１４０による処理の理解を容易にするために、主な機能に応じて分割したものである。処理単位の分割の仕方や名称によって本願発明が制限されることはない。文書配信管理サーバー１１０及び監視サーバー１４０の処理は、処理内容に応じて更に多くの処理単位に分割することもできる。また、１つの処理単位が更に多くの処理を含むように分割することもできる。

【0092】

また、実施例に記載された装置群は、本明細書に開示された実施形態を実施するための複数のコンピューティング環境のうちの１つを示すものにすぎない。ある実施形態では、監視サーバー１４０は、サーバクラスタといった複数のコンピューティングデバイスを含む。複数のコンピューティングデバイスは、ネットワークや共有メモリなどを含む任意のタイプの通信リンクを介して互いに通信するように構成されており、本明細書に開示された処理を実施する。

【0093】

更に、文書配信管理サーバー１１０及び監視サーバー１４０は、本実施形態で開示された処理ステップ、例えば図１０を様々な組み合わせで共有するように構成できる。文書配信管理サーバー１１０及び監視サーバー１４０は、１つのサーバー装置にまとめられていても良いし、複数の装置に分けられていても良い。

【0094】

上記で説明した実施形態の各機能は、一又は複数の処理回路によって実現することが可能である。ここで、本明細書における「処理回路」とは、電子回路により実装されるプロセッサのようにソフトウェアによって各機能を実行するようプログラミングされたプロセッサや、上記で説明した各機能を実行するよう設計されたASIC(Application Specific Integrated Circuit)、DSP（Digital Signal Processor）、FPGA（Field Programmable Gate Array）や従来の回路モジュール等のデバイスを含むものとする。

【符号の説明】

【0095】

１００ サービス提供システム
１１０ 文書配信管理サーバー
１２０ 配信先サーバー
１３０ ＭＦＰ
１４０ 監視サーバー

【先行技術文献】

【特許文献】

【0096】

【特許文献1】特開2014-220665号公報

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】