特許 7067232 サービス提供装置およびプログラム

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2022-05-06

(45)【発行日】2022-05-16

(54)【発明の名称】サービス提供装置およびプログラム

(51)【国際特許分類】

   G06F 9/46 20060101AFI20220509BHJP

   G06F 8/61 20180101ALI20220509BHJP

【ＦＩ】

G06F9/46 420

G06F8/61

【請求項の数】 23

(21)【出願番号】P 2018081350

(22)【出願日】2018-04-20

(65)【公開番号】P2019191740

(43)【公開日】2019-10-31

【審査請求日】2020-12-23

(73)【特許権者】

【識別番号】000001270

【氏名又は名称】コニカミノルタ株式会社

(74)【代理人】

【識別番号】100117673

【弁理士】

【氏名又は名称】中島 了

(72)【発明者】

【氏名】前川 裕明

【審査官】多胡 滋

(56)【参考文献】

【文献】特表２００６－５０２４６５（ＪＰ，Ａ）

【文献】特開２０１３－０２０４９４（ＪＰ，Ａ）

【文献】特開２００２－２９７４０２（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ ９／４６

Ｇ０６Ｆ ８／６１

(57)【特許請求の範囲】

【請求項1】

サービス提供装置であって、
一のサービスの提供要求を受け付ける受付手段と、
自装置内にインストールされている複数のアプリケーションのいずれかを用いて前記一のサービスを提供することが可能か否か、を判定する判定手段と、
前記一のサービスの前記提供要求に応じたサービス処理を制御するサービス管理手段と、
を備え、
前記サービス管理手段は、
前記複数のアプリケーションのいずれかを用いて前記一のサービスを提供することが可能であると判定される場合、前記複数のアプリケーションのうち、前記一のサービスに対応するアプリケーションを用いて、前記一のサービスの前記提供要求に応じた前記サービス処理を開始し、
前記複数のアプリケーションのいずれを用いても前記一のサービスを提供することが不可能であると判定される場合、
前記サービス提供装置とは別のサービス提供装置である外部サーバに前記一のサービスの前記提供要求を転送して当該提供要求に応じた前記サービス処理を前記外部サーバに開始させるとともに、
前記一のサービスを提供するための特定のアプリケーションを前記外部サーバあるいは他の外部装置からダウンロードして自装置にインストールし、前記特定のアプリケーションの自装置へのインストールが完了した後において、前記一のサービスの前記提供要求の転送に伴って前記外部サーバによって開始されていた前記サービス処理を前記外部サーバから引き継いで実行することを特徴とするサービス提供装置。

【請求項2】

請求項１に記載のサービス提供装置において、
前記サービス管理手段は、前記複数のアプリケーションのいずれかを用いて前記一のサービスを提供することが不可能であると判定される場合、前記サービス提供装置にて稼働している少なくとも１つのサービスを非稼働状態に遷移させてその使用リソースを解放し当該少なくとも１つのサービスと入れ替わりに前記一のサービスを前記サービス提供装置で稼働させる処理である差替処理を実行することを特徴とするサービス提供装置。

【請求項3】

請求項２に記載のサービス提供装置において、
前記サービス管理手段は、その使用リソースの合計が前記一のサービスの提供に要するリソースよりも多い少なくとも１つのサービスを、前記差替処理にて前記非稼働状態へと遷移させて停止させるべき停止対象サービスとして、前記サービス提供装置にて現在稼働している稼働中サービスの中から決定することを特徴とするサービス提供装置。

【請求項4】

請求項２に記載のサービス提供装置において、
前記差替処理にて前記非稼働状態へと遷移させて停止させるべき停止対象サービスは、前記サービス提供装置にて何れのユーザによっても現在使用されていないサービスの中から決定されることを特徴とするサービス提供装置。

【請求項5】

請求項４に記載のサービス提供装置において、
前記サービス管理手段は、前記サービス提供装置にて現在稼働中且つ非使用中のサービスの中から、最終使用時点を示す情報に基づいて前記停止対象サービスを決定することを特徴とするサービス提供装置。

【請求項6】

請求項４に記載のサービス提供装置において、
前記サービス管理手段は、前記サービス提供装置にて現在稼働中且つ非使用中のサービスの中から、過去の所定期間中における使用回数を示す情報に基づいて前記停止対象サービスを決定することを特徴とするサービス提供装置。

【請求項7】

請求項４に記載のサービス提供装置において、
前記サービス管理手段は、前記サービス提供装置にて現在稼働中且つ非使用中のサービスの中から、過去の所定期間中における使用ユーザ数を示す情報に基づいて前記停止対象サービスを決定することを特徴とするサービス提供装置。

【請求項8】

請求項４から請求項７のいずれかに記載のサービス提供装置において、
前記サービス管理手段は、前記サービス提供装置にて現在稼働中のサービスの中に、現在使用されていないサービスが存在しない場合には、前記差替処理を保留することを特徴とするサービス提供装置。

【請求項9】

請求項８に記載のサービス提供装置において、
前記サービス管理手段は、使用されていないサービスが存在しないことに基づき前記差替処理を保留することが決定された時点の後において、当該時点で使用されていたサービスが当該時点の後に使用されなくなったことを条件として、前記差替処理の保留を解除し前記差替処理を開始することを特徴とするサービス提供装置。

【請求項10】

請求項４から請求項９のいずれかに記載のサービス提供装置において、
前記サービス管理手段は、前記サービス提供装置にて現在使用されていないサービスが存在しないために前記停止対象サービスが決定できない場合、前記一のサービスに対応する前記特定のアプリケーションのダウンロードを開始して前記一のサービスの稼働開始のための準備を進行させておき、前記サービス提供装置における使用終了サービスの発生に伴って前記使用終了サービスを前記停止対象サービスとして決定し、前記停止対象サービスの稼働停止と引き換えに、前記特定のアプリケーションを利用した前記一のサービスの稼働を開始することを特徴とするサービス提供装置。

【請求項11】

請求項２に記載のサービス提供装置において、
前記差替処理にて前記非稼働状態へと遷移させて停止させるべき停止対象サービスは、所定の差替除外対象サービスを除いたサービスであることを特徴とするサービス提供装置。

【請求項12】

請求項２に記載のサービス提供装置において、
前記サービス管理手段は、前記差替処理にて前記非稼働状態へと遷移させて停止させるべき停止対象サービスに関するデータのうち、前記非稼働状態への遷移前の稼働期間において変更されていたデータを、前記外部サーバにアップロードしておき前記外部サーバに管理させることを特徴とするサービス提供装置。

【請求項13】

請求項１から請求項１１のいずれかに記載のサービス提供装置において、
前記サービス処理を前記外部サーバから引き継いで実行する際には、前記サービス処理に関連するサービス関連情報をも前記外部サーバから引き継いで使用することを特徴とするサービス提供装置。

【請求項14】

請求項１３に記載のサービス提供装置において、
前記サービス管理手段は、前記サービス処理を前記外部サーバから引き継いで実行することを決定すると、前記一のサービスの使用中ユーザを特定するとともに前記一のサービスの複数のユーザに関するデータのうち前記使用中ユーザに関するデータをダウンロードすることを特徴とするサービス提供装置。

【請求項15】

請求項１４に記載のサービス提供装置において、
前記サービス管理手段は、前記一のサービスの前記使用中ユーザに関するデータのダウンロードが完了した後、前記一のサービスの前記使用中ユーザ以外のユーザに関するデータのダウンロードを開始することを特徴とするサービス提供装置。

【請求項16】

請求項１４に記載のサービス提供装置において、
前記サービス管理手段は、前記一のサービスの前記複数のユーザに関するデータのうち、前記一のサービスの前記使用中ユーザである第１の使用対象ユーザに関するデータをダウンロードした後、前記第１の使用対象ユーザとは別の第２の使用対象ユーザからの前記一のサービスの提供要求を受け付けたことに応答して、前記第２の使用対象ユーザに関するデータをダウンロードすることを特徴とするサービス提供装置。

【請求項17】

請求項１から請求項１１のいずれかに記載のサービス提供装置において、
前記サービス管理手段は、前記サービス処理を前記外部サーバから引き継いで実行する際、前記一のサービスに関するデータのうち、画面操作に関するデータを含む一部のデータを前記外部サーバからダウンロードして引き継ぐことを特徴とするサービス提供装置。

【請求項18】

請求項１から請求項１１のいずれかに記載のサービス提供装置において、
前記サービス管理手段は、前記サービス処理を前記外部サーバから引き継いで実行する際、前記一のサービスに関するデータのうち、前記サービス提供装置に関するステータスをポーリングして表示するためのステータスデータを含む一部のデータを前記外部サーバからダウンロードして引き継ぐことを特徴とするサービス提供装置。

【請求項19】

請求項１から請求項１１のいずれかに記載のサービス提供装置において、
前記サービス管理手段は、前記サービス処理を前記外部サーバから引き継いで実行する際、前記一のサービスに関するデータのうち一部の特定データであって前記外部サーバで管理される一部の特定データをダウンロードせず、前記サービス処理における引継対象データから当該一部の特定データを除外することを特徴とするサービス提供装置。

【請求項20】

請求項１９に記載のサービス提供装置において、
前記一部の特定データは、トランザクションデータを含むことを特徴とするサービス提供装置。

【請求項21】

請求項１から請求項１１のいずれかに記載のサービス提供装置において、
前記サービス管理手段は、前記サービス提供装置によって提供される前記一のサービスにて変更されるデータを、逐次に前記外部サーバに転送して格納させることを特徴とするサービス提供装置。

【請求項22】

請求項１から請求項１１のいずれかに記載のサービス提供装置において、
前記サービス管理手段は、前記サービス提供装置によって提供される前記一のサービスにて変更されるデータを、前記一のサービスの一のユーザによる使用が終了した時点で一括して前記外部サーバに転送して格納させることを特徴とするサービス提供装置。

【請求項23】

サービス提供装置に内蔵されたコンピュータに、
ａ）一のサービスの提供要求を受け付けるステップと、
ｂ）自装置内にインストールされている複数のアプリケーションのいずれかを用いて前記一のサービスを提供することが可能か否かを判定するステップと、
ｃ）前記一のサービスの前記提供要求に応じたサービス処理を制御するステップと、
を実行させるためのプログラムであって、
前記ステップｃ）は、
ｃ－１）前記複数のアプリケーションのいずれかを用いて前記一のサービスを提供することが可能であると判定される場合、前記複数のアプリケーションのうち、前記一のサービスに対応するアプリケーションを用いて、前記一のサービスの前記提供要求に応じた前記サービス処理を開始するステップと、
ｃ－２）前記複数のアプリケーションのいずれを用いても前記一のサービスを提供することが不可能であると判定される場合、前記サービス提供装置とは別のサービス提供装置である外部サーバに前記一のサービスの前記提供要求を転送して当該提供要求に応じた前記サービス処理を前記外部サーバに開始させるとともに、前記一のサービスを提供するための特定のアプリケーションを前記外部サーバあるいは他の外部装置からダウンロードして自装置にインストールし、前記特定のアプリケーションの自装置へのインストールが完了した後において、前記一のサービスの前記提供要求の転送に伴って前記外部サーバによって開始されていた前記サービス処理を前記外部サーバから引き継いで実行するステップと、
を有することを特徴とするプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、サービス提供装置およびそれに関連する技術に関する。

