JP2014241146A - 告知双方向通信システム及び視聴者端末 - Google Patents

Abstract

【課題】視聴者がある区域の事業者の告知をどこでもいつでも閲覧できかつ視聴者が希望するコンテンツを効率よく得ることができる告知双方向配信システムを得る。
【解決手段】視聴者端末９００と事業者端末１００とクラウドシステム１０とインターネット網２０で接続して、自治体、告知サービス業者等からの告知登録データを視聴者の端末の種類に係わらず、いつでも、どこでも、誰でもが受信する。ＤＢサーバ４００の一定時間後に表示させる告知をスプレイｗｅｂサーバ１０２０が担当の視聴者端末９００に一斉配信して、一定時間後に告知タイトルを視聴者端末に順次表示させる。そして、ＤＢサーバ４００から、告知タイトルが選択されたとき、予め事業者によって登録されているこの告知タイトルの詳細情報を取り出して、低容量コンテンツ配信ｗｅｂサーバ部１１００を介してその視聴者端末に配信する。
【選択図】図１

Description

本発明は、インターネット網に接続された視聴者端末に対して効率のよい告知を配信する告知双方向通信システムに関する。

情報の伝達をインターネット網を介して双方向通信するサービスはさまざま存在している。企業、大学等は、ｗｗｗサーバ、データベースサーバ等を備えてホームページにユーザからアクセスさせて、ユーザが必要とする情報を提供する双方向通信がある。

そして、双方向通信は、サーバ側が主導権を得て、ユーザの端末に定期的に情報を送信して、ユーザが要求する情報提供する方式と、ユーザがサーバにアクセスして情報を得る方式等がある。

このような双方向通信は、例えば、安否確認、自治体防災情報等にも使用されている。

例えば特許文献１は、受信端末は専用端末を用いている。そして、役場等に備えた配信装置がこれらの専用端末をグループ分けして時刻が来ると該当のグループの専用端末（ブラウザ機能付き）に情報を提供して、専用端末の画面に表示されたボタンの押下を収集して、その押下したボタン種に応じた告知情報を音声で流している。

特許第４８０８３６９号公報

近年は子供が都会で暮らして、親が地方にいる場合が多くなってきている。このため、役場から親の専用端末に提供された情報を都会の子供が常にしっておきたいという要望もある。

一方、近年は多機能携帯電話機（スマートホーン）やタブレット、パソコンを有する方が多くなっている。とうぜん、多機能携帯電話機等で特許文献１で提供する情報を取得したいという希望が出てくる。

しかしながら、特許文献１の方式は、非常に多くの方がアクセスしてきても、直ぐに対応できる方式を採用していないので、遠くにいる方は情報を共有することができない。

また、特許文献１は配信装置を主導にして情報を専用端末に送信して、画面に表示されたボタンを選択させて、その押下を知るのを主とするものであるから、視聴者が希望するコンテンツを得るものではない。

例えば、○○県の○○町の役場からの告知が複数送信されてきても、それらが全て視聴者が必要とするものとは限らない。

従って、視聴者がある区域の事業者の告知をどこでもいつでも閲覧できかつ視聴者が希望するコンテンツを効率よく得ることができる告知双方向配信システムが望ましい。

本発明の告知双方向通信システムは、区域の告知を登録する事業者の事業者端末と、視聴者の視聴者端末と、告知サービスセンターと通信ネットワークで接続した告知双方向通信システムである。

前記告知サービスセンターは、
複数のスプレイサーバを備えたスプレイｗｅｂサーバ部とバッチサーバを備えたバッチサーバ部とで前記視聴者端末へのプッシュルート部を構築して、さらに複数のコンテンツ配信ｗｅｂサーバを備えた低容量コンテンツ信ｗｅｂサーバ部で前記視聴者端末からのアクセスを受け付けるプルルート部を構築し、該プルルート部からはログイン後の各種情報を送信し、前記プッシュルート部からは前記事業者が登録した告知の詳細情報の告知タイトル情報を送信させる告知サービス提供用サーバを接続し、
前記告知サービス提供用サーバは、
前記告知タイトル情報を順次、記憶する告知タイトル情報用記憶手段を前記視聴者端末に生成させる制御データと、
前記視聴者端末に事業者のサービス項目を表示する項目画面と、該サービス項目の詳細を表示する詳細画面とに分割させる制御データと、
前記視聴者端末に項目画面用のメモリ、前記詳細画面用のメモリを生成させる制御データと、
前記サービス項目のフォルダを前記項目画面用のメモリに生成させる制御データと、
前記項目画面の前記サービス項目の選択に伴って、このサービス項目を前記詳細画面用のメモリを介して前記詳細画面に表示させる制御データと、
前記告知タイトル情報用記憶手段の告知タイトル情報を読み込み、該読み込む毎に、前記告知サービスセンタに対して詳細画面を通過しない又は通過するのかどうかの通過有無問合情報を前記詳細画面に表示されているサービス項目名のフォルダＩＤを付加して前記告知サーバセンターに送信させる制御データと、
前記告知サービスセンターから前記通過有無問合情報に対する通過応答結果情報を受信し、該通過応答結果情報が通過しないを示している場合は前記読み込んだ告知タイトル情報の告知タイトルを前記前記詳細画面用のメモリを介して前記詳細画面に表示すると共に、前記読み込んだ告知タイトル情報をこの通過応答結果情報が示すフォルダに格納させる制御データと、
前記通過応答結果情報が通過するを示している場合は、前記読み込んだ告知タイトル情報の告知タイトルを表示させないで、該告知タイトル情報を前記通過応答結果情報に含まれている移動先のサービス項目のフォルダＩＤのフォルダに格納させる制御データと
を前記プルルート部を介して送信する手段を有し、
さらに、
前記告知サービス提供用サーバは、
前記事業者ＩＤと、前記サービス項目名と、前記サービス項目名の詳細画面において前記告知タイトルを通過させる又は通過させないを示す通過有無フラグと、通過する場合の移動先のフォルダＩＤ又は通過しない場合のフォルダＩＤとが対応させられた告知タイトル通過有無情報が記憶された告知タイトル通過有無マスタと、
前記視聴者端末から前記通過有無問合情報を受信した場合は、該通過有無問合情報に含まれている事業者ＩＤ、視聴者ＩＤ、詳細画面に表示されているサービス項目名のＩＤを有する告知タイトル通過有無情報を前記告知タイトル通過有無情報マスタから読み込む手段と、
前記読み込んだ告知タイトル通過有無情報を前記プルルート部で前記視聴者端末に送信する手段と、
を有することを要旨とする。

以上のように本発明によれば、視聴者端末は、いつでもどこでも告知サービス提供センターにアクセスして希望の告知を提供させることができる。

実施の形態１の告知通信システムの概略構成図である。 視聴者端末９００の概略構成図である。 ＤＢサーバ４００の概略プログラム構成図である。 事業者端末側の概略構成図である。 各種マスタテーブルの説明図である。 各種マスタテーブルの説明図である。 各種マスタテーブルの説明図である。 各種マスタテーブルの説明図である。 各種マスタテーブルの説明図である。 各種マスタテーブルの説明図である。 各種マスタテーブルの説明図である。 各種マスタテーブルの説明図である。 本実施の形態の動作を説明するシーケンス図である。 本実施の形態の動作を説明するシーケンス図である。 本実施の形態の動作を説明するシーケンス図である。 本実施の形態の動作を説明するシーケンス図である。 本実施の形態の動作を説明するシーケンス図である。 本実施の形態の動作を説明するシーケンス図である。 本実施の形態の動作を説明するシーケンス図である。 本実施の形態の動作を説明するシーケンス図である。 本実施の形態の動作を説明するシーケンス図である。 本実施の形態の動作を説明するシーケンス図である。 本実施の形態の動作を説明するシーケンス図である。 告知基本情報入力画面の説明図である。 配信先登録画面の説明図である。 配信先フォルダの登録変更画面の説明図である。 配信リスト、告知タイトル情報、視聴者ログの説明図である。 配信リスト、告知タイトル情報、視聴者ログの説明図である。 視聴者端末に表示される項目画面の説明図である。 視聴者端末に表示される告知タイトルの説明図である。 未読リストの説明図である。 視聴者端末に表示される詳細画面、動画画面の説明図である。 本実施の形態２の告知双方向通信システムの概略構成図である。 ＤＢサーバの視聴者毎告知変更処理部４０１の概略構成図である。 視聴者毎告知変更処理部４０１の動作を説明するフローチャートである。 視聴者毎告知変更処理部４０１の動作を説明するフローチャートである。 告知更新を説明する説明図である。 実施の形態２による視聴者端末に表示される詳細画面における告知タイトルの説明図である。 本実施の形態の応用例の概略構成図である。 本実施の形態の応用例の概略構成図である。

本実施の形態の告知双方向通信システムは、自治体、告知サービス業者等（以下総称して事業者という）からの告知登録データを視聴者の端末の種類に係わらず、いつでも、どこでも、誰でもが受信できるシステムであり、クラウドシステム（告知提供サービスセンター部ともいう）に登録した告知登録データをプッシュで視聴者側に配信し、視聴者側はプルでこの告知登録データを取得するように構成している。

なお、事業者とは、本システムの管理業者（ｉｃｏｍ）、料理店、病院、学校、デパート、スーパー、農協、漁業組合等を含むとする。

そして、視聴者は全国とし、これらを区域で分けている（例えばＡ県Ａ市、Ｂ県Ｂ市、東京都Ｃ区、・・）。これらの区域を担当しているのがその区域の事業者である。

また、視聴者が所有する視聴者端末は、スマートホーン、タブレット、パソコン、インターネットインタフェース付きテレビジョン等とする。

＜実施の形態１＞
視聴者が数百万もなる区域には、異なる事業者が複数存在してもかまわないが、実施の形態１ではＡ県のＡ市を一つの区域とし、管理事業者以外は１つの自治体として説明する。

図１は実施の形態１の告知通信システムの概略構成図である。図１に示すように本実施の形態の告知通信システムは、複数の視聴者端末９００（１００００台、１００００００台、・・：図１においては１００００台を例としている）と、クラウドサーバシステム１０（告知提供サービスセンター部）と、管理事業者端末２００と、自治体管理者端末１００とを各々通信ネットワーク２０（例えばインターネット網）で接続している。

クラウドサーバシステム１０は、図１に示すように、バッチサーバ６００と、スプレイ管理ｗｅｂサーバ７００と、スプレイサーバ部１００１（スプレイセッション確立ｗｅｂサーバ１０１０、スプレイサーバ１０２０ａ〜１０２０ｊ））と、バッチサーバ６００と、ＤＢサーバ４００等でプッシュルート部を形成している。

また、ログイン受付・振分ｗｅｂサーバ１０００と、低容量コンテンツ配信ｗｅｂサーバ１１００と、ＤＢサーバ４００などでプルルート部を形成している。

さらに、プルルート部は、大容量コンテンツは真ｗｅｂサーバ１２００（１２００ａ〜１２００ｊ）とストレージサーバ５００を含む。

また、管理者用ｗｅｂサーバ３００と、構成管理ｗｅｂサーバ８００等を有している。

管理者用ｗｅｂサーバ３００は通信ネットワーク２０とスプレイ管理ｗｅｂサーバ７００とストレージサーバ５００に接続されている。

ＤＢサーバ４００は、バッチサーバ６００と構成管理ｗｅｂサーバ８００とストレージサーバ５００と低容量コンテンツ配信ｗｅｂサーバ１１００ａ〜１１００ｊとスプレイｗｅｂサーバ１０２０ａ〜１０２０ｊ等に接続されている。

