JP4479334B2 - プレゼンスサービスを基盤としたプッシュ型情報配信方法、プッシュ型情報配信システム、情報提供装置及びチャネル検索装置 - Google Patents

Description

本発明は、プレゼンスサービスを利用可能な端末装置を用いた、プッシュ型情報配信方法、システム及びその装置に関する。

近年、携帯電話に代表される無線情報端末の普及と、無線技術やＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）などによる位置情報取得技術の発展に伴い、位置情報と連動した情報配信サービスの提供が開始されている。ユーザは位置情報をキャリアまたはキャリアと提携したサービスプロバイダに通知することで、位置情報に応じた情報やコンテンツの配信サービスを利用できる。位置情報に応じた情報やコンテンツとは、例えば、現在位置付近の地図、周辺の天気予報や交通情報などである。

ユーザが情報の配信サービスを受ける方法としては、プル型とプッシュ型とがある。プル型とは、ユーザが情報配信の要求をサービスプロバイダに通知し、サービスプロバイダ側は、ユーザの要求に応じて情報提供を開始する形式の情報提供方法である。一方、プッシュ型とは、ユーザの要求によってではなく、サービスプロバイダ側が、何らかのユーザの状態の変化を契機として勝手に情報を配信する形式の情報提供方法である。プッシュ型の情報配信方法として特に普及している方法が、ユーザの位置情報に基づいて、特定のコンテンツを配信する方法である。例えば、ユーザが自分の興味にあったチャネル（天気予報チャネル、地域ニュースチャネルなど）に対して予め購読の申請を行うと、その後は、ユーザの操作による位置情報の提供を待つことなく、位置情報がキャリアまたはキャリアと提携したコンテンツプロバイダに通知され、そのチャネルのコンテンツの中でユーザの位置情報に適合する情報が選択され、配信される。

また、ユーザが一方的に情報の配信を受けるばかりでなく、ユーザが自分から情報を発信することができるユーザ参加型の位置情報サービスも存在する。例えば、ユーザが、発信したいメッセージを自分の位置情報と併せて専用のサーバに登録し、更に、登録されたメッセージは、現在位置が特定の条件を満たした別のユーザに対して送信される、という仕組みのサービスがある。

現在、上述の「位置情報」は、ユーザの他の属性情報（例えば、氏名、年齢、性別等）と併せて「プレゼンス情報」という用語で表現されることが多い。現在、プレゼンス情報を用いた種々のサービスが考案されており、またプレゼンス情報を用いたサービスが将来的に普及していくものと考えられているが、現時点で、最も普及しているサービスがインスタントメッセンジャーである。インスタントメッセンジャーを利用するためには、ユーザは、専用のソフトウェアを端末にインストールし、当該ソフトウェアを起動して、ネットワークに接続する。すると通信相手が現在、ネットワークに接続しているかどうかが確認できるので、もし通信相手が同じソフトウェアを起動していれば、リアルタイムでメッセージを交換できる。

従って、インスタントメッセージャーを利用するためには、ユーザは「自分がネットワークに接続しているか」という自分のプレゼンス情報を提供し、更に通信相手のプレゼンス情報も取得する必要がある。このため、ユーザは、サービスプロバイダによって提供されるプレゼンスサービス上で、アカウントを持つことが必要である。このようなアカウントは、プレゼンティティと呼ばれ、本明細書でも、以下では、プレゼンティティという呼称を用いることとする。ユーザは、通信相手のプレゼンティティを登録して管理するためのリスト（以下、バディリスト）を持ち、このバディリストに含まれているプレゼンティティとの間でプレゼンス情報のやり取りを行う。

バディリストにプレゼンティティを登録するためには相手のプレゼンティティの識別子（以下、プレゼンティティ識別子）を何らかの方法で知り、これを用いてプレゼンティティにプレゼンス情報のプッシュ型通知を申請する。以下では、これを「サブスクライブする」と言う。ユーザがある相手にサブスクライブすると、プレゼンスサーバ経由かまたはユーザから直接それが相手に通知され、相手側ではユーザ毎にプレゼンス情報を公開するかどうかを判断できる。また、この仕組みを利用して、プレゼンスサービスを利用するインスタントメッセンジャーの大半は、バディリストに登録されたプレゼンティティ以外からのメッセージを遮断することでスパムを防止する機能を持っている。

最近の調査結果では、ＰＣのアプリケーションとしてはインスタントメッセンジャーがＷｅｂブラウザの利用率を超えたとする報告もあり、今後はこのようなソフトが携帯電話のアプリケーションとしても普及すると思われる。また、それを見据えて、ＩＥＴＦ（Internet Engineering Task Force）などの標準化団体では、ユーザの位置情報をプレゼンス情報の一部として扱うための方式の検討が進められている。

以下では、位置情報サービスとして、特に位置情報を利用したプッシュ型情報配信サービスにおける課題を提示する。
現状では、位置情報サービスを提供したい企業は、ユーザの位置情報の提供を受けるために携帯キャリアと密接に連携する必要がある。そのための手続きや、サーバや回線の確保などにそれなりのコストがかかるため、位置情報サービスを利用してコンテンツを配信する企業はキャリアまたは専門のコンテンツプロバイダに限られ、その内容も広告または簡単に有益性が認められて課金可能なものに偏っている。このコストを何らかの手段によって軽減し、一般ユーザやコンテンツプロバイダ以外の企業も気軽に位置情報サービスを利用してコンテンツを配信できるようになれば、上記のような偏りは減少してコンテンツが多様化する。また、このようなサービスにはユーザ同士の新たなコミュニケーション発掘の手段としての効果も見込まれる。

しかし、従来のユーザ参加型の位置情報サービスのように、１つまたは少数の空間に対して誰もがメッセージを登録できるようにするという方法では、サービスの普及に伴って、メールに見られるようなスパムの問題が拡大する可能性が高い。これは特にプッシュ型の情報配信サービスにとっては深刻である。そのため、ユーザ参加型の位置情報サービスでも、企業による情報配信サービスにおけるチャネルのように、送信元によってユーザが受信するメッセージをフィルタリングする何らかの手段が必要となる。

また、逆に、メッセージを登録するユーザが、不特定多数に見られる可能性のあるメッセージに自分の情報（ユーザの識別子など）を含めることは、プライバシー上問題になる可能性がある。しかし、登録したユーザの情報をメッセージに全く含めないとすると、そのメッセージを受信したユーザからのリアクションを受け取る手段を完全に失うため、健全なコミュニケーションまで阻害することになってしまう。そのため、ユーザ参加型の位置情報サービスには、ユーザのプライバシーとコミュニケーションの間でバランスの取れた匿名化の手段が必要となる。

以上の課題を解決する手段として、既に一般ユーザの間で普及しつつあるプレゼンスサービスを基盤とすることが考えられる。プレゼンス情報を利用するサービスとして最も普及しているインスタントメッセージングにおいては、プレゼンティティを介して、アドレス情報など、通信相手の個人情報が相互に伝達されるようになっており、個人情報の漏洩防止の観点からは問題がある。また、プレゼンスサービスに基づいてプッシュ型情報配信サービスを実現するために、プレゼンスサーバやそのクライアントに独自の修正を強いることは、情報配信サービスを普及させるための障害となるため望ましくない。特に、プレゼンスサーバへの独自の修正を加えることはプレゼンスサービスの将来の拡張性を低下させるため、プレゼンス情報の取得はあくまで通常のプレゼンスサービスの手順に則って行われるべきである。
本発明は上記事情に鑑みてなされたものであり、従来のプレゼンスサーバの構成を変化させることなく、かつ個人情報の漏洩の程度を低減することが可能な、プレゼンスサービスに基づくプッシュ型情報配信方法、システム及びその装置を提供することを目的とする。

本発明では、プレゼンスサービス上に、情報配信を行なうためのチャネルを表すプレゼンティティを形成し、更に、情報配信サーバ上に、それらのプレゼンティティに対応した仮想的なチャネル通信端末を論理的に形成する。チャネル検索サーバは、チャネルを表すプレゼンティティをユーザが検索することを助ける。
更に、コンテンツ配信の際、コンテンツの送信元・送信先の各々に対して、直接アドレス情報を伝送せず、あたかもチャネルからコンテンツが配信されているように見せかける。これにより、前記の目的を達成する。

コンテンツの送受信に際して、ユーザ間で、アドレス情報を交換し合う必要がなくなり、コンテンツ送受信に伴う個人情報の漏洩が防止できる。

以下、実施例を図面に基づいて説明する。
図１には、実施例１で想定している物理的な通信ネットワークの構成を模式的に示す。複数のユーザ通信端末2-1〜2-nが通信網１を介して相互に接続されている。本実施例では、端末数がｎ個（ｎは自然数）ある場合を想定している。ｋは、１〜ｎの間の自然数であり複数の端末のうちの任意の端末を示すために便宜的に記している。ユーザ通信端末としては、携帯電話やＰＤＡのような移動端末の他、通信機能を備えたＰＣなど、固定端末であっても良い。３はプレゼンスサーバであり、ユーザ通信端末の2-1〜2-nの属性情報を管理する。４は情報配信サーバであり、ユーザ通信端末2-1〜2-nの要求する情報（コンテンツ）を配信するためのサーバである。上記端末2-1〜2-n、プレゼンスサーバ３および情報配信サーバ４は、互いに物理的な通信回線６を介して接続されている。

ユーザは、プレゼンス情報を利用したサービスを受けるため、サービスプロバイダによって提供されるプレゼンスサービス上で、アカウントつまりプレゼンティティを持つ。プレゼンティティに関する情報は、プレゼンスサーバ３上に格納され、かつ管理される。ここで、サービスプロバイダとは、プレゼンス情報を利用したサービスを提供するサービス提供事業者のことであり、図１でいうと、情報配信サーバ３を所有している事業者を意味する。サービスプロバイダは、情報配信サーバ４だけを所有している場合もあれば、プレゼンスサーバ３と情報配信サーバ４の両方を所有している場合もある。