【背景技術】

【0002】

クライアント端末からの要求に応じてウエブサービスを提供するクラウドサーバが存在する。

【0003】

ただし、通信環境にも依るが、クライアント端末（ＬＡＮの内部装置）とクラウドサーバ（ＬＡＮの外部装置）との間の通信速度は、ローカル環境内での通信速度（ＬＡＮ内の装置同士の通信速度）よりも小さい（低速である）ため、サービス提供時における反応速度等が低下するという問題が存在する。

【0004】

これに対して、ＬＡＮ内に設けられたサーバ（たとえばローカル側のプロキシサーバ）にウエブサービス用のプログラムをダウンロードしておき、当該ＬＡＮ内のサーバ（サービス提供装置とも称する）にて当該プログラムを動作させる技術が存在する（特許文献１等参照）。これによれば、ＬＡＮ内のクライアント端末と当該サービス提供装置との間での比較的高速な通信を伴ってサービスが提供され得る。

【先行技術文献】

【特許文献】

【0005】

【文献】特開２００１－５１８３９号公報

【発明の概要】

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

【0006】

しかしながら、サービス提供装置（ＬＡＮ内サーバ等）のリソースには限界が存在するため、このような技術において多数のサービスの全てを当該サービス提供装置にて常に動作させ続けることは困難である。

【0007】

そこで、この発明は、比較的多数のサービスを提供することが可能なサービス提供装置を提供することを課題とする。

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

【0008】

上記課題を解決すべく、請求項１の発明は、サービス提供装置であって、一のサービスの提供要求を受け付ける受付手段と、自装置内にインストールされている複数のアプリケーションのいずれかを用いて前記一のサービスを提供することが可能か否か、を判定する判定手段と、前記一のサービスの前記提供要求に応じたサービス処理を制御するサービス管理手段と、を備え、前記サービス管理手段は、前記複数のアプリケーションのいずれかを用いて前記一のサービスを提供することが可能であると判定される場合、前記複数のアプリケーションのうち、前記一のサービスに対応するアプリケーションを用いて、前記一のサービスの前記提供要求に応じた前記サービス処理を開始し、前記複数のアプリケーションのいずれを用いても前記一のサービスを提供することが不可能であると判定される場合、前記サービス提供装置とは別のサービス提供装置である外部サーバに前記一のサービスの前記提供要求を転送して当該提供要求に応じた前記サービス処理を前記外部サーバに開始させるとともに、前記一のサービスを提供するための特定のアプリケーションを前記外部サーバあるいは他の外部装置からダウンロードして自装置にインストールし、前記特定のアプリケーションの自装置へのインストールが完了した後において、前記一のサービスの前記提供要求の転送に伴って前記外部サーバによって開始されていた前記サービス処理を前記外部サーバから引き継いで実行することを特徴とする。

【0009】

請求項２の発明は、請求項１の発明に係るサービス提供装置において、前記サービス管理手段は、前記複数のアプリケーションのいずれかを用いて前記一のサービスを提供することが不可能であると判定される場合、前記サービス提供装置にて稼働している少なくとも１つのサービスを非稼働状態に遷移させてその使用リソースを解放し当該少なくとも１つのサービスと入れ替わりに前記一のサービスを前記サービス提供装置で稼働させる処理である差替処理を実行することを特徴とする。

【0010】

請求項３の発明は、請求項２の発明に係るサービス提供装置において、前記サービス管理手段は、その使用リソースの合計が前記一のサービスの提供に要するリソースよりも多い少なくとも１つのサービスを、前記差替処理にて前記非稼働状態へと遷移させて停止させるべき停止対象サービスとして、前記サービス提供装置にて現在稼働している稼働中サービスの中から決定することを特徴とする。

【0011】

請求項４の発明は、請求項２の発明に係るサービス提供装置において、前記差替処理にて前記非稼働状態へと遷移させて停止させるべき停止対象サービスは、前記サービス提供装置にて何れのユーザによっても現在使用されていないサービスの中から決定されることを特徴とする。

【0012】

請求項５の発明は、請求項４の発明に係るサービス提供装置において、前記サービス管理手段は、前記サービス提供装置にて現在稼働中且つ非使用中のサービスの中から、最終使用時点を示す情報に基づいて前記停止対象サービスを決定することを特徴とする。

【0013】

請求項６の発明は、請求項４の発明に係るサービス提供装置において、前記サービス管理手段は、前記サービス提供装置にて現在稼働中且つ非使用中のサービスの中から、過去の所定期間中における使用回数を示す情報に基づいて前記停止対象サービスを決定することを特徴とする。

【0014】

請求項７の発明は、請求項４の発明に係るサービス提供装置において、前記サービス管理手段は、前記サービス提供装置にて現在稼働中且つ非使用中のサービスの中から、過去の所定期間中における使用ユーザ数を示す情報に基づいて前記停止対象サービスを決定することを特徴とする。

【0015】

請求項８の発明は、請求項４から請求項７のいずれかの発明に係るサービス提供装置において、前記サービス管理手段は、前記サービス提供装置にて現在稼働中のサービスの中に、現在使用されていないサービスが存在しない場合には、前記差替処理を保留することを特徴とする。

【0016】

請求項９の発明は、請求項８の発明に係るサービス提供装置において、前記サービス管理手段は、使用されていないサービスが存在しないことに基づき前記差替処理を保留することが決定された時点の後において、当該時点で使用されていたサービスが当該時点の後に使用されなくなったことを条件として、前記差替処理の保留を解除し前記差替処理を開始することを特徴とする。

【0017】

請求項１０の発明は、請求項４から請求項９のいずれかの発明に係るサービス提供装置において、前記サービス管理手段は、前記サービス提供装置にて現在使用されていないサービスが存在しないために前記停止対象サービスが決定できない場合、前記一のサービスに対応する前記特定のアプリケーションのダウンロードを開始して前記一のサービスの稼働開始のための準備を進行させておき、前記サービス提供装置における使用終了サービスの発生に伴って前記使用終了サービスを前記停止対象サービスとして決定し、前記停止対象サービスの稼働停止と引き換えに、前記特定のアプリケーションを利用した前記一のサービスの稼働を開始することを特徴とする。

【0018】

請求項１１の発明は、請求項２の発明に係るサービス提供装置において、前記差替処理にて前記非稼働状態へと遷移させて停止させるべき停止対象サービスは、所定の差替除外対象サービスを除いたサービスであることを特徴とする。

【0019】

請求項１２の発明は、請求項２の発明に係るサービス提供装置において、前記サービス管理手段は、前記差替処理にて前記非稼働状態へと遷移させて停止させるべき停止対象サービスに関するデータのうち、前記非稼働状態への遷移前の稼働期間において変更されていたデータを、前記外部サーバにアップロードしておき前記外部サーバに管理させることを特徴とする。

【0020】

請求項１３の発明は、請求項１から請求項１１のいずれかの発明に係るサービス提供装置において、前記サービス処理を前記外部サーバから引き継いで実行する際には、前記サービス処理に関連するサービス関連情報をも前記外部サーバから引き継いで使用することを特徴とする。

【0021】

請求項１４の発明は、請求項１３の発明に係るサービス提供装置において、前記サービス管理手段は、前記サービス処理を前記外部サーバから引き継いで実行することを決定すると、前記一のサービスの使用中ユーザを特定するとともに前記一のサービスの複数のユーザに関するデータのうち前記使用中ユーザに関するデータをダウンロードすることを特徴とする。

【0022】

請求項１５の発明は、請求項１４の発明に係るサービス提供装置において、前記サービス管理手段は、前記一のサービスの前記使用中ユーザに関するデータのダウンロードが完了した後、前記一のサービスの前記使用中ユーザ以外のユーザに関するデータのダウンロードを開始することを特徴とする。

【0023】

請求項１６の発明は、請求項１４の発明に係るサービス提供装置において、前記サービス管理手段は、前記一のサービスの前記複数のユーザに関するデータのうち、前記一のサービスの前記使用中ユーザである第１の使用対象ユーザに関するデータをダウンロードした後、前記第１の使用対象ユーザとは別の第２の使用対象ユーザからの前記一のサービスの提供要求を受け付けたことに応答して、前記第２の使用対象ユーザに関するデータをダウンロードすることを特徴とする。

【0024】

請求項１７の発明は、請求項１から請求項１１のいずれかの発明に係るサービス提供装置において、前記サービス管理手段は、前記サービス処理を前記外部サーバから引き継いで実行する際、前記一のサービスに関するデータのうち、画面操作に関するデータを含む一部のデータを前記外部サーバからダウンロードして引き継ぐことを特徴とする。

【0025】

請求項１８の発明は、請求項１から請求項１１のいずれかの発明に係るサービス提供装置において、前記サービス管理手段は、前記サービス処理を前記外部サーバから引き継いで実行する際、前記一のサービスに関するデータのうち、前記サービス提供装置に関するステータスをポーリングして表示するためのステータスデータを含む一部のデータを前記外部サーバからダウンロードして引き継ぐことを特徴とする。

【0026】

請求項１９の発明は、請求項１から請求項１１のいずれかの発明に係るサービス提供装置において、前記サービス管理手段は、前記サービス処理を前記外部サーバから引き継いで実行する際、前記一のサービスに関するデータのうち一部の特定データであって前記外部サーバで管理される一部の特定データをダウンロードせず、前記サービス処理における引継対象データから当該一部の特定データを除外することを特徴とする。

【0027】

請求項２０の発明は、請求項１９の発明に係るサービス提供装置において、前記一部の特定データは、トランザクションデータを含むことを特徴とする。

【0028】

請求項２１の発明は、請求項１から請求項１１のいずれかの発明に係るサービス提供装置において、前記サービス管理手段は、前記サービス提供装置によって提供される前記一のサービスにて変更されるデータを、逐次に前記外部サーバに転送して格納させることを特徴とする。

【0029】

請求項２２の発明は、請求項１から請求項１１のいずれかの発明に係るサービス提供装置において、前記サービス管理手段は、前記サービス提供装置によって提供される前記一のサービスにて変更されるデータを、前記一のサービスの一のユーザによる使用が終了した時点で一括して前記外部サーバに転送して格納させることを特徴とする。

【0030】