管理構成ｗｅｂサーバ８００は通信ネットワーク２０とＤＢサーバ４００とストレージサーバ５００に接続されている。つまり、管理事業者端末２００からのアクセスでＤＢサーバ４００、ストレージサーバ５００のメモリの内容の参照及び書き換えを可能とするようになっている。

バッチサーバ５００はＤＢサーバ４００とスプレイ管理ｗｅｂサーバ７００とに接続されている。

スプレイ管理ｗｅｂサーバ７００は管理者用ｗｅｂサーバ３００と各スプレイｗｅｂサーバ１０２０に接続されている。

スプレイサーバ１０２０は、スプレイ管理ｗｅｂサーバ７００とスプレイセッション確立用ｗｅｂサーバ１０１０とＤＢサーバ４００と通信ネットワーク２０等に接続されている。

さらに、ログイン受付・振分ｗｅｂサーバ１０００は通信ネットワーク２０と各低容量コンテンツ配信ｗｅｂサーバ１１００と各大容量コンテンツ配信ｗｅｂサーバ部１２００等に接続されている。

各大容量コンテンツ配信ｗｅｂサーバ部１２００はストレージサーバ５００に接続されている。

そして、このような接続構成にすることで、プッシュ配信とプル配信とを可能としている。

また、視聴者は管理事業者に連絡して会員登録している。

（プッシュ配信の概要）
プッシュ配信は、事業者端末（自治体管理者用端末１００、管理事業者端末２００）からの告知を、管理者用ｗｅｂサーバ３００を介してＤＢサーバ４００に登録し、これをバッチサーバ６００によって一定時間後（例えば15分後に視聴者の画面に表示させる告知）を取り出させてスプレイ管理ｗｅｂサーバ７００を介してスプレイｗｅｂサーバ部１００１に送信し、スプレイｗｅｂサーバ部のスプレイｗｅｂサーバ１０２０がスプレイセッション確立用ｗｅｂサーバ１０１０でセッション確立されている担当の視聴者端末９００に一斉配信して、一定時間後に告知タイトルを視聴者端末に順次表示させる。

（プル配信の概要）
プル配信は、視聴者端末９００からのログインをログイン受付・振分ｗｅｂサーバ１０００が受け付けて、これを低容量コンテンツ配信ｗｅｂサーバ部１１００を介してＤＢサーバ４００に送信して認証させて視聴者端末９００とセッションを確立させる。

そして、ＤＢサーバ４００から、予め記憶されている視聴者端末９００の区域を担当している事業者のメイン項目を取り出して低容量コンテンツ配信ｗｅｂサーバ部１１００を介してその視聴者端末に配信する。

そして、この視聴者端末からメイン項目のいずれかの項目に含まれている告知タイトルが選択されたとき、予め事業者によって登録されているこの告知タイトルの詳細情報を取り出して、低容量コンテンツ配信ｗｅｂサーバ部１１００を介してその視聴者端末に配信する。

また、視聴者端末９００が動画（音声含む）を要求した場合は、ログイン受付・振分ｗｅｂサーバ１０００が大容量コンテンツｗｅｂサーバ部１２００を介してストレージサーバ５００からその動画を取り出して視聴者端末９００に配信する。

（サーバの説明）
スプレイサーバ部１００１のスプレイｗｅｂサーバ１０２０ａ〜１０２０ｊ及び低容量コンテンツ配信ｗｅｂサーバ１１００ａ〜１１００ｊ並びに大容量コンテンツ配信ｗｅｂサーバ１２００ａ〜１２００ｊは、各々が例えば１０００台の視聴者端末９００を担当している。

ＤＢサーバ４００は、後述する制御データを記憶しており、これを視聴者端末９００に送信する機能（手段）、並びに告知タイトル配信処理部４１０と、表示通過判定処理部４２０と、履歴登録処理部４３０と、詳細配信処理部４４０を少なくとも備えている。

告知タイトル配信処理部４１０はプルルート部で配信させる。事業者によって登録された一定時間先の告知タイトル情報（告知ＩＤ、タイトル名、・・）をグループ単位又は視聴者単位でバッチサーバ６００に渡してスプレイサーバ部１００１（スプレイセッション確立ｗｅｂサーバ１０１０、スプレイサーバ１０２０ａ〜１０２０ｊ））から視聴者端末９００に一斉配信する。

表示通過判定処理部４２０は、セッション確立後に低容量コンテンツ配信ｗｅｂサーバ１１００を介して視聴者端末９００から告知タイトルの表示の問い合わせ（通過する、通過しない）があると、この告知タイトルを表示設定条件に基づいて画面に表示させたり、画面に表示させない応答情報を返信する。

履歴登録処理部４３０は、視聴者端末９００の画面操作の状況を受信して、これを登録する（告知タイトルの削除を含む）。

詳細配信処理部４４０は、告知タイトルのタッチ伴ってこの告知タイトルに関連付けて登録している詳細情報を返信する。

管理者用ｗｅｂサーバ３００は、自治体管理者用端末１００又は管理事業者管理端末２００からのアクセスを通信ネットワーク２０を介して受け付けて、ＤＢサーバ４００からこれらの事業者が要求するページを提供すると共に、入力された各種データをＤＢサーバ４００又はスプレイ管理サーバ７００に送信する。

バッチサーバ６００は、一定時間毎にＤＢサーバ４００に登録されている一定時間後に表示させる告知タイトル情報（告知ＩＤ、告知タイトル名、視聴者ＩＤ、表示するまでの時間、アイコンＩＤ）を取り出してこれをスプレイ管理ｗｅｂサーバ７００に送信する。

スプレイ管理ｗｅｂサーバ７００は、スプレイｗｅｂサーバ１０２０ａ〜１０２０ｊがどの視聴者ＩＤの視聴者端末９００に配信するかを把握しており、受信した告知タイトル情報を該当のスプレイｗｅｂサーバ１０２０に送信する。

（視聴者端末９００の構成）
視聴者端末９００（ブラウザ、インターネットインターフェースを有する）はクラウドサーバシステム１０のＤＢサーバ４００からの制御データに基づいて以下に説明するプログラム構成を有する。

図２は視聴者端末９００の概略構成図である。視聴者端末９００はＲＡＭ、ＲＯＭ、ＣＰＵ等を備えており、制御データによって機能する構成をブロック化している。

図２においては視聴者端末９００は、画面を二分割に表示し、左側（紙面の左）にメイン項目画面ＧＢ、右側に詳細画面ＧＡを表示する。

メイン項目画面ＧＢは、区域の配信事業者名ＧＢＡ（○○役場）と、この配信事業者が提供する項目名Ｇｂａ（本日のお知らせＧｂａ１、役場からＧｂａ２、写真・・・ＰＴＡ・・・）を表示させている。また、ｉｃｏｍが提供するメイン項目画面が裏側にある。また、これらの項目には告知詳細情報の未読数（まる数字）が示されている。なお、配信事業者名ＧＢＡ（○○役場）の○数字は、各項目の未読回数の総計である。

さらに、詳細画面ＧＡには、告知タイトルＡｉ（Ａ１、Ａ２・・・）が管理詳細画面ＧＡに表示されている。また、これらの告知タイトルＡｉには削除アイコンＢｉが表示されている。

図２に示すようにメイン項目画面ＧＢは、メイン項目画面用メモリ９２０が対応させられて設けられ、このメイン項目画面用メモリ９２０に保存された情報をブラウザで表示する。

また、詳細画面ＧＡには告知タイトル等を表示するための詳細画面用メモリ９１０が設けられている。

さらに、クラウドサーバシステム１０からの告知タイトル情報を記憶するためのメモリ９３０を備えている。

さらに、メイン項目取得部９５０と、タイトル表示部９８０と、タイマー９７０と、詳細取得部９２０と、タイトル表示有無問合部９８２と、格納配信先フォルダ決定部９８３と、タイトル削除部９９０と、動画取得部９６０等を有する。

メイン項目取得部９５０は、本サイトのＵＲＬでログインページの提供を受けて、ログインＩＤ、パスワードを入力してＵＲＬが示すログイン受付・振分ｗｅｂサーバ１０００にこのログイン情報を送信して、ＤＢサーバ４００（低容量コンテンツ配信ｗｅｂサーバ１１００を介して）からのメイン項目（事業者名、本日のお知らせ、役場から・・）並びに未読リストを受信してこれをメイン項目画面用メモリ９２０に保存する。

メイン項目画面用メモリ９２０への保存にあたってメイン項目取得部９５０はメイン項目画面用メモリ９２０に事業者名のフォルダ（大配信先フォルダ９４０とも称する）を生成し、この大配信先フォルダに各項目のフォルダ（単に配信先フォルダ９４１ａ、９４１ｂ・・・ともいう）を関連付けて生成して、ブラウザ機能で画面に表示させる。

また、メイン項目取得部９５０は、メイン項目画面ＧＢの項目（Ｇｂａｉ：配信先フォルダ名）が選択されたとき、その項目（配信先フォルダ名）を詳細画面用メモリ９１０に記憶して詳細画面ＧＡに表示させる。

タイトル表示部９８０は、メモリ９３０の告知タイトル情報を順次読み込み、読み込んだ告知タイトル情報に含まれている表示するまでの時間とタイマー９７０の現在時刻とがほぼ一致したとき（例えば０．５秒前）、この告知タイトル情報の告知ＩＤをタイトル表示有無問合部９８２に知らせる。

タイトル表示有無問合部９８２は、告知ＩＤと視聴者ＩＤと事業者ＩＤとの組みを表示問合情報（通過有無問合わ情報ともいう）としてログイン受付・振分ｗｅｂサーバ１０００宛に送信する。

そして、ログイン受付・振分ｗｅｂサーバ１０００からの表示問合応答情報が「通過する」又は「通過しない」を示しているかを判断して、「通過しない」を示している場合は、読み込んだ告知タイトル情報の告知タイトルを詳細画面用メモリ９１０に保存して詳細画面ＧＢに直ちに表示する。

また、「通過する」を示している場合は、読み込んだ告知タイトル情報の告知タイトルを詳細画面ＧＢに表示させない。

格納配信先フォルダ決定部９８３は、表示問合応答情報（事業者ＩＤ、視聴者ＩＤ、告知ＩＤ、自動又は手動、通過の設定情報、移動先：通過応答結果情報ともいう）が「通過しない」を示している場合は、読み込んだ告知タイトル情報を詳細画面ＧＢに表示している項目に対応する配信先フォルダに格納する。

また、格納配信先フォルダ決定部９８３は、表示問合応答情報が「通過する」ことを示している場合は、表示問合応答情報に含まれている移動先の配信先フォルダ（例えば役場）に格納する。

詳細取得部９２０は、告知タイトル表示部９８０が読み込んだ告知タイトル情報が手動を示している場合に、詳細画面ＧＢに表示された告知タイトルＡｉがタッチされたかどうかを監視し、タッチされた場合は、その告知ＩＤと視聴者ＩＤと事業者ＩＤと詳細要求等を詳細情報要求情報としてログイン受付・振分ｗｅｂサーバ１０００に送信して、その詳細情報を受信して詳細画面ＧＢに直ちに表示する。

また、詳細取得部９２０は、告知タイトル表示部９８０が読み込んだ告知タイトル情報が自動（表示する時刻になったもの）を示している場合に、その告知ＩＤと視聴者ＩＤと事業者ＩＤと詳細要求等を詳細情報要求情報としてログイン受付・振分ｗｅｂサーバ１０００に直ちに送信して、その詳細情報を受信して詳細画面ＧＢに直ちに表示する。

動画取得部９６０は、告知タイトルの動画ボタンが選択された場合は、告知ＩＤと事業者ＩＤと動画要求とを動画要求情報としてログイン受付・振分サーバ１０００に出力し、送信されてきた動画を詳細画面ＧＢに表示する。

