(57)【特許請求の範囲】
【請求項１】
その中にユーザ・アプリケーション・プログラム（１６）と、動作中は複数のターミナル対象物（５４〜５８）を有する電話プログラム（１８）とを格納するメモリ；および
前記ユーザ・アプリケーション・プログラム（１６）と前記電話プログラム（１８）との間のアプリケーション・プログラミング・インタフェース（API）（３０）であって、前記API（３０）は単モード呼を開設するための引数を受け取るコマンドを有し、前記電話プログラム（１８）が前記単モード呼を開設する前記コマンドの引数として、異なるタイプの複数のターミナル対象物（５４〜５８）を識別するアレイを受け取り、前記単モード呼を取り消して、前記単モード呼を開設する際に使用されるコマンドと同じコマンドを用いて前記複数のターミナル対象物（５４〜５８）のための二重モード呼を開設することが可能になるAPI（３０）；
によって構成されることを特徴とする無線通信装置。
【請求項２】
前記複数のターミナル対象物（５４〜５８）が音声ターミナル対象物（４２），ファクス・ターミナル対象物およびデータ・ターミナル対象物（４４）からなるグループからの少なくとも２つの異なるターミナル対象物（４６）として選択可能であることを特徴とする請求項１記載の装置。
【請求項３】
前記複数のターミナル対象物（５４〜５８）の第１ターミナル対象物により制御される音声要素と、前記複数のターミナル対象物（５４〜５８）の第２ターミナル対象物により制御されるデータ要素とを少なくとも有することを特徴とする請求項１記載の装置。
【請求項４】
少なくとも前記電話プログラム（１８）が実行される仮想装置（１５）を有する第１プロセッサ（１０）と、その上で実行され、前記音声要素および前記データ要素を制御するトランシーバ・ソフトウェア（２０）を有する第２プロセッサ（１１）とによって構成されることを特徴とする請求項３記載の装置。
【請求項５】
前記第１プロセッサ（１０）と前記第２プロセッサ（１１）との間のシリアル・リンク（２２）によって構成されることを特徴とする請求項４記載の装置。
【請求項６】
前記第１プロセッサ（１０）と前記第２プロセッサ（１１）との間のシリアル・リンク（２２）によって構成され、前記リンク（２２）が呼を開設するコマンドが主要タイプと交替タイプのいずれかであることを前記トランシーバ・ソフトウェア（２０）に知らせ、交替タイプが二重モード呼を示すことを特徴とする請求項４記載の装置。
【請求項７】
無線通信装置において二重モード呼を開設する方法であって、
アプリケーション・プログラム（１６）からアプリケーション・プログラミング・インタフェース（API）（３０）を通じて、アレイによって構成される引数を有するコマンドを用いることにより、単モード呼を開設するように適合された呼接続クラスを呼び出して、前記単モード呼の開設を取り消す段階であって、このとき前記アレイが音声タイプ（４２），ファクス・タイプ（４６）およびデータ・タイプ（４６）から選択される異なるタイプの複数のターミナル対象物（５４〜５８）によって構成され、これにより、前記単モード呼の呼接続クラスを用いて二重モード呼の開設が可能となる段階によって構成されることを特徴とする方法。
【請求項８】
前記呼接続クラスにおいて、音声ターミナル（４２）を参照する第１接続対象物と、データ・ターミナル（４４）およびファクス・ターミナル（４６）のいずれか一方を参照する第２接続対象物とを呼び出す段階によってさらに構成されることを特徴とする請求項７記載の方法。
【請求項９】
前記アプリケーション・プログラム（１６）が単独のターミナル対象物によって構成される引数を有するコマンドを用いることにより、二重モード呼出の開設を支援しない呼接続クラスとさらにインタフェースすることができることを特徴とする請求項７記載の方法。
【請求項１０】
前記呼接続クラスを単独のターミナル対象物によって構成される引数を有するコマンドにより呼び出すことができ、それにより、単モード呼を開設することを特徴とする請求項７記載の方法。
【請求項１１】
その中にユーザ・アプリケーション・プログラム（１６）と電話プログラム（１８）とを格納するメモリであって、前記電話プログラム（１８）が定義されたイベントの集合を有し、各定義された集合はイベント識別子（ID）を有することを特徴とし、定義される前記集合が
（ａ）基本クラス，
（ｂ）プロバイダ・イベント・クラス，
（ｃ）アドレスおよび呼制御アドレス・イベント・クラス，
（ｄ）呼および呼制御呼イベント・クラス，
（ｅ）接続および呼制御接続イベント・クラス，
（ｆ）ターミナルおよび呼制御ターミナル・イベント・クラス，
（ｇ）ターミナル接続および呼制御ターミナル接続イベント・クラス，および
（ｈ）媒体イベント・クラス
に分類されるメモリ；および
前記ユーザ・アプリケーション・プログラム（１６）と前記電話プログラム（１８）との間のアプリケーション・プログラミング・インタフェース（API）（３０）であって、前記API（３０）が前記アプリケーション・プログラム（１６）からコマンドを受け取り、前記コマンドが、前記グループ（ａ）ないし（ｈ）のうちから単モード呼を開設するための１つのイベント・クラスを、前記イベント・クラス内のイベントを定義するIDと共に定義し、該ＩＤは、前記単モード呼の開設を取り消して、同じイベント・クラスを用いて二重モード呼を開設するためのものである、API（３０）；
によって構成されることを特徴とする無線通信装置。
【請求項１２】
各被定義イベントが方法を定義するコンピュータ・プログラムを有し、被定義イベントの集合のイベントに対応する方法に関する全コンピュータ・プログラムがクラス対象物に含まれ、前記クラス対象物より低い任意のレベルにおいては対象物内で下位定義されないことを特徴とする請求項１１記載の無線通信装置。
【発明の詳細な説明】
【０００１】
【産業上の利用分野】
本発明は、ユーザ・アプリケーション・プログラム（一般にアプリケーションまたはアプレットと呼ばれる）および電話プログラム（たとえば電話方式の一例）を有し、ユーザ・アプリケーション・プログラムと電話プログラムとの間のアプリケーション・プログラミング・インタフェース（API： application programming interface）を有する無線通信装置に関する。本発明は、APIの性状に関し、APIを介して実施される方法、たとえば二重モード呼を開設する方法に関する。
【０００２】
【従来の技術および発明が解決しようとする課題】
Java（商標）などの対象物志向型プログラム言語は、プラットフォーム，オペレーティング・システムおよび装置間においてプログラムの移植可能性があるためにより多くの装置で普及しつつある。これは、ある装置のために開発されたプログラムが異なる特性を持つ別の装置、たとえば異なるオペレーティング・システムや異なるマイクロプロセッサでより容易に用いられることを意味する。
【０００３】
対象物志向型プログラムは、従来のパーソナル・コンピュータやこのような言語が広く用いられてきた他のプラットフォームよりもメモリ・サイズや処理能力が非常に小さい装置にも普及しつつある。Java（商標）などの対象物志向型言語を非常に小さいプラットフォームで用いようとする際に、いくつかの理由から問題が起こっている。問題点の一例は、対象物が定まった方法で他のプログラムと対話をする内蔵型コンピュータ・プログラムであったり、クラスが同様の特性を持つ対象物の集合のための一般的テンプレートであるような場合に、対象物クラスの集合全体に対応する必要があることである。異なるプラットフォーム間でプログラムの移植可能性を維持するためには、任意のアプリケーションが実施することができる均一性がクラス内に存在する必要があるということが問題になる。たとえば、pJava（商標）は、非常に大きな集合のクラス・ライブラリを有し、クラス・ライブラリの集合全体の下部集合のみを用いるより小型の言語を「eJava（商標）」と定義する努力がなされている。
【０００４】
クラスの一例はJava（商標）電話API（JTAPI： Java telephony API）を通じて実施される電話クラスである。このようなクラスの一例を「JTAPI実行部」と呼ぶことがある。
【０００５】
JTAPIはJava（商標）準拠コンピュータ電話アプリケーションのための移植可能な対象物志向型アプリケーション・プログラミング・インタフェースであり、ワールドワイド・ウェブ上の以下のユニバーサル・リソース・ロケータにおいて記述される：www.javasoft.com/products/JATPI/index.html。Java（商標）電話APIは、第１および第３者の電話アプリケーション・ドメインの両方を支援する。APIはプログラミングを簡素化しアプリケーションを容易にして、高度な電話アプリケーションのために必要な機能を提供する。JTAPIはAPIの集合である。基本的な呼方式と、電話呼を発しそれに応答するなどの初歩的な電話機能を提供する「コア」APIがある。コアAPIは、呼出センターおよび媒体ストリーム・アクセスなどの特定の電話ドメインのための機能を提供する標準的な拡張APIに囲まれる。JTAPIを用いて書かれるアプリケーションは種々のコンピュータ・プラットフォームおよび電話システム間で移植可能である。１９９７年１２月にJTAPIのバージョン１．２が発行された。
【０００６】
JTAPIの使用例に、JTAPIアプリケーションまたはJava（商標）アプレットが、ディスプレイ，キーボード，プロセッサおよびメモリのみを有するネットワーク・コンピュータなどの遠隔基地で動作するネットワーク構造がある。このコンピュータはネットワーク・リソースにアクセスし、電話リソースを管理する中央サーバを利用する。JTAPIは、Java（商標）の遠隔法実施（RMI：remote method invocation）または電話プロトコルなどの遠隔通信機構を介してサーバと通信する。Java（商標）電話APIは、Java（商標）言語パッケージの集合によって構成される。各パッケージがコンピュータ電話アプリケーションの特定の面に関する機能を提供する。
【０００７】
電話サーバ実行部は、下部構造として存在するプラットフォーム・ハードウェアにより、それが対応するパッケージを選択する。アプリケーションは現在使用中の実行部により支援されるパッケージを照会する。さらに、アプリケーション開発者は、アプリケーションがタスクを実行するために必要な被支援パッケージのみに関わる。たとえば、呼出パッケージにより、アプレット設計者はウェブ・ページに電話機能を追加することができ、いくつかの標準的拡張パッケージがJTAPIコア・パッケージを拡張する。これらの拡張パッケージはAPIに、全制御，呼出センター，媒体，電話，プライベート・データおよび機能パッケージなどの追加の電話機能を与える。
【０００８】
JTAPIなどの標準的電話APIを、無線電話またはその他の無線通信装置のための電話APIとして用いることが望ましい。
【０００９】
無線通信装置のための電話APIとしてJTAPIを用いるにはいくつかの問題点があり、特に汎ヨーロッパ・デジタル化移動体通信システム（GSM：Global System for Mobile）無線電話のための電話APIとして用いる際に問題となる。一般に、JTAPIには約１３０ｋバイトの総クラス・ファイル・サイズをもつ６３個超のイベント・クラスを有するという問題がある。これは、無線電話のプログラム全体の比較的小さい要素に対して、かなりのメモリ割当があることを表す。JTAPIと互換性を持つプログラムのメモリ要件を削減することが必要である。
【００１０】
GSM通信装置については、既存のJTAPIシンタックスと方法署名（method signature）を用いて容易にアクセスできないGSM機能がある。さらに、二重モード呼（音声およびファクス呼または音声およびデータ呼に関してGSMで用いられる用語）に対応することが必要であり、二重モード呼の概念は有線電話およびJTAPIにおいては知られていない。単純にJTAPIに追加しJTAPIを削減することで満足の行く解決は得られない。これはJTAPIに追加するとイベント・クラスを発見する必要性が増大し、JTAPIを削減するとプラットフォーム間でのアプリケーションの移植を可能にする標準的APIの利点が損なわれるためである。
【００１１】
従って、無線通信装置のための電話APIと、メモリの占有量を最小限に抑え、無線電話特有の機能を支援する関連クラスとが必要とされる。
【００１２】
【実施例】
図１を参照して、無線電話を異なる層に関して図示し、ハードウェアを最下層にアプリケーション・ソフトウェアを最上層に図示する。無線電話は、第１マイクロプロセッサ１０（マイクロプロセッサＡ），第２マイクロプロセッサ１１（マイクロプロセッサB）および特定のRFハードウェア１３によって構成される。マイクロプロセッサＡ，Ｂは、互いに接続される。マイクロプロセッサＢは、RFハードウェア１３に接続される。RFハードウェア１３は、少なくとも１つの受信機および送信機を備える。RFハードウェアはさらに、好ましくはたとえば音声コーダを備える音声通信要素２３と、好ましくはたとえばデータ・モデムまたはファクス・モデムを備えるデータ通信要素２４とを有する。マイクロプロセッサはMicroware Systems Corporation（アイオワ州Des Moines）により供給されるOS9000などのオペレーティング・システム（OS）１４を有する。オペレーティング・システムの上層には市販されるJava（商標）仮想装置などの仮想装置１５が図示される。アプリケーション・プログラム１６および他の様々なJava（商標）クラス１７は、仮想装置１５上で実行される。クラス１７の１つがJTAPI実行部１８である。マイクロプロセッサ１７は、呼の制御，フレーミングおよび一般にブロック・コーディングなどのバイト・レベルの操作を実行するトランシーバ・ソフトウェア２０を有する。トランシーバ・ソフトウェア２０は、共通サービス・プロバイダ・モジュール・インタフェース（CSPMI：common service provider module interface）２２を介してオペレーティング・システム１４と通信を行う。
【００１３】
図１の構造の代替例として、マイクロプロセッサＡ，Ｂを図２に破線で図示されるように単独の集積回路２５に事実上統合することができる。この実施例においては、マイクロプロセッサ１０，ハードウェア１３，オペレーティング・システム１４，仮想装置１５および種々のソフトウェア要素１６〜１８は図１の実施例と同じである。マイクロプロセッサＢの代わりに、単独の集積回路２５内のマイクロプロセッサ１０と一体化されるデジタル信号プロセッサ（DSP：digital signal processor）がある。DSP２７は、フレーミングと、ブロック・コーディングなどその他のバイト・レベル操作とを実行するDSPコード２８を有し、一方で呼制御などの他のトランシーバ・ソフトウェア機能は、オペレーティング・システム１４を用いてマイクロプロセッサ１０上で実行されるトランシーバ・ソフトウェア・コード２９によって実行される。適切な集積回路２５は、モトローラ社（イリノイ州Schaumburg）から市販されるMコア（商標）集積プロセッサおよびDSP（M-core (TM) integrated microprocessor and DSP）である。
【００１４】
図３において、アプリケーション１６が図示され（「フォーン・アプレット」と呼ばれる）、JTAPI法実行部１８が図示される。JTAPIインタフェース３０は、フォーン・アプレット１６とJTAPI法実行部１８との間をインタフェースして図示される。JTAPI法実行部１８は、CSPMI２２を介するGSMトランシーバ３０などの無線トランシーバからの入力を制御および受信する。GSMトランシーバ３０は、第２マイクロプロセッサ１１，RFハードウェア１３およびトランシーバ・ソフトウェア２０（すべて図１に図示）によって構成される。
【００１５】
JTAPI３０は「プロバイダ」などの高レベル対象物のシンタクッスおよび動作を定義し、付表Ａに記述されるJTAPI仕様書バージョン１．２に実質的に説明される。また、GSMに特有の一定の動作が支援されるが、これらの動作に関して、以下の特定の意味論を定義する。
【００１６】
JTAPIプロバイダのドメインは単純に移動局（MS）である。プロバイダのドメイン内の唯一のアドレスはMSのものであり、たとえば単独の回線電話のドメイン内の１つのアドレスである。
【００１７】
Provider.getAddresses()でMSについて１アレイのアドレスが、通常１回のエントリのみで戻される。MSが複数の回線と電話番号とに対応する場合は、デフォルトまたは一次アドレスが第１エントリとなる。
【００１８】
Provider.getAddress()はMSに割り当てられる番号または番号群のみを受け入れる。デフォルトでは、一次アドレスすなわちgetAddresses()[0]が戻される。
【００１９】
Provider.getTerminals()は、MSが支援するターミナルのアレイを戻す。別々の呼保持者（call bearer）のタイプに関して別々のターミナルが定義される（下記参照）。
【００２０】
Provider.getTerminals()は、ターミナル名を特定する列をとる。デフォルトでは、音声ターミナルが戻される。すべての実行部は個別のターミナル名として音声，データおよびファクスに対応しなければならない（下記参照）。
【００２１】
Provider.create/Call()で、プロバイダは停止されていない限り、サービス不能（OUT#OF#SERVICE）となる。プロバイダがサービス可能（IN#SERVICE）となるまで呼出を成功させることはできない。この機能はJTAPI1.2createCall()予備条件に対する変更点であり、図５および図６に関してさらに詳細に説明される。
【００２２】
Call.connect()で、宛先アドレス・ストリングが共通SSコードおよびアドレス・フラッグに関して分解される。Call.connect()に伝えられる宛先番号列が「＋」キャラクタで始まる場合は、番号タイプ（TON：type of number）が国際（INTERNATIONAL）に設定され、そうでない場合はTONは未知（UNKNOWN）である。列に数値しか含まれない場合は、ナンバリング・プラン識別子（NPI：numbering-plan identifier）はISDNであり、そうでない場合は未知である。
【００２３】
TerminalConnection.join()およびTerminalConnection.leave()は、二重モード（音声およびデータまたは音声およびファクス）呼において呼モードを変更するために用いられる。呼出においてアクティブなターミナル接続がいつも必ず１つあり、別のターミナル接続においてjoin()を起動すると、呼出モードのスイッチが起こされ、アクティブなターミナル接続上のleave()を呼び出すと別のスイッチが起動される。
【００２４】
媒体ターミナル接続に関して定義されるAPIを用いてアプリケーションは呼の情報内容と対話を行うことができる。Connetion.getTerminalConnections（）から戻されたターミナル接続が媒体ターミナル接続を実行すると、アプリケーションは以下の方法を用いることができる：MediaTerminalConnection.getMediaAvailability()（これはJTAPI1.2に定義されるように実行される）；MediaTerminalConnection.getMediaState()（これはJTAPI1.2に定義されるように実行される）；MediaTerminalConnection.generateDtmf()（これは呼にDTMFトーンを生成するために用いられる）。媒体ターミナル接続における他のすべての方法はオプションである。
【００２５】
プロバイダは、必ずしもサービス不能状態の場合にすべてのアクティブな呼の接続を切るわけではない。プロバイダは、呼をアクティブに維持し、一時的な通信不良を想定して呼の再開設を試みる。ProvOutOfSeviceEvのすぐ後にCallInvalidEvと関連するConnDisconnectedEvイベントが続かない場合（すなわちこれらが期限内に続かない場合）は、アプリケーションは、プロバイダが呼を再開設しようと試みることを想定することができる。
【００２６】
さらに、GSM機能には既存のJTAPIシンタックスおよび方法署名を用いて容易にアクセスできないものがある。以下の新規の方法と異なる署名をもつ方法とが定義される。
【００２７】
Provider.getNetworkID()は、現ネットワーク名を戻す。
【００２８】
Provider.getServiceLevel()は、オペレーティング・サービス・レベルなし（NONE），緊急（EMERGENCY），満杯(FULL）を戻す。
【００２９】
MSがホームPLMNにない場合は、Provider.isRoaming()は真となる。
【００３０】
これらの新たな方法により、アプリケーションは現行の公衆地上移動網（PLMN：public land mobile network）と、オペレーティング・サービス・レベルと、ユニットがホームPLMN上にあるか否かを決定することができる。
【００３１】
JTAPIにおいては、ターミナル対象物は呼の物理的な最終地点を表す。呼は音声を伝えることとする。GSMに関して定義された追加の呼保持者のタイプに対応するために、１つの主要な呼保持者のタイプについて１つずつ、追加のターミナル・サブクラスが定義される。ターミナルのデータ・ターミナル・サブクラスはGSMデータ呼の物理的最終地点を表す。ターミナルのファクス・ターミナル・サブクラスはGSMファクス呼の物理的最終地点を表す。
【００３２】
通常のGSM MSは少なくとも３つのターミナル、音声，データおよびファクス・ターミナルに対応する。MSは追加のターミナル例またはサブクラス（たとえば内部データのための内部データ・ターミナルおよび接続PCに送付されるデータのためのモデム・データ・ターミナルに対応する。アプリケーションは、適切なターミナル上の着信呼イベントを観察することによって種々の保持者の着信呼を受け入れる。
【００３３】
次に図４を参照して、二重モードGSM呼に対応することのできる特定の機能を説明する。
【００３４】
図４は、図３のJTAPI実行部１８の詳細を説明する。本方法の中心となるのはプロバイダ法４０である。このプロバイダ法は、ある方式でオペレーティング・システム１４とインタフェースするが、その方式を詳細に説明する必要はない。本明細書の文脈で用いる場合、「方法」とはあるクラスの事例で動作する、そのクラスの内部に定義される機能である。プロバイダ法４０は、音声ターミナル対象物４２，データ・ターミナル対象物４４，ファクス・ターミナル対象物４６およびアドレス対象物４８を接続する。呼が設定されると、プロバイダ法４０は呼対象物を作成する。呼対象物５０はローカル接続対象物５２を作成する。単純な音声接続については、ローカル接続対象物５２が、音声ターミナル４２を参照するターミナル接続対象物５４を作成する。詳細に後述するが、ローカル接続対象物５２は第２ターミナル接続対象物５６（および第３ターミナル接続対象物５８）も作成することができる。第２ターミナル接続対象物５６はデータ・ターミナル対象物４４を参照する。第３ターミナル対象物５８がある場合は、ファクス・ターミナル４６を参照することができる。代替の構造として、第２および第３ターミナル接続対象物をデータおよびファクス呼を作成する目的で作成することもできるが、これについては後で詳述する。
【００３５】
呼が三方向の呼である場合、呼対象物５０は必要に応じて、それ自身の関連ターミナル接続対象物６２〜６６を伴う追加の遠隔接続対象物６０を作成することに注目されたい。さらに、別の呼（たとえば保留中の呼）がある場合は、プロバイダ法４０は、それ自身の対応ローカル接続およびターミナル接続を有する追加の第２呼対象物７０を作成することができることにも注目されたい。いずれの場合も、特定の無線電話に関しては、３つのターミナル、すなわち音声ターミナル，データ・ターミナルおよびファクス・ターミナルの３つしか存在しない。そのためにいずれの場合も、ローカル接続５２および遠隔接続６０や他のローカル接続または遠隔接続により作成される種々のターミナル対象物はすべて、音声ターミナル対象物４２，データ・ターミナル対象物４４およびファクス・ターミナル対象物４６をそれぞれ参照することができる。
【００３６】
次に説明するプロセスにおいては、GSMトランシーバ３０が無線電話通信チャネルを介して遠隔スイッチとの呼を設定することが目標であり、呼が二重モード（たとえば音声およびデータまたは音声およびファクス）の場合は、JTAPI法実行部１８が二重モード機能との呼を設定し、CSPMI２２を介してGSMトランシーバに二重モード呼が開設されたことを通知することが目標である。これにより、GSMトランシーバ３０がGSMシステムに対して呼が二重モードであることを通知することができ、それによりGSMシステムのスイッチは、呼の設定要求を受信すると、呼を発してその相互作用機能のモデムを確保し、呼のデータまたはファクス機能を支援することができるようにする。さらに、JTAPIコマンドcall.connect()（呼の接続）を用いて電話アプリケーション１６の始動時にこの二重モード呼を開設することが目標である。
【００３７】
JTAPIバージョン１．２において、call.connect()は、ターミナル対象物である引数を予想し、それによりそのターミナルとの間に単モード呼の開設を可能にする。二重モード呼を開設するには、本発明の好適な実施例はcall.connect()を取り消して、単独の発信ターミナルの代わりに第１引数としてターミナル・アレイをとる方法を追加する。ターミナル・アレイは、コマンドcall.connectの引数であり、ターミナル対象物のアレイを含む。このアレイは、音声ターミナルおよびデータ・ターミナル、または音声ターミナルおよびファクス・ターミナル、またはデータ・ターミナルおよびファクス・ターミナル、または音声ターミナル，データ・ターミナルおよびファクス・ターミナルである。方法プロバイダ４０がこのコマンドと引数としてのアレイとで起動されると、呼対象物５０およびローカル接続対象物２２を作成する。ローカル接続対象物２２は、第１および第２ターミナル対象物５４，５６を作成する。ローカル接続対象物５２は、そのターミナルに関する第１ターミナル接続対象物５４を照会し、第１ターミナル対象物５４はローカル接続対象物５２に対して応答して、そのターミナル（すなわち参照するターミナル）が音声ターミナルであることを示す。同様に、第２ターミナル接続対象物５６がローカル接続対象物５２によって照会され、そのターミナルがデータ・ターミナルであることを示して応答する。ローカル接続対象物５４は、呼対象物５０に対して、データ・ターミナル接続および音声ターミナル接続が開設されることを知らせる。呼対象物５０は、プロバイダ４０に対して、二重モード呼が開設されたことを知らせる。プロバイダ４０は、CSPMI２２を介し（OS１４を通じて）二重モード呼が開設されたことをGSMトランシーバに知らせる。
【００３８】
プロバイダ４０は、以下の要領でトランシーバ３０を通じて呼を開設する。プロバイダ４０はそのタイプとしてPlaceCallReqを有するバッファを作成し、以下の表１からパラメータM/O/Cを追加する。これらのパラメータは呼を記述する。
【００３９】
【表１】
パラメータ名      パラメータ・タイプ                       M/O/C
CallType1          CALL#TYPE（呼タイプ）                   M
CalledParty1       PHONE#NUMBER（電話番号）                C
RepeatIndicator2   REPEAT#INDICATOR（指示子反復）          O
CallType2          CALL#TYPE（呼タイプ）                   O
DataParameters3    DATA-PARAMETERS（データ・パラメータ）   C
CLIRDispositoin4   CLIR#DISPOSITION（CLIR配置）            O
CUGInfo5           CUG#INFO                                O
１．緊急呼についてはオプション、他のすべての呼タイプについては強制
２．多重呼タイプ呼出については強制
３．呼タイプがファクスまたはデータの場合は強制
４．クライアントがCLIRサブクリプション・デフォルトを打ち消したい場合に入れる
５．クライアントがCUGサブクリプション・デフォルトを打ち消したい場合に入れる。
【００４０】
このバッファの内容がシリアル・リンク２２を介してトランシーバ３０に送られ、受け入れられた場合は、トランシーバは以下の表２から確認メッセージを送り返す。
【００４１】
【表２】
パラメータ名      パラメータ・タイプ                       M/O/C
CAllHandle1        CALL#HANDLE（呼処理）                   C
１．呼要求が成功した場合は強制。
この確認メッセージが呼処理を与え、それによってマイクロプロセッサ１０は後続のコマンド内に呼を識別することができる。
【００４２】
表１では、呼タイプ２は代替の呼タイプを示し、代替の呼タイプがデータまたはファクス（最初の呼タイプはGSMでは常に音声である）ことを示す。このようにして、プロバイダ４０はトランシーバ３０に対して、代替の呼タイプがあることとそれがデータ（またはファクス）であることを知らせる。かくして、トランシーバ３０が呼を設定すると、スイッチには、代替の呼タイプがあること、この代替の呼タイプがデータ・モデム（またはファクス・モデム）の確保を必要とすることを知らせる。
【００４３】
第１ターミナル・アレイ・エントリは最初にアクティブになるターミナルであるが、呼はアレイ内で示された任意のターミナルを扱うように設定される。すなわち、他のターミナルに対するターミナル接続が呼制御ターミナルconnection.bridgestate（接続ブリッジ状態）（またはterminalconnection.passivestate（ターミナル接続パッシブ状態）に置かれる。上記の如く、joined/leave（結合／放置）を用いて現在の呼モードを制御する。connect()のこの変数は、最初に示す二重モード呼パラメータのGSM要件に対応するために用いられる（それにより、アプリケーション１６が、呼に加担するすべてのターミナルを前面に占有する必要がある）。
【００４４】
Call.connectが打ち消されて、宛先アドレス列のTON（番号タイプ）およびNPI（ナンバリング・プラン識別子）を上記の如く示すことができない場合は、これらを明示するための方法が追加される。
【００４５】
Call.setEmergency()（呼設定緊急）が定義されて、緊急モード・フラッグが設定される。
【００４６】
Call.setCUGInfo()（呼設定CUG情報）が定義されて、宛先アドレス列内にSS（補助サービス：supplementary services）コードを用いずにプログラム形式で閉じられたユーザ・グループ情報が指定される。
【００４７】
Call.setCallerIdRestricted()（呼設定発呼者ID制限）が定義され、宛先アドレス列内にSSコードを用いずにプログラム形式で、発呼回線識別制限要求が指定される。
【００４８】
Call.offHook()（呼オフフック）には対応しない。
【００４９】
アプリケーションは、転送または会議コントローラを指定することはできない。setTransferController()（設定転送コントローラ）およびsetConferenceController()（設定会議コントローラ）法は、MethodNotSupported（方法非対応）を投入して、getConferenceController()およびgetTransferController()が<NULL>（ヌル）を戻す。
【００５０】
setConferenceEnable()（設定会議イネーブル），getConferenceEnable()（会議イネーブル），setTransferEnable()（設定転送イネーブル）およびgetTransferEnable()（転送イネーブル）が、この呼を転送または会議設定する機能を制御する内部フラッグを操作する。
【００５１】
Call.consult()（呼コンサルト）実施は宛先アドレス列を含まねばならない；指定されない変数には対応しない。
【００５２】
Connection.reject(int)（接続拒否）が定義され、アプリケーションは、呼を拒否する場合の拒否理由を指定することができる。これは、ユーザが決定するユーザ・ビジー機能に対応する。
【００５３】
Connection.addToAddress()（接続追加アドレス）には対応しない。
【００５４】
Connection.park()（接続パーク）には対応しない。
【００５５】
ターミナル接続の下部クラスが定義され（データ・ターミナル接続）、ネットワークと最終地点のデータ・ターミナルとの間の物理的リンクを表す。データ速度，モデム・タイプ，プロトコルの階層などのデータ呼パラメータを指定および照会するための方法が定義される。同様に、ターミナル接続の下部クラス（媒体ターミナル接続の下部クラスとしてより正確に記述される（ファクス・ターミナル接続））はネットワークと最終地点ターミナルとの間の物理的リンクを表す。データ加重，グループ・モードなどのファクス呼パラメータを指定および照会するための方法が定義される。
【００５６】
ファクス・ターミナル接続は、ファクス媒体列を設定し、データ・ページおよびページ終点指標を送信する媒体別方法も提供する。
【００５７】
新ターミナル・イベントが定義され、アプリケーションは、進行中の呼が「TermForwardingActiveEv」専用ターミナルについてアクティブであるか否かを判定することができる。異なるサービス（すなわち音声，ファクスおよびデータ）に対する転送が適切なターミナル対象物（すなわち音声，データ，ファクス）を通じて知らされる。
【００５８】
Provider.createCall()は、プロバイダが停止されていない限りサービス不能であっても呼を発すること、またプロバイダがサービス可能になるまで発呼に成功しないことを説明した。ここでは、この特徴について図５および図６を参照してより詳細に説明する。
【００５９】
図５を参照して、いかなる理由があろうともアプリケーション１６が呼を発するか、あるいは接続またはパケット・データ・セッションを開設することを求める場合を考える。アプリケーション１６は、通常は、ユーザに対するインタフェースであり、たとえば、ユーザが無線通信装置（移動局またはMS）の電源を入れて電話番号をダイヤルすることにより呼を起こすことを求めることができる。アプリケーション１６は、図５に示されるプログラム（または方法）を、API３０に対するProvider.createCall()コマンドを通じてProvider.createCall方法（段階１００）を呼び出すことにより開始する。段階１０１において、通信装置が停止モードにある場合は、プログラムは段階１０２で単純にエラーを戻し、段階１０３で終了する。装置が停止モードにない場合は、段階１１０で呼対象物５０が作成され、図５のプログラムが段階１１１で完了して、図６のプログラムの開始の準備が整う。
【００６０】
呼対象物５０の作成の直後、さらなるイベントまたは条件を伴わずに（また打ち消しイベントもなしに）、アプリケーション１６は、API３０に対するCall.connect()コマンドを通じてCall.connect方法（段階１５０）を呼び出す。段階１５１において、通信装置がサービス不能であると判定されると、プログラム（または方法）は、段階１５２で待機し他の機能が段階１５４においてスキャン動作を実行する。待機期間は約１０秒間あれば、スキャン・ルーチン内でセルラ・ネットワークに接続を行うには充分である。段階１５１または１５６の後で、通信装置が無線通信網とサービスを開設した場合は、段階１５８が始まり、コマンドがシリアル・インタフェース２２を介してトランシーバ３０に送られて呼を発する。図６のプログラムは段階１６０で終了する。
【００６１】
このようにして、ユーザはサービスが開設される前でも電話番号のダイヤル動作を開始して呼を発することができる。通常のユーザは、サービスが開設されたか否かに関わらず通信装置が給電されるとすぐに発呼を開始することを欲するので、これは特に有用な特徴である。サービスの開設は、装置の電源オン動作（たとえば電源キーを押したりフリップを開ける）に応答して開始することができ、図５および図６の方法はユーザまたはアプリケーションの他の動作に応答して平行に開始することができる。
【００６２】
JTAPI定義が異なるJTAPIイベントの各々について別のクラスを有することは大きな問題である。このために合計で約１３０ｋバイトのクラス・ファイルをもつ６３個超のクラスを定義するという重荷がMSに課される。
【００６３】
本発明のある局面により、アプリケーションはイベント・クラスのタイプではなくイベントIDに基づいて行われる。これによって、多数のイベント・クラスをはるかに小さな集合のイベント・カテゴリ・クラスと置き換える。アプリケーションはイベントIDを用いて広いタイプ内で特定のイベントを決定する。この結果、対象物の包括に重大な損失を起こさずに大幅にスペースを節約することができる。
【００６４】
イベント・クラスは、以下の８つの包括的クラスに分かれる：
EV  全イベントの基本クラス
ProvEv  プロバイダ・イベント
CallCtlAddrEv アドレスおよび呼制御アドレス・イベント
CallCtlCallEv 呼および呼制御呼イベント
CallCtlConnEv 接続および呼制御接続イベント
CallCtrlTermEv  ターミナルおよび呼制御ターミナル・イベント
CallCtlTermConnEv ターミナル接続および呼制御ターミナル接続イベント
MediaEv 媒体イベント
これらの包括的クラスに分類される特定のイベントを以下の表３に示す。
【００６５】
【表３】
0004362178.tif 000002
0004362178.tif 000003
要するに、ワイヤレス電話機能を呼び出すための対象物志向型コンピュータ・プログラムの開発に高度に適するワイヤレス通信装置のための電話APIとプロバイダ法を備える関連の実行部とが開示された。APIを用いると、プラットフォーム間と、メモリ要件が極めて低い実行部において高度な移植可能性をもたらす。さらに、GSM無線電話システムにおいて必要とされるような二重モード呼出機能が、従来は単純な有線電話呼の開設に用いられる標準的なJTAPIイベント・クラスを用いて支援される。
【００６６】
本発明のある局面により、その中にユーザ・アプリケーション・プログラムと移動電話プログラムとを格納するメモリによって構成される無線通信装置が開示された。この移動電話プログラムは、装置が接続されるワイヤレス・ネットワークを記述するパラメータを維持する。これらのパラメータは次の１つ以上を含む：現ネットワーク名；現ネットワークがホーム・ネットワークであるか否かの指標。これらのパラメータはトランシーバから、あるいは移動インターネット・プロトコル接続を介して移動電話プログラムに配布される。ユーザ・アプリケーション・プログラムと移動電話プログラムTON間のアプリケーション・プログラミング・インタフェースはこれらのパラメータを呼び出して、それをアプリケーション・プログラムに戻すための少なくとも１つのコマンド（たとえば、Provider.getNetworkID(); Provider.getServiceLevel()または Provider.isRoaming()）を有する。
【００６７】
上記の説明は例としてあげられたに過ぎず、本発明の範囲および精神の中で詳細の修正を行うことができる。
付表１
Java電話API
概要
バージョン１．２
導入部
Java電話API（JTAPI）はJava準拠コンピュータ電話アプリケーションのための携帯型対象物志向アプリケーション・プログラミング・インタフェースである。JTAPIは、呼出センタアプリケーション開発者からウェブ・ページ設計者まで広範囲の使用者に対応する。JTAPIは第１および第３者電話アプリケーション・ドメインの両方に対応する。APIはプログラミングを簡素にアプリケーションを容易にするように設計され、なおかつ高度な電話アプリケーションのために必要な機能を提供する。
【００６８】
Java電話APIは、実際にはAPIの集合である。「コア」となるAPIは基礎となる呼モデルと、電話呼の送信および電話呼の応答など初歩的な電話機能を提供する。コアAPIの周囲には、呼出センタおよび媒体ストリーム・アクセスなど特定の電話ドメインのための機能を提供する標準的な拡張APIがある。JTAPIおよび拡張パッケージのアーキテクチャを本書で説明する。
【００６９】
Java電話APIを用いて書かれたアプリケーションは種々のコンピュータ・プラットフォームと電話システム間で移植可能である。JTAPIの実行部は、Sun Microsystem社のSunXTL，Microsoft and Intel社のTAPI，Novell and Lucent社のTSAPIおよびIBM社のCallPathなどの既存のコンピュータ電話統合プラットフォームについて可能である。また、独立したハードウェア販売業者は、自身の専用ハードウェアに基づきJava電話APIの実行部を選定して提供することができる。
文書構成の概要
この文書は次のセクションで構成される：
Java電話API機能−−JTAPIの機能とそれが設計された原則を説明する。
被支援構造−−JTAPIを用いることができる環境とそれが設計されたコンピュータおよびソフトウェア構造を要約する。
Java電話パッケージ・アーキテクチャ−−Java電話APIが種々のJava言語パッケージにどのように編成されるかを要約する。各パッケージに、短い説明を行い、より詳細な説明への関連部を付記する。
Java電話呼モデル−−電話呼と電話呼を構成する異なる対象物とをこのAPIにおいて表す。
コア・パッケージ法−−電話呼の発生，電話呼の応答および電話呼への接続の切断など最も基本的な電話動作を実施するコア・パッケージにおいて可能な主要方法の簡単な要約を行う。
接続対象物状態−−接続対象物が存在することのできる状態を解説する。各状態から可能な移行の説明を行う。
ターミナル接続対象物状態−−ターミナル接続対象物が存在することのできる状態を解説する。各状態から可能な移行の説明を行う。
電話呼の発生−−どの電話APIにおいても最も基本的な機能の１つが電話呼の発生である。このセクションは、電話呼を発生するために必要なJTAPI法の実施を説明し、呼モデルの状態変化を検証する。この分析では呼がどのように発され、応答され、終息されるかを説明する。
Java電話オブザーバ・モデル−−JTAPIオブザーバ・モデルを解説する。アプリケーションは、JTAPI呼モデルの状態の変化を非同期的に通知するためにオブザーバを使用する。
【００７０】
アプリケーション・コードの例は本書には含まれないが、Sun Microsystems社（カリフォルニア州Palo Alto）により発行されるJava電話APIバージョン１．２にJava電話APIを用いる２つの実際のコード例が示される。１つの例は指定される電話番号に電話をかける。もう１つの例は指定されたターミナルが着信電話呼に応答する。
プロバイダの位置特定と捕捉−−アプリケーションがJTAPIプロバイダ対象物を作成捕捉する方法を解説する。
セキュリティ−−JTAPIのセキュリティ法を要約する。
Java電話機能
Java電話APIの機能および手引きとなる設計原則は次の通りである：
最も基本的な電話アプリケーションを簡素にする。
【００７１】
デスクトップ・アプリケーションから分配呼出センターの電話アプリケーションに至る度量可能なフレームワークを提供する。
【００７２】
サービス・プロバイダに直接的にアプリケーションをインタフェースする、あるいはSunXTL，TSAPIおよびTAPIなどの既存の電話APIへのJava・インタフェースとして機能する。
【００７３】
標準拡張パッケージで拡張された単純なコアを基準とする。
【００７４】
Javaの実行時間を使うことのできる構造であれば、広範囲のハードウェア構造で実行される。
被支援構造
JTAPIは、電話リソースに直接アクセスする中央サーバや、ネットワーク上で電話リソースにアクセスする遠隔ネットワーク・コンピュータを含む広範囲のシステム構造において実行される。第１構造においては、ネットワーク・コンピュータがJTAPIアプリケーションを実行して、図７に示されるようにネットワーク上で電話リソースにアクセスする。第２構造においては、アプリケーションは図８に示されるように自身の電話リソースを有するコンピュータ上で実行される。
ネットワーク・コンピュータ（NC）構造
ネットワーク構造においては、JTAPIアプリケーションまたはJava・アプレットは、遠隔ワークステーションで実行される。このワークステーションは、ディスプレイ，キーボード，プロセッサおよびある種のメモリのみを有するネットワーク・コンピュータでよい。ワークステーションがネットワーク・リソースにアクセスし、電話リソースを管理する中央サーバを利用する。JTAPIは、Javaの遠隔法実施（RMI：Remote Method Invocation），JOEまたは電話プロトコルなどの遠隔通信機構を介してこのサーバと通信する。以下の表がこの構造を示す。
デスクトップ・コンピュータ構造
デスクトップ構造においては、JTAPIアプリケーションまたはJavaアプレットは、電話リソースを内蔵するのと同じワークステーションで実行される。図８にデスクトップ構造を示す。
Java電話パッケージ・アーキテクチャ
Java電話APIは、Java言語パッケージの集合で構成される。各パッケージが、コンピュータ電話アプリケーションの一定の局面に関する特定の機能を提供する。電話サーバ実行部は下部構造のプラットフォームおよびハードウェアの機能によって、支援するパッケージを選定する。アプリケーションは、現在使用中の実行部により支援されるパッケージを照会する。また、アプリケーション開発者は、アプリケーションがタスクを実行するために必要な被支援パッケージのみを考慮する。図９はJTAPIパッケージのアーキテクチャを示す。
【００７５】
「コア」パッケージはJava電話APIの中心にある。コア・パッケージは、電話呼および初歩的電話機能をモデル化するための基本的なフレームワークを提供する。これらの機能には、電話呼の発生，電話呼の応答および電話呼への接続の切断などが含まれる。単純な電話アプリケーションでは、タスクを実行するためにコアのみを用いれば済み、他のパッケージの詳細を考慮する必要はない。たとえば、コア・パッケージによってアプレット設計者はウェブ・ページに電話機能を容易に追加することができる。
【００７６】
いくつかの「標準拡張」パッケージがJTAPIコア・パッケージの機能を拡張する。これらの拡張パッケージは、それぞれ、追加の電話機能をAPIに与える。現時点では、次の拡張パッケージがこのAPIについて存在する：呼制御，センター呼出，媒体，電話，プライベート・データおよび機能パッケージ。各パッケージを、それがJTAPIに与える特徴に関して以下にまとめ、個別の概要説明および仕様に関連させる。
JTAPIパッケージ・アーキテクチャは、実行部とアプリケーションの双方にとって双方向の通路である。言い換えると、電話サーバ実行部は下部にあるハードウェアの機能に基づき、内蔵する拡張パッケージ（コア・パッケージに加えて）を選定する。アプリケーションは、アプリケーションの所望するタスクを実行するために用いる必要のある拡張パッケージを（コア・パッケージに加えて）選定する。アプリケーションが、実行部の支援する拡張パッケージに関する実行部を照会し、アプリケーション開発者はアプリケーションに必要としないパッケージの詳細は考慮しないでよい。
Java電話標準拡張パッケージ
各JTAPI拡張パッケージにはコアAPIに対するその拡張部を説明するそれぞれの仕様があり、多くの場合それを記述する別の概要説明書を有する。以下のチャートは仕様可能な拡張パッケージをリストアップし、個別の概要説明書が存在する場合はそれに対する関連部を付記する。
呼制御パッケージ
javax.telephony.callcontrolパッケージは保留中の呼の発生，電話呼の転送および会議電話呼など、より高度な呼制御機能を提供することにより、コア・パッケージを拡張する。このパッケージは、電話呼のより詳細な状態モデルも提供する。
呼出センター・パッケージ
javax.telephony.callcenterパッケージは、大型の呼出センターを管理するために必要な高度な機能を実施する能力をアプリケーションに提供する。この高度な機能としては：配信，自動呼分配（ACD：Automated Call Distribution），予測呼出，アプリケーション・データの電話対象物との接続などがある。
媒体パッケージ
javax.telephony.mediaパッケージは、電話呼に関連する媒体ストリームへのアクセスをアプリケーションに提供する。アプリケーションは、これらの媒体ストリームからデータを読み書きすることができる。DTMF（タッチトーン）および非DTMFトーン検出と発生もjava.telephony.mediaパッケージで行われる。
電話パッケージ
javax.telephony.phoneパッケージは、アプリケーションが電話ハードウェア電話装置の物理的機能を制御することを可能にする。実行部はターミナルを構成部品の集合として記述し、これらの構成部品タイプの各々がこのパッケージ内でインタフェースを有する。
機能パッケージ
javax.telephony.capabilitiesパッケージにより、アプリケーションは特定の動作が実施されるか否かを照会することができる。機能は２つの形態をとる。すなわち、静止機能は実行部が機能に対応するか否かを示し、動的機能は、呼モデルの現在の状態が与えられると特定の動作が許されるか否かを示す。
プライベート・データ・パッケージ
javax.telephony.privatedataパッケージは、アプリケーションが下部構造のハードウェア・スイッチと直接データを通信することを可能にする。このデータは、スイッチに対して、スイッチ特有の動作を実施することを命令するために用いられる。アプリケーションは、このパッケージを用いて、Java電話API対象物と共にデータを「ピギーバック」方式で担うこともできる。
Java電話呼モデル
JTAPI呼モデルは６個のJava対象物で構成される。これらの対象物は、コア・パッケージ内のjavaインタフェースを用いて定義される。各呼モデル対象物は、電話界における物理的実体または論理的実体のいずれかを表す。これらの呼モデル対象物の主要目的は、電話呼および電話呼に含まれる最終地点を記述することである。これらの呼モデル対象物は特定の方法で互いに関連性を持つ。これを下記にまとめ、コア・パッケージ仕様の中でより詳細に説明する。
【００７７】
図１０は、JTAPI呼モデルと呼モデルを構成する対象物とを示す。各対象物の説明は図の後にある。
プロバイダ対象物
プロバイダ対象物は、電話サービス−プロバイダ・ソフトウェアの抽象的概念である。プロバイダは、サーバに接続されるPBX，デスクトップ装置内の電話／ファクス・カードまたはIPなどのコンピュータ・ネットワーク技術を管理する。プロバイダは、電話サブシステムのサービス特有の面を隠し、javaアプリケーションおよびアプレットが装置とは独立した方法で電話サブシステムと対話することを可能にする。
呼対象物
呼対象物は電話呼、すなわちサービス・プロバイダと呼の参加者との間に流れる情報を表す。電話呼は、呼対象物とゼロ個またはそれ以上の接続とによって構成される。２者呼の場合は、電話呼は１つの呼対象物と２つの接続部を有する。会議呼は、１つの呼対象物に関連する３つ以上の接続部を有する。
アドレス対象物
アドレス対象物は、電話番号を表す。これは電話呼の論理的な最終地点に関する抽象的概念である。これは物理的な最終地点とは全く異なることに留意されたい。実際に、１つのアドレスが数個の物理的最終地点（すなわちターミナル）に相当することがある。
接続対象物
接続対象物は呼対象物とアドレス対象物との間の通信リンクをモデル化する。この関係は、「論理的」側面とも呼ばれるが、これは接続対象物が呼とアドレス（すなわち論理的最終地点）との間の関係に関わるためである。接続対象物は呼とアドレスとの関係の現状を示すいくつかの状態のうちの１つである。この接続状態については後述する。
ターミナル対象物
ターミナル対象物は、電話とそれに伴う装置などの物理的装置を表す。各ターミナル対象物はそれに関連する１つ以上のアドレス対象物（電話番号）を有するが、これは複数の呼を管理することのできるオフィス電話などの場合である。ターミナルは呼の物理的な最終地点とも呼ばれるが、これはターミナルがハードウェアの物理的部分に対応するためである。
ターミナル接続対象物
ターミナル接続対象物は、接続と、ターミナル対象物により表される呼の物理的最終地点との間の関係をモデル化する。この関係は、接続の「物理的」側面とも呼ばれる（論理的側面をモデル化する接続と対照的に）。ターミナル接続は、接続と特定のターミナルとの間の関係の現状を記述する。ターミナル接続に関わる状態は本書に後述される。
コア・パッケージ法
コア・パッケージはその主要機能である電話呼の発生，電話呼の応答および電話呼への接続の切断に対応するために３つの方法を定義する。これらの方法とはそれぞれ、Call.connect(), TerminalConnection.answer(), Connection.disconnect()である。
Call.connect()
アプリケーションがアイドル呼対象物（Provider.createCall()を介して獲得）を有すると、Call.connect()法を用いて電話呼を発する。アプリケーションは、そのターミナル上に（ターミナルが複数の電話番号を持つ場合）発信ターミナル（物理的最終地点）と発信アドレス（論理最終地点）とを指定しなければならない。アプリケーションは宛先電話番号列も提供する。２つの接続対象物がCall.connect()法から戻され、電話呼の発信および宛先地点を表す。
【００７８】
TerminalConnection.answer()
アプリケーションは、ターミナル上でオブザーバ（後述）と共に着信呼があるときを監視する。ターミナルへの着信電話呼は、ベル呼出（RINGING）状態におけるそのターミナルへのターミナル接続によって示される（下記のターミナル接続状態参照）。このとき、アプリケーションはTerminalConnection.answer()を呼び出して、その着信電話呼に応答する。
【００７９】
Connection.disconnect()
Connection.disconnect()法は電話呼からアドレスを削除するために用いる。接続対象物はそのアドレスと電話呼との関係を表す。アプリケーションは、通常、接続が接続（CONNECETD）状態にあるときに、この方法を実施し、結果として接続は非接続（DISCONNECTED）状態に移る。コア・パッケージにおいては、アプリケーションは呼からアドレス全体を単純に削除して、呼の一部であるそのアドレスに関わるすべてのターミナルも削除される。呼制御拡張パッケージは、呼のみから個別のターミナルを削除する能力をアプリケーションに与える。
接続対象物状態
接続対象物は、呼とアドレスとの関係を反映する状態に常にある。接続が存在する状態は、情報の目的でアプリケーションにとって重要であるだけでなく、常に、接続対象物においてどの方法および動作を実施することができるかの指標となる。接続対象物の状態変化は、状態移行図において下記に示される原則により支配される。この図は、アプリケーション開発者に対して、現行状態に関して接続対象物が移行できる状態を保証する。これらの状態移行原則は、アプリケーション開発者にとっては非常に大切である。図１１は、接続対象物の可能な移行状態を示す。各状態の意味を以下に簡単にまとめる。
アイドル（IDLE）状態
アイドル状態は、すべての新しい接続対象物にとって最初の状態である。接続は、アイドル状態から別の状態にすぐ移行するのが普通である。アイドル状態の接続は、関係者がある形態の電話呼に参入したばかりであることを示す。アイドル状態においては接続に関して有効なコア方法はない。
進行中（INPROGRESS）状態
進行中状態は、電話呼が呼の宛先最終地点に向けて発されていることを示す。
警告（ALERTING）状態
警告状態は、電話呼の宛先側に着信電話呼が通知されていることを示す。
接続（CONNECTED）状態
接続状態は、関係者がアクティブに電話呼の一部であることを示す。接続状態における接続は、関係者が電話呼上で他の関係者に対して話しているか、トーンに接続されていることを示す。
非接続（DISCONNECTED）状態
非接続状態は、関係者がもはや電話呼の一部でないことを示す。非接続状態にいては接続に有効な方法はない。
失敗（FAILED）状態
失敗状態は、最終地点に向けて発された電話呼が失敗したことを示す。たとえば、アプリケーションがCall.connect()を用いて話し中の関係者に電話呼を発した場合、呼び出された関係者に関連する接続は失敗状態に移行する。
未知(UNKNOWN）状態
未知状態は、プロバイダが現時点で接続の状態を判断できないことを示す。接続は非接続または失敗状態にない限り、いつでも未知状態に出入りすることがある。この状態で接続に関して何らかの方法を実施した場合の効果は予測不能である。
ターミナル接続対象物状態
ターミナル接続対象物は、ターミナルと接続との関係を表す。前述のように、これらの対象物は呼の物理的側面を表し、どの物理的ターミナル最終地点が電話呼の一部であるかを説明する。接続対象物と同様に、ターミナル接続対象物は、それ自身の状態の集合と状態移行図とを有する。状態移行図は図１２に示され、各状態の短い説明を以下に示す。
アイドル（IDLE）状態
アイドル状態は、すべての新しいターミナル接続対象物にとって最初の状態である。これは、接続対象物のアイドル状態と同じ意味を持つ。
アクティブ（ACTIVE）状態
アクティブ状態は、ターミナルが能動的に電話呼の一部であることを示す。ターミナル送受器が外されていることを示す場合が多い。
ベル呼出（RINGING）状態
ベル呼出状態は、ターミナルが、ユーザに対してターミナルに着信電話呼があることを知らせていることを示す。
見失った（DROPPED）状態
見失った状態は、ターミナルがかつては電話呼の一部であったのに、その電話呼から外されたことを示す。見失った状態は、すべてのターミナル接続の最終状態である。
パッシブ（PASSIVE）状態
パッシブ状態は、ターミナルが電話呼の一部であるが能動的にはそうでないことを示す。パッシブ状態にあるターミナル接続は、ターミナル上のリソースがこの電話呼により使用されていることを示す。高度な機能を提供するパッケージを用いると、ターミナルはパッシブ状態から呼に加わることができる。
未知(UNKNOWN）状態
未知状態は、プロバイダがターミナル接続の現時点の状態を判断できないことを示す。接続対象物の未知状態と同様の意味を持つ。
電話呼の発生
上記のセクションではJTAPI呼モデル，コア・パッケージにおける基本的方法および接続とターミナル接続の状態を概説した。このセクションでは、これらの情報をすべてまとめて、多くの電話アプリケーションに見られる共通の状況を示す。このセクションでは、アプリケーションが単純な電話呼を発すると呼モデル全体が経験する状態変化を説明する。読者は、この単純な例の呼モデル変化を首尾一貫して理解できる。
【００８０】
呼モデルが経験する状態変化を説明するために用いられる手段を図１３に示す。この図は、呼モデル・タイミング図であり、種々の対象物の変化を、縦軸に沿って時間が経過することで示す。この図は、アプリケーションがCall.connect()法を実施した後の典型的状態変化を示す。
【００８１】
図１３において、縦軸に沿った整数により個別の時間的段階が示される。時間はこの軸に沿って下向きに増大するが、整数は実際の（クロック）時刻を示すものではない。
【００８２】
図１３は全体として、１つの電話呼を表す。この場合、図は２者による電話呼を表す（Call.connect()法は常に２者呼となる）。図を左半分と右半分の２つの部分に分ける。左半分は電話呼の発信端を表し、右半分は電話呼の宛先端を表す。
【００８３】
図の左（発信）側では、図に示されるように２本の縦線が発信ターミナルとアドレス（Call.connect()法の引数である）対象物を表す。横線は接続対象物またはターミナル接続対象物のいずれかを表記されたように表す。接続対象物が最も内側に描かれ、ターミナル接続対象物が最も外側の領域に描かれていることに注目されたい。
【００８４】
同様に、図の右（宛先）側では、２本の縦線が宛先アドレスおよびターミナルを表す。この例では、宛先アドレスに関して２つの宛先ターミナルがある。この構造については図１０で前述した。ターミナルが２つあるために、宛先側にもターミナル接続対象物が２つあることに留意されたい。
【００８５】
図１３は、次のように読み取ることができる：時間の経過と共に、接続およびターミナル接続対象物が状態を変化させる。新しい接続またはターミナル接続の横線の外観は作成されるそのタイプの新しい対象物に対応する。
【００８６】
電話呼発生の例では、２つの接続がアイドル状態で作成された後で発信接続が接続状態に移行し、宛先接続が進行状態に移行することがわかる。その時点で、発信ターミナルに対するターミナル接続が作成されアクティブ状態に移行する。宛先接続が警告状態に移行すると、２つのターミナル接続がベル呼出状態において作成される。
【００８７】
この時点で、宛先ターミナルの１つに居る人が呼に応答する。これが起こると、そのターミナル接続はアクティブ状態に移動し、もう一方のターミナル接続はパッシブ状態に移動する。同時に、宛先接続が接続状態に平行して移動する。電話呼が終了すると、すべての接続が非接続状態に移動し、すべてのターミナル接続は見失った状態に移動する。
【００８８】
最後に、この説明書は、電話呼の「論理的」および「物理的」側面という言葉を用いた。この図はこれらの概念を明確にする。アプリケーションは、接続対象物の状態変化（すなわち論理的側面）を監視することができる。図を見ることによって、読者は、これらの状態が電話呼のより高度なレベルへの進行を可能にすることを理解できる。ターミナル接続状態変化は、物理的側面を表す。ターミナル接続の状態変化を監視することによって、アプリケーションは各物理的最終地点で何が起こっているかを発見することができる。
Java電話オブサーバ・モデル
Java電話APIは、Java電話オブサーバ／観察可能モデルを用いてアプリケーションに対し、JTAPI呼モデルの種々の変化を非同期的に通知する。これらの変化には、対象物の状態変化および対象物の作成が含まれる。
【００８９】
プロバイダ，呼，ターミナルおよびアドレス対象物にはオブサーバがある。これらのオブサーバに対応するインタフェースは、それぞれプロバイダ・オブサーバ，呼オブサーバ，ターミナル・オブサーバおよびアドレス・オブサーバである。
【００９０】
プロバイダ・オブサーバは、プロバイダ対象物にすべての状態変化を報告する。コア・パッケージについては、プロバイダがサービス不能からサービス可能または停止に状態を変化させると、状態変化が報告される。
【００９１】
呼オブサーバは、電話呼の一部であるすべての接続およびターミナル接続２関する状態変化情報と、呼自身の状態変化とを報告する。これらの状態変化は、アドレス・オブサーバでもターミナル・オブサーバでも報告されない。
【００９２】
ときにより、アプリケーションはアドまたはターミナル対象物を、着信電話呼に関して監視しようとする。このような場合、アプリケーションは、Address.addCallObserver()またはTerminal.addCallObserver()法を用いる。これらの方法は、実行部に、アドレスまたはターミナルに来たすべての呼に呼オブサーバを自動的に付加することを命令する。これらの呼オブサーバは、呼がアドレスまたはターミナルを離れると削除される。
【００９３】
アドレスおよびターミナル・オブサーバは、これらの対象物における状態変化をすべて報告する。コア・パッケージにおいては、これらの対象物に関するイベントはない。しかし、アドレス・オブサーバおよびターミナル・オブサーバのインタフェースが依然として存在するので、他のパッケージはこれらのインタフェースを拡張することができる。
プロバイダの位置特定と捕捉
Java電話APIは、JTAPIの電話サーバ実行部がアプリケーションに対してそのサービスを利用可能にする取り決めを定義する。
【００９４】
アプリケーションをサーバにリンクする２つの要素は次のものである：
JtapiPeerFactory
JtapiPeerFactoryクラスは、電話サービスを必要とするアプリケーションに対する最初の接触点である。これは、名前をつけたJtapiPeer対象物またはデフォルトのJtapiPeer対象物を戻すことができる。これを静止クラスと定義する。
JtapiPeer
JtapiPeerインタフェースは、Java電話APIの販売業者用の特定の実行部の基礎となる。JTAPIの実行部を提供する各販売業者は、JtapiPeerFactoryによりロードすることのできるクラス内にこのインタフェースを内蔵しなければならない。
【００９５】
アプリケーションはJtapiPeer対象物を内蔵するクラスを通じてプロバイダ対象物を獲得する。
JtapiPeerFactory：開始
JtapiPeerFactoryは、JTAPIで定義される静止クラスである。この唯一の公然の方法であるgetJtapiPeer()により要求されるJtapiPeer実行部が獲得されるか、あるはデフォルト実行部を戻す。
【００９６】
getJtapiPeer()は、パラメータとして所望のJTAPIサーバ実行部クラスの名前をとり、そのクラスの対象物例として戻す。名前が提供されない場合は、getJtapiPeer()はデフォルトのJTAPIサーバ実行部対象物を戻す。
JtapiPeer：プロバイダ対象物の獲得
JtapiPeerはインタフェースである。これはJTAPIサーバ実行部により用いられる。これは、アプリケーションがプロバイダ対象物を捕捉し、それらのプロバイダ上で使用可能なサービスを照会し、JtapiPeer対象物例の名前を得るために用いる方法である。JtapiPeerインタフェースを内蔵するクラスを作成することにより、JTAPI実行例はアプリケーションに対して次の方法を使用可能にする。
【００９７】
アプリケーションは、JtapiPeer.getProvider()法を用いて、新しいプロバイダ対象物を獲得する。各実行部は１つ以上の異なる「サービス」に対応する（たとえば下部構造のネットワーク基板の異なるタイプ毎に）。使用可能なサービスは、JtapiPeer.getProvider()法を介して得ることができる。
【００９８】
アプリケーションは、プロバイダにオプションの引数を供給することもできる。これらの引数は、JtapiPeer.getProvider()法に伝えられる列引数に加えられる。列引数は次の形式を持つ：
＜サービス名＞；arg1=val1;  arg2=val2;...
ただし＜サービス名＞はオプションではなく、続く各オプション引数がセミコロンで分割される。これらの引数に対するキーは、２つの標準的な定義済みのキーを除き、実行部毎に異なる。
１．login：プロバイダにログイン・ユーザ名を送る。
２．passwd：プロバイダにパスワードを送る。
【００９９】
アプリケーションは、JtapiPeer.getName()法を用いて、JtapiPeer対象物例の名前を得る。これはJtapiPeer.Factory.getJtapiPeer()法に対する引数として用いられるのと同じ名前である名前パラメータである。
Java電話APIにおけるセキュリティ
JTAPIピア実行部は、Javaの「サンドボックス」モデルを用いて敏感な動作に対するアクセスを制御する。JTAPI法を呼び出す者は、実行時間システムにより決定される規範を用いて「信用される」と「信用されない」に分類される。信用される呼出者にはJTAPI機能に対する全面的なアクセスが許可される。信用されない呼出者は、システムの統合性を傷つけない動作に制限される。
【０１００】
JTAPIを用いて、それ自身のセキュリティ機構を提供する電話サーバまたは実行部にアクセスすることができる。これらの機構は所定の場所にある；ユーザ名やパスワードなどのパラメータはJtapiPeer.get.Provider()法を通じて提供される。
【図面の簡単な説明】
【図１】本発明の第１実施例による無線電話装置の一例である。
【図２】本発明の第２実施例による無線電話装置の一例である。
【図３】図１および図２の無線電話のいずれか一方のソフトウェア構造を示すソフトウェア・アーキテクチャ図である。
【図４】図３のJTAPI法実行例の詳細を示すプログラム流れ図である。
【図５】図３のJTAPI法実行例の詳細を示すプログラム流れ図である。
【図６】図３のJTAPI法実行例の詳細を示すプログラム流れ図である。
【図７】  JTAPIを説明する付票１に関する。
【図８】  JTAPIを説明する付票１に関する。
【図９】  JTAPIを説明する付票１に関する。
【図１０】  JTAPIを説明する付票１に関する。
【図１１】  JTAPIを説明する付票１に関する。
【図１２】  JTAPIを説明する付票１に関する。
【図１３】  JTAPIを説明する付票１に関する。
【符号の説明】
１０，１１  マイクロプロセッサ
１３  RFハードウェア
１４  オペレーティング・システム
１５  仮想装置
１６  アプリケーション・プログラム
１７  Javaクラス
１８  JTAPI実行部
２０  トランシーバ・ソフトウェア
２２  CSPMI（共通サービス・プロバイダ・モジュール・インタフェース）
２３  音声
２４  データ
【図１】
0004362178.tif 000004
【図２】
0004362178.tif 000005
【図３】
0004362178.tif 000006
【図４】
0004362178.tif 000007
【図５】
0004362178.tif 000008
【図６】
0004362178.tif 000009
【図７】
0004362178.tif 000010
【図８】
0004362178.tif 000011
【図９】
0004362178.tif 000012
【図１０】
0004362178.tif 000013
【図１１】
0004362178.tif 000014
【図１２】
0004362178.tif 000015
【図１３】
0004362178.tif 000016