JP4301377B2 - インテリジェント端末用のアプリケーションプロトコル - Google Patents
インテリジェント端末用のアプリケーションプロトコル Download PDFInfo
- Publication number
- JP4301377B2 JP4301377B2 JP53079798A JP53079798A JP4301377B2 JP 4301377 B2 JP4301377 B2 JP 4301377B2 JP 53079798 A JP53079798 A JP 53079798A JP 53079798 A JP53079798 A JP 53079798A JP 4301377 B2 JP4301377 B2 JP 4301377B2
- Authority
- JP
- Japan
- Prior art keywords
- service
- intelligent terminal
- terminal
- service provider
- service node
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/12—Messaging; Mailboxes; Announcements
- H04W4/14—Short messaging services, e.g. short message services [SMS] or unstructured supplementary service data [USSD]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M1/00—Substation equipment, e.g. for use by subscribers
- H04M1/247—Telephone sets including user guidance or feature selection means facilitating their use
- H04M1/2478—Telephone terminals specially adapted for non-voice services, e.g. email, internet access
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M1/00—Substation equipment, e.g. for use by subscribers
- H04M1/72—Mobile telephones; Cordless telephones, i.e. devices for establishing wireless links to base stations without route selection
- H04M1/724—User interfaces specially adapted for cordless or mobile telephones
- H04M1/72403—User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality
- H04M1/72406—User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality by software upgrading or downloading
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M3/00—Automatic or semi-automatic exchanges
- H04M3/42—Systems providing special services or facilities to subscribers
- H04M3/42136—Administration or customisation of services
- H04M3/42178—Administration or customisation of services by downloading data to substation equipment
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q3/00—Selecting arrangements
- H04Q3/0016—Arrangements providing connection between exchanges
- H04Q3/0029—Provisions for intelligent networking
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q3/00—Selecting arrangements
- H04Q3/42—Circuit arrangements for indirect selecting controlled by common circuits, e.g. register controller, marker
- H04Q3/54—Circuit arrangements for indirect selecting controlled by common circuits, e.g. register controller, marker in which the logic circuitry controlling the exchange is centralised
- H04Q3/545—Circuit arrangements for indirect selecting controlled by common circuits, e.g. register controller, marker in which the logic circuitry controlling the exchange is centralised using a stored programme
- H04Q3/54541—Circuit arrangements for indirect selecting controlled by common circuits, e.g. register controller, marker in which the logic circuitry controlling the exchange is centralised using a stored programme using multi-processor systems
- H04Q3/54566—Intelligent peripherals, adjunct processors
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M1/00—Substation equipment, e.g. for use by subscribers
- H04M1/72—Mobile telephones; Cordless telephones, i.e. devices for establishing wireless links to base stations without route selection
- H04M1/724—User interfaces specially adapted for cordless or mobile telephones
- H04M1/72403—User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality
- H04M1/7243—User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality with interactive means for internal management of messages
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M1/00—Substation equipment, e.g. for use by subscribers
- H04M1/72—Mobile telephones; Cordless telephones, i.e. devices for establishing wireless links to base stations without route selection
- H04M1/724—User interfaces specially adapted for cordless or mobile telephones
- H04M1/72403—User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality
- H04M1/7243—User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality with interactive means for internal management of messages
- H04M1/72433—User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality with interactive means for internal management of messages for voice messaging, e.g. dictaphones
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Human Computer Interaction (AREA)
- Computer Vision & Pattern Recognition (AREA)
- Telephonic Communication Services (AREA)
- Mobile Radio Communication Systems (AREA)
- Communication Control (AREA)
- Exchange Systems With Centralized Control (AREA)
Description
本発明は通信システムに関し、より正確には、プロトコルを含む、通信システムにおける効率的で補助的なサービスのための技術に関するものである。
この技術は、様々な形態の電話機のユーザに広範囲で多種のサービスを提供することで知られている。この種のサービスにアクセスするために、ユーザは、スイッチあるいは、スイッチ機能付き又は無しのコンピュータであるサービスノード(SN)に接続する。多くのシステムにおいて、SN上で動作しているアプリケーションプログラムは、音声を電話機に送るために音声チャネルを使用する。また、音声チャネルは、DTMF(Dual-Tone Multi-Frequency)信号の桁を電話機からSNに送るために、逆方向に使用される。このようなシステムでは、電話機がどんな知能(インテリジェンス)を有することも必要でない。すなわち、サービスノードとユーザ間のやりとりがすべてであり、ユーザは音声を聞いて、電話機のボタンを押して応答すればよい。結果的に、電話機は通信に関しては透過的となり、ユーザを支援することは全くできない。
一方で、より高度なサービスも知られている。このようなサービスとしては、800サービスデータベース(800 Services Database)、クレジットカード照合データベース(Credit Card Verification Database)、地理的呼び出しルーティング(Geographic Call Routing)、複数位置内線ダイアリング(Multilocation Extension Dialing)、ネットワーク自動呼び出しの分配(Network Automatic Call Distribution)、フレキシブル呼び出しルーティング(Flexible Call Routing)、フレキシブルキャリア選択(Flexible Carrier Selection)などが挙げられる。有線電話サービスでは、このような高度な加入電話サービスがインテジェント・ネットワーク(IN;Intelligent Network)を介して提供されるであろう(例えばBellcore Advanced Intelligent Network(AIN)や、AINのCCITT/ITU版であるITUのCS-1、Q.1200など)。
無線通信システムにおいては、高度な加入電話サービスは、1996年3月18日に出願された「INTELLIGNENT MOBILE STATION FOR A CELLULAR TELECOMMUNICATIONS NETWORK」と言う名称の米国特許出願番号第08/617、139号(ここに、この特許が参考として挿入される)などのインテリジェント移動局(インテリジェント端末とも言う)によって実現されるであろう。なんらかの高度なサービスは、SNと協動するインテリジェント移動局によって提供されるであろう。異なる種類のサービスに適応するために、SN内のコンピュータは、多種のインターフェースやスイッチ装置、ファクシミリ装置、音声処理装置、電子メールインターフェース、コンピュータネットワークインターフェース、モデム装置、データ記憶部などの広範囲で多種のリソースを扱うことになる。これらのリソースは、インテリジェント端末内のソフトウェアと相互にやりとりするソフトウェアによって制御される。そのようなSNは、単一ユーザあるいは複数ユーザの1つあるいは複数のSNとの相互のやりとりに対する解決策となる。
SNとインテリジェント端末間の相互のやりとりは、コントロールチャネルとよばれる通信リンクによって行われる。コントロールチャネルは、音声チャネルへモデムを接続することによって確立したり、独立した通信リンクによって確立したりできる。図1a〜1dに、セルラーあるいは通常の固定電話のユーザへのサービスの提供を可能とするSNの配置を示す。
図1aには、モデム103と1つ以上のサービスを提供するためのソフトウェア105とを内蔵するセルラー電話機101の場合が示されている。システム内には、ソフトウェア109とモデム111とを内蔵するSN107も提供される。セルラー電話機101とSNl07間の通信リンクは、セルラーネットワーク113及びその他の各種ネットワーク115(例えば、公衆回線やプライベートネットワーク)によって確立することができる。SNl07は、図1aに示されるように、他のネットワーク115の一部であっても良いし、セルラーネットワーク113の一部であっても良いし、これらのネットワークの1つに(公衆回線に接続されているPABX(private access branch exchange)のような方法を用いて)オーバーレイする形で付加されていても良い。2つのモデム103及び111は、SN107とセルラー電話機101間で行われる情報伝達の物理的な手段を提供している。情報は、SNのソフトウェア109とセルラー電話機のソフトウェア105間でやりとりされる。
図1bに、セルラー電話機が自分のモデムを持たないという点を除けば、図1aに示されている方式と本質的に同様な別の方式を示す。この場合、無線基地局117がモデムの機能を代行している。セルラー電話機上のソフトウェア105からみれば、SN上のソフトウェア109とセルラー電話機上のソフトウェア105間におけるサービス関連情報の流れという点においては、同一と考えることができる。
図1cに、従来の固定電話機119にサービスを提供する方式を示す。この図においては、固定電話機119は1つ以上のサービスを提供するためのソフトウェア123を搭載したモデム装置121に接続されている。前述の方式と異なるのは、セルラーネットワークが固定ネットワークに置き換わっている点である。その他のすべての点において、この配置では、様々なサービスの要求に応じてSN上のソフトウェア111がソフトウェア123と情報交換をして、図1a及び1bに示される配置と同様に機能する。
更に他の方式を図1dに示す。この場合、固定ディジタル電話機127は、各種モデムを介さずに固定ディジタルネットワーク129に直接的に接続される。したがって、ソフトウェア109を搭載するSN107も直接、固定ディジタルネットワーク129に接続される。SN上のソフトウェア109は、各種サービスの提供の要求に応じて、ソフトウェア123と情報交換を行う。
以上のように、SN107及び”サービス電話機”(101、119、127のようなセルラーあるいは固定の各種電話機)が相互対話するソフトウェア123及びモデムと等価の能力を持っていなければならないことがわかる。これらは、相互対話するソフトウェア(あるいはサービスソフトウェア)の通信を維持する上位レベルのプロトコル(”アプリケーションプロトコル”と呼ぶことにする)、及びモデム間の通信を維持する下位レベルのプロトコルからなる、2つの異なるプロトコルによってもっとも効果的に支援される。この階層プロトコルを、図2a及び図2bに示す。階層プロトコルについては一般的な技術として知られているので、詳細についてはここでは言及しない。
図3に、ユーザが1人で、発呼者がSN107の電話番号のみに電話するだけでも、異なる種類の電話機301、303、305、307へのインターフェースを1つのSNで提供できる例を示す。SN107上のソフトウェア309は、異なる電話番号(発呼者にはわからない番号)のユーザを呼び出すことができる。
コントロールチャネルを使用する新しいサービスの特徴は、アプリケーション・プロトコルが新しい機能及び/又はサービスをオープンに支援することを要求する。しかしながら、コントロールチャネルのいくつかの実装においては、新しい機能及び/又はサービスに関連する情報を運ぶために、限られた帯域しか提供されていない。そのため、効率的なアプリケーション・プロトコルが非常に望まれている。
全ヨーロッパ向けGSMシステムに関するETSI勧告のフェーズ2では、ベアラサービス及びテレサービスの両方を補足及び修正できる多くの追加サービスが指定されている。たとえば、呼の禁止や転送のサービス、2つの接続された呼の間での切り替えサービスなどがある。移動通信ネットワークのオペレータは、標準化されたGSMの追加サービスに加えて、オペレータ特有のサービスへの需要の増加を経験している。
オペレータがオペレータ特有のサービスを実装することができるようにするには、ネットワークのサービス・アプリケーションと移動局間でユーザが対話する包括的機構が必要となる。
今日のGSMでは、ネットワークのサービス・アプリケーションと移動局間のヨーザの対話を提供する機構がある。この機構は“USSD(United Supplementary Services Data)”と呼ばれている。以下の文章におけるUSSDについての記述は、GSMのフェーズ2に対応するUSSDで有効になった。USSDはGSMの第1段階にも有ったが、対話の取り扱いはもっと限定されていた。
図4をみると、GSMスイッチングシステム内において、USSDはよく知られている“MAP(Mobile Application Part)”プロトコル401の一部になっている。無線インターフェースでは、USSD操作はレイヤー3の“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を起動することによって、対話を継続してもよい。
図5を用いて、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)は7ビットのアルファベット)、及び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では、同時に1つの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)」である。
本発明の他の態様において、最初のセッションが維持されている間に、インテリジェント端末とサービスノードとの間に第2のセッションが開始される。
本発明の他の態様において、サービスの提供は、インテリジェント端末によって実行されるオペレーションを定義するイメージ記述をサービスノードからインテリジェント端末へ送信するステップを更に備える。
本発明の更に他の態様において、帯域制限のある通信手段を用いてオペレーションをサービスノードに送信するステップは、オペレーションを「非構造の付加的サービスデータ(Unstructured Supplementary Services Data)」プロトコルのデータユニットにマッピングするステップを備える。本発明のある実施の形態においては、帯域制限のある通信手段を用いてオペレーションをサービスノードに送信するステップは、オペレーションを「短メッセージサービス(Short Message Service)」プロトコルのデータユニットにマッピングするステップを備える。
本発明の他の態様において、帯域制限のある通信手段を用いてオペレーションをサービスノードに送信するステップは、オペレーションを下位レイヤ・プロトコルのデータユニットにマッピングするステップを備える。
本発明の更に他の態様において、サービスの提供は、サービスノードからの補助を要求することなく、インテリジェント端末においてローカルなサービス機能を実行するステップを更に備える。
【図面の簡単な説明】
本発明の目的及び利点は、以下の図面と共に詳細な記述を読むことで理解される。
図1a〜1dは、セルラーあるいは従来の固定電話機のユーザへのサービス提供を容易にするサービスノードの可能な配置を示す図である。
図2a及び2bは、通信システムにおけるプロトコルの階層を示す図である。
図3は、ユーザが1人であり発呼者がSNの電話番号のみに電話する場合においても、異なる種類の電話機へのインターフェースを1つのSNで提供できる可能性を示す図である。
図4は、USSDが既知の移動アプリケーション部(MAP)プロトコルの一部として含まれているGSMスイッチングシステムを示す図である。
図5は、USSDサービスを示す図である。
図6は、SNとインテリジェント端末間の関係、及び、本発明の実施の形態に関連する多数の構成要素について示したブロックダイアグラムである。
図7a、7b及び7cは、ユーザ、インテリジェント端末及びSN間の典型的な対話を示すフローチャートである。
図8及び図9は、SNによって起動される動作の可能性を示したフローチャートである。
図10a、10b及び10cは、「空」のインテリジェント端末にアプリケーションをダウンロードする方法を示すフローチャートである。
図11は、本発明における実施の形態の一例に関係するSNのブロックダイアグラムを示す。
図12は、IMSにサービスを提供するためにITAPが用いられているGSMネットワークを示す図である。
図13a〜13eは、ITAPサービスの例を示す図である。
図14は、本発明の一態様における妥当な応答時間を得るためにSNとIMS間に送信されるオペレーションのサイズ及び数の使用制限を示す図である。
図15は、本発明の一態様に関するロード可能なITAPイメージ記述の使用を示す図である。
図16は、メニューオプション用の典型的なイメージ記述を示す図である。
図17及び図18は、GSMフェーズ2に対応するUSSDオペレーションにおけるパラメータ“USSD string”へのITAPオペレーションの典型的なマッピング方法を示す図である。
図19〜51は、ベアラとしてUSSD(GSMフェーズ2に対応)を用いるITAPシナリオを示す図である。
図52〜57は、着呼の選択に関連するシナリオを示す図である。
図58〜61は、本発明の一つの実施の形態に関連して、メールボックス関連のサービスに伴うシナリオを示す図である。
図62及び図63は、本発明の一つの実施の形態に関連して、ルーティングテーブルの更新に伴うシナリオを示す図である。
図64は、本発明の一つの実施の形態に関連して、ITAPを用いる新しいメッセージの通知に関わるシナリオを示す図である。
発明の詳細な説明
本発明のさまざまな特徴を図面を用いて説明する。これらの図面においては、類似の部分は同じ参照文字を用いて特定する。
本発明の第1の実施の形態を、SN603とインテリジェント端末601間の関係及びその構成要素を示すブロックダイアグラムである図6を用いて説明する。アプリケーション(たとえば、より高度なサービスなど)の実装は、インテリジェント端末601内に存在する部分とSN603内に存在する部分との、2つの部分に分けられる。本発明の一態様例として、アプリケーションの2つの部分は、コントロールチャネル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からリモートで呼び出す等)。プリミティブは、パラメータなしでも、あるいは1個、あるいは数個のパラメータを持ってもよい。
端末への制御メッセージ611
制御メッセージの組は、SN603からインテリジェント端末601への伝送のために定義されている。制御メッセージ611は、データを端末のレジスタ615に格納させたり、プリミティブ609を呼び出したりする。状態の変化を指令する制御メッセージ611は、プリミティブの呼び出しである。
端末からのメッセージ613
インテリジェント端末601は、1つ以上のメッセージを、呼び出されたプリミティブ609からSN603へと送信する。メッセージには特別なメッセージが存在し、それぞれはユニークな意味を持つ。また、イベントをSN603に通知する汎用メッセージも存在する。イベント通知メッセージは、現在の状態及びイベントを示すパラメータを含む(たとえば、キー”x”が押されたことや状態監視時刻が終了したことなどを示す)。インテリジェント端末601は、そのようなメッセージを送る時には、適切な基準の決定をSN603に任せるべきである。
端末レジスタ群615
端末レジスタ群615は、端末識別子、ユーザ固有あるいは一時的なデータなどの、インテリジェント端末601に固有のデータを保持している。ユーザあるいはSN603は、端末レジスタ群615を更新することができる。
ユーザとインテリジェント端末とSN603との間の典型的な対話を、図7a、7b及び7cに示されるフローチャートを用いて説明する。この例では、現在、インテリジェント端末601が状態S1であるとする(ステップ701)。ステップ703で、インテリジェント端末601は、ユーザが入力キーkを押したことを検出する。これに応答して、状態S1でキーkに対応するプリミティブ609が特定されて呼び出される(ステップ705)。
イベント(すなわち、端末が状態S1であるときに、ユーザがキーkを押したこと)は、SN603に通知されるべきイベントであってもなくともよい。通知しなくともよい場合(判定ブロック707においてnoの場合)には、処理は判定ブロック723に移る。通知する場合(判定ブロック707においてyesの場合)には、呼び出されたプリミティブがSN603にイベントを通知し(ステップ709)、インテリジェント端末は応答を待つ(ステップ711)。
SN603はイベント通知の受信を検出し(ステップ713)、イベントの解析を行って応答を返す(ステップ715)。解析では、インテリジェント端末601が次にどのプリミティブを呼び出すべきかを決定し、SN603はコントロールチャネル上でアプリケーションプロトコルを用いて、そのプリミティブを呼び出すように指示する(ステップ717)。
インテリジェント端末601はSN603からの通信を受け取り(ステップ719)、プリミティブを呼び出す(すなわち、インテリジェント端末601はプリミティブに指示された記憶してあるルーチンを実行する)(ステップ721)。実行は判定ブロック723まで継続する。
状態S1においてキーkが押されたことに対応するプリミティブの実行結果(判定ブロック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上にダウンロードされている。アプリケーションが変更される場合には、1つ以上の状態表607がSN603からダウンロードされる。
アプリケーションがインテリジェント端末601内に記憶できるよりも多くの状態表607を必要とする場合、端末がその状態になったときに要求があり次第直ちにSN603から不足している状態表がダウンロードされる。これは、インテリジェント端末601がSN603に接続されている場合にも、インテリジェント端末が切断状態にある場合にも行われる。
不足している状態表607をインテリジェント端末601に記憶するのは、一時的である(すなわち、インテリジェント端末が対応する状態に留まる間のみである)。一方、不足している状態表607は、ほかの多数の状態表607と共にスタックに置くこともできる。スタックに新しい状態表607用の領域を確保するために、最も長時間使われていない状態表607が置き換えられる置換方式が用いられる。
また、他のプリミティブの呼出しあるいはオブジェクトコードとして、新しいプリミティブをダウンロードすることによってアプリケーションを起動したり変更したりすることもできる。
図7bのフローチャートに戻って、状態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)。
以上の例では、すべての動作はユーザの操作(たとえばユーザがキーkを押したなど)に対応して起動された。一方で、図8及び図9のフローチャートで示されるように、SN603によってアプリケーションを起動することもできる。
図8において、インテリジェント端末は状態Sにあるとする。SN603はインテリジェント端末に影響するイベントの発生を検出する(ステップ801)。イベントは、たとえば新しい着呼であったり、新しいメッセージであってもよい。これに対し、SN603はイベントを解析する(ステップ803)。解析ではインテリジェント端末601内のどのプリミティブを次に呼び出すべきかを決定し、SN603は、コントロールチャネル605で用いられているアプリケーションプロトコルによって、このプリミティブの呼び出しを指示する(ステップ805)。
インテリジェント端末601はSN603からの通信を受けとり(ステップ807)、受け取った何らかのパラメータを用いてプリミティブを呼び出す(すなわち、インテリジェント端末601はプリミティブに対応する記憶されたルーチンを実行する)(ステップ809)。
この例では、インテリジェント端末はその状態を変化することを要求されないとする。結果として、新しい情報はユーザに示される(ステップ811)。たとえば、新しい情報を用いてインテリジェント端末601のディスプレイの一部が更新される。端末は状態Sに留まる(ステップ813)。
SN603で最初に検出されたイベントはまた、インテリジェント端末601の状態を変化させることもある。図9において、インテリジェント端末の初期状態が状態S1にあるとする。SN603はインテリジェント端末に影響するイベントの発生を検出する(ステップ901)。イベントは、たとえば新しい着呼であったり、新しいメッセージであってもよい。これに対し、SN603はイベントを解析する(ステップ903)。解析ではインテリジェント端末601内のどのプリミティブを次に呼び出すべきかを決定し、SN603は、コントロールチャネル605で用いられているアプリケーションプロトコルによって、このプリミティブの呼び出しを指示する(ステップ905)。
インテリジェント端末601はSN603からの通信を受けとり(ステップ807)、受け取った何らかのパラメータを用いてプリミティブを呼び出す(すなわち、インテリジェント端末601はプリミティブに対応する記憶されたルーチンを実行する)(ステップ909)。
この例では、インテリジェント端末601はその状態をS2に変化させるとする(ステップ911)。結果として、状態S2の情報がユーザに示される(ステップ913)。たとえば、新しい情報を用いてインテリジェント端末601のディスプレイの一部が更新される。端末は状態S2に変化する(ステップ915)。
図7a〜7c、図8及び図9における例は、SN603との関連でさまざまなレベルの自立性によってインテリジェント端末601を動作させる可能性を示している。インテリジェント端末601の自立性は次の範囲内で扱われる。
インテリジェント端末601の動作が完全に自立的である。インテリジェント端末601は、SN603が利用するどんなコントロールチャネルの確立を行わなくとも、ユーザと相互対話ができる。
また、SN603に、制御を完全に取って代わらせ、ユーザに表示する情報を供給させることもできる。この場合、状態表607のどの状態においても、インテリジェント端末601が検出するどのイベントもSN603に報告するように指示される。
アプリケーションは、インテリジェント端末601内の状態表607及び端末レジスタ群615によって定義されるので、ネットワークを介して端末に完全なアプリケーションをダウンロードすることが容易にできる。新しいアプリケーションを、ロードされたブーツストラッププログラムのみを持っているインテリジェント端末601へダウンロードすることもできる。また代わりに、新しいアプリケーションを、ほかのアプリケーションと置き換えるためにインテリジェント端末601にダウンロードすることもできる。
「空」のインテリジェント端末601にアプリケーションをダウンロードする方法を、図10a、10b及び10cに示されるフローチャートを用いて説明する。ここでは、あらかじめ決まっている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に記憶していても良いし、要求の中に含めてSN603から送信されても良い。
これに対して、ユーザはパスワードを入力し(ステップ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に状態1になるように指示し(ステップ1063)、サービス要求を待つ(ステップ1065)。指示の受信に応答して、インテリジェント端末601はユーザに状態1の情報を表示し(ステップ1067)、状態1に留まる(ステップ1069)。
新しい状態表607のダウンロード及びインテリジェント端末601からのイベント通知メッセージに依存しない汎用サービスは、アプリケーションプロトコルの変更やインテリジェント端末601の再プログラムを行うことなしに、新しいアプリケーションの利用を可能とする。
前述の配置は、機能が固定的に配置されていない場合に有利である。機能は、SN603とインテリジェント端末601間を容易に移動できる。新しい機能が追加された場合には、初期的にはSN603に配置され、その後、1つ以上の状態表607としてインテリジェント端末601に記憶される。
機能の配置は、次のような考え方に基づいて最適化できる。
SN603及びインテリジェント端末内のプロセッサの能力及び記憶装置の容量
コントロールチャネル605の伝送容量
ユーザに提供する情報量
SN603にコントロールチャネルの確立が行われず、インテリジェント端末601がスタンドアロンモードであるときに、機能の一部あるいは全部を実行するための条件
機能が使用される頻度
前述の配置は、インテリジェント端末601及びSM603を構成するシステムの機能を容易に変更することができるという面においても利点がある。このことは以下の場合に実現する。
システムがほかのアプリケーションによって使用されているとき
新しいアプリケーションが更に開発され、新しい機能が追加されたとき
何人かのユーザが同じインテリジェント端末601を使用しており、同じアプリケーションに対して個人的なユーザインタフェースを持っているとき
ユーザがユーザのアプリケーションの機能を変更したいと考えているとき
次に、本発明における他の実施の形態について述べる。この実施の形態では、オペレータがより進んだサービスの実装を可能にするUSSD上のアプリケーションプロトコルが提供される。本発明の理解を容易にするために、この実施の形態は移動体通信システムの環境として記述される。しかしながら、ここで説明する技術が移動体通信システムだけでなく、ほかの形態の通信システムにも同等に適用可能であることは、専門技術者によって理解されるであろう。すなわち、移動体端末に関して言えば、MSC/VR、HLRのようなセルラー通信システムの要素などが本発明の範囲を制限すると解釈すべきではなく、本発明のほんの数例が実施されたものと解釈すべきである。
本実施の形態では、サービスアプリケーションのロジックは、ネットワークノード(たとえばSN)と、以前に参照して取り入れた、1996年3月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フェーズ2に関するUSSDプロトコルあるいはSMS(Short Message Protocol:ショートメッセージ・プロトコル)のような下位層のプロトコルを用いることによって伝送される。IMSのユーザは、要求したサービスが存在するサービスノードと通信をおこなう。ITAPによる接続は並行して行われている音声通信と独立に行われる。
ITAPの特徴は以下のものを含む。
サービスの独立性。ITAPは汎用のプロトコルである。あらゆるパーソナル通信サービスのために、ITAPをサポートするIMSを用いることができる。
サービス追加及びサービス修正を行うためにIMSのソフトウェアを変更する必要がない。このことは、サービスの修正や新しいサービスの追加があったときに必要となるソフトウェアの修正のすべてが、ネットワークサービスノードにおいてのみ行えばよいことを意味する。
ベアラの独立性。これは、ITAP通信がベアラの音声接続の存在を必要としないという事実を含んでいる。
ITAPは低速のベアラに対して最適化される。利用可能なベアラはUSSDや(低速のベアラである)SMSを含んでいるので、ITAPプロトコルはユーザにとって実用的な応答時間を達成できるように最適化される。
グラフィック式及びテキスト式両方のインテリジェント移動局をサポートする。
ITAPの概念は標準化に適用できる。
サービスノードはデータマスタである。
オペレータのサービス管理が複雑でない。新しいサービスを追加したり既存のサービスを更新したりすることが容易である。
図11は、本発明における実施の形態の一態様例のSN1101のブロックダイアグラムである。SN1101は、階層的に組織された1つ以上のソフトウェアプログラムを実行するコンピュータ装置によって構成されてよい。最下位レイヤは、既知の技術であるUSSDサービスプロバイダ1103である。USSDサービスプロバイダ1103の上位には、下位のUSSDサービスプロバイダ1103と上位のサービスアプリケーション間のインターフェースサービスを提供するITAPサービスプロバイダ1105がある。プロトコルスタックとして、ITAPサービスプロバイダ1105は以下の事項を受け持つ。
ITAPのオペレーションの符号化及び復号
通信の意味のチェック。たとえば、最初に受信したオペレーションを確認するのは、ITAPバインドオペレーション(BIND operation)である。
特定の実装で使用されているベアラ上にITAPのマッピング(たとえばUSSD)。マッピングは、通信のためのITAPオペレーションを2つ以上のベアラプロトコルデータユニットに分割することも含んでいる。
また、ITAPサービスプロバイダ1105は、getImageDescription(後述)とよばれるITAPオペレーションを、単独で受け持っていてもよい。
図12に、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は、図11に示されるように、USSDサービスプロバイダ1103及びITAPサービスプロバイダ1105を含む移動体サービスノード1101内に存在する。ITAPメッセージは、MAP-USSDメッセージを用いるGSMネットワーク1205、及びレイヤ3-USSDメッセージを用いる無線インターフェースを介して、伝送される。
ITAPサービスの例を、図13aから図13eを用いて説明する。ここで示されているサービスは、ユーザがサービスアプリケーションによって記憶されているメッセージを検索するものである。ステップ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を表示する。この例では、このメニューには検索できる3つの音声メッセージと1つの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には2つの新しいメッセージと1つの古いメッセージが表示される。
ユーザはこれらの選択肢をスクロールすることができる。この例では、ユーザは、この選択肢にマークが付された時に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をより有効に使用できるということは便利である。実際に、本方法により以下のような効果が達成される。
1.サービスロジックがサービスアプリケーション11017だけでなくIMS1201内にも存在するので、より速い応答時間が達成できる。ローカルなメニュー処理もIMS1201内で行うことができる。ネットワークサービス・アプリケーション1107との通信は、ネットワークサービスのデータをフェッチあるいはストアする場合や、ネットワークサービス機能を呼び出す場合にのみ行われる。
更に、ITAPオペレーションは、SMS(Short Message Services)の7ビットアルファベットよりもコンパクトな、BER(Basic Encoding Rules:基本符号化ルール)やPER(Packed Encoding Rules:圧縮符号化ルール)を用いて符号化することができる。
2.IMS1201内にサービスアプリケーションロジックがあるので、オペレータへの特定のサービスのためによりよいユーザインタフェースを用いることができ、IMS1201における他の全サービスのために、同様のMMI方式を用いることができる。たとえば、IMS1201への特定のサービスのために、同様のMMI方式でメニュー処理を行うことができる。また、IMSがグラフィカルインターフェースを持つ場合に、これを利用することができる。
3.ローカルなIMSサービスアプリケーションロジックを介して、ローカルなIMS機能を呼び出すこともできる。そのようなローカルな機能には、番号を対応する名前に変換したり、呼び出し音をだしたり、自動オフフックを行ったりする機能が含まれる。
4.ITAPのセマンティックは、ネットワークタイマの期限切れを防止する。つまり、ITAPサービスの寿命はネットワークUSSDタイマによって制限されることはない。
5.ITAPオペレーションはいくつかのUSSDオペレーションに分割できる。
6.1つの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を用いるPCのような、IMS1201と異なる種類の端末からのサービスデータを扱うことができるようになる。
g)ITAPはベアラに対して独立である。たとえば、SMSのような他の利用可能なベアラ上にITAPをマッピングすることができる。更に、ベアラが存在するその他の電話ネットワークにITAPを用いることもできる。ITAPを以下のようなネットワークに使用することができる。
固定電話ネットワーク
アナログ/ディジタル移動体ネットワーク
衛星ネットワーク
h)ITAPがベアラに対して独立であるとしても、USSDのような遅いベアラに対してITAPが最適化される。
i)ベアラが並列の対話をサポートしている場合、真の並列のITAPセッションを実行することができる。
j)ITAPは以下のように実装することができる。
IMSにおける移動装備の一部として実装
SIM(Subscription Identification Module)でアプリケーションツールキットがサーポートされている場合に、SIMにおいて実装
移動局と、USSDと他の移動局の特定の機能及び呼の処理の制御をサポートするコンピュータデバイスとの間にインタフェースが有る場合において、移動局に接続されたPC、ラップトップ、通信機、オーガナイザ、あるいは、全てのコンピュータデバイスに実装
以前に述べたように、本発明の一態様として、本発明が(USSDやSMSのような)遅いベアラに対して最適化できるという事実がある。IMSのユーザが満足する応答時間を得るために、SNとIMS間に送信されるオペレーションの数と大きさが制限される。これは、IMS1201において、できる限り多くのサービスアプリケーションロジックを持つことによって達成できる。これについては、図14に示す。IMS1401は、3つのレイヤに分割された機能を含んでいる。下から上の順に、ITAPベアラサービスプロバイダ1403、ITAPサービスプロバイダ1405、ITAPの制御下におけるサービスアプリケーションである。
SN1409もやはり、3つのレイヤに分割された機能を含んでいる。下から上の順に、ITAPベアラサービスプロバイダ1411、ITAPサービスプロバイダ1413、1つ以上のサービスアプリケーション1415である。
SN1409及びIMS1401において、サービスアプリケーションプロセス1407及び1415が動作している。それぞれのサービスプロセス1415、1417は、互いに他の装置(IMS1401やSN1409)の状態に独立な自分のステートマシンを持っている。
SN1409及びIMS1401におけるサービスアプリケーションプロセスは、ITAPオペレーションの組を介して通信を行う。Bind1417、Unbind1419及びAlert1421が、基本的なITAPオペレーションに含まれる。更に、ITAPを使用するそれぞれのサービスアプリケーションのために、アプリケーションに依存するオペレーションの組1423がある。それぞれのアプリケーションは、正しいSNサービスアプリケーション機能1415を呼び出す。
複数のITAPセッションは同時に動作できる。しかしながら、複数のセッションが並行に実行できるかどうかは、ベアラの能力に依存している。たとえば、現バージョンのUSSDは並列のUSSD対話をサポートしていないので、新しいITAPのセッションは、一時的に、すでに動作しているセッションを中断させる。
図15において、ITAPを用いる場合のその他の特徴は、IMS1401の再プログラムを行うことなしにサービスの追加や変更ができることである。これは、ロード可能なITAPイメージ記述1501の方法を用いてIMS1401のサービスアプリケーション1407を制御することによって実現される。これらのイメージ記述1501は、MMI、MMIの状態遷移、呼び出すローカル機能、呼び出すSNの機能を定義する。イメージ記述1501を無くしたり、更新されなかった場合には、GetImageDescr 1503と呼ばれるITAPのオペレーションによって、SN1409からフェッチすることができる。
各種のITAPの実施の形態では、イメージ記述1501はサポートされていてもいなくても良い。次の表は、イメージ記述がある場合とない場合における、ITAPのアーキテクチャの比較である。
望ましいITAPオペレーションのセットについて更に詳しく説明する。ITAPオペレーションは、望ましくは、2つの大きなグループに分けられる。
基本的ITAPオペレーション:
これらすべてのオペレーションは基本的、サービス非依存なオペレーションであり、ITAPを使用するすべてのアプリケーションに共通のものである。
アプリケーション依存型ITAPオペレーション:
これらのオペレーションはSN内のサービスアプリケーションをリモートで呼び出すためにIMSによって使用される。
オペレーションの構造は、参考文献として挙げたCCITT勧告X.229及びX.219に関する、Rose(Remote Operation Service Element)標準に準拠する。望ましい基本的ITAPオペレーションについて、更に詳しく説明する。
Bind
BindオペレーションはIMS1401によって起動される。これはROSEクラス1のオペレーションであり、同期型のオペレーションで、成功(result)あるいは失敗(error)を報告する。Bindは次のいずれかの場合に用いられる。(1)ITAPサービスアプリケーションを開始する場合。(2)ITAPセッションを開始する場合。これらの各場合は以下で詳しく解説される。
Unbind
UnbindオペレーションはIMS1401によって起動される。これはROSEクラス5のオペレーションであり、このオペレーションの結果は報告されない。Unbindの目的はITAPセッションを終了させることである。
GetImage Descr
GetImage DescrオペレーションはIMS1401によって起動される。これはROSEクラス1のオペレーションであり、同期型のオペレーションで、成功(result)あるいは失敗(error)を報告する。GetImage DescrオペレーションはSN1409からイメージ記述を要求する。このオペレーションは、イメージや、対応するイメージがキャッシュに存在しない場合にIMS1401によって起動される。このオペレーションはIMS1401及びSN1409がイメージ記述をサポートしている場合に限り、使用される。
Alert
AlertオペレーションはSN1409によって起動される。これはROSEクラス3のオペレーションであり、失敗(error)のみを報告する。Alertオペレーションの目的は、新しいメッセージの通知などのイベントの存在をIMS1401に警告することである。このオペレーションはITAPのレベルに責を持つが、IMS1401はBind、GetImageDescr、Unbindあるいはその他のアプリケーション依存のITAPオペレーションを起動することによってダイアログを継続する。Bindオペレーションは、IMS01401がAlertオペレーションに指定されていないものと異なるアプリケーションのバージョンを持っている場合に起動される。
アプリケーション依存型ITAPオペレーションに関しては、これらはすべてROSEクラス1のオペレーションであり、同期型のオペレーションで、成功(result)あるいは失敗(error)を報告する必要がある。これらのオペレーションは、サービスアプリケーションの機能がSN1409において実行することを、IMS1401が要求した場合に用いられる。要求された機能からの応答は起動したオペレーションからの結果として受信される。ITAPを使用しなければならない各サービスアプリケーション1415のために、アプリケーション依存型ITAPオペレーションが明示されなくてはならない。どのようにこれらのオペレーションを明示するかについては制限がある。これらの制限は以下に説明される。
イメージ記述がサポートされている場合には、各アプリケーション依存型オペレーション用の、起動及び結果の議論はイメージ記述で明示される。
ITAPサービスアプリケーションの開始
加入者が特定のITAPサービスアプリケーションのサービスにアクセスできるようになる前に、ITAPアプリケーションがIMS1409で開始されなくてはならない。この手続きは以下の通りである。
1.ユーザはIMS1401上で起動するサービスのメニューに入る。その後、このアプリケーションのサービスコードがユーザによって入力される。
2.Bindオペレーション1417がMS1401からSN1409に送信される。このオペレーションにおいて、“Bind reason”は”init subscription”にセットされる。
3.SN1409は、アプリケーションの名前及びBindが到来した呼に対して起動された/呼が指示を待っているかどうかに関係する情報を含んだ”Bind result”を返す。
4.IMS1401はアプリケーションのパラメータを記録する。好ましくは、このサービスアプリケーション用のメインメニューのためにIMS MMIに用いられるべきである。
5.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クラス1オペレーションResult、errorあるいはreject)がIMS1401に送信された場合に、いつも起動される。SNにおける「アイドル状態の」タイマの初期値は定数である。
タイムアウトは、ある期間内にIMS1401によって新しいオペレーション(Bind、GetImageDescr、Unbind、アプリケーション依存型ITAPオペレーション)が起動されない場合に検出される。タイムアウトが検出された場合には、SN1409はITAPセッションをローカルに中止し、ベアラがダイアログの構造を持っている場合にはベアラレベルでダイアログを中止する。
IMS1401におけるタイムアウト処理において、IMS1401は、IMS1401によって起動されるROSEクラス1のオペレーション(Bind、GetImageDescr、Unbind、アプリケーション依存型ITAPオペレーション)の応答を監視するタイマを持つ必要がある。タイマ値は送信されたオペレーションそれぞれに固有である必要がある。アプリケーション依存型ITAPオペレーションでは、タイマ値は起動したオペレーションに依存する。イメージ記述がサポートされている場合には、アプリケーション依存型ITAPオペレーション用のタイマ値は、イメージ記述によって設定される。
ある期間内にSN1409からの応答(Result、ErrorあるいはReject)がない場合に、タイムアウトが検出される。タイムアウトが検出された場合、IMS1401はITAPセッションをローカルに中止し、ベアらがダイアログの構造を持っている場合にはベアラレベルでダイアログを中止する。
更にIMS1401は、ある期間内にユーザが動作を行ったかどうかを監視する「アイドル状態の」タイマを装備する必要がある。このタイマは、SN1409からオペレーション(AlertあるいはROSEクラス1オペレーション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オクテットhを越えてはならない。
次に、ITAPイメージ記述について述べる。ITAPイメージ記述は以下の項目を定義するリソースである。
サービスが実行されたときのIMS1401におけるMMI。イメージ記述においては、MMI定義はより高い論理レベルで行われる。実際のイメージフォーマット及び表示はIMS1401によって決定される。
サービスが実行された場合に、IMS1401及びSN1409における機能の呼び出し。
イメージ記述は以下のリストからのオブジェクトを設定する。
ローカルのIMSファンクションコール、アプリケーション依存型ITAPオペレーション(「SNファンクションコール」)の刷新、コンディショナルステートメント、及びラベルステートメントからなる動作項目のリスト。
固定テキスト
IMS標準キーに関する動作
各メニューオプション用の動作のメニュー
動的データのリスト
入出力フィールドの異なる型
動的データの一時記憶領域用の端末レジスタ群
メニューオプション用の典型的なイメージ記述1601を図16に示す。イメージ記述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サービスアプリケーションロジックの修正及びイメージ記述の更新を調整しなくてはならない。
イメージ記述の作成、管理のためのツールを作成しなくてはならない。
図17及び18を用いて、GSMフェーズ2に関連するUSSDオペレーションにおける”USSD string”パラメータへのITAPオペレーションのマッピング方法について解説する。図17はUSSDダイアログを開始するUSSDオペレーションに用いるマッピングを示している。図18はその他のすべてオペレーションへのマッピングを示している。それぞれの文字列は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(すべてのオペレーション)
セグメンテーション情報を指定するこのフィールドは、すべてのオペレーションにおいて存在する。これは、1つの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オペレーションに、1及び2の値が用いられる。それぞれの時間制御は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)により返信する。
3−5の値は、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の値5も、同じダイアログ上に、以前に中止されたITAPセッションを再開するために用いられる。このシナリオの例を以下に示す。
USSD specific tail 1717
USSDオペレーションの開始時のみに含まれる、このspecific tail 1717はGSM 02.90、セクション4.1.2、ケースaに関連して追加された。“#”の文字はSMS標準アルファベットで7ビットを必要とする。8ビット目は0にセットされる。
さて、ベアラ非依存部分に戻って、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文字列の最大長はGSMの仕様で明確に定義されないので、ITAPオペレーションの最大長はどちらかというと不明確な段階にある。
_USSD Request invokeあるいはProcess USSD request invoke用
GSM 09。02は160オクテットの最大長を明記している。しかしながらTCAPレイヤにも制限がある。USSDの各エキスパートたちは、USSD文字列の長さにこれらの制限がどのような影響を与えるかについて、それぞれ異なる情報を与えられてきた。100から150の間という数字がいわれてきた。更に、USSD文字列が128オクテットを越えると、応答時間が増加するA-インターフェースに分割されるともいわれてきた。
_USSD Request resultあるいはProcess USSD Request result用
GSM 02。90では、resultのUSSD文字列は、7ビット標準アルファベットで符号化された文字で80文字が最大の制限であるを明記している。このことは70オクテットが最大であることを意味している。しかしながら、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が2進値”00001111”を持たなくてはならないことを意味する。
以下の節ではUSSDオペレーション及びアイドル状態のタイマ二関連する問題及び解決策について解説する。
一般
SN1409とIMS1401間における通信用のITAPを用いるサービスが実行された場合には、サービス実行中にはITAPセッションを能動状態にしておく必要がある。
ネットワークノード、HLR及びMSC内には、USSDオペレーションがある時間内に応答しなかった場合やUSSDダイアログがある時間使用されなかった場合にUSSDダイアログを終了させるタイマがある。タイマの値は30秒から10分の範囲である。この結果、ITAPを用いるサービスの長さが制限されることになる。より進んだサービスのためにITAPセッションを長時間継続させることが望ましいので、これは問題である。これは、ユーザがITAPセッションを10分以上継続させる場合も同様である。
ProcessUSSDRequestタイマに関する問題
記述:このタイマの値は1分から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フェーズ2仕様において正当なものである。
IMS1401を用いた複数のITAPダイアログは不可能であるので、ひとつのITAPセッションしか同時に能動状態になれない。すでに能動状態にあるセッションがあるときに新しいITAPセッションが開始された場合には、最初のセッションは一時的に中断される。2番目の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は1つのタイマ当たり1つのUSSDダイアログしか認めていないからである)。
なお、タイムアウトが”no input from user”によって起こった場合には、前述され、また以下に図示されるMS1401内のアイドル状態のタイマを用いることによってこの問題を解決することができる。
図19〜51は、USSD(GSMフェーズ2に関連)をベアラとして使用する場合の各シナリオを図示している。
図19は、ITAPセッションが現在進行中でない場合のBindオペレーションを図示している。この図においては、IMS1401はIMSのアプリケーションのバージョンが更新されている(すなわち、端末のバージョンレベルがサービスノードのバージョンレベルと一致する)状態で、ITAPセッションを開始する。
図20は、現在進行中のITAPセッションがない場合の、ほかのBindオペレーションを図示している。しかしながら、この図では、IMS1401はIMSアプリケーションのバージョンアップが必要なITAPセッションを開始する。また、イメージ記述がサポートされているとする。時刻=2においてSN1401が新しいアプリケーションバージョン、MS1401内のキャッシュを消去するための命令、及び消去するイメージのリストを含むResultを返信していることがわかる。
図21は、現在進行中のITAPセッションがないときに、呼に関連した指示2101の手段を用いてMS1401がITAPセッションを開始するシナリオが図示されている。
図22は、IMS1401がBindオペレーションを用いてITAPセッションを開始し、そのなかでSNがBindオペレーションのerrorあるいはrejectを検出するようなITAPのシナリオを図示している。なお、時刻=3で、IMS1401が”Continue、Result(USSD req)”を用いてBindオペレーションを再試行することも可能である。
図23は、現在進行中のIMSセッションがある場合に、IMS1401がITAPセッションを開始するようなITAPのシナリオを図示している。新しいセッションを引き起こすイベント(たとえば、呼の指示など)が検出され、現在進行中のセッションが未処理のInvokeオペレーションを保持している場合には、オペレーションのresultは、開始できる新しいセッション用のBindの前に受信されなければならない。
図24は、現在進行中のITAPセッションがあり、そのなかでSN1409がBindオペレーションのerrorあるいはrejectを検出した場合に、IMS1401がITAPセッションを開始するようなITAPのシナリオを図示している。なお、時刻=4において、IMS1401がセッション2用のBindオペレーションを再試行することも可能である。
図25は、ある時刻にIMS1401がアプリケーションデータをまったく利用できない場合におけるITAPサービスの起動を図示している。なお、IMS1401はbind resultを受信し(ステップ2051)アプリケーションパラメータはIMS1401内に記録される。ITAPセッションは常にITAPオペレーションが開始した後で終了される。
図26及び図27は、アプリケーション非依存型ITAPオペレーションを図示している。図26においては、連続した応答がSN1409から受信される(ステップ2601)。図27では、SN1409はオペレーションのErrorあるいはReject2701を検出する。
図28及び図29はGetImageDescrオペレーションを図示している。図28では、連続した応答がSN1409により生成される(ステップ2801)。図29では、SN1409がオペレーションのerrorあるいはrejectを検出する(ステップ2901)。
図30、図31及び図32は、Unbindオペレーションに関する複数のITAPのシナリオを図示している。図30ではセッションが1つだけ進行しており、連続した応答がSN1409mにより生成される。なお、USSDダイアログがSN1409によって開始された場合には、時刻3においてUSSDダイアログは空のTCAP-Endにより閉じられる。USSDダイアログがIMS1401によって開始される場合には、USSDダイアログはResult(Process USSD Req)により閉じられる。
図31においては、以前に中断されたセッションが再開され、連続した応答がSN1409によって生成される(ステップ3101)。
図32は、1つ以上のいくつかのセッションが進行しており、SN1409がunbindを拒否する(ステップ3201)ようなシナリオが図示されている。なお、この場合にはすべてのITAPセッションは中止される。これは、ITAPレベルでセッションを中止する試みが失敗し、デッドロック状態を回避しなくてはならないという理由で、必要である。
図33〜39は、Alertオペレーションに関するさまざまなシナリオを図示している。図33は、SN1409がIMS1401にイベントの通知を行い(ステップ3301)、IMSアプリケーションバージョンが更新される場合を示している。
図34では、SN1409が、IMS1401にIMSアプリケーションバージョンがSN1409のものと異なる場合に、イベントの通知を行う。図示されたシナリオはイメージ記述がサポートされている場合のものである。
図35は、SN1409が、IMS1401にIMSアプリケーションバージョンがSN1409のものと異なる場合に、イベントの通知を行うようなシナリオである。この場合には、IMS1401はイメージ記述をサポートしておらず、SN1409は下位互換の状態である。
図36は、Sn1409がIMS1401にイベントの通知を行う(ステップ3601)シナリオを示している。この場合には、IMS1401は古いバージョンのITAPをサポートしており、SN1409は下位互換の状態である。
図37では、SN1409はIMS1401にイベントの通知を行う(ステップ3701)。ここでは、IMS1401は古いバージョンのITAPをサポートしているが、SN1409は下位互換の状態ではない。結果として、SN1409はUSSDダイアログを閉じる(ステップ3703)。
図38では、SN1409はAlertオペレーションを生成するが(ステップ3801)、IMS1401はAlertオペレーションのerrorあるいはrejectを検出する。
図39では、SN1409はAlertにしたがうBindオペレーションのerrorあるいはrejectを検出する(ステップ3901)。
図40は、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文字列にマッピングされるかは、図17及び18を用いて前述した。図41〜43に示される以下のシナリオでは、USSD specific header1701、1801内のSegmentation flag1713が分割情報のために用いられる。PERあるいはBERにより符号化されたITAPオペレーションがUSSDオペレーションのUSSD文字列に入らない場合には、それは2つ以上のUSSDオペレーションに分割される。IMS1401あるいはSN1409が“more to come”にセットされたsegmentation flagを伴ったオペレーションを受信した場合には、segmentation flagが“get more info”にセットされたヘッダをつけたUSSDオペレーションは他の実体に送信されなくてはならない。完全なITAPオペレーションが受信された場合には、それは受信実体によって復号されなくてはならない。
図41では、IMSにより開始されたオペレーションがUSSDオペレーションに入りきらない場合が示されている。解決策はITAPオペレーションを2つのUSSDオペレーション4301、4303に分割することである。
ITAPレベルのタイムアウト処理が図44から図49により議論される。図44はIMS1401がオペレーションの開始の前にタイムアウトを検出した場合の(ステップ4401)シナリオが示されている。これにより、すべてのITAPセッションは中止され、EndオペレーションがSN1409に送信される(ステップ4403)。
図45は、IMS1401が、USSDダイアログ用の最初のオペレーションとしてBindを開始した後でタイムアウトを検出するシナリオが図示されている。IMS1401はローカルでITAPセッション及びUSSDダイアログを中止することにより応答する(ステップ4503)。
図46では、IMS1401は「アイドル状態」タイムアウトを検出、すなわち、ユーザからなにも応答がなかった場合である(ステップ4601)。IMS1401はUnbindオペレーションの開始を生成する事によって応答する(ステップ4603)。結果として、Unbindのシナリオは継続し(ステップ4605)、したがって、USSDダイアログが終了するか、以前に中止されたセッションが再開される。
図47は、Alertが受信された後で、IMS1401が「アイドル状態」タイムアウトを検出、すなわち、ユーザがなにも応答しなかった場合のシナリオを示している(ステップ4701)。これに対して、IMS1401は、Unbindオペレーションの開始を含め(ステップ4705)、ITAPセッションを終了する(ステップ4703)。
図48では、「アイドル状態」タイムアウトを検出するのはSN1409である(ステップ4801)。これに対し、AbortオペレーションをIMS1401に送信することを含め、すべてのITAPセッションを中止する(4803)。
図49は、SN1409がAlertを送信し(ステップ4901)、その結果「アイドル状態」タイムアウトを検出するような(ステップ4903)シナリオを図示している。これに対し、SN1409はローカルでITAPセッション及びUSSDダイアログの中止を行う。
図50及び図51は、ネットワーク内でUSSDタイムアウトの発生を回避するために行われる処理に関するシナリオを示している。図50では、ダミーのUSSDオペレーション(ステップ5001)が、USSDRequestタイムアウトを回避するために実行される。図51では、ProcessUSSDRequestタイムアウトを回避するために、IMSで開始されたUSSDダイアログからネットワークで開始されたUSSDダイアログへの切り替えを引き起こす(ステップ5103及び5105)IMS1401内のタイマ期限切れ(ステップ51501)を示している。切り替えは移動局で開始されたUSSDダイア路津を終了させ、新しくネットワークで起動されたUSSDダイアログが設定される(ステップ5107)。切り替え後は、SN1409はITAPセッションを再開する(ステップ5109)。
本発明の1つの実施の形態に関するITAPオペレーションの詳細を以下で説明する。ITAPはアプリケーションの実体間で、相互対話の通信における仕様のための、リモートオペレーションの概念を用いている。ITAPはROSE及び以前に参考文献として採用したCCITT勧告X.208:Abstract Syntax Notation(ASN.1)及びCCITT勧告X.219:Remote Operation:Protocol Specificationとして定義されているASN.1シンタックスにより明示される。
リモートオペレーション
ITAPオペレーションは4つのROSEプリミティブにより定義される。
invoke(request)
Result(positive outcome)
Error(negative outcome)
Reject(protocol error)
各ITAPオペレーションはROSEによって定義される規定にしたがって分類される。
オペレーションクラス1、同期型、成功あるいは失敗を報告
オペレーションクラス2、非同期型、成功あるいは失敗を報告
オペレーションクラス3、非同期型、失敗のみ報告
オペレーションクラス4、非同期型、成功のみ報告
オペレーションクラス5、結果は報告されない
タイマ
使用したタイマ値の範囲は以下により変換して範囲指定する。
s=3秒から10秒
m=15秒から30秒
ml=1分から10分
l=28時間から38時間
オペレーション及びアイドル状態の2種類のタイマが存在する。オペレーションタイマは要求しているアプリケーションの実体が要求の結果を待ている時に起動される。タイマの時間切れまでに結果が帰ってこなかった場合には、オペレーションは取りやめになる。ITAPオペレーションタイマは、次節の“基本的ITAPオペレーション”内のITAPオペレーションそれぞれに対して設定される。アイドル状態タイマはIMS1401内でサービス用の未処理の要求がない場合や、SN1409内で要求が実行されていない場合に起動する。セッション上に活動がない場合には、アイドル状態タイマは期限切れになる。IMS1401及びSN1409内のアイドル状態タイマは以下のようになる。
MS、ml
SN、ml
なお、アイドル状態タイマがIMS1401で期限切れになった場合にIMS1401はUnbindを送信するので、アイドル状態タイマは、セッションを適切な方法で終了させるために、IMS1401内ではSN409内よりも少し短くなくてはならない。
基本的及びアプリケーション依存型ITAPオペレーション
ITAPオペレーションは2つの主要なグループに分割される。
基本的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))
--申し込みの中に含まれているサービスのいずれかを示すビット列。
--最初の8ビットの1ビット目は1番目のサブサービスの有無を示し、
--次の2ビット目は2番目のサブサービスの有無を示し…のように続き、
--最高32個(4オクテット分)のサブサービスを指定することができる。
--異なるビット群の解釈はアプリケーション特有であり、アプリケー
--ション特有の動作を定義する。
SupportOfImage::=BOOLEAN
--TRUEの場合、IMSはイメージ記述をサポートしている。
TBCDString::=OCTET STRING(SIZE(1..64)
--digitが詰められたビット列。digitとは、0_9、*、#、a、b、cのいずれか
--であり、1オクテットに2つのdigitが入る。それぞれのdigitは、
--以下のように符号化される。
--0000_0009(0_9)、1010(*)、1011(#)、1100(a)、1101(b)、1110(c)
--1111は半端な数のdigitがある場合のフィルタとして使われる。
--最初のdigitは、最初の1オクテットの0_3ビット目に蓄えられる。
TerminalType::=SMSSTring(SIZE(1..31))
--IMS端末の形式。例えば、”GH338”。
TextString::=IA5String(SIZE(1..255))
--文字列。
UnsigunedByte::=INTEGER(0..255)
--0から255までの符号無し整数。
アプリケーションに依存するITAPの動作の規則と制限
1.以下の動作はすべてROSEのクラス1である。
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.イベントを受け取ったらすぐにステップ3で示される関連動作を
--実行する。
--画像オブジェクト。一つの画像オブジェクトには一つのメニュー
--またはリストオブジェクトだけが存在しうる。
レジスタのデータ形式
--レジスタはIMSの中にデータを貯めるために使われる。レジスタは
--そのレジスタを定義するイメージ記述が動作中になったとき、すなわち、
--displayImageがIMSで実行された場合に割り当てられる。一度
--レジスタが割り当てられると、ITAPセッションが終わるかまたは
--新しいレジスタが同じIDに割り当てられるまで割り当てられ続ける。
--レジスタが割り当てられている限り、他のイメージ記述のためにその
--レジスタを参照することができる。
--レジスタは、レジスタの中身を表示する画面やリストと関連させる
--ことができる。更にレジスタはローカルまたはリモートにある機能に
--渡す入出力パラメータと関連させることができる。レジスタはベクトル
--を持つものか、ただ一つの項目を含むもののいずれかになる。レジスタが
--ベクトルの場合、ベクトルのインデックスを与えることにより、
--ベクトルの中のある入力にアクセスすることができる。
--sizeパラメータはレジスタがベクトルかどうかを示す。sizeが1の場合、
--そのレジスタは単一のレジスタと考えられる。
--レジスタのデータ形式は独特のタグによって定義される。
--レジスタの項目の参照。ベクトルでないレジスタの参照、または
--ベクトルレジスタを含む項目への参照となることができる。
--ベクトルレジスタにはベクトルのインデックスが必ずある。
--OneRegisterEntryInVectorはベクトルレジスタ内の項目を参照する
--ために使われる。
RegisterId::=INTEGER(0..255)
--レジスタのID。
--ベクトルのインデックスは、レジスタ内の固定値、指定されたリスト列か、
--整数値のいずれかである。インデックスがあるレジスタに蓄えられる場合、
--そのレジスタはLongInt型、またはUnsignedByte型でなければならない。
--ベクトルのインデックスがselectedListRowにもなりうるので、画面の
--内容がリストオブジェクトの中のあるリスト列に依存するイメージ記述を
--デザインすることができる。それゆえ、サービスユーザがリストオブ
--ジェクトをスクロールするときに、IMSは画面を更新することが
--できなければならない。
動作データ形式
--以下に続く用語はパラメータとして使われる。
--simpleValue…ベクトルでないレジスタから与えられる値。その値は
--レジスタのIDだけで一意に決められる。
--レジスタIDは1
--simpleVector…ベクトルレジスタから得られる値。ベクトル全体は
--パラメータとしてパスされる。ベクトルはレジスタIDによって
--一意に決められる。
--レジスタIDは1
--simpleValueInVector…レジスタベクトルの中にあるレジスタ項目から
--得られる値。その値はレジスタIDとベクトルインデックスによって
--一意に決められる。
--レジスタIDは1、ベクトルインデックスは3
--いくつか組み合わせることで動作になる様々な項目。”localFunction”は
--IMSにおいて実行される機能を定義する。”remoteFunction”はサービス
--ノードで実行される機能を定義する。displayImage動作項目は、新しい
--イメージ記述を表示するために使われる。displayImageが実行されるとき、
--現在のイメージ記述の評価が遮断され、新しいイメージ記述が表示される。
--conditionalStatementとlabelStatementは関連している。
--conditionalStatementは評価するための論理的表現を定義する。
--評価結果によると、conditionalStatementは1つまたは2つのlabelStatement
--を参照にして、どこまで実行し続けるかを定義する。labelStatementは、
--動作が実行し続けている実際の場所である。endStatementはある動作の
--実行が即座に止められることを示している。
--条件付きの記述。expressionは評価される表現を定義する。trueとfalse
--のラベルは実行し続けるラベルのIDを定義する。その参照されたラベルは
--同じ動作内で定義されなければならない。少なくともtrueLabelか
--falseLabelのパラメータのうちの一つが定義されなければならない。
--それらのパラメータの一つが省略されている場合、その動作の実行は
--そのパラメータに相当するラベルを持つ次のactionItemまで継続される。
--評価される表現を指定する。その表現は左から右(“firstParameter
--“operator”“secondParameter”の順)に評価される。1番目と2番目の
--パラメータは、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はリストの中で選択されている列の値を持つ。
--1つの列が選択される場合、selectedRegisterは1つの項目を持つ。2つの
--列が選択される場合、レジスタは2つの項目を持つ。1つも選択されない
--場合、レジスタは空である。可能な選択数はpossibleSelectionsパラメー
--タで定義される。
--値からテキスト列への変換を指定している。アイコンはグラフィカルな
--端末のための変換と関係している。
--ITAPの基本データ形式。
SelectedListRow::=NULL
--この形式は選択されたリスト列を指定する。IMSはこの値を計算する。
--初めのリスト列は0である。
入出力フィールドデータ形式
--アドレスの出力または入出力フィールドを指定する。レジスタは
--AddressInfo形式またはNumber形式である。AddressInfo形式のレジスタ
--の表現のために以下の規則が定義されている。
--1.あるアドレスが得られる場合、IMSは自分のアドレス帳の中にある
--アドレスを探し、アドレス帳で見つけた名前を表示する。
--2.名前がネットワークから与えられ、その項目がIMSのアドレス帳にない
--場合、その名前が表示される。
--3.名前が得られないがそのアドレスが得られる場合、そのアドレスが
--表示される。
--加入者は名前とアドレスを結びつけることができる。Number形式の
--レジスタは常に数字として表示される。
--整数の入力または入出力フィールドを指定する。レジスタは符号有り、
--または符号無しの整数形式である。
--数字の出力または入出力フィールドを指定する。レジスタはNumber形式
--である。
--一般的な選択型入出力フィールドを指定する。IMSはこれをメニュー、
--チェックボックス、選択ボタン、選択フィールド、キー入力などとして
--表現する。選択が行われたとき、レジスタはConversionItem形式で
--指定された値を持つ。”moreThanOneAllowed”がFALSEである場合、
--そのレジスタは常に1つの値を持つ。すなわち、サービスユーザは1つの
--選択を行わなければならない。”moreThanOneAllowed”がTRUEである
--場合、最初に選択された項目の値はレジスタの索引0番に蓄えられ、
--2番目に選択された項目の値は索引1番に蓄えられ、以下2番、3番、、、
--と同様に続く。選択がない場合、レジスタは空である。
--オプションフィールドに関連するレジスタを指定する。レジスタは
--以下に示すものである。
--単一のレジスタ、レジスタベクトルの中にある要素、レジスタベクトル。
--テキストの出力または入出力フィールドを指定する。レジスタは
--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
ベクトルレジスタに項目を追加する。ベクトルの始めや終わり、または分類順に項目を追加することができる。この機能は項目が挿入された索引を返す。挿入された索引番号よりも大きい番号を持つ項目は1つ大きい索引へ移される。ベクトルが項目で満杯であり、かつ挿入方法がベクトルの先頭、あるいは分類順である場合、最後の項目は取り除かれ、新しい項目が挿入される。ベクトルが満杯であり、かつ挿入方法がベクトルの終わりである場合、項目数の最大値を超えたことを示すエラーが返される。注:“分類順”の挿入方法は分類されたベクトルだけが使用できる。
入力パラメータ:
出力パラメータ:
エラー:
insertRegisterEntry
ベクトルレジスタに項目を挿入する。挿入された項目よりも大きい索引番号を持つ項目は1つ大きい索引番号に移される。ベクトルが項目で満杯の場合、最後の項目が取り除かれ、新しい項目が挿入される。
入力パラメータ:
出力パラメータ:
なし
エラー:
removeRegisterEntry
一連のベクトルレジスタのある項目を取り除く。取り除かれた項目よりも大きい索引番号を持つ項目は、ギャップを埋めるために1つ小さい索引番号に移される。
入力パラメータ:
出力パラメータ:
なし
エラー:
searchRegister
ベクトルレジスタの中のある項目を検索する。検索項目に該当する最初の項目の索引番号を返す。この機能は該当する項目を見つけるためにレジスタ全体を検索しなければならないので、そのレジスタは分類されていない可能性がある。
入力パラメータ:
出力パラメータ:
エラー:
sortRegister
ベクトルレジスタやベクトルレジスタの付加的なリストを分類する。この機能への入力は、分類されるレジスタである。
入力パラメータ:
出力パラメータ:
なし
エラー:
mergeRegister
2つのベクトルレジスタを合併する。両方のレジスタは同じ形式でなければならない。結果レジスタは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機能によってクリアされる。1つのタイマーだけ始めることができる。
入力パラメータ:
出力パラメータ:
なし
エラー:
stopTimer
タイマーを止める。startTimer機能によってスタートしたタイマーをクリアする。
入力パラメータ:
なし
出力パラメータ:
なし
エラー:
関連する機能を呼ぶ
acceptIncomingCall
IMSで指示された要求を受け入れる、またはIMSを次の入力要求を受け入れられる方式にする。
この機能にはエラー応答がない。即座に要求IDを返す。要求IDは常に1以上である。
入力パラメータ:
なし
出力パラメータ:
エラー:
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セッションは、2通りの方法、すなわちネットワーク主導またはモバイル主導で設立される。ネットワーク主導の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パラメータのサイズは常に4。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=テレックス
--異なる言語の値は、ITAPオペレーションと題された前節における
--言語のデータタイプに対応する。
--ルーティングテーブルの名前の更新。ルーティングテーブル識別の
--値は(1..5)の範囲。
--Type of notofication:0=ダイアルアウト、1=ページャー、2=SMS、
--3=Fax、4=E-メール、5=USSD、6=ITAP
--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
図52から図64を用いて、多くの典型的なITAPセッションのシナリオを説明する。
まず、着呼の選択に関するシナリオを示す図52から図57について述べる。図52は呼が受け付けられるときの、着呼の選択を示している。IMS1401は、Bindオペレーションを用い(ステップ5203)、IMSにおける新しい呼の通知の受信への新しいセッションを開始する(ステップ5201)。SN1409は呼び出し者の名前及び番号を応答する(ステップ5205)。この例では、IMSのアプリケーションバージョンは、SN1409のアプリケーションバージョンと等しく、イメージ記述の開始はキャッシュメモリ上で利用可能である。トラフィックチャネルはすでに割り当てられているので、呼がIMS1401でローカルに許可された場合、直ちに音声接続が確立される(ステップ5207)。新しいセッションはUnbindオペレーションを送信することで閉じられる(ステップ5209)。
図53は、呼の拒否が行われるときの、着呼の選択を示している。IMS1401は、Bindオペレーションを用い(ステップ5303)、IMSにおける新しい呼の通知の受信への新しいセッションを開始する(ステップ5301)。SN1409は発呼者の名前及び番号を応答する(ステップ5305)。この例では、IMSのアプリケーションバージョンはSN1409のアプリケーションバージョンと等しく、イメージ記述の開始はキャッシュメモリ上で利用可能である。呼は拒否され、シグナリングリソースは解放される(ステップ5307)。
図54は、呼の転送が行われるときの、着呼の選択を示している。IMS1401は、Bindオペレーションを用い(ステップ5403)、IMSにおける新しい呼の通知の受信への新しいセッションを開始する(ステップ5401)。SN1409は発呼者の名前及び番号を応答する(ステップ5405)。この例では、IMSのアプリケーションバージョンはSN1409のアプリケーションバージョンと等しく、イメージ記述の開始はキャッシュメモリ上で利用可能である。呼は転送され(ステップ5407)、この転送に関してあらかじめ決まっている送信先が更新される。
図55は、呼の保持が呼び出されるときの、着呼の選択を示している。IMS1401は、Bindオペレーションを用い(ステップ5503)、IMSにおける新しい呼の通知の受信への新しいセッションを開始する(ステップ5501)。SN1409は発呼者の名前及び番号を応答する(ステップ5505)。この例では、IMSのアプリケーションバージョンはSN1409のアプリケーションバージョンと等しく、イメージ記述の開始はキャッシュメモリ上で利用可能である。サービスユーザは発呼者に回線を保持するように要求し(ステップ5507)、呼はしばらくしてから受け付けられる(ステップ5509)。
図56は、折り返しが呼び出される時の、着呼の選択を示している。IMS1401は、Bindオペレーションを用い(ステップ5603)、IMSにおける新しい呼の通知の受信への新しいセッションを開始する(ステップ5601)。SN1409は発呼者の名前及び番号を応答する(ステップ5605)。この例では、IMSのアプリケーションバージョンはSN1409のアプリケーションバージョンと等しく、イメージ記述の開始はキャッシュメモリ上で利用可能である。サービスユーザは個人アクセスアプリケーションを呼び出し、あらかじめ決められたメッセージを発呼者に再生する(ステップ5607)。
図57は、ITAPセッションがすでに進行中であるときの、着呼の選択を示している。サービスノードとIMS1401間にはITAPセッションがすでに確立している(ステップ5701)。IMS1401は、Bindオペレーションを用い(ステップ5705)、IMSにおける新しい呼の通知の受信への新しいセッションを開始する(ステップ5703)。SN1409は発呼者の名前及び番号を応答する(ステップ5707)。呼び出し手続きはIMS1401にすでに確立しているので、呼の受付はIMS1401のみで実行される。サービスノードは、応答イベントの監視によって、呼が受け付けられたことを検出する。新しいセッションはUnbindオペレーションを送信することにより終了する(ステップ5709)。サービスノード1409はIMS1401に空のUSSD requestオペレーションを送信することで、古いセッションを再会する。
メールボックスに関連するサービスを、図58から図61を用いて説明する。図58において、サービスユーザはITAPセッションを開始する(ステップ5801)。MaiboxStatus invokeを発行した後に(ステップ5803)、サービスユーザは音声メールボックスに新しいメッセージについて問い合わせを行う(ステップ5805)。
図59では、サービスユーザはITAPセッションを確立しており、音声メールボックスに問い合わせを行う。サービスユーザは音声メッセージの再生を選択する(ステップ5901)。いったん音声回線がIMS1401に割り当てられれば(ステップ5903)、IMS1401に結果が返送される(ステップ5905)。音声メッセージの再生はDTMFシグナリングによって制御される(ステップ5907)。サービスユーザが音声メールのセッションの終了を選択した場合には、ReleaseResourceオペレーションがSN1409に送信される(ステップ5909)。
図60では、サービスユーザはITAPセッションを確立しており、音声メールボックスあるいは各種の呼のログに問い合わせを行う。サービスユーザは音声メッセージの登録者あるいは呼のログに保持されている番号を選択する(6001)。呼のセットアップは、この資料に前述してあるように進行する。
図61では、IMS1401はITAPセッションを開始し、IMSのアプリケーションバージョンはSN1409のアプリケーションバージョンと等しい。イメージ記述の開始はキャッシュメモリ上で利用可能である。EnquiryMailbox invokeを発行し(ステップ6101)、結果を受信した後(ステップ6103)、faxを受信するためにIMS1401はSendMessage invokedを発行する(ステップ6105)。これに対して、新しいfaxメッセージが転送される(ステップ6107)。
図62及び63を用いて、ルーティングテーブルの更新について説明する。図62では、あるルーティングテーブルがサービスノード1409によって検索され、IMS1401のサービスユーザに表示される(ステップ6201、6203、6205及び6207)。サービスユーザはルーティングテーブルを修正し、それをサービスノードに保存する(ステップ6305)。
図63では、サービスノード1409は利用可能なルーティングテーブルに関して問い合わせをされる(ステップ6301及び6303)。サービスユーザはルーティングテーブルを1つ選択し、IMS1401がSetActive RoutingTable invokeを発行することによって、そのルーティングテーブルはアクティブになる(ステップ6305)。
ITAPを用いる新しいメッセージ通知を、図64を用いて説明する。通常SMSが通知メディアとして用いられる。しかしながら、ITAP/USSDを新しいメッセージの通知メディアとして用いることにより、サービスユーザはすでに確立されたITAPセッションにおいて直ちにメールボックスに問い合わせることができる。SN1409はIMS1401に新しいメッセージについて通知する(ステップ1401)。この場合では、IMSのアプリケーションバージョンはSN1409のアプリケーションバージョンと等しく、イメージ記述の開始はキャッシュメモリ上で利用可能である。新しいメッセージに関する情報はSNからフェッチされる(ステップ6403及び6409)。セッションは図58から図61及び付随する文に示されるように継続する。
本発明が特定の実施の形態を用いて説明された。しかしながら、当業者により容易に明らかにできるように、前述の好適な実施の形態以外の特定の形態に本発明を実施することが可能である。その実施は、本発明の範疇を越えずに実施可能であろう。好適な実施の形態は、まったく説明的なものであり、いずれの面でも制限を行うものではない。本発明の範囲は前述の説明よりもむしろ添付の請求項により与えられ、請求の範囲に入る変更したもの及び等価なもののすべては、請求の範囲に包含される。
Claims (58)
- 帯域制限のある通信手段でインテリジェント端末に接続されたサービスノードを含む通信システムにおいて、前記インテリジェント端末のユーザにサービスを提供する方法であって、
前記サービスノードが、ユーザが前記インテリジェント端末のマンマシンインタフェースを起動したことを示す第1メッセージを、前記インテリジェント端末から受信するステップと、
前記サービスノードで、前記第1メッセージを解析して1つのルーチンを指示するプリミティブを決定するステップと、
前記サービスノードが、前記帯域制限のある通信手段を用いて、前記プリミティブによって指示される前記ルーチンを実行することを前記インテリジェント端末に命令する第2メッセージを、前記インテリジェント端末に送信するステップと、
前記インテリジェント端末で、前記第2メッセージに応答して前記プリミティブによって指示される前記ルーチンを実行するステップとを含み、
前記第2メッセージをインテリジェント端末に送信するステップは、前記帯域制限のある通信手段で音声接続が確立されているかに依存せずに実行されることを特徴とする方法。 - 前記第2メッセージは更にパラメータを含み、
前記プリミティブによって指示されるルーチンを実行するステップは、受信した前記第2メッセージのパラメータを用いることを特徴とする請求項1記載の方法。 - 前記プリミティブによって指示されるルーチンを実行するステップは、前記インテリジェント端末のユーザに情報を提示するステップを含むことを特徴とする請求項1又は2記載の方法。
- 前記プリミティブによって指示されるルーチンを実行するステップは、前記インテリジェント端末の状態を変化させるステップを含むことを特徴とする請求項1乃至3のいずれか1項に記載の方法。
- 前記プリミティブにより指示されるルーチンを実行するステップは、
前記インテリジェント端末で、前記ルーチンの実行のため、前記インテリジェント端末が遷移する状態を定義する状態表であって前記インテリジェント端末に現在記憶されていない状態表が必要かを判定するステップと、
前記状態表が必要と判定された場合に、前記帯域制限のある通信手段を用いて、前記状態表を要求するメッセージを前記インテリジェント端末から前記サービスノードに送信するステップと、
前記インテリジェント端末が、前記帯域制限のある通信手段を用いて、要求された前記状態表を前記サービスノードから受信するステップと
前記インテリジェント端末で、受信した前記状態表を用いて前記ルーチン実行するステップとを備えることを特徴とする請求項1乃至4のいずれか1項に記載の方法。 - 前記インテリジェント端末で、前記サービスノードとの通信を行わずに、前記インテリジェント端末と前記ユーザとの間のメニュー操作の入出力機能を実行するステップを更に備えることを特徴とする請求項1乃至5のいずれか1項に記載の方法。
- 提供される前記サービスに依存しないマンマシンインタフェースの枠組みにしたがって、前記インテリジェント端末のユーザ入出力機能を制御するステップを更に備えることを特徴とする請求項1乃至6のいずれか1項に記載の方法。
- 帯域制限のある通信手段でサービスノードがインテリジェント端末に接続されている通信システムにおいて、前記インテリジェント端末のユーザにサービスを提供する方法であって、
前記インテリジェント端末において、
端末ベアラ・サービスプロバイダを前記通信手段と連結して、前記サービスノードに配置されたサービスノードベアラ・サービスプロバイダとプロトコルデータ・ユニットを交換するステップと、
端末アプリケーションプロトコル・サービスプロバイダが、前記ユーザが前記インテリジェント端末のマンマシンインタフェースを起動したとの検出に応答し、前記端末ベアラ・サービスプロバイダを使用して、前記サービスノードに配置されたサービスノード・アプリケーションプロトコル・サービスプロバイダと第1セッションを確立し、前記端末ベアラ・サービスプロバイダが前記通信手段で音声接続を確立することを要求することなしに、前記サービスノード・アプリケーションプロトコル・サービスプロバイダとオペレーションを交換するステップと、
端末サービスアプリケーションが、前記ユーザにローカルサービスを提供すると共に、前記端末アプリケーションプロトコル・サービスプロバイダを使用して、サービスノード・サービスアプリケーションにより実行されるリモートユーザサービスを要請するステップとを有し、
前記サービスノードにおいて、
サービスノードベアラ・サービスプロバイダを前記通信手段と連結して、前記インテリジェント端末に位置する前記端末ベアラ・サービスプロバイダとプロトコルデータ・ユニットを交換するステップと、
サービスノード・アプリケーションプロトコル・サービスプロバイダが、前記サービスノードベアラ・サービスプロバイダを使用して、前記インテリジェント端末に配置された端末サービスノード・アプリケーションプロトコル・サービスプロバイダと前記第1セッションを確立し、前記サービスノードベアラ・サービスプロバイダが前記通信手段で音声接続を確立することを要求することなしに、前記サービスノード・アプリケーションプロトコル・サービスプロバイダと前記オペレーションを交換するステップと、
サービスノード・サービスアプリケーションが、リモートサービスを提供すると共に、前サービスノード・アプリケーションプロトコル・サービスプロバイダを使用して、端末サービスアプリケーションに対してリモートサービスの結果を提供するステップとを有し、
前記端末サンプルアプリケーションはイメージ記述インタプリタとして提供され、
前記サービスノード・アプリケーションプロトコル・サービスプロバイダが、イメージ記述を前記端末アプリケーションプロトコル・サービスプロバイダに送り、
前記端末アプリケーションプロトコル・サービスプロバイダが、前記イメージ記述を受信して前記イメージ記述インタプリタに提供し、
前記イメージ記述が前記インテリジェント端末により実行されるオペレーションを定義していることを特徴とする方法。 - 前記サービスノードと第1セッションを確立するステップは、前記インテリジェント端末及びサービスノードで使用される資源が互いに整合性を持つのを確実にするために、前記インテリジェント端末とサービスノードとの間でネゴシエーションを行うステップを備えることを特徴とする請求項8記載の方法。
- 前記サービスノードと第1セッションを確立するステップは、前記インテリジェント端末とサービスノードとの間の通信で用いられる符号化の種別を明示するステップを備えることを特徴とする請求項8又は9記載の方法。
- 前記符号化の種別が基本符号化ルール(BER:Basic Encoding Rules)であることを特徴とする請求項10記載の方法。
- 前記符号化の種別が圧縮符号化ルール(PER:Packed Encoding Rules)であることを特徴とする請求項10記載の方法。
- 前記第1セッションが維持されている間に、前記帯域制限のある通信手段により前記インテリジェント端末とサービスノードとの間で第2セッションを開始するステップを更に備えることを特徴とする請求項8乃至12のいずれか1項に記載の方法。
- 前記インテリジェント端末のユーザに提供される情報を定義するイメージ記述を、前記サービスノードから前記インテリジェント端末に送信するステップを更に備えることを特徴とする請求項8乃至13のいずれか1項に記載の方法。
- 前記インテリジェント端末でのイベントの検出に応じて、前記インテリジェント端末により実行される1つ以上のステップを定義するイメージ記述を、前記サービスノードから前記インテリジェント端末に送信するステップを更に備えることを特徴とする請求項8乃至13のいずれか1項に記載の方法。
- 前記イメージ記述は、更に前記インテリジェント端末のユーザに提供される情報を定義することを特徴とする請求項15記載の方法。
- 前記インテリジェント端末でのイベントの検出に応じて、前記インテリジェント端末により実行される1つ以上のローカルな端末機能を定義するイメージ記述を、前記サービスノードから前記インテリジェント端末に送信するステップを更に備えることを特徴とする請求項8乃至13のいずれか1項に記載の方法。
- 前記帯域制限のある通信方法を用いてサービスノードにオペレーションを送信するステップは、前記オペレーションを非構造的な付加サービスデータのプロトコルデータ・ユニットにマッピングするステップを備えることを特徴とする請求項8乃至17のいずれか1項に記載の方法。
- 前記帯域制限のある通信方法を用いてサービスノードにオペレーションを送信するステップは、前記オペレーションを2つ以上の非構造的な付加サービスデータのプロトコルデータ・ユニットにマッピングするステップを備えることを特徴とする請求項8乃至17のいずれか1項に記載の方法。
- 前記帯域制限のある通信方法を用いてサービスノードにオペレーションを送信するステップは、前記オペレーションを短メッセージサービスのプロトコルデータ・ユニットにマッピングするステップを備えることを特徴とする請求項8乃至17のいずれか1項に記載の方法。
- 前記帯域制限のある通信方法を用いてサービスノードにオペレーションを送信するステップは、前記オペレーションを下位レイヤプロトコルのプロトコルデータ・ユニットにマッピングするステップを備えることを特徴とする請求項8乃至17のいずれか1項に記載の方法。
- 前記下位レイヤプロトコルのサービスプロバイダに関連したタイムアウトの発生を防止するために、前記インテリジェント端末から前記サービスノードにオペレーションを送信するステップを更に備えることを特徴とする請求項21記載の方法。
- 前記オペレーションがアプリケーションプロトコル・サービスプロバイダに関連するものであって、前記下位レイヤプロトコルのサービスプロバイダに関連するタイムアウトの発生を防止するために、アプリケーションプロトコルサービスのセッションの終了及び再確立を行うステップを更に備えることを特徴とする請求項21記載の方法。
- 前記帯域制限のある通信方法を用いてサービスノードにオペレーションを送信するステップは、前記オペレーションを下位レイヤプロトコルの2つ以上のプロトコルデータ・ユニットにマッピングするステップを備えることを特徴とする請求項8乃至17のいずれか1項に記載の方法。
- 前記サービスノードからの補助を要求することなく、前記インテリジェント端末でローカルサービス機能を実行するステップを更に備えることを特徴とする請求項8乃至24のいずれか1項に記載の方法。
- 前記サービスノードで、前記帯域制限のある通信方法を介して前記端末サービスアプリケーションに対してリモートサービスの結果を提供するステップは、前記結果を下位レイヤプロトコルの2つ以上のプロトコルデータ・ユニットにマッピングするステップを備えることを特徴とする請求項8乃至25のいずれか1項に記載の方法。
- 前記サービスノードで、前記帯域制限のある通信手段を介して前記インテリジェント端末と前記第1セッションを開始するステップを更に備えることを特徴とする請求項8乃至26のいずれか1項に記載の方法。
- 前記サービスノードで、前記帯域制限のある通信方法を介して前記インテリジェント端末と前記第1セッションを開始するステップは、前記インテリジェント端末に向けられたイベントの検出に応じて実行されることを特徴とする請求項27記載の方法。
- ユーザにサービスを提供する装置であって、
インテリジェント端末と、
サービスノードと、
前記インテリジェント端末とサービスノード間で情報の伝送を行う帯域制限のある通信手段とを備え、
前記インテリジェント端末は、
前記通信手段と接続され、前記サービスノードに配置されたサービスノードベアラ・サービスプロバイダとプロトコルデータ・ユニットを交換するための端末ベアラ・サービスプロバイダと、
前記ユーザが前記インテリジェント端末のマンマシンインタフェースを起動したとの検出に応答し、前記端末ベアラ・サービスプロバイダを用いて、前記サービスノードに配置されたサービスノード・アプリケーションプロトコル・サービスプロバイダと第1セッションを確立し、前記端末ベアラ・サービスプロバイダが前記通信手段上で音声接続を確立することを要求することなしに、サービスノード・アプリケーションプロトコル・サービスプロバイダとオペレーションを交換する端末アプリケーションプロトコル・サービスプロバイダと、
前記ユーザにローカルなサービスを提供するとともに、前記端末アプリケーションプロトコル・サービスプロバイダを用いて、サービスノード・サービスアプリケーションにより実行されるリモートユーザサービスを起動する端末サービスアプリケーションとを備え、
前記サービスノードは、
前記通信手段と接続され、前記インテリジェント端末に配置された端末ベアラ・サービスプロバイダとプロトコルデータ・ユニットを交換するためのサービスノードベアラ・サービスプロバイダと、
前記サービスノードベアラ・サービスプロバイダを用いて、前記インテリジェント端末に配置された端末アプリケーションプロトコル・サービスプロバイダと前記第1セッションを確立し、前記サービスノードベアラ・サービスプロバイダが前記通信手段で音声接続を確立することを要求することなしに、前記端末アプリケーションプロトコル・サービスプロバイダと前記オペレーションを交換するよう動作可能なサービスノード・アプリケーションプロトコル・サービスプロバイダと、
リモートサービスを実行するとともに、前記サービスノード・アプリケーションプロトコル・サービスプロバイダを用いて、前記端末サービスアプリケーションにリモートサービスの結果を提供するためのサービスノード・サービスアプリケーションとを備え、
前記端末サービスアプリケーションはイメージ記述インタプリタであって、
前記サービスノード・アプリケーションプロトコル・サービスプロバイダは、イメージ記述を前記端末アプリケーションプロトコル・サービスプロバイダに送る手段を有し、
前記端末アプリケーションプロトコル・サービスプロバイダは、前記イメージ記述を受信して前記イメージ記述インタプリタに提供する手段を有し、
前記イメージ記述が前記インテリジェント端末により実行されるオペレーションを定義していることを特徴とする装置。 - 前記イメージ記述は、前記インテリジェント端末のユーザに提供される情報を定義することを特徴とする請求項29記載の装置。
- 前記イメージ記述は、前記インテリジェント端末でのイベントの検出に応じて前記インテリジェント端末で実行される1つ以上のステップを定義することを特徴とする請求項29記載の装置。
- 前記イメージ記述は、更に前記インテリジェント端末のユーザに提供される情報を定義することを特徴とする請求項31記載の装置。
- 前記イメージ記述は、前記インテリジェント端末でのイベントの検出に応じて前記インテリジェント端末で実行される1つ以上のローカルな端末機能を定義することを特徴とする請求項29記載の装置。
- 前記端末アプリケーション・サービスプロバイダは、前記インテリジェント端末での着呼の検出に応じて、前記第1セッションを確立することを特徴とする請求項29乃至33のいずれか1項に記載の装置。
- 前記サービスノード・アプリケーションプロトコル・サービスプロバイダは、前記インテリジェント端末に向けられたイベントの検出に応じて、端末アプリケーションプロトコル・サービスプロバイダと前記第1セッションを確立することを特徴とする請求項29乃至34のいずれか1項に記載の装置。
- 前記端末アプリケーションプロトコル・サービスプロバイダは、前記インテリジェント端末及びサービスノードで使用される資源が互いに整合性を持つのを確実とするために、前記サービスノード・アプリケーションプロトコル・サービスプロバイダとネゴシエーションを行う手段を備えることを特徴とする請求項29乃至35のいずれか1項に記載の装置。
- 前記端末アプリケーションプロトコル・サービスプロバイダは、前記インテリジェント端末とサービスノードとの間の通信で用いられる符号化の種別を前記サービスノード・アプリケーションプロトコル・サービスプロバイダに明示する手段を備えることを特徴とする請求項29乃至36のいずれか1項に記載の装置。
- 前記符号化の種別が基本符号化ルール(BER:Basic Encoding Rules)であることを特徴とする請求項37記載の装置。
- 前記符号化の種別が圧縮符号化ルール(PER:Packed Encoding Rules)であることを特徴とする請求項37記載の装置。
- 前記端末アプリケーションプロトコル・サービスプロバイダは、前記第1セッションが維持されている間に、前記帯域制限のある通信手段により前記サービスノード・アプリケーションプロトコル・サービスプロバイダと第2セッションを確立する手段を更に備えることを特徴とする請求項29乃至39のいずれか1項に記載の装置。
- 前記端末アプリケーションプロトコル・サービスプロバイダは、前記オペレーションを2つ以上のプロトコルデータ・ユニットにマッピングすることにより前記端末ベアラ・サービスプロバイダを用いることを特徴とする請求項29乃至40のいずれか1項に記載の装置。
- 前記端末アプリケーションプロトコル・サービスプロバイダは、前記端末ベアラ・サービスプロバイダならびに前記サービスノードベアラ・サービスプロバイダに関連したタイムアウトの発生を防止するために、前記インテリジェント端末から前記サービスノードにオペレーションを送信する手段を備えることを特徴とする請求項41記載の装置。
- 前記端末アプリケーションプロトコル・サービスプロバイダは、前記端末ベアラ・サービスプロバイダならびに前記サービスノードベアラ・サービスプロバイダに関連したタイムアウトの発生を防止するために、前記第1セッションの終了及び再確立を行う手段を備えることを特徴とする請求項41記載の装置。
- 前記サービスノード・アプリケーションプロトコル・サービスプロバイダは、応答を2つ以上のプロトコルデータ・ユニットにマッピングすることにより前記サービスノードベアラ・サービスプロバイダを用いることを特徴とする請求項29乃至43のいずれか1項に記載の装置。
- インテリジェント端末であって、
前記インテリジェント端末を、前記インテリジェント端末とサービスノード間で情報の伝送を行う帯域制限のある通信手段と接続する接続手段と、
前記接続手段と接続され、前記サービスノードに配置されたサービスノードベアラ・サービスプロバイダとプロトコルデータ・ユニットを交換するための端末ベアラ・サービスプロバイダと、
前記ユーザが前記インテリジェント端末のマンマシンインタフェースを起動したとの検出に応答し、前記端末ベアラ・サービスプロバイダを用いて、前記サービスノードに配置されたサービスノード・アプリケーションプロトコル・サービスプロバイダと第1セッションを確立し、前記端末ベアラ・サービスプロバイダが前記通信手段で音声接続を確立することを要求することなしに、サービスノード・アプリケーションプロトコル・サービスプロバイダとオペレーションを交換する端末アプリケーションプロトコル・サービスプロバイダと、
前記ユーザにローカルなサービスを提供するとともに、前記端末アプリケーションプロトコル・サービスプロバイダを用いて、サービスノード・サービスアプリケーションにより実行されるリモートユーザサービスを起動する端末サービスアプリケーションとを備え、
前記端末サービスアプリケーションはイメージ記述インタプリタであって、
前記端末アプリケーションプロトコル・サービスプロバイダは、前記端末アプリケーションプロトコル・サービスプロバイダからイメージ記述を受信して前記イメージ記述インタプリタに提供する手段を有し、
前記イメージ記述が前記インテリジェント端末により実行されるオペレーションを定義していることを特徴とするインテリジェント端末。 - 前記イメージ記述は、前記インテリジェント端末のユーザに提供される情報を定義することを特徴とする請求項45記載のインテリジェント端末。
- 前記イメージ記述は、前記インテリジェント端末でのイベントの検出に応じて前記インテリジェント端末で実行される1つ以上のステップを定義することを特徴とする請求項45記載のインテリジェント端末。
- 前記イメージ記述は、更に前記インテリジェント端末のユーザに提供される情報を定義することを特徴とする請求項47記載のインテリジェント端末。
- 前記イメージ記述は、前記インテリジェント端末におけるイベントの検出に応じて前記インテリジェント端末で実行される1つ以上のローカルな端末機能を定義することを特徴とする請求項45記載のインテリジェント端末。
- 前記端末アプリケーション・サービスプロバイダは、前記インテリジェント端末での着呼の検出に応じて、前記第1セッションを確立することを特徴とする請求項45乃至49のいずれか1項に記載のインテリジェント端末。
- 前記サービスノード・アプリケーションプロトコル・サービスプロバイダは、前記インテリジェント端末に向けられたイベントの検出に応じて、前記端末アプリケーションプロトコル・サービスプロバイダと前記第1セッションを確立することを特徴とする請求項45乃至50のいずれか1項に記載のインテリジェント端末。
- 前記端末アプリケーションプロトコル・サービスプロバイダは、前記インテリジェント端末とサービスノードとの間の通信で用いられる符号化の種別を前記サービスノード・アプリケーションプロトコル・サービスプロバイダに明示する手段を備えることを特徴とする請求項45乃至51のいずれか1項に記載のインテリジェント端末。
- 前記符号化の種別が基本符号化ルール(BER:Basic Encoding Rules)であることを特徴とする請求項52記載のインテリジェント端末。
- 前記符号化の種別が圧縮符号化ルール(PER:Packed Encoding Rules)であることを特徴とする請求項53記載のインテリジェント端末。
- 前記端末アプリケーションプロトコル・サービスプロバイダは、前記第1セッションが維持されている間に、前記帯域制限のある通信手段により前記サービスノード・アプリケーションプロトコル・サービスプロバイダと第2セッションを確立する手段を更に備えることを特徴とする請求項45乃至54のいずれか1項に記載のインテリジェント端末。
- 前記端末アプリケーションプロトコル・サービスプロバイダは、前記オペレーションを2つ以上のプロトコルデータ・ユニットにマッピングすることにより前記端末ベアラ・サービスプロバイダを用いることを特徴とする請求項45乃至55のいずれか1項に記載のインテリジェント端末。
- 前記端末アプリケーションプロトコル・サービスプロバイダは、前記端末ベアラ・サービスプロバイダならびに前記サービスノードベアラ・サービスプロバイダに関連したタイムアウトの発生を防止するために、前記インテリジェント端末から前記サービスノードにオペレーションを送信する手段を備えることを特徴とする請求項56記載のインテリジェント端末。
- 前記端末アプリケーションプロトコル・サービスプロバイダは、前記端末ベアラ・サービスプロバイダならびに前記サービスノードベアラ・サービスプロバイダに関連したタイムアウトの発生を防止するために、前記第1セッションの終了及び再確立を行う手段を備えることを特徴とする請求項56記載のインテリジェント端末。
Applications Claiming Priority (7)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US78200697A | 1997-01-06 | 1997-01-06 | |
US08/782,006 | 1997-01-06 | ||
US3617097P | 1997-01-29 | 1997-01-29 | |
US60/036,170 | 1997-01-29 | ||
US08/825,177 | 1997-03-27 | ||
US08/825,177 US6055424A (en) | 1997-01-29 | 1997-03-27 | Intelligent terminal application protocol |
PCT/SE1997/002217 WO1998031172A1 (en) | 1997-01-06 | 1997-12-30 | Intelligent terminal application protocol |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2001507899A JP2001507899A (ja) | 2001-06-12 |
JP4301377B2 true JP4301377B2 (ja) | 2009-07-22 |
Family
ID=27364982
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP53079798A Expired - Lifetime JP4301377B2 (ja) | 1997-01-06 | 1997-12-30 | インテリジェント端末用のアプリケーションプロトコル |
Country Status (13)
Country | Link |
---|---|
EP (1) | EP1005762B1 (ja) |
JP (1) | JP4301377B2 (ja) |
KR (1) | KR100592451B1 (ja) |
CN (1) | CN1235421C (ja) |
AU (1) | AU732466B2 (ja) |
BR (1) | BR9714265B1 (ja) |
CA (1) | CA2277090C (ja) |
DE (1) | DE69736492T2 (ja) |
EE (1) | EE9900269A (ja) |
HK (1) | HK1028155A1 (ja) |
ID (1) | ID25836A (ja) |
NO (1) | NO993152L (ja) |
WO (1) | WO1998031172A1 (ja) |
Families Citing this family (15)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
SE513098C2 (sv) * | 1998-11-16 | 2000-07-10 | Ericsson Telefon Ab L M | Mobilstation, utrustning för anslutning till mobilstation, växelsystem i mobilkommunikationsystem samt mobilkommunikationsystem |
EP1003096A1 (en) * | 1998-11-19 | 2000-05-24 | Alcatel | Mediation device development method |
FR2810841B1 (fr) * | 2000-06-22 | 2005-07-29 | Bull Cp8 | Procede pour le traitement et la transmission de donnees numeriques sur un reseau de telephonie mobile, notamment a la norme "gsm", et systeme embarque a puce electronique |
US7418254B2 (en) * | 2001-02-20 | 2008-08-26 | Microsoft Corporation | Mobile communication device dynamic service application and dynamic service application scripting |
EP1442619A2 (en) * | 2001-08-14 | 2004-08-04 | Koninklijke Philips Electronics N.V. | Method of and system for providing a programming information for programming a device |
US7039398B2 (en) * | 2002-08-30 | 2006-05-02 | Qualcomm Incorporated | Server processing of interactive screens for a wireless device |
JP4537147B2 (ja) * | 2004-08-06 | 2010-09-01 | 富士通株式会社 | 端末装置、メッセージ表示方法及びメッセージ表示プログラム |
US20080020752A1 (en) * | 2006-07-24 | 2008-01-24 | Webb Ronald J | Fault Tolerant User Interface for Wireless Device |
JP4490460B2 (ja) * | 2006-07-24 | 2010-06-23 | 三星電子株式会社 | 障害許容性を提供する方法及びハンドセットとそのシステム |
US20090169171A1 (en) * | 2007-12-27 | 2009-07-02 | Motorola, Inc. | Methods and devices for coordinating functions of multimedia devices |
CN101631293B (zh) * | 2009-08-11 | 2012-01-11 | 中兴通讯股份有限公司 | 一种实现非结构化补充数据业务的方法及装置 |
CN101860848B (zh) * | 2010-06-11 | 2016-01-20 | 中兴通讯股份有限公司 | 向用户设备提供服务业务的方法及*** |
JP5438043B2 (ja) * | 2011-02-09 | 2014-03-12 | 株式会社Nttドコモ | 移動局、通信アプリケーション及び移動通信方法 |
CN107835330A (zh) * | 2017-11-29 | 2018-03-23 | 天津光电通信技术有限公司 | 一种电话线路检测设备 |
CN114374769B (zh) * | 2021-12-01 | 2024-07-19 | 恒安嘉新(北京)科技股份公司 | 一种异常号码的获取方法、装置、服务器和存储介质 |
Family Cites Families (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
GB9206679D0 (en) * | 1992-03-27 | 1992-05-13 | Hutchison Microtel Limited | Mobile terminals and mobile communication networks involving such terminals |
EP0717570A3 (de) * | 1994-12-12 | 2000-01-05 | Siemens Aktiengesellschaft | Verfahren zur Nutzung von nicht-anrufbezogenen Diensten durch Netzteilnehmer eines Kommunikationsnetzes |
US5752188A (en) * | 1994-12-23 | 1998-05-12 | Telefonaktiebolaget Lm Ericsson | Unstructured supplementary service data from a home location register to an external node |
DE19520632C2 (de) * | 1995-06-06 | 1997-09-04 | Siemens Ag | Verfahren und Anordnung zum Rufen eines Teilnehmers über ein Mobilfunknetz |
EP0772367A3 (de) * | 1995-09-07 | 1999-05-06 | Siemens Aktiengesellschaft | Mobilfunksystem |
-
1997
- 1997-12-30 WO PCT/SE1997/002217 patent/WO1998031172A1/en active IP Right Grant
- 1997-12-30 BR BRPI9714265-4A patent/BR9714265B1/pt not_active IP Right Cessation
- 1997-12-30 JP JP53079798A patent/JP4301377B2/ja not_active Expired - Lifetime
- 1997-12-30 KR KR1019997006117A patent/KR100592451B1/ko not_active IP Right Cessation
- 1997-12-30 CA CA002277090A patent/CA2277090C/en not_active Expired - Fee Related
- 1997-12-30 ID IDW990838D patent/ID25836A/id unknown
- 1997-12-30 AU AU55826/98A patent/AU732466B2/en not_active Ceased
- 1997-12-30 EP EP97952167A patent/EP1005762B1/en not_active Expired - Lifetime
- 1997-12-30 DE DE69736492T patent/DE69736492T2/de not_active Expired - Lifetime
- 1997-12-30 EE EEP199900269A patent/EE9900269A/xx unknown
- 1997-12-30 CN CNB971820198A patent/CN1235421C/zh not_active Expired - Fee Related
-
1999
- 1999-06-24 NO NO993152A patent/NO993152L/no not_active Application Discontinuation
-
2000
- 2000-11-14 HK HK00107244A patent/HK1028155A1/xx not_active IP Right Cessation
Also Published As
Publication number | Publication date |
---|---|
AU732466B2 (en) | 2001-04-26 |
HK1028155A1 (en) | 2001-02-02 |
CN1254482A (zh) | 2000-05-24 |
CA2277090A1 (en) | 1998-07-16 |
JP2001507899A (ja) | 2001-06-12 |
DE69736492D1 (de) | 2006-09-21 |
ID25836A (id) | 2000-11-09 |
BR9714265B1 (pt) | 2011-10-04 |
WO1998031172A1 (en) | 1998-07-16 |
NO993152L (no) | 1999-09-06 |
CA2277090C (en) | 2007-04-24 |
CN1235421C (zh) | 2006-01-04 |
KR100592451B1 (ko) | 2006-06-22 |
EP1005762A1 (en) | 2000-06-07 |
BR9714265A (pt) | 2000-04-18 |
EP1005762B1 (en) | 2006-08-09 |
DE69736492T2 (de) | 2007-03-15 |
EE9900269A (et) | 2000-02-15 |
NO993152D0 (no) | 1999-06-24 |
AU5582698A (en) | 1998-08-03 |
KR20000069905A (ko) | 2000-11-25 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6055424A (en) | Intelligent terminal application protocol | |
US7107068B2 (en) | System and method for provisioning of text message services | |
JP4301377B2 (ja) | インテリジェント端末用のアプリケーションプロトコル | |
TW307080B (ja) | ||
US7283808B2 (en) | System, method and mobile device for remote control of a voice mail system | |
US7995715B2 (en) | Communications systems and methods for exchanging messages between users | |
US6829474B1 (en) | System for providing multimedia value-added services | |
US6400816B1 (en) | Network-independent communications system | |
US20020019225A1 (en) | Communication control system using telephone directory management system of mobile phone | |
US20020071528A1 (en) | Communication apparatus | |
KR20040053341A (ko) | 다수의 사용자에게 음성메일 메시지 송신 | |
KR19990087609A (ko) | 개인통신 인터네트워킹 | |
US7684553B2 (en) | Method for transmitting data in a communication network | |
WO1999037070A1 (en) | Communication system with automatic information and media conversion | |
CN101110786B (zh) | 一种基于软交换网络实现的统一消息*** | |
WO2002049319A2 (en) | A method and system for handling multi-part messages by users of cellular phones | |
KR100578335B1 (ko) | 개인 자동 응답 서비스 제공 방법 및 시스템 | |
KR20020036603A (ko) | 통합 메시징 시스템을 이용한 인터넷폰 서비스 시스템 및방법 | |
JP3388893B2 (ja) | パーソナル通信サービス装置 | |
KR100617288B1 (ko) | 통화중 문자 메시지 전송 방법 및 장치 | |
KR100737139B1 (ko) | 인터넷 환경에서의 평생 번호 서비스 제공 시스템과 그 방법 | |
KR100710137B1 (ko) | 무선 인터넷을 이용한 통화 내용 전송 방법 | |
KR20040087782A (ko) | 통화중 양방향 효과음 전송 서비스 시스템 및 방법 | |
AU2002311739A1 (en) | System and method for provisioning of text message services |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20041221 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080513 |
|
A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20080812 |
|
A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20080922 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080916 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20090317 |
|
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20090415 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120501 Year of fee payment: 3 |
|
R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120501 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130501 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140501 Year of fee payment: 5 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313113 |
|
S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313113 |
|
R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
EXPY | Cancellation because of completion of term |