JP4301377B2

JP4301377B2 - インテリジェント端末用のアプリケーションプロトコル

Info

Publication number: JP4301377B2
Application number: JP53079798A
Authority: JP
Inventors: テルンクヴィスト，クリスター; ニルソン，クレース; イスベルク，アンダース
Original assignee: テレフオンアクチーボラゲットエルエムエリクソン（パブル）
Priority date: 1997-01-06
Filing date: 1997-12-30
Publication date: 2009-07-22
Anticipated expiration: 2017-12-30
Also published as: AU732466B2; HK1028155A1; CN1254482A; CA2277090A1; JP2001507899A; DE69736492D1; ID25836A; BR9714265B1; WO1998031172A1; NO993152L; CA2277090C; CN1235421C; KR100592451B1; EP1005762A1; BR9714265A; EP1005762B1; DE69736492T2; EE9900269A; NO993152D0; AU5582698A

Description

発明の背景
本発明は通信システムに関し、より正確には、プロトコルを含む、通信システムにおける効率的で補助的なサービスのための技術に関するものである。
この技術は、様々な形態の電話機のユーザに広範囲で多種のサービスを提供することで知られている。この種のサービスにアクセスするために、ユーザは、スイッチあるいは、スイッチ機能付き又は無しのコンピュータであるサービスノード（ＳＮ）に接続する。多くのシステムにおいて、ＳＮ上で動作しているアプリケーションプログラムは、音声を電話機に送るために音声チャネルを使用する。また、音声チャネルは、DTMF（Dual-Tone Multi-Frequency）信号の桁を電話機からＳＮに送るために、逆方向に使用される。このようなシステムでは、電話機がどんな知能（インテリジェンス）を有することも必要でない。すなわち、サービスノードとユーザ間のやりとりがすべてであり、ユーザは音声を聞いて、電話機のボタンを押して応答すればよい。結果的に、電話機は通信に関しては透過的となり、ユーザを支援することは全くできない。
一方で、より高度なサービスも知られている。このようなサービスとしては、800サービスデータベース（800 Services Database）、クレジットカード照合データベース（Credit Card Verification Database）、地理的呼び出しルーティング（Geographic Call Routing）、複数位置内線ダイアリング（Multilocation Extension Dialing）、ネットワーク自動呼び出しの分配（Network Automatic Call Distribution）、フレキシブル呼び出しルーティング（Flexible Call Routing）、フレキシブルキャリア選択（Flexible Carrier Selection）などが挙げられる。有線電話サービスでは、このような高度な加入電話サービスがインテジェント・ネットワーク（ＩＮ;Intelligent Network）を介して提供されるであろう（例えばBellcore Advanced Intelligent Network（AIN）や、AINのCCITT/ITU版であるITUのCS-1、Q.1200など）。
無線通信システムにおいては、高度な加入電話サービスは、1996年３月18日に出願された「INTELLIGNENT MOBILE STATION FOR A CELLULAR TELECOMMUNICATIONS NETWORK」と言う名称の米国特許出願番号第08/617、139号（ここに、この特許が参考として挿入される）などのインテリジェント移動局（インテリジェント端末とも言う）によって実現されるであろう。なんらかの高度なサービスは、ＳＮと協動するインテリジェント移動局によって提供されるであろう。異なる種類のサービスに適応するために、ＳＮ内のコンピュータは、多種のインターフェースやスイッチ装置、ファクシミリ装置、音声処理装置、電子メールインターフェース、コンピュータネットワークインターフェース、モデム装置、データ記憶部などの広範囲で多種のリソースを扱うことになる。これらのリソースは、インテリジェント端末内のソフトウェアと相互にやりとりするソフトウェアによって制御される。そのようなＳＮは、単一ユーザあるいは複数ユーザの１つあるいは複数のＳＮとの相互のやりとりに対する解決策となる。
ＳＮとインテリジェント端末間の相互のやりとりは、コントロールチャネルとよばれる通信リンクによって行われる。コントロールチャネルは、音声チャネルへモデムを接続することによって確立したり、独立した通信リンクによって確立したりできる。図１ａ〜１ｄに、セルラーあるいは通常の固定電話のユーザへのサービスの提供を可能とするＳＮの配置を示す。
図１ａには、モデム103と１つ以上のサービスを提供するためのソフトウェア105とを内蔵するセルラー電話機101の場合が示されている。システム内には、ソフトウェア109とモデム111とを内蔵するＳＮ107も提供される。セルラー電話機101とＳＮl07間の通信リンクは、セルラーネットワーク113及びその他の各種ネットワーク115（例えば、公衆回線やプライベートネットワーク）によって確立することができる。ＳＮl07は、図１ａに示されるように、他のネットワーク115の一部であっても良いし、セルラーネットワーク113の一部であっても良いし、これらのネットワークの１つに（公衆回線に接続されているPABX（private access branch exchange）のような方法を用いて）オーバーレイする形で付加されていても良い。２つのモデム103及び111は、ＳＮ107とセルラー電話機101間で行われる情報伝達の物理的な手段を提供している。情報は、ＳＮのソフトウェア109とセルラー電話機のソフトウェア105間でやりとりされる。
図１ｂに、セルラー電話機が自分のモデムを持たないという点を除けば、図１ａに示されている方式と本質的に同様な別の方式を示す。この場合、無線基地局117がモデムの機能を代行している。セルラー電話機上のソフトウェア105からみれば、ＳＮ上のソフトウェア109とセルラー電話機上のソフトウェア105間におけるサービス関連情報の流れという点においては、同一と考えることができる。
図１ｃに、従来の固定電話機119にサービスを提供する方式を示す。この図においては、固定電話機119は１つ以上のサービスを提供するためのソフトウェア123を搭載したモデム装置121に接続されている。前述の方式と異なるのは、セルラーネットワークが固定ネットワークに置き換わっている点である。その他のすべての点において、この配置では、様々なサービスの要求に応じてＳＮ上のソフトウェア111がソフトウェア123と情報交換をして、図１ａ及び１ｂに示される配置と同様に機能する。
更に他の方式を図１ｄに示す。この場合、固定ディジタル電話機127は、各種モデムを介さずに固定ディジタルネットワーク129に直接的に接続される。したがって、ソフトウェア109を搭載するＳＮ107も直接、固定ディジタルネットワーク129に接続される。ＳＮ上のソフトウェア109は、各種サービスの提供の要求に応じて、ソフトウェア123と情報交換を行う。
以上のように、ＳＮ107及び”サービス電話機”（101、119、127のようなセルラーあるいは固定の各種電話機）が相互対話するソフトウェア123及びモデムと等価の能力を持っていなければならないことがわかる。これらは、相互対話するソフトウェア（あるいはサービスソフトウェア）の通信を維持する上位レベルのプロトコル（”アプリケーションプロトコル”と呼ぶことにする）、及びモデム間の通信を維持する下位レベルのプロトコルからなる、２つの異なるプロトコルによってもっとも効果的に支援される。この階層プロトコルを、図２ａ及び図２ｂに示す。階層プロトコルについては一般的な技術として知られているので、詳細についてはここでは言及しない。
図３に、ユーザが１人で、発呼者がＳＮ107の電話番号のみに電話するだけでも、異なる種類の電話機301、303、305、307へのインターフェースを１つのＳＮで提供できる例を示す。ＳＮ107上のソフトウェア309は、異なる電話番号（発呼者にはわからない番号）のユーザを呼び出すことができる。
コントロールチャネルを使用する新しいサービスの特徴は、アプリケーション・プロトコルが新しい機能及び／又はサービスをオープンに支援することを要求する。しかしながら、コントロールチャネルのいくつかの実装においては、新しい機能及び／又はサービスに関連する情報を運ぶために、限られた帯域しか提供されていない。そのため、効率的なアプリケーション・プロトコルが非常に望まれている。
全ヨーロッパ向けGSMシステムに関するETSI勧告のフェーズ２では、ベアラサービス及びテレサービスの両方を補足及び修正できる多くの追加サービスが指定されている。たとえば、呼の禁止や転送のサービス、２つの接続された呼の間での切り替えサービスなどがある。移動通信ネットワークのオペレータは、標準化されたGSMの追加サービスに加えて、オペレータ特有のサービスへの需要の増加を経験している。
オペレータがオペレータ特有のサービスを実装することができるようにするには、ネットワークのサービス・アプリケーションと移動局間でユーザが対話する包括的機構が必要となる。
今日のGSMでは、ネットワークのサービス・アプリケーションと移動局間のヨーザの対話を提供する機構がある。この機構は“USSD（United Supplementary Services Data）”と呼ばれている。以下の文章におけるUSSDについての記述は、GSMのフェーズ２に対応するUSSDで有効になった。ＵＳＳＤはＧＳＭの第１段階にも有ったが、対話の取り扱いはもっと限定されていた。
図４をみると、GSMスイッチングシステム内において、USSDはよく知られている“MAP（Mobile Application Part）”プロトコル401の一部になっている。無線インターフェースでは、USSD操作はレイヤー３の“Register”、“Facility”及び”Release Complete”メッセージ403によって行われる。
USSDサービス・アプリケーションは、MSC/VLR（Mobile services Switching Center/Visitor Location Center）405、HLR（Home Location Register）407、あるいは外部のMSN（Mobile Service Node）409などに存在する。USSDサービス・アプリケーションがMSNに実装されている場合には、MAPプロトコルの拡張である”USSD to external node”が使用される。
USSDのオペレーションは汎用的であり、ネットワークを通じて透過的にテキストを送る。ネットワーク内のサービス・アプリケーションから受け取ったテキストは、MS411に表示される。また、MS411におけるユーザのキーボード入力は、透過的にサービス・アプリケーションに送られる。
USSDは対話形式になっている。対話はネットワーク内のサービス・アプリケーション、あるいはMS411によって開始することができる。USSDの対話は、並行して音声通話接続があるなしにかかわらず、独立に存在することができる。
ネットワークサービス・アプリケーションがUSSD対話を開始した場合には、RequestあるいはNotifyオペレーションが呼び出される。MS411がネットワークサービス・アプリケーション（たとえば、MSC/VLR405内のUSSD appl 1など）から表示するテキスト文字列を含んだUSSD Requestオペレーションを受け取った場合には、MS411はこれを表示する。ユーザによって入力された文字列は、オペレーションの結果としてネットワークサービス・アプリケーションに送り返される。また、ネットワークサービス・アプリケーションが表示するテキストを含んだUSSD Notificationオペレーションを起動することも可能である。RequestとNotificationの違いは、Notificationの場合にはユーザからの応答がなくともよいことである。つまり、ネットワークサービス・アプリケーションに受領通知を返すだけでよい。
MS411のユーザは、特定のマンマシンインターフェース（MMI）入力をおこなうことによって、USSD対話を開始することができる。この入力が行われた場合、MS411はネットワークに対してユーザからの入力を含む”Process Unstructured USSD Request”を呼び出す。このMMI入力は、ネットワークに対してアプリケーションを識別させオペレーションが正しいネットワークノードへの経路を決めることができるようにする、ユニークなサービスコードを含んでいる必要がある。その後、ネットワークサービス・アプリケーションは、表示するテキストを含む結果のオペレーションを返すことができる。ネットワークサービス・アプリケーションは、それから対話を終了させることができる。また、ネットワークサービス・アプリケーションは、USSD RequestあるいはNotificationを起動することによって、対話を継続させることもできる。MS411からの応答を受け取った後に、ネットワークサービス・アプリケーションが更にUSSD RequestあるいはNotificationを起動することによって、対話を継続してもよい。
図５を用いて、USSDサービスの例を説明する。ステップ501において、ユーザは情報サービスのためのサービスコードをMS411に入力する。これに応答して、MS411はProc USSD request invoke（user input=USSD serv code）を、USSDサービスプロバイダ553及びサービス・アプリケーション555を共に装備している、HLR、MSC/VR、あるいは外部ノード551に対して発行する（ステップ503）。USSDサービスプロバイダ553はProc USSD request invokeを受け取り、適切なコマンドやパラメータ情報などをサービス・アプリケーション555に渡す。以下の動作では、サービス・アプリケーション555が、MS411と送受するメッセージの受信者及び発信源として参照される。しかしながら、これらのメッセージが下位層のUSSDプロバイダ553を通過していることがわかる。
サービス・アプリケーション555は応答をサービスプロバイダ553に返し、今度はサービスプロバイダ553がUSSD request invoke（“INFO SERV<LF>1 Weather<LF>2 TeleNum......”）をMS411に返す（ステップ505）。その結果、MS411は、ユーザに対して受信したテキストを表示する。
この例では、ユーザは1を入力してMS411のYESキーを押し、”Weather”を選択する（ステップ507）。この結果、MS411はUSSD request result（user input=1）をサービス・アプリケーション555に送信する（ステップ509）。
これに応答して、サービス・アプリケーション555はUSSD request invoke（“WEATHER<LF>Enter area:”）のメッセージをMS411に返す（ステップ511）。
この新しいテキストがユーザに表示された後、ユーザは046（この例の場合）を入力し、MS411のYESキーを押す（ステップ513）。この結果、USSD request result（user input=046）がサービス・アプリケーション515に送られる（ステップ515）。MS411のユーザとサービス・アプリケーション555との対話はこのような形で継続し、サービスの提供が完了した時点で接続が切断される。
以上のように、USSDは、簡単なオペレータ特有のサービスのためにユーザとの対話機構として動作することがわかるが、特により高度なサービスを実装しようとする場合に、いくつか欠点がある。
1.低帯域（300〜600bps）による長い応答時間、非効率的な符号化（ショートメッセージサービス（SMS）は７ビットのアルファベット）、及びMS411がインテリジェントでない端末なので、すべてのサービスロジックがサービス・アプリケーションに存在する必要があるという事実。たとえば、MSのメニューは、ユーザに表示する必要があるたびにMSに送信しなくてはならない。また、ユーザの選択結果も、論理判断を行うネットワークサービス・アプリケーションに送らなくてはならない。すなわち、高速な応答時間を得るには、アプリケーションサービス・プロバイダとMS間の通信速度が重要となってくる。しかしながら、前述のとおり、USSDは300〜600bpsの低い帯域しか利用できない。一般的に、帯域制限された通信手段では、約1000bps以上の速度でのオペレーションは行えない。
2.USSDを用いたサービス用のMSユーザインターフェースは原始的なものであり、通常のMS MMI形式を用いることが出来ない。たとえば、サービスがメニュー処理を含んでいた場合、それぞれのメニュー選択は数字（あるいはその他のアルファベット文字）によって識別しなくてはならない。ユーザは選択項目に対応した数字（あるいはアルファベット文字）を返す。このようなメニュー選択方式は、ユーザフレンドリーではなく、MS411内のその他のメニューとは異なるメニュー形式をあたえてしまう。なお、このユーザインタフェースは、MS411がグラフィカルインターフェースを持っている場合には利用できない。
3.MS固有の機能はUSSDサービスから利用できない。たとえば、インテリジェントな呼の処理は行えず、ローカルな電話帳へのアクセス（番号から名前への変換）もできない。
4.USSDサービスの寿命がネットワーク内のタイマにより制限される。
5.MS411とネットワーク内のサービス・アプリケーション555間で送信されるテキスト文字列の長さに制限がある。
6.MS411では、同時に１つのUSSD対話しか駆動できない。
ユーザとの対話の他の方策が知られている。これらは、アナログディスプレイサービスインターフェース（ADSI;Analog Display Services Interface）を含んでいる。これは、SPCS（Stored Program Controlled Swtching）システム（サービスノード）とアナログディスプレイサービスCPE（Customer Premises Equipment）（ターミナル）間の双方向データ伝送用の通信プロトコルである。データ伝送は、FFSK及びDTMFを用いて音声パス上で実行することができる。ADSIのデザインは、端末内にロード可能なサービスロジックを持つことを基本にしている。しかしながら、ASDIは固定ネットワークの全プロトコルスタックを特定するという制限がある。すなわち、ベアラから独立ではなく、前述のUSSDのようなアプリケーションプロトコルとして使用することができない。
又、インターネットのWWWサーバ及びクライアントで用いられているWWW-HTTP/HTMLの概念も含んでいる。WWWの概念における主な問題点は、要求される帯域幅にある。WWWは最低9.6kbpsのデータチャネルを要求するが、USSD接続の平均速度は300〜600bpsである。データチャネルがUSSDの代わりにベアラとして使用されている場合、並行して音声通話の接続を行うことはできない。また、WWWは厳密なクライアント・サーバの概念に基づいている。したがって、サーバがクライアントとサーバ間の対話を開始する方法はない。
発明の要約
したがって、本発明の目的は、通信システムにおいて追加のサービスを実現する機構を提供することにある。
本発明のさらなる目的は、通信システムにおいて追加のサービスを実現するプロトコルを提供することにある。
本発明のまたさらなる目的は、サービスノードと追加のサービスを受ける者との間に帯域制限のあるチャネルを持つ通信システムにおいて、追加のサービスを実現するプロトコルを提供することにある。
本発明の一態様において、前述及びその他の目的は、帯域制限された通信手段を用いてインテリジェント端末に接続されたサービスノードを含む通信システムで達成される。本発明の一態様においては、サービスノードでは、イベントを解析してプリミティブを決定し、帯域制限のある通信手段を用いて、プリミティブに対応するルーチンを実行するようインテリジェント端末に命令するメッセージを、インテリジェント端末へ送信し、インテリジェント端末では、プリミティブに対応するルーチンを実行してメッセージに応答することによって、インテリジェント端末のユーザにサービスが提供される。
本発明のほかの態様において、メッセージは更にパラメータを含み、プリミティブに対応するルーチンの実行ステップでは、受信したパラメータを用いる。
本発明のまた他の態様において、ルーチンを実行するステップは、インテリジェント端末のユーザに情報を提供するステップを含む。
本発明のまたさらなる他の態様において、ルーチンを実行するステップは、インテリジェント端末の状態を変更するステップを含む。
本発明のまたさらなるほかの態様において、イベントはインテリジェント端末からのメッセージの受信であり、そのメッセージはユーザがインテリジェント端末の特定のキーを押したことを示す。
本発明のさらなるほかの態様において、イベントはインテリジェント端末に影響を及ぼす何らかのものが発生したことの、サービスノードによる検出である。この発生は、例えばインテリジェント端末へ向けられた着呼などである。
本発明のまたさらなる他の態様において、インテリジェント端末でプリミティブに対応したルーチンを実行することによってメッセージに応答するステップは、インテリジェント端末で、ルーチンの実行にインテリジェント端末に現在ない状態表が必要かを決定するステップと、帯域制限のある通信手段を用いて、状態表を要求するメッセージをインテリジェント端末からサービスノードに送信するステップと、帯域制限のある通信手段を用いて、要求された状態表をサービスノードからインテリジェント端末へ送信するステップと、インテリジェント端末で、受信した状態表を用いてルーチンを実行するステップとを含む。
本発明のさらなる他の態様において、インテリジェント端末は、サービスノードとの通信を行うことなく、インテリジェント端末とユーザ間のメニュー処理入出力機能を更に実行する。
本発明の他の態様において、インテリジェント端末のユーザ入出力機能は、提供されるサービスとは独立のマンマシンインターフェース方式にしたがって制御される。
本発明の他の態様において、サービスは、インテリジェント端末で、イベントを解析して実行すべき動作を決定するステップと、帯域制限のある通信手段を用いて、実行すべき処理に対応しサービスノードに対応するルーチンを実行させるオペレーションをサービスノードに送信するステップと、サービスノードで、オペレーションに対応する動作を実行し、オペレーションの結果を帯域制限された通信手段を介してインテリジェント端末に返信するステップとを実行することにより、インテリジェント端末のユーザに提供される。
本発明の更に他の態様において、サービスの提供は、更に、インテリジェント端末で、インテリジェント端末に向けられた着呼の検出に応じて、帯域制限のある通信手段を介してサービスノードと最初のセッションを開始することを含む。
本発明のまた更に他の態様において、サービスノードと最初のセッションを開始するステップは、インテリジェント端末とサービスノードとの間でネゴシエーションを行い、インテリジェント端末とサービスノードにより用いられる資源が互いに矛盾しないことを確かめるステップを含む。
本発明のまた更に他の態様において、サービスノードと最初のセッションを開始するステップは、インテリジェント端末とサービスノードとの間の通信で用いられる符号化種別を明示するステップを含む。ある実施の形態においては、符号化種別は「基本符号化ルール（BER）」である。またある実施の形態においては、符号化種別は「圧縮符号化ルール（PER）」である。
本発明の他の態様において、最初のセッションが維持されている間に、インテリジェント端末とサービスノードとの間に第２のセッションが開始される。
本発明の他の態様において、サービスの提供は、インテリジェント端末によって実行されるオペレーションを定義するイメージ記述をサービスノードからインテリジェント端末へ送信するステップを更に備える。
本発明の更に他の態様において、帯域制限のある通信手段を用いてオペレーションをサービスノードに送信するステップは、オペレーションを「非構造の付加的サービスデータ（Unstructured Supplementary Services Data）」プロトコルのデータユニットにマッピングするステップを備える。本発明のある実施の形態においては、帯域制限のある通信手段を用いてオペレーションをサービスノードに送信するステップは、オペレーションを「短メッセージサービス（Short Message Service）」プロトコルのデータユニットにマッピングするステップを備える。
本発明の他の態様において、帯域制限のある通信手段を用いてオペレーションをサービスノードに送信するステップは、オペレーションを下位レイヤ・プロトコルのデータユニットにマッピングするステップを備える。
本発明の更に他の態様において、サービスの提供は、サービスノードからの補助を要求することなく、インテリジェント端末においてローカルなサービス機能を実行するステップを更に備える。
【図面の簡単な説明】
本発明の目的及び利点は、以下の図面と共に詳細な記述を読むことで理解される。
図１ａ〜１ｄは、セルラーあるいは従来の固定電話機のユーザへのサービス提供を容易にするサービスノードの可能な配置を示す図である。
図２ａ及び２ｂは、通信システムにおけるプロトコルの階層を示す図である。
図３は、ユーザが１人であり発呼者がＳＮの電話番号のみに電話する場合においても、異なる種類の電話機へのインターフェースを１つのＳＮで提供できる可能性を示す図である。
図４は、USSDが既知の移動アプリケーション部（MAP）プロトコルの一部として含まれているGSMスイッチングシステムを示す図である。
図５は、USSDサービスを示す図である。
図６は、SNとインテリジェント端末間の関係、及び、本発明の実施の形態に関連する多数の構成要素について示したブロックダイアグラムである。
図７ａ、７ｂ及び７ｃは、ユーザ、インテリジェント端末及びSN間の典型的な対話を示すフローチャートである。
図８及び図９は、SNによって起動される動作の可能性を示したフローチャートである。
図１０ａ、１０ｂ及び１０ｃは、「空」のインテリジェント端末にアプリケーションをダウンロードする方法を示すフローチャートである。
図１１は、本発明における実施の形態の一例に関係するSNのブロックダイアグラムを示す。
図１２は、IMSにサービスを提供するためにITAPが用いられているGSMネットワークを示す図である。
図１３ａ〜１３ｅは、ITAPサービスの例を示す図である。
図１４は、本発明の一態様における妥当な応答時間を得るためにSNとIMS間に送信されるオペレーションのサイズ及び数の使用制限を示す図である。
図１５は、本発明の一態様に関するロード可能なITAPイメージ記述の使用を示す図である。
図１６は、メニューオプション用の典型的なイメージ記述を示す図である。
図１７及び図１８は、GSMフェーズ２に対応するUSSDオペレーションにおけるパラメータ“USSD string”へのITAPオペレーションの典型的なマッピング方法を示す図である。
図１９〜５１は、ベアラとしてUSSD（GSMフェーズ２に対応）を用いるITAPシナリオを示す図である。
図５２〜５７は、着呼の選択に関連するシナリオを示す図である。
図５８〜６１は、本発明の一つの実施の形態に関連して、メールボックス関連のサービスに伴うシナリオを示す図である。
図６２及び図６３は、本発明の一つの実施の形態に関連して、ルーティングテーブルの更新に伴うシナリオを示す図である。
図６４は、本発明の一つの実施の形態に関連して、ITAPを用いる新しいメッセージの通知に関わるシナリオを示す図である。
発明の詳細な説明
本発明のさまざまな特徴を図面を用いて説明する。これらの図面においては、類似の部分は同じ参照文字を用いて特定する。
本発明の第１の実施の形態を、SN603とインテリジェント端末601間の関係及びその構成要素を示すブロックダイアグラムである図６を用いて説明する。アプリケーション（たとえば、より高度なサービスなど）の実装は、インテリジェント端末601内に存在する部分とSN603内に存在する部分との、２つの部分に分けられる。本発明の一態様例として、アプリケーションの２つの部分は、コントロールチャネル605で通信を行うためにアプリケーションプロトコルを利用する。
アプリケーションのインテリジェント端末601内の部分は、以下のようなアプリケーション構成要素によって、定義及び実装される。すなわち、状態及び状態表（State and State Tables）607;プリミティブ（Primitives）609;端末への制御メッセージControl Messages to the Terminal）611;端末からのメッセージ（Messages from the Terminal）613;端末レジスタ群（Terminal Registers）615。これらの構成要素の詳細を以下に示す。
状態及び状態表607
アプリケーションが動いているとき、端末は常に状態によって定義される。状態は、ユーザに対し表示する情報617や、状態の常時監視、ユーザからの操作の結果617を受け取るための動作を特定する、状態表607によって定義される。
本発明の一態様例では、ある状態からほかの状態への遷移は、プリミティブ609によって制御される。状態表607は、次のような状態を定義する。
ユーザに対し表示される情報617（たとえば、端末のディスプレイ上に表示されるもの）。
ユーザが利用可能なオプションの定義を含むユーザに表示されるメニュー。
全ての関連するユーザの操作（たとえば、インテリジェント端末601上のキー601を押すことなど）のために、呼び出されるプリミティブ609。
状態と時間になったときに呼び出すプリミティブとの時間監視。
プリミティブ609
インテリジェント端末601にはAPI（Application Programming Interface:アプリケーションプログラミング・インターフェース）が存在し、APIはプリミティブ609の組と関連する。これらのプリミティブ609は、コードから直接呼び出される（たとえば、起動シーケンス時に、状態表607を介して、あるいはSN603からリモートで呼び出す等）。プリミティブは、パラメータなしでも、あるいは１個、あるいは数個のパラメータを持ってもよい。
端末への制御メッセージ611
制御メッセージの組は、SN603からインテリジェント端末601への伝送のために定義されている。制御メッセージ611は、データを端末のレジスタ615に格納させたり、プリミティブ609を呼び出したりする。状態の変化を指令する制御メッセージ611は、プリミティブの呼び出しである。
端末からのメッセージ613
インテリジェント端末601は、１つ以上のメッセージを、呼び出されたプリミティブ609からSN603へと送信する。メッセージには特別なメッセージが存在し、それぞれはユニークな意味を持つ。また、イベントをSN603に通知する汎用メッセージも存在する。イベント通知メッセージは、現在の状態及びイベントを示すパラメータを含む（たとえば、キー”x”が押されたことや状態監視時刻が終了したことなどを示す）。インテリジェント端末601は、そのようなメッセージを送る時には、適切な基準の決定をSN603に任せるべきである。
端末レジスタ群615
端末レジスタ群615は、端末識別子、ユーザ固有あるいは一時的なデータなどの、インテリジェント端末６０１に固有のデータを保持している。ユーザあるいはSN603は、端末レジスタ群615を更新することができる。
ユーザとインテリジェント端末とSN603との間の典型的な対話を、図７ａ、７ｂ及び７ｃに示されるフローチャートを用いて説明する。この例では、現在、インテリジェント端末601が状態S1であるとする（ステップ701）。ステップ703で、インテリジェント端末601は、ユーザが入力キーｋを押したことを検出する。これに応答して、状態S1でキーｋに対応するプリミティブ609が特定されて呼び出される（ステップ705）。
イベント（すなわち、端末が状態S1であるときに、ユーザがキーｋを押したこと）は、SN603に通知されるべきイベントであってもなくともよい。通知しなくともよい場合（判定ブロック707においてnoの場合）には、処理は判定ブロック723に移る。通知する場合（判定ブロック707においてyesの場合）には、呼び出されたプリミティブがSN603にイベントを通知し（ステップ709）、インテリジェント端末は応答を待つ（ステップ711）。
SN603はイベント通知の受信を検出し（ステップ713）、イベントの解析を行って応答を返す（ステップ715）。解析では、インテリジェント端末601が次にどのプリミティブを呼び出すべきかを決定し、SN603はコントロールチャネル上でアプリケーションプロトコルを用いて、そのプリミティブを呼び出すように指示する（ステップ717）。
インテリジェント端末601はSN603からの通信を受け取り（ステップ719）、プリミティブを呼び出す（すなわち、インテリジェント端末601はプリミティブに指示された記憶してあるルーチンを実行する）（ステップ721）。実行は判定ブロック723まで継続する。
状態S1においてキーｋが押されたことに対応するプリミティブの実行結果（判定ブロック707におけるnoの場合）、あるいはSN603によって指示されたプリミティブの実行の結果（ステップ721）に対して、インテリジェント端末は状態の変更を要求されたり、要求されなかったりする（判定ブロック723）。変更が要求されない場合（判定ブロック723においてnoの場合）には、新しい情報の表示をユーザに行うかどうかの判定がなされる（ステップ725）。表示を行う場合には新しい情報がユーザに表示され（ステップ727）、端末は状態S1を保持する（ステップ729）。表示を行わない場合（判定ブロック725においてyesの場合）には、新しい情報はユーザには表示されず、単に状態をS1を保持するだけである（ステップ729）。
判定ブロック723にもどり、端末が状態を変化する決定がなされた場合（判定ブロック723においてyesの場合）には、状態S2の状態表が現在インテリジェント端末601内に記録されているかどうかを判定する（判定ブロック731）。一般に、インテリジェント端末601がアプリケーション用にプログラムされている場合には、関連する状態表607が、インテリジェント端末601にデータベースを直接接続する、あるいはSN603からネットワークを介して接続することによって、インテリジェント端末601上にダウンロードされている。アプリケーションが変更される場合には、１つ以上の状態表607がSN603からダウンロードされる。
アプリケーションがインテリジェント端末601内に記憶できるよりも多くの状態表607を必要とする場合、端末がその状態になったときに要求があり次第直ちにSN603から不足している状態表がダウンロードされる。これは、インテリジェント端末601がSN603に接続されている場合にも、インテリジェント端末が切断状態にある場合にも行われる。
不足している状態表607をインテリジェント端末601に記憶するのは、一時的である（すなわち、インテリジェント端末が対応する状態に留まる間のみである）。一方、不足している状態表607は、ほかの多数の状態表607と共にスタックに置くこともできる。スタックに新しい状態表607用の領域を確保するために、最も長時間使われていない状態表607が置き換えられる置換方式が用いられる。
また、他のプリミティブの呼出しあるいはオブジェクトコードとして、新しいプリミティブをダウンロードすることによってアプリケーションを起動したり変更したりすることもできる。
図７ｂのフローチャートに戻って、状態S2用の状態表607がインテリジェント端末内に記憶されている場合（判定ブロック731においてyesの場合）には、状態S2に移行し（ステップ743）、状態S2に関連する情報がユーザに示される（ステップ745）。インテリジェント端末は、現在、状態S2にある（ステップ747）。
しかしながら、状態S2用の状態表607がインテリジェント端末601内にまだ記憶されていない場合（判定ブロック731においてnoの場合）には、状態S2に対応する状態表607の要求を、インテリジェント端末601からSN603に送信する（ステップ733）。この要求を伝えるために、コントロールチャネル605上でアプリケーションプロトコルが使用される。
SN603は状態表607の要求の受信を検出し（ステップ737）、要求する状態表607の場所を把握し、インテリジェント端末601へ状態表607をダウンロードする（ステップ739）。ここでも、状態表607のダウンロードには、コンロロールチャネル605上でアプリケーションプロトコルが使用される。
インテリジェント端末601は状態S2用の状態表607を受け取り（ステップ741）、ステップ743を処理して状態S2となる。その後、状態S2に関連する情報はユーザに示される（ステップ745）。インテリジェント端末は、現在、状態S2にある（ステップ747）。
以上の例では、すべての動作はユーザの操作（たとえばユーザがキーｋを押したなど）に対応して起動された。一方で、図８及び図９のフローチャートで示されるように、SN603によってアプリケーションを起動することもできる。
図８において、インテリジェント端末は状態Ｓにあるとする。SN603はインテリジェント端末に影響するイベントの発生を検出する（ステップ801）。イベントは、たとえば新しい着呼であったり、新しいメッセージであってもよい。これに対し、SN603はイベントを解析する（ステップ803）。解析ではインテリジェント端末601内のどのプリミティブを次に呼び出すべきかを決定し、SN603は、コントロールチャネル605で用いられているアプリケーションプロトコルによって、このプリミティブの呼び出しを指示する（ステップ805）。
インテリジェント端末601はSN603からの通信を受けとり（ステップ807）、受け取った何らかのパラメータを用いてプリミティブを呼び出す（すなわち、インテリジェント端末601はプリミティブに対応する記憶されたルーチンを実行する）（ステップ809）。
この例では、インテリジェント端末はその状態を変化することを要求されないとする。結果として、新しい情報はユーザに示される（ステップ811）。たとえば、新しい情報を用いてインテリジェント端末601のディスプレイの一部が更新される。端末は状態Ｓに留まる（ステップ813）。
SN603で最初に検出されたイベントはまた、インテリジェント端末601の状態を変化させることもある。図９において、インテリジェント端末の初期状態が状態S1にあるとする。SN603はインテリジェント端末に影響するイベントの発生を検出する（ステップ901）。イベントは、たとえば新しい着呼であったり、新しいメッセージであってもよい。これに対し、SN603はイベントを解析する（ステップ903）。解析ではインテリジェント端末601内のどのプリミティブを次に呼び出すべきかを決定し、SN603は、コントロールチャネル605で用いられているアプリケーションプロトコルによって、このプリミティブの呼び出しを指示する（ステップ905）。
インテリジェント端末601はSN603からの通信を受けとり（ステップ807）、受け取った何らかのパラメータを用いてプリミティブを呼び出す（すなわち、インテリジェント端末601はプリミティブに対応する記憶されたルーチンを実行する）（ステップ909）。
この例では、インテリジェント端末601はその状態をS2に変化させるとする（ステップ911）。結果として、状態S2の情報がユーザに示される（ステップ913）。たとえば、新しい情報を用いてインテリジェント端末601のディスプレイの一部が更新される。端末は状態S2に変化する（ステップ915）。
図７ａ〜７ｃ、図８及び図９における例は、SN603との関連でさまざまなレベルの自立性によってインテリジェント端末601を動作させる可能性を示している。インテリジェント端末601の自立性は次の範囲内で扱われる。
インテリジェント端末601の動作が完全に自立的である。インテリジェント端末601は、SN603が利用するどんなコントロールチャネルの確立を行わなくとも、ユーザと相互対話ができる。
また、SN603に、制御を完全に取って代わらせ、ユーザに表示する情報を供給させることもできる。この場合、状態表607のどの状態においても、インテリジェント端末601が検出するどのイベントもＳＮ603に報告するように指示される。
アプリケーションは、インテリジェント端末601内の状態表607及び端末レジスタ群615によって定義されるので、ネットワークを介して端末に完全なアプリケーションをダウンロードすることが容易にできる。新しいアプリケーションを、ロードされたブーツストラッププログラムのみを持っているインテリジェント端末601へダウンロードすることもできる。また代わりに、新しいアプリケーションを、ほかのアプリケーションと置き換えるためにインテリジェント端末601にダウンロードすることもできる。
「空」のインテリジェント端末601にアプリケーションをダウンロードする方法を、図１０ａ、１０ｂ及び１０ｃに示されるフローチャートを用いて説明する。ここでは、あらかじめ決まっているSN603に接続するための電話番号及びパスワードをユーザが知っているものとする。SN603は、ユーザのアプリケーション、端末の識別子、期待されるユーザのパスワードを保持している。
インテリジェント端末601は初期状態で電源OFFの状態にある。ユーザが端末の電源をONする（ステップ1001）のに応じて、インテリジェント端末601は、好ましくはあらかじめ不揮発性メモリにロードされているブーツストラップ・アプリケーションプログラムを実行し始める（ステップ1003）。ブーツストラッププログラムは次のステップを起動する:
インテリジェント端末601は、インテリジェント端末601上の出力デバイス（例えばディスプレイ画面など）を使用して、どのようにしてSN603にアクセスするかの情報をユーザに提示する（ステップ1005）。その情報は、たとえばSN603に接続するための電話番号などである。インテリジェント端末はその後、ユーザからの応答を待つ（ステップ1007）。
これに対し、ユーザは要求された情報を入力し（ステップ1009）、インテリジェント端末はネットワークを介してSN603に呼び出しを行う（ステップ1011）。その後、データチャネル（例えばモデム接続）が確立される（ステップ1013）。インテリジェント端末は、それから、確立されたデータチャネルを使用して、このインテリジェント端末601の端末識別子を伴ったアプリケーション要求を送る（ステップ1015）。安全な接続を行うために、メッセージ対話においては、何らかの符号化されたメッセージをもちいて、ハンドシェーク及び端末識別子の送信を行うこともできる。アプリケーション要求を送信した後、インテリジェント端末601は応答を待つ（ステップ1017）。
SN603側では、SN603はインテリジェント端末601から到来した発呼に対して受信及び応答を行い（ステップ1019）、こちら側のデータチャネルの確立を行う（ステップ1021）。SN603はその後、対応するユーザのデータを識別するために受信した端末識別子を使用する（ステップ1023）。次に、SN603はパスワードの要求をインテリジェント端末601に送信する（ステップ1025）。
受信したパスワードの要求に対して、インテリジェント端末は、ユーザにパスワードの入力を通知し（ステップ1027）、ユーザの動作を待つ。ユーザへの通知は、あらかじめインテリジェント端末601に記憶していても良いし、要求の中に含めてＳＮ603から送信されても良い。
これに対して、ユーザはパスワードを入力し（ステップ1033）、インテリジェント端末はSN603にパスワードを送信し、応答を待つ（ステップ1035）。
パスワードの受信に対し、SN603はこのユーザのために記憶しているパスワードと受信したパスワードとを比較する（ステップ1037）。ここでは、このパスワードは正しいものとし、SN603は承認メッセージをインテリジェント端末601に送信する（ステップ1039）。
承認メッセージの受信に対して、インテリジェント端末601はサービスの開始を待っていることをユーザに通知し（ステップ1041）、その後、開始のためのダウンロードを待つ。ユーザへの通知は、インテリジェント端末601に記憶していても良いし、SN603から送信されても良い。
SN603はその後、インテリジェント端末601にアプリケーションデータをダウンロードする（ステップ1045）。インテリジェント端末は受信したアプリケーションデータを記憶し（ステップ1047）、更なるダウンロードを待つ（ステップ1049）。
SN603はその後、状態表をインテリジェント端末601にダウンロードする（ステップ1051）。インテリジェント端末601は受信した状態表を記憶し（ステップ1053）、更なるダウンロードを待つ（ステップ1055）。
その後、SN603は、インテリジェント端末にアプリケーションのダウンロードが完了したことを知らせる（ステップ1057）。この知らせの受信に応答して、インテリジェント端末601はユーザにアプリケーションが使用可能になったことを通知し（ステップ1059）、操作を待つ（ステップ1061）。ユーザへの通知は、聴覚的あるいは視覚的なメッセージであって良く、インテリジェント端末601内に記憶していたり、SN603によって送られきても良い。
SN603はその後、インテリジェント端末601に状態１になるように指示し（ステップ1063）、サービス要求を待つ（ステップ1065）。指示の受信に応答して、インテリジェント端末601はユーザに状態１の情報を表示し（ステップ1067）、状態１に留まる（ステップ1069）。
新しい状態表607のダウンロード及びインテリジェント端末601からのイベント通知メッセージに依存しない汎用サービスは、アプリケーションプロトコルの変更やインテリジェント端末601の再プログラムを行うことなしに、新しいアプリケーションの利用を可能とする。
前述の配置は、機能が固定的に配置されていない場合に有利である。機能は、SN603とインテリジェント端末601間を容易に移動できる。新しい機能が追加された場合には、初期的にはSN603に配置され、その後、１つ以上の状態表607としてインテリジェント端末601に記憶される。
機能の配置は、次のような考え方に基づいて最適化できる。
SN603及びインテリジェント端末内のプロセッサの能力及び記憶装置の容量
コントロールチャネル605の伝送容量
ユーザに提供する情報量
SN603にコントロールチャネルの確立が行われず、インテリジェント端末601がスタンドアロンモードであるときに、機能の一部あるいは全部を実行するための条件
機能が使用される頻度
前述の配置は、インテリジェント端末601及びSM603を構成するシステムの機能を容易に変更することができるという面においても利点がある。このことは以下の場合に実現する。
システムがほかのアプリケーションによって使用されているとき
新しいアプリケーションが更に開発され、新しい機能が追加されたとき
何人かのユーザが同じインテリジェント端末601を使用しており、同じアプリケーションに対して個人的なユーザインタフェースを持っているとき
ユーザがユーザのアプリケーションの機能を変更したいと考えているとき
次に、本発明における他の実施の形態について述べる。この実施の形態では、オペレータがより進んだサービスの実装を可能にするUSSD上のアプリケーションプロトコルが提供される。本発明の理解を容易にするために、この実施の形態は移動体通信システムの環境として記述される。しかしながら、ここで説明する技術が移動体通信システムだけでなく、ほかの形態の通信システムにも同等に適用可能であることは、専門技術者によって理解されるであろう。すなわち、移動体端末に関して言えば、MSC/VR、HLRのようなセルラー通信システムの要素などが本発明の範囲を制限すると解釈すべきではなく、本発明のほんの数例が実施されたものと解釈すべきである。
本実施の形態では、サービスアプリケーションのロジックは、ネットワークノード（たとえばSN）と、以前に参照して取り入れた、1996年３月18日の「INTELLIGENT MOBILE STATION FOR A CELLULAR TELECOMMUNICATIONS NETWORK」（Attorney Docket No.1000-0022）、米国特許出願番第08/61719号に記述されているIMS（Intelligent Mobile Station）のようなインテリジェント端末との両方に存在する。アプリケーションのロジックとインテリジェント端末が互いに通信を行うプロトコルを、ここではITAP（Intelligent Terminal Protocol:インテリジェント端末プロトコル）と呼ぶことにする。前述のように、SNとインテリジェント端末間の通信には階層化プロトコルが使用され、このプロトコル内において、ITAPはベアラに依存しないプロトコルであり、GSMフェーズ２に関するUSSDプロトコルあるいはSMS（Short Message Protocol:ショートメッセージ・プロトコル）のような下位層のプロトコルを用いることによって伝送される。IMSのユーザは、要求したサービスが存在するサービスノードと通信をおこなう。ITAPによる接続は並行して行われている音声通信と独立に行われる。
ITAPの特徴は以下のものを含む。
サービスの独立性。ITAPは汎用のプロトコルである。あらゆるパーソナル通信サービスのために、ITAPをサポートするIMSを用いることができる。
サービス追加及びサービス修正を行うためにIMSのソフトウェアを変更する必要がない。このことは、サービスの修正や新しいサービスの追加があったときに必要となるソフトウェアの修正のすべてが、ネットワークサービスノードにおいてのみ行えばよいことを意味する。
ベアラの独立性。これは、ITAP通信がベアラの音声接続の存在を必要としないという事実を含んでいる。
ITAPは低速のベアラに対して最適化される。利用可能なベアラはUSSDや（低速のベアラである）SMSを含んでいるので、ITAPプロトコルはユーザにとって実用的な応答時間を達成できるように最適化される。
グラフィック式及びテキスト式両方のインテリジェント移動局をサポートする。
ITAPの概念は標準化に適用できる。
サービスノードはデータマスタである。
オペレータのサービス管理が複雑でない。新しいサービスを追加したり既存のサービスを更新したりすることが容易である。
図１１は、本発明における実施の形態の一態様例のSN1101のブロックダイアグラムである。SN1101は、階層的に組織された１つ以上のソフトウェアプログラムを実行するコンピュータ装置によって構成されてよい。最下位レイヤは、既知の技術であるUSSDサービスプロバイダ1103である。USSDサービスプロバイダ1103の上位には、下位のUSSDサービスプロバイダ1103と上位のサービスアプリケーション間のインターフェースサービスを提供するITAPサービスプロバイダ1105がある。プロトコルスタックとして、ITAPサービスプロバイダ1105は以下の事項を受け持つ。
ITAPのオペレーションの符号化及び復号
通信の意味のチェック。たとえば、最初に受信したオペレーションを確認するのは、ITAPバインドオペレーション（BIND operation）である。
特定の実装で使用されているベアラ上にITAPのマッピング（たとえばUSSD）。マッピングは、通信のためのITAPオペレーションを２つ以上のベアラプロトコルデータユニットに分割することも含んでいる。
また、ITAPサービスプロバイダ1105は、getImageDescription（後述）とよばれるITAPオペレーションを、単独で受け持っていてもよい。
図１２に、IMS1201にサービスを提供すためにITAPが用いられているGSMネットワークを示す。これに関して、GSMの規格やCCITT勧告に記述されている多くの概念や要求条件などは、図示されている実施の形態が適用されている環境を理解するのに役立ち、特に、GSM 02.90、GSM 09.02、GSM 03.38、バージョン4.0.0、CCITT勧告X.229、及びCCITT勧告X.219が関係する。これらのGSM及びCCITTの文書を、ここにその全体を参考として挿入する。
ITAPアプリケーション1203は、図１１に示されるように、USSDサービスプロバイダ1103及びITAPサービスプロバイダ1105を含む移動体サービスノード1101内に存在する。ITAPメッセージは、MAP-USSDメッセージを用いるGSMネットワーク1205、及びレイヤ3-USSDメッセージを用いる無線インターフェースを介して、伝送される。
ITAPサービスの例を、図１３ａから図１３ｅを用いて説明する。ここで示されているサービスは、ユーザがサービスアプリケーションによって記憶されているメッセージを検索するものである。ステップ1301で、ユーザはIMS1201上のITAPサービスのメインメニューを選択する。これに応答して、IMS1201はProc USSD request invoke（ITAP operation＝Bind invoke）を、下位層のUSSDサービスプロバイダ1355、中間層のITAPサービスプロバイダ1353、及び最上位層のサービスアプリケーション1351を有するSN1357へ発行する（ステップ1303）。USSDサービスプロバイダ1355はProc USSD request invokeを受信し、関連するITAPオペレーション情報をITAPサービスプロバイダ1353へ渡し、今度はITAPサービスプロバイダ1353が関連する情報をサービスアプリケーション1351へ渡す。以下の記述では、サービスアプリケーション1351は、MS120に対して送受されるメッセージの受信側及びソースとして、参照される。しかしながら、これらのメッセージはUSSDサービスプロバイダ1355及びITAPサービスプロバイダ1353両方を通過するということは理解できるであろう。
サービスアプリケーション1351は、ITAPサービスプロバイダ1353及びUSSDサービスプロバイダ1355がUSSD request invoke（ITAP operation＝Bind result）へ変換する応答を渡し、これはIMS1201に返信される（ステップ1305）。このメッセージの受信に応答して、IMS1201はメニューを画面上に表示する（ステップ1307）。メニューは、IMS1201内にキャッシュされているイメージ記述に従って決められる。IMS1201は表示されているメニュー以外のメニュー項目へとスクロールするために、IMS1201上の矢印キーの使用をユーザに許可するようなインテリジェンスを備えている。ユーザがスクロールダウンを続けた場合には、他のメニュー項目がユーザに表示される。
この例では、ユーザは“Messages”のサブメニューを、この選択肢がマークされた時にIMS1201上のYESキーを押すことによって選択する（ステップ1309）。これにより、IMS1201はUSSD request result（ITAP operation＝MailboxStatus invoke）メッセージをサービスアプリケーション1351に送信する（ステップ1311）。
それに応答して、サービスアプリケーション1351は、USSD request invoke（ITAP operation＝MailboxStatus result）メッセージをIMS01201に送信する（ステップ1313）。これにより、IMS1201は新しいメニュー1315を表示する。この例では、このメニューには検索できる３つの音声メッセージと１つのfaxメッセージが表示される。この例では、ユーザは選択肢をスクロールして、“Voice”のサブメニューをYESキーを押すことによって選択する（ステップ1317）。この選択を行うことによって、IMS1201は、USSD request result（ITAP operation＝EnquiryMailbox invoke）メッセージをサービスアプリケーション1351に送信する（ステップ1319）。これに対するSN1357からの応答は、USSD request invoke（ITAP operation＝EnquiryMailbox result）メッセージである（ステップ1321）。このメッセージには、IMS1201に記憶される音声メッセージリストが含まれている。音声メッセージリストには、リスト内にいくつの新しい音声メッセージがあり、いくつの古い音声メッセージがあるかに関する情報が含まれている。IMS1201はこの情報を使って表示をする。この例では、メニュー1323には２つの新しいメッセージと１つの古いメッセージが表示される。
ユーザはこれらの選択肢をスクロールすることができる。この例では、ユーザは、この選択肢にマークが付された時にIMS1201上のYESキーを押すことによって、新しい音声メッセージをリストするよう選択する（ステップ1325）。音声メッセージリストはすでに受信されIMS1201に記憶されているので、ユーザの選択によってIMS1201とサービスノード1357間にはどんな処理も生じない。その代わりに、新しい音声メッセージに関する情報1327がIMS1201の画面上に表示される。ユーザはローカルに新しい音声メッセージのリストをスクロールさせるために矢印キーを使用できる（ステップ1329）。
ユーザは、要求したメッセージに関する情報が表示されているときにIMS1201上のYESキーを押すことによって、音声メッセージの再生を選択する（ステップ1331）。この選択により、IMS1201がSN1357へUSSD request invoke（USSD operation＝PlayMessage invoke）メッセージが送信する（ステップ1333）。SN1357内のサービスアプリケーション1351は、SN1357とIMS1201間に呼を発生させる（ステップ1335）。SN1351もUSSD request invoke（ITAP operation＝PlayMessage result）をIMS1201に送信する（ステップ1337）。
IMS1201内で走っているITAPアプリケーションは、ローカルの“AcceptIncomming Call”と呼ばれるファンクションコールを実行することにより、応答する（ステップ1339）。これにより、IMS1021がSN1357によって設定された呼を受け入れる（ステップ1341）。ユーザは、現在、選択した音声メッセージを聞いている。画面にも、IMSが音声メッセージを再生している旨の情報1343が表示される。
前述の例における一連のイベントは、アプリケーションに依存しており、従って、変化できるのが解る。しかしながら、SN1101におけるサービスの部分とIMS1201における他のサービスの部分とを実装することによって、「速記」のようにSN1101とIMS1201間の通信量を減らすことができ、制限帯域の制御チャネル605をより有効に使用できるということは便利である。実際に、本方法により以下のような効果が達成される。
１.サービスロジックがサービスアプリケーション11017だけでなくIMS1201内にも存在するので、より速い応答時間が達成できる。ローカルなメニュー処理もIMS1201内で行うことができる。ネットワークサービス・アプリケーション1107との通信は、ネットワークサービスのデータをフェッチあるいはストアする場合や、ネットワークサービス機能を呼び出す場合にのみ行われる。
更に、ITAPオペレーションは、SMS（Short Message Services）の７ビットアルファベットよりもコンパクトな、BER（Basic Encoding Rules:基本符号化ルール）やPER（Packed Encoding Rules:圧縮符号化ルール）を用いて符号化することができる。
２.IMS1201内にサービスアプリケーションロジックがあるので、オペレータへの特定のサービスのためによりよいユーザインタフェースを用いることができ、IMS1201における他の全サービスのために、同様のMMI方式を用いることができる。たとえば、IMS1201への特定のサービスのために、同様のMMI方式でメニュー処理を行うことができる。また、IMSがグラフィカルインターフェースを持つ場合に、これを利用することができる。
３.ローカルなIMSサービスアプリケーションロジックを介して、ローカルなIMS機能を呼び出すこともできる。そのようなローカルな機能には、番号を対応する名前に変換したり、呼び出し音をだしたり、自動オフフックを行ったりする機能が含まれる。
４.ITAPのセマンティックは、ネットワークタイマの期限切れを防止する。つまり、ITAPサービスの寿命はネットワークUSSDタイマによって制限されることはない。
５.ITAPオペレーションはいくつかのUSSDオペレーションに分割できる。
６.１つのUSSD対話の実行により、複数のITAPセッションが存在可能である。これにより、一時的なサービスの中断、他のサービスの実行、最初のサービスの再開を行うことができる。
その他のITAPの特徴は、以下の通りである。
a）IMSのローカルなサービスアプリケーションロジック及びMMIは、本稿で「イメージ記述（Image Description）」として参照される「キャッシュ可能な（cacheable）」サービスアプリケーションスクリプトによって制御することができる。これらのイメージ記述は、IMS1201内のMMI及びサービスロジックを定義する。MMIの定義は論理レベルであり、したがって、サービスが実行される場合には、IMS1201の現在のMMI方式が用いられる。
イメージ記述の使用は、ネットワーク内のサービスアプリケーションが更新される場合には、新しいイメージ記述の組がIMS1201にロードされるということを意味している。IMS側のソフトウェアの更新は必要ない。
b）イメージ記述は、望ましくはIMS1201にキャッシュされていた方がよく、IMS1201の電源が切られた場合でも保持されていた方がよい。
c）IMS1201あるいはネットワークサービスアプリケーション1107のいずれかによって、ITAPセッションが開始された場合に、IMS1201とネットワークサービスアプリケーション1107間でネゴシエーションが行われる。このことは、ネットワーク内のサービスが更新された場合に、IMS1201内及びネットワーク内のサービスアプリケーションの一貫性を保証する。イメージ記述がサポートされている場合には、新しいイメージ記述のセットをロードすることができる。
d）IMS1201で着呼が検出された場合に、ITAPセッションを開始することができる。これにより、ネットワークの住所データベースを用いて番号から名前に変換するような、拡張された着呼に対するサービスの実現が可能となる。
e）ITAPオペレーションの開始時に、どのタイプの符号化（PERあるいはBER）を用いているかを表示することができる。
f）ネットワーク内のITAPサービスアプリケーション1107は、常にデータマスタである必要がある。これにより、オペレータが動的にサービスデータを運営することができるようになる。また、通常の卓上電話機やインターネットWWWを用いるＰＣのような、IMS1201と異なる種類の端末からのサービスデータを扱うことができるようになる。
g）ITAPはベアラに対して独立である。たとえば、SMSのような他の利用可能なベアラ上にITAPをマッピングすることができる。更に、ベアラが存在するその他の電話ネットワークにITAPを用いることもできる。ITAPを以下のようなネットワークに使用することができる。
固定電話ネットワーク
アナログ／ディジタル移動体ネットワーク
衛星ネットワーク
h）ITAPがベアラに対して独立であるとしても、USSDのような遅いベアラに対してITAPが最適化される。
i）ベアラが並列の対話をサポートしている場合、真の並列のITAPセッションを実行することができる。
j）ITAPは以下のように実装することができる。
IMSにおける移動装備の一部として実装
SIM（Subscription Identification Module）でアプリケーションツールキットがサーポートされている場合に、SIMにおいて実装
移動局と、USSDと他の移動局の特定の機能及び呼の処理の制御をサポートするコンピュータデバイスとの間にインタフェースが有る場合において、移動局に接続されたＰＣ、ラップトップ、通信機、オーガナイザ、あるいは、全てのコンピュータデバイスに実装
以前に述べたように、本発明の一態様として、本発明が（USSDやSMSのような）遅いベアラに対して最適化できるという事実がある。IMSのユーザが満足する応答時間を得るために、SNとIMS間に送信されるオペレーションの数と大きさが制限される。これは、IMS1201において、できる限り多くのサービスアプリケーションロジックを持つことによって達成できる。これについては、図１４に示す。IMS1401は、３つのレイヤに分割された機能を含んでいる。下から上の順に、ITAPベアラサービスプロバイダ1403、ITAPサービスプロバイダ1405、ITAPの制御下におけるサービスアプリケーションである。
SN1409もやはり、３つのレイヤに分割された機能を含んでいる。下から上の順に、ITAPベアラサービスプロバイダ1411、ITAPサービスプロバイダ1413、１つ以上のサービスアプリケーション1415である。
SN1409及びIMS1401において、サービスアプリケーションプロセス1407及び1415が動作している。それぞれのサービスプロセス1415、1417は、互いに他の装置（IMS1401やSN1409）の状態に独立な自分のステートマシンを持っている。
SN1409及びIMS1401におけるサービスアプリケーションプロセスは、ITAPオペレーションの組を介して通信を行う。Bind1417、Unbind1419及びAlert1421が、基本的なITAPオペレーションに含まれる。更に、ITAPを使用するそれぞれのサービスアプリケーションのために、アプリケーションに依存するオペレーションの組1423がある。それぞれのアプリケーションは、正しいSNサービスアプリケーション機能1415を呼び出す。
複数のITAPセッションは同時に動作できる。しかしながら、複数のセッションが並行に実行できるかどうかは、ベアラの能力に依存している。たとえば、現バージョンのUSSDは並列のUSSD対話をサポートしていないので、新しいITAPのセッションは、一時的に、すでに動作しているセッションを中断させる。
図１５において、ITAPを用いる場合のその他の特徴は、IMS1401の再プログラムを行うことなしにサービスの追加や変更ができることである。これは、ロード可能なITAPイメージ記述1501の方法を用いてIMS1401のサービスアプリケーション1407を制御することによって実現される。これらのイメージ記述1501は、MMI、MMIの状態遷移、呼び出すローカル機能、呼び出すＳＮの機能を定義する。イメージ記述1501を無くしたり、更新されなかった場合には、GetImageDescr 1503と呼ばれるITAPのオペレーションによって、SN1409からフェッチすることができる。
各種のITAPの実施の形態では、イメージ記述1501はサポートされていてもいなくても良い。次の表は、イメージ記述がある場合とない場合における、ITAPのアーキテクチャの比較である。