図２は、本実施例のプレゼンティティの概念を説明するための概念図である。ユーザ通信端末２は、各クライアントに対応したプレゼンティティを通してプレゼンスサービス１０に接続する。情報配信サーバ４とユーザ通信端末２間、或いはユーザ通信端末2-1〜2-n間で送受信される情報は、論理的には、全てプレゼンティティを介して送受信される。図２中の矢印は、プレゼンスサービス１０上で公開されたプレゼンティティを通してコンテンツの送受信が行われる様子を示している。ここで、プレゼンスサービス１０とは、プレゼンスサーバ３によって管理されているネットワーク上での広がり（以下、ドメインと称する）を意味し、プレゼンス情報を利用するサービスが提供されるプラットフォームをなしている。図１では、プレゼンスサーバ３は１台しか示していないので、図２で示したプレゼンスサービス１０は、プレゼンスサーバ３のみが管理するドメインに相当するが、複数のプレゼンスサーバが備えられたネットワークにおいては、プレゼンスサービスの大きさは、複数のプレゼンスサーバによって管理される領域の広がりに相当する。

プレゼンス情報利用サービス（以下プレゼンスサービス）を受けようとするユーザがサービスプロバイダと契約すると、ユーザの使用する端末には、プレゼンスサービスを利用するためのクライアントソフトウェアがインストールされる。ソフトウェアのインストールは、ネットワーク経由でダウンロードしても良いし、ＣＤ−ＲＯＭのような可搬媒体から行なってもよい。ユーザ通信端末に最初からクライアントソフトが備わっている場合はそれを利用する。これにより、ユーザの端末上で、プレゼンスサービスを利用するクライアント（以下、プレゼンス対応型クライアント）が動作するようになる。サービスプロバイダは、各クライアントに対応したアカウント情報をプレゼンスサーバ３上に格納し、プレゼンスサービスを提供するためのアカウントを開設する。これにより、各クライアントに対応するプレゼンティティが、プレゼンスサービス１０上に論理的に形成される。ここで、アカウント情報とは、アカウントを開設するのに必要な情報のことであり、例えば、ユーザやチャネルのプレゼンティティ識別子などの情報である。なお、以下の説明では、プレゼンティティ識別子としてメールアドレスと同じ形式の文字列を使用するものとする。

図２は、プレゼンスサービス１０上に、ユーザ通信端末側のプレゼンティティ12-1〜12-nと、情報配信サーバ側のプレゼンティティ14-1〜14-mが形成された様子を示している。図２においては、プレゼンスサービスを受けるユーザ通信端末の個数はｎ個であり、ｎ個のユーザ通信端末上で動作しているクライアントもｎ個存在している。従って、プレゼンスサービス１０上に形成されるプレゼンティティの個数もｎ個存在している。図２の例では、各クライアント毎に１つのプレゼンティティを公開しているが、１つのクライアントが複数のプレゼンティティを公開してもよい。逆に、複数のクライアントを１つのプレゼンティティとして公開してもよい。

情報配信サーバ４はコンテンツを配信する仮想的なエンティティであるチャネルを複数管理し、各チャネル毎に１つのプレゼンティティ１４をプレゼンスサービス１０上に公開する。情報配信サーバ４側のプレゼンティティが形成されると、図示されてはいないが、情報配信サーバ内に、チャネル数に対応したチャネル通信端末が仮想的に形成される。チャネル通信端末については後段で詳述する。
プレゼンスサービス１０上では、情報配信サーバ４とユーザ通信端末２ないしユーザ通信端末2-1〜2-n間の情報の送受信は、全てプレゼンティティを介して行なわれる。図２において、プレゼンティティ12-1と14-1間を結ぶ矢印は、プレゼンス情報がプレゼンティティを通して双方向に流れている様子も示している。

以上、プレゼンティティ１２、プレゼンティティ１４、プレゼンティティ１５は、それぞれの使用される目的が異なるものの、プレゼンスサービス上ではその違いは認識されず、全て通常のユーザのプレゼンティティとして扱われる。しかし、プレゼンティティの種類を示すプレゼンス情報を新しく追加し、そのプレゼンティティが示すものがユーザか、チャネル（情報配信サーバ）か、またはチャネル検索サーバかを明示的に表せるようにしてもよい。ユーザ通信端末２またはプレゼンスサーバ３は、バディリストを備える。ここで、バディリストとは、通信相手のプレゼンティティを登録して管理するためのリストのことである。

図３には、図２に示したプレゼンティティ間で流れる情報が、現実の物理ネットワーク上でどう流れるかを示すための模式図を示した。ユーザ通信端末2-1〜2-n、プレゼンスサーバ３および情報配信サーバ４は、所定の帯域を有する通信回線６を介して、通信網１に接続される。プレゼンスサーバ３の内部には、複数のユーザ通信端末側プレゼンティティ１２（12-1〜12-n）が形成され、ユーザ通信端末２とプレゼンスサーバ間でのプレゼンス情報の送受信を行なう。同様に、複数の情報配信サーバ側プレゼンティティ１４（14-1〜14-m）も形成され、更に、情報配信サーバ内には、チャネル通信端末４０（40-1〜40-m）が形成される。情報配信サーバとプレゼンスサーバ間でプレゼンス情報を送受信する必要がある場合、当該情報は、情報配信サーバ側プレゼンティティ１４（14-1〜14-m）とチャネル通信端末４０（40-1〜40-m）との間で送受信される。

図３において、細い実線はプレゼンス情報の流れを示す。一方、太い実線はコンテンツ配信の流れを意味する。これは、本実施例においては、プレゼンスサーバは、実コンテンツを格納していないので、実際のコンテンツの配信は、ユーザ通信端末のプレゼンス情報の変化またはユーザ通信端末からのコンテンツ配信要求を元に、情報配信サーバ４により実行されるためである。

図４には、図３に示した情報配信サーバ４内部の論理構成図を示した。分り易さのため、図では、各チャネル通信端末40-1〜40-mと情報配信サーバ側プレゼンティティ14-1〜14-mとの対応関係も併せて示した。情報配信サーバ４には、プレゼンティティ１４に応じたチャネル通信端末４０が仮想的に形成される。わかりやすく言えば、チャネル通信端末４０とは、各チャネルないし情報配信サーバ側プレゼンティティに応じて論理的に形成されたミニ配信サーバである。点線はチャネル通信端末とプレゼンティティの対応関係を示している。各チャネル通信端末40-1〜40-mは、ユーザ通信端末２と同様にプレゼンス対応型クライアント４８とバディリスト４５７を備え、それに加えて、ユーザに配信するコンテンツを蓄積するコンテンツデータベース４５８、ユーザのプレゼンス情報に基づいてコンテンツの送信を判断するコンテンツ送信制御部４３４、及びコンテンツをコンテンツデータベース４５８に登録するコンテンツ登録部４３５を備える。

図５には、情報配信サーバ４の内部構成を機能展開して示したブロック図を示す。図中の実線部分はハードウェアの物理的な結線を表し、矢印付きの点線は論理的な情報の流れを表している。情報配信サーバ４の各ブロックの動作はメモリ４３に収納されており、動作時にはＣＰＵ４２がその動作手順を読み出して実行する。情報配信サーバ４の管理する情報はハードディスク等のストレージシステムで実現されるＤＢ装置４５に格納されており、ここから必要な情報を取り出し、書き込む。

メモリ４３は、プレゼンスプロトコル送受信部４３１、コンテンツ送受信部４３２、プレゼンス情報管理部４３３、コンテンツ送信制御部４３４及びコンテンツ登録部４３５の各機能ブロックを格納する。ＤＢ装置４５は、各チャネルに関連するユーザの情報（以下、ユーザ情報）を格納するユーザ情報テーブル４５１と、各チャネルの情報（以下、チャネル情報）を格納するチャネル情報テーブル４５２と、不特定多数のユーザに対して配信したいコンテンツ（以下、配信コンテンツ）を格納する配信コンテンツテーブル４５３と、特定のユーザから特定のユーザに対して１度だけ送信したいコンテンツ（以下、転送コンテンツ）を格納する転送コンテンツテーブル４５４を備える。

図６はチャネル情報テーブル４５２の一例を示す図である。図６に示した情報テーブルは、チャネルNo.フィールド、（チャネルの）プレゼンティティ識別子フィールド、チャネル名フィールド、紹介文フィールドなどにより構成される。各チャネルには、対応するプレゼンティティを示すための識別子であるプレゼンティティ識別子が付与される。チャネルNo.はチャネル毎に一意に割り当てられるＩＤであり、情報配信サーバの設計に応じて、任意に使用可能なＩＤである。本実施例では、チャネルNo.はチャネルのプレゼンティティ識別子の代わりとして、ユーザ情報テーブル、配信コンテンツテーブル、転送コンテンツテーブルの内容をチャネル毎に区別するために用いられる。

チャネル名フィールドには、対応するチャネルの名前が格納される。また、紹介文フィールドには、対応するチャネルがどのような情報を扱うチャネルかを紹介する内容が格納される。原理的には、チャネル識別子フィールドさえあればチャネルの区別はできるので、チャネル名フィールドは不要である。しかしながら、チャネルに与えられるチャネル識別子は、cake@example.co.jpなど、人間にとって理解しにくいので、ユーザの利便性を考慮した場合、チャネル名フィールドが必要となる。また、チャネル名フィールドや紹介文フィールドに含まれる情報（テキストデータでも画像データでも種類は問わない）は、プレゼンスサービスを利用するユーザが、チャネルを検索する際に用いられる。