タイトル削除部９９０は、告知タイトルの削除ボタンＢｉがタッチされた場合は、詳細画面用メモリ９１０のその告知タイトルを削除すると共に、メモリ９３０及び配信先フォルダ内のその告知タイトル情報を削除する。また、告知ＩＤと事業者ＩＤと視聴者ＩＤと削除フラグとをタイトル削除情報としてログイン受付・振分ｗｅｂサーバ１０００に送信して、対応するログ情報に削除フラグを設定させる。

（ＤＢサーバ４００の構成）
図３はＤＢサーバ４００の概略プログラム構成図である。視聴者端末９００はＲＡＭ、ＲＯＭ、ＣＰＵ等を備えており、制御データによって機能する構成をブロック化している。

図３に示すように、ＤＢサーバ４００は、各種入力画面提供部４７０と、各種マスタ４７１と、告知ＩＤ発行部４７２と、告知登録データＫＢｉを記憶するメモリ４７３と、一定時間先データ抽出部４１１と、告知タイトル送信部４１４と、ログ作成部４１６と、ログを記憶するためのメモリ４１５と、視聴者端末送信結果書込部４３１と、タイトル操作結果書込部４３２とを備えている。

また、視聴者認証部４６０と、メイン項目提供部４８０と、詳細画面提供部４４１と、未読回数更新部４４２と、表示有無通知部４３０と、セッション後ログ作成部４９０等を備えている。

なお、告知タイトル配信提供部４１０は、一定時間先データ抽出部４１１と、告知タイトル送信部４１４と、ログ作成部４１６とが対応し、登録処理部４３０が視聴者端末送信結果書込部４３１と、タイトル操作結果書込部４３２とに対応する。

表示通過判定処理部４２０が表示有無通知部４３１に対応し、詳細配信処理部４４０が詳細画面提供部４４１と、未読回数更新部４４２とに対応する。

各種入力画面提供部４７０は、事業者側に提供する各種ページ（例えば告知登録用画面、配信先予定入力画面、フォルダ通過有無の入力画面・・・）を提供する。このとき、告知ＩＤ発行部４７２からの告知ＩＤ（ユニークコード）、ＵＲＬ等を関連付けて提供する。必要に応じて各種マスタテーブル４７１の情報を提供する。

例えば、告知基本入力情報ｋａ、配信先入力情報ｋｂ、告知配信フォルダ先変更入力情報ｋｃを提供して、これらの情報を告知登録データＫＢｉとしてメモリ４７３に記憶する。

一定時間先データ抽出部４１１は、バッチサーバ６００からの告知要求情報が入力する毎に、メモリ４７３に告知基本情報ＫＭａを順次（登録順）に読み込み、タイマー４１２の現在時刻に対して一定時間先（例えば１５分先：定期、定時、一般の場合を含む）に配信する告知基本情報ＫＭａが存在する場合は、この告知ＩＤを有する配信先予定情報ＫＭｂの利用者ＩＤ（グループＩＤ又は視聴者ＩＤ）と配信先フォルダＩＤ、事業者ＩＤ等からなる配信リストＬｉをメモリ４１３に作成する。

告知タイトル送信部４１４は、メモリ４１３の配信リストＬｉのレコードを引き当て、このレコードの利用者ＩＤ（視聴者ＩＤ又はグループＩＤ）と告知ＩＤと、この告知ＩＤを有する告知基本情報ＫＭａの配信日時（表示させるまでの時間；例えば到着１５後に表示）、アイコンＩＤ、告知タイトル（例えば本日の夏祭りについて）を読み込んで、これらを組み合わせて告知タイトル情報ＫＨｉ）としてバッチサーバ６００に送信する。

利用者ＩＤがグループの場合は、このグループＩＤに関連付けられている視聴者ＩＤを全て告知ＩＤと配信日時（表示させるまでの時間）とアイコンＩＤと告知タイトルに関連付けた塊にして送信する。

ログ作成部４１６は、告知タイトル情報ＫＨｉの作成に伴って、図２７（ｃ）に示す第１の視聴者毎配信初期ログ情報Ｆａをメモリ４１５に作成する。

そして、の視聴者ＩＤ、告知ＩＤを第１の視聴者毎配信初期ログ情報Ｆａの該当の欄に埋め込んだ第２の視聴者毎初期ログＦｂを生成し、バッチサーバ６００からの視聴者ＩＤと告知ＩＤを第２の視聴者毎初期ログＦｂに埋め込んだ視聴者毎ログＦｉ（配信先実績とも称する）を生成する。

視聴者端末送信結果書込部４３１は、低容量コンテンツ配信ｗｅｂサーバ１１０を介して視聴者端末９００からの配信結果情報を受信してこの配信結果情報の視聴者ＩＤ、告知ＩＤを有するログＦｉを引き当て、この送信結果欄に送信結果を書き込む（エラー又はＯＫ）。

タイトル操作結果書込部４３２は、低容量コンテンツ配信ｗｅｂサーバ１１０を介して視聴者端末９００からの告知タイトルの操作結果（削除、タッチ）を受信してこの操作結果の視聴者ＩＤ、告知ＩＤを有するログＦｉを引き当て、該当の欄に書き込む（削除、再生）。

視聴者認証部４６０はログイン情報を視聴者マスタテーブル４７１と比較して認証を行い、認証結果情報（ＯＫ）を返す（ｄ５５）。このとき、視聴者認証部４３１は例えば時刻（年月日含む）、ログイン情報、視聴者ＩＤ等を用いてユーザＩＤを生成し、さらにスプレイセッション確立ｗｅｂサーバ１０１０のＵＲＬ（アクセス先）を組み合わせて送信している。

メイン項目提供部４８０は、セッションが確立後にユーザＩＤに含まれている事業者ＩＤを読み込み、この事業者ＩＤを有する配信先フォルダマスタを全て引き当て、これらの配信先フォルダマスタに含まれている配信先フォルダ名称を読み込んで、メイン項目画面情報を作成して低容量コンテンツ配信Ｗｅｂサーバ１１００を介して視聴者端末９００に送信する。

詳細画面情報提供部４４１は、低容量コンテンツ配信Ｗｅｂサーバ１１００介しての視聴者端末９００からの告知タイトルタッチ情報を読み込み、告知ＩＤ、視聴者ＩＤ、事業者ＩＤを有する詳細コンテンツを詳細コンテンツデータベース４４４から取得し、低容量コンテンツ配信サーバ１１００を介して視聴者端末に送信させる。

表示有無通知部４３１は、視聴者端末９００からの表示問合情報を受信し、この告知ＩＤ、事業者ＩＤを有する告知基本情報マスタを引き当て、この告知基本情報マスタに手動再生が書き込まれている場合は、表示問合情報の配信先フォルダＩＤ、事業者ＩＤを有する配信先フォルダマスタを引き当てる。

そして、このマスタのフォルダ通過フラグの状態（「通過する」または「通過しない」）を表示問合応答結果として返信する。

未読回数更新部４４２は、視聴者端末９００からの告知タイトル削除情報を読み込み、告知ＩＤ、視聴者ＩＤ、事業者ＩＤを有するログを引き当て、削除フラグ（「１」）を設定する。

セッション後ログ作成部４９０は、視聴者端末９００からの告知タイトルＡｉの表示開始時間、詳細情報の表示開始時間等をログ情報としてログに書き込む。

なお、前述の事業者の管理端末（自治体を例にする）は、図４に示すように入力者端末１００ａと、上位者端末１００ｂとをＬＡＮケーブルで接続して、上位者端末１００ｂが入力者端末１００ａから入力された告知基本情報、配信先、配信先フォルダをチェックして、ふさわしくない配信先フォルダを設定している場合は、「通過しない」に変更するのが好ましい。

（各種マスタテーブル）
各種マスタ（メモリ）は、図５に示すように視聴者マスタテーブルと、事業者マスタテーブルと、事業者詳細マスタテーブルと、・・グループマスタテーブルと、視聴者グループマスタテーブルと、配信先フォルダマスタテーブルと、ＩＤ管理マスタテーブルと、視聴者ログイン管理マスタテーブルと、オンライン視聴者マスタテーブルと、告知基本情報マスタテーブルと、告知詳細情報マスタテーブルと、告知配信先予定マスタテーブルと、告知配信先実績マスタテーブル（配信ログマスタテーブルとも称する）と、コード管理マスタテーブル・・・等からなる。

なお、図６には視聴者マスタテーブル４０１ａを示し、図７には事業者マスタテーブル４０１ｂを示し、図８には配信先フォルダマスタテーブル４０１ｃとＩＤ管理マスタテーブル４０１ｄとコード管理マスタテーブル４０１ｅとを示し、図９には告知基本情報マスタテーブル４７３ａを示し、図１０には告知詳細情報マスタテーブル４７３ｂを示し、図１１には告知配信先予定情報マスタテーブル４７３ｃと、告知配信実績（視聴者ログ）４１５とを示し、図１２には視聴者ログイン管理マスタ４７１ｇと、オンライン視聴者管理テーブル４７１ｈとを示す。

これらのマスタテーブルは事業者単位で視聴者毎に設けられている。ただし、告知基本情報マスタテーブルと、告知詳細情報マスタテーブルと、告知配信先予定マスタテーブルと、告知配信先実績マスタテーブル（配信ログマスタテーブルとも称する）は、各種マスタテーブル４７１に示さないで外に出して示している。

（全体の動作説明）
本実施の形態１では自治体を一例にして説明する。

図１３〜図２３は本実施の形態１の動作を説明するシーケンス図である。

（告知データの登録）
自治体管理者端末１００の担当者は自治体管理者端末１００のキーボード、マウス等を操作して管理者ｗｅｂサーバ３００、ＤＢサーバ４００と接続処理を行う（ｄ１、ｄ２）。

そして、管理者用ｗｅｂサーバ３００は、ＤＢサーバ４００と通信を行って必要とする各種画面を自治体管理者端末１００に提供（送信）する（ｄ３、ｄ４）。この各種画面は、図３の各種入力画面提供部４１０が各種マスタ４００から必要なデータを取得して送信する。

また、この画面の提供に当たってＤＢサーバ４００の各種入力画面提供部４７０は図３に示す告知ＩＤ発行部４７２を起動させて告知ＩＤを発行させて付加して送信している（ｄ５、ｄ６）。

告知ＩＤは年月日、事業者コード、担当者コード、コンテンツ種類、乱数等を組み合わせたユニークコードである。本実施の形態では図２４に示す告知基本情報入力画面（新規登録の場合）を提供する。

この画面はＡ市のＡ地域の告知基本情報を入力する画面である。

この画面の左側には、緊急、定時、定期、一般の告知配信タイプ欄Ｃｉが設けられ、操作する担当者が指定する。また、配信時間を指定する欄ＣＨａはが設けられ、このＣＨａに配信日の指定欄Ｃｈａと配信時間を設定する欄ｃｈｂと登録後に直ちに配信を指定させる欄ｃｈｃと、ライブ放送を指定する欄ｃｈｄとを表示している。

さらに、左側には手動、自動、チャイムオンの有無、レベルなどを設定するための配信パターン欄ＣＢａが表示されている。さらに、公開期限、保存期限を設定するための期限欄Ｃｃａが表示されている。

一方、右側にはメッセージエリアの設定欄Ｅａ、コンテンツ種別欄Ｅｂ、タイトル入力欄Ｅｃ、アイコン選択欄Ｅｄ、文章入力欄Ｅｅ、音声録音指定欄Ｅｆ等が表示されている。

このような入力情報を告知基本入力情報ｋａと称する。

