JP2017102802A - 配信システム、及び配信システムの制御方法 - Google Patents

Abstract

【課題】配信システムに配信設定をリクエストしたサービスが配信設定管理の対象としていないデバイスおよびデバイスのコンテンツを不適切に更新する状況の発生を防ぐこと。【解決手段】配信システム（１０）は、ＷｅｂＡＰＩによりコンテンツの配信設定リクエストを受け付けた場合（Ｓ１０００）、該配信設定を許可するか否かを、該配信設定の要求元のサービスの情報（Ｓ１００１）、該配信設定でコンテンツを配信する対象となるデバイスの状態（Ｓ１００３）、該配信設定で配信するコンテンツの情報、及び、予め設定されている配信条件に基づいて判断し（Ｓ１００８，Ｓ１００９）、許可すると判断された場合には該配信設定を確定し（Ｓ１０１０）、許可しないと判断された場合には該配信設定をキャンセルする（Ｓ１００７）。【選択図】図７

Description

本発明は、デバイスへのコンテンツの配信を制御する配信システム、及び配信システムの制御方法に関するものである。

従来、複合機等のデバイスの良好な稼働状態を維持するために、デバイスを監視サービスに接続し、監視サービス側からデバイスの状態を監視することが行われている。このような監視を行うことにより、例えば、デバイスにおいて故障やジャムの頻発などの異常が検出された場合には、サービスマンが速やかに出動し対処することができる。また、消耗品の寿命が近いことを検出した場合には、消耗品の発送処理等を行ってユーザの在庫消耗品を適切な量に維持することも可能となる。このような監視サービスは、デバイスの開発会社あるいは直接販売会社によって提供されるサービスである。

一方、最近では、企業のオフィス出力環境の現状を分析し、最適な出力環境を提案、構築するアウトソーシングサービスであるマネージド・プリント・サービス（ＭＰＳ）へもデバイスが接続される。ＭＰＳでは、企業の環境を構成するデバイスのメーカが複数混在する場合があり、デバイスの開発会社あるいは直接販売会社以外の会社からサービスが提供される場合もある。

また、デバイスは、デバイスにインストールされるソフトウェアをネットワーク経由でリモート配信、自動更新する配信システムに接続され、最新バージョン、あるいは、適切なバージョンのソフトウェアが動作するように維持されている。デバイスでは、デバイス本来の組み込み機能を実現するためのファームウェアと、利用者毎に後からインストールして使用するアプリケーションという二種類のソフトウェアが利用可能である。上述のような配信システムは、デバイスの開発会社によって提供される。
なお、家電では、製品情報を管理サーバへ送信し、管理情報に該当する製品のソフトウェアバージョンアップにより、不具合を自動修復する技術が提案されている（特許文献１）。

特開２００２−９１８４２号公報

デバイスでは、ネットワークを使って提供される各種サービスに接続し、連携して動作するために、そのサービスと紐付いた管理エージェントをインストールして動作させている。例えば、デバイスの情報を収集、集計する管理サービスと連携するためには、デバイスの情報をネットワーク上のサービスへ送信するための管理エージェントが必要となる。また、管理サービス以外でも、デバイスの機能を拡張するために、外部システムと連携するためのエージェントソフトウェアのインストールや、ファームウェアに含まれる機能の有効化を行う場合がある。

このように、配信システム以外にも、デバイスに接続するサービスが複数存在する状況において、各サービスは、デバイスとの連携状態を適切に維持するために、次のような要求がある。すなわち、配信システム以外のサービスも、デバイスにインストールされ動作しているソフトウェアあるいは機能が、適切なバージョンに維持されるようにソフトウェアのリモート配信をしたい場合がある。

そこで、配信システムは、外部から配信設定を行うためのＡＰＩ（Application Programming Interface）を提供して、これらサービスからの配信設定リクエストを受け付けるように構成されている。
しかし、配信サービスが複数のサービスから配信設定を受け付けるようになると、そのサービスが管理対象としていないデバイスに対する配信設定がされないように、配信サービス側でリクエスト受付の制御を行う必要があるといった課題があった。

本発明は、上記の問題点を解決するためになされたものである。本発明の目的は、配信システムに配信設定をリクエストしたサービスが配信設定管理の対象としていないデバイスおよびデバイスのコンテンツを不適切に更新する状況の発生を防ぐ仕組みを提供することである。

本発明は、デバイスを管理する１以上のサービスから配信設定の要求に従ってデバイスへのコンテンツの配信を制御する配信システムであって、ネットワークを介して通信可能なサービスから前記コンテンツの配信設定の要求を受け付ける第１受付手段と、前記第１受付手段によりコンテンツの配信設定の要求を受け付けた場合、該配信設定を許可するか否かを、該配信設定を要求したサービスの情報、該配信設定でコンテンツを配信する対象となるデバイスの状態、及び、予め設定されている配信条件に基づいて判断する判断手段と、前記判断手段により前記配信設定を許可すると判断された場合には該配信設定を確定し、前記配信設定を許可しないと判断された場合には該配信設定をキャンセルする制御を行う制御手段と、を有することを特徴とする。

本発明によれば、配信システムに配信設定をリクエストしたサービスが配信設定管理の対象としていないデバイスおよびデバイスのコンテンツを不適切に更新する状況の発生を防ぐことができる。

本実施例の配信システムを適用可能なシステムの構成図 配信システムのアプリケーションサーバのハードウェア構成 配信システム及びデバイスの機能構成図 管理サービスからの配信設定デバイスリストに伴う配信システムの通信シーケンス例 管理サービスからの配信設定リクエストに伴う配信システムの通信シーケンス例（配信設定を確定する例） 管理サービスからの配信設定リクエストに伴う配信システムの通信シーケンス例（配信設定を無効にする例） 配信システムにおける配信設定判断を例示するフローチャート

以下、本発明を実施するための形態について図面を用いて説明する。
図１は、本発明の一実施例を示す配信システムを適用可能なシステムの構成を例示する図である。

図１において、配信システム（１０）は、Ｗｅｂサーバ（１２）、データベースサーバ（ＤＢサーバ）（１３）及びアプリケーションサーバ（１１）などから構成されている。配信システム（１０）は、インターネット（１００）に接続されたＷｅｂサーバ（１２）を介して、各顧客企業（１１４、１１９、１２９等）のデバイス（１１５〜１１７、１２０、１２１、１２４〜１２７、１３１等）と通信を行う。これにより、配信システム（１０）は、１以上のデバイスへの、アプリケーションソフトウェア（以後「アプリ」と略記）及びファームウェア（以後「ＦＷ」と略記）の配信制御を行う。

