JP2000165960A

JP2000165960A - ユ―ザ・アプリケ―ション・プログラムと電話プログラム間のａｐｉを備える無線通信装置およびその方法

Info

Publication number: JP2000165960A
Application number: JP11271653A
Authority: JP
Inventors: James E Mathis; ジェームス・イー・マティス
Original assignee: Motorola Inc
Current assignee: Motorola Solutions Inc
Priority date: 1998-09-28
Filing date: 1999-09-27
Publication date: 2000-06-16
Anticipated expiration: 2019-09-27
Also published as: BRPI9904366B8; AU734151B2; EP0994614B1; EP1519532A3; AR021829A1; IL131630A; ATE291806T1; IL176365A; AU4484599A; EP0994614A2; DE69924337T2; EP1519532A2; CN1249640A; TW457823B; US6269254B1; DE69924337D1; CA2282996A1; HK1026997A1; KR100342952B1; EP0994614A3

Abstract

(57)【要約】（修正有）【課題】電話APIと、メモリの占有量を最小限に抑
え、無線電話機能を提供する。【解決手段】無線通信装置は、その中にユーザ・アプ
リケーション・プログラム１６，電話プログラム１８お
よびこれらの間のアプリケーション・プログラミング・
インタフェース３０を格納するメモリを有する。API３
０は呼を開設するコマンドを有し、電話プログラム１８
は、呼を開設するコマンドの引数としていくつかのター
ミナル対象物５４〜５８を識別するアレイを受け取り、
それによって複数のターミナル対象物に関して呼が開設
される。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、ユーザ・アプリケーシ
ョン・プログラム（一般にアプリケーションまたはアプ
レットと呼ばれる）および電話プログラム（たとえば電
話方式の一例）を有し、ユーザ・アプリケーション・プ
ログラムと電話プログラムとの間のアプリケーション・
プログラミング・インタフェース（API： application
programming interface）を有する無線通信装置に関す
る。本発明は、APIの性状に関し、APIを介して実施され
る方法、たとえば二重モード呼を開設する方法に関す
る。

【０００２】

【従来の技術および発明が解決しようとする課題】Java
（商標）などの対象物志向型プログラム言語は、プラッ
トフォーム，オペレーティング・システムおよび装置間
においてプログラムの移植可能性があるためにより多く
の装置で普及しつつある。これは、ある装置のために開
発されたプログラムが異なる特性を持つ別の装置、たと
えば異なるオペレーティング・システムや異なるマイク
ロプロセッサでより容易に用いられることを意味する。

【０００３】対象物志向型プログラムは、従来のパーソ
ナル・コンピュータやこのような言語が広く用いられて
きた他のプラットフォームよりもメモリ・サイズや処理
能力が非常に小さい装置にも普及しつつある。Java（商
標）などの対象物志向型言語を非常に小さいプラットフ
ォームで用いようとする際に、いくつかの理由から問題
が起こっている。問題点の一例は、対象物が定まった方
法で他のプログラムと対話をする内蔵型コンピュータ・
プログラムであったり、クラスが同様の特性を持つ対象
物の集合のための一般的テンプレートであるような場合
に、対象物クラスの集合全体に対応する必要があること
である。異なるプラットフォーム間でプログラムの移植
可能性を維持するためには、任意のアプリケーションが
実施することができる均一性がクラス内に存在する必要
があるということが問題になる。たとえば、pJava（商
標）は、非常に大きな集合のクラス・ライブラリを有
し、クラス・ライブラリの集合全体の下部集合のみを用
いるより小型の言語を「eJava（商標）」と定義する努
力がなされている。

【０００４】クラスの一例はJava（商標）電話API（JTA
PI： Java telephony API）を通じて実施される電話ク
ラスである。このようなクラスの一例を「JTAPI実行
部」と呼ぶことがある。

【０００５】JTAPIはJava（商標）準拠コンピュータ電
話アプリケーションのための移植可能な対象物志向型ア
プリケーション・プログラミング・インタフェースであ
り、ワールドワイド・ウェブ上の以下のユニバーサル・
リソース・ロケータにおいて記述される：www.javasof
t.com/products/JATPI/index.html。Java（商標）電話A
PIは、第１および第３者の電話アプリケーション・ドメ
インの両方を支援する。APIはプログラミングを簡素化
しアプリケーションを容易にして、高度な電話アプリケ
ーションのために必要な機能を提供する。JTAPIはAPIの
集合である。基本的な呼方式と、電話呼を発しそれに応
答するなどの初歩的な電話機能を提供する「コア」API
がある。コアAPIは、呼出センターおよび媒体ストリー
ム・アクセスなどの特定の電話ドメインのための機能を
提供する標準的な拡張APIに囲まれる。JTAPIを用いて書
かれるアプリケーションは種々のコンピュータ・プラッ
トフォームおよび電話システム間で移植可能である。１
９９７年１２月にJTAPIのバージョン１．２が発行され
た。

【０００６】JTAPIの使用例に、JTAPIアプリケーション
またはJava（商標）アプレットが、ディスプレイ，キー
ボード，プロセッサおよびメモリのみを有するネットワ
ーク・コンピュータなどの遠隔基地で動作するネットワ
ーク構造がある。このコンピュータはネットワーク・リ
ソースにアクセスし、電話リソースを管理する中央サー
バを利用する。JTAPIは、Java（商標）の遠隔法実施（R
MI：remote method invocation）または電話プロトコル
などの遠隔通信機構を介してサーバと通信する。Java
（商標）電話APIは、Java（商標）言語パッケージの集
合によって構成される。各パッケージがコンピュータ電
話アプリケーションの特定の面に関する機能を提供す
る。

【０００７】電話サーバ実行部は、下部構造として存在
するプラットフォーム・ハードウェアにより、それが対
応するパッケージを選択する。アプリケーションは現在
使用中の実行部により支援されるパッケージを照会す
る。さらに、アプリケーション開発者は、アプリケーシ
ョンがタスクを実行するために必要な被支援パッケージ
のみに関わる。たとえば、呼出パッケージにより、アプ
レット設計者はウェブ・ページに電話機能を追加するこ
とができ、いくつかの標準的拡張パッケージがJTAPIコ
ア・パッケージを拡張する。これらの拡張パッケージは
APIに、全制御，呼出センター，媒体，電話，プライベ
ート・データおよび機能パッケージなどの追加の電話機
能を与える。

【０００８】JTAPIなどの標準的電話APIを、無線電話ま
たはその他の無線通信装置のための電話APIとして用い
ることが望ましい。

【０００９】無線通信装置のための電話APIとしてJTAPI
を用いるにはいくつかの問題点があり、特に汎ヨーロッ
パ・デジタル化移動体通信システム（GSM：Global Syst
em for Mobile）無線電話のための電話APIとして用いる
際に問題となる。一般に、JTAPIには約１３０ｋバイト
の総クラス・ファイル・サイズをもつ６３個超のイベン
ト・クラスを有するという問題がある。これは、無線電
話のプログラム全体の比較的小さい要素に対して、かな
りのメモリ割当があることを表す。JTAPIと互換性を持
つプログラムのメモリ要件を削減することが必要であ
る。

【００１０】GSM通信装置については、既存のJTAPIシン
タックスと方法署名（method signature）を用いて容易
にアクセスできないGSM機能がある。さらに、二重モー
ド呼（音声およびファクス呼または音声およびデータ呼
に関してGSMで用いられる用語）に対応することが必要
であり、二重モード呼の概念は有線電話およびJTAPIに
おいては知られていない。単純にJTAPIに追加しJTAPIを
削減することで満足の行く解決は得られない。これはJT
APIに追加するとイベント・クラスを発見する必要性が
増大し、JTAPIを削減するとプラットフォーム間でのア
プリケーションの移植を可能にする標準的APIの利点が
損なわれるためである。

【００１１】従って、無線通信装置のための電話API
と、メモリの占有量を最小限に抑え、無線電話特有の機
能を支援する関連クラスとが必要とされる。

【００１２】

【実施例】図１を参照して、無線電話を異なる層に関し
て図示し、ハードウェアを最下層にアプリケーション・
ソフトウェアを最上層に図示する。無線電話は、第１マ
イクロプロセッサ１０（マイクロプロセッサＡ），第２
マイクロプロセッサ１１（マイクロプロセッサB）およ
び特定のRFハードウェア１３によって構成される。マイ
クロプロセッサＡ，Ｂは、互いに接続される。マイクロ
プロセッサＢは、RFハードウェア１３に接続される。RF
ハードウェア１３は、少なくとも１つの受信機および送
信機を備える。RFハードウェアはさらに、好ましくはた
とえば音声コーダを備える音声通信要素２３と、好まし
くはたとえばデータ・モデムまたはファクス・モデムを
備えるデータ通信要素２４とを有する。マイクロプロセ
ッサはMicroware Systems Corporation（アイオワ州Des
Moines）により供給されるOS9000などのオペレーティ
ング・システム（OS）１４を有する。オペレーティング
・システムの上層には市販されるJava（商標）仮想装置
などの仮想装置１５が図示される。アプリケーション・
プログラム１６および他の様々なJava（商標）クラス１
７は、仮想装置１５上で実行される。クラス１７の１つ
がJTAPI実行部１８である。マイクロプロセッサ１７
は、呼の制御，フレーミングおよび一般にブロック・コ
ーディングなどのバイト・レベルの操作を実行するトラ
ンシーバ・ソフトウェア２０を有する。トランシーバ・
ソフトウェア２０は、共通サービス・プロバイダ・モジ
ュール・インタフェース（CSPMI：common service prov
ider module interface）２２を介してオペレーティン
グ・システム１４と通信を行う。