前述の緊急というは、直ちに配信する緊急情報であり、定時というのは朝の例えば８時、昼の１２時、晩の１８時の配信を意味する。定期というのは、毎月の例えば水曜日の１１時に放送を意味する。一般というのは、指定された時間で配信を意味する。

また、自治体管理者端末１００の担当者は自治体管理者端末１００のキーボード、マウス等を操作して管理者ｗｅｂサーバ３００と通信を行って図２５に示す配信先登録画面の提供を受ける。図２５に示すように、配信先は視聴者単位、グループ単位（総称して利用者単位という）で指定することができている。また、配信先フォルダ（事業者が配信する告知の大項目；視聴者端末に表示される項目のフォルダ名）も設定できる。

このような入力情報は配信先入力情報ｋｂと称する。

さらに、自治体管理者端末１００の担当者は自治体管理者端末１００のキーボード、マウス等を操作して管理者ｗｅｂサーバ３００と通信を行って図２６に示す配信先フォルダの登録変更画面の提供を受ける。図２６の画面は、事業者名と、配信先フォルダ名（（２）：空３（例えばレシピ））と、配信先フォルダ番号と（１）を通過するの指定等からなる。

このような入力情報を告知配信フォルダ先変更入力情報ｋｃという。

つまり、（１）を通過すると設定した場合は、「（１）を通過させて（２）のフォルダに登録させることを意味する。この配信先フォルダの登録変更画面の操作は、管理権限が高い担当者がパソコン（図示せず）を操作して登録された告知基本情報、配信先のフォルダを画面に開いてチェックし、本日（１）に登録すべき程度のものではないと判断したときに、（１）を通過すると設定する。

これによって、視聴者端末９００の詳細画面における告知タイトルの表示個数を制限できることになるから、有効なものだけを本日のお知らせとして提供できることになる。

このような情報を手作業で担当者（単なる入力担当者、権限が高い担当者）は入力して管理者用ｗｅｂサーバ３００に送信する（ｄ７）。

一方、管理者用ｗｅｂサーバ３００は、自治体管理者端末１００からの情報を告知登録情報Ｋｉ（告知基本入力情報ｋａと配信先入力情報ｋｂと告知配信フォルダ先変更入力情報ｋｃ等を含む）と、動画／音声（告知ＩＤ付き、視聴者ＩＤ付き）して受信し、振り分け判断する（ｄ１２）。

振り分けは、告知登録情報ＫｉはＤＢサーバ４００に送信し（ｄ１１）、動画／音声データはストレージサーバ５００に送信して登録させる（ｄ１３）。

ＤＢサーバ４００の各種入力画像提供部４７０は、登録告知入力情報Ｋｉをメモリ４７３に記憶する（ｄ１４）。

また、登録告知入力情報Ｋｉ（告知基本入力情報ｋａと配信先入力情報ｋｂと告知配信フォルダ先変更入力情報ｋｃ等を含む）に対してはさまざまなデータも付加されるので、メモリ４７３に登録される登録告知入力情報Ｋｉを告知登録データＫＭｉと称し、告知基本入力情報ｋａを告知基本情報ＫＭａ（図９参照）、配信先入力情報ｋｂを告知配信先予定情報ＫＭｂ（図１１参照）、告知配信フォルダ先変更入力情報ｋｃを告知配信先フォルダ変更情報（単に配信先フォルダマスタ４０１とも称する）はＫＭｃ（図８参照）と称する。

なお、告知基本情報ＫＭａには告知詳細情報（図１０）も付加されている。

図８に記憶された配信先フォルダマスタ（告知配信先フォルダ変更情報ＫＭｃ）には、フォルダ通過フラグが設定されている（「通過」、「通過しない」）。

このようにして自治管理者端末１００は、告知する情報をクラウドサーバシステム１０のＤＢサーバ４００に登録している。

（クラウドサーバシステムから視聴者端末への告知配信）
（ＤＢサーバからバッチサーバへの配信）
図１４に示すように、バッチサーバ６００はタイマー６１０が一定時刻（例えば１分）を計測する毎に（ｄ２１）、告知要求情報をＤＢサーバ４００に送信する（ｄ２２）。

ＤＢサーバ４００の一定時間先データ抽出部４１１はバッチサーバ６００から告知要求情報（例えば１分毎）を受信したかどうかを監視している（ｄ２３ａ）。

告知要求情報を受信した場合は、バッチサーバ６００から告知要求情報を受信する毎に、メモリ４７３の告知基本情報ＫＭａ（図９、図１０、図２６参照）を順次（登録順）に読み込み、配信種別ＩＤが緊急以外の場合（定時、定期、一般）はタイマー４１２の現在時刻に対して一定時間先（例えば１５分先）に配信する告知基本情報ＫＭａがないかどうかを判定する（ｄ２３ｂ）。

一定時間先データ抽出部４１４は一定時間先に配信する告知基本情報ＫＭａがメモリ４７３に存在する場合は、その告知基本情報ＫＭａの告知ＩＤを読み込み、この告知ＩＤを有する配信先予定情報ＫＭｂをメモリ４７３から検索する。そして、設定されている利用者ＩＤ（グループＩＤ又は視聴者ＩＤ）を読み込んで、告知ＩＤと利用者ＩＤと配信先フォルダＩＤ、事業者ＩＤ等からなる配信リスト（Ｌｉ）をメモリ４１３に作成する（ｄ２４）。

配信先フォルダＩＤは配信先予定情報ＫＭｂ（図１１参照）から読み込むのが好ましい。

配信リストＬｉは、図２７（ａ）に示すように、事業者ＩＤ毎に、視聴者ＩＤと告知ＩＤと配信先フォルダＩＤとからなる。

そして、ＤＢサーバ４００の告知タイトル送信部４１４は、メモリ４１３の配信リストＬｉのレコードを引き当て、このレコードの利用者ＩＤ（視聴者ＩＤ又はグループＩＤ）と告知ＩＤと、この告知ＩＤを有する告知基本情報ＫＭａ（図９参照）の配信日時（表示させるまでの時間；例えば到着１５後に表示）、アイコンＩＤ、告知タイトル（例えば本日の夏祭りについて）を読み込む。

そして、これらを組み合わせて告知タイトル情報ＫＨｉ（図２７（ｂ）を参照）として生成する（ｄ２５）。

なお、利用者ＩＤがグループＩＤの場合は、メモリ４７１に記憶されている視聴者グループマスタ（図示せず：グループＩＤと視聴者ＩＤとが関連付けられている）を読み込んで、このグループＩＤに関連付けられている視聴者ＩＤを全て読み込んで組み込んで告知タイトル情報ＫＨｉ（ＪＡＳＯＮ）としてバッチサーバ６００に渡す。この告知タイトル情報ＫＨｉはメモリ４８１に実配信リストＧＨｉ（「視聴者ＡのＩＤと告知ＩＤと事業者ＩＤと配信日時と告知タイトルとアイコンＩＤ」、「視聴者ＢのＩＤと告知ＩＤと事業者ＩＤと配信日時と告知タイトルとアイコンＩＤ」・・・）して保存する。

また、ログ作成部４１６は、告知タイトル情報ＫＨｉの作成に伴って、図２７（ｃ）に示す第１の視聴者毎配信初期ログ情報Ｆａをメモリ４１５に作成する（ｄ２６）。

この第１の視聴者毎配信初期ログ情報Ｆａの生成について説明する。

告知タイトル情報ＫＨｉの作成に伴って、メモリ４１５に告知ＩＤ欄と視聴者ＩＤ欄と配信先フォルダＩＤ欄と送信状況欄と視聴者再生回数欄と自動再生日時欄と手動再生日時欄と視聴者削除フラグ欄等（図２７（ｃ）、図１１（ｂ）参照）のレコード（視聴者毎用ログレコードともいう）を生成する。

そして、生成した第１の視聴者毎初期ログＦａを順次指定し、かつ読み込んだ視聴者ＩＤを順次指定し、指定した第１の視聴者毎初期ログＦａに指定した視聴者ＩＤを埋め込むと共に、生成した告知タイトル情報ＫＨｉの告知ＩＤと配信先フォルダＩＤとを該当の欄に埋め込む。これを本実施の形態では第２の視聴者毎初期ログＦｂと称する。

また、告知タイトル情報ＫＨｉの利用者ＩＤが視聴者ＩＤの場合は、この視聴者の視聴者用ログレコードのみを生成する。

つまり、１個の視聴者用ログレコードを作成して視聴者ＩＤを埋め込むと共に生成した告知タイトル情報ＫＨｉの告知ＩＤと配信先フォルダＩＤとを該当の欄に埋め込んで第２の視聴者毎告知配信初期ログＦｂを生成する。

そして、この第２の視聴者毎告知配信初期ログＦｂを生成した後に、生成した告知タイトル情報ＫＨｉ（グループＩＤ又は視聴者ＩＤ付き）をバッチサーバ６００に送信する（ｄ２７）。

バッチサーバ６００は、ＤＢサーバ４００から送信された告知タイトル情報ＫＨｉを受信する毎に、この告知タイトル情報ＫＨｉに含まれている利用者ＩＤ（グループＩＤ又は視聴者ＩＤ）と告知ＩＤとログとしてＤＢサーバ４００に送信する（ｄ２８）。

ＤＢサーバ４００のログ作成部４１６は、バッチサーバ６００からログを受信し、このログの視聴者ＩＤを有する第２の視聴者毎告知配信初期ログＦｂをメモリ４１５から引き当て、ログの視聴者ＩＤと告知ＩＤとを該当の欄に埋め込む（ｄ２９：図２８（ｃ）参照）。このように欄に実際にデータが埋め込まれたものを視聴者毎配信ログＦｉ（実績）と称する。

次に、告知タイトル送信部４１４はメモリ４１３に他に告知があるかどうかを判断し、ある場合は処理をｄ２３ｂに移して次の告知を配信させる（ｄ３０）。

なお、緊急の場合は直ちにバッチサーバに配信するために配信リストの最上位に告知タイトル情報を埋め込む（自動再生）。

（バッチサーバ→スプレイ管理→スプレイ→視聴者端末までの配信）
一方、バッチサーバ６００は図１５に示すように、受信した告知タイトル情報ＫＨｉ（グループＩＤ又は視聴者ＩＤ、告知ＩＤ、表示するまでの時間、アイコンＩＤ、告知タイトル）＋付属情報（視聴者端末のアドレス等）をスプレイ管理ｗｅｂサーバ７００に送信する（ｄ３１）。

スプレイ管理ｗｅｂサーバＤＢ７００は、スプレイサーバ１０２０ａ〜１０２０ｊを管理しており、利用者ＩＤに基づいて該当のスプレイサーバを検索してそのスプレイサーバに告知タイトル情報ＫＨｉを送信する（ｄ３３）。

具体的には、グループＩＤ又は視聴者ＩＤとスプレイサーバの番号とを関連付けたテーブル（図示せず）を備えている。

例えば、告知タイトル情報ＫＨｉがグループＩＤとし、このグループＩＤはスプレイサーバ１０２０ａに対応しているとする。スプレイ管理サーバ７００は、告知タイトル情報ＫＨｉを受信して付属情報と共にスプレイサーバ１０２０ａに送信する。

次に、スプレイ配信ｗｅｂサーバ１０２０ａはスプレイセッション確立用ｗｅｂサーバ１０１０に対してセッションが確立している視聴者端末９００がどれかを問い合わせる（ｄ３４）。このセッション確立については後述する。

次に、スプレイ配信ｗｅｂサーバ１０２０ａは、配信先の視聴者端末９００がセッション確立中かどうかを判断する（ｄ３５）。

セッションが確立されていない場合は、スプレイｗｅｂサーバ１０２０ａは、その配信結果情報（視聴者ＩＤ、告知ＩＤ、送信未）をＤＢサーバ４００に送信する（ｄ４１）。