配信システム（１０）は、ネットワークを介してＷｅｂブラウザ等から配信設定を受け付けることが可能である。また、配信システム（１０）は、管理サービス２（５０）や管理サービス３（６０）からの配信設定リクエストを受けて、配信制御を行うことも可能である。

アプリ及びＦＷの実ファイルは、コンテンツサーバ（２０）上に配置されている。デバイスへアプリをインストールする場合には、デバイスは、配信システム（１０）からコンテンツサーバ（２０）上の実ファイルの位置情報（例えばＵＲＬ）を取得し、コンテンツサーバ（２０）からアプリをダウンロードする。これにより、多くのデバイスのアプリ配信の負荷を分散し効率良くアプリの配信を行うことができる。アプリ及びＦＷの更新も同様である。

コンテンツサーバ（２０）は、コンテンツ管理サーバ（２１）およびファイル・ストレージ（２２、２３）等から構成される。コンテンツ管理サーバ（２１）は、外部からのリクエストに従って、ファイル・コンテンツすなわちアプリ及びＦＷの実ファイルを保存、あるいは提供する。

デバイスには、マルチ・ファンクション・プリンタ（ＭＦＰ）や、シングル・ファンクション・プリンタ（ＳＦＰ）等の種類があり、デバイスのモデル毎に一つあるいは複数の機能が搭載されている。それらの機能を実現するためのＦＷがデバイスにインストールされることにより、デバイスの各機能が利用可能となる。また、デバイスには、デバイスのモデル毎、あるいは、デバイスのモデルに共通で実行可能なアプリをインストールして実行することが可能である。デバイスの利用者は、そのデバイスで利用可能な複数のアプリの中から、所望のものを選び、ライセンスを購入するなどして入手することにより、アプリのインストールを行うことができる。また、デバイスのアプリの不具合が修正された場合や機能の改善あるいは追加がされた場合には、アプリを更新することで、それらの機能を利用することができる。

販売会社システム（３０）は、デバイスを各顧客企業（１１４、１１９、１２９等）へ販売し、維持、管理するデバイスの製造会社あるいはデバイスの販売会社がアプリ及びＦＷの登録・管理のための操作をするシステムである。販売会社システム（３０）は、１台以上のＰＣ（３１、３２）あるいはサーバ（３３、３４）を有する。販売会社システム（３０）から配信システム（１０）およびコンテンツサーバ（２０）へアクセスすることにより、アプリ及びＦＷの登録と配信設定を行うことができる。

管理サービス１（４０）は、販売会社あるいは製造会社が、顧客のデバイスをメンテナンスするための管理サービスである。管理サービス１（４０）は、例えばＷｅｂサーバ（４２）、データベースサーバ（ＤＢサーバ）（４３）及びアプリケーションサーバ（４１）などから構成されている。管理サービス１（４０）は、管理対象の顧客のデバイスとインターネット（１００）を経由して接続し、各デバイスからの情報を収集する。サービスマンは、販売会社システム（３０）から管理サービス１（４０）へアクセスすることにより、顧客のデバイスをメンテナンスするために必要な情報の収集や状態の監視を行う。

なお、管理サービス１（４０）は、配信システム（１０）と密に連携する連携機能を有する。この連携機能では、例えば、管理サービス１（４０）は、自身の管理対象のデバイス群からＷｅｂブラウザ等のＷｅｂクライアントにて指定させたデバイスのリストを配信システム（１０）に対して送信し、該デバイスのリストを配信システム（１０）と共有することができる。さらに、管理サービス１（４０）は、該Ｗｅｂクライアントのアクセス先を配信システム（１０）が提供するＷｅｂユーザインタフェースにリダイレクト等の手法で導き、該デバイスのリストで指定されたデバイスを配信対象とするコンテンツの配信設定を該Ｗｅｂユーザインタフェースから入力可能にする。詳細は後述する図４で説明する。

管理サービス２（５０）や管理サービス３（６０）は、顧客のＩＴ管理者あるいは、顧客から業務を委託された販売会社のサービスマンが、顧客のデバイスをメンテナンスするための管理サービスである。管理サービス２（５０）や管理サービス３（６０）も管理サービス１（４０）と同様の構成である。管理サービス２（５０）や管理サービス３（６０）は、管理対象の顧客のデバイスとインターネット（１００）を経由して接続し、各デバイスからの情報を収集する。顧客のＩＴ管理者あるいはサービスマンは、管理サービス２（４０）や管理サービス３（６０）へアクセスすることにより、顧客のデバイスをメンテナンスするために必要な情報の収集や状態の監視を行う。また、管理サービス２（５０）や管理サービス３（６０）は、配信システム（１０）に対して配信設定リクエストを送信して、配信システム（１０）におけるコンテンツの配信設定を要求することができる。詳細は後述する図５〜図７で説明する。

このように、デバイスを管理する１以上のサービスが、インターネット（１００）を介して配信システム（１０）と通信可能に接続されている。そして、配信システム（１０）は、これらデバイス等のクライアントを管理する一つ以上のサービスからの要求に従って、クライアントへコンテンツの配信を制御する。

本実施例では、配信システム（１０）がコンテンツを配信するデバイスとして、ＭＦＰおよびＳＦＰを例に挙げているが、これに限るものではない。すなわち、配信システムによるアプリの自動配信がなされる一方で、一つ以上の管理サービスによって各デバイスの管理を行う仕組みを持つようなデバイスであれば、本発明の技術は有効である。他に本発明が有効なデバイスの例としては、ネットワークカメラ、パーソナルコンピュータ、インターネットに接続された各種の家電、電子制御機器を複数搭載する車両、あるいは携帯電話などが挙げられる。

図２は、本実施例の配信システム（１０）のアプリケーションサーバ（１１）のハードウェア構成を例示するブロック図である。
本実施例におけるアプリケーションサーバ（１１）は、ネットワークインタフェース（Ｎｅｔｗｏｒｋ Ｉ／Ｆ）（２０４）を介して、Ｗｅｂサーバ（１２）やＤＢサーバ（１３）と互いに接続されている。アプリケーションサーバ（１１）は、バス（２０５）を介して接続されたＣＰＵ（２０１）、ＲＡＭ（２０２）、ＲＯＭ（２０３）、ネットワークインタフェース（２０４）、ＨＤＤ（２０６）などを有する。

