JP5712805B2 - 通信制御方法、通信制御装置、および通信制御システム - Google Patents

Description

本発明は、通信を制御する通信制御方法、通信制御装置、および通信制御システムに関する。

電話を用いた通信の分野において、通信端末の利用者は、通信端末に呼が着信したときには、自らが着信許可できる状態であるか否かを判断し、着信許可できない状態である場合は一旦着信拒否して、後に発信元へのコールバック（かけ直し）を行っていた。

従来、通信端末の利用者が、自らの現在の着信可否の状態をサーバに登録しておく技術があった。そして、発信者からの発信をサーバに通知し、サーバで着信可否を自動的に判断することにより、着信者自らが着信可否を判断するといった手間を削減する技術があった（例えば、下記特許文献１参照）。

また、関連する技術として、発信者が呼を発信する前に、着信者の情報を得ることができるようにして、発信者が発信の妥当性を判断できるようにした技術があった（例えば、下記特許文献２参照）。

特許第４０９１５１７号公報 特開２００８−０１１１４８号公報

しかしながら、上述した従来技術では、着信が拒否された後のコールバックについては考慮されていないため、通信端末の利用者は、コールバックに関しては、自らが着信許可の状態であるか否かを判断する手間がかかるといった問題があった。また、利用者の状況が変化するたびに、着信可否の状態をサーバに設定し直す必要があるため、設定変更作業の手間がかかるといった問題があった。また、利用者の状況が変化したときに、利用者が設定変更を行わなかった場合、利用者の望まない着信が行われるといった問題があった。

本発明は、上述した従来技術による問題点を解消するため、着信者が着信許可の状態であるときにコールバックさせる通信制御方法、通信制御装置、および通信制御システムを提供することを目的とする。

上述した課題を解決し、目的を達成するため、本発明の一側面によれば、コンピュータが、第１の端末からの発信を第２の端末が受け付けなかったことを検出し、第１の端末からの発信を第２の端末が受け付けなかったことが検出された場合、着信許可または不許可を示すコンテキストを端末ごとに記憶する記憶手段を参照することにより、第２の端末が着信許可の状態であるかを判断し、着信許可の状態であると判断された場合、第１の端末へのコールバック要求を第２の端末に送信する通信制御方法、および通信制御装置が提案される。

また、上述した課題を解決し、目的を達成するため、本発明の一側面によれば、端末間の発着信を制御する第１の装置と、発信元端末へのコールバックを制御する第２の装置と、が接続された通信制御システムであって、第２の装置は、着信許可または不許可を示すコンテキストを端末ごとに記憶する記憶手段を有し、第１の端末からの発信を第２の端末が受け付けなかったことを検出し、第１の端末からの発信を第２の端末が受け付けなかったことが検出された場合、記憶手段を参照することにより、第２の端末が着信許可の状態であるかを判断し、着信許可の状態であると判断された場合、第１の端末へのコールバック要求を第２の端末に送信し、第１の装置は、第１の端末から第２の端末へ発信されたことを第２の装置に通知する通信制御システムが提案される。

上述した課題を解決し、目的を達成するため、本発明の一側面によれば、端末間の発着信を制御する第１の装置と、発信元端末へのコールバックを制御する第２の装置と、が接続された通信制御システムであって、第２の装置は、着信許可または不許可を示すコンテキストを端末ごとに記憶する記憶手段を有し、第１の端末からの発信を第２の端末が受け付けなかったことを検出し、第１の端末からの発信を第２の端末が受け付けなかったことが検出された場合、記憶手段を参照することにより、第２の端末が着信許可の状態であるかを判断し、着信許可の状態であると判断された場合、第１の端末へのコールバック要求を第１の装置に送信し、第１の装置は、第１の端末から第２の端末へ発信されたことを第２の装置に通知し、送信手段からのコールバック要求を第２の装置に通知する通信制御システムが提案される。

本発明の一側面によれば、着信者が着信許可の状態であるときにコールバックさせるという効果を奏する。

図１は、通信制御装置による着信者へのコールバック要求の送信の内容を示す説明図である。 図２は、図１に示した通信システムＣの構成例を示す説明図である。 図３は、実施の形態にかかる通信制御装置１００に含まれる各サーバのハードウェア構成例を示すブロック図である。 図４は、コンテキスト管理サーバ１１０に記憶されている場所ＤＢの記憶内容を示す説明図である。 図５は、コンテキスト管理サーバ１１０に記憶されているコンテキストＤＢの記憶内容を示す説明図である。 図６は、コンテキスト管理サーバ１１０に記憶されている監視コンテキストＤＢの記憶内容を示す説明図である。 図７は、コールバック制御サーバ１２０に記憶されている呼制御ＤＢの記憶内容を示す説明図である。 図８は、コールバック制御サーバ１２０に記憶されているコールバックＤＢの記憶内容を示す説明図である。 図９は、通信制御装置１００の機能的構成を示すブロック図である。 図１０は、実施例１にかかる通信制御装置１００による着信者へのコールバック要求の送信例１の内容を示す説明図である。 図１１は、実施例１にかかる通信制御装置１００による着信者へのコールバック要求の送信例２の内容を示す説明図である。 図１２は、実施例１における発信側端末Ｓから呼が発信されるときの各サーバの通信内容の詳細を示すシーケンス図である。 図１３は、実施例１におけるコールバック制御サーバ１２０によりコールバック要求が送信されるときの各サーバの通信内容の詳細を示すシーケンス図である。 図１４は、実施例１におけるコールバック制御サーバ１２０のコールバック制御処理の処理内容の詳細を示すフローチャートである。 図１５は、実施例１におけるコンテキスト管理サーバ１１０の監視コンテキスト登録処理の処理内容の詳細を示すフローチャートである。 図１６は、実施例１におけるコンテキスト管理サーバ１１０のコールバック契機通知送信処理の処理内容の詳細を示すフローチャートである。 図１７は、実施例２にかかる通信端末Ｔの画面表示例を示す説明図である。 図１８は、実施例２にかかるコンテキストＤＢ１１２の記憶内容を示す説明図である。 図１９は、コールバック要求の中止に関する監視コンテキストを含む監視コンテキストＤＢ１１３の記憶内容を示す説明図である。 図２０は、呼の用件および緊急度を含む呼制御ＤＢ１２１の記憶内容を示す説明図である。 図２１は、実施例２にかかる通信制御装置１００による着信者へのコールバック要求の送信例１の内容を示す説明図（その１）である。 図２２は、実施例２にかかる通信制御装置１００による着信者へのコールバック要求の送信例１の内容を示す説明図（その２）である。 図２３は、実施例２にかかる通信制御装置１００による着信者へのコールバック要求の送信例２の内容を示す説明図である。 図２４は、実施例２における発信側端末Ｓから呼が発信されるときの各サーバの通信内容の詳細を示すシーケンス図（その１）である。 図２５は、実施例２における発信側端末Ｓから呼が発信されるときの各サーバの通信内容の詳細を示すシーケンス図（その２）である。 図２６は、実施例２におけるコールバック制御サーバ１２０によりコールバック要求が送信されるときの各サーバの通信内容の詳細を示すシーケンス図である。 図２７は、実施例２におけるコールバック要求の取消を行うときの各サーバの通信内容の詳細を示すシーケンス図である。 図２８は、実施例２におけるコールバック制御サーバ１２０の着信制御処理の処理内容の詳細を示すフローチャートである。 図２９は、実施例２におけるコールバック制御サーバ１２０のコールバック制御処理の処理内容の詳細を示すフローチャートである。 図３０は、実施例２におけるコンテキスト管理サーバ１１０の監視コンテキスト登録処理の処理内容の詳細を示すフローチャートである。 図３１は、実施例２におけるコンテキスト管理サーバ１１０のコールバック契機通知送信処理の処理内容の詳細を示すフローチャートである。

以下に添付図面を参照して、この発明にかかる通信制御方法、通信制御装置、および通信制御システムの実施の形態を詳細に説明する。通信制御装置は、着信側端末が着信許可の状態になったときに、コールバックが行われるようにするために、着信側端末の状態を示すコンテキストを取得する。

次に、通信制御装置は、予め保持しておいた着信側端末が着信許可の状態になる場合のコンテキストと、取得した着信側端末のコンテキストと、を参照することにより、着信側端末の状態が着信許可の状態か、または着信不許可の状態か、を判断する。そして、通信制御装置は、着信側端末の状態が着信許可の状態であると判断された場合にのみ、着信側端末にコールバック要求を送信する。これにより、着信側端末が着信不許可の状態のときにはコールバック要求が送信されないため、着信者の手間が削減できる。

（通信制御装置による着信者へのコールバック要求の送信の内容）
まず、図１を用いて、通信制御装置による着信者へのコールバック要求の送信の内容について説明する。図１は、通信制御装置による着信者へのコールバック要求の送信の内容を示す説明図である。

図１では、呼を発信する側の通信端末Ｔ（以下、「発信側端末Ｓ」という）と、呼が着信される側の通信端末Ｔ（以下、「着信側端末Ｒ」という）と、通信制御装置１００と、を含む通信システムＣを示す。

発信側端末Ｓは、発信側端末Ｓの利用者の操作により、着信側端末Ｒへの呼を発信する端末である。着信側端末Ｒは、発信側端末Ｓが発信した呼が着信される端末である。また、着信側端末Ｒは、着信側端末Ｒのコンテキストを取得するセンサを有する。コンテキストとは、自端末（ならびに自端末の利用者）の状態を示す情報であり、例えば、着信側端末Ｒがある場所（ならびに着信側端末Ｒの利用者のいる場所）、または、着信側端末Ｒが通話中か否か（ならびに着信側端末Ｒの利用者が通話中か否か）を示す情報である。以下では、発信側端末Ｓの利用者を「発信者」という。また、以下では、着信側端末Ｒの利用者を「着信者」という。

通信制御装置１００は、着信側端末Ｒのコンテキストを取得して、着信側端末Ｒの着信許可または着信不許可を判断する装置である。また、通信制御装置１００は、着信側端末Ｒが着信許可の状態である場合に、コールバック要求を送信する装置である。

具体的には、例えば、通信制御装置１００は、コンテキスト管理サーバ１１０と、コールバック制御サーバ１２０と、を含む装置である。ここで、コンテキスト管理サーバ１１０は、着信側端末Ｒのコンテキストを管理するサーバである。また、コンテキスト管理サーバ１１０は、通信端末Ｔごとの着信許可である場合のコンテキストを記憶する監視コンテキストＤＢを保持し、通信端末Ｔが通信許可の状態になったことを検出するサーバである。

コールバック制御サーバ１２０は、コールバックのために発信側端末Ｓの電話番号を記憶するコールバックＤＢを記憶するサーバである。また、コールバック制御サーバ１２０は、コンテキスト管理サーバ１１０から着信側端末Ｒが着信許可の状態になったことを通知された場合に、着信側端末Ｒと発信側端末Ｓとにコールバックの通信を行わせるサーバである。

また、通信制御装置１００は、さらに、呼制御サーバ１３０を含んでもよい。呼制御サーバ１３０は、発信側端末Ｓと着信側端末Ｒとの通信の接続および切断を行うサーバである。そして、コールバック制御サーバ１２０は、呼制御サーバ１３０を介して、着信側端末Ｒと発信側端末Ｓとにコールバックの通信を行わせるようにしてもよい。具体的には、呼制御サーバ１３０は、いわゆる第三者呼制御（ｔｈｉｒｄ−ｐａｒｔｙ ｃａｌｌ ｃｏｎｔｒｏｌ）により、着信側端末Ｒと発信側端末Ｓとにコールバックの通信を行わせる。ただし、通信制御装置１００は、コンテキスト管理サーバ１１０と、コールバック制御サーバ１２０と、呼制御サーバ１３０と、の機能を含む１装置であってもよい。

ここで、発信側端末Ｓから着信側端末Ｒへと発信された呼が、着信側端末Ｒに受け付けられなかった場合を想定して、通信制御装置１００による着信者へのコールバック要求の送信の内容について説明する。

（１）通信制御装置１００は、発信側端末Ｓから着信側端末Ｒへの呼が、着信側端末Ｒに受け付けられなかったことを検出する。具体的には、例えば、通信制御装置１００は、発信側端末Ｓから着信側端末Ｒへの呼の着信を拒否するイベントがあったことが、着信側端末Ｒから通知されることにより、呼が着信側端末Ｒに受け付けられなかったことを検出する。また、具体的には、例えば、通信制御装置１００は、呼制御サーバ１３０により発信側端末Ｓと着信側端末Ｒとの通話を制御している場合は、呼制御サーバ１３０が着信側端末Ｒへの着信を拒否するイベントを検出して、呼が着信側端末Ｒに受け付けられなかったことを検出する。

そして、通信制御装置１００は、発信側端末Ｓから着信側端末Ｒへの呼が着信側端末Ｒに受け付けられなかったことを検出すると、コールバック要求の送信の可否の判定を開始し、着信側端末Ｒのコンテキストを監視する。

（２）ここで、着信側端末Ｒは、着信側端末Ｒのコンテキストを通信制御装置１００に通知する。ここでは、コンテキストは、通信端末Ｔの場所を示す情報である。例えば、通信制御装置１００が無線ＬＡＮのＳＳＩＤ（Ｓｅｒｖｉｃｅ Ｓｅｔ ＩＤｅｎｔｉｆｉｅｒ）に対応する場所を記憶するテーブルを有し、テーブルを参照して無線ＬＡＮのＳＳＩＤから場所を特定することができる。

また、例えば、通信制御装置１００が場所に対応するＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）の座標の範囲を記憶するテーブルを有し、テーブルを参照してＧＰＳの座標から場所を特定できることができる。

