JP2004213287A - 情報配信システム、情報配信方法、データ送信装置、データ受信装置、データ管理装置及びプログラム - Google Patents

Abstract

【課題】ネットワークを介した企業等の事業者から消費者等の需要者への情報提供において、多種多量の情報から需要者が自らが必要とする情報のみを受け取ることができるようにし、この際、情報の受け取り側の個人情報や嗜好等に関する情報開示の必要性を可及的に少なくする。
【解決手段】メッセージヘッダ部をコネクション管理サーバに送信し、コネクション管理サーバにおいてこのメッセージヘッダ部をクライアント装置に送出することが許可されているか否かを判断し、許可されていると判断した場合はこのメッセージヘッダ部をクライアント装置に送信し、クライアント装置は受信したメッセージヘッダ部内の属性データ等に基づきこのメッセージヘッダ部を選択するか否かを判断し、選択すると判断した場合に、選択したメッセージヘッダ部内の入手先データ等を用いてコンテンツ本体としてのメッセージ本体部をメッセージ本体部配信サーバから受信する。
【選択図】 図１

Description

【０００１】
【発明の属する技術分野】
本発明は、情報配信システム、情報配信方法、データ送信装置、データ受信装置、データ管理装置及びプログラムに関するものである。
【０００２】
【従来の技術】
従来から、企業は、顧客が必要とする情報を顧客が必要とするときに簡単に認識させ、また、顧客の声に応えた商品開発を進めるという必要性を有していた。これらの目的を達成するため、企業は、ダイレクトメール（ＤＭ）を送付したり、チラシを配布したりして顧客に情報の配信を行っていた。しかし、このＤＭの送付やチラシの配布では企業にコストがかかりすぎた。また、企業がせっかく配信した情報も消費者にとって不要なものであれば消費者がこの情報を見てくれる可能性も低く無駄が多かった。一方、消費者が必要としない情報のＤＭの送付やチラシの配布は消費者にとっても迷惑であった。
【０００３】
このような状況の下、近年では、インターネットが発達し、インターネットを用いる消費者も増えてきたため、電子メールやホームページ等を用いて顧客に情報の配信を行う企業が増えてきている。このような電子メールやホームページ等を用いた情報配信によれば確かに企業はコストを下げることができる。しかし、このような電子メールやホームページ等による情報の配信においては以下のような問題を企業は有していた。
【０００４】
即ち、例えば電子メールによる情報配信は上述のようにコストがかからなく簡易であるため企業による顧客への情報提供メールは氾濫し、このような状況の下では、企業が配信した情報を顧客が確実に読むという保証はなかった。また、この電子メールによる情報配信を行うにしても情報配信の宛先となる顧客のメールアドレスを取得する負担が大きかった。一方、ホームページを用いた情報配信では消費者が企業のホームページを見に来てくれなければ情報配信の意味がなかった。消費者ごとにＷＥＢサーバの対応を変化させて各消費者に適合した情報を提供する仕組み（Ｏｎｅ ｔｏ Ｏｎｅ）の構築するのでは企業側の負担が大きかった。以上のように、企業は、自ら配信する情報をこの情報を必要とする顧客に確実に認識させることができているとは言えなかった。
【０００５】
また、多くの企業が顧客の購買履歴、嗜好、属性をデータベース（ＤＢ）化して蓄積し、蓄積されたデータをマイニングして顧客の将来の嗜好等を予測しようとしているが、この効果は今のところあまり出ていなかった。例えば、購買履歴等はあくまで過去のデータであるので、将来の消費者の嗜好等を正しく予測する材料とはなりえないことも多い（典型的には旅行履歴の活用）。また、このデータマイニングによる将来の予測には、多くの消費者の個人データの取得及び溜め込みが必要であるが、これを行うと、企業のシステムに大きな負荷がかかり、また、消費者から取得した個人情報に対する保護の負荷も大きくなる。このように、データマイニングでは消費者の将来の動向を正しく予測することに限界があった。
【０００６】
一方、企業による電子メール等を用いた情報の配信に対しては消費者は以下のような要求を有していた。
【０００７】
即ち、消費者は、自らが必要とする情報を企業から入手するまでの負荷を小さくしたいという要求を有していた。より詳しくは以下の通りである。現在、オプトインメールや、その他の広告等の情報提供メールにより、多くの情報が消費者に配信されて情報過多となり、これらの情報の中から必要な情報を取得する負担が大きかった。情報の配信許可（パーミッション）を与えていない企業からの情報配信も迷惑であるが、パーミッションを与えている企業からの配信情報でも不要な情報は多い。このため、顧客は自ら必要とする情報を必要な時に入手したいという要求を有していた。
【０００８】
また、消費者は企業から情報を入手するために個人情報を企業に開示したくないという要求を有していた。より詳しくは以下の通りである。即ち、インターネットを介して企業からの情報を入手する際、個人の年齢や性別等の基本的な情報や嗜好等に関する情報を企業から開示するよう要求されることが消費者は多い。企業から必要な情報を入手するためにはある程度の情報開示はやむをえないという消費者の認識も確かに存在するが、一方では企業による個人情報の保護の確実性に対する不安も広がってきている。また、仮に、個人情報が企業によって確実に保護されるとしても、個人情報の開示には抵抗のある消費者も多い。さらに、消費者が開示した個人情報に基づいて行われた企業によるマイニングの結果が自己への情報提供のために効果的に用いられるのは消費者に快適に受け止められるとは限られず、不快感を呼ぶこともある。
【０００９】
【特許文献】
特開２００１−３１３６６６号公報
【非特許文献】
神田陽治著「わかる！インスタントメッセージング」オーム社出版局、平成１４年１月２５日
【００１０】
【発明が解決しようとする課題】
本発明は、上記問題点に鑑みてなされたものであり、ネットワークを介した企業等の事業者から消費者等の需要者への情報提供において、多種多量の情報から需要者が自らが必要とする情報のみを受け取ることができ、情報の受け取り側の個人情報や嗜好等に関する情報開示の必要性を可及的に少なくした情報提供システム、情報提供方法、データ送信装置、データ受信装置、データ管理装置及びプログラムを提供することを目的とする。
【００１１】
【課題を解決するための手段】
本発明の情報配信システムは、メッセージ本体部を配信要求に応じて配信するメッセージ本体部配信サーバと、少なくとも、前記メッセージ本体部を識別するメッセージ本体部ＩＤと、前記メッセージ本体部の属性を示すメッセージ本体部属性データと、前記メッセージ本体部の入手先を示すメッセージ本体部入手先情報と、前記メッセージ本体部の発信者を示す発信者情報と、前記メッセージ本体部の宛先グループを示す宛先グループ情報とを含む第１のメッセージヘッダ部であって、前記第１のメッセージヘッダ部を識別するメッセージヘッダ部ＩＤをさらに含む第１のメッセージヘッダ部を配信するメッセージヘッダ部配信サーバと、前記発信者情報と、前記宛先グループ情報と、前記メッセージヘッダ部の宛先としてのクライアント装置ＩＤとを関連づけて格納するコネクションデータベースを記憶するコネクション管理記憶部を管理するコネクション管理サーバであって、前記メッセージヘッダ部配信サーバから受信した前記第１のメッセージヘッダ部内の前記発信者情報及び宛先グループ情報を前記コネクションデータベースに対応させて得られた前記クライアント装置ＩＤのクライアント装置に、少なくとも前記メッセージ本体部ＩＤと、前記メッセージ本体部属性データと、前記メッセージ本体部入手先情報と、前記発信者情報とを含む第２のメッセージヘッダ部を送出するコネクション管理サーバと、前記コネクション管理サーバから受信した前記第２のメッセージヘッダ部内の前記発信者情報及びメッセージ本体部属性データに基づいて前記第２のメッセージヘッダ部を選択するか否かを判断し、且つ、選択された前記第２のメッセージヘッダ部内の前記メッセージ本体部入手先情報及びメッセージ本体部ＩＤを用いて前記メッセージ本体部の配信要求データを作成して前記メッセージ本体部配信サーバに送出するクライアント装置と、を備えるものとして構成される。
【００１２】
本発明のデータ送信装置は、データの入力を受け付けるデータ入力部と、前記データ入力部に入力されたデータを用いて、少なくとも、メッセージ本体部を識別するメッセージ本体部ＩＤと、前記メッセージ本体部の属性を示すメッセージ本体部属性データと、前記メッセージ本体部の入手先を示すメッセージ本体部入手先情報と、前記メッセージ本体部の発信者を示す発信者情報と、前記メッセージ本体部の宛先グループを示す宛先グループ情報とを含むメッセージヘッダ部であって、前記メッセージヘッダ部を識別するメッセージヘッダ部ＩＤをさらに含むメッセージヘッダ部を組み立てるデータ組立部と、前記データ組立部で組み立られた前記メッセージヘッダ部を送出する第１の送信部と、を備えるものとして構成される。
【００１３】
本発明のデータ受信装置は、少なくとも、メッセージ本体部の発信者を示す発信者情報と、前記メッセージ本体部の属性を示すメッセージ本体部属性データと、前記メッセージ本体部の入手先を示すメッセージ本体部入手先情報と、前記メッセージ本体部を識別するメッセージ本体部ＩＤと、を少なくとも含むメッセージヘッダ部をデータ送信装置から受信する受信部と、前記受信部によって受信されたメッセージヘッダ部を前記メッセージヘッダ部を構成する各データに分解する分解部と、前記分解部から前記メッセージ本体部入手先情報及び前記メッセージ本体部ＩＤを受信し、受信した前記メッセージ本体部入手先情報及び前記メッセージ本体部ＩＤを用いて、メッセージ本体部の配信要求データを作成する配信要求データ作成部と、を備えるものとして構成される。
【００１４】
本発明のプログラムは、データ受信装置上で実行されるプログラムであって、
前記データ受信装置の受信部が、メッセージ本体部の発信者を示す発信者情報と、前記メッセージ本体部の属性を示すメッセージ本体部属性データと、前記メッセージ本体部の要約を示す要約データと、前記メッセージ本体部の入手先を示すメッセージ本体部入手先情報と、前記メッセージ本体部を識別するメッセージ本体部ＩＤとを少なくとも含むメッセージヘッダ部をデータ送信装置から受信するステップと、前記メッセージ本体部入手先情報及び前記メッセージ本体部ＩＤを用いて、メッセージ本体部の配信要求データを作成するステップと、を前記データ受信装置に実行させるものとして構成される。
【００１５】
本発明のデータ管理装置は、少なくとも、前記メッセージ本体部を識別するメッセージ本体部ＩＤと、前記メッセージ本体部の属性を示すメッセージ本体部属性データと、前記メッセージ本体部の入手先を示すメッセージ本体部入手先情報と、前記メッセージ本体部の発信者を示す発信者情報と、前記メッセージ本体部の宛先グループを示す宛先グループ情報とを含む第１のメッセージヘッダ部であって、前記第１のメッセージヘッダ部を識別するメッセージヘッダ部ＩＤをさらに含む第１のメッセージヘッダ部を受信する受信部と、前記発信者情報と、前記宛先グループ情報と、前記メッセージヘッダ部の宛先としてのクライアント装置ＩＤとを関連づけて格納するコネクションデータベースを記憶するコネクション管理記憶部と、前記メッセージヘッダ部配信サーバから受信した前記第１のメッセージヘッダ部内の前記発信者情報及び宛先グループ情報を前記コネクションデータベースに対応させて得られた前記クライアント装置ＩＤのクライアント装置に、少なくとも前記メッセージ本体部ＩＤと、前記メッセージ本体部属性データと、前記メッセージ本体部入手先情報と、前記発信者情報とを含む第２のメッセージヘッダ部を配信するか否かの判断をする制御部と、前記制御部によって配信すると判断された前記第２のメッセージヘッダ部をデータ受信装置へ送信する送信部と、を備えるものとして構成される。
【００１６】
本発明のデータ配信方法は、データ送信装置からデータ受信装置へデータを送信する情報配信方法であって、メッセージ本体部の発信者を示す発信者情報と、前記メッセージ本体部の宛先グループを示す宛先グループ情報と、前記メッセージ本体部の配信開始日時を示すメッセージヘッダ部情報発信日時データ、前記メッセージ本体部の有効期限を示すメッセージ本体部有効期限データと、前記メッセージ本体部の属性を示すメッセージ本体部属性データと、前記メッセージ本体部の要約を示す要約データと、前記メッセージ本体部の入手先を示すメッセージ本体部入手先情報と、前記メッセージ本体部を識別するメッセージ本体部ＩＤと、前記データ受信装置における表示画像状態や発音状態等の表示状態を変化させる表示変更データとからなるメッセージヘッダ部であって、前記メッセージヘッダ部を識別するメッセージヘッダ部ＩＤをさらに含むメッセージヘッダ部を送信するものとして構成される。
【００１７】
【発明の実施の形態】
以下、図面を参照しながら、本発明の実施の形態を説明する。
【００１８】
図１は、本発明の実施の形態としての情報配信システムの構成を示すブロック図である。
【００１９】
先ず、この情報配信システムの特徴について簡単に説明すると以下の通りである。
【００２０】
図１に示すように、この情報配信システムは、主として、複数の企業や小売店等の事業者の施設Ａ内にそれぞれ設置されたメッセージヘッダ部配信サーバ１及びメッセージ本体部配信サーバ２と、プラットフォーマの施設Ｂ内に設置されたコネクション管理サーバ３と、複数のユーザー宅にそれぞれ配置された、クライアントソフトウェアを内蔵するクライアント装置４とを備える。このコネクション管理サーバ３はクライアント装置４がオンライン状態かオフライン状態かを常に監視しており、オンライン状態のときは、例えばテキスト情報やマルチメディア情報等の情報をリアルタイムに送り込むことができるものである。
【００２１】
このような構成において、コネクション管理サーバ３はメッセージヘッダ部配信サーバ１からクライアント装置へのメッセージヘッダ部を受信し、このメッセージヘッダ部を、メッセージヘッダ部を配信条件を満たすクライアント装置にのみ送信する。メッセージヘッダ部を受信したクライアント装置４は受信したメッセージヘッダ部を、企業等に対しては開示されないユーザーの嗜好データ等に基づいてフィルタリング処理する。即ち、クライアント装置４は、必要なメッセージヘッダ部のみを選択し、必要でないメッセージヘッダ部は例えば廃棄する。そして、クライアント装置４は、選択されたメッセージヘッダ部に対応するメッセージ本体部（コンテンツ本体）を例えばユーザーの指示データ等に基づきメッセージ本体部配信サーバ２から受信する。
【００２２】
これにより、ユーザーは自らが配信を認めた企業からの情報のうち、自らが必要とする種類の情報のみを、嗜好・属性等の個人データを開示することなく取得できる。一方、企業は、ユーザーが必要とする情報のみを確実にユーザーに届けることができる。以下、このような情報配信システムについて詳しく説明する。
【００２３】
先ず、上述の情報配信システムを構成する各装置１〜４間で送受信されるメッセージヘッダ部及びメッセージ本体部について説明する。
【００２４】
図２は、これらメッセージヘッダ部とメッセージ本体部との基本的な関係を示す図である。図２に示すように、メッセージヘッダ部とメッセージ本体部は互いに対の関係にある。これらメッセージヘッダ部及びメッセージ本体部は、後に詳述するように、メッセージヘッダ部配信サーバ１（図１参照）上で同一のデータ作成フォームにて作成される。そして、作成されたメッセージヘッダ部及びメッセージ本体部は、図１からも分かるように、それぞれ別個のルートで配信され、最終的にはそれぞれ同一の各クライアント装置４に送り込まれる。即ち、ユーザーの観点から見た場合、メッセージヘッダ部とメッセージ本体部とは一体として認識されるものである。
【００２５】
これらメッセージヘッダ部及びメッセージ本体部の内容について詳しく説明すると以下の通りである。
【００２６】
まず、メッセージ本体部の内容について説明する。
【００２７】
図２に示すように、このメッセージ本体部の内容は、企業や小売店等の事業者がユーザーに送る（読んでもらい）広告情報等の情報（コンテンツ本体）である。
【００２８】
次に、メッセージヘッダ部の内容について説明する。
【００２９】
このメッセージヘッダ部の内容は、図２に示すように、メッセージ本体部に関連する種々の情報である。より詳しくは以下の通りである。
【００３０】
図３は、メッセージヘッダ部のデータ構造を示す図である。図４は、メッセージヘッダ部の具体的なデータ構造例を例えば３つ（メッセージヘッダ部−１、−２−３）示す図である。
【００３１】
図３及び図４を参照しながら、このメッセージヘッダ部のデータ構造について説明する。
【００３２】
図３に示すように、このメッセージヘッダ部のデータ構造は、例えば１０のデータ（１）〜（１０）から成る。以下、これらのデータ（１）〜（１０）について順次説明する。
【００３３】
図４に示すように、第１番目のデータ（データ（１））であるメッセージヘッダ部ＩＤは、複数のメッセージヘッダ部をそれぞれ識別するものである。このため、このメッセージヘッダ部ＩＤは、メッセージヘッダ部ごとに異なった値データを有し、例えば、重複データの発生を防ぐプログラムにより自動生成される。このメッセージヘッダ部ＩＤは、例えば、図４に示すように、特定の形式（例えば“アルファベット５つ”＋“−”＋“数字１つ”）を有する。
【００３４】
第２番目のデータ（データ（２））である発信者データ（発信者情報）は、メッセージヘッダ部に対応するメッセージ本体部（図２参照）を配信する企業等（発信者）を示すものである。メッセージ本体部の発信者は、メッセージヘッダ部の発信者でもある。
【００３５】
第３番目のデータ（データ（３））である宛先グループデータは、メッセージ本体部の宛先グループ（メッセージヘッダ部の宛先グループでもある）を示すものである。後述するように、クライアント装置４（図１参照）はいずれかの宛先グループデータに属する。この宛先グループデータは、例えばメッセージヘッダ部−１の宛先グループデータに示すように、複数の宛先グループを含んでもよい。この宛先グループデータは、後述するように、例えば予め登録された複数のデータの中から任意に選択されるものである（図７参照）。
【００３６】
第４番目のデータ（データ（４））である情報発信日時データ（メッセージ本体部情報発信日時データ）は、メッセージヘッダ部に対応するメッセージ本体部の配信が開始される日時を示すものである。このメッセージ本体部情報発信日時データは、図４に示すように、例えば特定の形式（例えば“ＹＹＹＹ／ＭＭ／ＤＤ”、“元号年／ＭＭ／ＤＤ”）を有する。例えばメッセージヘッダ部−１の場合、メッセージ本体部情報発信日時データは「２００２−１１−１」であるので、このメッセージヘッダ部−１に対応するメッセージ本体部−１は、２００２年１１月１日に配信が開始される。
【００３７】
第５番目のデータ（データ（５））である情報有効期限データ（メッセージ本体部情報有効期限データ）は、メッセージ本体部配信サーバ２（図１参照）から配信されるメッセージ本体部の配信終了日時を示すものである。このメッセージ本体部情報発信日時データは、図４に示すように、例えば特定の形式（例えば“ＹＹＹＹ／ＭＭ／ＤＤ”や“メッセージ本体部情報発信日時からの日数”）を有する。例えばメッセージヘッダ部−１の場合、メッセージ本体部情報有効期限データは「２００２−１１−３０」であるので、メッセージヘッダ部−１に対応するメッセージ本体部−１は２００２年１１月３０日に配信が終了する。また、メッセージヘッダ部−３の場合「３０ｄａｙｓ」であるので、メッセージヘッダ部−３に対応するメッセージ本体部−３は、メッセージ本体部情報発信日時データに示される「Ｈ１４−１０−１」から３０日後の平成１４年１０月３１日に配信が終了する。
【００３８】
第６番目のデータ（データ（６））であるメッセージ本体部の属性データ（メッセージ本体部属性データ）は、メッセージヘッダ部に対応するメッセージ本体部の属性を示すものである。例えば、メッセージヘッダ部−１の場合、メッセージ本体部属性データは「外貨預金」であるので、メッセージヘッダ部−１に対応するメッセージ本体部−１は外貨預金に関連する情報が含まれている。このメッセージ本体部属性データは、例えばメッセージヘッダ部−２に示すように、例えば複数の属性データを含んでもよい。このメッセージ本体部属性データは、後述するように、例えば予め登録された複数のデータの中から任意に選択されるものである（図７参照）。
【００３９】
第７番目のデータ（データ（７））である要約データは、メッセージ本体部の内容を要約した内容を示すものである。例えばメッセージヘッダ部−１の場合、この要約データは「外貨預金金利上乗せキャンペーン」であるので、メッセージヘッダ部−１に対応するメッセージ本体部には、外貨預金の金利上乗せに関する情報が具体的に含まれている。この要約データは、後述するように、例えばユーザーによって自由に記述作成される。この要約データは、例えばメッセージヘッダ部−１に示すように、宛先グループに応じて異なるデータであっても良い。
【００４０】
第８番目のデータ（データ（８））であるメッセージ本体部の入手先データ（メッセージ本体部入手先データ）は、メッセージ本体部の入手先（例えばＵＲＬ（ｕｎｉｆｏｒｍ ｒｅｓｏｕｒｃｅ ｌｏｃａｔｏｒ）等のＵＲＩ（ｕｎｉｆｏｒｍ ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ））を示すものである。例えばメッセージヘッダ部−１の場合、メッセージ本体部入手先データは「ＵＲＬ−１」であるので、メッセージ本体部−１はこのＵＲＬ−１を有するサーバ内に蓄積されている。
【００４１】
第９番目のデータ（データ（９））であるメッセージ本体部ＩＤは、複数のメッセージ本体部をそれぞれ識別するためのものである。このため、このメッセージ本体部部ＩＤは、例えばメッセージ本体部ごとに異なった値が設定される。このメッセージ本体部ＩＤは、例えば、図４に示すように、特定の形式（例えば“ｂｏｄｙ”＋“−”＋“任意の数字５桁以内”）を有する。
【００４２】
第１０番目のデータ（データ（１０））である表示変更データには、例えばクライアント装置４のディスプレイ（表示部）４ａ（図１参照）に表示されるアイコン（図１７の３８（１）〜３８（３）参照）の色や点灯状態を変えてユーザーにメッセージヘッダ部の着信を知らせるデータ（アイコン状態変更データ）や、メッセージヘッダ部のクライアント装置への着信を発音によってユーザーに知らせる発音状態変更データがある（以下これらを表示変更データと称する）。また、新たなデザイン（形状・色等）のアイコンや、データ表示用のフォーム（スキン）（図１７の３５参照）をユーザーに提供するための新アイコンデータや新表示フォームデータがある（以下これらを新デザインデータと称する）。
【００４３】
なお、上述した各データ項目（１）〜（１０）には必ずしも全てにデータが格納される必要はなく、例えば、図４のメッセージヘッダ部−１の表示変更データに示すようにデータが格納されなくともよい。また、上述したメッセージヘッダ部の構造は上記のものに限定されず、さらに新たな別のデータ項目が追加されてもよい。
【００４４】
上述した特徴を有するメッセージヘッダ部及びメッセージ本体部を用いて企業からユーザーへの好適な情報配信を行う本情報配信システムについて図１〜３３を用いて詳しく説明する。
【００４５】
まず、図１に示すように、メッセージヘッダ部配信サーバ１について説明する。
【００４６】
このメッセージヘッダ部配信サーバ１は、上述したメッセージヘッダ部及びメッセージ本体部（図２参照）をデータ入力者からの指示データ等に基づき作成する。そして、作成したメッセージヘッダ部及びメッセージ本体部を、メッセージ本体部についてはメッセージ本体部配信サーバ２に送出し、一方、メッセージヘッダ部についてはインターネット９等を介してコネクション管理サーバ３に送出するものである。より詳しくは以下の通りである。
【００４７】
図５は、メッセージヘッダ部配信サーバ１及びその周辺装置の構成を示すブロック図である。
【００４８】
まず、メッセージヘッダ部配信サーバ１及びその周辺装置の構成について説明する。
【００４９】
このメッセージヘッダ部配信サーバ１には、データ入力装置（キーボード）８、データ表示装置（ディスプレイ）６及びメッセージヘッダ部を記憶するメッセージヘッダ部記憶装置５がそれぞれインターフェース部（ＩＦ）を介して、接続されている。このような各周辺装置と接続されたメッセージヘッダ部配信サーバ１は、データ入力装置８からの入力データを用いて種々の処理を行う制御部１ａを備える。また、メッセージヘッダ部配信サーバ１は、この制御部１ａから入力データを受け取って、図３の構造にメッセージヘッダ部を組み立てるデータ組立部１ｂを備える。また、メッセージヘッダ部配信サーバ１は、このデータ組立部１ｂで組立てられたメッセージヘッダ部を変調処理するデータ変調部１ｃ、データ変調部１ｃで変調されたメッセージヘッダ部を、コネクション管理サーバ３に送出するデータ送信部１ｄを備える。一方、上述した種々の処理を行う制御部１ａは、データ組立部１ｂで組立てられたメッセージヘッダ部をメッセージヘッダ部記憶装置５に記憶するものとして構成されている。また、この制御部１ａは、データ入力装置８からの入力データ（例えばメッセージ本体部）をデータ組立部１ｂを介さずにデータ変調部１ｃに送出可能なものとして構成されている。この他、制御部１ａは、データを一時的に格納するメモリ１ｅや、メッセージヘッダ部及びメッセージ本体部の作成処理の際に用られるプログラム等を格納する記憶部１ｆを備える。なお、上述した周辺装置、即ち、データ入力装置８、データ出力装置６、メッセージヘッダ部記憶装置５は、メッセージヘッダ部配信サーバ１の一部として備えさせても良い。
【００５０】
以上のような構成を有するメッセージヘッダ部配信サーバ１の動作について説明する。
【００５１】
図６は、このメッセージヘッダ部配信サーバ１の動作を説明するためのフローチャート（ステップＳ１、Ｓ２）を示す図である。
【００５２】
このメッセージヘッダ部配信サーバ１の動作を各ステップＳ１、Ｓ２ごとに説明すると以下の通りである。
【００５３】
まず、ステップＳ１について説明する。
【００５４】
このステップＳ１は、メッセージヘッダ部及びメッセージ本体部を作成する工程である。より詳しくは以下の通りである。
【００５５】
図７は、メッセージヘッダ部及びメッセージ本体部を作成するメッセージヘッダ部及び本体部作成ツールを示す図である。具体的には、この図７は、図４の最上段に示したメッセージヘッダ部−１及びこれに対応するメッセージ本体部−１を作成する状態をディスプレイ６（図５参照）に示している。
【００５６】
メッセージヘッダ部及びメッセージ本体部はこのメッセージヘッダ部及びヘッダ部作成ツールを用いて作成される。より詳しくは以下の通りである。
【００５７】
図７に示すように、ディスプレイ６に表示されたメッセージヘッダ部及びメッセージ本体部作成フォーム（データ作成フォーム）１５内には、宛先グループデータの選択候補を複数格納したプルダウンボックス１６ａ、１６ｂ、メッセージ本体部属性データの選択候補を複数格納したプルダウンボックス１８が設けられている。プルダウンボックス１６ａ、１６ｂから入力装置（キーボード）８からの指示データに従って選択されたデータが宛先グループデータとなる。一方、プルダウンボックス１８から選択されたデータがメッセージ本体部属性データとなる。また、データ作成フォーム１５内には、要約データを作成するためのテキストボックス１９ａ、１９ｂが、上述したプルダウンボックス１６ａ、１６ｂに対応して設けられている。これらのテキストボックス１９ａ、１９ｂに入力されたキーボード８からの入力データが要約データとなる。メッセージヘッダ部の他の７つのデータ（１）（２）（４）（５）（８）〜（１０）（図３参照）も上と同様にしてそれぞれ決定される。一方において、データ作成フォーム１５内にはメッセージ本体部を作成するためのテキストボックス１７が設けられ、このテキストボックス１７に格納されたキーボード８からの入力データがメッセージ本体部となる。以上のようにして決定された各データ（１）〜（１０）（メッセージヘッダ部）及びメッセージ本体部はメモリ１ｅ（図５参照）に格納される。
【００５８】
上述したメッセージヘッダ部の作成例では、データ入力装置８からの選択指示データ及び入力データに従って各データを作成したが、これら各データは、所定のアルゴリズムにより自動的に決定されてもよい。例えば、それぞれ互いにユニークである必要があるメッセージヘッダ部ＩＤ（データ（１））は、重複データの発生するのを避けるべく、例えば重複データの発生を防ぐ所定のプログラムによって採番されてもよい。
【００５９】
以上のようにしてメッセージヘッダ部及びメッセージ本体部の内容が決定された状態で、データ作成フォーム１５内の送信ボタン２０がクリック等されると、ステップＳ２に示す送信処理が行われる。即ち、図５に示すように、メッセージヘッダ部及びメッセージ本体部の送信の指示をする送信指令データがデータ入力装置８から制御部１ａに送られるとステップＳ２に示す送信処理が行われる。
【００６０】
具体的には、制御部１ａが、メモリ１ｅ内に格納された上述の各データ（１）〜（１０）をデータ組立部１ｂに送り、各データを受け取ったデータ組立部１ｂは、メッセージヘッダ部の構造（図３参照）に従って各データをメッセージヘッダ部の構造に組立てる。組立てられたメッセージヘッダ部をデータ変調部１ｃはデータ組立部１ｂから受信して変調処理し、変調されたメッセージヘッダ部をデータ送信部１ｄはインターネット９等を介してコネクション管理サーバ３（図１参照）へ送信する。この際、制御部１ａは、データ組立部１ｂで組み立てられたメッセージヘッダ部をメッセージヘッダ部記憶装置５内に記憶する。一方、メモリ１ｅ内に格納されたメッセージ本体部をデータ変調部１ｃは受信して変調処理し、変調されたメッセージ本体部をデータ送信部１ｄがメッセージ本体部配信サーバ２（図１参照）に送出する。メッセージ本体部を受信したメッセージ本体部配信サーバ２はこのメッセージヘッダ部をメッセージ本体部記憶部１３（図１参照）内に記憶し、後の配信に備える。
【００６１】
上述したメッセージヘッダ部及びメッセージ本体部の作成において用いたメッセージヘッダ部及び本体部作成ツール（図７参照）は一例であり、例えばメッセージ本体部（コンテンツ本体）の内容や送信形態に応じて異なったタイプのテンプレートを用いることができる。なお、本実施の形態においては、図１からも分かるように、メッセージヘッダ部配信サーバ１とメッセージ本体部配信サーバ２とを別体として構成したが当然ながらこれらを一体として構成してもよい。
【００６２】
次に、コネクション管理サーバ３について説明する（図１参照）。
【００６３】
このコネクション管理サーバ３は、メッセージヘッダ部配信サーバ１からメッセージヘッダ部を受信し、受信したメッセージヘッダ部を、配信条件を満たす（配信可能状態にある）各クライアント装置４へ送信する。一方、配信条件を満たさない（配信不能状態にある）クライアント装置４が存在する場合には、配信可能状態にある各クライアント装置４にメッセージヘッダ部を送信した上で、このメッセージヘッダ部を一旦保存する（以上第１の配信処理）。そして、上述のクライアント装置４の配信不能状態が後に解除されたときは第１の配信処理で保存されたメッセージヘッダ部を配信不能状態が解除されたクライアント装置へ配信する（第２の配信処理）。より詳しくは以下の通りである。
【００６４】
図８は、コネクション管理サーバ３及びその周辺装置の構成を示すブロック図である。
【００６５】
まず、このコネクション管理サーバ３及びその周辺装置の構成について説明する。
【００６６】
図８に示すように、このコネクション管理サーバ３には、後述する配信許可テーブルを記憶するコネクション管理記憶装置１０が接続されている。また、コネクション管理サーバ３には、後述する未配信メッセージヘッダ部テーブル及び未配信クライアント装置ＩＤテーブルを記憶するキャッシュ記憶装置１２を管理するキャッシュサーバ１１が接続されている。これら各周辺装置１０、１１と接続されたコネクション管理サーバ３は、メッセージヘッダ部配信サーバ１（図１参照）からメッセージヘッダ部を受信するデータ受信部３ａと、このメッセージヘッダ部を復調処理するデータ復調部３ｂとを備える。また、このコネクション管理サーバ３は、復調されたメッセージヘッダ部を用いて後述する種々の処理（図９参照）を行い、また、クライアント装置４の接続状態（オンライン・オフライン）を監視する制御部３ｃを備える。この他、このコネクション管理サーバ３は、記憶部３ｄ、データ変調部３ｅ、データ送信部３ｆを備える。
【００６７】
以上のような構成を有するコネクション管理サーバ３の動作（第１の配信処理及び第２の配信処理）について説明する。
【００６８】
まず、第１の配信処理について説明する。
【００６９】
上述したようにこの第１の配信処理は、メッセージヘッダ部の宛先グループに属するクライアント装置４が配信可能状態である場合にはこのメッセージヘッダ部をクライアント装置に送信する。一方、配信不能状態にあるクライアント装置４がある場合には、配信可能状態にあるクライアント装置４にメッセージヘッダ部を送信した上で、このメッセージヘッダ部を保存する。
【００７０】
図９は、この第１の配信処理を説明するためのフローチャート（ステップＳ１０〜Ｓ１４−２）を示す図である。
【００７１】
このコネクション管理サーバ３の動作を各ステップＳ１０〜Ｓ１４−２ごとに説明する。
【００７２】
まず、ステップＳ１０について説明する。
【００７３】
このステップＳ１０は、メッセージヘッダ部内のメッセージ本体部情報発信日時データ（図３参照）と現在日時（例えばシステムタイム）とを比較して現在日時がメッセージ本体部情報発信日時に示される日時以降になっているか否かを制御部３ｃ（図８参照）が判断する工程である（ステップＳ１０−１）。比較の結果、現在日時がメッセージ本体部情報発信日時データに示される日時よりも前であれば（ステップＳ１０−１のＮＧ）、現在日時がその日時と同じ若しくは後になるまでメッセージヘッダ部を記憶部３ｄに保存する。一方、比較の結果、現在日時がメッセージ本体部情報発信日時データに示される日時と同じ若しくはこれよりも後であれば（ステップＳ１０−１のＧｏｏｄ）次のステップＳ１０−２に進む。
【００７４】
ステップＳ１０−２、Ｓ１１、Ｓ１２ではクライアント装置４が配信可能状態であるか否かの判断が行われる。より詳しくは以下の通りである。
【００７５】
ステップＳ１０−２は、クライアント装置４がオンライン状態であるか否かを制御部３ｃが判断する工程である。
【００７６】
図１１（ａ）は、各クライアント装置４の接続状態を示すテーブル（接続状態テーブル）を示す図である。ここで、クライアント装置ＩＤフィールドは、メッセージヘッダ部の最終的な配信先（宛先）となるクライアント装置４の識別子（クライアント装置ＩＤ）を格納するフィールドである。このクライアント装置ＩＤは、例えば、クライアント装置４にインストールされたクライアントソフトウェアの識別番号（例えばシリアルナンバ）である。一方、接続状態フィールドはクライアント装置４の接続状態データを格納するフィールドである。
【００７７】
本ステップＳ１０−２ではこの接続状態テーブルを用いてクライアント装置４のオンオフ状態の判断が行われる。判断の結果、クライアント装置４がオフライン状態であれば（ステップＳ１０−２）、クライアント装置４は配信不能状態であるとして後述するステップＳ１４−１に進む。一方、判断の結果、クライアント装置４がオンライン状態であれば（ステップＳ１０−２）次のステップＳ１１に進む。
【００７８】
ステップＳ１１は、各クライアント装置４へメッセージヘッダ部を配信する許可（配信許可）が、メッセージヘッダ部の発信者に与えられているか否かを各クライアント装置４ごとに判断する工程である。より詳しくは以下の通りである。
【００７９】
先ず、図１１（ｂ）を示す。図１１（ｂ）は、発信者、宛先グループ、クライアント装置ＩＤ、配信許可、配信日、配信時刻、接続状態をフィールド（項目）として有するテーブル（配信許可テーブル）を示す図である。各クライアント装置４への配信許可が与えられているか否かはこの配信許可テーブルに基づいて判断される。この配信許可テーブルは、コネクション管理記憶装置１０（図８参照）内に記憶されている。
【００８０】
先ず、この配信許可テーブルの各フィールドについて説明する。
【００８１】
まず、発信者及び宛先グループフィールドについて説明する。
【００８２】
図１１（ｂ）から明らかなように、発信者及び宛先グループフィールドは、発信者データ及び宛先グループデータ（図４参照）を格納するフィールドである。
【００８３】
次に、クライアント装置ＩＤフィールドについて説明する。
【００８４】
クライアント装置ＩＤフィールドは、上述したようにクライアント装置４の識別子（クライアント装置ＩＤ）を格納するフィールドである。図１１（ｂ）に示すように、１つのクライアント装置ＩＤは単数あるいは複数の宛先グループに属する。例えば、クライアント装置ＩＤ「１２３４５−Ａ」は、３つの宛先グループ「ＡＢＣ銀行の個人顧客」「チケット検索サービス登録者」「ネット八百屋会員」に属する。
【００８５】
次に、配信許可フィールドについて説明する。
【００８６】
配信許可フィールドは、メッセージヘッダ部内の発信者データに対して配信許可が与えられているか否かを示す配信許可データ（配信条件データ）を格納するフィールドである。例えば、第１番目のレコードの場合、配信許可データが「Ｙｅｓ」であるので、発信者データ「ＡＢＣ銀行」を含むメッセージヘッダ部（図４参照）を、クライアント装置ＩＤ「１２３４５−Ａ」を有するクライアント装置へ配信することは許可されている。一方、第２番目のレコードの場合、配信許可データが「Ｎｏ」であるので、発信者データ「ＡＢＣ銀行」を含むメッセージヘッダ部（図４参照）を、クライアント装置ＩＤ「１２３４５−Ｂ」を有するクライアント装置へ配信することは許可されていない。
【００８７】
次に、配信日及び配信時刻フィールドについて説明する。
【００８８】
配信日及び配信時刻フィールドは、メッセージヘッダ部の配信可能な曜日及び時刻を示す配信日及び配信時刻データ（配信条件データ）を格納するフィールドである。例えば、第１番目のレコードの場合、配信日データは「月・水・金」であるので、メッセージヘッダ部を「火曜日」に配信することは許容されていない。
【００８９】
上述した配信許可データ、配信日データ、配信時刻データは、クライアント装置４からの指示データに従って設定及び変更できる。これについては後述する。
【００９０】
本ステップＳ１１は、上述したように、この配信許可テーブルを用いてメッセージヘッダ部を各クライアント装置へ配信するか否かを各クライアント装置４ごとに判断する工程である（図９のステップＳ１１）。より詳しくは以下の通りである。
【００９１】
即ち、図８に示す制御部３ｃは、メッセージヘッダ部内の発信者データ及び宛先グループデータ（図３参照）をキーにして配信許可テーブル（図１１（ｂ）参照）を検索する。検索されたレコードの配信許可データが「Ｎｏ」であれば（ステップＳ１１のＮｏ）後述するステップＳ１４−１へ進む。一方、検索されたレコードの配信許可データが「Ｙｅｓ」であれば（ステップＳ１１のＹｅｓ）次のステップＳ１２に進む。検索されたレコードが複数あればその全てのレコードについて本ステップＳ１１における判断及び以降のステップ１２〜Ｓ１４−２の処理が行われる。以降の説明では１つのレコードに着目して説明する。
【００９２】
次に、ステップＳ１２について説明する。
【００９３】
ステップＳ１２は、上のステップＳ１１で検索されたレコードにおける配信日データ及び配信時刻データ（図１１（ｂ）参照）を現在の曜日及び時刻と制御部３ｃ（図８参照）が比較する工程である。比較の結果、現在の曜日及び時間がこれらの配信日データ及び配信時刻データを満たさないと判断すれば（ステップＳ１２のＮｏ）後述するステップＳ１４−１へ進む。一方、比較の結果、現在の曜日及び時間がこれらの配信日データ及び配信時刻データを満たすと判断すれば（ステップＳ１２のＹｅｓ）次のステップＳ１３に進む。
【００９４】
次に、ステップＳ１３について説明する。
【００９５】
このステップＳ１３は、上のステップＳ１１、Ｓ１２による判断処理を経たメッセージヘッダ部をインターネット９（図１参照）等を介してクライアント装置４に送信する工程である。
【００９６】
即ち、図８に示すように、制御部３ｃによる判断を経たメッセージヘッダ部をデータ変調部３ｅが変調処理して、変調されたメッセージヘッダ部をデータ送信部３ｆが送出する。この際、メッセージヘッダ部内から、少なくともメッセージ本体部ＩＤ、メッセージ本体部属性データ、メッセージ本体部入手先情報、発信者データ（図４参照）を抜き出した別のメッセージヘッダ部（第２のメッセージヘッダ部）を制御部３ｃが作成し、この別のメッセージヘッダ部をデータ変調部３ｅ及びデータ送信部３ｆを介して送出してもよい。
【００９７】
次に、ステップＳ１４−１及び１４−２について説明する。
【００９８】
これらステップＳ１４−１及び１４−２はクライアント装置４が配信不能状態であった場合に（ステップＳ１１のＮｏ、ステップＳ１２のＮｏ）行われる処理である。この配信不能状態には、上述した配信許可データが「Ｎｏ」の場合、現在日及び現在時間が配信日及び配信時刻データを満たさない場合の他、クライアント装置４がオフライン状態の場合を含む。
【００９９】
まず、ステップＳ１４−１について説明する。
【０１００】
このステップＳ１４−１は、クライアント装置４の配信不能状態が解除されたときにメッセージヘッダ部を配信するため、メッセージヘッダ部等を保存しておく工程である。より詳しくは以下の通りである
先ず、図１３を示す。この図１３は、メッセージヘッダ部ＩＤ、メッセージヘッダ部有効期限、メッセージヘッダ部、をフィールドとして有するテーブル（未配信メッセージヘッダ部テーブル）を示す図である。
【０１０１】
この未配信メッセージヘッダ部テーブルの各フィールドについて簡単に説明すると以下の通りである。
【０１０２】
メッセージＩＤフィールドはメッセージヘッダ部内のメッセージＩＤを格納するフィールドである。メッセージヘッダ部フィールドは、メッセージヘッダ部自体を格納するフィールドである。メッセージヘッダ部有効期限フィールドは、メッセージヘッダ部の配信期限を示すデータを格納するフィールドである。
【０１０３】
本ステップＳ１４−１は、具体的には、この未配信メッセージヘッダ部テーブルにレコードを作成する。例えば、図１３には、図１１（ｂ）の配信許可テーブルにおいて配信許可データが「Ｎｏ」であるクライアント装置ＩＤを含むメッセージヘッダ部（メッセージヘッダ部−１、−２）（図４参照）が保存されている。この未配信メッセージヘッダ部テーブルはキャッシュ記憶装置１２（図８参照）に記憶されている。本ステップについてさらに詳しく述べれば以下の通りである。
【０１０４】
即ち、制御部３ｃ（図８参照）が、この未配信メッセージヘッダ部テーブル（図１３参照）に格納するデータ（メッセージヘッダ部ＩＤ、メッセージヘッダ部有効期限データ、メッセージヘッダ部）をメッセージヘッダ部を用いて作成する。メッセージヘッダ部有効期限データには、例えばメッセージヘッダ部内のメッセージ本体部有効期限データを用いる。制御部３ｃは作成した各データを未配信メッセージヘッダ部テーブル（図１３参照）にレコードとして追加する。具体的には、図８に示すように、制御部３ｃが、レコードの作成を命ずる指令データを作成して、キャッシュサーバ１１の制御部１１ａに送信する。この指令データを受けた制御部１１ａは、この指令データに基づいてキャッシュ記憶装置１２内の未配信メッセージヘッダ部テーブルにレコードを作成する。
【０１０５】
なお、メッセージヘッダ部フィールドには、上述した別のメッセージヘッダ部（メッセージヘッダ部内から少なくともメッセージ本体部ＩＤ、メッセージ本体部属性データ、メッセージ本体部入手先情報、発信者データを抜き出したもの）を格納してもよい。
【０１０６】
次に、ステップＳ１４−２について説明する。
【０１０７】
本ステップＳ１４−２は、配信不能状態にあるクライアント装置４のクライアント装置ＩＤと、メッセージヘッダ部のメッセージヘッダ部ＩＤ（クライアント装置ＩＤ−メッセージヘッダ部Ｉ）とを記憶する工程である。より詳しくは以下の通りである。
【０１０８】
先ず、図１２を示す。図１２は、メッセージヘッダ部ＩＤ及びクライアント装置ＩＤをフィールドとして有するテーブル（未配信クライアント装置ＩＤテーブル）を示す図である。
【０１０９】
本ステップＳ１４−２は、具体的には、この未配信クライアント装置ＩＤテーブルにレコードを作成する工程である。即ち、配信不能状態にあるクライアント装置ＩＤはこの未配信クライアント装置ＩＤテーブルに記憶される。例えば、図１２の未配信クライアント装置ＩＤテーブルには、配信許可データ（図１１（ｂ）参照）が「Ｎｏ」のクライアント装置ＩＤ「１２３４５−Ｂ」「１２３４５−Ｃ」「１２３４５−Ｅ」と、これらのクライアント装置ＩＤを宛先グループに含むメッセージヘッダ部のメッセージヘッダ部ＩＤ「ＡＢＣＤＥ−１」「ＡＢＣＤＥ−１」「ＥＦＧＨＩ−１」（図４参照）が示されている。本ステップについてさらに詳しく述べれば以下の通りである。
【０１１０】
即ち、制御部３ｃ（図８参照）が、図１１（ｂ）における配信許可テーブルから配信不能状態（例えば配信許可データが「Ｎｏ」等）であるクライアント装置ＩＤを抽出する。一方において、メッセージヘッダ部内からメッセージヘッダ部ＩＤを制御部３ｃは抽出する。制御部３ｃはレコードの作成を命ずる指令データをキャッシュサーバ１１の制御部１１ａ（図８参照）に送信し、この指示データを受信した制御部１１ａは、この指令データに基づき未配信クライアント装置ＩＤテーブルにレコードを作成する。
【０１１１】
次に、第２の配信処理について説明する。
【０１１２】
この第２の配信処理は、上述したように、第１の配信処理で配信不能状態であったクライアント装置４が配信不能状態から解除された場合に、このクライアント装置４に第１の配信処理で保存したメッセージヘッダ部を配信する処理である。
【０１１３】
図１０は、この第２の配信処理を説明するためのフローチャート（ステップＳ１５〜Ｓ１９）を示す図である。
【０１１４】
この第２の配信処理を各ステップＳ１５〜Ｓ１９ごとに説明する。
【０１１５】
まず、ステップＳ１５について説明する。
【０１１６】
このステップＳ１５は、配信不能状態が解除されたクライアント装置が発生したか否かを判断する工程である。具体的には以下のようにしてこの判断を行う。
【０１１７】
第１に、配信許可テーブル（図１１（ｂ）参照）においてオフライン状態からオンライン状態に変化したレコードが発生したか否かを判断する。そのようなレコードが発生したと判断した場合、そのレコードにおける配信許可データ、配信日データ及び配信時刻データがそれぞれ上述したステップＳ１１、Ｓ１２の条件を満足するか否かを判断する。満足すると判断した場合は（ステップＳ１５のＹｅｓ）、次のステップＳ１６に進む。
【０１１８】
第２に、配信許可テーブル（図１１（ｂ）参照）において配信許可データが「Ｎｏ」から「Ｙｅｓ」に変化したレコードが発生したか否かを判断する。配信許可データが「Ｎｏ」から「Ｙｅｓ」に変化したレコードが発生したと判断した場合、さらに現在の曜日及び現在時刻がそのレコードにおける配信日データ及び配信時刻データを満足するか否かを制御部３ｃは判断する（ステップＳ１１、Ｓ１２参照）。満足すると判断した場合は、満足すると判断した場合は（ステップＳ１５のＹｅｓ）、次のステップＳ１６に進む。
【０１１９】
第３に、配信許可データが「Ｙｅｓ」のまま変わらないが、現在の曜日・時刻が配信日データ及び配信時刻データを満足することとなったレコードが発生したか否かを判断する。そのようなレコードが発生したと判断した場合（ステップＳ１５のＹｅｓ）次のステップＳ１６に進む。
【０１２０】
次に、ステップＳ１６について説明する。
【０１２１】
このステップＳ１６は、配信不能状態が解除されたクライアント装置４に、配信すべきメッセージヘッダ部が存在するか否かを判断する工程である。
【０１２２】
より詳しくは、配信不能状態が解除されたクライアント装置４のクライアント装置ＩＤ（図４参照）をキーとして図１２の未配信クライアント装置ＩＤテーブルを検索する。
【０１２３】
具体的には、図８に示すように、キャッシュサーバ１１内の制御部１１ａが制御部３ｃからの指令データに基づき未配信クライアント装置ＩＤテーブルを検索する。検索の結果、該当レコードがなければ、その旨の検索結果データを制御部３ｃに返信し、検索結果データを受信した制御部３ｃは、その検索結果データに基づき、配信すべきメッセージヘッダ部は存在しないと判断する（ステップＳ１６のＮｏ）。一方、検索の結果、該当レコードがあれば（ステップＳ１６のＹｅｓ）配信するメッセージヘッダ部が存在すると判断して次のステップＳ１７に進む。
【０１２４】
次に、ステップＳ１７について説明する。
【０１２５】
このステップＳ１７は、配信すべきメッセージヘッダ部を未配信メッセージヘッダ部テーブル（図１３参照）から取得する工程である。
【０１２６】
より詳しくは、図８に示すように、キャッシュサーバ１１内の制御部１１ｃが、上のステップＳ１６で検索されたレコード（メッセージヘッダ部ＩＤ−クライアント装置ＩＤ）（図１２参照）に含まれるメッセージヘッダ部ＩＤを用いて未配信メッセージヘッダ部テーブル（図１３参照）を検索する。そして、制御部１１ｃは、検索されたレコードの各データ（メッセージＩＤ−メッセージヘッダ部有効期限データ−メッセージヘッダ部）を制御部３ｃに送出する。制御部３ｃは、受信した各データのうちメッセージヘッダ部有効期限データを現在日時（例えばシステムタイム）と比較する。比較の結果、現在日時が、メッセージヘッダ部有効期限データに示される日時を過ぎていないと制御部３ｃは判断すれば（ステップＳ１７のＹｅｓ）、メッセージヘッダ部をクライアント装置４に向けて送信する（ステップＳ１９）。一方、比較の結果、現在日時が、メッセージヘッダ部有効期限データに示される日時を過ぎていると制御部３ｃは判断すれば（ステップＳ１７のＮｏ）、未配信メッセージヘッダ部テーブル及び未配信クライアント装置ＩＤテーブル（図１２参照）から対応レコードを制御部１１ａを介して削除する。
【０１２７】
なお、現在日時がメッセージヘッダ部有効期限を越えたレコード（図１３参照）、及びこのレコードに対応する未配信クライアント装置ＩＤテーブルのレコード（図１２参照）については、ステップＳ１７に拘わらず、自動的に削除されるようにしてもよい。
【０１２８】
上述したコネクション管理サーバ３の説明では、未配信メッセージヘッダ部テーブル（図１３参照）及び未配信クライアント装置ＩＤテーブル（図１２参照）の２つのテーブルを作成したが（ステップ１４−１及び１４−２）、これらのテーブルを一体化させたテーブルを作成してもよい。即ち、図１２及び図１３を参照して分かるように、メッセージヘッダ部ＩＤ、メッセージヘッダ部有効期限、メッセージヘッダ部及びクライアント装置ＩＤをフィールドとするテーブルを作成してもよい。
【０１２９】
次に、クライアント装置４（図１参照）について説明する。
【０１３０】
このクライアント装置４は、コネクション管理サーバ３からメッセージヘッダ部を受信し、受信したメッセージヘッダ部の発信者データ及びメッセージ本体部属性データに基づいてフィルタリング処理を行う。即ち、クライアント装置４は、このメッセージヘッダ部が必要なものであるか否かを判断する。クライアント装置４は、必要なものであると判断すればこのメッセージヘッダ部を選択（保存）し、このメッセージヘッダ部の要約データを表示処理等する（メッセージヘッダ部選択処理）。そして、クライアント装置４は、表示された要約データ等に対してクリック等のアクションが生じた場合には、この要約データに対応するメッセージ本体部をメッセージ本体部配信サーバ２から取得しユーザーに認識させる（メッセージ本体部取得処理）。このクライアント装置４は、例えばデスクトップパソコンやノートパソコンであり、携帯電話端末やＰＨＳ端末のような移動端末装置も含む。なお、クライアント装置４は、コネクション管理サーバ３から、メッセージヘッダ部ではなく、前述した別のメッセージヘッダ部（メッセージヘッダ部内から少なくともメッセージ本体部ＩＤ、メッセージ本体部属性データ、メッセージ本体部入手先情報、発信者データを抜き出したもの）を受信してもよい。また、発信者データ及びメッセージ本体部属性データに基づくフィルタリング処理はコネクション管理サーバ３で行ってもよい。
【０１３１】
以下、クライアント装置４について詳しく説明する。
【０１３２】
図１４は、クライアント装置４の構成を示すブロック図である。
【０１３３】
まず、このクライアント装置４の構成について説明する。
【０１３４】
このクライアント装置４は、コネクション管理サーバ３からメッセージヘッダ部やメッセージ本体部を受信するデータ受信部４ｂと、データ受信部４ｂからメッセージヘッダ部及びメッセージ本体部等を受け取って復調処理するデータ復調部４ｃとを備える。また、このクライアント装置４は、データ復調部４ｃによって復調されたメッセージヘッダ部を、メッセージヘッダ部を構成する各データ（図３参照）に分解処理するデータ分解部４ｄを備える。また、このクライアント装置４は、この分解処理による各データを用いて後述の各種処理を行う制御部４ｅを備える。この制御部４ｅに接続された記憶部４ｆには、上述したクライアントソフトウェアが内蔵されいる。また、制御部４ｅからの指示データによってメッセージ本体部配信サーバ２（図１参照）にメッセージ本体部の配信要求データを作成する配信要求データ作成部４ｉをクライアント装置４は備える。また、このクライアント装置４は、この配信要求データを変調処理するデータ変調部４ｊ、変調された配信要求データを送信するデータ送信部４を備える。その他、クライアント装置４は、データ入力部４ｇ、データ表示部４ａ、メモリ４ｍを備える。
【０１３５】
以上のような構成を有するクライアント装置４の動作（メッセージヘッダ部選択処理及びメッセージ本体部取得処理）について説明する。
【０１３６】
まず、メッセージヘッダ部選択処理について説明する。
【０１３７】
図１５は、メッセージヘッダ部選択処理を説明するためのフローチャート（ステップＳ２１〜Ｓ２６）を示す図である。
【０１３８】
このクライアント装置４の動作を各ステップＳ２１〜Ｓ２６ごとに説明する。
【０１３９】
まず、ステップＳ２１について説明する。
【０１４０】
このステップＳ２１は、メッセージヘッダ部内の発信者データ及びメッセージ本体部属性データを用いてこのメッセージヘッダ部を選択するか否かの判断（フィルタリング処理）を行う工程である。より詳しくは以下の通りである。
【０１４１】
先ず、図１６を示す。図１６は、基準発信者、基準メッセージ本体部属性、受信選択（選択条件）をフィールドとして有する受信選択テーブルを示す図である。上述のフィルタリング処理はこの受信選択テーブルに基づいて行われる。この受信選択テーブルはクライアント装置４の記憶部４ｆ（図１４参照）内に格納されている。
【０１４２】
この受信選択テーブルの見方について説明すると以下の通りである。
【０１４３】
第１及び２番目のレコードを例にして説明する。第３番目のレコード以降については同様であるので説明を省略する。
【０１４４】
まず、第１番目のレコードについて説明する。
【０１４５】
即ち、第１番目のレコードにおいては受信選択データ（選択条件データ）が「選択」とされている。従って、発信者データ「ＡＢＣ銀行」及びメッセージ本体部属性データ「外貨預金」を含むメッセージヘッダ部は選択される。
【０１４６】
次に、第２番目のレコードについて説明する。
【０１４７】
一方、第２番目のレコードにおいては受信選択データが「非選択」とされている。従って、発信者データ「ＡＢＣ銀行」及びメッセージ本体部属性データ「定期預金」のみを含むメッセージヘッダ部は選択されしない（例えば廃棄される）。なお、メッセージヘッダ部内に「外貨預金」「普通預金」の２つのメッセージ本体部属性データが含まれる場合は、第１番目のレコードの受信選択データ「選択」が優先適用されて選択される。
【０１４８】
この受信選択テーブルにおける受信選択データ「選択」「非選択」は後述するようにユーザー側において随意に設定可能になっており、従って、ユーザーは自らの嗜好等を企業等に知らせることなく必要なメッセージヘッダ部及びこれに対応するメッセージ本体部を取得できる。
【０１４９】
本ステップＳ２１は、具体的には、この受信選択テーブルを用いてメッセージヘッダ部のフィルタリング処理を行う。
【０１５０】
より詳しくは、図１４に示すように、制御部４ｅは、発信者データ及びメッセージヘッダ部属性データをキーとして受信選択テーブル（図１６参照）を検索し、検索されたレコードにおける受信選択データの内容を確認する。確認の結果、受信選択データが「非選択」であれば（ステップＳ２１のＮｏ）、そのメッセージヘッダ部を例えば廃棄（消去）する（ステップＳ２７）。一方、受信選択データが「選択」であればメッセージヘッダ部を選択して各データ（１）〜（１０）（図４参照）を記憶部４ｆに保存し（ステップＳ２１のＹｅｓ）次のステップＳ２２へ進む。
【０１５１】
次に、ステップＳ２２について説明する（図１５参照）。
【０１５２】
このステップＳ２２は、選択されたメッセージヘッダ部における要約データをディスプレイ４ａ（図１４参照）上の表示フォームに表示する工程である。より詳しくは以下の通りである。
【０１５３】
図１７は、表示フォーム（バディリスト）３５内に要約データ３７（１）〜（３）（図４参照）を表示した状態を示す図である。当然ながら、表示フォーム３５の形状・色等は図１７に示したものに限定されない。各要約データ３７（１）〜（３）は、図４に示すように、メッセージヘッダ部−１、−２、−３にそれぞれ対応するものである。即ち、このクライアント装置４はクライアント装置ＩＤ「１２３４５−Ａ」（図１１（ｂ）参照）を有し、図４に示す各メッセージヘッダ部−１、−２、−３（図４参照）を選択している（図１６参照）。図４に示すメッセージヘッダ部−１の要約データのうち上段のものが要約データ３７（１）として表示されている。これは、このクライアント装置４（クライアント装置ＩＤ「１２３４５−Ａ」）が宛先グループ「ＡＢＣ銀行の個人顧客」に属するからである。なお、各要約データ３７（１）〜（３）に対応して各要約データの発信者に対応したアイコン３８（１）〜３８（３）が表示されている。
【０１５４】
また、表示フォーム３５内には人名リスト３９が表示されており、このクライアント装置４は人名リスト３９に登録されている人名データを有するクライアント装置とリアルタイムに通信できる。また表示フォーム３５内にはアイコン４１により特定される発信者から提供された要約情報４０が表示されている。これらは何れも図示しないサーバによって行われる。
【０１５５】
図１８は、要約データを表示する処理を具体的に説明するためのフローチャートを示す図である。
【０１５６】
要約データの表示処理について説明すると以下の通りである。
【０１５７】
即ち、制御部４ｅ（図１４参照）はデータ分解部４ｄから取得した要約データを（ステップＳ４１）、データ表示部４ａに送出する（ステップＳ４２）。要約データを受信したデータ表示部４ａは要約データを表示する（図１７参照）（ステップＳ４３）。
【０１５８】
次に、ステップ２３、Ｓ２４（図１５参照）について説明する。
【０１５９】
ステップ２３は、選択したメッセージヘッダ部内にアイコン状態変更データや発音状態変更データ等の表示変更データ（図４参照）が含まれているか否かを判断する工程である。一方、ステップＳ２４は、ステップＳ２３で表示変更データが含まれていると判断された場合に（ステップＳ２３のＹｅｓ）、表示変更データに対応した着信表示処理を行う工程である。
【０１６０】
以下、アイコン状態変更データを用いた着信表示処理、及び発音状態変更データを用いた着信表示処理についてそれぞれ説明する。
【０１６１】
まず、アイコン状態変更データを用いた着信表示処理（アイコン状態変更処理）について説明する。
【０１６２】
このアイコン状態変更処理は、図１７から分かるように、例えばアイコン３８（１）〜３８（３）の色や点滅の状態を変える工程である。
【０１６３】
図１９は、アイコン状態変更処理を説明するためのフローチャートを示す図である。
【０１６４】
以下、このアイコン状態変更処理について説明する。
【０１６５】
まず、制御部４ｅ（図１４参照）は、上述のアイコン状態変更データを用いて、アイコンの色・点滅具合を変化させた新状態アイコンデータを作成する（ステップＳ５１）。具体的には、変更対象となるアイコンデータを上述のアイコン状態変更データによって変更処理して新状態アイコンデータを作成する。変更対象となるアイコンデータは、例えば発信者別のアイコンデータを示す図２１に示すようにテーブル形式にて、あらかじめ記憶部４ｆに記憶されている。制御部４ｅは、作成した新状態アイコンデータをデータ表示部４ａに送出する（ステップＳ５２）。なお、図１７のアイコン３８（２）は、メッセージヘッダ部―２（図４参照）内のアイコン状態変更データ及びアイコンテーブル（図２１参照）から分かるように、三角形状を有し、点滅している。
【０１６６】
次に、発音状態変更データを用いた着信表示処理（音状態変更処理）について説明する。
【０１６７】
図２０は、音状態変更処理を説明するためのフローチャートを示す図である。
【０１６８】
以下、この音状態変更処理について説明する。
【０１６９】
まず、制御部４ｅ（図１４参照）は、発音状態変更データに対応する着信音データを記憶部４ｆから取り出して音源回路４ｎに送出する（ステップＳ５３）。着信音データは予め記憶部４ｆに格納されている。着信音データを受信した音源回路４ｎは内蔵する音源データを用いて対応する音電気信号を生成し、スピーカ（音発生器）４ｐにこの音電気信号を送出する（ステップＳ５４）。スピーカ４ｐはこの音電気信号に対応した音を発する（ステップＳ５４）。
【０１７０】
次に、ステップＳ２５、Ｓ２６（図１５参照）について説明する。
【０１７１】
ステップＳ２５は、選択したメッセージヘッダ部内に、新アイコン及び新表示フォーム（スキン）データ等の新デザインデータが含まれているか否かを判断する工程である。一方、ステップＳ２６は、ステップＳ２５で新アイコンあるいは新表示フォームデータが含まれていると判断された場合に（ステップＳ２５のＹｅｓ）各データを登録（保存）する工程である。本ステップＳ２６で登録された各データは、ユーザーの指示により現在表示されているもの（図１７参照）と随意変更できる。これについては後述する。
【０１７２】
以下、新アイコンデータの登録処理及び新表示フォーム（スキン）データの登録処理についてそれぞれ説明する。
【０１７３】
まず、新アイコンデータの登録処理について説明する。
【０１７４】
即ち、図２１のアイコンテーブルに示すように、制御部４ｅ（図１４参照）は、受信した新アイコンデータをアイコンテーブルにおけるアイコンフィールド２（アイコン追加フィード）に追加する。例えば、図４のメッセージヘッダ部−３の場合、表示変更データ（新デザインデータ）に星マーク形状のアイコンが含まれるので、この星マーク形状のアイコンが、アイコン２フィールドの発信者「チケット検索」のレコードに追加されている。この後、例えば、ユーザーからこの星マーク形状のアイコンを選択すべき旨の指示データが入力された場合は、制御部４ｅは、図１７の三角形のアイコン３８（２）をこの星マーク形状のアイコンに置き換えて表示する。
【０１７５】
次に、新表示フォームデータの登録処理について説明する。
【０１７６】
即ち、表示フォームデータを格納する表示フォームテーブルを示す図２２から分かるように、制御部４ｅ（図１４参照）は受信した新表示フォームデータをこの表示フォームテーブルに追加する。例えば、図４のメッセージヘッダ部−３の場合、表示変更データ（新デザインデータ）に表示フォームデータ２が含まれるので、この表示フォームデータ２が表示フォームフィールドに追加されている。なお、図１７に示す表示フォーム３５は表示フォームデータ１によるものである。この後、例えば、ユーザーから表示フォームデータ２を選択すべき旨の指示データが入力された場合は、制御部４ｅは、図１７の表示フォーム３５をこの表示フォームデータ２に従った形状・色に置き換えて表示する。
【０１７７】
次に、メッセージ本体部取得処理について説明する。
【０１７８】
このメッセージ本体部取得処理は、上述したように、選択したメッセージヘッダ部内のメッセージ本体部入手先データ及びメッセージ本体部ＩＤ（図４参照）を用いてこのメッセージヘッダ部に対応するメッセージ本体部をメッセージ本体部配信サーバ２（図１参照）から取得する処理である。具体的には、図２３に示すように、各要約データをクリック等すると、要約データ３７（１）〜３７（３）に対応するメッセージ本体部（メッセージ本体部−１、−２、−３）がメッセージ本体部配信サーバ２から送られてくる。
【０１７９】
以下、メッセージ本体部取得処理についてさらに詳しく説明する。
【０１８０】
図２４は、メッセージ本体部取得処理を説明するためのフローチャートを示す図である。
【０１８１】
即ち 例えば図２３に示すように要約データ３７（２）をクリック等して選択すると、この要約データ３７（２）を選択した旨を示す選択データがデータ入力部４ｇ（図１４参照）から制御部４ｅに入力される（ステップＳ６１）。この選択データを受信した制御部４ｅは、メッセージ本体部（メッセージ本体部−２）の配信を要求する配信要求データの作成指示データを作成して配信要求データ作成部４ｉに送出する（ステップＳ６２）。作成指示データを受信した配信要求データ作成部４ｉはこの作成指示データに従ってメッセージ本体部（メッセージ本体部−２）の配信要求データを作成する（ステップＳ６３）。具体的には、配信要求データ作成部４ｉは、制御部４ｅからメッセージ本体部入手先データ及びメッセージ本体部ＩＤ（図４参照）を受信し、これらのデータを用いてメッセージ本体部の配信要求データを作成する（ステップＳ６３）。この後、作成された配信要求データをデータ変調部４ｊが変調処理し、変調された配信要求データをデータ送信部４ｋがメッセージ本体部配信サーバ２（図１参照）に送信する（ステップＳ６４）。配信要求データを受信したメッセージ本体部配信サーバ２（図１参照）は配信要求データに従って、対応するメッセージ本体部（メッセージ本体部−２）をメッセージ本体部記憶装置１３から取り出してクライアント装置４のデータ受信部４ｂに送信する（ステップＳ６５）。データ受信部４ｂが受信したメッセージ本体部をデータ復調部４ｃが復調して制御部４ｅに送出し、制御部４ｅは復調されたメッセージ本体部（メッセージ本体部−２）をデータ表示部（ディスプレイ）４ａに送出する（ステップＳ６６）。データ表示部４ａはメッセージ本体部を、例えば図２３に示す表示フォーム４３（２）に表示する（ステップＳ６７）。この後、例えばさらに表示フォーム４３（２）内のボタン４４をクリック等することで、所定のサーバ（図示せず）からストリーミングデータ等が送り込まれ、動画再生等が行われる。ここでは、図２３に示すように、メッセージ本体部−２を取得する例を示したがメッセージ本体部−１、−３の取得も同様にして行われるは当然である。
【０１８２】
ところで、図１１（ｂ）の配信許可テーブルからも分かるように、本情報配信システムを実施するに当たっては、宛先グループ名及びクライアント装置ＩＤを予め配信許可テーブルに登録しておく必要がある（初期登録）。さらに、配信許可データ、配信日データ、配信時刻データも登録しておく必要がある（パーミッション設定）。一方、図１６の受信選択テーブルの受信選択データも設定しておく必要がある（フィルタリング設定）。
【０１８３】
以下、これら初期登録、パーミッション設定及びフィルタリング設定について説明する。
【０１８４】
まず、初期登録について説明する。
【０１８５】
図２５はクライアント装置４の初期登録を説明するためのフロー図である。
【０１８６】
図２５を参照しながら、初期登録処理（ステップＳ３１〜Ｓ３４）について説明する。
【０１８７】
先ず、図２５中の表示フォーム５１はクライアント装置４のディスプレイ４ａ（図１参照）に表示されたものである。表示フォーム５１内のテキストボックス５２、５３はそれぞれユーザーＩＤ及びパスワード（本システムの実施に参加する企業から予め取得したもの）を入力するためのものである。テキストボックス５２、５３内にそれぞれユーザーＩＤ及びパスワードを入力した状態で、「次へボタン」５４をクリックすると（ステップＳ３１）、クライアント装置４はコネクション管理サーバ３に接続を試みる（ステップＳ３２）。クライアント装置４から接続要求を受けたコネクション管理サーバ３はクライアント装置４の認証処理（ユーザー認証処理）を行う（ステップＳ３３）。ユーザー認証処理によりクライアント装置４が認証されるとこのクライアント装置４はコネクション管理サーバ３に登録される（登録完了）（ステップＳ３４）。即ち、コネクション管理サーバ３は、宛先グループデータとクライアント装置ＩＤとを配信許可テーブル（図１１（ｂ）参照）に追加する。このように宛先グループデータとクライアント装置ＩＤを特定できる理由について述べると以下の通りである。つまり、コネクション管理サーバ３は予め上述のユーザーＩＤ及びパスワードに宛先グループ名を関連づけたテーブルを有しているためこのテーブルにより宛先グループ名を決定できる。また、上述したユーザー認証処理（ステップＳ３３）においてクライアントソフトウェアに付与されたクライアント装置ＩＤがコネクション管理サーバ３に送信されるためクライアント装置ＩＤもコネクション管理サーバ３は把握できる。
【０１８８】
次に、パーミッション設定及びフィルタリング設定について説明する。
【０１８９】
図２６は、図１１（ｂ）の配信許可テーブルの配信許可データ、配信日データ、配信時刻データを設定する状態（パーミッション設定）、及び図１６の受信選択テーブルの受信選択データを設定する状態（フィルタリング設定）示す図である。
【０１９０】
まず、フィルタリング設定について説明する。
【０１９１】
図２６に示すように、表示フォーム２１内の基準メッセージ本体部属性データ（外貨預金、定期預金、普通預金、ライブチケット・・・）の左傍にチェックボックス２２（１）〜２２（３）が配置されている。これらチェックボックス２２（１）〜２２（３）に図２６に示すようにチェックマークを入れると、対応する受信選択データ（図１６参照）が「選択」に設定される。一方、チェックボックス２２（１）〜２２（３）をオフにすると対応する受信選択データ（図１６参照）は「非選択」に設定される。但し、この段階ではこれらの設定内容（新受信選択データ）は確定されずに、例えばメモリ４ｍ（図１４参照）に一時的に格納される。
【０１９２】
次に、パーミッション設定（配信許可データ、配信日データ、配信時刻データの設定）について説明する。
【０１９３】
まず、配信許可データ（図１１（ｂ）参照）の設定について説明する。
【０１９４】
図２６に示すように、左側の表示フォーム２１内の各発信者データ（ＡＢＣ銀行、チケット検索、ネット八百屋）の左傍にチェックボックス２３（１）〜２３（３）が配置されている。これらチェックボックス２３（１）〜２３（３）に図２６に示すようにチェックマークを入れると、対応する配信許可データが「Ｙｅｓ」にされる。一方、チェックボックス２３（１）〜２３（３）をオフにすると対応する配信許可データは「Ｎｏ」にされる。但し、この段階ではこれらの設定内容（新配信許可データ）は確定されず、つまり配信許可テーブルに反映されず、例えばクライアント装置４内のメモリ４ｍ（図１４参照）に格納される。なお、図２６中、各発信者データ（ＡＢＣ銀行、チケット検索、ネット八百屋）の図中右側に配置された削除ボタン２５（１）〜２５（３）は、配信許可テーブルの対応するレコードを削除するためのものである。
【０１９５】
次に、配信日データ及び配信時刻データの設定について説明する。
【０１９６】
図２６に示すように、表示フォーム２１内の各発信者データ（ＡＢＣ銀行、チケット検索、ネット八百屋）の右側に配置された詳細ボタン、例えば詳細ボタン２４（１）をクリック等すると、受信曜日及び時間帯を設定する表示フォーム２５がディスプレイ４ａに表示される。表示フォーム２５内の「受信したい曜日」の覧において例えばチェックボックス２８（１）、２８（３）、２８（５）にチェックマークを入れる、メッセージヘッダ部の受信曜日を月、水、金曜日に特定できる。また、例えば、チェックボックス２９にチェックマークを入れるとメッセージヘッダ部を毎日受信させることができる。同様にして、表示フォーム２５内の「受信したい時間帯」のチェックボックス３０、３１（１）〜３１（３）にチェックマークを入れることで、メッセージヘッダ部の受信時間帯を特定できる。例えば、チェックボックス３１（３）にチェックマークを入れると、受信時間帯を例えば１０時〜１８時と設定できる。このようにして受信曜日及び時間帯を設定した後、設定ボタン３２（１）をクリック等すると設定内容（新配信日データ及び配信時刻データ）がメモリ４ｍ（図１４参照）に格納され、表示フォーム２５は閉じられる。なお、キャンセルボタン３２（２）をクリック等すると上での設定が取り消されて表示フォーム２５が閉じられる。
【０１９７】
上述したフィルタリング設定及びパーミッション設定によって新たに設定された受信選択データ、及び配信許可データ、配信日データ、配信時刻データは、図２６に示すように、表示フォーム２１内の設定ボタン３３（１）をクリック等することで最終的に確定される。
【０１９８】
即ち、受信選択データの更新処理のフローチャートを示す図２７に示すように、上述の設定ボタン３３（１）のクリック等により受信選択データの確定指令データが入力部４ｇ（図１４参照）から制御部４ｅに送信される（ステップＳ８１）。確定指令データを受信した制御部４ｅは、受信した確定指令データに従って、上述したメモリ４ｍ内の新受信選択データを用いて受信選択テーブルの受信選択データを更新する（ステップＳ８２）。
【０１９９】
同様に、配信許可テーブルの更新処理のフローチャートを示す図２８に示すように、配信許可テーブル（配信許可データ、配信日データ、配信時刻データ）の確定指令データが入力部４ｇから制御部４ｅ（図１４参照）へ送信される（ステップＳ９１）。確定指令データを受信した制御部４ｅはこの確定指令データを新配信許可データ、新配信日及び新配信時刻データ等と共にコネクション管理サーバ３の制御部３ｃ（図８参照）に送信する（ステップＳ９２）。確定指令データ及び新配信許可データ等を受信した制御部３ｃは、受信した確定指令データ及び新配信許可データ等に基づき、記憶部３ｄ内の配信許可テーブル（配信許可データ、配信日データ、配信時刻データ）（図１１（ｂ）参照）を更新処理する（ステップＳ９３）。なお、図２６の表示フォーム２１内のキャンセルボタン３３（２）をクリックすると上述したフィルタリング設定及びパーミッション設定が全てキャンセルされ元の状態に戻る。
【０２００】
本実施の形態では、上述したように、コネクション管理サーバ３が配信日及び配信時刻データを用いたフィルタリング処理を行っているが（図９のステップＳ１２参照）、これらの時間的基準あるいは他の時間的基準を用いたフィルタリング処理をクライアント装置４側でさらに行ってもよい。これにより、一層きめ細やかなフィルタリングを実現することができ、ユーザーの利便性を向上させることができる。
【０２０１】
次に、図１６の受信選択テーブルにおける受信選択データをクライアント装置４（例えば携帯電話）の位置（ステータス）（例えば大阪、東京等）に応じて自動的に変更する処理について述べる。即ち、前述した受信選択データの設定（図２６及び図２７参照）は、ユーザー等によるデータ入力部からの入力データに基づいて行われたが、ここでは、クライアント装置４の位置に応じて受信選択データを自動的に変更処理する例について説明する。
【０２０２】
図２９は、クライアント装置４の位置に応じて受信選択データを自動的に変更する処理を説明するためのフローチャートを示す図である。
【０２０３】
以下、この処理について具体的に説明する。ここで、クライアント装置４の制御部４ｅ（図１４参照）は、図３０に示すように、クライアント装置４の位置をＧＰＳ等を用いて検出する位置検出部４ｐを備えるものとする。
【０２０４】
まず、制御部４ｅ内の位置検出部４ｐ（図３０参照）がクライアント装置４の位置情報を検出する（ステップＳ１０１）。位置検出部４ｐによって検出された位置情報を用いて制御部４ｅはクライアント装置４の位置が移動したか否かを判断する（ステップＳ１０２）。移動したと判断した場合は（ステップＳ１０２のＹｅｓ）、制御部４ｅは、新たな位置情報に基づいて受信選択データ（図１６参照）を更新する（ステップＳ１０３）。
【０２０５】
具体的には、位置情報と基準発信者情報と基準メッセージ本体部属性データと受信選択データを関連づけたテーブル（図示せず）を予め記憶部４ｆに記憶させておく。上で検出された位置情報をこのテーブルに対応させて該当する基準発信者情報と基準メッセージ本体部属性データと受信選択データを取得する。そして、取得された基準発信者情報と基準メッセージ本体部属性データと受信選択データとを受信選択テーブルに対応させ、対応するレコードにおける受信選択データを変更する。
【０２０６】
一方、移動していないと判断した場合は（ステップＳ１０２のＮｏ）受信選択データを変更処理しない。
【０２０７】
図３１は、クライアント装置４の位置が東京から大阪に移動したと判断された場合に受信選択データを更新した状態を示す図である。このようにクライアント装置４の位置に応じて受信選択データを変更することによって企業はクライアント装置４の位置に応じた好適な情報提供をできる。
【０２０８】
次に、受信選択テーブル（図１６参照）における基準メッセージ本体部属性データ（外貨預金、定期預金、普通預金・・・）の変更処理について述べる。即ち、この基準メッセージ本体部属性データは発信者（企業等）から配信されるテンプレートデータ（図示せず）によって変更できる。より詳しくは以下の通りである。
【０２０９】
図３２は、基準メッセージ本体部属性データフィールドのデータを新たなテンプレートデータを用いて変更処理する例を説明するフローチャートを示す図である。
【０２１０】
以下、この変更処理について説明する。
【０２１１】
即ち、制御部４ｅ（図１４参照）は、企業のサーバ（テンプレートデータ配信サーバ）（図示せず）から新たなテンプレートデータを受信する（ステップＳ７１）。このテンプレートデータには、例えば発信者情報と、変更前の基準メッセージ本体部属性データと、新たな基準メッセージ本体部属性データと、変更属性データ（追加、更新、削除等）が含まれる。このテンプレートデータを受信した制御部４ｅはこのテンプレートデータを用いて受信選択テーブル（図１６参照）を変更処理する。図３３は、発信者「チケット検索」からの新たなテンプレートデータを用いて受信選択テーブルを変更処理した例を示す図である。即ち、「ライブチケット情報」が「来年度の演奏会情報」に上書き（更新）され、さらに「国内アーティスト情報」が追加されている。
【０２１２】
以上から分かるように、本発明の実施の形態によれば以下の効果を得ることができる。
【０２１３】
（１）本発明の実施の形態によれば、企業と消費者との間にプラットフーマを介在させて消費者へのメッセージヘッダ部の配信を管理させるようにしたので、消費者は、自らは配信許可を与えた企業のみから且つ受け取り希望時にのみメッセージヘッダ部を受け取ることができる。
【０２１４】
また、本発明の実施の形態によれば、メッセージヘッダ部内の要約データを消費者が選択することによってメッセージ本体部を取得するようにしたので、必要と判断したメッセージ本体部のみを入手することができる。
【０２１５】
また、本発明の実施の形態によれば、種々の企業のＵＲＬ等を単に列挙した情報が電子メール等によって事業者から送られてくる従来の場合に比べて次のような有利な点を有する。
【０２１６】
即ち、本発明の実施の形態によれば、消費者は各企業ごとに配信許可を与えるか否かを随時任意に変更でき、また、配信許可を与えた企業からの情報でも不要な属性のデータの受信を拒否できるようにしたので、配信許可を与えた企業からの情報でも、不要な種類の情報の受信を随時止めて、真に必要な情報のみを受け取ることができる。また、複数の企業から情報を取得する場合でもプラットフォーマが配信許可情報等を一元的に管理するようにしたので、消費者は各企業ごとの配信許可設定を簡易に行うことができる。その他、クライアント装置のディスプレイ上に表示されるアイコンの色や点灯状態等をメッセージヘッダ部の着信に応じて自由に変更できるようにしたので、多様な表現をすることができるという特徴もある。
【０２１７】
（２）上の（１）に述べた特徴を企業側から見た観点から述べれば以下の通りである。即ち、本発明の実施の形態によれば、上述したようにメッセージ本体部の取得を消費者の意思に任せるようにしたので、企業は、データ量の少ないメッセージヘッダ部のみとりあえず消費者に送信し、消費者からメッセージ本体部の配信要求があった場合にのみ配信データ量の多いコンテンツ本体としてのメッセージ本体部を配信すればよい。これにより、企業は、ユーザーへの不要且つ大量の情報発信を低減でき、真に情報を必要とする消費者にのみ企業による情報を認識させることができる。つまり、企業は、真に企業による情報を欲するユーザーのみとのコミュニケーションをとることができる。
【０２１８】
（３）一般的な情報配信サービスではサービス実施者は顧客の個人情報や、顧客の欲する情報の属性データを予め取得し把握する。しかし、本発明の実施の形態によれば、サービス提供者（プラットフォーマ）が、宛先グループ名とクライアント装置ＩＤとの対応関係の情報、及び消費者が情報の発信者に対して配信許可を与えているか否かの情報のみを把握するようにした。これにより、企業は、消費者の個人情報を取得する必要はなく、個人情報の漏洩の心配をすることなく情報の配信を行うことができる。また、複数の企業間同士で、宛先グループ名のみを交換して用いることで、顧客の個人情報の交換を行うことなく、顧客ベースを広げることが容易になる。
【０２１９】
（４）本発明の実施の形態によれば、随意に変更できる即時性の高いフィルタリング（属性データ等のフィルタリング情報をマイポータル等の企業側に設定するのではなく、クライアント装置側に設定するので変更が極めて容易・迅速であり、心理的負担が小さい）により消費者が自ら取得する情報の種類を選択するようにしたので、必ずしも確度の高いとはいえないデータマイニングを行うことなく、消費者が必要とする情報のみを的確に消費者に届けることができる。
【０２２０】
また、本発明の実施の形態によれば、企業側やサービスサイド（プラットフォーマ）に個人の基本情報や嗜好情報を大量に蓄積する必要をなくしたので、システム構築及び運用コスト、個人情報保護の負担を大幅に下げることができる。
【０２２１】
（５）本発明の実施の形態によれば、消費者は、自らの手元にあるクライアント装置にフィルタリング情報を設定して必要な情報を適宜選択するようにしたので、個人情報を企業やサービス事業者に開示することなく必要な情報を取得することができる。この際、フィルタリングの結果消費者が入手した情報は“自ら選び取った”情報であるから、その入手した情報の確度は高いのは当然であり、その確度の高さに不安感を覚えることもない。
【０２２２】
（６）本発明の実施の形態によれば、企業は「フィルタリング設定用のテンプレート」をクライアント装置に送ってその利用を消費者に促すと共に、顧客との関係に応じたフィルタリング設定用のテンプレートを供給してその情報の選択肢（属性データ）を企業側から示すようにしたので、最終的な情報の選択は消費者にまかせつつも、企業からも能動的な関係を築くことが可能となる。また、テンプレートとして入学・引越し等のイベントに対応したものを企業やサービスサイドが消費者に提供することにより、効果的な宣伝を企業等は行うことができる。
【０２２３】
【発明の効果】
本発明により、ネットワークを介した事業者から需要者への情報提供において、事業者が発する多種多量の情報から需用者は必要な情報のみを受け取ることができる。
【図面の簡単な説明】
【図１】本発明の実施の形態としての情報配信システムの構成を示すブロック図である。
【図２】メッセージヘッダ部とメッセージ本体部の基本関係を示す図である。
【図３】メッセージヘッダ部のデータ構造を示す図である。
【図４】メッセージヘッダ部のデータ構造の具体例を示す図である。
【図５】メッセージヘッダ部配信サーバ１の構成を示すブロック図である。
【図６】このメッセージヘッダ部配信サーバ１の動作を説明するフローチャートを示す図である。
【図７】このメッセージヘッダ部及びメッセージ本体部を作成ツールを示す図である。
【図８】コネクション管理サーバ３の構成を示すブロック図である。
【図９】コネクション管理サーバ３の動作（第１の配信処理）を説明するためのフローチャートを示す図である。
【図１０】コネクション管理サーバ３の動作（第２の配信処理）を説明するためのフローチャートを示す図である。
【図１１】図１１（ａ）は、クライアント装置ＩＤとクライアント装置の接続状態をフィールドとして有するテーブル（接続状態テーブル）を示す図である。
図１１（ｂ）は、発信者、宛先グループ、クライアント装置ＩＤ、配信許可、配信日、配信時間をフィールドとして有するテーブル（配信許可テーブル）を示す図である。
【図１２】クライアント装置ＩＤ、メッセージヘッダ部ＩＤをフィールドとして有するテーブル（未配信クライアント装置ＩＤテーブル）を示す図である。
【図１３】メッセージヘッダ部ＩＤ、メッセージヘッダ部有効期限、メッセージヘッダ部をフィールドとして有するテーブル（未配信メッセージヘッダ部テーブル）を示す図である。
【図１４】クライアント装置４の構成を示すブロック図である。
【図１５】クライアント装置４の動作を説明するためのフローチャートを示す図である。
【図１６】発信者データ、メッセージ本体部属性データ、受信選択データをそれぞれフィールドデータとして有するテーブル（受信選択テーブル）を示す図である。
【図１７】受信したメッセージヘッダ部の一部（例えば要約データ等）をクライアント装置４のディスプレイ４ａ上における表示フォーム内に表示させた状態を示す図である。
【図１８】要約データを表示部に表示する処理を説明するためのフローチャートを示す図である。
【図１９】アイコン状態変更処理を説明するためのフローチャートを示す図である。
【図２０】音状態変更処理を説明するためのフローチャートを示す図である。
【図２１】アイコンテーブルを示す図である。
【図２２】表示フォームテーブルを示す図である。
【図２３】メッセージ本体部をクライアント装置４のディスプレイ４ａに表示させた状態を示す図である。
【図２４】メッセージ本体部の取得処理を説明するためのフローチャートを示す図である。
【図２５】クライアント装置４をコネクション管理サーバ３に初期登録する処理を説明するためのフロー図である。
【図２６】図１６の受信選択テーブル及び図１１（ｂ）の配信許可テーブルをクライアント装置４にて設定する状態を示す図である。
【図２７】受信選択データの更新処理を説明するためのフローチャートを示す図である。
【図２８】配信許可テーブルの更新処理を説明するためのフローチャートを示す図である。
【図２９】クライアント装置４の位置情報に基づいて受信選択データを更新する処理を説明するためのフローチャートを示す図である。
【図３０】位置検出部の構成を示すブロック図である。
【図３１】クライアント装置４の位置情報に応じて受信選択データが自動的に変更処理された例を示す図である。
【図３２】新たなテンプレートデータに対応したものに受信選択テーブルにおける基準メッセージ本体部属性データを更新する処理を説明するためのフローチャートを示す図である。
【図３３】新たなテンプレートデータを用いて受信選択テーブルを変更処理した例を示す図である。
【符号の説明】
１ メッセージヘッダ部配信サーバ（データ送信装置）
１ａ、３ｃ、４ｅ、１１ａ 制御部
１ｂ データ組立部
１ｃ、３ｅ、４ｊ データ変調部
１ｄ、３ｆ、４ｋ データ送信部
１ｅ メモリ
１ｆ、３ｄ、４ｆ 記憶部
２ メッセージ本体部配信サーバ
３ コネクション管理サーバ（データ管理装置）
３ａ、４ｂ データ受信部
３ｂ、４ｃ データ復調部
４ クライアント装置（データ受信装置）
４ａ 表示部（ディスプレイ）
４ｄ データ分解部
４ｉ 配信要求データ作成部
５ メッセージヘッダ部記憶装置（メッセージヘッダ部記憶部）
６、４ａ データ表示部（ディスプレイ）
８、４ｇ データ入力部（キーボード）
９ インターネット
１０ コネクション管理記憶装置（コネクション管理記憶部）
１１ キャッシュサーバ
１２ キャッシュ記憶装置（キャッシュ記憶部）
１３ メッセージ本体部記憶装置（メッセージ本体部記憶部）
２１、３５、４３（１）〜４３（３）、５１ 表示フォーム
３７（１）〜３７（３） 要約データ
３８（１）〜３８（３） アイコン