請求項２３の発明は、サービス提供装置に内蔵されたコンピュータに、ａ）一のサービスの提供要求を受け付けるステップと、ｂ）自装置内にインストールされている複数のアプリケーションのいずれかを用いて前記一のサービスを提供することが可能か否かを判定するステップと、ｃ）前記一のサービスの前記提供要求に応じたサービス処理を制御するステップと、を実行させるためのプログラムであって、前記ステップｃ）は、ｃ－１）前記複数のアプリケーションのいずれかを用いて前記一のサービスを提供することが可能であると判定される場合、前記複数のアプリケーションのうち、前記一のサービスに対応するアプリケーションを用いて、前記一のサービスの前記提供要求に応じた前記サービス処理を開始するステップと、ｃ－２）前記複数のアプリケーションのいずれを用いても前記一のサービスを提供することが不可能であると判定される場合、前記サービス提供装置とは別のサービス提供装置である外部サーバに前記一のサービスの前記提供要求を転送して当該提供要求に応じた前記サービス処理を前記外部サーバに開始させるとともに、前記一のサービスを提供するための特定のアプリケーションを前記外部サーバあるいは他の外部装置からダウンロードして自装置にインストールし、前記特定のアプリケーションの自装置へのインストールが完了した後において、前記一のサービスの前記提供要求の転送に伴って前記外部サーバによって開始されていた前記サービス処理を前記外部サーバから引き継いで実行するステップと、を有することを特徴とする。

【発明の効果】

【0031】

請求項１から請求項２３に記載の発明によれば、サービス提供装置内にインストールされている複数のアプリケーションを用いて一のサービスを提供することが不可能であると判定される場合には、サービス提供装置は、一のサービスの提供要求を外部サーバに転送して当該一のサービスの提供要求に応じたサービス処理を外部サーバに開始させ、特定のアプリケーションの自装置へのインストールが完了した後において、当該サービス処理を外部サーバから引き継いで実行する。したがって、サービス提供装置は、比較的多数のサービスを利用することが可能である。

【図面の簡単な説明】

【0032】

【図1】サービス提供システムを示す図である。

【図2】サービス提供システムにおける動作を示す概念図である。

【図3】画像形成デバイスの機能ブロックを示す図である。

【図4】サーバデバイスの機能ブロックを示す図である。

【図5】ＭＦＰおよびクラウドサーバにおけるサービスの稼働状況を示す図である。

【図6】第１実施形態に係るサービス提供装置の動作を示すフローチャートである。

【図7】本システムの動作（詳細には、稼働対象サービスの即時提供が「可能」な場合における動作）を示すタイミングチャートである。

【図8】本システムの動作（詳細には、稼働対象サービスの即時提供が「不可能」な場合における動作）を示すタイミングチャートである。

【図9】図８に続く動作を示す図である。

【図10】図８の動作を示す概念図である。

【図11】図９の動作を示す概念図である。

【図12】サーバデバイスにおける稼働中サービスの一覧（サービスリスト）を示す図である。

【図13】ＵＲＬリストを示す図である。

【図14】クラウドサーバにおける稼働中サービスの一覧（サービスリスト）を示す図である。

【図15】サーバデバイスにおける稼働中サービスの一覧を示す図である。

【図16】複数の仮想コンテナ環境を示す図である。

【図17】第２実施形態に係るタイミングチャートである。

【図18】第２実施形態に係るサービス提供装置の動作を示すフローチャートである。

【図19】図１８の動作の一部の詳細動作を示すフローチャートである。

【図20】稼働対象サービスの所要リソース情報の取得動作等を示す概念図である。

【図21】サーバデバイスにおける稼働中サービスの一覧を示す図である。

【図22】サーバデバイスにおける稼働中サービスの一覧を示す図である。

【図23】クラウドサーバにおける稼働中サービスの一覧を示す図である。

【図24】差替処理後のサービスリストを示す図である。

【図25】サーバデバイスのハードウエアリソースを示す図である。

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

【0033】

以下、本発明の実施形態を図面に基づいて説明する。

【0034】

＜１．第１実施形態＞
＜１－１．構成概要＞
図１は、サービス提供システム１を示す図である。サービス提供システム１は、ＭＦＰ１０（マルチ・ファンクション・ペリフェラル（Multi-Functional Peripheral））とクラウドサーバ８０とクライアント９０とを備えて構成される。なお、ＭＦＰ１０は、画像形成装置などとも称される。

【0035】

ＭＦＰ１０とクラウドサーバ８０とクライアント９０とは、ネットワーク１０８を介して接続されており、各装置１０，８０，９０の相互間でデータの送受信が可能である。なお、ネットワーク１０８は、ＬＡＮ（Local Area Network）およびインターネットなどの各種のネットワークを含む。ここでは、ＭＦＰ１０とクライアント９０とは同一のＬＡＮ内に配置されている。また、クラウドサーバ８０は、当該ＬＡＮの外部に配置されている。クライアント９０およびＭＦＰ１０は、それぞれ、インターネット等を介してクラウドサーバ８０にアクセスすることが可能である。

【0036】

このＭＦＰ１０は、互いに独立して動作する複数のデバイス（ここではサーバデバイス２０と画像形成デバイス３０との２つのデバイス）を備える（図２も参照）。ここでは、サーバデバイス２０と画像形成デバイス３０とは、一の筐体に収容され、一体的に構成されている。なお、当該一の筐体には、所定の部材と当該所定の部材に対して開閉自在に設けられた部材（たとえば、ＭＦＰ１０の原稿台に設けられた回転軸に対して回動自在に設けられたＡＤＦ（Auto Document Feeder）付き原稿カバー等）とが含まれるものとする。また、このＭＦＰ１０は、操作表示部４０（図１も参照）をも備える。当該操作表示部４０は、複数のデバイス２０，３０によって共用される。

【0037】

クライアント９０は、オンプレミス側の装置（ＭＦＰ１０（詳細にはサーバデバイス２０））によってサービスの提供を受けることが可能であるとともに、クラウド側の装置（クラウドサーバ８０）によってサービスの提供を受けることも可能である（図２も参照）。クライアント９０は、たとえば、パーソナルコンピュータ等として構成される。

【0038】

＜１－２．画像形成デバイス３０の構成＞
画像形成デバイス３０（図１も参照）は、各種のジョブ（コピージョブ、スキャンジョブ等）を実行することが可能なデバイスである。なお、画像形成デバイス３０は、ＭＦＰデバイスとも称される。

【0039】

図３は、画像形成デバイス３０の機能ブロックを示す図である。画像形成デバイス３０は、画像形成機能（コピー機能、スキャン機能、ファクシミリ機能およびボックス印刷機能等）等を有している。具体的には、画像形成デバイス３０は、図３に示すように、画像読取部３２、印刷出力部３３、通信部３４、格納部３５およびコントローラ（制御部）３９等を備えており、これらの各部を複合的に動作させることによって、各種の機能を実現する。

【0040】

画像読取部３２は、画像形成デバイス３０の所定の位置（自動原稿供給部（ＡＤＦ：Auto Document Feeder）あるいはガラス面等）に載置された原稿を光学的に読み取って（すなわちスキャンして）、当該原稿の画像データ（原稿画像あるいはスキャン画像とも称する）を生成する処理部である。この画像読取部３２は、スキャン部などとも称される。画像形成デバイス３０は、所定の位置に載置された原稿を読み取ることが可能なデバイスであり、画像読取デバイスとも称される。

【0041】

印刷出力部３３は、印刷対象に関するデータに基づいて紙などの各種の媒体に画像を印刷出力する出力部である。印刷出力部３３は、印刷出力機構（具体的には、トナーユニット（現像ユニット）、感光ドラムユニット、中間転写ベルト、転写部、定着部および搬送部など）を有している。当該印刷出力機構は、画像形成機構とも称される。また、画像形成デバイス３０は、各種の媒体に画像を印刷出力することが可能なデバイスであり、印刷出力デバイスとも称される。

【0042】

通信部３４は、公衆回線等を介したファクシミリ通信を行うことが可能な処理部である。さらに、通信部３４は、ネットワークを介したネットワーク通信を行うことも可能である。このネットワーク通信では、たとえば、ＴＣＰ／ＩＰ（Transmission Control Protocol / Internet Protocol）等の各種のプロトコルが利用される。当該ネットワーク通信を利用することによって、画像形成デバイス３０は、所望の相手先（サーバデバイス２０等）との間で各種のデータを授受することが可能である。

【0043】

格納部３５は、各種の記憶装置（（揮発性および／または不揮発性の）半導体メモリおよび／またはハードディスクドライブ（ＨＤＤ）等）で構成される。

【0044】

コントローラ３９は、画像形成デバイス３０に内蔵され、画像形成デバイス３０を統括的に制御する制御装置である。コントローラ３９は、ＣＰＵ（Central Processing Unit）（マイクロプロセッサあるいはコンピュータプロセッサなどとも称される）および各種の半導体メモリ（ＲＡＭおよびＲＯＭ）等を備えるコンピュータシステムとして構成される。コントローラ３９は、ＣＰＵにおいて、ＲＯＭ（例えば、ＥＥＰＲＯＭ（登録商標））内に格納されている所定のソフトウエアプログラム（以下、単にプログラムとも称する）を実行することによって、各種の処理部を実現する。なお、当該プログラム（詳細にはプログラムモジュール群）は、ＵＳＢメモリなどの可搬性の記録媒体に記録され、当該記録媒体から読み出されて画像形成デバイス３０にインストールされるようにしてもよい。あるいは、当該プログラムは、ネットワークを経由してダウンロードされて画像形成デバイス３０にインストールされるようにしてもよい。

【0045】

具体的には、図３に示されるように、コントローラ３９は、上記のプログラムの実行により、通信制御部３９ａと操作制御部３９ｂと動作制御部３９ｃと取得部３９ｄとを含む各種の処理部を実現する。

【0046】

通信制御部３９ａは、通信部３４等と協働して他のデバイス（同一筐体（同一装置）内の他のデバイス（サーバデバイス２０等）、および別の筐体内にて構成される他の装置内のデバイスを含む）との間の通信動作を制御する処理部である。

【0047】

操作制御部３９ｂは、操作表示部４０（図１参照）と協働して、操作表示部４０（特にタッチパネル４５（図１参照））に対する入力動作（操作入力を受け付ける動作）を制御するとともに、操作表示部４０（特にタッチパネル４５）における表示動作（表示出力動作）を制御する処理部である。たとえば、操作制御部３９ｂは、画像形成デバイス３０の画像形成機能に関する情報等を操作表示部４０（タッチパネル４５）に表示させるとともに、操作表示部４０に対するユーザ操作に関する操作入力情報（タッチ情報等）を当該操作表示部４０から取得する。

【0048】

動作制御部３９ｃは、画像形成デバイス３０における各種の動作（ジョブ動作等）を制御する処理部である。動作制御部３９ｃは、印刷ジョブ動作、コピージョブ動作およびスキャンジョブ動作等を制御する。

【0049】