図７には、ユーザ情報テーブル４５１の一例を示す。本実施例の情報テーブル４５１は、チャネルNo.フィールド、（チャネルの）プレゼンティティ識別子フィールド、ニックネームフィールド、権限フィールド、状態フィールド、配信コンテンツNo.フィールド、配信時刻フィールドなどにより構成されている。チャネルNo.フィールド、プレゼンティティ識別子フィールドに格納される情報は、図６で説明したので省略する。ニックネームフィールドには、プレゼンスサービスを利用するユーザが、プレゼンスサービス１０上で使用するニックネーム（ハンドルネームの類）が格納される。権限フィールドには、プレゼンティティ識別子によって識別されるユーザが、対応するチャネルの管理者かそうでないかを示す識別子が格納される。状態フィールドには、例えば、現在ネットワークに接続しているか否か、離席中か在席中かといった、当該ユーザの現在の状態を示す識別子が格納される。図７では、状態フィールドには、ユーザが在席中か否かを示す識別子が格納された例を示している。

（チャネルの）プレゼンティティ識別子フィールド、ニックネームフィールド、状態フィールドの各フィールドに格納されるデータは、ユーザのプレゼンティティから通知されたプレゼンス情報の一部または全てをキャッシュすることにより、登録または更新される。配信コンテンツNo.フィールド、配信時刻フィールドには、それぞれ配信済みのコンテンツ番号、ないし前回コンテンツを送信した時刻情報が格納される。配信コンテンツNo.フィールド、コンテンツNo.フィールドに格納される情報は、ＣＰＵ４２によって更新される。同様に、配信時刻フィールドに格納される情報は、ＣＰＵ４２の内部クロック情報や、図示されていないタイマなどの情報を基にＣＰＵ４２が記録、更新する。配信コンテンツNo.フィールド、コンテンツNo.フィールドの各フィールドは、原理的には不要であるが、コンテンツの配信条件をより精細に制御するために必要となる。

例えば、ユーザのプレゼンス情報が特定の時刻にマッチした場合にコンテンツを配信、あるいは一度配信したコンテンツは二度と配信しない、といった配信条件である。従って、コンテンツの配信条件を決めるために必要であれば、コンテンツNo.フィールドや配信時刻フィールド以外の種類のフィールドが、ユーザ情報テーブル４５１に設けられることもある。また、ユーザ情報テーブル４５１は、このテーブルはチャネルNo.の値に応じて複数のサブテーブルに区別できる。サブテーブルに分割することにより、ユーザが各チャネルに対して
公開するプレゼンス情報を変化させることができるという利点がある（図中のボブの状態を参照）。

図８は、配信コンテンツテーブルの一例を示す。図８に示したテーブルは、大別すると、配信コンテンツNo.フィールド、チャネルNo.フィールド、ユーザのプレゼンス情報に対する配信条件に関するフィールド、配信条件が満たされたときに送信されるコンテンツが格納されるフィールドと、コンテンツの配信に関する制限（配信回数、有効期間など）に関する情報が格納されるフィールドにより構成される。配信コンテンツNo.フィールドには、配信コンテンツに対する一意なIDが格納される。配信条件フィールドには、当該コンテンツを対応するチャネルに対して配信する際の配信条件が格納される。コンテンツ種別フィールドには、格納されたコンテンツの種類を示す種類識別子が格納される。図８の例では、格納されるコンテンツの種類はテキストだけであるが、画像データや音声データを格納しても構わない。

なお、コンテンツ種別フィールドには、コンテンツが画像データの場合は画像フォーマットを示す識別子などが格納され、コンテンツが音声データの場合はオーディオコーデックを示す識別子などが格納される。コンテンツ種別フィールドに格納されたデータは、コンテンツを配信する際に、コンテンツを配送するためのパケットに含められユーザに送信され、これによって、ユーザ通信端末上で動作するクライアントが、送信されたコンテンツを表示するために必要なアプリケーションソフトウェアを選択することが可能となる。コンテンツフィールドには、配信されるコンテンツデータ自身が格納される。配信回数フィールドには、該コンテンツの各ユーザへの配信回数情報が格納される。例えば、配信コンテンツNo.１に相当するコンテンツのチャネル１に対する配信回数は１回だけであるが、配信コンテンツNo.１４５に相当するコンテンツのチャネル２に対する配信回数は無制限である。

有効期間フィールドには、コンテンツ配信の有効期間情報が格納される。なお、配信条件フィールドや配信回数フィールド、あるいは有効期間フィールドに格納されるデータは、ユーザによって設定される。原理的には、配信回数フィールドや有効期間フィールドは無くとも良いが、コンテンツの配信条件をより精細に制御するために必要となる。従って、コンテンツの配信条件を決めるために必要であれば、配信回数フィールドや有効期間フィールド以外の種類のフィールドがコンテンツ配信テーブル４５３に設けられることは、図７と同様である。また、図８のテーブルを、チャネルNo.の値によって複数のサブテーブルに分割することにより、配信コンテンツテーブルをＣＰＵ４２が検索する際の検索速度が向上するという利点がある。

図９には、転送コンテンツテーブルの一例を示す。本実施例の転送コンテンツテーブルは、チャネルNo.フィールド、送信元ユーザのプレゼンティティ識別子が格納される送信元プレゼンティティフィールド、送信先ユーザのプレゼンティティ識別子が格納される送信先プレゼンティティフィールド、転送されるコンテンツの種類を示す種別識別子が格納されるコンテンツ種別フィールド、実際に転送されるコンテンツの実データが格納される転送コンテンツフィールドからなる。転送コンテンツフィールドには、相手ユーザが不在のために即座に転送できなかった転送コンテンツが格納される。また、図９では省略されているが、転送コンテンツテーブルのカラムにも、ユーザのプレゼンス情報に対する配信条件が含まれてよい。その場合、相手ユーザのプレゼンス情報が転送コンテンツの配信条件を満たす場合は即座に転送され、配信条件を満たさなかった場合は転送コンテンツテーブルに格納される。

（コンテンツ配信時の基本動作）
以下では、図１０に示したシーケンス図及び図４〜図９を用いて、コンテンツ配信を行なう際の情報配信サーバ４の動作について説明する。また、以下の説明では、コンテンツ配信を希望するユーザのプレゼンティティ識別子はcharlie@example.co.jp、ユーザのニックネームは「チャーリー」、ユーザの希望するチャネルのプレゼンティティ識別子はcake@example.co.jp、チャネル名は「空からケーキ」とする。

図１０は、ユーザへコンテンツを配信する際の情報配信サーバ４の動作の一例を示すシーケンス図である。コンテンツには、配信コンテンツおよび転送コンテンツの２種があるが、図１０では、配信コンテンツを配信する際のフローについて記載している。情報配信サーバ４は、特定のチャネルに対するユーザのプレゼンス情報の通知を契機として、そのチャネルに属するコンテンツの中で、ユーザのプレゼンス情報が配信条件を満たす配信コンテンツと、ユーザに転送可能な転送コンテンツがＤＢ装置４５に格納されているかどうか検索する。そして、送信可能と判断されたコンテンツをユーザに送信する。

ユーザ通信端末のプレゼンス情報が変化すると、ユーザ通信端末からプレゼンスサーバ３に対して、プレゼンス情報が送信される（Ｓ１００１）。情報配信サーバ４を含め、プレゼンス対応型クライアントがユーザのプレゼンス情報の通知を受ける方法には、プレゼンスサーバ３に対して特定ユーザのプレゼンス情報のプッシュ型通知を申請するサブスクライブ方式と、プレゼンスサーバに対して定期的にプレゼンス情報を要求するフェッチ方式とがある。サブスクライブ方式ではユーザのプレゼンス情報が変更されない限り通知は行われないが、フェッチ方式ではプレゼンス情報が変更されていない場合も通知が行われる。一般のプレゼンス対応型クライアントは主にサブスクライブ方式を使用しているが、情報配信サーバ４はサブスクライブ方式とフェッチ方式を併用してもよい。例えば、図１４のＳ１４０６を契機としてプレゼンス情報管理部４３３がプレゼンス情報を取得する場合は、コンテンツの配信を即座に判断するために、フェッチ方式で行うことが望ましい。

情報配信サーバ４がプレゼンス情報の通知パケットを受信する（Ｓ１００２）と、当該パケットは、図５のＩＦ４１で解析され、ヘッダ部ないしペイロード部に格納されたプレゼンス情報が抽出される。なお、以下の説明において、「通知」ないし「要求」などの動作は、全て使用される通信プロトコルに対応したパケットないしメッセージの形で送受信される。本実施例では、ユーザのプレゼンス情報として、ユーザのプレゼンティティ識別子である「charlie@example.co.jp」、ユーザのニックネームである「チャーリー」、状態情報である「在席」、そしてユーザの位置情報が、プレゼンティティ識別子「cake@example.co.jp」のチャネルに通知されたものとする。その通知はＩＦ４１を通してプレゼンスプロトコル送受信部４３１へ送られ、プレゼンスプロトコル送受信部４３１は、これをプレゼンス情報管理部４３３へ転送する（Ｓ１００３）。この通知はサブスクライブ方式で受けたものでもフェッチ型で受けたものでもよい。

プレゼンス情報管理部４３３は、チャネル情報テーブル４５２を参照し、ユーザからサブスクライブ要求されたチャネルのプレゼンティティ識別子をキーとして、チャネルのチャネルNo.を取得する（Ｓ１００４）。プレゼンス情報管理部４３３は更に、ユーザ情報テーブル４５１を参照し、サブスクライブ要求を行なっているユーザの、そのチャネルに対するプレゼンス情報（ユーザのプレゼンティティ識別子charlie@example.co.jp、権限情報；一般、状態情報：在席）および配信済みコンテンツNo.情報と前回の配信時刻情報とを取得する（Ｓ１００５）。後述するステップ１４０６などにおいて、ユーザのプレゼンス情報を毎回プレゼンスサーバ３から取得するようにシステムを構成することも可能であるが、プレゼンスサーバ３で通知パケットを作成するのに時間がかかるため、ユーザ通信端末に対するシステム全体のレスポンスが遅くなる。

