通信端末
【課題】通信端末において、通話連絡したい相手端末の状態変化を利用者が常に確認しなくてもその端末状態が変化したことを把握できるようにすること。
【解決手段】通信端末は、同じグループに属する他のメンバ端末の状態を発呼前にサーバーから取得する。発呼したいメンバ端末の状態がビジー状態である端末に対する発呼指示がなされると、通信端末は、レディー状態になるまでそのメンバ端末の状態の監視を続け、その端末状態がレディー状態に変化した時点でパターンＢによりその旨を通知する。上記メンバ端末がレディー状態に遷移した旨を示すパターンＢでの通知中に通話開始操作がなされると、通信端末は、そのメンバ端末に発呼する。また、パターンＢでの通知を行なっている間、再度、上記メンバ端末がレディー状態からビジー状態へと遷移しないか否かの監視を続け、再びビジー状態に遷移した際には、通信端末は、パターンＣによりその旨を通知する。
【解決手段】通信端末は、同じグループに属する他のメンバ端末の状態を発呼前にサーバーから取得する。発呼したいメンバ端末の状態がビジー状態である端末に対する発呼指示がなされると、通信端末は、レディー状態になるまでそのメンバ端末の状態の監視を続け、その端末状態がレディー状態に変化した時点でパターンＢによりその旨を通知する。上記メンバ端末がレディー状態に遷移した旨を示すパターンＢでの通知中に通話開始操作がなされると、通信端末は、そのメンバ端末に発呼する。また、パターンＢでの通知を行なっている間、再度、上記メンバ端末がレディー状態からビジー状態へと遷移しないか否かの監視を続け、再びビジー状態に遷移した際には、通信端末は、パターンＣによりその旨を通知する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通話通信機能を有する通信端末に関する。
【背景技術】
【０００２】
現在では、携帯電話及びＰＨＳ（Ｐｅｒｓｏｎａｌ Ｈａｎｄｙｐｈｏｎｅ Ｓｙｓｔｅｍ）等のような通話通信機能を有する通信端末による移動体通信は、広く一般に普及している。
【０００３】
かかる通信端末による移動体通信における通話通信処理においては、利用者のキー操作又はボタン操作により通話通信先の端末（相手端末）側の電話番号が特定された後に発呼処理が開始される。
【０００４】
上記発呼中に回線接続の失敗が生じると、その旨を通知するために第１の特定音が発せられ、正常な発呼処理により呼出状態に至ると、その旨を通知するために第１の特定音とは異なる態様の第２の特定音が発せられ、それによって利用者が発呼から通話通信接続状態への遷移状況を認識できるようにした通信端末がある。
【０００５】
このような構成の通信端末に対しては、種々の工夫がなされている。例えば、特許文献１に開示されている通信端末では、正常に発呼処理が進行して呼出状態に至った場合には、その旨を利用者に通知するために上記第２の特定音の出力と共に第１のパターンで振動を発生させ、発呼エラーが発生して呼出ができない場合には、その旨を利用者に通知するために上記第１の特定音の出力と共に第１のパターンとは異なる第２のパターンで振動を発生させる。
【０００６】
近年では、通信端末として、通話通信機能に加えてメール通信機能を有することが一般化している。このメール通信機能を備えた通信端末に関しては、その高機能化に伴い、同一のメール機能を備えた端末同士であれば、いわゆる絵文字及びキャラクタ文字等の特殊な文字のデータの送受を互いに行なうことができる。
【０００７】
このような構成の通信端末に対しても、種々の工夫がなされている。例えば、特許文献２に開示された通信端末では、メール送信先端末に対して発呼処理を行ない、メール送信先端末との接続に成功した場合には、その旨を利用者に通知するために第１のパターンで振動の発生及び視覚的な表示が行なわれる。メール送信先端末との接続に失敗した場合には、その旨を利用者に通知するために第１のパターンとは異なる第２のパターンで振動の発生及び視覚的な表示が行なわれる。メール送信先端末がメールの受信に成功した場合には、その旨を利用者に通知するために第１及び第２のパターンとは異なる第３のパターンで振動の発生及び視覚的な表示が行なわれる。メール送信先端末がメールの受信に失敗した場合には、その旨を利用者に通知するために第１〜第３のパターンとは異なる第４のパターンで振動の発生及び視覚的な表示が行なわれる。なお、視覚的な表示には、ＬＣＤ（Ｌｉｑｕｉｄ Ｃｒｙｓｔａｌ Ｄｉｓｐｌａｙ）による表示又はＬＥＤ（Ｌｉｇｈｔ Ｅｍｉｔｔｉｎｇ Ｄｉｏｄｅ）の発光が含まれる。
【特許文献１】特開平１０−２３５４５号公報
【特許文献２】特開２０００−２７０３５５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
上記特許文献１に係る通信端末では、特に、相手端末との通話通信接続が確立するか否かに応じてその通知パターンを変えることによって、通話通信接続の可否が利用者に通知される。つまり、発呼中に相手端末側でオフフック操作等がなされて当該発呼中の相手端末からの応答信号を検出するか否かを基に通知パターンの選択がなされる。
【０００９】
しかしながら、相手端末の状態の通知は発呼した後に行われることから、発呼側端末は、相手端末からの応答を待っている間、他の端末との間で通話ができない。
【００１０】
また、通信端末が、例えば、ＴＶ又は音楽の視聴及びゲーム等を楽しめる、通信機能と無関係なアプリケーション機能を付属的に有している場合には、この通話に影響しないアプリケーション機能を稼動させて、相手端末からの応答があるまで、又は所定の時間経過するまでの空き時間を有効に活用しようとする、利用者も少なくはないとも考えられる。ところが、相手端末からの応答があった旨を示す通知があったときに、常識的には直ちに電話に出ないと相手に失礼である等と考える利用者が多く、実質上、呼出中には、いつでも通話を開始できる状態とせざるを得ないので、結果的に上記端末の付属的なアプリケーション機能を利用できないことになる。
【００１１】
他方、上記特許文献２に係る通信端末では、特許文献１記載の技術と同様に、相手端末の状態通知は、発呼態様としてメールを送信するという、自分が起こしたアクションに対して、メールを受信した又は読んだこと等を示す相手端末からの応答信号を検出するか否かに応じてその通知パターンを変更するように構成されている。つまり、メール送信先でのメール受信の検出結果を基に通知パターンの選択が行なわれる。
【００１２】
そのため、発呼側端末の利用者は、自身が起こした過去のアクションに対して相手先が応答したかどうかによって、以降のアクション（即ち、端末の利用方法）を決めざるを得ない。具体的には、利用者自身がメール送信したことに対して、文章では表現し難いメッセージを電話で伝えるか否かの判断基準を得たりするのには有効ではあるものの、このタイミングが電話連絡しようとする相手と電話連絡を取りたい自分との両者間で必ずしも一致するとは限らない。そのため、互いに何回も電話をかけ合うことになり、結果的に無駄に時間を消費してしまうことも多々ある。
【００１３】
すなわち、両特許文献１及び２に記載の技術では、通信相手の端末の状態が常時把握できるが、例えば、相手端末が圏外又は電源オフの状態から通常状態に変化する等して当該相手端末の状態が変化したとしてもその旨が通知されない。そのため、利用者は、自分で常に相手端末の状態の変化を確認しなければならない。その結果、相手端末が通話通信可能な状態になっても利用者が気付かなかった場合には、相手端末への通話連絡が遅れてしまうことになる。
【００１４】
本発明は、上記技術的課題に鑑みなされたもので、通話連絡したい相手端末の状態の変化を利用者が常に確認しなくても当該相手端末の状態が変化したことを把握し得る通信端末の提供を目的とする。
【課題を解決するための手段】
【００１５】
上記目的を達成するため、本発明に係る通信端末は、特定端末との間での通話通信を可能とするための通信手段と、通信手段を介して通話通信可能な特定端末の状態を取得するための端末状態取得手段と、特定端末を一意に特定する識別情報と対応付けて、端末状態取得手段で取得した複数の特定端末の状態を表示するための端末状態表示手段と、表示手段にてその状態が表示されている複数の特定端末のうちから何れか１つの特定端末を選択するための端末選択手段と、利用者の聴覚及び触覚の少なくとも一方に訴える態様で端末選択手段によって選択された特定端末の状態が変化した旨を通知するための通知手段と、端末選択手段によって選択された特定端末に関し、端末状態取得手段によって取得された当該特定端末の状態が、選択時の第１の状態とは異なる第２の状態へと変化したときに、通知手段を第１の態様で作動させるための第１の制御手段と、を含む。
【００１６】
なお、上記「利用者の聴覚に訴える態様」としては、音による通知態様を例示でき、上記「利用者の触覚に訴える態様」としては、振動による通知態様を例示することができる。
【００１７】
また、上記「第１の状態」とは、いわゆるビジー（ＢＵＳＹ）状態と称される通話接続不可能な状態（通話ＮＧ状態）であって、相手端末ビジー状態及び回線ビジー状態はもとより圏外及び電源オフ状態を含む概念である。他方、上記「第２の状態」とは、いわゆるレディー（ＲＥＡＤＹ）状態と称される通話接続可能な状態（通話ＯＫ状態）である。
【００１８】
上記構成において、電源オン操作に伴う稼動中には、常時、通話通信可能な特定端末の状態が取得される。取得された特定端末の状態は、特定端末を一意に特定する識別情報と対応付けて表示される。このとき、複数の特定端末の状態が表示され、利用者は、自身の意思に基づいて、その状態が表示されている複数の特定端末のうちから任意に１つの特定端末を選択することができる。選択された特定端末に関しては、取得された当該特定端末の状態が選択時の第１の状態とは異なる第２の状態へと変化すると、これを契機にその旨が第１の態様で利用者に通知される。したがって、選択端末がビジー状態であるときには、当該端末がレディー状態になるまで待機し、ビジー状態からレディー状態への遷移が検出されると、その旨が利用者に通知されることになる。
【００１９】
また、上記通信端末は、端末選択手段によって選択された特定端末に関し、第１の制御手段により通知手段が第１の態様で作動されてから利用者による通話に関わる特定操作がなされるまでの間に、端末状態取得手段により取得された当該特定端末の状態が通知手段を第１の態様で作動させたときの第２の状態から第１の状態へと変化したときに、通知手段を第１の態様とは異なる第２の態様で作動させるための第２の制御手段をさらに含む。
【００２０】
なお、上記「通話に関わる特定操作」とは、通常の通話開始操作及びいわゆるリダイヤル操作等を含む概念である。
【００２１】
上記構成において、選択された特定端末に関し、上記第１の態様での通知がなされてから利用者による通話に関わる特定操作がなされるまでの間に、取得された当該特定端末の状態が第１の態様での通知時の第２の状態から第１の状態へと変化すると、これを契機に第１の態様とは異なる第２の態様でその旨が通知される。したがって、選択端末の状態がビジー状態からレディー状態へと遷移した旨を利用者に通知している間に、当該選択端末の状態がビジー状態に遷移した場合には、その旨が上記レディー遷移検出通知とは異なる態様で利用者に通知されることになる。
【００２２】
さらに、上記通信端末は、第１の態様での通知手段の作動時に利用者による通話に関わる特定操作がなされると、通信手段を介して端末選択手段によって選択された特定端末との通話通信接続を開始するための第３の制御手段をさらに含む。
【００２３】
上記構成において、上記第１の態様での通知時に利用者による通話に関わる特定操作がなされると、これを契機に選択された特定端末との通話通信接続が開始される。したがって、選択端末の状態がレディー状態に遷移した旨が通知されている間に、通話に関わる特定操作がなされると、これを契機にその選択端末に対する発呼が行なわれることになる。
【発明の効果】
【００２４】
本発明では、相手端末の状態を利用者自身の端末に表示することによって当該相手端末の状態が常時把握できる状態にしておいて、相手端末の状態が変化したときにその旨が利用者に通知される。そのため、利用者は、通話通信したい相手端末の状態を常に確認する必要がなくなる。その結果、相手端末の状態が通話通信可能な状態になったときに、利用者は直ぐに当該相手端末に通話連絡をすることができる。
【発明を実施するための最良の形態】
【００２５】
以下、本発明の実施の形態について、添付図面に基づき詳細に説明する。
【００２６】
[相手端末通話予約システムの構成]
図１は本発明の実施の形態に係る相手端末通話予約システム１００の構成を簡略化して示す図である。
【００２７】
図１を参照して、本実施の形態に係る相手端末通話予約システム１００は、公衆回線網２００に接続される交換機３００，４００と、公衆回線網又はインターネット等の通信回線網５００，６００を介して交換機３００，４００にそれぞれ接続される基地局７００，８００と、これら基地局７００又は８００、交換機３００又は４００及び公衆回線網２００を介して互いに接続可能な通信端末９００Ａ，９００Ｂ，９００Ｃと、公衆回線網２００に接続されたメールサーバ１０００と、メールサーバ１０００に接続されたＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）１１００とを含む。
【００２８】
図１に示す例では、通信端末９００Ａ及び通信端末９００Ｂの両者は、基地局７００及び通信回線網５００を介して交換機３００に接続されている。他方、通信端末９００Ｃは、通信回線網６００を介して交換機４００に接続されている。
【００２９】
交換機３００と交換機４００とは、公衆回線網２００を介して接続されており、それによって両交換機３００，４００同士の間で相互にデータの送受が可能とされている。
【００３０】
[交換機３００の構成]
図２は交換機３００の構成を示すブロック図である。
【００３１】
図２を参照して、交換機３００は、相手端末への通話予約を受付ける機能を有している。この交換機３００には、通信端末９００Ａ，９００Ｂ，９００Ｃを１つのグループを構成するメンバ端末としてグループ管理して当該通信端末９００Ａ，９００Ｂ，９００Ｃに対して通話予約サービスを提供する管理サーバ３０２と、この管理サーバ３０２にアクセスした各通信端末９００Ａ，９００Ｂ，９００Ｃの管理サービスの対象となる情報を蓄積する端末情報記憶装置（以下、単に「ＨＤＤ」と称する）３０４とが備えられている。
【００３２】
管理サーバ３０２は、その制御中枢を司り実質的にコンピュータからなるサーバ制御部３０６と、通信回線網５００及び公衆回線網２００の両者並びにサーバ制御部３０６に接続される端末接続・通信装置３０８とを含む。
【００３３】
サーバ制御部３０６は、何れも図示しないＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）及びＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等から構成され、このサーバ制御部３０６には、端末情報記憶装置としてのＨＤＤ３０４が接続されている。
【００３４】
＜ＨＤＤ３０４の構成＞
図３はＨＤＤ３０４内の記憶域の構成を図解的に示す図である。
【００３５】
図３を参照して、ＨＤＤ３０４には、上記管理サーバ３０２の相手端末への通話予約サービスを利用した（換言すると、管理サーバ３０２にアクセスした）通信端末に関する情報を端末毎に記憶する領域（端末Ａの記憶域、端末Ｂの記憶域、端末Ｃの記憶域…端末ｎの記憶域）が形成されている。
【００３６】
例えば、端末Ａの記憶域は、自端末情報記憶部及びメンバ端末情報記憶部を備えている。自端末情報記憶部には、端末Ａ自身に関する種々の情報が格納されており、特に、時々刻々変化する端末Ａとしての通信端末９００Ａ自身の状態を示す変数ＭＯＤＥの値が格納される。メンバ端末情報記憶部には、端末Ａとしての通信端末９００Ａと共に１つのグループを形成する他のメンバ端末情報の記憶アドレスを指すポインタＭＥＭ１，ＭＥＭ２，ＭＥＭ３…ＭＥＭｎが格納される。これら自端末情報記憶部及びメンバ端末情報記憶部にそれぞれ格納された変数ＭＯＤＥ値及び記憶アドレスポインタＭＥＭ１〜ＭＥＭｎは、端末Ａとしての通信端末９００Ａを一意に識別する識別情報としてのＩＤ（Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）をパラメータとして、サーバ制御部３０６に一括して管理される。上記ＭＯＤＥ値が「０」の場合には、端末Ａとしての通信端末９００Ａ自身の状態がレディー（着呼ＯＫ）状態であり、上記ＭＯＤＥ値が「１」の場合には、端末Ａとしての通信端末９００Ａ自身の状態がビジー（着呼ＮＧ）状態である。勿論、他の端末Ｂ〜ｎの各記憶域も上記端末Ａの記憶域の構成と同様に構成されている。
【００３７】
なお、通信端末９００Ａ，９００Ｂ，９００Ｃは共に同一の機能を有しているので、以下の説明においては、説明の便宜上、通信端末９００Ａ，９００Ｂ，９００Ｃを「通信端末９００」と称する。
【００３８】
[通信端末９００の構成]
＜通信端末９００の外観構成＞
図４は通信端末９００の外観構成を示す平面図である。
【００３９】
図４を参照して、通信端末９００は、携帯電話又はＰＨＳであって、操作部９０４及び表示部９０６から構成された通信端末本体９０２を含む。操作部９０４には、テンキー９０８、モード変更ボタン９１０、メールボタン９１２、電源ボタン９１４、通話開始ボタン９１６、通話終了ボタン９１８、一覧ボタン９２０及びカーソルキー９２２が備えられている。表示部９０６には、ディスプレイ９２４が備えられている。
【００４０】
テンキー９０８は、電話番号、メールアドレス等のアクセスコード及び文字等の入力時に操作されるキーであって、操作部９０４のほぼ中央部に配置されている。
【００４１】
モード変更ボタン９１０は、本通信端末９００の状態を、レディー状態である通常モードからビジー状態となる特定端末着呼拒否モードに切替える、又はビジー状態である特定端末着呼拒否モードからレディー状態となる通常モードへ切替える際に操作されるボタンである。ここに、「特定端末着呼拒否モード」とは、上記管理サーバ３０２により管理される同じグループに属する他のメンバ端末からの着呼（呼出）を受付けないようにするモードをいう。メールボタン９１２は、メールを送信若しくは返信する、又は受信メールの内容を確認する際等に操作されるボタンである。電源ボタン９１４は、本通信端末９００をオン又はオフする際に操作されるボタンである。これらのモード変更ボタン９１０、メールボタン９１２及び電源ボタン９１４は、上記テンキー９０８の左側において、上から下に向かってこの順に配置されている。
【００４２】
通話開始ボタン９１６は、通話を開始する際に操作されるボタンである。通話終了ボタン９１８は、通話を終了する際に操作されるボタンである。一覧ボタン９２０は、ディスプレイ９２４の表示面上において、管理サーバ３０２によりグループ管理される他のメンバ端末に関する情報をその端末ＩＤと対応付けて一覧表示させる、又はこの一覧表示を終了させる際に操作されるボタンである。なお、このディスプレイ９２４の表示面での一覧表示の内容については後述する。カーソルキー９２２は、ディスプレイ９２４の表示画面上でカーソルを上下左右に移動させる際に操作されるキーであって、その中央部に確定ボタン９２２Ａを有する。これらの通話開始ボタン９１６、通話終了ボタン９１８、一覧ボタン９２０及びカーソルキー９２２は、上記テンキー９０８の右側において、上から下に向かってこの順に配置されている。
【００４３】
表示部９０６に嵌め込まれたディスプレイ９２４の表示面には、通信に関する種々の情報が表示される。表示部９０６は、ディスプレイ９２４の表示面を上に向けた状態で操作部９０４に対して矢印Ｘ１及びＸ２により示される方向にスライド自在に装着されている。つまり、表示部９０６は、矢印Ｘ１方向に沿ってスライド移動させると、図４において実線で示すようにテンキー９０８を露呈させてその操作が可能な第１の姿勢となる。矢印Ｘ２に沿ってスライド移動させると、図４において仮想線で示すようにテンキー９０８を覆いその操作が不可能な第２の姿勢となる。それゆえ、利用者は、表示部９０６が第１及び第２の姿勢の何れの姿勢でも、本通信端末９００が稼動中であればディスプレイ９２４の表示内容を常時視認することができる。
【００４４】
＜一覧表示の内容＞
図５はディスプレイ９２４上での一覧表示の一例を示す図である。
【００４５】
図５を参照して、上記一覧ボタン９２０の表示操作がなされると表示部９０６のディスプレイ９２４の表示面上にグループメンバとその端末状態の一覧表示が実行される。この一覧表示では、自端末と同グループに属する他のメンバ端末の利用者の名前、その端末固有のＩＤとしての電話番号、及びその端末状態（ＢＵＳＹ又はＲＥＡＤＹ）が互いに関連付けた表示がなされる。
【００４６】
＜通信端末９００の電気的構成＞
図６は通信端末９００の電気的構成を示すブロック図である。
【００４７】
図６を参照して、通信端末９００は、その制御中枢を司る実質的にコンピュータからなる制御部９３０を含む。
【００４８】
制御部９３０は、何れも図示しないＣＰＵ、ＲＯＭ及びＲＡＭ等から構成される。制御部９３０には、アドレス帳記憶装置９３２、端末ＩＤ記憶装置９３４、相手端末状態通知パターン記憶装置９３６、通信装置９３８、入力装置９４０、表示装置９４２、音入力装置９４４、音出力装置９４６及び振動出力装置９４８が接続されている。
【００４９】
アドレス帳記憶装置９３２は、通信端末９００と同じグループに属する他のメンバ端末の利用者の名前、その端末固有の電話番号（端末ＩＤ）、その端末のメールアドレス及び会社名等を記憶するための装置である。なお、このメンバアドレス帳データの構成については後述する。
【００５０】
端末ＩＤ記憶装置９３４は、自端末の識別ＩＤとしての電話番号を記憶するための装置であって、この端末ＩＤ記憶装置９３４には、本通信端末９００自身の電話番号（端末ＩＤ）が格納されている。
【００５１】
相手端末状態通知パターン記憶装置９３６は、本通信端末９００から通話通信相手先として指定された他のメンバ端末の状態を通信端末９００の利用者の聴覚及び触覚に訴える態様で通知するための通知パターンを記憶するための装置である。相手端末状態通知パターン記憶装置９３６には、通知パターンデータとして、相手端末の状態及びその変化パターン（遷移パターン）に応じた複数の通知パターンが登録される。なお、この通知パターンデータの構成については後述する。
【００５２】
これらの記憶装置９３２，９３４及び９３６としては、電気的にデータの書き換えが可能な不揮発性フラッシュメモリが使用されている。
【００５３】
通信装置９３８は、何れも図示しないアンテナ、ＲＦ（Ｒａｄｉｏ Ｆｒｅｑｕｅｎｃｙ）部、変調部及び復調部等を含む。
【００５４】
入力装置９４０は、図示しない入力コントローラ、並びに図４に示す操作部９０４上の各種のキー及びボタン９０８，９１０，９１２，９１４，９１６，９１８，９２０及び９２２等を含む。
【００５５】
表示装置９４２は、図示しないディスプレイコントローラ、及び図４に示す表示部９０６に備えられたディスプレイ９２４等を含む。
【００５６】
音入力装置９４４は、何れも図示しないマイクロフォン及び音入力データ処理部等を含む。
【００５７】
音出力装置９４６は、何れも図示しないスピーカ及び音出力データ処理部等を含む。
【００５８】
振動出力装置９４８は、図４に示す通信端末本体９０２の特定部位（例えば、操作部９０４）に振動を与えるための装置であって、何れも図示しないバイブレータ及びその駆動源となる振動モータ等を含む。
【００５９】
＜メンバアドレス帳データの構成＞
図７はアドレス帳記憶装置９３２に記憶されるメンバアドレス帳データの構成の一例を示す図である。
【００６０】
図７を参照して、上記メンバアドレス帳データには、本システム１００による通話予約サービスの提供を受ける通信端末９００と同一のグループに属する他のメンバ端末の利用者の名前、その端末の電話番号（端末ＩＤ）、その端末のメールアドレス及び会社名等が含まれている。このメンバ端末アドレス帳データでは、上記の名前、端末ＩＤ、メールアドレス及び会社名等が図示しないメモリＮo等の特定コードに対応付けて、リレーショナルデータ化（テーブル化）される。
【００６１】
＜通知パターンデータの構成＞
図８は相手端末状態通知パターン記憶装置９３６に記憶される通知パターンデータの構成の一例を示す図である。
【００６２】
図８を参照して、上記通知パターンデータには、振動と音とを組合せて出力することによって本通信端末９００により通話通信相手として指定選択されたメンバ端末の状態及びその状態の変化を通知するためのパターンとして、パターンＡ、パターンＢ及びパターンＣが含まれている。
【００６３】
パターンＡは、通常周期振動（ブ〜ルブ〜ルブ〜ルブ〜ルブ〜ルブ〜ルブ〜ル）と着信メロディ（本通信端末９００の利用者により発呼者に応じて設定されたメロディ）とを組合せた通知パターンである。本通信端末９００がＭＯＤＥ＝「０」（レディー状態）のときに他の端末からの着呼があった場合、及びＭＯＤＥ＝「１」（ビジー状態）のときにグループ外の端末からの着呼があった場合に、その旨を利用者に通知するためのパターンである。音出力装置９４６及び振動出力装置９４８の両者がパターンＡに則して稼動されることによって、着呼があったことが利用者に通知される。
【００６４】
パターンＢは、高速周期振動（ブルブルブルブル＊＊ブルブルブルブル）とベル音（高音：リンリンリンリン）とを組合せた通知パターンである。通信端末９００は、同一グループの他端末に対して発呼したとき、相手端末がビジー状態であるときには一旦発呼を中止し、相手端末がレディー状態になるまで待機する。この待機中に相手端末の状態がレディー状態に変化したとき、音出力装置９４６及び振動出力装置９４８の両者がパターンＢに則して稼動させられる。パターンＢによる通知があったことによって、利用者には、相手端末がビジー状態からレディー状態に変化したことがわかる。このように状態がレディー状態に変化したことを利用者に通知することにより、利用者は相手に何度もかけたりする必要がなくなる。それゆえ、利用者は、単に、このパターンＢによる通知がされるまで待機すればよい。
【００６５】
パターンＣは、高低繰返振動（ブ〜〜ルブ〜〜ル＊＊ブ〜〜ルブ〜〜ル）とビープ（低音：ブーブーブーブー）とを組合せた通知パターンである。上記パターンＢでの通知があった後、利用者が通話開始ボタン９１６を操作して相手に対して発呼する前に、相手端末がビジー状態に再度変化した場合に、音出力装置９４６及び振動出力装置９４８の両者がパターンＣに則して稼動されることによって利用者に対し相手端末が再びビジー状態となったことが通知される。
【００６６】
[相手端末通話予約システム１００のソフトウェア構成]
＜通信端末９００側のソフトウェア構成＞
本通信端末９００側は、以下のようにプログラミングされている。
【００６７】
（１）一覧表示から選択されたメンバ端末に対して発呼を試みたときに、最初に交換機にアクセスし、相手のメンバ端末の状態がビジー（通話ＮＧ）状態かレディー（通話ＯＫ）状態かを調べる。レディー状態のときには、直ちに相手端末に対し発呼する。ビジー状態のときには、発呼は行なわず、ビジー状態からレディー状態に変化するまで待機する。そして、相手端末がレディー状態に変化すると、その旨を利用者に対しパターンＢで通知する。
【００６８】
（２）上記したように、選択されたがビジー状態である相手端末について、上記したパターンＢでの通知が開始された後、利用者が実際の発呼をするまでの間に相手の状態が再びビジー状態に変化したときには、その旨をパターンＣで通知する。
【００６９】
（３）自端末がレディー状態にあるとき、又は同一グループに属さない通信端末から着信があった場合には、パターンＡでの着信があったことを利用者に通知する。
【００７０】
このプログラムは、通信端末９００の制御部９３０内のＲＯＭに記憶されており、次に説明する通信端末９００の種々の機能を実現する。これらの機能の実現は、上記の実質的にはコンピュータである制御部９３０が上記のプログラムを実行することによって達成される。
【００７１】
図９〜図１０は相手端末通話予約システム１００に適用される通信端末９００の機能を実現するプログラムの制御の流れを示すフローチャートである。
【００７２】
図９を参照して、本通信端末９００では、電源ボタン９１４の端末オン操作がなされると、初期設定として自身の端末状態をレディー（着呼ＯＫ）状態とする。すなわち、自端末の状態を示す変数ＭＯＤＥに「０」を代入する（ステップＳ１００）。
【００７３】
次に、制御部９３０は、待受画面をディスプレイ９２４上に表示させる（ステップＳ１０２）。
【００７４】
続いて、制御部９３０は、通信装置９３８を介して、自端末の状態（モード）が変更された旨を管理サーバ３０２に通知する（ステップＳ１０４）。このときに管理サーバ３０２に送信される自端末モード変更通知メッセージは、モード変更したことを示す所定のキーワード「ＭｏｄｅＣｈａｎｇｅ」（即ち、自端末モード変更通知コマンド）、自端末ＩＤ（電話番号）、及び変更後の端末状態を示す変数ＭＯＤＥの値を含む。端末の電源オン直後には、変数ＭＯＤＥの値は「０」であり、その値が管理サーバ３０２に通知される。
【００７５】
その後、制御部９３０は、モード変更ボタン９１０が操作されたか否かを判定する（ステップＳ１０６）。モード変更ボタン９１０が操作された場合には、制御部９３０は、変数ＭＯＤＥの値をトグルする。すなわち、変数ＭＯＤＥの値が「０」であるときには「１」に、「１」であるときには「０」に、それぞれ変数ＭＯＤＥの値を変更する（ステップＳ１２２）。その後、制御部９３０は、制御を再びステップＳ１０４に制御を戻す。
【００７６】
モード変更ボタン９１０が操作されなかったとステップＳ１０６で判定された場合には、制御はステップＳ１０８に進む。ステップＳ１０８において、制御部９３０は、一覧ボタン９２０が操作されたか否かを判定する。一覧ボタン９２０が操作された場合には、制御部９３０は、制御を図１０に示すステップＳ１３４に移す。一覧ボタン９２０が操作されなかった場合には、制御部９３０は、制御をステップＳ１１０に移す。
【００７７】
ステップＳ１１０では、制御部９３０は、他の端末からの着呼があったか否かを判定する。他の端末からの着呼がない場合には、制御はステップＳ１０６に戻る。他の端末からの着呼があった場合には、制御はステップＳ１１２に移る。
【００７８】
ステップＳ１１２では、変数ＭＯＤＥの値が「０」か否かを判定する。変数ＭＯＤＥの値が「０」であれば、着呼があり、かつ自端末がレディー状態であるということであり、制御部９３０は、音出力装置９４６及び振動出力装置９４８の両者を共にパターンＡにしたがって稼動させて着呼があったことを利用者に通知する（ステップＳ１１４）。すなわち、この着呼通知は、通常周期振動と着信メロディとを組合せた態様で実行される。ステップＳ１１２において変数ＭＯＤＥの値が「１」であると判定された場合、同一グループのメンバ端末からの呼出か否かが判定される（ステップＳ１２４）。この判定は、着呼に伴う相手端末のＩＤが、アドレス帳記憶装置９３２に記憶されたメンバアドレス帳中に存在しているか否かによって行なわれる。
【００７９】
着呼が通信端末９００と同じグループに属するメンバ端末からのものであると判定されると、制御はステップＳ１０４に戻る。着呼がメンバ端末以外の端末からのものであると判定されると、制御はステップＳ１１４に移る。ステップＳ１１４においては、パターンＡでの着呼通知が行なわれる。利用者は、もしもこの着呼に応答するのであれば、通話開始ボタン９１６を操作すればよい。
【００８０】
制御部９３０は、パターンＡによる着呼通知を実行している間に、通話開始ボタン９１６の操作又は発呼側端末からの着呼終了を待つ（ステップＳ１１６及びＳ１１８）。通話開始ボタン９１６が操作される前に着呼が終了した場合には、制御部９３０は、パターンＡでの着呼通知を停止し（ステップＳ１２０）、制御をステップＳ１０４に戻す。着呼が終了する前に通話開始ボタン９１６が操作された場合には、制御はステップＳ１２６に進み、パターンＡでの着呼通知が停止される。さらに、変数ＭＯＤＥの値を変更せず、自端末状態がビジー状態になった（即ち、通話中である）旨を管理サーバ３０２に通知する（ステップＳ１２８）。制御部９３０は、オフフック処理等を含む通話接続制御を行なって（ステップＳ１３０）通話を開始させ、通話終了を待つ（ステップＳ１３２）。通話が終了すると、制御部９３０は、制御をステップＳ１０４に戻す。なお、制御部９３０により通話終了と判断される態様としては、自端末側での通話終了ボタン９１８の操作、相手端末側からの通話終了信号の受信、及び接続エラーが所定時間続きそれによって相手端末と接続できない状態が継続する等の態様を挙げることができる。
【００８１】
ステップＳ１００〜ステップＳ１３２の一連の制御は、電源ボタン９１４の端末オフ操作がなされない限り、繰返し実行される。
【００８２】
図９のステップＳ１０８において、一覧ボタン９２０の一覧表示操作がされた場合、制御は図１０のステップＳ１３４に移行する。ステップＳ１３４では、ディスプレイ９２４上に通信端末９００と同じグループに属する他のメンバ端末に関する情報の先頭ページ（即ち、１ページ目）の画面を作成し、一覧表示させる。この一覧表示画面では、図５に示すように、他のメンバ端末の利用者の名前、その端末固有のＩＤとしての電話番号、及びその端末の状態が互いに関連付けられて表示される。
【００８３】
続いてステップＳ１３６において、ステップＳ１３４で表示された１ページ目の一覧表示画面の最上位に表示されているメンバ端末を選択状態にする。
【００８４】
その後、ステップＳ１３８において、制御部９３０は、現在一覧表示中のメンバ端末の各々に関し、その端末状態を送信するよう管理サーバ３０２に対し送信要求を、通信装置９３８を介して送信する。ここでは、自端末ＩＤ及び各メンバ端末ＩＤを付した「ＧｅｔＭｏｄｅ」コマンド（以下、「端末状態送信要求コマンド」という）が管理サーバ３０２に送信される。管理サーバ３０２は、この送信要求コマンドに含まれる通信端末９００自身の端末ＩＤと各メンバ端末の端末ＩＤとの組合せをキーとして管理サーバ３０２専用のＨＤＤ３０４の端末ＩＤの記憶域を参照し、該当するメンバ端末の状態を読出して本通信端末９００に送信する。制御部９３０は、その管理サーバ３０２から送信されてきた値を管理サーバ３０２から通信装置９３８を介して受信する。そしてステップＳ１４０において、一覧表示中の各メンバ端末の状態表示が、送信されてきた値により更新される。
【００８５】
メンバ端末状態表示の更新処理が終了すると、制御部９３０は、ページ切替操作、相手端末の選択変更操作、一覧表示終了操作及び通話開始操作の何れかの操作がなされたかを順番に判定する（ステップＳ１４２、Ｓ１４４、Ｓ１４６及びＳ１４８）。
【００８６】
端末状態表示更新後の次の操作として、カーソルキー９２２の操作によりカーソルを左右に移動させるページ切替操作がなされた場合（ステップＳ１４２においてＹＥＳ）には、制御部９３０は、現在表示されているページの次のページ又は前のページに登録されているメンバ端末に関する情報をディスプレイ９２４上に一覧表示させる（ステップＳ１５０）。さらに、制御部９３０は、表示されたページの一覧の最上位に表示されているメンバ端末を上記ステップＳ１３６と同様にして選択状態とする（ステップＳ１５２）。その後、制御部９３０は、制御をステップＳ１３８に戻す。
【００８７】
カーソルを上下に移動させる操作がされた場合（ステップＳ１４４においてＹＥＳ）には、制御部９３０は、カーソルの移動にしたがって、現在選択中の１つ前又は後の端末を上記ステップＳ１３６と同様にして選択状態とする（ステップＳ１５４）。その後、制御部９３０は、制御をステップＳ１３８に戻す。
【００８８】
一覧ボタン９２０の一覧表示終了操作がされたと判定された場合（ステップＳ１４６においてＹＥＳ）には、制御部９３０は、メンバ端末の一覧表示を終了させ、制御を図９に示すステップＳ１０２に戻す。
【００８９】
通話開始ボタン９１６が操作された場合（ステップＳ１４８においてＹＥＳ）には、制御部９３０は、制御を図１１に示すステップＳ１５６に移す。
【００９０】
上記の何れの操作も行なわれない場合（ステップＳ１４２、Ｓ１４４、Ｓ１４６及びＳ１４８において共にＮＯ）には、制御部９３０は、制御をステップＳ１３８に戻す。換言すると、上記のステップＳ１４２〜ステップＳ１４８の各操作判定処理は、カーソルキー９２２、一覧ボタン９２０及び通話開始ボタン９１６のうち何れかの操作がなされるまで繰返し実行される。
【００９１】
図１１を参照して、メンバ端末一覧表示画面上で通話通信相手となるメンバ端末の選択が行なわれ、この選択されたメンバ端末に対する通話開始操作がされると、ステップＳ１５６において、制御部９３０は、現在選択中のメンバ端末に関する端末状態を、端末状態送信要求コマンドによって通信装置９３８を介して管理サーバ３０２に要求する（即ち、現在選択中のメンバ端末ＩＤを付した端末状態送信要求コマンドを管理サーバ３０２に送信する）と共にそのリターン値を管理サーバ３０２から通信装置９３８を介して受信する。
【００９２】
その後、制御部９３０は、管理サーバ３０２から受信した変数ＭＯＤＥのリターン値に基づいて、選択中のメンバ端末の状態がビジー（通話ＮＧ）状態か否かを判別する（ステップＳ１５８）。選択メンバ端末に関する変数ＭＯＤＥのリターン値が「０」であって当該選択メンバ端末がレディー（通話ＯＫ）状態であると判別した場合には、制御部９３０は、オフフック処理及び発呼処理等の選択中のメンバ端末との通話接続制御を行なって通話を開始させ、通話の終了まで待機する（ステップＳ１８０及びＳ１８２）。通話が終了すると、制御は図９に示すステップＳ１０２に戻る。
【００９３】
選択されたメンバ端末に関する変数ＭＯＤＥのリターン値が「１」の場合、制御はステップＳ１６０及びＳ１６２に進み、選択されたメンバ端末の状態がビジー状態からレディー状態へ遷移するまで、選択中のメンバ端末に関する端末状態送信要求コマンドを管理サーバ３０２に送信すると共にそのリターン値を管理サーバ３０２から受信する処理を実行し続ける。
【００９４】
選択中のメンバ端末の状態がレディー状態に遷移すると、制御部９３０は、音出力装置９４６及び振動出力装置９４８の両者を共にパターンＢにしたがって稼動させてその旨を本通信端末９００の利用者に通知する（ステップＳ１６４）。すなわち、この通知は、高速周期振動とベル音（高音）とを組合せた態様で実行される。これにより、この端末の利用者は、相手端末がレディー状態に変化したことを知ることができる。
【００９５】
パターンＢでの通知中に通話開始ボタン９１６が操作された場合（ステップＳ１６６においてＹＥＳ）には、制御部９３０は、当該パターンＢでの通知を停止し（ステップＳ１８４）、制御をステップＳ１８０に戻して選択中のメンバ端末との通話接続制御処理を実行する。したがって、利用者は相手端末との通話を開始できる。
【００９６】
パターンＢでの通知中に通話開始ボタン９１６が操作されない場合（ステップＳ１６６においてＮＯ）には、制御部９３０は、現在選択中のメンバ端末に関する端末状態をその送信を要求するコマンド（ＧｅｔＭｏｄｅコマンド）によって管理サーバ３０２に要求し、そのリターン値を管理サーバ３０２から受信する（ステップＳ１６８）。受信した変数ＭＯＤＥのリターン値に基づき当該選択メンバ端末の状態がレディー状態から再度ビジー状態に遷移したか否かを判定する（ステップＳ１７０）。判定結果がＹＥＳの場合には制御はステップＳ１８６に進み、それ以外の場合には制御はステップＳ１７８に進む。
【００９７】
ステップＳ１７８では、パターンＢでの通知開始後、一定時間が経過したか否かを判定し、経過していない場合には制御はステップＳ１６６に戻る。一定時間が経過すると、制御は図１０に示すステップＳ１３８に進む。すなわち、この選択メンバ端末に対するモニター処理は、パターンＢでの通知が開始されてから一定時間が経過するまで繰返し実行される。
【００９８】
その間に、選択中のメンバ端末の状態がレディー状態から再びビジー状態へと遷移すると（ステップＳ１７８においてＮＯ、ステップＳ１６６においてＮＯ、かつステップＳ１７０においてＹＥＳ）、制御はステップＳ１８６に進む。ステップＳ１８６では、制御部９３０は、規定時間が経過するまでの間、音出力装置９４６及び振動出力装置９４８の両者を共にパターンＣにしたがって稼動させる。この結果、利用者に対し、一旦レディー状態に遷移した相手端末が再びビジー状態となったことが通知される。この通知は、高低繰返振動とビープ（低音）とを組合せた態様で実行される。その後、制御は、ステップＳ１６０に戻る。これに対し、上記一定時間経過するまでに選択中のメンバ端末の状態がビジー状態に遷移することなく、かつ途中で通話ボタンが操作されることなくレディー状態のままであると（ステップＳ１７０においてＮＯ、ステップＳ１６６においてＮＯ、かつステップＳ１７８においてＹＥＳ）、制御部９３０は、制御を図１０に示すステップＳ１３８に戻す。
【００９９】
＜管理サーバ３０２側のソフトウェア構成＞
管理サーバ３０２は、このサービスを利用している通信端末から自端末モード変更通知コマンドを含む通知を受けると、そのメンバ端末の状態を更新することにより、このサービスを利用している全ての通信端末の状態を常に管理するようにプログラミングされている。管理サーバ３０２はさらに、このサービスを利用している通信端末から、その通信端末と同一グループに属する他の通信端末のＩＤを指定して端末状態送信要求コマンドを含む要求があると、指定されたＩＤを持つ通信端末の状態を、端末状態送信要求コマンドを送信してきた通信端末に返信するようにプログラミングされている。このプログラムは、管理サーバ３０２の制御部３０６内のＲＯＭに記憶されており、次に説明する管理サーバ３０２の種々の機能を実現する。これらの機能の実現は、上記の実質的にはコンピュータである制御部３０６が上記のプログラムを実行することによって達成される。
【０１００】
図１２は相手端末通話予約システム１００において使用される管理サーバ３０２の機能を実現するプログラムの制御の流れを示すフローチャートである。
【０１０１】
図１２を参照して、このサービスを受けている何れかの通信端末から端末接続・通信装置３０８を介して何らかのメッセージを受信すると、管理サーバ３０２の制御部３０６は、受信したメッセージにコード化された自端末モード変更通知コマンド又は端末状態送信要求コマンドが含まれているか否かを判定する（ステップＰ５００及びＰ５０２）。
【０１０２】
受信したメッセージに自端末モード変更通知コマンドが含まれている場合（ステップＰ５００においてＹＥＳ）には、制御部３０６は、この自端末モード変更通知コマンドに含まれる、このコマンドを送信してきた端末ＩＤ（電話番号）をキーにして図３に示すその端末の記憶域を特定し、そこに記憶されている変数ＭＯＤＥの値を、送信されてきた値により変更する（ステップＰ５０８）。すなわち、自端末モード変更通知コマンドと共に送信されてきた値が「１」であれば、該当する端末の変数ＭＯＤＥの内容が「１」に変更され、「０」であれば「０」に変更される。その後、制御部３０６は、制御をステップＰ５００及びＰ５０２に戻して次のメッセージ受信に備える。
【０１０３】
受信メッセージに端末状態送信要求コマンドが含まれている場合（ステップＰ５０２においてＹＥＳ）には、制御はステップＰ５０４に進む。ステップＰ５０４では、制御部３０６は、端末状態送信要求コマンドによって指定された端末ＩＤを持つ通信端末が、端末状態送信要求コマンドを送信してきた通信端末と同じグループに属するか否かを判定し、判定結果にしたがって制御を分岐させる。すなわち、この判定結果がＹＥＳであれば制御はステップＰ５０６に、ＮＯであれば制御はステップＰ５１０に進む。ステップＰ５０４における判定は、端末状態送信要求コマンドを送信してきた端末に対応する記憶域のメンバ端末情報記憶部内に、端末状態の送信が要求された通信端末のＩＤが記憶されているか否かによって行なわれる。
【０１０４】
端末状態送信要求コマンドにより端末状態の送信が要求された端末が端末状態送信要求コマンドの送信元の端末と同じグループに属すると判定されると、ステップＰ５０６において、制御部３０６は、端末状態の送信が要求された端末の状態を示すＭＯＤＥ値を端末状態送信要求コマンドの送信元端末に送信する。具体的には、制御部３０６は、ＨＤＤ３０４内の、端末状態要求コマンドを送信してきた通信端末に対応する記憶域のメンバ端末情報記憶部に記憶されているポインタにしたがって、端末状態の送信が要求された端末に対応する記憶域の自端末情報記憶部にアクセスすることによって、当該端末の現在のＭＯＤＥ値を読出す。この値が端末状態送信要求コマンドを送信してきた通信端末に対し返信される。この後、制御はステップＰ５００に戻る。
【０１０５】
これに対し、端末状態の送信が要求された端末が端末状態送信要求コマンドの送信元端末と同じグループに属さないと判定されると（ステップＰ５０４においてＮＯ）、制御部３０６は、エラーを示す戻り値「−１」を端末状態送信要求コマンドの送信元端末に送信する（ステップＰ５１０）。その後、制御はステップＰ５００に戻る。
【０１０６】
アクセス要求信号に自端末モード変更通知コマンド及び端末状態送信要求コマンドの何れも含まれていない場合（ステップＰ５００及びＰ５０２において共にＮＯ）には、制御部３０６は、受信したメッセージにしたがって図示しない他の処理を行ない、制御をステップＰ５００に戻す。
【０１０７】
［動作］
相手端末通話予約システム１００は以下のように動作する。
【０１０８】
通信端末９００は、電源が投入されると自己の変数ＭＯＤＥの値を「０」に初期化し、誰からの着呼でも受付ける状態とする。そして、待受画面を表示した後、管理サーバ３０２に対し、自分自身のＩＤを指定した自端末モード変更通知コマンドを含む自端末モード変更通知メッセージを送信し、サーバ側で管理されている自分のＭＯＤＥ値を「０」とする。
【０１０９】
以後、利用者がモード変更ボタン９１０を操作する度に、変数ＭＯＤＥの値を「０」から「１」に、「１」から「０」に、それぞれトグルさせ、その度に管理サーバ３０２に対して変数ＭＯＤＥの値の変更を自端末モード変更通知メッセージにより通知する。
【０１１０】
管理サーバ３０２側では、このサービスを受ける通信端末からの自端末モード変更通知メッセージに基づき、それらのＭＯＤＥ値（「０」ならレディー（通話ＯＫ）状態、「１」ならビジー（通話ＮＧ）状態）を常に管理する。
【０１１１】
通信端末９００側では、同じグループに属する他のメンバ端末に対する発呼要求があった場合、相手端末の状態を発呼前に管理サーバ３０２から取得し、その結果に応じた処理を行なう。
【０１１２】
すなわち、発呼要求があったメンバ端末の状態がビジー状態であるときには、通信端末９００は、発呼先のメンバ端末がレディー状態になるまで、管理サーバ３０２に対して端末状態送信要求を繰返し送信することにより発呼先のメンバ端末の状態の監視を続け、その端末状態がレディー状態に変化した時点で、高速周期振動及びベル音（高音）の両者を組合せたパターンＢによりその旨を通知する。
【０１１３】
パターンＢでの通知中に利用者が通話開始ボタン９１６を操作すると、通信端末９００は、パターンＢでの通知を停止し、相手のメンバ端末に対し実際の発呼を行なう。
【０１１４】
通信端末９００は、パターンＢでの通知を行なっている間にも、管理サーバ３０２に対して端末状態送信要求コマンドを繰返し送信することにより、発呼対象のメンバ端末がレディー状態からビジー状態に遷移したか否かの監視を続ける。発呼対象のメンバ端末が再度ビジー状態に遷移した際には、通信端末９００は、高低繰返振動及びビープ（低音）の両者を組合せたパターンＣにより、一定時間その旨の通知を行なう。パターンＢでの通知中に相手端末がビジー状態に遷移せずに一定時間経過すると、パターンＢでの通知を停止して、一覧表示に戻る。
【０１１５】
通信端末９００に対し、他の通信端末から着呼があった場合、自己の変数ＭＯＤＥの値を調べ、その値が「０」であれば、無条件でパターンＡにしたがって音出力装置９４６及び振動出力装置９４８とを用いて着呼があったことを利用者に通知する。変数ＭＯＤＥの値が「０」以外（即ち、「１」のとき）には、相手の通信端末が同一グループに属すか否かを調べる。相手が同一グループに属さないものであるときには、変数ＭＯＤＥの値が「０」である場合と同様の動作をする。変数ＭＯＤＥの値が「１」であるときには、この着呼を無視する。
【０１１６】
通話を開始する場合には、着信拒否のモードにするわけではないので、変数ＭＯＤＥの値は「０」のまま変更せず、管理サーバ３０２に自端末モード変更通知メッセージとして「１」を通知することで、当該サーバ３０２における、通信端末９００のＭＯＤＥ値を「１」とする。
【０１１７】
＜作用・効果＞
本実施の形態によると、以下の作用・効果を奏する。
【０１１８】
（１）通信端末９００側では、電源オン操作に伴う稼動中、メンバ端末の一覧表示を選択すると、当該通信端末９００と同一グループに属するメンバ端末の状態が管理サーバ３０２より取得され、表示される。利用者は、表示されている複数のメンバ端末から１つのメンバ端末を、その状態がレディーかビジーかにかかわらず、任意に選択することができる。選択されたメンバ端末がレディー状態であれば、直ぐに発呼及び通話が可能である。選択されたメンバ端末がビジー状態であれば、通信端末９００はすぐには発呼を行なわず、管理サーバ３０２における選択された端末の状態を監視する。相手端末の状態がビジー状態からレディー状態へと変化すると、通信端末９００側は、これをパターンＢで利用者に通知する。したがって、選択メンバ端末がビジー状態であるときには、当該端末がレディー状態になるまで待機し、ビジー状態からレディー状態への遷移が検出されると、その旨がパターンＢにしたがう音声及び振動で利用者に通知されることになる。利用者は、ビジー状態の端末を選択した場合、パターンＢでの通知がされるまで待機し、パターンＢの通知がされたときに実際の発呼を行なえばよい。音声及び振動で、かつ特有のパターンＢにしたがってその通知がされるため、利用者が通信端末を例えばポケットなどにしまっていた場合でも、相手端末がレディー状態となったことが容易にわかる。
【０１１９】
（２）選択された特定端末に関し、パターンＢでの通知がされてから利用者通話開始操作をしないうちに、管理サーバ３０２から取得された当該選択メンバ端末の状態がビジー状態へと変化すると、通信端末９００は、パターンＣでその旨を通知する。したがって、選択メンバ端末の状態がビジー状態からレディー状態へと遷移した旨が利用者に通知されたにもかかわらず、何らかの事情で利用者が相手端末に対する発呼を行なわない間に、相手端末の状態がビジー状態に遷移した場合には、その旨が上記レディー遷移検出通知とは異なる態様で利用者に通知されることになる。利用者は、相手端末が再びビジー状態になったことを知ることができ、ビジー状態であるにもかかわらず発呼を試みたりすることを避けることができる。
【０１２０】
このように、本実施の形態では、相手端末の状態を利用者自身の端末に表示することによって当該相手端末の状態が常時把握できる。さらに、その中の任意の端末を選択すると、その相手端末がビジー状態の場合、相手端末の状態が変化してレディー状態となったときにその旨がパターンＢにより利用者に通知される。また、通話が開始されずに再び相手端末がビジー状態に変化した場合にもその旨がパターンＣにより通知される。利用者は、通信端末からのパターンＢ又はパターンＣによる通知のみを待てばよく、通話通信したい相手端末の状態を常に確認する必要がなくなる。したがって、相手端末の状態が通話通信可能な状態になったときに、利用者はすぐに当該相手端末に通話連絡をすることができ、またそのまま相手が再びビジー状態になったときには発呼を避けることができる。その結果、無駄な発呼を防止できる。
【０１２１】
また、特許文献１に記載の技術では、相手端末が応答するまでの間は他の処理を実行することができないが、本実施の形態では、相手端末状態の監視中であっても、通信端末９００側では、例えば、ＴＶ又は音楽の視聴、並びにゲーム等の実行等の通信機能と無関係なアプリケーション機能を利用することが可能となる。
【０１２２】
なお、本発明は上記実施の形態に限定されるものではない。上記実施の形態では、相手端末の状態を通知する際に、端末状態の変化態様に応じてパターンを変えて音と振動との組合せで通知する例について記載した。しかし、本発明は、そのような構成に限定されない。例えば、音又は振動の単独での出力により相手端末の状態変化を通知するようにしてもよい。また、音又は振動、若しくはこれらの組合せに加え、相手端末の状態変化をＬＣＤ表示及び／又はＬＥＤ発光等により、視覚的に通知するようにしてもよい。その他、本明細書に添付の特許請求の範囲内での種々の設計変更及び修正を加え得ることは勿論である。
【０１２３】
すなわち、本明細書で開示された実施の形態は単に例示であって、本発明が上記した実施の形態のみに制限されるわけではない。本発明の範囲は、発明の詳細な説明の記載を参酌した上で、特許請求の範囲の請求項によって示され、そこに記載された文言と均等の意味及び範囲内での全ての変更を含む。
【図面の簡単な説明】
【０１２４】
【図１】本発明の実施の形態に係る相手端末通話予約システムの構成を簡略化して示す図である。
【図２】同システムに適用される管理サーバを有する交換機の構成を示すブロック図である。
【図３】同システムに適用される管理サーバに接続されるＨＤＤ内の記憶域の構成を図解的に示す図である。
【図４】同システムに適用される通信端末の外観構成を示す平面図である。
【図５】同通信端末のディスプレイ上での一覧表示の一例を示す図である。
【図６】同システムに適用される通信端末の電気的構成を示すブロック図である。
【図７】同通信端末のアドレス帳記憶装置に記憶されるメンバアドレス帳データの構成の一例を示す図である。
【図８】同通信端末の相手端末状態通知パターン記憶装置に記憶される通知パターンデータの構成の一例を示す図である。
【図９】同システムに適用される通信端末の機能を実現するプログラムの制御の流れを示すフローチャートである。
【図１０】同システムに適用される通信端末の機能を実現するプログラムの制御の流れを示すフローチャートであって、図９の続きを示す。
【図１１】同システムに適用される通信端末の機能を実現するプログラムの制御の流れを示すフローチャートであって、図１０の続きを示す。
【図１２】同システムに適用される管理サーバの機能を実現するプログラムの制御の流れを示すフローチャートである。
【符号の説明】
【０１２５】
１００ 相手端末通話予約システム
３０２ 管理サーバ
３０４ ＨＤＤ
３０６ サーバ制御部
３０８ 端末接続・通信装置
９００（９００Ａ，９００Ｂ，９００Ｃ） 通信端末
９１０ モード変更ボタン
９１６ 通話開始ボタン
９２４ ディスプレイ
９３０ 制御部
９３２ アドレス帳記憶装置
９３４ 端末ＩＤ記憶装置
９３６ 相手端末状態通知パターン記憶装置
９３８ 通信装置
９４２ 表示装置
９４６ 音出力装置
９４８ 振動出力装置
【技術分野】
【０００１】
本発明は、通話通信機能を有する通信端末に関する。
【背景技術】
【０００２】
現在では、携帯電話及びＰＨＳ（Ｐｅｒｓｏｎａｌ Ｈａｎｄｙｐｈｏｎｅ Ｓｙｓｔｅｍ）等のような通話通信機能を有する通信端末による移動体通信は、広く一般に普及している。
【０００３】
かかる通信端末による移動体通信における通話通信処理においては、利用者のキー操作又はボタン操作により通話通信先の端末（相手端末）側の電話番号が特定された後に発呼処理が開始される。
【０００４】
上記発呼中に回線接続の失敗が生じると、その旨を通知するために第１の特定音が発せられ、正常な発呼処理により呼出状態に至ると、その旨を通知するために第１の特定音とは異なる態様の第２の特定音が発せられ、それによって利用者が発呼から通話通信接続状態への遷移状況を認識できるようにした通信端末がある。
【０００５】
このような構成の通信端末に対しては、種々の工夫がなされている。例えば、特許文献１に開示されている通信端末では、正常に発呼処理が進行して呼出状態に至った場合には、その旨を利用者に通知するために上記第２の特定音の出力と共に第１のパターンで振動を発生させ、発呼エラーが発生して呼出ができない場合には、その旨を利用者に通知するために上記第１の特定音の出力と共に第１のパターンとは異なる第２のパターンで振動を発生させる。
【０００６】
近年では、通信端末として、通話通信機能に加えてメール通信機能を有することが一般化している。このメール通信機能を備えた通信端末に関しては、その高機能化に伴い、同一のメール機能を備えた端末同士であれば、いわゆる絵文字及びキャラクタ文字等の特殊な文字のデータの送受を互いに行なうことができる。
【０００７】
このような構成の通信端末に対しても、種々の工夫がなされている。例えば、特許文献２に開示された通信端末では、メール送信先端末に対して発呼処理を行ない、メール送信先端末との接続に成功した場合には、その旨を利用者に通知するために第１のパターンで振動の発生及び視覚的な表示が行なわれる。メール送信先端末との接続に失敗した場合には、その旨を利用者に通知するために第１のパターンとは異なる第２のパターンで振動の発生及び視覚的な表示が行なわれる。メール送信先端末がメールの受信に成功した場合には、その旨を利用者に通知するために第１及び第２のパターンとは異なる第３のパターンで振動の発生及び視覚的な表示が行なわれる。メール送信先端末がメールの受信に失敗した場合には、その旨を利用者に通知するために第１〜第３のパターンとは異なる第４のパターンで振動の発生及び視覚的な表示が行なわれる。なお、視覚的な表示には、ＬＣＤ（Ｌｉｑｕｉｄ Ｃｒｙｓｔａｌ Ｄｉｓｐｌａｙ）による表示又はＬＥＤ（Ｌｉｇｈｔ Ｅｍｉｔｔｉｎｇ Ｄｉｏｄｅ）の発光が含まれる。
【特許文献１】特開平１０−２３５４５号公報
【特許文献２】特開２０００−２７０３５５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
上記特許文献１に係る通信端末では、特に、相手端末との通話通信接続が確立するか否かに応じてその通知パターンを変えることによって、通話通信接続の可否が利用者に通知される。つまり、発呼中に相手端末側でオフフック操作等がなされて当該発呼中の相手端末からの応答信号を検出するか否かを基に通知パターンの選択がなされる。
【０００９】
しかしながら、相手端末の状態の通知は発呼した後に行われることから、発呼側端末は、相手端末からの応答を待っている間、他の端末との間で通話ができない。
【００１０】
また、通信端末が、例えば、ＴＶ又は音楽の視聴及びゲーム等を楽しめる、通信機能と無関係なアプリケーション機能を付属的に有している場合には、この通話に影響しないアプリケーション機能を稼動させて、相手端末からの応答があるまで、又は所定の時間経過するまでの空き時間を有効に活用しようとする、利用者も少なくはないとも考えられる。ところが、相手端末からの応答があった旨を示す通知があったときに、常識的には直ちに電話に出ないと相手に失礼である等と考える利用者が多く、実質上、呼出中には、いつでも通話を開始できる状態とせざるを得ないので、結果的に上記端末の付属的なアプリケーション機能を利用できないことになる。
【００１１】
他方、上記特許文献２に係る通信端末では、特許文献１記載の技術と同様に、相手端末の状態通知は、発呼態様としてメールを送信するという、自分が起こしたアクションに対して、メールを受信した又は読んだこと等を示す相手端末からの応答信号を検出するか否かに応じてその通知パターンを変更するように構成されている。つまり、メール送信先でのメール受信の検出結果を基に通知パターンの選択が行なわれる。
【００１２】
そのため、発呼側端末の利用者は、自身が起こした過去のアクションに対して相手先が応答したかどうかによって、以降のアクション（即ち、端末の利用方法）を決めざるを得ない。具体的には、利用者自身がメール送信したことに対して、文章では表現し難いメッセージを電話で伝えるか否かの判断基準を得たりするのには有効ではあるものの、このタイミングが電話連絡しようとする相手と電話連絡を取りたい自分との両者間で必ずしも一致するとは限らない。そのため、互いに何回も電話をかけ合うことになり、結果的に無駄に時間を消費してしまうことも多々ある。
【００１３】
すなわち、両特許文献１及び２に記載の技術では、通信相手の端末の状態が常時把握できるが、例えば、相手端末が圏外又は電源オフの状態から通常状態に変化する等して当該相手端末の状態が変化したとしてもその旨が通知されない。そのため、利用者は、自分で常に相手端末の状態の変化を確認しなければならない。その結果、相手端末が通話通信可能な状態になっても利用者が気付かなかった場合には、相手端末への通話連絡が遅れてしまうことになる。
【００１４】
本発明は、上記技術的課題に鑑みなされたもので、通話連絡したい相手端末の状態の変化を利用者が常に確認しなくても当該相手端末の状態が変化したことを把握し得る通信端末の提供を目的とする。
【課題を解決するための手段】
【００１５】
上記目的を達成するため、本発明に係る通信端末は、特定端末との間での通話通信を可能とするための通信手段と、通信手段を介して通話通信可能な特定端末の状態を取得するための端末状態取得手段と、特定端末を一意に特定する識別情報と対応付けて、端末状態取得手段で取得した複数の特定端末の状態を表示するための端末状態表示手段と、表示手段にてその状態が表示されている複数の特定端末のうちから何れか１つの特定端末を選択するための端末選択手段と、利用者の聴覚及び触覚の少なくとも一方に訴える態様で端末選択手段によって選択された特定端末の状態が変化した旨を通知するための通知手段と、端末選択手段によって選択された特定端末に関し、端末状態取得手段によって取得された当該特定端末の状態が、選択時の第１の状態とは異なる第２の状態へと変化したときに、通知手段を第１の態様で作動させるための第１の制御手段と、を含む。
【００１６】
なお、上記「利用者の聴覚に訴える態様」としては、音による通知態様を例示でき、上記「利用者の触覚に訴える態様」としては、振動による通知態様を例示することができる。
【００１７】
また、上記「第１の状態」とは、いわゆるビジー（ＢＵＳＹ）状態と称される通話接続不可能な状態（通話ＮＧ状態）であって、相手端末ビジー状態及び回線ビジー状態はもとより圏外及び電源オフ状態を含む概念である。他方、上記「第２の状態」とは、いわゆるレディー（ＲＥＡＤＹ）状態と称される通話接続可能な状態（通話ＯＫ状態）である。
【００１８】
上記構成において、電源オン操作に伴う稼動中には、常時、通話通信可能な特定端末の状態が取得される。取得された特定端末の状態は、特定端末を一意に特定する識別情報と対応付けて表示される。このとき、複数の特定端末の状態が表示され、利用者は、自身の意思に基づいて、その状態が表示されている複数の特定端末のうちから任意に１つの特定端末を選択することができる。選択された特定端末に関しては、取得された当該特定端末の状態が選択時の第１の状態とは異なる第２の状態へと変化すると、これを契機にその旨が第１の態様で利用者に通知される。したがって、選択端末がビジー状態であるときには、当該端末がレディー状態になるまで待機し、ビジー状態からレディー状態への遷移が検出されると、その旨が利用者に通知されることになる。
【００１９】
また、上記通信端末は、端末選択手段によって選択された特定端末に関し、第１の制御手段により通知手段が第１の態様で作動されてから利用者による通話に関わる特定操作がなされるまでの間に、端末状態取得手段により取得された当該特定端末の状態が通知手段を第１の態様で作動させたときの第２の状態から第１の状態へと変化したときに、通知手段を第１の態様とは異なる第２の態様で作動させるための第２の制御手段をさらに含む。
【００２０】
なお、上記「通話に関わる特定操作」とは、通常の通話開始操作及びいわゆるリダイヤル操作等を含む概念である。
【００２１】
上記構成において、選択された特定端末に関し、上記第１の態様での通知がなされてから利用者による通話に関わる特定操作がなされるまでの間に、取得された当該特定端末の状態が第１の態様での通知時の第２の状態から第１の状態へと変化すると、これを契機に第１の態様とは異なる第２の態様でその旨が通知される。したがって、選択端末の状態がビジー状態からレディー状態へと遷移した旨を利用者に通知している間に、当該選択端末の状態がビジー状態に遷移した場合には、その旨が上記レディー遷移検出通知とは異なる態様で利用者に通知されることになる。
【００２２】
さらに、上記通信端末は、第１の態様での通知手段の作動時に利用者による通話に関わる特定操作がなされると、通信手段を介して端末選択手段によって選択された特定端末との通話通信接続を開始するための第３の制御手段をさらに含む。
【００２３】
上記構成において、上記第１の態様での通知時に利用者による通話に関わる特定操作がなされると、これを契機に選択された特定端末との通話通信接続が開始される。したがって、選択端末の状態がレディー状態に遷移した旨が通知されている間に、通話に関わる特定操作がなされると、これを契機にその選択端末に対する発呼が行なわれることになる。
【発明の効果】
【００２４】
本発明では、相手端末の状態を利用者自身の端末に表示することによって当該相手端末の状態が常時把握できる状態にしておいて、相手端末の状態が変化したときにその旨が利用者に通知される。そのため、利用者は、通話通信したい相手端末の状態を常に確認する必要がなくなる。その結果、相手端末の状態が通話通信可能な状態になったときに、利用者は直ぐに当該相手端末に通話連絡をすることができる。
【発明を実施するための最良の形態】
【００２５】
以下、本発明の実施の形態について、添付図面に基づき詳細に説明する。
【００２６】
[相手端末通話予約システムの構成]
図１は本発明の実施の形態に係る相手端末通話予約システム１００の構成を簡略化して示す図である。
【００２７】
図１を参照して、本実施の形態に係る相手端末通話予約システム１００は、公衆回線網２００に接続される交換機３００，４００と、公衆回線網又はインターネット等の通信回線網５００，６００を介して交換機３００，４００にそれぞれ接続される基地局７００，８００と、これら基地局７００又は８００、交換機３００又は４００及び公衆回線網２００を介して互いに接続可能な通信端末９００Ａ，９００Ｂ，９００Ｃと、公衆回線網２００に接続されたメールサーバ１０００と、メールサーバ１０００に接続されたＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）１１００とを含む。
【００２８】
図１に示す例では、通信端末９００Ａ及び通信端末９００Ｂの両者は、基地局７００及び通信回線網５００を介して交換機３００に接続されている。他方、通信端末９００Ｃは、通信回線網６００を介して交換機４００に接続されている。
【００２９】
交換機３００と交換機４００とは、公衆回線網２００を介して接続されており、それによって両交換機３００，４００同士の間で相互にデータの送受が可能とされている。
【００３０】
[交換機３００の構成]
図２は交換機３００の構成を示すブロック図である。
【００３１】
図２を参照して、交換機３００は、相手端末への通話予約を受付ける機能を有している。この交換機３００には、通信端末９００Ａ，９００Ｂ，９００Ｃを１つのグループを構成するメンバ端末としてグループ管理して当該通信端末９００Ａ，９００Ｂ，９００Ｃに対して通話予約サービスを提供する管理サーバ３０２と、この管理サーバ３０２にアクセスした各通信端末９００Ａ，９００Ｂ，９００Ｃの管理サービスの対象となる情報を蓄積する端末情報記憶装置（以下、単に「ＨＤＤ」と称する）３０４とが備えられている。
【００３２】
管理サーバ３０２は、その制御中枢を司り実質的にコンピュータからなるサーバ制御部３０６と、通信回線網５００及び公衆回線網２００の両者並びにサーバ制御部３０６に接続される端末接続・通信装置３０８とを含む。
【００３３】
サーバ制御部３０６は、何れも図示しないＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）及びＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等から構成され、このサーバ制御部３０６には、端末情報記憶装置としてのＨＤＤ３０４が接続されている。
【００３４】
＜ＨＤＤ３０４の構成＞
図３はＨＤＤ３０４内の記憶域の構成を図解的に示す図である。
【００３５】
図３を参照して、ＨＤＤ３０４には、上記管理サーバ３０２の相手端末への通話予約サービスを利用した（換言すると、管理サーバ３０２にアクセスした）通信端末に関する情報を端末毎に記憶する領域（端末Ａの記憶域、端末Ｂの記憶域、端末Ｃの記憶域…端末ｎの記憶域）が形成されている。
【００３６】
例えば、端末Ａの記憶域は、自端末情報記憶部及びメンバ端末情報記憶部を備えている。自端末情報記憶部には、端末Ａ自身に関する種々の情報が格納されており、特に、時々刻々変化する端末Ａとしての通信端末９００Ａ自身の状態を示す変数ＭＯＤＥの値が格納される。メンバ端末情報記憶部には、端末Ａとしての通信端末９００Ａと共に１つのグループを形成する他のメンバ端末情報の記憶アドレスを指すポインタＭＥＭ１，ＭＥＭ２，ＭＥＭ３…ＭＥＭｎが格納される。これら自端末情報記憶部及びメンバ端末情報記憶部にそれぞれ格納された変数ＭＯＤＥ値及び記憶アドレスポインタＭＥＭ１〜ＭＥＭｎは、端末Ａとしての通信端末９００Ａを一意に識別する識別情報としてのＩＤ（Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）をパラメータとして、サーバ制御部３０６に一括して管理される。上記ＭＯＤＥ値が「０」の場合には、端末Ａとしての通信端末９００Ａ自身の状態がレディー（着呼ＯＫ）状態であり、上記ＭＯＤＥ値が「１」の場合には、端末Ａとしての通信端末９００Ａ自身の状態がビジー（着呼ＮＧ）状態である。勿論、他の端末Ｂ〜ｎの各記憶域も上記端末Ａの記憶域の構成と同様に構成されている。
【００３７】
なお、通信端末９００Ａ，９００Ｂ，９００Ｃは共に同一の機能を有しているので、以下の説明においては、説明の便宜上、通信端末９００Ａ，９００Ｂ，９００Ｃを「通信端末９００」と称する。
【００３８】
[通信端末９００の構成]
＜通信端末９００の外観構成＞
図４は通信端末９００の外観構成を示す平面図である。
【００３９】
図４を参照して、通信端末９００は、携帯電話又はＰＨＳであって、操作部９０４及び表示部９０６から構成された通信端末本体９０２を含む。操作部９０４には、テンキー９０８、モード変更ボタン９１０、メールボタン９１２、電源ボタン９１４、通話開始ボタン９１６、通話終了ボタン９１８、一覧ボタン９２０及びカーソルキー９２２が備えられている。表示部９０６には、ディスプレイ９２４が備えられている。
【００４０】
テンキー９０８は、電話番号、メールアドレス等のアクセスコード及び文字等の入力時に操作されるキーであって、操作部９０４のほぼ中央部に配置されている。
【００４１】
モード変更ボタン９１０は、本通信端末９００の状態を、レディー状態である通常モードからビジー状態となる特定端末着呼拒否モードに切替える、又はビジー状態である特定端末着呼拒否モードからレディー状態となる通常モードへ切替える際に操作されるボタンである。ここに、「特定端末着呼拒否モード」とは、上記管理サーバ３０２により管理される同じグループに属する他のメンバ端末からの着呼（呼出）を受付けないようにするモードをいう。メールボタン９１２は、メールを送信若しくは返信する、又は受信メールの内容を確認する際等に操作されるボタンである。電源ボタン９１４は、本通信端末９００をオン又はオフする際に操作されるボタンである。これらのモード変更ボタン９１０、メールボタン９１２及び電源ボタン９１４は、上記テンキー９０８の左側において、上から下に向かってこの順に配置されている。
【００４２】
通話開始ボタン９１６は、通話を開始する際に操作されるボタンである。通話終了ボタン９１８は、通話を終了する際に操作されるボタンである。一覧ボタン９２０は、ディスプレイ９２４の表示面上において、管理サーバ３０２によりグループ管理される他のメンバ端末に関する情報をその端末ＩＤと対応付けて一覧表示させる、又はこの一覧表示を終了させる際に操作されるボタンである。なお、このディスプレイ９２４の表示面での一覧表示の内容については後述する。カーソルキー９２２は、ディスプレイ９２４の表示画面上でカーソルを上下左右に移動させる際に操作されるキーであって、その中央部に確定ボタン９２２Ａを有する。これらの通話開始ボタン９１６、通話終了ボタン９１８、一覧ボタン９２０及びカーソルキー９２２は、上記テンキー９０８の右側において、上から下に向かってこの順に配置されている。
【００４３】
表示部９０６に嵌め込まれたディスプレイ９２４の表示面には、通信に関する種々の情報が表示される。表示部９０６は、ディスプレイ９２４の表示面を上に向けた状態で操作部９０４に対して矢印Ｘ１及びＸ２により示される方向にスライド自在に装着されている。つまり、表示部９０６は、矢印Ｘ１方向に沿ってスライド移動させると、図４において実線で示すようにテンキー９０８を露呈させてその操作が可能な第１の姿勢となる。矢印Ｘ２に沿ってスライド移動させると、図４において仮想線で示すようにテンキー９０８を覆いその操作が不可能な第２の姿勢となる。それゆえ、利用者は、表示部９０６が第１及び第２の姿勢の何れの姿勢でも、本通信端末９００が稼動中であればディスプレイ９２４の表示内容を常時視認することができる。
【００４４】
＜一覧表示の内容＞
図５はディスプレイ９２４上での一覧表示の一例を示す図である。
【００４５】
図５を参照して、上記一覧ボタン９２０の表示操作がなされると表示部９０６のディスプレイ９２４の表示面上にグループメンバとその端末状態の一覧表示が実行される。この一覧表示では、自端末と同グループに属する他のメンバ端末の利用者の名前、その端末固有のＩＤとしての電話番号、及びその端末状態（ＢＵＳＹ又はＲＥＡＤＹ）が互いに関連付けた表示がなされる。
【００４６】
＜通信端末９００の電気的構成＞
図６は通信端末９００の電気的構成を示すブロック図である。
【００４７】
図６を参照して、通信端末９００は、その制御中枢を司る実質的にコンピュータからなる制御部９３０を含む。
【００４８】
制御部９３０は、何れも図示しないＣＰＵ、ＲＯＭ及びＲＡＭ等から構成される。制御部９３０には、アドレス帳記憶装置９３２、端末ＩＤ記憶装置９３４、相手端末状態通知パターン記憶装置９３６、通信装置９３８、入力装置９４０、表示装置９４２、音入力装置９４４、音出力装置９４６及び振動出力装置９４８が接続されている。
【００４９】
アドレス帳記憶装置９３２は、通信端末９００と同じグループに属する他のメンバ端末の利用者の名前、その端末固有の電話番号（端末ＩＤ）、その端末のメールアドレス及び会社名等を記憶するための装置である。なお、このメンバアドレス帳データの構成については後述する。
【００５０】
端末ＩＤ記憶装置９３４は、自端末の識別ＩＤとしての電話番号を記憶するための装置であって、この端末ＩＤ記憶装置９３４には、本通信端末９００自身の電話番号（端末ＩＤ）が格納されている。
【００５１】
相手端末状態通知パターン記憶装置９３６は、本通信端末９００から通話通信相手先として指定された他のメンバ端末の状態を通信端末９００の利用者の聴覚及び触覚に訴える態様で通知するための通知パターンを記憶するための装置である。相手端末状態通知パターン記憶装置９３６には、通知パターンデータとして、相手端末の状態及びその変化パターン（遷移パターン）に応じた複数の通知パターンが登録される。なお、この通知パターンデータの構成については後述する。
【００５２】
これらの記憶装置９３２，９３４及び９３６としては、電気的にデータの書き換えが可能な不揮発性フラッシュメモリが使用されている。
【００５３】
通信装置９３８は、何れも図示しないアンテナ、ＲＦ（Ｒａｄｉｏ Ｆｒｅｑｕｅｎｃｙ）部、変調部及び復調部等を含む。
【００５４】
入力装置９４０は、図示しない入力コントローラ、並びに図４に示す操作部９０４上の各種のキー及びボタン９０８，９１０，９１２，９１４，９１６，９１８，９２０及び９２２等を含む。
【００５５】
表示装置９４２は、図示しないディスプレイコントローラ、及び図４に示す表示部９０６に備えられたディスプレイ９２４等を含む。
【００５６】
音入力装置９４４は、何れも図示しないマイクロフォン及び音入力データ処理部等を含む。
【００５７】
音出力装置９４６は、何れも図示しないスピーカ及び音出力データ処理部等を含む。
【００５８】
振動出力装置９４８は、図４に示す通信端末本体９０２の特定部位（例えば、操作部９０４）に振動を与えるための装置であって、何れも図示しないバイブレータ及びその駆動源となる振動モータ等を含む。
【００５９】
＜メンバアドレス帳データの構成＞
図７はアドレス帳記憶装置９３２に記憶されるメンバアドレス帳データの構成の一例を示す図である。
【００６０】
図７を参照して、上記メンバアドレス帳データには、本システム１００による通話予約サービスの提供を受ける通信端末９００と同一のグループに属する他のメンバ端末の利用者の名前、その端末の電話番号（端末ＩＤ）、その端末のメールアドレス及び会社名等が含まれている。このメンバ端末アドレス帳データでは、上記の名前、端末ＩＤ、メールアドレス及び会社名等が図示しないメモリＮo等の特定コードに対応付けて、リレーショナルデータ化（テーブル化）される。
【００６１】
＜通知パターンデータの構成＞
図８は相手端末状態通知パターン記憶装置９３６に記憶される通知パターンデータの構成の一例を示す図である。
【００６２】
図８を参照して、上記通知パターンデータには、振動と音とを組合せて出力することによって本通信端末９００により通話通信相手として指定選択されたメンバ端末の状態及びその状態の変化を通知するためのパターンとして、パターンＡ、パターンＢ及びパターンＣが含まれている。
【００６３】
パターンＡは、通常周期振動（ブ〜ルブ〜ルブ〜ルブ〜ルブ〜ルブ〜ルブ〜ル）と着信メロディ（本通信端末９００の利用者により発呼者に応じて設定されたメロディ）とを組合せた通知パターンである。本通信端末９００がＭＯＤＥ＝「０」（レディー状態）のときに他の端末からの着呼があった場合、及びＭＯＤＥ＝「１」（ビジー状態）のときにグループ外の端末からの着呼があった場合に、その旨を利用者に通知するためのパターンである。音出力装置９４６及び振動出力装置９４８の両者がパターンＡに則して稼動されることによって、着呼があったことが利用者に通知される。
【００６４】
パターンＢは、高速周期振動（ブルブルブルブル＊＊ブルブルブルブル）とベル音（高音：リンリンリンリン）とを組合せた通知パターンである。通信端末９００は、同一グループの他端末に対して発呼したとき、相手端末がビジー状態であるときには一旦発呼を中止し、相手端末がレディー状態になるまで待機する。この待機中に相手端末の状態がレディー状態に変化したとき、音出力装置９４６及び振動出力装置９４８の両者がパターンＢに則して稼動させられる。パターンＢによる通知があったことによって、利用者には、相手端末がビジー状態からレディー状態に変化したことがわかる。このように状態がレディー状態に変化したことを利用者に通知することにより、利用者は相手に何度もかけたりする必要がなくなる。それゆえ、利用者は、単に、このパターンＢによる通知がされるまで待機すればよい。
【００６５】
パターンＣは、高低繰返振動（ブ〜〜ルブ〜〜ル＊＊ブ〜〜ルブ〜〜ル）とビープ（低音：ブーブーブーブー）とを組合せた通知パターンである。上記パターンＢでの通知があった後、利用者が通話開始ボタン９１６を操作して相手に対して発呼する前に、相手端末がビジー状態に再度変化した場合に、音出力装置９４６及び振動出力装置９４８の両者がパターンＣに則して稼動されることによって利用者に対し相手端末が再びビジー状態となったことが通知される。
【００６６】
[相手端末通話予約システム１００のソフトウェア構成]
＜通信端末９００側のソフトウェア構成＞
本通信端末９００側は、以下のようにプログラミングされている。
【００６７】
（１）一覧表示から選択されたメンバ端末に対して発呼を試みたときに、最初に交換機にアクセスし、相手のメンバ端末の状態がビジー（通話ＮＧ）状態かレディー（通話ＯＫ）状態かを調べる。レディー状態のときには、直ちに相手端末に対し発呼する。ビジー状態のときには、発呼は行なわず、ビジー状態からレディー状態に変化するまで待機する。そして、相手端末がレディー状態に変化すると、その旨を利用者に対しパターンＢで通知する。
【００６８】
（２）上記したように、選択されたがビジー状態である相手端末について、上記したパターンＢでの通知が開始された後、利用者が実際の発呼をするまでの間に相手の状態が再びビジー状態に変化したときには、その旨をパターンＣで通知する。
【００６９】
（３）自端末がレディー状態にあるとき、又は同一グループに属さない通信端末から着信があった場合には、パターンＡでの着信があったことを利用者に通知する。
【００７０】
このプログラムは、通信端末９００の制御部９３０内のＲＯＭに記憶されており、次に説明する通信端末９００の種々の機能を実現する。これらの機能の実現は、上記の実質的にはコンピュータである制御部９３０が上記のプログラムを実行することによって達成される。
【００７１】
図９〜図１０は相手端末通話予約システム１００に適用される通信端末９００の機能を実現するプログラムの制御の流れを示すフローチャートである。
【００７２】
図９を参照して、本通信端末９００では、電源ボタン９１４の端末オン操作がなされると、初期設定として自身の端末状態をレディー（着呼ＯＫ）状態とする。すなわち、自端末の状態を示す変数ＭＯＤＥに「０」を代入する（ステップＳ１００）。
【００７３】
次に、制御部９３０は、待受画面をディスプレイ９２４上に表示させる（ステップＳ１０２）。
【００７４】
続いて、制御部９３０は、通信装置９３８を介して、自端末の状態（モード）が変更された旨を管理サーバ３０２に通知する（ステップＳ１０４）。このときに管理サーバ３０２に送信される自端末モード変更通知メッセージは、モード変更したことを示す所定のキーワード「ＭｏｄｅＣｈａｎｇｅ」（即ち、自端末モード変更通知コマンド）、自端末ＩＤ（電話番号）、及び変更後の端末状態を示す変数ＭＯＤＥの値を含む。端末の電源オン直後には、変数ＭＯＤＥの値は「０」であり、その値が管理サーバ３０２に通知される。
【００７５】
その後、制御部９３０は、モード変更ボタン９１０が操作されたか否かを判定する（ステップＳ１０６）。モード変更ボタン９１０が操作された場合には、制御部９３０は、変数ＭＯＤＥの値をトグルする。すなわち、変数ＭＯＤＥの値が「０」であるときには「１」に、「１」であるときには「０」に、それぞれ変数ＭＯＤＥの値を変更する（ステップＳ１２２）。その後、制御部９３０は、制御を再びステップＳ１０４に制御を戻す。
【００７６】
モード変更ボタン９１０が操作されなかったとステップＳ１０６で判定された場合には、制御はステップＳ１０８に進む。ステップＳ１０８において、制御部９３０は、一覧ボタン９２０が操作されたか否かを判定する。一覧ボタン９２０が操作された場合には、制御部９３０は、制御を図１０に示すステップＳ１３４に移す。一覧ボタン９２０が操作されなかった場合には、制御部９３０は、制御をステップＳ１１０に移す。
【００７７】
ステップＳ１１０では、制御部９３０は、他の端末からの着呼があったか否かを判定する。他の端末からの着呼がない場合には、制御はステップＳ１０６に戻る。他の端末からの着呼があった場合には、制御はステップＳ１１２に移る。
【００７８】
ステップＳ１１２では、変数ＭＯＤＥの値が「０」か否かを判定する。変数ＭＯＤＥの値が「０」であれば、着呼があり、かつ自端末がレディー状態であるということであり、制御部９３０は、音出力装置９４６及び振動出力装置９４８の両者を共にパターンＡにしたがって稼動させて着呼があったことを利用者に通知する（ステップＳ１１４）。すなわち、この着呼通知は、通常周期振動と着信メロディとを組合せた態様で実行される。ステップＳ１１２において変数ＭＯＤＥの値が「１」であると判定された場合、同一グループのメンバ端末からの呼出か否かが判定される（ステップＳ１２４）。この判定は、着呼に伴う相手端末のＩＤが、アドレス帳記憶装置９３２に記憶されたメンバアドレス帳中に存在しているか否かによって行なわれる。
【００７９】
着呼が通信端末９００と同じグループに属するメンバ端末からのものであると判定されると、制御はステップＳ１０４に戻る。着呼がメンバ端末以外の端末からのものであると判定されると、制御はステップＳ１１４に移る。ステップＳ１１４においては、パターンＡでの着呼通知が行なわれる。利用者は、もしもこの着呼に応答するのであれば、通話開始ボタン９１６を操作すればよい。
【００８０】
制御部９３０は、パターンＡによる着呼通知を実行している間に、通話開始ボタン９１６の操作又は発呼側端末からの着呼終了を待つ（ステップＳ１１６及びＳ１１８）。通話開始ボタン９１６が操作される前に着呼が終了した場合には、制御部９３０は、パターンＡでの着呼通知を停止し（ステップＳ１２０）、制御をステップＳ１０４に戻す。着呼が終了する前に通話開始ボタン９１６が操作された場合には、制御はステップＳ１２６に進み、パターンＡでの着呼通知が停止される。さらに、変数ＭＯＤＥの値を変更せず、自端末状態がビジー状態になった（即ち、通話中である）旨を管理サーバ３０２に通知する（ステップＳ１２８）。制御部９３０は、オフフック処理等を含む通話接続制御を行なって（ステップＳ１３０）通話を開始させ、通話終了を待つ（ステップＳ１３２）。通話が終了すると、制御部９３０は、制御をステップＳ１０４に戻す。なお、制御部９３０により通話終了と判断される態様としては、自端末側での通話終了ボタン９１８の操作、相手端末側からの通話終了信号の受信、及び接続エラーが所定時間続きそれによって相手端末と接続できない状態が継続する等の態様を挙げることができる。
【００８１】
ステップＳ１００〜ステップＳ１３２の一連の制御は、電源ボタン９１４の端末オフ操作がなされない限り、繰返し実行される。
【００８２】
図９のステップＳ１０８において、一覧ボタン９２０の一覧表示操作がされた場合、制御は図１０のステップＳ１３４に移行する。ステップＳ１３４では、ディスプレイ９２４上に通信端末９００と同じグループに属する他のメンバ端末に関する情報の先頭ページ（即ち、１ページ目）の画面を作成し、一覧表示させる。この一覧表示画面では、図５に示すように、他のメンバ端末の利用者の名前、その端末固有のＩＤとしての電話番号、及びその端末の状態が互いに関連付けられて表示される。
【００８３】
続いてステップＳ１３６において、ステップＳ１３４で表示された１ページ目の一覧表示画面の最上位に表示されているメンバ端末を選択状態にする。
【００８４】
その後、ステップＳ１３８において、制御部９３０は、現在一覧表示中のメンバ端末の各々に関し、その端末状態を送信するよう管理サーバ３０２に対し送信要求を、通信装置９３８を介して送信する。ここでは、自端末ＩＤ及び各メンバ端末ＩＤを付した「ＧｅｔＭｏｄｅ」コマンド（以下、「端末状態送信要求コマンド」という）が管理サーバ３０２に送信される。管理サーバ３０２は、この送信要求コマンドに含まれる通信端末９００自身の端末ＩＤと各メンバ端末の端末ＩＤとの組合せをキーとして管理サーバ３０２専用のＨＤＤ３０４の端末ＩＤの記憶域を参照し、該当するメンバ端末の状態を読出して本通信端末９００に送信する。制御部９３０は、その管理サーバ３０２から送信されてきた値を管理サーバ３０２から通信装置９３８を介して受信する。そしてステップＳ１４０において、一覧表示中の各メンバ端末の状態表示が、送信されてきた値により更新される。
【００８５】
メンバ端末状態表示の更新処理が終了すると、制御部９３０は、ページ切替操作、相手端末の選択変更操作、一覧表示終了操作及び通話開始操作の何れかの操作がなされたかを順番に判定する（ステップＳ１４２、Ｓ１４４、Ｓ１４６及びＳ１４８）。
【００８６】
端末状態表示更新後の次の操作として、カーソルキー９２２の操作によりカーソルを左右に移動させるページ切替操作がなされた場合（ステップＳ１４２においてＹＥＳ）には、制御部９３０は、現在表示されているページの次のページ又は前のページに登録されているメンバ端末に関する情報をディスプレイ９２４上に一覧表示させる（ステップＳ１５０）。さらに、制御部９３０は、表示されたページの一覧の最上位に表示されているメンバ端末を上記ステップＳ１３６と同様にして選択状態とする（ステップＳ１５２）。その後、制御部９３０は、制御をステップＳ１３８に戻す。
【００８７】
カーソルを上下に移動させる操作がされた場合（ステップＳ１４４においてＹＥＳ）には、制御部９３０は、カーソルの移動にしたがって、現在選択中の１つ前又は後の端末を上記ステップＳ１３６と同様にして選択状態とする（ステップＳ１５４）。その後、制御部９３０は、制御をステップＳ１３８に戻す。
【００８８】
一覧ボタン９２０の一覧表示終了操作がされたと判定された場合（ステップＳ１４６においてＹＥＳ）には、制御部９３０は、メンバ端末の一覧表示を終了させ、制御を図９に示すステップＳ１０２に戻す。
【００８９】
通話開始ボタン９１６が操作された場合（ステップＳ１４８においてＹＥＳ）には、制御部９３０は、制御を図１１に示すステップＳ１５６に移す。
【００９０】
上記の何れの操作も行なわれない場合（ステップＳ１４２、Ｓ１４４、Ｓ１４６及びＳ１４８において共にＮＯ）には、制御部９３０は、制御をステップＳ１３８に戻す。換言すると、上記のステップＳ１４２〜ステップＳ１４８の各操作判定処理は、カーソルキー９２２、一覧ボタン９２０及び通話開始ボタン９１６のうち何れかの操作がなされるまで繰返し実行される。
【００９１】
図１１を参照して、メンバ端末一覧表示画面上で通話通信相手となるメンバ端末の選択が行なわれ、この選択されたメンバ端末に対する通話開始操作がされると、ステップＳ１５６において、制御部９３０は、現在選択中のメンバ端末に関する端末状態を、端末状態送信要求コマンドによって通信装置９３８を介して管理サーバ３０２に要求する（即ち、現在選択中のメンバ端末ＩＤを付した端末状態送信要求コマンドを管理サーバ３０２に送信する）と共にそのリターン値を管理サーバ３０２から通信装置９３８を介して受信する。
【００９２】
その後、制御部９３０は、管理サーバ３０２から受信した変数ＭＯＤＥのリターン値に基づいて、選択中のメンバ端末の状態がビジー（通話ＮＧ）状態か否かを判別する（ステップＳ１５８）。選択メンバ端末に関する変数ＭＯＤＥのリターン値が「０」であって当該選択メンバ端末がレディー（通話ＯＫ）状態であると判別した場合には、制御部９３０は、オフフック処理及び発呼処理等の選択中のメンバ端末との通話接続制御を行なって通話を開始させ、通話の終了まで待機する（ステップＳ１８０及びＳ１８２）。通話が終了すると、制御は図９に示すステップＳ１０２に戻る。
【００９３】
選択されたメンバ端末に関する変数ＭＯＤＥのリターン値が「１」の場合、制御はステップＳ１６０及びＳ１６２に進み、選択されたメンバ端末の状態がビジー状態からレディー状態へ遷移するまで、選択中のメンバ端末に関する端末状態送信要求コマンドを管理サーバ３０２に送信すると共にそのリターン値を管理サーバ３０２から受信する処理を実行し続ける。
【００９４】
選択中のメンバ端末の状態がレディー状態に遷移すると、制御部９３０は、音出力装置９４６及び振動出力装置９４８の両者を共にパターンＢにしたがって稼動させてその旨を本通信端末９００の利用者に通知する（ステップＳ１６４）。すなわち、この通知は、高速周期振動とベル音（高音）とを組合せた態様で実行される。これにより、この端末の利用者は、相手端末がレディー状態に変化したことを知ることができる。
【００９５】
パターンＢでの通知中に通話開始ボタン９１６が操作された場合（ステップＳ１６６においてＹＥＳ）には、制御部９３０は、当該パターンＢでの通知を停止し（ステップＳ１８４）、制御をステップＳ１８０に戻して選択中のメンバ端末との通話接続制御処理を実行する。したがって、利用者は相手端末との通話を開始できる。
【００９６】
パターンＢでの通知中に通話開始ボタン９１６が操作されない場合（ステップＳ１６６においてＮＯ）には、制御部９３０は、現在選択中のメンバ端末に関する端末状態をその送信を要求するコマンド（ＧｅｔＭｏｄｅコマンド）によって管理サーバ３０２に要求し、そのリターン値を管理サーバ３０２から受信する（ステップＳ１６８）。受信した変数ＭＯＤＥのリターン値に基づき当該選択メンバ端末の状態がレディー状態から再度ビジー状態に遷移したか否かを判定する（ステップＳ１７０）。判定結果がＹＥＳの場合には制御はステップＳ１８６に進み、それ以外の場合には制御はステップＳ１７８に進む。
【００９７】
ステップＳ１７８では、パターンＢでの通知開始後、一定時間が経過したか否かを判定し、経過していない場合には制御はステップＳ１６６に戻る。一定時間が経過すると、制御は図１０に示すステップＳ１３８に進む。すなわち、この選択メンバ端末に対するモニター処理は、パターンＢでの通知が開始されてから一定時間が経過するまで繰返し実行される。
【００９８】
その間に、選択中のメンバ端末の状態がレディー状態から再びビジー状態へと遷移すると（ステップＳ１７８においてＮＯ、ステップＳ１６６においてＮＯ、かつステップＳ１７０においてＹＥＳ）、制御はステップＳ１８６に進む。ステップＳ１８６では、制御部９３０は、規定時間が経過するまでの間、音出力装置９４６及び振動出力装置９４８の両者を共にパターンＣにしたがって稼動させる。この結果、利用者に対し、一旦レディー状態に遷移した相手端末が再びビジー状態となったことが通知される。この通知は、高低繰返振動とビープ（低音）とを組合せた態様で実行される。その後、制御は、ステップＳ１６０に戻る。これに対し、上記一定時間経過するまでに選択中のメンバ端末の状態がビジー状態に遷移することなく、かつ途中で通話ボタンが操作されることなくレディー状態のままであると（ステップＳ１７０においてＮＯ、ステップＳ１６６においてＮＯ、かつステップＳ１７８においてＹＥＳ）、制御部９３０は、制御を図１０に示すステップＳ１３８に戻す。
【００９９】
＜管理サーバ３０２側のソフトウェア構成＞
管理サーバ３０２は、このサービスを利用している通信端末から自端末モード変更通知コマンドを含む通知を受けると、そのメンバ端末の状態を更新することにより、このサービスを利用している全ての通信端末の状態を常に管理するようにプログラミングされている。管理サーバ３０２はさらに、このサービスを利用している通信端末から、その通信端末と同一グループに属する他の通信端末のＩＤを指定して端末状態送信要求コマンドを含む要求があると、指定されたＩＤを持つ通信端末の状態を、端末状態送信要求コマンドを送信してきた通信端末に返信するようにプログラミングされている。このプログラムは、管理サーバ３０２の制御部３０６内のＲＯＭに記憶されており、次に説明する管理サーバ３０２の種々の機能を実現する。これらの機能の実現は、上記の実質的にはコンピュータである制御部３０６が上記のプログラムを実行することによって達成される。
【０１００】
図１２は相手端末通話予約システム１００において使用される管理サーバ３０２の機能を実現するプログラムの制御の流れを示すフローチャートである。
【０１０１】
図１２を参照して、このサービスを受けている何れかの通信端末から端末接続・通信装置３０８を介して何らかのメッセージを受信すると、管理サーバ３０２の制御部３０６は、受信したメッセージにコード化された自端末モード変更通知コマンド又は端末状態送信要求コマンドが含まれているか否かを判定する（ステップＰ５００及びＰ５０２）。
【０１０２】
受信したメッセージに自端末モード変更通知コマンドが含まれている場合（ステップＰ５００においてＹＥＳ）には、制御部３０６は、この自端末モード変更通知コマンドに含まれる、このコマンドを送信してきた端末ＩＤ（電話番号）をキーにして図３に示すその端末の記憶域を特定し、そこに記憶されている変数ＭＯＤＥの値を、送信されてきた値により変更する（ステップＰ５０８）。すなわち、自端末モード変更通知コマンドと共に送信されてきた値が「１」であれば、該当する端末の変数ＭＯＤＥの内容が「１」に変更され、「０」であれば「０」に変更される。その後、制御部３０６は、制御をステップＰ５００及びＰ５０２に戻して次のメッセージ受信に備える。
【０１０３】
受信メッセージに端末状態送信要求コマンドが含まれている場合（ステップＰ５０２においてＹＥＳ）には、制御はステップＰ５０４に進む。ステップＰ５０４では、制御部３０６は、端末状態送信要求コマンドによって指定された端末ＩＤを持つ通信端末が、端末状態送信要求コマンドを送信してきた通信端末と同じグループに属するか否かを判定し、判定結果にしたがって制御を分岐させる。すなわち、この判定結果がＹＥＳであれば制御はステップＰ５０６に、ＮＯであれば制御はステップＰ５１０に進む。ステップＰ５０４における判定は、端末状態送信要求コマンドを送信してきた端末に対応する記憶域のメンバ端末情報記憶部内に、端末状態の送信が要求された通信端末のＩＤが記憶されているか否かによって行なわれる。
【０１０４】
端末状態送信要求コマンドにより端末状態の送信が要求された端末が端末状態送信要求コマンドの送信元の端末と同じグループに属すると判定されると、ステップＰ５０６において、制御部３０６は、端末状態の送信が要求された端末の状態を示すＭＯＤＥ値を端末状態送信要求コマンドの送信元端末に送信する。具体的には、制御部３０６は、ＨＤＤ３０４内の、端末状態要求コマンドを送信してきた通信端末に対応する記憶域のメンバ端末情報記憶部に記憶されているポインタにしたがって、端末状態の送信が要求された端末に対応する記憶域の自端末情報記憶部にアクセスすることによって、当該端末の現在のＭＯＤＥ値を読出す。この値が端末状態送信要求コマンドを送信してきた通信端末に対し返信される。この後、制御はステップＰ５００に戻る。
【０１０５】
これに対し、端末状態の送信が要求された端末が端末状態送信要求コマンドの送信元端末と同じグループに属さないと判定されると（ステップＰ５０４においてＮＯ）、制御部３０６は、エラーを示す戻り値「−１」を端末状態送信要求コマンドの送信元端末に送信する（ステップＰ５１０）。その後、制御はステップＰ５００に戻る。
【０１０６】
アクセス要求信号に自端末モード変更通知コマンド及び端末状態送信要求コマンドの何れも含まれていない場合（ステップＰ５００及びＰ５０２において共にＮＯ）には、制御部３０６は、受信したメッセージにしたがって図示しない他の処理を行ない、制御をステップＰ５００に戻す。
【０１０７】
［動作］
相手端末通話予約システム１００は以下のように動作する。
【０１０８】
通信端末９００は、電源が投入されると自己の変数ＭＯＤＥの値を「０」に初期化し、誰からの着呼でも受付ける状態とする。そして、待受画面を表示した後、管理サーバ３０２に対し、自分自身のＩＤを指定した自端末モード変更通知コマンドを含む自端末モード変更通知メッセージを送信し、サーバ側で管理されている自分のＭＯＤＥ値を「０」とする。
【０１０９】
以後、利用者がモード変更ボタン９１０を操作する度に、変数ＭＯＤＥの値を「０」から「１」に、「１」から「０」に、それぞれトグルさせ、その度に管理サーバ３０２に対して変数ＭＯＤＥの値の変更を自端末モード変更通知メッセージにより通知する。
【０１１０】
管理サーバ３０２側では、このサービスを受ける通信端末からの自端末モード変更通知メッセージに基づき、それらのＭＯＤＥ値（「０」ならレディー（通話ＯＫ）状態、「１」ならビジー（通話ＮＧ）状態）を常に管理する。
【０１１１】
通信端末９００側では、同じグループに属する他のメンバ端末に対する発呼要求があった場合、相手端末の状態を発呼前に管理サーバ３０２から取得し、その結果に応じた処理を行なう。
【０１１２】
すなわち、発呼要求があったメンバ端末の状態がビジー状態であるときには、通信端末９００は、発呼先のメンバ端末がレディー状態になるまで、管理サーバ３０２に対して端末状態送信要求を繰返し送信することにより発呼先のメンバ端末の状態の監視を続け、その端末状態がレディー状態に変化した時点で、高速周期振動及びベル音（高音）の両者を組合せたパターンＢによりその旨を通知する。
【０１１３】
パターンＢでの通知中に利用者が通話開始ボタン９１６を操作すると、通信端末９００は、パターンＢでの通知を停止し、相手のメンバ端末に対し実際の発呼を行なう。
【０１１４】
通信端末９００は、パターンＢでの通知を行なっている間にも、管理サーバ３０２に対して端末状態送信要求コマンドを繰返し送信することにより、発呼対象のメンバ端末がレディー状態からビジー状態に遷移したか否かの監視を続ける。発呼対象のメンバ端末が再度ビジー状態に遷移した際には、通信端末９００は、高低繰返振動及びビープ（低音）の両者を組合せたパターンＣにより、一定時間その旨の通知を行なう。パターンＢでの通知中に相手端末がビジー状態に遷移せずに一定時間経過すると、パターンＢでの通知を停止して、一覧表示に戻る。
【０１１５】
通信端末９００に対し、他の通信端末から着呼があった場合、自己の変数ＭＯＤＥの値を調べ、その値が「０」であれば、無条件でパターンＡにしたがって音出力装置９４６及び振動出力装置９４８とを用いて着呼があったことを利用者に通知する。変数ＭＯＤＥの値が「０」以外（即ち、「１」のとき）には、相手の通信端末が同一グループに属すか否かを調べる。相手が同一グループに属さないものであるときには、変数ＭＯＤＥの値が「０」である場合と同様の動作をする。変数ＭＯＤＥの値が「１」であるときには、この着呼を無視する。
【０１１６】
通話を開始する場合には、着信拒否のモードにするわけではないので、変数ＭＯＤＥの値は「０」のまま変更せず、管理サーバ３０２に自端末モード変更通知メッセージとして「１」を通知することで、当該サーバ３０２における、通信端末９００のＭＯＤＥ値を「１」とする。
【０１１７】
＜作用・効果＞
本実施の形態によると、以下の作用・効果を奏する。
【０１１８】
（１）通信端末９００側では、電源オン操作に伴う稼動中、メンバ端末の一覧表示を選択すると、当該通信端末９００と同一グループに属するメンバ端末の状態が管理サーバ３０２より取得され、表示される。利用者は、表示されている複数のメンバ端末から１つのメンバ端末を、その状態がレディーかビジーかにかかわらず、任意に選択することができる。選択されたメンバ端末がレディー状態であれば、直ぐに発呼及び通話が可能である。選択されたメンバ端末がビジー状態であれば、通信端末９００はすぐには発呼を行なわず、管理サーバ３０２における選択された端末の状態を監視する。相手端末の状態がビジー状態からレディー状態へと変化すると、通信端末９００側は、これをパターンＢで利用者に通知する。したがって、選択メンバ端末がビジー状態であるときには、当該端末がレディー状態になるまで待機し、ビジー状態からレディー状態への遷移が検出されると、その旨がパターンＢにしたがう音声及び振動で利用者に通知されることになる。利用者は、ビジー状態の端末を選択した場合、パターンＢでの通知がされるまで待機し、パターンＢの通知がされたときに実際の発呼を行なえばよい。音声及び振動で、かつ特有のパターンＢにしたがってその通知がされるため、利用者が通信端末を例えばポケットなどにしまっていた場合でも、相手端末がレディー状態となったことが容易にわかる。
【０１１９】
（２）選択された特定端末に関し、パターンＢでの通知がされてから利用者通話開始操作をしないうちに、管理サーバ３０２から取得された当該選択メンバ端末の状態がビジー状態へと変化すると、通信端末９００は、パターンＣでその旨を通知する。したがって、選択メンバ端末の状態がビジー状態からレディー状態へと遷移した旨が利用者に通知されたにもかかわらず、何らかの事情で利用者が相手端末に対する発呼を行なわない間に、相手端末の状態がビジー状態に遷移した場合には、その旨が上記レディー遷移検出通知とは異なる態様で利用者に通知されることになる。利用者は、相手端末が再びビジー状態になったことを知ることができ、ビジー状態であるにもかかわらず発呼を試みたりすることを避けることができる。
【０１２０】
このように、本実施の形態では、相手端末の状態を利用者自身の端末に表示することによって当該相手端末の状態が常時把握できる。さらに、その中の任意の端末を選択すると、その相手端末がビジー状態の場合、相手端末の状態が変化してレディー状態となったときにその旨がパターンＢにより利用者に通知される。また、通話が開始されずに再び相手端末がビジー状態に変化した場合にもその旨がパターンＣにより通知される。利用者は、通信端末からのパターンＢ又はパターンＣによる通知のみを待てばよく、通話通信したい相手端末の状態を常に確認する必要がなくなる。したがって、相手端末の状態が通話通信可能な状態になったときに、利用者はすぐに当該相手端末に通話連絡をすることができ、またそのまま相手が再びビジー状態になったときには発呼を避けることができる。その結果、無駄な発呼を防止できる。
【０１２１】
また、特許文献１に記載の技術では、相手端末が応答するまでの間は他の処理を実行することができないが、本実施の形態では、相手端末状態の監視中であっても、通信端末９００側では、例えば、ＴＶ又は音楽の視聴、並びにゲーム等の実行等の通信機能と無関係なアプリケーション機能を利用することが可能となる。
【０１２２】
なお、本発明は上記実施の形態に限定されるものではない。上記実施の形態では、相手端末の状態を通知する際に、端末状態の変化態様に応じてパターンを変えて音と振動との組合せで通知する例について記載した。しかし、本発明は、そのような構成に限定されない。例えば、音又は振動の単独での出力により相手端末の状態変化を通知するようにしてもよい。また、音又は振動、若しくはこれらの組合せに加え、相手端末の状態変化をＬＣＤ表示及び／又はＬＥＤ発光等により、視覚的に通知するようにしてもよい。その他、本明細書に添付の特許請求の範囲内での種々の設計変更及び修正を加え得ることは勿論である。
【０１２３】
すなわち、本明細書で開示された実施の形態は単に例示であって、本発明が上記した実施の形態のみに制限されるわけではない。本発明の範囲は、発明の詳細な説明の記載を参酌した上で、特許請求の範囲の請求項によって示され、そこに記載された文言と均等の意味及び範囲内での全ての変更を含む。
【図面の簡単な説明】
【０１２４】
【図１】本発明の実施の形態に係る相手端末通話予約システムの構成を簡略化して示す図である。
【図２】同システムに適用される管理サーバを有する交換機の構成を示すブロック図である。
【図３】同システムに適用される管理サーバに接続されるＨＤＤ内の記憶域の構成を図解的に示す図である。
【図４】同システムに適用される通信端末の外観構成を示す平面図である。
【図５】同通信端末のディスプレイ上での一覧表示の一例を示す図である。
【図６】同システムに適用される通信端末の電気的構成を示すブロック図である。
【図７】同通信端末のアドレス帳記憶装置に記憶されるメンバアドレス帳データの構成の一例を示す図である。
【図８】同通信端末の相手端末状態通知パターン記憶装置に記憶される通知パターンデータの構成の一例を示す図である。
【図９】同システムに適用される通信端末の機能を実現するプログラムの制御の流れを示すフローチャートである。
【図１０】同システムに適用される通信端末の機能を実現するプログラムの制御の流れを示すフローチャートであって、図９の続きを示す。
【図１１】同システムに適用される通信端末の機能を実現するプログラムの制御の流れを示すフローチャートであって、図１０の続きを示す。
【図１２】同システムに適用される管理サーバの機能を実現するプログラムの制御の流れを示すフローチャートである。
【符号の説明】
【０１２５】
１００ 相手端末通話予約システム
３０２ 管理サーバ
３０４ ＨＤＤ
３０６ サーバ制御部
３０８ 端末接続・通信装置
９００（９００Ａ，９００Ｂ，９００Ｃ） 通信端末
９１０ モード変更ボタン
９１６ 通話開始ボタン
９２４ ディスプレイ
９３０ 制御部
９３２ アドレス帳記憶装置
９３４ 端末ＩＤ記憶装置
９３６ 相手端末状態通知パターン記憶装置
９３８ 通信装置
９４２ 表示装置
９４６ 音出力装置
９４８ 振動出力装置
【特許請求の範囲】
【請求項１】
特定端末との間での通話通信を可能とするための通信手段と、
前記通信手段を介して通話通信可能な特定端末の状態を取得するための端末状態取得手段と、
特定端末を一意に特定する識別情報と対応付けて、前記端末状態取得手段で取得した複数の特定端末の状態を表示するための端末状態表示手段と、
前記端末状態表示手段にてその状態が表示されている複数の特定端末のうちから何れか１つの特定端末を選択するための端末選択手段と、
利用者の聴覚及び触覚の少なくとも一方に訴える態様で前記端末選択手段によって選択された特定端末の状態が変化した旨を通知するための通知手段と、
前記端末選択手段によって選択された特定端末に関し、前記端末状態取得手段によって取得された当該特定端末の状態が、選択時の第１の状態とは異なる第２の状態へと変化したときに、前記通知手段を第１の態様で作動させるための第１の制御手段と、を含むことを特徴とする通信端末。
【請求項２】
前記端末選択手段によって選択された特定端末に関し、前記第１の制御手段により前記通知手段が前記第１の態様で作動されてから利用者による通話に関わる特定操作がなされるまでの間に、前記端末状態取得手段により取得された当該特定端末の状態が前記通知手段を前記第１の態様で作動させたときの前記第２の状態から前記第１の状態へと変化したときに、前記通知手段を前記第１の態様とは異なる第２の態様で作動させるための第２の制御手段をさらに含むことを特徴とする請求項１に記載の通信端末。
【請求項３】
前記第１の態様での前記通知手段の作動時に利用者による通話に関わる特定操作がなされると、前記通信手段を介して前記端末選択手段によって選択された特定端末との通話通信接続を開始するための第３の制御手段をさらに含むことを特徴とする請求項１又は請求項２に記載の通信端末。
【請求項１】
特定端末との間での通話通信を可能とするための通信手段と、
前記通信手段を介して通話通信可能な特定端末の状態を取得するための端末状態取得手段と、
特定端末を一意に特定する識別情報と対応付けて、前記端末状態取得手段で取得した複数の特定端末の状態を表示するための端末状態表示手段と、
前記端末状態表示手段にてその状態が表示されている複数の特定端末のうちから何れか１つの特定端末を選択するための端末選択手段と、
利用者の聴覚及び触覚の少なくとも一方に訴える態様で前記端末選択手段によって選択された特定端末の状態が変化した旨を通知するための通知手段と、
前記端末選択手段によって選択された特定端末に関し、前記端末状態取得手段によって取得された当該特定端末の状態が、選択時の第１の状態とは異なる第２の状態へと変化したときに、前記通知手段を第１の態様で作動させるための第１の制御手段と、を含むことを特徴とする通信端末。
【請求項２】
前記端末選択手段によって選択された特定端末に関し、前記第１の制御手段により前記通知手段が前記第１の態様で作動されてから利用者による通話に関わる特定操作がなされるまでの間に、前記端末状態取得手段により取得された当該特定端末の状態が前記通知手段を前記第１の態様で作動させたときの前記第２の状態から前記第１の状態へと変化したときに、前記通知手段を前記第１の態様とは異なる第２の態様で作動させるための第２の制御手段をさらに含むことを特徴とする請求項１に記載の通信端末。
【請求項３】
前記第１の態様での前記通知手段の作動時に利用者による通話に関わる特定操作がなされると、前記通信手段を介して前記端末選択手段によって選択された特定端末との通話通信接続を開始するための第３の制御手段をさらに含むことを特徴とする請求項１又は請求項２に記載の通信端末。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【公開番号】特開２００９−２７５８２（Ｐ２００９−２７５８２Ａ）
【公開日】平成２１年２月５日（２００９．２．５）
【国際特許分類】
【出願番号】特願２００７−１９０５０４（Ｐ２００７−１９０５０４）
【出願日】平成１９年７月２３日（２００７．７．２３）
【出願人】（０００００５０４９）シャープ株式会社 (33,933)
【Ｆターム（参考）】
【公開日】平成２１年２月５日（２００９．２．５）
【国際特許分類】
【出願日】平成１９年７月２３日（２００７．７．２３）
【出願人】（０００００５０４９）シャープ株式会社 (33,933)
【Ｆターム（参考）】
[ Back to top ]