配信システム（１０）の機能は、アプリケーションサーバ（１１）のＨＤＤ（２０６）あるいはＲＯＭ（２０３）、ＲＡＭ（２０２）に記録されたデータ及びプログラムを読み出してＣＰＵ（２０１）で実行することにより実現される。また、配信システム（１０）の機能は、複数のサーバの機能の連携によって実現される場合もある。ネットワークインタフェース（２０４）は、配信システム（１０）内のサーバ間の機能連携に使われると共に、インターネット（１００）を介して、外部システムと通信するためにも使用される。

なお、図２はアプリケーションサーバ（１１）に対応して図示しているが、その他のサーバ、及びデバイスのコントローラ部等も同様のハードウェア構成を有するものとする。よって、ここでは図示を省略する。

図３は、本実施例の配信システム（１０）の機能構成を例示するブロック図である。
配信システム（１０）は、図１に示したように、複数のサーバから構成されるため、その機能も複数サーバの組合せにより実現されているものとする。ただし、配信システム（１０）は、図１に示す構成に限らず、１つのサーバで全ての機能を実現してもよいし、また、高い性能が必要な場合には、より多くのサーバの組合せで実現してもよい。

図３において、４００は、配信システム（１０）に接続するデバイスの一例である。３０２は、配信システム（１０）に接続する販売会社システムの一例として、クライアントシステムであるＷｅｂブラウザを示す。

配信サーバ（１０）において、３１０はＷｅｂインタフェース部で、デバイス（４００）に対するアプリ及びＦＷの配信機能を提供するためのものである。Ｗｅｂインタフェース部（３１０）は、各デバイスから各種リクエストを受信し、処理結果を返却する。例えば、Ｗｅｂインタフェース部（３１０）は、ＦＷやアプリなどコンテンツの配送情報リクエストを受信すると、対象とするコンテンツの格納されている場所を検索し、コンテンツを取得するためのＵＲＬとして返却する。また、Ｗｅｂインタフェース部（３１０）は、管理サービス２（５０）や管理サービス３（６０）等の外部システムから配信設定を行うためのＡＰＩ（Ｗｅｂアプリケーションプログラミングインタフェース、以下ＷｅｂＡＰＩ）によるリクエストを受信し、配信設定を行う。

３１２はリクエスト受信部で、Ｗｅｂインタフェース部（３１０）からのリクエストを受信するためのものである。３１３はレスポンス返信部で、Ｗｅｂインタフェース部（３１０）へレスポンスを返すためのものである。

３１１はユーザインタフェース部で、Ｗｅｂブラウザ３０２から配信システム（１０）にアクセスして、アプリ及びＦＷの登録や配信設定などを行うためのものである。
３２１はデータ共有部で、上述した連携機能を有する管理サービス（本実施例では管理サービス１（４０））が管理対象としているデバイス群から選択されたコンテンツ配信対象のデバイスのリストを該管理サービスから受信して、該管理サービスと共有するためのものである。

３１４は配信設定制御部で、ＦＷおよびアプリの配信設定を制御するためのものである。配信設定制御部（３１４）は、デバイス管理部（３１５）、アプリ配信設定部（３１７）、ＦＷ配信設定部（３１８）を制御して、ユーザインタフェース部（３１１）で表示する配信設定のための画面の出力内容を決定する。配信設定制御部（３１４）は、また、外部システムからの配信設定の制御も行う。

３１９は設定判断部で、外部システムからの配信設定リクエストによる配信設定の可否を判断するためのものである。設定判断部（３１９）の判断結果により、配信設定制御部（３１４）を制御し、配信設定の仮スケジュールや配信設定の確定を行う。なお、詳細は後述する。

３２０はＤＢアクセス部で、各種処理に応じて、データ管理部（３３０）で管理されているテーブルのデータを更新あるいは検索するためのものである。
データ管理部（３３０）において、３３１は、登録アプリ管理テーブルである（後述する表３に例示）。３３２は、更新可能アプリ管理テーブルである（後述する表４に例示）。３３３は、登録ファームウェア管理テーブルである（後述する表５に例示）。

３３４は、デバイス管理テーブルである（後述する表６に例示）。このデバイス管理テーブル３３４に、配信システム（１０）が配信管理するデバイスにおいて有効化されている機能など、デバイスの状態も保持される。３３５は、インストール済みアプリ管理テーブルである（後述する表７に例示）。このインストール済みアプリ管理テーブル３３５に、配信システム（１０）が配信管理するデバイスにおいてインストールされているアプリおよびバージョンの情報が保持される。３３６は、コンテンツ配信管理テーブルである（後述する表８に例示）。３３８は、配信条件管理テーブルである（後述する表１と表２に例示）。

以下、デバイス（４００）の機能構成について説明する。
３４０はメイン処理部で、デバイス（４００）の本来の機能を処理するためのものある。メイン処理部（３４０）は、例えば、プリンタであれば画像形成処理を行う等の主機能を指す。デバイス（４００）は、この主機能の他に、デバイスのＦＷおよびアプリの配信制御を行うための機能も備えている。それが３４１〜３４８に示す機能ブロックである。

３４１はＷｅｂインタフェース部で、配信システム（１０）からアプリ及びＦＷの配信を受けるためのものである。Ｗｅｂインタフェース部３４１は、配信システム（１０）のＷｅｂインタフェース（３１０）と接続されている。３４２は、配信処理部である。３４３は、アプリインストール部である。３４４は、アプリ更新部である。３４５は、ＦＷ更新部である。３４７はコンテンツ格納部で、配信されたＦＷあるいはアプリを格納するためのものある。

以下、図４〜図６のシーケンス図を用いて、配信システム（１０）に対して配信設定を行い、配信システム（１０）がデバイス（４００）へ配信する場合の流れを例示する。なお、図４〜図６に示すシーケンス図において、配信システム（１０）の処理は、配信システム（１０）のＣＰＵ２０１がＨＤＤ２０６やＲＯＭ２０３等に格納されるプログラムを実行することにより実現されるものである。また、デバイス（４００）の処理は、例えばデバイス（４００）のＣＰＵがＨＤＤやＲＯＭ等に格納されるプログラムを実行することにより実現されるものである。また、管理サービス１（４０）の処理は、例えば管理サービス１（４０）のＣＰＵがＨＤＤやＲＯＭ等に格納されるプログラムを実行することにより実現されるものである。また、管理サービス２（５０）の処理は、例えば管理サービス１（５０）のＣＰＵがＨＤＤやＲＯＭ等に格納されるプログラムを実行することにより実現されるものである。