望ましいITAPオペレーションのセットについて更に詳しく説明する。ITAPオペレーションは、望ましくは、２つの大きなグループに分けられる。
基本的ITAPオペレーション:
これらすべてのオペレーションは基本的、サービス非依存なオペレーションであり、ITAPを使用するすべてのアプリケーションに共通のものである。
アプリケーション依存型ITAPオペレーション:
これらのオペレーションはSN内のサービスアプリケーションをリモートで呼び出すためにIMSによって使用される。
オペレーションの構造は、参考文献として挙げたCCITT勧告X.229及びX.219に関する、Rose（Remote Operation Service Element）標準に準拠する。望ましい基本的ITAPオペレーションについて、更に詳しく説明する。
Bind
BindオペレーションはIMS1401によって起動される。これはROSEクラス１のオペレーションであり、同期型のオペレーションで、成功（result）あるいは失敗（error）を報告する。Bindは次のいずれかの場合に用いられる。（1）ITAPサービスアプリケーションを開始する場合。（2）ITAPセッションを開始する場合。これらの各場合は以下で詳しく解説される。
Unbind
UnbindオペレーションはIMS1401によって起動される。これはROSEクラス５のオペレーションであり、このオペレーションの結果は報告されない。Unbindの目的はITAPセッションを終了させることである。
GetImage Descr
GetImage DescrオペレーションはIMS1401によって起動される。これはROSEクラス１のオペレーションであり、同期型のオペレーションで、成功（result）あるいは失敗（error）を報告する。GetImage DescrオペレーションはSN1409からイメージ記述を要求する。このオペレーションは、イメージや、対応するイメージがキャッシュに存在しない場合にIMS1401によって起動される。このオペレーションはIMS1401及びSＮ1409がイメージ記述をサポートしている場合に限り、使用される。
Alert
AlertオペレーションはSN1409によって起動される。これはROSEクラス３のオペレーションであり、失敗（error）のみを報告する。Alertオペレーションの目的は、新しいメッセージの通知などのイベントの存在をIMS1401に警告することである。このオペレーションはITAPのレベルに責を持つが、IMS1401はBind、GetImageDescr、Unbindあるいはその他のアプリケーション依存のITAPオペレーションを起動することによってダイアログを継続する。Bindオペレーションは、IMS01401がAlertオペレーションに指定されていないものと異なるアプリケーションのバージョンを持っている場合に起動される。
アプリケーション依存型ITAPオペレーションに関しては、これらはすべてROSEクラス１のオペレーションであり、同期型のオペレーションで、成功（result）あるいは失敗（error）を報告する必要がある。これらのオペレーションは、サービスアプリケーションの機能がSN1409において実行することを、IMS1401が要求した場合に用いられる。要求された機能からの応答は起動したオペレーションからの結果として受信される。ITAPを使用しなければならない各サービスアプリケーション1415のために、アプリケーション依存型ITAPオペレーションが明示されなくてはならない。どのようにこれらのオペレーションを明示するかについては制限がある。これらの制限は以下に説明される。
イメージ記述がサポートされている場合には、各アプリケーション依存型オペレーション用の、起動及び結果の議論はイメージ記述で明示される。
ITAPサービスアプリケーションの開始
加入者が特定のITAPサービスアプリケーションのサービスにアクセスできるようになる前に、ITAPアプリケーションがIMS1409で開始されなくてはならない。この手続きは以下の通りである。
１.ユーザはIMS1401上で起動するサービスのメニューに入る。その後、このアプリケーションのサービスコードがユーザによって入力される。
２.Bindオペレーション1417がMS1401からSN1409に送信される。このオペレーションにおいて、“Bind reason”は”init subscription”にセットされる。
３.SN1409は、アプリケーションの名前及びBindが到来した呼に対して起動された／呼が指示を待っているかどうかに関係する情報を含んだ”Bind result”を返す。
４.IMS1401はアプリケーションのパラメータを記録する。好ましくは、このサービスアプリケーション用のメインメニューのためにIMS MMIに用いられるべきである。
５.IMSはITAPセッションを終了する。
ITAPセッションの開始
ITAPセッションは、
IMS1401によって起動されたBindオペレーション1417
IMS1401によって起動されたAlertオペレーション1421
によって開始する。
ITAPセッションを起動するイベントは、
ユーザがITAPサービスアプリケーションをIMS1401で起動し、Bindが送られる場合。
SN1409のイベントで、Alertが送られる場合。
である。
Bindの理由をSN1409に知らせる必要があるので、このオペレーションは”Bind reason”のパラメータを含む。“Bind reason”は以下の値をとる。
ユーザによる開始
呼に関連する指示、つまり、到来した呼及び待ち状態の呼。
不正なアプリケーションバージョン。これは、SN1409が、Alertを用いてセッションを開始した場合や、アプリケーションバージョンがSN1409のバージョンと異なることを検出した場合に用いられる。
「ITAPサービスアプリケーションの開始」で記述されている“subscription”の起動。
SN1409がBindオペレーションを受信した場合には、IMS1401のアプリケーションバージョンとSN1409のアプリケーションバージョンが比較される。SN1409が、現在IMS1401がサポートしているアプリケーションバージョンと異なるアプリケーションバージョンを持つ場合にはいかのようになる。
イメージ記述がサポートされていない場合には、SN1409はIMS1401がサポートするようなアプリケーションバージョンに変更する。SN1409がそのようなアプリケーションをサポートしていない場合には、Bindエラーが返され、ITAPセッションは終了する。
イメージ記述がサポートされている場合には、Bindの応答にはキャッシュを消去するためのイメージ記述が含まれる。また、Bind resultオペレーションには、この加入者が利用できるサブサービスを指定するパラメータが含まれる。IMS1401は今パラメータをチェックし、メニューが表示される。
サービスが契約に入っていないサービスのオプションがメニューに含まれる場合には、このオプションは表示されない。これにより、オペレータはサービスアプリケーションを多数のサブサービスに分割することができるようになる。加入者は、どのサブサービスを使用したいかを決めることができる。
ITAPセッションの終了
通常、ITAPオペレーションは、IMS1401によって起動されたUnbindオペレーションによって終了する。しかしながら、エラーが発生した場合には、IMS1401及びSN1409の両方のベアラレベルにおける中止によって中止することができる。
ITAPタイムアウト処理
タイムアウトはSN1409、IMS1401の両方で処理される。SN1409のタイムアウト処理については、SN1409内の「アイドル状態の」タイマによって処理される。このタイマは、オペレーション（AlertあるいはROSEクラス１オペレーションResult、errorあるいはreject）がIMS1401に送信された場合に、いつも起動される。SNにおける「アイドル状態の」タイマの初期値は定数である。
タイムアウトは、ある期間内にIMS1401によって新しいオペレーション（Bind、GetImageDescr、Unbind、アプリケーション依存型ITAPオペレーション）が起動されない場合に検出される。タイムアウトが検出された場合には、SN1409はITAPセッションをローカルに中止し、ベアラがダイアログの構造を持っている場合にはベアラレベルでダイアログを中止する。
IMS1401におけるタイムアウト処理において、IMS1401は、IMS1401によって起動されるROSEクラス１のオペレーション（Bind、GetImageDescr、Unbind、アプリケーション依存型ITAPオペレーション）の応答を監視するタイマを持つ必要がある。タイマ値は送信されたオペレーションそれぞれに固有である必要がある。アプリケーション依存型ITAPオペレーションでは、タイマ値は起動したオペレーションに依存する。イメージ記述がサポートされている場合には、アプリケーション依存型ITAPオペレーション用のタイマ値は、イメージ記述によって設定される。
ある期間内にSN1409からの応答（Result、ErrorあるいはReject）がない場合に、タイムアウトが検出される。タイムアウトが検出された場合、IMS1401はITAPセッションをローカルに中止し、ベアらがダイアログの構造を持っている場合にはベアラレベルでダイアログを中止する。
更にIMS1401は、ある期間内にユーザが動作を行ったかどうかを監視する「アイドル状態の」タイマを装備する必要がある。このタイマは、SN1409からオペレーション（AlertあるいはROSEクラス１オペレーションResult、errorあるいはreject）を受信した場合に、いつも起動される。「アイドル状態の」タイマの初期値は、Alertが受信された場合を除いて、定数である。この場合には、タイマの値はAlertオペレーション内のパラメータによって設定される。
ITAPエラー処理
ITAPレベルのエラー処理はROSEに基づいて行われる。ベアラレベルでエラーあるいはタイムアウトが発生した場合には、このベアラダイアログによって実行されるすべてのITAPセッションは中止される。
ITAPオペレーションの符号化
オペレーションはBER（Basic Encoding rules）あるいはPER（Packed Encoding Rules）にしたがって符号化される。しかしながら、PER符号化標準はより短いオペレーション及びIMSユーザによりよいパフォーマンスを提供するので、PERが望ましい。
ITAPオペレーションの最大サイズ
好適な実施の形態においては、ITAPオペレーションの最大サイズは1024オクテットに制限されている必要がある。この制限は同時にITAPイメージ記述の最大サイズを定義する。ROSSヘッダを伴ったITAPイメージ記述のサイズは、1024オクテットｈを越えてはならない。
次に、ITAPイメージ記述について述べる。ITAPイメージ記述は以下の項目を定義するリソースである。
サービスが実行されたときのIMS1401におけるMMI。イメージ記述においては、MMI定義はより高い論理レベルで行われる。実際のイメージフォーマット及び表示はIMS1401によって決定される。
サービスが実行された場合に、IMS1401及びSN1409における機能の呼び出し。
イメージ記述は以下のリストからのオブジェクトを設定する。
ローカルのIMSファンクションコール、アプリケーション依存型ITAPオペレーション（「SNファンクションコール」）の刷新、コンディショナルステートメント、及びラベルステートメントからなる動作項目のリスト。
固定テキスト
IMS標準キーに関する動作
各メニューオプション用の動作のメニュー
動的データのリスト
入出力フィールドの異なる型
動的データの一時記憶領域用の端末レジスタ群
メニューオプション用の典型的なイメージ記述1601を図１６に示す。イメージ記述1601から、IMS機能1603及びSN機能1605を呼び出すことが可能である。機能が呼び出された場合には、入力及び出力のパラメータは一時レジスタに保存される。これらのレジスタは、入出力フィールド、リストなどに関連する。リモートのSNの機能は、現在のアプリケーションで利用可能な、アプリケーション依存型ITAPオペレーション1605のセットを介して、呼び出される。
ローカルのIMS機能では、ITAPはIMSでサポートされる機能のセットを指定する。IMSの機能は次のグループに分けられる。
イメージ記述、レジスタ及びパラメータリストのようなイメージ記述オブジェクトを操作する機能。
”Accept incoming call”や”Setup call”のような呼に関連する機能。
DTMF信号を処理するための機能
電話帳など、ローカルのIMSソフトウェアオブジェクトにアクセスするための機能
トーンジェネレータのようなローカルのIMSハードウェアオブジェクトにアクセスするための機能
SMSを処理するための機能
入出力パラメータを伴ったIMS機能のリストについては後で説明する。
ITAPをサポートするために、SN1409及びIMS1401両方とも、以下のような多くの要求条件を満足する必要がある。
SN1409に関する要求条件
SN1409はITAP用に選択されたベアラプロトコルをサポートしなくてはならない。
SN1409はITAPの基本的オペレーションをサポートする必要があり、PERあるいはBERに関するITAPデータ型を符号化／復号化できなくてはならない。
SN1409は実装されたそれぞれのアプリケーションについて、アプリケーション依存型ITAPオペレーションをサポートしなくてはならない。
SN1409はそれぞれの加入者に対して、正しいテキスト文字列をオペレーションにおいて生成するために、選択された言語を記憶していなくてはならない。
更に、イメージ記述をサポートする場合には、以下の要SNの求条件を満た必要がある。
SN1409はイメージ記述を記憶しておけなくてはならず、IMS1401の要求に対して、これらをIMS1401にロードできなくてはならない。
SN1409は、新しいバージョンのITAPアプリケーションが導入された場合に、IMS1401においてどのイメージ記述が記録されるべきかを保持しておく必要がある。
IMS1401に関する要求条件
IMS1401はITAP用に選択されたベアラプロトコルをサポートしなくてはならない。
IMS1401はITAPの基本的オペレーションをサポートする必要があり、PERあるいはBERに関するITAPデータ型を符号化／復号化できなくてはならない。
IMS1401は実装されたそれぞれのアプリケーションについて、アプリケーション依存型ITAPオペレーションをサポートしなくてはならない。
IMS1401は、オペレーション通常モードから離れ、ユーザのアプリケーションが主にITAPアプリケーション部によって制御されるようなオペレーションと伝送モードに移行できなくてはならない。ITAPモードは、ユーザのコマンド、呼による指示、受信したITAP Alertによって起動される。
呼制御用の基本的IMS機能のセット、MMI制御、SMS制御などがIMS1401のITAP部からアクセスできなくてはならない。
ITAPソフトウェアは、電話帳のような既存のIMSソフトウェアオブジェクトを使用できなくてはならない。
更に、イメージ記述をサポートする場合には以下のIMS要求条件を満足する必がある。
イメージ記述及び一時データの動的記憶用のメモリがIMS1401内で使用できなくてはならない、イメージ記述は、電源が切られた場合でも、メモリ内に留まっていなくてはならない。イメージ記述を記憶しておくためのメモリサイズは、サービスに用いられるイメージの数及びサービスの複雑さに依存する。ほとんどの場合においては、イメージ記述のサイズは200バイト未満であることが予想できる。したがって、60のイメージ記述を必要とする複雑なITAPアプリケーションの場合には、イメージ記述のために、IMS1401内に12Kバイトが割り当てられている必要がある。
IMS1401はイメージ記述を中断したり、ITAPアプリケーションやアプリケーション依存型ITAPオペレーションのセットを、イメージ記述を介して制御したりできなくてはならない。
システムオペレータによる管理もITAPをサポートしていなくてはならない。ITAPの概念における特徴の一つは、イメージ記述の動的なロードが可能な点である。オペレータがサービスを更新するシナリオは以下の通りである。
1.SN1409に新しいサービスアプリケーションがインストールされる。
2.SN1409においてバーションが更新されてから最初の接続が確立した場合、SN1409はIMS1401が古いバージョンを持っていることを検出する。
3.SN1409はIMS1401にイメージ記述キャッシュあるいはキャッシュの一部を消去するように命令する。
4.サービスが実行されるとき、IMS1401は、サービス実行の際に必要となる、不足しているイメージ記述を要求するために、”GetImageDescr”オペレーションを用いる。
イメージ記述がサポートされる場合には、ITAPの概念は以下のよう救助宇検をオペレータに要求する。
SNサービスアプリケーションロジックの修正及びイメージ記述の更新を調整しなくてはならない。
イメージ記述の作成、管理のためのツールを作成しなくてはならない。
図１７及び１８を用いて、GSMフェーズ２に関連するUSSDオペレーションにおける”USSD string”パラメータへのITAPオペレーションのマッピング方法について解説する。図１７はUSSDダイアログを開始するUSSDオペレーションに用いるマッピングを示している。図１８はその他のすべてオペレーションへのマッピングを示している。それぞれの文字列はUSSD固有のヘッダ1701、1801、及びベアラ非依存部1703を持っている。以下の文はUSSD文字列のそれぞれのフィールドについて説明するものである。
ITAP Service Code 1705
このフィールドはUSSDダイアログを開始するオペレーションにのみ必要となる。このフィールドの目的は以下の通りである。
USSDダイアログを開始するためのルーティング情報。加入者のHPLMNのHLRにルーティングすべきUSSDオペレーションを、サービスを行っているネットワークに通知する。GSM 02.90、セクション4.1.2、ケースa）の仕様は、USSDオペレーションがHPLMNのHLRにルーティングされる場合に、USSDを開始するMS用の要求フォーマットについて述べている。
サービスコードもまた、正しい外部ノード（SN）にUSSDオペレーションがルーティングされるべきであることをHLRに通知する。
USSDを開始するネットワーク用のプロトコル識別子。これは、IMS1401に、受信したUSSDオペレーション中に標準USSD文字列の代わりにITAPオペレーションが含まれていることを示す。
アプリケーション識別。開始したITAPを用いるアプリケーションの識別子を特定する。
ITAP Version Number 1707
ITAPのバージョン番号を指定するこのフィールドは、USSDオペレーション開始時のみに存在する。
Coding 1709（USSD開始時のみ）
USSDオペレーションの開始時のみに存在するこのフィールドでは、ITAPオペレーションを符号化する際に用いる符号化方法を指定する。典型的な符号化は以下の通りである。
0=Basic Encoding Rules
1=Packed Encoding Rules、basic aligned
2=Packed Encoding Rules、basic unaligned
3=Packed Encoding Rules、canonical aligned
4=Packed Encoding Rules、canonical unaligned
Session Id 1711（すべてのオペレーション）
ITAPセッションの識別を指定するこのフィールドは、すべてのオペレーションにおいて存在する。
Seg Flag 1713（すべてのオペレーション）
セグメンテーション情報を指定するこのフィールドは、すべてのオペレーションにおいて存在する。これは、１つのUSSDオペレーションのUSSD文字列に入りきらないようなITAPのオペレーションに対して用いられる。フラグの値は以下の通りである。
0=”no more infb”。このUSSDオペレーションでITAPオペレーションが完了する、あるいはこのUSSDオペレーションが現在送信されているITAPオペレーションの最後の部分であることを示す。
1=”more to come”。このUSSDオペレーションでITAPオペレーションが完了しない、あるいはこれは現在送信されているITAPオペレーションの最後の部分ではないことを示す。
2=”get more info”。実体（IMS1401あるいはSN1409）が”more to come”に設定されたseg flag 1713を持つUSSDオペレーションを受信した場合には、”get more info”に設定されたseg flag 1713を持つUSSDオペレーションを返信する。この場合、”ITAP operation”のフィールド1719及び1819は空であり、USSD文字列内にUSSDに特定のヘッダ1701及び1801のみが含まれる。
可能なセグメンテーションが行われる前に、ITAPオペレーションのPERあるいはBER符号化が行われていることが望ましい。受信したITAPオペレーションの復号化は、オペレーションが完全に受信されるまでは行うべきでない。
セグメンテーションについて記述したオペレーションシナリオのダイアグラムは後述する。
USSD dialogue flag 1715（すべてのオペレーション）
このフラグの目的はネットワークにおけるUSSDタイムアウトの問題を解決することである。フラグが0にセットされている場合には、USSD文字列には通常のITAPオペレーションが含まれる。その他すべての場合には、”ITAP operation”のフィールド1719、1819は空である。
ネットワークのUSSD Request invokeタイマが期限切れになることを防止するために送信されるダミーのUSSDオペレーションに、１及び２の値が用いられる。それぞれの時間制御はIMS1401に戻される。すなわち、USSD Request invokeによって運ばれるITAP resultあるいはITAP Alert invokeが受信され、IMS1401内のタイマが始動する。IMSタイマの値は、ネットワーク内のUSSD Request invokeタイマの値よりも小さくなくてはならない。USSD Request resultによって運ばれるITAPオペレーションが送信された場合には、IMSタイマはキャンセルされる。IMSタイマが期限切れになった場合には、USSD Request resultによって運ばれる”dummy request”（USSD dialogue flag=1）が送信される。SN1409はUSSD Request invokeによって運ばれる”dummy confbrm”（USSD dialogue flag=2）により返信する。
３−５の値は、IMSがUSSDダイアログを開始する場合に、ネットワーク内のPrcess USSDRequestが期限切れになるのを回避するために用いられる。これらのUSSDオペレーションは、IMSによって開始されたダイアログを終了させて新しくネットワークによって開始されるUSSDダイアログを開始するために用いられる。新しいUSSDダイアログによって運ばれた現在進行中のITAPセッションは継続される。この流れを以下に示す。
IMS1401がProcessUSSDRequest invokeによってUSSDダイアログを開始するときはいつも、IMS1401はタイマをスタートさせる。このIMS1401のタイマの値は、ネットワーク内のProcessUSSDRequest invokeタイマの値よりも小さい必要がある。IMS1401によってのみ“switch USSD dialogue”が初期化されるので、このIMSタイマが設定された場合には、SN内に存在可能な最大時間制御を考慮しなくてはならない。IMSタイマが時間切れになった場合には、USSDRequest resultによって運ばれる“switch USSD dialogue request”（USSD dialogue flag=3）が送信される。SN1409は、TCAP-END内のProcessUSSDRequest resultによって運ばれる“switch USSD dialogue confirm”（USSD dialogue flag=4）を返す。この移動局で開始されたUSSDダイアログは終了し、ネットワークによって開始される新しいUSSDダイアログがSN1409によって設定される。USSDRequest invokeは“ITAP session”コマンド（USSD dialogue=5）を含んでいる。
いま、この新しくネットワークによって開始されたUSSDダイアログによって運ばれたITAPセッションは継続する。
ネットワーク内のUSSDタイムアウトを回避する処理のための、ITAPオペレーションのシナリオを以下に示す。
“resume ITAP session”であるUSSD dialouge flag 1715の値５も、同じダイアログ上に、以前に中止されたITAPセッションを再開するために用いられる。このシナリオの例を以下に示す。
USSD specific tail 1717
USSDオペレーションの開始時のみに含まれる、このspecific tail 1717はGSM 02.90、セクション4.1.2、ケースａに関連して追加された。“#”の文字はSMS標準アルファベットで７ビットを必要とする。８ビット目は０にセットされる。
さて、ベアラ非依存部分に戻って、USSD文字列は以下のものを含む。
ITAP Operation 1719、1819
このフィールドは、seg flag=“get more info”の場合とUSSD dialogue flag<>“normal ITAP operation”の場合をのぞいた、すべてのオペレーションで用いられる。ITAPオペレーションはCCITT勧告X。229及びX。219のROSEの構造に従い、PERあるいはBERの規範に従って符号化される。USSD文字列の最大長はＧＳＭの仕様で明確に定義されないので、ITAPオペレーションの最大長はどちらかというと不明確な段階にある。
_USSD Request invokeあるいはProcess USSD request invoke用
GSM 09。02は160オクテットの最大長を明記している。しかしながらTCAPレイヤにも制限がある。USSDの各エキスパートたちは、USSD文字列の長さにこれらの制限がどのような影響を与えるかについて、それぞれ異なる情報を与えられてきた。１００から１５０の間という数字がいわれてきた。更に、USSD文字列が128オクテットを越えると、応答時間が増加するA-インターフェースに分割されるともいわれてきた。
_USSD Request resultあるいはProcess USSD Request result用
GSM 02。90では、resultのUSSD文字列は、７ビット標準アルファベットで符号化された文字で８０文字が最大の制限であるを明記している。このことは７０オクテットが最大であることを意味している。しかしながら、SMGでGSM 02。90におけるこの制限を取り除くよう提案された。
USSD文字列の最大長は非常に不明確かつ提案の問題であるので、SN1409及び、可能で有ればIMS1401における環境設定パラメータとしての異なるUSSDオペレーション用のUSSD文字列最大長を決めておくことが望ましい。
以下の表はITAPオペレーションをどのようにしてUSSDオペレーションにマッピングするかを示している。