＜１－３．サーバデバイス２０の構成＞
サーバデバイス２０（図１も参照）は、サーバ機能を実現することが可能なデバイスである。サーバデバイス２０は、たとえば汎用的なコンピュータ装置として構成される。

【0050】

図４は、サーバデバイス２０の機能ブロックを示す図である。

【0051】

サーバデバイス２０は、図４の機能ブロック図に示すように、通信部２４、格納部２５、コントローラ（制御部）２９等を備えており、これらの各部を複合的に動作させることによって、各種の機能を実現する。

【0052】

通信部２４は、ネットワーク通信を行うことが可能である。このネットワーク通信では、たとえば、ＴＣＰ／ＩＰ（Transmission Control Protocol / Internet Protocol）等の各種のプロトコルが利用される。当該ネットワーク通信を利用することによって、サーバデバイス２０は、所望の相手先（クライアント９０、クラウドサーバ８０および画像形成デバイス３０等）と連携して各種のデータを授受することが可能である。

【0053】

格納部２５は、各種の記憶装置（（揮発性および／または不揮発性の）半導体メモリおよび／またはハードディスクドライブ（ＨＤＤ）等）で構成される。

【0054】

コントローラ（制御部）２９は、サーバデバイス２０に内蔵され、サーバデバイス２０を統括的に制御する制御装置である。コントローラ２９は、ＣＰＵおよび各種の半導体メモリ（ＲＡＭおよびＲＯＭ）等を備えるコンピュータシステムとして構成される。コントローラ２９は、ＣＰＵにおいて、記憶部（半導体メモリ等）内に格納されている所定のプログラムを実行することによって、各種の処理部を実現する。なお、当該プログラム（詳細にはプログラムモジュール群）は、ＵＳＢメモリなどの可搬性の記録媒体に記録され、当該記録媒体から読み出されてサーバデバイス２０にインストールされるようにしてもよい。あるいは、当該プログラムは、ネットワークを経由してダウンロードされてサーバデバイス２０にインストールされるようにしてもよい。

【0055】

具体的には、コントローラ２９は、当該プログラム等の実行により、通信制御部２９ａと操作制御部２９ｂと動作制御部２９ｃと受付部２９ｄと判定部２９ｅとサービス管理部２９ｆとを含む各種の処理部を実現する。

【0056】

通信制御部２９ａは、通信部２４等と協働して他のデバイス（同一筐体（同一装置）内の他のデバイス（画像形成デバイス３０等）、および別の筐体内にて構成される他の装置内のデバイスを含む）との間の通信動作を制御する処理部である。

【0057】

操作制御部２９ｂは、操作表示部４０と協働して、操作表示部４０（特にタッチパネル４５）に対する入力動作を制御するとともに、操作表示部４０（特にタッチパネル４５）における表示動作を制御する処理部である。たとえば、操作制御部２９ｂは、サーバデバイス２０に関する情報等を操作表示部４０（タッチパネル４５）に表示させるとともに、操作表示部４０（タッチパネル４５）に対するユーザ操作に関する操作入力情報を当該操作表示部４０から取得する。

【0058】

動作制御部２９ｃは、サーバデバイス２０における各種の動作（サーバ動作等）を制御する処理部である。

【0059】

受付部２９ｄは、各クライアント（端末等）から各サービスの提供要求を受け付ける処理部である。

【0060】

判定部２９ｅは、受付部２９ｄにてその提供要求が受け付けられた一のサービスを、自装置内に既にインストールされている複数のアプリケーションのいずれかを用いて提供することが可能か否かを判定する処理部である。換言すれば、判定部２９ｅは、当該一のサービスの即時提供が可能か否か等を判定する。たとえば、判定部２９ｅは、当該特定のアプリケーションが自装置内に既にインストールされて（おり且つ稼働して）いる場合、当該一のサービスの即時提供が可能である旨を判定する。

【0061】

サービス管理部２９ｆは、各サービスの提供要求に応じたサービス処理を制御する処理部である。

【0062】

各種のサービスとしては、「翻訳サービス」、「ＯＣＲサービス」および「カラーコントロールサービス」等が例示される。「翻訳サービス」は、翻訳対象ファイル内の文書を現在の言語から別の言語へと翻訳して出力するサービスである。また、「ＯＣＲサービス」は、処理対象ファイル（画像データファイル）内の文字列をＯＣＲ処理によってテキストデータ化するサービスである。また、「カラーコントロールサービス」は、画像形成デバイス３０における出力色あるいは入力色の微調整を行うサービスである。

【0063】

サーバデバイス２０においては、複数の仮想環境が構築される。当該複数の仮想環境は、サーバデバイス２０のハードウエア（プロセッサおよびＨＤＤ等）を共有して（論理的に区分して）構築される。

【0064】

たとえば、「仮想環境」としては、「仮想コンテナ環境」が例示される（図１６参照）。複数の仮想コンテナ環境は、同一ホストＯＳ上の複数のゲストＯＳでそれぞれ動作する仮想コンテナ（単にコンテナとも称する）ＣＴ（ＣＴ１，ＣＴ２，...）によって構成される。なお、図１６は、複数の仮想コンテナ環境を示す図である。

【0065】

そして、各仮想環境において、或るサービスを提供するためのアプリケーション（詳細には、サーバアプリケーション）を実行することが可能である。たとえば、コンテナＣＴ１（「container_01」）においてサービス「service_01」を提供するためのアプリケーションを実行することが可能である。換言すれば、コンテナＣＴ１によってサービス「service_01」を提供することが可能である。同様に、コンテナＣＴ２によって別のサービス（「service_02」等）を提供することが可能であり、コンテナＣＴ３によって更に別のサービス（「service_03」等）を提供することが可能である。コンテナＣＴ４（不図示）以後においても同様である。

【0066】

このＭＦＰ１０（特にサーバデバイス２０）は、サービス提供装置として動作する。また、クラウドサーバ８０（ＭＦＰ１０の外部のサーバ（単に外部サーバとも称する））も、ＭＦＰ１０とは別のサービス提供装置として動作する。クラウドサーバ８０には多数のサービスの提供のための多数のアプリケーションがインストールされており、一方、ＭＦＰ１０には、（或る時点において、）当該多数のアプリケーションのうちの一部のアプリケーションのみがインストールされている。

【0067】

また、このＭＦＰ１０（サーバデバイス２０を含む）は、クライアント９０と同じＬＡＮ内に配置されるサーバ装置である。当該サーバ装置（ＭＦＰ１０）は、自社で保有され自社によって運用されるサーバであることから、「オンプレミスサーバ」とも称される。ＭＦＰ１０は、クライアント９０からのサービス要求に応じて各種のサービスを提供することが可能である。各サービスは、クラウドサーバ８０によっても提供され得る。ただし、ＭＦＰ１０とクライアント９０とは同じＬＡＮ内に存在するので、ＭＦＰ１０（特にサーバデバイス２０）とクライアント９０との間の通信速度は、クラウドサーバ８０とクライアント９０との間の通信速度よりも高速である。したがって、ＭＦＰ１０によるサービス提供時の反応速度は、クラウドサーバ８０によるサービス提供時の反応速度よりも高速である。また、オンプレミスサーバ１０は、外部のクライアント９０からのサービス提供要求を受け付けるのみならず、内部のクライアント（画像形成デバイス３０）からのサービス提供要求をも受け付けることが可能である。換言すれば、ＭＦＰ１０内部の画像形成デバイス３０は、ＭＦＰ１０（詳細にはサーバデバイス２０）に対してクライアントとして機能する。

【0068】

＜１－４．動作＞
図５は、ＭＦＰ１０およびクラウドサーバ８０におけるサービスの稼働状況を示す図である。図５に示されるように、或る時点においては、クラウドサーバ８０にて各種のサービス（たとえば、８０個のサービス「service_01」～「service_80」））が稼働しているとともに、そのうちの一部のサービス（ここでは、４個のサービス（「service_01」～「service_04」））がＭＦＰ１０にも予めインストールされて稼働している（図１２参照）。換言すれば、ＭＦＰ１０においては、当該４つのサービスにそれぞれ対応する４つのアプリケーションが既にインストールされている。なお、図１２は、ＭＦＰ１０（サーバデバイス２０）にて現在稼働しているサービスの一覧（サービスリスト２５０）を示す図である。当該サービスリスト２５０は、サーバデバイス２０の格納部２５（図４）内に格納されている。

【0069】

図６は、第１実施形態に係るＭＦＰ１０（詳細にはサーバデバイス２０）の動作を示すフローチャートである。

【0070】

ステップＳ１において、サーバデバイス２０は、同一ＬＡＮ内のクライアント９０等から、ユーザの所望のサービスの提供要求（サービス提供要求とも称する）を受け付ける。当該提供要求においては、稼働すべきサービス（稼働対象サービス）が指定されている。

【0071】

次のステップＳ２においては、サーバデバイス２０に（この時点で）インストール済みの複数のアプリケーション（インストール済アプリケーションとも称する）のいずれかを用いて当該稼働対象サービスが提供され得るか否かが判定される。換言すれば、稼働対象サービスが、インストール済アプリケーションに対応する複数のサービス（ここでは、４個のサービス（「service_01」～「service_04」））のいずれかに該当するか否かが判定される。具体的には、現在稼働中のサービスの中に稼働対象サービスが含まれるか否かがサービスリスト２５０に基づいて判定され、その判定結果に応じて、当該複数のアプリケーションのいずれかを用いて稼働対象サービスを提供することが可能であるか否かが判定される。

【0072】

当該複数のアプリケーションのいずれかを用いて稼働対象サービスを提供することが可能であると判定される場合、サーバデバイス２０は、当該複数のアプリケーションのうち、当該稼働対象サービスに対応するアプリケーションを用いて、当該稼働対象サービスの提供要求に応じたサービス処理を開始する（図７参照）。換言すれば、サーバデバイス２０は、自装置２０内にインストール済みのアプリケーションを用いて、当該稼働対象サービスをクライアント９０に対して提供する。すなわち、サーバデバイス２０は、自装置を利用して稼働対象サービスの提供を直ちに開始する。なお、図７は、本システム１の動作（詳細には、当該複数のアプリケーションのいずれかを用いて稼働対象サービスを提供できる場合における動作）を示すタイミングチャートである。

【0073】

たとえば、稼働対象サービス「service_01」が指定されている場合、サービスリスト２５０（図１２）内に当該サービス「service_01」が含まれていることに基づき、インストール済の当該複数のアプリケーションのいずれか（詳細には、サービス「service_01」用のインストール済アプリケーション）を用いて稼働対象サービスを提供することが可能である旨が判定される。この場合、図７に示されるように、サーバデバイス２０のサービス管理部２９ｆは、サービス提供要求を当該稼働対象サービス「service_01」に転送し（ステップＳ３）、当該当該サービス提供要求の受諾がクライアント９０に通知される（ステップＳ４）。その後、クライアント９０は、ＭＦＰ１０（詳細にはサーバデバイス２０内のサービス「service_01」）から稼働対象サービスの提供を受ける（ステップＳ５）。