図４は、管理サービス１（４０）からの配信設定に従って、配信システム（１０）がデバイス（４００）へ配信する場合の流れを例示するシーケンス図である。
図４において、４０１は、デバイス（４００）を利用する利用者である。４０２は、デバイス（４００）に対して、アプリおよびＦＷの更新のために、配信システム（１０）へリモート配信の設定操作を行うサービスマンである。図４に示すシーケンス図では、サービスマン（４０２）が配信設定を行うよりも前に、デバイス（４００）が配信システム（１０）と接続している場合を表している。

まず、利用者（４０１）がデバイス（４００）の電源を入れて起動する（４１０）と、デバイス（４００）は配信システム（１０）へデバイス状態を通知する（４１１）。ここで通知する情報には、デバイス（４００）にインストールされているアプリの情報、有効化されている組み込み機能の情報が含まれている。

その後、サービスマン（４０２）は、管理サービス１（４０）にアクセスしてコンテンツの配信設定を行うために、デバイス（４００）を含む配信設定対象デバイスのリストを指定する（４１２）。ここで、サービスマン（４０２）はＷｅｂブラウザを利用して、管理サービス１（４０）のユーザインタフェースを操作するものとする。

管理サービス１（４０）は、上述のサービスマン（４０２）から指定されたデバイスのリスト（配信設定デバイスリスト）を、データ共有部（３２１）を利用して配信システム（１０）へ送信する。この配信設定デバイスリストを受信すると、配信システム（１０）は、管理サービス１（４０）へ応答する（４１４）。管理サービス１（４０）は、配信システム（１０）からの応答が返る（４１４）と、サービスマン（４０２）のＷｅｂブラウザに対して、配信システム（１０）の設定画面へ移動するようリダイレクト指示を返す（４１５）。なお、この際、上述の配信設定デバイスリストをパラメータとして渡してもよい。

このリダイレクト指示に従って移動した配信システム（１０）の設定画面から、サービスマン（４０２）は、配信システム（１０）へ、各デバイスに対応する配信設定を入力する（４１６）。ここで、配信設定には、上述の配信設定デバイスリストで指定された配信対象デバイスの識別情報、配信するコンテンツの指定、配信予定日時などの情報が含まれているものとする。配信システム（１０）は、上記配信設定において指定されたデバイス毎に配信予約のために配信設定を記憶する（４１７）。この配信設定は、上記４１３で管理サービス１（４０）から受信した配信設定デバイスリストに基づくものであり、管理サービス１（４０）の管理対象のデバイスが配信対象のデバイスとして指定されている。このため、この配信設定では、管理サービス１（４０）の管理対象外のデバイスが配信対象のデバイスに指定されることがない。即ち、管理サービス１（４０）は信頼できるサービスで、この配信設定は信頼できる配信設定であるといえる。よって、配信システム（１０）は、後述する図７に示すような判断を行うことなくこの配信設定を確定させるものとする。なお、例えば４１１にてデバイス（４００）から通知を受けたデバイス状態に従って、配信設定を確定するようにしてもよい。また、後述する図７に示すような判断を行って配信設定を確定するようにしてもよい。

デバイス（４００）は、起動している間、定期的に配信システム（１０）に対して、配信予約が存在するか否かの確認を行う（４２０）。４２０で囲まれた範囲は、デバイス（４００）から配信システム（１０）に対して、定期的に問い合わせる配信設定確認のシーケンスを示している。デバイス（４００）は、所定の周期あるいは決められたタイミングにおいて、配信システム（１０）に、デバイス（４００）向けのアプリ更新あるいはＦＷ更新の設定が無いかを問い合わせる（４１８）。配信システム（１０）は、アプリ更新あるいはＦＷ更新の配信設定の有無と配信設定がある場合には、その情報をデバイス（４００）へ応答する（４１９）。デバイス（４００）は、配信設定がある場合には、配信システム（１０）からの情報を配信予定日時まで記憶しておく。４１９で返された配信設定情報には、配信日時情報、配信識別情報が含まれる。

デバイス（４００）は、上述の配信予定日時（４３０）になると、配信システム（１０）へ、配信識別情報を送り、配信設定が有効になっているかを確認する（４３１）。配信システム（１０）は、配信設定が有効であれば、配信設定情報を返す（４３２）。４３２で有効な配信設定情報が返ってきたら、デバイス（４００）は、配信するコンテンツのＵＲＬを要求する（４３３）。配信システム（１０）は、配信するコンテンツのＵＲＬを返す。そして、デバイス（４００）は、配信システム（１０）が返したコンテンツのＵＲＬ（４３４）で、コンテンツサーバ（２０）にコンテンツを要求（４３５）し、コンテンツをダウンロードする（４３６）。

次に、デバイス（４００）は、ダウンロードしたコンテンツのインストール処理を行う（４３７）。この際、デバイス（４００）は、ダウンロードしたコンテンツがＦＷの場合にはＦＷの更新を行い、アプリの場合にはアプリのインストールを行う。そして、コンテンツのインストール処理（４３７）が完了すると、デバイス（４００）は、配信システム（１０）へコンテンツの更新通知を行う（４３８）。この更新通知により、デバイス（４００）で更新されたＦＷのバージョン、あるいは、インストールされたアプリといったデバイス（４００）の状態情報を更新する。

以下、図５を用いて、図４とは異なる配信設定のシーケンスを示す。
図５は、管理サービス２（５０）からの配信設定リクエストに従って、配信システム（１０）がデバイス（４００）へ配信する場合の流れの例示するシーケンス図である。ここでは、管理サービス２（５０）として説明するが、管理サービス３（６０）でもよい。

図５において、４０１は、図４と同じくデバイス（４００）を利用する利用者である。４０３は、デバイス（４００）に対して、アプリおよびＦＷの更新のために、配信システム（１０）へリモート配信の設定操作を行う顧客ＩＴ管理者である。図５に示すシーケンス図では、顧客ＩＴ管理者（４０３）が配信設定を行う時には、デバイス（４００）が配信システム（１０）とまだ接続できていない場合を表している。管理サービス２（５０）は、配信システム（１０）に対して、ＷｅｂＡＰＩを利用した配信設定リクエストを送ることで、配信設定を行う。

まず、顧客ＩＴ管理者（４０３）は、管理サービス２（５０）にアクセスしてコンテンツの配信設定を行うために、デバイス（４００）を指定して、配信設定を入力する（４５０）。ここで、顧客ＩＴ管理者（４０３）はＷｅｂブラウザを利用して、管理サービス２（５０）のユーザインタフェースを操作するものとする。

管理サービス２（５０）は、Ｗｅｂインタフェースを利用して配信システム（１０）へ、上述の顧客ＩＴ管理者（４０３）から指定された配信設定の内容で、配信設定リクエストを送信する（４５１）。配信システム（１０）は、受信した配信設定リクエストに対応する配信設定を一旦配信予約の仮設定として記憶（４５２）し、管理サービス２（５０）へＷｅｂＡＰＩの応答を返す（４５３）。

