(57)【要約】      （修正有）【課題】クラウド配信サービスの配信先の事情に応じて柔軟に配信先を切り替えることができる配信切替え装置を提供する。【解決手段】配信切替え装置１１０は、ＭＦＰ−２Ｆ、ＭＦＰ−３ＦとＬＡＮ接続されており、クラウドサーバー１３０がクラウド配信したニュースをＭＦＰ−２Ｆ、ＭＦＰ−３Ｆの何れかに配信する。配信切替え部２０１は、配信先管理ＤＢ２００を参照して次の切替え時刻と配信先とを取得し、次の切替え時刻をタイマー２０４にセットする。タイマー２０４のタイムアウトによって次の切替え時刻になったことが分かると、配信切替え部２０１は、次の配信先をニュース配信部２０２に指示する。そして、配信切替え部２０１は、再度、配信先管理ＤＢ２００を参照して、次の切替え時刻と配信先とを取得する。ニュース配信部２０２は、指示された配信先を記憶して、以降のニュースを当該配信先に配信する。【選択図】図２
2016115184.tif 000002
【特許請求の範囲】
【請求項１】
クラウドサーバーから１の配信先を指定してクラウド配信された配信データを印刷出力する画像形成装置を、複数の画像形成装置のうちの何れかに切り替える配信切替え装置であって、
前記複数の画像形成装置の何れに印刷出力させるかを決定する決定手段を備え、
前記クラウドサーバーにはＷＡＮを経由して、前記複数の画像形成装置にはＬＡＮのみを経由して接続されている
ことを特徴とする配信切替え装置。
【請求項２】
時間帯毎に印刷出力すべき画像形成装置の指定を記憶する記憶手段を備え、
前記決定手段は、前記記憶手段が記憶する前記指定に従って、印刷出力すべき画像形成装置を決定する
ことを特徴とする請求項１に記載の配信切替え装置。
【請求項３】
前記配信データがクラウド配信された時間帯に指定されている画像形成装置が、当該配信データを印刷出力できるか否かを判定する出力可否判定手段と、
印刷出力できないと判定された場合には、当該画像形成装置への当該配信データの転送を禁止する禁止手段と、を備える
ことを特徴とする請求項２に記載の配信切替え装置。
【請求項４】
前記出力可否判定手段によって印刷出力できないと判定された場合に、前記配信データがクラウド配信された時間帯に指定されている画像形成装置以外の画像形成装置であって、当該配信データの印刷出力を代行できる画像形成装置があるか否かを判定する代行判定手段を備え、
前記代行判定手段の判定が肯定的である場合には、前記決定手段は、前記印刷出力を代行できる画像形成装置を、前記配信データを印刷出力する画像形成装置に決定する
ことを特徴とする請求項３に記載の配信切替え装置。
【請求項５】
前記配信データがクラウド配信された時間帯に配信先に指定されている画像形成装置が印刷出力できない旨の通知を、前記印刷出力を代行できる画像形成装置に、印刷出力させる通知手段を備える
ことを特徴とする請求項４に記載の配信切替え装置。
【請求項６】
前記印刷出力を代行できる画像形成装置がない場合には、クラウドサーバーにエラーレポートを返信する
ことを特徴とする請求項４に記載の配信切替え装置。
【請求項７】
前記出力可否判定手段の判定が否定的である旨の通知を、当該配信切替え装置の管理者に報知する報知手段を備える
ことを特徴とする請求項３に記載の配信切替え装置。
【請求項８】
前記出力可否判定手段は、前記配信データがクラウド配信された時間帯に指定されている画像形成装置と相互通信可能でないときに印刷出力できないと判定する
ことを特徴とする請求項３に記載の配信切替え装置。
【請求項９】
前記配信データがクラウド配信された時間帯に指定されている画像形成装置の状態情報を取得する状態情報取得手段を備え、
前記出力可否判定手段は、前記状態情報によって印刷出力の可否を判定する
ことを特徴とする請求項３に記載の配信切替え装置。
【請求項１０】
前記状態情報取得手段は、前記画像形成装置にテストプリントを要求し、当該要求に対して返信されたジョブステータスによって当該状態情報を取得する
ことを特徴とする請求項９に記載の配信切替え装置。
【請求項１１】
前記記憶手段は、時間帯毎の印刷出力すべき画像形成装置の指定をテーブルにて記憶する
ことを特徴とする請求項２に記載の配信切替え装置。
【請求項１２】
前記画像形成装置毎の稼働率を取得する稼働率取得手段を備え、
前記決定手段は、前記稼働率が最も高い画像形成装置に印刷出力させると決定する
ことを特徴とする請求項１に記載の配信切替え装置。
【請求項１３】
前記稼働率取得手段は、所定のユーザーが当該画像形成装置を最後に利用した時期が遅いほど前記稼働率が高くなるようにする
ことを特徴とする請求項１２に記載の配信切替え装置。
【請求項１４】
前記稼働率取得手段は、前記画像形成装置毎の実行ジョブ数を前記稼働率として定期的に取得し、
ことを特徴とする請求項１２に記載の配信切替え装置。
【請求項１５】
前記稼働率取得手段は、当該画像形成装置と同じネットワークセグメントに属する端末装置であって、前記配信データがクラウド配信されたときに起動されている端末装置の数を前記稼働率とする
ことを特徴とする請求項１２に記載の配信切替え装置。
【請求項１６】
前記配信データのクラウド配信に先立って、転送先となる画像形成装置との接続要求をクラウド側から受け付ける受付手段と、
前記接続要求の正当性を確認する確認手段と、
前記接続要求の正当性が確認された場合には、前記クラウド側から前記画像形成装置へ前記配信データを配信するための通信経路を確立する確立手段と、を備える
ことを特徴とする請求項１から１５の何れかに記載の配信切替え装置。
【請求項１７】
前記接続要求に係る接続先を予め記憶する接続先記憶手段と、
前記確認手段は、前記接続要求に係る接続先の指定が、前記接続先記憶手段が記憶している接続先と一致するか否かによって正当性を確認する
ことを特徴とする請求項１６に記載の配信切替え装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、配信切替え装置に関し、特に、クラウドサーバーから配信サービスを受ける配信先でクラウド配信サービスの受信装置を切り替える技術に関する。
【背景技術】
【０００２】
近年、クラウドサービスを活用したニュースの一斉配信が行われるようになっており、キー局からクラウド配信されたニュースは、配信先のローカル局に設置された複合機（MFP: Multi-Function Peripheral）を用いて受信され、印刷出力される。
受信装置たる複合機の運用方法はローカル局によってまちまちであるが、１台の複合機のみでニュースを受信し続けることは少なく、保守管理等を目的として複合機を切り替える場合もあれば、昼夜の勤務形態の違いに応じて、異なるフロアに設置された複合機を定期的に切り替えてニュースを受信する場合もある。
【０００３】
このようなニーズに対して、例えば、文書データの配信先となる複合機から配信元の情報処理装置に対して受信可能な時間帯を設定することによって、文書データの配信を制御する技術が提案されている（例えば、特許文献１を参照）。この提案によれば、複数の複合機のそれぞれについて互いに異なる受信可能時間帯を設定することができるので、配信先の複合機を切り替えることができる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１３−０２１５３２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、クラウド配信サービスにおいては、配信側の複合機からクラウドサーバーの配信動作を制御するのは、クラウドシステムの管理上望ましくないが、さりとてクラウドシステムの管理者が配信先毎に固有の事情を斟酌してクラウドサーバーの配信動作を設定するのは、特に配信先が多数に上る場合には管理者の手間が煩瑣となり、誤設定が発生する恐れもある。
【０００６】
本発明は、上述のような問題に鑑みて為されたものであって、クラウド配信サービスの配信先の事情に応じて柔軟に受信装置を切り替えることができる配信切替え装置を提供することを目的とする。
【課題を解決するための手段】
【０００７】
上記目的を達成するため、本発明に係る配信切替え装置は、クラウドサーバーから１の配信先を指定してクラウド配信された配信データを印刷出力する画像形成装置を、複数の画像形成装置のうちの何れかに切り替える配信切替え装置であって、前記複数の画像形成装置の何れに印刷出力させるかを決定する決定手段を備え、前記クラウドサーバーには広域通信網（WAN: wide area network）を経由して、前記複数の画像形成装置には構内通信網（LAN: Local Area Network）のみを経由して接続されていることを特徴とする。
【発明の効果】
【０００８】
このようにすれば、クラウドサーバーが１の配信先を指定してクラウド配信した配信データを印刷出力する画像形成装置に配線切替え装置がＬＡＮ接続されており、従って、配信切替え装置がクラウド配信サービスの配信先に設置されているので、当該配信先の事情に応じて柔軟に配信先を切り替えることができる。
【図面の簡単な説明】
【０００９】
【図１】クラウド配信システムの概略構成を示す図である。
【図２】配信切替え装置１１０の機能構成を示すブロック図である。
【図３】配信先管理ＤＢが記憶する切替え条件を例示する表である。
【図４】配信切替え装置１１０の動作を示すフローチャートである。
【図５】配信切替え装置１１０の機能構成を示すブロック図である。
【図６】配信切替え装置１１０の動作を示すフローチャートである。
【図７】配信先診断処理（Ｓ６０２、Ｓ６０５）を例示するフローチャートである。
【図８】配信切替え装置１１０の機能構成を示すブロック図である。
【図９】配信切替え装置１１０の動作を示すフローチャートである。
【図１０】配信切替え装置１１０の動作を示すフローチャートである。
【発明を実施するための形態】
【００１０】
以下、本発明に係る配信切替え装置の実施の形態について、クラウド配信システムを例にとり、図面を参照しながら説明する。
［１］第１の実施の形態
まず、本発明の第１の実施の形態について説明する。
（１−１）クラウド配信システムの構成
まず、本実施の形態に係るクラウド配信システムの概略構成について説明する。
【００１１】
図１に示されるように、クラウド配信システム１はインターネット１４０を介してキー局１５０、ローカル局１００、１６０及びクラウドサーバー１３０を接続した構成となっており、クラウドサーバー１３０によってキー局１５０からローカル局１００、１６０へニュースが配信される。特に、ローカル局１００においては、配信切替え装置１１０を介してＬＡＮ１２０がインターネット１４０に接続されており、ＬＡＮ１２０にはＭＦＰ−２Ｆ並びにＭＦＰ−３Ｆが接続されている。本実施の形態においては、ＭＦＰ−２Ｆ並びにＭＦＰ−３Ｆはそれぞれローカル局１００の別のフロア（２階と３階）に設置されている。
【００１２】
（１−２）配信切替え装置１１０
次に、配信切替え装置１１０について説明する。
図２に示されるように、配信切替え装置１１０は、クラウドサーバー１３０がインターネット１４０を介して配信したニュースをニュース受信部２０５にて受信すると、当該ニュースをニュース配信部２０２にてＭＦＰ−２ＦとＭＦＰ−３Ｆとの何れかへ配信する。
【００１３】
配信先管理ＤＢ（DataBase）２００は、ニュースの配信先を切り替える条件を記憶している。配信先管理ＤＢ２００は、例えば、図３に示されるように、１週間分の切替え条件を記憶する。図３の配信先管理ＤＢ２００においては、曜日欄に１週間分の曜日が指定されており、切替え時刻欄には曜日ごとに配信先を切り替える時刻が指定されている。また、配信先欄には切り替え後の配信先が指定される。
【００１４】
図３の例では、日曜日と土曜日は配信先の切替えは行われない。また、平日（月曜日から金曜日）においては、朝９時に送信先がＭＦＰ−２Ｆに切り替えられた後、夕方５時（１７時）まではＭＦＰ−２Ｆにニュースが配信される。そして、夕方５時に配信先がＭＦＰ−３Ｆに切り替えられると、翌朝９時までＭＦＰ−３Ｆがニュースを受信する。
図４に示されるように、配信切替え部２０１は、まず、配信先管理ＤＢ２００を参照して次の切替え時刻と配信先とを取得し（Ｓ４０１）、次の切替え時刻をタイマー２０４にセットする（Ｓ４０２）。タイマー２０４のタイムアウトによって次の切替え時刻になったことが分かると（Ｓ４０３）、配信切替え部２０１は、次の配信先をニュース配信部２０２に指示する（Ｓ４０４）。
【００１５】
そして、配信切替え部２０１は、再度、配信先管理ＤＢ２００を参照して（Ｓ４０１）、次の切替え時刻と配信先とを取得する。ニュース配信部２０２は、指示された配信先を記憶して、以降のニュースを当該配信先に配信する。以上のような処理を繰り返すことによって、ニュースの配信先が切り替えられる。
配信切替え装置１１０は、更に、ユーザーインタフェース（UI: User Interface）２０３を備えている。ユーザーインタフェース２０３は、配信切替え装置１１０の管理者が配信先管理ＤＢを設定したり、設定内容を確認したりするために用いられる。従って、ローカル局１００においては、クラウドサーバー１３０の管理者の手を煩わせることなく、独自に配信先の切替え設定を行うことができる。従って、クラウド配信サービスの配信先であるローカル局の都合に応じて柔軟に配信先を切り替えることができる。
【００１６】
［２］第２の実施の形態
次に、本発明の第２の実施の形態について説明する。
第２の実施の形態に係る配信切替え装置は、上記第１の実施の形態に係る配信切替え装置１１０と同様の構成を備えるだけでなく、更に、配信先の動作状態を確認して配信先を切り替える点を特徴としている。以下、この特徴点に着目して説明する。なお、先行する実施の形態において、対応する要素がある場合には同じ符号を付した。
【００１７】
本実施の形態に係る配信切替え装置１１０のニュース配信部２０２は、図５に示されるように、ユーザーインタフェース２０３及びタイマー２０４と連携して動作する。
具体的には、図６に示されるように、ニュース受信部２０５からニュースを受け付けると（Ｓ６０１）、当該ニュースを配信するのに先立って、配信先が正常か否かを診断する配信先診断処理を実行する（Ｓ６０２）。配信先診断処理の結果、当該配信先が正常であると判断された場合には（Ｓ６０３：ＹＥＳ）、ニュース配信部２０２は当該配信先にニュースを配信する（Ｓ６０７）。
【００１８】
配信先が正常でないと判断された場合には（Ｓ６０３：ＮＯ）、配信先を切り替え（Ｓ６０４）、切り替え後の配信先について配信先診断処理を実行する（Ｓ６０５）。その結果、切り替え後の配信先が正常であると判断された場合には（Ｓ６０６：ＹＥＳ）、ニュース配信部２０２は切り替え後の配信先にニュースを配信する（Ｓ６０７）。
このようにすれば、切り替え後の配信先が、切り替え前の配信先に代わって、ニュースの印刷出力を代行する。なお、この場合において、切り替え前の配信先がニュースを印刷出力できない旨のエラーレポートを配信先切替え装置１１０が作成して、当該エラーレポートを切り替え後の配信先に印刷出力させてもよい。
【００１９】
切替え後の配信先も正常でないと判断された場合には（Ｓ６０６：ＮＯ）、ニュース配信部２０２はユーザーインタフェース２０３を介して異常を報知する（Ｓ６０８）。配信切替え装置１１０の管理者に異常を報知するためには警告音を発したり、警告ランプを点滅させたりすればよい。また、配信切替え装置１１０は、クラウドサーバー１３０に印刷出力可能な配信先が無い旨のエラーレポートを返信してもよい。
【００２０】
なお、上記第１の実施の形態と同様に、ニュース配信部２０２は、配信切替え部２０１から配信先の指示を受けると（Ｓ６１０：ＹＥＳ）、当該配信先を記憶する（Ｓ６１１）。したがって、配信先に異常が発生しなければ、上記第１の実施の形態と同様に、配信先管理ＤＢ２００に設定された配信先へニュースが配信される。
配信先診断処理においては、例えば、次のようにすれば良い。図７に示されるように、まず、配信先にテストプリントを要求し（Ｓ７０１）、タイマー２０４をセットする（Ｓ７０２）。その後、配信先からテストプリントのジョブステータスを受信して（Ｓ７０３：ＹＥＳ）、テストプリントが正常終了していたら（Ｓ７０６：ＹＥＳ）、当該配信先はニュース（配信データ）を印刷出力できると判断される。従って、当該配信先は正常であると判断して（Ｓ７０７）、上位ルーチンに復帰する。
【００２１】
紙切れやトナー切れ等、何らかの原因でテストプリントが正常終了しなかった場合には（Ｓ７０６：ＮＯ）、当該配信先はニュース（配信データ）を印刷出力できないと判断される。従って、当該配信先は異常であると判断して（Ｓ７０５）、上位ルーチンに復帰する。また、ジョブステータスを受信しないまま（Ｓ７０３：ＮＯ）、タイムアウトが発生した場合にも（Ｓ７０４：ＹＥＳ）、当該配信先は異常と判断して（Ｓ７０５）、上位ルーチンに復帰する。
【００２２】
なお、配信先診断処理は、テストプリントによって配信先の状態情報を取得する以外にも、ＳＮＭＰ（Simple Network Management Protocol）やＯｐｅｎＡＰＩを用いて配信先の装置状態を取得して正常か否かを判断してもよい。また、ＳＮＭＰのＰｉｎｇ等を用いて配信先からの応答の有無（相互通信可能性）を確認することによって配信先の正常性を判断してもよい。
【００２３】
また、異常の報知（Ｓ６０８）は、上記の他、正常と判断された方の配信先に他方の配信先の異常を報知する文書を印刷出力させてもよいし、配信切替え装置１１０の管理者に異常を報知する電子メールを自動送信してもよい。
［３］第３の実施の形態
次に、本発明の第３の実施の形態について説明する。
【００２４】
第３の実施の形態に係る配信切替え装置は、上記第１の実施の形態に係る配信切替え装置１１０と概ね同様の構成を備える一方、配信先を切り替える条件において相違している。以下、この相違点に着目して説明する。
本実施の形態に係る配信切替え装置１１０は、図８に示されるように、配信切替え部２０１、ニュース配信部２０２及びニュース受信部２０５を備えており、クラウドサーバー１３０が配信したニュースをニュース受信部２０５で受信して、ニュース配信部２０２でＭＦＰ−２Ｆ又はＭＦＰ−３Ｆに配信する。
【００２５】
配信先は以下のようにして選択する。すなわち、図９に示されるように、配信切替え装置１１０は、ニュース受信部２０５にてニュースを受信すると（Ｓ９０１：ＹＥＳ）、当該ニュースを配信するに先立って、配信先のＭＦＰ−２Ｆ及びＭＦＰ−３Ｆから利用履歴を取得する（Ｓ９０２）。
特定のユーザー（以下、「指標ユーザー」という。）の利用履歴を抽出する（Ｓ９０３）。更に、抽出した利用履歴のうち最も新しい利用履歴を抽出し、当該最も新しい利用履歴を記録したＭＦＰを次の配信先として（Ｓ９０４）、ニュースを配信する（Ｓ９０５）。
【００２６】
このようにすれば、例えば、指標ユーザーが配信されたニュースを処理すべき担当者や担当部署であるような場合には、ニュースが配信された時点で指標ユーザーが使用していると推定され、従って、指標ユーザーにとって手近な場所に設置されているＭＦＰにニュースが配信されるので、ニュースを指標ユーザーにいち早く届けることができる。
なお、最も新しい利用履歴に代えて、直近の単位時間当たりの出力数（ジョブ数＝稼働率）を計数し、出力数が多い（稼働率が高い）方のＭＦＰを配信先に選択しても良い。このようにすれば、よく使われているＭＦＰにニュースを配信して、印刷出力させるので、ユーザーの利便性を向上させることができる。
【００２７】
また、各配信先の稼働率は短い期間中には大きく変動し難いと考えられるので、稼働率を定期的に取得してもよい。このようにすれば、ニュースが短期間に繰り返し配信される場合であっても、稼働率を繰り返し取得することなく、配信先を選択することができるので、稼働率を取得するために必要となる処理負荷やネットワークの負荷を低減することができる。
【００２８】
更に、ＭＦＰ−２ＦとＭＦＰ−３Ｆとが互いに異なるネットワークセグメントに接続されている場合には、ネットワークセグメント毎に起動されているＰＣ（Personal Computer）の台数を検出し、当該台数が多い方のネットワークセグメントに接続されているＭＦＰを配信先として選択しても良い。このようにしても、よく使われているＭＦＰにニュースを配信して、印刷出力させることができる。
【００２９】
［４］第４の実施の形態
次に、本発明の第４の実施の形態について説明する。
第４の実施の形態に係る配信切替え装置は、上記第２の実施の形態に係る配信切替え装置１１０と概ね同様の構成を備える一方、クラウドサーバーからニュースを受信する前に配信要求及び配信経路作成要求を受信して、その当否を判定する点において相違している。以下、この相違点に着目して説明する。
【００３０】
本実施の形態に係る配信切替え装置１１０は、上記第２の実施の形態に係る配信切替え装置１１０と同様の構成（図５）を備える一方、トンネルサーバーにもなっている。クラウド配信されるニュースは、配線切替え装置１１０が作成したトンネルを経由してＭＦＰ−２ＦやＭＦＰ−３Ｆに配信される。
配信切替え装置１１０は、図１０に示されるように、クラウドサーバー１３０から配信要求並びに配信経路作成要求を受け付けると（Ｓ１００１）、配信切替え装置１１０のニュース受信部２０５は、当該要求の要求先を確認する。要求先は、例えば、当該要求のヘッダー部分に記載されているので、記載された要求先が自己に一致しているかを確認する。
【００３１】
要求先が自分でなかったら（Ｓ１００２：ＮＯ）、配信切替え装置１１０は、要求先が誤っている旨のエラーをクラウドサーバー１３０に返信して（Ｓ１０２１）、ステップＳ１００１に進む。
要求先が自分だったら（Ｓ１００２：ＹＥＳ）、配信先選択処理を実行する（Ｓ１００３）。この配信先選択処理は、上記第２の実施の形態のステップＳ６０２からステップＳ６０６までの処理に対応する処理であって、正常な配信先がある場合には選択成功と判断され、正常な配信先が無い場合には選択失敗と判断される。
【００３２】
選択失敗と判断された場合には（Ｓ１００４：ＮＯ）、配信切替え装置１１０は、ＭＦＰ−２Ｆ及びＭＦＰ−３Ｆの不調により配信経路作成に失敗した旨のエラーレポートを作成し（Ｓ１０１１）、当該エラーレポートをクラウドサーバー１３０に返信して（Ｓ１０１２）、ステップＳ１００１に進む。
選択成功と判断された場合には（Ｓ１００４：ＹＥＳ）、配信切替え装置１１０は、配信経路を作成すると共に（Ｓ１００５）、配信経路作成に成功した旨のエラーをクラウドサーバー１３０に返信して（Ｓ１００６）、ニュースの配信を待つ。クラウドサーバー１３０からニュースを受信したら（Ｓ１００７：ＹＥＳ）、配信切替え装置１１０は当該ニュースを選択された配信先に配信して（Ｓ１００８）、ステップＳ１００１に進む。
【００３３】
なお、クラウドサーバー１３０は、ＸＭＰＰ（eXtensible Messaging and Presence Protocol）に従って、配信要求や通信経路作成要求を行ってもよく、配信切替え装置１１０は、当該要求に係る配信先（通信経路の接続先）のテナントＩＤを確認することによってクラウドサーバー１３０の要求先の当否を判断しても良い。また、配信切替え装置１１０は、ＨＴＴＰ（HyperText Transfer Protocol）トンネリングの通信経路を作成してもよい。
【００３４】
［５］変形例
以上、本発明を実施の形態に基づいて説明してきたが、本発明が上述の実施の形態に限定されないのは勿論であり、以下のような変形例を実施することができる。
（１）上記第５の実施の形態においては、ＨＴＴＰトンネリングを用いる場合を例にとって説明したが、本発明がこれに限定されないのは言うまでもなく、ＨＴＴＰトンネリングに代えて他のトンネリング技術を用いても本発明の効果は同じである。ただし、配信先を切り替える必要上、動的に経路を切り替えることができるトンネリング技術を用いるのが望ましい。
【００３５】
（２）上記実施の形態においては、ニュースの配信先となる画像形成装置がＭＦＰである場合を例にとって説明したが、本発明がこれに限定されないのは言うまでもなく、ＭＦＰに代えて、プリンター装置を用いても良いし、スキャナーを備えた複写装置を用いても良く、更に、通信機能を備えたファクシミリ装置であっても良い。また、印刷出力は、モノクロ出力であってもよいし、カラー出力であってもよい。
【００３６】
（３）上記実施の形態においては、ニュースを配信するクラウド配信システムを例にとって説明したが、本発明がこれに限定されないのは言うまでもなく、ニュース以外のデータを配信する場合であっても、本発明を適用することによって同様の効果を得ることができる。
（４）上記実施の形態においては、配信切替え装置１１０がインターネット１４０に接続されている場合を例にとって説明したが、本発明がこれに限定されないのは言うまでもなく、次のようにしても良い。すなわち、配信切替え装置１１０は、ＬＡＮ１２０を介してインターネット接続装置に接続されており、当該インターネット接続装置を介してニュースを受信してもよい。
【００３７】
また、配信切替え装置１１０は、回線交換網など、インターネット以外のＷＡＮを介してニュースを受信してもよい。配線切替え装置１１０は構内交換機（PBX: Private branch exchange）を介してＷＡＮに接続されていてもよい。ネットワーク構成の如何に関わらず、本発明を適用してその効果を得ることができる。
【産業上の利用可能性】
【００３８】
本発明に係る配信切替え装置は、クラウドサーバーから配信サービスを受ける配信先でクラウド配信サービスの受信装置を切り替える装置として有用である。
【符号の説明】
【００３９】
１………クラウド配信システム
１００…ローカル局
１１０…配信切替え装置
１５０…キー局
１３０…クラウドサーバー
２００…配信先管理ＤＢ
２０１…配信切替え部
２０２…ニュース配信部
２０３…ユーザーインタフェース
２０４…タイマー
２０５…ニュース受信部
【図１】
2016115184.tif 000003
【図２】
2016115184.tif 000004
【図３】
2016115184.tif 000005
【図４】
2016115184.tif 000006
【図５】
2016115184.tif 000007
【図６】
2016115184.tif 000008
【図７】
2016115184.tif 000009
【図８】
2016115184.tif 000010
【図９】
2016115184.tif 000011
【図１０】
2016115184.tif 000012