ＤＢサーバ４００の視聴者端末送信結果書込部４３１は配信結果情報を受信してこの配信結果情報の視聴者ＩＤ、告知ＩＤを有する配信ログＦｉを引き当て、これに送信結果欄に送信エラーを書き込む（ｄ４２）。

一方、スプレイ配信ｗｅｂサーバ１０２０ａは、配信先がセッション確立の場合は、告知タイトル情報ＫＨｉを接続中の各視聴者端末９００に送信する（ｄ３８）。

視聴者端末９００は、メモリ９３０にこの告知タイトル情報ＫＨｉを記憶する（ｄ４０）。

そして、配信結果情報を受信完了にしてＤＢサーバ４００に送信する（ｄ３９）。ＤＢサーバ４００は視聴者端末送信結果書込部４２６は送信ＯＫを視聴ログに書き込む（ｄ４３）。

（セッション確立）
本実施の形態では図１６に示すように、視聴者端末９００には既に制御データ（プログラム）及び告知配信タイトル情報ＫＨｉが保存されて、画面にはそのアイコン（知らせますけん）が表示されているとする（ｄ５０ａ、ｄ５０ｂ）。視聴者端末９００の視聴者はアイコン（知らせますけん）をタッチする。

このタッチはログイン受付・振分ｗｅｂサーバ１０００へのアクセスと判定して、そのアクセスをログイン受付振分ｗｅｂサーバ１００に送信し、ログイン受付振分ｗｅｂサーバ１０００はログイン画面を視聴者端末９００に送信し、視聴者端末９００の視聴者はログイン情報を入力してログイン情報をログイン受付振分ｗｅｂサーバ１００に送信する（ｄ５２）。

ログイン受付振分ｗｅｂサーバ１０００は、どの低容量コンテンツ配信ｗｅｂサーバ１１００がこの視聴者のアクセスを受け付けるかを管理しており、該当の低容量コンテンツ配信ｗｅｂサーバ１１００にそのログイン情報を送信する（ｄ５３）。本実施の形態では低容量コンテンツ配信ｗｅｂサーバ１１００ａが該当しているとして送信する。

低容量コンテンツ配信ｗｅｂサーバ１１００ａはこのログイン情報をＤＢサーバ４００に送信する（ｄ５４）。

図３に示すＤＢサーバ４００の視聴者認証部４６０は、視聴者マスタと比較して認証を行い、認証結果情報（ＯＫ）を返す（ｄ５５）。このとき、視聴者認証部４６０は例えば時刻（年月日含む）、ログイン情報、視聴者ＩＤ等を用いてユーザＩＤを生成し、さらにスプレイセッション確立ｗｅｂサーバ１０１０のＵＲＬ（アクセス先）を組み合わせて送信している。

また、ＤＢサーバ４００の視聴者認証部４６０は、視聴者端末９００からのログイン情報がＯＫ（利用許可）とされた場合は、その視聴者端末９００とセッションを結ぶスプレイ配信ｗｅｂサーバ１０２０にそのユーザＩＤを知らせる（ｄ５６）。

一方、視聴者端末９００のセッション確立部（図示せず）は、認証結果情報がＯＫ（アクセス許可）を示している場合は、アクセス先のＵＲＬに基づいてそのユーザＩＤ（利用者情報ともいう）をスプレイセッション確立用ｗｅｂサーバ１０１０に送信する（ｄ５７）。

スプレイセッション確立用ｗｅｂサーバ１０１０は、ユーザＩＤを受信し、このユーザＩＤが設定されているスプレイサーバ１０２０を各スプレイｗｅｂサーバに問い合わせして、ユーザＩＤが設定されているスプレイサーバにそのユーザＩＤを振り分け送信する（ｄ５９）。

ユーザＩＤを受信したスプレイサーバ１０２０は、利用者端末９００に対してセッション確立信号を送出する（ｄ６０）。

そして、さらにスプレイ配信Ｗｅｂサーバ１０２０ａはセッション確立後に回線が切断されないように、ｐｉｎｇデータを視聴者端末９００に送信し（ｄ６１）、視聴者端末９００は応答データを返信している（ｄ６２）。

また、視聴者端末９００はトンネル等において回線が切断されないように例えば１分毎に視聴者ＩＤをスプレイ振り分けＷｅｂサーバ１０１０に送信して、スプレイ配信Ｗｅｂサーバ１０２０ａがその応答信号を返信してオンライン接続を完了させている（ｄ６３，６３）。

このような状態において手動再生と自動再生とを説明する。

（手動再生）
本説明ではスプレイ配信Ｗｅｂサーバ１０２０ａと視聴者端末９００とはセッションが確立されている（ｄ６５）。

また利用者端末９００のメモリ９３０には１５分後に表示する告知タイトル情報ＫＨｉが記憶されているとする。

また、ＤＢサーバ４００のメイン項目提供部４８０は、セッションが確立後にユーザＩＤに含まれている事業者ＩＤを読み込み、この事業者ＩＤを有する配信先フォルダマスタを全て引き当て、これらの配信先フォルダマスタに含まれている配信先フォルダ名称を読み込んで、メイン項目画面情報を作成する（ｄ６８）。

そして、ＤＢサーバ４００のメイン項目提供部４８０は、このメイン項目画面情報（複数の配信先フォルダ名称及び配信先フォルダＩＤ、事業者名、視聴者ＩＤ）を該当の低容量コンテンツ配信Ｗｅｂサーバ１１００ａに送信する（ｄ６９）。このとき、視聴者マスタの視聴者ＩＤに関連する通信に必要な情報も付加して送信する。

メイン項目画面情報を受信した低容量コンテンツ配信Ｗｅｂサーバ１１００ａは受信したメイン項目画面情報を視聴者ＩＤが割り付けられている視聴者端末９００に送信する（ｄ７０）。

また、ＤＢサーバ４００の未読回数送出部４４２は、メイン項目画面の配信先フォルダＩＤ（メイン項目）及び視聴者ＩＤを順次読み込み、該読込毎に、この配信先フォルダＩＤ及びを有する配信ログ情報（告知ＩＤ、告知タイトルの現在の詳細再生回数・・）を配信ログテーブル４１５から全て引き当て、これらのログ情報の現在の詳細再生回数の合計をこの配信先フォルダ内の詳細合計未読回数として順次求める。

そして、配信先フォルダＩＤと詳細未読合計回数とを各々関連付けた（配信先フォルダ未読回数リストともいう）を作成する（ｄ７１）。そして、低容量コンテンツ配信ｗｅｂサーバ１１００を介してログインしてきた視聴者端末に配信先送信する（ｄ７２、ｄ７３）。

また、配信先フォルダ未読回数リストには、各配信先フォルダＩＤの詳細未読合計回数の総計（事業者の未読総計回数）を求め、これを含んでいるとする。

視聴者端末９００のメイン項目取得部９５０は、未読リストを受信して制御データ及び画面フォーマットに基づいて図２９に示すように表示する（ｄ７５）。

図２９に示すように左のメイン項目画面ＧＢには、配信事業者名ＧＢＡ（○○役場）が表示され、これにこの配信事業者が配信するメイン項目名Ｇｂｉ（本日のお知らせ、ＰＴＡ、役場から、文化・・）を表示し、かつ各々のメイン項目に視聴者未読回数が表示され、かつこれらの総計未読回数が配信事業者名（○○役場）に表示されている。

このとき、タイマー９７０の現在時刻を時刻表示部（図示せず）が詳細画面用メモリ９１０に記憶して詳細画面ＧＡに表示する。

具体的には、図２に示す、メイン項目画面メモリ９５０がメイン項目画面用メモリ９２０に保存して左のメイン項目画面ＧＢに表示させる。

次に、視聴者端末９００のいずれかの項目Ｇｂａｉ（配信先フォルダ名）の内で、視聴者が例えば本日のお知らせの配信事業者メニューをタッチすると（ｄ８０）、視聴者端末９００は制御データに従って視聴者ＩＤとそのメニューの配信先フォルダＩＤ、アクセスするＵＲＬ（低容量コンテンツ配信ｗｅｂサーバ１１００）などを配信先フォルダタッチ情報として視聴者毎低容量コンテンツ配信ｗｅｂサーバ１１００ａに送信して、ＤＢサーバ４００に送信する（ｄ８１、ｄ８２）。

一方、視聴者端末９００のメイン項目取得部９５０は、タッチされた項目（配信先フォルダ名）のフォルダ名（項目名）を読み込み、これを詳細画面用メモリ９１０に保存して詳細画面ＧＡに表示（例えば本日のお知らせ）する（ｄ８４：図３０参照）。

（告知タイトルの表示）
このような状態で、視聴者端末９００のタイトル表示部９８０は、メモリ９３０に告知タイトル情報があるかどうかを監視している（ｄ８７）。

告知タイトル情報が配信された場合は、タイトル表示部９８０がこの告知タイトル情報ＫＨｉの表示時間を読み込み（ｄ８８）、直ちに表示（スタート０）を示しているかどうかを判断する（ｄ８９）。

直ちに表示と判断したときは後述する自動再生モードと判断する（ｄ９０）。

直ちに表示でないと判断したときは、図１８に示すように、読み込んだ告知タイトル情報ＫＨｉの表示を開始するまでの時間（例えば１２時００）とタイマ９７１の現在時刻とを比較して表示する時間になったかどうかを判断する（ｄ１１０：例えば１１時５９分５８秒で表示する時間と判断する）。

表示する時間になった判断した場合は、タイトル表示有無問合部９８２に対して告知タイトル情報ＫＨｉの告知ＩＤ、視聴者ＩＤ、事業者ＩＤ、詳細画面に表示されている項目名（配信先フォルダＩＤ：メモリ９１０から読む）を出力する。

表示有無問合部９６０は、表示問合情報（表示の問い合わせ、告知ＩＤ、視聴者ＩＤ、事業者ＩＤ、配信先フォルダＩＤ）を低容量コンテンツ配信サーバ１１００を介してＤＢサーバ４００に送信すると共に、格納配信先フォルダ決定部９８３に表示の問い合わせであることを知らせる（ｄ１１１）。

ＤＢサーバ４００の表示有無通知部４３１は、図１９に示すように、視聴者端末９００から表示問合情報を受信し、この告知ＩＤ、事業者ＩＤを有する告知基本情報マスタを引き当て、この告知基本情報マスタの再生フラグが自動再生か手動再生かどうかを判断する（ｄ１１４）。

表示有無通知部４３１は手動再生の場合は、手動モードと判断する。手動モードの場合は、表示問合情報の配信先フォルダＩＤ、事業者ＩＤを有する配信先フォルダマスタを引き当て、このマスタのフォルダ通過フラグが「通過する」または「通過しない」を示しているかどうかを判断する（ｄ１１５）。

そして、その判断結果を表示問合応答情報（事業者ＩＤ、視聴者ＩＤ、告知ＩＤ、通過の有無、配信先）として低容量コンテンツ配信ｗｅｂサーバ１１００を介して返信する（ｄ１１６）。

「通過する」と判断した場合は、配信先フォルダマスタの移動先の配信先フォルダＩＤを付加した表示問合応答情報として返信する。「通過しないと」と判断した場合は配信先フォルダマスタの配信先フォルダＩＤを付加する。

つまり、詳細画面に読み込んだ告知タイトルを表示させるかどうかを事業者単位で判断して、その結果を視聴者端末に知らせている。

すなわち、事業者の種類よっては本日の告知として配信するのが好ましくない場合もある。これは、告知タイトルの内容がどのようなものであっても１５分先のものであれば事業者に関係なく配信される。例えば、役場関係、町内会関係、デパート又はスープのタイムセールは本日としてふさわしいと思うが、例えば料理教室経営者の事業者の告知であれば、本日としてはふさわしくない。このため、詳細画面が本日の場合は、料理教室の告知を本日としないでレシピフォルダ（視聴者端末側）に格納するようにしている。