DCS（Data Coding Scheme）は、言語、アルファベット、及びメッセージクラスの情報を含んだUSSDオペレーション内のパラメータである。GSM 02。90はどのようにアルファベット指定及び言語指定がセットされるべきかを定義している。
_移動局によってUSSDオペレーションが開始される場合
アルファベット指定子=”SMS default alphabet”、言語指定子=”Language unspecified”。応答については特に指定されない。
_ネットワークによってUSSDオペレーションが開始される場合
要求は特に指定されないが、DCS応答は”SMS default aphabet”及び”Language unspecified”にセットされなくてはならない。
GSM 02.90によれば、IMS1401から送信されたオペレーションはアルファベット指定子=“SMS default alphabet”及び言語指定子=”Language unspecified”を保持していなくてはならないように見える。GSM 02.90によれば、SN1409から送信されたオペレーションはこれらの指定子以外の値をとることができる。しかしながら、現段階ではCME20、R6.1（現在の発明の譲受人であるTelefonakttiebolaget LM Ericssonにより供給された装置）におけるHLR及びMSC/VRが”SMS default alphabe”以外のアルファベット指定子を受け付けるかどうか、定かではない。
結論として、CME20の制約により、主な選択肢は、すべてのオペレーションにおいてアルファベット指定子を”SMS default alphabet”にし、言語指定子を”Language unspecified”にすることである。GSM 03.38によれば、このことはDCSが２進値”00001111”を持たなくてはならないことを意味する。
以下の節ではUSSDオペレーション及びアイドル状態のタイマ二関連する問題及び解決策について解説する。
一般
SN1409とIMS1401間における通信用のITAPを用いるサービスが実行された場合には、サービス実行中にはITAPセッションを能動状態にしておく必要がある。
ネットワークノード、HLR及びMSC内には、USSDオペレーションがある時間内に応答しなかった場合やUSSDダイアログがある時間使用されなかった場合にUSSDダイアログを終了させるタイマがある。タイマの値は30秒から10分の範囲である。この結果、ITAPを用いるサービスの長さが制限されることになる。より進んだサービスのためにITAPセッションを長時間継続させることが望ましいので、これは問題である。これは、ユーザがITAPセッションを10分以上継続させる場合も同様である。
ProcessUSSDRequestタイマに関する問題
記述:このタイマの値は１分から10分であり、SN1409内でProcessUSSDRequest invokeが受信された場合に、このタイマはスタートする。
ITAP、における結果:このタイマは、移動曲で開始されるUSSDダイアログの全体の長さ、IMS1401のユーザによって開始されるすべてのITAPセッションの長さを制限する。
解決策:IMS1401は、IMSによって開始されたITAPセッションがProcessUSSDRequest invokeにマッピングされた”Bind invoke”を用いて開始される場合にスタートするタイマを保有している。このタイマの値は、ネットワーク内のProcessUSSDRequest invokeのタイムアウト値よりも小さくなくてはならない。IMSタイマが期限切れになった場合にはネットワークによって開始されるUSSDダイアログへのスイッチが行われる。ITAPセッションは継続し、新しいUSSDダイアログ上にマッピングされる。
USSDRequestタイマに関する問題
記述:このタイマは1分から10分の値をとり、USSDRequest invokeが送信された場合にスタートする。このタイマはIMS1401からUSSDRequest resultが返信されるまで動作する。
ITAPにおける結果:kのタイマは、MS1401におけるITAPのアイドル状態の時間を制限する。つまり、次のITAPオペレーションが送信されるまで、この時間はIMS1401が待つことができる。
解決策:IMS1401がある時間内（USSDRequest invokeタイマの値よりもわずかに短い時間内）にITAPオペレーションを返信しない場合には、ダミーのUSSDRequest invokeが送信される。SN1409はダミーのUSSDRequest invokeを用いて応答する。
HLR内のUSSD Idleタイマにおける問題
記述:このHLRタイマは30秒から5分の値をとり、USSDオペレーションの開始の開始間隔を監視する。このタイマはUSSDRequest resultga SN1409、に送信された場合にスタートし、次のUSSDRequest invokeがSN1409から受信されるまでの間、あるいはUSSDダイアログが終了するまでの間動作する。
ITAPにおける結果:このタイマはITAPオペレーションの開始が、応答の返信前にSN1409内にとどまっていられる時間を制限する。
解決策:SN1409は、USSD Idleタイマが期限切れになる前にいつも、開始されたITAPオペレーションい応答しなくてはならない。
ベアラとしてUSSDを用いることは、ITAP機能に制限が生じることを暗示している。以下の制限は、GSMフェーズ２仕様において正当なものである。
IMS1401を用いた複数のITAPダイアログは不可能であるので、ひとつのITAPセッションしか同時に能動状態になれない。すでに能動状態にあるセッションがあるときに新しいITAPセッションが開始された場合には、最初のセッションは一時的に中断される。２番目のITAPセッションが終了したときには、最初のセッションが再開される。
現在進行中のITAPセッションがあるときに新しいITAPセッションが開始された場合には、新しいセッションは、Bindオペレーションを用いてIMS1401によって開始されるのみである。この場合、Alertを用いたSN1409からの新しいセッションが開始されることは不可能である。この理由は、現在進行中のITAPオペレーションはAlert以外でIMS1401によって開始されていあるからであり、SN1409はresultを用いて返信する。SN1409からのResultオペレーションは”invoke（USSD request）”にマッピングされている。Alertが送信された場合には、並行して”invoke（USSD requesst）”が送信されなくてはならない。しかしながら、複数の開始はUSSDにおいては認められていない。
ITAPセッションがAlertを用いてSN1409によって開始され、ある時間内にIMS1401から返信がない場合には、開始されたセッションはSN1409において中止される。しかしながら、IMS1401及びネットワーク内のUSSDダイアログを中止することはできない。なぜなら、これはこのダイアログにおける最初のUSSDダイアログだからである。SN1409におけるアプリケーションタイムアウトがMS/VLR USSDタイムアウトよりも短い場合には、IMS1401方向のUSSDチャネルはMSC/VLRタイムアウトの時間切れまでにブロックされる（なぜなら、MSC/VRは１つのタイマ当たり１つのUSSDダイアログしか認めていないからである）。
なお、タイムアウトが”no input from user”によって起こった場合には、前述され、また以下に図示されるMS1401内のアイドル状態のタイマを用いることによってこの問題を解決することができる。
図１９〜５１は、USSD（GSMフェーズ２に関連）をベアラとして使用する場合の各シナリオを図示している。
図１９は、ITAPセッションが現在進行中でない場合のBindオペレーションを図示している。この図においては、IMS1401はIMSのアプリケーションのバージョンが更新されている（すなわち、端末のバージョンレベルがサービスノードのバージョンレベルと一致する）状態で、ITAPセッションを開始する。
図２０は、現在進行中のITAPセッションがない場合の、ほかのBindオペレーションを図示している。しかしながら、この図では、IMS1401はIMSアプリケーションのバージョンアップが必要なITAPセッションを開始する。また、イメージ記述がサポートされているとする。時刻=2においてSN1401が新しいアプリケーションバージョン、MS1401内のキャッシュを消去するための命令、及び消去するイメージのリストを含むResultを返信していることがわかる。
図２１は、現在進行中のITAPセッションがないときに、呼に関連した指示2101の手段を用いてMS1401がITAPセッションを開始するシナリオが図示されている。
図２２は、IMS1401がBindオペレーションを用いてITAPセッションを開始し、そのなかでSNがBindオペレーションのerrorあるいはrejectを検出するようなITAPのシナリオを図示している。なお、時刻＝３で、IMS1401が”Continue、Result（USSD req）”を用いてBindオペレーションを再試行することも可能である。
図２３は、現在進行中のIMSセッションがある場合に、IMS1401がITAPセッションを開始するようなITAPのシナリオを図示している。新しいセッションを引き起こすイベント（たとえば、呼の指示など）が検出され、現在進行中のセッションが未処理のInvokeオペレーションを保持している場合には、オペレーションのresultは、開始できる新しいセッション用のBindの前に受信されなければならない。
図２４は、現在進行中のITAPセッションがあり、そのなかでSN1409がBindオペレーションのerrorあるいはrejectを検出した場合に、IMS1401がITAPセッションを開始するようなITAPのシナリオを図示している。なお、時刻=4において、IMS1401がセッション２用のBindオペレーションを再試行することも可能である。
図２５は、ある時刻にIMS1401がアプリケーションデータをまったく利用できない場合におけるITAPサービスの起動を図示している。なお、IMS1401はbind resultを受信し（ステップ2051）アプリケーションパラメータはIMS1401内に記録される。ITAPセッションは常にITAPオペレーションが開始した後で終了される。
図２６及び図２７は、アプリケーション非依存型ITAPオペレーションを図示している。図２６においては、連続した応答がSN1409から受信される（ステップ2601）。図２７では、SN1409はオペレーションのErrorあるいはReject2701を検出する。
図２８及び図２９はGetImageDescrオペレーションを図示している。図２８では、連続した応答がSN1409により生成される（ステップ2801）。図２９では、SN1409がオペレーションのerrorあるいはrejectを検出する（ステップ2901）。
図３０、図３１及び図３２は、Unbindオペレーションに関する複数のITAPのシナリオを図示している。図３０ではセッションが１つだけ進行しており、連続した応答がSN1409ｍにより生成される。なお、USSDダイアログがSN1409によって開始された場合には、時刻３においてUSSDダイアログは空のTCAP-Endにより閉じられる。USSDダイアログがIMS1401によって開始される場合には、USSDダイアログはResult（Process USSD Req）により閉じられる。
図３１においては、以前に中断されたセッションが再開され、連続した応答がSN1409によって生成される（ステップ3101）。
図３２は、1つ以上のいくつかのセッションが進行しており、SN1409がunbindを拒否する（ステップ3201）ようなシナリオが図示されている。なお、この場合にはすべてのITAPセッションは中止される。これは、ITAPレベルでセッションを中止する試みが失敗し、デッドロック状態を回避しなくてはならないという理由で、必要である。
図３３〜３９は、Alertオペレーションに関するさまざまなシナリオを図示している。図３３は、SN1409がIMS1401にイベントの通知を行い（ステップ3301）、IMSアプリケーションバージョンが更新される場合を示している。
図３４では、SN1409が、IMS1401にIMSアプリケーションバージョンがSN1409のものと異なる場合に、イベントの通知を行う。図示されたシナリオはイメージ記述がサポートされている場合のものである。
図３５は、SN1409が、IMS1401にIMSアプリケーションバージョンがSN1409のものと異なる場合に、イベントの通知を行うようなシナリオである。この場合には、IMS1401はイメージ記述をサポートしておらず、SN1409は下位互換の状態である。
図３６は、Sn1409がIMS1401にイベントの通知を行う（ステップ3601）シナリオを示している。この場合には、IMS1401は古いバージョンのITAPをサポートしており、SN1409は下位互換の状態である。
図３７では、SN1409はIMS1401にイベントの通知を行う（ステップ3701）。ここでは、IMS1401は古いバージョンのITAPをサポートしているが、SN1409は下位互換の状態ではない。結果として、SN1409はUSSDダイアログを閉じる（ステップ3703）。
図３８では、SN1409はAlertオペレーションを生成するが（ステップ3801）、IMS1401はAlertオペレーションのerrorあるいはrejectを検出する。
図３９では、SN1409はAlertにしたがうBindオペレーションのerrorあるいはrejectを検出する（ステップ3901）。
図４０は、IMS1401がSN1409からの応答を拒否するようなITAPのシナリオを示している。すなわち、ステップ4001で、SN1409はResult、ErrorあるいはRejectをIMS1401に送信する。ステップ4003では、IMS1401はSN1409からの応答を適切に中断できず、したがって、ステップ4005において、IMS1401はSN1409にUnbindオペレーションを送信する。なお、CCITT勧告X.219のセクション10.4によれば、ROSEユーザがReject APDUを送信することによって返信（ResultあるいはError Application Protocol Data Unit（APDU））の拒否を実装するかどうかはオプションである。図示されているITAPの実施の形態では、IMS1401のために、SN1409から間違ったResultあるいはError APDUの場合にReject APDUを送信することがないように設定されている。この場合には、代わりにITAPセッションはUnbindによって終了される。
どのようにITAPがUSSD文字列にマッピングされるかは、図１７及び１８を用いて前述した。図４１〜４３に示される以下のシナリオでは、USSD specific header1701、1801内のSegmentation flag1713が分割情報のために用いられる。PERあるいはBERにより符号化されたITAPオペレーションがUSSDオペレーションのUSSD文字列に入らない場合には、それは２つ以上のUSSDオペレーションに分割される。IMS1401あるいはSN1409が“more to come”にセットされたsegmentation flagを伴ったオペレーションを受信した場合には、segmentation flagが“get more info”にセットされたヘッダをつけたUSSDオペレーションは他の実体に送信されなくてはならない。完全なITAPオペレーションが受信された場合には、それは受信実体によって復号されなくてはならない。
図４１では、IMSにより開始されたオペレーションがUSSDオペレーションに入りきらない場合が示されている。解決策はITAPオペレーションを２つのUSSDオペレーション4301、4303に分割することである。
ITAPレベルのタイムアウト処理が図４４から図４９により議論される。図４４はIMS1401がオペレーションの開始の前にタイムアウトを検出した場合の（ステップ4401）シナリオが示されている。これにより、すべてのITAPセッションは中止され、EndオペレーションがSN1409に送信される（ステップ4403）。
図４５は、IMS1401が、USSDダイアログ用の最初のオペレーションとしてBindを開始した後でタイムアウトを検出するシナリオが図示されている。IMS1401はローカルでITAPセッション及びUSSDダイアログを中止することにより応答する（ステップ4503）。
図４６では、IMS1401は「アイドル状態」タイムアウトを検出、すなわち、ユーザからなにも応答がなかった場合である（ステップ4601）。IMS1401はUnbindオペレーションの開始を生成する事によって応答する（ステップ4603）。結果として、Unbindのシナリオは継続し（ステップ4605）、したがって、USSDダイアログが終了するか、以前に中止されたセッションが再開される。
図４７は、Alertが受信された後で、IMS1401が「アイドル状態」タイムアウトを検出、すなわち、ユーザがなにも応答しなかった場合のシナリオを示している（ステップ4701）。これに対して、IMS1401は、Unbindオペレーションの開始を含め（ステップ4705）、ITAPセッションを終了する（ステップ4703）。
図４８では、「アイドル状態」タイムアウトを検出するのはSN1409である（ステップ4801）。これに対し、AbortオペレーションをIMS1401に送信することを含め、すべてのITAPセッションを中止する（4803）。
図４９は、SN1409がAlertを送信し（ステップ4901）、その結果「アイドル状態」タイムアウトを検出するような（ステップ4903）シナリオを図示している。これに対し、SN1409はローカルでITAPセッション及びUSSDダイアログの中止を行う。
図５０及び図５１は、ネットワーク内でUSSDタイムアウトの発生を回避するために行われる処理に関するシナリオを示している。図５０では、ダミーのUSSDオペレーション（ステップ5001）が、USSDRequestタイムアウトを回避するために実行される。図５１では、ProcessUSSDRequestタイムアウトを回避するために、IMSで開始されたUSSDダイアログからネットワークで開始されたUSSDダイアログへの切り替えを引き起こす（ステップ5103及び5105）IMS1401内のタイマ期限切れ（ステップ51501）を示している。切り替えは移動局で開始されたUSSDダイア路津を終了させ、新しくネットワークで起動されたUSSDダイアログが設定される（ステップ5107）。切り替え後は、SN1409はITAPセッションを再開する（ステップ5109）。
本発明の１つの実施の形態に関するITAPオペレーションの詳細を以下で説明する。ITAPはアプリケーションの実体間で、相互対話の通信における仕様のための、リモートオペレーションの概念を用いている。ITAPはROSE及び以前に参考文献として採用したCCITT勧告X.208:Abstract Syntax Notation（ASN.1）及びCCITT勧告X.219:Remote Operation:Protocol Specificationとして定義されているASN.1シンタックスにより明示される。
リモートオペレーション
ITAPオペレーションは４つのROSEプリミティブにより定義される。
invoke（request）
Result（positive outcome）
Error（negative outcome）
Reject（protocol error）
各ITAPオペレーションはROSEによって定義される規定にしたがって分類される。
オペレーションクラス１、同期型、成功あるいは失敗を報告
オペレーションクラス２、非同期型、成功あるいは失敗を報告
オペレーションクラス３、非同期型、失敗のみ報告
オペレーションクラス４、非同期型、成功のみ報告
オペレーションクラス５、結果は報告されない
タイマ
使用したタイマ値の範囲は以下により変換して範囲指定する。
s＝3秒から１０秒
m＝15秒から30秒
ml＝１分から１０分
l＝２８時間から３８時間
オペレーション及びアイドル状態の２種類のタイマが存在する。オペレーションタイマは要求しているアプリケーションの実体が要求の結果を待ている時に起動される。タイマの時間切れまでに結果が帰ってこなかった場合には、オペレーションは取りやめになる。ITAPオペレーションタイマは、次節の“基本的ITAPオペレーション”内のITAPオペレーションそれぞれに対して設定される。アイドル状態タイマはIMS1401内でサービス用の未処理の要求がない場合や、SN1409内で要求が実行されていない場合に起動する。セッション上に活動がない場合には、アイドル状態タイマは期限切れになる。IMS1401及びSN1409内のアイドル状態タイマは以下のようになる。
MS、ml
SN、ml
なお、アイドル状態タイマがIMS1401で期限切れになった場合にIMS1401はUnbindを送信するので、アイドル状態タイマは、セッションを適切な方法で終了させるために、IMS1401内ではSN409内よりも少し短くなくてはならない。
基本的及びアプリケーション依存型ITAPオペレーション
ITAPオペレーションは２つの主要なグループに分割される。
基本的ITAPオペレーション:これらのオペレーションは基礎的、サービス非依存型のオペレーションで、ITAPを使用するすべてのアプリケーションに共通である。これらのオペレーションは次節以降で明示される。
アプリケーション依存型ITAPオペレーション:SN1409内のサービスアプリケーションの機能をリモートで呼び出すために、IMS1401によって開始されるオペレーション。これらの機能の規範及び制約は以下で明示される。
ITAPの基本動作
イメージ記述について詳細に書かれている以下の節で、データ形式を説明する。