その後、利用者（４０１）がデバイス（４００）の電源を入れて起動する（４５４）と、デバイス（４００）は配信システム（１０）へデバイス状態を通知する（４５５）。配信システム（１０）は、設定判断部（３１９）にて、上記４５５で得られた情報に従って、後述する図７に示す設定判断を行う。図５の例では、配信設定許可と判断されたものとし、配信システム（１０）は、仮設定した配信予約を確定した配信設定とする（４５６）。

デバイス（４００）は、図４に示したシーケンスと同様に、定期的に配信システム（１０）に対して、配信予約が存在するか否かの確認を行う（４５９）。４５９に示すように、デバイス（４００）は、配信システム（１０）に、デバイス（４００）向けのアプリ更新あるいはＦＷ更新の設定が無いかを問い合わせる（４５７）。配信システム（１０）は、アプリ更新あるいはＦＷ更新の配信設定の有無と配信設定がある場合には、その情報をデバイス（４００）へ応答する（４５８）。デバイス（４００）は、配信設定がある場合には、配信システム（１０）からの情報を配信予定日時まで記憶しておく。予約日時（４６０）以降のシーケンスは図４に示す４３１以降のシーケンスと同様である。よって説明を省略する。

さらに、図６を用いて、図４、図５とは異なる配信設定のシーケンスを示す。
図６は、管理サービス２（５０）からの配信設定リクエストに対して、配信システム（１０）が配信設定を無効にする場合の流れの例を示すシーケンス図である。図６における４５１〜４５５は、図５と同じであるので説明を省略する。ここでは、管理サービス２（５０）として説明するが、管理サービス３（６０）でもよい。

配信システム（１０）は、設定判断部（３１９）にて、４５５で得られた情報に従って、後述する図７に示す設定判断を行う。図６におけるシーケンスの例では、デバイス（４００）から通知された情報に従って、管理サービス２（５０）から、デバイス（４００）に対する配信設定を許可できないと判断されるものとする。すなわち、配信システム（１０）は、４５５で得られた情報に従って、仮設定した配信予約をキャンセルする（４７０）。

デバイス（４００）は、図５に示すシーケンスと同様に、配信予約が存在するか否かの確認を行う（４７３）。４７３に示すように、デバイス（４００）は、配信システム（１０）に、デバイス（４００）向けのアプリ更新あるいはＦＷ更新の設定が無いかを問い合わせる（４７１）。しかし、配信システム（１０）は、デバイス（４００）向けの配信設定が無いため、その旨の情報を返す（４７２）。配信設定が無いため、デバイス（４００）は、次の配信設定が入るまで、定期的に配信システム（１０）に問い合わせを繰り返す。

図５、図６で示したように、配信システム（１０）では、デバイス（４００）から得られる情報によって、管理サービス２（５０）からのリクエストに従った配信設定が有効あるいは無効に設定され、有効に設定された配信設定だけが処理される。
なお、図４に示した管理サービス１（４０）によるデバイスリスト送信と配信システム（１０）における設定画面の配信設定、も同様に配信設定の有効あるいは無効を判断するようにしてもよい。

次に、設定判断部（３１９）における、配信設定の有効（許可）あるいは無効（キャンセル）の判断について説明する。
表１と表２に配信条件管理テーブル（３３８）に格納されている配信条件情報を例示する。

配信条件情報の表１は、サービス、条件、タイプ、コンテンツＩＤ、バージョン、範囲などの組合せの一覧から構成される。「サービス」は、条件の判断対象となる配信設定リクエストを行うサービスを表し、管理サービス２（５０）や管理サービス３（６０）を識別する情報である。「条件」は、配信設定を許可する条件式であり、表２の行を番号で参照して論理式を表現した文字列である。「タイプ」は、配信設定を許可するコンテンツのタイプ（アプリ、ＦＷなど）を表す。「コンテンツＩＤ」は、配信設定を許可するコンテンツを識別する情報である。「バージョン」は「コンテンツＩＤ」と合わせて、配信設定を許可するコンテンツのバージョンを識別する情報である。「範囲」は、「バージョン」と合わせて、配信設定を許可するコンテンツのバージョンの範囲を識別する情報である。これらの項目の組合せにより、表１の行単位で、サービス毎に特定の条件を満たした場合に、その行が示す、コンテンツ（の範囲）の配信設定を対象デバイスに対して許可する。サービスから行おうとする配信設定に条件とコンテンツが一致する行が存在し無い場合には、その配信設定は許可されず、図６の４７０に示した例のようにキャンセルされる。なお、本実施例では、サービスから行おうとする配信設定と配信条件とが一致した場合に該配信設定を許可するものとするが、逆に、サービスから行おうとする配信設定と配信条件とが一致した場合に該配信設定を許可しないようにしてもよい。即ち、配信条件は、サービスごとに、該サービスからの配信設定を許可する（又は許可しない）デバイスの状態と、該サービスからの配信設定を許可する（又は許可しない）コンテンツの情報とを組み合わせた条件であればよい。

本実施例における表１において、「サービス」には、配信設定リクエストを送ってきたサービスを識別する情報として、サービスの名称を使用している。しかし、他の実施例としては、表１の「サービス」に、接続サービスのＩＰアドレスや、システムＩＤ等の接続サービスの認証情報を用いても有効である。

「条件」には、表２の番号を項として、条件を構成する式を記述する。本実施例においては、条件式を構成するための論理演算子として、論理和（「＋」）、論理積（「＊」）、論理否定（「！」）、評価順序制御のための括弧（「（」、「）」）が使えるものとする。論理式の評価方法については、公知の手段に従うものとして詳細は省略する。

「タイプ」には、コンテンツの種別として、本実施例においては、アプリ（「Ａｐｐｌｉｃａｔｉｏｎ」）、ファームウェア（「ＦＷ」）、任意（「＊」）のいずれかを記述できるものとする。
「コンテンツＩＤ」には、タイプがアプリの場合にアプリのＩＤを記述する。任意のアプリの配信を許可する場合には、「バージョン」に「＊」を記述する。また、「タイプ」がＦＷの場合にも、「バージョン」に「＊」を記述するものとする。他の実施例としては、アプリを一意に識別するＩＤを「バージョン」に記述するものとしても有効である。