【0074】

なお、上記実施形態では、稼働対象サービスが既に稼働しているが、これに限定されない。たとえば、稼働対象サービス（「service_01」等）がインストール済みではあるものの未だ稼働されていない場合には、当該稼働対象サービスの起動処理を直ちに行った後に、ステップＳ３，Ｓ４，Ｓ５の処理が実行されてもよい。

【0075】

一方、稼働対象サービス「service_05」が指定されている場合、ステップＳ２において、サービスリスト２５０（図１２）内に当該サービス「service_05」が含まれていないことが判定される。そして、この判定結果に基づき、「サーバデバイス２０にインストール済の当該複数のアプリケーションのいずれかを用いて稼働対象サービスを提供すること」が「不可能」である旨が判定される。換言すれば、当該複数のアプリケーションのいずれを用いても稼働対象サービスを提供することが不可能である旨が判定される。

【0076】

この場合、サーバデバイス２０は、ステップＳ１１（図６）以後の処理を実行する（図８～図１１参照）。なお、図８および図９は、本システム１の動作（詳細には、当該複数のアプリケーションのいずれかを用いて稼働対象サービスを提供できない場合における動作）を示すタイミングチャートである。また、図１０は、図８の動作を示す概念図であり、図１１は、図９の動作を示す概念図である。以下では、ステップＳ１にてサービス「service_05」が稼働対象サービスとして指定されている状況を中心に説明する。

【0077】

具体的には、まず、ステップＳ１１～Ｓ１４（図８および図１０参照）において、サーバデバイス２０のサービス管理部２９ｆは、クラウドサーバ８０に稼働対象サービスの提供要求を転送して、当該提供要求に応じたサービス処理をクラウドサーバ８０に開始させる。すなわち、サーバデバイス２０は、クライアント９０に対する当該稼働対象サービスをクラウドサーバ８０に提供させる。

【0078】

詳細には、ステップＳ１１において、サーバデバイス２０は、サービス提供要求をクラウドサーバ８０上のサービスにリダイレクトする。

【0079】

具体的には、まず、サーバデバイス２０は、クラウドサーバ８０上の稼働対象サービスへのアクセス用のＵＲＬをクラウドサーバ８０に問い合わせて、当該アクセス用のＵＲＬをクラウドサーバ８０から取得する。なお、これに限定されず、サーバデバイス２０は、格納部２５に格納されたＵＲＬリスト２１０（図１３）を利用して、クラウド上の稼働対象サービスへのアクセス用のＵＲＬを取得してもよい。ＵＲＬリスト２１０は、クラウド上の稼働対象サービスへのアクセス用のＵＲＬを予め列挙して記憶したデータリストである。

【0080】

このようにして、たとえば、クラウドサーバ８０で提供されているサービス「service_05」にアクセスするためのＵＲＬ（「http://***.com/service_05」）が取得される。そして、当該ＵＲＬが取得されると、当該ＵＲＬへのリダイレクト処理が行われる（ステップＳ１１）。

【0081】

このリダイレクト処理（ステップＳ１１）によって、元のＵＲＬ「http://192.168.0.1/service_05」へのアクセスが新たなＵＲＬ「http://***.com/service_05」へのアクセスへと変更され、クライアント９０は、（ＭＦＰ１０（サーバデバイス２０）ではなく）クラウドサーバ８０へとアクセスする（ステップＳ１２）。換言すれば、クライアント９０からの当該サービス提供要求は、クラウドサーバ８０に転送される。クラウドサーバ８０は、当該サービス提供要求を受信すると、当該サービス提供要求の受諾をクライアント９０に送信する（ステップＳ１３）。そして、クラウドサーバ８０による稼働対象サービスの提供が開始される（ステップＳ１４）。すなわち、クライアント９０は、クラウドサーバ８０から稼働対象サービスの提供を受けることが可能である。

【0082】

さらに、ＭＦＰ１０（サーバデバイス２０）は、クラウドサーバ８０による稼働対象サービスの提供期間内において、稼働対象サービスを提供するための特定のアプリケーションのダウンロード等を実行する（ステップＳ３１～Ｓ３４参照）（図９および図１１参照）。換言すれば、クラウドサーバ８０からクライアント９０への稼働対象サービスの提供に並行して、サーバデバイス２０はクラウドサーバ８０からのダウンロード等を実行する。

【0083】

具体的には、サーバデバイス２０は、クラウドサーバ８０上の稼働対象サービスのダウンロード要求をクラウドサーバ８０に送信し（ステップＳ３１）、クラウドサーバ８０は当該ダウンロード要求に応答して稼働対象サービス（ここでは、「service_05」（図１４参照））用のアプリケーション等を送信する（ステップＳ３２）。たとえば、クラウドサーバ８０上の稼働対象サービスのサービスイメージデータ（アプリケーション等を含むデータ）が、クラウドサーバ８０からサーバデバイス２０へと送信される。サーバデバイス２０は、受信したデータ（サービスイメージデータ等）を利用して、稼働対象サービスを自装置にインストールする。そして、サーバデバイス２０は、自装置内にインストールされた稼働対象サービスに対して起動要求を送信し（ステップＳ３３）、当該稼働対象サービス（「service_05」）を起動する（図１５も参照）。稼働対象サービスの起動が完了すると、サーバデバイス２０は起動完了通知を受信する（ステップＳ３４）。なお、稼働対象サービスにおいては、ユーザによる各種事項の入力操作（設定操作等）に比較的長い期間（操作期間）を要することが多い。上述のインストール処理等は、このようなユーザの操作期間を利用して進行させることが可能である。

【0084】

このようにして稼働対象サービス用のアプリケーションの自装置へのインストールが完了し且つ稼働対象サービスが起動すると、サーバデバイス２０は、ステップＳ１４にて開始されていた稼働対象サービスのサービス処理をクラウドサーバ８０からサーバデバイス２０へと引き継ぐための処理を実行する（ステップＳ３７～Ｓ４０）。

【0085】

具体的には、サーバデバイス２０は、まず、サーバデバイス２０上の稼働対象サービスへの切替要求をクラウドサーバ８０に対して送信する（ステップＳ３７）。当該切替要求は、稼働対象サービスの提供元装置をクラウドサーバ８０からサーバデバイス２０へと切り替えるべき旨の要求である。

【0086】

クラウドサーバ８０は、当該切替要求を受信すると、当該稼働対象サービスのサービス提供を中断する。そして、ラウドサーバ８０は、ステップＳ１４でのサービス開始時点から現時点（サービス提供中断時点）までに当該稼働対象サービスに関して変更された情報である変更情報（ユーザによる入力情報等）をＭＦＰ１０（詳細には、サーバデバイス２０上の稼働対象サービス）に送信する（ステップＳ３８）。

【0087】

たとえば、稼働対象サービスが「翻訳サービス」である場合には、翻訳対象データに関する情報（ファイル名およびファイルパス等）、ならびに翻訳に関する各種の設定情報（入力言語、出力言語など）等が送信される。また、稼働対象サービスが「ＯＣＲサービス」である場合には、ＯＣＲ処理対象データに関する情報（ファイル名およびファイルパス等）、ならびにＯＣＲに関する各種の設定情報（ＯＣＲエンジン、出力ファイル形式など）等が送信される。なお、当該変更情報は、サービス管理部２９ｆを経由してサーバデバイス２０上の稼働対象サービスに送信されてもよく、あるいは、サーバデバイス２０上の稼働対象サービスに直接的に送信されてもよい。

【0088】

クラウドサーバ８０は、当該変更情報（途中情報とも称する）の送信が完了すると、送信完了通知を送信する（ステップＳ３９）とともに、切替要求に関する処理の完了通知を送信する（ステップＳ４０）。

【0089】

さらに、クラウドサーバ８０は、クライアント９０からの次の処理に関するリクエストを受信する（ステップＳ４１）と、サーバデバイス２０上の稼働対象サービスに当該リクエストをリダイレクトし（ステップＳ４２，Ｓ４３）し、リダイレクト後のレスポンスは、サーバデバイス２０から返信される（ステップＳ４４）。以後、稼働対象サービスに関するクライアント９０からのリクエストは、サーバデバイス２０へと送信され、サーバデバイス２０からレスポンスがクライアント９０へと返信される。その結果、（サーバデバイス２０上の）稼働対象サービスが、サーバデバイス２０によってクライアント９０に対して提供される（ステップＳ４５）。このようにして、サーバデバイス２０は、稼働対象サービスの提供要求の転送に伴ってクラウドサーバ８０によって開始されていたサービス処理をクラウドサーバから引き継いで実行する。

【0090】

以上のように、サーバデバイス２０にインストール済の当該複数のアプリケーションのいずれを用いても稼働対象サービスを提供することが「不可能」である旨が判定される（ステップＳ２）と、サーバデバイス２０は、稼働対象サービスに関するサービス処理をクラウドサーバ８０に開始させる（Ｓ１１～Ｓ１４）とともに、クラウドサーバ８０による稼働対象サービスの提供処理に並行して、当該稼働対象サービス用のアプリケーションをサーバデバイス２０自身にインストールしてサービス稼働準備を進める（Ｓ３１～Ｓ４０）。そして、稼働対象サービス用の当該アプリケーションが起動されてサービス稼働準備が完了すると、稼働対象サービスの提供元がクラウドサーバ８０からサーバデバイス２０へと切り換わる（Ｓ４２～Ｓ４４）。

【0091】

このような動作において、稼働対象サービスの要求時点でサーバデバイス２０に未だインストールされていないアプリケーションに対応するサービスは、先ずはクラウドサーバ８０によって提供されるので、ユーザは所望のサービスの利用を直ちに（比較的早期に）開始することが可能である。

【0092】

また、クラウドサーバ８０による稼働対象サービスのクライアント９０への提供処理に並行して、サーバデバイス２０は、当該稼働対象サービス用のアプリケーションをクラウドサーバ８０からダウンロードしてサーバデバイス２０自身にインストールする。そして、インストール完了後において、サーバデバイス２０は、稼働対象サービスに関してクラウドサーバ８０によって開始されていたサービス処理を当該クラウドサーバ８０から引き継いで実行する。このように、稼働対象サービスの要求時点では稼働対象サービス用のアプリケーションがサーバデバイス２０にインストールされていなかったとしても、当該アプリケーションがサーバデバイス２０へとインストールされ、当該稼働対象サービスがクラウドサーバ８０からサーバデバイス２０へと引き継いで実行される。したがって、サーバデバイス２０は、予め準備されていたサービスのみならず他のサービスをも含む比較的多数のサービスを提供することが可能である。換言すれば、ユーザは、サーバデバイス２０によって提供される比較的多数のサービスを利用することが可能である。