また、例えば、対象となる場所に赤外線受信器が設けられ、通信制御装置１００が赤外線受信器の識別子に対応する場所を記憶するテーブルを有し、テーブルを参照して赤外線受信器の識別子から場所を特定することができる。

なお、着信側端末Ｒがコンテキストを通知するトリガは、例えば、着信側端末Ｒのコンテキストに変化があったときである。また、特定の場所に入ったときのコンテキストの変化のみをトリガにすることで、着信者が特定の場所へ出入りを繰り返した場合を検出しないようにして、通信制御装置の動作を安定化できる。また、例えば、着信側端末Ｒは、一定時間ごとにコンテキストを通知することにしてもよい。

（３）次に、通信制御装置１００は、着信側端末Ｒのコンテキストの通知を受けると、予め保持しておいた監視コンテキストＤＢ（ＤａｔａＢａｓｅ）を参照して、着信側端末Ｒが着信許可の状態にあるか否かを判定する。ここでは、通信制御装置１００は、着信側端末Ｒから通知されたコンテキストが示す場所が休憩室であり、監視コンテキストＤＢには会議室以外では着信許可の状態であると記憶されているため、着信側端末Ｒが着信許可の状態にあると判定する。ただし、通信制御装置１００は、さらに、発信側端末Ｓが着信許可の状態であるか否かを判定してもよい。

（４）そして、通信制御装置１００は、着信側端末Ｒが着信許可の状態であれば、着信側端末Ｒにコールバック要求を送信する。ここで、コールバック要求とは、例えば、発信側端末Ｓの電話番号を含んだメッセージである。また、コールバック要求とは、例えば、発信側端末Ｓへのコールバックを実行するアプリケーションであってもよい。また、コールバック要求とは、例えば、呼制御サーバ１３０からの着信要求であってもよい。ただし、通信制御装置１００は、（３）において、発信側端末Ｓが着信許可の状態であるかを判定した場合、着信側端末Ｒと発信側端末Ｓの双方が着信許可の状態である場合に限って、着信側端末Ｒにコールバック要求を送信するようにしてもよい。

（５）コールバック要求を受けた着信側端末Ｒは、発信側端末Ｓとの通話を開始する。具体的には、例えば、コールバック要求が発信側端末Ｓの電話番号を含んだメッセージであれば、着信側端末Ｒは、着信者によるメッセージに含まれる電話番号に呼を発信する操作を受けて、発信側端末Ｓとの通話を開始する。

また、具体的には、例えば、コールバック要求が発信側端末Ｓへのコールバックを実行するアプリケーションであれば、着信側端末Ｒは、着信者による該当アプリケーションを実行する操作を受けて、発信側端末Ｓとの通話を開始する。また、具体的には、例えば、コールバック要求が呼制御サーバ１３０からの着信要求であれば、着信側端末Ｒは、着信者による着信要求を許可する操作を受けて、発信側端末Ｓとの通話を開始する。

このように、通信制御装置１００は、着信側端末Ｒのコンテキストを取得し、自動的に着信側端末Ｒが着信許可の状態になったか否かを判定する。そして、通信制御装置１００は、着信側端末Ｒが着信許可の状態になったことが判定された場合にのみ、着信側端末Ｒにコールバック要求を送信する。そのため、着信側端末Ｒの利用者が、着信許可または不許可の状態であるかを、自ら判断しなくてよくなり、着信側端末Ｒの利用者の手間を削減できる。また、着信側端末Ｒの利用者は、着信不許可の状態であるにもかかわらず、コールバック要求を受けるといった不都合を被ることはない。

また、通信制御装置１００は、発信側端末Ｓまたは着信側端末Ｒのコンテキストを保持する他のシステムがあれば、他のシステムからコンテキストを取得して、着信側端末Ｒの着信許可の状態を判断する指標にしてもよい。

また、図１では、発信側端末Ｓと着信側端末Ｒとは１台ずつだったが、電話会議やテレビ会議の場合に対しても、着信側端末Ｒが複数台であるとして、通信制御装置１００を適用することができる。また、図１では、音声電話を例に挙げているが、音声メールやテキストメールに対しても、通信制御装置１００を適用することができる。

（図１に示した通信システムＣの構成例）
次に、図２を用いて、図１に示した通信システムＣの構成例について説明する。

図２は、図１に示した通信システムＣの構成例を示す説明図である。図２に示すように、通信システムＣは、複数の無線ＬＡＮ２０１と、発信側端末Ｓと、着信側端末Ｒと、コンテキスト管理サーバ１１０と、コールバック制御サーバ１２０と、呼制御サーバ１３０と、他のシステム２０２と、を含む。また、コンテキスト管理サーバ１１０は、場所ＤＢ１１１と、コンテキストＤＢ１１２と、監視コンテキストＤＢ１１３と、を有する。コールバック制御サーバ１２０は、呼制御ＤＢ１２１と、コールバックＤＢ１２２と、を有する。

コンテキスト管理サーバ１１０は、通信端末Ｔから通知された無線ＬＡＮ２０１のＳＳＩＤに対応する場所を場所ＤＢに基づいて特定するサーバである。そして、コンテキスト管理サーバ１１０は、特定した場所を含む通信端末Ｔのコンテキストを、コンテキストＤＢ１１２に格納して管理するサーバである。また、コンテキスト管理サーバ１１０は、通信端末Ｔごとの着信許可である場合のコンテキストを記憶する監視コンテキストＤＢ１１３を保持し、通信端末Ｔが通信許可の状態になったことを検出するサーバである。

コールバック制御サーバ１２０は、呼制御ＤＢ１２１に基づいて、コールバックを行うか否かを判定するサーバである。そして、コールバック制御サーバ１２０は、コールバックのために発信側端末Ｓの電話番号を記憶するコールバックＤＢを記憶するサーバである。また、コールバック制御サーバ１２０は、コールバックを行うと判定した後に、コンテキスト管理サーバ１１０から着信側端末Ｒが着信許可の状態になったことを通知された場合に、着信側端末Ｒと発信側端末Ｓとにコールバックの通信を行わせるサーバである。

呼制御サーバ１３０は、発信側端末Ｓと着信側端末Ｒとの通信の接続および切断を行うサーバである。なお、コールバック制御サーバ１２０は、呼制御サーバ１３０を介して、着信側端末Ｒと発信側端末Ｓとにコールバックの通信を行わせるようにしてもよい。具体的には、呼制御サーバ１３０は、いわゆる第三者呼制御（ｔｈｉｒｄ−ｐａｒｔｙ ｃａｌｌ ｃｏｎｔｒｏｌ）により、着信側端末Ｒと発信側端末Ｓとにコールバックの通信を行わせる。

発信側端末Ｓは、発信側端末Ｓの利用者の操作により、着信側端末Ｒへの呼を発信する端末である。着信側端末Ｒは、発信側端末Ｓが発信した呼が着信される端末である。また、各通信端末Ｔは、自端末のコンテキストを取得するセンサを有し、取得したコンテキストを、無線ＬＡＮ２０１を介して通信制御装置１００に送信する端末である。コンテキストには、例えば、自端末の場所を示す情報として、無線ＬＡＮ２０１のＳＳＩＤが含まれる。他のシステム２０２は、発信側端末Ｓまたは着信側端末Ｒのコンテキストを保持するシステムである。例えば、発信側端末Ｓが発信した呼の用件および緊急度を管理するシステムが挙げられる。

（通信制御装置１００のハードウェア構成例）
次に、図３を用いて、通信制御装置１００のハードウェア構成例について説明する。図１に示したように、通信制御装置１００は、コンテキスト管理サーバ１１０と、コールバック制御サーバ１２０と、呼制御サーバ１３０と、を含む装置である。

図３は、実施の形態にかかる通信制御装置１００に含まれる各サーバのハードウェア構成例を示すブロック図である。図３において、例えば、コンテキスト管理サーバ１１０を想定すると、コンテキスト管理サーバ１１０は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）３０１と、ＲＯＭ（Ｒｅａｄ‐Ｏｎｌｙ Ｍｅｍｏｒｙ）３０２と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）３０３と、磁気ディスクドライブ３０４と、磁気ディスク３０５と、光ディスクドライブ３０６と、光ディスク３０７と、ディスプレイ３０８と、Ｉ／Ｆ（Ｉｎｔｅｒｆａｃｅ）３０９と、キーボード３１０と、マウス３１１と、スキャナ３１２と、プリンタ３１３と、を備えている。また、各構成部はバス３２０によってそれぞれ接続されている。

ここで、ＣＰＵ３０１は、各サーバの全体の制御を司る。ＲＯＭ３０２は、ブートプログラムなどのプログラムを記憶している。ＲＡＭ３０３は、ＣＰＵ３０１のワークエリアとして使用される。また、コンテキスト管理サーバ１１０のＲＡＭ３０３は、場所ＤＢ１１１と、コンテキストＤＢ１１２と、監視コンテキストＤＢ１１３と、を記憶する。磁気ディスクドライブ３０４は、ＣＰＵ３０１の制御にしたがって磁気ディスク３０５に対するデータのリード／ライトを制御する。磁気ディスク３０５は、磁気ディスクドライブ３０４の制御で書き込まれたデータを記憶する。

光ディスクドライブ３０６は、ＣＰＵ３０１の制御にしたがって光ディスク３０７に対するデータのリード／ライトを制御する。光ディスク３０７は、光ディスクドライブ３０６の制御で書き込まれたデータを記憶したり、光ディスク３０７に記憶されたデータをコンピュータに読み取らせたりする。

ディスプレイ３０８は、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示する。このディスプレイ３０８は、例えば、ＣＲＴ、ＴＦＴ液晶ディスプレイ、プラズマディスプレイなどを採用することができる。

インターフェース（以下、「Ｉ／Ｆ」と略する。）３０９は、通信回線を通じてＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）、インターネットなどのネットワーク２１４に接続され、このネットワーク２１４を介して他の装置に接続される。そして、Ｉ／Ｆ３０９は、ネットワーク２１４と内部のインターフェースを司り、外部装置からのデータの入出力を制御する。Ｉ／Ｆ３０９には、例えばモデムやＬＡＮアダプタなどを採用することができる。

キーボード３１０は、文字、数字、各種指示などの入力のためのキーを備え、データの入力を行う。また、タッチパネル式の入力パッドやテンキーなどであってもよい。マウス３１１は、カーソルの移動や範囲選択、あるいはウィンドウの移動やサイズの変更などを行う。ポインティングデバイスとして同様に機能を備えるものであれば、トラックボールやジョイスティックなどであってもよい。

スキャナ３１２は、画像を光学的に読み取り、各サーバ内に画像データを取り込む。なお、スキャナ３１２は、ＯＣＲ（Ｏｐｔｉｃａｌ Ｃｈａｒａｃｔｅｒ Ｒｅａｄｅｒ）機能を持たせてもよい。また、プリンタ３１３は、画像データや文書データを印刷する。プリンタ３１３には、例えば、レーザプリンタやインクジェットプリンタを採用することができる。

また、図３において、例えば、コールバック制御サーバ１２０を想定すると、コールバック制御サーバ１２０は、ＣＰＵ３０１と、ＲＯＭ３０２と、ＲＡＭ３０３と、磁気ディスクドライブ３０４と、磁気ディスク３０５と、光ディスクドライブ３０６と、光ディスク３０７と、ディスプレイ３０８と、Ｉ／Ｆ（Ｉｎｔｅｒｆａｃｅ）３０９と、キーボード３１０と、マウス３１１と、スキャナ３１２と、プリンタ３１３と、を備えている。また、各構成部はバス３２０によってそれぞれ接続されている。各構成部の内容は、コンテキスト管理サーバ１１０を想定して説明した内容と同様であるため説明を省略する。ただし、コールバック制御サーバ１２０のＲＡＭ３０３は、呼制御ＤＢ１２１と、コールバックＤＢ１２２と、を記憶する。

また、図３において、例えば、呼制御サーバ１３０を想定すると、呼制御サーバ１３０は、ＣＰＵ３０１と、ＲＯＭ３０２と、ＲＡＭ３０３と、磁気ディスクドライブ３０４と、磁気ディスク３０５と、光ディスクドライブ３０６と、光ディスク３０７と、ディスプレイ３０８と、Ｉ／Ｆ（Ｉｎｔｅｒｆａｃｅ）３０９と、キーボード３１０と、マウス３１１と、スキャナ３１２と、プリンタ３１３と、を備えている。また、各構成部はバス３２０によってそれぞれ接続されている。各構成部の内容は、コンテキスト管理サーバ１１０を想定して説明した内容と同様であるため説明を省略する。

（場所ＤＢの記憶内容）
次に、図４を用いて、コンテキスト管理サーバ１１０に記憶されている場所ＤＢの記憶内容について説明する。場所ＤＢは、通信制御装置１００（コンテキスト管理サーバ１１０）が、通信端末Ｔがどの場所にあるかを推定する際に参照するＤＢである。

図４は、コンテキスト管理サーバ１１０に記憶されている場所ＤＢの記憶内容を示す説明図である。図４に示すように、場所ＤＢ１１１は、ＳＳＩＤ（Ｓｅｒｖｉｃｅ Ｓｅｔ ＩＤｅｎｔｉｆｉｅｒ）項目に対応付けて、場所項目を有し、ＳＳＩＤごとにレコードを構成する。

ＳＳＩＤ項目には、無線ＬＡＮにおけるアクセスポイントの識別子（以下、「ＳＳＩＤ」という）が記憶されている。なお、ＳＳＩＤは、最大３２文字の英数字である。場所項目には、ＳＳＩＤによって識別されるアクセスポイントが設置されている場所の名称が記憶されている。

（コンテキストＤＢの記憶内容）
次に、図５を用いて、コンテキスト管理サーバ１１０に記憶されているコンテキストＤＢの記憶内容について説明する。コンテキストＤＢは、通信制御装置１００（コンテキスト管理サーバ１１０）が通信端末Ｔの現在のコンテキストを取得する際に参照するＤＢである。