従って、本実施例では、ユーザのプレゼンス情報の一部をユーザ情報テーブル４５１にキャッシュしている。ステップ１００５において、プレゼンス情報管理部４３３は、コンテンツ配信要求を行なっているユーザが、チャネルに対応しているか否かの判断を行なう。すなわち、プレゼンスサーバ３から通知されたプレゼンス情報に対応するユーザ情報が、ユーザ情報テーブル４５１に存在すれば処理を続行し、存在しなかったらそのユーザはまだチャネルへの購読手続きを行っていないと見なして処理を終了する。

次に、プレゼンスサーバ３から通知されたプレゼンス情報が、ユーザ情報テーブル４５１にキャッシュされたプレゼンス情報と変化しているか否かを判断し、ユーザ情報が変化していた場合は新しい内容でユーザ情報テーブル４５１を更新する（Ｓ１００６）。最後に、ユーザ情報に含まれる状態が「在席」などのコンテンツ受信可能な状態かを調べ、受信可能な場合は、コンテンツ送信制御部４３４へプレゼンス情報の更新とその内容を通知する（Ｓ１００７）。本実施例では、「チャーリー」氏の状態情報は「在席」であるので、プレゼンス情報管理部４３３は、ユーザがコンテンツを受信可能と判断し、ステップ１００７の動作を実行する。コンテンツ受信が不可能なユーザに対してプレゼンス情報の変化を受け取った場合、例えば、図７の「ボブ」氏に関するプレゼンス情報の変化を受け取った場合、プレゼンス情報管理部４３３は、ユーザがコンテンツを受信不可能と判断し、処理を終了する。

ステップ１００７でプレゼンス情報の通知を受けると、コンテンツ送信制御部４３４は、配信コンテンツテーブル４５３を参照し、送信先のチャネルに対応する配信コンテンツ及びコンテンツ配信可否を判断するための参照情報を取得する（Ｓ１００８）。本実施例のステップ１００８においては、例えば、ユーザ１から配信要求されたチャネル番号１に相当するコンテンツである「Ａ菓子店のおすすめ・・・」と「▼期間限定▼・・・」の両者が、コンテンツ送信制御部４３４によって取得される。ステップ１００８の終了後、コンテンツ送信制御部４３４は、ユーザのプレゼンス情報と、ユーザ情報に含まれる過去の配信記録などに基づいて、送信すべき配信コンテンツを選別する。配信コンテンツテーブル４５３に格納される配信条件としては、コンテンツの配信を判断する関数を用いることが可能である。格納された関数に、引数としてユーザのプレゼンス情報などを渡すことで配信可能なコンテンツを識別する。

また、配信回数が１回のコンテンツで、そのユーザに対して既に配信している（過去の配信記録に含まれる）コンテンツは上記の識別の対象外とする。上記の処理に基づき、コンテンツ送信制御部４３４は、ユーザに対して送信すべき配信コンテンツがあるかどうか判断することが可能となる。本実施例では、配信コンテンツテーブルから取得したコンテンツ「Ａ菓子店のおすすめ・・・」と「▼期間限定▼・・・」に対応する配信回数フィールド、及び有効期間フィールドに格納された情報と、図７の「チャーリー」に対応するコンテンツNo.フィールドと前回配信時刻フィールドに格納された情報とを比較し、過去に配信されていないコンテンツである「Ａ菓子店のおすすめ・・・」が選択される。そして、配信すべきコンテンツがある場合は、コンテンツ送信制御部４３４は、その全てまたは一部の配信コンテンツを、コンテンツ送受信部４３２に転送する（Ｓ１００９）。
コンテンツ送受信部４３２は、ＩＦ４１を通して、転送されたコンテンツをユーザ通信端末２へ送信する（Ｓ１０１０）。送信終了後は、その結果を基に、ユーザ情報テーブル４５１の過去の配信記録を更新する（Ｓ１０１１）。

次に、図１１に示すシーケンス図及び図４〜図９を用いて、転送コンテンツ送信時の情報配信サーバ４の動作について説明する。本実施例では、図９の転送コンテンツテーブルに示された、送信元ユーザのプレゼンティティ識別子「bob@example.co.jp」に対応するユーザから、送信先ユーザのプレゼンティティ識別子「alice@example.co.jp」に対応するユーザに送信したコンテンツが、送信先ユーザ離席中のため、リアルタイムのコンテンツ配信ができずに、転送コンテンツテーブルに格納された場合を想定して説明する。

まず、送信先ユーザである「アリス」氏のプレゼンス情報が「離席中」から「在席中」へ変化し、それがユーザ通信端末からプレゼンスサーバ３へ通知されたとする（Ｓ１１０１）。本実施例では、ユーザのプレゼンス情報として、ユーザのプレゼンティティ識別
子である「alice@example.co.jp」、ユーザのニックネームである「アリス」、状態情報である「在席」、そしてユーザの位置情報が、プレゼンティティ識別子「cake@example.co.jp」のチャネルに通知されたものとする。ステップ１１０２からステップ１１０７までの動作は、図１０で説明したステップ１１０２から１００７までの動作と同じなので省略し、以下、ステップ１１０８以降の動作について説明する。

プレゼンス情報が変化した通知があったユーザ「アリス」氏が、コンテンツ配信可能な状態にあることが判明したので、コンテンツ送信制御部４３４は、転送コンテンツテーブル４５４を参照して、プレゼンス情報の送信先のチャネルに対応し、プレゼンス情報の送信元を送信先ユーザとする転送コンテンツを取得する（Ｓ１１０８）。ステップ１１０３からステップ１１０７までの動作で、プレゼンスサーバ３から通知されたユーザ「アリス」氏のプレゼンティティ識別子は「alice@example.co.jp」であることが判っているので、コンテンツ送信制御部４３４は、図９の転送コンテンツテーブルより、プレゼンス情報の送信元を送信先ユーザとする転送コンテンツである「教えていただいた新作・・・」を取得できる。該当するコンテンツが転送コンテンツテーブルに存在しなかった場合、コンテンツ送信制御部４３４は、コンテンツ転送処理を終了する。本実施例の場合、転送コンテンツが存在しているので、その全てまたは一部を、コンテンツ送受信部４３２に転送する（Ｓ１１０９）。コンテンツ送受信部４３２は、転送された転送コンテンツを、ＩＦ４１を経由してユーザに送信する（Ｓ１１１０）。そして、送信終了した転送コンテンツを転送コンテンツテーブル４５４から削除する（Ｓ１１１１）。

なお、実際には、プレゼンスサーバからプレゼンス情報の変化が通知されたユーザに対しては、送信コンテンツの送信処理と転送コンテンツの送信処理が平行して実行される。つまり、図１０のステップ１００６以降の処理と、図１１のステップ１１０６以降の処理が、同時並行的に実行される。しかしながら、説明を簡略化するため、以上の説明では、送信コンテンツの送信処理と転送コンテンツの送信処理のフローを別な図面を用いて説明している。
以上のようにシステムを構成することで、予めユーザが購読したチャネルに対して、ユーザのプレゼンス情報を契機としたコンテンツのプッシュ型配信が可能となる。

（チャネルへのサブスクライブ動作）
以上の説明では、既にチャネルへの登録が完了しているユーザに対するコンテンツの配信・転送方法について説明したが、新たなチャネルからコンテンツの配信を受けたいユーザは、そのチャネルに自分を登録する必要がある。以下、ユーザのチャネルへの登録方法について説明する。なお、以下の説明ではこのユーザのプレゼンティティ識別子はbob@example.co.jp、ユーザのニックネームは「ボブ」、ユーザがサブスクライブを希望するチャネルのプレゼンティティ識別子はcake@example.co.jp、チャネル名は「空からケーキ」とする。

ユーザが、特定のチャネルの購読申込みを行なう場合、端末を操作して、当該チャネルのプレゼンティティ１４をバディリストに追加する。バディリストの内容が変化したので、ユーザ通信端末は、バディリストの内容変化をプレゼンスサーバ３に送信する。実用的には、バディリストの変化を、ユーザ通信端末に備えられたクライアントソフトが検出し、端末に備えられた通信用のアプリケーションソフトウェアを起動し自動送信するようなシーケンスが組まれる。

図１２には、ユーザからチャネルの購読申請が行われる際の、情報配信サーバ４の動作の一例を示すシーケンス図である。ユーザ通信端末２は、自分が持つバディリストにチャネルのプレゼンティティ１４が追加されると、プレゼンスサーバ３に対して、チャネルのプレゼンティティ１４へのサブスクライブを要求する（Ｓ１２０１）。サブスクライブに際しては、サブスクライブしようとするチャネルのプレゼンティティ識別子「cake@example.co.jp」と、ユーザのプレゼンティティ識別子「bob@example.co.jp」とが少なくとも格納されたパケットが、ユーザ通信端末２からプレゼンスサーバ３に対して送信されるものとする。要求を受けたプレゼンスサーバ３は、情報配信サーバ４に対してユーザからのサブスクライブの要求を通知するか、またはユーザの代理としてプレゼンスサーバ３がサブスクライブを要求する（Ｓ１２０２）。この要求は情報配信サーバ４のＩＦ４１を通して、プレゼンスプロトコル送受信部４３１へ送られる。プレゼンスプロトコル送受信部４３１は、プレゼンス情報管理部４３３に対してサブスクライブの依頼を行う（Ｓ１２０３）。

