(57)【要約】  通信ネットワークにおいてサービスユーザに契約者サービスを提供するシステムおよび方法を提供する。ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）通信ネットワークにおいて、会議主催者と他の複数の会議参加者との間で電話会議を設定することができる。呼設定と呼制御のためにＳＩＰ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）制御シグナリングを利用するネットワークにおいて、ＳＩＰ＿ＲＥＧＩＳＴＥＲメッセージは、サービスプロバイダのためにサービス能力情報と、それに加えて任意でトラヒック負荷状況を示すように修正される。ＲＥＧＩＳＴＥＲメッセージは、会議サーバなどの登録サービスプロバイダのためのプレゼンス情報およびサービス能力情報を格納する修正版ＰＩＭ（ｍｏｄｉｆｉｅｄ  Ｐｒｅｓｅｎｃｅ  ａｎｄ  Ｉｎｓｔａｎｔ  Ｍｅｓｓａｇｉｎｇ）サーバに送られる。ＰＩＭサーバは、ネットワーク上に登録されているサービスプロバイダのアイデンティティを、会議参加者などの契約サービスユーザに通知する。ＰＩＭサーバは、最も負荷の軽いサービスプロバイダのアイデンティティをユーザに知らせることによってサービスプロバイダ間のトラヒック負荷を平均化するためにトラヒック負荷情報を利用する。電話会議のために、会議主催者が会議参加者を識別して、会議を開始するための基準を用意した後、会議サーバは、各参加者のサービスＣＳＣＰを識別し、サービス提供される参加者が出席してスタンバイの状態であれば、そのことを会議サーバに通知するように各ＣＳＣＦに要求する。所定人数の参加者が出席してスタンバイの状態であれば、会議サーバは電話会議を開始する。
2005512421.tif 000002
【特許請求の範囲】
【請求項１】
通信ネットワークにおいてサービスユーザに契約者サービスへのアクセスを提供する方法であって、
契約者サービスを契約する複数のサービスユーザをネットワークで登録するステップと、
契約者サービスの提供者である少なくとも一つのサービスプロバイダからネットワークのプレゼンスサーバに登録メッセージを送るステップと、
プレゼンスサーバから複数のサービスユーザにサービスプロバイダのアイデンティティを送るステップと、
を含む方法。
【請求項２】
呼設定および呼制御のためにネットワークにおいてＳＩＰ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）制御シグナリングを採用し、少なくとも一つのサービスプロバイダからネットワークのプレゼンスサーバに登録メッセージを送る前記ステップに、
サービスプロバイダのためのサービス能力情報を含むようにＳＩＰ＿ＲＥＧＩＳＴＥＲメッセージを修正するステップと、
サービスプロバイダからプレゼンスサーバにＳＩＰ＿ＲＥＧＩＳＴＥＲメッセージを送るステップと、
を含む請求項１記載の方法。
【請求項３】
少なくとも一つのサービスプロバイダからネットワークのプレゼンスサーバに登録メッセージを送る、前記ステップに更に、サービスプロバイダのサービス能力あるいはプレゼンス状態が変化したときは、常にサービスプロバイダからプレゼンスサーバに更新ＳＩＰ＿ＲＥＧＩＳＴＥＲメッセージを送るステップを含む請求項２記載の方法。
【請求項４】
サービスプロバイダが更新ＳＩＰ＿ＲＥＧＩＳＴＥＲメッセージをプレゼンスサーバに送るときは、常にサービスプロバイダのサービス能力の変更をサービスユーザに通知するステップを更に含む請求項３記載の方法。
【請求項５】
サービス能力情報に指定サービスタイプが含まれ、サービスプロバイダのためのサービス能力情報をプレゼンスサーバに格納するステップに、
サービスプロバイダとして登録可能なサービスタイプの所定リストをプレゼンスサーバに格納するステップと、
サービスプロバイダの指定サービスタイプを所定リスト上のサービスタイプの１つと照合するステップと、
を含む請求項２記載の方法。
【請求項６】
サービス能力情報に指定サービスタイプが含まれ、更に、
プレゼンスサーバが指定サービスタイプをサポートするか否かを、プレゼンスサーバが判定するステップと、
プレゼンスサーバが指定サービスタイプをサポートしない場合にエラーメッセージをサービスプロバイダに送るステップと、
を含む請求項２記載の方法。
【請求項７】
少なくとも一つのサービスプロバイダからネットワークのプレゼンスサーバに登録メッセージを送る前記ステップが更に、サービスプロバイダで処理中のトラヒック負荷の表示を含むようにＳＩＰ＿ＲＥＧＩＳＴＥＲメッセージを修正するステップを含む請求項２記載の方法。
【請求項８】
プレゼンスサーバから複数のサービスユーザにサービスプロバイダのアイデンティティを送る前に、サービスプロバイダが追加のサービスユーザに対して現在サービス提供可能か否かを判定するために、サービスプロバイダで処理中のトラヒック負荷を解析するステップを更に含む請求項７記載の方法。
【請求項９】
サービスプロバイダが追加のサービスユーザに対して現在サービス提供不可能であると判定されたとき、
存在しているが利用不可能なサービスプロバイダを分別するステップと、
サービスプロバイダのアイデンティティおよびサービスプロバイダが現在利用不可能であることとを、複数のサービスユーザに通知するステップと、
を更に含む請求項８記載の方法。
【請求項１０】
プレゼンスサーバから複数のサービスユーザにサービスプロバイダのアイデンティティを送る前に、
サービスプロバイダが契約者サービスを提供する別の登録サービスプロバイダより負荷が軽いか否かを判定するために、サービスプロバイダで処理されるトラヒック負荷を解析するステップと、
サービスプロバイダが他の登録サービスプロバイダより負荷が軽くないと判定されたときに、プレゼンスサーバから複数のサービスユーザに別のサービスプロバイダのアイデンティティを送るステップと、
を更に含む請求項７記載の方法。
【請求項１１】
契約者サービスへのアクセスを提供する方法であって、契約者サービスが会議サービスであり、サービスプロバイダが会議サーバである請求項１記載の方法。
【請求項１２】
契約者サービスがグループ設定サービスであり、サービスプロバイダがグループ主催者である請求項１記載の方法。
【請求項１３】
グループ設定サービスがゲームサービスであり、サービスプロバイダがゲームサーバである請求項１２記載の方法。
【請求項１４】
通信ネットワークにおいて複数のサービスユーザに契約者サービスを提供する複数のサービスプロバイダ間のトラヒック負荷平均化方法であって、
契約者サービスを提供する複数のサービスプロバイダをネットワーク内で登録し、各サービスプロバイダで処理中のトラヒック負荷の表示を含むようにサービスプロバイダからの登録メッセージの修正を含む前記登録ステップと、
最も負荷の軽いサービスプロバイダを求めるためにトラヒック負荷表示を解析するステップと、
最も負荷の軽いサービスプロバイダがネットワーク上に存在することを複数のサービスユーザに通知するステップと、
を含むトラヒック負荷平均化方法。
【請求項１５】
複数のサービスプロバイダを登録する前記ステップに、特定のサービスプロバイダのトラヒック負荷が変化したときは、常にその特定のサービスプロバイダからネットワークに更新登録メッセージを送信するステップを含む請求項１４記載のトラヒック負荷平均化方法。
【請求項１６】
最も負荷の軽いサービスプロバイダを求めるためにトラヒック負荷表示を解析する前記ステップに、いずれかのサービスプロバイダから更新登録メッセージの受信後にトラヒック負荷表示を再解析するステップを含む請求項１５記載のトラヒック負荷平均化方法。
【請求項１７】
複数の利用者に会議サービスを提供するために、通信ネットワーク内で登録されている複数の会議サーバ間のトラヒック負荷平均化方法であって、
第一の要求元ユーザからプレゼンスサーバに会議サービスを要求するために、前記第一の要求元ユーザのアイデンティティと、会議サーバによって接続される第一の集まりと、を含む第一の要求メッセージをネットワークに送るステップと、
プレゼンスサーバによって、複数の会議サーバから最初の１つを前記第一の要求元ユーザに割り当てるステップと、
会議サービスのための第二の要求メッセージをプレゼンスサーバで受信するステップと、
第二の要求メッセージが第一の要求元ユーザからの来信か否かをプレゼンスサーバで判定するステップと、
第二の要求メッセージが第一の要求元ユーザの来信であると判定された時点でプレゼンスサーバから第一の会議サーバに第二の要求メッセージを転送するステップと、
第二の要求メッセージが第二の要求元ユーザからの来信であると判定された時点でプレゼンスサーバによってラウンドロビン方式で第二の会議サーバを第二の要求元ユーザに割り当てるステップと、
を含むトラヒック負荷平均化方法。
【請求項１８】
通信ネットワークにおいてサービスユーザに契約者サービスへのアクセスを提供するシステムであって、
サービスプロバイダのサービス能力情報を含む登録情報をネットワークに送る少なくとも一つのサービスプロバイダと、
登録情報を受信して、登録情報と、サービス情報と、複数のサービスユーザおよびサービスプロバイダに関するプレゼンス情報と、を格納するＰＩＭ（Ｐｒｅｓｅｎｃｅ  ａｎｄ  Ｉｎｓｔａｎｔ  Ｍｅｓｓａｇｉｎｇ）サーバと、
を有するシステムにおいて、
前記ＰＩＭサーバが、
各サービスプロバイダから受信した登録情報に基づいて、サービスプロバイダによって提供されるサービスのタイプを判定する手段と、
サービスプロバイダの登録時にサービスプロバイダのアイデンティティをサービスユーザに通知する通信手段と、
を含むシステム。
【請求項１９】
契約者サービスを契約するサービスユーザと契約者サービスを提供する登録サービスプロバイダとの間の接続を確立するために、ＰＩＭサーバとの通信用接続ノードを、更に有する請求項１８記載のシステム。
【請求項２０】
ネットワークにおいてＳＩＰ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）制御シグナリングを採用し、前記接続ノードがＣＳＣＦ（Ｃａｌｌ  Ｓｔａｔｅ  Ｃｏｎｔｒｏｌ  Ｆｕｎｃｔｉｏｎ）である請求項１９記載のシステム。
【請求項２１】
契約者サービスを契約するサービスユーザと契約者サービスを提供する登録サービスプロバイダとの接続を、関連するＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）ネットワークを利用して確立する請求項１８記載のシステム。
【請求項２２】
会議サーバと、呼制御機能をユーザに提供する少なくとも一つのＳ−ＣＳＣＦ（Ｓｅｒｖｉｎｇ  Ｃａｌｌ  Ｓｔａｔｅ  Ｃｏｎｔｒｏｌ  Ｆｕｎｃｔｉｏｎ）と、を含むＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）通信ネットワークにおいて、会議主催者としての第一のユーザと会議参加者としての他の複数ユーザとの間の電話会議を設定する方法であって、
第一のユーザにサービスする第一のＳ−ＣＳＣＦに、第一のユーザを会議主催者として登録するステップと、
第一のＳ−ＣＳＣＦへの会議参加者を識別するステップと、
各参加者の割り当てられたＳ−ＣＳＣＦを第一のＳ−ＣＳＣＦによって識別するステップと、
参加者側のＳ−ＣＳＣＦによってサービスされる参加者が電話会議を開始するための所定基準を満たしている場合に、そのことを第一のＳ−ＣＳＣＦに通知するように各Ｓ−ＣＳＣＦに求める要求を第一のＳ−ＣＳＣＦから各参加者側のＳ−ＣＳＣＦに送るステップと、
各参加者が所定基準を満たしている場合、そのことを各参加者側のＳ−ＣＳＣＦによって検出するステップと、
参加者側のＳ−ＣＳＣＦによってサービスされる各参加者が所定基準を満たしている場合に、その通知を各参加者側のＳ−ＣＳＣＦから第一のＳ−ＣＳＣＦに送るステップと、
参加者が電話会議を開始するための所定基準を満たしているか否かを第一のＳ−ＣＳＣＦによって判定するステップと、
参加者が所定基準を満たしていると判定された時点で、会議サーバに電話会議の開始を命令するステップと、
を含む電話会議を設定する方法。
【請求項２３】
会議参加者を識別した後に、出席していてスタンバイの状態にある参加者数を考慮した、電話会議を開始するための所定基準を会議主催者から提供するステップを、更に含む請求項２２記載の電話会議を設定する方法。
【請求項２４】
所定基準を提供する前記ステップに、出席してスタンバイの状態にある参加者の下限人数と電話会議への参加を許される参加者の上限人数とを提供するステップが含まれる、請求項２３記載の電話会議を設定する方法。
【請求項２５】
所定基準を提供する前記ステップに、識別された各参加者を必須参加者と任意参加者とに識別するステップを含む請求項２３記載の電話会議を設定する方法。
【請求項２６】
所定基準を提供する前記ステップに、電話会議の開始時刻を知らせるステップを含む請求項２３記載の電話会議を設定する方法。
【請求項２７】
各参加者側のＳ−ＣＳＣＦにＰＩＭ（Ｐｒｅｓｅｎｃｅ  ａｎｄ  Ｉｎｓｔａｎｔ  Ｍｅｓｓａｇｉｎｇ）サーバが含まれ、各参加者が所定基準を満たしたときにそのことを検出する前記ステップに、参加者が出席してスタンバイの状態であるときにそのことを各参加者側のＳ−ＣＳＣＦのＰＩＭサーバで検出するステップを含む請求項２２記載の電話会議を設定する方法。
【請求項２８】
通信ネットワークにおいて呼制御シグナリング用にＳＩＰ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）を採用し、各参加者が出席してスタンバイの状態にあるときにそのことを各参加者側のＣＳＣＦのＰＩＭサーバで検出する前記ステップに、参加者が出席してスタンバイの状態であるときに各参加者からのＳＩＰ＿ＲＥＧＩＳＴＥＲメッセージをＰＩＭサーバで受信するステップを含む請求項２７記載の電話会議を設定する方法。
【請求項２９】
参加者が出席してスタンバイの状態になったときに各参加者からのＳＩＰ＿ＲＥＧＩＳＴＥＲメッセージをＰＩＭサーバで受信する前記ステップに、ＳＩＰ非対応（ｎｏｎ−ＳＩＰ−ｅｎａｂｌｅｄ）通信装置を利用している参加者のためにＰ−ＩＶＲ（Ｐｒｏｇｒａｍｍａｂｌｅ  Ｉｎｔｅｒａｃｔｉｖｅ  Ｖｏｉｃｅ  Ｒｅｓｐｏｎｓｅ）ユニットからＳＩＰ＿ＲＥＧＩＳＴＥＲメッセージを受信するステップを含む請求項２８記載の電話会議を設定する方法。
【請求項３０】
参加者が電話会議を開始するための所定基準を満たしているか否かを判定する前記ステップの後で、
参加者が所定基準を満たしていないと判定された時点で第一のＳ−ＣＳＣＦから主催者にステータスメッセージを送るステップと、
主催者が所定基準を無視するか否かを判定するステップと、
主催者が所定基準を無視すると判定された時点で電話会議を開始するステップと、
を更に含む請求項２２記載の電話会議を設定する方法。
【請求項３１】
電話会議を開始した後で、
ユーザのひとりからのメッセージを会議サーバで受信するステップと、
メッセージが主催者からの来信か、または他の参加者のひとりからの来信かを会議サーバで判定するステップと、
メッセージが主催者からの来信であると判定された時点で、会議サーバから参加者全員にメッセージを転送するステップと、
メッセージが他の参加者のひとりからの来信であると判定された時点で会議サーバから主催者だけにメッセージを転送するステップと、
を更に含む請求項２２記載の電話会議を設定する方法。
【請求項３２】
ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）通信ネットワークにおいて、ユーザに呼制御機能を提供するＳ−ＣＳＣＦ（Ｓｅｒｖｉｎｇ  Ｃａｌｌ  Ｓｔａｔｅ  Ｃｏｎｔｒｏｌ  Ｆｕｎｃｔｉｏｎ）によってサービスされる前記各ユーザのうち、会議主催者としての第一のユーザと会議参加者としての他の複数ユーザとの間の電話会議を設定するためのシステムであって、
会議主催者として第一のユーザを登録し、会議参加者の識別確認を主催者から受け取るための手段と；各参加者の割り当てられたＳ−ＣＳＣＦを識別する手段と；参加者側のＳ−ＣＳＣＦによってサービスされる参加者が電話会議を開始するための所定基準を満たしている場合に、そのことを第一のＳ−ＣＳＣＦに通知するように参加者側のＳ−ＣＳＣＦへ求める要求を各参加者側のＳ−ＣＳＣＦに送り、各参加者側のＳ−ＣＳＣＦから通知を受信するための通信手段と；参加者が電話会議を開始するための所定基準を満たしているか否かを判定するための手段と；参加者が所定基準を満たしていると判定された時点で、電話会議を開始するように会議サーバに命令するための手段と、を含む、第一のユーザにサービスする第一のＳ−ＣＳＣＦと、
第一のＳ−ＣＳＣＦから命令されたときに電話会議を開始し、実行するための会議手段と、
各参加者が所定基準を満たしているか否かを判定するための手段と；参加者側のＳ−ＣＳＣＦによってサービスされる各参加者が所定基準を満たしている場合に、その通知を第一のＳ−ＣＳＣＦに送るための通信手段と、を含む各参加者側のＳ−ＣＳＣＦ内に置かれたＰＩＭ（Ｐｒｅｓｅｎｃｅ  ａｎｄ  Ｉｎｓｔａｎｔ  Ｍｅｓｓａｇｉｎｇ）サーバと、
を有するシステム。
【請求項３３】
ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）通信ネットワークにおいて、会議主催者にサービスすると共に、所定基準が満たされているときに、会議主催者と複数の会議参加者との間の電話会議を開始するように会議サーバに命令する主催者側Ｓ−ＣＳＣＦ（Ｓｅｒｖｉｎｇ  Ｃａｌｌ  Ｓｔａｔｅ  Ｃｏｎｔｒｏｌ  Ｆｕｎｃｔｉｏｎ）であって、
会議主催者を登録すると共に、会議参加者の識別確認を主催者から受け取るための手段と、
各参加者側のＳ−ＣＳＣＦを識別するための手段と、
参加者側のＳ−ＣＳＣＦによってサービスされる参加者が、電話会議を開始するための所定基準を満たしている場合に、そのことを主催者側のＳ−ＣＳＣＦに通知するように参加者側のＳ−ＣＳＣＦへ求める要求を各参加者側のＳ−ＣＳＣＦに送信する通信手段であって、参加者側のＳ−ＣＳＣＦによってサービスされる参加者が所定基準を満たしている場合に、その通知を参加者の各Ｓ−ＣＳＣＦから受信するための通信手段と、
参加者が電話会議を開始するための所定基準を満たしているか否かを判定するための手段と、
参加者が所定基準を満たしていると判定された時点で電話会議を開始、進行させるように会議サーバに命令するための手段と、
を有する主催者側Ｓ−ＣＳＣＦ。
【請求項３４】
会議サーバと、ユーザに呼制御機能を提供する少なくとも１つのＣＳＣＦ（Ｃａｌｌ  Ｓｔａｔｅ  Ｃｏｎｔｒｏｌ  Ｆｕｎｃｔｉｏｎ）とを含むＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）通信ネットワークにおいて、会議主催者としての第一のユーザと会議参加者としての他の複数ユーザとの間の電話会議を設定する方法であって、
第一のユーザを会議主催者として会議サーバに登録するステップと、
会議主催者によって会議参加者を識別するステップと、
会議サーバによって各参加者側のＣＳＣＦを識別するステップと、
ＣＳＣＦによってサービスされる参加者が電話会議を開始するための所定基準を満たしている場合、そのことを会議サーバに通知するようにＣＳＣＦに求める要求を会議サーバから各参加者側のＣＳＣＦに送るステップと、
各参加者が所定基準を満たしている場合、そのことを各参加者側のＣＳＣＦによって検出するステップと、
ＣＳＣＦによってサービスされる各参加者が所定基準を満たしている場合に、その通知を各参加者側のＣＳＣＦから会議サーバに送るステップと、
参加者が電話会議を開始するための所定基準を満たしているか否かを会議サーバで判定するステップと、
参加者が所定基準を満たしていると判定された時点で電話会議を開始するステップと、
を含む電話会議を設定する方法。
【発明の詳細な説明】
【技術分野】
【０００１】
（発明の背景）
（発明の技術分野）
本発明は通信システムに関する。具体的にいえば、本発明は、例えばサービスへのアクセスを提供するシステムと方法や、ＳＩＰ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）を利用する通信ネットワーク内で会議を設定するシステムと方法を意図したものである。
【背景技術】
【０００２】
（関連技術の説明）
ワイヤレス通信ネットワークは第二世代（２Ｇ）回路交換ネットワークから第三世代（３Ｇ）パケット交換ネットワークへと発展している。３Ｇワイヤレスネットワークの参照アーキテクチャは３ＧＰＰ（Ｔｈｉｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ）によって開発途上である。３ＧＰＰネットワークアーキテクチャは、呼設定シグナリング用のＩＥＴＦ（Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ）によって開発されたＳＩＰ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）を使用する。メディアは既存のＩＰネットワークを介して送られる。ＳＩＰ規格については、ＲＦＣ２５４３に記述されており、引用により全体としてここに組み入れられる。
【０００３】
ＳＩＰネットワークにおいて、ユーザはサブネットワーク上に存在する自己をＣＳＣＦ（Ｃａｌｌ  Ｓｔａｔｅ  Ｃｏｎｔｒｏｌ  Ｆｕｎｃｔｉｏｎ）によって登録する。各ユーザは、異なる端末を使用する場合でも使用される固有のＳＩＰ＿ＩＤを持っている。ユーザは、例えばオフィスの机に座っている場合、その机にいるものとして自分を登録することができる。ユーザの固有ＳＩＰ＿ＩＤおよび電話のハードウェアデバイスＩＤを含むＳＩＰ＿ＲＥＧＩＳＴＥＲメッセージが卓上電話からＣＳＣＦに送られるので、ユーザの呼のルーティング先がＣＳＣＦで認識される。ＲＥＧＩＳＴＥＲメッセージはまた、ユーザの現在のステータスを示すプレゼンス状態も含んでいる。例えば、ユーザは、現在自分の席にいるが電話に出られないことを指定することができる。
【０００４】
ＲＥＧＩＳＴＥＲメッセージのプレゼンス状態は、ＣＳＣＦに関わるＰＩＭ（Ｐｒｅｓｅｎｃｅ  ａｎｄ  Ｉｎｓｔａｎｔ  Ｍｅｓｓａｇｉｎｇ）サーバにルーティングされる。ＰＩＭサーバは、ユーザのプレゼンス状態をネットワーク上で他のユーザに提供し、また、ユーザによる他のユーザのプレゼンス状態監視も可能にする。ユーザは、電話を掛ける前に机の上の電話やコンピュータディスプレイなどのディスプレイによって相手のプレゼンス状態（例えば、登録済み、未登録、話中など）を調べることができる。
【０００５】
起点側ユーザは相手ユーザに関わる正確な宛先アドレスを指定する必要はない。特定ユーザの登録済の端末または装置のアイデンティティを自動的に調査し、既存のＩＰネットワークを介して登録済装置との通信を自動的にフォーマットして伝送するために、３ＧＰＰネットワークはそのユーザに関わるエイリアス使用する。したがって、３ＧＰＰネットワークアーキテクチャは集中的独立通信制御機構を提供する。登録ユーザについては、３ＧＰＰネットワークと関連要素により、ユーザの正確な位置とユーザの登録端末のアイデンティティが常に把握され、したがって、その登録ユーザとの通信が既存のＩＰネットワーク上でルーティングされ、確立される。
【０００６】
通信ネットワークにおいて契約者に提供される典型的なサービスは、３人以上の参加者の間で電話会議を設定するための会議サービスである。３ＧＰＰネットワークアーキテクチャにおいて、会議サーバは呼設定中に参加者を召集し、通話が確立すると、メディアのルーティングとミキシングを行う。会議サーバはＣＳＣＦネットワークの内部、外部のいずれでも良いが、サービスを要求するユーザには会議サーバのネットワークＩＤを知らせる必要がある。サーバのＩＤを知らされているクライアントユーザは、電話会議の開始をサーバに要求するメッセージ、例えばＳＩＰ＿ＲＥＦＥＲメッセージをサーバに送ることができる。ユーザＡがユーザＢ、ユーザＣとの電話会議を開始する際、ユーザＡは電話会議への参加者３人を特定する３つのＲＥＦＥＲメッセージを会議サーバに送る。これらＲＥＦＥＲメッセージは、ユーザＡから会議サーバに直接、またはＣＳＣＦネットワークを介して送られる。つぎに、会議サーバはユーザＡ、Ｂ、ＣにＳＩＰ＿ＩＮＶＩＴＥメッセージを送出する。全員が通話に参加したとき、サーバの会議ブリッジがメディアのミキシングを実行する。しかし、このソリューションは、サービスを要求するユーザが会議サーバのネットワークＩＤを知っていなければならない。
【０００７】
しかし、ユーザが特定のサーバにおける常駐サービスの利用を望んでいて、サーバのＩＰアドレスやホスト名を知らない場合には問題がある。例えば、電話会議に関する文脈で、電話会議を開催しようとするユーザは、会議サーバのＩＰアドレスやホスト名などのネットワークＩＤを知らないかもしれない。会議サーバのネットワークＩＤを知らなければ、ユーザは会議サービスにアクセスして電話会議を開催しようとしても、会議サーバと通信することができない。
【０００８】
提案されたソリューションにおいて、ユーザは利用可能な会議サーバを探すためのマルチキャストメッセージをネットワーク経由で送る。しかし、利用可能な会議サーバがまったくない場合や、あったとしても待ち時間が長すぎる場合もあり、これは信頼できるソリューションとはいえない。
【０００９】
したがって、ユーザがサービス提供サーバのネットワークＩＤを知らなくても、通信ネットワークにおけるサービスへのアクセスを提供する方法およびシステムがあれば便利である。また、所定の基準条件が満たされたときに自動的に電話会議を設定するシステムおよび方法があれば便利である。本発明はそのようなシステムおよび方法を提供する。
【発明の開示】
【００１０】
（発明の概要）
本発明は、通信ネットワークにおけるサービスノードが前記特定のサービスタイプとして、またそのサービスタイプに関する前記能力として、自己を一般的に登録するシステムと方法を提供する。そして、このサービス能力情報は、修正版ＰＩＭ（ｍｏｄｉｆｉｅｄ  Ｐｒｅｓｅｎｃｅ  ａｎｄ  Ｉｎｓｔａｎｔ  Ｍｅｓｓａｇｉｎｇ）サーバからサービス契約ユーザに提供される。このように、ユーザはサービス提供サーバのネットワークＩＤを知らない場合でも、サービスにアクセスすることができる。
【００１１】
本発明の一側面は、通信ネットワークにおけるサービスユーザに契約者サービスへのアクセスを提供する方法である。一実施例において、ネットワークは呼設定および呼制御にＳＩＰ制御シグナリングを利用する。この方法では、契約者サービスを契約する複数のサービスユーザがネットワークで登録され、そして、契約者サービスの提供者である少なくとも一つのサービスプロバイダがネットワークで登録される。サービスプロバイダにおけるサービス能力情報はプレゼンスサーバに格納され、プレゼンスサーバは、ネットワークに存在するサービスプロバイダのアイデンティティを複数のサービスユーザに通知する。
【００１２】
発明のもう一つの側面は、通信ネットワークにおけるサービスユーザに契約者サービスへのアクセスを提供するシステムである。一実施例において、ネットワークは呼設定および呼制御にＳＩＰ制御シグナリングを利用する。このシステムは少なくとも一つのサービスプロバイダと修正版ＰＩＭサーバを含んでいる。サービスプロバイダは、サービスプロバイダのサービス能力情報を含むネットワークに登録情報を送る。修正版ＰＩＭサーバは登録情報を受け取り、複数のサービスユーザとサービスプロバイダのために、登録情報、サービス情報、プレゼンス情報を格納する。ＰＩＭサーバは、各サービスプロバイダから得た登録情報に基づいて、サービスプロバイダによる提供サービスの一タイプを決定するための手段を含んでいる。ＰＩＭサーバはまた、サービスプロバイダの登録時にサービスプロバイダのアイデンティティをサービスユーザに通知するための通信手段を含んでいる。
【００１３】
発明のさらに別の側面は、通信ネットワークにおける複数のサービスユーザに契約者サービスを提供する複数サービスプロバイダ間のトラヒック負荷を平均化する方法である。この方法では、契約者サービスを提供する複数のサービスプロバイダがネットワークで登録される。サービスプロバイダからの登録メッセージは、各サービスプロバイダで扱われるトラヒック負荷の表示を含むように変更される。トラヒック負荷表示は最も負荷の軽いサービスプロバイダを求めるために解析され、そして、最も負荷の軽いサービスプロバイダがネットワークに存在することが複数のサービスユーザに通知される。
【００１４】
発明のさらに別の側面は、複数のユーザに会議サービスを提供するために、通信ネットワークで登録される複数の会議サーバ間のトラヒック負荷を平均化する方法である。この方法は、会議サービスのための第一の要求メッセージを第一の要求元ユーザからネットワークのプレゼンスサーバに送ることから開始する。要求メッセージは、第一の要求元ユーザのアイデンティティと、会議サーバによって接続される第一の集まりを含んでいる。プレゼンスサーバは複数の会議サーバから最初の１つを第一の要求元ユーザに割り当てる。プレゼンスサーバは、会議サービスのための第二の要求メッセージを受け取ると、第二の要求メッセージも第一の要求元ユーザからの来信か否かを判定する。ＹＥＳであれば、プレゼンスサーバは第二の要求メッセージを第一の会議サーバに転送する。しかし、第二の要求メッセージが第二の要求元ユーザからの来信であれば、プレゼンスサーバはラウンドロビン方式で第二の会議サーバを第二の要求元ユーザに割り当てる。
【００１５】
発明のさらに別の側面は、会議主催者としての第一のユーザと会議参加者としての複数ユーザとの間のＩＰ通信ネットワークにおいて電話会議を設定する方法である。ＩＰネットワークは、会議サーバと、ユーザに呼制御機能を提供する少なくとも一つのＳ−ＣＳＣＦ（Ｓｅｒｖｉｎｇ  Ｃａｌｌ  Ｓｔａｔｅ  Ｃｏｎｔｒｏｌ  Ｆｕｎｃｔｉｏｎ）を含んでいる。第一のユーザは会議主催者として第一のＳ−ＣＳＣＦに登録され、会議参加者は第一のＳ−ＣＳＣＦとして識別される。第一のＳ−ＣＳＣＦは、各参加者の割り当てられたＳ−ＣＳＣＦを識別し、Ｓ−ＣＳＣＦによってサービスされる参加者が電話会議を開始するための所定基準を満たしている場合に、そのことを第一のＳ−ＣＳＣＦに通知するように各Ｓ−ＣＳＣＦに求める要求を各参加者側のＳ−ＣＳＣＦに送る。次に、各参加者側のＳ−ＣＳＣＦは、各参加者が所定基準を満たしている場合、そのことを検出して、通知を第一のＳ−ＣＳＣＦに送る。第一のＳ−ＣＳＣＦは、参加者が電話会議を開始するために所定基準を満たしているか否かを判定し、ＹＥＳであれば、電話会議を開始するように会議サーバに命令する。
【００１６】
発明のさらに別の側面は、会議主催者としての第一のユーザと会議参加者としての複数のユーザとの間の電話会議を設定するためにＩＰ通信ネットワークに設けられるシステムである。各ユーザは、呼制御機能をユーザに提供するＳ−ＣＳＣＦによってサービスされる。システムは、第一のユーザにサービスする第一のＳ−ＣＳＣＦと、会議サーバと、各参加者側のＳ−ＣＳＣＦ内のＰＩＭサーバを含む。第一のＳ−ＣＳＣＦは、会議主催者として第一のユーザを登録し、会議参加者の識別確認を主催者から受け取るための手段を含む。第一のＳ−ＣＳＣＦはまた、各参加者の割り当てられたＳ−ＣＳＣＦを識別するための手段と、要求メッセージを各参加者側のＳ−ＣＳＣＦに送って各参加者側のＳ−ＣＳＣＦから通知を受け取るための通信手段と、を含んでいる。この要求メッセージは、Ｓ−ＣＳＣＦによってサービスされる参加者が電話会議を開始するための所定基準を満たしている場合、そのことを第一のＳ−ＣＳＣＦに通知するように、参加者側のＳ−ＣＳＣＦに要求する。第一のＳ−ＣＳＣＦは更に、参加者が電話会議を開始するための所定基準を満たしているか否かを判定するための手段と、参加者が所定基準を満たしていると判定された時点で、電話会議を開始するように会議手段に命令するための手段と、を含む。第一のＳ−ＣＳＣＦから命令を受けると、会議手段は電話会議を開始、実行する。各参加者側のＳ−ＣＳＣＦにおけるＰＩＭサーバは、各参加者が所定基準を満たしているか否かを判定するための手段と、Ｓ−ＣＳＣＦによってサービスされる各参加者が所定基準を満たしている場合に第一のＳ−ＣＳＣＦに通知するための通信手段と、を含む。
【００１７】
発明のさらに別の側面は、ＩＰ通信ネットワークにおける会議主催者側のＳ−ＣＳＣＦである。主催者側のＳ−ＣＳＣＦは会議主催者にサービスし、所定基準が満たされているときに会議主催者と複数の会議参加者との間の電話会議を開始させるように会議サーバに命令する。主催者側のＳ−ＣＳＣＦは、会議主催者を登録し、会議参加者の識別確認を主催者から受け取るための手段と、各参加者側のＳ−ＣＳＣＦを識別するための手段と、を含む。主催者側のＳ−ＣＳＣＦは更に、参加者側のＳ−ＣＳＣＦによってサービスされる参加者が電話会議を開始するための所定基準を満たしているときに、そのことを主催者側のＳ−ＣＳＣＦに通知するように参加者側のＳ−ＣＳＣＦに求める要求を各参加者側のＳ−ＣＳＣＦに送ると共に、参加者側のＳ−ＣＳＣＦによってサービスされる参加者が所定条件を満たしているときに、そのことを知らせる通知を各参加者側のＳ−ＣＳＣＦから受けるための手段を含む。主催者側のＳ−ＣＳＣＦは更に、参加者が電話会議を開始するための所定基準を満たしているか否かを判定するための手段と、参加者が所定条件を満たしていると判定された時点で電話会議を開始、実行するように会議サーバに命令するための手段と、を含む。
【００１８】
発明のさらに別の側面は、会議主催者としての第一のユーザと会議参加者としての複数ユーザの間でＩＰ通信ネットワーク上の電話会議を開催する方法である。ＩＰネットワークは、会議サーバと、ユーザのために呼制御機能を提供する少なくとも一つのＣＳＣＦと、を含む。この方法は、会議主催者としての第一のユーザを会議サーバに登録するステップと、会議主催者によって会議参加者を識別するステップと、各参加者側のＣＳＣＦによって会議サーバを識別するステップと、を含む。Ｓ−ＣＳＣＦによってサービスされる参加者が電話会議を開始するための所定基準を満たしている場合、そのことを会議サーバに通知するようにＣＳＣＦに求める要求が会議サーバから各参加者側のＣＳＣＦに送られる。各参加者側のＳ−ＣＳＣＦは、各参加者が所定基準を満たしている場合、そのことを検出して、ＣＳＣＦによってサービスされる各参加者が所定基準を満たしている場合に、そのことを知らせる通知を会議サーバに送る。これに続いて、会議サーバは電話会議を開始するための所定基準を参加者が満たしているか否かを判定し、参加者が所定基準を満たしていると判定された時点で電話会議が開始される。
【００１９】
当業者は本発明に関する数々の目的および特長を本明細書と付図から理解することができる。
【実施例】
【００２０】
（実施例の詳細な説明）
付図において、同一または類似の要素は、それぞれの図の中で同じ参照符号によって表され、また、様々な要素は必ずしも示された通りである必要はない。図１は、典型的な３ＧＰＰネットワークアーキテクチャ１０の一部を示すブロック図である。図示される部分は、端末Ａ１１を使用する起点側ユーザと端末Ｂ１２を利用する終端側ユーザとの間の呼設定に適している。３ＧＰＰアーキテクチャの主要ノードはＣＳＣＦ（Ｃａｌｌ  Ｓｔａｔｅ  Ｃｏｎｔｒｏｌ  Ｆｕｎｃｔｉｏｎ）である。各参加者には、それぞれのＣＳＣＦが対応する。ＣＳＣＦは基本的に、ネットワークへのアクセスを参加者に提供し、参加者間の呼設定シグナリングをルーティングするスイッチである。各ＣＳＣＦはＰ−ＣＳＣＦ（Ｐｒｏｘｙ  ＣＳＣＦ）、Ｉ−ＣＳＣＦ（Ｉｎｔｅｒｒｏｇａｔｉｎｇ  ＣＳＣＦ）、Ｓ−ＣＳＣＦ（Ｓｅｒｖｉｎｇ  ＣＳＣＦ）を含む。
【００２１】
Ｐ−ＣＳＣＦはネットワークに登録するユーザのための第一コンタクトポイントである。端末Ａ１１が登録するとき、起点側のＰ−ＣＳＣＦ１３は、起点側のユーザに関わるホームネットワーク１４を特定し、そのホームネットワークで、認証と確認を実行する。端末Ａが発呼するとき、起点側のＩ−ＣＳＣＦ１５はユーザ情報を得るために端末Ａに関わる起点側のＨＳＳ（Ｈｏｍｅ  Ｓｕｂｓｃｒｉｂｅｒ  Ｓｅｒｖｅｒ）１６に問い合わせる。ＨＳＳは与えられたユーザのためのマスターデータベースであり、実際に呼／セッションを扱っているネットワークエンティティをサポートするために契約関連情報を保有するネットワークエンティティである。ＨＳＳはまた、起点側のユーザのＳ−ＣＳＣＦ１７を特定し、その位置を確認するために使用される。起点側のＳ−ＣＳＣＦはサービスを開始し、契約ユーザが利用可能な特別企画を提供する。起点側のＳ−ＣＳＣＦはまた、ＰＩＭ（Ｐｒｅｓｅｎｃｅ  ａｎｄ  Ｉｎｓｔａｎｔ  Ｍｅｓｓａｇｉｎｇ）サーバ１８を含む。
【００２２】
また、終端側（被呼）ユーザにはホームネットワーク２１が対応する。終端側ホームネットワークは終端側Ｉ−ＣＳＣＦ２２と、終端側ＨＳＳ２３と、ＰＩＭサーバ２５を備えた終端側Ｓ−ＣＳＣＦ２４とを含む。端末Ｂは終端側Ｐ−ＣＳＣＦ２６を介して終端側ホームネットワークに登録する。呼設定が完了すると、ＩＰネットワーク２７を介して２人の参加者間でメディアが交換される。
【００２３】
図２は図１の３ＧＰＰネットワークアーキテクチャにおいてＳＩＰシグナリングを利用する典型的な呼設定シグナリングを示すシグナリング図である。まず、２つの端末がネットワークに登録する。端末Ａ１１はＲＥＧＩＳＴＥＲメッセージ３１を起点側のＰ−ＣＳＣＦ１３に送る。起点側のＰ−ＣＳＣＦは、その特定ユーザに関わるホームネットワーク１４を特定するためにＲＥＧＩＳＴＥＲメッセージの“Ｆｒｏｍ”フィールドで指定されるドメインを使用し、指定されたホームネットワークで認証および確認を実行する。ホームネットワークのＤＮＳ（Ｄｏｍａｉｎ  Ｎａｍｅ  Ｓｅｒｖｅｒ）レコードは起点側のＩ−ＣＳＣＦを指し、ステップ３２において、Ｐ−ＣＳＣＦが起点側のＩ−ＣＳＣＦ１５にＲＥＧＩＳＴＥＲメッセージを送る。ステップ３３において、Ｉ−ＣＳＣＦは起点側ユーザにおける現在のＳ−ＣＳＣＦ１８のアドレスを得るために、その特定の起点側契約者に関わる起点側ＨＳＳ１６に問い合わせる。３４において、情報がキャッシュされている場合、ＨＳＳは起点側Ｉ−ＣＳＣＦに現在の起点側Ｓ−ＣＳＣＦのアドレスを返す。
【００２４】
ステップ３５において、ＲＥＧＩＳＴＥＲメッセージは起点側Ｓ−ＣＳＣＦ１８に転送される。３６において、起点側ユーザが契約しているかまたはアクティブにしているテレフォニー機能（例えば、通話ブロッキング、通話転送、ボイスメール等）を調べるために、起点側Ｓ−ＣＳＣＦはユーザＡのプロフィール情報を求めて起点側ＨＳＳに問い合わせる。ステップ３７において、情報がキャッシュされている場合、ＨＳＳは起点側Ｓ−ＣＳＣＦにプロフィール情報を返す。
【００２５】
同様に、端末Ｂ１２はＲＥＧＩＳＴＥＲメッセージ３８を終端側Ｐ−ＣＳＣＦ２６に送る。終端側Ｐ−ＣＳＣＦは、ＲＥＧＩＳＴＥＲメッセージからそのユーザに関わるホームネットワーク２１を特定し、そのホームネットワークで認証と確認を実行する。３９において、ＲＥＧＩＳＴＥＲメッセージは終端側Ｉ−ＣＳＣＦ２２に転送される。先方契約者が現在登録されている場合、終端側Ｓ−ＣＳＣＦ２４の識別および位置特定を行うために、ステップ４１において終端側Ｉ−ＣＳＣＦは終端側ＨＳＳ２３に問い合わせる。ステップ４２において、情報がキャッシュされている場合、終端側Ｓ−ＣＳＣＦのアドレスは終端側Ｉ−ＣＳＣＦに返される。ステップ４３において、ＲＥＧＩＳＴＥＲメッセージは終端側Ｓ−ＣＳＣＦ２４に転送される。ステップ４４において、終端側ユーザが契約しているかまたはアクティブにしているテレフォニー機能を調べるために、終端側Ｓ−ＣＳＣＦはユーザＢのプロフィール情報を求めて終端側ＨＳＳに問い合わせる。ステップ４５において、情報がキャッシュされている場合、終端側ＨＳＳはプロフィール情報を終端側Ｓ−ＣＳＣＦに返す。
【００２６】
その後、端末Ａ１１は、ＳＩＰ＿ＩＮＶＩＴＥメッセージ４６を起点側Ｐ−ＣＳＣＦ１３に送ることによって端末Ｂへの呼設定を開始する。ＳＩＰ対応（ＳＩＰ  ｅｎａｂｌｅｄ）のマルチメディア通信には、限定的な意味ではないが、ボイス、ビデオ、インスタントメッセージング、プレゼンス、その他多くのデータ通信が含まれる。ステップ４７において、ＩＮＶＩＴＥメッセージは起点側の契約者のホームネットワークに関わる起点側Ｉ−ＣＳＣＦ１５に転送され、そして、４８において、以前に識別されたＳ−ＣＳＣＦ１８にＳＩＰ＿ＩＮＶＩＴＥメッセージが送られる。
【００２７】
起点側Ｓ−ＣＳＣＦ１８はサービスを開始し、端末Ａ１１に利用可能な特別企画を提供する。この特定ユーザがこの特定の呼接続を開始可能であることが確認された時点で、ステップ４９において起点側Ｓ−ＣＳＣＦは、終端側契約者のホームネットワーク２１に関わる終端側Ｉ−ＣＳＣＦ２２にＳＩＰ＿ＩＮＶＩＴＥメッセージを送信する。つぎに、５１において、ＩＮＶＩＴＥメッセージは終端側Ｓ−ＣＳＣＦに転送される。５２において、終端側Ｓ−ＣＳＣＦは終端側ユーザのプロフィールから現在終端側端末Ｂ１２にサービスしているＰ−ＣＳＣＦ２６を特定する。５３において、ＩＮＶＩＴＥメッセージは終端側Ｐ−ＣＳＣＦに転送され、次にステップ５４で端末Ｂに送られる。
【００２８】
５５において、端末Ｂ１２はＳＩＰ＿２００＿ＯＫメッセージで応答する。５６において、終端側Ｐ−ＣＳＣＦ２６は、端末ＢのホームネットワークにおけるＳ−ＣＳＣＦ２４に２００＿ＯＫメッセージを転送し、Ａｃｋ（Ａｃｋｎｏｗｌｅｄｇｍｅｎｔ）５７を端末Ｂに返す。５８において、終端側Ｓ−ＣＳＣＦは、２００＿ＯＫメッセージを終端側Ｉ−ＣＳＣＦ２２に送り、Ａｃｋｎｏｗｌｅｄｇｍｅｎｔ５９を終端側Ｐ−ＣＳＣＦに返す。６１において、終端側Ｉ−ＣＳＣＦ２２は、端末Ａのホームネットワーク１４における起点側Ｓ−ＣＳＣＦ１８に２００＿ＯＫメッセージを送り、終端側Ｓ−ＣＳＣＦにＡｃｋｎｏｗｌｅｄｇｍｅｎｔ６２を返す。
【００２９】
６３において、起点側Ｓ−ＣＳＣＦ１８は、起点側のＩ−ＣＳＣＦ１５に２００＿ＯＫメッセージを転送し、Ａｃｋｎｏｗｌｅｄｇｍｅｎｔ６４を終端側Ｉ−ＣＳＣＦ２２に返す。６５において、起点側のＩ−ＣＳＣＦ１５は、起点側Ｐ−ＣＳＣＦ１３に２００＿ＯＫメッセージを送り、Ａｃｋｎｏｗｌｅｄｇｍｅｎｔ６６を起点側Ｓ−ＣＳＣＦ１８に返す。６７において、起点側Ｐ−ＣＳＣＦ１３は、端末Ａ１１に２００＿ＯＫメッセージを送り、Ａｃｋｎｏｗｌｅｄｇｍｅｎｔ６８を起点側Ｉ−ＣＳＣＦ１５に返す。最後に、６９において、端末ＡはＡｃｋｎｏｗｌｅｄｇｍｅｎｔを起点側Ｐ−ＣＳＣＦ１３に送る。先方端末の特定および確認が完了すれば、既存のＩＰネットワーク２７を介して２つの端末間で直接的にデータ・チャンネル７０が確立され、その他に３ＧＰＰネットワークに要求されるものはない。
【００３０】
図３Ａ、３Ｂは電話会議を開催するときに使用される本発明の方法の第一実施例を示すフローチャートの一部である。本発明は、ネットワーク上のサービスノードが特定のサービスタイプを持ち、その提供するサービスタイプに関するいくつかの能力を持つものとして、それ自体を一般に登録する方法を提供する。図３Ａにおいて、ネットワークおよびＰＩＭサーバに登録したユーザＡはまず、会議サービス等の所望のサービスをステップ７１で契約する。ステップ７２において、会議サーバＢがネットワークおよびＰＩＭサーバに登録する。本発明では、ＲＥＧＩＳＴＥＲメッセージは、登録サーバのサービス能力を含むように変更され、そして、会議の場合には、サーバの現在のトラヒック負荷も含むように変更される。トラヒック負荷が所定のイベントにしたがって変化すると、ステップ７３において会議サーバは新しいＲＥＧＩＳＴＥＲメッセージを送る。
【００３１】
ステップ７４において、ＰＩＭサーバはプレゼンス状態と各登録ユーザのサービス能力を格納する。ＰＩＭサーバは、ユーザとして登録するサービスタイプの所定リストを含む場合がある。それらのサービスタイプを提供するサーバはユーザとしてＰＩＭサーバに登録されるが、ＰＩＭサーバは、実際にはサービスプロバイダであることを認識している。単一サービスを提供するものとして、複数のユーザを登録することが可能である。しかし、ＵＲＩ末尾のＲＥＧＩＳＴＥＲメッセージに例えばｓｅｒｖｉｃｅ＝ｃｏｎｆｅｒｅｎｃｅというパラメータを付加することが望ましい。この表示により、ＰＩＭサーバは、この登録がサービスであることを確実に認識する。例えば、そのタイプのサービス登録を扱うことができないという理由でＰＩＭサーバがそのユーザを構成できない場合には、エラーメッセージが返される。さらに、サービスはあらかじめ規定された特定のリストに制限されないので、より多くのサービスが利用可能になる。
【００３２】
ステップ７５において、ＰＩＭサーバは、ネットワーク上に会議サーバが存在することと、会議サーバのアイデンティティとをユーザＡに通知する。そして、ユーザＡは、電話会議を始める前に会議サーバが利用可能であることを、自己の端末から確認することができる。ステップ７６において、ユーザＡは電話会議を要求し、自己のＳ−ＣＳＣＦへの通話とＰＩＭサーバの参加者と、を識別する。ステップ７７において、ＰＩＭサーバは２つ以上の会議サーバが登録されているか否かをサービスプロバイダのリストで判定する。ＮＯであれば、会議サーバＢが唯一の登録された会議サーバであり、プロセスはステップ８２（図３Ｂ）へ移り、ＰＩＭサーバは会議サーバＢに会議要求をルーティングする。
【００３３】
しかし、２つ以上の会議サーバが登録されていることがステップ７７で判明した場合、プロセスはステップ７８へ移り、ＰＩＭサーバはトラヒック負荷の最も軽い会議サーバを調べる。所定のトリガイベントに起因するトラヒック負荷の変化を報告する更新済みＲＥＧＩＳＴＥＲメッセージが各サーバからＰＩＭサーバに送られるので、ＰＩＭサーバは各サーバのトラヒック負荷を把握している。次に、プロセスはステップ７９（図３Ｂ）に移り、会議サーバＢの負荷が最も軽いか否かを判定する。ＮＯであれば、プロセスはステップ８１へ移り、ＰＩＭサーバは会議要求を負荷の最も軽い別の会議サーバにルーティングする。しかし、会議サーバＢの負荷が最も軽い場合、ステップ８２においてＰＩＭサーバは会議要求を会議サーバＢにルーティングする。
【００３４】
図４は電話会議を開催するとき使用される本発明の方法の第二実施例を示すフローチャートであり、ＰＩＭサーバはラウンドロビン方式で負荷のバランスをとる。この実施例の場合、会議サーバはトラヒック負荷を報告する必要がない。ステップ８６において、複数の会議サーバとユーザはＰＩＭサーバに登録する。サーバが登録するとき、各登録サーバのサービス能力を特定する拡張子がＲＥＧＩＳＴＥＲメッセージに含まれることが望ましい。ステップ８７において、第一のユーザからＰＩＭサーバに電話会議の要求が送られる。この要求は、要求元ユーザと会議参加者のアイデンティティの両方を示すＲＥＦＥＲメッセージによって行われることが望ましい。ステップ８８において、ＰＩＭサーバは会議サーバを第一の要求元ユーザに割り当てる。
【００３５】
同じ会議に参加者全員を集めるためには、要求元ユーザは複数のＲＥＦＥＲメッセージをＰＩＭサーバに送る必要があり、そして、ＰＩＭサーバは同じ会議のためのＲＥＦＥＲメッセージをすべて同じ会議サーバに送る必要がある。したがって、第一のＲＥＦＥＲメッセージが第一の要求元ユーザから届いたとき、ＰＩＭサーバは、どの会議サーバを第一の要求元ユーザに割り当てたかを把握している。８９において、ＰＩＭサーバは電話会議を要求する追加ＲＥＦＥＲメッセージを受け取り、ステップ９０において、追加要求が第一の要求元ユーザからのものか否かを判定する。ＹＥＳであれば、プロセスはステップ１００に移り、ＰＩＭサーバは追加ＲＥＦＥＲメッセージを第一の会議サーバに転送する。例えば、ＰＩＭサーバはそれぞれのＲＥＦＥＲメッセージの“Ｆｒｏｍ”フィールドをチェックして、メッセージが同じ要求元ユーザから来たものであれば、ＰＩＭサーバはメッセージを同じ会議サーバに転送する。しかし、“Ｆｒｏｍ”フィールドが異なる要求元ユーザを示していれば、プロセスはステップ１１０へ移り、ＰＩＭサーバはラウンドロビン方式で次の登録済み会議サーバをそのユーザに割り当てる。
【００３６】
図３Ｂに戻って、ステップ８３において、選択された会議サーバは識別された参加者に電話会議への参加を呼びかける。図５にしたがって後述するように、この呼びかけは、会議サーバから参加者に複数のＳＩＰ＿ＩＮＶＩＴＥメッセージを送ることによって行われる。ステップ８４において、呼びかけられた参加者が電話会議に参加し、ステップ８５において、会議サーバはメディアのミキシングを行い、各参加者にメディアをルーティングする。
【００３７】
図５は、この発明の教義にしたがって電話会議を設定する際に３ＧＰＰネットワークにおけるノード間のメッセージの流れを示すシグナリング図である。簡潔にするため、それぞれのＣＳＣＦの各コンポーネントは単一のＣＳＣＦノードにまとめられている。アドレスｂ．ｘ．ｃｏｍの会議サーバである端末Ｂ９２に対して、アドレスａ．ｘ．ｃｏｍの端末Ａ９１が電話会議を要求する。端末Ａと会議サーバはアドレスｘ．ｃｏｍのＣＳＣＦ−１＿９３に登録されている。端末Ａは、アドレスｃ．ｙ．ｃｏｍの端末Ｃ９４がこの電話会議に参加するように要求する。端末Ｃはアドレスｙ．ｃｏｍのＣＳＣＦ−２＿９５に登録されている。
【００３８】
ステップ９６において、端末Ａ９１は、ＲＥＧＩＳＴＥＲメッセージをＣＳＣＦ−１＿９３とその関連ＰＩＭサーバに送り、自己をｕｓｅｒＡ＠ｘ．ｃｏｍとして識別する。同様に、ステップ９７において、端末Ｃ９４は、ＲＥＧＩＳＴＥＲメッセージをＣＳＣＦ−２＿９５とその関連ＰＩＭサーバに送り、自己をｕｓｅｒＣ＠ｙ．ｃｏｍとして識別する。ステップ９８において、端末Ａは、ＳＵＢＳＣＲＩＢＥメッセージをＣＳＣＦ−１に送り、会議サービスとして必要なサービスを識別する。ＳＵＢＳＣＲＩＢＥメッセージは以下のようにフォーマットされる。
2005512421.tif 000003
【００３９】
ステップ９９において、端末Ｂ９２は、ＲＥＧＩＳＴＥＲメッセージをＣＳＣＦ−１とその関連ＰＩＭサーバに送り、自己をｕｓｅｒＢ＠ｘ．ｃｏｍとして識別する。また、本発明では、登録エンティティによってサポートされるサービス（この場合は会議サーバ）を識別する拡張子をＲＥＧＩＳＴＥＲメッセージに付ける。端末ＢからのＲＥＧＩＳＴＥＲメッセージは以下のようにフォーマットされる。
2005512421.tif 000004
この場合、ＰＩＭサーバはサービスユーザ名の所定リストを維持する必要はない。その代わり、“ｓｅｒｖｉｃｅ＝”パラメータの値が提供サービスのタイプを反映する。このようにすると、サービスユーザに対応するために特に負荷が増えることがないので、サーバの負担は大幅に減少する。
【００４０】
メッセージボディには、記述子ｘｍｌ、あるいはノード能力と現在のトラヒック負荷を記述した他のコードを含めることが可能である。ＰＩＭサーバは、この情報を保持することにより、ユーザからセッションを要求されたときに、その要求を適切なサーバに転送することができる。サービスはＵＲＩの後尾のサービスタグ（例えば、ｓｅｒｖｉｃｅ＝ｃｏｎｆｅｒｅｎｃｅ）で識別される。あるいは、ソースアドレスはｓｅｒｖｉｃｅｎａｍｅ＠ｄｏｍａｉｎ．ｃｏｍ形式のサービスを識別する。会議サーバのプレゼンス状態が所定のイベントに対応して変化したとき、新しいＲＥＧＩＳＴＥＲメッセージを会議サーバからＰＩＭサーバに送ることができる。例えば、電話会議が接続されたとき、更新されたＲＥＧＩＳＴＥＲメッセージを会議サーバから送出して利用可能ポート数を更新することができる。ＰＩＭサーバはこの情報を負荷平均化のために利用する。複数の会議サーバが登録されているとき、ネットワークは、なるべく負荷の軽い会議サーバを最初に選択することによって会議サーバ間の負荷を管理する。ＰＩＭサーバは登録された個々の会議サーバとその現在負荷を把握しているので、ＰＩＭサーバの蓄積情報によって負荷管理が行われる。
【００４１】
また、ＳＩＰ非対応装置からの登録を可能にするために、Ｐ−ＩＶＲ（Ｐｒｏｇｒａｍｍａｂｌｅ  Ｉｎｔｅｒａｃｔｉｖｅ  Ｖｏｉｃｅ  Ｒｅｓｐｏｎｓｅ）ユニットを利用することも可能である。その種の装置にアクセスするユーザはＰ−ＩＶＲにダイヤルし、音声メニューにしたがって選択する。１つの選択方法はＳＩＰネットワークに登録することであり、そのほかに、現在のグループをリストアップして特定のグループへの参加を選択することもできる。
【００４２】
ステップ１０１において、ＰＩＭサーバはｘ．ｃｏｍ（例えば、会議）で利用可能なサービスを端末Ａに通知し、適切な会議サーバ９２のアドレス／ホスト名を知らせる。また、その会議サーバのプレゼンス状態をユーザに報告することもできる。例えば、会議サーバは登録されているが現在ビジーであることをユーザに知らせる。１０２において、端末Ａは会議サービスを要求する。これは、ＣＳＣＦ−１のＰＩＭサーバにＳＩＰを送ることによって要求することが望ましい。端末ＡからのＲＥＦＥＲメッセージは以下のようにフォーマットされる。
2005512421.tif 000005
【００４３】
ＰＩＭサーバは、ＲＥＦＥＲメッセージの“Ｔｏ”フィールドに含まれるｓｅｒｖｉｃｅ＝ｃｏｎｆｅｒｅｎｃｅパラメータを認識し、“Ｔｏ”フィールドのアドレスを会議サーバのアドレスまたはホスト名で置換する。つぎに１０３において、ＰＩＭサーバはメッセージを会議サーバに転送する。ＲＥＦＥＲメッセージは、ＩＮＶＩＴＥメッセージには含まれないＲｅｆｅｒ−ＴｏヘッダおよびＲｅｆｅｒｒｅｄ−Ｂｙヘッダを含む。Ｒｅｆｅｒｒｅｄ−Ｂｙヘッダは電話会議（ｕｓｅｒＡ＠ｘ．ｃｏｍ）を要求する参加者のアイデンティティを識別し、Ｒｅｆｅｒ−Ｔｏヘッダは電話会議（ｕｓｅｒＢ＠ｘ．ｃｏｍ）に接続される参加者のアドレスを識別する。要求されたサービスは、拡張子によって会議サービスとして識別される。
【００４４】
端末Ａから会議サーバに複数のＲＥＦＥＲメッセージを送ることによって、会議サーバは会議参加の招待状を出すための参加者リストを作成することができる。あるいは、会議サーバが第一のＲＥＦＥＲメッセージに応答した後で、その後のすべてのＲＥＦＥＲメッセージを端末Ａから会議サーバに直接送ることもできる。これにより、どのユーザがどのサービスノードに割り当てられているかということを、ＰＩＭサーバが把握する必要がなくなると同時に、要求元ユーザはサービス要求を会議サーバに送り続けることができる。
【００４５】
要求された特定のサービスを提供する複数のユーザが登録されている場合、サービス提供可能と判明しているすべての登録ユーザにＰＩＭサーバからメッセージを送ることができる。このメッセージは、要求されたサービスに応じてＳＩＰ＿ＩＮＶＩＴＥメッセージまたはＳＩＰ＿ＲＥＦＥＲメッセージとなる。会議サービスの場合、ＰＩＭサーバからＩＮＶＩＴＥメッセージを送ることが望ましい。会議サーバからの応答に基づいて、ＰＩＭサーバは利用可能な（そして、望ましくは、最も負荷の軽い）１つの会議サーバを選択し、選択された会議サーバに電話会議用のユーザを接続する。
【００４６】
１０４と１０５において、会議サーバ９２はＣＳＣＦ−１＿９３を介して端末Ａ９１にＩＮＶＩＴＥメッセージを送る。１０６と１０７において、会議サーバはＣＳＣＦ−２＿９５を介して端末Ｃ９４にＩＮＶＩＴＥメッセージを送る。ステップ１０８において、端末Ａは、ＳＩＰ＿２００＿ＯＫメッセージをＣＳＣＦ−１に返すことによってＩＮＶＩＴＥの承諾を表す。ＣＳＣＦ−１はＡｃｋｎｏｗｌｅｄｇｍｅｎｔ１０９に応答し、１１１において、２００＿ＯＫメッセージを会議サーバに転送する。会議サーバはＡｃｋｎｏｗｌｅｄｇｍｅｎｔ１１２に応答する。同様に、ステップ１１３において、端末Ｃは、ＳＩＰ＿２００＿ＯＫメッセージをＣＳＣＦ−２に返すことによってＩＮＶＩＴＥの承諾を表す。ＣＳＣＦ−２はＡｃｋｎｏｗｌｅｄｇｍｅｎｔ１１４に応答し、１１５において、２００＿ＯＫメッセージを会議サーバに転送する。会議サーバはＡｃｋｎｏｗｌｅｄｇｍｅｎｔ１１６に応答する。その後、会議サーバはメディアのミキシングを行い、１１７において端末Ａにメディアを送り、１１８において端末Ｃにメディアをルーティングする。
【００４７】
本発明によれば、ユーザグループとしてサービスの登録が可能である。サービスを要求することによって、ユーザをグループに追加し、ユーザ相互の通信が可能である。例えば、ゲームサーバの主催者はクイズゲームのホストになることができる。例えば、最小２人から最大４人のプレーヤがテキストメッセージを往復させてプレーするクイズゲームの機能を備えたサービスとして主催者を登録することができる。メッセージのセマンティックに関して、サーバは単一ユーザに見えるが、ＰＩＭサーバはこれがグループであることを認識している。プレーヤからグループに送られるものはいずれも、グループの主催者として登録されている人に送られる。主催者からグループに送られるものはすべて、全プレーヤに同報される。したがって、ゲーム続行中、サーバから参加者に質問が送られ、参加者が答えをタイプして“ｅｎｔｅｒ”を押すと、答えは参加者からサーバに送られる。
【００４８】
図６はクイズゲームなどのグループを設定するときに使用される本発明の方法の好ましい実施例のステップを示すフローチャートである。ステップ１２１において、クイズゲームに興味を持つプレーヤがクイズゲームサービスを契約する。ステップ１２２において、ゲーム主催者であるユーザは、グループサービス（例えば、クイズゲームサーバ）としてネットワークとＰＩＭサーバに登録する。ＲＥＧＩＳＴＥＲメッセージは、ゲームが現在利用可能か利用不可能かを示す。主催者はゲーム、開始前に登録しなければならない下限プレーヤ数、ゲームに参加する上限プレーヤ数などの条件を指定する。ステップ１２３において、ＰＩＭサーバは、クイズゲームサービスを契約したプレーヤに、クイズゲームサービスの開催およびその現在ステータスを通知する。ＰＩＭサーバは、登録プレーヤ数とそれらのステータスを監視し、所定人数のプレーヤが登録され、スタンバイの状態のとき、そのことをゲームサーバに通知する。
【００４９】
ゲームサーバは、参加契約通知を受けているので、他のＣＳＣＦにおけるメンバを把握している。ゲームサーバは、プレゼンス状態（オンラインか、オフラインか、ビジーか等）を確認する必要がある場合、プレーヤの状態が変化したときにその通知を得るために、往復契約者メッセージを各プレーヤのホームドメインに送ることができる。プレーヤのＩ−ＣＳＣＦのアドレスは、プレーヤのドメイン名に対して特別なＣＳＣＦ＿ＤＮＳルックアップを実行することによって得られる。プレーヤにサービスするＨＳＳまたはＳ−ＣＳＣＦからのプレーヤ・ステータスはＩ−ＣＳＣＦで確認されるので、プレーヤのホームＩ−ＣＳＣＦのアドレスはすべて、ゲームサーバが必要とする情報である。
【００５０】
あるいは、初期登録手順において、ゲーム開始前にすべての条件が整うのを待たずに、例えば特定のプレーヤによる新規登録など、一定の状態が発生する度にＰＩＭサーバから主催者に通知することができる。そして、以前に識別された状態を無視してサービスを開始するオプションが主催者に与えられる。
【００５１】
１２４において、主催者はゲームを起動し、例えばプレーヤ数、プレーヤ基準またはＩＤ、メディアタイプなどを識別するための更新ＲＥＧＩＳＴＥＲメッセージを送る。ステップ１２５において、クイズゲームサービスの新しいステータスとゲームをするための基準が、参加見込みプレーヤに通知される。ステップ１２６において、興味を持つプレーヤがゲームへの参加を申し込む。
【００５２】
ステップ１２７において、ゲームサーバは、ゲームへの参加基準を満たすプレーヤを勧誘する。１２８において、勧誘に応じたプレーヤがゲームサーバに応答する。ステップ１２９において、ゲームサーバはゲームサーバと会議に参加するプレーヤの間の電話会議を設定する。ゲームサーバはメディアのミキシングを行い、ゲームの質問と応答を交換するために様々なプレーヤにメディアをルーティングする。
【００５３】
図７Ａ、７Ｂは本発明の方法の実施例にしたがって会議サーバが電話会議を開始するときのフローチャートの一部である。ステップ１３１において、特定ユーザ、例えばユーザＡが主催者としての会議サーバと契約する。ステップ１３２において、ユーザＡは、電話会議を開始するために複数の基準を会議サーバに提供する。そのような基準には、例えば、最小参加者数、最大参加者数、電話会議の予定開始または終了時刻、参加者の名前またはアドレスがあり、また、識別された各参加者（エイリアス）が必須メンバか、任意メンバか、代替メンバか、更に、主催者が基準を無視して電話会議を開始するように会議サーバに命令するかどうかの境界である参加者の閾値も基準に含めることができる。
【００５４】
ステップ１３３において、ユーザＡの契約に際して、会議サーバは各参加者Ｓ−ＣＳＣＦを識別し、識別された各参加者が「出席」してスタンバイの状態になったときに、そのことを会議サーバに通知するように、各ＣＳＣＦのＰＩＭサーバに要求する。ステップ１３４において、識別された参加者は個々にＳ−ＣＳＣＦに登録し、つづいてＰＩＭサーバに登録する。ＲＥＧＩＳＴＥＲメッセージはまた、各参加者がスタンバイの状態か否かを示す。ステップ１３５において、各ＰＩＭサーバは、そのＰＩＭサーバによってサービスされる参加者が出席してスタンバイの状態になれば、直ちに会議サーバに通知する。識別された各参加者がスタンバイ状態であることを示す通知がそれぞれのＰＩＭサーバから届くと、ステップ１３６において会議サーバは現在ステータスを所定基準と比較し、電話会議を開始するべきか否かを判定する。
【００５５】
電話会議を開始するための基準が満たされれば、プロセスは図７Ｂのステップ１４１に移り、会議サーバは電話会議を開始する。しかし、電話会議を開始するための基準が満たされていない場合、プロセスはステップ１３７に移り、会議サーバは、主催者が基準を無視して電話会議を開始するように会議サーバに命令するかどうかの境界である所定の閾値と比較して、スタンバイしていない参加者、または基準を満たしていない参加者の人数が少ないか否かを判定する。スタンバイしていない参加者の数が閾値を下回らなければ、プロセスはステップ１３４に戻って、識別された参加者からの追加登録を待ち続ける。
【００５６】
しかし、スタンバイしていない参加者の数が閾値を下回ると、プロセスはステップ１３８に移り、スタンバイ状態の参加者数とスタンバイしていない参加者のアイデンティティとに関するステータスレポートまたはメッセージが会議サーバから主催者に送られる。そして、ステップ１３９において、残りの基準を無視して電話会議を開始するオプションが主催者に与えられる。主催者が基準を無視しない場合、プロセスはステップ１３４に戻って、識別された参加者からの追加登録を待ち続ける。しかし、主催者が基準を無視すると、プロセスは図７Ｂのステップ１４１に移り、会議サーバは電話会議を開始する。
【００５７】
図７Ｂにおいて、会議サーバは、ステップ１４１で例えばＳＩＰ＿ＩＮＶＩＴＥメッセージを各参加者に送ることによって電話会議を開始する。すべての参加者が会議に集まった後、会議サーバはメディアのミキシングを行い、必要に応じて、メディアと他の識別された参加者全員に転送する。ステップ１４２において、会議サーバは参加者のひとりからメッセージを受信する。ステップ１４３において、サーバは、そのメッセージが主催者から来たものか否かを判定する。主催者からサーバへのメッセージは、いずれもメンバ全員に送信されることになっているので、プロセスはステップ１４７に移り、そのメッセージは会議サーバから参加者全員に送られる。しかし、主催者以外の参加者からのメッセージは、主催者だけに送信されることになっている。したがって、ステップ１４３において、主催者からのメッセージでないと判定されれば、プロセスはステップ１４４に移り、そのメッセージは会議サーバから主催者に送られる。
【００５８】
メッセージをサーバに返すか、または受信メッセージを他の参加者全員に送信するようにサーバに命令するオプションが主催者に与えられる。したがって、ステップ１４５において、主催者は、電話会議の参加者全員にそのメッセージを送るべきか否かを判定する。ＮＯであれば、プロセスはステップ１４６に移り、主催者は、そのメッセージへの応答として会議サーバに応答メッセージを返す。しかし、参加者全員に送るべきメッセージであると主催者が判断した場合には、プロセスはステップ１４７に移り、そのメッセージは会議サーバから電話会議の参加者全員に送られる。注目すべき点は、ＳＩＰ非対応装置を使用するユーザでも、Ｐ−ＩＶＲを介して登録することによって、このような電話会議に参加することができることである。
【００５９】
図８は、図７Ａ、７Ｂに示す方法を実行するために本発明の教義にしたがって修正された３ＧＰＰネットワークアーキテクチャ１５０の一部を示す簡略化ブロック図である。図示されるように、ＩＰネットワーク１５１は修正版会議サーバ（Ｍｏｄｉｆｉｅｄ  Ｃｏｎｆｅｒｅｎｃｅ  Ｓｅｒｖｅｒ）１５２を含んでいる。修正版会議サーバは、ＳＩＰ制御ネットワーク部（ＣＳＣＦ、ＰＩＭなど）１１−２６へのＳＩＰメッセージの送受信と、ＩＰデータパケットのルーティングおよび送信が可能な個別ＩＰノードである。特定のユーザが主催者として修正版会議サーバと契約して、修正版会議サーバに電話会議の開始基準を与えると、修正版会議サーバは、識別された参加者のステータスがＰＩＭサーバによって報告されたときに、それを監視して基準を満たしているか否かを判定する。参加者全員がスタンバイの状態であり、そのほかの基準が満たされているか、主催者に無視された場合、修正版会議サーバは、参加者を勧誘して電話会議を開始するために参加者側のＣＳＣＦと通信する。いったん電話会議が始まると、修正版会議サーバは確立した通信リンクに留まって、図７Ａ、７Ｂで示されるように、参加者からのメッセージを転送、配送する。
【００６０】
この発明の動作と構成は以上の詳細説明から明らかである。上述のシステムおよび方法は好ましいものと思われるが、特許請求の範囲に記載される発明の範囲から逸脱することなく、様々な変更、修正が可能であると理解するべきである。当業者に明らかなように、例えば、この発明は会議サービスに留まらず、データ通信ネットワーク内で利用可能な別のサービスおよび機能を提供するために利用することができる。そのような様々なサービスには、例えば、ＳＩＰユーザからＰＳＴＮ加入者への通話を可能にするＰＳＴＮ（Ｐｕｂｌｉｃ  Ｓｗｉｔｃｈｅｄ  Ｔｅｌｅｐｈｏｎｅ  Ｎｅｔｗｏｒｋ）ゲートウェイとして登録するサーバが含まれる。同様に、シグナリングゲートウェイへの電話の場合、ＳＩＰネットワークで２Ｇ電話を登録することができる。
【００６１】
また、本発明の代表的な好適実施例と関連して、特定のネットワークアーキテクチャ、特定のメッセージ、信号プロトコルの使用について以上に説明したが、それらアーキテクチャおよびシグナリングは単なる説明手段である。説明では、個別サービス（サービスホスト）が二者択一的にホームＳ−ＣＳＣＦに属しているが、ＩＰネットワーク内の別のネットワークノードに属していてもよい。そのような代替ネットワークノードは、既存のＩＰネットワーク内のＭＲＳ（Ｍｅｄｉａ  Ｒｅｓｏｕｒｃｅ  Ｓｅｒｖｉｃｅ）ノードであってもよい。その場合、Ｓ−ＣＳＣＦは識別されたサービスホストにサービス要求信号をルーティングする。そして、サービスホストは主催者として識別されるオリジナルユーザと他の登録メンバ全員との間で通話を開始する。メディア経路はサービスホストを介して全メンバ間に確立される。したがって、修正、拡張、変更、補正、追加、削除、組み合わせ等はすべて、特許請求の範囲に規定される本発明の範囲内に包含されるものとする。
【図面の簡単な説明】
【００６２】
【図１】典型的な３ＧＰＰネットワークアーキテクチャの一部を示す簡略化ブロック図。（従来技術）
【図２】図１の３ＧＰＰネットワークアーキテクチャにおいてＳＩＰシグナリングを利用する典型的な呼設定シグナリングを示すシグナリング図。（従来技術）
【図３Ａ】電話会議を開催するときに使用される本発明の方法の第一実施例を示すフローチャートの一部。
【図３Ｂ】電話会議を開催するときに使用される本発明の方法の第一実施例を示すフローチャートの一部。
【図４】電話会議を開催するとき使用される本発明の方法の第二実施例を示すフローチャート。
【図５】本発明の方法を実行するときに３ＧＰＰネットワークのノード間におけるメッセージの流れを示すシグナリング図。
【図６】グループを設定するときに使用される本発明の方法の好ましい実施例の各ステップを示すフローチャート。
【図７Ａ】電話会議が会議サーバによって開始されるときに使用される本発明の方法の実施例を示すフローチャートの一部。
【図７Ｂ】電話会議が会議サーバによって開始されるときに使用される本発明の方法の実施例を示すフローチャートの一部。
【図８】図７Ａ、図７Ｂの方法を実行するために本発明の教義に基づいて修正版３ＧＰＰネットワークアーキテクチャの一部を示す簡略化ブロック図。
【図１】
2005512421.tif 000006
【図２】
2005512421.tif 000007
【図３Ａ】
2005512421.tif 000008
【図３Ｂ】
2005512421.tif 000009
【図４】
2005512421.tif 000010
【図５】
2005512421.tif 000011
【図６】
2005512421.tif 000012
【図７Ａ】
2005512421.tif 000013
【図７Ｂ】
2005512421.tif 000014
【図８】
2005512421.tif 000015
【国際調査報告】
2005512421.tif 000016
2005512421.tif 000017
2005512421.tif 000018
2005512421.tif 000019
2005512421.tif 000020