図５は、コンテキスト管理サーバ１１０に記憶されているコンテキストＤＢの記憶内容を示す説明図である。図５に示すように、コンテキストＤＢ１１２は、通信端末Ｔごとに、コンテキスト種別項目に対応付けて、値項目と、コールバックＩＤ項目と、を有し、通信端末Ｔからコンテキストを受信するごとにレコードを構成する。

コンテキスト種別項目には、通信端末Ｔのコンテキストの種別が記憶されている。具体的には、コンテキストの種別には、通信端末Ｔがある場所を示す種別である「場所」や、通信端末Ｔが通話中であるか否かを示す「電話」がある。

値項目には、コンテキストの種別に対応する状態が記憶されている。具体的には、コンテキストの種別の「場所」に対応する値項目には「事務所Ａ」が記憶されている。また、コンテキストの種別「電話」に対応する値項目には、「ｉｄｌｅ」が記憶されている。「ｉｄｌｅ」は、発信側端末Ｓまたは着信側端末Ｒが通話していない状態を示す。コールバックＩＤ項目には、コールバックを識別する識別子が記憶されている。

（監視コンテキストＤＢの記憶内容）
次に、図６を用いて、コンテキスト管理サーバ１１０に記憶されている監視コンテキストＤＢの記憶内容について説明する。監視コンテキストＤＢは、通信制御装置１００（コンテキスト管理サーバ１１０）が、通信端末Ｔが着信許可の状態であるか否かを判定する際に参照するＤＢである。

図６は、コンテキスト管理サーバ１１０に記憶されている監視コンテキストＤＢの記憶内容を示す説明図である。図６に示すように、監視コンテキストＤＢ１１３は、コールバックＩＤ項目に対応付けて、ユーザＩＤ項目と、コンテキスト種別項目と、値項目と、を有し、コールバック制御サーバ１２０からコールバック契機通知要求が通知されるごとにレコードを構成する。

コールバックＩＤ項目には、コールバックを識別する識別子が記憶されている。ユーザＩＤ項目には、発信側端末Ｓまたは着信側端末Ｒの識別子が記憶されている。コンテキスト種別項目には、発信側端末Ｓまたは着信側端末Ｒのコンテキストの種別が記憶されている。値項目には、コンテキストの種別に対応する状態が記憶されている。

（呼制御ＤＢの記憶内容）
次に、図７を用いて、コールバック制御サーバ１２０に記憶されている呼制御ＤＢの記憶内容について説明する。呼制御ＤＢは、通信制御装置１００（コールバック制御サーバ１２０）が、通信端末Ｔが着信不許可の状態であるか否かを判定する際に参照するＤＢである。

図７は、コールバック制御サーバ１２０に記憶されている呼制御ＤＢの記憶内容を示す説明図である。図７に示すように、呼制御ＤＢ１２１は、通信端末Ｔごとに、コンテキスト種別項目に対応付けて、値項目を有し、通信端末Ｔから着信不許可の状態に対応するコンテキストの条件（以下、「呼制御条件」という）を受信するごとにレコードを構成する。

コンテキスト種別項目には、コンテキストの種別が記憶されている。具体的には、コンテキストの種別には、通信端末Ｔがある場所を示す種別である「場所」や、通信端末Ｔが通話中であるか否かを示す「電話」がある。

値項目には、通信端末Ｔが着信不許可である状態に対応するコンテキストの種別の状態が記憶されている。具体的には、通信端末Ｔが着信不許可である状態に対応するコンテキストの種別「場所」の状態として、値項目には「会議室」が記憶されている。

（コールバックＤＢの記憶内容）
次に、図８を用いて、コールバック制御サーバ１２０に記憶されているコールバックＤＢの記憶内容について説明する。コールバックＤＢは、通信制御装置１００がコールバックを実行する際に使用する発信側端末Ｓの電話番号やＩＰアドレスを特定するために参照するＤＢである。

図８は、コールバック制御サーバ１２０に記憶されているコールバックＤＢの記憶内容を示す説明図である。図８に示すように、コールバックＤＢ１２２は、コールバックＩＤ項目に対応付けて、ユーザ種別項目と、電話番号項目と、ＩＰアドレス項目と、を有し、発信側端末Ｓからの呼が着信側端末Ｒに受け付けられなかったときにレコードを構成する。

コールバックＩＤ項目の記憶内容は、図６に示したコールバックＩＤ項目の記憶内容と同様のため説明を省略する。ユーザ種別項目には、発信側端末Ｓまたは着信側端末Ｒの識別子が記憶されている。電話番号項目には、ユーザＩＤ項目の内容から識別される通信端末Ｔの電話番号が記憶されている。ＩＰアドレス項目には、ユーザＩＤ項目の内容から識別される通信端末ＴのＩＰアドレスが記憶されている。

（通信制御装置１００の機能的構成例）
次に、図９を用いて、通信制御装置１００の機能的構成例について説明する。

図９は、通信制御装置１００の機能的構成を示すブロック図である。通信制御装置１００は、記憶部９０１と、検出部９０２と、判断部９０３と、送信部９０４と、を含む構成である。この制御部となる機能（記憶部９０１〜送信部９０４）は、具体的には、例えば、図３に示したＲＯＭ３０２、ＲＡＭ３０３、磁気ディスク３０５、光ディスク３０７などの記憶装置に記憶されたプログラムをＣＰＵ３０１に実行させることにより、または、Ｉ／Ｆ３０９により、その機能を実現する。

記憶部９０１は、着信許可または不許可を示すコンテキストを端末ごとに記憶する機能を有する。ここで、コンテキストとは、通信端末Ｔの状態であり、例えば、通信端末Ｔの場所、または通信端末Ｔが通信中か否かの状態である。着信許可または不許可を示すコンテキストとは、通信端末Ｔが着信許可または不許可の状態になるコンテキストであり、具体的には、例えば、不許可を示すコンテキストとして、会議室が挙げられる。

具体的には、例えば、記憶部９０１は、上述した呼制御ＤＢ１２１および監視コンテキストＤＢ１１３を記憶する。これにより、通信端末Ｔのコンテキストに基づいて、通信装置が着信許可の状態であるか否かを判定することができるようになる。

検出部９０２は、第１の端末からの発信を第２の端末が受け付けなかったことを検出する機能を有する。ここで、第１の端末とは、上述した発信側端末Ｓである。第２の端末とは、上述した着信側端末Ｒである。

具体的には、例えば、検出部９０２は、第１の端末からの発信について第２の端末で着信拒否の操作が行われたことを検出する。より具体的には、例えば、検出部９０２は、発信側端末Ｓからの呼を着信拒否するイベントがあったことの通知を、着信側端末Ｒから受信することにより、着信側端末Ｒで着信拒否の操作が行われたことを検出する。これにより、コールバック要求の送信の可否の判定を開始するトリガを検出できる。

具体的には、例えば、検出部９０２は、第１の端末から第２の端末へ発信されたことが検出されたときに、記憶部９０１を参照することにより、第２の端末が着信不許可の状態であると判断された場合、第１の端末からの発信を第２の端末が受け付けなかったことを検出する。より具体的には、例えば、検出部９０２は、呼制御サーバ１３０が呼制御ＤＢ１２１を参照して、発信側端末Ｓから着信側端末Ｒへの呼の着信を拒否したことを検出する。これにより、コールバック要求の送信の可否の判定を開始するトリガを検出できる。

また、検出部９０２は、第１の端末からコールバック要求の取消し要求を検出する機能を有する。具体的には、検出部９０２は、発信側端末Ｓからコールバック要求の取消し要求が通知されることにより、取消し要求を検出する。これにより、発信側端末Ｓの利用者が、コールバックされなくてもよい状態になった場合に、不要なコールバックが行われることを防止する処理を開始するためのトリガを検出することができる。なお、検出結果は、ＲＡＭ３０３、磁気ディスク３０５、光ディスク３０７などの記憶領域に記憶される。

判断部９０３は、検出部９０２によって第１の端末からの発信を第２の端末が受け付けなかったことが検出された場合、記憶部９０１を参照することにより、第２の端末が着信許可の状態であるか否かを判断する機能を有する。ここで、第１の端末からの発信とは、上述した発信側端末Ｓから発信される呼である。

具体的には、例えば、判断部９０３は、検出部９０２によって第１の端末からの発信を第２の端末が受け付けなかったことが検出された場合、記憶部９０１を参照することにより、第１の端末からの発信について第２の端末が着信許可の状態であるか否かを判断する。

より具体的には、例えば、検出部９０２によって発信側端末Ｓからの呼を着信側端末Ｒが受け付けなかったことが検出された場合を想定する。この場合、判断部９０３は、監視コンテキストＤＢ１１３を参照することにより、着信側端末Ｒが着信許可の状態になったか否かを判断する。これにより、着信側端末Ｒが着信許可の状態にあるときのみ、コールバック要求の送信を開始することができる。

具体的には、例えば、判断部９０３は、検出部９０２によって第１の端末からの発信を第２の端末が受け付けなかったことが検出された場合、記憶部９０１を参照することにより、第１および第２の端末が着信許可の状態であるか否かを判断する。

より具体的には、例えば、検出部９０２によって発信側端末Ｓからの呼を着信側端末Ｒが受け付けなかったことが検出された場合を想定する。この場合、判断部９０３は、監視コンテキストＤＢ１１３を参照することにより、着信側端末Ｒおよび発信側端末Ｓの双方が着信許可の状態になったか否かを判断する。これにより、着信側端末Ｒおよび発信側端末Ｓの双方が着信許可の状態にあるときのみ、コールバック要求の送信を開始することができる。

具体的には、例えば、判断部９０３は、検出部９０２によって第１の端末からの発信を第２の端末が受け付けなかったことが検出された場合、記憶部９０１を参照することにより、第１の端末からの発信について第２の端末が着信許可の状態であるか否かを判断し、かつ、第１の端末が着信許可の状態であるか否かを判断する。

より具体的には、例えば、着信側端末Ｒが発信側端末Ｓからの呼の用件や緊急度、または発信側端末Ｓの利用者との関係（例えば、着信側端末Ｒの利用者にとって発信側端末Ｓの利用者が顧客であること）に基づいて着信許可の状態であるかを判断する場合を想定する。そして、検出部９０２によって発信側端末Ｓからの呼を着信側端末Ｒが受け付けなかったことが検出された場合を想定する。この場合、判断部９０３は、呼の用件や緊急度を含む監視コンテキストＤＢ１１３を参照することにより、発信側端末Ｓからの呼に関して着信側端末Ｒが着信許可の状態になったか否かを判断する。また、判断部９０３は、発信側端末Ｓが着信許可の状態になったか否かを判断する。

これにより、発信側端末Ｓとの通信に関して着信側端末Ｒが着信許可の状態にあり、かつ、発信側端末Ｓが着信許可の状態のときのみ、コールバック要求の送信を開始することができる。そのため、例えば、顧客の発信側端末Ｓへのコールバックと同僚の発信側端末Ｓへのコールバックとをそれぞれ異なる基準（監視コンテキスト）で行うようにすることができ、着信側端末Ｒの利便性を向上できる。

具体的には、例えば、判断部９０３は、検出部９０２によって第１の端末からの発信を第２の端末が受け付けなかったことが検出された場合、記憶部９０１を参照することにより、第１の端末からの発信について第２の端末が着信許可の状態であるか否かを判断し、かつ、第２の端末からの発信について第１の端末が着信許可の状態であるか否かを判断する。

より具体的には、例えば、着信側端末Ｒが発信側端末Ｓからの呼の用件や緊急度に基づいて着信許可の状態であるか否かを判断し、かつ、発信側端末Ｓが着信側端末Ｒからの呼の用件や緊急度に基づいて着信許可の状態であるか否かを判断する場合を想定する。また、各通信端末Ｔは、自端末の利用者と通信相手の通信端末Ｔの利用者との関係をさらに参照してもよい。そして、検出部９０２によって発信側端末Ｓからの呼を着信側端末Ｒが受け付けなかったことが検出された場合を想定する。この場合、判断部９０３は、呼の用件や緊急度を含む監視コンテキストＤＢ１１３を参照することにより、発信側端末Ｓとの通信に関して着信側端末Ｒが着信許可の状態になったか否かを判断する。また、判断部９０３は、着信側端末Ｒとの通信に関して発信側端末Ｓが着信許可の状態になったか否かを判断する。

これにより、発信側端末Ｓとの通信に関して着信側端末Ｒが着信許可の状態にあり、かつ、着信側端末Ｒとの通信に関して発信側端末Ｓが着信許可の状態のときのみ、コールバック要求の送信を開始することができる。そのため、例えば、顧客の通信端末Ｔとのコールバックに関する通話と同僚の通信端末Ｔとのコールバックに関する通話をそれぞれ異なる基準（監視コンテキスト）で行うようにすることができ、通信端末Ｔの利便性を向上できる。また、呼の用件や緊急度に応じて異なる基準（監視コンテキスト）で、着信許可の状態か否かを判断することができ、通信端末Ｔの利便性を向上できる。なお、判断結果は、ＲＡＭ３０３、磁気ディスク３０５、光ディスク３０７などの記憶領域に記憶される。

送信部９０４は、判断部９０３によって着信許可の状態であると判断された場合、第１の端末へのコールバック要求を第２の端末に送信する機能を有する。ここで、コールバック要求とは、例えば、発信側端末Ｓを識別する識別子になる発信側端末Ｓの電話番号を含んだメッセージである。また、コールバック要求とは、例えば、発信側端末Ｓへのコールバックを実行するアプリケーションであってもよい。また、コールバック要求とは、例えば、呼制御サーバ１３０からの着信要求であってもよい。