これによって、視聴者画面には、本日の告知としてふさわしい告知を常に表示させることができる。

なお、配信先フォルダマスタに告知ＩＤも関連させて保存し、表示問合情報の告知ＩＤ、配信先フォルダＩＤ、事業者ＩＤを有する配信先フォルダマスタを引き当て、このマスタのフォルダ通過フラグが「通過する」または「通過しない」を示しているかどうかを判断してその結果を知らせてもよい。

つまり、告知タイトル毎に詳細画面（本日）に表示させるかどうかを決定してもよい。

一方、視聴者端末９００のタイトル表示有無問合部９８２は、表示問合応答情報を受信して「通過しない」、「通過する」を示している（表示かどうか）かどうかを判断する（ｄ１１７）。

「通過しない」（表示）を示していると判断した場合は、読み込んだ告知タイトル情報を詳細画面表示用メモリ９１０に格納して図３０（ａ）に示すように告知タイトルＡ１を表示する（ｄ１１８）。なお、図３０（ａ）の告知タイトルＡのゴミ箱アイコンＢ１は削除アイコンを示す。

このとき、格納配信先フォルダ決定部９８３は、「通過しない」場合は表示問合応答情報に含まれている配信先フォルダＩＤに対応する配信先フォルダに告知タイトル情報を格納（例えば本日フォルダ）する。

また、タイトル表示部９８０は、事業者ＩＤ、視聴者ＩＤ、詳細画面に表示した告知タイトルの告知ＩＤと、表示した時間とをログ情報としてＤＢサーバに送信する（ｄ１２１）。

ＤＢサーバ４００のセッション後ログ作成部４９０は、このログ情報を事業者ＩＤ、視聴者ＩＤ、告知ＩＤを有するログ情報に書き込む（ｄ１２２）。

また、格納配信先フォルダ決定部９８３は、表示問合応答情報が表示しない（通過する）を示している場合は、表示問合応答情報に含まれている移動先の配信フォルダＩＤ（例えばＰＴＡ）に対応するメイン項目画面用メモリ９２０の配信先フォルダに格納する（ｄ１２５）。つまり、詳細画面には表示しない。

次に、格納配信先フォルダ決定部９８３は、移動先の配信先フォルダに格納した告知タイトル情報の視聴者ＩＤ、告知ＩＤ、移動先の配信先フォルダＩＤとを告知移動先情報として低容量コンテンツ配信サーバ１１００を介してＤＢサーバ４００に送信する（ｄ１２６）。

ＤＢサーバ４００の未読回数更新部４４２は、告知移動先情報を受信してこの視聴者ＩＤ、配信先フォルダＩＤを有する未読リスト４４３を引き当て、未読リストの配信先フォルダＩＤに関連付けられている未読回数を更新する（１増加する）する（ｄ１２７）。

未読リスト４４３は図３１に示すように事業者ＩＤと視聴者ＩＤとの組に、この事業者が提供した項目（配信先フォルダ名）の配信先フォルダＩＤが関連付けられ、かつ未読数が関連付けられている。

そして、ステップｄ８７に処理を戻して次の告知タイトル情報を読み込んで、表示の有無をＤＢサーバに判断させて表示する（ｄ１２８）。従って、図３０（ｂ）に示すように告知タイトルが順次表示される。

また、図２０に示すように、視聴者端末９００の詳細表示部９８０は、詳細画面の告知タイトルがタッチされたかどうかを監視する（ｄ１３１）。

告知タイトルのタッチでないと判定したときは、タイトル削除部９９０が告知タイトル内の削除アイコンが選択（タッチ）されたかどうかを監視し、タッチされていない場合は処理をｄ１３１に戻してタッチの入力を待つ（ｄ１３２）。

タイトル削除部９９０は、削除アイコンが選択（タッチ）された場合は、その告知タイトルの告知ＩＤと削除コマンドと視聴者ＩＤと事業者ＩＤと詳細画面の現在の項目名（配信先フォルダＩＤ）等（ログイン受付・振分ｗｅｂサーバのＵＲＬ、１１００のアドレス、ＤＢサーバのアドレスを含む）を告知タイトル削除情報（図２０においては告知ＩＤ付きＵＲＬと記載している）としてログイン受付・振分ｗｅｂサーバ１０００に送信する（ｄ１３４）。

ログイン受付・振分ｗｅｂサーバ１０００は、告知タイトル削除情報を低容量コンテンツ配信サーバ１１００に送信する（ｄ１３６）。つまり、告知タイトル削除情報を該当の低容量コンテンツ配信サーバ１１００に送信するように振り分けしている（ｄ１３５）。

低容量コンテンツ配信サーバ１１００は、告知タイトル削除情報をＤＢサーバ４００にする（ｄ１３７）。

ＤＢサーバ４００のセッション後ログ作成部４９０は、告知タイトル削除情報を読み込み、告知ＩＤ、視聴者ＩＤ、事業者ＩＤを有するログを引き当て、削除フラグ（「１」）を設定する（ｄ１３８）。

また、ＤＢサーバ４００の未読回数更新部４４２は、告知タイトル削除情報を読み込み、配信先フォルダＩＤ、視聴者ＩＤ、事業者ＩＤを有する未読リストのレコードを引き当て、未読数を更新（１減算）する（ｄ１３９）。

一方、視聴者端末９００の詳細取得部９２０は、詳細画面の告知タイトルがタッチされたと判定した場合は、その告知タイトルを色別表示する。

視聴者端末９００の詳細表示部９８０は、その告知タイトルの告知ＩＤと告知タイトルタッチのコマンドと視聴者ＩＤと事業者ＩＤとタッチ時刻（手動再生日時）等（１０００のＵＲＬ、１１００、４００のアドレスを含む）とを告知タイトルタッチ情報（図２０においては告知ＩＤ付きＵＲＬと記載している）としてログイン受付・振分ｗｅｂサーバ１０００に送信する（ｄ１４０）。

ログイン受付・振分ｗｅｂサーバ１０００は、告知タイトルタッチ情報を低容量コンテンツ配信サーバ１１００に振り分け送信する（ｄ１４１、ｄ１４２）。

低容量コンテンツ配信サーバ１１００は、告知タイトルタッチ情報をＤＢサーバ４００に送信する（ｄ１４３）。

ＤＢサーバ４００の詳細画面情報提供部４４１は告知タイトルタッチ情報を読み込み、告知ＩＤ、視聴者ＩＤ、事業者ＩＤを有する詳細コンテンツを詳細コンテンツデータベース４４４から取得する（ｄ１４４）。

そして、詳細画面情報提供部４４１は取得した詳細コンテンツに視聴者ＩＤ、告知ＩＤを付加して低容量コンテンツ配信サーバ１１００に送信（ＨＴＭＬ）する（ｄ１４５）。

低容量コンテンツ配信サーバ１１００は、これを受信し、この視聴者ＩＤに対して詳細コンテンツを送信する（ｄ１４６）。

視聴者端末９００の詳細表示部９２０は、詳細コンテンツを受信して詳細画面に表示する（ｄ１４７；図３２（ａ）参照）。

そして、詳細取得部９２０は、タイマー９７０の現在時刻を再生開始時刻としてログ作成要求（視聴者ＩＤ、事業者ＩＤ、告知ＩＤ、詳細コンテンツＩＤ、再生開始時刻、再生）を低容量コンテンツ配信サーバ１１００に送信する（ｄ１４８）。

低容量コンテンツ配信サーバ１１００は、このログ作成要求をＤＢサーバ４００に送信する（ｄ１４９）。

ＤＢサーバ４００の詳細画面提供部４４１はログ作成要求の視聴者ＩＤ、事業者ＩＤ、告知ＩＤを有するログを引き当て、このログ作成要求に含まれている再生開始時刻を書き込む（ｄ１５０）。

また、未読回数更新部４４２は視聴者ＩＤ、事業者ＩＤ、告知ＩＤ、詳細コンテンツＩＤを有する未読リストを引き当て、該当の未読回数から「１」を減算すると共に総計から１を減算する（ｄ１５０）。

また、詳細画面の詳細コンテンツを表示した場合に、動画アイコンが選択された場合は、動画要求（視聴者ＩＤ、事業者ＩＤ、告知ＩＤ、詳細コンテンツＩＤ、動画、１０００のＵＲＬ、１２００、５００のアドレスを含む）をログイン受付・振り分けサーバ１０００に送信する（ｄ１５２）。

ログイン受付・振り分けサーバ１０００は該当のストレージサーバ５００に動画要求を振り分け送信する（ｄ１５３、ｄ１５４）。

ストレージサーバ５００は動画要求を受信して、視聴者ＩＤ、事業者ＩＤ、告知ＩＤ、詳細コンテンツＩＤを有する動画コンテンツを動画データベース５２０から引き当てこれを視聴者端末９００に送信する（ｄ１５５）。

視聴者端末を詳細画面に動画コンテンツを表示する（ｄ１５６：図３２（ｂ）参照）。

（自動再生：定期、定時、一般）
視聴者端末９００のタイトル表示部９８０は図２１に示すように、ステップＳ８９において直ちに再生でないと判定した場合は、タイトル表示有無問合部９８２の表示問合応答情報を読み、定期、定時又は一般でかつ自動を示しているかどうかを判定する（ｄ１６１）。

自動として知らせられた場合は、告知タイトル情報の表示開始時刻とタイマー９７０の時刻と比較して表示する時間になったかどうか（タイマー時刻＝表示開始時間）を判定する（ｄ１６２）。

表示時間になっていないと判定したときは、処理をステップＳ８７に戻す（ｄ１６３）。

表示する時間になったと判定したときはタイトル表示部９８０は、端末の画面の詳細画面をバックグラウンド処理を行う（ｄ１６４）。

そして、詳細取得部９２０は、その告知タイトルの告知ＩＤと視聴者ＩＤと事業者ＩＤと詳細自動のコマンドと告知タイトルに貼り付けられているログイン受付・振分サーバ１０００のＵＲＬと低容量コンテンツ配信ｗｅｂサーバ１１００のアドレスとＤＢサーバ４００のアドレスとを詳細自動情報（図２１においては告知ＩＤ付きＵＲＬと記載している）としてログイン受付・振分ｗｅｂサーバ１０００に送信する（ｄ１６６）。

ログイン受付・振分ｗｅｂサーバ１０００は、詳細自動情報を低容量コンテンツ配信サーバ１１００に送信する（ｄ１６７）。

低容量コンテンツ配信サーバ１１００は、詳細自動情報をＤＢサーバ４００にする（ｄ１６８）。

ＤＢサーバ４００の詳細画面情報提供部４４１は詳細自動情報を読み込み、告知ＩＤ、視聴者ＩＤ、事業者ＩＤを有する詳細コンテンツを詳細コンテンツデータベース４４４から取得して低容量コンテンツ配信サーバ１１００を介して視聴者端末９００に送信する（ｄ１６９、ｄ１７０）。

視聴者端末９００の詳細取得部９２０は、詳細コンテンツを受信して詳細画面に表示する（ｄ１７１；図３２（ａ）参照）。

そして、詳細表示部９２０は、タイマーの現在時刻を再生開始時刻としてログ作成要求（視聴者ＩＤ、事業者ＩＤ、告知ＩＤ、詳細コンテンツＩＤ、再生開始時刻、再生）を低容量コンテンツ配信サーバ１１００を介してＤＢサーバ４００に送信する（ｄ１７２）。