プレゼンス情報管理部４３３は、チャネル情報テーブル４５２を参照し、ユーザからサブスクライブ要求されたチャネルのチャネルNo.を取得する（Ｓ１２０４）。プレゼンス情報管理部４３３は更に、ユーザ情報テーブル４５１を参照し、サブスクライブ要求を行なっているユーザの、そのチャネルに対するプレゼンス情報（権限情報；管理者、状態情報：在籍）および配信済みコンテンツNo.情報と前回の配信時刻情報とを取得する（Ｓ１２０５）。ここで、そのようなユーザ情報が存在しなかったら、そのユーザはまだチャネルへの購読手続きを行っていないと見なす。ユーザがまだチャネルを購読していない場合、ユーザからのサブスクライブを許可する前に、チャネルからユーザに対してサブスクライブを行う（ただしこのサブスクライブの成功が保証されている場合は、先に許可してもよい）。

プレゼンス情報管理部４３３は、チャネルのプレゼンティティを送信元として、ユーザのプレゼンティティに対するサブスクライブをプレゼンスプロトコル送受信部４３１に依頼する（Ｓ１２０６）。プレゼンスプロトコル送受信部４３１は、ＩＦ４１を通して、プレゼンスサーバ３に対して、ユーザのプレゼンティティ１２へのサブスクライブを要求する（Ｓ１２０７）。この要求を受けたプレゼンスサーバ３は、一般のプレゼンスサービスの動作として、ユーザ通信端末２に対して情報配信サーバ４（チャネル）からのサブスクライブの要求を通知するか、または情報配信サーバ４の代理としてプレゼンスサーバ３がサブスクライブを要求する（Ｓ１２０８）。

ユーザがこのサブスクライブを許可するとそれがプレゼンスサーバ３に通知され（Ｓ１２０９）、プレゼンスサーバ３は情報配信サーバ４にそれを通知する（Ｓ１２１０）。この通知は、情報配信サーバ４のＩＦ４１を通して、プレゼンスプロトコル送受信部４３１へ転送される。プレゼンスプロトコル送受信部４３１は、プレゼンス情報管理部４３３に対してサブスクライブの完了を通知し（Ｓ１２１１）、プレゼンス情報管理部４３３は、ユーザ情報テーブル４５１にユーザの情報（権限を「一般」とする）を示す行を追加する（Ｓ１２１２）。最後に、プレゼンス情報管理部４３３は最初に送られてきたユーザのサブスクライブを許可する。その後の処理は、ユーザがサブスクライブを許可した場合と同様である（Ｓ１２１３、Ｓ１２１４、Ｓ１２１５）。これ以降、情報配信サーバ４上のこのチャネルは、プレゼンティティ１２を通してユーザのプレゼンス情報を取得し、プレゼンス情報に含まれる通信手段によって、ユーザ通信端末２との間でコンテンツの送受信を行えるようになる。

以上の処理はユーザがあるチャネルに対して初めてサブスクライブをした場合は必ず行われるが、２度目以降はプレゼンスサーバ３か、または情報配信サーバ４のプレゼンス情報管理部４３３の機能によって、ユーザからのサブスクライブは即座に許可されてもよい。

（配信コンテンツの登録時の動作）
情報配信サーバ４上のチャネルを利用してコンテンツを配信するためには、チャネル管理者は予め何らかの方法によって配信コンテンツとその配信条件を情報配信サーバ４へ送信しておく必要がある。この手段は大きく２つに分けられる。
１つは、プレゼンス対応型クライアントの持つ、ユーザ間のコンテンツ送受信機能を利用する方法である。プレゼンスサービス上では、チャネルのプレゼンティティ１４もユーザのプレゼンティティ１２も同等に扱われるため、ユーザ間でのコミュニケーションに使用するコンテンツ（テキスト、音声、動画など）の形式で、配信コンテンツをチャネル（実際は情報配信サーバ）へ送信できる。

図１３は、インスタントメッセンジャーを利用して配信コンテンツを送信する際の、ユーザ通信端末のメッセージ送信ウィンドウの画面例である。これは、配信コンテンツの登録操作画面を想定している。メッセージの１行目先頭の文字「／regist」はこのメッセージが配信コンテンツの登録であることを示すコマンドで、その後に続く文字は「緯度３５．４２１１、経度１３９．２８２７の地点から半径２０ｍ以内に居る場合」という配信条件を示している。２行目以降の文章は実際の配信コンテンツである。また、配信条件の指定にチャネル管理者のプレゼンス情報を利用してもよい。例えば、「緯度３５．４２１１、経度１３９．２８２７の地点から半径２０ｍ以内」と入力する替わりに、「半径２０ｍ以内」のみを入力し、当該形式の入力に対しては、「登録時のチャネル管理者の位置から半径２０ｍ以内に居る場合」であると予め設定しておけば、配信条件入力時のユーザの負担が軽減される。

２つは、配信コンテンツを登録するためのインタフェイスを情報配信サーバ４上に設け、そのインタフェイスを利用するクライアントをユーザ通信端末２かその他の端末に設けるという方法である。例としては、情報配信サーバ４はＷｅｂ上のＣＧＩとして配信コンテンツの登録用のインタフェイスを公開し、ユーザはＷｅｂブラウザを通してそれを利用する方法などがある。
図１４には、配信コンテンツの登録が行われる際の、情報配信サーバの動作の一例を示すシーケンス図を示した。この例を含め、以下の説明では、配信コンテンツの登録は、上記の１つ目の方法で実行されるものとする。

ユーザ通信端末２は、端末上のプレゼンス対応型クライアントの持つコンテンツ送受信機能によって、配信コンテンツとその配信条件を情報配信サーバ４へ送信する（Ｓ１４０１）。この際、図８に示した、コンテンツ情報および配信条件、配信に関する制限情報の他、チャネルのプレゼンティティ識別子と、コンテンツ登録を要求したユーザのプレゼンティティ識別子が情報配信サーバ４へ送信される。送信されたコンテンツは、情報配信サーバ４のＩＦ４１を通してコンテンツ送受信部４３２へ送られ、これを受信したコンテンツ送受信部４３２は、コンテンツ登録部４３５へコンテンツの登録を依頼する（Ｓ１４０２）。

コンテンツ登録部４３５は、チャネル情報テーブル４５２を参照し、チャネルのプレゼンティティ識別子をキーとして、チャネルNo.を取得する（Ｓ１４０３）。次に、コンテンツ登録部４３５は、ユーザ情報テーブル４５１を参照し、送信元ユーザのユーザ情報、つまり、ユーザのプレゼンティティ識別子と権限情報を取得する（Ｓ１４０４）。コンテンツの送信元のユーザのチャネルに対する権限を調べるためである。送信元ユーザが、確かに送信先チャネルのチャネル管理者であると判断された場合は、配信コンテンツテーブル４５３に配信コンテンツを登録する（Ｓ１４０５）。

ユーザからのプレゼンス情報の通知を待たずに、配信条件を満たすユーザへ配信コンテンツを送信したい場合は、チャネルを購読しているユーザのプレゼンス情報の取得をプレゼンス情報管理部４３３へ要求する（Ｓ１４０６）。このとき、ユーザ情報テーブル４５１にて状態が「在席」などのコンテンツ受信可能なものであるユーザに対してのみ、プレゼンス情報を要求すればよい。また、配信コンテンツの登録に成功した場合は、コンテンツ送受信部４３２とＩＦ４１を通して、ユーザに配信コンテンツの登録成功を通知してもよい（Ｓ１４０７、Ｓ１４０８）。

図１５には、コンテンツ登録時の情報配信サーバの動作に関し、図１４のシーケンス図よりも詳細な動作のフローチャートを示した。
ユーザ通信端末２からチャネルに対して送信されたコンテンツは、情報配信サーバ４内のコンテンツ送受信部４３２へ送られ、コンテンツ送受信部４３２はコンテンツ登録部４３５へこのコンテンツを送信する（Ｓ１５０１）。

コンテンツ登録部４３５は、まずコンテンツの送信先になっているチャネルのチャネル情報を、チャネル情報テーブル４５２から取得する（Ｓ１５０２）。次に、コンテンツの送信元のユーザのチャネルに対する権限を調べるために、ユーザ情報テーブル４５１から送信元ユーザのユーザ情報を取得する（Ｓ１５０３）。送信元のユーザがこのチャネルのチャネル購読者でもチャネル管理者でもない場合は、この時点でコンテンツを破棄して処理を終了する（Ｓ１５０４）。

次に、送信元のユーザがこのチャネルのチャネル管理者かどうかで処理の分岐を行う（Ｓ１５０５）。送信元のユーザがチャネル購読者の場合は、チャネル管理者に対する転送コンテンツと見なす。送信元のユーザがチャネル管理者の場合は、更にメッセージ１行目のコマンドをチェックするなどして、コンテンツが転送コンテンツか配信コンテンツかを判断して、更に処理の分岐を行う（Ｓ１５０６）。メッセージ１行目のコマンドが不正であるなどの理由で、転送コンテンツでも配信コンテンツでもなかった場合はコンテンツを破棄して処理を終了する（Ｓ１５０６）。

送信元のユーザがチャネル管理者で、コンテンツが配信コンテンツの場合は、配信コンテンツテーブルにその配信コンテンツを登録する（Ｓ１５０８）。ユーザからのプレゼンス情報の更新を待たずに、配信条件を満たすユーザへ配信コンテンツを送信したい場合は、チャネルを購読しているユーザのプレゼンス情報の取得をプレゼンス情報管理部４３３へ要求する（Ｓ１５０９）。このとき、プレゼンス情報管理部４３３は、コンテンツ受信可能な状態のユーザに対してのみプレゼンス情報を要求すればよい。