【0093】

また、サーバデバイス２０（オンプレミスサーバとも表現される）は、（クラウドサーバ８０よりも）クライアント９０側に近いネットワーク内位置に存在する（詳細には、サーバデバイス２０とクライアント９０とは同一ＬＡＮ内に存在する）。それ故、サーバデバイス２０（同一ＬＡＮ内に存在する装置）とクライアント９０との通信速度は、クラウドサーバ８０（当該ＬＡＮの外部に存在する装置）とクライアント９０との通信速度よりも大きい（高速である）。仮に全てのサービスが常にクラウドサーバ８０によってクライアント９０に対して提供される場合には、比較的低速な通信速度に起因して反応速度が大きく低下する。これに対して、上記態様によれば、クライアント９０における反応速度の低下を抑制することが可能である。

【0094】

このようなサーバデバイス２０（ＭＦＰ１０）によれば、反応速度の低下を抑制しつつ比較的多数のサービスを利用することが可能である。

【0095】

また、サーバデバイス２０は、サービス処理をクラウドサーバ８０から引き継いで実行する際には、当該サービス処理に関連するサービス関連情報（具体的には、クラウドサーバ８０によるサービス提供中に変更されたデータ（ユーザによる入力情報等）を含む）をクラウドサーバ８０から受信しておき（ステップＳ３８）、当該データをクラウドサーバ８０から引き継いで使用する（ステップＳ４５以後）。したがって、サービスの提供元がクラウドサーバ８０からサーバデバイス２０へと変更された場合に、ユーザによる再度のデータ入力（冗長な重複入力操作等）を要しない。

【0096】

なお、サーバデバイス２０のハードウエアリソースの残存量（余裕量）が少ない場合には、新たに稼働されたサービス（「service_05」等）は、当該サービスの使用終了時点で、直ちに稼働停止されることが好ましい。これによれば、さらに別のサービスをサーバデバイス２０で新たに稼働させることが可能である。したがって、さらに多数のサービスをサーバデバイス２０によって提供することが可能になる。ただし、これに限定されず、新たに稼働されたサービスは、当該サービスの使用が終了しても、（更に別のユーザ等による使用に備えて）引き続き稼働されたままでもよい。その場合には、次述する第２実施形態のように、非稼働中サービスの提供要求が受け付けられた際に、現在稼働中のサービスのうちの少なくとも１つを非稼働状態に遷移させて、新たなサービスを稼働させるためのリソースを確保することが好ましい。

【0097】

また、ここでは、稼働対象サービスを提供するための特定のアプリケーションがクラウドサーバ８０（外部装置）からダウンロードされているが、これに限定されない。たとえば、クラウドサーバ８０以外の外部装置からＭＦＰ１０（サーバデバイス２０）へとダウンロードされてもよい。

【0098】

＜２．第２実施形態＞
第２実施形態は、第１実施形態の変形例である。以下では、第１実施形態との相違点を中心に説明する。

【0099】

上記第１実施形態では、ユーザからの要求時点（ステップＳ１（図６））で未だ稼働していなかったサービスを新たに稼働させるためのリソース（ハードウエアリソース）が、当該要求時点でサーバデバイス２０に残存していることを前提に説明した。換言すれば、新たなサービスを追加するためのリソース（余裕リソース）がサーバデバイス２０に常に存在する場合について説明した。

【0100】

この第２実施形態では、ユーザからの要求時点で当該余裕リソースがサーバデバイス２０に存在しない場合にも良好に対応することが可能な態様について説明する。

【0101】

図１８および図１９は、第２実施形態に係るＭＦＰ１０（サーバデバイス２０）の動作を示すフローチャートである。第２実施形態に係るＭＦＰ１０では、図６の動作に代えて図１８（および図１９）の動作が実行される。なお、図１９は、図１８の動作の一部（ステップＳ２０）の詳細動作を示すフローチャートである。

【0102】

詳細には、第２実施形態では、第１実施形態とは異なり、ステップＳ１１とステップＳ３１との間で、ステップＳ２０（図１８および図１９参照）の動作がさらに実行される。

【0103】

その結果、第２実施形態では、図８の動作に代えて図１７の動作が行われる。図１７は、第２実施形態の動作の一部を示すタイミングチャートである。図８と比較すると判るように、ステップＳ１４の直後にステップＳ２０の処理が実行される（図１７参照）。以下、ステップＳ２０の処理について、図１９等を参照しつつ説明する。

【0104】

第２実施形態においては、稼働対象サービスの即時提供が不可能であるとステップＳ２（図１８）で判定される場合、ステップＳ１１～Ｓ１４の処理（図６、図８および図１０参照）が第１実施形態と同様に行われた後、ステップＳ２０に進む。なお、ステップＳ２０の後は、ステップＳ３１～Ｓ４５の処理（図６（図１８）、図９および図１１参照）が第１実施形態と同様に行われる。

【0105】

ステップＳ２０では、稼働対象サービス（現在未稼働のサービス）と現在稼働中のサービスとを差し替える処理（「差替処理」とも称する）等が行われる。より具体的には、稼働中の複数のサービス（サーバデバイス２０のリソースを使用している複数のサービス）のうちの少なくとも１つのサービスを非稼働状態に遷移させて当該少なくとも１つのサービスの使用リソースを解放し（サーバデバイス２０における空きリソースを拡大し）当該少なくとも１つのサービスと入れ替わりに稼働対象サービスをサーバデバイス２０で稼働させる差替処理等が実行される。端的に言えば、一部の稼働中サービスを削除するとともに当該削除した一部の稼働中サービスと入れ替えて（差し替えて）稼働対象サービスを稼働させる差替処理が実行される。なお、差替処理において非稼働状態（停止状態）に遷移される少なくとも１つのサービス（サーバデバイス２０のメモリ等から削除される少なくとも１つの稼働中サービス）を「停止対象サービス（あるいは削除対象サービス）」とも称する。

【0106】

詳細には、まず、ステップＳ６１において、ＭＦＰ１０（詳細にはサーバデバイス２０のサービス管理部２９ｆ）は、稼働対象サービスの稼働に要するリソース情報（所要リソース情報とも称する）をクラウドサーバ８０から取得する。より詳細には、図１７および図２０に示すように、サーバデバイス２０（サービス管理部２９ｆ）は、クラウドサーバ８０（詳細にはクラウドサーバ８０内のサービス管理部８９ｆ）に対して所要リソース情報の取得要求を送信し、当該サービス管理部８９ｆから所要リソース情報を受信して取得する。

【0107】

たとえば、稼働対象サービスが「service_10」である場合には、クラウドサーバ８０内に格納されているサービスリスト８５０（図２３参照）に基づいて、「service_10」の所要リソース情報（ＣＰＵコア数「２」およびメモリ「１０００」ＭＢ（メガバイト））が取得される。なお、サービスリスト８５０には、クラウドサーバ８０で稼働している各サービスの各種情報（「サービス名」、「所要ＣＰＵコア数」、「所要メモリ容量」、「クラウドサービスのアドレス」）が格納されている。

【0108】

次のステップＳ６２では、サービス管理部２９ｆは、サーバデバイス２０（オンプレミスサーバ）で稼働しているサービスの情報を、サービスリスト２５０（図２２参照）に基づいて取得する。サービスリスト２５０には、サーバデバイス２０で現在稼働している各サービスの各種情報（「コンテナ名」、「サービス名」、「使用ＣＰＵコア数」、「使用メモリ容量」、「クラウドサービス（クラウドサーバ８０によって提供されるサービス）のアドレス」、「オンプレミスサービス（サーバデバイス２０によって提供されるサービス）のアドレス」、「サーバＩＤ」）が格納されている。なお、サーバデバイス２０は２枚のブレードサーバ（「server_01」および「server_02」）を備えて構成されており、実際に各サービスを実行しているブレードサーバのＩＤが「サーバＩＤ」として格納されている。

【0109】

たとえば、図２２のサービスリスト２５０においては、９つのサービスがそれぞれ対応コンテナで稼働していることが示されている。そして、これら９つのサービスで使用されているリソース（使用リソース）の合計量が算出される。ここでは、ブレードサーバごとに使用リソースの合計量が算出される。

【0110】

ブレードサーバ「server_02」では３つのサービス（「service_06」～「service_08」）が稼働しており、当該３つのサービスで使用されているＣＰＵコア数は、「７」（＝３＋２＋２）である。したがって、ブレードサーバ「server_01」での使用ＣＰＵコア数は「７」である。また、図２５に示されるように、ブレードサーバ「server_02」は、「８」個のＣＰＵコアを有している。したがって、空いているＣＰＵコアの数は、「１」個（＝８－７）である。なお、図２５は、サーバデバイスのハードウエアリソースを示す図である。

【0111】

また、ブレードサーバ「server_01」では６つのサービス（「service_01」～「service_05」、および「service_09」）が稼働しており（図２２参照）、当該６つのサービスで使用されているＣＰＵコア数は、「７」（＝１＋２＋１＋１＋１＋１）である。ただし、ブレードサーバ「server_01」では当該６つのサービスに加えてサービス管理用のサービス（およびホストＯＳ）も稼働しているので、サービス管理用のサービス（およびホストＯＳ）の使用ＣＰＵコア数「１」を「７」に加えた「８」が、ブレードサーバ「server_01」での使用ＣＰＵコア数である。また、図２５に示されるように、ブレードサーバ「server_01」は「８」個のＣＰＵコアを有している。したがって、空いているＣＰＵコアの数は「０」個（＝８－８）であり、ブレードサーバ「server_01」には、空いているＣＰＵコアが存在しない。

【0112】

ステップＳ６３では、サーバデバイス２０の現在の空きリソース量が稼働対象サービスの所要リソース量以上であるか否かが判定される。具体的には、ブレードサーバごとの空きリソース量と稼働対象サービスの所要リソース量とが比較される。ここでは、「リソース」として、ＣＰＵコア数が考慮される。ただし、これに限定されず、ＣＰＵコア数に加えて（あるいはＣＰＵコア数に代えて）所要メモリ量等が考慮されてもよい。

【0113】

サーバデバイス２０の空きリソース量が稼働対象サービスの所要リソース量以上である場合には、ステップＳ６３からステップＳ３１（図６）に進み、第１実施形態と同様の動作が実行される。

【0114】

たとえば、図２１に示すように、サーバデバイス２０にて８つのサービス（「service_01」～「service_08」）の稼働中に、サービス「service_09」が稼働対象サービスとして稼働されようとしている場合には、サーバデバイス２０にて空いているＣＰＵコアの数は「２」個（各ブレードサーバ「server_01」，「server_02」にて１個ずつ）であり、稼働対象サービス「service_09」の所要ＣＰＵコア数は「１」個である。その場合、サーバデバイス２０の空きリソース量が稼働対象サービスの所要リソース量以上であると判定され、（次述するステップＳ６４には進まず）ステップＳ３１に進む。そして、ステップＳ３１以降の処理が実行されることによって、稼働対象サービス「service_09」がサーバデバイス２０（たとえば、ブレードサーバ「server_01」）によって稼働され、サーバデバイス２０による稼働対象サービス「service_09」の提供が開始される。