Claims (27)

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. 少なくとも、前記クライアント装置ＩＤ、前記クライアント装置ＩＤ、前記メッセージ本体部ＩＤ、前記メッセージ本体部属性データ、前記メッセージ本体部入手先情報、前記発信者情報を関連づけて格納する未配信メッセージヘッダ部データベースを記憶するキャッシュ記憶部をさらに備え、
    前記制御部は、前記配信条件データが配信不能状態を示すものとして前記第２のメッセージヘッダ部を配信しないと判断したときは、前記未配信メッセージヘッダ部データベースにデータを作成し、且つ、前記コネクションデータベース内の前記配信条件データが配信可能状態に変更されたと判断したときは、変更された前記配信条件データに対応する前記クライアント装置ＩＤを前記未配信メッセージヘッダ部データベースに対応させて対応データを抽出して、前記第２のメッセージヘッダ部を送信することを特徴とする請求項２４に記載のデータ管理装置。
26. 前記制御部は、前記クライアント装置から前記配信条件データの変更を要求する配信条件変更要求データを受信し、且つ、前記配信条件変更要求データに基づいて前記コネクション管理記憶部に格納された前記配信条件データを変更することを特徴とする請求項２３乃至２５のいずれかに記載のデータ管理装置。
27. データ送信装置からデータ受信装置へデータを送信する情報配信方法であって、
    メッセージ本体部の発信者を示す発信者情報と、前記メッセージ本体部の宛先グループを示す宛先グループ情報と、前記メッセージ本体部の配信開始日時を示すメッセージヘッダ部情報発信日時データ、前記メッセージ本体部の有効期限を示すメッセージ本体部有効期限データと、前記メッセージ本体部の属性を示すメッセージ本体部属性データと、前記メッセージ本体部の要約を示す要約データと、前記メッセージ本体部の入手先を示すメッセージ本体部入手先情報と、前記メッセージ本体部を識別するメッセージ本体部ＩＤと、前記データ受信装置における表示画像状態や発音状態等の表示状態を変化させる表示変更データとからなるメッセージヘッダ部であって、前記メッセージヘッダ部を識別するメッセージヘッダ部ＩＤをさらに含むメッセージヘッダ部を送信することを特徴とする情報配信方法。

Images