具体的には、例えば、送信部９０４は、判断部９０３によって、着信側端末Ｒ、または着信側端末Ｒと発信側端末Ｓとの双方、が着信許可の状態であると判断された場合、発信側端末Ｓへのコールバック要求を着信側端末Ｒに送信する。ただし、コールバック要求が呼制御サーバ１３０からの着信要求である場合、送信部９０４は、発信側端末Ｓにも着信要求を送信して、着信側端末Ｒと発信側端末Ｓと通信を開始させる。これにより、着信側端末Ｒに発信側端末Ｓへのコールバックを行わせることができる。

また、送信部９０４は、検出部９０２によって取消し要求が検出された場合、コールバック要求を第２の端末に送信しない機能を有する。具体的には、例えば、送信部９０４は、検出部９０２によって取消し要求が検出された場合、コールバック要求を着信側端末Ｒに送信しない。これにより、不要なコールバック要求を行わないようにする。

（実施例１）
ここで、図１０〜図１６を用いて、実施例１について説明する。実施例１は、着信側端末Ｒからの着信拒否イベントがあったことの通知を受けることにより、通信制御装置１００が発信側端末Ｓからの呼を着信側端末Ｒが受け付けなかったことを検出する場合の実施例である。

（実施例１にかかる通信制御装置１００による着信者へのコールバック要求の送信例１の内容）
次に、図１０を用いて、実施例１にかかる通信制御装置１００による着信者へのコールバック要求の送信例１の内容について説明する。送信例１は、通信制御装置１００が、着信側端末Ｒが着信許可の状態か否かに基づいて、コールバック要求を送信する例である。

図１０は、実施例１にかかる通信制御装置１００による着信者へのコールバック要求の送信例１の内容を示す説明図である。図１０では、図１と同様に、発信者が有する発信側端末Ｓと、着信者が有する着信側端末Ｒと、通信制御装置１００と、を含む通信システムを示す。通信制御装置１００は、コンテキスト管理サーバ１１０と、コールバック制御サーバ１２０と、呼制御サーバ１３０と、を含む装置である。

（１）まず、発信側端末Ｓは、着信側端末Ｒに呼を発信する。（２）ここで、着信側端末Ｒは、発信側端末Ｓからの呼を着信拒否する。着信拒否は、例えば、着信者が着信側端末Ｒを操作することにより行われる。また、着信者の着信側端末Ｒへの操作がなく呼が一定時間着信されなかったことを、着信拒否とみなしてもよい。

（３）着信側端末Ｒは、呼を着信拒否すると、着信拒否のイベントがあったことを通信制御装置１００に通知する。（４）通信制御装置１００は、着信側端末Ｒから着信拒否のイベントがあったことの通知を受けると、コールバック要求の送信の可否の判定を開始し、着信側端末Ｒのコンテキストを監視する。

（５）ここで、着信側端末Ｒが、役員会議室から休憩室へ移動した場合を想定する。（６）着信側端末Ｒは、休憩室に移動すると、着信側端末Ｒのコンテキストを、通信制御装置１００に通知する。ここでは、コンテキストは、着信側端末Ｒの場所である。

（７）次に、通信制御装置１００は、着信側端末Ｒのコンテキストの通知を受けると、予め保持しておいた監視コンテキストＤＢ１１３を参照して、着信側端末Ｒが着信許可の状態であるか否かを判定する。

（８）着信側端末Ｒが着信許可の状態である場合、通信制御装置１００は、コールバックＤＢ１２２を参照して、コールバック要求を作成する。例えば、コールバック要求には、コールバックＤＢ１２２から抽出した発信側端末Ｓの電話番号が含まれている。（９）そして、通信制御装置１００は、作成したコールバック要求を着信側端末Ｒに送信する。

（１０）コールバック要求を受けた着信側端末Ｒは、コールバック要求に含まれている電話番号に対してコールバックを行い、発信側端末Ｓとの通話を開始する。

このように、通信制御装置１００は、着信側端末Ｒのコンテキストを取得し、自動的に着信側端末Ｒが着信許可の状態になったか否かを判定する。そして、通信制御装置１００は、着信側端末Ｒが着信許可の状態になったことが判定された場合にのみ、着信側端末Ｒにコールバック要求を送信する。そのため、着信側端末Ｒの利用者が、コールバックが必要であることを憶えていなくてもよくなり、着信側端末Ｒの利用者の手間を削減できる。また、着信側端末Ｒの利用者は、着信不許可の状態であるにもかかわらず、コールバック要求を受けるといった不都合を被ることはない。

（実施例１にかかる通信制御装置１００による着信者へのコールバック要求の送信例２の内容）
次に、図１１を用いて、実施例１にかかる通信制御装置１００による着信者へのコールバック要求の送信例２の内容について説明する。送信例２は、通信制御装置１００が、着信側端末Ｒが着信許可の状態か否かと、発信側端末Ｓが着信許可の状態か否かと、に基づいて、コールバック要求を送信する例である。

図１１は、実施例１にかかる通信制御装置１００による着信者へのコールバック要求の送信例２の内容を示す説明図である。図１１では、図１と同様に、発信者が有する発信側端末Ｓと、着信者が有する着信側端末Ｒと、通信制御装置１００と、を含む通信システムを示す。通信制御装置１００は、コンテキスト管理サーバ１１０と、コールバック制御サーバ１２０と、呼制御サーバ１３０と、を含む装置である。

（１）〜（３）の処理は、図１０の（１）〜（３）と同様の処理のため、ここでは、説明を省略する。（４）次に、通信制御装置１００は、着信側端末Ｒから着信拒否のイベントがあったことの通知を受けると、コールバック要求の送信の可否の判定を開始し、着信側端末Ｒおよび発信側端末Ｓのコンテキストを監視する。

（５）ここで、着信側端末Ｒが、役員会議室から休憩室へ移動した場合を想定する。（６）着信側端末Ｒは、休憩室に移動すると、通信制御装置１００に、着信側端末Ｒのコンテキストを通知する。また、発信側端末Ｓは、通信制御装置１００に、発信側端末Ｓのコンテキストを通知する。ここでは、コンテキストは、着信側端末Ｒの場所である。

（７）次に、通信制御装置１００は、着信側端末Ｒのコンテキストの通知を受けると、予め保持しておいた監視コンテキストＤＢ１１３を参照して、着信側端末Ｒが着信許可の状態であるか否かを判定する。また、通信制御装置１００は、コンテキストＤＢ１１２の発信側端末Ｓのコンテキストから、発信側端末Ｓが着信拒否の状態であるか否かを判定する。

（８）着信側端末Ｒと発信側端末Ｓとの双方が着信許可の状態である場合、通信制御装置１００は、コールバックＤＢ１２２を参照して、コールバック要求を作成する。例えば、コールバック要求には、コールバックＤＢ１２２から抽出した発信側端末Ｓの電話番号が含まれている。（９）そして、通信制御装置１００は、作成したコールバック要求を着信側端末Ｒに送信する。

（１０）コールバック要求を受けた着信側端末Ｒは、コールバック要求に含まれている電話番号に対してコールバックを行い、発信側端末Ｓとの通話を開始する。

このように、通信制御装置１００は、着信側端末Ｒのコンテキストを取得し、自動的に着信側端末Ｒが着信許可の状態になったか否かを判定する。そして、通信制御装置１００は、着信側端末Ｒが着信許可の状態になったことが判定された場合にのみ、着信側端末Ｒにコールバック要求を送信する。そのため、着信側端末Ｒの利用者が、コールバックが必要であることを憶えていなくてもよくなり、着信側端末Ｒの利用者の手間を削減できる。また、着信側端末Ｒの利用者は、着信不許可の状態であるにもかかわらず、コールバック要求を受けるといった不都合を被ることはない。

（実施例１にかかる通信制御装置１００内における各サーバの具体的な通信内容）
ここで、図１２および図１３を用いて、図１０に示した実施例１にかかる通信制御装置１００内における各サーバの具体的な通信内容について説明する。

（実施例１における発信側端末Ｓから呼が発信されるときの各サーバの通信内容の詳細）
まず、図１２を用いて、実施例１における発信側端末Ｓから呼が発信されるときの各サーバの通信内容の詳細について説明する。

図１２は、実施例１における発信側端末Ｓから呼が発信されるときの各サーバの通信内容の詳細を示すシーケンス図である。まず、着信側端末Ｒは、呼制御条件をコールバック制御サーバ１２０に送信する（ステップＳ１２０１）。コールバック制御サーバ１２０は、受信した呼制御条件に基づいて、呼制御ＤＢ１２１を更新する。

次に、着信側端末Ｒは、自端末の状態を示すコンテキストをコンテキスト管理サーバ１１０に通知する（ステップＳ１２０２）。コンテキスト管理サーバ１１０は、受信したコンテキストに基づいて、コンテキストＤＢ１１２を更新する。例えば、コンテキスト管理サーバ１１０は、コンテキストに含まれるＳＳＩＤから、場所ＤＢ１１１に基づいて、通信端末Ｔの場所を特定して、コンテキストＤＢ１１２を更新する。

ここで、発信側端末Ｓから着信側端末Ｒへの呼が発信される（ステップＳ１２０３）。着信側端末Ｒは、呼が着信されると、コンテキスト管理サーバ１１０に通話中であることを示すコンテキストを送信する（ステップＳ１２０４）。コンテキスト管理サーバ１１０は、受信したコンテキストに基づいて、コンテキストＤＢ１１２を更新する。

次に、着信側端末Ｒは、着信者の操作を受けて、呼の着信を拒否する。そして、着信側端末Ｒは、コンテキスト管理サーバ１１０に着信拒否のイベントがあったことを通知する（ステップＳ１２０５）。コンテキスト管理サーバ１１０は、着信拒否のイベントがあったことにより、コンテキストＤＢ１１２を更新する。

次に、着信側端末Ｒは、コールバック制御サーバ１２０に着信拒否のイベントがあったことを通知する（ステップＳ１２０６）。着信拒否のイベントがあったことを通知されたコールバック制御サーバ１２０は、呼制御ＤＢ１２１を参照し（ステップＳ１２０７）、コールバック契機通知要求をコンテキスト管理サーバ１１０に通知する（ステップＳ１２０８）。コールバック契機通知要求は、コンテキスト管理サーバ１１０に着信側端末Ｒのコンテキストを監視させ、着信許可の状態になった際に、コールバック制御サーバ１２０へ通知させる要求である。

そして、コールバック制御サーバ１２０は、コールバックＤＢ１２２に、コールバック情報を登録する（ステップＳ１２０９）。コールバック情報は、例えば、コールバックの際に使用する発信側端末Ｓの電話番号およびＩＰアドレスである。これにより、コンテキスト管理サーバ１１０に、着信側端末Ｒのコンテキストの監視を開始させて、コールバック要求の送信のトリガを発生させることができる。

（実施例１におけるコールバック制御サーバ１２０によりコールバック要求が送信されるときの各サーバの通信内容の詳細）
次に、図１３を用いて、実施例１におけるコールバック制御サーバ１２０によりコールバック要求が送信されるときの各サーバの通信内容の詳細について説明する。ここで、図１２においてコンテキスト管理サーバ１１０にコンテキストを監視されている着信側端末Ｒが移動を行い、着信側端末Ｒのコンテキストが着信許可の状態に変化した場合を想定する。

図１３は、実施例１におけるコールバック制御サーバ１２０によりコールバック要求が送信されるときの各サーバの通信内容の詳細を示すシーケンス図である。まず、着信側端末Ｒは、移動によりコンテキストが変化すると、自端末の状態を示すコンテキストをコンテキスト管理サーバ１１０に通知する（ステップＳ１３０１）。

コンテキストの通知を受けたコンテキスト管理サーバ１１０は、監視コンテキストＤＢ１１３を参照して、着信側端末Ｒが着信許可の状態になったか否かを判定する。そして、コンテキスト管理サーバ１１０は、着信側端末Ｒが着信許可の状態であれば、コールバック契機通知をコールバック制御サーバ１２０に通知する（ステップＳ１３０２）。

コールバック契機通知を受けたコールバック制御サーバ１２０は、コールバックＤＢ１２２を参照し（ステップＳ１３０３）、コールバック要求を作成する。そして、コールバック制御サーバ１２０は、作成したコールバック要求を着信側端末Ｒに送信する（ステップＳ１３０４）。

そして、コールバック要求を受けた着信側端末Ｒは、コールバック要求に含まれる発信側端末Ｓの電話番号に基づいて、発信側端末Ｓへコールバックを行う（ステップＳ１３０５）。

これにより、着信者が自らコールバックが必要であることを憶えておくことなく、通信制御装置１００により自動的に着信側端末Ｒが着信許可の状態か否かが判定される。そして、通信制御装置１００は、着信側端末Ｒが着信許可の状態のときのみコールバック要求を送信する。

そのため、着信者が、コールバックが必要であることを憶えておく手間を削減できる。また、着信側端末Ｒが着信不許可の状態であるにもかかわらず、コールバック要求が受信されるといった不都合はなく、着信側端末Ｒの利便性を向上できる。

（実施例１におけるコールバック制御サーバ１２０のコールバック制御処理の処理内容の詳細）
次に、図１４を用いて、実施例１におけるコールバック制御サーバ１２０のコールバック制御処理の処理内容の詳細について説明する。図１４では、図１２および図１３において、コールバック制御サーバ１２０が行ったコールバック制御処理の処理内容について説明する。

図１４は、実施例１におけるコールバック制御サーバ１２０のコールバック制御処理の処理内容の詳細を示すフローチャートである。まず、コールバック制御サーバ１２０は、着信拒否イベントを受信したか否かを判定する（ステップＳ１４０１）。ここで、着信拒否イベントを受信していない場合（ステップＳ１４０１：Ｎｏ）、コールバック制御サーバ１２０は、ステップＳ１４０１に戻り、着信拒否イベントの受信を待つ。