--IMSをSNにバインドする
--クラス1オペレーション
Unbind::=OPERATION
--IMSをMSNからアンバインドする
--クラス5オペレーション

--MSNからイメージ記述を要求する
--クラス1オペレーション

--IMSにイベントに対する警報を出す
--クラス3オペレーション

--SNがデータベースにアクセスできない時にこのエラーコードが返される。
BindReasonNotSupported::=ERROR
--バインド動作において、正当なバインドの理由があるが、MSNが
--この特定のバインドの理由に対するサービスを提供していない時に
--このエラーコードが返される。
DataMissing::=ERROR
--データが失われた時、例えば、オプションパラメータが失われた時に
--このエラーコードが返される。
SystemFailure::=ERROR
--他のエンティティの問題によってタスクが実行できない時に
--このエラーコードが返される。
UnexpectedDataValue::=ERROR
--データの値がITAPの動作の規定外である時にこのエラーコードが返される。
UnknownApplicationVersion::=ERROR
--SNがサポートしていないバージョンのアプリケーションを、
--IMSがバインドした時にこのエラーコードが返される。このことは、
--IMSがITAPのイメージ記述をサポートしていない時のみ適用される。
UnknownImageDescr::=ERROR
--要求されたイメージ記述が定義されていない時にこのエラーコードが返される。
UnknownTerminalType::=ERROR
--getImageDescr動作で特定されている端末の形式が定義されて
--いない時にこのエラーコードが返される。
SubscriptionViolation::=ERROR
--加入者に関する適切な申し込みがない時にこのエラーコードが返される。
PARAMETERS
アーギュメントデータ形式