送信元のユーザがチャネル管理者かチャネル購読者で、コンテンツが転送コンテンツの場合は、ユーザ情報テーブル４５１からそれぞれの送信先のユーザ情報を取得する（Ｓ１５１０、Ｓ１５１１）。そして、送信先のユーザの状態を確認し（Ｓ１５１２）、送信先のユーザがコンテンツ受信可能な状態ならばコンテンツ送受信部４３２を経由してコンテンツを送信し（Ｓ１５１３）、送信先のユーザがコンテンツ受信可能な状態でなければ転送コンテンツテーブル４５４に転送コンテンツを登録する（Ｓ１５１４）。コンテンツ送受信部４３２はＩＦ４１を通してユーザ通信端末２へ転送コンテンツを送信する。

なお、ユーザはバディリストへのプレゼンティティの追加と削除によってチャネルの購読と解約の申請を実行できるため、コンテンツの配信が特定の場所や時間に限られたチャネル（美術館の案内チャネルなど）の購読も気軽に行えるというメリットがある。また、上記の例とは逆に、チャネルのプレゼンティティからユーザのプレゼンティティへとサブスクライブを行うことでチャネルの購読手続きを開始してもよい。

（チャネルの新規作成時の動作）
情報配信サーバ４を利用してコンテンツの配信を行いたいユーザは、チャネル情報テーブルとプレゼンス情報テーブルを操作できる情報配信サーバ４の管理者または管理用のプログラム（以下、管理主体）に、チャネルの作成を要求する必要がある。
まず、情報配信サーバ４は、何らかの手段でユーザからチャネルの作成要求を受ける。この手段にはオフラインの文書、電子メール、Ｗｅｂサイトのフォームへの入力、インスタントメッセージなどがある。チャネルの作成要求にはユーザのプレゼンティティ識別子、チャネルのプレゼンティティ識別子の第一希望、チャネル名、紹介文などを含める。以下の説明ではこのユーザのプレゼンティティ識別子はalice@example.co.jp、ユーザのニックネームは「アリス」、ユーザの希望するチャネルのプレゼンティティ識別子はcake@example.co.jp、チャネル名は「空からケーキ」とする。

この要求を受けた管理主体は、プレゼンスサービスの一部として用意されている手段を用いて、ユーザから指定されたプレゼンティティ「alice@example.co.jp」をプレゼンスサーバに新規追加しようと試みる。当該プレゼンティティ識別子が既に他のユーザによって使用されていればこの追加は失敗し、プレゼンスサーバ３は、その旨を情報配信サーバ４に通知する。この際、使用可能なプレゼンティティ識別子の情報を情報配信サーバ４へ送信し、情報配信サーバ４経由でユーザに転送しても良い。この例ではユーザの希望通りのプレゼンティティ識別子を追加できたとする。

次に、ＤＢ装置４５内のテーブルにチャネルの情報を登録する。まず、チャネル情報テーブル４５２に新しいチャネルの情報を示す行を追加する。次に、申し込みを行ったユーザをそのチャネルの管理者（以下、チャネル管理者）として登録するために、ユーザ情報テーブル４５１にチャネル管理者の情報（権限を「管理者」とする）を示す行を追加する。図９の表の、上から２番目と６番目の行がチャネル管理者を示す行である。図９では１つのチャネルに対するチャネル管理者は常に１人になっているが、１つのチャネルに対して複数のチャネル管理者が登録されてもよい。以上でＤＢ装置４５へのチャネルの情報の登録は完了である。

最後に、情報配信サーバ４の管理主体は何らかの手段でチャネル管理者へチャネルのプレゼンティティ識別子を通知する。この手段にはオフラインの文書、電子メール、Ｗｅｂサイトのフォームへの入力、インスタントメッセージなどがある。
チャネル管理者は、情報配信サーバ４の管理者または管理用のプログラムからチャネルのプレゼンティティ識別子が通知されると、それを使ってチャネルを表すプレゼンティティにサブスクライブし、バディリストにチャネルのプレゼンティティを追加する（チャネル管理者のプレゼンティティ識別子は既にユーザ情報テーブルに登録されているので、この追加はすぐに成功する）。このように、プレゼンスサービス上ではチャネルのプレゼンティティも他のユーザのプレゼンティティと同様に扱われる。
以上説明した構成により、端末ユーザは、チャネルに関する各種の設定動作が自由に実施できるようになる。

図１６及び図１７には、チャネル管理者「アリス」氏と、アリス氏の管理するチャネル「空からケーキ」にサブスクライブしたユーザ「ボブ」氏の端末に表示される端末画面の一例を示す。図１６は、「ボブ」氏がチャネル「空からケーキ」宛に送ったメッセージ（コンテンツ）であり、図１７は、「アリス」氏が、チャネル「空からケーキ」から受信したメッセージの表示画面である。図１６を見ると、ボブ氏は、コンテンツをアリス氏に対して直接送信（例えば、アリス氏のアドレス宛に送信）しておらず、チャネルに対して送信していることが判る。また、図１７を見ると、アリス氏の見ている端末画面には、チャネル購読者であるボブ氏のニックネームのみが表示され、他の個人情報（アドレス、プレゼンティティ識別子など）が全く表示されていないことが判る。なお、チャネル購読者でもチャネル管理者でもないユーザから、チャネルに対して送信されたコンテンツは情報配信サーバ４にて無視される。つまり、チャネルのバディリストに登録されたプレゼンティティ以外からのコンテンツを遮断するという、通常のプレゼンス対応型クライアントと同様の動作を行う。

また、プレゼンス情報としては、位置情報（例えば、ユーザの状態、ニックネーム、通信手段、そして緯度と経度情報等）以外の情報も使用可能である。例えば、各種センサから取得した現在の気温や湿度などもプレゼンス情報として扱うことも可能である。また、ネットゲームなどの仮想的な空間における位置や、ユーザがＷｅｂブラウザで閲覧中のサイトのＵＲＬなどの論理的な位置をプレゼンス情報として利用した場合も、本実施例と同様にユーザ間のコミュニケーションを促進する効果が期待できる。
更に、配信コンテンツの配信条件に、チャネル購読者のプレゼンス情報以外の動的に変わる情報を含めてもよい。例えば、「ユーザの現在位置の天気が雨の場合だけ傘屋に関する配信コンテンツを配信する」ような配信条件がこれに該当する。情報配信サーバはこの動的に変わる情報（この例における各地の天気情報）をプレゼンスサービスから取得してもよいし、それ以外の手段で取得してもよい。

更にまた、以上の説明では、ユーザのプレゼンス情報が配信条件を満たすと情報配信サーバがコンテンツ（配信コンテンツ、転送コンテンツ）を送信したが、このようにすぐにコンテンツを配信するのではなく、情報配信サーバは一度ユーザに確認を取って、確認が取れたときだけコンテンツを送信するような対話的な方法などを用いてもよい。また、ユーザから登録されたコンテンツは、情報配信サーバがそのままの形式で送信したが、情報配信サーバはコンテンツを受信するユーザのプレゼンス情報に含まれる通信手段に適すように、コンテンツの形式や内容を変換してから送信してもよい。例えば、相手の通信手段によっては、テキストとして登録されたコンテンツを音声に変換してから送信するなどの変換をしてもよい。

また、本実施例では、ユーザのプレゼンス情報が配信条件を満たすと情報配信サーバがコンテンツ（配信コンテンツ、転送コンテンツ）を送信したが、このようにすぐにコンテンツを配信するのではなく、情報配信サーバは一度ユーザに確認を取って、確認が取れたときだけコンテンツを送信するような対話的な方法などを用いてもよい。また、ユーザから登録されたコンテンツは、情報配信サーバがそのままの形式で送信したが、情報配信サーバはコンテンツを受信するユーザのプレゼンス情報に含まれる通信手段に適すように、コンテンツの形式や内容を変換してから送信してもよい。例えば、相手の通信手段によっては、テキストとして登録されたコンテンツを音声に変換してから送信するなどの変換をしてもよい。

以上のように、本実施例により、ユーザ間で、個人情報の漏洩の少ないコンテンツ送受信方法が実現可能となる。なお、情報配信サーバ４のポリシーによっては、図１７の表示画面には、プレゼンティティ識別子や、他のプレゼンス情報（コンテンツ作成時の位置情報など）も表示してもよい。

実施例１では、ユーザが入手したいコンテンツ、換言すれば購読したいチャネルの情報をユーザが予め知っていることを前提としていた。しかしながら、そのような情報は、ユーザは通常知らないのが普通である。また、コンテンツを登録したユーザ（管理者）側に立てば、折角登録したコンテンツをなるべく多くのユーザに閲覧してもらいたいと考えるのが人情である。そこで、本実施例では、チャネルを検索するためのチャネル検索サーバについて説明する。

図１８には、本実施例で想定しているネットワークの物理的な構成図を示す。チャネルを検索する手段を提供するチャネル検索サーバ５が接続されている以外は、図１に示したネットワークの構成図と同じである。チャネル検索サーバ５が接続されている場合、論理的には、プレゼンスサービス１０上に、チャネル検索サーバ５のプレゼンティティが形成される。従って、図２に示した概念図に即して説明すると、情報配信サーバ側プレゼンティティ１４（14-1〜14-m）に類似したチャネル検索サーバ側プレゼンティティが、プレゼンスサービス１０上に公開されることになる。従って、チャネル検索サーバ５も、概念的にはプレゼンス対応型クライアントとバディリストを持つ１つの通信端末のように振る舞う。

図１９には、チャネル検索サーバ５の内部構成を機能展開して示したブロック図を示す。図中の実線部分はハードウェアの物理的な結線を表し、矢印付きの点線は論理的な情報の流れを表している。チャネル検索サーバ５の各ブロックの動作はメモリ５３に収納されており、動作時にはＣＰＵ５２がその動作手順を読み出して実行する。チャネル検索サーバ５の管理する情報はハードディスクで実現されるＤＢ装置５５に格納されており、ここから必要な情報を取り出し、書き込む。