【００１３】図１の構造の代替例として、マイクロプロ
セッサＡ，Ｂを図２に破線で図示されるように単独の集
積回路２５に事実上統合することができる。この実施例
においては、マイクロプロセッサ１０，ハードウェア１
３，オペレーティング・システム１４，仮想装置１５お
よび種々のソフトウェア要素１６〜１８は図１の実施例
と同じである。マイクロプロセッサＢの代わりに、単独
の集積回路２５内のマイクロプロセッサ１０と一体化さ
れるデジタル信号プロセッサ（DSP：digital signal pr
ocessor）がある。DSP２７は、フレーミングと、ブロッ
ク・コーディングなどその他のバイト・レベル操作とを
実行するDSPコード２８を有し、一方で呼制御などの他
のトランシーバ・ソフトウェア機能は、オペレーティン
グ・システム１４を用いてマイクロプロセッサ１０上で
実行されるトランシーバ・ソフトウェア・コード２９に
よって実行される。適切な集積回路２５は、モトローラ
社（イリノイ州Schaumburg）から市販されるMコア（商
標）集積プロセッサおよびDSP（M-core (TM) integrate
d microprocessor and DSP）である。

【００１４】図３において、アプリケーション１６が図
示され（「フォーン・アプレット」と呼ばれる）、JTAP
I法実行部１８が図示される。JTAPIインタフェース３０
は、フォーン・アプレット１６とJTAPI法実行部１８と
の間をインタフェースして図示される。JTAPI法実行部
１８は、CSPMI２２を介するGSMトランシーバ３０などの
無線トランシーバからの入力を制御および受信する。GS
Mトランシーバ３０は、第２マイクロプロセッサ１１，R
Fハードウェア１３およびトランシーバ・ソフトウェア
２０（すべて図１に図示）によって構成される。

【００１５】JTAPI３０は「プロバイダ」などの高レベ
ル対象物のシンタクッスおよび動作を定義し、付表Ａに
記述されるJTAPI仕様書バージョン１．２に実質的に説
明される。また、GSMに特有の一定の動作が支援される
が、これらの動作に関して、以下の特定の意味論を定義
する。

【００１６】JTAPIプロバイダのドメインは単純に移動
局（MS）である。プロバイダのドメイン内の唯一のアド
レスはMSのものであり、たとえば単独の回線電話のドメ
イン内の１つのアドレスである。

【００１７】Provider.getAddresses()でMSについて１
アレイのアドレスが、通常１回のエントリのみで戻され
る。MSが複数の回線と電話番号とに対応する場合は、デ
フォルトまたは一次アドレスが第１エントリとなる。

【００１８】Provider.getAddress()はMSに割り当てら
れる番号または番号群のみを受け入れる。デフォルトで
は、一次アドレスすなわちgetAddresses()[0]が戻され
る。

【００１９】Provider.getTerminals()は、MSが支援す
るターミナルのアレイを戻す。別々の呼保持者（call b
earer）のタイプに関して別々のターミナルが定義され
る（下記参照）。

【００２０】Provider.getTerminals()は、ターミナル
名を特定する列をとる。デフォルトでは、音声ターミナ
ルが戻される。すべての実行部は個別のターミナル名と
して音声，データおよびファクスに対応しなければなら
ない（下記参照）。

【００２１】Provider.create/Call()で、プロバイダは
停止されていない限り、サービス不能（OUT#OF#SERVIC
E）となる。プロバイダがサービス可能（IN#SERVICE）
となるまで呼出を成功させることはできない。この機能
はJTAPI1.2createCall()予備条件に対する変更点であ
り、図５および図６に関してさらに詳細に説明される。

【００２２】Call.connect()で、宛先アドレス・ストリ
ングが共通SSコードおよびアドレス・フラッグに関して
分解される。Call.connect()に伝えられる宛先番号列が
「＋」キャラクタで始まる場合は、番号タイプ（TON：t
ype of number）が国際（INTERNATIONAL）に設定され、
そうでない場合はTONは未知（UNKNOWN）である。列に数
値しか含まれない場合は、ナンバリング・プラン識別子
（NPI：numbering-plan identifier）はISDNであり、そ
うでない場合は未知である。

【００２３】TerminalConnection.join()およびTermina
lConnection.leave()は、二重モード（音声およびデー
タまたは音声およびファクス）呼において呼モードを変
更するために用いられる。呼出においてアクティブなタ
ーミナル接続がいつも必ず１つあり、別のターミナル接
続においてjoin()を起動すると、呼出モードのスイッチ
が起こされ、アクティブなターミナル接続上のleave()
を呼び出すと別のスイッチが起動される。

【００２４】媒体ターミナル接続に関して定義されるAP
Iを用いてアプリケーションは呼の情報内容と対話を行
うことができる。Connetion.getTerminalConnection
s（）から戻されたターミナル接続が媒体ターミナル接
続を実行すると、アプリケーションは以下の方法を用い
ることができる：MediaTerminalConnection.getMediaAv
ailability()（これはJTAPI1.2に定義されるように実行
される）；MediaTerminalConnection.getMediaState()
（これはJTAPI1.2に定義されるように実行される）；Me
diaTerminalConnection.generateDtmf()（これは呼にDT
MFトーンを生成するために用いられる）。媒体ターミナ
ル接続における他のすべての方法はオプションである。

【００２５】プロバイダは、必ずしもサービス不能状態
の場合にすべてのアクティブな呼の接続を切るわけでは
ない。プロバイダは、呼をアクティブに維持し、一時的
な通信不良を想定して呼の再開設を試みる。ProvOutOfS
eviceEvのすぐ後にCallInvalidEvと関連するConnDiscon
nectedEvイベントが続かない場合（すなわちこれらが期
限内に続かない場合）は、アプリケーションは、プロバ
イダが呼を再開設しようと試みることを想定することが
できる。

【００２６】さらに、GSM機能には既存のJTAPIシンタッ
クスおよび方法署名を用いて容易にアクセスできないも
のがある。以下の新規の方法と異なる署名をもつ方法と
が定義される。

【００２７】Provider.getNetworkID()は、現ネットワ
ーク名を戻す。

