(57)【要約】      （修正有）【課題】公開日が予め定められたコンテンツに対し、コンテンツの安定配信及び一斉公開を実現する。【解決手段】コンテンツＩＤと配信済みバージョン情報を提示したコンテンツ送信要求の受信部と、コンテンツの配信処理と公開処理の可否を判断する判断部と、コンテンツ配信の集中を防止する配信制御部と、コンテンツ公開日に基いてコンテンツ公開を調整する公開制御部と、端末装置にコンテンツ応答を送信する送信部を備え、コンテンツＩＤ毎のバージョン情報と公開日情報とを含むコンテンツ管理テーブルを参照可能なコンテンツ配信サーバで、判断部が端末装置からの配信済みバージョン情報よりもコンテンツ管理テーブルのバージョン情報の方が新しく、公開日情報がシステム日時と一致又は以前であると判断した場合、公開制御部が公開処理を実行し、公開日情報がシステム日時以降であると判断した場合、配信状態管理テーブルの状態を公開要求に更新する。【選択図】図６
2013074436.tif 000002
【特許請求の範囲】
【請求項１】
端末装置からの、コンテンツＩＤと配信済みバージョン情報とを提示したコンテンツ配信要求と公開要求とを受信する受信部と、コンテンツ配信要求と公開要求されたコンテンツの、配信処理、公開処理の可否を判断する判断部と、コンテンツ配信を制御し、コンテンツ配信の集中を防止する配信制御部と、コンテンツ公開日を制限し、コンテンツ公開を調整する公開制御部と、端末装置にコンテンツ応答を送信する送信部と、を備え、コンテンツＩＤ毎のバージョン情報と公開日情報とを含むコンテンツ管理テーブルを参照可能なコンテンツ配信サーバであって、
前記判断部は、
配信要求の際に、前記端末装置からの前記配信済みバージョン情報と前記コンテンツ管理テーブルのバージョン情報とを比較し、前記配信済みバージョン情報よりも前記コンテンツ管理テーブルのバージョン情報の方が新しいと判断した場合にコンテンツを配信し、
公開要求の際に、
前記コンテンツ管理テーブルの公開日情報がシステム日時と一致又は以前であると判断した場合には、前記公開制御部が前記コンテンツの公開処理を実行し、
公開要求の際に、
前記コンテンツ管理テーブルの公開日情報がシステム日時以降であると判断した場合には、前記公開制御部が前記コンテンツの配信状態を管理する配信状態管理テーブルの状態を公開要求に更新することを特徴とするコンテンツ配信サーバ。
【請求項２】
さらに、コンテンツの配信負荷の上限値と、該当する前記端末装置の配信負荷をコンテンツ配信開始毎に現在の負荷値に加算し、コンテンツ配信終了毎に現在値から減算することで更新される現在の負荷値と、を有する配信負荷管理テーブルを参照可能であり、
前記判断部は、
前記現在の負荷値に、配信候補のコンテンツの配信負荷を加算した値が、前記上限値以下と判断した場合には、当該配信候補のコンテンツの配信をするとともに、前記配信負荷管理テーブルの現在値を、該当する前記端末装置の配信負荷を加算した値で更新し、
前記現在の負荷値に、配信候補のコンテンツの配信負荷を加算した値が、前記上限値より大きいと判断した場合には、前記配信制御部が、前記配信状態管理テーブルの状態を「配信要求」に更新して「配信制限」することを特徴とする請求項１に記載のコンテンツ配信サーバ。
【請求項３】
前記受信部による前記端末装置からのコンテンツ配信要求の受信に応じて、前記判断部と、前記配信制御部と、前記公開制御部と、における一連の処理が行われることを特徴とする請求項１又は２に記載のコンテンツ配信サーバ。
【請求項４】
配信済みバージョン情報を提示したコンテンツの送信要求を定期的に行う端末装置と、
前記端末装置からのコンテンツＩＤと配信済みバージョン情報とを提示したコンテンツ配信要求と公開要求とを受信する受信部と、コンテンツ配信要求と公開要求とがなされたコンテンツの、配信処理、公開処理の可否を判断する判断部と、コンテンツ配信を制御し、コンテンツ配信の集中を防止する配信制御部と、コンテンツ公開日を制限し、コンテンツ公開を調整する公開制御部と、端末装置にコンテンツ応答を送信する送信部と、を備え、コンテンツＩＤ毎のバージョン情報と公開日情報とを含むコンテンツ管理テーブルを参照可能なコンテンツ配信サーバと、
を有するコンテンツ配信システムであって、
前記判断部は、配信要求の際に、前記端末装置からの前記配信済みバージョン情報と前記コンテンツ管理テーブルのバージョン情報とを比較し、前記配信済みバージョン情報よりも前記コンテンツ管理テーブルのバージョン情報の方が新しいと判断した場合にコンテンツを配信し、
公開要求の際に、
前記コンテンツ管理テーブルの公開日情報がシステム日時と一致又は以前であると判断した場合には、前記公開制御部が前記コンテンツの公開処理を実行し、
公開要求の際に、
前記コンテンツ管理テーブルの公開日情報がシステム日時以降であると判断した場合には、前記公開制御部が前記コンテンツの配信状態を管理する配信状態管理テーブルの状態を公開要求に更新することを特徴とするコンテンツ配信システム。
【請求項５】
端末装置からのコンテンツＩＤと、配信済みバージョン情報を提示したコンテンツ送信配信要求と公開要求とを受信する受信部と、コンテンツ配信要求と公開要求とがなされたコンテンツの、配信処理、公開処理の可否を判断する判断部と、コンテンツ配信を制御し、コンテンツ配信の集中を防止する配信制御部と、コンテンツ公開日を制限し、コンテンツ公開を調整する公開制御部と、端末装置にコンテンツ応答を送信する送信部と、を備え、コンテンツＩＤ毎のバージョン情報と公開日情報とを含むコンテンツ管理テーブルを参照可能なコンテンツ配信サーバにおけるコンテンツ配信方法であって、
前記端末装置からのコンテンツ配信要求を前記受信部が受信するステップと、
前記受信するステップに応じて、コンテンツ送信要求されたコンテンツの、配信処理、公開処理の可否を、前記端末装置からの配信要求の際に、前記端末装置からの前記配信済みバージョン情報と前記コンテンツ管理テーブルのバージョン情報とを比較することで判断するステップと、
前記配信済みバージョン情報よりも前記コンテンツ管理テーブルのバージョン情報の方が新しいと判断した場合にコンテンツを配信し、公開要求の際に前記コンテンツ管理テーブルの公開日情報がシステム日時と一致又は以前であると判断した場合には、前記公開制御部が、前記コンテンツの公開処理を実行し、公開要求の際に前記コンテンツ管理テーブルの公開日情報がシステム日時以降であると判断した場合には、前記公開制御部が、前記コンテンツの配信状態を管理する配信状態管理テーブルの状態を公開要求に更新するステップと、を有することを特徴とするコンテンツ配信方法。
【請求項６】
請求項５に記載のコンテンツ配信方法をコンピュータに実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンテンツ配信技術に関し、特に、端末からのコンテンツ要求に対して、コンテンツ配信・公開サービスをコンテンツサーバで実行するコンテンツ配信システムに関する。
【背景技術】
【０００２】
スマートフォン等の小型無線通信端末の飛躍的な普及が進み、例えば、アパレル・化粧品等の小売専門店では、各店舗の商品カタログをタブレット端末等の無線通信端末（以下、単に、「端末」と称する。）を店舗に設置してこれで商品カタログの代替にしようとする傾向が強くなっている。
【０００３】
このような場合に、商品カタログはコンテンツサーバから配信されるサーバコンテンツとして扱われるが、アパレル・化粧品等の小売専門店の取り扱う商品は、流行性が強いため、季節やその年の流行などにより、取扱商品のラインナップが一変するのが一般的である。そこで、端末からは定期的なコンテンツ要求（問い合わせ）が行われ、コンテンツ要求に応じて、商品ラインナップがコンテンツサーバから配信される。
【０００４】
端末がコンテンツ更新を検知すると、系列各店舗に設けられている多くの端末からのコンテンツ要求が集中しがちであり、コンテンツサーバでのコンテンツ配信が集中するため、通信トラフィックの混雑、もしくは、サーバ過負荷の状態となりサーバが動作不安定に陥る可能性がある。
【０００５】
そこで、コンテンツ要求が集中した場合でも安定してコンテンツ配信できるシステムが提案されている。
【０００６】
図８は、このコンテンツ配信システムの構成例を示す図である。図８に示すように、定期的にコンテンツ要求する端末801、端末801からの要求を受信、応答を送信するオンラインインタフェースであるサービスインターフェース部811とコンテンツ処理部812とを備えたコンテンツサーバ810と、端末801からのコンテンツ要求をサービスインターフェース部811が受信した時点でコンテンツ配信が可能かどうかの情報、つまり、端末毎のコンテンツ配信可能日時を格納するスケジュール管理テーブル821を備えたデータベース820と、から構成される。
【０００７】
このような構成のコンテンツ配信システムにおいては、端末801のコンテンツ要求に対するコンテンツ配信は、スケジュール管理テーブル821によって制御される。コンテンツ要求が時期的に集中した場合でも、特定の時点における同時コンテンツ配信数は抑えることができるため、サーバ負荷を配信スケジュール内で分散することができ、安定してコンテンツを配信させることができる。
【０００８】
本発明に関連する公知技術文献としては下記特許文献１、特許文献２、特許文献３があげられる。
【０００９】
小売専門店では、出店形態（単独出店、商店街、百貨店等）、出店地区（都心、郊外等）により利用可能な無線通信環境が異なるため、各端末の通信速度は様々となる。また、季節商品の入替え等、コンテンツ公開日は予め定められており、全端末一斉に公開開始する必要がある。
【００１０】
下記特許文献１、特許文献３のコンテンツ配信方法では、コンテンツ配信毎に各々の端末の通信環境を考慮し、複雑な配信スケジュールを作成するものである。
【００１１】
特許文献２の負荷分散方法では、配信スケジュールによるコンテンツ配信制御は、端末の負荷レベルを考慮した負荷分散で補うことができる。
【先行技術文献】
【特許文献】
【００１２】
【特許文献１】特開２００７−２０８７４４号公報
【特許文献２】特開２０１１−４３９６８号公報
【特許文献３】特開２０１１−９５８９９号公報
【発明の概要】
【発明が解決しようとする課題】
【００１３】
ところで、小売専門店では、出店形態（単独出店、商店街、百貨店等）、出店地区（都心、郊外等）により利用可能な無線通信環境が異なるため、各端末の通信速度は様々となる。また、季節商品の入替え等、コンテンツ公開日は予め定められており、全端末一斉に公開開始する必要がある。
【００１４】
このため、特許文献１、特許文献３のコンテンツ配信方法では、コンテンツ配信毎に各々の端末の通信環境を考慮し、複雑な配信スケジュールを作成する必要があり、管理者の運用作業負荷が増加する。また、コンテンツ配信完了が、コンテンツ公開開始となるため、端末によってコンテンツ公開開始時間に差が生じる。
【００１５】
これは、コンテンツサーバの増強、増設という、コンテンツ配信装置の増強により補うことができる。しかし、コンテンツ配信装置の増強は、マス向けのリアルタイムなコンテンツ配信には有効だが、更新頻度が比較的小さく、公開日が予め定められたコンテンツ配信については、費用対効果が小さいという問題がある。
【００１６】
また、端末毎に、それぞれの端末システムが有するタイマは、諸事情により、ずれが生じる場合がある。
【００１７】
また特許文献２の負荷分散方法では、負荷レベルによりサーバ資源が確保されるため、特定負荷レベルが実行されていない場合、対応するサーバ資源が有効活用されないという問題がある。
【００１８】
本発明の目的は、公開日が予め定められたコンテンツに対し、配信スケジュールを作成することなく、コンテンツの安定配信及び一斉公開を実現することができる、コンテンツ配信・公開技術を提供することにある。
【課題を解決するための手段】
【００１９】
本発明の一観点によれば、端末装置からの、コンテンツＩＤと配信済みバージョン情報とを提示したコンテンツ配信要求と公開要求とを受信する受信部と、コンテンツ配信要求と公開要求されたコンテンツの、配信処理、公開処理の可否を判断する判断部と、コンテンツ配信を制御し、コンテンツ配信の集中を防止する配信制御部と、コンテンツ公開日を制限し、コンテンツ公開を調整する公開制御部と、端末装置にコンテンツ応答を送信する送信部と、を備え、コンテンツＩＤ毎のバージョン情報と公開日情報とを含むコンテンツ管理テーブルを参照可能なコンテンツ配信サーバであって、前記判断部は、配信要求の際に、前記端末装置からの前記配信済みバージョン情報と前記コンテンツ管理テーブルのバージョン情報とを比較し、前記配信済みバージョン情報よりも前記コンテンツ管理テーブルのバージョン情報の方が新しいと判断した場合にコンテンツを配信し、公開要求の際に前記コンテンツ管理テーブルの公開日情報がシステム日時と一致又は以前であると判断した場合には、前記公開制御部が前記コンテンツの公開処理を実行し、公開要求の際に前記コンテンツ管理テーブルの公開日情報がシステム日時以降であると判断した場合には、前記公開制御部が前記コンテンツの配信状態を管理する配信状態管理テーブルの状態を公開要求に更新することを特徴とするコンテンツ配信サーバが提供される。
【００２０】
これにより、コンテンツ配信タイミングを、端末からのコンテンツ配信要求に応じてそのタイミングで一律に配信するのではなく、バージョン情報に基づいてコンテンツ配信対象のフィルタリングを行うとともに、公開日を規定する公開日情報と、コンテンツサーバのシステム日時と、に基づいて公開時期を規定することができるため、公開日までに端末に事前配信し、公開日に配信済コンテンツを一斉公開するようにすることができる。この際、予め配信スケジュールを作成することなく、コンテンツの安定配信及び一斉公開を実現することができる。また、システム日時を基準にして公開制御を行うため、各端末装置が保有するタイマの日時にばらつきがあったとしても、コンテンツの公開はほぼ一律に行われる。
【００２１】
さらに、コンテンツの配信負荷の上限値と、該当する前記端末装置の配信負荷をコンテンツ配信開始毎に現在の負荷値に加算し、コンテンツ配信終了毎に現在値から減算することで更新される現在の負荷値と、を有する配信負荷管理テーブルを参照可能であり、前記判断部は、前記現在の負荷値に、配信候補のコンテンツの配信負荷を加算した値が、前記上限値以下と判断した場合には、当該配信候補のコンテンツを配信するとともに、前記配信負荷管理テーブルの現在値を、該当する前記端末装置の配信負荷を加算した値で更新し、前記現在の負荷値に、配信候補のコンテンツの配信負荷を加算した値が、前記上限値より大きいと判断した場合には、前記配信制御部が、前記配信状態管理テーブルの状態を「配信要求」に更新して「配信制限」することが好ましい。
【００２２】
前記受信部による前記端末装置からのコンテンツ配信要求の受信に応じて、前記判断部と、前記配信制御部と、前記公開制御部と、における一連の処理が行われることが好ましい。
【００２３】
また、本発明は、配信済みバージョン情報を提示したコンテンツの送信要求を定期的に行う端末装置と、前記端末装置からのコンテンツＩＤと配信済みバージョン情報とを提示したコンテンツ配信要求と公開要求とを受信する受信部と、コンテンツ配信要求と公開要求とがなされたコンテンツの、配信処理、公開処理の可否を判断する判断部と、コンテンツ配信を制御し、コンテンツ配信の集中を防止する配信制御部と、コンテンツ公開日を制限し、コンテンツ公開を調整する公開制御部と、端末装置にコンテンツ応答を送信する送信部と、を備え、コンテンツＩＤ毎のバージョン情報と公開日情報とを含むコンテンツ管理テーブルを参照可能なコンテンツ配信サーバであって、前記判断部は、配信要求の際に、前記端末装置からの前記配信済みバージョン情報と前記コンテンツ管理テーブルのバージョン情報とを比較し、前記配信済みバージョン情報よりも前記コンテンツ管理テーブルのバージョン情報の方が新しいと判断した場合にコンテンツを配信し、公開要求の際に前記コンテンツ管理テーブルの公開日情報がシステム日時と一致又は以前であると判断した場合には、前記公開制御部が前記コンテンツの公開処理を実行し、公開要求の際に前記コンテンツ管理テーブルの公開日情報がシステム日時以降であると判断した場合には、前記公開制御部が前記コンテンツの配信状態を管理する配信状態管理テーブルの状態を公開要求に更新することをコンテンツ配信サーバと、を有することを特徴とするコンテンツ配信システムである。
【００２４】
本発明の他の観点によれば、端末装置からのコンテンツＩＤと、配信済みバージョン情報を提示したコンテンツ送信配信要求と公開要求とを受信する受信部と、コンテンツ配信要求と公開要求とがなされたコンテンツの、配信処理、公開処理の可否を判断する判断部と、コンテンツ配信を制御し、コンテンツ配信の集中を防止する配信制御部と、コンテンツ公開日を制限し、コンテンツ公開を調整する公開制御部と、端末装置にコンテンツ応答を送信する送信部と、を備え、コンテンツＩＤ毎のバージョン情報と公開日情報とを含むコンテンツ管理テーブルを参照可能なコンテンツ配信サーバにおけるコンテンツ配信方法であって、前記端末装置からのコンテンツ配信要求を前記受信部が受信するステップと、前記受信するステップに応じて、コンテンツ送信要求されたコンテンツの、配信処理、公開処理の可否を、前記端末装置からの配信要求の際に、前記端末装置からの前記配信済みバージョン情報と前記コンテンツ管理テーブルのバージョン情報とを比較することで判断するステップと、前記配信済みバージョン情報よりも前記コンテンツ管理テーブルのバージョン情報の方が新しいと判断した場合にコンテンツを配信し、公開要求の際に前記コンテンツ管理テーブルの公開日情報がシステム日時と一致又は以前であると判断した場合には、前記公開制御部が、前記コンテンツの公開処理を実行し、公開要求の際に前記コンテンツ管理テーブルの公開日情報がシステム日時以降であると判断した場合には、前記公開制御部が、前記コンテンツの配信状態を管理する配信状態管理テーブルの状態を公開要求に更新することを特徴とするコンテンツ配信方法が提供される。
【００２５】
本発明は、コンテンツ配信方法をコンピュータに実行させるためのプログラム、当該プログラムを記録するコンピュータ読み取り可能な記録媒体であっても良い。
【発明の効果】
【００２６】
本発明のコンテンツ配信技術によれば、次のような効果がある。
公開日が予め定められたコンテンツに対し、配信負荷を考慮した配信制御のもとで公開日までに事前配信し、公開日に配信済コンテンツを一斉公開することで、配信スケジュールを作成することなく、コンテンツの安定配信及び一斉公開を実現することができる。
【図面の簡単な説明】
【００２７】
【図１Ａ】本発明の一実施の形態によるコンテンツ配信システムの一構成例を示す図である。
【図１Ｂ】本発明の一実施の形態によるコンテンツ配信サーバの一構成例を示す機能ブロック図である。
【図２】コンテンツを管理するコンテンツ管理テーブルの一構成例を示す図である。
【図３】端末を管理する端末管理テーブルの一構成例を示す図である。
【図４】コンテンツ配信状態を管理する配信状態管理テーブルの一構成例を示す図である。
【図５】コンテンツ配信負荷を管理する配信負荷管理テーブルの一構成例を示す図である。
【図６】コンテンツ配信・公開サービスのインタフェース処理の内容を示す図である。
【図７】コンテンツ要求・応答の処理シーケンス図及び配信状態の遷移図である。
【図８】従来のコンテンツ配信システムの構成例を示す図である。
【発明を実施するための形態】
【００２８】
以下、本発明の一実施の形態によるコンテンツ配信技術について、図面を参照しながら詳細に説明する。
図１Ａは、本発明の一実施の形態によるコンテンツ配信システムの一構成例を示す機能ブロック図である。図１Ａに示すように、本実施の形態によるコンテンツ配信システムＡは、店舗等に設けられ、定期的にコンテンツを要求する端末101と、端末101のコンテンツ配信状態を表示する管理端末102と、端末101からの要求を受信、応答を送信するオンラインインタフェースであるサービスインターフェース部111とコンテンツ処理部112とを備えたコンテンツサーバ110と、サービスインターフェース部111で受信・送信するコンテンツ配信の情報を格納するデータベース120と、から構成される。
【００２９】
データベース120は、コンテンツ情報を格納するコンテンツ管理テーブル121、端末情報を格納する端末管理テーブル122、コンテンツ配信状態の情報を格納する配信状態管理テーブル123、コンテンツ配信負荷の情報を格納する配信負荷管理テーブル124を格納し、また、テーブルの管理、更新処理などを行う処理部125を有している。端末101からのコンテンツ要求の内容により、サービスインターフェース部111が配信状態管理テーブル123を更新する。また、サービスインターフェース部111が配信状態管理テーブル123を参照することで、管理端末102は、端末101のコンテンツ配信状態を確認することができる。
【００３０】
図１Ｂは、図１Ａでは、サービスインターフェース部111とコンテンツ処理部112とで簡単に示したコンテンツサーバ110の詳細な構成例を示す機能ブロック図である。図１Ｂに示すように、コンテンツサーバ110は、複数の端末101からコンテンツ要求を受信する受信部110-1と、コンテンツ要求により、配信処理、公開処理を判断する判断部110-2と、コンテンツ配信を制限し、コンテンツ配信の集中を防止する配信制御部110-3と、コンテンツ公開日を制限し、コンテンツ公開を調整する公開制御部110-4と、端末101にコンテンツ応答を送信する送信部110-5と、端末101のコンテンツ配信状態を管理するコンテンツ配信状態管理部110-6と、コンテンツ配信状態を端末に照会する配信状態照会部110-7とを備えている。
【００３１】
次に、データベース120内に格納されるコンテンツ管理テーブル121の内容の一例について説明する。
図２に示すコンテンツ管理テーブル121には、コンテンツID201、コンテンツ名称202、コンテンツのバージョン情報203、コンテンツの公開日情報204が含まれており、バージョン情報203は、コンテンツの最新バージョン、公開日情報204はコンテンツの最新バージョンを公開開始する日時の情報である。
【００３２】
コンテンツID201は、コンテンツ管理テーブル121でレコードを一意に決定するキー項目である。コンテンツ管理テーブル121は例えば管理者によって更新され、配信コンテンツを更新する場合、バージョン情報203と公開日情報204とをあわせて更新する。
【００３３】
以下、データベース120の端末管理テーブル122の内容の例について説明する。
図３は、端末を管理する端末管理テーブル122の一構成例を示す図であり、端末ID301、店舗コード302、配信負荷303とを有している。店舗コード302は、端末を設置している店舗の店舗コードであり、配信負荷303は、コンテンツ配信における通信負荷度（例えば10:高速通信〜1:低速通信など、数値で表しても良い。）の情報である。
【００３４】
端末ID301は、端末管理テーブル122でレコードを一意に決定するキー項目である。端末管理テーブル122は、例えば管理者によって更新され、端末101を店舗に設置する場合、レコードを追加する。配信負荷303は、端末101の通信方式等により値を設定する。
【００３５】
以下、データベース120内の配信状態管理テーブル123の内容の一例について説明する。
図４は、配信状態を管理する配信状態管理テーブル123の一例を示す図であり、端末ID401、コンテンツID402、状態403、配信済バージョン404、公開済バージョン405から構成される。端末ID401は、端末管理テーブル122の端末ID301、コンテンツID402はコンテンツ管理テーブル121のコンテンツID201、状態403は配信状態（配信要求、配信開始、公開要求、公開開始、公開完了）、配信済バージョン404は配信が完了しているコンテンツのバージョンであり、公開済バージョン405は、端末101で公開完了しているコンテンツのバージョンの情報である。
【００３６】
端末ID401とコンテンツID402とは、配信状態管理テーブル123でレコードを一意に決定するための複合キー項目（組）である。配信状態管理テーブル123は、コンテンツサーバ110のサービスインターフェース部111によって更新され、状態403、配信済バージョン404、公開済バージョン405によって、特定の端末、特定のコンテンツの配信状態を確認することができる。
【００３７】
以下、データベース120の配信負荷管理テーブル124の内容の一例について説明する。
図５は、配信負荷を管理する配信負荷管理テーブル124の一構成例を示す図であり、配信負荷（通信負荷）の上限値501と、配信負荷（通信負荷）の現在値502とから構成される。上限値501は、システム全体での通信負荷度の合計値の上限値であり、現在値502は通信負荷度の現在の合計値の情報である。ここでは、上限値501が30であり、現在値502が21となっており、負荷に余裕がある状態であることが示されている。
【００３８】
配信負荷管理テーブル124は、該当する端末に対応する端末管理テーブル122の配信負荷303をコンテンツ配信開始毎に現在値に加算し、コンテンツ配信終了毎に現在値から減算することで、コンテンツサーバ110のサービスインターフェース部111によって更新される。特許文献２に記載されているテーブルでは、例えば、高負荷、中負荷、低負荷のサーバ毎の上限値と、現在値との値を有しており、ハードウェアの上限負荷毎の現在値との比較により負荷分散をしていたが、図５のようにシンプルなテーブルにすることで、無駄を省くことができるようになった。
【００３９】
以下、コンテンツサーバ110のサービスインターフェース部111のコンテンツ配信・公開方式の一例について説明する。
図６は、コンテンツ配信・公開サービスの処理内容等を示すインタフェース情報であり、引数600、戻り値610、処理内容620から構成される。
【００４０】
引数600は、端末ID601、コンテンツID602、配信済バージョン603、公開済バージョン604で構成され、端末ID601は端末管理テーブル122の端末ID301であり、コンテンツID602はコンテンツ管理テーブル121のコンテンツID201であり、配信済バージョン603は配信完了しているコンテンツのバージョンであり、公開済バージョン604は、端末で公開完了しているコンテンツのバージョンの情報である。戻り値610は、結果611、配信コンテンツURL612から構成され、結果611は、要求結果（配信なし、配信あり、配信制限、公開可、公開不可）、配信コンテンツURL612は、コンテンツアドレスの情報であり、端末101は、要求に基づいて得られたこれらの値を自己のメモリに格納する。
【００４１】
次に、処理内容620を、コンテンツ配信・公開サービスのフローチャート図で説明する。
受信部110-1による受信処理が開始されると、まず、バージョン確認処理621が行われる。
【００４２】
端末ID601、コンテンツID602に対応する配信状態管理テーブル123の配信済バージョン404、公開済バージョン405を、得られた配信済バージョン603、公開済バージョン604で更新する。
【００４３】
（１）配信候補のコンテンツであるコンテンツID602に対応するコンテンツ管理テーブル121のバージョン情報203と配信済バージョン情報603とが等しくないと判断部110-2が判断した場合、コンテンツサーバ110の持っているバージョンの方が新しいため、コンテンツの配信における負荷確認622を行う。
【００４４】
（２）コンテンツID602に対応するコンテンツ管理テーブル121のバージョン203と公開済バージョン604とが等しくないと判断部110-2が判断した場合、公開が可能なコンテンツであるかを確認するため、公開日確認処理624を行う。
【００４５】
（３）上記以外の場合、すなわち、公開済みバージョン、配信済みバージョンの両方ともがコンテンツサーバの保持する公開済みバージョン、配信済みバージョンと等しいと判断部110-2が判断した場合には、配信制御部110-3は、このタイミングで、前回配信され公開されたコンテンツに関して、配信状態管理テーブル123の状態403を「公開完了」に更新し、結果611は、「配信なし」、配信コンテンツURL612は「なし」で、処理を終了する。
【００４６】
バージョン情報確認処理621において、（１）に進む場合には、負荷確認処理622が行われる。
ここでは、まず、配信状態照会部110-7が、端末101から、配信負荷管理テーブル124の上限値501と、現在値502と、端末ID601に対応する端末管理テーブル122の該当する端末の配信負荷303と、を取得する。
【００４７】
（４）ここで、現在値502に配信負荷303を加算した値が、上限値501以下の場合には、この配信を行っても良いことになるので、配信負荷管理テーブル124の現在値502を、配信負荷303を加算した値で更新し、配信処理623に進む。
【００４８】
（５）現在値502に配信負荷303を加算した値が、上限値501より大きいと判断部110-2が判断した場合には、配信すると負荷が上限値を超えてしまうため配信制限が必要となり、配信制御部110-3が、配信状態管理テーブル123の状態403を「配信要求」に更新し、結果611は「配信制限」、配信コンテンツURL612は「なし」で終了する。
【００４９】
配信処理623においては、配信状態管理テーブル123の状態403を「配信開始」に更新し、結果611は「配信あり」、配信コンテンツURL612は「コンテンツアドレス」として処理を終了する。
【００５０】
バージョン確認処理621で、（２）の場合には、公開日確認処理624に進む。
（６）コンテンツID602に対応するコンテンツテーブル管理121の公開日204がサーバシステム日時以下と判断部110-2が判断した場合には、公開制御部110-4は、すぐに公開が可能であり、公開処理625を実行する。
【００５１】
（７）コンテンツID602に対応するコンテンツ管理テーブル121の公開日204がサーバシステム日時より大きいと判断部110-2が判断した場合には、すぐに公開することはできないため、公開制御部110-4は、配信状態管理テーブル123の状態403を「公開要求」に更新し、結果611は「公開不可」、配信コンテンツURL612は「なし」として処理を終了する。
【００５２】
送信部110-5は、端末101にコンテンツ応答を送信する。また、配信状態照会部110-7がコンテンツ配信状態を端末装置に照会し、高負荷になる場合には、配信状態管理部110-6が端末101のコンテンツ配信状態を管理して、配信を抑制したり促したりする。
【００５３】
公開処理625においては、配信状態管理テーブル123の状態403を「公開開始」に更新し、結果611は「公開可」、配信コンテンツURL612は「なし」として処理を終了する。
【００５４】
以下、端末101とコンテンツサーバ110との間における処理の順番について説明する。端末101からコンテンツサーバ110への応答要求は、例えば、１日に１回、１時間に１回、１分に１回など、設定に応じて行われる。応答要求の繰り返し間隔が短いほど、負荷は高まるが、最新の更新情報を得やすくなる。複数の端末101からのコンテンツ要求を受信部110-1が受信する。
【００５５】
図７は、コンテンツ要求・応答の処理のシーケンス図及び配信状態遷移図であり、以下のフローがコンテンツ更新処理毎に繰り返される。
【００５６】
まず、コンテンツ更新処理711前における端末101からコンテンツサーバ110への応答要求が行われても、更新の必要がないため、応答（配信なし）721となる。
【００５７】
コンテンツ更新処理711が行われた後の要求に対しては、応答（配信あり）722となるが、まず、その前に、負荷の問い合わせが行われ、負荷が低いという応答が帰ってくると(722)、以下の処理が行われる。負荷が高い場合には、以下の処理は行われず、ある時間毎の要求に応じて負荷が低くなるのを待つ（負荷確認700）。
【００５８】
状態は、要求時点で配信要求701、応答時点で配信開始702となる。配信されたコンテンツは端末のテンポラリー領域等にコンテンツ格納処理731が実行される。
【００５９】
コンテンツ格納処理731の後であって、コンテンツ公開日712前の要求があった場合には、応答（公開不可）724となる。状態は、要求時点で公開要求703となる。
【００６０】
コンテンツ格納処理731後であって、コンテンツ公開日712後の要求に対しては、応答（公開可）725となる。状態は、応答時点で公開開始704となる。コンテンツ格納731した情報をコンテンツ公開処理732が行われる。
コンテンツ公開処理732後に、状態は、要求時点で公開完了705となる。
図７の処理において、図６のような判断が適宜実行される。
【００６１】
以上に説明したように、本実施の形態によるコンテンツ配信技術によれば、公開日が予め定められたコンテンツに対し、配信負荷を考慮した配信制御のもとで公開日までに事前配信し、公開日に配信済コンテンツを一斉公開するように制御することで、配信スケジュールを予め作成することなく、コンテンツの安定配信及び一斉公開を実現することができる。
【００６２】
尚、上記の実施の形態において、添付図面に図示されている構成等については、これらに限定されるものではなく、本発明の効果を発揮する範囲内で適宜変更することが可能である。その他、本発明の目的の範囲を逸脱しない限りにおいて適宜変更して実施することが可能である。また、本実施の形態で説明した機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより各部の処理を行ってもよい。
【産業上の利用可能性】
【００６３】
本発明は、コンテンツ管理装置として利用可能である。
【符号の説明】
【００６４】
101…端末、102…管理端末、110…コンテンツサーバ、111…サービスインターフェース部、112…コンテンツ処理部、120…データベース、121…コンテンツ管理テーブル、122…端末管理テーブル、123…配信状態管理テーブル、124…配信負荷管理テーブル。
【図１Ａ】
2013074436.tif 000003
【図１Ｂ】
2013074436.tif 000004
【図２】
2013074436.tif 000005
【図３】
2013074436.tif 000006
【図４】
2013074436.tif 000007
【図５】
2013074436.tif 000008
【図６】
2013074436.tif 000009
【図７】
2013074436.tif 000010
【図８】
2013074436.tif 000011