--IMSにあるapplicationVersionがアラート動作の対応するバージョン
--と異なっている場合、IMSはBind動作で応答する。
--selectedLanguageパラメータは、指定した加入者のために現在選択
--されている言語を示す。serviceIdは、警報の理由を定義する。
--イメージ記述のサポートを受けている端末のserviceIdは、最初に描写され、
--評価される画像に等しい。アラートタイマーはIMSでアラート動作を
--受け取ったときに発動する。アラートタイマーが切れた場合、
--Unbind動作がSNに送られる。また、アラートタイマーは、
--最初のITAP動作がIMSから送られたときにクリアされる。
--aPartyInfoとbPartyinfoは、a-partyとb-pertyのアドレス情報を
--送るために使われる。textInfoはサービスユーザーに示す文字列を
--送るために使われる。subServiceは、申し込みに含まれているアプリ
--ケーションのどこかの部分を示すために使われる。

--MSNが新しいapplicationVersionで応答した場合、IMSは
--キャッシュに蓄えていたイメージ記述の一部またはすべてを消さな
--ければならない。clearImageCacheの値がTRUEの場合、
--imagesToClearで定義されたイメージ記述は消される。
--clearImageCacheの値がTRUE、かつimagesToClearの値が
--与えられていない場合、キャッシュの中身全体が消される。
--IMSがイメージ記述をサポートしておらず、かつIMSのアプリケ
--ーションのバージョンがSNのアプリケーションバージョンと
--異なる場合、セッションは閉ざされる。IMSは、SNがサポート
--している（選択している）言語用のイメージ記述を保持しているか
--どうか調べる。IMSのキャッシュサイズによっては、選択された
--言語によるイメージ記述用のスペースを作るために、IMSにある
--既存のイメージ記述を消す必要があり得る。serviceIdは、最初に
--表示、評価されるイメージ記述に等しい。aPartyInfoとbPartyInfoは、
--a-partyとb-partyに関するアドレス情報を送るのに使われる。
--textInfoはサービスユーザーに示す文字列を送るのに使われる。
--nameOfAppl、initSessionIncomingCallまたはinitSessionCallWaiting
--は、Bindを発動したときの理由が”initSubscription”であるとき
--のみ返される。nameOfApplはアプリケーションの名前である。
--この文字は、そのアプリケーションにアクセスするためにMMI上の
--メニューに表示するために使われる。
--initSessionIncomingCall/initSessionCallWaitingは、新しい呼が
--やってきたとき、または指示を待っている呼があるときに
--ITAPセッションを設立するかどうかを示す。subServiceは申し込みの中に
--書かれているアプリケーションのどこかの部分を示すために使われる。

--要求されたイメージ記述は画像IDと端末形式で区別される。
--端末形式が与えられていない場合、SNはデフォルトセットの
--中からイメージ記述を選択する。SNが異なる言語をサポートして
--いる場合、バインドの間に選択された言語は、正しいイメージ記述を
--認識するために使われる。
共通データ形式

--可能なアドレス形式を挙げている。restricted変数は、数値指定の
--制限があるときに使われる。

--アドレスとアドレスの名前を挙げる。
AlertTimer::=INTEGER（0..65535）
--アラートを受け取ったときのIMSユーザーのアイドル時間を挙げる。
ApplicationVersion::=INTEGER（0..65535）
--現在のアプリケーションのバージョン。

--Bindの理由を示す。例えば、新しい入呼、誤ったアプリケー
--ションバージョン、ユーザーが初期化したセッション、申し込み管理。
ByteString::=OCTET STRING（SIZE（1..255））
--バイト文字列
ClearImageCache::=BOOLEAN
--TRUEならば、IMSの画像キャッシュの一部、またはすべてを消す
--必要がある。
DateAndTime::=OCTET STRING（SIZE（6））
--YYMMDDHHSSのように、BCD符号であらわす。
--例えば、1995年12月31日12時15分ならば、59 21 13 21 51 00
DistributionListId::=INTEGER（0..15）
--分布リストのID。
ImageId::=INTEGER（0..65535）
--ITAPに関するIMS画像に独特なID。

--MSのために選択された言語。
LongInt::=INTEGER（-2147483647..2147483647）
-- -2、147、483、647から2、147、483、647までの符号付き整数。
Number::=TBCDString（SIZE（1..14））
--BCD形式で表された電話番号。
ServiceId::=INTEGER（0..65535）
--IMSで起動するアプリケーションを示す。IMSがイメージ記述をサポート
--している場合、serviceIdは最初に表示され、評価されるイメージ記述を
--定義する。
SMSString::=OCTET STRING（SIZE（1..140））
--GSMの03。38で定められた7ビットのSMSデフォルトアルファ
--ベットで符号化されたビット列。
SubService::=OCTET STRING（SIZE（1..4））
--申し込みの中に含まれているサービスのいずれかを示すビット列。
--最初の８ビットの１ビット目は１番目のサブサービスの有無を示し、
--次の２ビット目は２番目のサブサービスの有無を示し…のように続き、
--最高３２個（４オクテット分）のサブサービスを指定することができる。
--異なるビット群の解釈はアプリケーション特有であり、アプリケー
--ション特有の動作を定義する。
SupportOfImage::=BOOLEAN
--TRUEの場合、IMSはイメージ記述をサポートしている。
TBCDString::=OCTET STRING（SIZE（1..64）
--digitが詰められたビット列。digitとは、0_9、^*、#、a、b、cのいずれか
--であり、１オクテットに２つのdigitが入る。それぞれのdigitは、
--以下のように符号化される。
--0000_0009（0_9）、1010（^*）、1011（#）、1100（a）、1101（b）、1110（c）
--1111は半端な数のdigitがある場合のフィルタとして使われる。
--最初のdigitは、最初の１オクテットの0_3ビット目に蓄えられる。
TerminalType::=SMSSTring（SIZE（1..31））
--IMS端末の形式。例えば、”GH338”。
TextString::=IA5String（SIZE（1..255））
--文字列。
UnsigunedByte::=INTEGER（0..255）
--0から255までの符号無し整数。

アプリケーションに依存するITAPの動作の規則と制限
1.以下の動作はすべてROSEのクラス１である。
2.各動作の仕様の構造は、以下のようになる。

--MyOperationの説明
3.ITAPの動作に依存するアプリケーションの動作コードは、10から255までの範囲内である。動作コード1から9はITAPの基本動作のために予約してある。
4.各動作のアーギュメント（“MyArg”、“MyResultArg”）は常にSEAUENCEデータ形式として指定される。
動作アーギュメントの要素としていくつかのデータ形式が用いられる。そのデータ形式は以下の通りである。
BOOLEAN、
UnsignedByte、
LongInt、
ByteString、
TextString、
AddressInfo、
DateAndTime、
Number、
SMSString
これらのデータ形式のそれぞれは基礎データ形式、または”SEQUENCEOF”データ形式として使われる。
ある特定の要素の値の範囲またはサイズの範囲を特定することは許されていない。要素の形式によって特定されている値の範囲またはサイズの範囲がかなり小さくならなければならない場合、その要素はASN。1のシンタックスとしてではなくコメントとして示されるだろう。なぜなら、PERが使われる場合、“サイズが決められた要素”の長さ部分が、最大サイズのために必要なビットの数を含んでいるからである。また、ある“値の要素”の値部分のために必要なビットの数がその特定された最大の値に依存する。これらにより、長さ部分、または値部分のためのビットの数が可変になってしまう。MSにあるPERのエンコーダ・デコーダが可変長な部分の長さを扱うことは、PERが汎用的であるために難しい。
タグのつけ方は以下のとおりである。
-連続した整数（0から始まる）
-文脈に特有
-明示しない
オプションのパラメータはその動作アーギュメントの後で説明される。
DEFAULTは許されない。
例を後に続ける。

3.エラー形式にはパラメータは無い。エラーコードは20から255までの数であり、エラーコードの1から19まではITAPの基本動作用に予約されている。
4.ITAPの動作に依存しているアプリケーションは、独立したASN。1モジュールの中で規定される。このモジュールは、基本的なITAP ASN。1モジュールから指定されたデータ形式の使用を取り込む。
この説明の焦点はイメージ記述のより詳細な記述である。このイメージ記述は主にIMSの供給者を必要としている。なぜなら、SNの観点から見ると、イメージ記述はITAPのGetImageDescription動作によって取り寄せる必要のある単なるリソースであるからである。
後述の仕様はASN。1シンタックスを用いて作られている。ここで規定されていないデータ形式は前記のITAPの動作を説明している節で規定されている。
仕様

--イメージ記述の主な構造。
--イメージ記述を行うとき、IMSは以下の手続きを行う。
--1.宣言されたレジスタのためのメモリを割り当てる。
--2.論理機能のための新しい定義を行う。
--3.動作を行う。動作項目は番号順に評価される。新しいイメージ記述が
--動作中に行われる場合、、IMSは新しいイメージ記述を取ってきて、
--その評価を行い、ステップ1に移る。動作は決して中断できない。
--IMSが動作中にイベントを受け取った場合、そのイベントはイベント
--キューで待たされる。持たせているイベントと関連のある動作は
--IMSが何もしていなくてイベントキューから次のイベントを
--取り出している場合に実行される。
--4.ヘッダを表示する。
--5.画面やリストを含む画像オブジェクトを表示する。
--6.次のイベントに移る。IMSはイベントキューから次のイベントを
--取り込む。イベントがない場合、IMSはアイドル状態のまま
--次のイベントを待つ。イベントは優先度を持つ。以下に大きい順で
--示す。
-- 1.徴候と接続が切れる徴候
-- 2.タイムアウト
-- 3.ユーザの入力
--7.イベントを受け取ったらすぐにステップ３で示される関連動作を
--実行する。

--画像オブジェクト。一つの画像オブジェクトには一つのメニュー
--またはリストオブジェクトだけが存在しうる。
レジスタのデータ形式
--レジスタはIMSの中にデータを貯めるために使われる。レジスタは
--そのレジスタを定義するイメージ記述が動作中になったとき、すなわち、
--displayImageがIMSで実行された場合に割り当てられる。一度
--レジスタが割り当てられると、ITAPセッションが終わるかまたは
--新しいレジスタが同じIDに割り当てられるまで割り当てられ続ける。
--レジスタが割り当てられている限り、他のイメージ記述のためにその
--レジスタを参照することができる。
--レジスタは、レジスタの中身を表示する画面やリストと関連させる
--ことができる。更にレジスタはローカルまたはリモートにある機能に
--渡す入出力パラメータと関連させることができる。レジスタはベクトル
--を持つものか、ただ一つの項目を含むもののいずれかになる。レジスタが
--ベクトルの場合、ベクトルのインデックスを与えることにより、
--ベクトルの中のある入力にアクセスすることができる。

--sizeパラメータはレジスタがベクトルかどうかを示す。sizeが１の場合、
--そのレジスタは単一のレジスタと考えられる。

--レジスタのデータ形式は独特のタグによって定義される。

--レジスタの項目の参照。ベクトルでないレジスタの参照、または
--ベクトルレジスタを含む項目への参照となることができる。
--ベクトルレジスタにはベクトルのインデックスが必ずある。

--OneRegisterEntryInVectorはベクトルレジスタ内の項目を参照する
--ために使われる。
RegisterId::=INTEGER（0..255）
--レジスタのID。

--ベクトルのインデックスは、レジスタ内の固定値、指定されたリスト列か、
--整数値のいずれかである。インデックスがあるレジスタに蓄えられる場合、
--そのレジスタはLongInt型、またはUnsignedByte型でなければならない。
--ベクトルのインデックスがselectedListRowにもなりうるので、画面の
--内容がリストオブジェクトの中のあるリスト列に依存するイメージ記述を
--デザインすることができる。それゆえ、サービスユーザがリストオブ
--ジェクトをスクロールするときに、IMSは画面を更新することが
--できなければならない。
動作データ形式
--以下に続く用語はパラメータとして使われる。
--simpleValue…ベクトルでないレジスタから与えられる値。その値は
--レジスタのIDだけで一意に決められる。
--レジスタIDは1
--simpleVector…ベクトルレジスタから得られる値。ベクトル全体は
--パラメータとしてパスされる。ベクトルはレジスタIDによって
--一意に決められる。
--レジスタIDは1
--simpleValueInVector…レジスタベクトルの中にあるレジスタ項目から
--得られる値。その値はレジスタIDとベクトルインデックスによって
--一意に決められる。
--レジスタIDは１、ベクトルインデックスは３

--いくつか組み合わせることで動作になる様々な項目。”localFunction”は
--IMSにおいて実行される機能を定義する。”remoteFunction”はサービス
--ノードで実行される機能を定義する。displayImage動作項目は、新しい
--イメージ記述を表示するために使われる。displayImageが実行されるとき、
--現在のイメージ記述の評価が遮断され、新しいイメージ記述が表示される。
--conditionalStatementとlabelStatementは関連している。
--conditionalStatementは評価するための論理的表現を定義する。
--評価結果によると、conditionalStatementは１つまたは２つのlabelStatement
--を参照にして、どこまで実行し続けるかを定義する。labelStatementは、
--動作が実行し続けている実際の場所である。endStatementはある動作の
--実行が即座に止められることを示している。

--条件付きの記述。expressionは評価される表現を定義する。trueとfalse
--のラベルは実行し続けるラベルのIDを定義する。その参照されたラベルは
--同じ動作内で定義されなければならない。少なくともtrueLabelか
--falseLabelのパラメータのうちの一つが定義されなければならない。
--それらのパラメータの一つが省略されている場合、その動作の実行は
--そのパラメータに相当するラベルを持つ次のactionItemまで継続される。

--評価される表現を指定する。その表現は左から右（“firstParameter
--“operator”“secondParameter”の順）に評価される。１番目と２番目の
--パラメータは、UnsignedByte型がINTEGER型で評価されうるのと、
--TextString型がSMSString型で評価されうるのを除いて、常に同じ型で
--なければならない。firstParameterがBOOLEAN型であるとき、
--secondParameterとoperatorは省略できる。

--表現のためのパラメータを指定する。パラメータは、一定値、単純
--レジスタ値、ベクトルの中の単純値、指定されたリスト列のいずれかである。

--機能要求への入力パラメータを指定する。入力パラメータは
--以下の通りである。
--一定値または連続した一定値、単一のレジスタ値、ベクトルレジスタ、
--ベクトルの中にある単一の値、選択されたリスト列、値無し（オプション）。
Label::=INTEGER（0..255）
--ラベルのIDを定義する。同一の動作内でのみ、その実行をラベルに
--変換することができる。

--イメージ記述からローカルな機能を呼ぶ要求を指定する。致命的なエラーが
--起きて機能が実行できなくなった場合、実行はエラーラベルに移される。
--エラーラベルが与えられないのに致命的なエラーが起こった場合、
--致命的エラーの扱いとして、ITAPセッションはITAPのUnbind動作
--をすることにより終了する。

--IMS機能独特のID。
maxNoOfParameters INTEGER::=16
--入出力パラメータの最大数
OperationCode::=INTEGER（10..255）
--SNで実行される機能を定義する。

--可能な演算子すべて。優先度の高い順に並べてある。例えば、
--logicalOrはlogicalAndよりも優先度が低い。

--機能から得られる出力パラメータを指定する。出力パラメータは
--以下の通りである。
--単一のレジスタの値、ベクトルレジスタ、ベクトルの中の単一の値

--イメージ記述からリモート機能を呼ぶ要求を指定する。リモート動作が
--符号化されるのか解読されるのかをIMSが知るために、いくつかある
--オプションのパラメータを指定しなければならない。timeOutは、
--未解決な要求に対する応答が起こるまでの秒数を指定する。指定した
--時間内に応答を受け取らなかった場合、信号の接続が切られる。
--致命的なエラーが生じて機能が実行できない場合、実行はエラーラベルに
--移される。エラーラベルが与えられずに致命的なエラーが生じた場合、
--致命的エラーの扱いとして、ITAPセッションはITAPのUnbind動作
--をすることにより終了する。
TimeOut::=INTEGER（0..65535）
--タイムアウト時間を秒数で定義する。
メニューのデータ形式
IconId::=INTEGER（0..65535）
--IMSでローカルに蓄えられるグラフィカルリソースのID。アイコンは
--グラフィカルなIMS上でのみ使うことができる。あるIconIdに関連する
--リソースは、端末の供給機関によって定義される。