一方、着信拒否イベントを受信した場合（ステップＳ１４０１：Ｙｅｓ）、コールバック制御サーバ１２０は、呼制御ＤＢ１２１を参照して、着信側端末Ｒの呼制御条件を取得する（ステップＳ１４０２）。

次に、コールバック制御サーバ１２０は、取得した呼制御条件に基づいて、着信側端末Ｒの着信許可の状態に対応する監視コンテキストを生成する（ステップＳ１４０３）。そして、コールバック制御サーバ１２０は、コンテキスト管理サーバ１１０に、生成した監視コンテキストを含むコールバック契機通知要求を送信する（ステップＳ１４０４）。

次に、コールバック制御サーバ１２０は、コールバックＤＢ１２２にコールバック情報を登録する（ステップＳ１４０５）。以上のステップＳ１４０１〜ステップＳ１４０５の処理が、ステップＳ１２０６〜ステップＳ１２０９の処理に対応する処理である。

次に、コールバック制御サーバ１２０は、コンテキスト管理サーバ１１０からのコールバック契機通知を受信したか否かを判定する（ステップＳ１４０６）。ここで、コールバック契機通知を受信していない場合（ステップＳ１４０６：Ｎｏ）、コールバック制御サーバ１２０は、ステップＳ１４０６に戻り、コールバック契機通知の受信を待つ。

一方、コールバック契機通知を受信した場合（ステップＳ１４０６：Ｙｅｓ）、コールバック制御サーバ１２０は、コールバックＤＢ１２２からコールバック情報を取得し（ステップＳ１４０７）、コールバック要求を送信する（ステップＳ１４０８）。そして、コールバック制御サーバ１２０は、コールバック制御処理を終了する。以上のステップＳ１４０６〜ステップＳ１４０８の処理が、ステップＳ１３０２〜ステップＳ１３０４の処理に対応する処理である。

これにより、通信制御装置１００は、着信側端末Ｒが着信許可の状態になった場合にのみ、コールバック要求を送信することができる。着信者が、コールバックが必要であることを憶えておく手間を削減できる。また、着信側端末Ｒが着信不許可の状態であるにもかかわらず、コールバック要求が受信されるといった不都合はなく、着信側端末Ｒの利便性を向上できる。

（実施例１におけるコンテキスト管理サーバ１１０の監視コンテキスト登録処理の処理内容の詳細）
次に、図１５を用いて、実施例１におけるコンテキスト管理サーバ１１０の監視コンテキスト登録処理の処理内容の詳細について説明する。図１５では、図１２において、コンテキスト管理サーバ１１０が行った監視コンテキスト登録処理の処理内容について説明する。

図１５は、実施例１におけるコンテキスト管理サーバ１１０の監視コンテキスト登録処理の処理内容の詳細を示すフローチャートである。まず、コンテキスト管理サーバ１１０は、コールバック制御サーバ１２０から、コールバック契機通知要求を受信したか否かを判定する（ステップＳ１５０１）。ここで、コールバック契機通知要求を受信していない場合（ステップＳ１５０１：Ｎｏ）、コンテキスト管理サーバ１１０は、ステップＳ１５０１に戻り、コールバック契機通知要求の受信を待つ。

一方、コールバック契機通知を受信した場合（ステップＳ１５０１：Ｙｅｓ）、コンテキスト管理サーバ１１０は、コールバック契機通知要求から監視コンテキストを抽出して、監視コンテキストＤＢ１１３に登録する（ステップＳ１５０２）。そして、コンテキスト管理サーバ１１０は、監視コンテキスト登録処理を終了する。

以上のステップＳ１５０１〜ステップＳ１５０２の処理が、ステップＳ１２０８の処理によりコールバック契機通知要求を送信されたコンテキスト管理サーバ１１０が行う処理である。これにより、コンテキスト管理サーバ１１０は、通信端末Ｔの着信許可の状態に対応する監視コンテキストを監視コンテキストＤＢ１１３に登録し、通信端末Ｔが着信許可の状態になったか否かを監視できるようになる。

（実施例１におけるコンテキスト管理サーバ１１０のコールバック契機通知送信処理の処理内容の詳細）
次に、図１６を用いて、実施例１におけるコンテキスト管理サーバ１１０のコールバック契機通知送信処理の処理内容の詳細について説明する。図１６では、図１３において、コンテキスト管理サーバ１１０が行ったコールバック契機通知送信処理の処理内容について説明する。

図１６は、実施例１におけるコンテキスト管理サーバ１１０のコールバック契機通知送信処理の処理内容の詳細を示すフローチャートである。まず、コンテキスト管理サーバ１１０は、コンテキストＤＢ１１２が更新されたか否かを判定する（ステップＳ１６０１）。例えば、コンテキストＤＢ１１２の更新は、通信端末Ｔからのコンテキストを受け付けた際に行われる。ここで、コンテキストＤＢ１１２が更新されていない場合（ステップＳ１６０１：Ｎｏ）、コンテキスト管理サーバ１１０は、ステップＳ１６０１に戻り、コンテキストＤＢ１１２の更新を待つ。

一方、コンテキストＤＢ１１２が更新された場合（ステップＳ１６０１：Ｙｅｓ）、コンテキスト管理サーバ１１０は、更新されたコンテキストＤＢ１１２のレコードに、コールバックＩＤの登録があるか否かを判定する（ステップＳ１６０２）。ここで、コールバックＩＤの登録がない場合（ステップＳ１６０２：Ｎｏ）、コンテキスト管理サーバ１１０は、コールバック契機通知送信処理を終了する。

一方、コールバックＩＤの登録がある場合（ステップＳ１６０２：Ｙｅｓ）、コンテキスト管理サーバ１１０は、登録されているコールバックＩＤに対応する監視コンテキストＤＢ１１３の全レコードの条件が満たされたか否かを判定する（ステップＳ１６０３）。ここで、満たされていない条件がある場合（ステップＳ１６０３：Ｎｏ）、コンテキスト管理サーバ１１０は、コールバック契機通知送信処理を終了する。

一方、全レコードの条件が満たされている場合（ステップＳ１６０３：Ｙｅｓ）、コンテキスト管理サーバ１１０は、コールバック制御サーバ１２０に、コールバック契機通知を送信し（ステップＳ１６０４）、コールバック契機通知送信処理を終了する。以上のステップＳ１６０１〜ステップＳ１６０４の処理が、ステップＳ１３０２の処理に対応する処理である。

これにより、コンテキスト管理サーバ１１０は、監視対象となる通信端末Ｔのコンテキストを監視し、通信端末Ｔが着信許可の状態になった場合に、コールバック制御サーバ１２０にコールバック契機通知を送信することができる。

（実施例２）
ここで、図１７〜図３０を用いて、実施例２について説明する。実施例２は、通信制御装置１００が、呼制御サーバ１３０により、着信側端末Ｒと発信側端末Ｓとの通信を制御している場合の実施例である。また、実施例２は、呼制御サーバ１３０が発信側端末Ｓからの呼を着信側端末Ｒへ着信させなかったことを検出することにより、通信制御装置１００が発信側端末Ｓからの呼を着信側端末Ｒが受け付けなかったことを検出する場合の実施例である。

実施例２では、呼の用件および緊急度を、発信者が発信側端末Ｓに入力するようにする。そして、通信制御装置１００は、発信側端末Ｓから呼の用件および緊急度を受信することにより、呼の用件および緊急度を考慮したコールバック要求の送信を行う。実施例２では、呼の用件の一例として、会社において出張許可を求める伝票の承認を上司に要求するといった用件を例に挙げる。ただし、呼の用件および緊急度を、発信者が他のシステム２０２に入力するようになっている場合、通信制御装置１００は、他のシステム２０２から呼の用件および緊急度を受信することにより、呼の用件および緊急度を考慮したコールバック要求の送信を行う。

また、通信制御装置１００が行うコールバック要求が不要になる場合が想定される。例えば、コールバック要求が送信される前に、発信者と着信者とが直に会って呼の用件が口頭により伝えられた場合である。そのため、実施例２では、通信制御装置１００は、発信側端末Ｓからの要求により、コールバック要求を中止できるようにする。

（実施例２にかかる通信端末Ｔの画面表示例）
まず、図１７を用いて、実施例２にかかる通信端末Ｔの画面表示例について説明する。

図１７は、実施例２にかかる通信端末Ｔの画面表示例を示す説明図である。具体的には、図１７（ａ）には、呼の用件および緊急度を入力することができる発信側端末Ｓの画面表示例を示す。（ａ）に示すように、発信側端末Ｓの画面には、着信先電話番号を入力する部分と、呼の用件および緊急度を入力する部分と、が含まれている。この画面に発信者が入力した呼の用件および緊急度が、発信側端末Ｓや、通信制御装置１００に通知されることになる。

また、図１７（ｂ）には、呼の用件および緊急度を表示することができる着信側端末Ｒの画面表示例を示す。（ｂ）に示すように、着信側端末Ｒの画面には、発信元の電話番号を表示する部分と、呼の用件および緊急度を表示する部分と、が含まれている。この画面が表示されることにより、着信者は、呼の用件および緊急度を確認して、着信許可または不許可を判断することができる。

（実施例２にかかるコンテキストＤＢ１１２の記憶内容）
まず、図１８を用いて、実施例２にかかるコンテキストＤＢ１１２の記憶内容について説明する。実施例２でも、コンテキストＤＢ１１２には、実施例１におけるコンテキストＤＢ１１２と同様の内容が記憶されている。

図１８は、コンテキストＤＢ１１２の記憶内容を示す説明図である。図１８に示すように、コンテキスト管理サーバ１１０は、通信端末Ｔごとに、コンテキストＤＢ１１２を有する。コンテキストＤＢ１１２は、コンテキスト種別項目に対応付けて、値項目と、コールバックＩＤ項目と、を有し、通信端末Ｔからコンテキストを受信するごとにレコードを構成する。

コンテキスト種別項目には、発信側端末Ｓまたは着信側端末Ｒのコンテキストの種別が記憶されている。具体的には、コンテキストの種別には、実施例１で示した「場所」、「電話」の他に、呼の用件の一例である伝票の承認が必要であるか否かを示す「伝票承認」がある。

値項目には、コンテキストの種別に対応する状態が記憶されている。具体的には、コンテキストの種別の「伝票承認」に対応する値項目には「ユーザＡ」が記憶されている。「ユーザＡ」は、伝票の承認を申請した発信側端末Ｓの利用者のＩＤである。コールバックＩＤ項目には、コールバックを識別する識別子が記憶されている。この伝票情報は、例えば、発信側端末Ｓの利用者が電子伝票システムにおいて、着信側端末Ｒの利用者に対して伝票の承認を依頼すると、コンテキスト管理サーバ１１０に通知され、コンテキストＤＢ１１２に記憶される。

（コールバック要求の中止に関する監視コンテキストを含む監視コンテキストＤＢ１１３の記憶内容）
次に、図１９を用いて、コールバック要求の中止に関する監視コンテキストを含む監視コンテキストＤＢ１１３の記憶内容について説明する。実施例２では、コールバック要求を中止する場合があるため、監視コンテキストＤＢ１１３にはコールバック要求の中止に関する監視コンテキストが記憶されている。

図１９は、コールバック要求の中止に関する監視コンテキストを含む監視コンテキストＤＢ１１３の記憶内容を示す説明図である。図１９に示すように、監視コンテキストＤＢ１１３は、コールバックＩＤ項目に対応付けて、種別項目と、ユーザＩＤ項目と、コンテキスト種別項目と、値項目と、を有し、コールバック制御サーバ１２０からコールバック契機通知要求が通知されるごとにレコードを構成する。

コールバックＩＤ項目には、コールバックを識別する識別子が記憶されている。種別項目には、コールバック要求の送信を実行する条件になるレコードであることを示す「実行」、または、コールバック要求の送信を中止する条件になるレコードであることを示す「中止」が記憶されている。ユーザＩＤ項目には、発信側端末Ｓまたは着信側端末Ｒの識別子が記憶されている。コンテキスト種別項目には、発信側端末Ｓまたは着信側端末Ｒのコンテキストの種別が記憶されている。値項目には、コンテキストの種別に対応する状態が記憶されている。

（呼の用件および緊急度を含む呼制御ＤＢ１２１の記憶内容）
次に、図２０を用いて、呼の用件および緊急度を含む呼制御ＤＢ１２１の記憶内容について説明する。実施例２では、呼の用件および緊急度を考慮してコールバック要求の送信を行うため、呼制御ＤＢ１２１には、実施例１における呼制御ＤＢ１２１の記憶内容とともに、呼の用件および緊急度に関する条件が記憶されている。

図２０は、呼の用件および緊急度を含む呼制御ＤＢ１２１の記憶内容を示す説明図である。図２０に示すように、呼制御ＤＢ１２１は、コンテキスト種別項目に対応付けて、値項目と、用件項目と、緊急度項目と、を有し、通信端末Ｔから呼制御条件を受信するごとにレコードを構成する。

コンテキスト種別項目には、コンテキストの種別が記憶されている。具体的には、コンテキストの種別には、通信端末Ｔがある場所を示す種別である「場所」がある。値項目には、コンテキストの種別の状態が記憶されている。具体的には、コンテキストの種別「場所」の状態として、値項目には「会議室」が記憶されている。

用件項目には、値項目が示す状態において、着信許可する呼の用件が記憶されている。例えば、用件項目には、「顧客Ｘ」や「＊」が記憶されている。「顧客Ｘ」は、顧客Ｘに関する用件の呼、または顧客Ｘからの呼であれば着信許可することを示す。「＊」は、ワイルドカードであり、用件にかかわらず着信許可することを示す。

