JP4494419B2 - コンテンツサーバ及びコンテンツサービスシステム - Google Patents

Description

本発明はコンテンツサーバ及びコンテンツサービスシステムに関し、特に無線通信エリア内に在圏する携帯端末をトランシーバ（ＰＴＴ；Push to Talk) のように使用できるＰｏＣ (Push to talk over Cellular) サービスを提供するＰｏＣサーバ及びＰｏＣサービスシステムに関するものである。また、さらに本発明はＩＰネットワークを介した音声会議やテレビ会議等の会議サービスを提供する会議サーバ及び会議システムに関するものである。

近年における携帯電話機の普及により、従来の１対１音声通話サービスに加えて画像や動画等を転送する高速データ通信等の新たなサービスに対する要求が増大してきている。３ＧＰＰ (the 3^th Generation Partnership Project) が基本仕様を作成するＰｏＣサービスもそのような新たなサービスの１つとして普及が期待されている（非特許文献１参照）。

図１には、ＰｏＣサービスを提供する移動通信システムの一例を示している。ここでは、ＰｏＣ対応端末として、図中の右上に拡大して示すようなＰＴＴボタン付きの携帯電話機を使用する。ＰｏＣ対応端末を用いると、トランシーバのように、ＰＴＴボタンを押下して同一グループ内の複数の相手に話しかけることができ、またＰＴＴボタンを開放して当該相手からの話を聞くことができる。

図１において、ＰｏＣサービスを提供する電気通信事業者は、ＩＰパケット通信リンク無線網から成る事業者ネットワーク２内にＰｏＣサーバ１を設置している。各無線エリア３及び４内に在圏するＰｏＣ対応端末Ａ及びＢを使って参加したいグループの番号（特番）をダイヤルすると、ＰｏＣ対応端末Ａ及びＢは先ずＩＰパケット通信リンク無線網との間の通信リンクを確立し、次にその網を利用してＰｏＣサーバ１のＳＩＰ（Session Initiation Protocol）制御部１１との間でＳＩＰプロトコルによる通信リンクを確立する。

通信リンク確立後、例えばＰｏＣ対応端末ＡのユーザＡがＰＴＴボタンを押下して発言すると、その発信音声がＲＴＰ（Real-time Transport Protocol）パケットに変換されてＰｏＣサーバ１に送信される。ＰｏＣサーバ１は、ＲＴＰブリッジ部１２を介して、受信したＲＴＰパケットをＰｏＣ対応端末Ａと同一グループに属するＰｏＣ対応端末Ｂ及びＣにマルチキャストする。この場合、本例のＰｏＣ対応端末Ｃは、無線通信が可能なエリア外（圏外）に位置するため前記ＲＴＰパケットを受信することができない。

ところで、上述したＰｏＣサーバ及びＰｏＣサービスシステムの仕組みは、ネットワークを介した音声会議システムやテレビ会議システムにも同様に適用できる。この場合には、複数の会議端末がＩＰネットワーク内の会議サーバにアクセスし、会議サーバがある会議端末から送信された音声情報や画像情報を含むＲＴＰパケットを受信すると、それを同一会議に参加する他のユーザの会議端末へマルチキャストする。