--メニューの中の一つの列（オプション）、すなわち表示物や、オプションが
--選択されたときに呼ぶ機能を指定する。どのようにメニューをユーザに
--示すかを決定するのはIMSである。iconパラメータはIMSに蓄えられ
--ているローカルなアイコンを指す。iconパラメータはグラフィカルな
--端末にのみ適用される。subServiceStatusはメニューオプションが表示
--されるかどうかを示している。申込みにメニューオプションのサービスが
--含まれていない場合、メニューオプションは常に使うことができない。

--それぞれのオプション列のテキストはこれらの項目の集まりから成る。
--このオプションテキストを画面に構成する方法を決めるのはIMSである。
リストデータ形式

--リスト列にある各項目を指定する。参照されたレジスタはリストの各列に
--含まれるデータを持つ。lengthは各項目の長さを定義し、conversionは
--代わりの表現を定義する。例えば、INTEGER型の1はテキスト列のYES
--を表す。アドレス情報の表現には同様の規則がアドレスフィールドに適し
--ている。このことについては”入出力フィールドデータ形式”の節を参照。
--selectedRegisterはリストの中で選択されている列の値を持つ。
--１つの列が選択される場合、selectedRegisterは１つの項目を持つ。２つの
--列が選択される場合、レジスタは２つの項目を持つ。１つも選択されない
--場合、レジスタは空である。可能な選択数はpossibleSelectionsパラメー
--タで定義される。

--値からテキスト列への変換を指定している。アイコンはグラフィカルな
--端末のための変換と関係している。

--ITAPの基本データ形式。
SelectedListRow::=NULL
--この形式は選択されたリスト列を指定する。IMSはこの値を計算する。
--初めのリスト列は0である。
入出力フィールドデータ形式

--アドレスの出力または入出力フィールドを指定する。レジスタは
--AddressInfo形式またはNumber形式である。AddressInfo形式のレジスタ
--の表現のために以下の規則が定義されている。
--1.あるアドレスが得られる場合、IMSは自分のアドレス帳の中にある
--アドレスを探し、アドレス帳で見つけた名前を表示する。
--2.名前がネットワークから与えられ、その項目がIMSのアドレス帳にない
--場合、その名前が表示される。
--3.名前が得られないがそのアドレスが得られる場合、そのアドレスが
--表示される。
--加入者は名前とアドレスを結びつけることができる。Number形式の
--レジスタは常に数字として表示される。

--整数の入力または入出力フィールドを指定する。レジスタは符号有り、
--または符号無しの整数形式である。

--数字の出力または入出力フィールドを指定する。レジスタはNumber形式
--である。

--一般的な選択型入出力フィールドを指定する。IMSはこれをメニュー、
--チェックボックス、選択ボタン、選択フィールド、キー入力などとして
--表現する。選択が行われたとき、レジスタはConversionItem形式で
--指定された値を持つ。”moreThanOneAllowed”がFALSEである場合、
--そのレジスタは常に１つの値を持つ。すなわち、サービスユーザは１つの
--選択を行わなければならない。”moreThanOneAllowed”がTRUEである
--場合、最初に選択された項目の値はレジスタの索引0番に蓄えられ、
--２番目に選択された項目の値は索引１番に蓄えられ、以下２番、３番、、、
--と同様に続く。選択がない場合、レジスタは空である。

--オプションフィールドに関連するレジスタを指定する。レジスタは
--以下に示すものである。
--単一のレジスタ、レジスタベクトルの中にある要素、レジスタベクトル。

--テキストの出力または入出力フィールドを指定する。レジスタは
--textString形式である。

--日付と時間の出力または入出力フィールドを指定する。レジスタは
--DateAndTime形式である。タイムスタンプを適切な方法で表現するのは
--IMSである。
論理機能形式

--0_4番の論理機能はGSM 2.30で指定されている。disconnect機能は
--接続が切れたときに実行される動作を指定する。timeout機能はIMSの
--startTimer機能と一緒に始まったタイマーが切れた場合に行われる動作を
--指定する。論理機能はIMSの標準機能に優先する。論理機能に関連する
--動作が行われていない場合、IMSによって標準機能が行われる。

--標準のGSM論理機能が実行されているときにどの機能を呼ぶべきかを
--指定する。その定義は、ITAPセッション中に現在のイメージ記述が
--アクティブまたは正当であるときに一時的であり妥当である。
共通データ形式

--アドレスの形式。
END
IMSの機能の仕様
概要
画像を描写するとき、IMSの機能の要求は”LocalFunction”データ形式によって指定される。このデータ形式にはオプションとして”errorLabel”が含まれる。この”errorLabel”を通して、致命的なエラーが生じたときに実行される動作を指定することができる。しかし、その機能要求に”errorLabel”が含まれていない場合、デフォルトのエラーの取り扱いが行われる。すべてのIMSの機能のための、致命的エラーのデフォルトの扱いは、ITAPのUnbind動作によってITAPセッションを終えることである。
イメージ記述とそのオブジェクトを操作するための機能
displayErrorMessage
エラーメッセージを画面に表示する。
入力パラメータ：

出力パラメータ：
なし
エラー：
なし
storeSessionInitiatedParam
テキスト情報、すなわちアラート要求またはBind結果とともにSNから受け取ったa-partyとb-partyのアドレス情報を一連のレジスタ内に蓄える。この機能はアラート、Bind応答動作の中にあるserviceIdと同じ番号を持つイメージ記述から呼ばれる。
入力パラメータ：

出力パラメータ：
なし
エラー：

setMenuEntryStatus
メニュー項目の状態をセットする。メニュー項目の状態は”enabled”か”disabled”である。状態がdisabledの場合、そのメニュー項目はサービスユーザには表示されない。デフォルトの状態はenabledである。
入力パラメータ：

出力パラメータ：
なし
エラー：

addRegisterEntry
ベクトルレジスタに項目を追加する。ベクトルの始めや終わり、または分類順に項目を追加することができる。この機能は項目が挿入された索引を返す。挿入された索引番号よりも大きい番号を持つ項目は１つ大きい索引へ移される。ベクトルが項目で満杯であり、かつ挿入方法がベクトルの先頭、あるいは分類順である場合、最後の項目は取り除かれ、新しい項目が挿入される。ベクトルが満杯であり、かつ挿入方法がベクトルの終わりである場合、項目数の最大値を超えたことを示すエラーが返される。注:“分類順”の挿入方法は分類されたベクトルだけが使用できる。
入力パラメータ：

出力パラメータ：

エラー：

insertRegisterEntry
ベクトルレジスタに項目を挿入する。挿入された項目よりも大きい索引番号を持つ項目は１つ大きい索引番号に移される。ベクトルが項目で満杯の場合、最後の項目が取り除かれ、新しい項目が挿入される。
入力パラメータ：

出力パラメータ：
なし
エラー：

removeRegisterEntry
一連のベクトルレジスタのある項目を取り除く。取り除かれた項目よりも大きい索引番号を持つ項目は、ギャップを埋めるために１つ小さい索引番号に移される。
入力パラメータ：

出力パラメータ：
なし
エラー：

searchRegister
ベクトルレジスタの中のある項目を検索する。検索項目に該当する最初の項目の索引番号を返す。この機能は該当する項目を見つけるためにレジスタ全体を検索しなければならないので、そのレジスタは分類されていない可能性がある。
入力パラメータ：

出力パラメータ：

エラー：

sortRegister
ベクトルレジスタやベクトルレジスタの付加的なリストを分類する。この機能への入力は、分類されるレジスタである。
入力パラメータ：

出力パラメータ：
なし
エラー：

mergeRegister
２つのベクトルレジスタを合併する。両方のレジスタは同じ形式でなければならない。結果レジスタはregisterId1と同じIDを持つ。
入力パラメータ：

出力パラメータ：
なし
エラー：

clearRegister
一連のベクトルレジスタまたは単一のレジスタを消去する。
入力パラメータ：

出力パラメータ：
なし
エラー：

setRegister
単一レジスタの値、またはベクトルレジスタの中にある項目の範囲を入れる。代入する値はそのレジスタと同じ形式でなければならない。
入力パラメータ：

出力パラメータ：
なし
エラー：

incrementRegister
レジスタの項目の値を増やす。レジスタはLongint形式またはUnsignedByte形式でなければならない。
入力パラメータ：

出力パラメータ：
なし
エラー：

decrementRegister
レジスタの項目の値を減らす。レジスタはLongInt形式またはUnsignedByte形式でなければならない。
入力パラメータ：

出力パラメータ：
なし
エラー：

copyRegister
あるレジスタの内容を他のレジスタに複写する。両方のレジスタは同じ形式でなければならないが、単一レジスタまたはベクトルレジスタであってよい。レジスタがベクトルの場合、ベクトル全体が複写される。
入力パラメータ：

出力パラメータ：
なし
エラー：

executeOptionNo
画像に表示するメニューのうち選択されたメニューオプションで指定された動作を実行する。
入力パラメータ：

出力パラメータ：
なし
エラー：

exitItapControl
制御をIMSの基本部分に返す。UnbindがSNに送られる。
入力パラメータ：
なし
出力パラメータ：
なし
エラー：
なし
startNewITAPSession
新しいITAPセッションを始める。新しいセッションIDを持つBindがSNに送られる。ベアラの容量が、すでにアクティブのITAPセッションが一時的に中断されるかどうか、または新しいITAPセッションと並行して実行されつづけるかを決定する。
入力パラメータ：

出力パラメータ：
なし
エラー：

startTimer
タイマーを始める。タイマーが切れた場合、論理機能タイムアウトで定義されている動作を行う。タイマーはstopTimer機能によってクリアされる。１つのタイマーだけ始めることができる。
入力パラメータ：

出力パラメータ：
なし
エラー：

stopTimer
タイマーを止める。startTimer機能によってスタートしたタイマーをクリアする。
入力パラメータ：
なし
出力パラメータ：
なし
エラー：

関連する機能を呼ぶ
acceptIncomingCall
IMSで指示された要求を受け入れる、またはIMSを次の入力要求を受け入れられる方式にする。
この機能にはエラー応答がない。即座に要求IDを返す。要求IDは常に１以上である。
入力パラメータ：
なし
出力パラメータ：

エラー：

disconnectCall
要求またはマルチパーティーを接続しない。
入力パラメータ：

出力パラメータ：
なし
エラー：

setUpCall
他の相手への要求を行う。機能は即座に要求IDを返す。
入力パラメータ：

出力パラメータ：

エラー：

GSMの補足サービスにアクセスするための機能
callHold
アクティブの要求またはマルチパーティーを待ち状態にする。すでに待ち状態の要求がある場合、その要求がアクティブになり、そのIDが返される。待ち状態の要求がない場合、0番のcallIdが返される。
入力パラメータ：
なし
出力パラメータ：

エラー：

callActive
待ち状態の要求またはマルチパーティーをアクティブにする。
入力パラメータ：
なし
出力パラメータ：

エラー：

multiParty
会議の要求を行う。マルチパーティーにおいてはアクティブの要求と待ち状態の要求が結び付けられ、サービスを受けているモバイルの加入者や遠くにいるパーティーはすべてお互いに通信しあうことができる。機能はマルチパーティーのIDを返す。
入力パラメータ：
なし
出力パラメータ：

エラー：

removeCallFromMultiParty
マルチパーティーから要求を取り除く。取り除かれた要求はアクティブになり、マルチパーティの要求は待ち状態になる。
入力パラメータ：

出力パラメータ：
なし
エラー：

callTransfer
要求を他のパーティーに伝送する。
入力パラメータ：

出力パラメータ：
なし
エラー：

DTMFを扱うための機能
sendDTMF
DTMF数列をアクティブの要求接続に送る。
入力パラメータ：

出力パラメータ：
なし
エラー：

setDTMFMode
DTMFのモードをオンまたはオフにする。
入力パラメータ：

出力パラメータ：
なし
エラー：
なし
SMSを扱う機能
enquirySM
MS-TEまたはSIMに貯えられている関連するショートメッセージを問う。
入力パラメータ：

出力パラメータ：

エラー：

sendSM
ショートメッセージを送る。応答パス、プロトコルID、サービスセンターアドレスなどのモバイル端末が作ったショートメッセージのために与えられた他のパラメータのために、この機能はIMSに蓄えられているデフォルトの値を使う。
入力パラメータ：

出力パラメータ：

エラー：

replySM
受け取ったショートメッセージに応答する。この機能は元のショートメッセージで応答パスが要求されているかを調べる。応答パスが要求されている場合、元のショートメッセージにあるサービスセンターのアドレスが応答メッセージに使われる。応答パスが要求されていない場合、デフォルトのサービスセンターのアドレスが使われる。受信者のアドレスは常に元のメッセージから取り込む。
入力パラメータ：

出力パラメータ：

エラー：

getSM
ショートメッセージを得る。
入力パラメータ：

出力パラメータ：

エラー：

deleteSM
ショートメッセージを削除する。
入力パラメータ：

出力パラメータ：
なし
エラー：

commandSM
SMS-Cに命令を送る。以下のコマンドが定義されている:提出されたメッセージ（送られたもの、送られてないもの、置き換わったもの）の状態を尋ねる、状態を報告するための要求を止める、または提出されたメッセージを削除する。
入力パラメータ：

出力パラメータ：
なし
エラー：

IMSのハードウェア、ソフトウェアオブジェクトにアクセスする機能
generateIndication
IMSにあるベルの音などの指示物を生成する。
入力パラメータ：

出力パラメータ：
なし
エラー：

stopIndication
IMSにあるベルの音などの指示物を止める。
入力パラメータ：

出力パラメータ：
なし
エラー：

displayIndication
IMSの画面に指示物を表示する。
入力パラメータ：

出力パラメータ：
なし
エラー：

removeDisplayIndication
IMSにおける画面の指示を取り除く。
入力パラメータ：

出力パラメータ：
なし
エラー：

setStatusLine
IMSの画面に状態リストを置く。
入力パラメータ：

出力パラメータ：
なし
エラー：
なし
enquiryByAddress
アドレスによって指定される1つまたはそれ以上の加入者に関するアドレス情報についてアドレス帳を調べる。機能は探索キーに当てはまる全ての項目を返す。
入力パラメータ：

出力パラメータ：

エラー：

addAddressBookEntry
アドレス帳に項目を追加する。
入力パラメータ：

出力パラメータ：

エラー：

updateAddressBookEntry
アドレス帳の中の項目を更新する。
入力パラメータ：

出力パラメータ：
なし
エラー：

removeAddressBookEntry
アドレス帳の中にある項目を取り除く。
入力パラメータ：

出力パラメータ：
なし
エラー：

個人アクセスサービスのためのアプリケーション依存ITAP動作の詳細な記述に、今までの記述の焦点が置かれている。アプリケーション依存動作の抽象的なシンタックスは、ASN。1シンタックスを使用している“ITAPの動作“、という題名の節で定義される規則と制限に従う。
サービスID
概要
ITAPの動作であるAlertとBindは、ITAPセッションを始める理由（例えば、入力要求または新しいメッセージ）を示すことができる。その理由はサービスIDパラメータによって指示される。その動作と一緒に、サービスIDに関連するパラメータ、すなわち文字情報やアドレス情報を与えることができる。
この節では、個人アクセス（Personal Access、PA）アプリケーションのために異なるサービスIDを定義し、またその異なるサービスのために初期化したITAP動作におけるアプリケーションに依存するパラメータを伝送するのにどのようにして対応したパラメータを使用するかを定義する。
メッセージ送信とプロファイル管理
サービスユーザが認証なしでサービスノードの中の個人アクセスアプリケーションにアクセスする時に使われるのがサービスIDである。サービスユーザは、メールボックスを尋ねたり、または個人のプロファイルを扱うためにサービスを提供されている。サービスIDはどのパラメータとも関連が無い。
入力要求
入力要求のためのITAPセッションは、２通りの方法、すなわちネットワーク主導またはモバイル主導で設立される。ネットワーク主導のITAPセッションは、スピーチ接続が設立する前に要求者が遮られるときに起こる。スピーチ接続の設立によりIMSが新しいITAPセッションを始める時は、ITAPセッションがモバイル主導になる。Aの数値やAの名前は、情報が得られた場合、または、要求者の制限が無い場合に送られる。Aの名前とAの番号はAlert発動またはBind結果の中のaPartyInfoパラメータに当てはめる。
新しいメッセージ認識
メッセージ通知のためのITAP動作は常にネットワーク主導である。サービスノードは、新しいメッセージが加入者のメールボックスに蓄えられたことを示すために、ITAPのAlert動作でITAPのセッションを始める。通知情報はアプリケーション依存動作であるRetrieveNewMessageInformationを扱うことでSNから取り込むことができる。一つのパラメータも通さない。
スクリーニング終了の通知
スクリーニングが終わったことを示すITAPセッションは、常にネットワークから設立される。終了した上演の理由は文字列で送られる。スクリーニングの理由はAlert動作のtextInfo
パラメータにある。サービスユーザは新しい終了時間を設定することができる。
一般的な通知
通知のためのITAPセッションは常にネットワークから設立される。通知理由は文字列として送られる。通知の文字はAlert動作のtextInfoパラメータにある。
状態の境界線を引く
状態の境界線を引くためのITAPセッションは、常にネットワークから始められる。現在のスクリーニング状態が変わった時のように、アイドル状態で表示されている状態文字が変わることを示すことで、サービスノードはITAPのAlert動作によってITAPセッションを開始する。状態文字はAlert動作のtextInfoパラメータの上にある。
認証
サービスユーザが認証によってサービスノードの中の個人アクセスアプリケーションにアクセスしているとき、サービスIDが良く使われる。サービスユーザは個人認証番号（PIN）コードを入力するよう要求される。正しいPINコードが入力されている場合、サービスユーザはメールボックスを見たり、個人のプロファイルを管理することにより、サービスを受ける。どのパラメータもサービスIDとは関連しない。
サービス番号

サブサービス
PAアプリケーションは、個人に関連するサービスから成る動作環境を与える。そのサービスには必須なものと補足的なものがある。
必須のPAサービスと、使用可能な補足的PAのサービスから使用者が独自に選択したものからなるPAサービスアプリケーションパッケージを作り出すことができる。
以下のPAのサービスが必須である:
-ボイスメール
-個人番号
-POTS PAサービス
-通知
-Operator Determined Barring
以下のUIFにおけるPAサービスが補足的である。
-ファックス検出
-呼び手の選択
-呼び手の表示
-呼を隠す
-入力呼の選択
-呼のログ
-ファックスメール
-電子メール
-転換
どの補足的なサービスがサービスユーザの加入権に含まれているかの確認は、Bind結果またはAlert起動にあるsubServiceパラメータで示されている。サービスは以下のように割り当てられている。
-ファックス検出…オクテット1のビット1
-呼び手の選択…オクテット1のビット2
-呼び手の表示…オクテット1のビット3
-呼を隠す…オクテット1のビット4
-入力呼の選択…オクテット1のビット5
-呼のログ…オクテット1のビット6
-ファックスメール…オクテット1のビット7
-電子メール…オクテット1のビット8
-転換…オクテット2のビット1
もしビットが1なら、対応するサービスが加入権に含まれている。
PA特有のITAP動作
以降で指定されていないデータ形式は、以前の“ITAPの動作“という題の節で指定されている。
呼び出しに関する動作

--入ってくる子を受け付け、パーティーがすぐに接続される。
--クラス1オペレーション

--前もって定義されているメッセージが呼んでいるパーティーに表示され、
--呼び手の番号は呼のバックログに蓄えられる。
--クラス1オペレーション

--呼のセットアップ状態をSNから尋ねるために使われる。SetUpCall、
--PlayMessage、RecordGreeting、PlayGreetingからの成功結果の後で
--動作が行われる。
--クラス1オペレーション

--入ってくる呼はできるだけすぐに応答されるように、とのメッセージが
--呼んでいるパーティーに向かって作られる。
--クラス1オペレーション

--入ってくる呼が拒まれ、呼び手が応答の無い目的地へ行かされる。
--クラス1オペレーション

--サービスノード（SN）にある目的地、IMSへの呼のログを取るように要求する
--。IMSへの呼のログが割り当てられていたとき、すなわち、SNがネットワ
--ークから”Alerting”の指示を受けったときに、SNは結果を返す。
--クラス1オペレーション

--呼は新しい目的地へ送られる。目的地は作業者または決まった数によって
--定義された番号である。
--クラス1オペレーション
メッセージに関する動作

--要求するメッセージが入っている郵送をやめる
--クラス1オペレーション

--一つまたはそれ以上のメッセージを削除する。
--クラス1オペレーション

--郵送ログを尋ねる。
--クラス1オペレーション

--加入者のメールボックスから、質問と関連するメッセージ、例えば
--タイムスタンプ、作動者、メディア、IDを尋ねる状態。結果は、SNに
--は更に多くの得られる項目があるかどうか、を示す。残りの部分が付加した
--状態情報要求によって、選択されたより多くの情報が割り当てられている
--状態に解消される。

--流れているボイスメッセージを高速にする方法を述べる。この動作は
--声のメッセージが演奏されたときに思うでしょう。SNはすぐに結果を返す。
--クラス1オペレーション

--メッセージについて、メッセージヘッダ、長さ、優先度、メッセージの中
--身などの詳細情報を得る。

--加入者のメールボックスに蓄えられている関連するメッセージ番号の状態。
--クラス1オペレーション。

--再生中のボイスメッセージの休止を行う。その動作はボイスメッセージが
--再生されているときにのみ行うことができる。付け加えた休止動作は休止
--しているボイスメッセージを再生することができる。SNはその結果をすぐに
--返す。
--クラス1オペレーション

--現在の挨拶を表示するようサービスノードに要求する。IMSと設立され
--ているスピーチ接続がない場合、SNはスピーチ接続を設立する。
--スピーチ接続が割り当てられたとき、すなわちSNが“Alerting”の指示
--を受信したときにその結果を返す。IMSはその結果が返されるときに
--呼を受け付ける。挨拶の再生はSNによって応答メッセージ（ANM）が検出
--されたときに始められる。すでにスピーチ接続が設立されている場合、
--SNはすぐに挨拶を再生し始め、その結果をすぐに返す。
--クラス1オペレーション。

--SNに加入者のボイスメールボックスの中にあるボイスメッセージを再生する
--要求を出す。IMSとスピーチ接続が設立されていない場合、SNはスピーチ
--接続を設立する。スピーチ接続が割り当てられたとき、すなわちSNが
--“Alerting”の指示をネットワークから受信したときに結果を返す。
--IMSはその結果が返されるときに呼を受け付ける。メッセージの再生は、
--応答メッセージ（ANM）がSNによって検出されたときに始められる。既に
--スピーチ接続が設立されている場合、SNはすぐにメッセージの再生をはじめ
--、すぐにその結果を返す。

--SNに新しい現在の挨拶を記録するよう要求する。IMSとスピーチ接続が
--設立されていない場合、SNはスピーチ接続を設立する。スピーチ接続が
--割り当てられたとき、すなわちSNが“Alerting”の指示をネットワーク
--から受信したときに結果を返す。IMSはその結果が返されるときに呼を
--受け付ける。挨拶の記録は、応答メッセージ（ANM）がSNによって
--検出されたときに始められる。既にスピーチ接続が設立されている場合、
--SNはすぐに挨拶の記録を始め、すぐにその結果を返す。

--メッセージの検索または挨拶の記録、例えば呼のログや信号の対話といった
--ことに割り当てられていた全てのリソースを開放するようSNに要求する。
--クラス1オペレーション。