緊急度項目には、値項目が示す状態において、着信許可する緊急度が記憶されている。例えば、緊急度項目には、「高」や「＊」が記憶されている。「高」は、緊急度の高い呼であれば着信許可することを示す。「＊」は、ワイルドカードであり、緊急度にかかわらず着信許可することを示す。

（実施例２にかかる通信制御装置１００による着信者へのコールバック要求の送信例１の内容）
次に、図２１および図２２を用いて、実施例２にかかる通信制御装置１００による着信者へのコールバック要求の送信例１の内容について説明する。送信例１は、通信制御装置１００が、着信側端末Ｒが着信許可の状態か否かに基づいて、コールバック要求を送信する例である。

図２１および図２２は、実施例２にかかる通信制御装置１００による着信者へのコールバック要求の送信例１の内容を示す説明図である。図２１では、図１と同様に、発信者が有する発信側端末Ｓと、着信者が有する着信側端末Ｒと、通信制御装置１００と、を含む通信システムを示す。通信制御装置１００は、コンテキスト管理サーバ１１０と、コールバック制御サーバ１２０と、呼制御サーバ１３０と、を含む装置である。そして、通信制御装置１００は、呼制御サーバ１３０により、発信側端末Ｓと着信側端末Ｒとの通信を制御する。

図２１において、（１）まず、発信側端末Ｓは、着信側端末Ｒへの呼を発信する。着信側端末Ｒへの呼は、まず、通信制御装置１００に受信される。（２）ここで、着信側端末Ｒは、着信側端末Ｒのコンテキストを、予め通信制御装置１００に通知している。そのため、通信制御装置１００では、着信側端末Ｒのコンテキストとして、着信側端末Ｒの場所が「役員会議室」であると記憶されている。

（３）そして、通信制御装置１００は、着信側端末Ｒのコンテキストと、呼制御ＤＢ１２１と、に基づいて、着信側端末Ｒが着信許可の状態であるか否かを判定する。そして、着信側端末Ｒが着信不許可の状態であれば、発信側端末Ｓからの呼を着信側端末Ｒに着信させない。

通信制御装置１００は、発信側端末Ｓからの呼を着信側端末Ｒに着信させなかった場合、コールバック要求の送信の可否の判定を開始し、着信側端末Ｒからのコンテキストの通知を待つ。

図２２において、（１）ここで、着信側端末Ｒが、役員会議室から休憩室へ移動した場合を想定する。（２）着信側端末Ｒは、休憩室に移動すると、着信側端末Ｒのコンテキストを、通信制御装置１００に通知する。ここでは、コンテキストは、着信側端末Ｒの場所である。

（３）次に、通信制御装置１００は、着信側端末Ｒのコンテキストの通知を受けると、予め保持しておいた監視コンテキストＤＢ１１３を参照して、着信側端末Ｒが着信許可の状態であるか否かを判定する。

（４）着信側端末Ｒが着信許可の状態である場合、通信制御装置１００は、コールバックＤＢ１２２を参照して、コールバック要求を着信側端末Ｒと発信側端末Ｓとに送信する。ここで、コールバック要求は、呼制御サーバ１３０からの着信要求である。着信側端末Ｒと発信側端末Ｓとがそれぞれ、呼制御サーバ１３０からの着信要求を許可することにより、着信側端末Ｒと発信側端末Ｓとの通話が開始される。

このように、通信制御装置１００は、着信側端末Ｒのコンテキストを取得し、自動的に着信側端末Ｒが着信許可の状態になったか否かを判定する。そして、通信制御装置１００は、着信側端末Ｒが着信許可の状態になったことが判定された場合にのみ、着信側端末Ｒにコールバック要求を送信する。そのため、着信側端末Ｒの利用者が、コールバックが必要であることを憶えておかなくてよくなり、着信側端末Ｒの利用者の手間を削減できる。また、着信側端末Ｒの利用者は、着信不許可の状態であるにもかかわらず、コールバック要求を受けるといった不都合を被ることはない。

（実施例２にかかる通信制御装置１００による着信者へのコールバック要求の送信例２の内容）
次に、図２３を用いて、実施例２にかかる通信制御装置１００による着信者へのコールバック要求の送信例２の内容について説明する。送信例２は、通信制御装置１００が、着信側端末Ｒが着信許可の状態か否かと、発信側端末Ｓが着信許可の状態か否かと、に基づいて、コールバック要求を送信する例である。

図２３は、実施例２にかかる通信制御装置１００による着信者へのコールバック要求の送信例２の内容を示す説明図である。図２３では、図１と同様に、発信者が有する発信側端末Ｓと、着信者が有する着信側端末Ｒと、通信制御装置１００と、を含む通信システムを示す。通信制御装置１００は、コンテキスト管理サーバ１１０と、コールバック制御サーバ１２０と、呼制御サーバ１３０と、を含む装置である。そして、通信制御装置１００は、呼制御サーバ１３０により、発信側端末Ｓと着信側端末Ｒとの通信を制御する。

図２３において、通信制御装置１００は、図２１と同様に発信側端末Ｓからの呼を着信側端末Ｒに着信させなかった場合、コールバック要求の送信の可否の判定を開始し、着信側端末Ｒおよび発信側端末Ｓのコンテキストを監視する。

（１）ここで、着信側端末Ｒが、役員会議室から休憩室へ移動した場合を想定する。（２）着信側端末Ｒは、休憩室に移動すると、着信側端末Ｒのコンテキストを、通信制御装置１００に通知する。ここでは、コンテキストは、着信側端末Ｒの場所である。

（３）次に、通信制御装置１００は、着信側端末Ｒのコンテキストの通知を受けると、予め保持しておいた監視コンテキストＤＢ１１３を参照して、着信側端末Ｒが着信許可の状態であるか否かを判定する。また、通信制御装置１００は、コンテキストＤＢ１１２の発信側端末Ｓのコンテキストから、発信側端末Ｓが着信拒否の状態であるか否かを判定する。

（４）着信側端末Ｒと発信側端末Ｓとの双方が着信許可の状態である場合、通信制御装置１００は、コールバックＤＢ１２２を参照して、コールバック要求を着信側端末Ｒと発信側端末Ｓとに送信する。ここで、コールバック要求は、呼制御サーバ１３０からの着信要求である。着信側端末Ｒと発信側端末Ｓとがそれぞれ、呼制御サーバ１３０からの着信要求を許可することにより、着信側端末Ｒと発信側端末Ｓとの通話が開始される。

このように、通信制御装置１００は、着信側端末Ｒのコンテキストを取得し、自動的に着信側端末Ｒが着信許可の状態になったか否かを判定する。そして、通信制御装置１００は、着信側端末Ｒが着信許可の状態になったことが判定された場合にのみ、着信側端末Ｒにコールバック要求を送信する。そのため、着信側端末Ｒの利用者が、コールバックが必要であることを憶えておかなくてよくなり、着信側端末Ｒの利用者の手間を削減できる。また、着信側端末Ｒの利用者は、着信不許可の状態であるにもかかわらず、コールバック要求を受けるといった不都合を被ることはない。

（実施例２にかかる通信制御装置１００内における各サーバの具体的な通信内容）
ここで、図２４および図２５を用いて、図２１および図２２に示した実施例２にかかる通信制御装置１００内における各サーバの具体的な通信内容について説明する。

（実施例２における発信側端末Ｓから呼が発信されるときの各サーバの通信内容の詳細）
まず、図２４および図２５を用いて、実施例２における発信側端末Ｓから呼が発信されるときの各サーバの通信内容の詳細について説明する。

図２４および図２５は、実施例２における発信側端末Ｓから呼が発信されるときの各サーバの通信内容の詳細を示すシーケンス図である。図２４において、まず、着信側端末Ｒは、呼制御条件をコールバック制御サーバ１２０に送信する（ステップＳ２４０１）。コールバック制御サーバ１２０は、受信した呼制御条件に基づいて、呼制御ＤＢ１２１を更新する。

次に、着信側端末Ｒは、自端末の状態を示すコンテキストをコンテキスト管理サーバ１１０に通知する（ステップＳ２４０２）。なお、コンテキスト管理サーバ１１０は、受信したコンテキストに基づいて、コンテキストＤＢ１１２を更新する。例えば、コンテキスト管理サーバ１１０は、コンテキストに含まれるＳＳＩＤから、場所ＤＢ１１１に基づいて、通信端末Ｔの場所を特定して、コンテキストＤＢ１１２を更新する。

ここで、発信者が着信者に承認依頼しようとする。この承認依頼は、例えば、図示しない電子伝票システム（他のシステム２０２）上で、発信者が電子伝票を起票し、その承認を着信者に依頼することで行われる。この電子伝票の承認が着信者に依頼されると、図示しない電子伝票システムからコンテキスト管理サーバ１１０に、発信者が着信者に電子伝票の承認依頼を行ったことが通知される。コンテキスト管理サーバ１１０が、着信側端末ＲのコンテキストＤＢ１１２のコンテキスト種別が伝票承認である値として、当該伝票の承認依頼者である発信者のＩＤ（ユーザＡ）を登録する。

そして、発信側端末Ｓにおいて、発信者は着信側端末Ｒへの承認依頼の用件と緊急度とを設定する（ステップＳ２４０３）。そして、着信側端末Ｒへの承認依頼の用件と緊急度とを含む呼が、呼制御サーバ１３０に発信される（ステップＳ２４０４）。

ここでは、発信側端末Ｓから呼制御サーバ１３０に、直接、用件と緊急度とが通知されている。しかし、発信側端末Ｓから上述した電子伝票システム（他のシステム２０２）に呼の用件と緊急度とが登録され、通信制御装置１００が当該システムを参照することにより、呼の用件と緊急度とを取得するようにしてもよい。

次に、呼制御サーバ１３０は、コンテキスト管理サーバ１１０にコンテキストを通知する（ステップＳ２４０５）。コンテキスト管理サーバ１１０は、受信したコンテキストに基づいて、コンテキストＤＢ１１２を更新する。そして、呼制御サーバ１３０は、コールバック制御サーバ１２０に着信制御要求を通知する（ステップＳ２４０６）。

着信制御要求を通知されたコールバック制御サーバ１２０は、コンテキスト管理サーバ１１０のコンテキストＤＢ１１２を参照し（ステップＳ２４０７）、呼制御ＤＢ１２１を参照し（ステップＳ２４０８）、着信側端末Ｒが着信許可の状態か否かを判定する（ステップＳ２４０９）。ここでは、コールバック制御サーバ１２０が、着信側端末Ｒが着信不許可の状態であると判定した場合を想定する。

図２５において、コールバック制御サーバ１２０は、呼制御サーバ１３０に着信制御応答を通知する（ステップＳ２５０１）。着信制御応答には、着信側端末Ｒが着信不許可の状態であることを示す情報が含まれている。

着信制御応答を受信した呼制御サーバ１３０は、発信側端末Ｓに、切断要求とコールバック登録通知とを通知する（ステップＳ２５０２）。また、呼制御サーバ１３０は、コンテキスト管理サーバ１１０にコンテキストを通知する（ステップＳ２５０３）。コンテキスト管理サーバ１１０は、受信したコンテキストに基づいて、コンテキストＤＢ１１２を更新する。

そして、コールバック制御サーバ１２０は、着信側端末Ｒが着信不許可の状態であると判定した場合、コールバック要求の送信の可否の判定を開始する（ステップＳ２５０４）。次に、コールバック制御サーバ１２０は、通信端末Ｔに関する呼制御ＤＢ１２１を参照する（ステップＳ２５０５）。

そして、コールバック制御サーバ１２０は、コンテキスト管理サーバ１１０に、コールバック契機通知要求を通知する（ステップＳ２５０６）。コールバック契機通知要求は、コンテキスト管理サーバ１１０に着信側端末Ｒのコンテキストを監視させ、着信許可の状態になった際に、コールバック制御サーバ１２０へ通知させる要求である。

次に、コールバック制御サーバ１２０は、コールバック情報をコールバックＤＢ１２２に登録する（ステップＳ２５０７）。コールバック情報は、例えば、コールバックの際に使用する発信側端末Ｓの電話番号およびＩＰアドレスである。これにより、コンテキスト管理サーバ１１０に、着信側端末Ｒのコンテキストの監視を開始させて、コールバック要求の送信のトリガを発生させることができる。

（実施例２におけるコールバック制御サーバ１２０によりコールバック要求が送信されるときの各サーバの通信内容の詳細）
次に、図２６を用いて、実施例２におけるコールバック制御サーバ１２０によりコールバック要求が送信されるときの各サーバの通信内容の詳細について説明する。ここで、図２５においてコンテキスト管理サーバ１１０にコンテキストを監視されている着信側端末Ｒが移動を行い、着信側端末Ｒのコンテキストが着信許可の状態に変化した場合を想定する。

図２６は、実施例２におけるコールバック制御サーバ１２０によりコールバック要求が送信されるときの各サーバの通信内容の詳細を示すシーケンス図である。まず、着信側端末Ｒは、移動によりコンテキストが変化すると、自端末の状態を示すコンテキストをコンテキスト管理サーバ１１０に通知する（ステップＳ２６０１）。

コンテキストの通知を受けたコンテキスト管理サーバ１１０は、監視コンテキストＤＢ１１３を参照して、着信側端末Ｒが着信許可の状態になったか否かを判定する。そして、コンテキスト管理サーバ１１０は、着信側端末Ｒが着信許可の状態であれば、コールバック契機通知をコールバック制御サーバ１２０に通知する（ステップＳ２６０２）。

コールバック契機通知を受けたコールバック制御サーバ１２０は、コールバックＤＢ１２２を参照し（ステップＳ２６０３）、コールバック制御要求を呼制御サーバ１３０に送信する（ステップＳ２６０４）。コールバック制御要求は、呼制御サーバ１３０に、発信側端末Ｓと着信側端末Ｒとに対して、いわゆる第三者呼制御を実行させる要求である。