「バージョン」は、「タイプ」がＦＷ、あるいは、「コンテンツＩＤ」が特定のアプリを記述している場合には、特定のバージョンを表すバージョン番号を記述するものとする。任意のバージョンを許可する場合、あるいは、任意のコンテンツを許可する場合には、「バージョン」に「＊」を記述するものとする。さらに、特定のバージョンが記述された場合、「範囲」に比較演算子を記述することで、その行に記述された特定のバージョンを基準として配信許可するバージョンの範囲を表現できるものとする。本実施例においては、「＝」、「＞＝」、「＜＝」、「＞」、「＜」が使えるものとする。「＝」ならば、バージョンに一致するものだけ許可する。「＞＝」ならば、バージョンで示すバージョン以上のバージョンならば配信許可する。「＜＝」ならば、バージョンで示すバージョン以下のバージョンならば配信許可する。「＞」は、より新しいバージョンを示す。「＜」は、より古いバージョンを示す。「バージョン」の記述が任意の場合には、「＊」を記述するものとする。

配信条件情報の表２は、タイプ、コンテンツＩＤ、バージョン、範囲などの組合せの一覧から構成される。各行は、配信設定対象デバイスから取得した情報を基に確認する条件であり、有効な組み込み機能、あるいは、インストール済みアプリを表す。組み込み機能を表したい場合には、「タイプ」に「Ｅｍｂｅｄ」と記述し、インストール済みアプリを表したい場合には、「タイプ」に「Ａｐｐｌｉｃａｔｉｏｎ」と記述する。

「コンテンツＩＤ」には、確認する組み込み機能の識別情報あるいは、アプリの識別情報としてのアプリ名称を記述する。特定のバージョンあるいはバージョンの範囲を示すためには、「バージョン」と「範囲」に、その条件を記述する。「バージョン」と「範囲」の記述方法については、表１の項目と同じものとする。これらの項目の組合せにより、表２の各行は、特定の組み込み機能が有効、あるいは、特定のバージョンあるいはバージョン範囲のアプリがインストール済みであること、を表す。即ち、表２の各行は、配信条件のうち、配信対象のデバイスが満たすべき、コンテンツのインストール状態、機能の有効化の状態を示す。これと表１との組み合わせにより、設定判断部（３１９）は、配信設定対象デバイスにて、所定の組み込み機能が有効か否か、あるいは、所定のアプリがインストール済みか否か、および、それらの組合せを条件として確認し、条件に合致した場合のみ、そのデバイスへの配信設定を許可する。

本実施例において、例えば、表１の１行目および表２の１行目より、「Ｓｅｒｖｉｃｅ−Ａ」の示すサービスからのリクエストにおいては、対象デバイスにおいて「ＥＲＤＳ」という組み込み機能が有効であれば、任意の配信設定を許可することを意味する。なお、本実施例では、表１の１行目の「Ｓｅｒｖｉｃｅ−Ａ」は、図１に示した管理サービス３（６０）に対応するものとする。管理サービス３（６０）は、管理サービス３（６０）で管理対象のデバイスに対する配信設定リクエストのみを、配信サービス（１０）に送信するように作成されている信頼できるサービスである。このため、管理サービス３（６０）の配信設定リクエストに基づく配信設定に対しては、対象デバイスにおいて「ＥＲＤＳ」という組み込み機能が有効であれば、任意の配信設定が許可される。

また、別の例として、表１の２行目、表２の２，３行目は、「Ｓｅｒｖｉｃｅ−Ｂ」の示すサービスからのリクエストにおける次のような条件を表している。つまり、バージョン「２．０」以上のアプリ「Ｂ＿ＣＬＩＥＮＴ」がインストールされ、かつ、「ＥＲＤＳ」機能が有効であるデバイスには、バージョン「２．０」以上の「Ｂ＿ＣＬＩＥＮＴ」を配信設定許可できる。

さらに、表１の３行目、表２の４，５行目より、「Ｓｒｖ−Ｃ」の示すサービスからのリクエストにおいては、アプリ「ＭＰＳＣＬＩＥＮＴ」がインストールされ、かつ、「ＥＲＤＳ」機能が無効であるデバイスには「ＭＰＳＣＬＩＥＮＴ」だけを配信設定許可できる。

本実施例においては、配信条件管理テーブル（３３８）は、予め登録されているものとして説明した。しかし、配信条件管理テーブル（３３８）は、配信システムと外部システムの連携を決定した際に手動で登録および更新してもよいし、外部システムの自動登録の仕組みに連動して自動更新することも有効である。

図７は、配信システム（１０）の設定判断部（３１９）における、配信設定の許可判断処理を示すフローチャートである。即ち、このフローチャートの処理は、配信システム（１０）のＣＰＵ２０１がＨＤＤ２０６やＲＯＭ２０３等に格納されるプログラムを実行することにより実現されるものである。また、このフローチャートに示す処理は、配信設定対象デバイス毎に実行される。

管理サービス２（５０）あるいは管理サービス３（６０）のような管理サービスより、配信設定リクエストのＡＰＩ呼び出しがあると、配信システム（１０）は、Ｓ１０００からの処理を開始する。
Ｓ１００１にて、配信システム（１０）は、ＡＰＩで受け付けた配信設定を仮スケジュールとして登録し、ＡＰＩの呼び出し元には先に応答を返しておく。このステップは、図５，図６の４５２に対応する。

次に、Ｓ１００２にて、配信システム（１０）は、ＡＰＩ呼び出し元のサービスを識別する。ここで識別した情報に従って、表１における「サービス」と一致する行で示される条件を、配信設定許可判断の確認対象とする。

Ｓ１００３では、配信システム（１０）は、配信設定リクエストで指定されたデバイス（配信対象のデバイス）からの最新情報を取得済みであるか否かを判断する。具体的には、対象デバイスにインストールされているアプリの情報、および、有効になっている組み込み機能の情報を取得済みであるか否かを判断する。これらの情報は、例えば図４における４１１、４３８、図５，図６における４５５によって更新される。そして、これらの情報を取得済みであると判断した場合（Ｓ１００３でＹｅｓの場合）、配信システム（１０）は、Ｓ１００８へ処理を進める。Ｓ１００８以降の処理については後述する。

一方、これらの情報を未取得であると判断した場合（Ｓ１００３でＮｏの場合）、配信システム（１０）は、Ｓ１００４へ処理を進める。
Ｓ１００４では、配信システム（１０）は、デバイスからの最新情報（例えば有効機能あるいはインストール済みアプリ情報）の取得を受け付ける。そして、Ｓ１００５において、配信システム（１０）は、デバイスからの最新情報を取得できたか、デバイスから情報を取得できない（最新情報取得待ち）かを判断する。