--新しいメッセージに関する情報を検索する。この動作は、
--“New Message Notification”サービスIDを持ってITAPセッションを
--設立するときに使われる。新しいメッセージの通知パラメータを返す。
--クラス1オペレーション。

--既に再生されたボイスメッセージの巻き戻しを行う。この動作はボイス
--メッセージが再生されているときにのみ行うことができる。SNは
--その結果を即座に返す。
--クラス1オペレーション。

--指定されたメッセージを記録する。
--クラス1オペレーション。

--指定された目的地へメッセージを送る。転送されるよう選択された
--メッセージはメディア形式とともにメッセージIDによって認証される。
--クラス1オペレーション。

--ボイスメッセージを再生するのを止める。SNは即座に結果を返す。
--クラス1オペレーション。
プロファイルに関連する動作

--白または黒のスクリーニングリストに新しい番号を加える。
--クラス1オペレーション。

--呼のログの項目を削除する。
--クラス1オペレーション。

--スクリーニングリストからある番号を削除する。
--クラス1オペレーション。

--呼のログの中の関連する項目、例えばタイムスタンプ、呼び手のIDなどの
--状況調査。SNに得られる状態項目があるかどうかを結果が示す。
--残りの部分は、より多くの情報を持っているログ形式による追加の状態調査
--によって検索される。
--クラス1オペレーション。

--スクリーニングリストにある関連項目、例えば接続番号などの状態調査。
--クラス1オペレーション。

--現在アクティブの前もって定義されているルーティングテーブルのIDと
--名前を検索する。
--クラス1オペレーション。

--ビジーで応答のない目的地を検索する。
--クラス1オペレーション。

--すぐにメッセージを送るためにプロファイルを検索する。
--クラス1オプション。

--“古い電話サービス“（POTS）アクセスのために使われる言語を検索する。
--クラス1オペレーション。

--利用可能なルーティングテーブルの名前やIDのリストを検索する。
--クラス1オペレーション。

--提出された通知形式を検索する。
--クラス1オペレーション。

--ルーティングリストを検索する。
--クラス1オペレーション。

--サービスノードからルーティングテーブルを検索する。
--クラス1オペレーション。

--スクリーニングプロファイルを検索する。
--クラス1オペレーション。

--スクリーニングの理由のリストを検索する。
--クラス1オペレーション。

--ある特定のルーティングテーブルの探索時間を検索する。
--クラス1オペレーション。

--アクティブなルーティングテーブルを入力パラメータのルーティング
--テーブルIDで指定されたルーティングテーブルに変更する。
--クラス1オペレーション。

--ビジー状態で応答のない目的地を更新する。
--クラス1オペレーション。

--スクリーニングリストの項目を更新する。
--クラス1オペレーション。

--メッセージの即時配送用のプロファイルを更新する。
--クラス1オペレーション。

--POTSへのアクセスに使用する言語形式を更新する。
--クラス1オペレーション。

--設定されていたルーティングテーブルの名前を更新する。
--クラス1オペレーション。

--設定されている通知形式を更新する。
--クラス1オペレーション。

--サービスノードのルーティングテーブルを更新する。
--クラス1オペレーション。

--スクリーニングプロファイルを更新する。
--クラス1オペレーション。

--ルーティングテーブル内の各要素の探索時間を更新する。
--クラス1オペレーション。
認証動作

--入力されたPINコードを調べる。
--クラス1オペレーション。

--サービスノードから認証状態を検索する。
--クラス1オペレーション。

--サービスノードの認証状態を更新する。
--クラス1オペレーション。

--サービスユーザのIDが正しいことを証明するために使われるPINコードを
--更新する。
--クラス1オペレーション。

--Faxの検出が正しく実行された。呼はFaxの送信先にルーティングされ、
--入ってきた呼の選択は終了する。
HookOn::=ERROR
--A-partはフックオンを実行した。
CallAnswerd::=ERROR
--呼は接続されない。例。輻輳あるいはリソース限界の発生
SytemFailure::=ERROR
--呼は同時に通知された他の送信先によってすでに応答された。
UnknownMedia::=ERROR
--未定義メッセージ
UnknownStatus::=ERROR
--未定義メッセージ
UnknownResource::=ERROR
--未定義メッセージ
IllegalAdress::=ERROR
--アドレス不正
NoMoreMessages::=ERROR
--メールボックス内にこれ以上メッセージがない。
UnknownRoutingTable::=ERROR
--未定義のルーティングテーブル
UnknownCallLog
--未定義の呼のログ
UnknownRoutingList::=ERROR
--未定義のルーティングリスト
IllegalOperation::=ERROR
--不正なオペレーション
AutheticationFailed::=ERROR
--不正なPIN-Codeが入力された
PINCodeBlocked::=ERROR
--過剰なリトライによりPIN-Codeがブロックされた
NoAnswer::=ERROR
--応答なし
Busy::=ERROR
--呼び差し先がビジーである
NoReachable::=ERROR
--呼び出し先に到達できない

--Type of List:0=ホワイトリスト、1=ブラックリスト
--PIN-Codeあるいは発呼者はスクリーニングリストに登録される

--リスト内のIndexに新しいスクリーニングエントリが記録される

--Media:1=Faxメール、2=E-メール、3=SMS

--Type of call log:0=入ってきた呼のログ、1=失った呼のログ、2=折り返し呼の
--ログCall log entryは呼のろぐのインデックスである。インデックスは1から
--10の値をとる

--Media:0=音声メール、1=Faxメール、2=E-メール、3=SMS.SEQUENCE OF
--の大きさはSIZE（1..0）の範囲内。音声メッセージの再生中にオペレーションが
--呼び出された場合にはメッセージID及びメディアは省略できる。
--メッセージID及びメディアは現在のメッセージからSNでフェッチされる。

--Type of list:0=ホワイトリスト、1=ブラックリスト
--Index:消去されるスクリーンニングリストにおけるエントリのインデックス

--SEQUENCE OFパラメータの大きさはSIZE（1....10）の範囲

--Selected media:1=faxメール、2=E-メール、3=SMS、4=全部

--SEQUENCE OFパラメータの大きさはSIZE（1..。10）の範囲。mediaパラメー
--タは選択したmediaがallに等しい場合のみ。

--Selected media:0=音声メール、1=faxメール、2=E-メール、3=SMS、4=全部
--Selected satus:0=新規、1=古い、2=保存済み、3=全て、4=更なる情報

--SEQUENCE OFパラメータのサイズはSIZE（1..5）の範囲。mediaパラメータ
--は選択したメディアが「全て」に等しい場合のみ。
--ステータスパラメータは選択されたパラメータのステータスがallに等しい場
--合のみ。

--Type of list:0=ホワイトリスト、1=ブラックリスト

--SEQUENCE OFパラメータのサイズはSIZE（1..25）の範囲。
--Indexは（1..25）の範囲。

--Selected media:0=音声メール、1=faxメール、2=E-メール、3=SMS、4=全部

--Priority:0=低、1=通常、2=高
--メッセージの長さはメディアに依存。音声メッセージ（秒）、
--Faxメッセージ（ページ）、E-メール（バイト）、SMS（文字）
--このメッセージbodyパラメータはE-メールのみ。メッセージが
--SMSSringのサイズよりも長い場合には、メッセージは切り捨てられる。
--SEQUENCE OFパラメータのサイズはSIZE（1..5）の範囲。

--Type of media:0=音声メール、1=faxメール、2=E-メール、3=SMS、4=全部

--選択したメディアにおける加入者メールボックス内のメッセージ数
--要求のメディア形式が「全部」の場合には、全てのパラメータが返される。
--メディア形式が特定のメディアの場合には、要求されたメディアの
--パラメータが返される。例えば、メディア形式が音声メールの場合には、
--音声メールの数が返される。
--SEQUENCE OFパラメータのサイズは常に４。SEQUENCE OFは
--以下の情報を備える。
--Index1=メッセージ総数
--Index2=新しいメッセージなし
--Index3=古いメッセージなし
--Index4=保存されたメッセージなし
--メッセージ数が255の場合には、少なくとも255のメッセージがあることを示
--す。

--TypeOfPlay:0=全て、1=特定、2=繰り返し、3=次
--SNはメッセージ識別によって識別された音声メッセージを再生する。
--再生形式が「全て」の場合には、全てのメッセージは順に再生される。
--再生形式が「特定」の場合には、特定のメッセージが再生される。
--再生形式が「次」の場合には次のメッセージが再生される
--「繰り返し」及び「次」は1つ以上のメッセージが再生された場合にのみ
--用いられる。メッセージIDは「繰り返し」及び「次」では用いられない。

--Type of resource:0=音声メール、1=faxメール、2=E-メール、3=SMS、4=全
--部

--アクティブルーティングテーブル識別は（1..5）の範囲である。

--認証ステータスアクティブ（On／Off）

--名前及び番号は、アドレス情報が利用可能な時、これに含まれる。番号が
--ユーザに表示された場合、たとえばビジーな送信先がオペレータが指定した
--送信先であった場合、名前はアドレス情報に含まれ、ルーティングテーブル
--内のインデックスはアドレス（例えば#4）とし送信される。名前が
--利用可能でない場合には、番号のみが含まれる。

--Source media:0=音声メール、1=faxメール、2=E-メール、3=SMS

--名前及び番号は、アドレス情報が利用可能な時、これに含まれる。番号が
--ユーザに表示された場合、たとえばビジーな送信先がオペレータが指定した
--送信先であった場合、名前はアドレス情報に含まれ、ルーティングテーブル
--内のインデックスはアドレス（例えば#4）とし送信される。名前が
--利用可能でない場合には、番号のみが含まれる。
--Immediate and auto copy media:0=音声、1=Faxグループ3、
--2=Faxグループ4、3=SMS、4=E-メール、5=Ermes、
--6=テレテックス、7=テレックス

--異なる言語の値は、ITAPオペレーションと題された前節における
--言語のデータタイプに対応する。

--ルーティングテーブルの名前及び識別のリスト。
--SEQUENCE OFパラメータのサイズはSIZE（1..5）。
---ルーティングテーブル識別は（1..5）の範囲

--Media:0=音声メール、1=faxメール、2=E-メール、3=SMS

--Type of notofication:0=ダイアルアウト、1=ページャー、2=SMS、
--3=Fax、4=E-メール、5=USSD、6=ITAP

--0=ルーティングテーブル管理、加入者及びオペレータによって定義された
--送信先が返される。
--1=転送による入ってきた呼の選択、加入者及びオペレータによって定義された
--送信先が、最近の転送先とともに返される。
--2=Fax管理、加入者及びオペレータによって定義された送信先が返される。
--3=E-メール管理、E-メールのデフォルトの送信先が返される。

--SEQUENCE OFパラメータのサイズはSIZE（1..10）の範囲であり、
--latestDestinationはSIZE（1..4）の範囲。
--名前及び番号は、アドレス情報が利用可能な時、これに含まれる。番号が
--ユーザに表示された場合、たとえばビジーな送信先がオペレータが指定した
--送信先であった場合、名前はアドレス情報に含まれ、ルーティングテーブル
--内のインデックスはアドレス（例えば#4）として送信される。
--サービスユーザがルーティングリストからエントリを選択した場合には、
--ルーティングリストからのアドレス情報はSNに送信される。オペレータが
--定義した送信先がある場合には、実際のアドレスを発見するためにSNは
--番号パラメータの中のルーティングインデックスを用いる。名前が
--利用可能でない時には番号のみが示される。

--ルーティングテーブル識別は（1..5）の範囲。

--SEQUENCE OFパラメータのサイズはSIZE（1..2）の範囲。
--名前及び番号は、アドレス情報が利用可能な時、これに含まれる。番号が
--ユーザに表示された場合、たとえばビジーな送信先がオペレータが指定した
--送信先であった場合、名前はアドレス情報に含まれ、ルーティングテーブル
--内のインデックスはアドレス（例えば#4）として送信される。名前が
--利用可能でない場合には、番号のみが含まれる。

--スクリーニングがアクティブの場合には、screening reasonは現在の
--スクリーニング理由（例えば会議、休暇）を示す。スクリーニングが
--アクティブでない場合には、このパラメータは最後に失効した
--スクリーニング理由を示す。Screening reasonは1-10の値をとる。
--会議、休暇などのスクリーニング理由に関するテキスト。
--SEQUENCE OFパラメータは1-10の範囲。

--ルーティングテーブル識別は（1..5）の値をとり得る。

--検索時間は1-60秒の値をとり得る

--Media:0=音声メール、1=Faxメール、2=E-メール、3=SMS。
--タグはメッセージと一緒に記憶される。
--音声メッセージの再生中にオペレーションが呼び出された場合には
--メッセージID及びメディアは省略できる。
--メッセージID及びメディアは現在のメッセージからSNでフェッチされる。

--Media:0=音声メール、1=faxメール、2=E-メール、3=SMS
--Recipient media:0=音声、1=Faxグループ3、
--2=Faxグループ4、3=SMS、4=E-メール、5=Ermes、
--6=テレテックス、7=テレックス

--アクティブルーティングテーブルの設定。ルーティングテーブル識別は
--（1..5）の値をとり得る。

--確立される呼の数。
--音声メッセージの再生中にオペレーションが呼び出された場合には
--bnumberは省略できる。
--SNは現在のメッセージ数をフェッチする

--転送される呼の数。
--転送先がルーティングリストのエントリである場合には、ルーティング
--リストからのエントリから完全なアドレスが送信される。
--アドレス情報がローカルのアドレスリストあるいは手動で番号入力された
--場合には番号のみがSNに送信される。

--認証ステータスアクティブ（On/Off）

--アドレス情報がルーティングリストからのエントリである場合には、
--ルーティングリストからの完全なアドレス情報が送信される。
--アドレス情報がローカルのアドレスリストあるいは手動で番号入力された
--場合には番号のみがSNに送信される。

--Type of list:0=ホワイトリスト 1=ブラックリスト
--Index:更新されるスクリーニングリストにおけるエントリのインデックス
--スクリーニングリストを更新する呼び出し者の新しいPIN-Code
--あるいは識別

-アドレス情報がルーティングリストからのエントリである場合には、
--ルーティングリストからの完全なアドレス情報が送信される。
--アドレス情報がローカルのアドレスリストあるいは手動で番号入力された
--場合には番号のみがSNに送信される。
--Source Media:0=音声メール、1=faxメール、2=E-メール、3=SMS
--Immediate and auto copy media:0=音声、1=Faxグループ3、
--2=Faxグループ4、3=SMS、4=E-メール、5=Ermes、
--6=テレテックス、7=テレックス

--ルーティングテーブルの名前の更新。ルーティングテーブル識別の
--値は（1..5）の範囲。

--PINコードが変更される前に、古いPINコードはプロファイル内に
--記録されている古いPINコードと比較される。

--ルーティングテーブル識別は（1..5）の値をとる。
--SEQUENCE OFパラメータのサイズはSIZE（1..2）の範囲。
--名前及び番号は、アドレス情報が利用可能な時、これに含まれる。番号が
--ユーザに表示された場合、たとえばビジーな送信先が、オペレータが指定した
--送信先であった場合、名前はアドレス情報に含まれ、ルーティングテーブル
--内のインデックスはアドレス（例えば#4）として送信される。名前が
--利用可能でない場合には、番号のみが含まれる。

--screening reasonは、例えば会議、休暇などの現在の
--スクリーニング理由を示すスクリーニング理由は1-10の値をとる。

--ルーティングテーブル識別の値は（1..5）の範囲。検索時間は1-60秒の範囲
オペレーションコード
呼に関連するオペレーション
acceptCall AcceptCall
callBack CallBack
holdCall HoldCall
rejectCall RejectCall
setUpCall SetUpCall
transferCall TransferCall
enquiryCallSetUpStatus EnquiryCallSetUpStatus
メッセージに関連するオペレーション
cancelMessageDelivery CancelMessageDelivery
deleteMessage DeleteMessage
enquiryDeliveryLog EnquiryDeliveryLog
eunqiryMailbox EunqiryMailbox
fastForwarding FastForwarding
getDetailedMessageInfo GetDetailedMessageInfo
mailboxStatus MailboxStatus
pause Pause
playGreeting PlayGreeting
playMessage PlayMessage
recordGreeting ReleaseResource
retriveNewMessageInfo RetriveNewMessageInfo
retriveNewMessageInfo RetriveNewMessageInfo
rewind Rewind
saveMassage SaveMassage
sendMessage SendMessage
stop Stop
プロファイルに関連するオペレーション
addEntryToScreeningList AddEntryToScreeningList
deleteEntryInScreeningList DeleteEntryInScreeningList
enquiryCallLog EnquiryCallLog
enquiryScreeningList EnquiryScreeningList
retriveActiveRoutingTable RetriveActiveRoutingTable
retriveBusyAndNoAnswerDest RetriveBusyAndNoAnswerDest
retrieveImmediateDelivery RetrieveImmediateDelivery
retriveLanguage RetriveLanguage
retrieveNameOfRoutingTables RetrieveNameOfRoutingTables
retrieveNotificationtype RetrieveNotificationtype
retrieveRoutingList RetrieveRoutingList
retrieveRoutingTableRetrieveRoutingTable
retrieveScreeningProfile RetrieveScreeningProfile
retrieveScreeningReasons RetrieveScreeningReasons
retrieveSearchTimes RetrieveSearchTimes
setActiveRoutingTable SetActiveRoutingTable
updateBusyAndNoAnswerDest UpdateBusyAndNoAnswerDest
updateEntryInScreening UpdateEntryInScreening
updateImmediateDelivery UpdateImmediateDelivery
updateLanguage UpdateLanguage
updateNameOfRoutingTable UpdateNameOfRoutingTable
updateNotificationType UpdateNotificationType
updateRoutingTable UpdateRoutingTable
updateScreeningProfile UpdateScreeningProfil
updateSearchTimes UpdateSearchTimes
認証オペレーション
authenticate Authenticate
retrieveAuthenticaionStatus RetrieveAuthenticaionStatus
updateAuthenticationStatus UpdateAuthenticationStatus
updatePINCode UpdatePINCode
エラーコード
faxdetected Faxdetected
hookOn HookOn
callAnswe CallAnswer
systemFailure SystemFailure
unknownMessage UnknownMessage
accessDeniedToResource AccessDeniedToResource
unknownMedia UnknownMedia
unknownStatus UnknownStatus
unknownResource UnknownResource
illegalAddress IllegalAddress
noMoreMessages NoMoreMessages
unknownRoutingTable UnknownRoutingTable
unknownCallLog UnknownCallLog
unknownRoutingList UnknownRoutingList
illegalOperation IllegalOperation
authenticationFailed AuthenticationFailed
pINCodeBlocked PINCodeBlocked
noAnswer NoAnswer
図５２から図６４を用いて、多くの典型的なITAPセッションのシナリオを説明する。
まず、着呼の選択に関するシナリオを示す図５２から図５７について述べる。図５２は呼が受け付けられるときの、着呼の選択を示している。IMS1401は、Bindオペレーションを用い（ステップ5203）、IMSにおける新しい呼の通知の受信への新しいセッションを開始する（ステップ5201）。SN1409は呼び出し者の名前及び番号を応答する（ステップ5205）。この例では、IMSのアプリケーションバージョンは、SN1409のアプリケーションバージョンと等しく、イメージ記述の開始はキャッシュメモリ上で利用可能である。トラフィックチャネルはすでに割り当てられているので、呼がIMS1401でローカルに許可された場合、直ちに音声接続が確立される（ステップ5207）。新しいセッションはUnbindオペレーションを送信することで閉じられる（ステップ5209）。
図５３は、呼の拒否が行われるときの、着呼の選択を示している。IMS1401は、Bindオペレーションを用い（ステップ5303）、IMSにおける新しい呼の通知の受信への新しいセッションを開始する（ステップ5301）。SN1409は発呼者の名前及び番号を応答する（ステップ5305）。この例では、IMSのアプリケーションバージョンはSN1409のアプリケーションバージョンと等しく、イメージ記述の開始はキャッシュメモリ上で利用可能である。呼は拒否され、シグナリングリソースは解放される（ステップ5307）。
図５４は、呼の転送が行われるときの、着呼の選択を示している。IMS1401は、Bindオペレーションを用い（ステップ5403）、IMSにおける新しい呼の通知の受信への新しいセッションを開始する（ステップ5401）。SN1409は発呼者の名前及び番号を応答する（ステップ5405）。この例では、IMSのアプリケーションバージョンはSN1409のアプリケーションバージョンと等しく、イメージ記述の開始はキャッシュメモリ上で利用可能である。呼は転送され（ステップ5407）、この転送に関してあらかじめ決まっている送信先が更新される。
図５５は、呼の保持が呼び出されるときの、着呼の選択を示している。IMS1401は、Bindオペレーションを用い（ステップ5503）、IMSにおける新しい呼の通知の受信への新しいセッションを開始する（ステップ5501）。SN1409は発呼者の名前及び番号を応答する（ステップ5505）。この例では、IMSのアプリケーションバージョンはSN1409のアプリケーションバージョンと等しく、イメージ記述の開始はキャッシュメモリ上で利用可能である。サービスユーザは発呼者に回線を保持するように要求し（ステップ5507）、呼はしばらくしてから受け付けられる（ステップ5509）。
図５６は、折り返しが呼び出される時の、着呼の選択を示している。IMS1401は、Bindオペレーションを用い（ステップ5603）、IMSにおける新しい呼の通知の受信への新しいセッションを開始する（ステップ5601）。SN1409は発呼者の名前及び番号を応答する（ステップ5605）。この例では、IMSのアプリケーションバージョンはSN1409のアプリケーションバージョンと等しく、イメージ記述の開始はキャッシュメモリ上で利用可能である。サービスユーザは個人アクセスアプリケーションを呼び出し、あらかじめ決められたメッセージを発呼者に再生する（ステップ5607）。
図５７は、ITAPセッションがすでに進行中であるときの、着呼の選択を示している。サービスノードとIMS1401間にはITAPセッションがすでに確立している（ステップ5701）。IMS1401は、Bindオペレーションを用い（ステップ5705）、IMSにおける新しい呼の通知の受信への新しいセッションを開始する（ステップ5703）。SN1409は発呼者の名前及び番号を応答する（ステップ5707）。呼び出し手続きはIMS1401にすでに確立しているので、呼の受付はIMS1401のみで実行される。サービスノードは、応答イベントの監視によって、呼が受け付けられたことを検出する。新しいセッションはUnbindオペレーションを送信することにより終了する（ステップ5709）。サービスノード1409はIMS1401に空のUSSD requestオペレーションを送信することで、古いセッションを再会する。
メールボックスに関連するサービスを、図５８から図６１を用いて説明する。図５８において、サービスユーザはITAPセッションを開始する（ステップ5801）。MaiboxStatus invokeを発行した後に（ステップ5803）、サービスユーザは音声メールボックスに新しいメッセージについて問い合わせを行う（ステップ5805）。
図５９では、サービスユーザはITAPセッションを確立しており、音声メールボックスに問い合わせを行う。サービスユーザは音声メッセージの再生を選択する（ステップ5901）。いったん音声回線がIMS1401に割り当てられれば（ステップ5903）、IMS1401に結果が返送される（ステップ5905）。音声メッセージの再生はDTMFシグナリングによって制御される（ステップ5907）。サービスユーザが音声メールのセッションの終了を選択した場合には、ReleaseResourceオペレーションがSN1409に送信される（ステップ5909）。
図６０では、サービスユーザはITAPセッションを確立しており、音声メールボックスあるいは各種の呼のログに問い合わせを行う。サービスユーザは音声メッセージの登録者あるいは呼のログに保持されている番号を選択する（6001）。呼のセットアップは、この資料に前述してあるように進行する。
図６１では、IMS1401はITAPセッションを開始し、IMSのアプリケーションバージョンはSN1409のアプリケーションバージョンと等しい。イメージ記述の開始はキャッシュメモリ上で利用可能である。EnquiryMailbox invokeを発行し（ステップ6101）、結果を受信した後（ステップ6103）、faxを受信するためにIMS1401はSendMessage invokedを発行する（ステップ6105）。これに対して、新しいfaxメッセージが転送される（ステップ6107）。
図６２及び６３を用いて、ルーティングテーブルの更新について説明する。図６２では、あるルーティングテーブルがサービスノード1409によって検索され、IMS1401のサービスユーザに表示される（ステップ6201、6203、6205及び6207）。サービスユーザはルーティングテーブルを修正し、それをサービスノードに保存する（ステップ6305）。
図６３では、サービスノード1409は利用可能なルーティングテーブルに関して問い合わせをされる（ステップ6301及び6303）。サービスユーザはルーティングテーブルを１つ選択し、IMS1401がSetActive RoutingTable invokeを発行することによって、そのルーティングテーブルはアクティブになる（ステップ6305）。
ITAPを用いる新しいメッセージ通知を、図６４を用いて説明する。通常SMSが通知メディアとして用いられる。しかしながら、ITAP/USSDを新しいメッセージの通知メディアとして用いることにより、サービスユーザはすでに確立されたITAPセッションにおいて直ちにメールボックスに問い合わせることができる。SN1409はIMS1401に新しいメッセージについて通知する（ステップ1401）。この場合では、IMSのアプリケーションバージョンはSN1409のアプリケーションバージョンと等しく、イメージ記述の開始はキャッシュメモリ上で利用可能である。新しいメッセージに関する情報はSNからフェッチされる（ステップ6403及び6409）。セッションは図５８から図６１及び付随する文に示されるように継続する。
本発明が特定の実施の形態を用いて説明された。しかしながら、当業者により容易に明らかにできるように、前述の好適な実施の形態以外の特定の形態に本発明を実施することが可能である。その実施は、本発明の範疇を越えずに実施可能であろう。好適な実施の形態は、まったく説明的なものであり、いずれの面でも制限を行うものではない。本発明の範囲は前述の説明よりもむしろ添付の請求項により与えられ、請求の範囲に入る変更したもの及び等価なもののすべては、請求の範囲に包含される。