次に、呼制御サーバ１３０は、発信側端末Ｓと着信側端末Ｒとに着信要求を送信する（ステップＳ２６０５）。そして、発信側端末Ｓと着信側端末Ｒに通話させる。次に、呼制御サーバ１３０は、コンテキスト管理サーバ１１０にコンテキストを通知する（ステップＳ２６０６）。コンテキスト管理サーバ１１０は、受信したコンテキストに基づいて、コンテキストＤＢ１１２を更新する。

これにより、着信者が自らコールバックが必要であることを憶えておく必要なく、通信制御装置１００により自動的に着信側端末Ｒが着信許可の状態か否かが判定される。そして、通信制御装置１００は、着信側端末Ｒが着信許可の状態のときのみコールバック要求を送信する。

そのため、着信者が、コールバックが必要であることを憶えておく手間を削減できる。また、着信側端末Ｒが着信不許可の状態であるにもかかわらず、コールバック要求が受信されるといった不都合はなく、着信側端末Ｒの利便性を向上できる。

（実施例２におけるコールバック要求の取消を行うときの各サーバの通信内容の詳細）
次に、図２７を用いて、実施例２におけるコールバック要求の取消を行うときの各サーバの通信内容の詳細について説明する。

図２７は、実施例２におけるコールバック要求の取消を行うときの各サーバの通信内容の詳細を示すシーケンス図である。まず、発信側端末Ｓにおいて、発信した呼の用件が解決された場合、コールバック要求の取消が入力される（ステップＳ２７０１）。そして、発信側端末Ｓは、コールバック要求の取消があったことを示すコンテキストを、コンテキスト管理サーバ１１０に送信する（ステップＳ２７０２）。

これは例えば、発信側端末Ｓによって、図示しない電子伝票システム（他のシステム２０２）で先になされた着信者に対する伝票承認依頼が取り消されることによって行われてもよい。この場合、電子伝票システムで承認依頼が取り消されると、その旨が電子伝票システムからコンテキスト管理サーバ１１０に通知される。そして、コンテキスト管理サーバ１１０により、コンテキストＤＢ１１２の着信側端末Ｒのコンテキスト種別が伝票承認である値項目に登録済みの発信者の情報（ユーザＡ）が削除される。

コンテキスト管理サーバ１１０は、コンテキストＤＢ１１２を更新し、コールバックの中止を要求するコールバック契機通知をコールバック制御サーバ１２０に送信する（ステップＳ２７０３）。そして、コールバック制御サーバ１２０は、コールバックＤＢ１２２のレコードを消去する（ステップＳ２７０４）。これにより、不要なコールバック要求が送信されることがなくなる。

（実施例２におけるコールバック制御サーバ１２０の着信制御処理の処理内容の詳細）
次に、図２８を用いて、実施例２におけるコールバック制御サーバ１２０の着信制御処理の処理内容の詳細について説明する。図２８では、図２４および図２５において、コールバック制御サーバ１２０が行った着信制御処理の処理内容について説明する。

図２８は、実施例２におけるコールバック制御サーバ１２０の着信制御処理の処理内容の詳細を示すフローチャートである。まず、コールバック制御サーバ１２０は、着信制御要求を受信したか否かを判定する（ステップＳ２８０１）。ここで、着信制御要求を受信していない場合（ステップＳ２８０１：Ｎｏ）、コールバック制御サーバ１２０は、ステップＳ２８０１に戻り、着信制御要求の受信を待つ。

一方、着信制御要求を受信した場合（ステップＳ２８０１：Ｙｅｓ）、コールバック制御サーバ１２０は、着信側端末Ｒのコンテキストを取得する（ステップＳ２８０２）。次に、コールバック制御サーバ１２０は、取得したコンテキストに対応する呼制御ＤＢ１２１のレコードを参照する（ステップＳ２８０３）。

そして、コールバック制御サーバ１２０は、参照した呼制御ＤＢ１２１のレコードに基づいて、着信側端末Ｒが着信許可の状態であるか否かを判定する（ステップＳ２８０４）。ここで、着信側端末Ｒが着信許可の状態である場合（ステップＳ２８０４：Ｙｅｓ）、コールバック制御サーバ１２０は、着信側端末Ｒが着信許可の状態であることを示す着信制御応答を、呼制御サーバ１３０に送信する（ステップＳ２８０５）。そして、コールバック制御サーバ１２０は、着信制御処理を終了する。

一方、着信側端末Ｒが着信許可の状態でない場合（ステップＳ２８０４：Ｎｏ）、コールバック制御サーバ１２０は、着信側端末Ｒが着信不許可の状態であることを示す着信制御応答を、呼制御サーバ１３０に送信する（ステップＳ２８０６）。次に、コールバック制御サーバ１２０は、コールバック制御処理を開始するイベントを発生する（ステップＳ２８０７）。そして、コールバック制御サーバ１２０は、着信制御処理を終了する。

以上のステップＳ２８０１〜ステップＳ２８０７の処理が、ステップＳ２４０６〜ステップＳ２４０９およびステップＳ２５０１〜ステップＳ２５０２の処理に対応する処理である。これにより、通信制御装置１００が、着信側端末Ｒに呼を着信させるか否かを判定できるため、着信者が自ら着信許可の状態か否かを判定し、着信側端末Ｒを操作して着信を拒否する手間を削減することができる。

（実施例２におけるコールバック制御サーバ１２０のコールバック制御処理の処理内容の詳細）
次に、図２９を用いて、実施例２におけるコールバック制御サーバ１２０のコールバック制御処理の処理内容の詳細について説明する。図２９では、図２５〜図２７において、コールバック制御サーバ１２０が行ったコールバック制御処理の処理内容について説明する。

図２９は、実施例２におけるコールバック制御サーバ１２０のコールバック制御処理の処理内容の詳細を示すフローチャートである。まず、コールバック制御サーバ１２０は、コールバック制御処理を開始するイベントが発生すると、コールバック制御処理を開始する（ステップＳ２９０１）。次に、コールバック制御サーバ１２０は、呼制御ＤＢ１２１を参照して、着信側端末Ｒの呼制御条件を取得する（ステップＳ２９０２）。

次に、コールバック制御サーバ１２０は、取得した呼制御条件に基づいて、着信側端末Ｒの着信許可の状態に対応する監視コンテキストを生成する（ステップＳ２９０３）。そして、コールバック制御サーバ１２０は、コールバック中止条件を生成する（ステップＳ２９０４）。

次に、コールバック制御サーバ１２０は、生成した監視コンテキストとコールバック中止条件とを含むコールバック契機通知を、コンテキスト管理サーバ１１０に送信する（ステップＳ２９０５）。そして、コールバック制御サーバ１２０は、コールバックＤＢ１２２にコールバック情報を登録する（ステップＳ２９０６）。コールバック契機通知の受信を待つ。以上のステップＳ２９０１〜ステップＳ２９０６の処理が、ステップＳ２５０４〜ステップＳ２５０７の処理に対応する処理である。

次に、コールバック制御サーバ１２０は、コンテキスト管理サーバ１１０からコールバック契機通知を受信したか否かを判定する（ステップＳ２９０７）。ここで、コールバック契機通知を受信していない場合（ステップＳ２９０７：Ｎｏ）、コールバック制御サーバ１２０は、ステップＳ２９０７に戻り、コールバック契機通知の受信を待つ。

一方、コールバック契機通知を受信した場合（ステップＳ２９０７：Ｙｅｓ）、コールバック制御サーバ１２０は、コールバック契機通知の内容を判定する（ステップＳ２９０８）。ここで、コールバック契機通知の内容がコールバックの実行であれば（ステップＳ２９０８：コールバック実行）、コールバック制御サーバ１２０は、コールバックＤＢ１２２から情報を取得する（ステップＳ２９０９）。そして、コールバック制御サーバ１２０は、コールバック要求を送信して（ステップＳ２９１０）、コールバック制御処理を終了する。以上のステップＳ２９０７〜ステップＳ２９１０の処理が、ステップＳ２６０１〜ステップＳ２６０４の処理に対応する処理である。

一方、コールバック契機通知の内容がコールバックの中止であれば（ステップＳ２９０８：コールバック中止）、コールバック制御サーバ１２０は、コールバックＤＢ１２２から情報を消去する（ステップＳ２９１１）。そして、コールバック制御サーバ１２０は、コールバック制御処理を終了する。以上のステップＳ２９０７〜ステップＳ２９１１の処理が、ステップＳ２７０１〜ステップＳ２７０４の処理に対応する処理である。

これにより、通信制御装置１００は、着信側端末Ｒが着信許可の状態になった場合にのみ、コールバック要求を送信することができる。着信者が、コールバックが必要であることを憶えておく手間を削減できる。また、着信側端末Ｒが着信不許可の状態であるにもかかわらず、コールバック要求が受信されるといった不都合はなく、着信側端末Ｒの利便性を向上できる。また、不要になったコールバック要求を取り消すことにより、着信側端末Ｒの利便性を向上できる。

（実施例２におけるコンテキスト管理サーバ１１０の監視コンテキスト登録処理の処理内容の詳細）
次に、図３０を用いて、実施例２におけるコンテキスト管理サーバ１１０の監視コンテキスト登録処理の処理内容の詳細について説明する。

図３０は、実施例２におけるコンテキスト管理サーバ１１０の監視コンテキスト登録処理の処理内容の詳細を示すフローチャートである。まず、コンテキスト管理サーバ１１０は、コールバック制御サーバ１２０から、コールバック契機通知要求を受信したか否かを判定する（ステップＳ３００１）。ここで、コールバック契機通知要求を受信していない場合（ステップＳ３００１：Ｎｏ）、コンテキスト管理サーバ１１０は、ステップＳ３００１に戻り、コールバック契機通知要求の受信を待つ。

一方、コールバック契機通知要求を受信した場合（ステップＳ３００１：Ｙｅｓ）、コンテキスト管理サーバ１１０は、コールバック契機通知要求から監視コンテキストを抽出して、監視コンテキストＤＢ１１３に登録する（ステップＳ３００２）。そして、コンテキスト管理サーバ１１０は、監視コンテキスト登録処理を終了する。これにより、コンテキスト管理サーバ１１０は、通信端末Ｔの着信許可の状態に対応する監視コンテキストを監視コンテキストＤＢ１１３に登録し、通信端末Ｔが着信許可の状態になったか否かを監視できるようになる。

（実施例２におけるコンテキスト管理サーバ１１０のコールバック契機通知送信処理の処理内容の詳細）
次に、図３１を用いて、実施例２におけるコンテキスト管理サーバ１１０のコールバック契機通知送信処理の処理内容の詳細について説明する。

図３１は、実施例２におけるコンテキスト管理サーバ１１０のコールバック契機通知送信処理の処理内容の詳細を示すフローチャートである。まず、コンテキスト管理サーバ１１０は、コンテキストＤＢ１１２が更新されたか否かを判定する（ステップＳ３１０１）。例えば、コンテキストＤＢ１１２の更新は、通信端末Ｔからのコンテキストを受け付けた際に行われる。ここで、コンテキストＤＢが更新されていない場合（ステップＳ３１０１：Ｎｏ）、コンテキスト管理サーバ１１０は、ステップＳ３１０１に戻り、コンテキストＤＢの更新を待つ。

一方、コンテキストＤＢが更新された場合（ステップＳ３１０１：Ｙｅｓ）、コンテキスト管理サーバ１１０は、更新されたコンテキストＤＢ１１２のレコードに、コールバックＩＤの登録があるか否かを判定する（ステップＳ３１０２）。ここで、コールバックＩＤの登録がない場合（ステップＳ３１０２：Ｎｏ）、コンテキスト管理サーバ１１０は、コールバック契機通知送信処理を終了する。

一方、コールバックＩＤの登録がある場合（ステップＳ３１０２：Ｙｅｓ）、コンテキスト管理サーバ１１０は、登録されているコールバックＩＤに対応する監視コンテキストＤＢ１１３の種別が実行の全レコードの条件が満たされたか否かを判定する（ステップＳ３１０３）。ここで、全レコードの条件が満たされている場合（ステップＳ３１０３：Ｙｅｓ）、コンテキスト管理サーバ１１０は、コールバック制御サーバ１２０に、コールバック実行を示すコールバック契機通知を送信し（ステップＳ３１０４）、コールバック契機通知送信処理を終了する。

一方、満たされていない条件がある場合（ステップＳ３１０３：Ｎｏ）、コンテキスト管理サーバ１１０は、監視コンテキストの種別が中止の全条件が満たされたか否かを判定する（ステップＳ３１０５）。

ここで、全条件が満たされている場合（ステップＳ３１０５：Ｙｅｓ）、コンテキスト管理サーバ１１０は、コールバック制御サーバ１２０に、コールバック中止を示すコールバック契機通知を送信し（ステップＳ３１０６）、コールバック契機通知送信処理を終了する。

一方、満たされていない条件がある場合（ステップＳ３１０５：Ｎｏ）、コンテキスト管理サーバ１１０は、コールバック契機通知送信処理を終了する。これにより、コンテキスト管理サーバ１１０は、監視対象となる通信端末Ｔのコンテキストを監視し、通信端末Ｔが着信許可の状態になった場合に、コールバック制御サーバ１２０にコールバック契機通知を送信することができる。

以上説明したように、通信制御方法、通信制御装置１００、および通信制御システムによれば、着信側端末Ｒが呼を受け付けなかった場合に、着信側端末Ｒのコンテキストを監視し、着信側端末Ｒが着信許可の状態になったことを判断する。そして、通信制御装置１００は、着信側端末Ｒが着信許可の状態になった場合にのみコールバック要求を送信する。これにより、着信側端末Ｒの利用者が、コールバックが必要であることを憶えておかなくてよくなり、着信側端末Ｒの利用者の手間を削減できる。また、着信側端末Ｒが着信許可の状態のときのみコールバックが行われるようになり、着信側端末Ｒの利便性を向上させることができる。