メモリ５３は、プレゼンスプロトコル送受信部５３１、コンテンツ送受信部５３２、プレゼンス情報管理部５３３及び検索制御部５３４の各機能ブロックを格納する。ＤＢ装置５５は、ユーザのプレゼンス情報をキャッシュするプレゼンス情報テーブル５５１と、チャネル情報を格納するチャネル情報テーブル５５２と、チャネル検索のための情報を格納する検索インデックステーブル５５３、及び配信コンテンツの全体または一部からなる検索結果用のコンテンツ（以下、検索コンテンツ）を格納する検索コンテンツテーブル５５４とを備える。

チャネル検索サーバ５はプレゼンスプロトコル送受信部５３１の動作によって専用のプレゼンティティ１５をプレゼンスサービスに公開し、これを通して取得したユーザのプレゼンス情報を検索に使用する。また、プレゼンスサービスに基づいて行われるコンテンツの送受信によって検索要求と検索結果をやり取りするものとする。しかし、このやり取りは、プレゼンティティ１５を通さない方法（Ｗｅｂ上のＣＧＩとして検索用のインタフェイスを公開する方法など）で行ってもよい。

図２０には、検索インデックステーブルの構成例を示す。検索インデックステーブル５５３は、単語フィールドと、検索コンテンツテーブル上で、当該単語フィールドに含まれる情報が含まれた検索コンテンツのＩＤを格納する検索コンテンツNo.フィールドなどにより構成される。また、図２１には、検索コンテンツテーブル５５４の構成例を示す。検索コンテンツテーブル５５４は、前記のＩＤを格納する検索コンテンツNo.フィールドと、チャネルNo.フィールド、配信条件フィールド、コンテンツ種別フィールド、コンテンツ自体が格納されるコンテンツフィールド、当該チャネルの人気を数値化した情報が格納されるランクフィールドなどにより構成される。ランクフィールドは、原理的には無くとも検索を実行できるが、ユーザに対して様々な検索方法のオプションを提供する場合に必要となる。

また、プレゼンス情報テーブル５５１には、チャネル検索サーバのプレゼンティティにサブスクライブしているユーザのプレゼンス情報が格納されている。詳しく説明すれば、チャネル検索サーバにサブスクライブしているユーザのプレゼンティティ識別子に対応するプレゼンス情報を、プレゼンスサーバ３からキャッシュすることにより形成されたテーブルであり、具体的には、「ユーザのプレゼンティティ識別子フィールド」、「ニックネームフィールド」、およびユーザの位置情報を格納する位置情報フィールド等により構成されている。なお、チャネル情報を格納するチャネル情報テーブル５５２の構成は、図６に示したテーブルの構成とほぼ同じであるが、チャネル検索サーバのチャネルNo.と、情報配信サーバのチャネルNo.は独立に管理されるため、同じチャネルを指すチャネルNo.同士であっても必ずしも一致しない。本実施例では、情報配信サーバとチャネル検索サーバがそれぞれ１つずつであるため、その値が一致しているものとする。

次に、チャネル検索サーバ５の動作について、図２２のシーケンス図及び図１９の機能ブロック図、更に図６のチャネル情報テーブルを用いて説明する。なお、以下の説明においては、プレゼンティティ識別子「bob@example.co.jp」に対応するユーザ「ボブ」が、現在位置で受信できる「おすすめのケーキ」に関するコンテンツを検索しようとしている場合を想定している。また、当然であるが、「ボブ」の端末に備えられたプレゼンス対応型クライアントは、チャネル検索サーバのプレゼンティティsearch@example.co.jpを既に知っているものと仮定する。
図２２には、チャネルの検索が行われる際の、ユーザ通信端末とチャネル検索サーバ５との連携動作及びチャネル検索サーバ５の内部動作の一例を示すシーケンス図を示した。

まず、「ボブ」のユーザ通信端末２から、検索キーワードなどを含む検索要求がチャネル検索サーバ５へ送信される（Ｓ２２０１）。本実施例では、ユーザ「ボブ」から送信されたチャネル検索の要求パケットが、検索キーワード「ケーキ」およびユーザのニックネームである「ボブ」を含んでいた場合を考える。受信した検索要求パケットは、ＩＦ５１により解析され、ニックネーム「ボブ」および検索キーワード「ケーキ」が抽出される。当該情報は、コンテンツ送受信部５３２へ転送され、これを受信したコンテンツ送受信部５３２は、検索制御部５３４へチャネルの検索を依頼する（Ｓ２２０２）。

検索制御部５３４は、まずユーザのプレゼンティティ識別子をキーにしてプレゼンス情報テーブル５５１を参照し、検索要求の送信元ユーザのプレゼンス情報、例えばユーザの位置情報などを取得する（Ｓ２２０３）。次に、検索制御部５３４は、検索インデックステーブル５５３を参照し、ユーザの通知した検索キー「ケーキ」を含む検索コンテンツの検索コンテンツNo.「1,6,7,15」を取得する（Ｓ２２０４）。検索コンテンツNo.を取得すると、検索制御部５３４は、検索コンテンツテーブルを参照し、取得した検索コンテンツNo.に対応する行の情報を取得する。検索制御部５３４は、更に、取得したコンテンツから、配信条件フィールドに格納された情報とユーザのプレゼンス情報とを比較して、適切なコンテンツを選別する（Ｓ２２０５）。選別されるコンテンツは、複数見つかる場合もあれば、全く見つからない場合もある。

検索コンテンツテーブル５５４に格納される配信条件としては、情報配信サーバ４の配信コンテンツテーブル４５３と同様、コンテンツの配信を判断する関数を用いることが可能である。当該格納された関数に、引数としてユーザのプレゼンス情報などを渡すことで配信可能なコンテンツを識別することができる。また、このときに検索結果の順位付けなども行う。

ユーザの要求するコンテンツが上手く発見された場合、検索制御部５３４は、チャネル情報テーブルを検索し、選別された検索コンテンツに対応するチャネルの情報（チャネルのプレゼンティティ識別子、チャネル名など）をチャネル情報テーブル５５２から取得する（Ｓ２２０６）。検索制御部５３４は、最後に、コンテンツ送受信部５３２とＩＦ５１を通して、ユーザ通信端末２へ検索結果を送信する（Ｓ２２０７、Ｓ２２０８）。以上、チャネル検索サーバの構成及び動作について説明した。しかし、以上で説明した内容は、あくまで実施形態の一例であり、チャネル検索を実現するための詳細方法は、公知技術が適用される範囲で、本実施例の範疇に含まれる。また、図１８では、チャネル検索サーバが一つしかないネットワークについて説明したが、複数のチャネル検索サーバが存在してもよいことは言うまでもない。
以上、本実施例に開示される技術によりコンテンツに応じたチャネル検索が実現可能となり、不特定多数のユーザに対してコンテンツ配信を行なう上でのユーザ利便性が非常に向上する。

本実施例では、チャネル検索サーバの別な構成例について、２つの例を用いて説明する。チャネル検索サーバ５は、チャネルの検索に必要な情報を内部に持たず、ユーザから検索が行われるたびに情報配信サーバ４に対して検索要求を行ってもよい。
図２３には、そのようなチャネル検索サーバ５の内部構成を機能展開して示したブロック図を示す。メモリ５３とＤＢ装置５５以外は図５と同様である。本実施例のチャネル検索サーバ５は、チャネル検索に必要な情報（チャネル情報テーブル５５２、検索インデックステーブル５５３、検索コンテンツテーブル５５４）をＤＢ装置５５に持たない代わりに、情報配信サーバ４に対して検索要求を行うための検索プロトコル送受信部５３５を持つ。この場合、チャネル検索サーバ５と情報配信サーバ４の間でチャネル検索のための独自のプロトコルを定義し、各情報配信サーバ４はチャネル検索に必要な情報をＤＢ装置４５に持つ必要がある。

図２４は、図２３に示すチャネル検索サーバ５がチャネルの検索要求を受けた際の、検索制御部５３４の動作の一例を示すシーケンス図である。チャネル検索サーバ５がユーザからの検索要求を受け取ると、その検索要求はＩＦ５１を通してコンテンツ送受信部５３２へ送られ、コンテンツ送受信部５３２はこれを検索制御部５３４へ送信する（Ｓ２４０１）。検索制御部５３４は、まずプレゼンス情報テーブル５５１から、検索要求の送信元ユーザのプレゼンス情報を取得する（Ｓ２４０２）。そして、送信元ユーザの検索要求とプレゼンス情報を組み合わせて新たな検索要求を作成し、これを検索プロトコル送受信部５３５を経由して１つまたは複数の情報配信サーバ４に送信する（Ｓ２４０３）。検索プロトコル送受信部５３５はＩＦ５１を通して情報配信サーバ４へ検索要求を送信する。

情報配信サーバ４では何らかの方法によって検索結果が作成され、それがチャネル検索サーバ５に送信される。その検索結果はＩＦ５１を通して検索プロトコル送受信部５３５へ送られ、検索プロトコル送受信部５３５はこれを検索制御部５３４へ送信する（Ｓ２４０４）。複数の情報配信サーバに対して検索要求を送信した場合は、各情報配信サーバの検索応答を１つの結果にまとめ（Ｓ２４０５、Ｓ２４０６）、コンテンツ送受信部５３２を経由して検索要求の送信元ユーザへ送信する（Ｓ２４０７）。コンテンツ送受信部５３２はこれをＩＦ５１を通してユーザ通信端末２に送信する。

以上のように、チャネル検索サーバ自身はチャネル検索に必要な情報を持たないため、複数の情報配信サーバと接続して実施される際に、チャネル検索サーバの管理が容易になるという利点がある。この利点は、チャネル検索サーバ５の実施事業者と情報配信サーバの実施事業者とが別であるような場合に、特に有効であり、プレゼンスサービス１０のスケーラビリティを確保する上では、実施例２に示したチャネル検索サーバに比べて有利であると言える。