【0115】

一方、サーバデバイス２０の空きリソース量が稼働対象サービスの所要リソース量未満である場合には、ステップＳ６３からステップＳ６４に進む。たとえば、所望の稼働対象サービス「service_10」の所要ＣＰＵコア数「２」が空きリソース（ここでは空きＣＰＵコア数）の合計「１」よりも大きい場合（図２２参照）、サーバデバイス２０の空きリソース量が稼働対象サービスの所要リソース量未満であると判定され、ステップＳ６４に進む。

【0116】

ステップＳ６４において、サービス管理部２９ｆは、現時点でサーバデバイス２０にて稼働している各サービス（稼働中サービスとも称する）の所要リソース量を確認する。

【0117】

さらに、サービス管理部２９ｆは、各稼働中サービスのユーザの利用状況（使用状況）を確認し（ステップＳ６５）、「稼働中サービスのうち何れのユーザによっても現在使用されていないサービス」（非使用中サービス（あるいは非利用中サービス）とも称する）が存在するか否かを判定する（ステップＳ６６）。

【0118】

非使用中サービスが存在しないと判定される場合、ステップＳ６８に進み、サービスの差替処理の開始を保留する。次のステップＳ６９の分岐処理では、稼働対象サービスの利用が未だ終了していないときには、ステップＳ６５に戻る。一方、稼働対象サービスの利用が終了すると、本処理を終了する。このように、稼働対象サービスの利用が未だ終了していないことを条件として、何れかの非使用中サービスが発生するまで、ステップＳ６５，Ｓ６６，Ｓ６８の処理が繰り返される。換言すれば、サーバデバイス２０にて現在稼働中のサービスの中に、非使用中サービスが存在しない場合には、差替処理（ステップＳ７２，Ｓ３１～Ｓ３４等）が保留される。

【0119】

一方、非使用中サービスが存在すると判定される場合、ステップＳ６７に進む。

【0120】

ステップＳ６７では、非使用中サービスの合計リソースが、稼働対象サービスの所要リソース以上であるか否かが判定される。

【0121】

非使用中サービスの合計リソースが稼働対象サービスの所要リソース未満である場合、ステップＳ６８に進む。この場合にも、差替処理（ステップＳ７２，Ｓ３１～Ｓ３４等）が保留される。

【0122】

一方、非使用中サービスの合計リソースが稼働対象サービスの所要リソース以上である場合、サーバデバイス２０は、稼働中サービスの中から（詳細には、非使用中サービスの中から）、差替処理における「停止対象サービス（削除対象サービス）」を決定する（ステップＳ７２）。より詳細には、サーバデバイス２０は、サービスの利用履歴を取得（ステップＳ７１）し、当該利用履歴に基づいて、差替処理における停止対象サービス（非稼働状態に遷移させて停止させるべきサービス）を決定する（ステップＳ７２）。なお、非使用中サービスが１つのみである場合には、当該１つの非使用中サービスが停止対象サービスとして決定される。また、複数の非使用中サービスが存在する場合には、当該利用履歴に基づいて差替処理における停止対象サービスが決定される。

【0123】

ここでは、ＭＦＰ１０（サーバデバイス２０）にて現在稼働中且つ非使用中のサービスの中から、最終使用時点を示す情報に基づいて「停止対象サービス」が決定される。より詳細には、ＭＦＰ１０にて現在稼働中且つ非使用中のサービスのうち、最終使用時点（最終利用時刻）が最も古いサービスが「停止対象サービス」として決定される。たとえば、現在稼働中のサービスのうち、最終使用時点が「５分前」の非使用中サービスと最終使用時点が「１週間前」の非使用中サービスとが存在する場合、最終使用時点が「１週間前」のサービスが停止対象サービスとして決定される。このように、使用されていない期間が最も長いサービスが停止対象サービスとして決定される。

【0124】

たとえば、図２２においてサービス「service_02」を含む複数のサービスが非使用中サービスである場合、当該非使用中サービスの合計リソース（ＣＰＵコア数「２」以上）は、稼働対象サービスの所要リソース（ＣＰＵコア数「１」）以上であるので、ステップＳ６７からステップＳ７１，Ｓ７２に進む。そして、サービス「service_02」が、稼働中且つ非使用中の複数のサービスのうちその最終使用時点（最終利用時刻）が最も古いサービスである場合、当該サービス「service_02」が「停止対象サービス」として決定される。

【0125】

ただし、これに限定されず、ＭＦＰ１０にて現在稼働中且つ非使用中のサービスの中から、最終使用時点からの経過期間が所定の期間より長いサービスが抽出され、抽出された１又は複数のサービスの中から、「停止対象サービス」が選択（決定）されてもよい。複数のサービスが抽出される場合は、その中で最終使用時点が最も古いサービスが「停止対象サービス」として選択されるようにしてもよいし、当該複数のサービスの中から「停止対象サービス」をユーザに選択させるようにしてもよい。

【0126】

あるいは、ＭＦＰ１０（サーバデバイス２０）にて現在稼働中且つ非使用中のサービスの中から、過去の所定期間中における使用回数を示す情報に基づいて「停止対象サービス」が決定されてもよい。より詳細には、ＭＦＰ１０にて現在稼働中且つ非使用中のサービスのうち、過去の所定期間中における使用回数が最も少ないサービス（使用頻度が最も小さいサービス）が停止対象サービスとして決定されてもよい。たとえば、現在稼働中のサービスのうち、過去３ヶ月における使用回数が「１００回」の非使用中サービスと過去３ヶ月における使用回数が「５回」の非使用中サービスとが存在する場合、過去３ヶ月における使用回数が「５回」のサービスが停止対象サービスとして決定される。このように、使用頻度が最も小さいサービスが停止対象サービスとして決定されてもよい。あるいは、過去の所定期間中における使用回数が所定回数より少ないサービスが抽出され、その中から「停止対象サービス」が選択されてもよい。複数のサービスが抽出される場合は、その中で使用回数が最も少ないサービスが「停止対象サービス」として選択されるようにしてもよいし、当該複数のサービスの中から「停止対象サービス」をユーザに選択させるようにしてもよい。

【0127】

あるいは、ＭＦＰ１０（サーバデバイス２０）にて現在稼働中且つ非使用中のサービスの中から、過去の所定期間中における使用ユーザ数を示す情報に基づいて「停止対象サービス」が決定されてもよい。より詳細には、ＭＦＰ１０にて現在稼働中且つ非使用中のサービスのうち、過去の所定期間中における使用ユーザ数が最も少ないサービス（過去の所定期間にそのサービスを使用したことがあるユーザの数が最も少ないサービス）が停止対象サービスとして決定されてもよい。たとえば、現在稼働中のサービスのうち、過去３ヶ月における使用ユーザ数が「５人」の非使用中サービスと過去３ヶ月における使用ユーザ数が「１人」の非使用中サービスとが存在する場合、過去３ヶ月における使用ユーザ数が「１人」の非使用中サービスが停止対象サービスとして決定される。このように、過去の使用ユーザ数が最も少ないサービスが停止対象サービスとして決定されてもよい。あるいは、過去の所定期間中における使用ユーザ数が所定数より少ないサービスが抽出され、その中から「停止対象サービス」が選択されてもよい。複数のサービスが抽出される場合は、その中で使用ユーザ数が最も少ないサービスが「停止対象サービス」として選択されるようにしてもよいし、当該複数のサービスの中から「停止対象サービス」をユーザに選択させるようにしてもよい。なお、過去の所定期間は、過去の全期間であってもよい。

【0128】

このような処理によって、少なくとも１つのサービス（たとえば、１つのサービス「service_02」）が停止対象サービスとして決定される。より詳細には、その使用リソース（占有リソース）の合計が稼働対象サービスの提供に要するリソースよりも多い少なくとも１つのサービスが、停止対象サービスとして稼働中サービスの中から（より詳細には、非使用中サービスの中から）決定される。

【0129】

なお、ここでは、非使用中サービスの中から停止対象サービスが決定されているが、これに限定されず、使用中サービスを含む複数の稼働中サービスの中から、停止対象サービスが決定されてもよい。

【0130】

その後、サーバデバイス２０は、停止対象サービスとして決定されたサービスを、稼働状態から非稼働状態に遷移させ停止させる（ステップＳ７２）。端的に言えば、当該停止対象サービス（削除対象サービス）がサーバデバイス２０から削除される。

【0131】

そして、ステップＳ３１以後の動作（図１８、図９および図１１参照）が、第１実施形態と同様に実行される。これによれば、サーバデバイス２０による稼働対象サービス「service_10」の提供が開始される。図２４のサービスリスト２５０においては、サーバデバイス２０において停止対象サービス「service_02」が停止される（ステップＳ７２）とともに、（サービス「service_02」の停止と引き換えに）サーバデバイス２０において稼働対象サービス「service_10」の稼働が開始（ステップＳ４４）された様子が示されている。

【0132】

以上のようにして、差替処理を伴いつつサーバデバイス２０による稼働対象サービスの提供動作が実行される。このような差替処理を伴うことによれば、ユーザからの要求時点で余裕リソースがサーバデバイス２０に存在しない場合にも、サーバデバイス２０のリソースを有効に活用して、良好に対応することが可能である。具体的には、サーバデバイス２０において停止対象サービスと引き換えに稼働対象サービスを稼働させることが可能である。

【0133】

また、稼働中サービスのうち非使用中サービスが停止対象サービスとして決定されるので、他のサービスへの影響を抑制して停止対象サービスを稼働させることが可能である。

【0134】

さらに、非使用中サービスのうち、長期間不使用のサービス、使用頻度が低いサービス、あるいは、過去の使用ユーザ数が少ないサービス等が、停止対象サービスとして決定されるので、他のサービスへの影響をより適切に抑制して停止対象サービスを稼働させることが可能である。

【0135】

また、上記動作（特にステップＳ６６，Ｓ６７～Ｓ７２等）においては、使用されていないサービス（非使用中サービス）が存在しないことに基づき差替処理を保留することが一旦決定（ステップＳ６６）された時点の後において、当該時点で使用されていた１以上のサービスが当該時点の後に使用されなくなった場合（使用中サービスの使用が終了した場合）、これに応答して、ステップＳ６６からステップＳ６７に進む。この場合、非使用中サービスの合計リソースが稼働対象サービスの所要リソース以上であることをも条件として、差替処理（ステップＳ７２，Ｓ３１～Ｓ３４等）の保留が解除され当該差替処理が開始される（ステップＳ６７，Ｓ７１，Ｓ７２）。これによれば、サーバデバイス２０での使用状況の経時変化をも考慮して、より適切に差替処理を実行することが可能である。