Claims

帯域制限のある通信手段でインテリジェント端末に接続されたサービスノードを含む通信システムにおいて、前記インテリジェント端末のユーザにサービスを提供する方法であって、
前記サービスノードが、ユーザが前記インテリジェント端末のマンマシンインタフェースを起動したことを示す第１メッセージを、前記インテリジェント端末から受信するステップと、
前記サービスノードで、前記第１メッセージを解析して１つのルーチンを指示するプリミティブを決定するステップと、
前記サービスノードが、前記帯域制限のある通信手段を用いて、前記プリミティブによって指示される前記ルーチンを実行することを前記インテリジェント端末に命令する第２メッセージを、前記インテリジェント端末に送信するステップと、
前記インテリジェント端末で、前記第２メッセージに応答して前記プリミティブによって指示される前記ルーチンを実行するステップとを含み、
前記第２メッセージをインテリジェント端末に送信するステップは、前記帯域制限のある通信手段で音声接続が確立されているかに依存せずに実行されることを特徴とする方法。
前記第２メッセージは更にパラメータを含み、
前記プリミティブによって指示されるルーチンを実行するステップは、受信した前記第２メッセージのパラメータを用いることを特徴とする請求項１記載の方法。
前記プリミティブによって指示されるルーチンを実行するステップは、前記インテリジェント端末のユーザに情報を提示するステップを含むことを特徴とする請求項１又は２記載の方法。
前記プリミティブによって指示されるルーチンを実行するステップは、前記インテリジェント端末の状態を変化させるステップを含むことを特徴とする請求項１乃至３のいずれか１項に記載の方法。
前記プリミティブにより指示されるルーチンを実行するステップは、
前記インテリジェント端末で、前記ルーチンの実行のため、前記インテリジェント端末が遷移する状態を定義する状態表であって前記インテリジェント端末に現在記憶されていない状態表が必要かを判定するステップと、
前記状態表が必要と判定された場合に、前記帯域制限のある通信手段を用いて、前記状態表を要求するメッセージを前記インテリジェント端末から前記サービスノードに送信するステップと、
前記インテリジェント端末が、前記帯域制限のある通信手段を用いて、要求された前記状態表を前記サービスノードから受信するステップと
前記インテリジェント端末で、受信した前記状態表を用いて前記ルーチン実行するステップとを備えることを特徴とする請求項１乃至４のいずれか１項に記載の方法。
前記インテリジェント端末で、前記サービスノードとの通信を行わずに、前記インテリジェント端末と前記ユーザとの間のメニュー操作の入出力機能を実行するステップを更に備えることを特徴とする請求項１乃至５のいずれか１項に記載の方法。
提供される前記サービスに依存しないマンマシンインタフェースの枠組みにしたがって、前記インテリジェント端末のユーザ入出力機能を制御するステップを更に備えることを特徴とする請求項１乃至６のいずれか１項に記載の方法。
帯域制限のある通信手段でサービスノードがインテリジェント端末に接続されている通信システムにおいて、前記インテリジェント端末のユーザにサービスを提供する方法であって、
前記インテリジェント端末において、
端末ベアラ・サービスプロバイダを前記通信手段と連結して、前記サービスノードに配置されたサービスノードベアラ・サービスプロバイダとプロトコルデータ・ユニットを交換するステップと、
端末アプリケーションプロトコル・サービスプロバイダが、前記ユーザが前記インテリジェント端末のマンマシンインタフェースを起動したとの検出に応答し、前記端末ベアラ・サービスプロバイダを使用して、前記サービスノードに配置されたサービスノード・アプリケーションプロトコル・サービスプロバイダと第１セッションを確立し、前記端末ベアラ・サービスプロバイダが前記通信手段で音声接続を確立することを要求することなしに、前記サービスノード・アプリケーションプロトコル・サービスプロバイダとオペレーションを交換するステップと、
端末サービスアプリケーションが、前記ユーザにローカルサービスを提供すると共に、前記端末アプリケーションプロトコル・サービスプロバイダを使用して、サービスノード・サービスアプリケーションにより実行されるリモートユーザサービスを要請するステップとを有し、
前記サービスノードにおいて、
サービスノードベアラ・サービスプロバイダを前記通信手段と連結して、前記インテリジェント端末に位置する前記端末ベアラ・サービスプロバイダとプロトコルデータ・ユニットを交換するステップと、
サービスノード・アプリケーションプロトコル・サービスプロバイダが、前記サービスノードベアラ・サービスプロバイダを使用して、前記インテリジェント端末に配置された端末サービスノード・アプリケーションプロトコル・サービスプロバイダと前記第１セッションを確立し、前記サービスノードベアラ・サービスプロバイダが前記通信手段で音声接続を確立することを要求することなしに、前記サービスノード・アプリケーションプロトコル・サービスプロバイダと前記オペレーションを交換するステップと、
サービスノード・サービスアプリケーションが、リモートサービスを提供すると共に、前サービスノード・アプリケーションプロトコル・サービスプロバイダを使用して、端末サービスアプリケーションに対してリモートサービスの結果を提供するステップとを有し、
前記端末サンプルアプリケーションはイメージ記述インタプリタとして提供され、
前記サービスノード・アプリケーションプロトコル・サービスプロバイダが、イメージ記述を前記端末アプリケーションプロトコル・サービスプロバイダに送り、
前記端末アプリケーションプロトコル・サービスプロバイダが、前記イメージ記述を受信して前記イメージ記述インタプリタに提供し、
前記イメージ記述が前記インテリジェント端末により実行されるオペレーションを定義していることを特徴とする方法。
前記サービスノードと第１セッションを確立するステップは、前記インテリジェント端末及びサービスノードで使用される資源が互いに整合性を持つのを確実にするために、前記インテリジェント端末とサービスノードとの間でネゴシエーションを行うステップを備えることを特徴とする請求項８記載の方法。
前記サービスノードと第１セッションを確立するステップは、前記インテリジェント端末とサービスノードとの間の通信で用いられる符号化の種別を明示するステップを備えることを特徴とする請求項８又は９記載の方法。
前記符号化の種別が基本符号化ルール（ＢＥＲ：Basic Encoding Rules）であることを特徴とする請求項１０記載の方法。
前記符号化の種別が圧縮符号化ルール（ＰＥＲ:Packed Encoding Rules）であることを特徴とする請求項１０記載の方法。
前記第１セッションが維持されている間に、前記帯域制限のある通信手段により前記インテリジェント端末とサービスノードとの間で第２セッションを開始するステップを更に備えることを特徴とする請求項８乃至１２のいずれか１項に記載の方法。
前記インテリジェント端末のユーザに提供される情報を定義するイメージ記述を、前記サービスノードから前記インテリジェント端末に送信するステップを更に備えることを特徴とする請求項８乃至１３のいずれか１項に記載の方法。
前記インテリジェント端末でのイベントの検出に応じて、前記インテリジェント端末により実行される１つ以上のステップを定義するイメージ記述を、前記サービスノードから前記インテリジェント端末に送信するステップを更に備えることを特徴とする請求項８乃至１３のいずれか１項に記載の方法。
前記イメージ記述は、更に前記インテリジェント端末のユーザに提供される情報を定義することを特徴とする請求項１５記載の方法。
前記インテリジェント端末でのイベントの検出に応じて、前記インテリジェント端末により実行される１つ以上のローカルな端末機能を定義するイメージ記述を、前記サービスノードから前記インテリジェント端末に送信するステップを更に備えることを特徴とする請求項８乃至１３のいずれか１項に記載の方法。
前記帯域制限のある通信方法を用いてサービスノードにオペレーションを送信するステップは、前記オペレーションを非構造的な付加サービスデータのプロトコルデータ・ユニットにマッピングするステップを備えることを特徴とする請求項８乃至１７のいずれか１項に記載の方法。
前記帯域制限のある通信方法を用いてサービスノードにオペレーションを送信するステップは、前記オペレーションを２つ以上の非構造的な付加サービスデータのプロトコルデータ・ユニットにマッピングするステップを備えることを特徴とする請求項８乃至１７のいずれか１項に記載の方法。
前記帯域制限のある通信方法を用いてサービスノードにオペレーションを送信するステップは、前記オペレーションを短メッセージサービスのプロトコルデータ・ユニットにマッピングするステップを備えることを特徴とする請求項８乃至１７のいずれか１項に記載の方法。
前記帯域制限のある通信方法を用いてサービスノードにオペレーションを送信するステップは、前記オペレーションを下位レイヤプロトコルのプロトコルデータ・ユニットにマッピングするステップを備えることを特徴とする請求項８乃至１７のいずれか１項に記載の方法。
前記下位レイヤプロトコルのサービスプロバイダに関連したタイムアウトの発生を防止するために、前記インテリジェント端末から前記サービスノードにオペレーションを送信するステップを更に備えることを特徴とする請求項２１記載の方法。
前記オペレーションがアプリケーションプロトコル・サービスプロバイダに関連するものであって、前記下位レイヤプロトコルのサービスプロバイダに関連するタイムアウトの発生を防止するために、アプリケーションプロトコルサービスのセッションの終了及び再確立を行うステップを更に備えることを特徴とする請求項２１記載の方法。
前記帯域制限のある通信方法を用いてサービスノードにオペレーションを送信するステップは、前記オペレーションを下位レイヤプロトコルの２つ以上のプロトコルデータ・ユニットにマッピングするステップを備えることを特徴とする請求項８乃至１７のいずれか１項に記載の方法。
前記サービスノードからの補助を要求することなく、前記インテリジェント端末でローカルサービス機能を実行するステップを更に備えることを特徴とする請求項８乃至２４のいずれか１項に記載の方法。
前記サービスノードで、前記帯域制限のある通信方法を介して前記端末サービスアプリケーションに対してリモートサービスの結果を提供するステップは、前記結果を下位レイヤプロトコルの２つ以上のプロトコルデータ・ユニットにマッピングするステップを備えることを特徴とする請求項８乃至２５のいずれか１項に記載の方法。
前記サービスノードで、前記帯域制限のある通信手段を介して前記インテリジェント端末と前記第１セッションを開始するステップを更に備えることを特徴とする請求項８乃至２６のいずれか１項に記載の方法。
前記サービスノードで、前記帯域制限のある通信方法を介して前記インテリジェント端末と前記第１セッションを開始するステップは、前記インテリジェント端末に向けられたイベントの検出に応じて実行されることを特徴とする請求項２７記載の方法。
ユーザにサービスを提供する装置であって、
インテリジェント端末と、
サービスノードと、
前記インテリジェント端末とサービスノード間で情報の伝送を行う帯域制限のある通信手段とを備え、
前記インテリジェント端末は、
前記通信手段と接続され、前記サービスノードに配置されたサービスノードベアラ・サービスプロバイダとプロトコルデータ・ユニットを交換するための端末ベアラ・サービスプロバイダと、
前記ユーザが前記インテリジェント端末のマンマシンインタフェースを起動したとの検出に応答し、前記端末ベアラ・サービスプロバイダを用いて、前記サービスノードに配置されたサービスノード・アプリケーションプロトコル・サービスプロバイダと第１セッションを確立し、前記端末ベアラ・サービスプロバイダが前記通信手段上で音声接続を確立することを要求することなしに、サービスノード・アプリケーションプロトコル・サービスプロバイダとオペレーションを交換する端末アプリケーションプロトコル・サービスプロバイダと、
前記ユーザにローカルなサービスを提供するとともに、前記端末アプリケーションプロトコル・サービスプロバイダを用いて、サービスノード・サービスアプリケーションにより実行されるリモートユーザサービスを起動する端末サービスアプリケーションとを備え、
前記サービスノードは、
前記通信手段と接続され、前記インテリジェント端末に配置された端末ベアラ・サービスプロバイダとプロトコルデータ・ユニットを交換するためのサービスノードベアラ・サービスプロバイダと、
前記サービスノードベアラ・サービスプロバイダを用いて、前記インテリジェント端末に配置された端末アプリケーションプロトコル・サービスプロバイダと前記第１セッションを確立し、前記サービスノードベアラ・サービスプロバイダが前記通信手段で音声接続を確立することを要求することなしに、前記端末アプリケーションプロトコル・サービスプロバイダと前記オペレーションを交換するよう動作可能なサービスノード・アプリケーションプロトコル・サービスプロバイダと、
リモートサービスを実行するとともに、前記サービスノード・アプリケーションプロトコル・サービスプロバイダを用いて、前記端末サービスアプリケーションにリモートサービスの結果を提供するためのサービスノード・サービスアプリケーションとを備え、
前記端末サービスアプリケーションはイメージ記述インタプリタであって、
前記サービスノード・アプリケーションプロトコル・サービスプロバイダは、イメージ記述を前記端末アプリケーションプロトコル・サービスプロバイダに送る手段を有し、
前記端末アプリケーションプロトコル・サービスプロバイダは、前記イメージ記述を受信して前記イメージ記述インタプリタに提供する手段を有し、
前記イメージ記述が前記インテリジェント端末により実行されるオペレーションを定義していることを特徴とする装置。
前記イメージ記述は、前記インテリジェント端末のユーザに提供される情報を定義することを特徴とする請求項２９記載の装置。
前記イメージ記述は、前記インテリジェント端末でのイベントの検出に応じて前記インテリジェント端末で実行される１つ以上のステップを定義することを特徴とする請求項２９記載の装置。
前記イメージ記述は、更に前記インテリジェント端末のユーザに提供される情報を定義することを特徴とする請求項３１記載の装置。
前記イメージ記述は、前記インテリジェント端末でのイベントの検出に応じて前記インテリジェント端末で実行される１つ以上のローカルな端末機能を定義することを特徴とする請求項２９記載の装置。
前記端末アプリケーション・サービスプロバイダは、前記インテリジェント端末での着呼の検出に応じて、前記第１セッションを確立することを特徴とする請求項２９乃至３３のいずれか１項に記載の装置。
前記サービスノード・アプリケーションプロトコル・サービスプロバイダは、前記インテリジェント端末に向けられたイベントの検出に応じて、端末アプリケーションプロトコル・サービスプロバイダと前記第１セッションを確立することを特徴とする請求項２９乃至３４のいずれか１項に記載の装置。
前記端末アプリケーションプロトコル・サービスプロバイダは、前記インテリジェント端末及びサービスノードで使用される資源が互いに整合性を持つのを確実とするために、前記サービスノード・アプリケーションプロトコル・サービスプロバイダとネゴシエーションを行う手段を備えることを特徴とする請求項２９乃至３５のいずれか１項に記載の装置。
前記端末アプリケーションプロトコル・サービスプロバイダは、前記インテリジェント端末とサービスノードとの間の通信で用いられる符号化の種別を前記サービスノード・アプリケーションプロトコル・サービスプロバイダに明示する手段を備えることを特徴とする請求項２９乃至３６のいずれか１項に記載の装置。
前記符号化の種別が基本符号化ルール（ＢＥＲ：Basic Encoding Rules）であることを特徴とする請求項３７記載の装置。
前記符号化の種別が圧縮符号化ルール（ＰＥＲ：Packed Encoding Rules）であることを特徴とする請求項３７記載の装置。
前記端末アプリケーションプロトコル・サービスプロバイダは、前記第１セッションが維持されている間に、前記帯域制限のある通信手段により前記サービスノード・アプリケーションプロトコル・サービスプロバイダと第２セッションを確立する手段を更に備えることを特徴とする請求項２９乃至３９のいずれか１項に記載の装置。
前記端末アプリケーションプロトコル・サービスプロバイダは、前記オペレーションを２つ以上のプロトコルデータ・ユニットにマッピングすることにより前記端末ベアラ・サービスプロバイダを用いることを特徴とする請求項２９乃至４０のいずれか１項に記載の装置。
前記端末アプリケーションプロトコル・サービスプロバイダは、前記端末ベアラ・サービスプロバイダならびに前記サービスノードベアラ・サービスプロバイダに関連したタイムアウトの発生を防止するために、前記インテリジェント端末から前記サービスノードにオペレーションを送信する手段を備えることを特徴とする請求項４１記載の装置。
前記端末アプリケーションプロトコル・サービスプロバイダは、前記端末ベアラ・サービスプロバイダならびに前記サービスノードベアラ・サービスプロバイダに関連したタイムアウトの発生を防止するために、前記第１セッションの終了及び再確立を行う手段を備えることを特徴とする請求項４１記載の装置。
前記サービスノード・アプリケーションプロトコル・サービスプロバイダは、応答を２つ以上のプロトコルデータ・ユニットにマッピングすることにより前記サービスノードベアラ・サービスプロバイダを用いることを特徴とする請求項２９乃至４３のいずれか１項に記載の装置。
インテリジェント端末であって、
前記インテリジェント端末を、前記インテリジェント端末とサービスノード間で情報の伝送を行う帯域制限のある通信手段と接続する接続手段と、
前記接続手段と接続され、前記サービスノードに配置されたサービスノードベアラ・サービスプロバイダとプロトコルデータ・ユニットを交換するための端末ベアラ・サービスプロバイダと、
前記ユーザが前記インテリジェント端末のマンマシンインタフェースを起動したとの検出に応答し、前記端末ベアラ・サービスプロバイダを用いて、前記サービスノードに配置されたサービスノード・アプリケーションプロトコル・サービスプロバイダと第１セッションを確立し、前記端末ベアラ・サービスプロバイダが前記通信手段で音声接続を確立することを要求することなしに、サービスノード・アプリケーションプロトコル・サービスプロバイダとオペレーションを交換する端末アプリケーションプロトコル・サービスプロバイダと、
前記ユーザにローカルなサービスを提供するとともに、前記端末アプリケーションプロトコル・サービスプロバイダを用いて、サービスノード・サービスアプリケーションにより実行されるリモートユーザサービスを起動する端末サービスアプリケーションとを備え、
前記端末サービスアプリケーションはイメージ記述インタプリタであって、
前記端末アプリケーションプロトコル・サービスプロバイダは、前記端末アプリケーションプロトコル・サービスプロバイダからイメージ記述を受信して前記イメージ記述インタプリタに提供する手段を有し、
前記イメージ記述が前記インテリジェント端末により実行されるオペレーションを定義していることを特徴とするインテリジェント端末。
前記イメージ記述は、前記インテリジェント端末のユーザに提供される情報を定義することを特徴とする請求項４５記載のインテリジェント端末。
前記イメージ記述は、前記インテリジェント端末でのイベントの検出に応じて前記インテリジェント端末で実行される１つ以上のステップを定義することを特徴とする請求項４５記載のインテリジェント端末。
前記イメージ記述は、更に前記インテリジェント端末のユーザに提供される情報を定義することを特徴とする請求項４７記載のインテリジェント端末。
前記イメージ記述は、前記インテリジェント端末におけるイベントの検出に応じて前記インテリジェント端末で実行される１つ以上のローカルな端末機能を定義することを特徴とする請求項４５記載のインテリジェント端末。
前記端末アプリケーション・サービスプロバイダは、前記インテリジェント端末での着呼の検出に応じて、前記第１セッションを確立することを特徴とする請求項４５乃至４９のいずれか１項に記載のインテリジェント端末。
前記サービスノード・アプリケーションプロトコル・サービスプロバイダは、前記インテリジェント端末に向けられたイベントの検出に応じて、前記端末アプリケーションプロトコル・サービスプロバイダと前記第１セッションを確立することを特徴とする請求項４５乃至５０のいずれか１項に記載のインテリジェント端末。
前記端末アプリケーションプロトコル・サービスプロバイダは、前記インテリジェント端末とサービスノードとの間の通信で用いられる符号化の種別を前記サービスノード・アプリケーションプロトコル・サービスプロバイダに明示する手段を備えることを特徴とする請求項４５乃至５１のいずれか１項に記載のインテリジェント端末。
前記符号化の種別が基本符号化ルール（ＢＥＲ：Basic Encoding Rules）であることを特徴とする請求項５２記載のインテリジェント端末。
前記符号化の種別が圧縮符号化ルール（ＰＥＲ：Packed Encoding Rules）であることを特徴とする請求項５３記載のインテリジェント端末。
前記端末アプリケーションプロトコル・サービスプロバイダは、前記第１セッションが維持されている間に、前記帯域制限のある通信手段により前記サービスノード・アプリケーションプロトコル・サービスプロバイダと第２セッションを確立する手段を更に備えることを特徴とする請求項４５乃至５４のいずれか１項に記載のインテリジェント端末。
前記端末アプリケーションプロトコル・サービスプロバイダは、前記オペレーションを２つ以上のプロトコルデータ・ユニットにマッピングすることにより前記端末ベアラ・サービスプロバイダを用いることを特徴とする請求項４５乃至５５のいずれか１項に記載のインテリジェント端末。
前記端末アプリケーションプロトコル・サービスプロバイダは、前記端末ベアラ・サービスプロバイダならびに前記サービスノードベアラ・サービスプロバイダに関連したタイムアウトの発生を防止するために、前記インテリジェント端末から前記サービスノードにオペレーションを送信する手段を備えることを特徴とする請求項５６記載のインテリジェント端末。
前記端末アプリケーションプロトコル・サービスプロバイダは、前記端末ベアラ・サービスプロバイダならびに前記サービスノードベアラ・サービスプロバイダに関連したタイムアウトの発生を防止するために、前記第１セッションの終了及び再確立を行う手段を備えることを特徴とする請求項５６記載のインテリジェント端末。