呼制御装置、代理応答方法
【課題】通信端末の電話番号が複数の呼制御装置のいずれかの管理下に置かれている場合に、通信端末が、自装置の電話番号と異なる呼制御装置の管理下に置かれている電話番号を有する通信端末への着信に対して、より短時間で代理応答できるようにした呼制御装置、代理応答方法を提供すること。
【解決手段】各ＳＩＰサーバ（呼制御装置）は、システム内の各電話番号と、電話番号が収容されているＳＩＰサーバとを対応付けた電番分析テーブルを備えている。そして、ＳＩＰサーバは、自局に収容されている電話番号の通信端末から局間ピックアップの要求があった場合には、電番分析テーブルを参照して呼出中の電話番号が収容されているＳＩＰサーバを特定し、その特定したＳＩＰサーバとの間で呼の中継処理を行う。
【解決手段】各ＳＩＰサーバ（呼制御装置）は、システム内の各電話番号と、電話番号が収容されているＳＩＰサーバとを対応付けた電番分析テーブルを備えている。そして、ＳＩＰサーバは、自局に収容されている電話番号の通信端末から局間ピックアップの要求があった場合には、電番分析テーブルを参照して呼出中の電話番号が収容されているＳＩＰサーバを特定し、その特定したＳＩＰサーバとの間で呼の中継処理を行う。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信端末が他の通信端末への着信に対して代理応答する技術に関する。
【背景技術】
【０００２】
従来、例えば会社内の同一グループにおいて複数の電話機等の通信端末が配置されている場合に、そのグループ内のある通信端末への着信に対し、別の通信端末によって代理応答することが可能である。また、この代理応答の利便性を高めることを可能にするために、呼の発信元や各通信端末の表示画面に他の通信端末の動作状態（圏外、待受中、発信中、呼出中、通信中などの状態）を通知するようにした技術が知られている。例えば、通信端末の表示画面上で、他の通信端末の動作状態や発信元をユーザが確認できれば、代理応答をすべきか否かの判断も容易になる。
【０００３】
他の通信端末の動作状態を通知する技術の一例として、プレゼンスサーバからの情報に基づき、代理応答端末の表示画面において、受信された着信先の番号に対応する通信端末の識別情報の表示を、着信中であることを示す表示に変更するようにしたものが知られている。この代理応答端末では、ユーザ操作に応じて、表示されたいずれかの通信端末の識別情報を選択し、選択された通信端末に代わって応答する。
【０００４】
他の通信端末の動作状態を通知する別の技術の例として、代理応答端末内に、呼制御装置に対して呼出状態にある呼に関わる情報を要求する手段と、呼制御装置から通知された情報に基づいて代理応答する呼を特定した接続要求を発行する手段を備えたものが知られている。呼制御装置から代理応答端末に通知される情報には、呼出中の呼について発信者情報、着信者情報等の情報が含まれる。
【０００５】
比較的大規模なシステムでは、ＳＩＰ（Session Initiation Protocol）サーバ等の呼制御装置が複数設けられ、各通信端末の電話番号はいずれかの呼制御装置の管理下に置かれる。このようなシステムにおいて、ある通信装置（通信端末）が、自装置と異なる呼制御装置の管理下に置かれている電話番号への着信に対して代理応答できるようにすることが好ましい。その理由としては、第１に、例えば会社内のグループ内のすべてのユーザの通信端末の電話番号が同一の呼制御装置（局）の管理下に置かれているとは限らない点がある。第２に、ユーザによるグループの区分けは短期間で見直されうるが、その都度、ユーザが使用する通信端末の電話番号が属する呼制御装置を切り替えるのは煩雑である点がある。
【０００６】
ある通信装置（通信端末）が、自装置と異なる呼制御装置の管理下に置かれている電話番号への着信に対して代理応答できるようにすることに関する技術を以下のものが知られている。すなわち、例えば２つの呼制御システムＡ，Ｂが存在する場合に、システムＡ内の代理応答端末からのピックアップ（代理応答）要求時に、システムＡに着呼があればピックアップ制御を行い、無ければシステムＡとシステムＢをインターワークするシステム間ゲートウェイ装置を介してシステムＢに対して発呼を行うようにしたものが知られている。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２０１０−３４９７５号公報
【特許文献２】特開２００７−１７４００３号公報
【特許文献３】特開２００７−２４３７２７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
自装置と異なる呼制御装置の管理下に置かれている識別情報（例えば電話番号）への着信に対して代理応答できるようにすることに関する技術の一例を挙げたが、この技術によれば、一方のシステム内の代理応答端末からのピックアップ要求に対して他のシステムに呼出中の呼を検索していくことになる。そのため、この例示の技術では、システム内の呼制御装置の数、つまりユーザが増加するほど、各呼制御装置に対して順に呼出中の呼の検索を行うことになり、代理応答端末が代理応答するまでに相当な時間が掛かると考えられる。
【０００９】
よって、発明の１つの側面では、通信端末の識別情報が複数の呼制御装置のいずれかの管理下に置かれている場合に、通信端末が、自装置の識別情報と異なる呼制御装置の管理下に置かれている識別情報を有する通信端末への着信に対して、より短時間で代理応答できるようにした呼制御装置、代理応答方法を提供することを目的とする。
【課題を解決するための手段】
【００１０】
第１の観点では、通信端末の識別情報を管理して通信端末間の呼を制御し、他の呼制御装置と通信可能な呼制御装置が提供される。
この呼制御装置は、
各通信端末の識別情報と、自装置を含み通信網に接続されている複数の呼制御装置のうち当該識別情報を管理するいずれかの呼制御装置と、が対応付けられている第１情報を記憶する記憶部；
呼出中の通信端末の識別情報を含む代理応答要求を、識別情報が自装置の管理下にある通信端末から受け、当該要求に応じて上記第１情報を参照して、上記呼出中の通信端末の識別情報を管理する他の呼制御装置を特定する制御部；
制御部によって特定された上記他の呼制御装置宛に、識別情報が自装置の管理下にある通信端末が上記呼出中の通信端末への着信に対して代理応答することを示す第２情報を送信する通信部；
を備える。
【００１１】
第２の観点では、通信端末と、通信端末の識別情報を管理するとともに通信端末間の呼を制御する複数の呼制御装置と、各通信端末の動作状態を管理する状態管理サーバと、が通信網によって接続されている通信システムにおいて、通信端末が他の通信端末への着信に対して代理応答する代理応答方法が提供される。
この代理応答方法は、
複数の呼制御装置の各々は、通信網に接続されている通信端末ごとに、識別情報と、識別情報を管理する呼制御装置とが対応付けられている第１情報を予め記憶すること；
識別情報が第１呼制御装置の管理下にある第１通信端末は、自端末の動作状態が待受中から呼出中に変化した場合、自端末の動作状態を状態管理サーバ宛に通知すること；
状態管理サーバは、第１通信端末からの通知に応じて、第１通信端末の識別情報と、第１通信端末の動作状態とを対応付けて記憶すること；
識別情報が第１呼制御装置とは異なる第２呼制御装置の管理下にある第２通信端末は、呼出中の動作状態にある上記第１通信端末の識別情報を状態管理サーバから取得すること；
第２呼制御装置は、第１通信端末の識別情報を含む代理応答要求を第２通信端末から受け、当該要求に応じて上記第１情報を参照して、第１通信端末の識別情報を管理する呼制御装置として上記第１呼制御装置を特定すること；
第２呼制御装置は、特定した第１呼制御装置宛に、識別情報が自装置の管理下にある通信端末が第１通信端末への着信に対して代理応答することを示す第２情報を送信すること；
を含む。
【発明の効果】
【００１２】
開示の呼制御装置、代理応答方法によれば、通信端末の識別情報が複数の呼制御装置のいずれかの管理下に置かれている場合に、通信端末は、自装置の識別情報と異なる呼制御装置の管理下に置かれている識別情報を有する通信端末への着信に対して、より短時間で代理応答することができる。
【図面の簡単な説明】
【００１３】
【図１】第１の実施形態のシステムの構成を示す図。
【図２】第１の実施形態における代理応答方法の一例を概念的に示す図。
【図３】第１の実施形態の通信端末の構成の主要部を示すブロック図。
【図４】状態要求リストと状態通知リストの内容を示す図。
【図５】第１の実施形態のＳＩＰサーバの構成の主要部を示すブロック図。
【図６】電番分析テーブルの例を示す図。
【図７】第１の実施形態のプレゼンスサーバの構成の主要部を示すブロック図。
【図８】プレゼンスサーバの例を示す図。
【図９】登録端末リストの例を示す図。
【図１０】本実施形態のプレゼンスサーバが通信端末から特定のメッセージを受信したときの処理を示すフローチャート。
【図１１】本実施形態のプレゼンスサーバが通信端末から特定のメッセージを受信したときの処理を示すフローチャート。
【図１２Ａ】第１の実施形態のシステム内の動作を示すフローチャート。
【図１２Ｂ】第１の実施形態のシステム内の動作を示すフローチャート。
【図１３】第１の実施形態の発信端末の動作の一部を示すフローチャート。
【図１４】第１の実施形態の着信端末の動作の一部を示すフローチャート。
【図１５】第１の実施形態の代理応答端末の動作の一部を示すフローチャート。
【図１６Ａ】着信端末の電話番号が収容されているＳＩＰサーバの動作を示すフローチャート。
【図１６Ｂ】着信端末の電話番号が収容されているＳＩＰサーバの動作を示すフローチャート。
【図１７Ａ】代理応答端末の電話番号が収容されているＳＩＰサーバの動作を示すフローチャート。
【図１７Ｂ】代理応答端末の電話番号が収容されているＳＩＰサーバの動作を示すフローチャート。
【図１８Ａ】第２の実施形態のシステム内の動作を示すフローチャート。
【図１８Ｂ】第２の実施形態のシステム内の動作を示すフローチャート。
【図１９】第２の実施形態の代理応答端末の動作の一部を示すフローチャート。
【発明を実施するための形態】
【００１４】
（１）第１の実施形態
以下、第１の実施形態について説明する。
なお、以下の各実施形態の説明において、電話番号は、通信端末の識別情報の一例である。通信端末の識別情報は特に限定するものではないが、他にＩＰアドレス等が適用されうる。
【００１５】
（１）システム構成
本実施形態のシステム構成を図１に示す。本実施形態のシステムでは、通信網ＮＷに対して、複数のＳＩＰサーバ（局）１，２，３，４，５…と、複数の通信端末（以下、適宜「端末」と略記する。）Ａ，Ｂ，Ｃ，Ｄ，…と、プレゼンスサーバＰＳとが接続されている。複数の通信端末の各々の電話番号（以下、適宜「電番」と略記する。）は複数のＳＩＰサーバのいずれかの管理下に置かれており、ＳＩＰサーバが通信端末間の呼を制御する。プレゼンスサーバＰＳは、通信網ＮＷに接続されている各通信端末の動作状態（圏外、待受中、発信中、呼出中、通信中などの状態）を管理している。各通信端末は、プレゼンスサーバＰＳから通信される情報を参照して他の通信端末の動作状態を表示することが可能となっている。各通信端末の通信網ＮＷへの接続形態は特に限定しないが、例えば無線ＬＡＮ(Local Area Network)または有線ＬＡＮである。
なお、ＳＩＰサーバは呼制御装置の一例であり、プレゼンスサーバは状態管理サーバの一例である。
【００１６】
（２）本実施形態における代理応答
本実施形態では、通信端末が、自装置の電話番号と異なるＳＩＰサーバの管理下に置かれている（つまり、異なるＳＩＰサーバに収容されている）電話番号の通信端末への着信に対して代理応答する場合（以下、適宜「局間ピックアップ」という。）を想定する。図２に、本実施形態における代理応答方法の一例を概念的に示す。
【００１７】
図２に示す例では、通信端末Ａと通信端末Ｂの電話番号がＳＩＰサーバ５に収容されており、通信端末Ｃの電話番号がＳＩＰサーバ１に収容されている。このとき、通信端末Ａから通信端末Ｂへ発信された呼（つまり、通信端末Ｂの着信）に対して、通信端末Ａ，Ｂとは異なるＳＩＰサーバに属している電話番号の通信端末Ｃが代理応答する場合を想定する。プレゼンスサーバは、各通信端末から動作状態が変化する度に通知される情報に基づいて、通信端末の電話番号と、その通信端末の動作状態とを対応付けたプレゼンスデータを記憶および更新している。図２において、Subscribeは通信端末からプレゼンスサーバ宛に送信される、通信端末の登録メッセージであり、Notifyはプレゼンスサーバと通信端末の間でプレゼンスデータに変更があった場合に変更された情報について通知するためのメッセージである。一例として通信端末Ｃの表示画面（プレゼンス表示画面）を示すように、各通信端末では、通信網に接続されている複数の通信端末の動作状態が表示される。図２では「Ａさん」に対応して「発信中」と表示された例が示されているが、各通信端末あるいはプレゼンスサーバでは、「Ａさん」と電話番号（例えばaaaa）とが対応付けられているものとする。
【００１８】
図２において、通信端末Ａのユーザが通信端末Ｂの電話番号であるbbbbをダイヤルすると、ＳＩＰサーバ５を経由して通信端末Ｂが呼出中となり、通信端末Ｂの動作状態の変化（待受中→呼出中）がプレゼンスサーバへ通知される。この通知に応じて、プレゼンスサーバにてプレゼンスデータが更新されると、その更新されたデータが通信端末Ｃに通知されて、通信端末Ｃの表示画面上に表示される（Ｂさん−呼出中）。この表示内容を見た通信端末Ｃのユーザが、例えば表示画面上で「Ｂさん」を選択すると通信端末Ｃが代理応答処理（ピックアップ処理）を開始する。すなわち、通信端末Ｃは、ピックアップを表す特番（ピックアップ特番：この実施形態では、一例として「*12」）と、呼出中の電話番号(Ｂさんの電話番号であるbbbb)とを含むデータ(*12-bbbb；後述するINVITEに含まれる)をＳＩＰサーバ１宛てに送信する。
【００１９】
ＳＩＰサーバ１は、通信端末Ｃから受信したデータ(*12-bbbb)を分析することによって、通信端末Ｃによる代理応答要求であること、および、呼出中の電話番号bbbb（通信端末Ｂ）がＳＩＰサーバ１に収容されていることを認識する。この認識処理については後述する。その結果、通信端末Ｂへの着信に対する通信端末Ｃの代理応答を行うことを可能にするため、INFOメッセージ（以下、適宜単にINFOという。）を生成してＳＩＰサーバ５宛てに送信する。これによって、ＳＩＰサーバ５は通信端末Ｂの呼出中処理をキャンセルする。その後、ＳＩＰサーバ１とＳＩＰサーバ５の間で、代理応答のための呼制御が行われる。
【００２０】
（３）システム内の各装置の構成および機能
以下、図３〜１１を参照して、本実施形態のシステム内の各装置の構成および機能について説明する。
【００２１】
（３−１）通信端末
図３は、本実施形態の通信端末の構成の主要部を示すブロック図である。図３に示すように、本実施形態の通信端末は、ＣＰＵ１０、通信制御部１１、プレゼンス処理部１２、操作入力部１３、表示部１４、音声入出力部１５、および、データバスおよび制御バスを含むバス１６を備える。
ＣＰＵ１０は、通信端末内の各部とバス１６によって信号を送受信可能に構成され、通信端末の機能を実現するための全体の制御を行う。
通信制御部１１は、ＣＰＵ１０による制御の下で、自端末の電話番号が収容されているＳＩＰサーバとの間で通信網ＮＷを経由してＳＩＰ（Session Initiation Protocol）に従ったメッセージの送受信を行う。いったん呼が確立されると、ＲＴＰ(Real-time Transport Protocol)に従って端末間でデータ転送が行われ、通話における音声の信号処理が音声入出力部１５にて行われる。なお、通信制御部１１とＳＩＰサーバとの通信は、無線でも有線でもよい。
【００２２】
通信制御部１１は、ＣＰＵ１０による制御の下で、プレゼンスサーバとの間で通信網ＮＷを経由して、メッセージの送受信を行う。通信制御部１１は例えば、自端末の登録メッセージ（Subscribe）の送信、自端末の動作状態の変化についての通知メッセージ（Notify）の送信、あるいは他の端末の動作状態の変化について通知メッセージ（Notify）の受信の処理を行う。なお、通信端末とプレゼンスサーバとの間で通信網に接続されている他の通信端末の動作状態についてのデータ送受信が可能であれば、通信端末とプレゼンスサーバの間の通信に使用される通信プロトコルは問わない。また、通信制御部１１とプレゼンスサーバとの通信形態は、無線でも有線でもよい。
【００２３】
プレゼンス処理部１２は、通信制御部１１で受信した、プレゼンスサーバからのメッセージの解析処理、メッセージの解析結果に応じた表示処理、プレゼンスサーバ宛のメッセージの生成処理等を行う。例えば、プレゼンスサーバへ送信するSubscribeには、図４（ａ）に例示する状態要求リストが含まれる。状態要求リストは、動作状態を取得したい電話番号の一覧を指定した情報である。図４（ａ）に示す例では、３個の電話番号aaaa, bbbb, ddddについて指定されている。また、プレゼンスサーバから受信するNotifyには、図４（ｂ）に例示する状態通知リストが含まれる。状態通知リストは、状態要求リストを含むSubscribeに応じてプレゼンスサーバから通知されるリストである。図４（ｂ）には、電話番号aaaaの通信端末は「発信中」であり、電話番号bbbbの通信端末は「呼出中」であり、電話番号ddddの通信端末は「圏外」であることが通知される例が示される。
【００２４】
また、プレゼンス処理部１２は、自端末の動作状態の変化を検出すると、自端末の電話番号と自端末の動作状態とを含むNotifyを生成する。このNotifyは、通信制御部１１からプレゼンスサーバ宛に送信される。
【００２５】
ある通信端末から送信される状態要求リストに含まれる、動作状態を取得したい電話番号の一覧には、典型的な例としては、その通信端末のユーザと同一グループ内の他の１または複数のユーザの電話番号が含まれる。つまり、一覧には、通信端末のユーザが代理応答する可能性のある他のユーザの通信端末の電話番号が含まれる。例えば、通信端末Ａ（電話番号aaaa）、通信端末Ｂ（電話番号bbbb）、通信端末Ｃ（電話番号cccc）、通信端末Ｄ（電話番号dddd）のユーザが同一グループである場合、図４（ａ）に示す状態要求リストは、通信端末Ｃから送信される。
【００２６】
ＣＰＵ１０は表示部１４を制御し、プレゼンス処理部１２で取得した状態通知リストの内容を再構成する等して表示画面（プレゼンス表示画面）に表示する。これにより、通信端末のユーザは、他の通信端末の動作状態を視認することができる。なお、操作入力部１３はＣＰＵ１０と協働して、表示画面に表示された状態の状態通知リストの中から、「呼出中」の通信端末のいずれかを選択操作（代理応答操作）、あるいは所定のピックアップ特番のダイヤル操作（代理応答操作）を受け入れる。
【００２７】
ＣＰＵ１０は、「呼出中」の通信端末が選択されると、ピックアップ特番（この実施形態では、一例として「*12」）と、呼出中の電話番号とを含むデータ(図２に示した例では、*12-bbbb)を組み立て、そのデータを含むメッセージを通信制御部１１から自端末の電話番号が収容されているＳＩＰサーバ宛てに送信する。
【００２８】
（３−２）ＳＩＰサーバ
図５は、本実施形態のＳＩＰサーバの構成の主要部を示すブロック図である。図５に示すように、本実施形態のＳＩＰサーバは、ＣＰＵ２０、通信制御部２１、メモリ２２、ＨＤＤ（Hard Disk Drive；ハードディスク駆動装置）２３、および、データバスおよび制御バスを含むバス２４を備える。なお、ＨＤＤ２３には、バックアップのためのデータが記憶されている。
ＣＰＵ２０は、ＳＩＰサーバ内の各部とバス２４によって信号を送受信可能に構成され、ＳＩＰサーバの機能を実現するための全体の制御を行う。ＣＰＵ２０は、制御部の一例である。
通信制御部２１は、ＣＰＵ２０による制御の下で、自サーバが管理する電話番号の通信端末との間、および、通信網ＮＷに接続されている他のＳＩＰサーバとの間で、通信網ＮＷを経由してＳＩＰに従ったメッセージの送受信を行う。このとき、ＣＰＵ２０は、メモリ２２内の呼処理プログラムを解釈して、通信制御部２１に対する制御を含む呼処理（セッション制御処理）を実行する。通信制御部２１は、通信部の一例である。
【００２９】
メモリ２２には、上記呼処理プログラムのほか、電番分析テーブルを含む局データと、端末データとが記憶されている。メモリ２２は、記憶部の一例である。
電番分析テーブルには、通信網ＮＷに接続されているすべての通信端末の電話番号と、各電話番号が収容されているＳＩＰサーバとが対応付けられている。また、電番分析テーブルには、特番と、その特番のサービスとが対応付けられている。電番分析テーブルの例を図６に示す。図６（ａ），（ｂ）に示す例では、それぞれＳＩＰサーバ１，５に含まれる電番分析テーブルの例が示される。図６（ａ）のＳＩＰサーバ１内の電番分析テーブルの例では、電話番号aaaa，bbbbがＳＩＰサーバ５に収容され、電話番号cccc，ddddがそれぞれ自局収容の（つまり、自サーバ内に収容されている）通信端末Ｃ，Ｄであることを示している。図６（ｂ）のＳＩＰサーバ５内の電番分析テーブルの例では、電話番号cccc，ddddがＳＩＰサーバ１に収容され、電話番号aaaa，bbbbがそれぞれ自局収容の通信端末Ａ，Ｂであることを示している。また、*12がピックアップサービス、つまり代理応答を示す特番であることが示される。
なお、電番分析テーブルは、第１情報の一例である。
【００３０】
端末データは、自サーバが収容している電話番号と、通信網ＮＷ上でユニークな識別情報とが対応付けられている。例えば、通信網ＮＷとしてＩＰネットワークを利用する場合、通信制御部２１は、端末データを参照し、電話番号に対応する発信元および着信先のＩＰアドレスを特定する。
【００３１】
自サーバに属している電話番号の通信端末が、他サーバに属している電話番号の通信端末への着信に対して代理応答する機能（局間ピックアップ機能）は、呼処理プログラムをＣＰＵ２０が解釈して実行することにより実現される。局間ピックアップ機能では、自サーバに属している電話番号の通信端末から、ピックアップ特番（この実施形態では、一例として「*12」）と、呼出中の電話番号とを含むデータ(図２に示した例では、*12-bbbb)を受信すると、そのデータに含まれる番号を、メモリ２２内の電番分析テーブルを参照して分析する。例えば、図６（ａ）に示した例において、ＳＩＰサーバ１が、通信端末から*12-bbbbのデータを受信した場合、そのデータが電話番号bbbbに対する代理応答要求であること意味するため、bbbbをキーとして電番分析テーブルを検索する。その結果、ＳＩＰサーバ１は、bbbbがＳＩＰサーバ５に収容されていることが分かるため、INFOメッセージ（INFO）を生成してＳＩＰサーバ５宛てに送信する。INFOは、あるＳＩＰサーバが他のＳＩＰサーバに対し、他のＳＩＰサーバに収容されている電話番号の着信に対して代理応答を行うときに送信される。INFOを受信した他のサーバは、そのINFOが示す電話番号に対する呼出の処理をキャンセルする等、代理応答についての所定の手続きを行う。
INFOメッセージは、第２情報の一例である。
【００３２】
（３−３）プレゼンスサーバ
図７は、本実施形態のプレゼンスサーバの構成の主要部を示すブロック図である。図７に示すように、本実施形態のプレゼンスサーバは、ＣＰＵ４０、通信制御部４１、メモリ４２、ＨＤＤ４３、および、データバスおよび制御バスを含むバス４４を備える。なお、ＨＤＤ４３には、バックアップのためのデータが記憶されている。
ＣＰＵ４０は、プレゼンスサーバ内の各部とバス４４によって信号を送受信可能に構成され、プレゼンスサーバの機能を実現するための全体の制御を行う。
【００３３】
通信制御部４１は、ＣＰＵ４０による制御の下で、通信網ＮＷに接続されている複数の通信端末との間で、通信網ＮＷを経由してメッセージの送受信を行う。通信制御部４１は例えば、各通信端末からの登録メッセージ（Subscribe）の受信、各通信端末の動作状態の変化についての通知メッセージ（Notify）の受信、あるいは各通信端末の動作状態の変化について通知メッセージ（Notify）の送信の処理を行う。
【００３４】
ＣＰＵ４０は、メモリ４２内のプレゼンスサービスプログラムを解釈して実行することにより、通信網ＮＷに接続されている各通信端末に対してプレゼンスサービス機能を提供する。プレゼンスサービス機能には、各通信端末の登録、各通信端末からの他の通信端末の動作状態の要求に対する応答などが含まれる。例えば、ＣＰＵ４０は、通信制御部４１で受信した、通信端末からのメッセージの解析処理、メッセージの解析結果に応じた処理、通信端末宛のメッセージの生成処理等を行う。例えば、通信制御部４１が受信するSubscribeには、図４（ａ）に例示した状態要求リストが含まれる。また、通信端末宛に送信するNotifyには、図４（ｂ）に例示した状態通知リストが含まれる。
【００３５】
メモリ４２には、上記プレゼンスサービスプログラムのほか、プレゼンスデータと、端末登録リストとが記憶されている。プレゼンスデータは、プレゼンスサーバに登録している電話番号と、その電話番号の通信端末の動作状態（圏外、待受中、発信中、呼出中、通信中などの状態）とが対応付けられたデータであり、その一例を図８に示す。ＣＰＵ４０は、各通信端末から動作状態が変化する度に送信されるNotifyに基づいて、プレゼンスデータの内容を更新する。また、ＣＰＵ４０は、通信端末から状態要求リストを受信すると、プレゼンスデータを参照して、状態要求リストで指定された通信端末の動作状態を取得して、通信端末宛の状態通知リストを生成する。
【００３６】
登録端末リストは、Subscribeを送信した通信端末の電話番号と、Subscribeに含まれる状態要求リストに含まれる電話番号とが対応付けられているデータであり、その一例を図９に示す。図９に示す例では、例えば前述したように、通信端末Ａ（電話番号aaaa）、通信端末Ｂ（電話番号bbbb）、通信端末Ｃ（電話番号cccc）、通信端末Ｄ（電話番号dddd）のユーザが同一グループである場合が想定されている。このとき、登録端末リストでは、電話番号aaaaと、同一グループ内の他の電話番号（bbbb, cccc, dddd）とが対応付けられる。
【００３７】
以下、通信端末からメッセージを受信したときにＣＰＵ４０によって実行される処理について、図１０および図１１を参照して説明する。図１０は、通信端末からSubscribeを受信したときの処理である。図１１は、通信端末からNotifyを受信したときの処理である。
図１０において、プレゼンスサーバのＣＰＵ４０は、通信端末からSubscribeを受信すると（ステップＳ１０のＹｅｓ）、登録端末リストを更新する。つまり、Subscribeには、状態要求リスト（図４（ａ）参照）が含まれているので、ＣＰＵ４０は、Subscribeを送信した通信端末の電話番号と、リスト内で指定されている電話番号とを、登録端末リスト内で対応付ける。次にＣＰＵ４０は、プレゼンスデータを参照して、受信したSubscribe内の登録端末リストの各電話番号に対応した動作状態を取得する。そして、ＣＰＵ４０は、指定された電話番号に対応した動作状態を含む状態通知リスト（図４（ｂ）参照）を生成し（ステップＳ１３）、この状態通知リストを含むNotifyを、ステップＳ１０でSubscribeを送信した通信端末へ送信する（ステップＳ１４）。
【００３８】
図１１において、プレゼンスサーバのＣＰＵ４０は、通信端末からNotifyを受信すると（ステップＳ２０のＹｅｓ）、プレゼンスデータを更新する。つまり、Notifyには、ステップＳ２０でNotifyを送信した通信端末の電話番号と、その通信端末の動作状態とが含まれているので、これらの情報に基づいてＣＰＵ４０はプレゼンスデータを更新する（ステップＳ２１）。その後、ＣＰＵ４０は通信制御部４１を制御して、ＳＩＰに従ったメッセージである200 OKを通信端末宛に返送する（ステップＳ２２）。次に、ステップＳ２０でNotifyを送信した通信端末の動作状態の変化を、例えば、その通信端末の電話番号と同一グループ内の他の電話番号の通信端末へ通知するために、登録端末リストが参照される。他の電話番号の通信端末への通知は、更新された状態通知リストを含むNotifyが使用される（ステップＳ２３）。
【００３９】
（４）システム内の動作および各装置の動作
以下、図１２Ａ〜１７Ｂを参照して、本実施形態のシステム内の局間ピックアップ時の動作、および各装置の局間ピックアップ時の動作について説明する。
図１２Ａ，図１２Ｂは、本実施形態のシステム内の動作を示すフローチャートである。図１３は、発信端末Ａの動作の一部を示すフローチャートである。図１４は、着信端末Ｂの動作の一部を示すフローチャートである。図１５は、代理応答端末（ピックアップ端末）Ｃの動作の一部を示すフローチャートである。図１６Ａ，図１６Ｂは、以下の説明におけるＳＩＰサーバ５（着信端末Ｂの電話番号が収容されているＳＩＰサーバ）の動作を示すフローチャートである。図１７Ａ，図１７Ｂは、以下の説明におけるＳＩＰサーバ１（代理応答端末Ｃの電話番号が収容されているＳＩＰサーバ）の動作を示すフローチャートである。
なお、以下の説明では、発信端末Ａと着信端末Ｂの電話番号はＳＩＰサーバ５に収容されており、代理応答端末Ｃの電話番号はＳＩＰサーバ１に収容されているものとする。また、以下の説明において、着信端末Ｂは第１通信端末の一例であり、ＳＩＰサーバ５は第１呼制御装置の一例である。代理応答端末Ｃは第２通信端末の一例であり、ＳＩＰサーバ１は第２呼制御装置の一例である。
【００４０】
以下では、基本的に、図１２Ａ，図１２Ｂのフローを参照して全体の動作を時系列上で説明しつつ、適宜個々の装置の動作を補足的に付すことにする。また、各図では、ＳＩＰで定義されているメッセージを以下のとおり簡略的に記載してある。
【００４１】
・100…100 Trying （受信完了を知らせ、INVITEの再送を止める）
・180…180 Ringing （呼出中）
・200…200 OK （要求が成功したことを示す）
・4xx…リクエスト失敗
・404…404 Not Found （ユーザが見つからないことを示す）
・INVITE…セッション開始
・CANCEL…キャンセル
・ACK…セッション確立確認
・BYE…セッション終了
【００４２】
ステップＳ１００：
先ず、通信網に接続されている端末Ａ，Ｂ，Ｃは、状態要求リストを含むSubscribeをプレゼンスサーバ宛に送信する。状態要求リストでは、各端末が動作状態を取得したい電話番号の一覧が指定される。ここでは、端末Ａ，Ｂ，Ｃのユーザが同一グループ内である場合を想定する。この場合、端末Ａは、動作状態を取得したい電話番号として、端末Ｂの電話番号(bbbb)と端末Ｃ(cccc)の電話番号を指定する。端末Ｂは、動作状態を取得したい電話番号として、端末Ａの電話番号(aaaa)と端末Ｃ(cccc)の電話番号を指定する。端末Ｃは、動作状態を取得したい電話番号として、端末Ａの電話番号(aaaa)と端末Ｂ(bbbb)の電話番号を指定する。各端末からSubscribeを受信したプレゼンスサーバは、端末Ａ〜Ｃを登録、つまり登録端末リスト（図９参照）を更新し、各端末宛に200を返す。
【００４３】
ステップＳ１１０：
ここで、端末Ａのユーザがbbbb（端末Ｂの電話番号）のダイヤル操作を行う。
【００４４】
ステップＳ１２０：
ステップＳ１１０のダイヤル操作により、端末Ａは電話番号bbbbを指定したINVITEをＳＩＰサーバ５宛てに送信し、ＳＩＰサーバ５は端末Ａに100を返す（図１３のステップＳ３０，Ｓ３１、図１６ＡのステップＳ６０，Ｓ６１）。
【００４５】
ステップＳ１３０：
ステップＳ１２０の処理により、端末Ａの動作状態は「待受中」から「発信中」へ動作状態が変化したので、端末Ａは、その状態変化を示すNotifyをプレゼンスサーバ宛に送信する（図１３のステップＳ３２）。プレゼンスサーバでは、端末Ａの動作状態の変化に基づきプレゼンスデータを更新するとともに、端末Ａの動作状態の変化を他の端末Ｂ，Ｃに通知するため、端末状態通知リストを含むNotifyを端末Ｂ，Ｃ宛に送信し、その後、端末Ｂ，Ｃから200を受信する。これにより、各端末におけるプレゼンス表示画面が更新される。
【００４６】
ステップＳ１４０：
ＳＩＰサーバ５は、ステップＳ１２０で端末Ａから送信されたINVITEに含まれる電話番号を分析して着信先が電話番号bbbbであることが分かると、電話番号bbbbの端末Ｂ宛てにINVITEを送信する（図１６ＡのステップＳ６２，Ｓ６３）。端末ＢはこのINVITEを受信する（図１４のステップＳ４０）。このINVITEに応じて端末Ｂは、100および180（呼出中）をＳＩＰサーバ５宛てに送信する（図１４のステップＳ４１，Ｓ４２）。ＳＩＰサーバ５は、端末Ｂから100および180を受信する（図１６ＡのステップＳ６４，Ｓ６５）。端末Ｂから180を受信すると、ＳＩＰサーバ５は、180を発信端末Ａ宛に送信する。端末Ａは、この180を受信する（図１３のステップＳ３３）。これにより、端末Ａにおいて所定の発信音出力がなされ、端末Ａが「発信中」であることが端末Ａのユーザに認識される（図１３のステップＳ３４）。このようにして、発信端末Ａから着信端末Ｂへの呼出中の状態となる（図１４のステップＳ４３、図１６ＡのステップＳ６６）。
【００４７】
なお、図１２Ａには記載されていないが、ここで仮に、ＳＩＰサーバ５が端末Ａから200を受信したならば（図１６ＡのステップＳ６７）、端末Ａと端末Ｂの間で通信中（通話中）の状態となる（図１６ＡのステップＳ６８）。
【００４８】
ステップＳ１５０：
ステップＳ１４０の処理により、端末Ｂの動作状態は「待受中」から「呼出中」へ動作状態が変化したので、端末Ｂは、その状態変化を示すNotifyをプレゼンスサーバ宛に送信する（図１４のステップＳ４４）。プレゼンスサーバでは、端末Ｂの動作状態の変化に基づきプレゼンスデータを更新するとともに、端末Ｂの動作状態の変化を他の端末Ａ，Ｃに通知するため、端末状態通知リストを含むNotifyを端末Ａ，Ｃ宛に送信し、その後、端末Ａ，Ｃから200を受信する。これにより、各端末におけるプレゼンス表示画面が更新される。
【００４９】
ステップＳ１６０：
端末Ｃにおいてプレゼンス表示画面が表示される（図１５のステップＳ５０）。ここで、端末Ｃのユーザは、プレゼンス表示画面上で端末Ｂが「呼出中」であることを視認し、端末Ｂを選択する操作を行うこと等によって（図１５のステップＳ５１のＹＥＳ）、コールピックアップ、すなわち、端末Ｂへの着信に対して代理応答する操作を行う。
【００５０】
ステップＳ１７０：
ステップＳ１６０の操作により、端末Ｃは、ピックアップ特番である*12と、代理応答対象の電話番号（ここでは、端末Ｂのbbbb）とを順に組み立てた電番のデータ（*12-bbbb）を含むINVITEを生成する（図１５のステップＳ５２）。端末ＣはそのINVITEをＳＩＰサーバ１宛てに送信する（図１５のステップＳ５３）。ＳＩＰサーバ１は、端末ＣからのINVITEを受信するとともに、端末Ｃ宛に100を返信する（図１７ＡのステップＳ８０，Ｓ８１）。端末ＣがＳＩＰサーバ１から100を受信する（図１５のステップＳ５４）。
なお、ここで端末Ｃから送信されるINVITEは、代理応答要求の一例である。
【００５１】
ステップＳ１８０：
ステップＳ１７０の処理により、端末Ｃの動作状態は「待受中」から「発信中」へ動作状態が変化したので、端末Ｃは、その状態変化を示すNotifyをプレゼンスサーバ宛に送信する（図１５のステップＳ５５）。プレゼンスサーバでは、端末Ｃの動作状態の変化に基づきプレゼンスデータを更新するとともに、端末Ｃの動作状態の変化を他の端末Ａ，Ｂに通知するため、端末状態通知リストを含むNotifyを端末Ａ，Ｂ宛に送信し、その後、端末Ａ，Ｂから200を受信する。これにより、各端末におけるプレゼンス表示画面が更新される。
【００５２】
ステップＳ１９０：
ＳＩＰサーバ１は、ステップＳ１７０で端末Ｃから受信したINVITEに含まれる電番のデータ（*12-bbbb）を、メモリ２２内の電番分析テーブルを参照して分析する（図１７ＡのステップＳ８２）。具体的には、ＳＩＰサーバ１は、INVITEに含まれる電番のデータ（*12-bbbb）の先頭のコードが“*12”でない場合には（図１７ＡのステップＳ８３のＮＯ）、例えば局内通話等の通常の呼処理を行い、先頭のコードが“*12”である場合には（図１７ＡのステップＳ８３のＹＥＳ）、さらに後続コードを分析する（図１７ＡのステップＳ８５）。つまり、後続コード（本実施形態の場合には“bbbb”）が示す電話番号が自局収容の電話番号であるか否か判定する（図１７ＡのステップＳ８６）。つまり、ＳＩＰサーバ１は電番分析テーブルを参照して、後続コードが示す電話番号が収容されているＳＩＰサーバを特定する。以上の分析結果から、ＳＩＰサーバ１は、端末Ｃから受信したINVITEに含まれる電番のデータ（*12-bbbb）が、他局（ＳＩＰサーバ５）の電話番号bbbbに対する局間ピックアップの要求であることを認識する。
【００５３】
なお、図１２Ａおよび図１２Ｂには示していないが、仮に後続コードが示す電話番号bbbbが自局収容の電話番号であると判定した場合には（図１７ＡのステップＳ８７）、ＳＩＰサーバ１において以下の局内ピックアップ処理が行われる。すなわち、ＳＩＰサーバ１は、自局収容の電話番号bbbbの端末Ｂに対してCANCELを送信し、端末Ａおよび端末Ｃ宛に200を送信し、端末Ａおよび端末ＣからACKを受信する処理を経て、端末Ａ，Ｃ間で通信中となる（図１７ＡのステップＳ８７〜Ｓ９０）。
【００５４】
ステップＳ２００：
ＳＩＰサーバ１は、ステップＳ１９０における分析結果に基づいて、INFOメッセージ（INFO）を生成し（図１７ＢのステップＳ９１）、bbbbの電話番号が収容されているＳＩＰサーバ５宛てに送信する（図１７ＢのステップＳ９２）。ＳＩＰサーバ５はINFOを受信する（図１６ＡのステップＳ６９）。INFOには、bbbbの電話番号に対する代理応答要求(pickup,bbbb)を示すデータが含まれている。
【００５５】
ステップＳ２１０：
ＳＩＰサーバ５は、ＳＩＰサーバ１からINFOを受信し、INFOの内容がbbbbの電話番号（つまり、自局収容の電話番号）に対する代理応答要求であることを認識すると（図１６ＢのステップＳ７０のＹＥＳ）、通信端末Ｂの呼出中処理をキャンセルするためのメッセージであるCANCELを端末Ｂ宛に送信する（図１６ＢのステップＳ７２）。端末Ｂは、ＳＩＰサーバ５からCANCELを受信すると（図１４のステップＳ４５）、200をＳＩＰサーバ５宛てに送信する（図１４のステップＳ４６）。ＳＩＰサーバ５は、端末Ｂから200を受信すると、ＳＩＰサーバ１宛てに200を送信する（図１６ＢのステップＳ７３）。ＳＩＰサーバ１では、ＳＩＰサーバ５から信号を受信し、その受信信号が200であることを認識する（図１７ＢのステップＳ９３、Ｓ９４のＹＥＳ）。
【００５６】
なお、INFOの内容が自局収容の電話番号でない場合には（図１６ＢのステップＳ７０のＮＯ）、ＳＩＰサーバ５は、ＳＩＰサーバ１宛てに404を送信し（図１６ＢのステップＳ７１）、端末Ａから端末Ｂを呼出中の状態（図１６ＡのステップＳ６６）へ戻る。
【００５７】
ステップＳ２２０：
ステップＳ２１０の処理により、端末Ｂの動作状態は「呼出中」から「待受中」へ動作状態が変化したので、端末Ｂは、その状態変化を示すNotifyをプレゼンスサーバ宛に送信する。プレゼンスサーバでは、端末Ｂの動作状態の変化に基づきプレゼンスデータを更新するとともに、端末Ｂの動作状態の変化を他の端末Ａ，Ｃに通知するため、端末状態通知リストを含むNotifyを端末Ａ，Ｃ宛に送信し、その後、端末Ａ，Ｃから200を受信する。これにより、各端末におけるプレゼンス表示画面が更新される。
【００５８】
ステップＳ２３０：
ＳＩＰサーバ５は、ステップＳ２１０における200の送信に次いで、INFOの送信元サーバであるＳＩＰサーバ１宛てにINVITEを送信する（図１６ＢのステップＳ７４）。ＳＩＰサーバ１は、ＳＩＰサーバ５からINVITEを受信するとともに（図１７ＢのステップＳ９６）、このINVITE受信に応じてＳＩＰサーバ５宛てに100を送信する。ＳＩＰサーバ５は、ＳＩＰサーバ１から100を受信する（図１６ＢのステップＳ７５）。
【００５９】
ステップＳ２４０：
ＳＩＰサーバ１は、ステップＳ２３０におけるINVITEの受信に対する200をＳＩＰサーバ５宛てに送信するとともに（図１７ＢのステップＳ９７）、ステップＳ１７０におけるINVITEの受信に対する200を代理応答端末Ｃ宛に送信する。ＳＩＰサーバ５はＳＩＰサーバ１から200を受信し（図１６ＢのステップＳ７６）、端末ＣはＳＩＰサーバ１から200を受信する（図１５のステップＳ５６）。
また、ＳＩＰサーバ５は、ＳＩＰサーバ１から200を受信すると、ステップＳ１２０におけるINVITEの受信に対する200を発信端末Ａ宛に送信する。端末Ａは、ＳＩＰサーバ５から200を受信する（図１３のステップＳ３５）。
200を受信したＳＩＰサーバ５、端末ＡおよびＣはそれぞれ、200の送信元宛にACKを送信する（図１６ＢのステップＳ７７、図１７ＢのステップＳ９８）。
ステップＳ２３０およびＳ２４０の処理を経て、発信端末Ａと代理応答端末Ｃの間で呼が確立される。
【００６０】
ステップＳ２５０：
ステップＳ２３０およびＳ２４０の処理により、端末Ｃの動作状態は「発信中」から「通信中」へ動作状態が変化したので、端末Ｃは、その状態変化を示すNotifyをプレゼンスサーバ宛に送信する（図１５のステップＳ５７）。プレゼンスサーバでは、端末Ｃの動作状態の変化に基づきプレゼンスデータを更新するとともに、端末Ｃの動作状態の変化を他の端末Ａ，Ｂに通知するため、端末状態通知リストを含むNotifyを端末Ａ，Ｂ宛に送信し、その後、端末Ａ，Ｂから200を受信する。これにより、各端末におけるプレゼンス表示画面が更新される。
【００６１】
ステップＳ２６０：
ステップＳ２３０およびＳ２４０の処理により、端末Ａの動作状態は「発信中」から「通信中」へ動作状態が変化したので、端末Ａは、その状態変化を示すNotifyをプレゼンスサーバ宛に送信する（図１３のステップＳ３６）。プレゼンスサーバでは、端末Ａの動作状態の変化に基づきプレゼンスデータを更新するとともに、端末Ａの動作状態の変化を他の端末Ｂ，Ｃに通知するため、端末状態通知リストを含むNotifyを端末Ｂ，Ｃ宛に送信し、その後、端末Ｂ，Ｃから200を受信する。これにより、各端末におけるプレゼンス表示画面が更新される。
【００６２】
ステップＳ２７０：
発信端末Ａと代理応答端末Ｃの間で呼が確立されると、端末Ａ，Ｃ間で、ＲＴＰ(Real-time Transport Protocol)に基づくデータ通信が行われ、いわゆる通話中の状態となる（図１３のステップＳ３７、図１５のステップＳ５８、図１６ＢのステップＳ７８、図１７ＢのステップＳ９９）。
【００６３】
ステップＳ２８０：
端末Ａ，Ｃ間で通信が終了すると、端末ＡはＳＩＰサーバ５宛てにBYEを送信し、ＳＩＰサーバ５はＳＩＰサーバ１宛てにBYEを送信し、ＳＩＰサーバ１は端末Ｃ宛にBYEを送信する。
【００６４】
ステップＳ２９０：
ステップＳ２８０でBYEを受信した端末Ｃの動作状態は「通信中」から「待受中」へ動作状態が変化したので、端末Ｃは、その状態変化を示すNotifyをプレゼンスサーバ宛に送信する。プレゼンスサーバでは、端末Ｃの動作状態の変化に基づきプレゼンスデータを更新するとともに、端末Ｃの動作状態の変化を他の端末Ａ，Ｂに通知するため、端末状態通知リストを含むNotifyを端末Ａ，Ｂ宛に送信し、その後、端末Ａ，Ｂから200を受信する。これにより、各端末におけるプレゼンス表示画面が更新される。
【００６５】
ステップＳ３００：
ステップＳ２８０のBYEの送信に応じて、受信元はBYEの送信元に対して200を送信する。
【００６６】
ステップＳ３１０：
ステップＳ３００で200を受信した端末Ａの動作状態は「通信中」から「待受中」へ動作状態が変化したので、端末Ａは、その状態変化を示すNotifyをプレゼンスサーバ宛に送信する。プレゼンスサーバでは、端末Ａの動作状態の変化に基づきプレゼンスデータを更新するとともに、端末Ａの動作状態の変化を他の端末Ｂ，Ｃに通知するため、端末状態通知リストを含むNotifyを端末Ｂ，Ｃ宛に送信し、その後、端末Ｂ，Ｃから200を受信する。これにより、各端末におけるプレゼンス表示画面が更新される。
【００６７】
以上、本実施形態のシステム内の局間ピックアップ時の動作、および各装置の局間ピックアップ時の動作について詳述した。上述したとおり、本実施形態の代理応答方法によれば、通信網に対して複数のＳＩＰサーバ（局）が接続されたシステムにおいて、各ＳＩＰサーバは、システム内の各電話番号と、電話番号が収容されているＳＩＰサーバとを対応付けた電番分析テーブルを備えている。そして、ＳＩＰサーバは、自局に収容されている電話番号の通信端末から局間ピックアップの要求があった場合には、電番分析テーブルを参照して呼出中の電話番号が収容されているＳＩＰサーバを特定し、その特定したＳＩＰサーバとの間で呼の中継処理を行う。そのため、代理応答対象の電話番号について他の複数のＳＩＰサーバを個別に検索する必要がなく、局間ピックアップの処理を短時間で完了させることができる。
【００６８】
（２）第２の実施形態
以下、第２の実施形態について説明する。
第１の実施形態の代理応答方法では、予め代理応答端末Ｃがプレゼンスサーバに自端末の登録を行い、プレゼンスデータに基づいて表示されるプレゼンス表示画面上で、端末Ｃのユーザが代理応答のための所定の操作を行うことを契機として代理応答処理が開始される。これに対し、本実施形態の代理応答方法では、代理応答端末Ｃは、予めプレゼンスサーバに自端末の登録を行わず、端末Ｃのユーザが代理応答のための所定のダイヤル操作（代理応答操作）を行うことを契機として代理応答処理が開始される。例えば、他の呼出中の端末の鳴動動作を知覚して、端末Ｃのユーザが代理応答のための所定のダイヤル操作を行う場合が想定されている。
【００６９】
以下、図１８Ａ〜１９を参照して、本実施形態のシステム内の局間ピックアップ時の動作、および各装置の局間ピックアップ時の動作について説明する。図１８Ａ，図１８Ｂは、本実施形態のシステム内の動作を示すフローチャートである。図１９は、代理応答端末（ピックアップ端末）Ｃの動作の一部を示すフローチャートである。
第１の実施形態と同様、以下の説明では、発信端末Ａと着信端末Ｂの電話番号はＳＩＰサーバ５に収容されており、代理応答端末Ｃの電話番号はＳＩＰサーバ１に収容され、端末Ａ，Ｂ，Ｃのユーザが同一グループ内である場合を想定する。
【００７０】
ステップＳ４００：
先ず、端末Ａ，Ｂは、自端末の登録要求を含むSubscribeをプレゼンスサーバ宛に送信する。端末Ａ，ＢからSubscribeを受信したプレゼンスサーバは、端末Ａ，Ｂを登録、つまり登録端末リスト（図９参照）を更新し、各端末宛に200を返す。
なお、図１８Ａおよび図１８Ｂに示すフローチャートにおいて、プレゼンスサーバは以後、登録した通信端末からの通知に応じて通信端末の動作状態を更新するが、特定の通信端末の動作状態の変化を他の通信端末宛に通知しない場合が想定されている。
また、図１８Ａおよび図１８Ｂに示すフローチャートでは、代理応答端末Ｃが代理応答処理を行うときに初めてプレゼンスサーバに登録して状態通知リストを取得する場合が示されているが、この限りではない。端末Ｃが予めプレゼンスサーバに登録されていてもよいし、代理応答処理後継続的に状態通知リストを取得するようにしてもよい。
【００７１】
ステップＳ４１０：
ここで、端末Ａのユーザがbbbbのダイヤル操作を行う。
【００７２】
ステップＳ４２０：
ステップＳ４１０のダイヤル操作により、端末Ａは電話番号bbbbを指定したINVITEをＳＩＰサーバ５宛てに送信し、ＳＩＰサーバ５は端末Ａに100を返す。
【００７３】
ステップＳ４３０：
ステップＳ４２０の処理により、端末Ａの動作状態は「待受中」から「発信中」へ動作状態が変化したので、端末Ａは、その状態変化を示すNotifyをプレゼンスサーバ宛に送信する。プレゼンスサーバではNotifyの受信に応じて、200を端末Ａに返す。
【００７４】
ステップＳ４４０：
ＳＩＰサーバ５は、ステップＳ４２０で端末Ａから送信されたINVITEに含まれる電話番号を分析して着信先が電話番号bbbbであることが分かると、電話番号bbbbの端末Ｂ宛てにINVITEを送信する。端末ＢはこのINVITEを受信する。このINVITEに応じて端末Ｂは、100をＳＩＰサーバ５宛てに送信する。ＳＩＰサーバ５は、端末Ｂから100を受信する。
【００７５】
ステップＳ４５０：
ステップＳ４４０の処理により、端末Ｂの動作状態は「待受中」から「呼出中」へ動作状態が変化したので、端末Ｂは、その状態変化を示すNotifyをプレゼンスサーバ宛に送信する。プレゼンスサーバではNotifyの受信に応じて、200を端末Ｂに返す。
【００７６】
ステップＳ４６０：
ＳＩＰサーバ５は、端末Ｂから180が送信されてくると、発信端末Ａ宛に180を送信する。このようにして、発信端末Ａから着信端末Ｂへの呼出中の状態となる。
【００７７】
ステップＳ４７０：
この時点で、端末Ｃのユーザは、着信端末Ｂの鳴動動作を知覚して所定のダイヤル操作（ここでは、ピックアップ特番を示す“*12”）を行う。このダイヤル操作、すなわち代理応答操作は、端末Ｂの操作入力部１３を経てＣＰＵ１０に認識される。
【００７８】
ステップＳ４８０：
ピックアップ特番を示す所定のダイヤル操作を認識した端末Ｃは、状態要求リストを含むSubscribeをプレゼンスサーバ宛に送信する（図１９のステップＳ８００）。状態要求リストでは、動作状態を取得したい電話番号の一覧が指定される。ここでは、端末Ａ，Ｂ，Ｃのユーザが同一グループ内である場合を想定されているため、端末Ｃは、動作状態を取得したい電話番号として、端末Ａの電話番号(aaaa)と端末Ｂ(bbbb)の電話番号を指定する。端末ＣからSubscribeを受信したプレゼンスサーバは、端末Ｃを登録、つまり登録端末リスト（図９参照）を更新し、端末Ｃ宛に200を返す。
プレゼンスサーバは、Subscribeを受信すると、Subscribe内の状態要求リストで指定された端末Ａ，Ｂの動作状態を含む状態通知リスト（例えば図４（ｂ）参照）を含むNotifyを端末Ｃ宛に送信する。端末Ｃは、プレゼンスサーバから状態通知リストを含むNotifyを受信する（図１９のステップＳ８０１）。
端末Ｃは、プレゼンスサーバからNotifyを受信すると、それ以降では、状態通知リストの受信は必ずしも必要ないので、そのリスト送信を止めるためのメッセージであるUnsubscribeをプレゼンスサーバ宛に送信し、プレゼンスサーバから200を受信する。
【００７９】
ステップＳ４９０：
端末Ｃは、ステップＳ４７０のダイヤル操作に応じて、プレゼンスサーバから受信した状態通知リストの中で、「呼出中」の端末（本実施形態では、bbbbの電話番号の通信端末）あるいはその電話番号を特定する（図１９のステップＳ８０２）。さらに、端末Ｃは、その「呼出中」の端末への着信に対するコールピックアップ、すなわち、端末Ｂへの着信に対して代理応答する処理を行うことを決定する。
【００８０】
ステップＳ５００：
端末Ｃは、ピックアップ特番である*12と、代理応答対象の電話番号（ここでは、端末Ｂのbbbb）とを順に組み立てた電番のデータ（*12-bbbb）を含むINVITEを生成する（図１９のステップＳ８０３）。端末ＣはそのINVITEをＳＩＰサーバ１宛てに送信する（図１９のステップＳ８０４）。ＳＩＰサーバ１は、端末ＣからのINVITEを受信するとともに、端末Ｃ宛に100を返信する。端末ＣがＳＩＰサーバ１から100を受信する（図１９のステップＳ８０５）。
【００８１】
ステップＳ５１０：
ステップＳ５００の処理により、端末Ｃの動作状態は「待受中」から「発信中」へ動作状態が変化したので、端末Ｃは、その状態変化を示すNotifyをプレゼンスサーバ宛に送信する（図１９のステップＳ８０６）。プレゼンスサーバではNotifyの受信に応じて、200を端末Ｃに返す。
【００８２】
ステップＳ５９０〜Ｓ７１０
図１８Ａおよび図１８ＢにおけるステップＳ５９０以降の処理は、図１２Ａおよび図１２ＢにおけるステップＳ１９０以降の処理と実質的に同一であるので、以下では簡略化して説明する。
【００８３】
ＳＩＰサーバ１は、ステップＳ５００で端末Ｃから受信したINVITEに含まれる電番のデータ（*12-bbbb）を、メモリ２２内の電番分析テーブルを参照して分析する（ステップＳ５９０）。その結果、ＳＩＰサーバ１は、端末Ｃから受信したINVITEに含まれる電番のデータ（*12-bbbb）が、他局（ＳＩＰサーバ５）の電話番号bbbbに対する局間ピックアップの要求であることを認識する。
ＳＩＰサーバ１は、ステップＳ５９０における分析結果に基づいて、INFOメッセージ（INFO）を生成し、bbbbの電話番号が収容されているＳＩＰサーバ５宛てに送信する（ステップＳ６００）。INFOには、bbbbの電話番号に対する代理応答要求(pickup,bbbb)を示すデータが含まれている。
【００８４】
ＳＩＰサーバ５は、通信端末Ｂの呼出中処理をキャンセルするためのメッセージであるCANCELを端末Ｂ宛に送信し、端末Ｂから200を受信する。さらに、ＳＩＰサーバ５は、端末Ｂから200を受信すると、ＳＩＰサーバ１宛てに200を送信する（ステップＳ６１０）。これにより、端末Ｂの動作状態は「呼出中」から「待受中」へ動作状態が変化したので、端末Ｂは、その状態変化を示すNotifyをプレゼンスサーバ宛に送信する（ステップＳ６２０）。
【００８５】
ＳＩＰサーバ５は、ステップＳ６１０における200の送信に次いで、INFOの送信元サーバであるＳＩＰサーバ１宛てにINVITEを送信し、ＳＩＰサーバ１から100を受信する（ステップＳ６３０）。
【００８６】
次に、以下のステップＳ６４０の処理が行われる。すなわち、ＳＩＰサーバ１は、ステップＳ６３０におけるINVITEの受信に対する200をＳＩＰサーバ５宛てに送信するとともに、ステップＳ５００におけるINVITEの受信に対する200を代理応答端末Ｃ宛に送信する。ＳＩＰサーバ５はＳＩＰサーバ１から200を受信し、端末ＣはＳＩＰサーバ１から200を受信する（図１９のステップＳ８０７）。また、ＳＩＰサーバ５は、ＳＩＰサーバ１から200を受信すると、ステップＳ４２０におけるINVITEの受信に対する200を発信端末Ａ宛に送信する。200を受信したＳＩＰサーバ５、端末ＡおよびＣはそれぞれ、200の送信元宛にACKを送信する。
【００８７】
ステップＳ６３０およびＳ６４０の処理を経て、発信端末Ａと代理応答端末Ｃの間で呼が確立される。その結果、端末Ｃの動作状態は「発信中」から「通信中」へ動作状態が変化したので、ステップＳ６５０において端末Ｃは、その状態変化を示すNotifyをプレゼンスサーバ宛に送信する（図１９のステップＳ８０８）。同様にして、端末Ａの動作状態は「発信中」から「通信中」へ動作状態が変化したので、ステップＳ６６０において端末Ａは、その状態変化を示すNotifyをプレゼンスサーバ宛に送信する。
【００８８】
発信端末Ａと代理応答端末Ｃの間で呼が確立されると、ステップＳ６７０において端末Ａ，Ｃ間でＲＴＰに基づくデータ通信が行われ、いわゆる通話中の状態となる（図１９のステップＳ８０９）。端末Ａ，Ｃ間で通信が終了すると、ステップＳ６８０に示すように、端末ＡはＳＩＰサーバ５宛てにBYEを送信し、ＳＩＰサーバ５はＳＩＰサーバ１宛てにBYEを送信し、ＳＩＰサーバ１は端末Ｃ宛にBYEを送信する。ステップＳ６８０でBYEを受信した端末Ｃの動作状態は「通信中」から「待受中」へ動作状態が変化したので、端末Ｃは、その状態変化を示すNotifyをプレゼンスサーバ宛に送信する。
【００８９】
ステップＳ７００では、ステップＳ６８０のBYEの受信元は、BYEの送信元に対して200を送信する。ステップＳ７００で200を受信した端末Ａの動作状態は「通信中」から「待受中」へ動作状態が変化したので、ステップＳ７１０において端末Ａは、その状態変化を示すNotifyをプレゼンスサーバ宛に送信する。
【００９０】
以上、本実施形態のシステム内の局間ピックアップ時の動作、および各装置の局間ピックアップ時の動作について詳述した。上述したとおり、本実施形態の代理応答方法によれば、第１の実施形態と同様に、ＳＩＰサーバは、自局に収容されている電話番号の通信端末から局間ピックアップの要求があった場合には、電番分析テーブルを参照して呼出中の電話番号が収容されているＳＩＰサーバを特定し、その特定したＳＩＰサーバとの間で呼の中継処理を行う。そのため、代理応答対象の電話番号について他の複数のＳＩＰサーバを個別に検索する必要がなく、局間ピックアップの処理を短時間で完了させることができる。
【００９１】
以上、本発明の実施形態について詳細に説明したが、本発明の呼制御装置、代理応答方法は上記実施形態に限定されず、本発明の主旨を逸脱しない範囲において、種々の改良や変更をしてもよいのは勿論である。
【００９２】
例えば、上述した各実施形態では、発信端末Ａと着信端末Ｂの電話番号が同一のＳＩＰサーバに収容されている場合について説明したが、両者が異なるＳＩＰサーバに収容されている場合についても、同様の局間ピックアップ機能を実現させることができる。
例えば、上述した各実施形態において、仮に着信端末Ｂの電話番号がＳＩＰサーバ４に収容されている場合、電話番号がＳＩＰサーバ１に収容されている端末Ｃから代理応答することができる。具体的には、図１２ＡのステップＳ１４０において、ＳＩＰサーバ５は、ＳＩＰサーバ４（図示せず）宛てにINVITEを送信し、ＳＩＰサーバ４が端末Ｂ宛にINVITEを送信する。また、図１２ＡのステップＳ２００において、ＳＩＰサーバ１は、着信端末Ｂの電話番号がＳＩＰサーバ４に収容されていることを認識した後、そのＳＩＰサーバ４（図示せず）宛てにINFOを送信する。
【００９３】
上述した各実施形態では、代理応答端末からＳＩＰサーバ宛に送信されるINVITE、および、ＳＩＰサーバ間で送受信されるINFOには、ピックアップ特番と呼出中の電話番号を直列に組み立てたデータ（実施形態の例では、*12-bbbb)が含まれるが、このデータ構成は一例に過ぎない。装置間でなされる特定のプロトコルに従い、受信側において、代理応答であることと、代理対象の電話番号（識別情報）とが認識可能であれば、そのデータ構成（データフォーマット）は問わない。
【００９４】
以上の各実施形態に関し、さらに以下の付記を開示する。
【００９５】
（付記１）
通信端末の識別情報を管理して通信端末間の呼を制御し、他の呼制御装置と通信可能な呼制御装置であって、
各通信端末の識別情報と、自装置を含み通信網に接続されている複数の呼制御装置のうち当該識別情報を管理するいずれかの呼制御装置と、が対応付けられている第１情報を記憶する記憶部と、
呼出中の通信端末の識別情報を含む代理応答要求を、識別情報が自装置の管理下にある通信端末から受け、当該要求に応じて前記第１情報を参照して、前記呼出中の通信端末の識別情報を管理する他の呼制御装置を特定する制御部と、
前記制御部によって特定された前記他の呼制御装置宛に、識別情報が自装置の管理下にある通信端末が前記呼出中の通信端末への着信に対して代理応答することを示す第２情報を送信する通信部と、
を備えた、呼制御装置。
【００９６】
（付記２）
前記第２情報は、代理応答を示すピックアップ特番と、第１通信端末の識別情報としての電話番号とを含む、
付記１に記載された呼制御装置。
【００９７】
（付記３）
通信端末と、通信端末の識別情報を管理するとともに通信端末間の呼を制御する複数の呼制御装置と、各通信端末の動作状態を管理する状態管理サーバと、が通信網によって接続されている通信システムにおいて、通信端末が他の通信端末への着信に対して代理応答する代理応答方法であって、
複数の呼制御装置の各々は、通信網に接続されている通信端末ごとに、識別情報と、識別情報を管理する呼制御装置とが対応付けられている第１情報を予め記憶し、
識別情報が第１呼制御装置の管理下にある第１通信端末は、自端末の動作状態が待受中から呼出中に変化した場合、自端末の動作状態を状態管理サーバ宛に通知し、
状態管理サーバは、第１通信端末からの通知に応じて、第１通信端末の識別情報と、第１通信端末の動作状態とを対応付けて記憶し、
識別情報が第１呼制御装置とは異なる第２呼制御装置の管理下にある第２通信端末は、呼出中の動作状態にある前記第１通信端末の識別情報を状態管理サーバから取得し、
第２呼制御装置は、第１通信端末の識別情報を含む代理応答要求を第２通信端末から受け、当該要求に応じて前記第１情報を参照して、第１通信端末の識別情報を管理する呼制御装置として前記第１呼制御装置を特定し、
第２呼制御装置は、特定した第１呼制御装置宛に、識別情報が自装置の管理下にある通信端末が第１通信端末への着信に対して代理応答することを示す第２情報を送信する、
ことを含む、代理応答方法。
【００９８】
（付記４）
第２通信端末は、１または複数の通信端末の識別情報を指定して状態管理サーバに予め通知し、
状態管理サーバは、第２通信端末の識別情報と、第２通信端末によって指定された前記１または複数の通信端末の識別情報とを対応付けて記憶し、
状態管理サーバは、第２通信端末によって指定された前記１または複数の通信端末のいずれかの動作状態が変化する度に、当該動作状態の変化を第２通信端末に対して通知する、
ことをさらに含む、付記３に記載された代理応答方法。
【００９９】
（付記５）
第２通信端末は、１または複数の通信端末の識別情報を指定して状態管理サーバに予め通知し、
状態管理サーバは、第２通信端末の識別情報と、第２通信端末によって指定された前記１または複数の通信端末の識別情報とを対応付けて記憶し、
第２通信端末は、自端末に対する所定の代理応答操作に応じて、状態管理サーバに対し、前記１または複数の通信端末の各々の動作状態の通知を要求し、
第２通信端末は、状態管理サーバから通知された動作状態の中で呼出中の状態の通信端末の識別情報を特定する、
ことをさらに含む、付記３に記載された代理応答方法。
【０１００】
（付記６）
前記第２情報は、代理応答を示すピックアップ特番と、第１通信端末の識別情報としての電話番号とを含む、
付記３〜５のいずれかに記載された代理応答方法。
【符号の説明】
【０１０１】
（通信端末）
１０…ＣＰＵ
１１…通信制御部
１２…プレゼンス処理部
１３…操作入力部
１４…表示部
１５…音声入出力部
１６…バス
（ＳＩＰサーバ）
２０…ＣＰＵ
２１…通信制御部
２２…メモリ
２３…ＨＤＤ
２４…バス
（プレゼンスサーバ）
４０…ＣＰＵ
４１…通信制御部
４２…メモリ
４３…ＨＤＤ
４４…バス
【技術分野】
【０００１】
本発明は、通信端末が他の通信端末への着信に対して代理応答する技術に関する。
【背景技術】
【０００２】
従来、例えば会社内の同一グループにおいて複数の電話機等の通信端末が配置されている場合に、そのグループ内のある通信端末への着信に対し、別の通信端末によって代理応答することが可能である。また、この代理応答の利便性を高めることを可能にするために、呼の発信元や各通信端末の表示画面に他の通信端末の動作状態（圏外、待受中、発信中、呼出中、通信中などの状態）を通知するようにした技術が知られている。例えば、通信端末の表示画面上で、他の通信端末の動作状態や発信元をユーザが確認できれば、代理応答をすべきか否かの判断も容易になる。
【０００３】
他の通信端末の動作状態を通知する技術の一例として、プレゼンスサーバからの情報に基づき、代理応答端末の表示画面において、受信された着信先の番号に対応する通信端末の識別情報の表示を、着信中であることを示す表示に変更するようにしたものが知られている。この代理応答端末では、ユーザ操作に応じて、表示されたいずれかの通信端末の識別情報を選択し、選択された通信端末に代わって応答する。
【０００４】
他の通信端末の動作状態を通知する別の技術の例として、代理応答端末内に、呼制御装置に対して呼出状態にある呼に関わる情報を要求する手段と、呼制御装置から通知された情報に基づいて代理応答する呼を特定した接続要求を発行する手段を備えたものが知られている。呼制御装置から代理応答端末に通知される情報には、呼出中の呼について発信者情報、着信者情報等の情報が含まれる。
【０００５】
比較的大規模なシステムでは、ＳＩＰ（Session Initiation Protocol）サーバ等の呼制御装置が複数設けられ、各通信端末の電話番号はいずれかの呼制御装置の管理下に置かれる。このようなシステムにおいて、ある通信装置（通信端末）が、自装置と異なる呼制御装置の管理下に置かれている電話番号への着信に対して代理応答できるようにすることが好ましい。その理由としては、第１に、例えば会社内のグループ内のすべてのユーザの通信端末の電話番号が同一の呼制御装置（局）の管理下に置かれているとは限らない点がある。第２に、ユーザによるグループの区分けは短期間で見直されうるが、その都度、ユーザが使用する通信端末の電話番号が属する呼制御装置を切り替えるのは煩雑である点がある。
【０００６】
ある通信装置（通信端末）が、自装置と異なる呼制御装置の管理下に置かれている電話番号への着信に対して代理応答できるようにすることに関する技術を以下のものが知られている。すなわち、例えば２つの呼制御システムＡ，Ｂが存在する場合に、システムＡ内の代理応答端末からのピックアップ（代理応答）要求時に、システムＡに着呼があればピックアップ制御を行い、無ければシステムＡとシステムＢをインターワークするシステム間ゲートウェイ装置を介してシステムＢに対して発呼を行うようにしたものが知られている。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２０１０−３４９７５号公報
【特許文献２】特開２００７−１７４００３号公報
【特許文献３】特開２００７−２４３７２７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
自装置と異なる呼制御装置の管理下に置かれている識別情報（例えば電話番号）への着信に対して代理応答できるようにすることに関する技術の一例を挙げたが、この技術によれば、一方のシステム内の代理応答端末からのピックアップ要求に対して他のシステムに呼出中の呼を検索していくことになる。そのため、この例示の技術では、システム内の呼制御装置の数、つまりユーザが増加するほど、各呼制御装置に対して順に呼出中の呼の検索を行うことになり、代理応答端末が代理応答するまでに相当な時間が掛かると考えられる。
【０００９】
よって、発明の１つの側面では、通信端末の識別情報が複数の呼制御装置のいずれかの管理下に置かれている場合に、通信端末が、自装置の識別情報と異なる呼制御装置の管理下に置かれている識別情報を有する通信端末への着信に対して、より短時間で代理応答できるようにした呼制御装置、代理応答方法を提供することを目的とする。
【課題を解決するための手段】
【００１０】
第１の観点では、通信端末の識別情報を管理して通信端末間の呼を制御し、他の呼制御装置と通信可能な呼制御装置が提供される。
この呼制御装置は、
各通信端末の識別情報と、自装置を含み通信網に接続されている複数の呼制御装置のうち当該識別情報を管理するいずれかの呼制御装置と、が対応付けられている第１情報を記憶する記憶部；
呼出中の通信端末の識別情報を含む代理応答要求を、識別情報が自装置の管理下にある通信端末から受け、当該要求に応じて上記第１情報を参照して、上記呼出中の通信端末の識別情報を管理する他の呼制御装置を特定する制御部；
制御部によって特定された上記他の呼制御装置宛に、識別情報が自装置の管理下にある通信端末が上記呼出中の通信端末への着信に対して代理応答することを示す第２情報を送信する通信部；
を備える。
【００１１】
第２の観点では、通信端末と、通信端末の識別情報を管理するとともに通信端末間の呼を制御する複数の呼制御装置と、各通信端末の動作状態を管理する状態管理サーバと、が通信網によって接続されている通信システムにおいて、通信端末が他の通信端末への着信に対して代理応答する代理応答方法が提供される。
この代理応答方法は、
複数の呼制御装置の各々は、通信網に接続されている通信端末ごとに、識別情報と、識別情報を管理する呼制御装置とが対応付けられている第１情報を予め記憶すること；
識別情報が第１呼制御装置の管理下にある第１通信端末は、自端末の動作状態が待受中から呼出中に変化した場合、自端末の動作状態を状態管理サーバ宛に通知すること；
状態管理サーバは、第１通信端末からの通知に応じて、第１通信端末の識別情報と、第１通信端末の動作状態とを対応付けて記憶すること；
識別情報が第１呼制御装置とは異なる第２呼制御装置の管理下にある第２通信端末は、呼出中の動作状態にある上記第１通信端末の識別情報を状態管理サーバから取得すること；
第２呼制御装置は、第１通信端末の識別情報を含む代理応答要求を第２通信端末から受け、当該要求に応じて上記第１情報を参照して、第１通信端末の識別情報を管理する呼制御装置として上記第１呼制御装置を特定すること；
第２呼制御装置は、特定した第１呼制御装置宛に、識別情報が自装置の管理下にある通信端末が第１通信端末への着信に対して代理応答することを示す第２情報を送信すること；
を含む。
【発明の効果】
【００１２】
開示の呼制御装置、代理応答方法によれば、通信端末の識別情報が複数の呼制御装置のいずれかの管理下に置かれている場合に、通信端末は、自装置の識別情報と異なる呼制御装置の管理下に置かれている識別情報を有する通信端末への着信に対して、より短時間で代理応答することができる。
【図面の簡単な説明】
【００１３】
【図１】第１の実施形態のシステムの構成を示す図。
【図２】第１の実施形態における代理応答方法の一例を概念的に示す図。
【図３】第１の実施形態の通信端末の構成の主要部を示すブロック図。
【図４】状態要求リストと状態通知リストの内容を示す図。
【図５】第１の実施形態のＳＩＰサーバの構成の主要部を示すブロック図。
【図６】電番分析テーブルの例を示す図。
【図７】第１の実施形態のプレゼンスサーバの構成の主要部を示すブロック図。
【図８】プレゼンスサーバの例を示す図。
【図９】登録端末リストの例を示す図。
【図１０】本実施形態のプレゼンスサーバが通信端末から特定のメッセージを受信したときの処理を示すフローチャート。
【図１１】本実施形態のプレゼンスサーバが通信端末から特定のメッセージを受信したときの処理を示すフローチャート。
【図１２Ａ】第１の実施形態のシステム内の動作を示すフローチャート。
【図１２Ｂ】第１の実施形態のシステム内の動作を示すフローチャート。
【図１３】第１の実施形態の発信端末の動作の一部を示すフローチャート。
【図１４】第１の実施形態の着信端末の動作の一部を示すフローチャート。
【図１５】第１の実施形態の代理応答端末の動作の一部を示すフローチャート。
【図１６Ａ】着信端末の電話番号が収容されているＳＩＰサーバの動作を示すフローチャート。
【図１６Ｂ】着信端末の電話番号が収容されているＳＩＰサーバの動作を示すフローチャート。
【図１７Ａ】代理応答端末の電話番号が収容されているＳＩＰサーバの動作を示すフローチャート。
【図１７Ｂ】代理応答端末の電話番号が収容されているＳＩＰサーバの動作を示すフローチャート。
【図１８Ａ】第２の実施形態のシステム内の動作を示すフローチャート。
【図１８Ｂ】第２の実施形態のシステム内の動作を示すフローチャート。
【図１９】第２の実施形態の代理応答端末の動作の一部を示すフローチャート。
【発明を実施するための形態】
【００１４】
（１）第１の実施形態
以下、第１の実施形態について説明する。
なお、以下の各実施形態の説明において、電話番号は、通信端末の識別情報の一例である。通信端末の識別情報は特に限定するものではないが、他にＩＰアドレス等が適用されうる。
【００１５】
（１）システム構成
本実施形態のシステム構成を図１に示す。本実施形態のシステムでは、通信網ＮＷに対して、複数のＳＩＰサーバ（局）１，２，３，４，５…と、複数の通信端末（以下、適宜「端末」と略記する。）Ａ，Ｂ，Ｃ，Ｄ，…と、プレゼンスサーバＰＳとが接続されている。複数の通信端末の各々の電話番号（以下、適宜「電番」と略記する。）は複数のＳＩＰサーバのいずれかの管理下に置かれており、ＳＩＰサーバが通信端末間の呼を制御する。プレゼンスサーバＰＳは、通信網ＮＷに接続されている各通信端末の動作状態（圏外、待受中、発信中、呼出中、通信中などの状態）を管理している。各通信端末は、プレゼンスサーバＰＳから通信される情報を参照して他の通信端末の動作状態を表示することが可能となっている。各通信端末の通信網ＮＷへの接続形態は特に限定しないが、例えば無線ＬＡＮ(Local Area Network)または有線ＬＡＮである。
なお、ＳＩＰサーバは呼制御装置の一例であり、プレゼンスサーバは状態管理サーバの一例である。
【００１６】
（２）本実施形態における代理応答
本実施形態では、通信端末が、自装置の電話番号と異なるＳＩＰサーバの管理下に置かれている（つまり、異なるＳＩＰサーバに収容されている）電話番号の通信端末への着信に対して代理応答する場合（以下、適宜「局間ピックアップ」という。）を想定する。図２に、本実施形態における代理応答方法の一例を概念的に示す。
【００１７】
図２に示す例では、通信端末Ａと通信端末Ｂの電話番号がＳＩＰサーバ５に収容されており、通信端末Ｃの電話番号がＳＩＰサーバ１に収容されている。このとき、通信端末Ａから通信端末Ｂへ発信された呼（つまり、通信端末Ｂの着信）に対して、通信端末Ａ，Ｂとは異なるＳＩＰサーバに属している電話番号の通信端末Ｃが代理応答する場合を想定する。プレゼンスサーバは、各通信端末から動作状態が変化する度に通知される情報に基づいて、通信端末の電話番号と、その通信端末の動作状態とを対応付けたプレゼンスデータを記憶および更新している。図２において、Subscribeは通信端末からプレゼンスサーバ宛に送信される、通信端末の登録メッセージであり、Notifyはプレゼンスサーバと通信端末の間でプレゼンスデータに変更があった場合に変更された情報について通知するためのメッセージである。一例として通信端末Ｃの表示画面（プレゼンス表示画面）を示すように、各通信端末では、通信網に接続されている複数の通信端末の動作状態が表示される。図２では「Ａさん」に対応して「発信中」と表示された例が示されているが、各通信端末あるいはプレゼンスサーバでは、「Ａさん」と電話番号（例えばaaaa）とが対応付けられているものとする。
【００１８】
図２において、通信端末Ａのユーザが通信端末Ｂの電話番号であるbbbbをダイヤルすると、ＳＩＰサーバ５を経由して通信端末Ｂが呼出中となり、通信端末Ｂの動作状態の変化（待受中→呼出中）がプレゼンスサーバへ通知される。この通知に応じて、プレゼンスサーバにてプレゼンスデータが更新されると、その更新されたデータが通信端末Ｃに通知されて、通信端末Ｃの表示画面上に表示される（Ｂさん−呼出中）。この表示内容を見た通信端末Ｃのユーザが、例えば表示画面上で「Ｂさん」を選択すると通信端末Ｃが代理応答処理（ピックアップ処理）を開始する。すなわち、通信端末Ｃは、ピックアップを表す特番（ピックアップ特番：この実施形態では、一例として「*12」）と、呼出中の電話番号(Ｂさんの電話番号であるbbbb)とを含むデータ(*12-bbbb；後述するINVITEに含まれる)をＳＩＰサーバ１宛てに送信する。
【００１９】
ＳＩＰサーバ１は、通信端末Ｃから受信したデータ(*12-bbbb)を分析することによって、通信端末Ｃによる代理応答要求であること、および、呼出中の電話番号bbbb（通信端末Ｂ）がＳＩＰサーバ１に収容されていることを認識する。この認識処理については後述する。その結果、通信端末Ｂへの着信に対する通信端末Ｃの代理応答を行うことを可能にするため、INFOメッセージ（以下、適宜単にINFOという。）を生成してＳＩＰサーバ５宛てに送信する。これによって、ＳＩＰサーバ５は通信端末Ｂの呼出中処理をキャンセルする。その後、ＳＩＰサーバ１とＳＩＰサーバ５の間で、代理応答のための呼制御が行われる。
【００２０】
（３）システム内の各装置の構成および機能
以下、図３〜１１を参照して、本実施形態のシステム内の各装置の構成および機能について説明する。
【００２１】
（３−１）通信端末
図３は、本実施形態の通信端末の構成の主要部を示すブロック図である。図３に示すように、本実施形態の通信端末は、ＣＰＵ１０、通信制御部１１、プレゼンス処理部１２、操作入力部１３、表示部１４、音声入出力部１５、および、データバスおよび制御バスを含むバス１６を備える。
ＣＰＵ１０は、通信端末内の各部とバス１６によって信号を送受信可能に構成され、通信端末の機能を実現するための全体の制御を行う。
通信制御部１１は、ＣＰＵ１０による制御の下で、自端末の電話番号が収容されているＳＩＰサーバとの間で通信網ＮＷを経由してＳＩＰ（Session Initiation Protocol）に従ったメッセージの送受信を行う。いったん呼が確立されると、ＲＴＰ(Real-time Transport Protocol)に従って端末間でデータ転送が行われ、通話における音声の信号処理が音声入出力部１５にて行われる。なお、通信制御部１１とＳＩＰサーバとの通信は、無線でも有線でもよい。
【００２２】
通信制御部１１は、ＣＰＵ１０による制御の下で、プレゼンスサーバとの間で通信網ＮＷを経由して、メッセージの送受信を行う。通信制御部１１は例えば、自端末の登録メッセージ（Subscribe）の送信、自端末の動作状態の変化についての通知メッセージ（Notify）の送信、あるいは他の端末の動作状態の変化について通知メッセージ（Notify）の受信の処理を行う。なお、通信端末とプレゼンスサーバとの間で通信網に接続されている他の通信端末の動作状態についてのデータ送受信が可能であれば、通信端末とプレゼンスサーバの間の通信に使用される通信プロトコルは問わない。また、通信制御部１１とプレゼンスサーバとの通信形態は、無線でも有線でもよい。
【００２３】
プレゼンス処理部１２は、通信制御部１１で受信した、プレゼンスサーバからのメッセージの解析処理、メッセージの解析結果に応じた表示処理、プレゼンスサーバ宛のメッセージの生成処理等を行う。例えば、プレゼンスサーバへ送信するSubscribeには、図４（ａ）に例示する状態要求リストが含まれる。状態要求リストは、動作状態を取得したい電話番号の一覧を指定した情報である。図４（ａ）に示す例では、３個の電話番号aaaa, bbbb, ddddについて指定されている。また、プレゼンスサーバから受信するNotifyには、図４（ｂ）に例示する状態通知リストが含まれる。状態通知リストは、状態要求リストを含むSubscribeに応じてプレゼンスサーバから通知されるリストである。図４（ｂ）には、電話番号aaaaの通信端末は「発信中」であり、電話番号bbbbの通信端末は「呼出中」であり、電話番号ddddの通信端末は「圏外」であることが通知される例が示される。
【００２４】
また、プレゼンス処理部１２は、自端末の動作状態の変化を検出すると、自端末の電話番号と自端末の動作状態とを含むNotifyを生成する。このNotifyは、通信制御部１１からプレゼンスサーバ宛に送信される。
【００２５】
ある通信端末から送信される状態要求リストに含まれる、動作状態を取得したい電話番号の一覧には、典型的な例としては、その通信端末のユーザと同一グループ内の他の１または複数のユーザの電話番号が含まれる。つまり、一覧には、通信端末のユーザが代理応答する可能性のある他のユーザの通信端末の電話番号が含まれる。例えば、通信端末Ａ（電話番号aaaa）、通信端末Ｂ（電話番号bbbb）、通信端末Ｃ（電話番号cccc）、通信端末Ｄ（電話番号dddd）のユーザが同一グループである場合、図４（ａ）に示す状態要求リストは、通信端末Ｃから送信される。
【００２６】
ＣＰＵ１０は表示部１４を制御し、プレゼンス処理部１２で取得した状態通知リストの内容を再構成する等して表示画面（プレゼンス表示画面）に表示する。これにより、通信端末のユーザは、他の通信端末の動作状態を視認することができる。なお、操作入力部１３はＣＰＵ１０と協働して、表示画面に表示された状態の状態通知リストの中から、「呼出中」の通信端末のいずれかを選択操作（代理応答操作）、あるいは所定のピックアップ特番のダイヤル操作（代理応答操作）を受け入れる。
【００２７】
ＣＰＵ１０は、「呼出中」の通信端末が選択されると、ピックアップ特番（この実施形態では、一例として「*12」）と、呼出中の電話番号とを含むデータ(図２に示した例では、*12-bbbb)を組み立て、そのデータを含むメッセージを通信制御部１１から自端末の電話番号が収容されているＳＩＰサーバ宛てに送信する。
【００２８】
（３−２）ＳＩＰサーバ
図５は、本実施形態のＳＩＰサーバの構成の主要部を示すブロック図である。図５に示すように、本実施形態のＳＩＰサーバは、ＣＰＵ２０、通信制御部２１、メモリ２２、ＨＤＤ（Hard Disk Drive；ハードディスク駆動装置）２３、および、データバスおよび制御バスを含むバス２４を備える。なお、ＨＤＤ２３には、バックアップのためのデータが記憶されている。
ＣＰＵ２０は、ＳＩＰサーバ内の各部とバス２４によって信号を送受信可能に構成され、ＳＩＰサーバの機能を実現するための全体の制御を行う。ＣＰＵ２０は、制御部の一例である。
通信制御部２１は、ＣＰＵ２０による制御の下で、自サーバが管理する電話番号の通信端末との間、および、通信網ＮＷに接続されている他のＳＩＰサーバとの間で、通信網ＮＷを経由してＳＩＰに従ったメッセージの送受信を行う。このとき、ＣＰＵ２０は、メモリ２２内の呼処理プログラムを解釈して、通信制御部２１に対する制御を含む呼処理（セッション制御処理）を実行する。通信制御部２１は、通信部の一例である。
【００２９】
メモリ２２には、上記呼処理プログラムのほか、電番分析テーブルを含む局データと、端末データとが記憶されている。メモリ２２は、記憶部の一例である。
電番分析テーブルには、通信網ＮＷに接続されているすべての通信端末の電話番号と、各電話番号が収容されているＳＩＰサーバとが対応付けられている。また、電番分析テーブルには、特番と、その特番のサービスとが対応付けられている。電番分析テーブルの例を図６に示す。図６（ａ），（ｂ）に示す例では、それぞれＳＩＰサーバ１，５に含まれる電番分析テーブルの例が示される。図６（ａ）のＳＩＰサーバ１内の電番分析テーブルの例では、電話番号aaaa，bbbbがＳＩＰサーバ５に収容され、電話番号cccc，ddddがそれぞれ自局収容の（つまり、自サーバ内に収容されている）通信端末Ｃ，Ｄであることを示している。図６（ｂ）のＳＩＰサーバ５内の電番分析テーブルの例では、電話番号cccc，ddddがＳＩＰサーバ１に収容され、電話番号aaaa，bbbbがそれぞれ自局収容の通信端末Ａ，Ｂであることを示している。また、*12がピックアップサービス、つまり代理応答を示す特番であることが示される。
なお、電番分析テーブルは、第１情報の一例である。
【００３０】
端末データは、自サーバが収容している電話番号と、通信網ＮＷ上でユニークな識別情報とが対応付けられている。例えば、通信網ＮＷとしてＩＰネットワークを利用する場合、通信制御部２１は、端末データを参照し、電話番号に対応する発信元および着信先のＩＰアドレスを特定する。
【００３１】
自サーバに属している電話番号の通信端末が、他サーバに属している電話番号の通信端末への着信に対して代理応答する機能（局間ピックアップ機能）は、呼処理プログラムをＣＰＵ２０が解釈して実行することにより実現される。局間ピックアップ機能では、自サーバに属している電話番号の通信端末から、ピックアップ特番（この実施形態では、一例として「*12」）と、呼出中の電話番号とを含むデータ(図２に示した例では、*12-bbbb)を受信すると、そのデータに含まれる番号を、メモリ２２内の電番分析テーブルを参照して分析する。例えば、図６（ａ）に示した例において、ＳＩＰサーバ１が、通信端末から*12-bbbbのデータを受信した場合、そのデータが電話番号bbbbに対する代理応答要求であること意味するため、bbbbをキーとして電番分析テーブルを検索する。その結果、ＳＩＰサーバ１は、bbbbがＳＩＰサーバ５に収容されていることが分かるため、INFOメッセージ（INFO）を生成してＳＩＰサーバ５宛てに送信する。INFOは、あるＳＩＰサーバが他のＳＩＰサーバに対し、他のＳＩＰサーバに収容されている電話番号の着信に対して代理応答を行うときに送信される。INFOを受信した他のサーバは、そのINFOが示す電話番号に対する呼出の処理をキャンセルする等、代理応答についての所定の手続きを行う。
INFOメッセージは、第２情報の一例である。
【００３２】
（３−３）プレゼンスサーバ
図７は、本実施形態のプレゼンスサーバの構成の主要部を示すブロック図である。図７に示すように、本実施形態のプレゼンスサーバは、ＣＰＵ４０、通信制御部４１、メモリ４２、ＨＤＤ４３、および、データバスおよび制御バスを含むバス４４を備える。なお、ＨＤＤ４３には、バックアップのためのデータが記憶されている。
ＣＰＵ４０は、プレゼンスサーバ内の各部とバス４４によって信号を送受信可能に構成され、プレゼンスサーバの機能を実現するための全体の制御を行う。
【００３３】
通信制御部４１は、ＣＰＵ４０による制御の下で、通信網ＮＷに接続されている複数の通信端末との間で、通信網ＮＷを経由してメッセージの送受信を行う。通信制御部４１は例えば、各通信端末からの登録メッセージ（Subscribe）の受信、各通信端末の動作状態の変化についての通知メッセージ（Notify）の受信、あるいは各通信端末の動作状態の変化について通知メッセージ（Notify）の送信の処理を行う。
【００３４】
ＣＰＵ４０は、メモリ４２内のプレゼンスサービスプログラムを解釈して実行することにより、通信網ＮＷに接続されている各通信端末に対してプレゼンスサービス機能を提供する。プレゼンスサービス機能には、各通信端末の登録、各通信端末からの他の通信端末の動作状態の要求に対する応答などが含まれる。例えば、ＣＰＵ４０は、通信制御部４１で受信した、通信端末からのメッセージの解析処理、メッセージの解析結果に応じた処理、通信端末宛のメッセージの生成処理等を行う。例えば、通信制御部４１が受信するSubscribeには、図４（ａ）に例示した状態要求リストが含まれる。また、通信端末宛に送信するNotifyには、図４（ｂ）に例示した状態通知リストが含まれる。
【００３５】
メモリ４２には、上記プレゼンスサービスプログラムのほか、プレゼンスデータと、端末登録リストとが記憶されている。プレゼンスデータは、プレゼンスサーバに登録している電話番号と、その電話番号の通信端末の動作状態（圏外、待受中、発信中、呼出中、通信中などの状態）とが対応付けられたデータであり、その一例を図８に示す。ＣＰＵ４０は、各通信端末から動作状態が変化する度に送信されるNotifyに基づいて、プレゼンスデータの内容を更新する。また、ＣＰＵ４０は、通信端末から状態要求リストを受信すると、プレゼンスデータを参照して、状態要求リストで指定された通信端末の動作状態を取得して、通信端末宛の状態通知リストを生成する。
【００３６】
登録端末リストは、Subscribeを送信した通信端末の電話番号と、Subscribeに含まれる状態要求リストに含まれる電話番号とが対応付けられているデータであり、その一例を図９に示す。図９に示す例では、例えば前述したように、通信端末Ａ（電話番号aaaa）、通信端末Ｂ（電話番号bbbb）、通信端末Ｃ（電話番号cccc）、通信端末Ｄ（電話番号dddd）のユーザが同一グループである場合が想定されている。このとき、登録端末リストでは、電話番号aaaaと、同一グループ内の他の電話番号（bbbb, cccc, dddd）とが対応付けられる。
【００３７】
以下、通信端末からメッセージを受信したときにＣＰＵ４０によって実行される処理について、図１０および図１１を参照して説明する。図１０は、通信端末からSubscribeを受信したときの処理である。図１１は、通信端末からNotifyを受信したときの処理である。
図１０において、プレゼンスサーバのＣＰＵ４０は、通信端末からSubscribeを受信すると（ステップＳ１０のＹｅｓ）、登録端末リストを更新する。つまり、Subscribeには、状態要求リスト（図４（ａ）参照）が含まれているので、ＣＰＵ４０は、Subscribeを送信した通信端末の電話番号と、リスト内で指定されている電話番号とを、登録端末リスト内で対応付ける。次にＣＰＵ４０は、プレゼンスデータを参照して、受信したSubscribe内の登録端末リストの各電話番号に対応した動作状態を取得する。そして、ＣＰＵ４０は、指定された電話番号に対応した動作状態を含む状態通知リスト（図４（ｂ）参照）を生成し（ステップＳ１３）、この状態通知リストを含むNotifyを、ステップＳ１０でSubscribeを送信した通信端末へ送信する（ステップＳ１４）。
【００３８】
図１１において、プレゼンスサーバのＣＰＵ４０は、通信端末からNotifyを受信すると（ステップＳ２０のＹｅｓ）、プレゼンスデータを更新する。つまり、Notifyには、ステップＳ２０でNotifyを送信した通信端末の電話番号と、その通信端末の動作状態とが含まれているので、これらの情報に基づいてＣＰＵ４０はプレゼンスデータを更新する（ステップＳ２１）。その後、ＣＰＵ４０は通信制御部４１を制御して、ＳＩＰに従ったメッセージである200 OKを通信端末宛に返送する（ステップＳ２２）。次に、ステップＳ２０でNotifyを送信した通信端末の動作状態の変化を、例えば、その通信端末の電話番号と同一グループ内の他の電話番号の通信端末へ通知するために、登録端末リストが参照される。他の電話番号の通信端末への通知は、更新された状態通知リストを含むNotifyが使用される（ステップＳ２３）。
【００３９】
（４）システム内の動作および各装置の動作
以下、図１２Ａ〜１７Ｂを参照して、本実施形態のシステム内の局間ピックアップ時の動作、および各装置の局間ピックアップ時の動作について説明する。
図１２Ａ，図１２Ｂは、本実施形態のシステム内の動作を示すフローチャートである。図１３は、発信端末Ａの動作の一部を示すフローチャートである。図１４は、着信端末Ｂの動作の一部を示すフローチャートである。図１５は、代理応答端末（ピックアップ端末）Ｃの動作の一部を示すフローチャートである。図１６Ａ，図１６Ｂは、以下の説明におけるＳＩＰサーバ５（着信端末Ｂの電話番号が収容されているＳＩＰサーバ）の動作を示すフローチャートである。図１７Ａ，図１７Ｂは、以下の説明におけるＳＩＰサーバ１（代理応答端末Ｃの電話番号が収容されているＳＩＰサーバ）の動作を示すフローチャートである。
なお、以下の説明では、発信端末Ａと着信端末Ｂの電話番号はＳＩＰサーバ５に収容されており、代理応答端末Ｃの電話番号はＳＩＰサーバ１に収容されているものとする。また、以下の説明において、着信端末Ｂは第１通信端末の一例であり、ＳＩＰサーバ５は第１呼制御装置の一例である。代理応答端末Ｃは第２通信端末の一例であり、ＳＩＰサーバ１は第２呼制御装置の一例である。
【００４０】
以下では、基本的に、図１２Ａ，図１２Ｂのフローを参照して全体の動作を時系列上で説明しつつ、適宜個々の装置の動作を補足的に付すことにする。また、各図では、ＳＩＰで定義されているメッセージを以下のとおり簡略的に記載してある。
【００４１】
・100…100 Trying （受信完了を知らせ、INVITEの再送を止める）
・180…180 Ringing （呼出中）
・200…200 OK （要求が成功したことを示す）
・4xx…リクエスト失敗
・404…404 Not Found （ユーザが見つからないことを示す）
・INVITE…セッション開始
・CANCEL…キャンセル
・ACK…セッション確立確認
・BYE…セッション終了
【００４２】
ステップＳ１００：
先ず、通信網に接続されている端末Ａ，Ｂ，Ｃは、状態要求リストを含むSubscribeをプレゼンスサーバ宛に送信する。状態要求リストでは、各端末が動作状態を取得したい電話番号の一覧が指定される。ここでは、端末Ａ，Ｂ，Ｃのユーザが同一グループ内である場合を想定する。この場合、端末Ａは、動作状態を取得したい電話番号として、端末Ｂの電話番号(bbbb)と端末Ｃ(cccc)の電話番号を指定する。端末Ｂは、動作状態を取得したい電話番号として、端末Ａの電話番号(aaaa)と端末Ｃ(cccc)の電話番号を指定する。端末Ｃは、動作状態を取得したい電話番号として、端末Ａの電話番号(aaaa)と端末Ｂ(bbbb)の電話番号を指定する。各端末からSubscribeを受信したプレゼンスサーバは、端末Ａ〜Ｃを登録、つまり登録端末リスト（図９参照）を更新し、各端末宛に200を返す。
【００４３】
ステップＳ１１０：
ここで、端末Ａのユーザがbbbb（端末Ｂの電話番号）のダイヤル操作を行う。
【００４４】
ステップＳ１２０：
ステップＳ１１０のダイヤル操作により、端末Ａは電話番号bbbbを指定したINVITEをＳＩＰサーバ５宛てに送信し、ＳＩＰサーバ５は端末Ａに100を返す（図１３のステップＳ３０，Ｓ３１、図１６ＡのステップＳ６０，Ｓ６１）。
【００４５】
ステップＳ１３０：
ステップＳ１２０の処理により、端末Ａの動作状態は「待受中」から「発信中」へ動作状態が変化したので、端末Ａは、その状態変化を示すNotifyをプレゼンスサーバ宛に送信する（図１３のステップＳ３２）。プレゼンスサーバでは、端末Ａの動作状態の変化に基づきプレゼンスデータを更新するとともに、端末Ａの動作状態の変化を他の端末Ｂ，Ｃに通知するため、端末状態通知リストを含むNotifyを端末Ｂ，Ｃ宛に送信し、その後、端末Ｂ，Ｃから200を受信する。これにより、各端末におけるプレゼンス表示画面が更新される。
【００４６】
ステップＳ１４０：
ＳＩＰサーバ５は、ステップＳ１２０で端末Ａから送信されたINVITEに含まれる電話番号を分析して着信先が電話番号bbbbであることが分かると、電話番号bbbbの端末Ｂ宛てにINVITEを送信する（図１６ＡのステップＳ６２，Ｓ６３）。端末ＢはこのINVITEを受信する（図１４のステップＳ４０）。このINVITEに応じて端末Ｂは、100および180（呼出中）をＳＩＰサーバ５宛てに送信する（図１４のステップＳ４１，Ｓ４２）。ＳＩＰサーバ５は、端末Ｂから100および180を受信する（図１６ＡのステップＳ６４，Ｓ６５）。端末Ｂから180を受信すると、ＳＩＰサーバ５は、180を発信端末Ａ宛に送信する。端末Ａは、この180を受信する（図１３のステップＳ３３）。これにより、端末Ａにおいて所定の発信音出力がなされ、端末Ａが「発信中」であることが端末Ａのユーザに認識される（図１３のステップＳ３４）。このようにして、発信端末Ａから着信端末Ｂへの呼出中の状態となる（図１４のステップＳ４３、図１６ＡのステップＳ６６）。
【００４７】
なお、図１２Ａには記載されていないが、ここで仮に、ＳＩＰサーバ５が端末Ａから200を受信したならば（図１６ＡのステップＳ６７）、端末Ａと端末Ｂの間で通信中（通話中）の状態となる（図１６ＡのステップＳ６８）。
【００４８】
ステップＳ１５０：
ステップＳ１４０の処理により、端末Ｂの動作状態は「待受中」から「呼出中」へ動作状態が変化したので、端末Ｂは、その状態変化を示すNotifyをプレゼンスサーバ宛に送信する（図１４のステップＳ４４）。プレゼンスサーバでは、端末Ｂの動作状態の変化に基づきプレゼンスデータを更新するとともに、端末Ｂの動作状態の変化を他の端末Ａ，Ｃに通知するため、端末状態通知リストを含むNotifyを端末Ａ，Ｃ宛に送信し、その後、端末Ａ，Ｃから200を受信する。これにより、各端末におけるプレゼンス表示画面が更新される。
【００４９】
ステップＳ１６０：
端末Ｃにおいてプレゼンス表示画面が表示される（図１５のステップＳ５０）。ここで、端末Ｃのユーザは、プレゼンス表示画面上で端末Ｂが「呼出中」であることを視認し、端末Ｂを選択する操作を行うこと等によって（図１５のステップＳ５１のＹＥＳ）、コールピックアップ、すなわち、端末Ｂへの着信に対して代理応答する操作を行う。
【００５０】
ステップＳ１７０：
ステップＳ１６０の操作により、端末Ｃは、ピックアップ特番である*12と、代理応答対象の電話番号（ここでは、端末Ｂのbbbb）とを順に組み立てた電番のデータ（*12-bbbb）を含むINVITEを生成する（図１５のステップＳ５２）。端末ＣはそのINVITEをＳＩＰサーバ１宛てに送信する（図１５のステップＳ５３）。ＳＩＰサーバ１は、端末ＣからのINVITEを受信するとともに、端末Ｃ宛に100を返信する（図１７ＡのステップＳ８０，Ｓ８１）。端末ＣがＳＩＰサーバ１から100を受信する（図１５のステップＳ５４）。
なお、ここで端末Ｃから送信されるINVITEは、代理応答要求の一例である。
【００５１】
ステップＳ１８０：
ステップＳ１７０の処理により、端末Ｃの動作状態は「待受中」から「発信中」へ動作状態が変化したので、端末Ｃは、その状態変化を示すNotifyをプレゼンスサーバ宛に送信する（図１５のステップＳ５５）。プレゼンスサーバでは、端末Ｃの動作状態の変化に基づきプレゼンスデータを更新するとともに、端末Ｃの動作状態の変化を他の端末Ａ，Ｂに通知するため、端末状態通知リストを含むNotifyを端末Ａ，Ｂ宛に送信し、その後、端末Ａ，Ｂから200を受信する。これにより、各端末におけるプレゼンス表示画面が更新される。
【００５２】
ステップＳ１９０：
ＳＩＰサーバ１は、ステップＳ１７０で端末Ｃから受信したINVITEに含まれる電番のデータ（*12-bbbb）を、メモリ２２内の電番分析テーブルを参照して分析する（図１７ＡのステップＳ８２）。具体的には、ＳＩＰサーバ１は、INVITEに含まれる電番のデータ（*12-bbbb）の先頭のコードが“*12”でない場合には（図１７ＡのステップＳ８３のＮＯ）、例えば局内通話等の通常の呼処理を行い、先頭のコードが“*12”である場合には（図１７ＡのステップＳ８３のＹＥＳ）、さらに後続コードを分析する（図１７ＡのステップＳ８５）。つまり、後続コード（本実施形態の場合には“bbbb”）が示す電話番号が自局収容の電話番号であるか否か判定する（図１７ＡのステップＳ８６）。つまり、ＳＩＰサーバ１は電番分析テーブルを参照して、後続コードが示す電話番号が収容されているＳＩＰサーバを特定する。以上の分析結果から、ＳＩＰサーバ１は、端末Ｃから受信したINVITEに含まれる電番のデータ（*12-bbbb）が、他局（ＳＩＰサーバ５）の電話番号bbbbに対する局間ピックアップの要求であることを認識する。
【００５３】
なお、図１２Ａおよび図１２Ｂには示していないが、仮に後続コードが示す電話番号bbbbが自局収容の電話番号であると判定した場合には（図１７ＡのステップＳ８７）、ＳＩＰサーバ１において以下の局内ピックアップ処理が行われる。すなわち、ＳＩＰサーバ１は、自局収容の電話番号bbbbの端末Ｂに対してCANCELを送信し、端末Ａおよび端末Ｃ宛に200を送信し、端末Ａおよび端末ＣからACKを受信する処理を経て、端末Ａ，Ｃ間で通信中となる（図１７ＡのステップＳ８７〜Ｓ９０）。
【００５４】
ステップＳ２００：
ＳＩＰサーバ１は、ステップＳ１９０における分析結果に基づいて、INFOメッセージ（INFO）を生成し（図１７ＢのステップＳ９１）、bbbbの電話番号が収容されているＳＩＰサーバ５宛てに送信する（図１７ＢのステップＳ９２）。ＳＩＰサーバ５はINFOを受信する（図１６ＡのステップＳ６９）。INFOには、bbbbの電話番号に対する代理応答要求(pickup,bbbb)を示すデータが含まれている。
【００５５】
ステップＳ２１０：
ＳＩＰサーバ５は、ＳＩＰサーバ１からINFOを受信し、INFOの内容がbbbbの電話番号（つまり、自局収容の電話番号）に対する代理応答要求であることを認識すると（図１６ＢのステップＳ７０のＹＥＳ）、通信端末Ｂの呼出中処理をキャンセルするためのメッセージであるCANCELを端末Ｂ宛に送信する（図１６ＢのステップＳ７２）。端末Ｂは、ＳＩＰサーバ５からCANCELを受信すると（図１４のステップＳ４５）、200をＳＩＰサーバ５宛てに送信する（図１４のステップＳ４６）。ＳＩＰサーバ５は、端末Ｂから200を受信すると、ＳＩＰサーバ１宛てに200を送信する（図１６ＢのステップＳ７３）。ＳＩＰサーバ１では、ＳＩＰサーバ５から信号を受信し、その受信信号が200であることを認識する（図１７ＢのステップＳ９３、Ｓ９４のＹＥＳ）。
【００５６】
なお、INFOの内容が自局収容の電話番号でない場合には（図１６ＢのステップＳ７０のＮＯ）、ＳＩＰサーバ５は、ＳＩＰサーバ１宛てに404を送信し（図１６ＢのステップＳ７１）、端末Ａから端末Ｂを呼出中の状態（図１６ＡのステップＳ６６）へ戻る。
【００５７】
ステップＳ２２０：
ステップＳ２１０の処理により、端末Ｂの動作状態は「呼出中」から「待受中」へ動作状態が変化したので、端末Ｂは、その状態変化を示すNotifyをプレゼンスサーバ宛に送信する。プレゼンスサーバでは、端末Ｂの動作状態の変化に基づきプレゼンスデータを更新するとともに、端末Ｂの動作状態の変化を他の端末Ａ，Ｃに通知するため、端末状態通知リストを含むNotifyを端末Ａ，Ｃ宛に送信し、その後、端末Ａ，Ｃから200を受信する。これにより、各端末におけるプレゼンス表示画面が更新される。
【００５８】
ステップＳ２３０：
ＳＩＰサーバ５は、ステップＳ２１０における200の送信に次いで、INFOの送信元サーバであるＳＩＰサーバ１宛てにINVITEを送信する（図１６ＢのステップＳ７４）。ＳＩＰサーバ１は、ＳＩＰサーバ５からINVITEを受信するとともに（図１７ＢのステップＳ９６）、このINVITE受信に応じてＳＩＰサーバ５宛てに100を送信する。ＳＩＰサーバ５は、ＳＩＰサーバ１から100を受信する（図１６ＢのステップＳ７５）。
【００５９】
ステップＳ２４０：
ＳＩＰサーバ１は、ステップＳ２３０におけるINVITEの受信に対する200をＳＩＰサーバ５宛てに送信するとともに（図１７ＢのステップＳ９７）、ステップＳ１７０におけるINVITEの受信に対する200を代理応答端末Ｃ宛に送信する。ＳＩＰサーバ５はＳＩＰサーバ１から200を受信し（図１６ＢのステップＳ７６）、端末ＣはＳＩＰサーバ１から200を受信する（図１５のステップＳ５６）。
また、ＳＩＰサーバ５は、ＳＩＰサーバ１から200を受信すると、ステップＳ１２０におけるINVITEの受信に対する200を発信端末Ａ宛に送信する。端末Ａは、ＳＩＰサーバ５から200を受信する（図１３のステップＳ３５）。
200を受信したＳＩＰサーバ５、端末ＡおよびＣはそれぞれ、200の送信元宛にACKを送信する（図１６ＢのステップＳ７７、図１７ＢのステップＳ９８）。
ステップＳ２３０およびＳ２４０の処理を経て、発信端末Ａと代理応答端末Ｃの間で呼が確立される。
【００６０】
ステップＳ２５０：
ステップＳ２３０およびＳ２４０の処理により、端末Ｃの動作状態は「発信中」から「通信中」へ動作状態が変化したので、端末Ｃは、その状態変化を示すNotifyをプレゼンスサーバ宛に送信する（図１５のステップＳ５７）。プレゼンスサーバでは、端末Ｃの動作状態の変化に基づきプレゼンスデータを更新するとともに、端末Ｃの動作状態の変化を他の端末Ａ，Ｂに通知するため、端末状態通知リストを含むNotifyを端末Ａ，Ｂ宛に送信し、その後、端末Ａ，Ｂから200を受信する。これにより、各端末におけるプレゼンス表示画面が更新される。
【００６１】
ステップＳ２６０：
ステップＳ２３０およびＳ２４０の処理により、端末Ａの動作状態は「発信中」から「通信中」へ動作状態が変化したので、端末Ａは、その状態変化を示すNotifyをプレゼンスサーバ宛に送信する（図１３のステップＳ３６）。プレゼンスサーバでは、端末Ａの動作状態の変化に基づきプレゼンスデータを更新するとともに、端末Ａの動作状態の変化を他の端末Ｂ，Ｃに通知するため、端末状態通知リストを含むNotifyを端末Ｂ，Ｃ宛に送信し、その後、端末Ｂ，Ｃから200を受信する。これにより、各端末におけるプレゼンス表示画面が更新される。
【００６２】
ステップＳ２７０：
発信端末Ａと代理応答端末Ｃの間で呼が確立されると、端末Ａ，Ｃ間で、ＲＴＰ(Real-time Transport Protocol)に基づくデータ通信が行われ、いわゆる通話中の状態となる（図１３のステップＳ３７、図１５のステップＳ５８、図１６ＢのステップＳ７８、図１７ＢのステップＳ９９）。
【００６３】
ステップＳ２８０：
端末Ａ，Ｃ間で通信が終了すると、端末ＡはＳＩＰサーバ５宛てにBYEを送信し、ＳＩＰサーバ５はＳＩＰサーバ１宛てにBYEを送信し、ＳＩＰサーバ１は端末Ｃ宛にBYEを送信する。
【００６４】
ステップＳ２９０：
ステップＳ２８０でBYEを受信した端末Ｃの動作状態は「通信中」から「待受中」へ動作状態が変化したので、端末Ｃは、その状態変化を示すNotifyをプレゼンスサーバ宛に送信する。プレゼンスサーバでは、端末Ｃの動作状態の変化に基づきプレゼンスデータを更新するとともに、端末Ｃの動作状態の変化を他の端末Ａ，Ｂに通知するため、端末状態通知リストを含むNotifyを端末Ａ，Ｂ宛に送信し、その後、端末Ａ，Ｂから200を受信する。これにより、各端末におけるプレゼンス表示画面が更新される。
【００６５】
ステップＳ３００：
ステップＳ２８０のBYEの送信に応じて、受信元はBYEの送信元に対して200を送信する。
【００６６】
ステップＳ３１０：
ステップＳ３００で200を受信した端末Ａの動作状態は「通信中」から「待受中」へ動作状態が変化したので、端末Ａは、その状態変化を示すNotifyをプレゼンスサーバ宛に送信する。プレゼンスサーバでは、端末Ａの動作状態の変化に基づきプレゼンスデータを更新するとともに、端末Ａの動作状態の変化を他の端末Ｂ，Ｃに通知するため、端末状態通知リストを含むNotifyを端末Ｂ，Ｃ宛に送信し、その後、端末Ｂ，Ｃから200を受信する。これにより、各端末におけるプレゼンス表示画面が更新される。
【００６７】
以上、本実施形態のシステム内の局間ピックアップ時の動作、および各装置の局間ピックアップ時の動作について詳述した。上述したとおり、本実施形態の代理応答方法によれば、通信網に対して複数のＳＩＰサーバ（局）が接続されたシステムにおいて、各ＳＩＰサーバは、システム内の各電話番号と、電話番号が収容されているＳＩＰサーバとを対応付けた電番分析テーブルを備えている。そして、ＳＩＰサーバは、自局に収容されている電話番号の通信端末から局間ピックアップの要求があった場合には、電番分析テーブルを参照して呼出中の電話番号が収容されているＳＩＰサーバを特定し、その特定したＳＩＰサーバとの間で呼の中継処理を行う。そのため、代理応答対象の電話番号について他の複数のＳＩＰサーバを個別に検索する必要がなく、局間ピックアップの処理を短時間で完了させることができる。
【００６８】
（２）第２の実施形態
以下、第２の実施形態について説明する。
第１の実施形態の代理応答方法では、予め代理応答端末Ｃがプレゼンスサーバに自端末の登録を行い、プレゼンスデータに基づいて表示されるプレゼンス表示画面上で、端末Ｃのユーザが代理応答のための所定の操作を行うことを契機として代理応答処理が開始される。これに対し、本実施形態の代理応答方法では、代理応答端末Ｃは、予めプレゼンスサーバに自端末の登録を行わず、端末Ｃのユーザが代理応答のための所定のダイヤル操作（代理応答操作）を行うことを契機として代理応答処理が開始される。例えば、他の呼出中の端末の鳴動動作を知覚して、端末Ｃのユーザが代理応答のための所定のダイヤル操作を行う場合が想定されている。
【００６９】
以下、図１８Ａ〜１９を参照して、本実施形態のシステム内の局間ピックアップ時の動作、および各装置の局間ピックアップ時の動作について説明する。図１８Ａ，図１８Ｂは、本実施形態のシステム内の動作を示すフローチャートである。図１９は、代理応答端末（ピックアップ端末）Ｃの動作の一部を示すフローチャートである。
第１の実施形態と同様、以下の説明では、発信端末Ａと着信端末Ｂの電話番号はＳＩＰサーバ５に収容されており、代理応答端末Ｃの電話番号はＳＩＰサーバ１に収容され、端末Ａ，Ｂ，Ｃのユーザが同一グループ内である場合を想定する。
【００７０】
ステップＳ４００：
先ず、端末Ａ，Ｂは、自端末の登録要求を含むSubscribeをプレゼンスサーバ宛に送信する。端末Ａ，ＢからSubscribeを受信したプレゼンスサーバは、端末Ａ，Ｂを登録、つまり登録端末リスト（図９参照）を更新し、各端末宛に200を返す。
なお、図１８Ａおよび図１８Ｂに示すフローチャートにおいて、プレゼンスサーバは以後、登録した通信端末からの通知に応じて通信端末の動作状態を更新するが、特定の通信端末の動作状態の変化を他の通信端末宛に通知しない場合が想定されている。
また、図１８Ａおよび図１８Ｂに示すフローチャートでは、代理応答端末Ｃが代理応答処理を行うときに初めてプレゼンスサーバに登録して状態通知リストを取得する場合が示されているが、この限りではない。端末Ｃが予めプレゼンスサーバに登録されていてもよいし、代理応答処理後継続的に状態通知リストを取得するようにしてもよい。
【００７１】
ステップＳ４１０：
ここで、端末Ａのユーザがbbbbのダイヤル操作を行う。
【００７２】
ステップＳ４２０：
ステップＳ４１０のダイヤル操作により、端末Ａは電話番号bbbbを指定したINVITEをＳＩＰサーバ５宛てに送信し、ＳＩＰサーバ５は端末Ａに100を返す。
【００７３】
ステップＳ４３０：
ステップＳ４２０の処理により、端末Ａの動作状態は「待受中」から「発信中」へ動作状態が変化したので、端末Ａは、その状態変化を示すNotifyをプレゼンスサーバ宛に送信する。プレゼンスサーバではNotifyの受信に応じて、200を端末Ａに返す。
【００７４】
ステップＳ４４０：
ＳＩＰサーバ５は、ステップＳ４２０で端末Ａから送信されたINVITEに含まれる電話番号を分析して着信先が電話番号bbbbであることが分かると、電話番号bbbbの端末Ｂ宛てにINVITEを送信する。端末ＢはこのINVITEを受信する。このINVITEに応じて端末Ｂは、100をＳＩＰサーバ５宛てに送信する。ＳＩＰサーバ５は、端末Ｂから100を受信する。
【００７５】
ステップＳ４５０：
ステップＳ４４０の処理により、端末Ｂの動作状態は「待受中」から「呼出中」へ動作状態が変化したので、端末Ｂは、その状態変化を示すNotifyをプレゼンスサーバ宛に送信する。プレゼンスサーバではNotifyの受信に応じて、200を端末Ｂに返す。
【００７６】
ステップＳ４６０：
ＳＩＰサーバ５は、端末Ｂから180が送信されてくると、発信端末Ａ宛に180を送信する。このようにして、発信端末Ａから着信端末Ｂへの呼出中の状態となる。
【００７７】
ステップＳ４７０：
この時点で、端末Ｃのユーザは、着信端末Ｂの鳴動動作を知覚して所定のダイヤル操作（ここでは、ピックアップ特番を示す“*12”）を行う。このダイヤル操作、すなわち代理応答操作は、端末Ｂの操作入力部１３を経てＣＰＵ１０に認識される。
【００７８】
ステップＳ４８０：
ピックアップ特番を示す所定のダイヤル操作を認識した端末Ｃは、状態要求リストを含むSubscribeをプレゼンスサーバ宛に送信する（図１９のステップＳ８００）。状態要求リストでは、動作状態を取得したい電話番号の一覧が指定される。ここでは、端末Ａ，Ｂ，Ｃのユーザが同一グループ内である場合を想定されているため、端末Ｃは、動作状態を取得したい電話番号として、端末Ａの電話番号(aaaa)と端末Ｂ(bbbb)の電話番号を指定する。端末ＣからSubscribeを受信したプレゼンスサーバは、端末Ｃを登録、つまり登録端末リスト（図９参照）を更新し、端末Ｃ宛に200を返す。
プレゼンスサーバは、Subscribeを受信すると、Subscribe内の状態要求リストで指定された端末Ａ，Ｂの動作状態を含む状態通知リスト（例えば図４（ｂ）参照）を含むNotifyを端末Ｃ宛に送信する。端末Ｃは、プレゼンスサーバから状態通知リストを含むNotifyを受信する（図１９のステップＳ８０１）。
端末Ｃは、プレゼンスサーバからNotifyを受信すると、それ以降では、状態通知リストの受信は必ずしも必要ないので、そのリスト送信を止めるためのメッセージであるUnsubscribeをプレゼンスサーバ宛に送信し、プレゼンスサーバから200を受信する。
【００７９】
ステップＳ４９０：
端末Ｃは、ステップＳ４７０のダイヤル操作に応じて、プレゼンスサーバから受信した状態通知リストの中で、「呼出中」の端末（本実施形態では、bbbbの電話番号の通信端末）あるいはその電話番号を特定する（図１９のステップＳ８０２）。さらに、端末Ｃは、その「呼出中」の端末への着信に対するコールピックアップ、すなわち、端末Ｂへの着信に対して代理応答する処理を行うことを決定する。
【００８０】
ステップＳ５００：
端末Ｃは、ピックアップ特番である*12と、代理応答対象の電話番号（ここでは、端末Ｂのbbbb）とを順に組み立てた電番のデータ（*12-bbbb）を含むINVITEを生成する（図１９のステップＳ８０３）。端末ＣはそのINVITEをＳＩＰサーバ１宛てに送信する（図１９のステップＳ８０４）。ＳＩＰサーバ１は、端末ＣからのINVITEを受信するとともに、端末Ｃ宛に100を返信する。端末ＣがＳＩＰサーバ１から100を受信する（図１９のステップＳ８０５）。
【００８１】
ステップＳ５１０：
ステップＳ５００の処理により、端末Ｃの動作状態は「待受中」から「発信中」へ動作状態が変化したので、端末Ｃは、その状態変化を示すNotifyをプレゼンスサーバ宛に送信する（図１９のステップＳ８０６）。プレゼンスサーバではNotifyの受信に応じて、200を端末Ｃに返す。
【００８２】
ステップＳ５９０〜Ｓ７１０
図１８Ａおよび図１８ＢにおけるステップＳ５９０以降の処理は、図１２Ａおよび図１２ＢにおけるステップＳ１９０以降の処理と実質的に同一であるので、以下では簡略化して説明する。
【００８３】
ＳＩＰサーバ１は、ステップＳ５００で端末Ｃから受信したINVITEに含まれる電番のデータ（*12-bbbb）を、メモリ２２内の電番分析テーブルを参照して分析する（ステップＳ５９０）。その結果、ＳＩＰサーバ１は、端末Ｃから受信したINVITEに含まれる電番のデータ（*12-bbbb）が、他局（ＳＩＰサーバ５）の電話番号bbbbに対する局間ピックアップの要求であることを認識する。
ＳＩＰサーバ１は、ステップＳ５９０における分析結果に基づいて、INFOメッセージ（INFO）を生成し、bbbbの電話番号が収容されているＳＩＰサーバ５宛てに送信する（ステップＳ６００）。INFOには、bbbbの電話番号に対する代理応答要求(pickup,bbbb)を示すデータが含まれている。
【００８４】
ＳＩＰサーバ５は、通信端末Ｂの呼出中処理をキャンセルするためのメッセージであるCANCELを端末Ｂ宛に送信し、端末Ｂから200を受信する。さらに、ＳＩＰサーバ５は、端末Ｂから200を受信すると、ＳＩＰサーバ１宛てに200を送信する（ステップＳ６１０）。これにより、端末Ｂの動作状態は「呼出中」から「待受中」へ動作状態が変化したので、端末Ｂは、その状態変化を示すNotifyをプレゼンスサーバ宛に送信する（ステップＳ６２０）。
【００８５】
ＳＩＰサーバ５は、ステップＳ６１０における200の送信に次いで、INFOの送信元サーバであるＳＩＰサーバ１宛てにINVITEを送信し、ＳＩＰサーバ１から100を受信する（ステップＳ６３０）。
【００８６】
次に、以下のステップＳ６４０の処理が行われる。すなわち、ＳＩＰサーバ１は、ステップＳ６３０におけるINVITEの受信に対する200をＳＩＰサーバ５宛てに送信するとともに、ステップＳ５００におけるINVITEの受信に対する200を代理応答端末Ｃ宛に送信する。ＳＩＰサーバ５はＳＩＰサーバ１から200を受信し、端末ＣはＳＩＰサーバ１から200を受信する（図１９のステップＳ８０７）。また、ＳＩＰサーバ５は、ＳＩＰサーバ１から200を受信すると、ステップＳ４２０におけるINVITEの受信に対する200を発信端末Ａ宛に送信する。200を受信したＳＩＰサーバ５、端末ＡおよびＣはそれぞれ、200の送信元宛にACKを送信する。
【００８７】
ステップＳ６３０およびＳ６４０の処理を経て、発信端末Ａと代理応答端末Ｃの間で呼が確立される。その結果、端末Ｃの動作状態は「発信中」から「通信中」へ動作状態が変化したので、ステップＳ６５０において端末Ｃは、その状態変化を示すNotifyをプレゼンスサーバ宛に送信する（図１９のステップＳ８０８）。同様にして、端末Ａの動作状態は「発信中」から「通信中」へ動作状態が変化したので、ステップＳ６６０において端末Ａは、その状態変化を示すNotifyをプレゼンスサーバ宛に送信する。
【００８８】
発信端末Ａと代理応答端末Ｃの間で呼が確立されると、ステップＳ６７０において端末Ａ，Ｃ間でＲＴＰに基づくデータ通信が行われ、いわゆる通話中の状態となる（図１９のステップＳ８０９）。端末Ａ，Ｃ間で通信が終了すると、ステップＳ６８０に示すように、端末ＡはＳＩＰサーバ５宛てにBYEを送信し、ＳＩＰサーバ５はＳＩＰサーバ１宛てにBYEを送信し、ＳＩＰサーバ１は端末Ｃ宛にBYEを送信する。ステップＳ６８０でBYEを受信した端末Ｃの動作状態は「通信中」から「待受中」へ動作状態が変化したので、端末Ｃは、その状態変化を示すNotifyをプレゼンスサーバ宛に送信する。
【００８９】
ステップＳ７００では、ステップＳ６８０のBYEの受信元は、BYEの送信元に対して200を送信する。ステップＳ７００で200を受信した端末Ａの動作状態は「通信中」から「待受中」へ動作状態が変化したので、ステップＳ７１０において端末Ａは、その状態変化を示すNotifyをプレゼンスサーバ宛に送信する。
【００９０】
以上、本実施形態のシステム内の局間ピックアップ時の動作、および各装置の局間ピックアップ時の動作について詳述した。上述したとおり、本実施形態の代理応答方法によれば、第１の実施形態と同様に、ＳＩＰサーバは、自局に収容されている電話番号の通信端末から局間ピックアップの要求があった場合には、電番分析テーブルを参照して呼出中の電話番号が収容されているＳＩＰサーバを特定し、その特定したＳＩＰサーバとの間で呼の中継処理を行う。そのため、代理応答対象の電話番号について他の複数のＳＩＰサーバを個別に検索する必要がなく、局間ピックアップの処理を短時間で完了させることができる。
【００９１】
以上、本発明の実施形態について詳細に説明したが、本発明の呼制御装置、代理応答方法は上記実施形態に限定されず、本発明の主旨を逸脱しない範囲において、種々の改良や変更をしてもよいのは勿論である。
【００９２】
例えば、上述した各実施形態では、発信端末Ａと着信端末Ｂの電話番号が同一のＳＩＰサーバに収容されている場合について説明したが、両者が異なるＳＩＰサーバに収容されている場合についても、同様の局間ピックアップ機能を実現させることができる。
例えば、上述した各実施形態において、仮に着信端末Ｂの電話番号がＳＩＰサーバ４に収容されている場合、電話番号がＳＩＰサーバ１に収容されている端末Ｃから代理応答することができる。具体的には、図１２ＡのステップＳ１４０において、ＳＩＰサーバ５は、ＳＩＰサーバ４（図示せず）宛てにINVITEを送信し、ＳＩＰサーバ４が端末Ｂ宛にINVITEを送信する。また、図１２ＡのステップＳ２００において、ＳＩＰサーバ１は、着信端末Ｂの電話番号がＳＩＰサーバ４に収容されていることを認識した後、そのＳＩＰサーバ４（図示せず）宛てにINFOを送信する。
【００９３】
上述した各実施形態では、代理応答端末からＳＩＰサーバ宛に送信されるINVITE、および、ＳＩＰサーバ間で送受信されるINFOには、ピックアップ特番と呼出中の電話番号を直列に組み立てたデータ（実施形態の例では、*12-bbbb)が含まれるが、このデータ構成は一例に過ぎない。装置間でなされる特定のプロトコルに従い、受信側において、代理応答であることと、代理対象の電話番号（識別情報）とが認識可能であれば、そのデータ構成（データフォーマット）は問わない。
【００９４】
以上の各実施形態に関し、さらに以下の付記を開示する。
【００９５】
（付記１）
通信端末の識別情報を管理して通信端末間の呼を制御し、他の呼制御装置と通信可能な呼制御装置であって、
各通信端末の識別情報と、自装置を含み通信網に接続されている複数の呼制御装置のうち当該識別情報を管理するいずれかの呼制御装置と、が対応付けられている第１情報を記憶する記憶部と、
呼出中の通信端末の識別情報を含む代理応答要求を、識別情報が自装置の管理下にある通信端末から受け、当該要求に応じて前記第１情報を参照して、前記呼出中の通信端末の識別情報を管理する他の呼制御装置を特定する制御部と、
前記制御部によって特定された前記他の呼制御装置宛に、識別情報が自装置の管理下にある通信端末が前記呼出中の通信端末への着信に対して代理応答することを示す第２情報を送信する通信部と、
を備えた、呼制御装置。
【００９６】
（付記２）
前記第２情報は、代理応答を示すピックアップ特番と、第１通信端末の識別情報としての電話番号とを含む、
付記１に記載された呼制御装置。
【００９７】
（付記３）
通信端末と、通信端末の識別情報を管理するとともに通信端末間の呼を制御する複数の呼制御装置と、各通信端末の動作状態を管理する状態管理サーバと、が通信網によって接続されている通信システムにおいて、通信端末が他の通信端末への着信に対して代理応答する代理応答方法であって、
複数の呼制御装置の各々は、通信網に接続されている通信端末ごとに、識別情報と、識別情報を管理する呼制御装置とが対応付けられている第１情報を予め記憶し、
識別情報が第１呼制御装置の管理下にある第１通信端末は、自端末の動作状態が待受中から呼出中に変化した場合、自端末の動作状態を状態管理サーバ宛に通知し、
状態管理サーバは、第１通信端末からの通知に応じて、第１通信端末の識別情報と、第１通信端末の動作状態とを対応付けて記憶し、
識別情報が第１呼制御装置とは異なる第２呼制御装置の管理下にある第２通信端末は、呼出中の動作状態にある前記第１通信端末の識別情報を状態管理サーバから取得し、
第２呼制御装置は、第１通信端末の識別情報を含む代理応答要求を第２通信端末から受け、当該要求に応じて前記第１情報を参照して、第１通信端末の識別情報を管理する呼制御装置として前記第１呼制御装置を特定し、
第２呼制御装置は、特定した第１呼制御装置宛に、識別情報が自装置の管理下にある通信端末が第１通信端末への着信に対して代理応答することを示す第２情報を送信する、
ことを含む、代理応答方法。
【００９８】
（付記４）
第２通信端末は、１または複数の通信端末の識別情報を指定して状態管理サーバに予め通知し、
状態管理サーバは、第２通信端末の識別情報と、第２通信端末によって指定された前記１または複数の通信端末の識別情報とを対応付けて記憶し、
状態管理サーバは、第２通信端末によって指定された前記１または複数の通信端末のいずれかの動作状態が変化する度に、当該動作状態の変化を第２通信端末に対して通知する、
ことをさらに含む、付記３に記載された代理応答方法。
【００９９】
（付記５）
第２通信端末は、１または複数の通信端末の識別情報を指定して状態管理サーバに予め通知し、
状態管理サーバは、第２通信端末の識別情報と、第２通信端末によって指定された前記１または複数の通信端末の識別情報とを対応付けて記憶し、
第２通信端末は、自端末に対する所定の代理応答操作に応じて、状態管理サーバに対し、前記１または複数の通信端末の各々の動作状態の通知を要求し、
第２通信端末は、状態管理サーバから通知された動作状態の中で呼出中の状態の通信端末の識別情報を特定する、
ことをさらに含む、付記３に記載された代理応答方法。
【０１００】
（付記６）
前記第２情報は、代理応答を示すピックアップ特番と、第１通信端末の識別情報としての電話番号とを含む、
付記３〜５のいずれかに記載された代理応答方法。
【符号の説明】
【０１０１】
（通信端末）
１０…ＣＰＵ
１１…通信制御部
１２…プレゼンス処理部
１３…操作入力部
１４…表示部
１５…音声入出力部
１６…バス
（ＳＩＰサーバ）
２０…ＣＰＵ
２１…通信制御部
２２…メモリ
２３…ＨＤＤ
２４…バス
（プレゼンスサーバ）
４０…ＣＰＵ
４１…通信制御部
４２…メモリ
４３…ＨＤＤ
４４…バス
【特許請求の範囲】
【請求項１】
通信端末の識別情報を管理して通信端末間の呼を制御し、他の呼制御装置と通信可能な呼制御装置であって、
各通信端末の識別情報と、自装置を含み通信網に接続されている複数の呼制御装置のうち当該識別情報を管理するいずれかの呼制御装置と、が対応付けられている第１情報を記憶する記憶部と、
呼出中の通信端末の識別情報を含む代理応答要求を、識別情報が自装置の管理下にある通信端末から受け、当該要求に応じて前記第１情報を参照して、前記呼出中の通信端末の識別情報を管理する他の呼制御装置を特定する制御部と、
前記制御部によって特定された前記他の呼制御装置宛に、識別情報が自装置の管理下にある通信端末が前記呼出中の通信端末への着信に対して代理応答することを示す第２情報を送信する通信部と、
を備えた、呼制御装置。
【請求項２】
通信端末と、通信端末の識別情報を管理するとともに通信端末間の呼を制御する複数の呼制御装置と、各通信端末の動作状態を管理する状態管理サーバと、が通信網によって接続されている通信システムにおいて、通信端末が他の通信端末への着信に対して代理応答する代理応答方法であって、
複数の呼制御装置の各々は、通信網に接続されている通信端末ごとに、識別情報と、識別情報を管理する呼制御装置とが対応付けられている第１情報を予め記憶し、
識別情報が第１呼制御装置の管理下にある第１通信端末は、自端末の動作状態が待受中から呼出中に変化した場合、自端末の動作状態を状態管理サーバ宛に通知し、
状態管理サーバは、第１通信端末からの通知に応じて、第１通信端末の識別情報と、第１通信端末の動作状態とを対応付けて記憶し、
識別情報が第１呼制御装置とは異なる第２呼制御装置の管理下にある第２通信端末は、呼出中の動作状態にある前記第１通信端末の識別情報を状態管理サーバから取得し、
第２呼制御装置は、第１通信端末の識別情報を含む代理応答要求を第２通信端末から受け、当該要求に応じて前記第１情報を参照して、第１通信端末の識別情報を管理する呼制御装置として前記第１呼制御装置を特定し、
第２呼制御装置は、特定した第１呼制御装置宛に、識別情報が自装置の管理下にある通信端末が第１通信端末への着信に対して代理応答することを示す第２情報を送信する、
ことを含む、代理応答方法。
【請求項３】
第２通信端末は、１または複数の通信端末の識別情報を指定して状態管理サーバに予め通知し、
状態管理サーバは、第２通信端末の識別情報と、第２通信端末によって指定された前記１または複数の通信端末の識別情報とを対応付けて記憶し、
状態管理サーバは、第２通信端末によって指定された前記１または複数の通信端末のいずれかの動作状態が変化する度に、当該動作状態の変化を第２通信端末に対して通知する、
ことをさらに含む、請求項２に記載された代理応答方法。
【請求項４】
第２通信端末は、１または複数の通信端末の識別情報を指定して状態管理サーバに予め通知し、
状態管理サーバは、第２通信端末の識別情報と、第２通信端末によって指定された前記１または複数の通信端末の識別情報とを対応付けて記憶し、
第２通信端末は、自端末に対する所定の代理応答操作に応じて、状態管理サーバに対し、前記１または複数の通信端末の各々の動作状態の通知を要求し、
第２通信端末は、状態管理サーバから通知された動作状態の中で呼出中の状態の通信端末の識別情報を特定する、
ことをさらに含む、請求項２に記載された代理応答方法。
【請求項１】
通信端末の識別情報を管理して通信端末間の呼を制御し、他の呼制御装置と通信可能な呼制御装置であって、
各通信端末の識別情報と、自装置を含み通信網に接続されている複数の呼制御装置のうち当該識別情報を管理するいずれかの呼制御装置と、が対応付けられている第１情報を記憶する記憶部と、
呼出中の通信端末の識別情報を含む代理応答要求を、識別情報が自装置の管理下にある通信端末から受け、当該要求に応じて前記第１情報を参照して、前記呼出中の通信端末の識別情報を管理する他の呼制御装置を特定する制御部と、
前記制御部によって特定された前記他の呼制御装置宛に、識別情報が自装置の管理下にある通信端末が前記呼出中の通信端末への着信に対して代理応答することを示す第２情報を送信する通信部と、
を備えた、呼制御装置。
【請求項２】
通信端末と、通信端末の識別情報を管理するとともに通信端末間の呼を制御する複数の呼制御装置と、各通信端末の動作状態を管理する状態管理サーバと、が通信網によって接続されている通信システムにおいて、通信端末が他の通信端末への着信に対して代理応答する代理応答方法であって、
複数の呼制御装置の各々は、通信網に接続されている通信端末ごとに、識別情報と、識別情報を管理する呼制御装置とが対応付けられている第１情報を予め記憶し、
識別情報が第１呼制御装置の管理下にある第１通信端末は、自端末の動作状態が待受中から呼出中に変化した場合、自端末の動作状態を状態管理サーバ宛に通知し、
状態管理サーバは、第１通信端末からの通知に応じて、第１通信端末の識別情報と、第１通信端末の動作状態とを対応付けて記憶し、
識別情報が第１呼制御装置とは異なる第２呼制御装置の管理下にある第２通信端末は、呼出中の動作状態にある前記第１通信端末の識別情報を状態管理サーバから取得し、
第２呼制御装置は、第１通信端末の識別情報を含む代理応答要求を第２通信端末から受け、当該要求に応じて前記第１情報を参照して、第１通信端末の識別情報を管理する呼制御装置として前記第１呼制御装置を特定し、
第２呼制御装置は、特定した第１呼制御装置宛に、識別情報が自装置の管理下にある通信端末が第１通信端末への着信に対して代理応答することを示す第２情報を送信する、
ことを含む、代理応答方法。
【請求項３】
第２通信端末は、１または複数の通信端末の識別情報を指定して状態管理サーバに予め通知し、
状態管理サーバは、第２通信端末の識別情報と、第２通信端末によって指定された前記１または複数の通信端末の識別情報とを対応付けて記憶し、
状態管理サーバは、第２通信端末によって指定された前記１または複数の通信端末のいずれかの動作状態が変化する度に、当該動作状態の変化を第２通信端末に対して通知する、
ことをさらに含む、請求項２に記載された代理応答方法。
【請求項４】
第２通信端末は、１または複数の通信端末の識別情報を指定して状態管理サーバに予め通知し、
状態管理サーバは、第２通信端末の識別情報と、第２通信端末によって指定された前記１または複数の通信端末の識別情報とを対応付けて記憶し、
第２通信端末は、自端末に対する所定の代理応答操作に応じて、状態管理サーバに対し、前記１または複数の通信端末の各々の動作状態の通知を要求し、
第２通信端末は、状態管理サーバから通知された動作状態の中で呼出中の状態の通信端末の識別情報を特定する、
ことをさらに含む、請求項２に記載された代理応答方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２Ａ】
【図１２Ｂ】
【図１３】
【図１４】
【図１５】
【図１６Ａ】
【図１６Ｂ】
【図１７Ａ】
【図１７Ｂ】
【図１８Ａ】
【図１８Ｂ】
【図１９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２Ａ】
【図１２Ｂ】
【図１３】
【図１４】
【図１５】
【図１６Ａ】
【図１６Ｂ】
【図１７Ａ】
【図１７Ｂ】
【図１８Ａ】
【図１８Ｂ】
【図１９】
【公開番号】特開２０１２−１６９７２０（Ｐ２０１２−１６９７２０Ａ）
【公開日】平成２４年９月６日（２０１２．９．６）
【国際特許分類】
【出願番号】特願２０１１−２６７１７（Ｐ２０１１−２６７１７）
【出願日】平成２３年２月１０日（２０１１．２．１０）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
【公開日】平成２４年９月６日（２０１２．９．６）
【国際特許分類】
【出願日】平成２３年２月１０日（２０１１．２．１０）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
[ Back to top ]