また、通信制御装置１００は、着信側端末Ｒからの着信拒否イベントがあったことの通知を受けることにより、着信側端末Ｒが着信許可の状態になったことの判断を開始して、コールバック要求の送信を行うことができる。

また、通信制御装置１００が呼制御サーバ１３０を備え、発信側端末Ｓと着信側端末Ｒとの通信を制御している場合は、呼制御サーバ１３０が発生させた着信拒否イベントを検出することにより、着信側端末Ｒが着信許可の状態になったことの判断を開始して、コールバック要求の送信を行うことができる。

また、通信制御装置１００は、着信側端末Ｒが着信許可の状態になった場合、かつ、発信側端末Ｓが着信許可の状態になった場合、にのみコールバック要求を送信するようにして、通信端末Ｔの利便性を向上させることができる。また、通信制御装置１００は、通信相手ごとに異なる着信許可の状態を設定することにより、例えば、顧客に関する要件で緊急度の高い呼や顧客の有する発信側端末Ｓに対しては着信許可の状態と判断し、同僚の有する発信側端末Ｓに対しては着信不許可の状態と判断することができる。そのため、より通信端末Ｔの利便性を向上させることができる。

また、通信制御装置１００は、コールバック要求の取消し要求を受信して、コールバック要求の送信を行わないようにするため、不要なコールバック要求を行わない。そのため、発信側端末Ｓの利用者と、着信側端末Ｒの利用者と、は不要なコールバック要求に対応するといった無駄な手間を掛けることがなくなる。

なお、本実施の形態で説明した通信制御方法は、予め用意されたプログラムをパーソナル・コンピュータやワークステーション等のコンピュータで実行することにより実現することができる。本通信制御プログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。また本通信制御プログラムは、インターネット等のネットワークを介して配布してもよい。

上述した実施の形態に関し、さらに以下の付記を開示する。

（付記１）コンピュータが、
第１の端末からの発信を第２の端末が受け付けなかったことを検出する検出工程と、
前記検出工程によって前記第１の端末からの発信を前記第２の端末が受け付けなかったことが検出された場合、着信許可または不許可を示すコンテキストを端末ごとに記憶する記憶手段を参照することにより、前記第２の端末が着信許可の状態であるかを判断する判断工程と、
前記判断工程によって着信許可の状態であると判断された場合、前記第１の端末へのコールバック要求を前記第２の端末に送信する送信工程と、
を実行することを特徴とする通信制御方法。

（付記２）前記検出工程は、
前記第１の端末からの発信について前記第２の端末で着信拒否の操作が行われたことを検出することを特徴とする付記１に記載の通信制御方法。

（付記３）前記検出工程は、
前記第１の端末から前記第２の端末へ発信されたことが検出されたときに、前記記憶手段を参照することにより、前記第２の端末が着信不許可の状態であると判断された場合、前記第１の端末からの発信を前記第２の端末が受け付けなかったことを検出することを特徴とする付記１に記載の通信制御方法。

（付記４）前記判断工程は、
前記検出工程によって前記第１の端末からの発信を前記第２の端末が受け付けなかったことが検出された場合、前記記憶手段を参照することにより、前記第１の端末からの発信について前記第２の端末が着信許可の状態であるかを判断することを特徴とする付記１〜３のいずれか一つに記載の通信制御方法。

（付記５）前記判断工程は、
前記検出工程によって前記第１の端末からの発信を前記第２の端末が受け付けなかったことが検出された場合、前記記憶手段を参照することにより、前記第１および第２の端末が着信許可の状態であるかを判断することを特徴とする付記１〜３のいずれか一つに記載の通信制御方法。

（付記６）前記判断工程は、
前記検出工程によって前記第１の端末からの発信を前記第２の端末が受け付けなかったことが検出された場合、前記記憶手段を参照することにより、前記第１の端末からの発信について前記第２の端末が着信許可の状態であるかを判断し、かつ、前記第１の端末が着信許可の状態であるかを判断することを特徴とする付記１〜３のいずれか一つに記載の通信制御方法。

（付記７）前記判断工程は、
前記検出工程によって前記第１の端末からの発信を前記第２の端末が受け付けなかったことが検出された場合、前記記憶手段を参照することにより、前記第１の端末からの発信について前記第２の端末が着信許可の状態であるかを判断し、かつ、前記第２の端末からの発信について前記第１の端末が着信許可の状態であるかを判断することを特徴とする付記１〜３のいずれか一つに記載の通信制御方法。

（付記８）前記検出工程は、
前記第１の端末から前記コールバック要求の取消し要求を検出し、
前記送信工程は、
前記検出工程によって前記取消し要求が検出された場合、前記コールバック要求を前記第２の端末に送信しないことを特徴とする付記１〜７のいずれか一つに記載の通信制御方法。

（付記９）前記送信工程は、
前記第１の端末を識別する識別子を含む前記第１の端末へのコールバック要求を前記第２の端末に送信することを特徴とする付記１〜８のいずれか一つに記載の通信制御方法。

（付記１０）前記送信工程は、
前記第１の端末への発信を実行するソフトウェアを含む前記第１の端末へのコールバック要求を前記第２の端末に送信することを特徴とする付記１〜８のいずれか一つに記載の通信制御方法。

（付記１１）前記送信工程は、
前記第１の端末へのコールバック要求を前記第１の端末および前記第２の端末に送信することを特徴とする付記１〜８のいずれか一つに記載の通信制御方法。

（付記１２）着信許可または不許可を示すコンテキストを端末ごとに記憶する記憶手段と、
第１の端末からの発信を第２の端末が受け付けなかったことを検出する検出手段と、
前記検出手段によって前記第１の端末からの発信を前記第２の端末が受け付けなかったことが検出された場合、前記記憶手段を参照することにより、前記第２の端末が着信許可の状態であるかを判断する判断手段と、
前記判断手段によって着信許可の状態であると判断された場合、前記第１の端末へのコールバック要求を前記第２の端末に送信する送信手段と、
を備えることを特徴とする通信制御装置。

（付記１３）端末間の発着信を制御する第１の装置と、発信元端末へのコールバックを制御する第２の装置と、が接続された通信制御システムであって、
前記第２の装置は、
着信許可または不許可を示すコンテキストを端末ごとに記憶する記憶手段と、
第１の端末からの発信を第２の端末が受け付けなかったことを検出する検出手段と、
前記検出手段によって前記第１の端末からの発信を前記第２の端末が受け付けなかったことが検出された場合、前記記憶手段を参照することにより、前記第２の端末が着信許可の状態であるかを判断する判断手段と、
前記判断手段によって着信許可の状態であると判断された場合、前記第１の端末へのコールバック要求を前記第２の端末に送信する送信手段と、を備え、
前記第１の装置は、
前記第１の端末から前記第２の端末へ発信されたことを前記第２の装置に通知することを特徴とする通信制御システム。

（付記１４）端末間の発着信を制御する第１の装置と、発信元端末へのコールバックを制御する第２の装置と、が接続された通信制御システムであって、
前記第２の装置は、
着信許可または不許可を示すコンテキストを端末ごとに記憶する記憶手段と、
第１の端末からの発信を第２の端末が受け付けなかったことを検出する検出手段と、
前記検出手段によって前記第１の端末からの発信を前記第２の端末が受け付けなかったことが検出された場合、前記記憶手段を参照することにより、前記第２の端末が着信許可の状態であるかを判断する判断手段と、
前記判断手段によって着信許可の状態であると判断された場合、前記第１の端末へのコールバック要求を前記第１の装置に送信する送信手段と、を備え、
前記第１の装置は、
前記第１の端末から前記第２の端末へ発信されたことを前記第２の装置に通知し、前記送信手段からの前記コールバック要求を前記第２の装置に通知することを特徴とする通信制御システム。

１００ 通信制御装置
１１０ コンテキスト管理サーバ
１２０ コールバック制御サーバ
１３０ 呼制御サーバ
Ｓ 発信側端末
Ｒ 着信側端末
８０１ 記憶部
８０２ 検出部
８０３ 判断部
８０４ 送信部

Claims (11)

1. コンピュータが、
   第１の端末からの発信を第２の端末が受け付けなかったことを検出する検出工程と、
   前記検出工程によって前記第１の端末からの発信を前記第２の端末が受け付けなかったことが検出された場合、端末が通知した前記端末の場所を示すコンテキストを前記端末ごとに記憶する記憶手段を参照することにより、前記第２の端末が通知したコンテキストが示す場所に基づいて、前記第２の端末が着信許可の状態であるかを判断する判断工程と、
   前記判断工程によって着信許可の状態であると判断された場合、前記第１の端末へのコールバック要求を前記第２の端末に送信する送信工程と、
   を実行することを特徴とする通信制御方法。
2. 前記検出工程は、
   前記第１の端末からの発信について前記第２の端末で着信拒否の操作が行われたことを検出することを特徴とする請求項１に記載の通信制御方法。
3. 前記検出工程は、
   前記第１の端末から前記第２の端末へ発信されたことが検出されたときに、前記記憶手段を参照することにより、前記第２の端末が着信不許可の状態であると判断された場合、前記第１の端末からの発信を前記第２の端末が受け付けなかったことを検出することを特徴とする請求項１に記載の通信制御方法。
4. 前記判断工程は、
   前記検出工程によって前記第１の端末からの発信を前記第２の端末が受け付けなかったことが検出された場合、前記記憶手段を参照することにより、前記第１の端末からの発信について前記第２の端末が着信許可の状態であるかを判断することを特徴とする請求項１〜３のいずれか一つに記載の通信制御方法。
5. 前記判断工程は、
   前記検出工程によって前記第１の端末からの発信を前記第２の端末が受け付けなかったことが検出された場合、前記記憶手段を参照することにより、前記第１および第２の端末が着信許可の状態であるかを判断することを特徴とする請求項１〜３のいずれか一つに記載の通信制御方法。
6. 前記判断工程は、
   前記検出工程によって前記第１の端末からの発信を前記第２の端末が受け付けなかったことが検出された場合、前記記憶手段を参照することにより、前記第１の端末からの発信について前記第２の端末が着信許可の状態であるかを判断し、かつ、前記第１の端末が着信許可の状態であるかを判断することを特徴とする請求項１〜３のいずれか一つに記載の通信制御方法。
7. 前記判断工程は、
   前記検出工程によって前記第１の端末からの発信を前記第２の端末が受け付けなかったことが検出された場合、前記記憶手段を参照することにより、前記第１の端末からの発信について前記第２の端末が着信許可の状態であるかを判断し、かつ、前記第２の端末からの発信について前記第１の端末が着信許可の状態であるかを判断することを特徴とする請求項１〜３のいずれか一つに記載の通信制御方法。
8. 前記検出工程は、
   前記第１の端末から前記コールバック要求の取消し要求を検出し、
   前記送信工程は、
   前記検出工程によって前記取消し要求が検出された場合、前記コールバック要求を前記第２の端末に送信しないことを特徴とする請求項１〜７のいずれか一つに記載の通信制御方法。
9. 端末が通知した前記端末の場所を示すコンテキストを前記端末ごとに記憶する記憶手段と、
   第１の端末からの発信を第２の端末が受け付けなかったことを検出する検出手段と、
   前記検出手段によって前記第１の端末からの発信を前記第２の端末が受け付けなかったことが検出された場合、前記記憶手段を参照することにより、前記第２の端末が通知したコンテキストが示す場所に基づいて、前記第２の端末が着信許可の状態であるかを判断する判断手段と、
   前記判断手段によって着信許可の状態であると判断された場合、前記第１の端末へのコールバック要求を前記第２の端末に送信する送信手段と、
   を備えることを特徴とする通信制御装置。
10. 端末間の発着信を制御する第１の装置と、発信元端末へのコールバックを制御する第２の装置と、が接続された通信制御システムであって、
    前記第２の装置は、
    端末が通知した前記端末の場所を示すコンテキストを前記端末ごとに記憶する記憶手段と、
    第１の端末からの発信を第２の端末が受け付けなかったことを検出する検出手段と、
    前記検出手段によって前記第１の端末からの発信を前記第２の端末が受け付けなかったことが検出された場合、前記記憶手段を参照することにより、前記第２の端末が通知したコンテキストが示す場所に基づいて、前記第２の端末が着信許可の状態であるかを判断する判断手段と、
    前記判断手段によって着信許可の状態であると判断された場合、前記第１の端末へのコールバック要求を前記第２の端末に送信する送信手段と、を備え、
    前記第１の装置は、
    前記第１の端末から前記第２の端末へ発信されたことを前記第２の装置に通知することを特徴とする通信制御システム。
11. 端末間の発着信を制御する第１の装置と、発信元端末へのコールバックを制御する第２の装置と、が接続された通信制御システムであって、
    前記第２の装置は、
    端末が通知した前記端末の場所を示すコンテキストを前記端末ごとに記憶する記憶手段と、
    第１の端末からの発信を第２の端末が受け付けなかったことを検出する検出手段と、
    前記検出手段によって前記第１の端末からの発信を前記第２の端末が受け付けなかったことが検出された場合、前記記憶手段を参照することにより、前記第２の端末が通知したコンテキストが示す場所に基づいて、前記第２の端末が着信許可の状態であるかを判断する判断手段と、
    前記判断手段によって着信許可の状態であると判断された場合、前記第１の端末へのコールバック要求を前記第１の装置に送信する送信手段と、を備え、
    前記第１の装置は、
    前記第１の端末から前記第２の端末へ発信されたことを前記第２の装置に通知し、前記送信手段からの前記コールバック要求を前記第２の端末に通知することを特徴とする通信制御システム。

Images