そして、デバイスから最新情報を取得できていない（最新情報取得待ち）と判断した場合（Ｓ１００５でＹｅｓの場合）、配信システム（１０）は、仮スケジュールした配信予約時刻になったか否かを判断する（Ｓ１００６）。そして、仮スケジュールした配信予約時刻になっていないと判断した場合（Ｓ１００６でＮｏの場合）、配信システム（１０）は、Ｓ１００４に処理を戻す。即ち、仮スケジュールした配信予約時刻になるまで（Ｓ１００６でＹｅｓとなるまで）、デバイスからの最新情報取得を待機する。

そして、仮スケジュールした配信予約時刻よりも前に（Ｓ１００６でＮｏの間に）、デバイスから最新情報を取得できた（最新情報取得待ちでない）と判断した場合（Ｓ１００５でＮｏとなった場合）、配信システム（１０）は、Ｓ１００８に処理を進める。

一方、デバイスから最新情報を取得できないまま（最新情報取得待ちのまま）仮スケジュールした配信予約時刻になった場合（Ｓ１００５でＹｅｓの間にＳ１００６でＹｅｓとなった場合）、配信システム（１０）は、Ｓ１００７へ処理を進める。Ｓ１００７では、配信システム（１０）は、上記Ｓ１００１で仮スケジュールした予約をキャンセルとし、配信設定を解除する。

また、Ｓ１００８では、配信システム（１０）は、デバイスから取得した情報と上述した表１および表２で例示した配信条件情報に基づいて（比較して）、配信設定を許可してよいか否かを判断する。そして、条件に合致するデバイスであり配信設定許可すると判断した場合（Ｓ１００９のＹｅｓの場合）、配信システム（１０）は、Ｓ１０１０に処理を進め、図４の４１７あるいは図５の４５６に示すように、配信設定を確定させる。
一方、条件に合致するデバイスではなく配信設定を許可しないと判断した場合（Ｓ１００９でＮｏの場合）、配信システム（１０）は、Ｓ１００７に処理を進め、仮スケジュールした予約をキャンセルとし、配信設定を解除する。

以下、表３に登録アプリ管理テーブル（３３１）に格納されているアプリの管理情報を例示する。

表３に示すように、アプリの管理情報は、登録ＩＤ、アプリＩＤ、アプリ名、バージョン、ＵＲＬなどの組合せの一覧から成る。あるバージョンの一つのアプリファイルは、「アプリＩＤ」と「バージョン」の組合せで一意に識別され、「ＵＲＬ」に示すコンテンツサーバ（２０）上の記憶場所に格納されている。登録されたアプリの管理情報には一意の登録ＩＤが付与され、管理情報の中で識別できるようになっている。また、ユーザインタフェース上での表示において分かり易いように「アプリ名」を付けることができる。アプリの管理情報は、販売会社システム（３０）から担当者がアプリを登録する際に入力され、更新されることで維持されている。

デバイスにインストールされたアプリをバージョンアップなどで更新する場合、更新可能なバージョンを識別するために、配信システム（１０）は、更新可能なアプリの組合せも管理している。表４に、更新可能アプリ管理テーブル（３３２）に格納されている更新可能なアプリの組合せ管理情報を例示する。

表４に示すように、更新可能アプリの管理情報は、表３に示す管理情報によって管理される登録ＩＤを使用して、更新元（更新前）の登録ＩＤと更新後の登録ＩＤの組合せの一覧から成る。表４に存在する、「更新元」の登録ＩＤと「更新後」の登録ＩＤの組合せが表３に示す管理情報に存在する場合のみ、その登録ＩＤ間での更新が可能であることを示す。更新可能アプリの管理情報は、販売会社システム（３０）から担当者がアプリを登録する際に入力され、更新されることで維持されている。

アプリと同様に、配信システム（１０）は、配信可能なＦＷも管理する。表５に、登録ファームウェア管理テーブル（３３３）に登録されているＦＷの管理情報を例示する。

表５に示すように、ＦＷの管理情報は、デバイスモデル、バージョン、ＵＲＬの組合せの一覧から成る。「デバイスモデル」と「バージョン」の組合せに対応するＦＷのファイルは、「ＵＲＬ」に示すコンテンツサーバ（２０）上の記憶場所に格納されている。ＦＷについてもアプリと同様に、不図示の管理情報によって、更新可能なバージョンの組合せを管理している。ＦＷの管理情報は、販売会社システム（３０）から担当者がＦＷを登録する際に入力され、更新されることで維持されている。

配信システム（１０）は、配信対象となる各デバイスの状態を保持し管理している。デバイスの状態を示す情報の一つとして、各デバイスで動作しているＦＷのバージョン情報がある。表６に、デバイス管理テーブル（３３４）に格納されているデバイス管理情報を例示する。

表６に示すように、デバイスの管理情報は、デバイスＩＤ、デバイスモデル、バージョン、顧客名、および各種機能の有効フラグなどの組合せの一覧から成る。「モデル」は、デバイスＩＤで識別されるデバイスのモデルである。「バージョン」は、そのデバイスで現在動作しているＦＷのバージョンを示す。「顧客名」は、そのデバイスを所有する顧客名である。「機能Ａ」、「機能Ｂ」、「機能Ｃ」は、それぞれ各デバイスで有効になっている機能を示す（有効は「ＯＮ」、無効は「ＯＦＦ」で示す）。これらの機能は、表２における「Ｅｍｂｅｄ」タイプのコンテンツに対応する。

デバイスの状態を示すもう一つの情報として、各デバイスにインストールされているアプリとその状態の情報がある。表７に、インストール済みアプリ管理テーブル（３３５）に格納されているデバイスのインストール済みアプリ情報を例示する。

表７に示すように、インストール済みアプリ情報は、デバイスＩＤ、アプリＩＤ、バージョン、動作状態、ライセンス残数、残数対応などの組合せの一覧から成る。「デバイスＩＤ」と「アプリＩＤ」、「バージョン」の組合せによって、「デバイスＩＤ」に示すデバイスに「アプリＩＤ」と「バージョン」の組合せが示すアプリがインストールされていることを示している。また、そのアプリの動作状態を「動作状態」が示している。「残数対応」は、ライセンス残数の情報が有効な場合には「ＴＲＵＥ」、ライセンス残数の情報が無効な場合には「ＦＡＬＳＥ」となるフラグである。ライセンス残数は、そのデバイスにおけるアプリのライセンス残数を示している。「残数対応」が「ＦＡＬＳＥ」の場合には、ライセンス残数の値は使用しない。