３ＧＰＰ ＴＲ ２３．９７９ ｖ0.4.0 (2004−05）

上記の例で示したように、通常のＰｏＣサービスでは、例え一時的であっても圏外にあるＰｏＣ対応端末Ｃのユーザだけが同一グループ内に通報される情報を取得できないという問題があった。このことは、ＰｏＣサービスが本来提供すべき同一グループにおける参加ユーザからの発言情報をリアルタイムで互いに共有できるという利便性とそのサービス品質とを著しく低下させるものであった。

この場合、ＰｏＣサーバ１が同一グループ内に通報すべき音声情報等を蓄積し、ＰｏＣ対応端末Ｃが無線エリアに入った後にその音声情報等を再生して通知することも考えられる。しかしながら、それにはＰｏＣサーバ１に複数ユーザからのデータをその都度蓄積していく大容量記憶装置を用意する必要があり、その結果ＰｏＣサービスの提供コストが上昇するという問題があった。

同様のことが、上記の会議システムにも当てはまる。すなわち、会議中のユーザが一時的でも離席する場合や途中から会議に参加する場合等に、その間にやりとりされる情報を的確に入手できないという問題があった。そのため、個々のユーザ端末に配信されるストリーミング情報を自発的に記録するか、又は会議サーバ側で会議開催期間中のすべてのストリーミング情報を記録しておく必要があった。

しかしながら、前者の場合はユーザ側に煩雑な記録操作を強要し、さらにユーザ側で会議内容を記録すると秘密情報の漏洩等を招く恐れがあることからセキュリティ上好ましくないという問題があった。また、後者の場合には会議サーバ側で会議毎の大きなログエリアを用意しなければならず、特にテレビ会議のように音声・画像データを含むデータ量の大きな情報を記録する場合には会議サービスの提供コストが上昇するという問題があった。

そこで本発明の目的は、上記問題点に鑑み、ＰｏＣサーバや会議サーバ等を含むコンテンツサーバに、複数ユーザからの音声・画像データ等を蓄積再生する手段と、さらに各ユーザの状態管理内容に基づいてその蓄積データの削除／更新等を適宜実行する手段とを設けることで、コンテンツサービスにおける同一グループや会議室内で参加ユーザからの情報が確実に共有され、且つそれを妥当なコストで提供し得るコンテンツサーバ及びコンテンツサービスシステムを提供することにある。

本発明によれば、所定のグループに参加した通信可能状態にある複数ユーザからのメディア情報を前記グループ毎に記録する記録部と、前記参加ユーザの各々の通信可能／通信不可能状態を所定時間毎に検出する検出部と、前記検出部が前記参加ユーザの状態を全て通信可能状態にあることを検出すると、その検出以前に前記記録部に記録されたメディア情報から必要性の有無の確認が行われているものを削除する削除部と、を有するコンテンツサーバが提供される。ここでのコンテンツは、音声、画像、映像、テキスト、プログラムデータ等の種々のメディア情報を含む。

前記削除部は、前記参加ユーザの全てがそのグループに参加しなくなったときに、当該グループからのメディア情報を前記記録部から削除する。この場合、前記削除部は、前記検出部が通信不可能状態になったユーザを検出してその通信不可能状態が所定時間継続したユーザを、前記グループに参加しなくなったものとみなす。また、コンテンツサーバは、前記検出部が通信不可能状態になったユーザが再び通信可能状態になったことを検出すると、前記記録部から当該ユーザの通信不可能状態から再び通信可能状態になるまでの間に記録したメディア情報を抽出する抽出部と、前記抽出部が抽出したメディア情報を前記再び通信可能状態になったユーザにのみ送信する送信部と、を有する。前記検出部は、通信可能状態にあるユーザ自身が設定できる一時的通信不可能状態をさらに検出し、前記一時的通信不可能状態は前記通信不可能状態と同じ処理がなされる。

コンテンツサーバは、さらに前記抽出部が抽出したメディア情報を前記再び通信可能状態になったユーザに提示してその情報取得の選択肢を与え、当該ユーザが選択した情報のみを前記送信部に送信させる選択部、を有し、また前記ユーザに対して付加的なサービス及びその選択枝を提供するウェブ制御部を有する。前記付加的なサービスは、前記ユーザに対する参加グループの選択、記憶したメディア情報の選択送信、又は通信可能／通信不可能状態の通知、を含む。さらに、前記検出部が前記参加ユーザを検出すると、その参加グループの他のユーザに対して当該グループへの参加を要請する参加要請部を有する。コンテンツサーバは、ＰｏＣ蓄積サービス又はテレビ会議サービスを提供する。

また本発明によれば、通信網と、コンテンツサーバと、加入データベースと、所定のグループに属する複数の端末とで構成するコンテンツサービスシステムであって、前記加入データベースは、前記端末のユーザに対するコンテンツサービスへの加入状態を前記グループ毎に管理し、前記コンテンツサーバは、前記端末の通信不可能状態時におけるメディア情報を前記グループ毎に記憶し、当該端末が再び通信可能状態になった時にその通信不可能状態から再び通信可能状態になるまでの間に記録した前記メディア情報を、その端末にのみ送信してから削除するコンテンツサービスシステムが提供される。

前記コンテンツサービスシステムは、さらにウェブサーバを有し、前記ウェブサーバは、そのウェブ制御機能を用いて前記コンテンツサービスに対する付加サービスの提供、その選択枝を前記端末に提供する。前記付加サービスには、参加するグループの選択、記憶したメディア情報の選択送信、又は通信可能／通信不可能状態の通知、が含まれる。

前記コンテンツサービスシステムは、さらにプレゼンスサーバを有し、前記プレゼンスサーバは、前記端末の通信可能／通信不可能状態を管理し、前記コンテンツサーバは、前記プレゼンスサーバからの前記通信可能／通信不可能状態の変更通知、又は前記プレゼンスサーバにした前記通信可能／通信不可能状態の問い合わせに対するその応答情報、に基づいて前記コンテンツサービスを提供する。

前記プレゼンスサーバは、前記端末の各々の通信可能／通信不可能状態を所定時間毎に検出して管理する。また、前記コンテンツサーバは、前記グループに参加した端末を検出すると、前記グループの他の端末にそのグループへの参加を通知する。

本発明によれば、グループユーザの在圏や会議参加ユーザの在席が確認できない等の通信不可能状態において通知すべき情報を一時記憶しておくことで、再度ユーザが在圏／在席状態等の通信可能状態になったときに、ユーザ自身がその情報の必要性の有無を確認し、必要な情報だけを該当ユーザだけに再送信することが可能となる。これにより、ＰｏＣサービスや会議サーバによる同一グループ内での参加ユーザ同士の情報共有が確実に達成される。

また、本発明によれば、各ユーザの無線エリア在圏／圏外や会議室での在席／離席等の通信可能／通信不可能状態の管理状態に基づいて、前記記憶された通知情報の削除／更新が自動的に実行される。そのため、ＰｏＣサーバや会議サーバにおける記憶装置規模の拡大が防止され、サービス品質を維持しながら妥当なサービス運用コストでサービスを提供することが可能となる。本発明は無線ＬＡＮ等における各種のグループサービスにも同様に適用できる。

一例として、ＭＣＵを用いたＴＶ会議システムの場合には、データ量の大きな映像や音声などのすべてのストリーミング情報をＭＣＵにいったん集約し、会議情報を蓄積する会議ログ機能と会議に参加するユーザ状態とを連動させることで、会議に参加していない/できない時間帯の会議ログ情報をセキュリティを維持しながら提供することが可能となる。

ＰｏＣサービスを提供する移動通信システムの一例を示した図である。 本発明の第１の実施例を示した図である。 加入者管理表の一例を示した図である。 グループ状態表の一例を示した図である。 ユーザ状態表の一例を示した図である。 メディアログ管理表の一例を示した図である。 グループ状態遷移の一例を示した図である。 ユーザ状態遷移の一例を示した図である。 圏外検出フローの一例を示した図である。 参加ユーザの全員が在圏する場合のメディアログ削除シーケンスの一例（１）を示した図である。 参加ユーザの全員が在圏する場合のメディアログ削除シーケンスの一例（２）を示した図である。 図２のＰｏＣサーバ１のより具体的な構成例を示した図である。 図７Ａ及び７Ｂのメディアログ削除制御フローの一例（１）を示した図である。 図７Ａ及び７Ｂのメディアログ削除制御フローの一例（２）を示した図である。 圏外ユーザが存在する場合のメディアログ削除シーケンスの一例（１）を示した図である。 圏外ユーザが存在する場合のメディアログ削除シーケンスの一例（２）を示した図である。 図１０のメディアログ削除制御フローの一例を示した図である。 本発明の第２の実施例を示した図である。 ウェブ機能を使ったグループ参加シーケンスの一例を示した図である。 グループ参加時における端末表示画面の一例を示した図である。 ウェブ機能を使った圏外からのグループ参加シーケンスの一例を示した図である。 圏外から圏内に移動する端末の表示画面の一例（１）を示した図である。 圏外から圏内に移動する端末の表示画面の一例（２）を示した図である。 本発明の第３の実施例を示した図である。 プレゼンスサーバ内のユーザ状態表の一例を示した図である。 離席の状態を含む状態遷移図の一例を示した図である。 参加ユーザの全員が在席する場合のメディアログ削除シーケンスの一例（１）を示した図である。 参加ユーザの全員が在席する場合のメディアログ削除シーケンスの一例（２）を示した図である。 図１９のＰｏＣサーバ１のより具体的な構成例を示した図である。 参加ユーザが圏外となった場合のメディアログ削除シーケンスの一例（１）を示した図である。 参加ユーザが圏外となった場合のメディアログ削除シーケンスの一例（２）を示した図である。 参加ユーザが離席した場合のメディアログ削除シーケンスの一例（１）を示した図である。 参加ユーザが離席した場合のメディアログ削除シーケンスの一例（２）を示した図である。 本発明の第４の実施例を示した図である。 グループ管理表の一例を示した図である。 加入者番号対応表の一例を示した図である。 ユーザ参加時に、他のユーザを強制参加させるシーケンスの一例（１）を示した図である。 ユーザ参加時に、他のユーザを強制参加させるシーケンスの一例（２）を示した図である。 参加要請時における端末表示画面の一例を示した図である。 テレビ会議システムの一例を図式的に示した図である。 本発明の第５の実施例を示した図である。 会議室状態表の一例を示した図である。 ユーザ状態表の一例を示した図である。 会議ログ管理表の一例を示した図である。 会議室状態遷移の一例を示した図である。 ユーザ状態遷移の一例を示した図である。 会議参加手順の一例を示した図である。 会議ログの削除制御フローの一例（１）を示した図である。 会議ログの削除制御フローの一例（２）を示した図である。 離席ユーザを検出したときの処理フロー例を示した図である。 再在席ユーザを検出したときの処理フロー例を示した図である。

図２は、本発明によるＰｏＣサーバ及びそれを用いたＰｏＣサービスシステムの第１の実施例を示したものである。
本例では、ＰｏＣサーバ１がＰｏＣユーザ圏外時のメディア情報を記憶（蓄積）し、再び在圏（グループ参加）した時に必要な情報を再生して提供する。その制御のために、ＰｏＣサーバ１はグループ状態表１０１、ユーザ状態表１０２、メディアログ管理表１４１を有しており、また外部のユーザデータベース（ＨＳＳ；Home Subscriber Server）５に加入者管理表５０１を備えている。ユーザは、参加したいＰｏＣサービス又はＰｏＣ蓄積サービスのグループ番号をダイヤルして、所望のグループに参加する。前者のＰｏＣサービスでは同一グループの参加ユーザ間で通常のトランシーバ機能が利用可能となり、また後者のＰｏＣ蓄積サービスではさらに自己の圏外時に蓄積された他の参加ユーザの発言内容も再在圏時に聴取可能となる。

図２において、無線網で構築されたＩＰネットワークの無線エリア３及び４（図１参照）内にあるＰｏＣ対応端末Ａ及びＢは、図１の事業者ネットワークに対応するＩＭＳ (IP Multimedia Subsystem) ２を介してＰｏＣサーバ１のＳＩＰ制御部１１との間で、ＳＩＰプロトコルのＳＩＰメッセージを用いて通信リンクを確立する。

ＲＴＰ制御部１３は、ＰｏＣ対応端末から受信したＲＴＰパケットを、ＲＴＰブリッジ１２を介して同一グループの他のＰｏＣ対応端末にマルチキャストする。メディアログ管理部１４は、データベースにＰｏＣ対応端末から受信したＲＴＰパケットのメディア情報を一次記憶し、その記憶内容をメディアログ管理表１４１で管理する。記憶したメディア情報は、後述する本発明により適宜削除され又は更新される。

ＰｏＣ制御部１０は、ＳＩＰ制御部１１、ＲＴＰ制御部１３、及びメディアログ管理部１４と連携し、圏外制御１０３が上述した管理表５０１、１０１、１０２及び１４１を使って本発明のＰｏＣ蓄積サービスを実施する。また、ユーザデータベース（ＨＳＳ；Home Subscriber Server ）５は、ＩＭＳ２を介してＰｏＣサーバ１と通信リンクを確立し、ＰｏＣサービスやＰｏＣ蓄積サービスの加入ユーザ情報をＰｏＣサーバ１に提供する。なお、ユーザデータベース５をＰｏＣサーバ１内部に構築するようにしてもよい。

図３Ａ〜３Ｄには、上記管理表５０１、１０１、１０２、及び１４１の一例を示しており、また図４〜６にはそれらに関する状態遷移図又は動作フロー図を示している。
図３Ａは、ユーザデータベース５の加入者管理表５０１の一例を示している。ここでは、登録ユーザＡ〜ＥのＰｏＣサービス及びＰｏＣ蓄積サービスの加入状態を管理している。例えば、本例のユーザＡは、ＰＴＴ機能が利用できる通常のＰｏＣサービスと、ユーザＡが圏外に出てから再在圏するまでの間に他の参加ユーザが発信したメディア内容を再生／取得できるＰｏＣ蓄積サービスの双方に加入している。そして、ユーザＡは、グループＩ又はＩＩに参加することで前記サービスを利用することができる。

図３Ｂは、グループ状態表１０１の一例を示している。ＰｏＣ制御部１０は、複数のＰｏＣグループＩ〜IIIの各々をユーザが誰も参加していない状態である初期状態と、誰か１人でも参加している状態であるグループＡｃｔｉｖｅ状態の２状態で管理している。本例は、グループＩに少なくとも１人のユーザが参加しており、グループII及びIIIにはユーザが誰も参加していないことを示している。

図４には、グループ状態の遷移図を示している。
始めはユーザ全員が未参加であるためグループ状態は初期状態にある。誰か１人でもグループに参加すると、グループ状態は初期状態からグループＡｃｔｉｖｅ状態に遷移する。グループＡｃｔｉｖｅ状態時にさらに別のユーザがグループ参加してきても、グループ状態はそのまま変化しない。参加していたユーザ全員がグループを脱退した場合や初期状態に遷移した時にそのグループは初期状態に復帰する。

図３Ｃは、ユーザ状態表１０２の一例を示している。
ユーザ状態表１０２には、ＰｏＣ蓄積サービスに加入（図３Ａ参照）している各ユーザのグループ参加と、その参加後の在圏か圏外かを知るための各状態及び最後に在圏を確認できた時刻とをユーザ状態表１０２に記録する。本例では、ユーザＡは初期、ユーザＢは在圏、ユーザＣは圏外、の各状態にあり、ユーザＢ及びＣについては最後に在圏又は圏外を確認できた時刻が記録されている。

図５にはユーザ状態遷移図を、そして図６には圏外検出フローの一例を示している。この圏外検出処理は圏外制御部１０３が実行する。以下では、図３Ｃを例に、図５及び６を参照してユーザ状態遷移及び圏外検出処理について説明する。

始めは全てのユーザＡ〜ＣがＰｏＣ蓄積サービスに未参加であり、本例ではグループＩの登録ユ−ザＡ〜Ｃを予め初期の状態に設定しておく（図５）。他にも、ユーザ状態表１０２を空欄にしておいて、ユーザ参加時にその参加ユーザを在圏の状態から表１０２に順次追加していくようにしてもよい。次に、ユーザＡ〜Ｃの各々が例えばグループＩの番号にダイヤル発信してグループＩに参加する。これにより、参加したユーザＡ〜Ｃは在圏の状態に遷移し、クループＩはグループＡｃｔｉｖｅ状態に遷移する（図４参照）。

圏外制御部１０３は、グループＡｃｔｉｖｅ状態への遷移を契機に起動され、少なくとも１人の参加ユーザの発言があると、グループ参加員の圏外検出処理を開始する。そのため、ＳＩＰ制御部１１を制御してＳＩＰメッセージであるｒｅＩＮＶＩＴＥメッセージを参加ユーザのＰｏＣ対応端末Ａ〜Ｃの各々に所定周期で送信する。各ＰｏＣ対応端末はそれを受信すると、その応答として２００ＯＫメッセージを返信する。

タイムアウト時間内にＰｏＣ対応端末Ｂから２００ＯＫメッセージを受信したことを確認した場合にはユーザＢを在圏の状態に維持する。一方、本例ではＰｏＣ対応端末Ａ及びＣからの応答がないため、最初のタイムアウトの検出時（初回ｒｅＩＮＶＩＴＥ Ｔ．Ｏ）によってユーザＡ及びＣの状態を圏外に遷移させる（図６のＳ１０１及び１０２）。圏外制御部１０３は、参加ユーザの圏外を確認すると、圏外ユーザ（ユーザＡ及びＣ）が存在することを予め録音してある音声等を用いてグループ員に広報し、ユーザＡ及びＣに対してはそれぞれの圏外タイマ（初回ｒｅＩＮＶＩＴＥ Ｔ．Ｏ後の一定回数のｒｅＩＮＶＩＴＥメッセージ送信時間）を起動する（同Ｓ１０３及び１０４）。

圏外制御部１０３は、その後もユーザＡ及びＣの再在圏を確認するため、ＰｏＣ対応端末Ａ及びＣに対してｒｅＩＮＶＩＴＥメッセージを圏外タイマ時間内で定期的に送信する（同Ｓ１０５）。なお、トンネル内通過時等のように、例えばＰｏＣ対応端末Ｃが一時的に圏外に移動したような場合には、トンネル通過後に受信したｒｅＩＮＶＩＴＥメッセージに対する２００ＯＫメッセージの返信によってユーザＣは再び在圏の状態に遷移（グループ参加）することになる（同Ｓ１０６）。

一方、ユーザＡについては圏外状態が圏外タイマ時間以上継続すると、圏外タイマがタイムアウト（Ｔ．Ｏ）してユーザＡは初期の状態に遷移する（図５）。この場合には、ユーザＡの圏外タイマが停止され且つユーザＡに対するｒｅＩＮＶＩＴＥメッセージの送信も停止される（同Ｓ１０９）。図３Ｃのユーザ状態表１０２には、一例としてこのような圏外検出結果を示している。

図３Ｄは、メディアログ管理表１４１の一例を示している。
ＰｏＣ制御部１０は、音声データ、テキストデータ、画像データ等の種々のメディアデータがＰｏＣ対応端末から発信される毎に、そのグループ名、発信元、発信時刻、及びメディアデータを記録する。その一方で、不要となったメディアデータは、後述する処理によってメディアデータのみが廃棄され、発信元、発信時刻はログとして保存される。

本例では、グループＩの参加ユーザＡ及びＢの発言内容がその発言時刻と伴にメディアログデータベース１４にメディアログ情報として逐次蓄積され、後述する所定の条件下でグループＩの参加ユーザに対する通知が完了又は通知が不要となったデータファイルが順次削除される。これにより、同一グループユーザ同士の情報共有が確実に達成される。また、メディアログデータベース１４の適切な記憶容量サイズ内で、許容し得るサービス品質を維持しながら、妥当なサービス運用コストによるＰｏＣサービスが提供可能となる。これまでの説明を前提に、以下ではより具体的な例を用いて本発明によるメディアログ情報の削除方法を説明する。

図７Ａ及び７Ｂには、参加ユーザの全員が在圏する場合におけるメディアログ削除シーケンスの一例を示している。また、図８にはＰｏＣサーバ１のより具体的な構成例を、そして図９及び１０にはメディアログ削除制御フローの一例を示している。なお、図８では、これまでのＰｏＣ制御部１０の一部を具体的なグループ管理部、ユーザ管理部及びメディアログ管理部として表している。

図７Ａ及び７Ｂにおいて、ユーザＡ〜Ｃの各々は、ＰｏＣ蓄積サービスのグループＩをダイヤルする。これにより、ＰＳリンクが確立され、次にＰｏＣサーバ１に接続して所望のグループＩに参加する（Ｓ０１及び０２）。その際、図８のＳＩＰ制御部１１は、ユーザがグループ参加する時（初回のＩＮＶＩＴＥ受信時）のメッセージに含まれるユーザ状態の変更指示により、ＤＩＡＭＥＴＥＲ制御部１５を介してユーザデータベース５の加入者管理表５０１を参照する。ＤＩＡＭＥＴＥＲ制御部１５は、ＤＩＡＭＥＴＥＲプロトコルを用いて交換網２（図７Ａ）に含まれるユーザデータベース（ＨＳＳ）にアクセスする。

ここでは、前記ＩＮＶＩＴＥメッセージのＦｒｏｍヘッダに含まれるユーザ識別子（ＳＩＰ−ＵＲＩ）に対応する参加ユーザの加入状態を参照することで、ユーザ認証処理を行う。なお、同様の処理でＰｏＣサービスへの新規加入登録が行われる。認証処理が完了すると、ＳＩＰ制御部１１は、次にユーザ管理部に通知してユーザ管理表１０２の参加ユーザの状態を更新（初期→在圏）する。この場合、グループＩには少なくとも１人の参加ユーザが在圏するため、ユーザ管理部は、グループ管理部に通知してグループＩの状態を初期状態からグループＡｃｔｉｖｅ状態に遷移させる。また、ユーザ管理部は、グループに参加しているユーザ全員が脱退または初期状態に遷移した場合、グループ管理部にその旨を通知する。グループ管理部は、これを受けて該当グループをグループＡｃｔｉｖｅ状態から初期状態に遷移させる。

次に、本例ではユーザＣがＰｏＣ対応端末ＣのＰＴＴボタンを押下して発言権を獲得し（Ｓ０４）、続いてユーザＣが発言した内容はＰｏＣ対応端末Ｃ内部でＲＴＰパケットに変換されてＰｏＣサーバ１に送信される。ＲＴＰ制御部１３は、受信したメディア情報をメディアログ管理部に送信し、メディアログ管理部はそれをメディアログデータベース１４に逐次保存（蓄積）すると伴に（Ｓ０５）、発信元のユーザＣとそのグループ、受信時刻、及びログデータファイルの記憶アドレスをメディアログ管理表１４１（図３Ｄ参照）に書き込む。また、ＲＴＰ制御部１３はＲＴＰブリッジ１２を制御して、受信したＲＴＰパケットを同一グループ内の参加ユーザＡ及びＢへマルチキャストする。本例では、ユーザＢによっても同様の処理が繰り返される（Ｓ０６及び０７）。

圏外制御部１０３は、メディアログ管理部から蓄積されたメディアデータの存在を通知されると、それを契機に図３Ｃ、図５及び図６で説明した圏外検出処理（Ｓ０８）を開始する。具体的には、圏外制御部１０３がＳＩＰ制御部１１に指示して、ＳＩＰ制御部１１が各参加ユーザのＰｏＣ対応端末Ａ〜Ｃに対して所定周期のｒｅＩＮＶＩＴＥメッセージを送信する。このｒｅＩＮＶＩＴＥメッセージの送信処理は、グループ管理部からグループＩが初期状態に遷移した旨の通知を受けるまで、ユーザ状態が初期以外の各ＰｏＣ対応端末に対して繰り返し実行される。

本例では、ＳＩＰ制御部１１が、全てのＰｏＣ対応端末Ａ〜Ｃからの２００ＯＫメッセージの応答を確認して（Ｓ０８、Ｓ２０１）、その旨をユーザ管理部と圏外制御部１０３に通知する。これにより、ユーザ管理部は、ユーザ状態表１０２における各ユーザＡ〜Ｃの在圏の状態を維持すると伴に、確認時刻をその応答受信時刻（最終確認時刻）で更新する（Ｓ２０２）。

一方、圏外制御部１０３は、更新されたユーザ状態表１０２の内容と現状のメディアログ管理表１４１の内容とを比較して以下に示すメディア削除処理を実行する。圏外制御部１０３は、ユーザ状態表１０２における各ユーザの最終確認時刻の内で最も古い確認時刻（本例ではユーザＣの確認時刻）とメディアログ管理表１４１の時刻（ファイル書込み時刻）とを比較して、その最も古い確認時刻以前に書き込まれたメディアデータファイルを全て削除（廃棄）するようにメディアログ管理部に要求する。ここでは、全ユーザの在圏確認を条件に、メディアログデータの書き込み時刻のほうがユーザの最終確認時刻よりも古ければ、当該メディアログデータは既に全ユーザに送信されたものとみなしている。メディアログ管理部は、圏外制御部１０３からの要求に従って該当メディアデータファイルを全て削除する（Ｓ２０３及び２０４）。

他にも、グループ管理部からグループＩが初期状態に遷移した旨の通知を受けると、圏外制御部１０３はその取得にリアルタイム性が要求されるメディアログデータの再生送信は不要になったとみなして（Ｓ２０５）、メディアログ管理部に対してメディアログデータベース１４の当該グループＩが保持するメディアログデータを強制的に全て削除（廃棄）するよう要求する。メディアログ管理部は、圏外制御部１０３からの要求に従って全てのメディアデータファイルを削除する（Ｓ２０６）。これにより、メディアログデータベース１４のログエリアには通知に必要なメディアデータのみが記憶される。従って、同一グループユーザ同士の情報共有が確実に達成されると伴に、許容し得るサービス品質及び妥当なサービス運用コストでＰｏＣ蓄積サービスが提供可能となる。

図１１Ａ及び１１Ｂには、圏外ユーザが存在する場合におけるメディアログ削除シーケンスの一例を示している。また、図１２には、図１１Ａ及び１１Ｂにおけるメディアログ情報の削除制御フローの一例を示している。なお、ユーザＡ〜ＣがグループＩに参加するまでのシーケンスは図７ＡのＳ０１〜０３と同様なため図１１Ａの中には示していない。

本例では、先ずユーザＢがＰｏＣ対応端末ＢのＰＴＴボタンを押下して発言権を獲得し（Ｓ２１）、ユーザＢが発言した内容はＰｏＣ対応端末Ｂ内部でＲＴＰパケットに変換されてＰｏＣサーバ１に送信される。ＲＴＰ制御部１３は、受信したメディア情報の内容をメディアログ管理部に送信し、メディアログ管理部はそれをメディアログデータベース１４に蓄積し（Ｓ２２）、さらに発信元のユーザＢとそのグループ、受信時刻、及びログデータファイルの記憶アドレスをメディアログ管理表１４１に書き込む。そして、受信したＲＴＰパケットは、ＲＴＰ制御部１３の制御によりＲＴＰブリッジ１２を経由して同一グループ内の他の参加ユーザＡ及びＣにマルチキャストされる。図７Ａ及び７Ｂの例と異なり、本例では圏外に移動したユーザＡのＰｏＣ対応端末ＡはユーザＢからのＲＴＰパケットを受信できない。

ここでも、圏外制御部１０３がメディアログ管理部から蓄積メディアログデータの存在を通知されると、それを契機に圏外検出処理（Ｓ２３）を開始する。本例では、図６に示す圏外検出フローＳ１０１〜１０４によってユーザＡの圏外が検出され、圏外タイマがタイムアウトするまでユーザ状態表１０２にユーザＡの圏外とその最終確認時刻が書き込まれる。具体的には、ＳＩＰ制御部１１は、ユーザＡに最初に送信したｒｅＩＮＶＩＴＥメッセージに対する応答がなくその応答期間がタイムアウト（初回ｒｅＩＮＶＩＴＥ Ｔ・Ｏ）したことを検出すると、圏外タイマを起動すると伴に、その旨をユーザ管理部と圏外制御部１０３に通知する。

ユーザ管理部は、ＳＩＰ制御１１からの通知を基にユーザ状態を圏外に遷移させる。また、圏外制御部１０３は、ＳＩＰ制御１１からの通知によって参加ユーザの初回ｒｅＩＮＶＩＴＥタイムアウトを認知すると、圏外音声部１６に予め録音してある「ＰｏＣグループに参加していたユーザが圏外状態になったときに再生する音声データ」を、ＲＴＰ制御１３の制御によりＲＴＰブリッジ１２を介して参加ユーザに応報する。圏外ユーザがいる限り、図９及び１０に示した全ユーザＡ〜Ｃの在圏確認を条件とするメディアログ情報の削除シーケンスは実行されない（Ｓ２４）。

本例では、続いて在圏するユーザＣがＰｏＣ対応端末ＣのＰＴＴボタンを押下して発言権を獲得し（Ｓ２５）、ユーザＣの発言内容がメディアログデータベース１４に蓄積される（Ｓ２６）。圏外のユーザＡは、ここでもユーザＣの発言内容を取得できない。

次に、ユーザＡは、その圏外タイマがタイムアウトする前に圏内に移動すると、ユーザＡの圏外中にもＳＩＰ制御部１１から所定周期で送られるｒｅＩＮＶＩＴＥメッセージをＰｏＣ対応端末Ａが受信して２００ＯＫメッセージで応答する（Ｓ２７）。ＳＩＰ制御部１１は、ユーザＡの再在圏を検出（初回ｒｅＩＮＶＩＴＥ Ｔ・Ｏ後のｒｅＩＮＶＩＴＥ応答確認）して、その旨をユーザ状態管理部と圏外制御部１０３に通知する。圏外制御部１０３は、ＳＩＰ制御１１からの通知を受けてユーザＡが再び在圏したことを認知し（Ｓ３０１）、図１２に示す再在圏加入者検出処理を実行する。なお、ユーザ管理部は、ＳＩＰ制御１１からの通知によりユーザＡの状態を在圏に更新するが、それには圏外制御部１０３から通知される後述の抽出データの送信後に行われる（Ｓ３０５）。

圏外制御部１０３は、更新前のユーザ状態表１０２からユーザＡの圏外移動時の最終確認時刻を取得し（Ｓ３０２）、それとメディアログ管理表１４１のメディアログの書き込み時刻と比較して、ユーザＡの最終確認時刻以降に蓄積されたメディアログデータを抽出する（Ｓ３０３）。抽出メディアログデータは、ユーザＡの圏外中に他のユーザＢ及び／又はＣの発言内容が蓄積されたものであるため、圏外制御部１０３はメディアログ管理部に対してユーザＡに抽出データの送信を要求する。メディアログ管理部は送信要求があったデータをＲＴＰ制御部１３に送信し、ＲＴＰブリッジ１２がそれをユーザＡにだけ送信する（Ｓ２８及びＳ３０４）。

その後、ユーザ管理部は、ユーザ状態表１０２をユーザＡの在圏とそれを検出した直近の最終確認時刻とに更新する（Ｓ３０５）。以降の処理内容（Ｓ３０６及び３０７）は、全ユーザＡ〜Ｃの在圏確認を条件とする図８のＳ２０３及び２０４と同様である。従って、ユーザＡの圏外中に蓄積された他のユーザＢ及び／又はＣの発言内容を含めて、最も古い確認時刻以前のメディアデータファイルは全て削除される（Ｓ２９）。これにより、圏外ユーザが存在する場合においても、同一グループユーザ同士の情報共有が確実に達成され、且つ許容し得るサービス品質及び妥当なサービス運用コストによってＰｏＣサービスが提供可能となる。

図１３は、本発明によるＰｏＣサーバ及びそれを用いたＰｏＣサービスシステムの第２の実施例を示したものである。
本例では、図２のＰｏＣサーバ１の構成に新たにウェブ（Ｗｅｂ）制御部１７が追加されている。ウェブ制御部１５は公知のＨＴＴＰ (Hyper Text Transfer Protocol) サーバ機能等により実現されるため、ＰｏＣ対応端末Ａ〜Ｃの側にはブラウザ機能が要求される。このようなＷｅｂ制御機能の導入により、ユーザはＧＵＩ (Graphical User Interface) を使ってＰｏＣ蓄積サービスに容易に参加可能となり、さらに図１１Ｂ及び１２で示したユーザＡが圏外状態から再び在圏状態に戻った時に、圏外中のメディアログデータ再生方法の多様な選択肢をブラウザ上に複数表示させることも可能となる。これにより、ＰｏＣサービスのユーザ側における操作性が向上するのに加えて、ＰｏＣサービスの品質も向上させることができる。

図１４は、ウェブ機能を使ったグループ参加シーケンスの一例を示したものである。また、図１５には、ＰｏＣサービスのグループに参加する際に表示されるＰｏＣ対応端末の表示画面の一例を示している。
図１４ではユーザＡを例に説明する。ＰＳリンク確立後（図７ＡのＳ０１参照）、ＨＴＴＰプロトコルによってＰｏＣ対応端末ＡからＰｏＣサーバ１のウェブ制御部１７へアクセスする。これにより、ＰｏＣ制御部１０はグループ状態表１０１等を参照してユーザＡが参加可能なグループ一覧の情報をウェブ制御部１７へ通知し、ウェブ制御部１７はその情報を、例えばＣ−ＨＴＭＬ ( Compact-Hyper Text Markup Language) 等のＨＴＭＬデータに変換してＰｏＣ対応端末Ａに送信する。ＰｏＣ対応端末Ａはそのブラウザ機能を使って、ユーザＡが参加可能なグループ一覧をディスプレイに表示する。

図１４の例では、ユーザＡが初期の状態においてウェブ操作によって参加可能なグループ一覧がＰｏＣ対応端末Ａ上に表示される。例えば、ユーザＡがその中からグループＩを選択して「決定」をクリックすると、例えばＰｏＣサーバ１側に設けられたＣＧＩ (Common Gateway Interface) やサーブレット機能を介してＰｏＣサービスが開始される。他にも、Ｃ−ＨＴＭＬのＰＨＯＮＥ ＴＯ機能等を使って、グループＩの番号に自動的にダイヤル発信してＰｏＣ／ＰｏＣ蓄積サービスが開始されるようにしてもよい。なお、画面右上のアイコンはＰｏＣ対応端末Ａにおける無線の受信強度を表している。これにより、ユーザＡは、所望のグループＩを選択してそのＰｏＣグループに参加することができる。この処理は、グループの選択にＧＵＩを使用する以外は、前述した第１の実施例と同様であり、ＰｏＣ対応端末ＡとＳＩＰ制御部１１との間でＳＩＰプロトコルを用いて行われる（図７ＡのＳ０２参照）。

図１６は、ウェブ機能を使った圏外からのグループ参加シーケンスの一例を示したものである。また、図１７及び１８は、参加ユーザが圏外から圏内に移動する際に、当該ユーザのＰｏＣ対応端末上に表示される画面の一例を示している。
図１６において、圏外から再びグループ参加したユーザＡのＰｏＣ対応端末Ａは、ＰｏＣサーバ１からｒｅＩＮＶＩＴＥメッセージを受信して２００ＯＫメッセージを返信する（Ｓ３１）。これにより、ＰｏＣ制御部１０内の圏外制御部１０３は、圏外ユーザＡの再在圏状態を検出する。

圏外制御部１０３は、メディアログ管理部に対して蓄積してあるメディアログの確認を要求し、メディアログ管理部からの確認結果に基づいてウェブ制御部１７にログの有無を通知する。ウェブ制御部１７は通知された内容をＨＴＭＬデータに変換してＰｏＣ対応端末Ａに送信する。ＰｏＣ対応端末Ａはそのブラウザ機能を使ってログ有無の通知内容をディスプレイに表示する。

図１７にはユーザＡが圏外中に他の参加ユーザからの発言が無かった場合の表示画面の一例を、そして図１８にはユーザＡが圏外中に複数の参加ユーザから発言が有った場合の表示画面の一例を示している。図１８の場合には、他の参加ユーザの発言内容を取得するか否かの選択肢がユーザＡに与えられる。ユーザＡは、発言内容が取得要の場合にはその発言番号を選択して「取得」をクリックし、反対に取得不要の場合にはその発言番号を選択して「消去」をクリックする。

図１６に戻って、この選択指示内容は、ＨＴＴＰプロトコルでウェブ制御部１５に通知され、ＰｏＣ制御部１０のメディアログ管理部がその指示に従って取得要のメディアデータを再生等してＲＴＰ制御部１３に送信する。ＲＴＰ制御部１３はＲＴＰブリッジ１２を制御してＰｏＣ対応端末Ａにだけそのメディアデータを送信する。一方、取得不要のメディアデータはメディアログ管理部がメディアログデータベース１４から削除する。このように、ウェブ機能を用いるとユーザが種々の選択肢を利用できるようになるため、品質の高いきめ細かなＰｏＣサービスが提供可能となる。

図１９は、本発明によるＰｏＣサーバ及びそれを用いたＰｏＣサービスシステムの第３の実施例を示したものである。
本例では、図２のＰｏＣサーバ１の構成に新たにプレゼンスサーバ７が追加され、さらにＰｏＣサーバ１内にはプレゼンスサーバ連携部１８が追加されている。また、図２のＰｏＣ制御部１０にあったグループ状態表１０１及びユーザ状態表１０２がプレゼンスサーバ７内にグループ状態表７０１及びユーザ状態表７０２として移管されている。

本例によれば、ＰｏＣサーバ１とは別にプレゼンスサーバ７を用意し、グループ状態及びユーザ状態をプレゼンスサーバ７側で一括管理することで、参加ユーザの離席／在席確認を同サーバで行う。プレゼンスサーバ７は、ＰｏＣサーバ１からの問合せにより又は自立的に、現在のユーザ状態又はその状態変化をＰｏＣサーバ１に通知する。ＰｏＣサーバ１とプレゼンスサーバ７とのこのような連携によって、ＰｏＣサービスの提供において適切な機能分散・負荷分散が達成される。これにより、ＰｏＣサーバ１は、本来のＰｏＣ／ＰｏＣ蓄積サービスに専念でき、参加ユーザが増大しても高品質なサービスの提供が可能となる。

図２０にはプレゼンスサーバ７内に設けられたユーザ状態表７０２の一例を示しており、図３Ｃのユーザ状態表１０２と比較すると「離席」の状態が新たに追加されている。また、図２１には前記離席の状態を含む状態遷移図を示している。図２１に示すように、プレゼンスサーバ７が管理するユーザ状態（プレゼンス）は、ユーザがグループに参加していな「初期」の状態（オフライン）、グループに参加している「在圏」の状態（オンライン）、グループに参加しているが無線エリア圏外にある「圏外」の状態、グループに参加しているが会話を聞くことのできない「離席」の状態の４状態で管理される。また、このようなユーザ状態における在圏確認はプレゼンスサーバ７が行う。

ここでは、本例の状態遷移について先に説明した図５の状態遷移との相違点だけを説明する。先ず、初期、在圏、及び圏外の各状態間の遷移については図５と同じである。ただし、本例ではＰｏＣサーバ１の負荷軽減のために、プレゼンスサーバ７の主導により定期的に全ユーザの在圏確認（ヘルスチェック）を行って圏外検出をＰｏＣサーバ１に通知するようにもできる。また、本例における離席の状態は、各ユーザが在圏の状態にあることを条件に、ユーザ自らの意思で自由にプレゼンスを変更できるようにしたものである。例えば、他の参加ユーザの発言を聞くことが出来ない事情が発生したような場合には、自らを離席の状態に変更し、その後に在圏の状態に復帰させることができる。

離席の状態から在圏の状態に遷移する場合、圏外からのグループ参加と同様にその後で離席中の発言内容を取得することができる。ユーザプレゼンスの変更（離席／在席）は、在圏するユーザ自らがＰｏＣサーバ１を介してプレゼンスサーバ７に通知する。なお、離席の状態から圏外又は初期の各状態への遷移する場合は、前述した在圏の状態から圏外や初期の各状態への遷移と同様の処理で実行される（図６参照）。

図２２Ａ及び２２Ｂは、参加ユーザの全員が在席する場合のメディアログ削除シーケンスの一例を示している。また、図２３には本例におけるＰｏＣサーバ１のより具体的な構成例を示している。図２３に示す各ブロック間の詳細な動作は、本例で追加されたプレゼンスサーバ７及びプレゼンスサーバ連携部１８を除いて、先に図８を用いて説明したのと同様であり、それらについては再度説明しない。

図２２Ａにおいて、ユーザＡ〜Ｃがパケット交換網２との間にＰＳリンクを確立してＰｏＣグループに参加するまでの処理（Ｓ４１及び４２）は、プレゼンスサーバの存在しない場合の処理（図７ＡのＳ０１及び０２）と同様である。但し、本例では参加ユーザからのプレセンスの変更要求（在圏）がプレゼンスサーバ連携部１８を介してＰｏＣサーバ１からプレゼンスサーバ７へ通知される（Ｓ４３）。プレゼンスサーバ連携部１８は、ＰｏＣサーバ１との連携のために、ＳＩＭＰＬＥ (SIP for Instant Messaging and Presence Leveraging Extensions) プロトコルを用いる。プレゼンスサーバ７は、そのグループ状態表７０１及びユーザ状態表７０２を使ってユーザの在圏／離席の状態管理を行う。

次に、本例ではユーザＣがＰｏＣ対応端末ＣのＰＴＴボタンを押下して発言権を獲得し（Ｓ４４）、ユーザＣが発言した内容はＰｏＣ対応端末Ｃ内部でＲＴＰパケットに変換されてＰｏＣサーバ１に送信される。ＲＴＰ制御部１３は、受信したメディア情報の内容をメディアログ管理部に送信し、メディアログ管理部がそれをデータベース１４に蓄積し（Ｓ４５）、併せて発信元のユーザＣとそのグループ、受信時刻、及び蓄積されたログデータファイルの記憶アドレスをメディアログ管理表１４１に書き込む。ＲＴＰ制御部１３は、また受信したＲＴＰパケットをブリッジ１２経由で同一グループ内の全ての参加ユーザＡ及びＢへマルチキャスする。

本例のプレゼンスサーバ７は、定期的にユーザの在圏確認を行って図１９に示すユーザ状態表７０２（図１９）を更新する（Ｓ４６）。具体的には、プレゼンスサーバ７がプレゼンスサーバ連携部１８を介してＳＩＰ制御部１１にｒｅＩＮＶＩＴＥメッセージの送信要求を行う。ＳＩＰ制御部１１は、その送信要求を受けて各参加ユーザに対してｒｅＩＮＶＩＴＥメッセージを定期的に送信し、その応答確認内容をプレゼンスサーバ連携部１８経由でプレゼンスサーバ７に通知する。なお、別のユーザ在圏確認の仕方としては、プレゼンスサーバ７が、ＰＩＮＧコマンド等を各ユーザ端末へ定期的に送信して在圏を確認するようにしてもよい。この場合、プレゼンスサーバ７だけでユーザの在圏確認が可能となり、ＰｏＣサーバ１の負荷が一層軽減される。

圏外制御部１０３は、メディアログ管理部から蓄積メディアデータの存在を通知されると、それを契機にプレゼンスサーバ連携部１８を経由して定期的にユーザ状態をプレゼンスサーバ７に問い合わせる（Ｓ４７）。圏外制御部１０３は、ここではＳＩＰ制御部１１の制御を行わない。問い合せの結果、全ユーザが在圏中の場合には、メディアログ管理部に対して該当するメディアログの削除要求を行う。メディアログ管理部は、要求されたメディアログを削除する（Ｓ４８）。第１の実施例（図７Ａ〜１０）と同様に、メディアログデータベース１４から在圏する全ユーザの最も古い確認時刻以前のログデータファイルが全て削除され、また全ユーザが初期の状態になったときには、ログデータファイルが強制的に全て削除される。

図２４Ａ及び２４Ｂは、参加ユーザが圏外となった場合のメディアログ削除シーケンスの一例を示している。なお、ユーザＡ〜ＣがグループＩに参加するまでのシーケンスは図２２ＡのＳ４１〜４３と同様であり、図２４Ａの中にはそれらを示していない。また、図２３に示す各ブロック間の詳細な動作は、プレゼンスサーバ７及びプレゼンスサーバ連携部１８を除いて、先に図８を用いて説明したのと同様であり、それらについては再度説明しない。

本例は、プレゼンスサーバ７の主導によるユーザの在圏確認の際中に、ＳＩＰ制御部１１がユーザＡに送信した初回のｒｅＩＮＶＩＴＥタイムアウトにより、それを検出したＳＩＰ制御部１１がプレゼンスサーバ連携部１８を介してプレゼンスサーバ７にその旨を通知したところから始まる（Ｓ５１）。この場合、プレゼンスサーバ７はユーザ状態表７０１のユーザＡを圏外に設定すると伴に、プレゼンスサーバ連携部１８を介して圏外制御部１０３にユーザＡの再在圏確認を指示する。圏外制御部１０３は、その指示を受けるとＳＩＰ制御部１１に再在圏確認処理を開始させる（Ｓ５２）。本例では、再在圏確認中にユーザＢからの発言があって、ＰｏＣサーバ１はその発言内容を蓄積する（Ｓ５３及び５４）。

これにより、圏外制御部１０３は、メディアログ管理部から蓄積したメディアデータの存在を通知され、それを契機にプレゼンスサーバ連携部１８を経由してユーザ状態をプレゼンスサーバ７に定期的に問い合わせる。圏外制御部１０３は、ここではユーザＡが圏外のためメディアログ管理部にメディアログの削除を要求しない（Ｓ５５及び５６）。

ＳＩＰ制御部１１は、圏外タイマがタイムアウトする前に圏内に移動したユーザＡからの２００ＯＫメッセージを受信すると、プレゼンスサーバ連携部１８を経由してその旨をプレゼンスサーバ７に通知する。この通知を受けたプレゼンスサーバ７は、ユーザ状態表のユーザＡを更新してから、プレゼンスサーバ連携部１８を経由して圏外制御部１０３にユーザＡの再在圏を通知する（Ｓ５７）。なお、ユーザが圏外の状態から在圏の状態に遷移したとき又は後の図２５Ａ及び２５Ｂに示すユーザが離席の状態から在圏（在席を含む）の状態に遷移したときにだけ、プレゼンスサーバ７からユーザの在圏状態と図１２に示す再在圏時の処理に必要な最終確認時刻が通知される。

圏外制御部１０３は、メディアログ管理表１４１上のメディアログの時刻を基にユーザＡの圏外検出時における最終確認時刻から現在に至るまでのメディアログを抽出して、抽出されたメディアログデータの再生をメディアログ管理部に指示する。メディアログ管理部は再生したデータをＲＴＰ制御１３に送信し、ＲＴＰ制御１３はＲＴＰブリッジ１２を介してその再生データをユーザＡにだけ送信する。メディアログ管理部は、送信したメディアログデータをメディアログデータベース１４から削除する（Ｓ５８及び５９）。

なお、再生データの送信には、前述した第２の実施例のウェブ機能と組み合わせて、ユーザＡが受信したいメディアデータだけを選択できるようにしてもよい。また、本例ではＰｏＣサーバ１の側で再在圏検出処理を実行するが、プレセンスサーバ７に例えばＰＩＮＧコマンド等を各ユーザ端末へ定期的に送信する機能や圏外タイマ等を持たせることで、プレセンスサーバ７の側だけで再在圏検出処理を実行できるようにしてもよい。これにより、ＰｏＣサーバ１の負荷が軽減される。

図２５Ａ及び２５Ｂは、参加ユーザが離席／在席した場合のメディアログ削除シーケンスの一例を示している。本例においても、ユーザＡ〜ＣがグループＩに参加するまでのシーケンスは図２２ＡのＳ４１〜４３と同様であり、図２３に示す各ブロック間の詳細な動作は、プレゼンスサーバ７及びプレゼンスサーバ連携部１８を除いて、先に図８を用いて説明したものと同様である。

本例では在圏するユーザＡが、例えばＰｏＣ対応端末Ａに設けられた離席ボタンを押下するか、又は端末画面に表示された離席ボタンをクリックする等によって、ＰｏＣサーバ１を介してプレゼンスサーバ７へユーザＡのプレゼンスの変更（離席）が通知される（Ｓ６１）。これにより、プレゼンスサーバ７はユーザ状態表７０２のユーザＡを離席に設定する。なお、プレゼンスの変更（離席／在席）については特に規定がなく、例えばＳＩＰメッセージに含まれるパラメータの変更等、を用いることができる。本例では、その後にユーザＢの発言があり、その発言内容はメディアログデータベース１４に蓄積される（Ｓ６２〜６３）。この場合、離席中のユーザＡは、ＰｏＣサーバ１から送信されるＲＴＰパケットを受信できない。

ＰｏＣサーバ１の圏外制御部１０３は、メディアデータファイルの存在によって起動され、プレゼンスサーバ連携部１８を経由してプレゼンスサーバ７にユーザ状態の確認を要求する。本例ではプレゼンスサーバ７からユーザＡの離席が通知される（Ｓ６４）。離席の状態は圏外の状態と同様に処理されるため、メディアログデータバース１４に蓄積されたメディアログデータファイルの削除処理は実行されない（Ｓ６５）。離席の状態は全ユーザに対してメディア情報を通知できない点において圏外の状態と同視できるからである。

その後で、前記ユーザＡが、例えばＰｏＣ対応端末Ａに設けられた在席ボタンを押下するか、又は端末画面に表示された在席ボタンをクリックする等によって、ＰｏＣサーバ１を介してプレゼンスサーバ７にユーザＡのプレゼンスの変更（在席）が通知される。これを受けたプレゼンスサーバ７はユーザ状態表７０２のユーザＡを在圏に設定し、その旨及びその確認時刻をプレゼンスサーバ連携部１８を経由してＰｏＣサーバ１の圏外制御部１０３に通知する（Ｓ６５）。圏外制御部１０３は、この通知を受けて再在圏処理（図１２参照）と同じ処理を実行する（Ｓ６６及び６７）。

なお、図中には示されていないが、ユーザＡの離席中も、圏外時と同様に在圏確認処理（ｒｅＩＮＶＩＴＥメッセージの定期的な送信）は行われており、初回のｒｅＩＮＶＩＴＥメッセージに対する応答がタイムアウトすればユーザＡは圏外の状態に遷移する（図２１参照）。本例によれば、ユーザ自身の自由意思で、他の参加ユーザの発言内容を後から取得できるようになる。

図２６は、本発明の第４の実施例を示しており、本例におけるＰｏＣサーバ１の具体的な構成例を示している。図２７Ａ及び２７Ｂには、図２６のグループ管理表と加入者番号対応表の一例を示している。これまでの実施例では、あるユーザがＰｏＣサービス（グループ）に最初に参加すると、他のユーザが同グループに自発的に参加するのを待つ必要があった。このような状況を回避すべく、本例ではある特定ユーザがＰｏＣグループに参加した場合に、同グループの他のユーザに対して参加を要請する。

図２６と前述した図８の各構成を比較すると、図２６のＰｏＣサーバ１には新たにユーザ参加制御部１９とＰＤＰ (Packet Data Protocol) 制御部２０が追加され、また図２６のユーザデータベース５には新たにグループ管理表５０２と加入者番号対応表５０３が追加されているだけである。その他の構成は、図８で説明したものと同様であるためそれらについて更に説明しない。

図２６において、ＰＤＰ制御部２０は、ＰＳ (Packet Switch) を含むコアネットワーク２内のＧＧＳＮ (Gateway GPRS Support Node, GPRS; General Packet Radio Service) 等との間でＰＤＰプロトコルを用いた通信制御を行う。本例ではＰＤＰ制御部２０がＧＧＳＮに対してＰＤＰメッセージで所定ユーザへのパケット着信要求を行い、それを受けたＧＧＳＮがＰＳ等に依頼してコアネットワーク２と該当ユーザとの間にパケットデータ転送用リンクを確立する。

また、ユーザ参加制御部１９は、ユーザ管理部と連携するグループ管理部から参加ユーザの検出及びその参加グループが通知されると、ＤＩＡＭＥＴＥＲ制御部１５を介してユーザデータベース５にアクセスし、ユーザデータベース５のグループ管理表５０２や加入者番号対応表５０３から必要なデータを取得する。ここでは、グループ管理表５０２から当該グループがユーザ強制参加機能を有するか否かの情報を取得し、さらにユーザ強制参加機能を有する場合には加入者番号対応表５０３から同グループの他のユーザを一意に特定する端末ユーザ識別子ＩＭＵＩ (International Mobile User Identity) を取得する。それにより、該当ユーザに対するパケット着信要求を前記ＰＤＰ制御部２０に通知する。

図２７Ａにはグループ管理表５０２の一例を示している。本例では、グループＩだけに強制参加機能が登録されており、グループＩのだれか１人の参加によって同グループ内の他のユーザに対してグループ参加が要請される。図２７Ｂには加入者番号対応表５０３の一例を示している。本例では、端末ユーザ識別子ＩＭＵＩを使って着信ユーザを特定している。それに代えて、着信ユーザの電話番号等を用いることもできる。また、本例では強制参加機能をグループ毎に付与しているが、これを特定ユーザ毎に付与するようにしてもよい。この場合、例えばグループＩの特定ユーザ（グループリーダ等）が参加した場合だけ、同グループの他のユーザに参加を要請することになる。

図２８Ａ及び２８Ｂは、ユーザＡがＰｏＣグループに参加した時に、他のユーザＢ及びＣを強制参加させるシーケンスの一例を示したものである。また、図２９には、参加が要請されたＰｏＣ対応端末Ｂ及びＣの表示画面の一例を示している。ここでは、グループＩに強制参加機能を付与し、ユーザＡ、Ｂ、ＣはグループＩに参加可能なことを前提としている。

図２８Ａにおいて、最初にユーザＡだけがパケット交換網２との間にＰＳリンクを確立してＰｏＣグループＩに参加する（Ｓ７１及び７２）。ＰｏＣサーバ１のユーザ参加制御部１９は、グループ管理部からユーザＡがグループＩに参加したとの通知を受けると、ＤＩＡＭＥＴＥＲ制御部１５を介してユーザデータベースにアクセスし、そのグループ管理表５０２からグループＩが強制参加機能を有する旨の情報（図２７Ａ）、及び加入者番号管理表５０３から同グループの他のユーザＢ及びＣの端末ユーザ識別子ＩＭＵＩ（図２７Ｂ）の情報を取得する。これにより、ユーザ参加制御部１９は、ＰＤＰ制御部２０にユーザＢ及びＣに対するパケット着信要求を指示する（Ｓ７３）。

ＰＤＰ制御部２０は、これを受けてコアネットワーク２のＧＧＳＮ等に対してユーザＢ及びＣの各々に対するパケット着信要求メッセージ（ＰＤＰ ＰＤＵ (Protocol Data Unit) メッセージ）を送出する（Ｓ７４）。図中に示すように、ＰＤＰ ＰＤＵ メッセージの情報要素には、サービス種別 （ＰｏＣ着信）、ＩＭＵＩ、ＰｏＣサーバ１のIPアドレス及びポート番号、そして参加グループＩＤ（グループＩ）等が含まれる。コアネットワーク２内のＰＳは、ＧＧＳＮ等からの依頼によりユーザＢ及びＣの各々に対しするパケットデータ転送用ＰＤＰ Context確立を行う（Ｓ７５）。その際には、前記ＰＤＰ ＰＤＵ メッセージの情報要素のデータ内容がＰｏＣ対応端末Ｂ及びＣにそれぞれ通知される。

この通知を受けたＰｏＣ対応端末Ｂ及びＣは、ＡＰＬ (Application Program Loader) を起動して、本例では図２９に示すブラウザ画面を表示する。ユーザＢ及びＣは、グループＩへの「参加」ボタン又は「辞退」ボタンのいずれかを選択してクリックする。図２９にはユーザＢ及びＣ共にグループＩへ参加する例を示しており、先に図１４及び１５の例で説明したのと同様の処理によってユーザＢ及びＣがグループＩに参加する（Ｓ７６及び７７）。このように、本例によれば他のユーザの自発的な参加を待つことなく、グループユーザの参加を自動的に要請できるようになる。そのため、例えばグループ会議やグループ員に対する重要情報の通達等が簡易に実現され、１対ｎ音声通信を基本とするＰｏＣサービスの一層の有効利用が可能となる。

図３０は、一般的なテレビ会議システムの一例を図式的に示したものである。
本例では、電気通信事業者等がＩＰネットワーク上で提供する多地点双方向テレビ会議システム、例えばパーソナルコンピュータ（以降、「ＰＣ」という）を使って少人数による簡易打合せを行う仮想会議室、の一例を示している。

図３０において、テレビ会議クライアント端末（ＰＣ端末）Ｄ、Ｅ及びＦは、電気通信事業者等がネットワーク内のテレビ会議サーバ８に設けた仮想会議室に対してそれぞれアクセスする。テレビ会議サーバ８上ではテレビ会議用サーバソフトウェアが常時稼動しており、テレビ会議サーバ８はサーバ内部のＭＣＵ（Multi-point Conference Unit）を用いて各クライアント端末（ＰＣ端末）Ｄ、Ｅ及びＦをスター状に結合する。この構成により、通信回線使用効率を高めるとともに一元的な会議室管理を実現している。

一方、クライアント端末Ｄ、Ｅ及びＦは、各々のテレビ会議用クライアントソフトウェアを起動してテレビ会議サーバ８にアクセスする。テレビ会議サーバ８とクライアント端末Ｄ、Ｅ及びＦとの間はＳＩＰプロトコルを用いて通信リンクが確立される。このようなテレビ会議システムでは、会議内容がテレビ会議サーバ８上のＭＣＵを通して各会議参加者へリアルタイムにストリーミング配信される。

図３１は、本発明の第５の実施例を示したものである。
本例は、これまで説明してきた本発明による各種のＰｏＣサービスシステムの仕組みをテレビ会議システムに応用したものである。本例は、ＰｏＣサービスシステムの第３の実施例と同様のシステム構成を有しており、テレビ会議サーバ８はプレゼンスサーバ連携部８６を介してプレゼンスサーバ７と連携する。プレゼンスサーバ７は、会議室状態表７０３及びユーザ状態表７０４を一括管理する。

プレゼンスサーバ７は、テレビ会議サーバ８からの問合せにより又は自立的に、現在のユーザ状態又はその状態変化をテレビ会議サーバ８に通知する。テレビ会議サーバ８とプレゼンスサーバ７との連携によって、テレビ会議サービスの提供における適切な機能分散・負荷分散が達成される。これにより、テレビ会議サーバ８は、本来のサービスに専念でき、参加ユーザが増大しても高品質なサービスの提供が可能となる。

本構成では、前述したようにＭＣＵ８５を用いて各クライアント端末（ＰＣ端末）Ｄ、Ｅ及びＦをスター状に結合し、通信回線使用効率を高めるとともに一元的な会議室管理を実現している。ＭＣＵ８５にはＲＴＰ制御部が含まれる。テレビ会議制御部８０の離席制御部８０１は、ユーザの退室（離席）を認識するとその間の情報を蓄積しておき、再び会議に参加した時に必要に応じて蓄積情報を再生する。

また、ＷＥＢ機能８２を用いれば、会議へ参加を希望するユーザはＷＥＢポータルサイトで会議参加を指定できる。会議参加したユーザは発言や聴取が可能となる。本例のＩＰネットワーク９は、ＰｏＣサービスのように無線ネットワーク３及び４に限定されず、有線ネットワークによる固定接続でもよい。本例では有線固定接続によるＩＰネットワーク９を使用する。他は、図１９の構成と同様である。

図３２Ａ〜３２Ｃには、本例で用いられる状態表やログデータ管理表の一例を示している。
プレゼンスサーバ７内に設けられた会議室状態表７０３は、ＰｏＣサービスのグループ状態表１０１（図３Ｂ）と同様に処理される（後述の図３３参照）。ユーザ状態表７０４については、本例が有線固定接続によるＩＰネットワーク９を使用するため、プレゼンズサーバ７を用いるＰｏＣサービスの実施例で使用するユーザ状態表（図２０）と異なり、「圏外」の状態がない（後述の図３４参照）。

テレビ会議サーバ７内に設けられた会議ログ管理表８３は、ＰｏＣサービスのメディアログ管理表１４１（図３Ｄ）と同様に処理される（後述の図３６〜３９参照）。なお、本例では不特定の者が会議に参加する場合も想定されるため、ＰｏＣサービスの加入者管理表５０１（図３Ａ）は特に設けられていない。なお、会議参加者はユーザデータベース６４を用いて管理される。

図３３には、会議室状態の遷移図を示しており、ＰｏＣサービスの図４と対応する。
ここでも、ＰｏＣサービスと同様に処理され、始めはユーザ全員が未参加であるため会議室状態は初期状態にある。誰か１人でも会議室に参加すると、会議室状態は初期状態から会議室Ａｃｔｉｖｅ状態に遷移する。会議室Ａｃｔｉｖｅ状態時にさらに別のユーザが参加してきても、会議室状態はそのまま変化しない。参加していたユーザ全員が会議室を脱退した場合や初期状態に遷移した時にその会議室は初期状態に復帰する。

図３４には、離席の状態を含むユーザ状態遷移図を示しており、ＰｏＣサービスの図２１と対応する。
図３４において、プレゼンスサーバ７が管理するユーザ状態（プレゼンス）は、ユーザが会議室に参加（入室）していない「初期」の状態（オフライン）、会議室に参加している「在籍」の状態（オンライン）、会議室に参加しているがユーザ自身の判断で退室した「離席−１」の状態、会議室に参加しているが何らかの要因で会議を聴取できない「離席−２」の状態の４状態で管理される。このようなユーザ状態における在席確認は、本例ではプレゼンスサーバ７が行う。

ここでの「離席−１」の状態は、ユーザ自身がＷＥＢ機能８２を使ってＷＥＢポータルサイトに「離席」を指示するような場合をいい、その指示は離席制御８０１に通知されて直ちに「離席」状態となる。一方、「離席−２」の状態は、ユーザが会議に参加しているにも係わらず、ＩＰネットワーク９の回線障害や一時的な輻輳発生等によってプレゼンスサーバ７がユーザを「離席」と検出するような場合をいう。なお、「離席−１」及び「離席−２」のいずれの状態も同じ離席処理が実行されることから、ユーザ状態表７０４では双方とも一つの「離席」状態として管理している。具体的な状態遷移の条件は図２１と同様である。

図３５は、会議参加手順の一例を示している。
本例のユーザはＩＰネットワーク９に固定的に接続されていることから、会議参加時にはＩＮＶＩＴＥメッセージをテレビ会議サーバ８へ送出する（Ｓ８１）。その際には、ＰｏＣサービスの図１４及び１５に示すような手順によってＷＥＢブラウザを利用してもよい。

会議参加後の具体的な処理シーケンスの流れは、ＰｏＣサービスの図７Ａ及び７Ｂ（本例ではユーザ全員が在席する場合に対応）、図１１Ａ及び１１Ｂ（本例では離席ユーザが存在する場合に対応）及び図１６（本例では再在席する場合に対応）等と同様である。これらの詳細については上記図面とその説明によることとし、ここではテレビ会議サービスの動作概要だけを簡単に説明する。

ユーザの離席検出と離席中時間の記録については、１）テレビ会議サーバ８は会議開始時に、すべての会議参加予定者が揃っていない場合に会議の情報（音声および映像を含むストリーミング情報）を記録する。２）会議参加者全員からレスポンスがあると、蓄積された対応情報を削除する。３）テレビ会議サーバ８は該当ユーザが離席になった時間を記憶する。

また、ユーザの在席検出時の再生コントロールについては、１）テレビ会議サーバ８は一度離席したユーザが再度会議に参加してきた場合に、離席中の情報を再生するか問い合わせる。２）離席中の情報が必要な場合には、必要な情報を該当ユーザにのみ再送信する。３）離席中の情報が不要な場合であって、他に蓄積が必要なユーザがいない場合には情報を廃棄する。上述した動作はＰｏＣサービスのものと基本的に変わらない。

次に、本発明のテレビ会議サービスにおける代表的な処理フローについて簡単に説明する。この処理フローもＰｏＣサービスのものと同様であり、その詳細についてはＰｏＣサービスの該当図面とその説明を参考にされたい。
図３６及び３７には、基本的な会議ログの削除制御フローの一例を示しており、ＰｏＣサービスの図９及び１０に対応する。図３６において、会議ログデータは全ユーザの在席が確認できれば順次削除される。具体的には、離席制御部８０１は、会議室Ａｃｔｉｖｅ状態への遷移を契機に起動され、少なくとも１人の参加ユーザの発言があると、グループ参加員の離席検出処理を開始する。

その後、ＳＩＰ制御部８１を制御してＳＩＰメッセージであるｒｅＩＮＶＩＴＥメッセージを参加ユーザ端末Ｄ〜Ｆの各々に所定周期で送信する。各端末はそれを受信すると、応答として２００ＯＫメッセージを返信する。参加ユーザからのｒｅＩＮＶＩＴＥメッセージを受信して全ユーザの在席を確認した時には（Ｓ８０１）、ユーザ状態表７０４に記録されたユーザ毎の最終確認時刻を比較して最も古い（最も以前の）確認時刻よりも前に記録された全ての会議ログ８３を削除する（Ｓ８０２及び８０３）。

図３７では、会議ログデータが存在している場合でも会議室状態が初期状態に遷移すると、ログエリアを有効に利用するために、該当グループが保持していた会議ログデータが存在すればそれらを全て削除する（Ｓ８１１及び８１２）。

図３８及び３９は、離席ユーザ／再在席ユーザを検出したときの処理フロー例を示しており、ＰｏＣサービスの図６及び１２に対応する。
本例では、参加ユーザの一人でも離席ユーザを検出すると会議ログの削除は行わない。離席ユーザ検出後は、会議ログ中のデータファイルは削除せずに随時保存していく。そして、離席ユーザが再度会議室へ入室した後に会議ログ中の必要なデータファイルの削除を行う（図３９参照）。

具体的には、ある端末の無応答により最初のタイムアウトを検出（初回ｒｅＩＮＶＩＴＥ Ｔ．Ｏ）すると、離席制御部８０１がその端末のユーザ状態を離席（図３４の「離席−２」）に遷移させる（Ｓ８２１〜８２３）。離席制御部８０１は、離席ユーザ以外の参加ユーザへその旨を広報し、離席ユーザに対して離席タイマ（初回ｒｅＩＮＶＩＴＥ Ｔ．Ｏ後の一定回数のｒｅＩＮＶＩＴＥメッセージ送信時間）を起動する（Ｓ８２４）。

離席制御部８０１は、その後も離席ユーザに対してｒｅＩＮＶＩＴＥメッセージを離席タイマ時間内で定期的に送信してその再在席を検出する（Ｓ８２５）。離席タイマ時間内の一時的な離席の場合（一時的な輻輳発生等の場合）には離席ユーザを再び在席状態に遷移させ（Ｓ８２７）、タイムアウト後には離席ユーザを初期状態（退室）に遷移させる（Ｓ８２６）。この場合には、離席ユーザの離席タイマが停止され且つ離席ユーザに対するｒｅＩＮＶＩＴＥメッセージの送信も停止される。

図３９では、離席制御部８０１が、離席ユーザの再在席を検出すると（Ｓ８３１）、更新前のユーザ状態表７０４から離席時の最終確認時刻を取得し（Ｓ８３２）、それと会議ログ管理表８３への書き込み時刻とを比較して、離席ユーザの最終確認時刻以降に蓄積された会議ログデータを抽出する（Ｓ８３３）。離席制御部８０１は、会議ログ管理部に抽出データの送信を要求し、送信要求があったデータはＲＴＰ制御部８５から離席ユーザに対してだけ送信される（Ｓ８３４）。

その後は、ユーザ状態表７０４において離席ユーザが「在席」に更新され、併せて在席を検出した直近の最終確認時刻に更新される（Ｓ８３５）。以降の処理内容（Ｓ８３６及び８３７）は、全ユーザの在圏確認を条件とする図３６のＳ８０３及び８０４と同様である。その結果、離席ユーザの離席中に蓄積された他のユーザの発言内容を含めて、最も古い確認時刻以前のメディアデータファイルは全て削除される。

Claims (17)

1. 所定のグループに参加した通信可能状態にある複数ユーザからのメディア情報を前記グループ毎に記録する記録部と、
   前記参加ユーザの各々の通信可能／通信不可能状態を所定時間毎に検出する検出部と、
   前記検出部が前記参加ユーザの全てが通信可能状態にあることを検出すると、その検出以前に前記記録部に記録されたメディア情報を削除する削除部と、を有することを特徴とするコンテンツサーバ。
2. 前記削除部は、前記参加ユーザの全てがそのグループに参加しなくなったときに、当該グループからのメディア情報を前記記録部から削除することを特徴とする、請求項１記載のコンテンツサーバ。
3. 前記削除部は、前記検出部が通信不可能状態となったユーザを検出してその通信不可能状態が所定時間継続したユーザを、前記グループに参加しなくなったものとみなす、請求項２記載のコンテンツサーバ。
4. 前記検出部は、通信不可能状態にあるユーザが再び通信可能状態になったことを検出すると、前記記録部から当該ユーザの通信不可能状態から再び通信可能状態になるまでの間に記録したメディア情報を抽出する抽出部と、
   前記抽出部が抽出したメディア情報を前記再び通信可能状態になったユーザにのみ送信する送信部と、を有することを特徴とする請求項１に記載のコンテンツサーバ。
5. 前記抽出部が抽出したメディア情報を前記再び通信可能状態になったユーザに提示してその情報取得の選択肢を与え、当該ユーザが選択した情報のみを前記送信部に送信させる選択部、を有することを特徴とする請求項４記載のコンテンツサーバ。
6. 前記検出部は、通信可能状態にあるユーザ自身が設定できる一時的通信不可能状態をさらに検出し、前記一時的通信不可能状態は前記通信不可能状態と同じ処理がなされることを特徴とする請求項１記載のコンテンツサーバ。
7. さらに、前記ユーザに対して付加的なサービス及びその選択肢を提供するウェブ制御部を有することを特徴とする請求項１に記載のコンテンツサーバ。
8. 前記付加的なサービスは、前記ユーザに対する参加グループの選択、記憶したメディア情報の選択送信、又は通信可能／通信不可能状態の通知、を含むことを特徴する請求項７記載のコンテンツサーバ。
9. さらに、前記検出部は、前記参加ユーザを検出すると、その参加グループの他のユーザに対して当該グループへの参加を要請する参加要請部を有することを特徴とする請求項１記載のコンテンツサーバ。
10. ＰｏＣ蓄積サービス又はテレビ会議サービスを提供することを特徴とする、請求項１記載のコンテンツサーバ。
11. 通信網と、コンテンツサーバと、加入データベースと、所定のグループに属する複数の端末とで構成するコンテンツサービスシステムであって、
    前記加入データベースは、前記端末のユーザに対するコンテンツサービスへの加入状態を前記グループ毎に管理し、
    前記コンテンツサーバは、前記端末が通知不可能状態にある時のメディア情報を前記グループ毎に記憶し、当該端末が再び通信可能状態になった時にはその通信不可能状態から再び通信可能状態になるまでの間に記録した前記メディア情報を、他に該メディア情報を必要とするユーザがないとき、前記端末にのみ送信してから削除する、ことを特徴とするコンテンツサービスシステム。
12. さらにウェブサーバを有し、
    前記ウェブサーバは、そのウェブ制御機能を用いて前記コンテンツサービスに対する付加サービスの提供と、その付加サービスの選択肢を前記端末に与えることを特徴とする請求項１１記載のコンテンツサービスシステム。
13. 前記付加サービスは、参加するグループの選択、記憶したメディア情報の選択送信、又は通信可能／通信不可能状態の通知と、その選択肢を含むことを特徴する請求項１２記載のコンテンツサービスシステム。
14. さらにプレゼンスサーバを有し、
    前記プレゼンスサーバは、前記端末の通信可能／通信不可能状態を管理し、
    前記コンテンツサーバは、前記プレゼンスサーバからの前記通信可能／通信不可能状態の変更通知、又は前記プレゼンスサーバにした前記通信可能／通信不可能状態の問い合わせに対するその応答情報、に基づいて前記コンテンツサービスを提供する、ことを特徴する請求項１１のいずれか一つに記載のコンテンツサービスシステム。
15. 前記プレゼンスサーバは、前記端末の各々の通信可能／通信不可能状態を所定時間毎に検出して管理する、ことを特徴する請求項１４記載のコンテンツサービスシステム。
16. 前記コンテンツサーバは、前記グループに参加した端末を検出すると、前記グループの他の端末にそのグループへの参加を通知することを特徴とする請求項１１記載のコンテンツサービスシステム。
17. ＰｏＣ蓄積サービス又はテレビ会議サービスを提供することを特徴とする、請求項１１記載のコンテンツサービスシステム。

Images