【００２８】Provider.getServiceLevel()は、オペレー
ティング・サービス・レベルなし（NONE），緊急（EMER
GENCY），満杯(FULL）を戻す。

【００２９】MSがホームPLMNにない場合は、Provider.i
sRoaming()は真となる。

【００３０】これらの新たな方法により、アプリケーシ
ョンは現行の公衆地上移動網（PLMN：public land mobi
le network）と、オペレーティング・サービス・レベル
と、ユニットがホームPLMN上にあるか否かを決定するこ
とができる。

【００３１】JTAPIにおいては、ターミナル対象物は呼
の物理的な最終地点を表す。呼は音声を伝えることとす
る。GSMに関して定義された追加の呼保持者のタイプに
対応するために、１つの主要な呼保持者のタイプについ
て１つずつ、追加のターミナル・サブクラスが定義され
る。ターミナルのデータ・ターミナル・サブクラスはGS
Mデータ呼の物理的最終地点を表す。ターミナルのファ
クス・ターミナル・サブクラスはGSMファクス呼の物理
的最終地点を表す。

【００３２】通常のGSM MSは少なくとも３つのターミナ
ル、音声，データおよびファクス・ターミナルに対応す
る。MSは追加のターミナル例またはサブクラス（たとえ
ば内部データのための内部データ・ターミナルおよび接
続PCに送付されるデータのためのモデム・データ・ター
ミナルに対応する。アプリケーションは、適切なターミ
ナル上の着信呼イベントを観察することによって種々の
保持者の着信呼を受け入れる。

【００３３】次に図４を参照して、二重モードGSM呼に
対応することのできる特定の機能を説明する。

【００３４】図４は、図３のJTAPI実行部１８の詳細を
説明する。本方法の中心となるのはプロバイダ法４０で
ある。このプロバイダ法は、ある方式でオペレーティン
グ・システム１４とインタフェースするが、その方式を
詳細に説明する必要はない。本明細書の文脈で用いる場
合、「方法」とはあるクラスの事例で動作する、そのク
ラスの内部に定義される機能である。プロバイダ法４０
は、音声ターミナル対象物４２，データ・ターミナル対
象物４４，ファクス・ターミナル対象物４６およびアド
レス対象物４８を接続する。呼が設定されると、プロバ
イダ法４０は呼対象物を作成する。呼対象物５０はロー
カル接続対象物５２を作成する。単純な音声接続につい
ては、ローカル接続対象物５２が、音声ターミナル４２
を参照するターミナル接続対象物５４を作成する。詳細
に後述するが、ローカル接続対象物５２は第２ターミナ
ル接続対象物５６（および第３ターミナル接続対象物５
８）も作成することができる。第２ターミナル接続対象
物５６はデータ・ターミナル対象物４４を参照する。第
３ターミナル対象物５８がある場合は、ファクス・ター
ミナル４６を参照することができる。代替の構造とし
て、第２および第３ターミナル接続対象物をデータおよ
びファクス呼を作成する目的で作成することもできる
が、これについては後で詳述する。

【００３５】呼が三方向の呼である場合、呼対象物５０
は必要に応じて、それ自身の関連ターミナル接続対象物
６２〜６６を伴う追加の遠隔接続対象物６０を作成する
ことに注目されたい。さらに、別の呼（たとえば保留中
の呼）がある場合は、プロバイダ法４０は、それ自身の
対応ローカル接続およびターミナル接続を有する追加の
第２呼対象物７０を作成することができることにも注目
されたい。いずれの場合も、特定の無線電話に関して
は、３つのターミナル、すなわち音声ターミナル，デー
タ・ターミナルおよびファクス・ターミナルの３つしか
存在しない。そのためにいずれの場合も、ローカル接続
５２および遠隔接続６０や他のローカル接続または遠隔
接続により作成される種々のターミナル対象物はすべ
て、音声ターミナル対象物４２，データ・ターミナル対
象物４４およびファクス・ターミナル対象物４６をそれ
ぞれ参照することができる。

【００３６】次に説明するプロセスにおいては、GSMト
ランシーバ３０が無線電話通信チャネルを介して遠隔ス
イッチとの呼を設定することが目標であり、呼が二重モ
ード（たとえば音声およびデータまたは音声およびファ
クス）の場合は、JTAPI法実行部１８が二重モード機能
との呼を設定し、CSPMI２２を介してGSMトランシーバに
二重モード呼が開設されたことを通知することが目標で
ある。これにより、GSMトランシーバ３０がGSMシステム
に対して呼が二重モードであることを通知することがで
き、それによりGSMシステムのスイッチは、呼の設定要
求を受信すると、呼を発してその相互作用機能のモデム
を確保し、呼のデータまたはファクス機能を支援するこ
とができるようにする。さらに、JTAPIコマンドcall.co
nnect()（呼の接続）を用いて電話アプリケーション１
６の始動時にこの二重モード呼を開設することが目標で
ある。

【００３７】JTAPIバージョン１．２において、call.co
nnect()は、ターミナル対象物である引数を予想し、そ
れによりそのターミナルとの間に単モード呼の開設を可
能にする。二重モード呼を開設するには、本発明の好適
な実施例はcall.connect()を取り消して、単独の発信タ
ーミナルの代わりに第１引数としてターミナル・アレイ
をとる方法を追加する。ターミナル・アレイは、コマン
ドcall.connectの引数であり、ターミナル対象物のアレ
イを含む。このアレイは、音声ターミナルおよびデータ
・ターミナル、または音声ターミナルおよびファクス・
ターミナル、またはデータ・ターミナルおよびファクス
・ターミナル、または音声ターミナル，データ・ターミ
ナルおよびファクス・ターミナルである。方法プロバイ
ダ４０がこのコマンドと引数としてのアレイとで起動さ
れると、呼対象物５０およびローカル接続対象物２２を
作成する。ローカル接続対象物２２は、第１および第２
ターミナル対象物５４，５６を作成する。ローカル接続
対象物５２は、そのターミナルに関する第１ターミナル
接続対象物５４を照会し、第１ターミナル対象物５４は
ローカル接続対象物５２に対して応答して、そのターミ
ナル（すなわち参照するターミナル）が音声ターミナル
であることを示す。同様に、第２ターミナル接続対象物
５６がローカル接続対象物５２によって照会され、その
ターミナルがデータ・ターミナルであることを示して応
答する。ローカル接続対象物５４は、呼対象物５０に対
して、データ・ターミナル接続および音声ターミナル接
続が開設されることを知らせる。呼対象物５０は、プロ
バイダ４０に対して、二重モード呼が開設されたことを
知らせる。プロバイダ４０は、CSPMI２２を介し（OS１
４を通じて）二重モード呼が開設されたことをGSMトラ
ンシーバに知らせる。

【００３８】プロバイダ４０は、以下の要領でトランシ
ーバ３０を通じて呼を開設する。プロバイダ４０はその
タイプとしてPlaceCallReqを有するバッファを作成し、
以下の表１からパラメータM/O/Cを追加する。これらの
パラメータは呼を記述する。

【００３９】

【表１】パラメータ名パラメータ・タイプ M/O/C CallType¹ CALL#TYPE（呼タイプ） M CalledParty¹ PHONE#NUMBER（電話番号） C RepeatIndicator² REPEAT#INDICATOR（指示子反復） O CallType² CALL#TYPE（呼タイプ） O DataParameters³ DATA-PARAMETERS（データ・パラメータ） C CLIRDispositoin⁴ CLIR#DISPOSITION（CLIR配置） O CUGInfo⁵ CUG#INFO O １．緊急呼についてはオプション、他のすべての呼タイ
プについては強制２．多重呼タイプ呼出については強制３．呼タイプがファクスまたはデータの場合は強制４．クライアントがCLIRサブクリプション・デフォルト
を打ち消したい場合に入れる５．クライアントがCUGサブクリプション・デフォルト
を打ち消したい場合に入れる。

【００４０】このバッファの内容がシリアル・リンク２
２を介してトランシーバ３０に送られ、受け入れられた
場合は、トランシーバは以下の表２から確認メッセージ
を送り返す。

【００４１】

【表２】パラメータ名パラメータ・タイプ M/O/C CAllHandle¹ CALL#HANDLE（呼処理） C １．呼要求が成功した場合は強制。この確認メッセージが呼処理を与え、それによってマイ
クロプロセッサ１０は後続のコマンド内に呼を識別する
ことができる。

【００４２】表１では、呼タイプ２は代替の呼タイプを
示し、代替の呼タイプがデータまたはファクス（最初の
呼タイプはGSMでは常に音声である）ことを示す。この
ようにして、プロバイダ４０はトランシーバ３０に対し
て、代替の呼タイプがあることとそれがデータ（または
ファクス）であることを知らせる。かくして、トランシ
ーバ３０が呼を設定すると、スイッチには、代替の呼タ
イプがあること、この代替の呼タイプがデータ・モデム
（またはファクス・モデム）の確保を必要とすることを
知らせる。

【００４３】第１ターミナル・アレイ・エントリは最初
にアクティブになるターミナルであるが、呼はアレイ内
で示された任意のターミナルを扱うように設定される。
すなわち、他のターミナルに対するターミナル接続が呼
制御ターミナルconnection.bridgestate（接続ブリッジ
状態）（またはterminalconnection.passivestate（タ
ーミナル接続パッシブ状態）に置かれる。上記の如く、
joined/leave（結合／放置）を用いて現在の呼モードを
制御する。connect()のこの変数は、最初に示す二重モ
ード呼パラメータのGSM要件に対応するために用いられ
る（それにより、アプリケーション１６が、呼に加担す
るすべてのターミナルを前面に占有する必要がある）。

【００４４】Call.connectが打ち消されて、宛先アドレ
ス列のTON（番号タイプ）およびNPI（ナンバリング・プ
ラン識別子）を上記の如く示すことができない場合は、
これらを明示するための方法が追加される。

【００４５】Call.setEmergency()（呼設定緊急）が定
義されて、緊急モード・フラッグが設定される。

【００４６】Call.setCUGInfo()（呼設定CUG情報）が定
義されて、宛先アドレス列内にSS（補助サービス：supp
lementary services）コードを用いずにプログラム形式
で閉じられたユーザ・グループ情報が指定される。

【００４７】Call.setCallerIdRestricted()（呼設定発
呼者ID制限）が定義され、宛先アドレス列内にSSコード
を用いずにプログラム形式で、発呼回線識別制限要求が
指定される。

【００４８】Call.offHook()（呼オフフック）には対応
しない。

【００４９】アプリケーションは、転送または会議コン
トローラを指定することはできない。setTransferContr
oller()（設定転送コントローラ）およびsetConference
Controller()（設定会議コントローラ）法は、MethodNo
tSupported（方法非対応）を投入して、getConferenceC
ontroller()およびgetTransferController()が<NULL>
（ヌル）を戻す。

【００５０】setConferenceEnable()（設定会議イネー
ブル），getConferenceEnable()（会議イネーブル），s
etTransferEnable()（設定転送イネーブル）およびgetT
ransferEnable()（転送イネーブル）が、この呼を転送
または会議設定する機能を制御する内部フラッグを操作
する。

【００５１】Call.consult()（呼コンサルト）実施は宛
先アドレス列を含まねばならない；指定されない変数に
は対応しない。

【００５２】Connection.reject(int)（接続拒否）が定
義され、アプリケーションは、呼を拒否する場合の拒否
理由を指定することができる。これは、ユーザが決定す
るユーザ・ビジー機能に対応する。

【００５３】Connection.addToAddress()（接続追加ア
ドレス）には対応しない。

【００５４】Connection.park()（接続パーク）には対
応しない。

【００５５】ターミナル接続の下部クラスが定義され
（データ・ターミナル接続）、ネットワークと最終地点
のデータ・ターミナルとの間の物理的リンクを表す。デ
ータ速度，モデム・タイプ，プロトコルの階層などのデ
ータ呼パラメータを指定および照会するための方法が定
義される。同様に、ターミナル接続の下部クラス（媒体
ターミナル接続の下部クラスとしてより正確に記述され
る（ファクス・ターミナル接続））はネットワークと最
終地点ターミナルとの間の物理的リンクを表す。データ
加重，グループ・モードなどのファクス呼パラメータを
指定および照会するための方法が定義される。

【００５６】ファクス・ターミナル接続は、ファクス媒
体列を設定し、データ・ページおよびページ終点指標を
送信する媒体別方法も提供する。

【００５７】新ターミナル・イベントが定義され、アプ
リケーションは、進行中の呼が「TermForwardingActive
Ev」専用ターミナルについてアクティブであるか否かを
判定することができる。異なるサービス（すなわち音
声，ファクスおよびデータ）に対する転送が適切なター
ミナル対象物（すなわち音声，データ，ファクス）を通
じて知らされる。

【００５８】Provider.createCall()は、プロバイダが
停止されていない限りサービス不能であっても呼を発す
ること、またプロバイダがサービス可能になるまで発呼
に成功しないことを説明した。ここでは、この特徴につ
いて図５および図６を参照してより詳細に説明する。

【００５９】図５を参照して、いかなる理由があろうと
もアプリケーション１６が呼を発するか、あるいは接続
またはパケット・データ・セッションを開設することを
求める場合を考える。アプリケーション１６は、通常
は、ユーザに対するインタフェースであり、たとえば、
ユーザが無線通信装置（移動局またはMS）の電源を入れ
て電話番号をダイヤルすることにより呼を起こすことを
求めることができる。アプリケーション１６は、図５に
示されるプログラム（または方法）を、API３０に対す
るProvider.createCall()コマンドを通じてProvider.cr
eateCall方法（段階１００）を呼び出すことにより開始
する。段階１０１において、通信装置が停止モードにあ
る場合は、プログラムは段階１０２で単純にエラーを戻
し、段階１０３で終了する。装置が停止モードにない場
合は、段階１１０で呼対象物５０が作成され、図５のプ
ログラムが段階１１１で完了して、図６のプログラムの
開始の準備が整う。

【００６０】呼対象物５０の作成の直後、さらなるイベ
ントまたは条件を伴わずに（また打ち消しイベントもな
しに）、アプリケーション１６は、API３０に対するCal
l.connect()コマンドを通じてCall.connect方法（段階
１５０）を呼び出す。段階１５１において、通信装置が
サービス不能であると判定されると、プログラム（また
は方法）は、段階１５２で待機し他の機能が段階１５４
においてスキャン動作を実行する。待機期間は約１０秒
間あれば、スキャン・ルーチン内でセルラ・ネットワー
クに接続を行うには充分である。段階１５１または１５
６の後で、通信装置が無線通信網とサービスを開設した
場合は、段階１５８が始まり、コマンドがシリアル・イ
ンタフェース２２を介してトランシーバ３０に送られて
呼を発する。図６のプログラムは段階１６０で終了す
る。

【００６１】このようにして、ユーザはサービスが開設
される前でも電話番号のダイヤル動作を開始して呼を発
することができる。通常のユーザは、サービスが開設さ
れたか否かに関わらず通信装置が給電されるとすぐに発
呼を開始することを欲するので、これは特に有用な特徴
である。サービスの開設は、装置の電源オン動作（たと
えば電源キーを押したりフリップを開ける）に応答して
開始することができ、図５および図６の方法はユーザま
たはアプリケーションの他の動作に応答して平行に開始
することができる。

【００６２】JTAPI定義が異なるJTAPIイベントの各々に
ついて別のクラスを有することは大きな問題である。こ
のために合計で約１３０ｋバイトのクラス・ファイルを
もつ６３個超のクラスを定義するという重荷がMSに課さ
れる。

【００６３】本発明のある局面により、アプリケーショ
ンはイベント・クラスのタイプではなくイベントIDに基
づいて行われる。これによって、多数のイベント・クラ
スをはるかに小さな集合のイベント・カテゴリ・クラス
と置き換える。アプリケーションはイベントIDを用いて
広いタイプ内で特定のイベントを決定する。この結果、
対象物の包括に重大な損失を起こさずに大幅にスペース
を節約することができる。

【００６４】イベント・クラスは、以下の８つの包括的
クラスに分かれる： EV 全イベントの基本クラス ProvEv プロバイダ・イベント CallCtlAddrEv アドレスおよび呼制御アドレス・イベン
ト CallCtlCallEv 呼および呼制御呼イベント CallCtlConnEv 接続および呼制御接続イベント CallCtrlTermEv ターミナルおよび呼制御ターミナル・
イベント CallCtlTermConnEv ターミナル接続および呼制御ターミ
ナル接続イベント MediaEv 媒体イベントこれらの包括的クラスに分類される特定のイベントを以
下の表３に示す。

【００６５】

【表３】EV--全イベントの基本クラス ProvEv--プロバイダ・イベント ProvInServiceEv ProvObservationEndedEv ProvOutOfServiceEv ProvShutdownEvCallCtlAddrEv--アドレスおよび呼制御CallCtlCallEv--呼および呼制御呼イアドレス・イベントベント AddrEv CallEv CallCtlEv CallCtlEv AddrObservationEndedEv CallActiveEv CallCtlAddrDoNotDisterbEv CallinvalidEv CallCtlAddrFowardEv CallObservationEndedEv CallCtlAddrMessageWaitingEv CallCtlConnEv CallCtlTermConnEv ConnEv TermConnEv CallCtlEv CallCtlEv ConnAlertingEv TermConnActiveEv ConnConnectedEv TermConnCreatedEv ConnCreatedEv TermConnDroppedEv ConnDisconnectedEv TermConnPassiveEv ConnFailedEv TermConnRingingEv ConnInProgressEv TermConnUnknownEv ConnUnknownEv CallCtlTermConnBridgedEv CallCtlConnAlertingEv CallCtlTermConnHeldEv CallCtlConnDialingEv CallCtlTermConnInUseEv CallCtlConnDisconnectedEv CallCtlTermConnRingingEv CallCtlConnEstablishedEv CallCtlTermConnTalkingEv CallCtlConnFailedEv CallCtlTermConnUnknownEv CallCtlConnInitiatedEv CallCtlConnNetworkAlertingEv CallCtlConnNetworkReachedEv CallCtlConnOfferedEv CallCtlConnQueuedEv CallCtlConnUnknownEvCallCtlTermEv MediaEv TermEv MediaTermConnAvailableEv CallCtlEv MediaTermConnDtmfEv TermObservationEndedEv MediaTermConnEv CallCtlTermDoNotDisturbEv MediaTermConnStateEv MediaTermConnUnavailableEv 要するに、ワイヤレス電話機能を呼び出すための対象物
志向型コンピュータ・プログラムの開発に高度に適する
ワイヤレス通信装置のための電話APIとプロバイダ法を
備える関連の実行部とが開示された。APIを用いると、
プラットフォーム間と、メモリ要件が極めて低い実行部
において高度な移植可能性をもたらす。さらに、GSM無
線電話システムにおいて必要とされるような二重モード
呼出機能が、従来は単純な有線電話呼の開設に用いられ
る標準的なJTAPIイベント・クラスを用いて支援され
る。

【００６６】本発明のある局面により、その中にユーザ
・アプリケーション・プログラムと移動電話プログラム
とを格納するメモリによって構成される無線通信装置が
開示された。この移動電話プログラムは、装置が接続さ
れるワイヤレス・ネットワークを記述するパラメータを
維持する。これらのパラメータは次の１つ以上を含む：
現ネットワーク名；現ネットワークがホーム・ネットワ
ークであるか否かの指標。これらのパラメータはトラン
シーバから、あるいは移動インターネット・プロトコル
接続を介して移動電話プログラムに配布される。ユーザ
・アプリケーション・プログラムと移動電話プログラム
TON間のアプリケーション・プログラミング・インタフ
ェースはこれらのパラメータを呼び出して、それをアプ
リケーション・プログラムに戻すための少なくとも１つ
のコマンド（たとえば、Provider.getNetworkID(); Pro
vider.getServiceLevel()または Provider.isRoamin
g()）を有する。

【００６７】上記の説明は例としてあげられたに過ぎ
ず、本発明の範囲および精神の中で詳細の修正を行うこ
とができる。付表１ Java電話API 概要バージョン１．２導入部 Java電話API（JTAPI）はJava準拠コンピュータ電話アプ
リケーションのための携帯型対象物志向アプリケーショ
ン・プログラミング・インタフェースである。JTAPI
は、呼出センタアプリケーション開発者からウェブ・ペ
ージ設計者まで広範囲の使用者に対応する。JTAPIは第
１および第３者電話アプリケーション・ドメインの両方
に対応する。APIはプログラミングを簡素にアプリケー
ションを容易にするように設計され、なおかつ高度な電
話アプリケーションのために必要な機能を提供する。

【００６８】Java電話APIは、実際にはAPIの集合であ
る。「コア」となるAPIは基礎となる呼モデルと、電話
呼の送信および電話呼の応答など初歩的な電話機能を提
供する。コアAPIの周囲には、呼出センタおよび媒体ス
トリーム・アクセスなど特定の電話ドメインのための機
能を提供する標準的な拡張APIがある。JTAPIおよび拡張
パッケージのアーキテクチャを本書で説明する。

【００６９】Java電話APIを用いて書かれたアプリケー
ションは種々のコンピュータ・プラットフォームと電話
システム間で移植可能である。JTAPIの実行部は、Sun M
icrosystem社のSunXTL，Microsoft and Intel社のTAP
I，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を用いる２つの実際のコード例が
示される。１つの例は指定される電話番号に電話をかけ
る。もう１つの例は指定されたターミナルが着信電話呼
に応答する。プロバイダの位置特定と捕捉−−アプリケーションがJT
APIプロバイダ対象物を作成捕捉する方法を解説する。セキュリティ−−JTAPIのセキュリティ法を要約する。 Java電話機能 Java電話APIの機能および手引きとなる設計原則は次の
通りである：最も基本的な電話アプリケーションを簡素
にする。

【００７１】デスクトップ・アプリケーションから分配
呼出センターの電話アプリケーションに至る度量可能な
フレームワークを提供する。

【００７２】サービス・プロバイダに直接的にアプリケ
ーションをインタフェースする、あるいはSunXTL，TSAP
IおよびTAPIなどの既存の電話APIへのJava・インタフェ
ースとして機能する。

【００７３】標準拡張パッケージで拡張された単純なコ
アを基準とする。

【００７４】Javaの実行時間を使うことのできる構造で
あれば、広範囲のハードウェア構造で実行される。被支援構造 JTAPIは、電話リソースに直接アクセスする中央サーバ
や、ネットワーク上で電話リソースにアクセスする遠隔
ネットワーク・コンピュータを含む広範囲のシステム構
造において実行される。第１構造においては、ネットワ
ーク・コンピュータがJTAPIアプリケーションを実行し
て、図７に示されるようにネットワーク上で電話リソー
スにアクセスする。第２構造においては、アプリケーシ
ョンは図８に示されるように自身の電話リソースを有す
るコンピュータ上で実行される。ネットワーク・コンピュータ（NC）構造ネットワーク構造においては、JTAPIアプリケーション
またはJava・アプレットは、遠隔ワークステーションで
実行される。このワークステーションは、ディスプレ
イ，キーボード，プロセッサおよびある種のメモリのみ
を有するネットワーク・コンピュータでよい。ワークス
テーションがネットワーク・リソースにアクセスし、電
話リソースを管理する中央サーバを利用する。JTAPI
は、Javaの遠隔法実施（RMI：Remote Method Invocatio
n），JOEまたは電話プロトコルなどの遠隔通信機構を介
してこのサーバと通信する。以下の表がこの構造を示
す。デスクトップ・コンピュータ構造デスクトップ構造においては、JTAPIアプリケーション
またはJavaアプレットは、電話リソースを内蔵するのと
同じワークステーションで実行される。図８にデスクト
ップ構造を示す。 Java電話パッケージ・アーキテクチャ Java電話APIは、Java言語パッケージの集合で構成され
る。各パッケージが、コンピュータ電話アプリケーショ
ンの一定の局面に関する特定の機能を提供する。電話サ
ーバ実行部は下部構造のプラットフォームおよびハード
ウェアの機能によって、支援するパッケージを選定す
る。アプリケーションは、現在使用中の実行部により支
援されるパッケージを照会する。また、アプリケーショ
ン開発者は、アプリケーションがタスクを実行するため
に必要な被支援パッケージのみを考慮する。図９はJTAP
Iパッケージのアーキテクチャを示す。

【００７５】「コア」パッケージはJava電話APIの中心
にある。コア・パッケージは、電話呼および初歩的電話
機能をモデル化するための基本的なフレームワークを提
供する。これらの機能には、電話呼の発生，電話呼の応
答および電話呼への接続の切断などが含まれる。単純な
電話アプリケーションでは、タスクを実行するためにコ
アのみを用いれば済み、他のパッケージの詳細を考慮す
る必要はない。たとえば、コア・パッケージによってア
プレット設計者はウェブ・ページに電話機能を容易に追
加することができる。

【００７６】いくつかの「標準拡張」パッケージがJTAP
Iコア・パッケージの機能を拡張する。これらの拡張パ
ッケージは、それぞれ、追加の電話機能をAPIに与え
る。現時点では、次の拡張パッケージがこのAPIについ
て存在する：呼制御，センター呼出，媒体，電話，プラ
イベート・データおよび機能パッケージ。各パッケージ
を、それがJTAPIに与える特徴に関して以下にまとめ、
個別の概要説明および仕様に関連させる。JTAPIパッケ
ージ・アーキテクチャは、実行部とアプリケーションの
双方にとって双方向の通路である。言い換えると、電話
サーバ実行部は下部にあるハードウェアの機能に基づ
き、内蔵する拡張パッケージ（コア・パッケージに加え
て）を選定する。アプリケーションは、アプリケーショ
ンの所望するタスクを実行するために用いる必要のある
拡張パッケージを（コア・パッケージに加えて）選定す
る。アプリケーションが、実行部の支援する拡張パッケ
ージに関する実行部を照会し、アプリケーション開発者
はアプリケーションに必要としないパッケージの詳細は
考慮しないでよい。 Java電話標準拡張パッケージ各JTAPI拡張パッケージにはコアAPIに対するその拡張部
を説明するそれぞれの仕様があり、多くの場合それを記
述する別の概要説明書を有する。以下のチャートは仕様
可能な拡張パッケージをリストアップし、個別の概要説
明書が存在する場合はそれに対する関連部を付記する。呼制御パッケージ javax.telephony.callcontrolパッケージは保留中の呼
の発生，電話呼の転送および会議電話呼など、より高度
な呼制御機能を提供することにより、コア・パッケージ
を拡張する。このパッケージは、電話呼のより詳細な状
態モデルも提供する。呼出センター・パッケージ javax.telephony.callcenterパッケージは、大型の呼出
センターを管理するために必要な高度な機能を実施する
能力をアプリケーションに提供する。この高度な機能と
しては：配信，自動呼分配（ACD：Automated Call Dist
ribution），予測呼出，アプリケーション・データの電
話対象物との接続などがある。媒体パッケージ javax.telephony.mediaパッケージは、電話呼に関連す
る媒体ストリームへのアクセスをアプリケーションに提
供する。アプリケーションは、これらの媒体ストリーム
からデータを読み書きすることができる。DTMF（タッチ
トーン）および非DTMFトーン検出と発生もjava.telepho
ny.mediaパッケージで行われる。電話パッケージ javax.telephony.phoneパッケージは、アプリケーショ
ンが電話ハードウェア電話装置の物理的機能を制御する
ことを可能にする。実行部はターミナルを構成部品の集
合として記述し、これらの構成部品タイプの各々がこの
パッケージ内でインタフェースを有する。機能パッケージ javax.telephony.capabilitiesパッケージにより、アプ
リケーションは特定の動作が実施されるか否かを照会す
ることができる。機能は２つの形態をとる。すなわち、
静止機能は実行部が機能に対応するか否かを示し、動的
機能は、呼モデルの現在の状態が与えられると特定の動
作が許されるか否かを示す。プライベート・データ・パッケージ javax.telephony.privatedataパッケージは、アプリケ
ーションが下部構造のハードウェア・スイッチと直接デ
ータを通信することを可能にする。このデータは、スイ
ッチに対して、スイッチ特有の動作を実施することを命
令するために用いられる。アプリケーションは、このパ
ッケージを用いて、Java電話API対象物と共にデータを
「ピギーバック」方式で担うこともできる。 Java電話呼モデル JTAPI呼モデルは６個のJava対象物で構成される。これ
らの対象物は、コア・パッケージ内のjavaインタフェー
スを用いて定義される。各呼モデル対象物は、電話界に
おける物理的実体または論理的実体のいずれかを表す。
これらの呼モデル対象物の主要目的は、電話呼および電
話呼に含まれる最終地点を記述することである。これら
の呼モデル対象物は特定の方法で互いに関連性を持つ。
これを下記にまとめ、コア・パッケージ仕様の中でより
詳細に説明する。

【００７７】図１０は、JTAPI呼モデルと呼モデルを構
成する対象物とを示す。各対象物の説明は図の後にあ
る。プロバイダ対象物プロバイダ対象物は、電話サービス−プロバイダ・ソフ
トウェアの抽象的概念である。プロバイダは、サーバに
接続されるPBX，デスクトップ装置内の電話／ファクス
・カードまたはIPなどのコンピュータ・ネットワーク技
術を管理する。プロバイダは、電話サブシステムのサー
ビス特有の面を隠し、javaアプリケーションおよびアプ
レットが装置とは独立した方法で電話サブシステムと対
話することを可能にする。呼対象物呼対象物は電話呼、すなわちサービス・プロバイダと呼
の参加者との間に流れる情報を表す。電話呼は、呼対象
物とゼロ個またはそれ以上の接続とによって構成され
る。２者呼の場合は、電話呼は１つの呼対象物と２つの
接続部を有する。会議呼は、１つの呼対象物に関連する
３つ以上の接続部を有する。アドレス対象物アドレス対象物は、電話番号を表す。これは電話呼の論
理的な最終地点に関する抽象的概念である。これは物理
的な最終地点とは全く異なることに留意されたい。実際
に、１つのアドレスが数個の物理的最終地点（すなわち
ターミナル）に相当することがある。接続対象物接続対象物は呼対象物とアドレス対象物との間の通信リ
ンクをモデル化する。この関係は、「論理的」側面とも
呼ばれるが、これは接続対象物が呼とアドレス（すなわ
ち論理的最終地点）との間の関係に関わるためである。
接続対象物は呼とアドレスとの関係の現状を示すいくつ
かの状態のうちの１つである。この接続状態については
後述する。ターミナル対象物ターミナル対象物は、電話とそれに伴う装置などの物理
的装置を表す。各ターミナル対象物はそれに関連する１
つ以上のアドレス対象物（電話番号）を有するが、これ
は複数の呼を管理することのできるオフィス電話などの
場合である。ターミナルは呼の物理的な最終地点とも呼
ばれるが、これはターミナルがハードウェアの物理的部
分に対応するためである。ターミナル接続対象物ターミナル接続対象物は、接続と、ターミナル対象物に
より表される呼の物理的最終地点との間の関係をモデル
化する。この関係は、接続の「物理的」側面とも呼ばれ
る（論理的側面をモデル化する接続と対照的に）。ター
ミナル接続は、接続と特定のターミナルとの間の関係の
現状を記述する。ターミナル接続に関わる状態は本書に
後述される。コア・パッケージ法コア・パッケージはその主要機能である電話呼の発生，
電話呼の応答および電話呼への接続の切断に対応するた
めに３つの方法を定義する。これらの方法とはそれぞ
れ、Call.connect(), TerminalConnection.answer(), C
onnection.disconnect()である。 Call.connect() アプリケーションがアイドル呼対象物（Provider.creat
eCall()を介して獲得）を有すると、Call.connect()法
を用いて電話呼を発する。アプリケーションは、そのタ
ーミナル上に（ターミナルが複数の電話番号を持つ場
合）発信ターミナル（物理的最終地点）と発信アドレス
（論理最終地点）とを指定しなければならない。アプリ
ケーションは宛先電話番号列も提供する。２つの接続対
象物がCall.connect()法から戻され、電話呼の発信およ
び宛先地点を表す。

【００７８】TerminalConnection.answer() アプリケーションは、ターミナル上でオブザーバ（後
述）と共に着信呼があるときを監視する。ターミナルへ
の着信電話呼は、ベル呼出（RINGING）状態におけるそ
のターミナルへのターミナル接続によって示される（下
記のターミナル接続状態参照）。このとき、アプリケー
ションはTerminalConnection.answer()を呼び出して、
その着信電話呼に応答する。

【００７９】Connection.disconnect() Connection.disconnect()法は電話呼からアドレスを削
除するために用いる。接続対象物はそのアドレスと電話
呼との関係を表す。アプリケーションは、通常、接続が
接続（CONNECETD）状態にあるときに、この方法を実施
し、結果として接続は非接続（DISCONNECTED）状態に移
る。コア・パッケージにおいては、アプリケーションは
呼からアドレス全体を単純に削除して、呼の一部である
そのアドレスに関わるすべてのターミナルも削除され
る。呼制御拡張パッケージは、呼のみから個別のターミ
ナルを削除する能力をアプリケーションに与える。接続対象物状態接続対象物は、呼とアドレスとの関係を反映する状態に
常にある。接続が存在する状態は、情報の目的でアプリ
ケーションにとって重要であるだけでなく、常に、接続
対象物においてどの方法および動作を実施することがで
きるかの指標となる。接続対象物の状態変化は、状態移
行図において下記に示される原則により支配される。こ
の図は、アプリケーション開発者に対して、現行状態に
関して接続対象物が移行できる状態を保証する。これら
の状態移行原則は、アプリケーション開発者にとっては
非常に大切である。図１１は、接続対象物の可能な移行
状態を示す。各状態の意味を以下に簡単にまとめる。アイドル（IDLE）状態アイドル状態は、すべての新しい接続対象物にとって最
初の状態である。接続は、アイドル状態から別の状態に
すぐ移行するのが普通である。アイドル状態の接続は、
関係者がある形態の電話呼に参入したばかりであること
を示す。アイドル状態においては接続に関して有効なコ
ア方法はない。進行中（INPROGRESS）状態進行中状態は、電話呼が呼の宛先最終地点に向けて発さ
れていることを示す。警告（ALERTING）状態警告状態は、電話呼の宛先側に着信電話呼が通知されて
いることを示す。接続（CONNECTED）状態接続状態は、関係者がアクティブに電話呼の一部である
ことを示す。接続状態における接続は、関係者が電話呼
上で他の関係者に対して話しているか、トーンに接続さ
れていることを示す。非接続（DISCONNECTED）状態非接続状態は、関係者がもはや電話呼の一部でないこと
を示す。非接続状態にいては接続に有効な方法はない。失敗（FAILED）状態失敗状態は、最終地点に向けて発された電話呼が失敗し
たことを示す。たとえば、アプリケーションがCall.con
nect()を用いて話し中の関係者に電話呼を発した場合、
呼び出された関係者に関連する接続は失敗状態に移行す
る。未知(UNKNOWN）状態未知状態は、プロバイダが現時点で接続の状態を判断で
きないことを示す。接続は非接続または失敗状態にない
限り、いつでも未知状態に出入りすることがある。この
状態で接続に関して何らかの方法を実施した場合の効果
は予測不能である。ターミナル接続対象物状態ターミナル接続対象物は、ターミナルと接続との関係を
表す。前述のように、これらの対象物は呼の物理的側面
を表し、どの物理的ターミナル最終地点が電話呼の一部
であるかを説明する。接続対象物と同様に、ターミナル
接続対象物は、それ自身の状態の集合と状態移行図とを
有する。状態移行図は図１２に示され、各状態の短い説
明を以下に示す。アイドル（IDLE）状態アイドル状態は、すべての新しいターミナル接続対象物
にとって最初の状態である。これは、接続対象物のアイ
ドル状態と同じ意味を持つ。アクティブ（ACTIVE）状態アクティブ状態は、ターミナルが能動的に電話呼の一部
であることを示す。ターミナル送受器が外されているこ
とを示す場合が多い。ベル呼出（RINGING）状態ベル呼出状態は、ターミナルが、ユーザに対してターミ
ナルに着信電話呼があることを知らせていることを示
す。見失った（DROPPED）状態見失った状態は、ターミナルがかつては電話呼の一部で
あったのに、その電話呼から外されたことを示す。見失
った状態は、すべてのターミナル接続の最終状態であ
る。パッシブ（PASSIVE）状態パッシブ状態は、ターミナルが電話呼の一部であるが能
動的にはそうでないことを示す。パッシブ状態にあるタ
ーミナル接続は、ターミナル上のリソースがこの電話呼
により使用されていることを示す。高度な機能を提供す
るパッケージを用いると、ターミナルはパッシブ状態か
ら呼に加わることができる。未知(UNKNOWN）状態未知状態は、プロバイダがターミナル接続の現時点の状
態を判断できないことを示す。接続対象物の未知状態と
同様の意味を持つ。電話呼の発生上記のセクションではJTAPI呼モデル，コア・パッケー
ジにおける基本的方法および接続とターミナル接続の状
態を概説した。このセクションでは、これらの情報をす
べてまとめて、多くの電話アプリケーションに見られる
共通の状況を示す。このセクションでは、アプリケーシ
ョンが単純な電話呼を発すると呼モデル全体が経験する
状態変化を説明する。読者は、この単純な例の呼モデル
変化を首尾一貫して理解できる。

【００８０】呼モデルが経験する状態変化を説明するた
めに用いられる手段を図１３に示す。この図は、呼モデ
ル・タイミング図であり、種々の対象物の変化を、縦軸
に沿って時間が経過することで示す。この図は、アプリ
ケーションがCall.connect()法を実施した後の典型的状
態変化を示す。

【００８１】図１３において、縦軸に沿った整数により
個別の時間的段階が示される。時間はこの軸に沿って下
向きに増大するが、整数は実際の（クロック）時刻を示
すものではない。

【００８２】図１３は全体として、１つの電話呼を表
す。この場合、図は２者による電話呼を表す（Call.con
nect()法は常に２者呼となる）。図を左半分と右半分の
２つの部分に分ける。左半分は電話呼の発信端を表し、
右半分は電話呼の宛先端を表す。

【００８３】図の左（発信）側では、図に示されるよう
に２本の縦線が発信ターミナルとアドレス（Call.conne
ct()法の引数である）対象物を表す。横線は接続対象物
またはターミナル接続対象物のいずれかを表記されたよ
うに表す。接続対象物が最も内側に描かれ、ターミナル
接続対象物が最も外側の領域に描かれていることに注目
されたい。

【００８４】同様に、図の右（宛先）側では、２本の縦
線が宛先アドレスおよびターミナルを表す。この例で
は、宛先アドレスに関して２つの宛先ターミナルがあ
る。この構造については図１０で前述した。ターミナル
が２つあるために、宛先側にもターミナル接続対象物が
２つあることに留意されたい。

【００８５】図１３は、次のように読み取ることができ
る：時間の経過と共に、接続およびターミナル接続対象
物が状態を変化させる。新しい接続またはターミナル接
続の横線の外観は作成されるそのタイプの新しい対象物
に対応する。

【００８６】電話呼発生の例では、２つの接続がアイド
ル状態で作成された後で発信接続が接続状態に移行し、
宛先接続が進行状態に移行することがわかる。その時点
で、発信ターミナルに対するターミナル接続が作成され
アクティブ状態に移行する。宛先接続が警告状態に移行
すると、２つのターミナル接続がベル呼出状態において
作成される。

【００８７】この時点で、宛先ターミナルの１つに居る
人が呼に応答する。これが起こると、そのターミナル接
続はアクティブ状態に移動し、もう一方のターミナル接
続はパッシブ状態に移動する。同時に、宛先接続が接続
状態に平行して移動する。電話呼が終了すると、すべて
の接続が非接続状態に移動し、すべてのターミナル接続
は見失った状態に移動する。

【００８８】最後に、この説明書は、電話呼の「論理
的」および「物理的」側面という言葉を用いた。この図
はこれらの概念を明確にする。アプリケーションは、接
続対象物の状態変化（すなわち論理的側面）を監視する
ことができる。図を見ることによって、読者は、これら
の状態が電話呼のより高度なレベルへの進行を可能にす
ることを理解できる。ターミナル接続状態変化は、物理
的側面を表す。ターミナル接続の状態変化を監視するこ
とによって、アプリケーションは各物理的最終地点で何
が起こっているかを発見することができる。 Java電話オブサーバ・モデル Java電話APIは、Java電話オブサーバ／観察可能モデル
を用いてアプリケーションに対し、JTAPI呼モデルの種
々の変化を非同期的に通知する。これらの変化には、対
象物の状態変化および対象物の作成が含まれる。

【００８９】プロバイダ，呼，ターミナルおよびアドレ
ス対象物にはオブサーバがある。これらのオブサーバに
対応するインタフェースは、それぞれプロバイダ・オブ
サーバ，呼オブサーバ，ターミナル・オブサーバおよび
アドレス・オブサーバである。

【００９０】プロバイダ・オブサーバは、プロバイダ対
象物にすべての状態変化を報告する。コア・パッケージ
については、プロバイダがサービス不能からサービス可
能または停止に状態を変化させると、状態変化が報告さ
れる。

【００９１】呼オブサーバは、電話呼の一部であるすべ
ての接続およびターミナル接続２関する状態変化情報
と、呼自身の状態変化とを報告する。これらの状態変化
は、アドレス・オブサーバでもターミナル・オブサーバ
でも報告されない。

【００９２】ときにより、アプリケーションはアドまた
はターミナル対象物を、着信電話呼に関して監視しよう
とする。このような場合、アプリケーションは、Addres
s.addCallObserver()またはTerminal.addCallObserve
r()法を用いる。これらの方法は、実行部に、アドレス
またはターミナルに来たすべての呼に呼オブサーバを自
動的に付加することを命令する。これらの呼オブサーバ
は、呼がアドレスまたはターミナルを離れると削除され
る。

【００９３】アドレスおよびターミナル・オブサーバ
は、これらの対象物における状態変化をすべて報告す
る。コア・パッケージにおいては、これらの対象物に関
するイベントはない。しかし、アドレス・オブサーバお
よびターミナル・オブサーバのインタフェースが依然と
して存在するので、他のパッケージはこれらのインタフ
ェースを拡張することができる。プロバイダの位置特定と捕捉 Java電話APIは、JTAPIの電話サーバ実行部がアプリケー
ションに対してそのサービスを利用可能にする取り決め
を定義する。

【００９４】アプリケーションをサーバにリンクする２
つの要素は次のものである： JtapiPeerFactory JtapiPeerFactoryクラスは、電話サービスを必要とする
アプリケーションに対する最初の接触点である。これ
は、名前をつけたJtapiPeer対象物またはデフォルトのJ
tapiPeer対象物を戻すことができる。これを静止クラス
と定義する。 JtapiPeer JtapiPeerインタフェースは、Java電話APIの販売業者用
の特定の実行部の基礎となる。JTAPIの実行部を提供す
る各販売業者は、JtapiPeerFactoryによりロードするこ
とのできるクラス内にこのインタフェースを内蔵しなけ
ればならない。

【００９５】アプリケーションはJtapiPeer対象物を内
蔵するクラスを通じてプロバイダ対象物を獲得する。 JtapiPeerFactory：開始 JtapiPeerFactoryは、JTAPIで定義される静止クラスで
ある。この唯一の公然の方法であるgetJtapiPeer()によ
り要求されるJtapiPeer実行部が獲得されるか、あるは
デフォルト実行部を戻す。

【００９６】getJtapiPeer()は、パラメータとして所望
のJTAPIサーバ実行部クラスの名前をとり、そのクラス
の対象物例として戻す。名前が提供されない場合は、ge
tJtapiPeer()はデフォルトのJTAPIサーバ実行部対象物
を戻す。 JtapiPeer：プロバイダ対象物の獲得 JtapiPeerはインタフェースである。これはJTAPIサーバ
実行部により用いられる。これは、アプリケーションが
プロバイダ対象物を捕捉し、それらのプロバイダ上で使
用可能なサービスを照会し、JtapiPeer対象物例の名前
を得るために用いる方法である。JtapiPeerインタフェ
ースを内蔵するクラスを作成することにより、JTAPI実
行例はアプリケーションに対して次の方法を使用可能に
する。

【００９７】アプリケーションは、JtapiPeer.getProvi
der()法を用いて、新しいプロバイダ対象物を獲得す
る。各実行部は１つ以上の異なる「サービス」に対応す
る（たとえば下部構造のネットワーク基板の異なるタイ
プ毎に）。使用可能なサービスは、JtapiPeer.getProvi
der()法を介して得ることができる。

【００９８】アプリケーションは、プロバイダにオプシ
ョンの引数を供給することもできる。これらの引数は、
JtapiPeer.getProvider()法に伝えられる列引数に加え
られる。列引数は次の形式を持つ：＜サービス名＞；arg1=val1; arg2=val2;... ただし＜サービス名＞はオプションではなく、続く各オ
プション引数がセミコロンで分割される。これらの引数
に対するキーは、２つの標準的な定義済みのキーを除
き、実行部毎に異なる。１．login：プロバイダにログイン・ユーザ名を送る。２．passwd：プロバイダにパスワードを送る。

【００９９】アプリケーションは、JtapiPeer.getNam
e()法を用いて、JtapiPeer対象物例の名前を得る。これ
はJtapiPeer.Factory.getJtapiPeer()法に対する引数と
して用いられるのと同じ名前である名前パラメータであ
る。 Java電話APIにおけるセキュリティ JTAPIピア実行部は、Javaの「サンドボックス」モデル
を用いて敏感な動作に対するアクセスを制御する。JTAP
I法を呼び出す者は、実行時間システムにより決定され
る規範を用いて「信用される」と「信用されない」に分
類される。信用される呼出者にはJTAPI機能に対する全
面的なアクセスが許可される。信用されない呼出者は、
システムの統合性を傷つけない動作に制限される。

【０１００】JTAPIを用いて、それ自身のセキュリティ
機構を提供する電話サーバまたは実行部にアクセスする
ことができる。これらの機構は所定の場所にある；ユー
ザ名やパスワードなどのパラメータはJtapiPeer.get.Pr
ovider()法を通じて提供される。

【図面の簡単な説明】

【図１】本発明の第１実施例による無線電話装置の一例
である。

【図２】本発明の第２実施例による無線電話装置の一例
である。

【図３】図１および図２の無線電話のいずれか一方のソ
フトウェア構造を示すソフトウェア・アーキテクチャ図
である。

【図４】図３のJTAPI法実行例の詳細を示すプログラム
流れ図である。

【図５】図３のJTAPI法実行例の詳細を示すプログラム
流れ図である。

【図６】図３のJTAPI法実行例の詳細を示すプログラム
流れ図である。

【図７】JTAPIを説明する付票１に関する。

【図８】JTAPIを説明する付票１に関する。

【図９】JTAPIを説明する付票１に関する。

【図１０】JTAPIを説明する付票１に関する。

【図１１】JTAPIを説明する付票１に関する。

【図１２】JTAPIを説明する付票１に関する。

【図１３】JTAPIを説明する付票１に関する。

【符号の説明】

１０，１１マイクロプロセッサ１３ RFハードウェア１４オペレーティング・システム１５仮想装置１６アプリケーション・プログラム１７ Javaクラス１８ JTAPI実行部２０トランシーバ・ソフトウェア２２ CSPMI（共通サービス・プロバイダ・モジュール
・インタフェース）２３音声２４データ

Claims

【特許請求の範囲】

【請求項１】その中にユーザ・アプリケーション・プ
ログラム（１６）と、動作中は複数のターミナル対象物
（５４〜５８）を有する電話プログラム（１８）とを格
納するメモリ；および前記ユーザ・アプリケーション・
プログラム（１６）と前記電話プログラム（１８）との
間のアプリケーション・プログラミング・インタフェー
ス（API）（３０）であって、前記API（３０）は呼を開
設するコマンドを有し、前記電話プログラム（１８）が
前記呼を開設する前記コマンドの引数として、複数のタ
ーミナル対象物（５４〜５８）を識別するアレイを受け
取り、それによって前記複数のターミナル対象物（５４
〜５８）のための呼を開設することが可能になるAPI
（３０）；によって構成されることを特徴とする無線通
信装置。
【請求項２】前記複数のターミナル対象物（５４〜５
８）が音声ターミナル対象物（４２），ファクス・ター
ミナル対象物およびデータ・ターミナル対象物（４４）
からなるグループからの少なくとも２つの異なるターミ
ナル対象物（４６）として選択可能であって、それによ
り二重モード呼の開設が可能になることを特徴とする請
求項１記載の装置。
【請求項３】前記複数のターミナル対象物（５４〜５
８）の第１ターミナル対象物により制御される音声要素
と、前記複数のターミナル対象物（５４〜５８）の第２
ターミナル対象物により制御されるデータ要素とを少な
くとも有することを特徴とする請求項１記載の装置。
【請求項４】少なくとも前記電話プログラム（１８）
が実行される仮想装置（１５）を有する第１プロセッサ
（１０）と、その上で実行され、前記音声要素および前
記データ要素を制御するトランシーバ・ソフトウェア
（２０）を有する第２プロセッサ（１１）とによって構
成されることを特徴とする請求項３記載の装置。
【請求項５】前記第１プロセッサ（１０）と前記第２
プロセッサ（１１）との間のシリアル・リンク（２２）
によって構成されることを特徴とする請求項４記載の装
置。
【請求項６】前記第１プロセッサ（１０）と前記第２
プロセッサ（１１）との間のシリアル・リンク（２２）
によって構成され、前記リンク（２２）が呼を開設する
コマンドが主要タイプと交替タイプのいずれかであるこ
とを前記トランシーバ・ソフトウェア（２０）に知ら
せ、交替タイプが二重モード呼を示すことを特徴とする
請求項４記載の装置。
【請求項７】無線通信装置において二重モード呼を開
設する方法であって、アプリケーション・プログラム
（１６）からアプリケーション・プログラミング・イン
タフェース（API）（３０）を通じて、アレイによって
構成される引数を有するコマンドを用いて呼接続クラス
を呼び出す段階であって、このとき前記アレイが音声タ
イプ（４２），ファクス・タイプ（４６）およびデータ
・タイプ（４６）から選択される異なるタイプの複数の
ターミナル対象物（５４〜５８）によって構成される段
階によって構成されることを特徴とする方法。
【請求項８】前記呼接続クラスにおいて、音声ターミ
ナル（４２）を参照する第１接続対象物と、データ・タ
ーミナル（４４）およびファクス・ターミナル（４６）
のいずれか一方を参照する第２接続対象物とを呼び出す
段階によってさらに構成されることを特徴とする請求項
７記載の方法。
【請求項９】前記アプリケーション・プログラム（１
６）が単独のターミナル対象物によって構成される引数
を有するコマンドを用いることにより、二重モード呼出
の開設を支援しない呼接続クラスとさらにインタフェー
スすることができることを特徴とする請求項７記載の方
法。
【請求項１０】前記呼接続クラスを単独のターミナル
対象物によって構成される引数を有するコマンドにより
呼び出すことができ、それにより、単モード呼を開設す
ることを特徴とする請求項７記載の方法。
【請求項１１】その中にユーザ・アプリケーション・
プログラム（１６）と電話プログラム（１８）とを格納
するメモリであって、前記電話プログラム（１８）が定
義されたイベントの集合を有し、各定義された集合はイ
ベント識別子（ID）を有することを特徴とし、定義され
る前記集合が（ａ）基本クラス，（ｂ）プロバイダ・イ
ベント・クラス，（ｃ）アドレスおよび呼制御アドレス
・イベント・クラス，（ｄ）呼および呼制御呼イベント
・クラス，（ｅ）接続および呼制御接続イベント・クラ
ス，（ｆ）ターミナルおよび呼制御ターミナル・イベン
ト・クラス，（ｇ）ターミナル接続および呼制御ターミ
ナル接続イベント・クラス，および（ｈ）媒体イベント
・クラスに分類されるメモリ；および前記ユーザ・アプ
リケーション・プログラム（１６）と前記電話プログラ
ム（１８）との間のアプリケーション・プログラミング
・インタフェース（API）（３０）であって、前記API
（３０）が前記アプリケーション・プログラム（１６）
からコマンドを受け取り、前記コマンドが、前記グルー
プ（ａ）ないし（ｈ）のうちから１つのイベント・クラ
スを、前記イベント・クラス内のイベントを定義するID
と共に定義するAPI（３０）；によって構成されること
を特徴とする無線通信装置。
【請求項１２】各被定義イベントが方法を定義するコ
ンピュータ・プログラムを有し、被定義イベントの集合
のイベントに対応する方法に関する全コンピュータ・プ
ログラムがクラス対象物に含まれ、前記クラス対象物よ
り低い任意のレベルにおいては対象物内で下位定義され
ないことを特徴とする請求項１１記載の無線通信装置。
【請求項１３】その中にユーザ・アプリケーション・
プログラム（１６）と電話プログラム（１８）とを格納
するメモリによって構成される無線通信装置の動作方法
であって：前記電話プログラム（１８）内のプログラム
を呼んで、前記無線通信装置に関する無線サービスが開
設されたか否かに関わらず呼対象物（５０）を作成する
段階；および前記電話プログラム（１８）内のプログラ
ムを呼んで、呼の発生を開始するが無線サービスが開設
されていない場合は無線サービスが開設されるのを待つ
段階；によって構成されることを特徴とする方法。
【請求項１４】前記電話プログラム（１８）内の前記
プログラムを呼んで前記呼の発生を開始した後の期限後
にサービスが開設されていない場合は、前記アプリケー
ション・プログラム（１６）にエラーを戻す段階によっ
てさらに構成されることを特徴とする請求項１３記載の
方法。