ＤＢサーバ４００のセッション後ログ作成部４９０は、ログ作成要求の視聴者ＩＤ、事業者ＩＤ、告知ＩＤを有するログを引き当て、このログ作成要求に含まれている自動再生開始時刻を書き込む（ｄ１７３）。

また、視聴者端末９００は動画再生の場合は上記と同様にして動画を表示する（ｄ１７５）。

（ライブ放送）
図２２に示すように、自治体端末１００の担当者は、端末１００を操作して音声ライブ用告知データを管理者ｗｅｂサーバ３００を介してＤＢサーバ４００に登録する（ｄ１８１、ｄ１８２）。

また、管理者用ｗｅｂサーバ３００は視聴ログの登録要求をＤＢサーバ４００に送信する（ｄ１８３）。

管理者用ｗｅｂサーバ３００は音声ライブの準備をせよのライブ告知情報（ライブＩＤ、タイトル、アイコンＩＤ、視聴者ＩＤ）をスプレイ管理サーバ７００に送信（ＪＡＳＯＮデータ）する（ｄ１８５）。

管理サーバ３００は、このライブ告知情報を受信して、これをスプレイサーバの台数分だけ作成して送信する（ｄ１８６）。

また、自治体端末１００は、ライブ告知情報の登録に伴って、管理サーバ３００に対してｗｅｂｓｏｃｋｅｔオープン要求管理を出力し（ｄ１９１）、管理サーバ３００はスプレイサーバ管理サーバに出力し（ｄ１９２）、スプレイ管理サーバはスプレイサーバ１０２０に出力している（ｄ１９３）。

一方、スプレイサーバからライブ告知要求を受信した視聴者端末は、ライブ告知要求の受信に伴って直ちに応答を送信する（ｄ１８８）。

これによって、視聴者端末は音声待機モードとなる（ｄ２０１）。

一方、図２３に示すように、自治体端末１００の担当者は、音声をマイクロホン（図示せず）から入力し、自治体端末１００はこれをエンコードして管理者ｗｅｂサーバ３００に送信する（ｄ２０２）。

管理者用ｗｅｂサーバは、これをスプレイ管理サーバ７００に送信し（ｄ２０３）、スプレイ管理サーバはスプレイサーバに送信する（ｄ２０４）。

そして、スプレイサーバは該当の視聴者端末に音声データを送信する（ｄ２０５）。

視聴者端末は音声データを受信すると、直ちに再生（ライブ再生）する（ｄ２０９）。

一方、自治体端末１００は担当者がライブが終了のボタンを押すと、直ちに管理サーバ３００、スプレイ管理サーバを介してクローズ信号をスプレイサーバに送信する（ｄ２１０、ｄ２１１、ｄ２１２）。

また、視聴者端末は開始後４分はタイマーを起動させて、４分経過するとソケットクローズをスプレイサーバに送信する（ｄ２１３）。

＜実施の形態２＞
上記実施の形態１では告知情報を登録する事業者を１つの自治体として説明したが、区域には複数の事業体が存在していてもかまわない。このような場合においては、視聴者側がＡ事業者、Ｂ事業者からも希望の告知情報を受け取りたい。しかし、視聴者に対して一定期間に配信する数は限られている。このような場合にも、視聴者が希望する告知情報を配信するのが実施の形態２である。

図３３は本実施の形態のＤＢサーバの概略構成図である。図３３に示すように、管理者ｗｅｂサーバ３００には、複数の事業者端末１００ａ、１００ｂ・・が接続されている。

ＤＢサーバ４００には、視聴者毎告知変更処理部４０１を有している。

視聴者毎変更処理部４０１は、メモリ４８１（バッチ配信用メモリともいう）の実配信リストＧＨｉ（「視聴者ＡのＩＤと告知ＩＤと事業者ＩＤと配信日時と告知タイトルとアイコンＩＤ」、「視聴者ＢのＩＤと告知ＩＤと事業者ＩＤと配信日時と告知タイトルとアイコンＩＤ」・・・）が保存されると、この実配信リストＧＨｉの番号を指定し、この番号の実配信リストＧｈｉ（以下告知配信実情報Ｍｉ（「視聴者ＡのＩＤと告知ＩＤと事業者ＩＤと配信日時と告知タイトルとアイコンＩＤ」）が過去に削除されている場合は、これを削除して、他の事業者のこの告知ＩＤに類似するコンテンツの告知配信実情報Ｍｉに変更して配信させる。

図３４はＤＢサーバの視聴者毎告知変更処理部４０１の概略構成図である。図３４に示すように、告知タイトル削除部４０５と、過去再生最多告知ＩＤ決定部４０６と、類似コンテンツ決定部４０７と、告知更新部４０８等を有している。また、視聴者マスタ４７１を用いる。この視聴者マスタ４７１は、図６の項目以外に視聴者の年齢、性別、希望するジャンル種別（コンテンツ種別）、配信許可事業者ＩＤをさらに関連させている。これらを属性情報Ｈｓｇｉという。

また、コンテンツマスタ４４４を用いる。このコンテンツマスタ４４４は、告知基本情報（図９）のＵＲＬに対応しており、コンテンツ種類に実際のコンテンツ（詳細）がリンク付けされている。

メモリ４８１（バッチ配信用メモリ）には、１５分先に視聴者端末９００に表示させる告知配信実情報Ｍｉが事業者単位で記憶されている。

告知削除部４０５は、バッチ配信用メモリ４８１の実配信リストＧＨｉを指定して（１個単位）、その告知配信実情報Ｍｉの視聴者ＩＤ、告知ＩＤ、事業者ＩＤを有する過去のログ情報Ｆｉをメモリ４１５から検索し、削除フラグが設定されている場合は、知配信実情報Ｍｉを削除する。

過去再生最多告知ＩＤ決定部４０６は、指定された告知配信実情報Ｍｉの視聴者ＩＤの属性情報Ｈｓｇｉ（性別、希望ジャンル、年齢、区域）を視聴者マスタから読み込み、この属性情報Ｈｓｇｉに最も類似する視聴者情報Ｓｇｉを視聴者マスタから決定し、配信予定情報マスタから告知配信実情報Ｍｉに関連する配信フォルダＩＤと視聴者情報Ｓｇｉの視聴者ＩＤとを有する過去のログ情報Ｆｉを全事業者に渡って検索して最も再生回数の多い告知ＩＤを決定（ＩＦ）する。

類似コンテンツ決定部４０７は、決定した告知ＩＤに関連するコンテンツ種類Ｐｉをコンテンツマスタから読み込み、このＵＲＬを有する告知基本情報を告知基本情報マスタから全て読込で類似するコンテンツ種別Ｐｐｉを決定する。

告知更新部４０８は、類似しているとされたコンテンツ種別Ｐｐｉを有する他の事業者の告知基本情報の告知ＩＤを読み込み、この告知ＩＤとこの告知ＩＤの告知基本情報の告知タイトル、アイコンＩＤ、表示する時間を新たな告知配信実情報Ｍｉとして（Ｓ４５）、メモリ４８１に記憶する。

図３５、図３６は本実施の形態２のＤＢサーバの動作を説明するフローチャートである。

告知削除部はバッチ配信用メモリの実配信リスト（事業者単位、視聴者単位）を指定して、その告知配信実情報Ｍｉを読み込む（Ｓ３１）。

次に、視聴者ログマスタ（テーブル）４１３からこの告知配信実情報Ｍｉの視聴者ＩＤ、告知ＩＤ、事業者ＩＤを有する過去のログ情報Ｆｉを読み込む（Ｓ３２）。

そして、この過去のログ情報Ｆｉに削除フラグが設定されているかどうかを判定する（Ｓ３３）。

ステップＳ３３において、削除フラグが設定されている場合は、ステップＳ３１で読み込んだ告知配信実情報Ｍｉを削除する（Ｓ３４）。

また、過去再生回数最多告知ＩＤ決定部４０６は、ステップＳ３２において読み込んだ告知配信実情報Ｍｉの視聴者ＩＤの属性情報Ｈｓｇｉ（性別、希望ジャンル、年齢、区域）を視聴者マスタ４７１ｈから読み込む（Ｓ３５）。

次に、過去再生回数最多告知ＩＤ決定部４０６は、この属性情報Ｈｓｇｉに最も類似する視聴者情報Ｓｇｉを視聴者マスタから決定する（Ｓ３６）。

次に、配信予定情報マスタ４７３から告知配信実情報Ｍｉに関連する配信フォルダＩＤを読み込む（Ｓ３７）。

そして、この配信先フォルダＩＤと視聴者情報Ｓｇｉの視聴者ＩＤを有する過去のログ情報Ｆｉを全事業者に渡って検索して最も再生回数の多い告知ＩＤを決定（ＩＦ）する（Ｓ３８）。

そして、図３６に示すように、類似コンテンツ決定部４０７は、決定した告知ＩＤに関連するコンテンツ種類Ｐｉをコンテンツマスタ４４４から読み込む（Ｓ３９）。

具体的には、コンテンツマスタ４４４は、コンテンツ（ジャンル）種別（ＰＴＡ、役場、料理、市場、イベント等）で分類されている。

また、告知基本情報マスタ４７３は告知ＩＤとコンテンツマスタのコンテンツのＵＲＬが関連させられて記憶されている。

つまり、決定した告知ＩＤを有する告知基本情報を引き当て、この告知基本情報に含まれているＵＲＬを読み込み、このＵＲＬをキーとしてコンテンツマスタのコンテンツ種別を読み込む。

そして、類似コンテンツ決定部４０７は、メモリ４８１の告知配信実情報Ｍｉ（削除されたものは除く）の全ての告知ＩＤを読み込み（Ｓ４０）、これらの告知ＩＤのコンテンツ種別を読み込む（Ｓ４１）。そして、ステップＳ３９で読み込んだコンテンツ種Ｐｉに類似しているコンテンツ種Ｐｐｉがあるかどうかを判定する（Ｓ４１）。

具体的には、これらの告知ＩＤを有する告知基本情報を告知基本情報マスタから全て読み込み、これらの告知ＩＤに関連しているコンテンツのＵＲＬを全て読み込む。

そして、これらのＵＲＬをキーとしてコンテンツマスタのコンテンツ種別を読み込んで、コンテンツ種別Ｐｉに類似するコンテンツ種別Ｐｐｉを決定する（重み付け関数等を用いるのがよい）。

次に、告知更新部４０８は、類似しているとされたコンテンツ種別Ｐｐｉを有する他の事業者の配信リストの告知基本情報を告知基本情報マスタから読み込み（Ｓ４３）、このＵＲＬに関連付けられている告知ＩＤを読み込む（Ｓ４４）。

そして、この告知ＩＤとこの告知ＩＤの告知基本情報の告知タイトル、アイコンＩＤ、表示する時間を新たな告知配信実情報Ｍｉとして（Ｓ４５）、メモリ４８１に記憶する（Ｓ４６）。

具体的には、類似するとされたコンテンツ種別ＰｐｉのＵＲＬを有する他の事業者の告知基本情報マスタを検索して、このＵＲＬが関連付けられている告知基本情報の告知ＩＤをステップＳ４５に渡している（図３７参照）。

次にメモリにステップＳ３１で読み込んだ告知配信実情報Ｍｉ以外の実配信リストの告知配信実情報Ｍｉがあるかどうかを判断し、他にない場合は処理を終了する（Ｓ４７）。

ステップＳ４７で他にあると判断した場合は、配信リストを次の配信リスとに更新して処理をステップＳ３１に戻す（Ｓ３８）。

すなわち、図３８（ａ）に示すように、視聴者Ａの詳細画面に表示される告知タイトルは、Ａ１、・・・Ａ６を表示するとした場合に、例えばＡ５が削除されることになる。