表８に、コンテンツ配信管理テーブル（３３６）に格納されている、コンテンツの配信情報の例を示す。

管理サービスからのリクエストでコンテンツの配信設定が登録されると、表８に示すような、コンテンツ配信情報が更新されて、配信設定のレコードが追加される。コンテンツ配信情報は、配信ＩＤ、デバイスＩＤ、タイプ、コンテンツＩＤ、バージョン、配信日時、仮設定などの組合せの一覧から成る。「配信ＩＤ」は、残りの列の組合せで配信設定が追加される時に一意の識別子を生成して設定する。「配信ＩＤ」は、図４の４１９および図５の４５８でデバイスに返却され、図４の４３１でデバイスから配信設定を特定するために指定される。

「タイプ」は、ＦＷかアプリかの種別を表す。「コンテンツＩＤ」は、アプリの場合、アプリのＩＤを表す。配信設定が仮スケジュールされている場合には、「仮設定」が「ＹＥＳ」となり、配信設定が確定すると、「仮設定」が「ＮＯ」に更新される。なお、配信が完了するか、配信設定がキャンセルされると、該当レコードが削除される。

以上、述べたように、配信システム（１０）以外のシステム、例えば管理サービス２（５０）から配信システムにおける対象デバイスへのコンテンツ配信設定を行う場合、対象デバイスから取得した情報に基づいて配信設定の許可を判断する。これにより、配信システムに配信設定をリクエストしたシステムが配信設定管理の対象としていないデバイスおよびデバイスのコンテンツを不適切に更新する状況を防ぐことができるようになった。一方、表１、表２のような配信条件管理テーブルを使用して条件を保持することにより、配信システムが信頼できるシステム（例えば管理サービス３（６０））については任意のコンテンツの配信設定を許可する等、柔軟な判断を行うことが可能である。

また、本実施例に示す配信条件管理テーブルを用いれば、表１の３行目に例示するように、アプリや機能の排他的な状況を設定できる。このため、この例で言えば「ＥＲＤＳ」に関連付けられたサービスからの配信設定を優先する、というような条件を設定することも可能となる。

以上説明したように、本実施例の配信システム（１０）は、配信設定を行う外部システム（例えば管理サービス２（５０））の識別情報と、配信設定対象デバイスから取得した情報に基づいて配信設定を無効化して、外部システムが管理対象としていないデバイスに対する配信設定がされないようにリクエスト受付の制御を行うことができる。
従って、配信システム（１０）に配信設定をリクエストしたシステム（外部サービス等）が、配信設定管理の対象としていないデバイスおよびデバイスのコンテンツを不適切に更新する状況を防ぐことができる。

なお、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されていてもよい。
以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施態様をとることが可能である。具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
また、上記各実施例を組み合わせた構成も全て本発明に含まれるものである。

（その他の実施例）
本発明は、上述の実施例の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。
本発明は上記実施例に限定されるものではなく、本発明の趣旨に基づき種々の変形（各実施例の有機的な組合せを含む）が可能であり、それらを本発明の範囲から除外するものではない。即ち、上述した各実施例及びその変形例を組み合わせた構成も全て本発明に含まれるものである。

Claims (7)

1. デバイスを管理する１以上のサービスから配信設定の要求に従ってデバイスへのコンテンツの配信を制御する配信システムであって、
   ネットワークを介して通信可能なサービスから前記コンテンツの配信設定の要求を受け付ける第１受付手段と、
   前記第１受付手段によりコンテンツの配信設定の要求を受け付けた場合、該配信設定を許可するか否かを、該配信設定を要求したサービスの情報、該配信設定でコンテンツを配信する対象となるデバイスの状態、及び、予め設定されている配信条件に基づいて判断する判断手段と、
   前記判断手段により前記配信設定を許可すると判断された場合には該配信設定を確定し、前記配信設定を許可しないと判断された場合には該配信設定をキャンセルする制御を行う制御手段と、
   を有することを特徴とする配信システム。
2. ネットワークを介してユーザインタフェースを提供してユーザからの配信設定を受け付ける第２受付手段と、
   自身の管理対象のデバイス群からＷｅｂクライアントにて指定させたデバイスのリストを前記配信システムに対して送信し、該Ｗｅｂクライアントのアクセス先を前記第２受付手段が提供するユーザインタフェースに導き、該デバイスのリストで指定されたデバイスを配信対象とするコンテンツの配信設定を該ユーザインタフェースから入力可能にする連携機能を有する特定のサービスから、前記デバイスのリストを受け取るデータ共有手段と、を有し、
   前記制御手段は、前記第２受付手段によりコンテンツの配信設定を受け付けた場合には、前記判断手段による判断を行うことなく、該配信設定を確定することを特徴とする請求項１に記載の配信システム。
3. 前記配信条件は、サービスごとに、該サービスからの配信設定を許可する又は許可しないデバイスの状態とコンテンツの情報とを組み合わせた条件であり、
   前記判断手段は、前記配信設定を要求したサービスの情報、該配信設定で配信対象とするデバイスの状態、及び該配信設定で配信するコンテンツの情報の組み合わせと、前記配信条件とを比較して、前記判断を行うことを特徴とする請求項１又は２に記載の配信システム。
4. 前記デバイスの状態は、該デバイスにおけるコンテンツのインストール状態を含むことを特徴とする請求項１乃至３のいずれか１項に記載の配信システム。
5. 前記デバイスの状態は、該デバイスにおける機能の有効化の状態を含むことを特徴とする請求項１乃至４のいずれか１項に記載の配信システム。
6. 前記判断手段は、前記第１受付手段により受け付け配信設定で指定された日時までに、前記デバイスの状態を取得できない場合には、前記配信設定を許可しないと判断することを特徴とする請求項１乃至６のいずれか１項に記載の配信システム。
7. デバイスを管理する１以上のサービスから配信設定の要求に従ってデバイスへのコンテンツの配信を制御する配信システムの制御方法であって、
   ネットワークを介して通信可能なサービスから前記コンテンツの配信設定の要求を受け付ける受付ステップと、
   前記受付ステップによりコンテンツの配信設定の要求を受け付けた場合、該配信設定を許可するか否かを、該配信設定を要求したサービスの情報、該配信設定でコンテンツを配信する対象となるデバイスの状態、及び、予め設定されている配信条件に基づいて判断する判断ステップと、
   前記判断ステップにより前記配信設定を許可すると判断された場合には該配信設定を確定し、前記配信設定を許可しないと判断された場合には該配信設定をキャンセルする制御を行う制御ステップと、
   を有することを特徴とする配信システムの制御方法。

Images