【0136】

また、上記ステップＳ７２においては、サーバデバイス２０は、稼働状態から非稼働状態（稼働停止状態）へと移行される停止対象サービスに関するデータであって、非稼働状態への遷移前の稼働期間において変更されていたデータを、クラウドサーバ８０にアップロードしてクラウドサーバ８０にて管理させることが好ましい。停止対象サービスがサービス提供装置１０にて実行されていた際に変更された当該データ（遷移前の稼働期間において変更されていたデータ）としては、たとえば、課金情報、ユーザによる入力情報、ユーザの使用履歴情報等が例示される。

【0137】

これによれば、ローカル側（サーバデバイス２０）で変更されていたデータがクラウド側（クラウドサーバ８０）に適切に反映されるので、停止対象サービスがクラウドサーバ８０にて再び実行される際にクラウドサーバ８０とサービス提供装置１０との間でのデータ不整合を回避することが可能である。

【0138】

＜３．変形例等＞
以上、この発明の実施の形態について説明したが、この発明は上記説明した内容のものに限定されるものではない。

【0139】

＜並行ダウンロード処理＞
たとえば、上記第２実施形態においては、サーバデバイス２０にて現在使用されていないサービスが存在しない場合（ステップＳ６６（図１９）でＹＥＳ）には、使用されていないサービスが発生するまで差し替え処理は保留され（ステップＳ６８）、停止対象サービスが決定できない態様が例示されているが、これに限定されない。

【0140】

具体的には、サーバデバイス２０にて現在使用されていないサービスが存在しないために停止対象サービスが決定できない場合、サーバデバイス２０は、（ステップＳ６８等にて）稼働対象サービスの稼働用アプリケーションのダウンロードを開始して稼働対象サービスの稼働開始のための準備を進行させておくようにしてもよい。そして、サーバデバイス２０は、サーバデバイス２０における使用終了サービスの発生に伴って当該使用終了サービスを停止対象サービスとして決定し、当該停止対象サービスの稼働停止と引き換えに、稼働対象サービスの稼働用アプリケーションを利用して稼働対象サービスの稼働を開始するようにしてもよい。より具体的には、当該停止対象サービスの稼働停止時点で稼働用アプリケーションのダウンロードが既に完了している場合には、当該ダウンロード済みの稼働用アプリケーションのインストールおよび起動が行われればよい。あるいは、当該停止対象サービスの稼働停止時点で稼働用アプリケーションのダウンロードが未だ完了していない場合には、当該ダウンロードが継続され、当該ダウンロード完了直後に稼働用アプリケーションのインストールおよび起動が行われればよい。さらに、その後に、ステップＳ３７，Ｓ３８の処理（稼働対象サービスの切換要求および稼働対象サービスに関するサービス関連情報の受信動作等）が実行されればよい。

【0141】

このような動作によれば、アプリケーションのダウンロード処理が停止対象サービスの決定時点（ステップＳ７２）よりも前に予め進行するので、ステップＳ３１から当該ダウンロード処理が開始される態様よりも当該ダウンロード処理を早期に終了させること、ひいては、稼働対象サービスをクラウドサーバ８０からサーバデバイス２０へと早期に引き継ぐことが可能である。

【0142】

＜停止対象サービス＞
また、上記各実施形態においては、ＭＦＰ１０内のサーバデバイス２０にて稼働されている全てのサービスが停止対象サービス（削除対象サービス）になり得る態様が示されているが、これに限定されない。たとえば、所定の除外対象サービス（予め指定された除外対象サービス）を除いたサービスの中から、停止対象サービスが決定されてもよい。当該所定の除外対象サービスとしては、（クラウドサーバ８０側ではなく）サーバデバイス２０内にて常に動作させておくことが好ましいサービスが例示される。たとえば、ＭＦＰ１０内の画像形成デバイス３０の基本動作サービス（詳細には、プリントサービス、スキャンサービス、コピーサービス、ファクシミリサービス等）が例示される。また、サーバデバイス２０にて常駐させるべきメールサービス等も例示される。当該除外対象サービス以外のサービスの中から停止対象サービスが決定されることによれば、当該除外対象サービスのサーバデバイス２０における稼働状態が適切に継続され得る。

【0143】

＜ユーザデータの引き継ぎ＞
また、上記各実施形態においては、サーバデバイス２０は、サービス処理をクラウドサーバ８０から引き継いで実行することを決定すると、ステップＳ３８（図６および図９参照）においてサービス関連情報を受信し、当該サービス関連情報をも引き継いでサービス処理を実行している。当該サービス関連情報は、複数のユーザの全てに関するデータを含んでいてもよいが、これに限定されず、当該複数のユーザの一部に関するデータのみであってもよい。

【0144】

たとえば、サーバデバイス２０は、ステップＳ３８において、稼働対象サービス（引継対象のサービス）の現在の使用中ユーザを特定するとともに、当該稼働対象サービスの複数のユーザ（Ｕ１，Ｕ２，Ｕ３等）に関するデータのうち、当該使用中ユーザ（Ｕ１，Ｕ２）に関するデータのみをダウンロードしてもよい。

【0145】

また、当該稼働対象サービスの当該使用中ユーザに関するデータのダウンロードが完了した後（より好ましくは、ステップＳ４４の後）、サーバデバイス２０は、当該使用中ユーザ以外のユーザ（Ｕ３等）に関するデータのダウンロードを開始（実行）してもよい。このように、使用中ユーザ（Ｕ１，Ｕ２）のデータがそれ以外のユーザ（Ｕ３等）のデータよりも優先的にダウンロードされてもよい。

【0146】

あるいは、サーバデバイス２０は、ステップＳ３８で当該使用中ユーザ（第１の使用対象ユーザとも称する）（Ｕ１，Ｕ２）に関するデータをダウンロードした後、当該第１の使用対象ユーザとは別の第２の使用対象ユーザ（Ｕ５等）からの同じ稼働対象サービスの提供要求を受け付けたことに応答して、当第２の使用対象ユーザ（Ｕ５等）に関するデータをダウンロードするようにしてもよい。

【0147】

＜ダウンロード対象データの種類等＞
上述のように上記各実施形態においては、サーバデバイス２０は、サービス処理をクラウドサーバ８０から引き継いで実行することを決定すると、ステップＳ３８（図６および図９参照）においてサービス関連情報を受信し、当該サービス関連情報をも引き継いでサービス処理を実行している。

【0148】

当該サービス関連情報は、全ての種類のデータを含んでいてもよいが、これに限定されず、当該一部の種類のデータのみであってもよい。換言すれば、ローカル側（サーバデバイス２０）で管理される情報は、一部の種類の情報であってもよい。

【0149】

ローカル側（サーバデバイス２０側）で管理される情報（データ）としては、たとえば、ログイン情報に関連付けられた情報（ログインユーザごとの印刷設定情報、およびログインユーザごとのファイル保存先のパス情報等）が例示される。また、画面操作に関するサムネイル画像情報（たとえば、特定フォルダ内のサムネイル画像情報）、およびポーリングモニタリング処理におけるステータス情報（プリント受付、画像変換中、印刷実行中、エラー発生、正常終了）等も例示される。これらの情報は、頻繁にアクセスが発生する情報（および／または画面表示などでユーザの目に触れやすい情報）であるなどの特性を有しており、そのデータ通信に伴う反応速度の低下を抑制するためには、ローカル側（オンプレミス側）で管理されることが好ましい。

【0150】

一方、一連の処理の整合性が所定レベル以上に要求される情報（一連の処理の不整合が回避されるべき情報）等は、複数のローカル側サーバ（複数のサーバデバイス２０等）で管理されるよりも、クラウドサーバ８０にて一括管理されることが好ましい。たとえば、トランザクション処理（入出金処理（入金処理および出金処理）などの一体不可分の処理群）に関するデータ（トランザクションデータ）は、サーバデバイス２０側で管理されるのではなく、クラウドサーバ８０で管理されることが好ましい。たとえば、これらの情報（トランザクション処理に関するデータ等）は、ステップＳ３８でのダウンロードの対象から除外され、クラウドサーバ８０で管理すればよい。具体的には、ステップＳ４５以後の通信において当該情報の変更要求がサーバデバイス２０からクラウドサーバ８０に対して逐次送信され、当該変更要求に応じてクラウドサーバ８０内での管理情報が逐次更新（変更）されればよい。

【0151】

このように、サーバデバイス２０は、稼働対象サービスに関するデータのうち一部の特定データ（トランザクションデータ等）をダウンロードせず（管理せず）、クラウドサーバ８０が当該一部の特定データを管理するようにしてもよい。

【0152】

＜アップロードタイミング＞
上記各実施形態においては、サーバデバイス２０によるサービス提供期間中に変更されたデータは、サーバデバイス２０にて稼働停止される際に、サーバデバイス２０からクラウドサーバ８０へとアップロードされている（ステップＳ７２）が、これに限定されない。

【0153】

たとえば、サーバデバイス２０は、サーバデバイス２０によって提供される稼働対象サービスのサービス提供期間中に変更されるデータを、稼働対象サービスの稼働期間中（ステップＳ１よりも前の稼働期間中、およびステップＳ４５以後の稼働期間中等）において逐次に（変更されるごとに）クラウドサーバ８０に転送して格納させる（管理させる）ようにしてもよい。

【0154】

あるいは、サーバデバイス２０は、サーバデバイス２０によって提供される稼働対象サービスのサービス提供期間中に変更されるデータを、稼働対象サービスの各ユーザによる使用が終了した時点（詳細には、各ユーザがユーザ操作に応じてログアウトした時点、および／または各ユーザの一定の無操作期間の経過に基づく強制ログアウト時点（セッションタイムアウト時点）等）で一括してクラウドサーバ８０に転送して格納させる（管理させる）ようにしてもよい。

【0155】

＜その他＞
また、上記各実施形態等においては、ＣＰＵに関するリソースがＣＰＵコア数で表現されているが、これに限定されず、ＣＰＵに関するリソースがＣＰＵの使用率（％）等で表現されてもよい。

【0156】

また、上記各実施形態では、クライアント９０として、いわゆるパーソナルコンピュータ等が例示されているが、これに限定されない。たとえば、クライアント９０は、上記ＭＦＰ１０とは別のＭＦＰなどであってもよい。当該別のＭＦＰは、サーバデバイス２０を有しない従来のＭＦＰ等であってもよい。

【符号の説明】

【0157】

１ サービス提供システム
１０ ＭＦＰ（サービス提供装置）
２０ サーバデバイス
３０ 画像形成デバイス
８０ クラウドサーバ
９０ クライアント
２５０ （サーバデバイス２０における）サービスリスト
８５０ （クラウドサーバ８０における）サービスリスト

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】

【図25】