コンピュータが、第1の端末からの発信を第2の端末が受け付けなかったことを検出する検出工程と、前記検出工程によって前記第1の端末からの発信を前記第2の端末が受け付けなかったことが検出された場合、着信許可または不許可を示すコンテキストを端末ごとに記憶する記憶手段を参照することにより、前記第2の端末が着信許可の状態であるかを判断する判断工程と、前記判断工程によって着信許可の状態であると判断された場合、前記第1の端末へのコールバック要求を前記第2の端末に送信する送信工程と、を実行することを特徴とする通信制御方法。前記検出工程は、前記第1の端末からの発信について前記第2の端末で着信拒否の操作が行われたことを検出することを特徴とする請求項1に記載の通信制御方法。前記検出工程は、前記第1の端末から前記第2の端末へ発信されたことが検出されたときに、前記記憶手段を参照することにより、前記第2の端末が着信不許可の状態であると判断された場合、前記第1の端末からの発信を前記第2の端末が受け付けなかったことを検出することを特徴とする請求項1に記載の通信制御方法。前記判断工程は、前記検出工程によって前記第1の端末からの発信を前記第2の端末が受け付けなかったことが検出された場合、前記記憶手段を参照することにより、前記第1の端末からの発信について前記第2の端末が着信許可の状態であるかを判断することを特徴とする請求項1~3のいずれか一つに記載の通信制御方法。前記判断工程は、前記検出工程によって前記第1の端末からの発信を前記第2の端末が受け付けなかったことが検出された場合、前記記憶手段を参照することにより、前記第1および第2の端末が着信許可の状態であるかを判断することを特徴とする請求項1~3のいずれか一つに記載の通信制御方法。前記判断工程は、前記検出工程によって前記第1の端末からの発信を前記第2の端末が受け付けなかったことが検出された場合、前記記憶手段を参照することにより、前記第1の端末からの発信について前記第2の端末が着信許可の状態であるかを判断し、かつ、前記第1の端末が着信許可の状態であるかを判断することを特徴とする請求項1~3のいずれか一つに記載の通信制御方法。前記判断工程は、前記検出工程によって前記第1の端末からの発信を前記第2の端末が受け付けなかったことが検出された場合、前記記憶手段を参照することにより、前記第1の端末からの発信について前記第2の端末が着信許可の状態であるかを判断し、かつ、前記第2の端末からの発信について前記第1の端末が着信許可の状態であるかを判断することを特徴とする請求項1~3のいずれか一つに記載の通信制御方法。前記検出工程は、前記第1の端末から前記コールバック要求の取消し要求を検出し、前記送信工程は、前記検出工程によって前記取消し要求が検出された場合、前記コールバック要求を前記第2の端末に送信しないことを特徴とする請求項1~7のいずれか一つに記載の通信制御方法。着信許可または不許可を示すコンテキストを端末ごとに記憶する記憶手段と、第1の端末からの発信を第2の端末が受け付けなかったことを検出する検出手段と、前記検出手段によって前記第1の端末からの発信を前記第2の端末が受け付けなかったことが検出された場合、前記記憶手段を参照することにより、前記第2の端末が着信許可の状態であるかを判断する判断手段と、前記判断手段によって着信許可の状態であると判断された場合、前記第1の端末へのコールバック要求を前記第2の端末に送信する送信手段と、を備えることを特徴とする通信制御装置。端末間の発着信を制御する第1の装置と、発信元端末へのコールバックを制御する第2の装置と、が接続された通信制御システムであって、前記第2の装置は、着信許可または不許可を示すコンテキストを端末ごとに記憶する記憶手段と、第1の端末からの発信を第2の端末が受け付けなかったことを検出する検出手段と、前記検出手段によって前記第1の端末からの発信を前記第2の端末が受け付けなかったことが検出された場合、前記記憶手段を参照することにより、前記第2の端末が着信許可の状態であるかを判断する判断手段と、前記判断手段によって着信許可の状態であると判断された場合、前記第1の端末へのコールバック要求を前記第2の端末に送信する送信手段と、を備え、前記第1の装置は、前記第1の端末から前記第2の端末へ発信されたことを前記第2の装置に通知することを特徴とする通信制御システム。端末間の発着信を制御する第1の装置と、発信元端末へのコールバックを制御する第2の装置と、が接続された通信制御システムであって、前記第2の装置は、着信許可または不許可を示すコンテキストを端末ごとに記憶する記憶手段と、第1の端末からの発信を第2の端末が受け付けなかったことを検出する検出手段と、前記検出手段によって前記第1の端末からの発信を前記第2の端末が受け付けなかったことが検出された場合、前記記憶手段を参照することにより、前記第2の端末が着信許可の状態であるかを判断する判断手段と、前記判断手段によって着信許可の状態であると判断された場合、前記第1の端末へのコールバック要求を前記第1の装置に送信する送信手段と、を備え、前記第1の装置は、前記第1の端末から前記第2の端末へ発信されたことを前記第2の装置に通知し、前記送信手段からの前記コールバック要求を前記第2の装置に通知することを特徴とする通信制御システム。しかしながら、上述した従来技術では、着信が拒否された後のコールバックについては考慮されていないため、通信端末の利用者は、コールバックに関しては、自らが着信許可の状態であるか否かを判断する手間がかかるといった問題があった。また、利用者の状況が変化するたびに、着信可否の状態をサーバに設定し直す必要があるため、設定変更作業の手間がかかるといった問題があった。また、利用者の状況が変化したときに、利用者が設定変更を行わなかった場合、利用者の望まない着信が行われるといった問題があった。本発明は、上述した従来技術による問題点を解消するため、着信者が着信許可の状態であるときにコールバックさせる通信制御方法、通信制御装置、および通信制御システムを提供することを目的とする。上述した課題を解決し、目的を達成するため、本発明の一側面によれば、コンピュータが、第1の端末からの発信を第2の端末が受け付けなかったことを検出し、第1の端末からの発信を第2の端末が受け付けなかったことが検出された場合、着信許可または不許可を示すコンテキストを端末ごとに記憶する記憶手段を参照することにより、第2の端末が着信許可の状態であるかを判断し、着信許可の状態であると判断された場合、第1の端末へのコールバック要求を第2の端末に送信する通信制御方法、および通信制御装置が提案される。また、上述した課題を解決し、目的を達成するため、本発明の一側面によれば、端末間の発着信を制御する第1の装置と、発信元端末へのコールバックを制御する第2の装置と、が接続された通信制御システムであって、第2の装置は、着信許可または不許可を示すコンテキストを端末ごとに記憶する記憶手段を有し、第1の端末からの発信を第2の端末が受け付けなかったことを検出し、第1の端末からの発信を第2の端末が受け付けなかったことが検出された場合、記憶手段を参照することにより、第2の端末が着信許可の状態であるかを判断し、着信許可の状態であると判断された場合、第1の端末へのコールバック要求を第2の端末に送信し、第1の装置は、第1の端末から第2の端末へ発信されたことを第2の装置に通知する通信制御システムが提案される。上述した課題を解決し、目的を達成するため、本発明の一側面によれば、端末間の発着信を制御する第1の装置と、発信元端末へのコールバックを制御する第2の装置と、が接続された通信制御システムであって、第2の装置は、着信許可または不許可を示すコンテキストを端末ごとに記憶する記憶手段を有し、第1の端末からの発信を第2の端末が受け付けなかったことを検出し、第1の端末からの発信を第2の端末が受け付けなかったことが検出された場合、記憶手段を参照することにより、第2の端末が着信許可の状態であるかを判断し、着信許可の状態であると判断された場合、第1の端末へのコールバック要求を第1の装置に送信し、第1の装置は、第1の端末から第2の端末へ発信されたことを第2の装置に通知し、送信手段からのコールバック要求を第2の装置に通知する通信制御システムが提案される。本発明の一側面によれば、着信者が着信許可の状態であるときにコールバックさせるという効果を奏する。以下に添付図面を参照して、この発明にかかる通信制御方法、通信制御装置、および通信制御システムの実施の形態を詳細に説明する。通信制御装置は、着信側端末が着信許可の状態になったときに、コールバックが行われるようにするために、着信側端末の状態を示すコンテキストを取得する。次に、通信制御装置は、予め保持しておいた着信側端末が着信許可の状態になる場合のコンテキストと、取得した着信側端末のコンテキストと、を参照することにより、着信側端末の状態が着信許可の状態か、または着信不許可の状態か、を判断する。そして、通信制御装置は、着信側端末の状態が着信許可の状態であると判断された場合にのみ、着信側端末にコールバック要求を送信する。これにより、着信側端末が着信不許可の状態のときにはコールバック要求が送信されないため、着信者の手間が削減できる。通信制御装置による着信者へのコールバック要求の送信の内容まず、図1を用いて、通信制御装置による着信者へのコールバック要求の送信の内容について説明する。図1は、通信制御装置による着信者へのコールバック要求の送信の内容を示す説明図である。図1では、呼を発信する側の通信端末T以下、発信側端末Sというと、呼が着信される側の通信端末T以下、着信側端末Rというと、通信制御装置100と、を含む通信システムCを示す。発信側端末Sは、発信側端末Sの利用者の操作により、着信側端末Rへの呼を発信する端末である。着信側端末Rは、発信側端末Sが発信した呼が着信される端末である。また、着信側端末Rは、着信側端末Rのコンテキストを取得するセンサを有する。コンテキストとは、自端末ならびに自端末の利用者の状態を示す情報であり、例えば、着信側端末Rがある場所ならびに着信側端末Rの利用者のいる場所、または、着信側端末Rが通話中か否かならびに着信側端末Rの利用者が通話中か否かを示す情報である。以下では、発信側端末Sの利用者を発信者という。また、以下では、着信側端末Rの利用者を着信者という。通信制御装置100は、着信側端末Rのコンテキストを取得して、着信側端末Rの着信許可または着信不許可を判断する装置である。また、通信制御装置100は、着信側端末Rが着信許可の状態である場合に、コールバック要求を送信する装置である。具体的には、例えば、通信制御装置100は、コンテキスト管理サーバ110と、コールバック制御サーバ120と、を含む装置である。ここで、コンテキスト管理サーバ110は、着信側端末Rのコンテキストを管理するサーバである。また、コンテキスト管理サーバ110は、通信端末Tごとの着信許可である場合のコンテキストを記憶する監視コンテキストDBを保持し、通信端末Tが通信許可の状態になったことを検出するサーバである。コールバック制御サーバ120は、コールバックのために発信側端末Sの電話番号を記憶するコールバックDBを記憶するサーバである。また、コールバック制御サーバ120は、コンテキスト管理サーバ110から着信側端末Rが着信許可の状態になったことを通知された場合に、着信側端末Rと発信側端末Sとにコールバックの通信を行わせるサーバである。また、通信制御装置100は、さらに、呼制御サーバ130を含んでもよい。呼制御サーバ130は、発信側端末Sと着信側端末Rとの通信の接続および切断を行うサーバである。そして、コールバック制御サーバ120は、呼制御サーバ130を介して、着信側端末Rと発信側端末Sとにコールバックの通信を行わせるようにしてもよい。具体的には、呼制御サーバ130は、いわゆる第三者呼制御third-partycallcontrolにより、着信側端末Rと発信側端末Sとにコールバックの通信を行わせる。ただし、通信制御装置100は、コンテキスト管理サーバ110と、コールバック制御サーバ120と、呼制御サーバ130と、の機能を含む1装置であってもよい。ここで、発信側端末Sから着信側端末Rへと発信された呼が、着信側端末Rに受け付けられなかった場合を想定して、通信制御装置100による着信者へのコールバック要求の送信の内容について説明する。1通信制御装置100は、発信側端末Sから着信側端末Rへの呼が、着信側端末Rに受け付けられなかったことを検出する。具体的には、例えば、通信制御装置100は、発信側端末Sから着信側端末Rへの呼の着信を拒否するイベントがあったことが、着信側端末Rから通知されることにより、呼が着信側端末Rに受け付けられなかったことを検出する。また、具体的には、例えば、通信制御装置100は、呼制御サーバ130により発信側端末Sと着信側端末Rとの通話を制御している場合は、呼制御サーバ130が着信側端末Rへの着信を拒否するイベントを検出して、呼が着信側端末Rに受け付けられなかったことを検出する。そして、通信制御装置100は、発信側端末Sから着信側端末Rへの呼が着信側端末Rに受け付けられなかったことを検出すると、コールバック要求の送信の可否の判定を開始し、着信側端末Rのコンテキストを監視する。2ここで、着信側端末Rは、着信側端末Rのコンテキストを通信制御装置100に通知する。ここでは、コンテキストは、通信端末Tの場所を示す情報である。例えば、通信制御装置100が無線LANのSSIDServiceSetIDentifierに対応する場所を記憶するテーブルを有し、テーブルを参照して無線LANのSSIDから場所を特定することができる。また、例えば、通信制御装置100が場所に対応するGPSGlobalPositioningSystemの座標の範囲を記憶するテーブルを有し、テーブルを参照してGPSの座標から場所を特定できることができる。また、例えば、対象となる場所に赤外線受信器が設けられ、通信制御装置100が赤外線受信器の識別子に対応する場所を記憶するテーブルを有し、テーブルを参照して赤外線受信器の識別子から場所を特定することができる。なお、着信側端末Rがコンテキストを通知するトリガは、例えば、着信側端末Rのコンテキストに変化があったときである。また、特定の場所に入ったときのコンテキストの変化のみをトリガにすることで、着信者が特定の場所へ出入りを繰り返した場合を検出しないようにして、通信制御装置の動作を安定化できる。また、例えば、着信側端末Rは、一定時間ごとにコンテキストを通知することにしてもよい。3次に、通信制御装置100は、着信側端末Rのコンテキストの通知を受けると、予め保持しておいた監視コンテキストDBDataBaseを参照して、着信側端末Rが着信許可の状態にあるか否かを判定する。ここでは、通信制御装置100は、着信側端末Rから通知されたコンテキストが示す場所が休憩室であり、監視コンテキストDBには会議室以外では着信許可の状態であると記憶されているため、着信側端末Rが着信許可の状態にあると判定する。ただし、通信制御装置100は、さらに、発信側端末Sが着信許可の状態であるか否かを判定してもよい。4そして、通信制御装置100は、着信側端末Rが着信許可の状態であれば、着信側端末Rにコールバック要求を送信する。ここで、コールバック要求とは、例えば、発信側端末Sの電話番号を含んだメッセージである。また、コールバック要求とは、例えば、発信側端末Sへのコールバックを実行するアプリケーションであってもよい。また、コールバック要求とは、例えば、呼制御サーバ130からの着信要求であってもよい。ただし、通信制御装置100は、3において、発信側端末Sが着信許可の状態であるかを判定した場合、着信側端末Rと発信側端末Sの双方が着信許可の状態である場合に限って、着信側端末Rにコールバック要求を送信するようにしてもよい。5コールバック要求を受けた着信側端末Rは、発信側端末Sとの通話を開始する。具体的には、例えば、コールバック要求が発信側端末Sの電話番号を含んだメッセージであれば、着信側端末Rは、着信者によるメッセージに含まれる電話番号に呼を発信する操作を受けて、発信側端末Sとの通話を開始する。また、具体的には、例えば、コールバック要求が発信側端末Sへのコールバックを実行するアプリケーションであれば、着信側端末Rは、着信者による該当アプリケーションを実行する操作を受けて、発信側端末Sとの通話を開始する。また、具体的には、例えば、コールバック要求が呼制御サーバ130からの着信要求であれば、着信側端末Rは、着信者による着信要求を許可する操作を受けて、発信側端末Sとの通話を開始する。このように、通信制御装置100は、着信側端末Rのコンテキストを取得し、自動的に着信側端末Rが着信許可の状態になったか否かを判定する。そして、通信制御装置100は、着信側端末Rが着信許可の状態になったことが判定された場合にのみ、着信側端末Rにコールバック要求を送信する。そのため、着信側端末Rの利用者が、着信許可または不許可の状態であるかを、自ら判断しなくてよくなり、着信側端末Rの利用者の手間を削減できる。また、着信側端末Rの利用者は、着信不許可の状態であるにもかかわらず、コールバック要求を受けるといった不都合を被ることはない。また、通信制御装置100は、発信側端末Sまたは着信側端末Rのコンテキストを保持する他のシステムがあれば、他のシステムからコンテキストを取得して、着信側端末Rの着信許可の状態を判断する指標にしてもよい。また、図1では、発信側端末Sと着信側端末Rとは1台ずつだったが、電話会議やテレビ会議の場合に対しても、着信側端末Rが複数台であるとして、通信制御装置100を適用することができる。また、図1では、音声電話を例に挙げているが、音声メールやテキストメールに対しても、通信制御装置100を適用することができる。図1に示した通信システムCの構成例次に、図2を用いて、図1に示した通信システムCの構成例について説明する。図2は、図1に示した通信システムCの構成例を示す説明図である。図2に示すように、通信システムCは、複数の無線LAN201と、発信側端末Sと、着信側端末Rと、コンテキスト管理サーバ110と、コールバック制御サーバ120と、呼制御サーバ130と、他のシステム202と、を含む。また、コンテキスト管理サーバ110は、場所DB111と、コンテキストDB112と、監視コンテキストDB113と、を有する。コールバック制御サーバ120は、呼制御DB121と、コールバックDB122と、を有する。コンテキスト管理サーバ110は、通信端末Tから通知された無線LAN201のSSIDに対応する場所を場所DBに基づいて特定するサーバである。そして、コンテキスト管理サーバ110は、特定した場所を含む通信端末Tのコンテキストを、コンテキストDB112に格納して管理するサーバである。また、コンテキスト管理サーバ110は、通信端末Tごとの着信許可である場合のコンテキストを記憶する監視コンテキストDB113を保持し、通信端末Tが通信許可の状態になったことを検出するサーバである。コールバック制御サーバ120は、呼制御DB121に基づいて、コールバックを行うか否かを判定するサーバである。そして、コールバック制御サーバ120は、コールバックのために発信側端末Sの電話番号を記憶するコールバックDBを記憶するサーバである。また、コールバック制御サーバ120は、コールバックを行うと判定した後に、コンテキスト管理サーバ110から着信側端末Rが着信許可の状態になったことを通知された場合に、着信側端末Rと発信側端末Sとにコールバックの通信を行わせるサーバである。呼制御サーバ130は、発信側端末Sと着信側端末Rとの通信の接続および切断を行うサーバである。なお、コールバック制御サーバ120は、呼制御サーバ130を介して、着信側端末Rと発信側端末Sとにコールバックの通信を行わせるようにしてもよい。具体的には、呼制御サーバ130は、いわゆる第三者呼制御third-partycallcontrolにより、着信側端末Rと発信側端末Sとにコールバックの通信を行わせる。発信側端末Sは、発信側端末Sの利用者の操作により、着信側端末Rへの呼を発信する端末である。着信側端末Rは、発信側端末Sが発信した呼が着信される端末である。また、各通信端末Tは、自端末のコンテキストを取得するセンサを有し、取得したコンテキストを、無線LAN201を介して通信制御装置100に送信する端末である。コンテキストには、例えば、自端末の場所を示す情報として、無線LAN201のSSIDが含まれる。他のシステム202は、発信側端末Sまたは着信側端末Rのコンテキストを保持するシステムである。例えば、発信側端末Sが発信した呼の用件および緊急度を管理するシステムが挙げられる。通信制御装置100のハードウェア構成例次に、図3を用いて、通信制御装置100のハードウェア構成例について説明する。図1に示したように、通信制御装置100は、コンテキスト管理サーバ110と、コールバック制御サーバ120と、呼制御サーバ130と、を含む装置である。図3は、実施の形態にかかる通信制御装置100に含まれる各サーバのハードウェア構成例を示すブロック図である。図3において、例えば、コンテキスト管理サーバ110を想定すると、コンテキスト管理サーバ110は、CPUCentralProcessingUnit301と、ROMRead‐OnlyMemory302と、RAMRandomAccessMemory303と、磁気ディスクドライブ304と、磁気ディスク305と、光ディスクドライブ306と、光ディスク307と、ディスプレイ308と、I/FInterface309と、キーボード310と、マウス311と、スキャナ312と、プリンタ313と、を備えている。また、各構成部はバス320によってそれぞれ接続されている。ここで、CPU301は、各サーバの全体の制御を司る。ROM302は、ブートプログラムなどのプログラムを記憶している。RAM303は、CPU301のワークエリアとして使用される。また、コンテキスト管理サーバ110のRAM303は、場所DB111と、コンテキストDB112と、監視コンテキストDB113と、を記憶する。磁気ディスクドライブ304は、CPU301の制御にしたがって磁気ディスク305に対するデータのリード/ライトを制御する。磁気ディスク305は、磁気ディスクドライブ304の制御で書き込まれたデータを記憶する。光ディスクドライブ306は、CPU301の制御にしたがって光ディスク307に対するデータのリード/ライトを制御する。光ディスク307は、光ディスクドライブ306の制御で書き込まれたデータを記憶したり、光ディスク307に記憶されたデータをコンピュータに読み取らせたりする。ディスプレイ308は、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示する。このディスプレイ308は、例えば、CRT、TFT液晶ディスプレイ、プラズマディスプレイなどを採用することができる。インターフェース以下、I/Fと略する。309は、通信回線を通じてLANLocalAreaNetwork、WANWideAreaNetwork、インターネットなどのネットワーク214に接続され、このネットワーク214を介して他の装置に接続される。そして、I/F309は、ネットワーク214と内部のインターフェースを司り、外部装置からのデータの入出力を制御する。I/F309には、例えばモデムやLANアダプタなどを採用することができる。キーボード310は、文字、数字、各種指示などの入力のためのキーを備え、データの入力を行う。また、タッチパネル式の入力パッドやテンキーなどであってもよい。マウス311は、カーソルの移動や範囲選択、あるいはウィンドウの移動やサイズの変更などを行う。ポインティングデバイスとして同様に機能を備えるものであれば、トラックボールやジョイスティックなどであってもよい。スキャナ312は、画像を光学的に読み取り、各サーバ内に画像データを取り込む。なお、スキャナ312は、OCROpticalCharacterReader機能を持たせてもよい。また、プリンタ313は、画像データや文書データを印刷する。プリンタ313には、例えば、レーザプリンタやインクジェットプリンタを採用することができる。また、図3において、例えば、コールバック制御サーバ120を想定すると、コールバック制御サーバ120は、CPU301と、ROM302と、RAM303と、磁気ディスクドライブ304と、磁気ディスク305と、光ディスクドライブ306と、光ディスク307と、ディスプレイ308と、I/FInterface309と、キーボード310と、マウス311と、スキャナ312と、プリンタ313と、を備えている。また、各構成部はバス320によってそれぞれ接続されている。各構成部の内容は、コンテキスト管理サーバ110を想定して説明した内容と同様であるため説明を省略する。ただし、コールバック制御サーバ120のRAM303は、呼制御DB121と、コールバックDB122と、を記憶する。また、図3において、例えば、呼制御サーバ130を想定すると、呼制御サーバ130は、CPU301と、ROM302と、RAM303と、磁気ディスクドライブ304と、磁気ディスク305と、光ディスクドライブ306と、光ディスク307と、ディスプレイ308と、I/FInterface309と、キーボード310と、マウス311と、スキャナ312と、プリンタ313と、を備えている。また、各構成部はバス320によってそれぞれ接続されている。各構成部の内容は、コンテキスト管理サーバ110を想定して説明した内容と同様であるため説明を省略する。場所DBの記憶内容次に、図4を用いて、コンテキスト管理サーバ110に記憶されている場所DBの記憶内容について説明する。場所DBは、通信制御装置100コンテキスト管理サーバ110が、通信端末Tがどの場所にあるかを推定する際に参照するDBである。図4は、コンテキスト管理サーバ110に記憶されている場所DBの記憶内容を示す説明図である。図4に示すように、場所DB111は、SSIDServiceSetIDentifier項目に対応付けて、場所項目を有し、SSIDごとにレコードを構成する。SSID項目には、無線LANにおけるアクセスポイントの識別子以下、SSIDというが記憶されている。なお、SSIDは、最大32文字の英数字である。場所項目には、SSIDによって識別されるアクセスポイントが設置されている場所の名称が記憶されている。コンテキストDBの記憶内容次に、図5を用いて、コンテキスト管理サーバ110に記憶されているコンテキストDBの記憶内容について説明する。コンテキストDBは、通信制御装置100コンテキスト管理サーバ110が通信端末Tの現在のコンテキストを取得する際に参照するDBである。図5は、コンテキスト管理サーバ110に記憶されているコンテキストDBの記憶内容を示す説明図である。図5に示すように、コンテキストDB112は、通信端末Tごとに、コンテキスト種別項目に対応付けて、値項目と、コールバックID項目と、を有し、通信端末Tからコンテキストを受信するごとにレコードを構成する。コンテキスト種別項目には、通信端末Tのコンテキストの種別が記憶されている。具体的には、コンテキストの種別には、通信端末Tがある場所を示す種別である場所や、通信端末Tが通話中であるか否かを示す電話がある。値項目には、コンテキストの種別に対応する状態が記憶されている。具体的には、コンテキストの種別の場所に対応する値項目には事務所Aが記憶されている。また、コンテキストの種別電話に対応する値項目には、idleが記憶されている。idleは、発信側端末Sまたは着信側端末Rが通話していない状態を示す。コールバックID項目には、コールバックを識別する識別子が記憶されている。監視コンテキストDBの記憶内容次に、図6を用いて、コンテキスト管理サーバ110に記憶されている監視コンテキストDBの記憶内容について説明する。監視コンテキストDBは、通信制御装置100コンテキスト管理サーバ110が、通信端末Tが着信許可の状態であるか否かを判定する際に参照するDBである。図6は、コンテキスト管理サーバ110に記憶されている監視コンテキストDBの記憶内容を示す説明図である。図6に示すように、監視コンテキストDB113は、コールバックID項目に対応付けて、ユーザID項目と、コンテキスト種別項目と、値項目と、を有し、コールバック制御サーバ120からコールバック契機通知要求が通知されるごとにレコードを構成する。コールバックID項目には、コールバックを識別する識別子が記憶されている。ユーザID項目には、発信側端末Sまたは着信側端末Rの識別子が記憶されている。コンテキスト種別項目には、発信側端末Sまたは着信側端末Rのコンテキストの種別が記憶されている。値項目には、コンテキストの種別に対応する状態が記憶されている。呼制御DBの記憶内容次に、図7を用いて、コールバック制御サーバ120に記憶されている呼制御DBの記憶内容について説明する。呼制御DBは、通信制御装置100コールバック制御サーバ120が、通信端末Tが着信不許可の状態であるか否かを判定する際に参照するDBである。図7は、コールバック制御サーバ120に記憶されている呼制御DBの記憶内容を示す説明図である。図7に示すように、呼制御DB121は、通信端末Tごとに、コンテキスト種別項目に対応付けて、値項目を有し、通信端末Tから着信不許可の状態に対応するコンテキストの条件以下、呼制御条件というを受信するごとにレコードを構成する。コンテキスト種別項目には、コンテキストの種別が記憶されている。具体的には、コンテキストの種別には、通信端末Tがある場所を示す種別である場所や、通信端末Tが通話中であるか否かを示す電話がある。値項目には、通信端末Tが着信不許可である状態に対応するコンテキストの種別の状態が記憶されている。具体的には、通信端末Tが着信不許可である状態に対応するコンテキストの種別場所の状態として、値項目には会議室が記憶されている。コールバックDBの記憶内容次に、図8を用いて、コールバック制御サーバ120に記憶されているコールバックDBの記憶内容について説明する。コールバックDBは、通信制御装置100がコールバックを実行する際に使用する発信側端末Sの電話番号やIPアドレスを特定するために参照するDBである。図8は、コールバック制御サーバ120に記憶されているコールバックDBの記憶内容を示す説明図である。図8に示すように、コールバックDB122は、コールバックID項目に対応付けて、ユーザ種別項目と、電話番号項目と、IPアドレス項目と、を有し、発信側端末Sからの呼が着信側端末Rに受け付けられなかったときにレコードを構成する。コールバックID項目の記憶内容は、図6に示したコールバックID項目の記憶内容と同様のため説明を省略する。ユーザ種別項目には、発信側端末Sまたは着信側端末Rの識別子が記憶されている。電話番号項目には、ユーザID項目の内容から識別される通信端末Tの電話番号が記憶されている。IPアドレス項目には、ユーザID項目の内容から識別される通信端末TのIPアドレスが記憶されている。通信制御装置100の機能的構成例次に、図9を用いて、通信制御装置100の機能的構成例について説明する。図9は、通信制御装置100の機能的構成を示すブロック図である。通信制御装置100は、記憶部901と、検出部902と、判断部903と、送信部904と、を含む構成である。この制御部となる機能記憶部901~送信部904は、具体的には、例えば、図3に示したROM302、RAM303、磁気ディスク305、光ディスク307などの記憶装置に記憶されたプログラムをCPU301に実行させることにより、または、I/F309により、その機能を実現する。記憶部901は、着信許可または不許可を示すコンテキストを端末ごとに記憶する機能を有する。ここで、コンテキストとは、通信端末Tの状態であり、例えば、通信端末Tの場所、または通信端末Tが通信中か否かの状態である。着信許可または不許可を示すコンテキストとは、通信端末Tが着信許可または不許可の状態になるコンテキストであり、具体的には、例えば、不許可を示すコンテキストとして、会議室が挙げられる。具体的には、例えば、記憶部901は、上述した呼制御DB121および監視コンテキストDB113を記憶する。これにより、通信端末Tのコンテキストに基づいて、通信装置が着信許可の状態であるか否かを判定することができるようになる。検出部902は、第1の端末からの発信を第2の端末が受け付けなかったことを検出する機能を有する。ここで、第1の端末とは、上述した発信側端末Sである。第2の端末とは、上述した着信側端末Rである。具体的には、例えば、検出部902は、第1の端末からの発信について第2の端末で着信拒否の操作が行われたことを検出する。より具体的には、例えば、検出部902は、発信側端末Sからの呼を着信拒否するイベントがあったことの通知を、着信側端末Rから受信することにより、着信側端末Rで着信拒否の操作が行われたことを検出する。これにより、コールバック要求の送信の可否の判定を開始するトリガを検出できる。具体的には、例えば、検出部902は、第1の端末から第2の端末へ発信されたことが検出されたときに、記憶部901を参照することにより、第2の端末が着信不許可の状態であると判断された場合、第1の端末からの発信を第2の端末が受け付けなかったことを検出する。より具体的には、例えば、検出部902は、呼制御サーバ130が呼制御DB121を参照して、発信側端末Sから着信側端末Rへの呼の着信を拒否したことを検出する。これにより、コールバック要求の送信の可否の判定を開始するトリガを検出できる。また、検出部902は、第1の端末からコールバック要求の取消し要求を検出する機能を有する。具体的には、検出部902は、発信側端末Sからコールバック要求の取消し要求が通知されることにより、取消し要求を検出する。これにより、発信側端末Sの利用者が、コールバックされなくてもよい状態になった場合に、不要なコールバックが行われることを防止する処理を開始するためのトリガを検出することができる。なお、検出結果は、RAM303、磁気ディスク305、光ディスク307などの記憶領域に記憶される。判断部903は、検出部902によって第1の端末からの発信を第2の端末が受け付けなかったことが検出された場合、記憶部901を参照することにより、第2の端末が着信許可の状態であるか否かを判断する機能を有する。ここで、第1の端末からの発信とは、上述した発信側端末Sから発信される呼である。具体的には、例えば、判断部903は、検出部902によって第1の端末からの発信を第2の端末が受け付けなかったことが検出された場合、記憶部901を参照することにより、第1の端末からの発信について第2の端末が着信許可の状態であるか否かを判断する。より具体的には、例えば、検出部902によって発信側端末Sからの呼を着信側端末Rが受け付けなかったことが検出された場合を想定する。この場合、判断部903は、監視コンテキストDB113を参照することにより、着信側端末Rが着信許可の状態になったか否かを判断する。これにより、着信側端末Rが着信許可の状態にあるときのみ、コールバック要求の送信を開始することができる。具体的には、例えば、判断部903は、検出部902によって第1の端末からの発信を第2の端末が受け付けなかったことが検出された場合、記憶部901を参照することにより、第1および第2の端末が着信許可の状態であるか否かを判断する。より具体的には、例えば、検出部902によって発信側端末Sからの呼を着信側端末Rが受け付けなかったことが検出された場合を想定する。この場合、判断部903は、監視コンテキストDB113を参照することにより、着信側端末Rおよび発信側端末Sの双方が着信許可の状態になったか否かを判断する。これにより、着信側端末Rおよび発信側端末Sの双方が着信許可の状態にあるときのみ、コールバック要求の送信を開始することができる。具体的には、例えば、判断部903は、検出部902によって第1の端末からの発信を第2の端末が受け付けなかったことが検出された場合、記憶部901を参照することにより、第1の端末からの発信について第2の端末が着信許可の状態であるか否かを判断し、かつ、第1の端末が着信許可の状態であるか否かを判断する。より具体的には、例えば、着信側端末Rが発信側端末Sからの呼の用件や緊急度、または発信側端末Sの利用者との関係例えば、着信側端末Rの利用者にとって発信側端末Sの利用者が顧客であることに基づいて着信許可の状態であるかを判断する場合を想定する。そして、検出部902によって発信側端末Sからの呼を着信側端末Rが受け付けなかったことが検出された場合を想定する。この場合、判断部903は、呼の用件や緊急度を含む監視コンテキストDB113を参照することにより、発信側端末Sからの呼に関して着信側端末Rが着信許可の状態になったか否かを判断する。また、判断部903は、発信側端末Sが着信許可の状態になったか否かを判断する。これにより、発信側端末Sとの通信に関して着信側端末Rが着信許可の状態にあり、かつ、発信側端末Sが着信許可の状態のときのみ、コールバック要求の送信を開始することができる。そのため、例えば、顧客の発信側端末Sへのコールバックと同僚の発信側端末Sへのコールバックとをそれぞれ異なる基準監視コンテキストで行うようにすることができ、着信側端末Rの利便性を向上できる。具体的には、例えば、判断部903は、検出部902によって第1の端末からの発信を第2の端末が受け付けなかったことが検出された場合、記憶部901を参照することにより、第1の端末からの発信について第2の端末が着信許可の状態であるか否かを判断し、かつ、第2の端末からの発信について第1の端末が着信許可の状態であるか否かを判断する。より具体的には、例えば、着信側端末Rが発信側端末Sからの呼の用件や緊急度に基づいて着信許可の状態であるか否かを判断し、かつ、発信側端末Sが着信側端末Rからの呼の用件や緊急度に基づいて着信許可の状態であるか否かを判断する場合を想定する。また、各通信端末Tは、自端末の利用者と通信相手の通信端末Tの利用者との関係をさらに参照してもよい。そして、検出部902によって発信側端末Sからの呼を着信側端末Rが受け付けなかったことが検出された場合を想定する。この場合、判断部903は、呼の用件や緊急度を含む監視コンテキストDB113を参照することにより、発信側端末Sとの通信に関して着信側端末Rが着信許可の状態になったか否かを判断する。また、判断部903は、着信側端末Rとの通信に関して発信側端末Sが着信許可の状態になったか否かを判断する。これにより、発信側端末Sとの通信に関して着信側端末Rが着信許可の状態にあり、かつ、着信側端末Rとの通信に関して発信側端末Sが着信許可の状態のときのみ、コールバック要求の送信を開始することができる。そのため、例えば、顧客の通信端末Tとのコールバックに関する通話と同僚の通信端末Tとのコールバックに関する通話をそれぞれ異なる基準監視コンテキストで行うようにすることができ、通信端末Tの利便性を向上できる。また、呼の用件や緊急度に応じて異なる基準監視コンテキストで、着信許可の状態か否かを判断することができ、通信端末Tの利便性を向上できる。なお、判断結果は、RAM303、磁気ディスク305、光ディスク307などの記憶領域に記憶される。送信部904は、判断部903によって着信許可の状態であると判断された場合、第1の端末へのコールバック要求を第2の端末に送信する機能を有する。ここで、コールバック要求とは、例えば、発信側端末Sを識別する識別子になる発信側端末Sの電話番号を含んだメッセージである。また、コールバック要求とは、例えば、発信側端末Sへのコールバックを実行するアプリケーションであってもよい。また、コールバック要求とは、例えば、呼制御サーバ130からの着信要求であってもよい。具体的には、例えば、送信部904は、判断部903によって、着信側端末R、または着信側端末Rと発信側端末Sとの双方、が着信許可の状態であると判断された場合、発信側端末Sへのコールバック要求を着信側端末Rに送信する。ただし、コールバック要求が呼制御サーバ130からの着信要求である場合、送信部904は、発信側端末Sにも着信要求を送信して、着信側端末Rと発信側端末Sと通信を開始させる。これにより、着信側端末Rに発信側端末Sへのコールバックを行わせることができる。また、送信部904は、検出部902によって取消し要求が検出された場合、コールバック要求を第2の端末に送信しない機能を有する。具体的には、例えば、送信部904は、検出部902によって取消し要求が検出された場合、コールバック要求を着信側端末Rに送信しない。これにより、不要なコールバック要求を行わないようにする。実施例1ここで、図10~図16を用いて、実施例1について説明する。実施例1は、着信側端末Rからの着信拒否イベントがあったことの通知を受けることにより、通信制御装置100が発信側端末Sからの呼を着信側端末Rが受け付けなかったことを検出する場合の実施例である。実施例1にかかる通信制御装置100による着信者へのコールバック要求の送信例1の内容次に、図10を用いて、実施例1にかかる通信制御装置100による着信者へのコールバック要求の送信例1の内容について説明する。送信例1は、通信制御装置100が、着信側端末Rが着信許可の状態か否かに基づいて、コールバック要求を送信する例である。図10は、実施例1にかかる通信制御装置100による着信者へのコールバック要求の送信例1の内容を示す説明図である。図10では、図1と同様に、発信者が有する発信側端末Sと、着信者が有する着信側端末Rと、通信制御装置100と、を含む通信システムを示す。通信制御装置100は、コンテキスト管理サーバ110と、コールバック制御サーバ120と、呼制御サーバ130と、を含む装置である。1まず、発信側端末Sは、着信側端末Rに呼を発信する。2ここで、着信側端末Rは、発信側端末Sからの呼を着信拒否する。着信拒否は、例えば、着信者が着信側端末Rを操作することにより行われる。また、着信者の着信側端末Rへの操作がなく呼が一定時間着信されなかったことを、着信拒否とみなしてもよい。3着信側端末Rは、呼を着信拒否すると、着信拒否のイベントがあったことを通信制御装置100に通知する。4通信制御装置100は、着信側端末Rから着信拒否のイベントがあったことの通知を受けると、コールバック要求の送信の可否の判定を開始し、着信側端末Rのコンテキストを監視する。5ここで、着信側端末Rが、役員会議室から休憩室へ移動した場合を想定する。6着信側端末Rは、休憩室に移動すると、着信側端末Rのコンテキストを、通信制御装置100に通知する。ここでは、コンテキストは、着信側端末Rの場所である。7次に、通信制御装置100は、着信側端末Rのコンテキストの通知を受けると、予め保持しておいた監視コンテキストDB113を参照して、着信側端末Rが着信許可の状態であるか否かを判定する。8着信側端末Rが着信許可の状態である場合、通信制御装置100は、コールバックDB122を参照して、コールバック要求を作成する。例えば、コールバック要求には、コールバックDB122から抽出した発信側端末Sの電話番号が含まれている。9そして、通信制御装置100は、作成したコールバック要求を着信側端末Rに送信する。10コールバック要求を受けた着信側端末Rは、コールバック要求に含まれている電話番号に対してコールバックを行い、発信側端末Sとの通話を開始する。このように、通信制御装置100は、着信側端末Rのコンテキストを取得し、自動的に着信側端末Rが着信許可の状態になったか否かを判定する。そして、通信制御装置100は、着信側端末Rが着信許可の状態になったことが判定された場合にのみ、着信側端末Rにコールバック要求を送信する。そのため、着信側端末Rの利用者が、コールバックが必要であることを憶えていなくてもよくなり、着信側端末Rの利用者の手間を削減できる。また、着信側端末Rの利用者は、着信不許可の状態であるにもかかわらず、コールバック要求を受けるといった不都合を被ることはない。実施例1にかかる通信制御装置100による着信者へのコールバック要求の送信例2の内容次に、図11を用いて、実施例1にかかる通信制御装置100による着信者へのコールバック要求の送信例2の内容について説明する。送信例2は、通信制御装置100が、着信側端末Rが着信許可の状態か否かと、発信側端末Sが着信許可の状態か否かと、に基づいて、コールバック要求を送信する例である。図11は、実施例1にかかる通信制御装置100による着信者へのコールバック要求の送信例2の内容を示す説明図である。図11では、図1と同様に、発信者が有する発信側端末Sと、着信者が有する着信側端末Rと、通信制御装置100と、を含む通信システムを示す。通信制御装置100は、コンテキスト管理サーバ110と、コールバック制御サーバ120と、呼制御サーバ130と、を含む装置である。1~3の処理は、図10の1~3と同様の処理のため、ここでは、説明を省略する。4次に、通信制御装置100は、着信側端末Rから着信拒否のイベントがあったことの通知を受けると、コールバック要求の送信の可否の判定を開始し、着信側端末Rおよび発信側端末Sのコンテキストを監視する。5ここで、着信側端末Rが、役員会議室から休憩室へ移動した場合を想定する。6着信側端末Rは、休憩室に移動すると、通信制御装置100に、着信側端末Rのコンテキストを通知する。また、発信側端末Sは、通信制御装置100に、発信側端末Sのコンテキストを通知する。ここでは、コンテキストは、着信側端末Rの場所である。7次に、通信制御装置100は、着信側端末Rのコンテキストの通知を受けると、予め保持しておいた監視コンテキストDB113を参照して、着信側端末Rが着信許可の状態であるか否かを判定する。また、通信制御装置100は、コンテキストDB112の発信側端末Sのコンテキストから、発信側端末Sが着信拒否の状態であるか否かを判定する。8着信側端末Rと発信側端末Sとの双方が着信許可の状態である場合、通信制御装置100は、コールバックDB122を参照して、コールバック要求を作成する。例えば、コールバック要求には、コールバックDB122から抽出した発信側端末Sの電話番号が含まれている。9そして、通信制御装置100は、作成したコールバック要求を着信側端末Rに送信する。10コールバック要求を受けた着信側端末Rは、コールバック要求に含まれている電話番号に対してコールバックを行い、発信側端末Sとの通話を開始する。このように、通信制御装置100は、着信側端末Rのコンテキストを取得し、自動的に着信側端末Rが着信許可の状態になったか否かを判定する。そして、通信制御装置100は、着信側端末Rが着信許可の状態になったことが判定された場合にのみ、着信側端末Rにコールバック要求を送信する。そのため、着信側端末Rの利用者が、コールバックが必要であることを憶えていなくてもよくなり、着信側端末Rの利用者の手間を削減できる。また、着信側端末Rの利用者は、着信不許可の状態であるにもかかわらず、コールバック要求を受けるといった不都合を被ることはない。実施例1にかかる通信制御装置100内における各サーバの具体的な通信内容ここで、図12および図13を用いて、図10に示した実施例1にかかる通信制御装置100内における各サーバの具体的な通信内容について説明する。実施例1における発信側端末Sから呼が発信されるときの各サーバの通信内容の詳細まず、図12を用いて、実施例1における発信側端末Sから呼が発信されるときの各サーバの通信内容の詳細について説明する。図12は、実施例1における発信側端末Sから呼が発信されるときの各サーバの通信内容の詳細を示すシーケンス図である。まず、着信側端末Rは、呼制御条件をコールバック制御サーバ120に送信するステップS1201。コールバック制御サーバ120は、受信した呼制御条件に基づいて、呼制御DB121を更新する。次に、着信側端末Rは、自端末の状態を示すコンテキストをコンテキスト管理サーバ110に通知するステップS1202。コンテキスト管理サーバ110は、受信したコンテキストに基づいて、コンテキストDB112を更新する。例えば、コンテキスト管理サーバ110は、コンテキストに含まれるSSIDから、場所DB111に基づいて、通信端末Tの場所を特定して、コンテキストDB112を更新する。ここで、発信側端末Sから着信側端末Rへの呼が発信されるステップS1203。着信側端末Rは、呼が着信されると、コンテキスト管理サーバ110に通話中であることを示すコンテキストを送信するステップS1204。コンテキスト管理サーバ110は、受信したコンテキストに基づいて、コンテキストDB112を更新する。次に、着信側端末Rは、着信者の操作を受けて、呼の着信を拒否する。そして、着信側端末Rは、コンテキスト管理サーバ110に着信拒否のイベントがあったことを通知するステップS1205。コンテキスト管理サーバ110は、着信拒否のイベントがあったことにより、コンテキストDB112を更新する。次に、着信側端末Rは、コールバック制御サーバ120に着信拒否のイベントがあったことを通知するステップS1206。着信拒否のイベントがあったことを通知されたコールバック制御サーバ120は、呼制御DB121を参照しステップS1207、コールバック契機通知要求をコンテキスト管理サーバ110に通知するステップS1208。コールバック契機通知要求は、コンテキスト管理サーバ110に着信側端末Rのコンテキストを監視させ、着信許可の状態になった際に、コールバック制御サーバ120へ通知させる要求である。そして、コールバック制御サーバ120は、コールバックDB122に、コールバック情報を登録するステップS1209。コールバック情報は、例えば、コールバックの際に使用する発信側端末Sの電話番号およびIPアドレスである。これにより、コンテキスト管理サーバ110に、着信側端末Rのコンテキストの監視を開始させて、コールバック要求の送信のトリガを発生させることができる。実施例1におけるコールバック制御サーバ120によりコールバック要求が送信されるときの各サーバの通信内容の詳細次に、図13を用いて、実施例1におけるコールバック制御サーバ120によりコールバック要求が送信されるときの各サーバの通信内容の詳細について説明する。ここで、図12においてコンテキスト管理サーバ110にコンテキストを監視されている着信側端末Rが移動を行い、着信側端末Rのコンテキストが着信許可の状態に変化した場合を想定する。図13は、実施例1におけるコールバック制御サーバ120によりコールバック要求が送信されるときの各サーバの通信内容の詳細を示すシーケンス図である。まず、着信側端末Rは、移動によりコンテキストが変化すると、自端末の状態を示すコンテキストをコンテキスト管理サーバ110に通知するステップS1301。コンテキストの通知を受けたコンテキスト管理サーバ110は、監視コンテキストDB113を参照して、着信側端末Rが着信許可の状態になったか否かを判定する。そして、コンテキスト管理サーバ110は、着信側端末Rが着信許可の状態であれば、コールバック契機通知をコールバック制御サーバ120に通知するステップS1302。コールバック契機通知を受けたコールバック制御サーバ120は、コールバックDB122を参照しステップS1303、コールバック要求を作成する。そして、コールバック制御サーバ120は、作成したコールバック要求を着信側端末Rに送信するステップS1304。そして、コールバック要求を受けた着信側端末Rは、コールバック要求に含まれる発信側端末Sの電話番号に基づいて、発信側端末Sへコールバックを行うステップS1305。これにより、着信者が自らコールバックが必要であることを憶えておくことなく、通信制御装置100により自動的に着信側端末Rが着信許可の状態か否かが判定される。そして、通信制御装置100は、着信側端末Rが着信許可の状態のときのみコールバック要求を送信する。そのため、着信者が、コールバックが必要であることを憶えておく手間を削減できる。また、着信側端末Rが着信不許可の状態であるにもかかわらず、コールバック要求が受信されるといった不都合はなく、着信側端末Rの利便性を向上できる。実施例1におけるコールバック制御サーバ120のコールバック制御処理の処理内容の詳細次に、図14を用いて、実施例1におけるコールバック制御サーバ120のコールバック制御処理の処理内容の詳細について説明する。図14では、図12および図13において、コールバック制御サーバ120が行ったコールバック制御処理の処理内容について説明する。図14は、実施例1におけるコールバック制御サーバ120のコールバック制御処理の処理内容の詳細を示すフローチャートである。まず、コールバック制御サーバ120は、着信拒否イベントを受信したか否かを判定するステップS1401。ここで、着信拒否イベントを受信していない場合ステップS1401:No、コールバック制御サーバ120は、ステップS1401に戻り、着信拒否イベントの受信を待つ。一方、着信拒否イベントを受信した場合ステップS1401:Yes、コールバック制御サーバ120は、呼制御DB121を参照して、着信側端末Rの呼制御条件を取得するステップS1402。次に、コールバック制御サーバ120は、取得した呼制御条件に基づいて、着信側端末Rの着信許可の状態に対応する監視コンテキストを生成するステップS1403。そして、コールバック制御サーバ120は、コンテキスト管理サーバ110に、生成した監視コンテキストを含むコールバック契機通知要求を送信するステップS1404。次に、コールバック制御サーバ120は、コールバックDB122にコールバック情報を登録するステップS1405。以上のステップS1401~ステップS1405の処理が、ステップS1206~ステップS1209の処理に対応する処理である。次に、コールバック制御サーバ120は、コンテキスト管理サーバ110からのコールバック契機通知を受信したか否かを判定するステップS1406。ここで、コールバック契機通知を受信していない場合ステップS1406:No、コールバック制御サーバ120は、ステップS1406に戻り、コールバック契機通知の受信を待つ。一方、コールバック契機通知を受信した場合ステップS1406:Yes、コールバック制御サーバ120は、コールバックDB122からコールバック情報を取得しステップS1407、コールバック要求を送信するステップS1408。そして、コールバック制御サーバ120は、コールバック制御処理を終了する。以上のステップS1406~ステップS1408の処理が、ステップS1302~ステップS1304の処理に対応する処理である。これにより、通信制御装置100は、着信側端末Rが着信許可の状態になった場合にのみ、コールバック要求を送信することができる。着信者が、コールバックが必要であることを憶えておく手間を削減できる。また、着信側端末Rが着信不許可の状態であるにもかかわらず、コールバック要求が受信されるといった不都合はなく、着信側端末Rの利便性を向上できる。実施例1におけるコンテキスト管理サーバ110の監視コンテキスト登録処理の処理内容の詳細次に、図15を用いて、実施例1におけるコンテキスト管理サーバ110の監視コンテキスト登録処理の処理内容の詳細について説明する。図15では、図12において、コンテキスト管理サーバ110が行った監視コンテキスト登録処理の処理内容について説明する。図15は、実施例1におけるコンテキスト管理サーバ110の監視コンテキスト登録処理の処理内容の詳細を示すフローチャートである。まず、コンテキスト管理サーバ110は、コールバック制御サーバ120から、コールバック契機通知要求を受信したか否かを判定するステップS1501。ここで、コールバック契機通知要求を受信していない場合ステップS1501:No、コンテキスト管理サーバ110は、ステップS1501に戻り、コールバック契機通知要求の受信を待つ。一方、コールバック契機通知を受信した場合ステップS1501:Yes、コンテキスト管理サーバ110は、コールバック契機通知要求から監視コンテキストを抽出して、監視コンテキストDB113に登録するステップS1502。そして、コンテキスト管理サーバ110は、監視コンテキスト登録処理を終了する。以上のステップS1501~ステップS1502の処理が、ステップS1208の処理によりコールバック契機通知要求を送信されたコンテキスト管理サーバ110が行う処理である。これにより、コンテキスト管理サーバ110は、通信端末Tの着信許可の状態に対応する監視コンテキストを監視コンテキストDB113に登録し、通信端末Tが着信許可の状態になったか否かを監視できるようになる。実施例1におけるコンテキスト管理サーバ110のコールバック契機通知送信処理の処理内容の詳細次に、図16を用いて、実施例1におけるコンテキスト管理サーバ110のコールバック契機通知送信処理の処理内容の詳細について説明する。図16では、図13において、コンテキスト管理サーバ110が行ったコールバック契機通知送信処理の処理内容について説明する。図16は、実施例1におけるコンテキスト管理サーバ110のコールバック契機通知送信処理の処理内容の詳細を示すフローチャートである。まず、コンテキスト管理サーバ110は、コンテキストDB112が更新されたか否かを判定するステップS1601。例えば、コンテキストDB112の更新は、通信端末Tからのコンテキストを受け付けた際に行われる。ここで、コンテキストDB112が更新されていない場合ステップS1601:No、コンテキスト管理サーバ110は、ステップS1601に戻り、コンテキストDB112の更新を待つ。一方、コンテキストDB112が更新された場合ステップS1601:Yes、コンテキスト管理サーバ110は、更新されたコンテキストDB112のレコードに、コールバックIDの登録があるか否かを判定するステップS1602。ここで、コールバックIDの登録がない場合ステップS1602:No、コンテキスト管理サーバ110は、コールバック契機通知送信処理を終了する。一方、コールバックIDの登録がある場合ステップS1602:Yes、コンテキスト管理サーバ110は、登録されているコールバックIDに対応する監視コンテキストDB113の全レコードの条件が満たされたか否かを判定するステップS1603。ここで、満たされていない条件がある場合ステップS1603:No、コンテキスト管理サーバ110は、コールバック契機通知送信処理を終了する。一方、全レコードの条件が満たされている場合ステップS1603:Yes、コンテキスト管理サーバ110は、コールバック制御サーバ120に、コールバック契機通知を送信しステップS1604、コールバック契機通知送信処理を終了する。以上のステップS1601~ステップS1604の処理が、ステップS1302の処理に対応する処理である。これにより、コンテキスト管理サーバ110は、監視対象となる通信端末Tのコンテキストを監視し、通信端末Tが着信許可の状態になった場合に、コールバック制御サーバ120にコールバック契機通知を送信することができる。実施例2ここで、図17~図30を用いて、実施例2について説明する。実施例2は、通信制御装置100が、呼制御サーバ130により、着信側端末Rと発信側端末Sとの通信を制御している場合の実施例である。また、実施例2は、呼制御サーバ130が発信側端末Sからの呼を着信側端末Rへ着信させなかったことを検出することにより、通信制御装置100が発信側端末Sからの呼を着信側端末Rが受け付けなかったことを検出する場合の実施例である。実施例2では、呼の用件および緊急度を、発信者が発信側端末Sに入力するようにする。そして、通信制御装置100は、発信側端末Sから呼の用件および緊急度を受信することにより、呼の用件および緊急度を考慮したコールバック要求の送信を行う。実施例2では、呼の用件の一例として、会社において出張許可を求める伝票の承認を上司に要求するといった用件を例に挙げる。ただし、呼の用件および緊急度を、発信者が他のシステム202に入力するようになっている場合、通信制御装置100は、他のシステム202から呼の用件および緊急度を受信することにより、呼の用件および緊急度を考慮したコールバック要求の送信を行う。また、通信制御装置100が行うコールバック要求が不要になる場合が想定される。例えば、コールバック要求が送信される前に、発信者と着信者とが直に会って呼の用件が口頭により伝えられた場合である。そのため、実施例2では、通信制御装置100は、発信側端末Sからの要求により、コールバック要求を中止できるようにする。実施例2にかかる通信端末Tの画面表示例まず、図17を用いて、実施例2にかかる通信端末Tの画面表示例について説明する。図17は、実施例2にかかる通信端末Tの画面表示例を示す説明図である。具体的には、図17aには、呼の用件および緊急度を入力することができる発信側端末Sの画面表示例を示す。aに示すように、発信側端末Sの画面には、着信先電話番号を入力する部分と、呼の用件および緊急度を入力する部分と、が含まれている。この画面に発信者が入力した呼の用件および緊急度が、発信側端末Sや、通信制御装置100に通知されることになる。また、図17bには、呼の用件および緊急度を表示することができる着信側端末Rの画面表示例を示す。bに示すように、着信側端末Rの画面には、発信元の電話番号を表示する部分と、呼の用件および緊急度を表示する部分と、が含まれている。この画面が表示されることにより、着信者は、呼の用件および緊急度を確認して、着信許可または不許可を判断することができる。実施例2にかかるコンテキストDB112の記憶内容まず、図18を用いて、実施例2にかかるコンテキストDB112の記憶内容について説明する。実施例2でも、コンテキストDB112には、実施例1におけるコンテキストDB112と同様の内容が記憶されている。図18は、コンテキストDB112の記憶内容を示す説明図である。図18に示すように、コンテキスト管理サーバ110は、通信端末Tごとに、コンテキストDB112を有する。コンテキストDB112は、コンテキスト種別項目に対応付けて、値項目と、コールバックID項目と、を有し、通信端末Tからコンテキストを受信するごとにレコードを構成する。コンテキスト種別項目には、発信側端末Sまたは着信側端末Rのコンテキストの種別が記憶されている。具体的には、コンテキストの種別には、実施例1で示した場所、電話の他に、呼の用件の一例である伝票の承認が必要であるか否かを示す伝票承認がある。値項目には、コンテキストの種別に対応する状態が記憶されている。具体的には、コンテキストの種別の伝票承認に対応する値項目にはユーザAが記憶されている。ユーザAは、伝票の承認を申請した発信側端末Sの利用者のIDである。コールバックID項目には、コールバックを識別する識別子が記憶されている。この伝票情報は、例えば、発信側端末Sの利用者が電子伝票システムにおいて、着信側端末Rの利用者に対して伝票の承認を依頼すると、コンテキスト管理サーバ110に通知され、コンテキストDB112に記憶される。コールバック要求の中止に関する監視コンテキストを含む監視コンテキストDB113の記憶内容次に、図19を用いて、コールバック要求の中止に関する監視コンテキストを含む監視コンテキストDB113の記憶内容について説明する。実施例2では、コールバック要求を中止する場合があるため、監視コンテキストDB113にはコールバック要求の中止に関する監視コンテキストが記憶されている。図19は、コールバック要求の中止に関する監視コンテキストを含む監視コンテキストDB113の記憶内容を示す説明図である。図19に示すように、監視コンテキストDB113は、コールバックID項目に対応付けて、種別項目と、ユーザID項目と、コンテキスト種別項目と、値項目と、を有し、コールバック制御サーバ120からコールバック契機通知要求が通知されるごとにレコードを構成する。コールバックID項目には、コールバックを識別する識別子が記憶されている。種別項目には、コールバック要求の送信を実行する条件になるレコードであることを示す実行、または、コールバック要求の送信を中止する条件になるレコードであることを示す中止が記憶されている。ユーザID項目には、発信側端末Sまたは着信側端末Rの識別子が記憶されている。コンテキスト種別項目には、発信側端末Sまたは着信側端末Rのコンテキストの種別が記憶されている。値項目には、コンテキストの種別に対応する状態が記憶されている。呼の用件および緊急度を含む呼制御DB121の記憶内容次に、図20を用いて、呼の用件および緊急度を含む呼制御DB121の記憶内容について説明する。実施例2では、呼の用件および緊急度を考慮してコールバック要求の送信を行うため、呼制御DB121には、実施例1における呼制御DB121の記憶内容とともに、呼の用件および緊急度に関する条件が記憶されている。図20は、呼の用件および緊急度を含む呼制御DB121の記憶内容を示す説明図である。図20に示すように、呼制御DB121は、コンテキスト種別項目に対応付けて、値項目と、用件項目と、緊急度項目と、を有し、通信端末Tから呼制御条件を受信するごとにレコードを構成する。コンテキスト種別項目には、コンテキストの種別が記憶されている。具体的には、コンテキストの種別には、通信端末Tがある場所を示す種別である場所がある。値項目には、コンテキストの種別の状態が記憶されている。具体的には、コンテキストの種別場所の状態として、値項目には会議室が記憶されている。用件項目には、値項目が示す状態において、着信許可する呼の用件が記憶されている。例えば、用件項目には、顧客Xやが記憶されている。顧客Xは、顧客Xに関する用件の呼、または顧客Xからの呼であれば着信許可することを示す。は、ワイルドカードであり、用件にかかわらず着信許可することを示す。緊急度項目には、値項目が示す状態において、着信許可する緊急度が記憶されている。例えば、緊急度項目には、高やが記憶されている。高は、緊急度の高い呼であれば着信許可することを示す。は、ワイルドカードであり、緊急度にかかわらず着信許可することを示す。実施例2にかかる通信制御装置100による着信者へのコールバック要求の送信例1の内容次に、図21および図22を用いて、実施例2にかかる通信制御装置100による着信者へのコールバック要求の送信例1の内容について説明する。送信例1は、通信制御装置100が、着信側端末Rが着信許可の状態か否かに基づいて、コールバック要求を送信する例である。図21および図22は、実施例2にかかる通信制御装置100による着信者へのコールバック要求の送信例1の内容を示す説明図である。図21では、図1と同様に、発信者が有する発信側端末Sと、着信者が有する着信側端末Rと、通信制御装置100と、を含む通信システムを示す。通信制御装置100は、コンテキスト管理サーバ110と、コールバック制御サーバ120と、呼制御サーバ130と、を含む装置である。そして、通信制御装置100は、呼制御サーバ130により、発信側端末Sと着信側端末Rとの通信を制御する。図21において、1まず、発信側端末Sは、着信側端末Rへの呼を発信する。着信側端末Rへの呼は、まず、通信制御装置100に受信される。2ここで、着信側端末Rは、着信側端末Rのコンテキストを、予め通信制御装置100に通知している。そのため、通信制御装置100では、着信側端末Rのコンテキストとして、着信側端末Rの場所が役員会議室であると記憶されている。3そして、通信制御装置100は、着信側端末Rのコンテキストと、呼制御DB121と、に基づいて、着信側端末Rが着信許可の状態であるか否かを判定する。そして、着信側端末Rが着信不許可の状態であれば、発信側端末Sからの呼を着信側端末Rに着信させない。通信制御装置100は、発信側端末Sからの呼を着信側端末Rに着信させなかった場合、コールバック要求の送信の可否の判定を開始し、着信側端末Rからのコンテキストの通知を待つ。図22において、1ここで、着信側端末Rが、役員会議室から休憩室へ移動した場合を想定する。2着信側端末Rは、休憩室に移動すると、着信側端末Rのコンテキストを、通信制御装置100に通知する。ここでは、コンテキストは、着信側端末Rの場所である。3次に、通信制御装置100は、着信側端末Rのコンテキストの通知を受けると、予め保持しておいた監視コンテキストDB113を参照して、着信側端末Rが着信許可の状態であるか否かを判定する。4着信側端末Rが着信許可の状態である場合、通信制御装置100は、コールバックDB122を参照して、コールバック要求を着信側端末Rと発信側端末Sとに送信する。ここで、コールバック要求は、呼制御サーバ130からの着信要求である。着信側端末Rと発信側端末Sとがそれぞれ、呼制御サーバ130からの着信要求を許可することにより、着信側端末Rと発信側端末Sとの通話が開始される。このように、通信制御装置100は、着信側端末Rのコンテキストを取得し、自動的に着信側端末Rが着信許可の状態になったか否かを判定する。そして、通信制御装置100は、着信側端末Rが着信許可の状態になったことが判定された場合にのみ、着信側端末Rにコールバック要求を送信する。そのため、着信側端末Rの利用者が、コールバックが必要であることを憶えておかなくてよくなり、着信側端末Rの利用者の手間を削減できる。また、着信側端末Rの利用者は、着信不許可の状態であるにもかかわらず、コールバック要求を受けるといった不都合を被ることはない。実施例2にかかる通信制御装置100による着信者へのコールバック要求の送信例2の内容次に、図23を用いて、実施例2にかかる通信制御装置100による着信者へのコールバック要求の送信例2の内容について説明する。送信例2は、通信制御装置100が、着信側端末Rが着信許可の状態か否かと、発信側端末Sが着信許可の状態か否かと、に基づいて、コールバック要求を送信する例である。図23は、実施例2にかかる通信制御装置100による着信者へのコールバック要求の送信例2の内容を示す説明図である。図23では、図1と同様に、発信者が有する発信側端末Sと、着信者が有する着信側端末Rと、通信制御装置100と、を含む通信システムを示す。通信制御装置100は、コンテキスト管理サーバ110と、コールバック制御サーバ120と、呼制御サーバ130と、を含む装置である。そして、通信制御装置100は、呼制御サーバ130により、発信側端末Sと着信側端末Rとの通信を制御する。図23において、通信制御装置100は、図21と同様に発信側端末Sからの呼を着信側端末Rに着信させなかった場合、コールバック要求の送信の可否の判定を開始し、着信側端末Rおよび発信側端末Sのコンテキストを監視する。1ここで、着信側端末Rが、役員会議室から休憩室へ移動した場合を想定する。2着信側端末Rは、休憩室に移動すると、着信側端末Rのコンテキストを、通信制御装置100に通知する。ここでは、コンテキストは、着信側端末Rの場所である。3次に、通信制御装置100は、着信側端末Rのコンテキストの通知を受けると、予め保持しておいた監視コンテキストDB113を参照して、着信側端末Rが着信許可の状態であるか否かを判定する。また、通信制御装置100は、コンテキストDB112の発信側端末Sのコンテキストから、発信側端末Sが着信拒否の状態であるか否かを判定する。4着信側端末Rと発信側端末Sとの双方が着信許可の状態である場合、通信制御装置100は、コールバックDB122を参照して、コールバック要求を着信側端末Rと発信側端末Sとに送信する。ここで、コールバック要求は、呼制御サーバ130からの着信要求である。着信側端末Rと発信側端末Sとがそれぞれ、呼制御サーバ130からの着信要求を許可することにより、着信側端末Rと発信側端末Sとの通話が開始される。このように、通信制御装置100は、着信側端末Rのコンテキストを取得し、自動的に着信側端末Rが着信許可の状態になったか否かを判定する。そして、通信制御装置100は、着信側端末Rが着信許可の状態になったことが判定された場合にのみ、着信側端末Rにコールバック要求を送信する。そのため、着信側端末Rの利用者が、コールバックが必要であることを憶えておかなくてよくなり、着信側端末Rの利用者の手間を削減できる。また、着信側端末Rの利用者は、着信不許可の状態であるにもかかわらず、コールバック要求を受けるといった不都合を被ることはない。実施例2にかかる通信制御装置100内における各サーバの具体的な通信内容ここで、図24および図25を用いて、図21および図22に示した実施例2にかかる通信制御装置100内における各サーバの具体的な通信内容について説明する。実施例2における発信側端末Sから呼が発信されるときの各サーバの通信内容の詳細まず、図24および図25を用いて、実施例2における発信側端末Sから呼が発信されるときの各サーバの通信内容の詳細について説明する。図24および図25は、実施例2における発信側端末Sから呼が発信されるときの各サーバの通信内容の詳細を示すシーケンス図である。図24において、まず、着信側端末Rは、呼制御条件をコールバック制御サーバ120に送信するステップS2401。コールバック制御サーバ120は、受信した呼制御条件に基づいて、呼制御DB121を更新する。次に、着信側端末Rは、自端末の状態を示すコンテキストをコンテキスト管理サーバ110に通知するステップS2402。なお、コンテキスト管理サーバ110は、受信したコンテキストに基づいて、コンテキストDB112を更新する。例えば、コンテキスト管理サーバ110は、コンテキストに含まれるSSIDから、場所DB111に基づいて、通信端末Tの場所を特定して、コンテキストDB112を更新する。ここで、発信者が着信者に承認依頼しようとする。この承認依頼は、例えば、図示しない電子伝票システム他のシステム202上で、発信者が電子伝票を起票し、その承認を着信者に依頼することで行われる。この電子伝票の承認が着信者に依頼されると、図示しない電子伝票システムからコンテキスト管理サーバ110に、発信者が着信者に電子伝票の承認依頼を行ったことが通知される。コンテキスト管理サーバ110が、着信側端末RのコンテキストDB112のコンテキスト種別が伝票承認である値として、当該伝票の承認依頼者である発信者のIDユーザAを登録する。そして、発信側端末Sにおいて、発信者は着信側端末Rへの承認依頼の用件と緊急度とを設定するステップS2403。そして、着信側端末Rへの承認依頼の用件と緊急度とを含む呼が、呼制御サーバ130に発信されるステップS2404。ここでは、発信側端末Sから呼制御サーバ130に、直接、用件と緊急度とが通知されている。しかし、発信側端末Sから上述した電子伝票システム他のシステム202に呼の用件と緊急度とが登録され、通信制御装置100が当該システムを参照することにより、呼の用件と緊急度とを取得するようにしてもよい。次に、呼制御サーバ130は、コンテキスト管理サーバ110にコンテキストを通知するステップS2405。コンテキスト管理サーバ110は、受信したコンテキストに基づいて、コンテキストDB112を更新する。そして、呼制御サーバ130は、コールバック制御サーバ120に着信制御要求を通知するステップS2406。着信制御要求を通知されたコールバック制御サーバ120は、コンテキスト管理サーバ110のコンテキストDB112を参照しステップS2407、呼制御DB121を参照しステップS2408、着信側端末Rが着信許可の状態か否かを判定するステップS2409。ここでは、コールバック制御サーバ120が、着信側端末Rが着信不許可の状態であると判定した場合を想定する。図25において、コールバック制御サーバ120は、呼制御サーバ130に着信制御応答を通知するステップS2501。着信制御応答には、着信側端末Rが着信不許可の状態であることを示す情報が含まれている。着信制御応答を受信した呼制御サーバ130は、発信側端末Sに、切断要求とコールバック登録通知とを通知するステップS2502。また、呼制御サーバ130は、コンテキスト管理サーバ110にコンテキストを通知するステップS2503。コンテキスト管理サーバ110は、受信したコンテキストに基づいて、コンテキストDB112を更新する。そして、コールバック制御サーバ120は、着信側端末Rが着信不許可の状態であると判定した場合、コールバック要求の送信の可否の判定を開始するステップS2504。次に、コールバック制御サーバ120は、通信端末Tに関する呼制御DB121を参照するステップS2505。そして、コールバック制御サーバ120は、コンテキスト管理サーバ110に、コールバック契機通知要求を通知するステップS2506。コールバック契機通知要求は、コンテキスト管理サーバ110に着信側端末Rのコンテキストを監視させ、着信許可の状態になった際に、コールバック制御サーバ120へ通知させる要求である。次に、コールバック制御サーバ120は、コールバック情報をコールバックDB122に登録するステップS2507。コールバック情報は、例えば、コールバックの際に使用する発信側端末Sの電話番号およびIPアドレスである。これにより、コンテキスト管理サーバ110に、着信側端末Rのコンテキストの監視を開始させて、コールバック要求の送信のトリガを発生させることができる。実施例2におけるコールバック制御サーバ120によりコールバック要求が送信されるときの各サーバの通信内容の詳細次に、図26を用いて、実施例2におけるコールバック制御サーバ120によりコールバック要求が送信されるときの各サーバの通信内容の詳細について説明する。ここで、図25においてコンテキスト管理サーバ110にコンテキストを監視されている着信側端末Rが移動を行い、着信側端末Rのコンテキストが着信許可の状態に変化した場合を想定する。図26は、実施例2におけるコールバック制御サーバ120によりコールバック要求が送信されるときの各サーバの通信内容の詳細を示すシーケンス図である。まず、着信側端末Rは、移動によりコンテキストが変化すると、自端末の状態を示すコンテキストをコンテキスト管理サーバ110に通知するステップS2601。コンテキストの通知を受けたコンテキスト管理サーバ110は、監視コンテキストDB113を参照して、着信側端末Rが着信許可の状態になったか否かを判定する。そして、コンテキスト管理サーバ110は、着信側端末Rが着信許可の状態であれば、コールバック契機通知をコールバック制御サーバ120に通知するステップS2602。コールバック契機通知を受けたコールバック制御サーバ120は、コールバックDB122を参照しステップS2603、コールバック制御要求を呼制御サーバ130に送信するステップS2604。コールバック制御要求は、呼制御サーバ130に、発信側端末Sと着信側端末Rとに対して、いわゆる第三者呼制御を実行させる要求である。次に、呼制御サーバ130は、発信側端末Sと着信側端末Rとに着信要求を送信するステップS2605。そして、発信側端末Sと着信側端末Rに通話させる。次に、呼制御サーバ130は、コンテキスト管理サーバ110にコンテキストを通知するステップS2606。コンテキスト管理サーバ110は、受信したコンテキストに基づいて、コンテキストDB112を更新する。これにより、着信者が自らコールバックが必要であることを憶えておく必要なく、通信制御装置100により自動的に着信側端末Rが着信許可の状態か否かが判定される。そして、通信制御装置100は、着信側端末Rが着信許可の状態のときのみコールバック要求を送信する。そのため、着信者が、コールバックが必要であることを憶えておく手間を削減できる。また、着信側端末Rが着信不許可の状態であるにもかかわらず、コールバック要求が受信されるといった不都合はなく、着信側端末Rの利便性を向上できる。実施例2におけるコールバック要求の取消を行うときの各サーバの通信内容の詳細次に、図27を用いて、実施例2におけるコールバック要求の取消を行うときの各サーバの通信内容の詳細について説明する。図27は、実施例2におけるコールバック要求の取消を行うときの各サーバの通信内容の詳細を示すシーケンス図である。まず、発信側端末Sにおいて、発信した呼の用件が解決された場合、コールバック要求の取消が入力されるステップS2701。そして、発信側端末Sは、コールバック要求の取消があったことを示すコンテキストを、コンテキスト管理サーバ110に送信するステップS2702。これは例えば、発信側端末Sによって、図示しない電子伝票システム他のシステム202で先になされた着信者に対する伝票承認依頼が取り消されることによって行われてもよい。この場合、電子伝票システムで承認依頼が取り消されると、その旨が電子伝票システムからコンテキスト管理サーバ110に通知される。そして、コンテキスト管理サーバ110により、コンテキストDB112の着信側端末Rのコンテキスト種別が伝票承認である値項目に登録済みの発信者の情報ユーザAが削除される。コンテキスト管理サーバ110は、コンテキストDB112を更新し、コールバックの中止を要求するコールバック契機通知をコールバック制御サーバ120に送信するステップS2703。そして、コールバック制御サーバ120は、コールバックDB122のレコードを消去するステップS2704。これにより、不要なコールバック要求が送信されることがなくなる。実施例2におけるコールバック制御サーバ120の着信制御処理の処理内容の詳細次に、図28を用いて、実施例2におけるコールバック制御サーバ120の着信制御処理の処理内容の詳細について説明する。図28では、図24および図25において、コールバック制御サーバ120が行った着信制御処理の処理内容について説明する。図28は、実施例2におけるコールバック制御サーバ120の着信制御処理の処理内容の詳細を示すフローチャートである。まず、コールバック制御サーバ120は、着信制御要求を受信したか否かを判定するステップS2801。ここで、着信制御要求を受信していない場合ステップS2801:No、コールバック制御サーバ120は、ステップS2801に戻り、着信制御要求の受信を待つ。一方、着信制御要求を受信した場合ステップS2801:Yes、コールバック制御サーバ120は、着信側端末Rのコンテキストを取得するステップS2802。次に、コールバック制御サーバ120は、取得したコンテキストに対応する呼制御DB121のレコードを参照するステップS2803。そして、コールバック制御サーバ120は、参照した呼制御DB121のレコードに基づいて、着信側端末Rが着信許可の状態であるか否かを判定するステップS2804。ここで、着信側端末Rが着信許可の状態である場合ステップS2804:Yes、コールバック制御サーバ120は、着信側端末Rが着信許可の状態であることを示す着信制御応答を、呼制御サーバ130に送信するステップS2805。そして、コールバック制御サーバ120は、着信制御処理を終了する。一方、着信側端末Rが着信許可の状態でない場合ステップS2804:No、コールバック制御サーバ120は、着信側端末Rが着信不許可の状態であることを示す着信制御応答を、呼制御サーバ130に送信するステップS2806。次に、コールバック制御サーバ120は、コールバック制御処理を開始するイベントを発生するステップS2807。そして、コールバック制御サーバ120は、着信制御処理を終了する。以上のステップS2801~ステップS2807の処理が、ステップS2406~ステップS2409およびステップS2501~ステップS2502の処理に対応する処理である。これにより、通信制御装置100が、着信側端末Rに呼を着信させるか否かを判定できるため、着信者が自ら着信許可の状態か否かを判定し、着信側端末Rを操作して着信を拒否する手間を削減することができる。実施例2におけるコールバック制御サーバ120のコールバック制御処理の処理内容の詳細次に、図29を用いて、実施例2におけるコールバック制御サーバ120のコールバック制御処理の処理内容の詳細について説明する。図29では、図25~図27において、コールバック制御サーバ120が行ったコールバック制御処理の処理内容について説明する。図29は、実施例2におけるコールバック制御サーバ120のコールバック制御処理の処理内容の詳細を示すフローチャートである。まず、コールバック制御サーバ120は、コールバック制御処理を開始するイベントが発生すると、コールバック制御処理を開始するステップS2901。次に、コールバック制御サーバ120は、呼制御DB121を参照して、着信側端末Rの呼制御条件を取得するステップS2902。次に、コールバック制御サーバ120は、取得した呼制御条件に基づいて、着信側端末Rの着信許可の状態に対応する監視コンテキストを生成するステップS2903。そして、コールバック制御サーバ120は、コールバック中止条件を生成するステップS2904。次に、コールバック制御サーバ120は、生成した監視コンテキストとコールバック中止条件とを含むコールバック契機通知を、コンテキスト管理サーバ110に送信するステップS2905。そして、コールバック制御サーバ120は、コールバックDB122にコールバック情報を登録するステップS2906。コールバック契機通知の受信を待つ。以上のステップS2901~ステップS2906の処理が、ステップS2504~ステップS2507の処理に対応する処理である。次に、コールバック制御サーバ120は、コンテキスト管理サーバ110からコールバック契機通知を受信したか否かを判定するステップS2907。ここで、コールバック契機通知を受信していない場合ステップS2907:No、コールバック制御サーバ120は、ステップS2907に戻り、コールバック契機通知の受信を待つ。一方、コールバック契機通知を受信した場合ステップS2907:Yes、コールバック制御サーバ120は、コールバック契機通知の内容を判定するステップS2908。ここで、コールバック契機通知の内容がコールバックの実行であればステップS2908:コールバック実行、コールバック制御サーバ120は、コールバックDB122から情報を取得するステップS2909。そして、コールバック制御サーバ120は、コールバック要求を送信してステップS2910、コールバック制御処理を終了する。以上のステップS2907~ステップS2910の処理が、ステップS2601~ステップS2604の処理に対応する処理である。一方、コールバック契機通知の内容がコールバックの中止であればステップS2908:コールバック中止、コールバック制御サーバ120は、コールバックDB122から情報を消去するステップS2911。そして、コールバック制御サーバ120は、コールバック制御処理を終了する。以上のステップS2907~ステップS2911の処理が、ステップS2701~ステップS2704の処理に対応する処理である。これにより、通信制御装置100は、着信側端末Rが着信許可の状態になった場合にのみ、コールバック要求を送信することができる。着信者が、コールバックが必要であることを憶えておく手間を削減できる。また、着信側端末Rが着信不許可の状態であるにもかかわらず、コールバック要求が受信されるといった不都合はなく、着信側端末Rの利便性を向上できる。また、不要になったコールバック要求を取り消すことにより、着信側端末Rの利便性を向上できる。実施例2におけるコンテキスト管理サーバ110の監視コンテキスト登録処理の処理内容の詳細次に、図30を用いて、実施例2におけるコンテキスト管理サーバ110の監視コンテキスト登録処理の処理内容の詳細について説明する。図30は、実施例2におけるコンテキスト管理サーバ110の監視コンテキスト登録処理の処理内容の詳細を示すフローチャートである。まず、コンテキスト管理サーバ110は、コールバック制御サーバ120から、コールバック契機通知要求を受信したか否かを判定するステップS3001。ここで、コールバック契機通知要求を受信していない場合ステップS3001:No、コンテキスト管理サーバ110は、ステップS3001に戻り、コールバック契機通知要求の受信を待つ。一方、コールバック契機通知要求を受信した場合ステップS3001:Yes、コンテキスト管理サーバ110は、コールバック契機通知要求から監視コンテキストを抽出して、監視コンテキストDB113に登録するステップS3002。そして、コンテキスト管理サーバ110は、監視コンテキスト登録処理を終了する。これにより、コンテキスト管理サーバ110は、通信端末Tの着信許可の状態に対応する監視コンテキストを監視コンテキストDB113に登録し、通信端末Tが着信許可の状態になったか否かを監視できるようになる。実施例2におけるコンテキスト管理サーバ110のコールバック契機通知送信処理の処理内容の詳細次に、図31を用いて、実施例2におけるコンテキスト管理サーバ110のコールバック契機通知送信処理の処理内容の詳細について説明する。図31は、実施例2におけるコンテキスト管理サーバ110のコールバック契機通知送信処理の処理内容の詳細を示すフローチャートである。まず、コンテキスト管理サーバ110は、コンテキストDB112が更新されたか否かを判定するステップS3101。例えば、コンテキストDB112の更新は、通信端末Tからのコンテキストを受け付けた際に行われる。ここで、コンテキストDBが更新されていない場合ステップS3101:No、コンテキスト管理サーバ110は、ステップS3101に戻り、コンテキストDBの更新を待つ。一方、コンテキストDBが更新された場合ステップS3101:Yes、コンテキスト管理サーバ110は、更新されたコンテキストDB112のレコードに、コールバックIDの登録があるか否かを判定するステップS3102。ここで、コールバックIDの登録がない場合ステップS3102:No、コンテキスト管理サーバ110は、コールバック契機通知送信処理を終了する。一方、コールバックIDの登録がある場合ステップS3102:Yes、コンテキスト管理サーバ110は、登録されているコールバックIDに対応する監視コンテキストDB113の種別が実行の全レコードの条件が満たされたか否かを判定するステップS3103。ここで、全レコードの条件が満たされている場合ステップS3103:Yes、コンテキスト管理サーバ110は、コールバック制御サーバ120に、コールバック実行を示すコールバック契機通知を送信しステップS3104、コールバック契機通知送信処理を終了する。一方、満たされていない条件がある場合ステップS3103:No、コンテキスト管理サーバ110は、監視コンテキストの種別が中止の全条件が満たされたか否かを判定するステップS3105。ここで、全条件が満たされている場合ステップS3105:Yes、コンテキスト管理サーバ110は、コールバック制御サーバ120に、コールバック中止を示すコールバック契機通知を送信しステップS3106、コールバック契機通知送信処理を終了する。一方、満たされていない条件がある場合ステップS3105:No、コンテキスト管理サーバ110は、コールバック契機通知送信処理を終了する。これにより、コンテキスト管理サーバ110は、監視対象となる通信端末Tのコンテキストを監視し、通信端末Tが着信許可の状態になった場合に、コールバック制御サーバ120にコールバック契機通知を送信することができる。以上説明したように、通信制御方法、通信制御装置100、および通信制御システムによれば、着信側端末Rが呼を受け付けなかった場合に、着信側端末Rのコンテキストを監視し、着信側端末Rが着信許可の状態になったことを判断する。そして、通信制御装置100は、着信側端末Rが着信許可の状態になった場合にのみコールバック要求を送信する。これにより、着信側端末Rの利用者が、コールバックが必要であることを憶えておかなくてよくなり、着信側端末Rの利用者の手間を削減できる。また、着信側端末Rが着信許可の状態のときのみコールバックが行われるようになり、着信側端末Rの利便性を向上させることができる。また、通信制御装置100は、着信側端末Rからの着信拒否イベントがあったことの通知を受けることにより、着信側端末Rが着信許可の状態になったことの判断を開始して、コールバック要求の送信を行うことができる。また、通信制御装置100が呼制御サーバ130を備え、発信側端末Sと着信側端末Rとの通信を制御している場合は、呼制御サーバ130が発生させた着信拒否イベントを検出することにより、着信側端末Rが着信許可の状態になったことの判断を開始して、コールバック要求の送信を行うことができる。また、通信制御装置100は、着信側端末Rが着信許可の状態になった場合、かつ、発信側端末Sが着信許可の状態になった場合、にのみコールバック要求を送信するようにして、通信端末Tの利便性を向上させることができる。また、通信制御装置100は、通信相手ごとに異なる着信許可の状態を設定することにより、例えば、顧客に関する要件で緊急度の高い呼や顧客の有する発信側端末Sに対しては着信許可の状態と判断し、同僚の有する発信側端末Sに対しては着信不許可の状態と判断することができる。そのため、より通信端末Tの利便性を向上させることができる。また、通信制御装置100は、コールバック要求の取消し要求を受信して、コールバック要求の送信を行わないようにするため、不要なコールバック要求を行わない。そのため、発信側端末Sの利用者と、着信側端末Rの利用者と、は不要なコールバック要求に対応するといった無駄な手間を掛けることがなくなる。なお、本実施の形態で説明した通信制御方法は、予め用意されたプログラムをパーソナルコンピュータやワークステーション等のコンピュータで実行することにより実現することができる。本通信制御プログラムは、ハードディスク、フレキシブルディスク、CD-ROM、MO、DVD等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。また本通信制御プログラムは、インターネット等のネットワークを介して配布してもよい。上述した実施の形態に関し、さらに以下の付記を開示する。付記1コンピュータが、第1の端末からの発信を第2の端末が受け付けなかったことを検出する検出工程と、前記検出工程によって前記第1の端末からの発信を前記第2の端末が受け付けなかったことが検出された場合、着信許可または不許可を示すコンテキストを端末ごとに記憶する記憶手段を参照することにより、前記第2の端末が着信許可の状態であるかを判断する判断工程と、前記判断工程によって着信許可の状態であると判断された場合、前記第1の端末へのコールバック要求を前記第2の端末に送信する送信工程と、を実行することを特徴とする通信制御方法。付記2前記検出工程は、前記第1の端末からの発信について前記第2の端末で着信拒否の操作が行われたことを検出することを特徴とする付記1に記載の通信制御方法。付記3前記検出工程は、前記第1の端末から前記第2の端末へ発信されたことが検出されたときに、前記記憶手段を参照することにより、前記第2の端末が着信不許可の状態であると判断された場合、前記第1の端末からの発信を前記第2の端末が受け付けなかったことを検出することを特徴とする付記1に記載の通信制御方法。付記4前記判断工程は、前記検出工程によって前記第1の端末からの発信を前記第2の端末が受け付けなかったことが検出された場合、前記記憶手段を参照することにより、前記第1の端末からの発信について前記第2の端末が着信許可の状態であるかを判断することを特徴とする付記1~3のいずれか一つに記載の通信制御方法。付記5前記判断工程は、前記検出工程によって前記第1の端末からの発信を前記第2の端末が受け付けなかったことが検出された場合、前記記憶手段を参照することにより、前記第1および第2の端末が着信許可の状態であるかを判断することを特徴とする付記1~3のいずれか一つに記載の通信制御方法。付記6前記判断工程は、前記検出工程によって前記第1の端末からの発信を前記第2の端末が受け付けなかったことが検出された場合、前記記憶手段を参照することにより、前記第1の端末からの発信について前記第2の端末が着信許可の状態であるかを判断し、かつ、前記第1の端末が着信許可の状態であるかを判断することを特徴とする付記1~3のいずれか一つに記載の通信制御方法。付記7前記判断工程は、前記検出工程によって前記第1の端末からの発信を前記第2の端末が受け付けなかったことが検出された場合、前記記憶手段を参照することにより、前記第1の端末からの発信について前記第2の端末が着信許可の状態であるかを判断し、かつ、前記第2の端末からの発信について前記第1の端末が着信許可の状態であるかを判断することを特徴とする付記1~3のいずれか一つに記載の通信制御方法。付記8前記検出工程は、前記第1の端末から前記コールバック要求の取消し要求を検出し、前記送信工程は、前記検出工程によって前記取消し要求が検出された場合、前記コールバック要求を前記第2の端末に送信しないことを特徴とする付記1~7のいずれか一つに記載の通信制御方法。付記9前記送信工程は、前記第1の端末を識別する識別子を含む前記第1の端末へのコールバック要求を前記第2の端末に送信することを特徴とする付記1~8のいずれか一つに記載の通信制御方法。付記10前記送信工程は、前記第1の端末への発信を実行するソフトウェアを含む前記第1の端末へのコールバック要求を前記第2の端末に送信することを特徴とする付記1~8のいずれか一つに記載の通信制御方法。付記11前記送信工程は、前記第1の端末へのコールバック要求を前記第1の端末および前記第2の端末に送信することを特徴とする付記1~8のいずれか一つに記載の通信制御方法。付記12着信許可または不許可を示すコンテキストを端末ごとに記憶する記憶手段と、第1の端末からの発信を第2の端末が受け付けなかったことを検出する検出手段と、前記検出手段によって前記第1の端末からの発信を前記第2の端末が受け付けなかったことが検出された場合、前記記憶手段を参照することにより、前記第2の端末が着信許可の状態であるかを判断する判断手段と、前記判断手段によって着信許可の状態であると判断された場合、前記第1の端末へのコールバック要求を前記第2の端末に送信する送信手段と、を備えることを特徴とする通信制御装置。付記13端末間の発着信を制御する第1の装置と、発信元端末へのコールバックを制御する第2の装置と、が接続された通信制御システムであって、前記第2の装置は、着信許可または不許可を示すコンテキストを端末ごとに記憶する記憶手段と、第1の端末からの発信を第2の端末が受け付けなかったことを検出する検出手段と、前記検出手段によって前記第1の端末からの発信を前記第2の端末が受け付けなかったことが検出された場合、前記記憶手段を参照することにより、前記第2の端末が着信許可の状態であるかを判断する判断手段と、前記判断手段によって着信許可の状態であると判断された場合、前記第1の端末へのコールバック要求を前記第2の端末に送信する送信手段と、を備え、前記第1の装置は、前記第1の端末から前記第2の端末へ発信されたことを前記第2の装置に通知することを特徴とする通信制御システム。付記14端末間の発着信を制御する第1の装置と、発信元端末へのコールバックを制御する第2の装置と、が接続された通信制御システムであって、前記第2の装置は、着信許可または不許可を示すコンテキストを端末ごとに記憶する記憶手段と、第1の端末からの発信を第2の端末が受け付けなかったことを検出する検出手段と、前記検出手段によって前記第1の端末からの発信を前記第2の端末が受け付けなかったことが検出された場合、前記記憶手段を参照することにより、前記第2の端末が着信許可の状態であるかを判断する判断手段と、前記判断手段によって着信許可の状態であると判断された場合、前記第1の端末へのコールバック要求を前記第1の装置に送信する送信手段と、を備え、前記第1の装置は、前記第1の端末から前記第2の端末へ発信されたことを前記第2の装置に通知し、前記送信手段からの前記コールバック要求を前記第2の装置に通知することを特徴とする通信制御システム。