図２５には、チャネル検索サーバの更に別の構成例を示す。チャネル検索サーバ５は、ユーザのプレゼンス情報のキャッシュを内部に持たず、ユーザから検索が行われるたびに、プレゼンスサーバ３に対してプレゼンス情報の要求を行ってもよい。図２５は、そのようなチャネル検索サーバ５の内部構成を機能展開して示したブロック図である。メモリ５３とＤＢ装置５５以外は、図１９に示した機能ブロック図と同様である。チャネル検索サーバ５はユーザのプレゼンス情報のキャッシュ（プレゼンス情報テーブル５５１）をＤＢ装置５５に持たない代わりに、ユーザから検索要求を受けるたびにプレゼンスサーバ３に対してプレゼンス情報を要求する。
更に、チャネル検索サーバ５は、ＤＢ装置５５を全く持たない構成であってもよい。

実施例１から３では、プレゼンスサーバ３及び情報配信サーバ４が一つしか存在しないネットワークを考えてきたが、複数のプレゼンスサーバや複数の情報配信サーバが通信網１に接続されていても良い。情報配信サーバ４を増やすことでプッシュ型情報配信システム１の収容可能チャネル数を増やすことができる。また、本発明は、プレゼンスサーバ３に独自の修正を要求しないため、このようにプレゼンスサーバ３を増やすことでプレゼンスサービスの収容可能プレゼンティティ数を増やすことができる。これはチャネル検索サーバや情報配信サーバの数に影響されない。

本発明を用いてコンテンツを配信するチャネル管理者がチャネル購読者に課金するためには、ユーザのプレゼンティティを管理するプレゼンスサーバと、チャネルのプレゼンティティを管理するプレゼンスサーバの双方が、ユーザを認証する機能を持っている必要がある。これによって、ユーザの成りすましによる配信コンテンツの受信を防止する。また、実際に購読が行われたことをチャネル購読者と情報配信サーバ以外の第三者に証明してもらいたい場合は、プレゼンスサーバにサブスクライブのログを記録してもらう方法がある。

チャネル購読者に対する課金の方法としては、チャネルに対してサブスクライブを行った期間（月単位など）に対して課金する定額制の方法や、チャネルに対してサブスクライブを行っていた時間の長さに対して課金する従量制の方法、そして有用なコンテンツを受け取ったときだけチャネル購読者がチャネル管理者にお金を払う投げ銭型の方法が考えられる。投げ銭型の方法を採用する場合は、コンテンツを送受信するための手段が非否認性やリプレイ防止などの機能を持っている必要がある。

一方、情報配信サーバの管理者がユーザに課金する方法としては、チャネルの作成料や利用料をチャネル管理者に対して請求する方法（Ｗｅｂ上のホームページのレンタル方法に類似）や、配信コンテンツに広告を挿入する方法（メールマガジンの広告に類似）などがある。
以上、本発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計なども含まれる。

実施例１で想定するネットワークの物理的な構成を示す図である。 プレゼンティティの概念を示すための概念図である。 プレゼンティティ間で送受信されるプレゼンス情報や実コンテンツ情報が、現実のネットワークでどう流れているかを示すための図である。 実施例１の情報配信サーバの論理構成を示す概念図である。 実施例１の情報配信サーバの機能ブロック図である。 チャネル情報テーブルの構成例を示す図である。 ユーザ情報テーブルの構成例を示す図である。 配信コンテンツテーブルの構成例を示す図である。 転送コンテンツテーブルの構成例を示す図である。 配信コンテンツ送信時の動作シーケンスを示す図である。 転送コンテンツ送信時の動作シーケンスを示す図である。 ユーザがチャネルにサブスクライブを行なう際の動作シーケンスを示す図である。 コンテンツ登録時に、ユーザ通信端末に表示される表示画面を示す図である。 コンテンツ登録時の動作シーケンス図である。 コンテンツ登録時の情報配信サーバの内部動作を示すフローチャートである。 ユーザが所望のチャネルに対してコンテンツを送信する際に、送信元ユーザのユーザ通信端末に表示される表示画面を示す図である。 図１６に示すコンテンツが転送された際に、コンテンツ送信先ユーザのユーザ通信端末に表示される表示画面を示す図である。 実施例２で想定するネットワークの物理的な構成を示す図である。 チャネル検索サーバの内部構成を機能展開して示したブロック図である。 検索インデックステーブルの構成例を示す図である。 検索コンテンツテーブルの構成例を示す図である。 実施例２のチャネル検索サーバに対してユーザ通信端末からチャネル検索要求があった場合の、動作シーケンスを示す図である。 別な構成のチャネル検索サーバの機能ブロック図である。 図２３に示す構成のチャネル検索サーバの内部動作を示すフローチャートである。 チャネル検索サーバの更に別な構成の機能ブロック図である。 チャネル検索時に、ユーザ通信端末に表示される表示画面を示す図である。 チャネル検索サーバから検索結果を受信した際に、ユーザ通信端末に表示される表示画面を示す図である。

符号の説明

１ プレゼンスサービスに基づくプッシュ型情報配信システム
２ ユーザ通信端末
３ プレゼンスサーバ
４ 情報配信サーバ
５ チャネル検索サーバ
６ 通信網
１０ プレゼンスサービス
１２、１４、１５ プレゼンティティ
４０ チャネル通信端末
４１、５１ ＩＦ
４２、５２ ＣＰＵ
４３、５３ メモリ
４４、５４ データパス
４５、５５ ＤＢ装置
４８ プレゼンス対応型クライアント
４３１、５３１ プレゼンスプロトコル送受信部
４３２、５３２ コンテンツ送受信部
４３３、５３３ プレゼンス情報管理部
４３４ コンテンツ送信制御部
４３５ コンテンツ登録部
４５１ ユーザ情報テーブル
４５２、５５２ チャネル情報テーブル
４５３ 配信コンテンツテーブル
４５４ 転送コンテンツテーブル
４５７ バディリスト
４５８ コンテンツデータベース
５３４ 検索制御部
５３５ 検索プロトコル送受信部
５５１ プレゼンス情報テーブル
５５３ 検索インデックステーブル
５５４ 検索コンテンツテーブル。

Claims (5)

1. ネットワーク上で、予め登録されたユーザに所定のコンテンツを配信する情報配信方法であって、前記ネットワークは、第１の端末と、第２の端末と、該第１の端末のユーザのプレゼンス情報と該第２の端末のユーザのプレゼンス情報とを管理するプレゼンスサーバと、前記第１の端末に配信するためのコンテンツを格納する情報配信サーバと、前記第１の端末、前記第２の端末、前記プレゼンスサーバおよび情報配信サーバ間とを接続して通信を可能とする通信網とから構成され、
   前記プレゼンスサーバにおいて、前記プレゼンスサーバ上に、前記第１の端末がプレゼンスサービスを受けるために必要なアカウントである第１のプレゼンティティと、前記第２の端末がプレゼンスサービスを受けるために必要なアカウントである第２のプレゼンティティと、前記情報配信サーバがプレゼンスサービスを受けるために必要なアカウントである前記第１及び第２のプレゼンティティとは異なる一以上のその他のプレゼンティティとを作成し、
   前記プレゼンスサーバにおいて、該第１のプレゼンティティに対して、当該プレゼンティティを一意に識別するための第１の識別子を、該第２のプレゼンティティに対して、当該プレゼンティティを一意に識別するための第２の識別子を、該一以上のその他のプレゼンティティに対して、各々を一意に識別するためのその他の識別子を付与し、
   前記第２の端末から、前記その他のプレゼンティティに対して、コンテンツデータと前記第２のプレゼンティティに関するアカウント情報とを送信し、
   前記情報配信サーバにおいて、該送信されたコンテンツデータをアカウント情報と対応させて登録し、
   前記情報配信サーバは、前記プレゼンスサーバより、前記その他のプレゼンティティを通して前記第１のユーザのプレゼンス情報を取得し、
   前記情報配信サーバにおいて、該取得したプレゼンス情報が前記格納されたコンテンツデータの配信条件に一致した場合は、当該コンテンツデータの配信元を前記その他の識別子として、前記第１のユーザに当該コンテンツデータを配信することを特徴とする情報配信方法。
2. 請求項１に記載の情報配信方法において、前記通信網には、
   前記第１の端末は、前記情報配信サーバの前記一以上のその他のプレゼンティティに対して、送信元を第１の識別子に設定して所定のコンテンツデータを送信し、
   前記情報配信サーバは、当該送信されたコンテンツデータを登録し、
   前記プレゼンスサーバより取得した前記第２のユーザのプレゼンス情報が、該登録されたコンテンツデータの配信条件に一致した場合は、当該コンテンツの配信元を前記その他の識別子として、前記第２のユーザに当該コンテンツを配信することを特徴とする情報配信方法。
3. 請求項１に記載の情報配信方法において、
   前記一以上のその他のプレゼンティティを、コンテンツデータ配信のためのチャネルとして、前記通信網に接続する他の端末ユーザに開示することを特徴とする情報配信方法。
4. 請求項３に記載の情報配信方法において、
   前記通信網に前記チャネルを検索するためのチャネル検索サーバが接続されたことを特徴とする情報配信方法。
5. 請求項４に記載の情報配信方法において、
   前記チャネル検索サーバは、前記一以上のその他のプレゼンティティに対応する識別子と、前記情報配信サーバが持つ前記一以上のその他のプレゼンティティに属するコンテンツを検索するために必要な情報を保持し、
   該チャネル検索サーバに対し、検索のための情報を含む検索要求を送信することにより、該検索要求に関係するチャネルを検索することを特徴する情報配信方法。

Images