また、図３８（ｂ）に示すように、視聴者Ａの詳細画面に表示される告知タイトルは、Ａ１、・・・Ａ６を表示するとした場合に、例えばＡ２に代えてＣ１（事業者Ｃのもの）の告知タイトルが表示されることなる。

従って、実施の形態２においては、過去に削除したものは配信されないので、視聴者にとってみれば、希望する告知だけを受け取ることができる。

また、削除したとしても、視聴者が希望する類似の告知を受け取ることができるので、希望する告知だけを受け取ることができる。

＜他の実施の形態＞
なお、図３９に示すように、管理業者端末２００に河川業者端末５０、気象事業者端末６０、道路管理業者、ガス事業者、水道事業者等から情報の提供を受けて希望の視聴者に本日の告知として送付してもかまわない。

また、図４０に示すように本クラウドシステムと県警端末と警察官端末（タブレット又はスマートホーン）と通信ネットワークで接続して、警察官に伝える情報（犯罪発生、緊急、パトロール指示等）を上記のような告知として配信してもかまわない。

さらに、例えば、テレビ局において司会者に本視聴者端末を携帯させて、本日の番組にかかわる告知を配信するようにしてもかまわない。

４００ ＤＢサーバ
４１０ 告知タイトル配信処理部
４２０ 表示通過判定処理部
４３０ 履歴登録処理部
４４０ 詳細配信処理部符号の説明
６００ バッチサーバ
７００ スプレイ管理ｗｅｂサーバ
９００ 視聴者端末
１０２０ スプレイサーバ
１０００ ログイン受付・振分ｗｅｂサーバ
１１００ 低容量コンテンツ配信ｗｅｂサーバ

Claims (9)

1. 区域の告知を登録する事業者の事業者端末と、視聴者の視聴者端末と、告知サービスセンターと通信ネットワークで接続した告知双方向通信システムであって、
   前記告知サービスセンターは、
   複数のスプレイサーバを備えたスプレイｗｅｂサーバ部とバッチサーバを備えたバッチサーバ部とで前記視聴者端末へのプッシュルート部を構築して、さらに複数のコンテンツ配信ｗｅｂサーバを備えた低容量コンテンツ信ｗｅｂサーバ部で前記視聴者端末からのアクセスを受け付けるプルルート部を構築し、該プルルート部からはログイン後の各種情報を送信し、前記プッシュルート部からは前記事業者が登録した告知の詳細情報の告知タイトル情報を送信させる告知サービス提供用サーバを接続し、
   前記告知サービス提供用サーバは、
   前記告知タイトル情報を順次、記憶する告知タイトル情報用記憶手段を前記視聴者端末に生成させる制御データと、
   前記視聴者端末に事業者のサービス項目を表示する項目画面と、該サービス項目の詳細を表示する詳細画面とに分割させる制御データと、
   前記視聴者端末に項目画面用のメモリ、前記詳細画面用のメモリを生成させる制御データと、
   前記サービス項目のフォルダを前記項目画面用のメモリに生成させる制御データと、
   前記項目画面の前記サービス項目の選択に伴って、このサービス項目を前記詳細画面用のメモリを介して前記詳細画面に表示させる制御データと、
   前記告知タイトル情報用記憶手段の告知タイトル情報を読み込み、該読み込む毎に、前記告知サービスセンタに対して詳細画面を通過しない又は通過するのかどうかの通過有無問合情報を前記詳細画面に表示されているサービス項目名のフォルダＩＤを付加して前記告知サーバセンターに送信させる制御データと、
   前記告知サービスセンターから前記通過有無問合情報に対する通過応答結果情報を受信し、該通過応答結果情報が通過しないを示している場合は前記読み込んだ告知タイトル情報の告知タイトルを前記前記詳細画面用のメモリを介して前記詳細画面に表示すると共に、前記読み込んだ告知タイトル情報をこの通過応答結果情報が示すフォルダに格納させる制御データと、
   前記通過応答結果情報が通過するを示している場合は、前記読み込んだ告知タイトル情報の告知タイトルを表示させないで、該告知タイトル情報を前記通過応答結果情報に含まれている移動先のサービス項目のフォルダＩＤのフォルダに格納させる制御データと
   を前記プルルート部を介して送信する手段を有し、
   さらに、
   前記告知サービス提供用サーバは、
   前記事業者ＩＤと、前記サービス項目名と、前記サービス項目名の詳細画面において前記告知タイトルを通過させる又は通過させないを示す通過有無フラグと、通過する場合の移動先のフォルダＩＤ又は通過しない場合のフォルダＩＤとが対応させられた告知タイトル通過有無情報が記憶された告知タイトル通過有無マスタと、
   前記視聴者端末から前記通過有無問合情報を受信した場合は、該通過有無問合情報に含まれている事業者ＩＤ、視聴者ＩＤ、詳細画面に表示されているサービス項目名のＩＤを有する告知タイトル通過有無情報を前記告知タイトル通過有無情報マスタから読み込む手段と、
   前記読み込んだ告知タイトル通過有無情報を前記プルルート部で前記視聴者端末に送信する手段と、
   を有することを特徴とする告知双方向通信システム。
2. 前記告知サービス提供用サーバは、
   前記事業者端末からの告知タイトル、該告知タイトルの告知ＩＤ、利用者ＩＤ、事業者ＩＤ、前記告知タイトルの前記視聴者端末での表示開始時刻を含む告知基本情報を記憶した告知基本情報マスタと、
   現在時刻を計測するタイマーと
   を備え、
   前記タイマーの現在時刻に一定時刻を加算した時刻を一定先後配信時刻として求める手段と、
   前記一定先後配信時刻を有している前記告知基本情報を前記告知基本情報マスタから読み込み、この告知ＩＤ、告知タイトル、利用者ＩＤ、前記視聴者端末での表示開始時刻を前記告知タイトル情報として生成する手段と、
   前記告知タイトル情報を前記プッシュルート部のバッチサーバ、スプレイサーバ部を介して前記視聴者端末に送信させる手段と、
   を有することを特徴とする請求項１記載の告知双方向通信システム。
3. 前記告知サービス提供サーバは、
   前記視聴者端末の視聴者ＩＤ、ＩＰアドレスを含む視聴者情報を記憶した視聴者マスタと
   を備え、
   前記告知タイトル情報を前記バッチサーバ部に送信するとき、該告知タイトル情報に含まれている利用者ＩＤを有する全ての視聴者ＩＤ及びそのＩＰアドレスを前記視聴者マスタから読み込み、これらを前記告知タイトル情報に付加して送信する手段と
   を有することを特徴とする請求項１又は２記載の告知双方向通信システム。
4. 前記告知サービス提供用サーバは、
   前記視聴者端末に対して送信する、前記区域の事業者が提供するサービス項目名のフォルダＩＤと利用者ＩＤとを含む配信予定情報を関連付けて登録した配信予定情報マスタと、
   前記配信予定情報の事業者ＩＤと告知ＩＤと前記利用者ＩＤと前記サービス項目のフォルダＩＤとを含んで、前記視聴者端末へのログ情報として記憶された視聴者毎ログテーブルと
   を備え、
   前記バッチサーバ部に対して前記告知タイトル情報の送信に伴って、前記告知タイトル情報の告知ＩＤ、事業者ＩＤ、利用者ＩＤを返送させ、これらを有する前記配信予定情報の前記サービス項目のフォルダＩＤを読み込む手段と、前記バッチサーバ部から返信された前記告知ＩＤ、事業者ＩＤ、利用者ＩＤを有するログ情報を前記視聴者毎ログテーブルから引き当てる手段と、
   前記引き当てたログ情報に前記読み込んだフォルダＩＤを書き込みする手段と、
   前記告知タイトルに削除アイコンを含ませて表示させ、この削除アイコンが選択されたとき、選択された告知タイトルの告知ＩＤ、事業者ＩＤ、利用者ＩＤと削除フラグ並びに現在の詳細画面に表示されているサービス項目のフォルダＩＤとをタイトル削除情報として前記プルルート部を介して返信させる手段と、
   タイトル削除情報の事業者ＩＤ、告知ＩＤ、利用者ＩＤ、フォルダＩＤを有する前記ログ情報を引きあて、これに削除フラグを設定して、削除履歴を得る手段と
   を有することを特徴とする請求項１、２又は３記載の告知双方向通信システム。
5. 前記告知サービス提供用サーバは、
   前記告知タイトル情報の詳細情報を告知ＩＤ、視聴者ＩＤ、事業者ＩＤに関連付けて記憶した詳細情報コンテンツ用サーバを備え、
   前記視聴者端末から前記プルルート部を介して告知タイトルのタッチ情報を受信した場合は、このタッチ情報に含まれている事業者ＩＤ、告知ＩＤ、利用者ＩＤを有する詳細情報を引き当て、これを前記視聴者端末の前記詳細画面に表示させる指示を前記プルルート部を介して送信する手段と
   を有することを特徴とする請求項１、２、３又は４記載の記載の告知双方向通信システム。
6. 前記告知ＩＤ、利用者ＩＤ、事業者ＩＤに関連付けた音声を含む動画コンテンツを記憶したストレージサーバとを備え、
   前記視聴者端末と前記ストレージサーバとを接続して前記動画コンテンツを送信する低容量コンテンツ配信サーバ部と
   を有することを特徴とする請求項１乃至５のいずれかに記載の告知双方向通信システム。
7. 前記プッシュルート部のスプレーサーバ部、前記プルルート部の低容量コンテンツ配信ｗｅｂサーバ並びに大容量コンテンツ配信ｗｅｂサーバと前記視聴者端末とはセッション確立後は、ｐｏｎｇ／ｐｉｎｇでセッションを継続していることを特徴とする請求項１乃至６のいずれかに記載の告知双方向通信システム。
8. 前記視聴者端末は、一定時間間隔で再接続要求を前記プッシュルート部のスプレーサーバ部、前記プルルート部の低容量コンテンツ配信ｗｅｂサーバ並びに大容量コンテンツ配信ｗｅｂサーバに送信することを特徴とする請求項１乃至７のいずれかに記載の告知双方向通信システム。
9. 前記告知サービスセンターから通信ネットワークで告知サービス情報を受信して、画面に表示する視聴者端末であって、
   前記告知サービスセンターからの告知タイトル情報を順次、記憶する告知タイトル情報用記憶手段と、
   前記事業者のサービス項目を表示する項目画面と、該サービス項目の詳細を表示する詳細画面とに分割する手段と、
   前記項目画面用のメモリ、前記詳細画面用のメモリを備え、
   前記サービス項目のフォルダを前記項目画面用のメモリに生成する手段と、前記項目画面の前記サービス項目の選択に伴って、このサービス項目を前記詳細画面用のメモリを介して前記詳細画面に表示する手段と、
   前記告知タイトル情報用記憶手段の告知タイトル情報を読み込み、該読み込む毎に、前記告知サービスセンタに対して詳細画面を通過しない又は通貨するのかどうかの通過有無問合情報を前記詳細画面に表示されているサービス項目名のフォルダＩＤを付加して送信する手段と、
   前記告知サービスセンターから前記通過有無問合情報に対する通過応答結果情報を受信し、該通過応答結果情報が通過しないを示している場合は前記読み込んだ告知タイトル情報の告知タイトルを前記前記詳細画面用のメモリを介して前記詳細画面に表示すると共に、前記読み込んだ告知タイトル情報をこの通過応答結果情報が示すフォルダＩＤに格納する手段と、
   前記通過応答結果情報が通過するを示している場合は、前記読み込んだ告知タイトル情報の告知タイトルを表示させないで、該告知タイトル情報を前記通過応答結果情報に含まれている移動先のサービス項目のフォルダＩＤのフォルダに格納する手段と
   を有することを特徴とする視聴者端末。

Images